[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#701832: doxygen consistently segfaults on kfreebsd-i386 when building opendnssec documentation



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


Reply to: