Last Comment Bug 57051 - Can't run under gdb
: Can't run under gdb
Status: RESOLVED WORKSFORME
: helpwanted
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: x86 Linux
: P3 blocker (vote)
: ---
Assigned To: Christopher Blizzard (:blizzard)
: rpotts (gone)
Mentors:
ftp://sourceware.cygnus.com/pub/gdb/s...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-17 13:18 PDT by Akkana Peck
Modified: 2002-11-07 00:54 PST (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Akkana Peck 2000-10-17 13:18:35 PDT
On the trunk, I can no longer run in gdb.  I see:

> Note: verifyreflow is disabled
> Note: styleverifytree is disabled
> Note: frameverifytree is disabled
> [New Thread 3076 (runnable)]
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> [Switching to Thread 2051 (runnable)]
> 0x0 in ?? ()

and I can't continue past that point.

Dbaron says:

> Reverting xpcom/threads/nsThread.cpp to revision 1.26 and
> xpcom/threads/nsThread.h to revision 1.15 (i.e., reverting dougt's
> checkin at 2000-09-30 22:35) fixes this problem for me.  (I figured
> this out by doing a binary search of release builds, which also show
> the problem.)

I'm running gdb-5.0-0 and glibc-2.1.3-15 on a fairly stock (but the gdb isn't
stock) RH 6.2 system.

Marking critical because not being able to debug at all is a very serious
regression.
Comment 1 R.K.Aa. 2000-10-17 13:24:20 PDT
Been seeing this too lately, the startup looks like this with gdb 4.18

(gdb) run
Starting program: /usr/local/mozilla/mozilla-bin
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...
(no debugging symbols found)...[New Thread 20406 (manager thread)]
[New Thread 20404 (initial thread)]
[New Thread 20407]
 I am inside the initialize
 Hey : You are in QFA Startup
(QFA)Talkback loaded Ok.
[New Thread 20408]
Cannot access memory at address 0x2e362e6f
(gdb)

It's always the same address.
Comment 2 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2000-10-17 13:26:04 PDT
bryner and I also see this.  dougt said he didn't

Here are some machine details I compiled via email and IRC:

dbaron & bryner:
 * RH 7.0 plus all errata (dbaron tried with and without glibc errata)
 * gdb-5.0-7
 * glibc-2.1.92-14 and glibc-2.1.94-3
 * binutils-2.10.0.18-1

dbaron:
 * kernel 2.4.test10.pre2
 * SMP (dual P-733)
bryner:
 * kernel 2.2
 * not SMP

akkana & dougt:
 * gdb 5
 * glibc-2.1.3-15
 * binutils-2.9.5.0.22-6

akkana:
 * compat-binutils-5.2-2.9.1.0.23.1
Comment 3 Doug Turner (:dougt) 2000-10-17 13:28:44 PDT
 R.K.Aa comments make me think that this is debugging optimized builds,  akk,
are you trying to debug an optimized build?
Comment 4 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2000-10-17 13:33:08 PDT
For reference, the output I saw from gdb was:

Note: verifyreflow is disabled
Note: styleverifytree is disabled
Note: frameverifytree is disabled
[New Thread 3076 (LWP 30351)]
ptrace: No such process.
(gdb)
Comment 5 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2000-10-17 13:34:42 PDT
I'm not debugging an optimized build.  However, the problem *also* showed up in
release builds for me too -- that's how I quickly narrowed it down to a half-day
period and figured out it was your checkin.
Comment 6 Akkana Peck 2000-10-17 13:40:18 PDT
No, I'm seeing this with my own debug builds.
Comment 7 Alec Flett 2000-10-17 15:00:55 PDT
this is a gdb bug. There's nothing we can do about it in mozilla.
I'm going to mark this INVALID in 3...2...1...
Comment 8 Doug Turner (:dougt) 2000-10-17 15:15:12 PDT
what is the bug?  is there a gdb bug number?  
Comment 9 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2000-10-17 15:37:18 PDT
It may not be a gdb bug, since some of us who see/don't see the problem have the
same versions of gdb.  It could be a glibc bug, or something else.  But we do
need to figure out which...
Comment 10 Akkana Peck 2000-10-17 15:40:02 PDT
Reopening.  We need to be able to debug mozilla, and this used to work (and
still does work on the branch).

