gdb halts on non-errors

"Øivind" oivind.loe at gmail.com
Wed Oct 9 21:15:37 PDT 2013


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


More information about the D.gnu mailing list