On 15.09.2017 14:31, Thomas Klausner wrote:
> On Fri, Sep 15, 2017 at 02:27:53PM +0200, Thomas Klausner wrote:
>> Hi!
>>
>> I'm running a multithreaded program in gdb on NetBSD-8.99.2/amd64.
>>
>> It doesn't show me some functions as completions for 'br', so I break
>> on them anyway:
>>
>> Function "foo" not defined.
>> Make breakpoint pending on future shared library load? (y or [n]) y
>> Breakpoint 1 (foo) pending.
>>
>> but it doesn't break on them, but exits (which is the problem I want
>> to debug). When I break into 'main' and then step, it appears and I
>> can step into the function.
>>
>> Another problem: after the first try I just wanted to br into main to
>> try again. So I 'r' the process again and see:
>>
>> (gdb) r
>> Starting program: /path/to/file
>> Warning:
>> Cannot insert breakpoint -38.
>> Cannot access memory at address 0x7d2d33e63180
>>
>> Command aborted.
>>
>>
>> I know that kamil has been complaining about lack of proper NetBSD
>> support in gdb, but I think this worked better before. Ideas?
>
> One more:
>
> I _can_ break on path+line number:
>
> (gdb) br /path/to/file:73
> No source file named /path/to/file
> Make breakpoint pending on future shared library load? (y or [n]) y
> Breakpoint 1 (/path/to/file:73) pending.
> (gdb) r
> Starting program: /something
>
> Breakpoint 1, foo::bar (this=this@entry=0x781434d80270)
> at /path/to/file:73
> 73 something
> (gdb) s<RET>
> ...
> (gdb) <RET>
> 335 if (pthread_sigmask(SIG_BLOCK, &sig_all, NULL)) {
> (gdb) <RET>
>
> hangs
>
> Thomas
>
It looks like masking all signals in a process. This is another bug with
signals in our ptrace(2). Crash signals (SIGSEGV, SIGILL, SIGBUS etc)
start to be invisible to the tracer. This results in anomalies like
hangs or random crashes.
kern/51918
I aim to address it when I will be back to the kernel.
Attachment:
signature.asc
Description: OpenPGP digital signature