Re: Another problem with debugging the navigator on FreeBSD2.2-STABLE

[ Available lists | Index of freebsd-hackers | Month of Feb 1998 | Week of 17 Feb 1998 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Chris Toshok <toshok@netscape.com>
Date
17 Feb 1998 01:25:11
Subject
Re: Another problem with debugging the navigator on FreeBSD2.2-STABLE
Message-ID
34E9574A.F0726589@netscape.com

References to

[ Hide this part ]
Greg Lehey wrote:
>
> On Thu, 12 February 1998 at 20:37:58 -0800, Chris Toshok wrote:
> > So, I've gotten around my complete inability to even *run* gdb on the
> > navigator, but now I've got another problem: When I hit a breakpoint
> > and try to either step or continue, I see:
> >
> > (gdb) c
> > Continuing.
> >
> > Program received signal SIGTRAP, Trace/breakpoint trap.
> > foo_nsFunction (foo=0x0) at foofile.c:192
> > (gdb)
> >
> > The problem is, the breakpoint is at the same place at which the program
> > just stopped. The only way to get past this breakpoint is to disable
> > the breakpoint and continue. Disabling the breakpoing and stepping
> > doesn't work.
>
> It should do. Are you sure that this is the real problem?
>
> > It's getting pretty frustrating, trying to debug a large amount of code
> > by setting breakpoints at just about every line of a function and
> > disabling one and then enabling another.
> >
> > Anyone got an idea what could be causing this? Debugging other
> > programs works fine. I would imagine that the size of the program
> > and it's shared libraries is part of the problem, but what can I do
> > to fix it?
>
> Good question. Can you give me a binary to look at?
>

Heh :) Thanks for the offer, but I actually found the problem shortly
after I sent the original mail. Turns out the the netscape thread
library uses SIGALRM for some accounting stuff.

All that was required was 'handle SIGALRM nopass'.

Chris

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message


Elapsed time: 0.216 seconds