Gdb

Gdb

[Russell Shaw]

Hi,
After narrowing down a bug location in the last few days, it seems
all too obvious that gdb needs to be gutted and recast. It can all
be made simpler and more understandable, thus easier to maintain.

Gdb should should be a library of functions for the various things
that can be done to a target, and have no user interface and command-
line parsing at all.

All the current user terminal interaction should be in a separate
program that is linked to the gdb library.

There is far too much complexity for the simple things that gdb does.

The bug i have is that gdb does not stop at pending breakpoints i have
set in a dlopen library. I made a small testcase, and gdb does do the
pending breakpoints there ok. This bug should be easy to find and fix,
but it isn't.

If there's no plans to redo gdb, i'll do it anyway.

Re: Gdb

[Daniel Jacobowitz]

On Wed, Oct 25, 2006 at 05:05:11PM +1000, Russell Shaw wrote:
> There is far too much complexity for the simple things that gdb does.

I just don't know what to do with this message.

Yes, GDB is a bit crufty and could use some new design in places.  But
calling the target control tasks "simple" is absurd.  It is a typical
fallacy to assume that a task you are only lightly familiar with is
simple, when in fact most of the existing complexity is necessary.

> If there's no plans to redo gdb, i'll do it anyway.

You are welcome to submit individual patches which make areas of GDB
easier to understand.  There are even some suggestions on the wiki.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Gdb

[Russell Shaw]

Daniel Jacobowitz wrote:
> On Wed, Oct 25, 2006 at 05:05:11PM +1000, Russell Shaw wrote:
> 
>>There is far too much complexity for the simple things that gdb does.
> 
> I just don't know what to do with this message.
> 
> Yes, GDB is a bit crufty and could use some new design in places.  But
> calling the target control tasks "simple" is absurd.  It is a typical
> fallacy to assume that a task you are only lightly familiar with is
> simple, when in fact most of the existing complexity is necessary.

There are places with long sequences of:

   if() {
     ...
   }

   if() {
     ...
   }

   if() {
     ...
   }

Instead of something more rigorous like:

   if() {
     ...
   }
   else if {
     ...
   }
   else if {
     ...
   }
...
   else {
     ...
   }

This makes touching anything unpredictable, as there's too many combinations
of possible code paths that may or may not be valid.

That's only one small example. The code is not well modularized. It's hard to
show that here. When a "run" resets a simple breakpoint, the stack depth is no
less than 35 levels. It also invokes a tortuous 10-level trip thru various
"memory set" functions until it eventually reaches target_xfer_partial or whatever,
intermingled with re-reading symbol files, re-syncing dynamic libraries, and
resetting breakpoints.

>>If there's no plans to redo gdb, i'll do it anyway.
> 
> You are welcome to submit individual patches which make areas of GDB
> easier to understand.  There are even some suggestions on the wiki.

It's undoable by anyone not intimately familiar with the code which means
weeks of prodding with a second gdb. The payoff is better in making something
totally different and new.

Re: Gdb

[Daniel Jacobowitz]

On Wed, Oct 25, 2006 at 11:38:49PM +1000, Russell Shaw wrote:
> This makes touching anything unpredictable, as there's too many combinations
> of possible code paths that may or may not be valid.

Guess what?  The conditions aren't orthogonal _for a reason_.

I don't think there's any point in my continuing this conversation, so
this will probably be my last message.  You continue insisting that
the complexity is unnecessary, and yet you don't know why it's there.
I can assure you that it isn't there just to make our lives harder.

> It's undoable by anyone not intimately familiar with the code which
> means weeks of prodding with a second gdb. The payoff is better in
> making something totally different and new.

Having spent many days considering this, talking to others about it,
and even starting it twice, I believe that you are wrong.

There's a lot of payoff in starting from scratch, but (A) you have to
put in just about as much work, and (B) you end up with something
totally different.  If that's your goal, congratulations (I'm thinking
of Frysk here, for instance).  But if you wanted something that looked
like GDB...

-- 
Daniel Jacobowitz
CodeSourcery

Re: Gdb

[Russell Shaw]

