public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug nptl/14697] New: Behavior of exit is nonconformant with respect to threads and stdio
@ 2012-10-10 18:04 bugdal at aerifal dot cx
2014-06-25 6:45 ` [Bug nptl/14697] " fweimer at redhat dot com
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: bugdal at aerifal dot cx @ 2012-10-10 18:04 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=14697
Bug #: 14697
Summary: Behavior of exit is nonconformant with respect to
threads and stdio
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: nptl
AssignedTo: unassigned@sourceware.org
ReportedBy: bugdal@aerifal.cx
CC: drepper.fsp@gmail.com
Classification: Unclassified
Consider the following program:
#include <pthread.h>
#include <stdio.h>
#include <semaphore.h>
#include <stdlib.h>
void *f(void *p) { flockfile(stdin); sem_post(p); for (;;) pause(); }
int main()
{
sem_t sem;
sem_init(&sem, 0, 0);
pthread_create(&(pthread_t){0}, 0, f, &sem);
while (sem_wait(&sem));
exit(0);
}
Per Austin Group interpretation for issue #611
(http://austingroupbugs.net/view.php?id=611), this program should deadlock in
exit waiting for the lock it will never obtain. Under glibc/NPTL, it exits
immediately.
If you'd like to make the example more interesting, you could have the thread
wake up after 5 seconds and unlock stdin; in that case, the program should run
for at least 5 seconds, rather than exiting immediately.
To make it even more interesting, have the thread performing a long-running
write operation that's intended to be atomic with respect to other threads and
also with respect to program termination (such that on normal program
termination, either the entire write happened, or no write happened at all).
This bug is due to intentional hackery in glibc to avoid hanging on exit() due
to locks being held by other threads, under the wrong assumption that exit()
"should" immediately exit in this case. There is no language in the standards
to support what glibc is doing.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nptl/14697] Behavior of exit is nonconformant with respect to threads and stdio
2012-10-10 18:04 [Bug nptl/14697] New: Behavior of exit is nonconformant with respect to threads and stdio bugdal at aerifal dot cx
@ 2014-06-25 6:45 ` fweimer at redhat dot com
2014-10-06 17:51 ` bugdal at aerifal dot cx
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: fweimer at redhat dot com @ 2014-06-25 6:45 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=14697
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |security-
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nptl/14697] Behavior of exit is nonconformant with respect to threads and stdio
2012-10-10 18:04 [Bug nptl/14697] New: Behavior of exit is nonconformant with respect to threads and stdio bugdal at aerifal dot cx
2014-06-25 6:45 ` [Bug nptl/14697] " fweimer at redhat dot com
@ 2014-10-06 17:51 ` bugdal at aerifal dot cx
2023-06-06 9:43 ` fweimer at redhat dot com
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: bugdal at aerifal dot cx @ 2014-10-06 17:51 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=14697
--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> ---
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nptl/14697] Behavior of exit is nonconformant with respect to threads and stdio
2012-10-10 18:04 [Bug nptl/14697] New: Behavior of exit is nonconformant with respect to threads and stdio bugdal at aerifal dot cx
2014-06-25 6:45 ` [Bug nptl/14697] " fweimer at redhat dot com
2014-10-06 17:51 ` bugdal at aerifal dot cx
@ 2023-06-06 9:43 ` fweimer at redhat dot com
2023-07-03 8:03 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: fweimer at redhat dot com @ 2023-06-06 9:43 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=14697
--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Andreas Schwab from comment #2)
> Note that nptl/tst-stdio1 expects this behaviour.
I posted patches to fix the test:
[PATCH 1/2] support: Add delayed__exit (with two underscores)
<https://sourceware.org/pipermail/libc-alpha/2023-June/148829.html>
[PATCH 2/2] pthreads: Use _exit to terminate the tst-stdio1 test
<https://sourceware.org/pipermail/libc-alpha/2023-June/148830.html>
I wonder if we should add a new symbol version for exit, so that the behavior
only changes for new applications. We did that for quick_exit. (Otherwise we
may have to add a tunable to bring back the old behavior—or we may have to do
that anyway.)
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nptl/14697] Behavior of exit is nonconformant with respect to threads and stdio
2012-10-10 18:04 [Bug nptl/14697] New: Behavior of exit is nonconformant with respect to threads and stdio bugdal at aerifal dot cx
` (2 preceding siblings ...)
2023-06-06 9:43 ` fweimer at redhat dot com
@ 2023-07-03 8:03 ` cvs-commit at gcc dot gnu.org
2023-07-03 9:07 ` fweimer at redhat dot com
2024-02-06 14:38 ` gabravier at gmail dot com
5 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-07-03 8:03 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=14697
--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andreas Schwab <schwab@sourceware.org>:
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=af130d27099651e0d27b2cf2cfb44dafd6fe8a26
commit af130d27099651e0d27b2cf2cfb44dafd6fe8a26
Author: Andreas Schwab <schwab@suse.de>
Date: Tue Jan 30 10:16:00 2018 +0100
Always do locking when accessing streams (bug 15142, bug 14697)
Now that abort no longer calls fflush there is no reason to avoid locking
the stdio streams anywhere. This fixes a conformance issue and potential
heap corruption during exit.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nptl/14697] Behavior of exit is nonconformant with respect to threads and stdio
2012-10-10 18:04 [Bug nptl/14697] New: Behavior of exit is nonconformant with respect to threads and stdio bugdal at aerifal dot cx
` (3 preceding siblings ...)
2023-07-03 8:03 ` cvs-commit at gcc dot gnu.org
@ 2023-07-03 9:07 ` fweimer at redhat dot com
2024-02-06 14:38 ` gabravier at gmail dot com
5 siblings, 0 replies; 7+ messages in thread
From: fweimer at redhat dot com @ 2023-07-03 9:07 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=14697
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |2.38
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
Fixed for 2.38.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug nptl/14697] Behavior of exit is nonconformant with respect to threads and stdio
2012-10-10 18:04 [Bug nptl/14697] New: Behavior of exit is nonconformant with respect to threads and stdio bugdal at aerifal dot cx
` (4 preceding siblings ...)
2023-07-03 9:07 ` fweimer at redhat dot com
@ 2024-02-06 14:38 ` gabravier at gmail dot com
5 siblings, 0 replies; 7+ messages in thread
From: gabravier at gmail dot com @ 2024-02-06 14:38 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=14697
Gabriel Ravier <gabravier at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gabravier at gmail dot com
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-02-06 14:38 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-10 18:04 [Bug nptl/14697] New: Behavior of exit is nonconformant with respect to threads and stdio bugdal at aerifal dot cx
2014-06-25 6:45 ` [Bug nptl/14697] " fweimer at redhat dot com
2014-10-06 17:51 ` bugdal at aerifal dot cx
2023-06-06 9:43 ` fweimer at redhat dot com
2023-07-03 8:03 ` cvs-commit at gcc dot gnu.org
2023-07-03 9:07 ` fweimer at redhat dot com
2024-02-06 14:38 ` gabravier at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).