This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to catch GDB crash


Hi Dmitry, thanks for taking the time to investigate deeper.

A Wednesday 02 July 2008 12:05:28, Dmitry Smirnov wrote:
> Hi,
>
> Regarding the problem of -exec-run, I've suspended its investigation: I've
> found that 6.8.50.20080630 just didn't respond "running" and this seems
> reasonable. So, perhaps, previous version is misbehaving so causing Eclipse
> behave wrong way. Though, it is not clear why gdbServer CDT debugger also
> fails. Just postponed...
>

I don't know what to say about this failure.  The command was already
failing before, but it was outputting a spurious "^running".  Why is
eclipse even trying to run a process in with "target remote", I don't know.

> I've found another Eclipse CDT debugger variant that can run as I wish.
> And here I have a problem that I was reported to Pedro earlier: Eclipse is
> unable to disassemble the code, show variables, etc.
>
> I've noticed that GDB respond to "info threads" contains an error message.
> Below is the stack dump of this situation. I'm suspecting this respond
> prevents Eclipse from doing right.
> What is that "T1"?

I don't know.  It looks like a bug in the stub/simulator.
Do you have a way to activate remote protocol debugging?
"set debug remote 1" is the GDB command to use.
The stub embedded in the simulator you're using doesn't seem to
support any other thread related packets, and I would expect
it to reply "" to this packet too.

In the mean time, I think the attached patch (untested other than
building it) is sensible.  Could you give it a try?

-- 
Pedro Alves
2008-07-02  Pedro Alves  <pedro@codesourcery.com>

	* remote.c (remote_threads_extra_info): Don't query the remote
	server about the <main> thread.

---
 gdb/remote.c |    6 ++++++
 1 file changed, 6 insertions(+)

Index: src/gdb/remote.c
===================================================================
--- src.orig/gdb/remote.c	2008-07-02 12:39:07.000000000 +0100
+++ src/gdb/remote.c	2008-07-02 12:50:31.000000000 +0100
@@ -2042,6 +2042,12 @@ remote_threads_extra_info (struct thread
     internal_error (__FILE__, __LINE__,
 		    _("remote_threads_extra_info"));
 
+  if (ptid_equal (tp->ptid, magic_null_ptid)
+      || (ptid_get_pid (tp->ptid) != 0 && ptid_get_tid (tp->ptid) == 0))
+    /* This is the main thread which was added by GDB.  The remote
+       doesn't know about it, so don't query about it.  */
+    return NULL;
+
   if (use_threadextra_query)
     {
       xsnprintf (rs->buf, get_remote_packet_size (), "qThreadExtraInfo,%lx",

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]