Daniel Jacobowitz wrote:
> On Wed, Oct 25, 2006 at 11:38:49PM +1000, Russell Shaw wrote:
> 
>>This makes touching anything unpredictable, as there's too many combinations
>>of possible code paths that may or may not be valid.
> 
> Guess what?  The conditions aren't orthogonal _for a reason_.
> 
> I don't think there's any point in my continuing this conversation, so
> this will probably be my last message.  You continue insisting that
> the complexity is unnecessary, and yet you don't know why it's there.
> I can assure you that it isn't there just to make our lives harder.
> 
>>It's undoable by anyone not intimately familiar with the code which
>>means weeks of prodding with a second gdb. The payoff is better in
>>making something totally different and new.
> 
> Having spent many days considering this, talking to others about it,
> and even starting it twice, I believe that you are wrong.
> 
> There's a lot of payoff in starting from scratch, but (A) you have to
> put in just about as much work, and (B) you end up with something
> totally different.  If that's your goal, congratulations (I'm thinking
> of Frysk here, for instance).  But if you wanted something that looked
> like GDB...

The amount of code is not what i mean. It's the organization that lacks
coherency. There's too many things tacked on half-heartedly knowing whether
that was the right thing to do or the right place to put it. So any patches
i submit could easily break something on some other system, and it's hard to
know.

I'll cut or re-arrange various steps i've seen (during "run"), but i won't
submit any patches for months (needs a lot of checking).

I was going to copy stuff starting from scratch, but that seems a bit of
effort after trying it. I'll just evolve the current gdb a bit.

Re: Gdb

[Eli Zaretskii]

