This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/14697] New: Behavior of exit is nonconformant with respect to threads and stdio


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]