Re: How to catch GDB crash

Re: How to catch GDB crash

[Dmitry Smirnov]

Finally, I was able to gather some logs from Cygwin GDB. For this, I've switched debug configuration in Eclipse from gdbServer to Cygwin GDB. It differs in how it starts the program. gdbServer connects to remote target by itself, whereas Cygwin GDB allows me to do it manually from its console.
Below is the log. I've set additional breakpoint at mi_execute_command to see what coommands are issued by Eclipse. 
As you can see, first time mi_on_resume is called with ptid={pid = -1, lwp = 0, tid = 0}. Something happens between this call and second call where ptid={pid = 42000, lwp = 0, tid = 0}.

I'm going to figure out which command is followed by wrong pid. I'm suspecting memory corruption.

I have to note that I didn't see some of these commands while debugging gdbServer as a Java code (CDT debugger) from Eclipse. I've seen the following commands that are common for both cases:
info threads
-stack-info-depth
-stack-list-frames
-data-list-changed-registers
-stack-list-arguments 0 0 0
info signal SIGHUP
-data-disassemble -f <my_file> -l 333 -n 100 -- 1
-data-disassemble -s 0x8c4a8e -e 0x8c4af2 -- 0
-stack-list-locals 0

I will try to simulate these command with console (do not use Eclipse), so if you know equivalent commands for GDB console, please let me know.

BTW, command 'info threads' gives me 
  (gdb) info threads
  warning: RMT ERROR : failed to get remote thread list.

Dmitry