> Date: Wed, 25 Oct 2006 23:38:49 +1000
> From: Russell Shaw <rjshaw@netspace.net.au>
> CC:  gdb@sourceware.org
> 
> There are places with long sequences of:
> 
>    if() {
>      ...
>    }
> 
>    if() {
>      ...
>    }
> 
>    if() {
>      ...
>    }
> 
> Instead of something more rigorous like:
> 
>    if() {
>      ...
>    }
>    else if {
>      ...

These two are not the same.  If you can show us places where the
conditions are disjoint, i.e. they cannot happen together, please do.

> When a "run" resets a simple breakpoint, the stack depth is no less
> than 35 levels.

That is not necessarily a sign of bad design.  For example, when Emacs
does garbage collection, the stack depth sometimes exceeds 10,000
levels when recursive data structures are marked.  That is normal and
by design.

> It also invokes a tortuous 10-level trip thru various
> "memory set" functions until it eventually reaches target_xfer_partial or whatever,
> intermingled with re-reading symbol files, re-syncing dynamic libraries, and
> resetting breakpoints.

This multi-level trip is mostly for valid reasons.

> It's undoable by anyone not intimately familiar with the code which means
> weeks of prodding with a second gdb.

That is a wild exaggeration, IMO.  When I first came to hack GDB to
submit a patch, it was no harder than in any other real-life program.

Perhaps you lack good tools for learning programs, or don't use them
to their full power.

Re: Gdb

[Eli Zaretskii]

> Date: Thu, 26 Oct 2006 02:29:18 +1000
> From: Russell Shaw <rjshaw@netspace.net.au>
> CC:  gdb@sourceware.org
> 
> So any patches i submit could easily break something on some other
> system, and it's hard to know.

We have the patch review process and the test suite for revealing such
breakage.

Re: Gdb

[Russell Shaw]

Eli Zaretskii wrote:
>>Date: Wed, 25 Oct 2006 23:38:49 +1000
>>From: Russell Shaw <rjshaw@netspace.net.au>
>>CC:  gdb@sourceware.org
>>
>>There are places with long sequences of:
>>
>>   if() {
>>     ...
>>   }
>>
>>   if() {
>>     ...
>>   }
>>
>>   if() {
>>     ...
>>   }
>>
>>Instead of something more rigorous like:
>>
>>   if() {
>>     ...
>>   }
>>   else if {
>>     ...
> 
> These two are not the same.  If you can show us places where the
> conditions are disjoint, i.e. they cannot happen together, please do.
> 
>>When a "run" resets a simple breakpoint, the stack depth is no less
>>than 35 levels.
> 
> That is not necessarily a sign of bad design.  For example, when Emacs
> does garbage collection, the stack depth sometimes exceeds 10,000
> levels when recursive data structures are marked.  That is normal and
> by design.

The slowness and size of emacs put me off it. I use (g)vim because
editing using ex regex commands is a more direct way at doing things imho.

>>It also invokes a tortuous 10-level trip thru various
>>"memory set" functions until it eventually reaches target_xfer_partial or whatever,
>>intermingled with re-reading symbol files, re-syncing dynamic libraries, and
>>resetting breakpoints.
> 
> This multi-level trip is mostly for valid reasons.

It still seems excessive at the way it currently works, but i'll look at it
again another time.

>>It's undoable by anyone not intimately familiar with the code which means
>>weeks of prodding with a second gdb.
> 
> That is a wild exaggeration, IMO.  When I first came to hack GDB to
> submit a patch, it was no harder than in any other real-life program.
> 
> Perhaps you lack good tools for learning programs, or don't use them
> to their full power.

I just use ctags to navigate in gvim.

I've been going to make a new GUI frontend for gdb but i keep getting
blocked by bugs in other tools.

Re: Gdb

[Eli Zaretskii]

> Date: Thu, 26 Oct 2006 12:28:40 +1000
> From: Russell Shaw <rjshaw@netspace.net.au>
> CC:  gdb@sourceware.org
> 
> > That is not necessarily a sign of bad design.  For example, when Emacs
> > does garbage collection, the stack depth sometimes exceeds 10,000
> > levels when recursive data structures are marked.  That is normal and
> > by design.
> 
> The slowness and size of emacs put me off it. I use (g)vim because
> editing using ex regex commands is a more direct way at doing things imho.

What does this have to do with the issue at hand?  I used Emacs as an
example of a very deep stack being a normal situation in a working
program whose design is generally considered well-thought.

> > Perhaps you lack good tools for learning programs, or don't use them
> > to their full power.
> 
> I just use ctags to navigate in gvim.

I recommend to add at least ID-Utils to your toolchest.  I don't know
if someone wrote a gvim plug-in for it (the Emacs interface is
included in the package), but even if you invoke it from the shell,
it's an invaluable tool for finding your way around an unfamiliar
program.

Also, some parts of GDB internals are documented in gdbint.texinfo.
Sadly, many important aspects are not covered at all there, but if you
are lucky to be working on something that is described, reading that
manual can help.

Re: Gdb

[Russell Shaw]

Eli Zaretskii wrote:
>>Date: Thu, 26 Oct 2006 12:28:40 +1000
>>From: Russell Shaw <rjshaw@netspace.net.au>
>>CC:  gdb@sourceware.org
>>
>>>That is not necessarily a sign of bad design.  For example, when Emacs
>>>does garbage collection, the stack depth sometimes exceeds 10,000
>>>levels when recursive data structures are marked.  That is normal and
>>>by design.
>>
>>The slowness and size of emacs put me off it. I use (g)vim because
>>editing using ex regex commands is a more direct way at doing things imho.
> 
> What does this have to do with the issue at hand?

Mainly that i detest deep indirect stacks to reach some final target code
because it makes things slow and hard to maintain. The speed and compactness
of vi is what i'd like in gdb, without sacrificing completeness and usability.

I don't like waiting for a text editor to start (emacs), and wouldn't want to
wait for a bloated debugger to start (gdb is currently ok imo).

 > I used Emacs as an
> example of a very deep stack being a normal situation in a working
> program whose design is generally considered well-thought.
>  
>>>Perhaps you lack good tools for learning programs, or don't use them
>>>to their full power.
>>
>>I just use ctags to navigate in gvim.
> 
> I recommend to add at least ID-Utils to your toolchest.  I don't know
> if someone wrote a gvim plug-in for it (the Emacs interface is
> included in the package), but even if you invoke it from the shell,
> it's an invaluable tool for finding your way around an unfamiliar
> program.

I'll read-up on id-utils.

> Also, some parts of GDB internals are documented in gdbint.texinfo.
> Sadly, many important aspects are not covered at all there, but if you
> are lucky to be working on something that is described, reading that
> manual can help.

Cannot get thread event message: debugger service failed

[Christophe Benoit]

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

Hi everybody,

I am trying to use gdb script on a multithreaded application.

My script is very simple :
- Attach on the process
- I set a breakpoint
- I use a while statement to reach the breakpoint fifty times
- After that, I delete the breakpoint, detach and quit.


The problem is that, sometimes, when the breakpoint is reach, gdb goes
in error:

   [New Thread -1210061904 (LWP 15939)]
   scriptgdb.withoutserv.out:56: Error in sourced command file:
   Cannot get thread event message: debugger service failed

The command is : gdb -batch -x scriptgdb.withoutserv.out

I don't know what the problem is, may be on the way I use gdb ? (The
script is in attachment)

It seems that gdb have some problems with the multithreaded application,
is it a known "bug" ?

Any help will be appreciated.

Regards,
Christophe




--
Christophe BENOIT, Production logiciels 6500
AASTRA MATRA Telecom 
1 rue Arnold Schoenberg
78280 Guyancourt
e-mail: christophe.benoit@aastra.com

[-- Attachment #2: scriptgdb.withoutserv.out --]
[-- Type: application/octet-stream, Size: 1117 bytes --]

echo -- Suppression de la pagination\n
set pagination off

echo -- Mise en route verbose et complaint
set verbose on
set complaints 5
show complaints
set confirm off

echo -- Valeur de scheduler-locking\n
show scheduler-locking



echo \n-- Attache sur PID\n
attach 15809


echo \n-- On coupe le Watchdog\n
print maid_system[3]
set maid_system[3]=0
print maid_system[3]


echo \n-- Pose du breakpoint\n
break cm291aaa.c:1362
c

echo \n-- Info threads\n
info threads



set $IND=0

# On ne passe que 5 fois dans le breakpoint
while($IND != 50)
	printf "\n-- Breakpoint rencontre pour la %d fois\n",$IND
	#echo \n-- Listing du code du breakpoint :\n
	#list

	echo \n-- Valeurs des variables locales\n
	info local
	
	# echo \n-- Info threads\n
	# info threads

	echo \n-- Info process\n
	info proc

	# On continue lexecution
	echo \n-- Continue\n
	c
        echo \n-- Breakpoint atteint\n
	set $IND += 1
end

echo \n-- Suppression du breakpoint\n
delete breakpoints


echo \n-- On remet le Watchdog\n
print maid_system[3]
set maid_system[3]=65535
print maid_system[3]

echo \n-- On se detache du process\n
detach

quit

Re: Cannot get thread event message: debugger service failed

[Daniel Jacobowitz]

On Thu, Oct 26, 2006 at 02:41:43PM +0200, Christophe Benoit wrote:
> Hi everybody,
> 
> I am trying to use gdb script on a multithreaded application.
> 
> My script is very simple :
> - Attach on the process
> - I set a breakpoint
> - I use a while statement to reach the breakpoint fifty times
> - After that, I delete the breakpoint, detach and quit.
> 
> 
> The problem is that, sometimes, when the breakpoint is reach, gdb goes
> in error:
> 
>    [New Thread -1210061904 (LWP 15939)]
>    scriptgdb.withoutserv.out:56: Error in sourced command file:
>    Cannot get thread event message: debugger service failed

Before today I'd never even seen that error, and now twice.  I have no
idea what is causing this.  If you are using an older version of GDB,
I recommend trying a current one; otherwise, we would need an
application that can reproduce the problem.

-- 
Daniel Jacobowitz
CodeSourcery

RE: Cannot get thread event message: debugger service failed

[Christophe Benoit]

> > The problem is that, sometimes, when the breakpoint is reach, gdb
goes
> > in error:
> >
> >    [New Thread -1210061904 (LWP 15939)]
> >    scriptgdb.withoutserv.out:56: Error in sourced command file:
> >    Cannot get thread event message: debugger service failed
> 
> Before today I'd never even seen that error, and now twice.  I have no
> idea what is causing this.  If you are using an older version of GDB,
> I recommend trying a current one; otherwise, we would need an
> application that can reproduce the problem.

Thanks Daniel,

I have just updated to the last release of gdb, the problem is always
here.

I will try to see with our development team if we can determine when
this problem occurred. 
I will give you some feedback as soon as possible.

Christophe

> 
> --
> Daniel Jacobowitz
> CodeSourcery

Re: Gdb

[Jim Blandy]

Russell Shaw <rjshaw@netspace.net.au> writes:
> After narrowing down a bug location in the last few days, it seems
> all too obvious that gdb needs to be gutted and recast. It can all
> be made simpler and more understandable, thus easier to maintain.

I think you should give it a shot.  I'd love to see a proper set of
libraries for controlling processes and interpreting debugging
information.  You may want to look at Frysk, which is a newer design
taking a very different approach, but addressing many of the same
kinds of problems that GDB tries to.

I've come to think that trying to do involved symbolic processing
(types; scoping; overload resolution; and multiply by ten where C++ is
involved) without garbage collection is like trying to build a pocket
watch out of sawdust and superglue.  Frysk is written in Java.

But I would also say that what you've written here looks to me like a
pretty common reaction of people who've had good experiences writing
their own code to unfamiliar and complex programs; and at least in my
own experience, it often mellows as one works with the code more.

Re: Gdb

[Russell Shaw]

Jim Blandy wrote:
> Russell Shaw <rjshaw@netspace.net.au> writes:
> 
>>After narrowing down a bug location in the last few days, it seems
>>all too obvious that gdb needs to be gutted and recast. It can all
>>be made simpler and more understandable, thus easier to maintain.
> 
> I think you should give it a shot.  I'd love to see a proper set of
> libraries for controlling processes and interpreting debugging
> information.  You may want to look at Frysk, which is a newer design
> taking a very different approach, but addressing many of the same
> kinds of problems that GDB tries to.
> 
> I've come to think that trying to do involved symbolic processing
> (types; scoping; overload resolution; and multiply by ten where C++ is
> involved) without garbage collection is like trying to build a pocket
> watch out of sawdust and superglue.  Frysk is written in Java.

I didn't know about Frysk. The problem is it's in Java, and java is too indirect
and resource consuming for me.

I made a scoped hierarchial automatic garbage collecting system for C where if
you created an object on the heap between these (possibly nested) macros:

   auto_scope

     AnObject *myobject = mem_new(anoldobject, AnObject);
     ...
     auto_ret(ret_result);
   end_auto
   ...
   return another_result


then any objects within the scope is automatically freed after endauto or auto_ret
if they aren't "owned" by another object outside the scope such as anoldobject.
It works for arbitraryly deep scope, and across long-jumps. A global tree of object
ownerships is maintained, so if a parent of an object is mem_freed() that has other
parents, then the object is not freed() until it has no more parents (an automatic
version of refcounts). You can also modify the scope level of objects, which is
something that is normally unmodifiable in other languages.

After getting it working, i found it slowed the code by 5-10 times and used quite a
bit of memory, because new memory-tracking objects were being used for every small
mem_malloc i did, which were very frequent (thousands per second). It's best to use
this sought of thing for tracking larger (eg, 64-byte) less frequently created objects.

I found later another hierarchial memory manager called Talloc used in Samba.
Haven't used it though. It didn't do as much as i wanted.

I'm still wondering if something like the more manual but faster cleanup chains of
gdb would be a good way of doing things.

> But I would also say that what you've written here looks to me like a
> pretty common reaction of people who've had good experiences writing
> their own code to unfamiliar and complex programs; and at least in my
> own experience, it often mellows as one works with the code more.

Hi,
I've got a closer idea of what/where the problem is now, after looking
through 2k lines of back-traces at various stages during "run" from
delete_breakpoint().

A thing i didn't like is that eg, solib_read_symbols() will eventually mess
around with resetting breakpoints 6 frames deeper in the stack. I would have
handled breakpoint readjustments *after* solib_read_symbols(). I don't know
if it is practical without knowing how all paths operate in greater detail
on all systems and targets. Because i know how it works for the current case,
it seems easier to make a minor patch than to rearrange anything.


#0  delete_breakpoint (bpt=0x84ddd58) at breakpoint.c:6750
#1  0x080e57a0 in breakpoint_re_set_one (bint=0x84ddd58) at breakpoint.c:7206
#2  0x0812ad08 in catch_errors (func=0x80e5264 <breakpoint_re_set_one>, func_args=0x84ddd58, 
errstring=0x898d310 "Error in re-setting breakpoint -413:\n", mask=6) at exceptions.c:515

#3  0x080e5825 in breakpoint_re_set () at breakpoint.c:7248
#4  0x0810e6bf in new_symfile_objfile (objfile=0x8bb8ca0, mainline=0, verbo=0) at symfile.c:868
#5  0x0810e9fb in symbol_file_add_with_addrs_or_offsets (abfd=0x8b66108, from_tty=0, 
addrs=0x8b8cf48, offsets=0x0, num_offsets=0, mainline=0, flags=8) at symfile.c:1019

