On Sun, Mar 03, 2013 at 12:20:57PM +0000, Steven Chamberlain wrote: > > #5 0x0000000800d21f2c in *__GI___libc_free (mem=<optimized out>) at > > malloc.c:3736 > > ar_ptr = 0x800ff3240 > > p = <optimized out> > > #6 0x0000000800844a79 in gvFreeContext () from /usr/lib/libgvc.so.5 > > No symbol table info available. > > #7 0x0000000000400fd8 in ?? () > > No symbol table info available. > > #8 0x000000080389bf04 in __pthread_sighandler
As many of you are probably aware, it's not permitted in POSIX to call free() in signal handler context without some additional guarantees about what the interrupted function may be. http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html (search for "async-signal-safe") It looks like this is what will happen when sending ctrl-c, though. That's why a hang can be provoked in this way. static void intr(int s) { /* if interrupted we try to produce a partial rendering before exiting */ if (G) gvRenderJobs(Gvc, G); /* Note that we don't call gvFinalize() so that we don't start event-driven * devices like -Tgtk or -Txlib */ exit (gvFreeContext(Gvc)); } ... and in main(): signal(SIGINT, intr); for that matter, whatever gvRenderJobs is intended to do is likely hard to guarantee to be only doing async-signal-safe things (let alone things that are data-structure safe). Indeed, I got a sigsegv when sending SIGINT exactly when the first free inside gvLayoutJobs is holding the lock: Breakpoint 3, 0x0000000800843b50 in gvLayoutJobs () from /usr/lib/libgvc.so.5 (gdb) ena 2 (gdb) c Continuing. Breakpoint 2, *__GI___libc_free (mem=0x61d940) at malloc.c:3736 3736 in malloc.c (gdb) signal 2 Continuing with signal SIGINT. Program received signal SIGSEGV, Segmentation fault. 0x0000000800867778 in ?? () from /usr/lib/libgvc.so.5 (gdb) where #0 0x0000000800867778 in ?? () from /usr/lib/libgvc.so.5 #1 0x0000000800870811 in ?? () from /usr/lib/libgvc.so.5 #2 0x0000000800873efd in emit_graph () from /usr/lib/libgvc.so.5 #3 0x0000000800875c9a in gvRenderJobs () from /usr/lib/libgvc.so.5 #4 0x0000000000400fcc in ?? () #5 0x000000080389bf04 in __pthread_sighandler (signo=6550134, _code=0, _sg=0x80063f276, ctx=0xa) at sighandler.c:39 #6 0x00007ffffffff083 in ?? () #7 0x000000080389be60 in ?? () at internals.h:545 from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 #8 0x0000000000000000 in ?? () possibly getting the segv is more common than the hang? I haven't managed to get the hang once using this break-and-signal-in-gdb methodology (amd64 kfreebsd sid/wheezy). Jeff -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
