public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "law at redhat dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug stdio/14622] New: exit handlers not thread safe Date: Tue, 25 Sep 2012 16:26:00 -0000 [thread overview] Message-ID: <bug-14622-131@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=14622 Bug #: 14622 Summary: exit handlers not thread safe Product: glibc Version: 2.17 Status: NEW Severity: normal Priority: P2 Component: stdio AssignedTo: unassigned@sourceware.org ReportedBy: law@redhat.com Classification: Unclassified The exit handlers which flush & close streams are not thread safe. For example, given this code: #include <stdio.h> #include <stdlib.h> #include <pthread.h> void *test(void *arg) { return NULL; } void *writer(void *arg) { for(;;) { char a[100]; FILE *f = fopen("out", "w"); if(f == NULL) abort(); fputs("Test", f); if(fgets(a, 100, stdin)) fputs(a, f); fclose(f); } return NULL; } int main(int argc, char *argv[]) { pthread_t tid1,tid2; pthread_create(&tid1, NULL, writer, NULL); pthread_create(&tid2, NULL, test, NULL); pthread_join(tid2, NULL); return 0; } while [ true ]; do echo test | valgrind --error-exitcode=2 ./a.out || break done If run under valgrind enough times you'll eventually see the IO cleanup handlers referencing free'd memory: ==7234== Invalid read of size 4 ==7234== at 0x34A7275FC8: _IO_file_write@@GLIBC_2.2.5 (in /usr/lib64/libc-2.15.so) ==7234== by 0x34A7275EA1: new_do_write (in /usr/lib64/libc-2.15.so) ==7234== by 0x34A7276D44: _IO_do_write@@GLIBC_2.2.5 (in /usr/lib64/libc-2.15.so) ==7234== by 0x34A7278DB6: _IO_flush_all_lockp (in /usr/lib64/libc-2.15.so) ==7234== by 0x34A7278F07: _IO_cleanup (in /usr/lib64/libc-2.15.so) ==7234== by 0x34A7238BBF: __run_exit_handlers (in /usr/lib64/libc-2.15.so) ==7234== by 0x34A7238BF4: exit (in /usr/lib64/libc-2.15.so) ==7234== by 0x34A722173B: (below main) (in /usr/lib64/libc-2.15.so) ==7234== Address 0x542f2e0 is 0 bytes inside a block of size 568 free'd ==7234== at 0x4A079AE: free (vg_replace_malloc.c:427) ==7234== by 0x34A726B11C: fclose@@GLIBC_2.2.5 (in /usr/lib64/libc-2.15.so) ==7234== by 0x40087C: writer (t.c:22) ==7234== by 0x34A7607D13: start_thread (in /usr/lib64/libpthread-2.15.so) ==7234== by 0x34A72F167C: clone (in /usr/lib64/libc-2.15.so) What's happening, is the thread in "writer" and the main program's thread are racing. If the "main" thread starts processing its exit IO handlers, then the "writer" thread fcloses the stream (which deallocates the associated memory), then the "main" thread continues processing its exit IO handlers and starts dereferencing free'd memory. The exit IO handlers explicitly avoid locking on the stream and the list_all_lock. Presumably to avoid having exit hang on an event that's never going to happen. At first I thought we could continue to avoid taking the stream lock, but always honour the list_all_lock in IO_flush_all_lockp when called from the exit IO handler. However, that can block in a 3 thread case. Thread 1 is blocked waiting on an event that will never happen with its stream locked. Thread 2 tries to fclose the same stream, it'll acquire the list_all_lock, then block on the stream lock. Thread 3 calls exit and blocks because it can't acquire the list_all_lock. I don't offhand see a good solution. Even playing games with last_stamp doesn't seem like it's work to me. -- 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.
next reply other threads:[~2012-09-25 16:26 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-09-25 16:26 law at redhat dot com [this message] 2012-09-25 18:04 ` [Bug stdio/14622] " bugdal at aerifal dot cx 2014-06-25 6:46 ` fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-14622-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).