#6  0x0810ea5f in symbol_file_add_from_bfd (abfd=0x8b66108, from_tty=0, addrs=0x8b8cf48, mainline=0, 
flags=8) at symfile.c:1039

#7  0x0810ea98 in symbol_file_add (name=0x8b88c58 "/usr/lib/libXfixes.so.3", from_tty=0, 
addrs=0x8b8cf48, mainline=0, flags=8) at symfile.c:1052

#8  0x08091869 in symbol_add_stub (arg=0x8b88a50) at solib.c:406
#9  0x0812ad08 in catch_errors (func=0x80917a0 <symbol_add_stub>, func_args=0x8b88a50, 
errstring=0x826c0b0 "Error while reading shared library symbols:\n", mask=6) at exceptions.c:515

#10 0x08091916 in solib_read_symbols (so=0x8b88a50, from_tty=0) at solib.c:432
#11 0x08091c95 in solib_add (pattern=0x0, from_tty=0, target=0x8317100, readsyms=1) at solib.c:684
#12 0x0811fc1b in handle_inferior_event (ecs=0xbf8931f4) at infrun.c:2198
#13 0x0811dc52 in wait_for_inferior () at infrun.c:1009
#14 0x0811da7e in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_0, step=0) at infrun.c:827
#15 0x0811a704 in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=0) at infcmd.c:556

