• =?UTF-8?B?IsOYaXZpbmQi?= (53/53) Oct 09 2013 Hi,
• Iain Buclaw (13/61) Oct 10 2013 s a

=?UTF-8?B?IsOYaXZpbmQi?= <oivind.loe gmail.com> writes:

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

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 10 October 2013 05:15, "=D8ivind" <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 Vi=

be
 specific, but the last one has nothing to do with Vibe, so I guess this i=

s 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=F6nke'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 an=

d 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 th=

e
 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, ...).

--=20
Iain Buclaw

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