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

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).