Re: Cannot get thread event message: debugger service failed

[Michael Snyder]

D. Hugh Redelmeier wrote:
> I'm trying to debug Firefox on Linux.  I'm using GDB.  Execution of
> Firefox is frequently interrupted with this message:
>   [New Thread 0x44125950 (LWP 30469)]
>   Cannot get thread event message: debugger service failed
> At this point, I enter a "continue" GDB command and execution
> proceeds.
> 
> Sometimes the screen locks up until the "continue".  So I need to run
> GDB somewhere other than the X desktop.
> 
> What is the best way to avoid this problem and get on with debugging 
> Firefox?  (I admit: a quixotic quest.)
> 
> Google finds this for me:
>   http://sourceware.org/ml/gdb/2006-10/msg00259.html
> but I don't see a resolution.
> 
> Some details:
> 
> - I get this message on 64-bit Fedora 9 (on a dual-core machine) and on 
>   64-bit Ubuntu 8.04 (on a quad core machine)
> 
> - GDB on Fedora 9: gdb-6.8-23.fc9.x86_64
> 
> - GDB on Ubuntu 8.04: 6.8-1ubuntu3
> 
> 
> - I run Firefox this way: Firefox --sync
>   or: Firefox --sync -no-remote
> 
> - I run gdb later, giving it the executable file and the PID
> 
> - I tell gdb to ignore sigpipe signals: handle SIGPIPE nostop
> 
> - I then let GDB continue Firefox
> 
> - after a small amount of browsing, the dreaded message shows up

