|Summary:||Behavior of exit is nonconformant with respect to threads and stdio|
|Product:||glibc||Reporter:||Rich Felker <bugdal>|
|Component:||nptl||Assignee:||Not yet assigned to anyone <unassigned>|
Description Rich Felker 2012-10-10 18:04:29 UTC
Comment 1 Rich Felker 2014-10-06 17:51:29 UTC
It seems that this bug can also result in more serious corruption such as duplicate output, even without any explicit file locking. See the example in this question on Stack Overflow, which is a perfectly valid program producing incorrect output: http://stackoverflow.com/questions/26211423/unexpected-output-in-a-multithreaded-program Of course the program has unpredictable output, but there is a finite set of outputs it can produce on a correct implementation: different interleavings of the lines, and different cutoffs for the number of lines produced by sample_thread. A real-world example where this could easily happen is writing a log file using stdio.
Comment 2 Andreas Schwab 2019-11-25 15:27:59 UTC
Note that nptl/tst-stdio1 expects this behaviour.
Comment 3 Rich Felker 2019-11-25 15:55:46 UTC
I'm not sure if this tracker entry is the best place to raise it, but since you mention tests, I think it would be worth considering policy around tests asserting behavior that's already been determined to be buggy/erroneous. Even without a fix for the behavior, the test demanding it could be removed or changed to assert the opposite.