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."

On 10 October 2013 05:15, "Øivind" <oivind.loe@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';