I have only a few random guesses.

1) Can you try building gdb from sources on your host machine?
Could conceivably be some sort of header file issue.

2) We can see where the error message comes from: void check_event
in linux-thread-db.c.  It's not very informative, it just tells us
that the call to td_ta_event_getmsg_p failed.  No reason for that
suggests itself, other than
   1) maybe mis-matched header files
   2) maybe privilege issues?  Does firefox run as priveleged?
I'm guessing that at least parts of it must, otherwise you would
not be seeing it taking over and hanging up your X server.

If its a privilege issue, can you try running gdb as root?

 > Sometimes the screen locks up until the "continue".  So I need to run
 > GDB somewhere other than the X desktop.

Yeah, this suggests that firefox is grabbing some locks or resources
from the X server, which may suggest that it's running privileged.
You're already running gdb from a separate pseudo-console, might as
well try running it as root as well...

Cannot get thread event message: debugger service failed

[D. Hugh Redelmeier]

I'm trying to debug Firefox on Linux.  I'm using GDB.  Execution of
Firefox is frequently interrupted with this message:
  [New Thread 0x44125950 (LWP 30469)]
  Cannot get thread event message: debugger service failed
At this point, I enter a "continue" GDB command and execution
proceeds.

Sometimes the screen locks up until the "continue".  So I need to run
GDB somewhere other than the X desktop.

What is the best way to avoid this problem and get on with debugging 
Firefox?  (I admit: a quixotic quest.)

Google finds this for me:
  http://sourceware.org/ml/gdb/2006-10/msg00259.html
but I don't see a resolution.

Some details:

- I get this message on 64-bit Fedora 9 (on a dual-core machine) and on 
  64-bit Ubuntu 8.04 (on a quad core machine)

- GDB on Fedora 9: gdb-6.8-23.fc9.x86_64

- GDB on Ubuntu 8.04: 6.8-1ubuntu3


- I run Firefox this way: Firefox --sync
  or: Firefox --sync -no-remote

- I run gdb later, giving it the executable file and the PID

- I tell gdb to ignore sigpipe signals: handle SIGPIPE nostop

- I then let GDB continue Firefox

- after a small amount of browsing, the dreaded message shows up