(gdb) attach 4760
Attaching to program `/cygdrive/d/Install/GDB/gdb-6.8.50.20080620/gdb-6.8.50.200
80620/gdb/gdb.exe', process 4760
[Switching to thread 4760.0xcbc]
(gdb) ni
0x7c9507a8 in ntdll!KiIntSystemCall () from /c/WINDOWS/system32/ntdll.dll
(gdb)
0x7c9507bb in ntdll!KiIntSystemCall () from /c/WINDOWS/system32/ntdll.dll
(gdb)
0x7c9507bf in ntdll!KiIntSystemCall () from /c/WINDOWS/system32/ntdll.dll
(gdb)
0x7c9507c1 in ntdll!KiIntSystemCall () from /c/WINDOWS/system32/ntdll.dll
(gdb)
[Switching to thread 4760.0x1150]

Breakpoint 5, mi_execute_command (
    cmd=0x113a4610 "182-interpreter-exec console \"info b\"", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {
(gdb) c
Continuing.

Breakpoint 5, mi_execute_command (cmd=0x1392c8c8 "183-exec-continue",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {
(gdb) c
Continuing.

Breakpoint 4, mi_on_resume (ptid={pid = -1, lwp = 0, tid = 0})
    at .././gdb/mi/mi-interp.c:335
335       if (PIDGET (ptid) == -1)
(gdb) c
Continuing.

Breakpoint 5, mi_execute_command (cmd=0x138c2700 "184 info threads",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {
(gdb) c
Continuing.

Breakpoint 5, mi_execute_command (cmd=0x13931a38 "185-stack-info-depth",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {
(gdb) c
Continuing.

Breakpoint 5, mi_execute_command (
    cmd=0x10d2abf0 "186-stack-list-frames 0 11", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {
(gdb) c
Continuing.

Breakpoint 5, mi_execute_command (
    cmd=0x10c3d120 "187-data-list-changed-registers", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {
(gdb) c
Continuing.

Breakpoint 5, mi_execute_command (cmd=0x10c3d2c0 "188 info sharedlibrary",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {
(gdb) c
Continuing.

Breakpoint 5, mi_execute_command (cmd=0x10cfd660 "189 info signal SIGHUP",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {
(gdb) c
Continuing.

Breakpoint 5, mi_execute_command (
    cmd=0x1144e0a8 "190-data-disassemble -f <my_file> -l 333 -n 100 -- 1", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {
(gdb)
Continuing.

Breakpoint 5, mi_execute_command (
    cmd=0x10d438b8 "191-stack-list-arguments 0 0 0", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {
(gdb)
Continuing.

Breakpoint 5, mi_execute_command (
    cmd=0x10d2a770 "192-data-disassemble -s 0x8c4a8e -e 0x8c4af2 -- 0",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {
(gdb)
Continuing.

Breakpoint 5, mi_execute_command (cmd=0x10d2a820 "193-stack-list-locals 0",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {
(gdb)
Continuing.

Breakpoint 5, mi_execute_command (cmd=0x10d2a8d0 "194 whatis i", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {
(gdb)
Continuing.

Breakpoint 5, mi_execute_command (cmd=0x10f3ea98 "195 whatis rt_status",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {
(gdb)
Continuing.

Breakpoint 5, mi_execute_command (cmd=0x10f34780 "196 whatis __result",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {
(gdb)
Continuing.

Breakpoint 5, mi_execute_command (cmd=0x10f3e748 "197-var-create - * i",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {
(gdb)
Continuing.

Breakpoint 5, mi_execute_command (
    cmd=0x10f39150 "198-var-evaluate-expression var1", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {
(gdb)
Continuing.

Breakpoint 5, mi_execute_command (
    cmd=0x1131f9e8 "199-var-create - * rt_status", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {
(gdb)
Continuing.

Breakpoint 5, mi_execute_command (
    cmd=0x11244350 "200-var-evaluate-expression var2", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {
(gdb)
Continuing.

Breakpoint 5, mi_execute_command (
    cmd=0x1127bb70 "201-var-create - * __result", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {
(gdb)
Continuing.

Breakpoint 5, mi_execute_command (
    cmd=0x1127bdc8 "202-var-evaluate-expression var3", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {
(gdb)
Continuing.

Breakpoint 5, mi_execute_command (
    cmd=0x112d6500 "203-exec-next-instruction 1", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {
(gdb) c
Continuing.

Breakpoint 4, mi_on_resume (ptid={pid = 42000, lwp = 0, tid = 0})
    at .././gdb/mi/mi-interp.c:335
335       if (PIDGET (ptid) == -1)
(gdb) c
Continuing.

Breakpoint 2, 0x61084819 in cygwin1!abort () from /usr/bin/cygwin1.dll
(gdb)

Re: How to catch GDB crash

[Pedro Alves]

A Tuesday 24 June 2008 18:02:49, Dmitry Smirnov wrote:
> As you can see, first time 
> mi_on_resume is called with ptid={pid = -1, lwp = 0, tid = 0}. Something
> happens between this call and second call where ptid={pid = 42000, lwp = 0,
> tid = 0}.
>
> I'm going to figure out which command is followed by wrong pid. I'm
> suspecting memory corruption.

This pid is used by GDB internally when you are connected to a target
that does not support threads at all, like small embedded systems.
If the remote side doesn't have a notion of thread ids or pids, that
magic number is what GDB will use internally.  This code path can
be triggered for example while stepping over a breakpoint (doing
nexti / -exec-next-instruction while stopped at a breakpoint).

> BTW, command 'info threads' gives me
>   (gdb) info threads
>   warning: RMT ERROR : failed to get remote thread list.

... which this seems to corroborate.

This is a new bug in GDB that was introduced recently.

I've already said in my last reply what needs to be done
to fix it.

If your target *does* support threads and the remote protocol
thread related packets, than there's yet another bug somewhere
else.

-- 
Pedro Alves

Re: How to catch GDB crash

[Dmitry Smirnov]

Hi Pedro,

I'll try to figure out, whether skyeye (which is remote target) supports notion of thread ids or pids. Now I just suppose it does not support.
Nevertheless, I do not believe this is related to a crash.

As I said previously, I was debugging this program (ARM code) for some time previously. It is very complex program, it consists of several ELF files. Before this one, I've debugged couple more. I've used 'ni' and/or -exec-next-instruction a lot and didn't see a lot crashes. I remember that I've seen couple of them (in similar scenario: when I've set a BP and run till it hits) but I had eliminated it by moving the breakpoint to another location. 
It is just feeling, no more, that crash is somehow connected with stack trace: previously I didn't see much stack traces. In most cases there was 2 or 3 frames (in fact, call stack should have more frames, but GDB was not able to correctly detect frames. This may be caused by assembler code which does not follow ABI).

BTW, I've just realized that command-line interface does not use mi_* interface (neither mi_on_resume nor mi_execute_command were hit) and this is most likely the reason why I cannot reproduce this test case with CLI.

Dmitry

-----Original Message-----
From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org,  Dmitry Smirnov <divis1969@mail.ru>
Date: Tue, 24 Jun 2008 18:29:28 +0100
Subject: Re: How to catch GDB crash

> 
> A Tuesday 24 June 2008 18:02:49, Dmitry Smirnov wrote:
> > As you can see, first time 
> > mi_on_resume is called with ptid={pid = -1, lwp = 0, tid = 0}. Something
> > happens between this call and second call where ptid={pid = 42000, lwp = 0,
> > tid = 0}.
> >
> > I'm going to figure out which command is followed by wrong pid. I'm
> > suspecting memory corruption.
> 
> This pid is used by GDB internally when you are connected to a target
> that does not support threads at all, like small embedded systems.
> If the remote side doesn't have a notion of thread ids or pids, that
> magic number is what GDB will use internally.  This code path can
> be triggered for example while stepping over a breakpoint (doing
> nexti / -exec-next-instruction while stopped at a breakpoint).
> 
> > BTW, command 'info threads' gives me
> >   (gdb) info threads
> >   warning: RMT ERROR : failed to get remote thread list.
> 
> ... which this seems to corroborate.
> 
> This is a new bug in GDB that was introduced recently.
> 
> I've already said in my last reply what needs to be done
> to fix it.
> 
> If your target *does* support threads and the remote protocol
> thread related packets, than there's yet another bug somewhere
> else.
> 
> -- 
> Pedro Alves
> 

Re: How to catch GDB crash

[Pedro Alves]

A Wednesday 25 June 2008 09:02:33, Dmitry Smirnov wrote:
> Hi Pedro,
>
> I'll try to figure out, whether skyeye (which is remote target) supports
> notion of thread ids or pids. Now I just suppose it does not support.
> Nevertheless, I do not believe this is related to a crash.

Yes it is.  :-)

>
> As I said previously, I was debugging this program (ARM code) for some time
> previously. 

But you've certainly upgraded your GDB recently (I can tell by your log
output on your original post).  As I said, this is a recently introduced
regression.

I've was able to reproduce the problem, by connecting to a local
gdbserver with a GDB with all thread support hacked out in the
remote target.

> BTW, I've just realized that command-line interface does not use mi_*
> interface (neither mi_on_resume nor mi_execute_command were hit) and this
> is most likely the reason why I cannot reproduce this test case with CLI.
>

Yes, that's exactly the reason.

Anyway, I've posted a patch that fixes the issue in your case
(it was actually a side effect of something else I was doing),
although we may need to get rid of the assert you weren't tripping
at for the time being (there are other targets other than
remote that will also trip on the assert).

Vladimir, not sure if you noticed the issue, as it's buried in
this long thread?  We can always leave the crash in place to
force targets to follow our evil plot of always registering the
main thread.  :-)
I'd post a patch for it, but I don't know if we should output
thread-id=0 in that case, or not output thread-id
at all ...

-- 
Pedro Alves

Re: How to catch GDB crash

[Dmitry Smirnov]

I still have some doubts :-)

Below is a new log of my debug session. I've set the same mi_execute_command and mi_on_resume. Last one prints the value of 'inferior_ptid' when hit. Also, from Eclipse I've issues command 'ni' before 'c'. As you can see, 'inferior_ptid' it is equal to {pid = 42000, lwp = 0, tid = 0} all the time whereas mi_on_resume is called with {pid = -1, lwp = 0, tid = 0} in all cases except last one.

On my mind it indicates that while executing last 'ni', function resume() in file infrun.c goes different way and it assigned 'inferior_ptid' to 'resume_ptid' instead of default RESUME_ALL.

Digging...

Dmitry

GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)
Copyright 2004 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-cygwin".
(gdb) attach 2348
Attaching to process 2348
Reading symbols from /cygdrive/d/Install/GDB/gdb-6.8.50.20080620/gdb-6.8.50.2008
0620/gdb/gdb.exe...done.
[Switching to thread 2348.0x15bc]
(gdb) info b
No breakpoints or watchpoints.
(gdb) b mi_on_resume
Breakpoint 1 at 0x48cf46: file .././gdb/mi/mi-interp.c, line 335.
(gdb) b mi_execute_command
Breakpoint 2 at 0x505537: file .././gdb/mi/mi-main.c, line 1135.
(gdb) commands 1
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>print inferior_ptid
>c
>end
(gdb) commands 2
Type commands for when breakpoint 2 is hit, one per line.
End with a line saying just "end".
>c
>end
(gdb) ni
0x7c9507a8 in ntdll!KiIntSystemCall () from /c/WINDOWS/system32/ntdll.dll
(gdb)
0x7c9507bb in ntdll!KiIntSystemCall () from /c/WINDOWS/system32/ntdll.dll
(gdb)
0x7c9507bf in ntdll!KiIntSystemCall () from /c/WINDOWS/system32/ntdll.dll
(gdb)
0x7c9507c1 in ntdll!KiIntSystemCall () from /c/WINDOWS/system32/ntdll.dll
(gdb)
[Switching to thread 2348.0x740]

Breakpoint 2, mi_execute_command (cmd=0x138f74a0 "303 ni", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 1, mi_on_resume (ptid={pid = -1, lwp = 0, tid = 0})
    at .././gdb/mi/mi-interp.c:335
335       if (PIDGET (ptid) == -1)
$1 = {pid = 42000, lwp = 0, tid = 0}

Breakpoint 2, mi_execute_command (cmd=0x1393df78 "304 info threads",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (cmd=0x1393dfd0 "305-stack-info-depth",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (cmd=0x1395a678 "306-stack-list-frames 0 1",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (
    cmd=0x1395a6d0 "307-data-list-changed-registers", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (cmd=0x13962898 "308 info sharedlibrary",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (
    cmd=0x139628f0 "309-stack-list-arguments 0 0 0", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (cmd=0x13927738 "310-stack-list-locals 0",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (
    cmd=0x13927790 "311-interpreter-exec console \"info b\"", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (cmd=0x13977ce8 "312 c", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 1, mi_on_resume (ptid={pid = -1, lwp = 0, tid = 0})
    at .././gdb/mi/mi-interp.c:335
335       if (PIDGET (ptid) == -1)
$2 = {pid = 42000, lwp = 0, tid = 0}

Breakpoint 2, mi_execute_command (cmd=0x13974bd8 "313 info threads",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (cmd=0x13980e98 "314-stack-info-depth",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (
    cmd=0x14770128 "315-stack-list-frames 0 11", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (
    cmd=0x14770010 "316-data-list-changed-registers", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (cmd=0x10ef8958 "317 info sharedlibrary",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (
    cmd=0x10ef89b0 "318-data-disassemble -f /c/p4/views/KSW_S4000_WP_DEV_unknown
/qct/drivers/parb/parb.c -l 333 -n 100 -- 1", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (
    cmd=0x1476fe18 "319-data-disassemble -s 0x8c4a8e -e 0x8c4af2 -- 0",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (
    cmd=0x1172a8d0 "320-stack-list-arguments 0 0 0", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (cmd=0x11738a00 "321-stack-list-locals 0",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (cmd=0x1174b920 "322 whatis i", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (cmd=0x11758f10 "323 whatis rt_status",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (cmd=0x11761360 "324 whatis __result",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (cmd=0x11761548 "325-var-create - * i",
    from_tty=1) at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (
    cmd=0x117616e8 "326-var-evaluate-expression var1", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (
    cmd=0x117c3978 "327-var-create - * rt_status", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (
    cmd=0x11785568 "328-var-evaluate-expression var2", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (
    cmd=0x1178b4b8 "329-var-create - * __result", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (
    cmd=0x1178b550 "330-var-evaluate-expression var3", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 2, mi_execute_command (cmd=0x11795130 "331 ni", from_tty=1)
    at .././gdb/mi/mi-main.c:1135
1135    {

Breakpoint 1, mi_on_resume (ptid={pid = 42000, lwp = 0, tid = 0})
    at .././gdb/mi/mi-interp.c:335
335       if (PIDGET (ptid) == -1)
$3 = {pid = 42000, lwp = 0, tid = 0}

Program exited with code 037777777777.
(gdb)

Re: How to catch GDB crash

[Pedro Alves]

A Thursday 26 June 2008 14:56:26, Dmitry Smirnov wrote:
> I still have some doubts :-)
>

Well, the doubts would go away if you tried the patches.  :-)

I'm hoping to get to commit them today, though...

> Below is a new log of my debug session. I've set the same
> mi_execute_command and mi_on_resume. Last one prints the value of
> 'inferior_ptid' when hit. Also, from Eclipse I've issues command 'ni'
> before 'c'. As you can see, 'inferior_ptid' it is equal to {pid = 42000,
> lwp = 0, tid = 0} all the time whereas mi_on_resume is called with {pid =
> -1, lwp = 0, tid = 0} in all cases except last one.
>
> On my mind it indicates that while executing last 'ni', function resume()
> in file infrun.c goes different way and it assigned 'inferior_ptid' to
> 'resume_ptid' instead of default RESUME_ALL.

Did you actually look at the function that is asserting?  Here it is again:

static void
mi_on_resume (ptid_t ptid)
{
  if (PIDGET (ptid) == -1)
    fprintf_unfiltered (raw_stdout, "*running,thread-id=\"all\"\n");
  else
    {
      struct thread_info *ti = find_thread_pid (ptid);
      gdb_assert (ti);
      fprintf_unfiltered (raw_stdout, "*running,thread-id=\"%d\"\n", ti->num);
    }
}

Calling the resume functions with {-1,0,0} means "let all threads execute",
while with {42000,0,0} meant, "let only this thread execute".  This last
case happens normally when GDB is trying to step over a breakpoint:

- remove breakpoints
- step only the thread of interest, leaving others stopped, so if they happen 
to be executing the same code, they don't miss the breakpoint
- reinsert breakpoints
- now safe to resume all threads

It just happens that in your case there's only one "thread" always,
but the core of inferior control in GDB doesn't care and sends {42000,0,0}
anyway.  The problem was that this assert is there because this function
assumes threads are always registered in the thread table, while that
is unfortunatelly still not always true throughout all of GDB's supported
targets.

> Breakpoint 1, mi_on_resume (ptid={pid = 42000, lwp = 0, tid = 0})
>     at .././gdb/mi/mi-interp.c:335
> 335       if (PIDGET (ptid) == -1)
> $3 = {pid = 42000, lwp = 0, tid = 0}
>
> Program exited with code 037777777777.
> (gdb)

-- 
Pedro Alves

Re: How to catch GDB crash

[Dmitry Smirnov]

Ok, you'd convinced me :-)
You are right, the last resume() is executed with stepping_over_breakpoint equal to 1 whereas previously it was 0.

I'll try your patch (I can find it in gdb-patches, right?).

Dmitry

-----Original Message-----
From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org,  Dmitry Smirnov <divis1969@mail.ru>
Date: Thu, 26 Jun 2008 15:20:54 +0100
Subject: Re: How to catch GDB crash

> 
> A Thursday 26 June 2008 14:56:26, Dmitry Smirnov wrote:
> > I still have some doubts :-)
> >
> 
> Well, the doubts would go away if you tried the patches.  :-)
> 
> I'm hoping to get to commit them today, though...
> 
> > Below is a new log of my debug session. I've set the same
> > mi_execute_command and mi_on_resume. Last one prints the value of
> > 'inferior_ptid' when hit. Also, from Eclipse I've issues command 'ni'
> > before 'c'. As you can see, 'inferior_ptid' it is equal to {pid = 42000,
> > lwp = 0, tid = 0} all the time whereas mi_on_resume is called with {pid =
> > -1, lwp = 0, tid = 0} in all cases except last one.
> >
> > On my mind it indicates that while executing last 'ni', function resume()
> > in file infrun.c goes different way and it assigned 'inferior_ptid' to
> > 'resume_ptid' instead of default RESUME_ALL.
> 
> Did you actually look at the function that is asserting?  Here it is again:
> 
> static void
> mi_on_resume (ptid_t ptid)
> {
>   if (PIDGET (ptid) == -1)
>     fprintf_unfiltered (raw_stdout, "*running,thread-id=\"all\"\n");
>   else
>     {
>       struct thread_info *ti = find_thread_pid (ptid);
>       gdb_assert (ti);
>       fprintf_unfiltered (raw_stdout, "*running,thread-id=\"%d\"\n", ti->num);
>     }
> }
> 
> Calling the resume functions with {-1,0,0} means "let all threads execute",
> while with {42000,0,0} meant, "let only this thread execute".  This last
> case happens normally when GDB is trying to step over a breakpoint:
> 
> - remove breakpoints
> - step only the thread of interest, leaving others stopped, so if they happen 
> to be executing the same code, they don't miss the breakpoint
> - reinsert breakpoints
> - now safe to resume all threads
> 
> It just happens that in your case there's only one "thread" always,
> but the core of inferior control in GDB doesn't care and sends {42000,0,0}
> anyway.  The problem was that this assert is there because this function
> assumes threads are always registered in the thread table, while that
> is unfortunatelly still not always true throughout all of GDB's supported
> targets.
> 
> > Breakpoint 1, mi_on_resume (ptid={pid = 42000, lwp = 0, tid = 0})
> >     at .././gdb/mi/mi-interp.c:335
> > 335       if (PIDGET (ptid) == -1)
> > $3 = {pid = 42000, lwp = 0, tid = 0}
> >
> > Program exited with code 037777777777.
> > (gdb)
> 
> -- 
> Pedro Alves
> 

Re: How to catch GDB crash

[Dmitry Smirnov]

Hi,

I've upgraded to gdb-6.8.50.20080630 and tested it.
Unfortunately, I was totally unable to run my test case from Eclipse CDT.
I've figured out that the problem is what GDB resonds to exec-run command.

Here is the Eclipse session log (it shows requests to GDB and responses)

84-exec-run
84^error,msg="Don't know how to run.  Try \"help target\"."

I've tried older version of arm-elf-gdb (6.5):

123-exec-run
123^running
&"Don't know how to run.  Try \"help target\".\n"
Don't know how to run.  Try "help target".
123^error,msg="Don't know how to run.  Try \"help target\"."

It seems that responses differs in 123^running (or maybe the order too?).

Is it possible to fix this?

Dmitry


-----Original Message-----
From: Dmitry Smirnov <divis1969@mail.ru>
To: Pedro Alves <pedro@codesourcery.com>
Date: Thu, 26 Jun 2008 18:32:46 +0400
Subject: Re: How to catch GDB crash

> 
> Ok, you'd convinced me :-)
> You are right, the last resume() is executed with stepping_over_breakpoint equal to 1 whereas previously it was 0.
> 
> I'll try your patch (I can find it in gdb-patches, right?).
> 
> Dmitry
> 
> -----Original Message-----
> From: Pedro Alves <pedro@codesourcery.com>
> To: gdb@sourceware.org,  Dmitry Smirnov <divis1969@mail.ru>
> Date: Thu, 26 Jun 2008 15:20:54 +0100
> Subject: Re: How to catch GDB crash
> 
> > 
> > A Thursday 26 June 2008 14:56:26, Dmitry Smirnov wrote:
> > > I still have some doubts :-)
> > >
> > 
> > Well, the doubts would go away if you tried the patches.  :-)
> > 

Re: How to catch GDB crash

[Dmitry Smirnov]

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'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"?
JIC, here is the console log of Eclipse:
 
&"info threads\n"
Reply contains invalid hex digit 84
info threads
&"warning: RMT ERROR : failed to get remote thread list.\n"
warning: RMT ERROR : failed to get remote thread list.
Reply contains invalid hex digit 84
~"* 1 Thread <main>"
* 1 Thread <main>&"Reply contains invalid hex digit 84\n"
553^error,msg="Reply contains invalid hex digit 84"


Breakpoint 1, fromhex (a=84) at remote.c:3007
3007        error (_("Reply contains invalid hex digit %d"), a);
(gdb) bt
#0  fromhex (a=84) at remote.c:3007
#1  0x004ea0db in hex2bin (hex=0x1004ace8 "T1", bin=0x697701 "", count=1)
    at remote.c:3023
#2  0x004ebe3a in remote_threads_extra_info (tp=0x1170cc60) at remote.c:2054
#3  0x0047c53f in print_thread_info (uiout=0x1006b278, requested_thread=-1)
    at thread.c:537
#4  0x00402473 in execute_command (p=0x22c6bc "", from_tty=1) at top.c:466
#5  0x00411722 in catch_exception (uiout=0x1006b278,
    func=0x48e3c0 <do_captured_execute_command>, func_args=0x22c6d8, mask=6)
    at exceptions.c:463
#6  0x0048e466 in cli_interpreter_exec (data=0x0,
    command_str=0x10ed21c0 "info threads") at .././gdb/cli/cli-interp.c:130
#7  0x0041ad3b in interp_exec (interp=0x1006b2e0,
    command_str=0x10ed21c0 "info threads") at interps.c:325
#8  0x0048cf39 in mi_cmd_interpreter_exec (
    command=0x64d5fb "-interpreter-exec", argv=0x22c7d8, argc=2)
    at .././gdb/mi/mi-interp.c:209
#9  0x0050626a in captured_mi_execute_command (uiout=0x1006bc58,
    data=0x11572ce0) at .././gdb/mi/mi-main.c:974
#10 0x00411722 in catch_exception (uiout=0x1006bc58,
    func=0x505f30 <captured_mi_execute_command>, func_args=0x11572ce0, mask=6)
    at exceptions.c:463
#11 0x00505d23 in mi_execute_command (cmd=0x1170ccb8 "551 info threads",
    from_tty=1) at .././gdb/mi/mi-main.c:1026
#12 0x0048d019 in mi_execute_command_wrapper (
    cmd=0x1170ccb8 "551 info threads") at .././gdb/mi/mi-interp.c:254
#13 0x0043703a in handle_file_event (event_file_desc=0) at event-loop.c:732
#14 0x00436aa2 in process_event () at event-loop.c:341
#15 0x00437385 in gdb_do_one_event (data=0x0) at event-loop.c:378
#16 0x0041196b in catch_errors (func=0x437200 <gdb_do_one_event>,
    func_args=0x0, errstring=0x607b30 "", mask=6) at exceptions.c:509
#17 0x00436af4 in start_event_loop () at event-loop.c:404
#18 0x004010ab in captured_command_loop (data=0x0) at .././gdb/main.c:104
#19 0x0041196b in catch_errors (func=0x4010a0 <captured_command_loop>,
    func_args=0x0, errstring=0x5f7139 "", mask=6) at exceptions.c:509
#20 0x00401c94 in captured_main (data=0x22cc40) at .././gdb/main.c:891
#21 0x0041196b in catch_errors (func=0x4010f0 <captured_main>,
    func_args=0x22cc40, errstring=0x5f7139 "", mask=6) at exceptions.c:509
#22 0x00402153 in gdb_main (args=0x22cc40) at .././gdb/main.c:900
#23 0x0040109b in main (argc=6, argv=0x1002aee8) at gdb.c:33

-----Original Message-----
From: Dmitry Smirnov <divis1969@mail.ru>
To: gdb@sourceware.org
Date: Mon, 30 Jun 2008 19:56:56 +0400
Subject: Re: How to catch GDB crash

> 
> Hi,
> 
> I've upgraded to gdb-6.8.50.20080630 and tested it.
> Unfortunately, I was totally unable to run my test case from Eclipse CDT.
> I've figured out that the problem is what GDB resonds to exec-run command.
> 
> Here is the Eclipse session log (it shows requests to GDB and responses)
> 
> 84-exec-run
> 84^error,msg="Don't know how to run.  Try \"help target\"."
> 
> I've tried older version of arm-elf-gdb (6.5):
> 
> 123-exec-run
> 123^running
> &"Don't know how to run.  Try \"help target\".\n"
> Don't know how to run.  Try "help target".
> 123^error,msg="Don't know how to run.  Try \"help target\"."
> 
> It seems that responses differs in 123^running (or maybe the order too?).
> 
> Is it possible to fix this?
> 
> Dmitry
> 
> 
> -----Original Message-----
> From: Dmitry Smirnov <divis1969@mail.ru>
> To: Pedro Alves <pedro@codesourcery.com>
> Date: Thu, 26 Jun 2008 18:32:46 +0400
> Subject: Re: How to catch GDB crash
> 
> > 
> > Ok, you'd convinced me :-)
> > You are right, the last resume() is executed with stepping_over_breakpoint equal to 1 whereas previously it was 0.
> > 
> > I'll try your patch (I can find it in gdb-patches, right?).
> > 
> > Dmitry
> > 
> > -----Original Message-----
> > From: Pedro Alves <pedro@codesourcery.com>
> > To: gdb@sourceware.org,  Dmitry Smirnov <divis1969@mail.ru>
> > Date: Thu, 26 Jun 2008 15:20:54 +0100
> > Subject: Re: How to catch GDB crash
> > 
> > > 
> > > A Thursday 26 June 2008 14:56:26, Dmitry Smirnov wrote:
> > > > I still have some doubts :-)
> > > >
> > > 
> > > Well, the doubts would go away if you tried the patches.  :-)
> > > 
> 

Re: How to catch GDB crash

[Pedro Alves]

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

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

[-- Attachment #2: dont_query_internal_threads.diff --]
[-- Type: text/x-diff, Size: 956 bytes --]

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",

Re[2]: How to catch GDB crash

[Dmitry Smirnov]

Hi Pedro,

Here is the log:

(gdb) set debug remote 1
(gdb) info threads
Sending packet: $qL1160000000000000000#55...Ack
Packet received:
warning: RMT ERROR : failed to get remote thread list.
Sending packet: $qThreadExtraInfo,ffffffff#b5...Ack
Packet received: T1
* 1 Thread <main>Reply contains invalid hex digit 84

I'm wondering why GDB is trying to get ThreadExtraInfo if stub has responded that it does not support threads?
BTW, I didn't see this "Reply contains invalid hex digit 84" in older GDBs.

Does stub HAVE to support it?

P.S. I'll test your patch a little bit later and come back with results.

Dmitry

-----Original Message-----
From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org,  Dmitry Smirnov <divis1969@mail.ru>
Date: Wed, 2 Jul 2008 12:52:15 +0100
Subject: 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
> 
> ATTACHMENT: text/x-diff (dont_query_internal_threads.diff)
> 

Re: How to catch GDB crash

[Pedro Alves]

A Wednesday 02 July 2008 13:50:00, Dmitry Smirnov wrote:

> I'm wondering why GDB is trying to get ThreadExtraInfo if stub has
> responded that it does not support threads? BTW, I didn't see this "Reply
> contains invalid hex digit 84" in older GDBs.

That's because versions of GDB until about a week ago didn't register
a main thread/task in the internal thread table if the target didn't
report thread support.  Now we're always registering a main
thread even in that case.  When you do "info threads", GDB queries
the target side for more info on each of the registered
threads.  Since previously there was 0 threads registered, there
were 0 qThreadExtraInfo queries performed.  Now, there's a thread, so
GDB core does 1 query.  But, since this thread was added internally
by GDB behind the remote side's back, we need to bar it just
before letting the query out to the remote side.  That's what
this new patch does.

> Does stub HAVE to support it?

No, it's optional.  But if the stub doesn't support it, it MUST
reply an empty response (an empty C string, as for all
unsupported packets).  Failing to do that is what looks
like a bug in the simulator.

> P.S. I'll test your patch a little bit later and come back with results.

Thanks!

-- 
Pedro Alves
l

Re: How to catch GDB crash

[Dmitry Smirnov]

Didn't have much time to digger.
It seems that Eclipse CDT debugger is confused with the delayed "running" response.
CDT can connect to the remote debugger, retireve stack (it is absent at this point, in fact), retrieve variables, disassebling. But when I try to run it ("-exec-continue") there is nothing responded from gdb (i.e. "running" until it hits the breakpoint. Since in my case, it takes significant time to get to BP, Eclipse decides that target is not responding and either terminates ("gdbServer" CDT debugger) or behaves oddly ("Hardware" CDT Debugger): it sends commands like usual but do not show retrieved data (gdb itself responses correctly).


> > P.S. I'll test your patch a little bit later and come back with results.
> 
> 

Re: How to catch GDB crash

[Pedro Alves]

A Monday 07 July 2008 09:35:43, Dmitry Smirnov wrote:
> Didn't have much time to digger.
> It seems that Eclipse CDT debugger is confused with the delayed "running"
> response. 

Oh, sorry if I didn't make it clear.  This patch was to fix the "info threads"
issue you found, not the "^running" problem.

> CDT can connect to the remote debugger, retireve stack (it is 
> absent at this point, in fact), retrieve variables, disassebling. But when
> I try to run it ("-exec-continue") there is nothing responded from gdb
> (i.e. "running" until it hits the breakpoint. Since in my case, it takes
> significant time to get to BP, Eclipse decides that target is not
> responding and either terminates ("gdbServer" CDT debugger) or behaves
> oddly ("Hardware" CDT Debugger): it sends commands like usual but do not
> show retrieved data (gdb itself responses correctly).
>

I think you said earlier that when you switched to the other eclipse you
had around that got over the "^running" problem, you weren't even able
to inspect the stack or do any disassembling --  eclipse would get
stuck on the "info threads" command.  I take it that since you
report you can now retrieve variables etc, that the "info threads"
issue is fixed?  I'll post this patch for review at gdb-patches@.

Thanks,

-- 
Pedro Alves

Re: How to catch GDB crash

[Dmitry Smirnov]

-----Original Message-----
From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org,  Dmitry Smirnov <divis1969@mail.ru>
Date: Mon, 7 Jul 2008 15:28:57 +0100
Subject: Re: How to catch GDB crash


> I think you said earlier that when you switched to the other eclipse you
> had around that got over the "^running" problem, you weren't even able
> to inspect the stack or do any disassembling --  eclipse would get
> stuck on the "info threads" command.  I take it that since you
> report you can now retrieve variables etc, that the "info threads"
> issue is fixed?  I'll post this patch for review at gdb-patches@.

Perhaps, "info threads" is fixed. But since both "info threads" and "running" problems were [most probably] caused by the "main thread registering" fix, maybe it is better to investigate "^running" problem before submission? What if they are connected? ;-)

I have to say, that my goal is not just report issues, I would like to help fixing them. Unfortunately, I do not have much time to learn GDB, so I'm just asking for hints: what can I do to discover the root cause. For example, who is responding "^running"? What functions/files should I debug to figure out the problem?

Dmitry

Re: How to catch GDB crash

[Pedro Alves]

A Monday 07 July 2008 16:47:26, Dmitry Smirnov wrote:
> Perhaps, "info threads" is fixed. But since both "info threads" and
> "running" problems were [most probably] caused by the "main thread
> registering" fix, maybe it is better to investigate "^running" problem
> before submission? What if they are connected? ;-)

I seriously doubt they are connected.  The code to output "^running"
has nothing to do with having threads or not.

> I have to say, that my goal is not just report issues, I would like to help
> fixing them. 

Welcome on board!  We need all the help we can get.

> Unfortunately, I do not have much time to learn GDB, so I'm 
> just asking for hints: what can I do to discover the root cause. 

The best way is to do a binary search on the CVS HEAD sources, to
find the patch that caused your issue.

> For 
> example, who is responding "^running"? What functions/files should I debug
> to figure out the problem?

Grepping for "^running" should get you there.  

See here, your issue was most likelly introduced by this:
 http://sourceware.org/ml/gdb-patches/2008-06/msg00247.html

-- 
Pedro Alves

Re: How to catch GDB crash

[Dmitry Smirnov]

Thanks,

Most likely I've found the root cause: mi_on_resume() does not flush raw_stdout. I've added "gdb_flush (raw_stdout)" at the end of this function and everything seems to work fine.

Also, I've found a solution for Eclipse problem when it unable to work correctly after this "^running". On my mind it does not related to GDB (and to delayed "^running" :-) ), so I have no problems with GDB at this moment.

M-m-m, there is just one weird and minor observation: just after "target remote:12345" executed, Eclipse shows two identical threads: Thread[0] and Thread[1]. They are stopped at the same address. After I issued "-exec-continue" and GDB hits the breakpoint, Eclipse shows just one thread: Thread[1] with a correct call stack. Perhaps, I will have some time to debug it and get back if this is related to GDB.

Thanks!
Dmitry

-----Original Message-----
From: Pedro Alves <pedro_alves@portugalmail.pt>
To: gdb@sourceware.org,  Dmitry Smirnov <divis1969@mail.ru>
Date: Mon, 7 Jul 2008 17:00:37 +0100
Subject: Re: How to catch GDB crash

> 
> A Monday 07 July 2008 16:47:26, Dmitry Smirnov wrote:
> > Perhaps, "info threads" is fixed. But since both "info threads" and
> > "running" problems were [most probably] caused by the "main thread
> > registering" fix, maybe it is better to investigate "^running" problem
> > before submission? What if they are connected? ;-)
> 
> I seriously doubt they are connected.  The code to output "^running"
> has nothing to do with having threads or not.
> 
> > I have to say, that my goal is not just report issues, I would like to help
> > fixing them. 
> 
> Welcome on board!  We need all the help we can get.
> 
> > Unfortunately, I do not have much time to learn GDB, so I'm 
> > just asking for hints: what can I do to discover the root cause. 
> 
> The best way is to do a binary search on the CVS HEAD sources, to
> find the patch that caused your issue.
> 
> > For 
> > example, who is responding "^running"? What functions/files should I debug
> > to figure out the problem?
> 
> Grepping for "^running" should get you there.  
> 
> See here, your issue was most likelly introduced by this:
>  http://sourceware.org/ml/gdb-patches/2008-06/msg00247.html
> 
> -- 
> Pedro Alves
> 

Re: How to catch GDB crash

[Vladimir Prus]

On Thursday 26 June 2008 03:27:58 Pedro Alves wrote:
> A Wednesday 25 June 2008 09:02:33, Dmitry Smirnov wrote:
> > Hi Pedro,
> >
> > I'll try to figure out, whether skyeye (which is remote target) supports
> > notion of thread ids or pids. Now I just suppose it does not support.
> > Nevertheless, I do not believe this is related to a crash.
> 
> Yes it is.  :-)
> 
> >
> > As I said previously, I was debugging this program (ARM code) for some time
> > previously. 
> 
> But you've certainly upgraded your GDB recently (I can tell by your log
> output on your original post).  As I said, this is a recently introduced
> regression.
> 
> I've was able to reproduce the problem, by connecting to a local
> gdbserver with a GDB with all thread support hacked out in the
> remote target.
> 
> > BTW, I've just realized that command-line interface does not use mi_*
> > interface (neither mi_on_resume nor mi_execute_command were hit) and this
> > is most likely the reason why I cannot reproduce this test case with CLI.
> >
> 
> Yes, that's exactly the reason.
> 
> Anyway, I've posted a patch that fixes the issue in your case
> (it was actually a side effect of something else I was doing),
> although we may need to get rid of the assert you weren't tripping
> at for the time being (there are other targets other than
> remote that will also trip on the assert).
> 
> Vladimir, not sure if you noticed the issue, as it's buried in
> this long thread?  We can always leave the crash in place to
> force targets to follow our evil plot of always registering the
> main thread.  :-)
> I'd post a patch for it, but I don't know if we should output
> thread-id=0 in that case, or not output thread-id
> at all ...

I think that for the time being, we can change the assert to check that
either the program is single-threaded, or the thread is known. If the
program is single-threaded, the the thread id is not registered, omitting
thread-id completely seems right.

I can make this change, or you have something already?

- Volodya

Re: How to catch GDB crash

[Pedro Alves]

A Tuesday 01 July 2008 12:37:35, Vladimir Prus wrote:

> I think that for the time being, we can change the assert to check that
> either the program is single-threaded, or the thread is known. If the
> program is single-threaded, the the thread id is not registered, omitting
> thread-id completely seems right.
>
> I can make this change, or you have something already?
>

Please go ahead.  Thanks.

-- 
Pedro Alves