On Fri, 2022-12-02 at 18:37 +0100, Florian Weimer wrote:

> Could you run it under strace -k, with debuginfo?  Hopefully that will
> shed some light on the problem.

Finally got back to working on this.

With glibc 2.39+ freopen these calls happen, bug present:

   lseek(3, -2138, SEEK_CUR)                 = 268198
   openat(AT_FDCWD, "example.pst", O_RDONLY) = 4
   dup3(4, 3, 0)                             = 3
   close(4)                                  = 0

With glibc 2.38 freopen these calls happen, bug absent:

   openat(AT_FDCWD, "example.pst", O_RDONLY) = 4
   dup3(4, 3, 0)                             = 3
   close(4)                                  = 0

With fclose+fopen these calls happen, bug absent:

   close(3)                                = 0
   openat(AT_FDCWD, "example.pst", O_RDONLY) = 3
   
With fflush+fclose+fopen these calls happen, bug present:

   lseek(3, -2138, SEEK_CUR)               = 268198
   close(3)                                = 0
   openat(AT_FDCWD, "example.pst", O_RDONLY) = 3

So the problem is that glibc freopen calls lseek on the existing file
descriptor, modifying the shared file description. So it seems like the
child process is interfering with the parent process file position.

Looking at the stack traces, the _IO_SYNC call introduced in the commit
0b727ed4d that I identified as triggering the readpst bug is definitely
the source of the lseek call.

   lseek(3, -2138, SEEK_CUR)               = 268198
    > /lib/x86_64-linux-gnu/libc.so.6(lseek64+0x7) [0xf81b7]
    > /lib/x86_64-linux-gnu/libc.so.6(_IO_file_sync+0x7e) [0x800ae]
    > /lib/x86_64-linux-gnu/libc.so.6(freopen+0x8c) [0x7d95c]
    > /usr/bin/readpst(pst_reopen+0x36) [0x102c6]
    > /usr/bin/readpst(try_fork+0x88) [0x4398]
    > /usr/bin/readpst(process+0x121) [0xa451]
    > /usr/bin/readpst(main+0x555) [0x3cc5]
    > /lib/x86_64-linux-gnu/libc.so.6(__libc_init_first+0x8a) [0x271ca]
    > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x27285]
    > /usr/bin/readpst(_start+0x21) [0x4061]

Based on the same thing happening with fflush+fclose+fopen, I'm not
entirely sure, but I think that this represents a POSIX compliance bug
in readpst that was papered over by the earlier behaviour of glibc.

Is my reasoning correct here?
   
For my notes:

   strace -o strace/readpst -e trace='!read,write' --follow-forks --output-separately --stack-traces readpst -j 2 -D -M -b example.pst
   
-- 
bye,
pabs

https://bonedaddy.net/pabs3/