gdb halts on non-errors

[Iain Buclaw]

On 10 October 2013 05:15, "Øivind" <oivind.loe at gmail.com> wrote:
> Hi,
> Debugging issues with GDB currently a bit of a pain because it halts on
> several different non-errors. Could you advise on how to get around this.
> Examples on places it will halt are below. The first ones are actually Vibe
> specific, but the last one has nothing to do with Vibe, so I guess this is a
> GDB setup issue, or a D issue. Any thoughts?
>
>
> 0 in determine_info of dl-addr.c:62
> 1 in GIdl_addr of dl-addr.c:140
> 2 in _backtracesymbols of ../sysdeps/generic/elf/backtracesyms.c:52
> 3 in core.runtime.defaultTraceHandler()
> 4 in core.runtime.defaultTraceHandler()
> 5 in dtraceContext
> 6 in dcreateTrace
> 7 in dthrowc
> 8 in vibe.core.core.VibeDriverCore.yieldForEvent() of
> /usr/src/vibed/source/vibe/core/core.d:542
> 9 in vibe.core.drivers.libevent2.Libevent2Driver.connectTCP() of
> /usr/src/vibed/source/vibe/core/drivers/libevent2.d:226
> 10 in vibe.core.net.connectTCP() of /usr/src/vibed/source/vibe/core/net.d:87
>
> 0 in _llllockwait of
> ../nptl/sysdeps/unix/sysv/linux/x8664/lowlevellock.S:132
> 1 in Llock903 of /lib/x8664-linux-gnu/libpthread.so.0
> 2 in _pthreadmutexlock of pthreadmutex_lock.c:82
> 3 in GIdl_addr of dl-addr.c:132
> 4 in _backtracesymbols of ../sysdeps/generic/elf/backtracesyms.c:52
> 5 in core.runtime.defaultTraceHandler()
> 6 in core.runtime.defaultTraceHandler()
> 7 in dtraceContext
> 8 in dcreateTrace
> 9 in dthrowc
> 10 in vibe.core.drivers.libevent2.Libevent2Driver.connectTCP() of
> /usr/src/vibed/source/vibe/core/drivers/libevent2.d:232
> 11 in vibe.core.net.connectTCP() of /usr/src/vibed/source/vibe/core/net.d:87
>
>
> 0 in _llllockwait of
> ../nptl/sysdeps/unix/sysv/linux/x8664/lowlevellock.S:132
> 1 in Llock903 of /lib/x8664-linux-gnu/libpthread.so.0
> 2 in _pthreadmutexlock of pthreadmutex_lock.c:82
> 3 in core.sync.mutex.Mutex.lock()
> 4 in gc.gc.GC.malloc()
> 5 in gc_malloc
> 6 in dallocmemory
>
> I posted this in the Vibed forums, and this is Sönke's reply:
>
> "I know the same is true when debugging on Windows/VisualD. It can be
> avoided there by disabling the interception of certain exception types and I
> think the same should be possible for GDB by disabling the proper user
> signals - however I haven't done this myself, so I can't say which are the
> correct signals. Maybe someone else has more experience there, I'd try on
> the D forums."


In gdb:

handle SIGNAL nostop


Where SIGNAL is the signal you wish to ignore (eg: SIGUSR1, SIGUSR2, ...).

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';