Re: problems with gdb

[Chris Blizzard <blizzard@redhat.com>]

Christopher Blizzard wrote:
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x404cbd41 in ?? () from /lib/libc.so.6
> (gdb) shar libc.so.6
> Reading symbols from /lib/libc.so.6...done.
> 

So, I've done some more digging into this and it looks like Jim Kingdon has
reported this problem in the past:

http://sourceware.cygnus.com/ml/bug-gdb/1999-10/msg00058.html

I can reproduce this problem both with and without Tom's patch.  Has anyone
seen this before?  Maybe have a solution for it hanging around? :)

There's a test case for this documented at:

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=9565

--Chris

-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
I think the mistake a lot of us make is thinking the state-appointed
psychiatrist is our "friend."
------------
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: [PATCH] remote_detach() and inferior_pid
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38ABADEC.F0320CCB@cygnus.com>
References: <14505.29243.656290.516276@kwikemart.cygnus.com> <bd7pynspv.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00323.html
Content-length: 479

Jim Kingdon wrote:
> 
> > This happens because remote_detach() (and remote_async_detach()) do
> > not reset inferior_pid to 0. Is there a reason for this being this
> > way?
> 
> Setting inferior_pid to 0 sounds good.  I'm not completely sure why
> the *_detach functions don't just call generic_mourn_inferior.

Would that kill the target?  Dig dig dig.  Nope!

Yes, generic_mourn_inferior looks to be doing the correct thing - namely
pulling breakpoints and the like.

	Andrew
From mark@codesourcery.com Sat Apr 01 00:00:00 2000
From: Mark Mitchell <mark@codesourcery.com>
To: donnte@microsoft.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Regressions problem (200 failures)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000301123337B.mitchell@codesourcery.com>
References: <BB61526CDE70D2119D0F00805FBECA2F12A39A08@RED-MSG-55>
X-SW-Source: 2000-q1/msg00478.html
Content-length: 677

>>>>> "Donn" == Donn Terry <donnte@microsoft.com> writes:

    Donn> regressions pointing it at a new gcc)?  (The gcc CVS as of
    Donn> 5:30 or so PST last night still exhibited the problem.)
    Donn> Does anyone have any thougts on how to proceed?

I have one.  (I communicated this to Donn privately, so this is for
the list.)

I think GCC shouldn't put out any line notes for the prologue in the
first place.  That's what's causing the problem, indirectly.  Does GDB
require a line note in the prologue, or can we wait until the first
bit of real code?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
From khendricks@ivey.uwo.ca Sat Apr 01 00:00:00 2000
From: Kevin Hendricks <khendricks@ivey.uwo.ca>
To: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>, Kevin Buettner <kevinb@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: Patches for GNU/Linux PPC native now in CVS
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <00022221542500.09439@localhost.localdomain>
References: <1000222025201.ZM9805@ocotillo.lan> <00022300073001.01275@enzo.bigblue.local>
X-SW-Source: 2000-q1/msg00378.html
Content-length: 2046

Hi Kevin B.

Here is my first bug report.  This is with gdb from today's cvs (after your
later commit) debugging a problem with Motif Drag-n-Drop in the jdk under
native threads.

Everything was working fine until I decided to rerun the program from within
gdb without removing my shared library breakpoints first.

Here is the resulting log file.  Notice the non-existent breakpoint 0 and also
even through I manually removed all of my breakpoints and tried to continue I
could not do so.

I hope this info helps.  The only simple test case would be to actually run the
DDTest java program under the jdk with Motif source around.

Let me know if you would like more info about this bug (explicit steps to try)
and I would be happy to follow instructions.

Thanks,

Kevin H.

Program received signal SIGINT, Interrupt.
[Switching to Thread 9456]
0xfda22c4 in __syscall_rt_sigsuspend () at soinit.c:59
59      soinit.c: No such file or directory.
(gdb) list
54      in soinit.c
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /usr/local/jdk/ucvs/jdk1.2.1/build/linux/bin/ppc/native_threads/java_g DDTest
warning: Cannot insert breakpoint 0:
Cannot access memory at address 0xfa94cdc
(gdb) c
Continuing.
warning: Cannot insert breakpoint 0:
Cannot access memory at address 0xfa94cdc
(gdb) c
Continuing.
warning: Cannot insert breakpoint 0:
Cannot access memory at address 0xfa94cdc
(gdb) del 0
warning: bad breakpoint number at or near '0'
(gdb) del 1
(gdb) del 2
(gdb) del 3
(gdb) c
Continuing.
warning: Cannot insert breakpoint 0:
Cannot access memory at address 0xfa94cdc
(gdb) info break
No breakpoints or watchpoints.
(gdb) c
Continuing.
warning: Cannot insert breakpoint 0:
Cannot access memory at address 0xfa94cdc
(gdb) 



 --
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA   
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959