[Bug libc/24184] New: Regression

[angrave at illinois dot edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=24184

            Bug ID: 24184
           Summary: Regression
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: angrave at illinois dot edu
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 11597
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11597&action=edit
Demonstration of bug

This regression bug was introduced sometime between 2.17 and 2.27 

gcc -Wall fork_exit_test.c  && ./a.out
GNU libc version: 2.17
Expected output is three lines (A,B,C):
0 A
1 B
2 C

[clang on OSX also produces the above output]


gcc -Wall fork_exit_test.c  && ./a.out
GNU libc version: 2.27
Expected output is three lines (A,B,C):
0 A
1 B
2 C
3 A
4 B
5 C
6 A
7 B
8 C
9 A


Commentary -

My tests show that it is triggered when exit () is called and there is 
an input FILE object  where glibc has read to the end of a file input 
stream, but has not reported EOF to the user process. Under this 
condition exit() resets the stream input position. Of course under 
normal conditions - who cares! - the process is exiting! However when 
forking (e.g writing a shell) the fact that a child calling exit() 
resets the stream position affects the parent's next read.

The fact that two filedescriptors of the child and parent share the same 
kernel object with a single position is well known and has been used in 
the past to disregard similar reports of this bug that were less clear 
than the example code below. 

https://sourceware.org/bugzilla/show_bug.cgi?id=23151
And just to be clear the sharing of the 
file descriptions is NOT the bug - the unnecessary seek-ing by exit() 
under this condition IS the problem)

However I note that exit() has no good reason to touch the stream 
position. There is also no true workaround for the parent - it implies 
that the parent must ensure all possible input streams are enumerated 
and fflushed. fflush(NULL) is not sufficient (it does not flush input 
streams).

The differences compared to bug 23151
* demonstration of regression -change in glibc behavior from one v. to another
v
* demonstration that this different from other libc implementations
* initial analysis of when this bug is triggered.

Also note for the C standard
"For input streams (and for update streams on which the last operation was
input), the behavior is undefined."
The current workaround (fflusing before forking) relies on POSIX, but is not C
standard compliant, which is irritating.

-- 
You are receiving this mail because:
You are on the CC list for the bug.