If we could find a version of gdb that does work to debug mozilla, that would be
a perfectly adequate resolution; but just saying "Oh, well, try to do your
debugging with printf" isn't enough.
Comment 11 Alec Flett 2000-10-17 15:43:57 PDT
bruce pointed me at something earlier today:
http://sources.redhat.com/ml/gdb/2000-10/msg00016.html

basically gdb is really flakey when it comes to mixing threads and DLLs loaded
at runtime.
Comment 12 kill this account 2000-10-17 18:45:46 PDT
That's my message to the gdb mailing list.

This message is about using a GUI to run gdb.
Threads were an issue but only in the sense that the gdb
code needed to service the event loop when the app
was threaded.

I was working at getting Insight (a GUI for gdb) to work on
mozilla. The problem was that gdb when to sleep waiting for the
app (mozilla in my case) to stop. But to stop mozilla I wanted
to click the "Stop" button but the UI was frozen.

After I figured out how to provide appropriate info this was
fixed.

I just updated my tree and it is not crashing.

Is there something one does to make the crash happen?
Comment 13 R.K.Aa. 2000-10-17 19:19:47 PDT
err.. i run from console, simply a "mozilla -g -d gdb".
That approach has worked just fine till quite recently.
Comment 14 Akkana Peck 2000-10-17 19:34:30 PDT
I run from rxvt, usually as "gdb mozilla-bin", but I just tried mozilla -g and
mozilla -g -d gdb, and saw the same problem both times.
Comment 15 kill this account 2000-10-17 19:49:57 PDT
I built the trunk and it doesn't happen for me.

