Re: is this a bug in glibc or readpst?

[Florian Weimer <fweimer@redhat.com>]

* Paul Wise via Libc-help:

> readpst from Debian buster in multi-process mode works but readpst from
> Debian bullseye randomly loses some data. Current readpst works on
> Debian buster but not Debian bullseye. The problem isn't related to the
> GCC optimisation level. The problem isn't compiler related, clang
> exhibits the problem too. Upgrading libc6 from 2.28-10 to 2.29-1 caused
> the issue. Bisecting glibc pointed at commit 0b727ed4d, which is titled
> "libio: Flush stream at freopen (BZ#21037)" and looks legitimate as it
> aligns glibc freopen with POSIX specifications. readpst is using
> freopen() after fork() to get new *.pst FILE pointers for child
> processes. Both the parent and child FILE are opened read-only. The
> FILE position is 0 after freopen for both scenarios. readpst seems to
> be skipping some PST file blocks in the broken scenario. The debug logs
> seem to indicate that in the broken scenario it reads data from a wrong
> location, even though the file position is 0 after freopen. Switching
> the readpst code to use fclose()+fopen() after fork() instead of
> freopen() after fork() fixes the issue.

Fork still shares the underlying file description.  It only duplicates
the descriptors.  If the subprocess changes the file pointer back to 0,
it will affect the original process, too.  This is just how file
descriptors work.

Could this explain the issue?

Thanks,
Florian