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