So I'm copying Akkana's tree to my system and trying that.
Comment 16 kill this account 2000-10-17 20:34:19 PDT
when i run my copy of akkana's code on akkana's system it crashes
when i run it on my system it does not crash
(it is nfs mounted on both systems)
Comment 17 kill this account 2000-10-17 20:42:11 PDT
I checked that the loaded libraries are the same
(static lib must be the same since I'm running the same program)

[guitar]$ LD_LIBRARY_PATH=. ldd mozilla-bin 
        libgkgfx.so => ./libgkgfx.so (0x40015000)
        libxpcom.so => ./libxpcom.so (0x4006d000)
        libmozjs.so => ./libmozjs.so (0x401a9000)
        libjsj.so => ./libjsj.so (0x40257000)
        libplds4.so => ./libplds4.so (0x40278000)
        libplc4.so => ./libplc4.so (0x4027c000)
        libnspr4.so => ./libnspr4.so (0x40281000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x402cd000)
        libjprof.so => ./libjprof.so (0x402e0000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x402e4000)
        libutil.so.1 => /lib/libutil.so.1 (0x402fa000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x402fd000)
        libdl.so.2 => /lib/libdl.so.2 (0x4030c000)
        libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2
(0x40310000)
        libm.so.6 => /lib/libm.so.6 (0x40352000)
        libc.so.6 => /lib/libc.so.6 (0x40370000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[guitar]$ sum -r /lib/libpthread.so.0 /lib/libnsl.so.1 /lib/libutil.so.1
/lib/libresolv.so.2 /lib/libdl.so.2 /usr/lib/libstdc++-libc6.1-1.so.2
/lib/libm.so.6 /lib/libc.so.6 /lib/ld-linux.so.2
25259   284 /lib/libpthread.so.0
11717   362 /lib/libnsl.so.1
16688    46 /lib/libutil.so.1
64731   166 /lib/libresolv.so.2
38159    74 /lib/libdl.so.2
62678  1118 /usr/lib/libstdc++-libc6.1-1.so.2
12635   516 /lib/libm.so.6
15111  4006 /lib/libc.so.6
24886   333 /lib/ld-linux.so.2
[guitar]$ 

[accipiter]$ LD_LIBRARY_PATH=. ldd mozilla-bin 
        libgkgfx.so => ./libgkgfx.so (0x40015000)
        libxpcom.so => ./libxpcom.so (0x4006d000)
        libmozjs.so => ./libmozjs.so (0x401a9000)
        libjsj.so => ./libjsj.so (0x40257000)
        libplds4.so => ./libplds4.so (0x40278000)
        libplc4.so => ./libplc4.so (0x4027c000)
        libnspr4.so => ./libnspr4.so (0x40281000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x402cd000)
        libjprof.so => ./libjprof.so (0x402e0000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x402e4000)
        libutil.so.1 => /lib/libutil.so.1 (0x402fa000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x402fd000)
        libdl.so.2 => /lib/libdl.so.2 (0x4030c000)
        libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2
(0x40310000)
        libm.so.6 => /lib/libm.so.6 (0x40352000)
        libc.so.6 => /lib/libc.so.6 (0x40370000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[accipiter]$ sum -r /lib/libpthread.so.0 /lib/libnsl.so.1 /lib/libutil.so.1
/lib/libresolv.so.2 /lib/libdl.so.2 /usr/lib/libstdc++-libc6.1-1.so.2
/lib/libm.so.6 /lib/libc.so.6 /lib/ld-linux.so.2 
25259   284 /lib/libpthread.so.0
11717   362 /lib/libnsl.so.1
16688    46 /lib/libutil.so.1
64731   166 /lib/libresolv.so.2
38159    74 /lib/libdl.so.2
62678  1118 /usr/lib/libstdc++-libc6.1-1.so.2
12635   516 /lib/libm.so.6
15111  4006 /lib/libc.so.6
24886   333 /lib/ld-linux.so.2
[accipiter]$ 

Comment 18 kill this account 2000-10-17 20:43:53 PDT
uname -a

Linux guitar.mcom.com 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686
unknown

Linux accipiter.mcom.com 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686
unknown
Comment 19 kill this account 2000-10-17 20:46:03 PDT
[guitar]$ gtk-config --version
1.2.6
[guitar]$ 

[accipiter]$ gtk-config --version
1.2.6
[accipiter]$ 
Comment 20 kill this account 2000-10-17 20:47:23 PDT
[guitar]$ gdb -v
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux".
[guitar]$ 


[accipiter]$ gdb -v
GNU gdb 20001004
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
[accipiter]$ 

Comment 21 kill this account 2000-10-17 20:48:46 PDT
[guitar]$ gcc --version
egcs-2.91.66
[guitar]$ 

[accipiter]$ gcc --version
egcs-2.91.66
[accipiter]$ 
Comment 22 Doug Turner (:dougt) 2000-10-18 11:23:16 PDT
blizzard, can you look at this?
Comment 23 kill this account 2000-10-18 11:34:55 PDT
I've built a recent (10/4) insight/gdb.

When I run it (uninstalled) on Akkana's machine guitar it does not crash but gdb
still has a problem.


Comment 24 kill this account 2000-10-18 11:44:02 PDT
People are free to install from my build
Note: it will as a side effect provide a GUI front end to gdb
Note: it will install in /usr/local/bin/gdb so the copy in /usr/bin/gdb
      will still be there. One will need have the new version first
      on their path.

To install:
cd to /u/bstell/downloads/insight/insight+dejagnu-20001004
as root do a make install
Comment 25 Christopher Blizzard (:blizzard) 2000-10-18 12:34:56 PDT
If you did something in mozilla that breaks gdb it's a gdb bug.  Period.  You
shouldn't be able to crash the debugger.  For what it's worth I don't have any
problems.  You can also try breaking at main, shutting off loading libraries and
let it finish running and loading the libraries later.  It makes it hard to
debug certain kinds of bugs but it does help some.
Comment 26 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2000-10-18 12:50:34 PDT
I've tried various combinations of loading / not loading shared libraries, and I
see the same symptoms.

Whatever the gdb bug is (or bug in something gdb uses), it only shows up on some
people's machines.  If we're going to report a bug against gdb, it might be good
to have some idea of what the conditions are, although I guess I could create an
account on my machine for someone to debug on...
Comment 27 kill this account 2000-10-18 13:02:24 PDT
I built with the "--prefix" options so I could run it without installing it.
However this means it won't install.

I'm rebuilding without the "--prefix".
Comment 28 Akkana Peck 2000-10-18 13:21:58 PDT
There's a misperception here.  gdb doesn't crash; it starts up mozilla, then
mozilla dies with either a bad memory reference or a SIGTRAP (neither of which
happens when mozilla is run outside of gdb).  It's probably a race condition of
some sort, which would explain why it happens on some machines and not others,
and why it happens in slightly different ways on different machines.

I run with prun (from mozilla's debugging-hints.html), so I already am breaking
at main and delaying loading libraries, because that's the only way I've ever
managed to get mozilla to run under gdb5 and RH6.2, even on my huge-memory
machine.  (I used to be able to run directly under gdb4 and RH6.0.)
Comment 29 kill this account 2000-10-18 15:45:20 PDT
it looks like one cannot install off a NFS partition.
I would guess that the install creates a temp file but
on NFS root (need to be root to install) cannot create 
that file so the install fails.
Comment 30 kill this account 2000-10-19 15:14:25 PDT
Akkana upgraded her gdb (with insight/gdb) and mozilla on the trunk appears not 
to crash.

get insight here: http://sources.redhat.com/insight/
get gdb here: http://sources.redhat.com/gdb/
Comment 31 Akkana Peck 2000-10-19 15:21:09 PDT
Life is good.  Insight is pretty cool, too.  Check it out!

We should add this info to the Mozilla debugging faq (I can do that, unless bliz
would rather do it).
Comment 32 R.K.Aa. 2000-10-21 02:46:02 PDT
sea linux 2000102021:
Can again run "mozilla -g -d gdb"
An additional "run" now starts mozilla just fine, like it used to, before this
weirdness. (still using RH6.2 gdb-4.18-11)
Comment 33 R.K.Aa. 2000-10-23 00:50:46 PDT
just fine, apart from a line during startup:
warning: find_solib: Can't read pathname for load map: Input/output error

Didn't notice this earlyer, perhaps it doesn't always display.
Comment 34 Nikolay Igotti 2000-10-23 13:13:46 PDT
I encountred the same prob with gdb-5.0 from ftp.gnu.org compile on RH6.2.
After I grabbed cvs tree from :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src:
cvs -z9 -d :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src co gdb dejagnu
everything is OK(at least with 22 Oct 2000 cvs).
So I think it's gdb bug.
Comment 35 Andreas Franke (gone) 2000-11-01 14:41:16 PST
Can someone with a working gdb put his/her binary (or a source tarball) on the
web, please? I can't believe that everyone is supposed to pull the gdb sources
from CVS, it's so sloooowwwww :(
Comment 36 Andreas Franke (gone) 2000-11-01 14:56:59 PST
Ok, sorry, I yelled at the wrong people. The problem is that the German ftp
mirror is not up-to-date. Adding a working URL to the gdb snapshot tarball.
Comment 37 kill this account 2000-11-01 15:42:51 PST
People probably want to talk to the gdb folks (or redhat folks, etc.) to figure 
out how to get pre-built gdb.

get insight here: http://sources.redhat.com/insight/
get gdb here: http://sources.redhat.com/gdb/

Comment 38 kill this account 2000-11-01 15:43:37 PST
Since upgrading gdb seems to solve this issue should we close this bug?
Comment 39 R.K.Aa. 2000-12-16 15:35:37 PST
Since it isn't even a problem with OLD gdb anymore, i think it's safe to close
this bug yes.
Comment 40 Akkana Peck 2000-12-18 15:01:29 PST
It isn't?  I still can't run under the gdb 5.0 that comes with RH7:

Note: verifyreflow is disabled
Style Data Sharing is Enabled :)
Note: styleverifytree is disabled
Note: frameverifytree is disabled
[New Thread 3076 (LWP 21385)]
[New Thread 4101 (LWP 21386)]
[New Thread 5126 (LWP 21387)]
ptrace: No such process.
(gdb) c
Continuing.
ptrace: No such process.
[Switching to Thread 3076 (unknown thread_db state 1)]
0x0 in ?? ()

Subsequent continues just repeat the same messages, except for the "[switching
to thread" message, which isn't repeated.

Sure would be nice if there were a binary install of gdb available somewhere
which could debug mozilla.
Comment 41 Doug Turner (:dougt) 2000-12-18 15:11:26 PST
I am using RH7 too, with its version of gdb.  I am not having any problems.  

How are you starting mozilla?

I basically do this in emacs:

gdb ~/mozilla-bin
br main
cont
shar thread
shar xpcom
cont
Comment 42 Akkana Peck 2000-12-18 15:30:31 PST
Aha, you're right, it does work if I set auto-solib-add 0 and then do prun.
It's just a regular run that doesn't work now, even on a huge-memory machine), i.e.

gdb mozilla-bin
(gdb) run
Comment 43 Brian Ryner (not reading) 2000-12-18 22:54:42 PST
gdb in redhat rawhide seems to have the necessary fixes:

ftp://rpmfind.net/linux/rawhide/1.0/i386/RedHat/RPMS/
Comment 44 Akkana Peck 2000-12-19 16:59:50 PST
Indeed, the rawhide RPM for gdb 5.0 does let me run, even without delayed shlib
loading.  However, once it runs it's not very useful: it randomly skips lines
when single-stepping with "next" (usually the lines I most want to step into),
and it randomly loses track of where it is in my source file and starts printing
line numbers from nsCOMPtr.cpp or somewhere else in xpcom even when it's still
stepping through source lines that live in some other file.  The latest gdb
built from cvs has the same problem.
Comment 45 Christopher Blizzard (:blizzard) 2000-12-20 08:12:12 PST
akkana, are you still on an RH 6.x box running that rawhide rpm?
Comment 46 Akkana Peck 2000-12-20 15:28:20 PST
No, this is RH 7.0.
Comment 47 Doug Turner (:dougt) 2001-01-08 11:32:43 PST
UGH.  This bit me this morning.  I am not sure what gives.  Upgrading to the url
that bryner suggests and this does not help  :-( 



This is what I did:

(gdb) prun
Breakpoint 1 at 0x8054de7: file nsAppRunner.cpp, line 1216.
Warning: MOZILLA_FIVE_HOME not set.
main (argc=2, argv=0xbffffab4) at nsAppRunner.cpp:1216
[New Thread 1024 (LWP 2022)]
(gdb) shar pthr
Symbols already loaded for /lib/libpthread.so.0
(gdb) c
Continuing.
Warning: MOZILLA_FIVE_HOME not set.
Type Manifest File: /home/builds/cmonkey/mozilla/dist/bin/components/xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
 --- > Buffered registry read fs hits (31)
[New Thread 2049 (LWP 2025)]
[New Thread 1026 (LWP 2026)]
 --- > Buffered registry read fs hits (32)
GFX: dpi=96 t2p=0.0666667 p2t=15 depth=16
WEBSHELL+ = 1
[New Thread 2051 (LWP 2027)]
********** Got plugins path: /home/builds/cmonkey/mozilla/dist/bin/plugins
Note: verifyreflow is disabled
[New Thread 3076 (LWP 2028)]
Note: styleverifytree is disabled
ptrace: No such process.
(gdb) 



Any ideas?

Comment 48 Dan Mosedale (:dmose) 2001-01-08 19:28:43 PST
dougt: try building from gdb's CVS tip.  the URL that bstell pasted in earlier
on can get you to instructions on how to do that.
Comment 49 Doug Turner (:dougt) 2001-01-09 08:42:49 PST
I tried build 5.0-11 which works better, but it still gets stupid during thread 
switches.  
Comment 50 Andreas Franke (gone) 2001-01-09 12:38:39 PST
With gdb 20010102, I get continuable SIG32 breaks:

(gdb) run
Starting program: /project/omega/mozilla/mtrunk-0105/./mozilla-bin 
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...

Gdk-WARNING **: locale not supported by C library
(no debugging symbols found)...
Program received signal SIG32, Real-time event 32.
0x4024bb6e in __sigsuspend (set=0xbfffdc4c)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
48      ../sysdeps/unix/sysv/linux/sigsuspend.c: No such file or directory.
        in ../sysdeps/unix/sysv/linux/sigsuspend.c
(gdb) cont
Continuing.
Comment 51 Dan Mosedale (:dmose) 2001-01-10 15:02:14 PST
afranke: see <http://www.mozilla.org/unix/debugging-faq.html#sig32>
Comment 52 Andreas Franke (gone) 2001-01-11 03:58:10 PST
dmose: Thanks, I indeed had forgotten about that, but I was talking about
nighlies here, and there a "b main" gives: Function "main" not defined.
So I just start them with "(gdb) run", and that causes two or four SIG32 breaks
before a mozilla window (profile manager) comes up, namely between 
	Gdk-WARNING **: locale not supported by C library
and
	Registering plugin 0 for: "*","All types",".*"
On exit, there's the same problem, and sometimes during the run, too. But these
may all be signs of subtle differences between Linux versions (I'm running on
SuSE 6.2/6.4 here). Debugging a self-made debug build doesn't show this problem.
Comment 53 David Shochat 2001-03-04 13:05:09 PST
I just started seeing this problem for the first time with a CVS debug build
with build date 2001-03-01 15:58:53 PST. In my case, the following steps
make it happen reproduceably:
1. Start mozilla using either mozilla -g (I have ddd) or
   export LD_LIBRARY_PATH=.
   gdb mozilla-bin
   The results are the same either way.
2. b main
3. r
4. set auto-solib-add 0
5. c

I see:
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 3076 (runnable)]
0x0 in ?? ()
(gdb) 

I was able to debug using exactly this methodology without problem until 
recently. I have gdb 5.0 and gcc 2.95.2. I mention gcc because I only started
to see this problem after the upgrade of gcc from 2.91 to 2.95.2 and full
recompile of mozilla using it, but maybe that is just a coincidence. I get 
the problem with gdb itself compiled with gcc 2.91 or 2.95.2. The gcc business 
is probably just a bad tree I've been barking up.
This is a RH 6.2 system (but with kernel 2.4.2).
Still the original glibc-2.1.3-15. 
This has me absolutely at a standstill since I can't debug at all now. Based on 
reading all the prior comments, I guess I have to find a newer-than-5.0 gdb.
Comment 54 David Shochat 2001-03-04 18:31:51 PST
I have made some progress by getting a recent snapshot gdb (last weekly).
However, this is not entirely satisfacory. First, there is some sort of
incompatability with ddd. Wben I attempt to do a 'set env', I get 2 alerts:
"GDB is busy", and "GDB terminated abnormally". The latter one has a 
"Restart GDB" button. If I click that, I am able to go ahead and type
for example 'set env XPCOM_BREAK_ON_LOAD msgnews'
this time without error (!?). But on most (but not all) attempts, after it has
stopped (or sometimes before) at the load of libmsgnews.so and I have 
successfully set my breakpoint, everything grinds to a halt with:
  Cannot find thread 33: invalid thread handle.
This last error occurs less often if I just run gdb from the command line, but
it still happens sometimes even then. Once it does, I'm dead.
Is there a specific gdb version that actually works reliably on mozilla?
Comment 55 Jens-Uwe 2001-04-22 06:30:23 PDT
seems like this is a fine collection of several gdb problems.
I do get the "ptrace: No such process" message.
Perhaps it is helpfull for you to know, that this ONLY happens with a
selfcompiled version taken from CVS, while the precompiled versions from
mozilla.org work fine.
I do a configure with the following options:
./configure --enable-strip-libs --enable-optimize --disable-debug 
--disable-pedantic 
via CXXFLAGS and friends "-O2" is set. The compiler is gcc 2.95.2, gdb is
version 5.0 and I am using a Suse 7.1 Linux distribution.

Please note, that this bug prevents me from getting good stack traces, which are
quite usefull for bugzilla.
Comment 56 Dan Mosedale (:dmose) 2001-04-24 16:01:13 PDT
rumstich: I suspect --enable-strip-libs might be what's causing your problem. 
try removing that and see if it makes any difference.
Comment 57 Andreas Franke (gone) 2001-04-24 19:03:25 PDT
You may also want to try a post-5.0 gdb. I'm running a 04/01/2001 gdb. 
"info threads" still comes up empty, but otherwise it seems to work (SuSE 6.2).

As a side note (probably unrelated): if your gdb stops on SIG32 real time
events, adding a "handle SIG32 nostop" line to ~/.gdbinit may help.
Comment 58 Dan Rosen 2001-04-26 17:59:49 PDT
<aol>me too</aol>

seriously, this is blocking me from getting any stack traces out of my own debug
builds. i should note that there's some vaguely useful info out there if you
search google for "ptrace no such process."

upping to blocker, per trudelle. adding cc's.
Comment 59 Jens-Uwe 2001-05-02 13:17:59 PDT
dan:
I just found out, that I am stupid :-/
I just tested one of the latest binary downloads and it did not work either, it
also showed the ptrace problem. Seems that since I installed the new Suse a few
monthes ago I never downloaded a binary Mozilla (with a slow modem it takes too
quite a while).
Ok, the debugging works on a Suse 6.4, but not on a Suse7.1. I guess that one
the the newer things broke this feature. After reading this bug I think it is
gdb5.0, Suse6.4 still has gdb 4.18. But I don't know anything about it...
Comment 60 Dan Mosedale (:dmose) 2001-05-02 14:46:44 PDT
FWIW, the CVS tree for GDB is scheduled to get some big whacks related to it's
handling of threads in the next few weeks.  See
<http://sources.redhat.com/ml/gdb-patches/2001-04/msg00240.html> and subsequent
messages for more details.
Comment 61 Jens-Uwe 2001-05-06 11:05:36 PDT
now after mozilla changed to gcc2.95.3 I can't use gdb on my good old Suse6.4
system anymore, it worked fine here before. I get the following message

Thread 1721 (manager thread)]
[New Thread 1720 (initial thread)]
[New Thread 1722]
[New Thread 1723]
[New Thread 1724]
Cannot access memory at address 0x46203a6c.

looks like the behaviour under gdb is also connected to the libs dynamicly
linked to Mozilla. without gdb mozilla works fine. 
Suse6.4 ships with gcc2.95.2, so i am quite surprised that I get problems now! 
Comment 62 Christopher Blizzard (:blizzard) 2001-08-06 12:04:53 PDT
Works for Me on Red Hat 7.1
Comment 63 Jens-Uwe 2001-08-06 12:14:47 PDT
blizzard:
doesn't work on a LOT of distributions, for example several Suse's, all those
which ship with gdb5.0. 
As described in this bug this is caused by a bug in gdb and it should work find
with an upgraded gdb. Not sure if you can expect a little user to upgrade to a
new (unofficial?) gdb just to produce a stacktrace...
Comment 64 Dan Mosedale (:dmose) 2001-08-06 12:29:49 PDT
Jens-Uwe: what other solution do you propose?
Comment 65 Hixie (not reading bugmail) 2002-11-07 00:54:52 PST
Moving all threading bugs to XPCOM. See bug 160356.

Note You need to log in before you can comment on or make changes to this bug.