gdb 6.1.1 (PPC) crash (long)

gdb 6.1.1 (PPC) crash (long)

[Fabian Cenedese]

Hi

First apologies for the long mail. I just thought I tell you exactly what happened :)

I get a crash when trying to lookup a symbol with my cross compiled gdb. It's
just this one symbol (so far), others I can lookup with no problems.
Here's what happens:


N:\IMD\Bin\Gnu32>gdb
GNU gdb 6.1.1
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 "--host=i686-pc-cygwin --target=powerpc-eabi".

(gdb) file n:/temp/throwaway/psism2/psism.x
Reading symbols from n:/temp/throwaway/psism2/psism.x...done.

(gdb) target remote 127.0.0.1:10372
Remote debugging using 127.0.0.1:10372
0x000b9d04 in CMainTask::Action (this=0x125018)
    at N:\Temp\ThrowAway\psism2\os\inos\Src\Inos.cpp:1924
1924                      Suspend();
warning: no shared library support for this OS / ABI
Current language:  auto; currently c++

(gdb) bt
#0  0x000b9d04 in CMainTask::Action (this=0x125018)
    at N:\Temp\ThrowAway\psism2\os\inos\Src\Inos.cpp:1924
#1  0x0010e348 in _guard_stack ()
#2  0x00118fdc in CINOSScheduler::DoInitialisation (this=0x125018)
    at N:\Temp\ThrowAway\psism2\os\inos\Src\Inos.cpp:546
#3  0x0011881c in inos_main ()
    at N:\Temp\ThrowAway\psism2\os\inos\Src\Inos.cpp:368
#4  0x0008d660 in resTb ()

(gdb) ptype this
type = class CMainTask : public CINOSTask {
  public:
    CMainTask & operator=(CMainTask const &);
    virtual ~CMainTask(void);
      2 [main] gdb 2100 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
    329 [main] gdb 2100 open_stackdumpfile: Dumping stack trace to gdb.exe.stack
dump


This is the written stack dump. Though I worked with the unstripped gdb.exe there
are no symbols in the dump:


Exception: STATUS_ACCESS_VIOLATION at eip=0048A102
eax=00000000 ebx=00000000 ecx=00000002 edx=0048A0F0 esi=00000000 edi=0A2B5D08
ebp=0022E718 esp=0022E700 program=N:\IMD\Bin\Gnu32\gdb.exe, pid 2100, thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022E718  0048A102  (00000000, 0A29CE18, 0022E7B8, 004DDA6C)
0022E728  00488BF8  (00000000, 0A2B5DA8, 00000000, FFFFFFFF)
0022E7B8  004DDA6C  (0A2B5BE8, 0A083C68, 00000001, 00000000)
0022E7E8  004DC816  (0A2B5BE8, 00716C4D, 0A083C68, 00000001)
0022E808  004945AF  (0A2B5BE8, 00716C4D, 0A083C68, 00000001)
0022E848  004946BE  (0A0513DE, 00000001, 0022E888, 6105C355)
0022E878  00494869  (0A0513DE, 00000001, 0022E8A8, 0042921C)
0022E888  00427339  (0A078A60, 0A0513DE, 00000001, 00415C7A)
0022E8A8  0042921C  (0A078A60, 0A0513DE, 00000001, 00000000)
0022E8E8  0040285D  (0A0513E1, 00000001, 0022E918, 0067C914)
0022E918  004247E9  (0A0513D8, 0A087BA0, 0022E940, 0068C0BF)
0022E958  00424C35  (0A2886A8, 0A2886A8, 0022F140, 0A2886A8)
0022E978  0068ACA5  (0022E938, 0A075F68, 0022E998, 004246CD)
0022E988  004240EB  (00000000, 0000000C, 0022E9B8, 0047F34E)
0022E998  004246CD  (00000000, 00000000, 00000000, 0040A7D9)
0022E9B8  0047F34E  (00000000, 00000001, 00000000, 00000000)
End of stack trace (more stack frames may be present)


I then tried to debug my gdb with the normal gdb, but this doesn't work either:


GNU gdb 2003-09-20-cvs (cygwin-special)
Copyright 2003 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) file gdb.exe
Reading symbols from gdb.exe...done.

(gdb) run
Starting program: /cygdrive/n/imd/bin/gnu32/gdb.exe
GNU gdb 6.1.1
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 "--host=i686-pc-cygwin --target=powerpc-eabi".

(gdb) file N:/temp/throwaway/psism2/psism.x
Reading symbols from N:/temp/throwaway/psism2/psism.x...done.

(gdb) target remote 127.0.0.1:10372

Program received signal SIGSEGV, Segmentation fault.
0x77e95e30 in KERNEL32!IsBadWritePtr ()
   from /cygdrive/c/WINNT/system32/kernel32.dll

(gdb) bt
#0  0x77e95e30 in KERNEL32!IsBadWritePtr ()
   from /cygdrive/c/WINNT/system32/kernel32.dll
#1  0x610a92ed in cygwin1!__getreent ()
   from /cygdrive/n/imd/bin/gnu32/cygwin1.dll
#2  0x00000008 in ?? ()
#3  0x0022d0d8 in ?? ()
#4  0x610a9387 in cygwin1!__getreent ()
   from /cygdrive/n/imd/bin/gnu32/cygwin1.dll
(gdb)


They both use the same new cygwin1.dll (1.5.10) so that shouldn't be
a problem.

How can I find out what gdb doesn't like about my symbols? The file
was made with an old gcc 2.95.2 (also cross compiled for PPC).
The stripped bin file is working in my target so at most there could
be something wrong with the debug info. I found that even simply
loading the file and doing a ptype CMainTask make both gdb crash.

Now the same again without doing remote communication:


N:\IMD\Bin\Gnu32>c:/cygwinnew/bin/gdb
GNU gdb 2003-09-20-cvs (cygwin-special)
Copyright 2003 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) file gdb.exe
Reading symbols from gdb.exe...done.

(gdb) run
Starting program: /cygdrive/n/IMD/Bin/Gnu32/gdb.exe
GNU gdb 6.1.1
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 "--host=i686-pc-cygwin --target=powerpc-eabi".

(gdb) file n:/temp/throwaway/psism2/psism.x
Reading symbols from n:/temp/throwaway/psism2/psism.x...done.

(gdb) ptype CMainTask
type = class CMainTask : public CINOSTask {
  public:
    CMainTask & operator=(CMainTask const &);
    virtual ~CMainTask(void);

Program received signal SIGSEGV, Segmentation fault.
gnuv2_is_constructor_name (name=0x0) at ../../gdb-6.1.1/gdb/gnu-v2-abi.c:56
56        if ((name[0] == '_' && name[1] == '_'

(gdb) bt
#0  gnuv2_is_constructor_name (name=0x0)
    at ../../gdb-6.1.1/gdb/gnu-v2-abi.c:56
#1  0x00488bf8 in is_constructor_name (name=0x0)
    at ../../gdb-6.1.1/gdb/cp-abi.c:44
#2  0x004dda6c in c_type_print_base (type=0xa2b4b68, stream=0xa084088,
    show=1, level=0) at ../../gdb-6.1.1/gdb/c-typeprint.c:952
#3  0x004dc816 in c_print_type (type=0xa2b4b68, varstring=0x716c4d "",
    stream=0xa084088, show=1, level=0) at ../../gdb-6.1.1/gdb/c-typeprint.c:75
#4  0x004945af in type_print (type=0xa2b4b68, varstring=0x716c4d "",
    stream=0xa084088, show=1) at ../../gdb-6.1.1/gdb/typeprint.c:109
#5  0x0049482a in ptype_command (typename=0xa05180e "CMainTask", from_tty=1)
    at ../../gdb-6.1.1/gdb/typeprint.c:223
#6  0x00427339 in do_cfunc (c=0xa078e88, args=0xa05180e "CMainTask",
    from_tty=1) at ../../gdb-6.1.1/gdb/cli/cli-decode.c:57
#7  0x0042921c in cmd_func (cmd=0xa078e88, args=0xa05180e "CMainTask",
    from_tty=1) at ../../gdb-6.1.1/gdb/cli/cli-decode.c:1541
#8  0x0040285d in execute_command (p=0xa051816 "k", from_tty=1)
    at ../../gdb-6.1.1/gdb/top.c:743
#9  0x004247e9 in command_handler (command=0xa051808 "ptype CMainTask")
    at ../../gdb-6.1.1/gdb/event-top.c:500
#10 0x00424c35 in command_line_handler (rl=0xa0880d8 "ptype CMainTask")
    at ../../gdb-6.1.1/gdb/event-top.c:793
#11 0x0068aca5 in rl_callback_read_char ()
    at ../../gdb-6.1.1/readline/callback.c:123
#12 0x004240eb in rl_callback_read_char_wrapper (client_data=0x0)
    at ../../gdb-6.1.1/gdb/event-top.c:166
#13 0x004246cd in stdin_event_handler (error=0, client_data=0x0)
    at ../../gdb-6.1.1/gdb/event-top.c:416
#14 0x0047f34e in handle_file_event (event_file_desc=0)
    at ../../gdb-6.1.1/gdb/event-loop.c:721
#15 0x0047edb9 in process_event () at ../../gdb-6.1.1/gdb/event-loop.c:334
#16 0x0047ee18 in gdb_do_one_event (data=0x0)
    at ../../gdb-6.1.1/gdb/event-loop.c:371
#17 0x004024b1 in do_catch_errors (uiout=0xa07cbb8, data=0x22eb50)
    at ../../gdb-6.1.1/gdb/top.c:523
#18 0x00402325 in catcher (func=0x4024a0 <do_catch_errors>,
    func_uiout=0xa07cbb8, func_args=0x22eb50, func_val=0x22eb48,
    func_caught=0x22eb4c, errstring=0x710a9c "", gdberrmsg=0x0, mask=6)
    at ../../gdb-6.1.1/gdb/top.c:430
#19 0x00402510 in catch_errors (func=0x47ede0 <gdb_do_one_event>,
    func_args=0x0, errstring=0x710a9c "", mask=6)
    at ../../gdb-6.1.1/gdb/top.c:535
#20 0x0047ee54 in start_event_loop () at ../../gdb-6.1.1/gdb/event-loop.c:397
#21 0x004010cb in captured_command_loop (data=0x0)
    at ../../gdb-6.1.1/gdb/main.c:97
#22 0x004024b1 in do_catch_errors (uiout=0xa07cbb8, data=0x22ed00)
    at ../../gdb-6.1.1/gdb/top.c:523
#23 0x00402325 in catcher (func=0x4024a0 <do_catch_errors>,
    func_uiout=0xa07cbb8, func_args=0x22ed00, func_val=0x22ecf8,
    func_caught=0x22ecfc, errstring=0x6da0ec "", gdberrmsg=0x0, mask=6)
    at ../../gdb-6.1.1/gdb/top.c:430
#24 0x00402510 in catch_errors (func=0x4010c0 <captured_command_loop>,
    func_args=0x0, errstring=0x6da0ec "", mask=6)
    at ../../gdb-6.1.1/gdb/top.c:535
#25 0x00401a64 in captured_main (data=0x22f030)
    at ../../gdb-6.1.1/gdb/main.c:805
#26 0x004024b1 in do_catch_errors (uiout=0x6ad4f0, data=0x22eff0)
    at ../../gdb-6.1.1/gdb/top.c:523
#27 0x00402325 in catcher (func=0x4024a0 <do_catch_errors>,
    func_uiout=0x6ad4f0, func_args=0x22eff0, func_val=0x22efe8,
    func_caught=0x22efec, errstring=0x6da0ec "", gdberrmsg=0x0, mask=6)
    at ../../gdb-6.1.1/gdb/top.c:430
#28 0x00402510 in catch_errors (func=0x401110 <captured_main>,
    func_args=0x22f030, errstring=0x6da0ec "", mask=6)
    at ../../gdb-6.1.1/gdb/top.c:535
#29 0x00401f03 in gdb_main (args=0x22f030) at ../../gdb-6.1.1/gdb/main.c:814
#30 0x004010aa in main (argc=1, argv=0xa0516e8)
    at ../../gdb-6.1.1/gdb/gdb.c:35


Thanks for any help. If this is fixed in gdb 6.2 please tell me the patch. Compiling
6.2 didn't work for some reason (don't remember now). But I can apply any changes
to my gdb as I need to compile it anyway.

bye  Fabi

Re: gdb 6.1.1 (PPC) crash (long)

[Fabian Cenedese]

Hi

Some followup:

(gdb) frame 1
#1  0x00488bf8 in is_constructor_name (name=0x0)
    at ../../gdb-6.1.1/gdb/cp-abi.c:44
44        return (*current_cp_abi.is_constructor_name) (name);
(gdb) info locals
name = 0x0
(gdb) info args
name = 0x0

(gdb) frame 2
#2  0x004dda6c in c_type_print_base (type=0xa2b4b68, stream=0xa084088,
    show=1, level=0) at ../../gdb-6.1.1/gdb/c-typeprint.c:952
952                       int is_full_physname_constructor =
(gdb) info locals
physname = 0x0
is_full_physname_constructor = 0
method_name = 0xa0951b8 "CMainTask"
f = (struct fn_field *) 0xa2b4da8
j = 0
len2 = 2
name = 0x0
is_constructor = 1
type = (struct type *) 0xa2b4b68
stream = (struct ui_file *) 0xa084088
show = 1
level = 0
i = 2
len = 4
real_len = 0
lastval = 0
mangled_name = 0xa297650 "_._9CMainTask"
demangled_name = 0xa28da58 "X\203)\nE\203)\nk::~CMainTask(void)"
section_type = s_public
need_access_label = 1
j = 170610088
len2 = 4

(gdb) frame 3
#3  0x004dc816 in c_print_type (type=0xa2b4b68, varstring=0x716c4d "",
    stream=0xa084088, show=1, level=0) at ../../gdb-6.1.1/gdb/c-typeprint.c:75
75        c_type_print_base (type, stream, show, level);
(gdb) info locals
type = (struct type *) 0xa2b4b68
varstring = 0x716c4d ""
stream = (struct ui_file *) 0xa084088
show = 1
level = 0
demangled_args = 0
need_post_space = 0
(gdb) info args
type = (struct type *) 0xa2b4b68
varstring = 0x716c4d ""
stream = (struct ui_file *) 0xa084088
show = 1
level = 0

(gdb) frame 4
#4  0x004945af in type_print (type=0xa2b4b68, varstring=0x716c4d "",
    stream=0xa084088, show=1) at ../../gdb-6.1.1/gdb/typeprint.c:109
109       LA_PRINT_TYPE (type, varstring, stream, show, 0);
(gdb) info locals
type = (struct type *) 0x0
varstring = 0x0
stream = (struct ui_file *) 0x0
show = 0
(gdb) info args
type = (struct type *) 0x0
varstring = 0x0
stream = (struct ui_file *) 0x0
show = 0

(gdb) frame 5
#5  0x0049482a in ptype_command (typename=0xa05180e "CMainTask", from_tty=1)
    at ../../gdb-6.1.1/gdb/typeprint.c:223
223               type_print (type, "", gdb_stdout, 1);
(gdb) info locals
typename = 0xa05180e "CMainTask"
expr = (struct expression *) 0xa094f38
old_chain = (struct cleanup *) 0xa069ac8
(gdb) info args
typename = 0xa05180e "CMainTask"
from_tty = 1

Maybe this is helpful. Debug format is stabs.
Is this supposed to look like that?

demangled_name = 0xa28da58 "X\203)\nE\203)\nk::~CMainTask(void)"

Thanks

bye  Fabi

Re: gdb 6.1.1 (PPC) crash (long)

[Fabian Cenedese]

>Hi
>
>I get a crash when trying to lookup a symbol with my cross compiled gdb. It's
>just this one symbol (so far), others I can lookup with no problems.
>Here's what happens:
>
>(gdb) ptype this
>type = class CMainTask : public CINOSTask {
>  public:
>    CMainTask & operator=(CMainTask const &);
>    virtual ~CMainTask(void);
>      2 [main] gdb 2100 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
>    329 [main] gdb 2100 open_stackdumpfile: Dumping stack trace to gdb.exe.stackdump

If anybody is interested in solving this, I can send a small debug-only file
(objcopy --only-keep-debug, ~250KB) and the sources and the processed
Assembler files (gcc -S). I still can't find how to solve this, debugging via
gdb is quite new to me.

As mentioned this also happens with the cygwin provided gdb. And I just
checked the "Real Thing" on Linux. gdb-6.0 as well as gdb-6.1-debian
crash on this.

Thanks

bye  Fabi

RE: gdb 6.1.1 (PPC) crash (long) AND gdb crash in cp_print_class_method

[Dave Korn]

> -----Original Message-----
> From: gdb-owner On Behalf Of Fabian Cenedese
> Sent: 01 September 2004 10:18
> To: gdb
> Subject: Re: gdb 6.1.1 (PPC) crash (long)

[...snip!...]

> (gdb) frame 2
> #2  0x004dda6c in c_type_print_base (type=0xa2b4b68, stream=0xa084088,
>     show=1, level=0) at ../../gdb-6.1.1/gdb/c-typeprint.c:952
> 952                       int is_full_physname_constructor =
> (gdb) info locals

[...snip!...]

> mangled_name = 0xa297650 "_._9CMainTask"
> demangled_name = 0xa28da58 "X\203)\nE\203)\nk::~CMainTask(void)"

[...snip!...]

> Is this supposed to look like that?
> 
> demangled_name = 0xa28da58 "X\203)\nE\203)\nk::~CMainTask(void)"



> -----Original Message-----
> From: gdb-owner On Behalf Of Craig Jeffree
> Sent: 02 September 2004 00:48
> To: gdb
> Subject: gdb crash in cp_print_class_method

[...snip!...]

> Crash 1
> =======
> (gdb) bt
> #0  0xb74b0e7a in strcmp () from /lib/tls/libc.so.6
> #1  0x0814d00f in cp_print_class_method (
>     valaddr=0x15a88b68 "\030\214W\bnline/taam/src/m!", 
> type=0x15ab6c48,
>     stream=0x8283740) at cp-valprint.c:134
> #2  0x0814ca69 in c_val_print (type=0x11361658,
>     valaddr=0x15b2d3f8 "??4\bodel/dynamicX", embedded_offset=0,
>     address=139955224, stream=0x8283740, format=0, deref_ref=1,
> recurse=0,
>     pretty=Val_prettyprint) at c-valprint.c:449
> #3  0x080dbc40 in val_print (type=0x11361658,
>     valaddr=0x15b2d3f8 "??4\bodel/dynamicX", embedded_offset=0,
>     address=139955224, stream=0x8283740, format=0, deref_ref=1,
> recurse=0,
>     pretty=Val_pretty_default) at ./valprint.c:149


  Gentlemen, you seem very likely to have stumbled across the same problem.
There is clearly something very very wrong in the C++ demangling and pretty
printing.  Last time I checked the bfd demangler had no regressions in it,
so I think it's fairly likely that something is stomping over the demangled
string after it's been returned to cp_print_class_method by bfd, and this is
causing a later failure when the damaged data is passed to strcmp or
is_constructor_name.  It might be possible to debug this by a clever
combination of scripting and setting hardware memory watchpoints to try and
catch anything changing the relevant memory area apart from the
demangler.... 

  Fabian, about a point from your first email:  the addresses in .stackdump
files are always raw, even from a debug build of the code; the
stackdump-writing code is quite simple and doesn't look them up for you.
You can use 'addr2line' from binutils to decode the "Function" addresses it
shows; check the man/info page for more.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

RE: gdb 6.1.1 (PPC) crash (long) AND gdb crash in cp_print_class_method

[Fabian Cenedese]

>  Gentlemen, you seem very likely to have stumbled across the same problem.
>There is clearly something very very wrong in the C++ demangling and pretty
>printing.  Last time I checked the bfd demangler had no regressions in it,
>so I think it's fairly likely that something is stomping over the demangled
>string after it's been returned to cp_print_class_method by bfd, and this is
>causing a later failure when the damaged data is passed to strcmp or
>is_constructor_name.  It might be possible to debug this by a clever
>combination of scripting and setting hardware memory watchpoints to try and
>catch anything changing the relevant memory area apart from the
>demangler.... 

Just out of curiosity I also tried gdb-5.3 on cygwin. This works without crashing:

GNU gdb 5.3
(gdb) ptype CMainTask
type = class CMainTask : public CINOSTask {
  public:
    CMainTask & operator=(CMainTask const &);
    CMainTask(CMainTask const &);
    virtual ~CMainTask(void);
    CMainTask(char *, unsigned long, unsigned long);
    virtual void Action(void);
}

So it looks like the error was introduced in stepping from 5.3 to 6.0.

>  Fabian, about a point from your first email:  the addresses in .stackdump
>files are always raw, even from a debug build of the code; the
>stackdump-writing code is quite simple and doesn't look them up for you.
>You can use 'addr2line' from binutils to decode the "Function" addresses it
>shows; check the man/info page for more.

Thanks for the hint, I've already wondered what this tool is for :) In this case
it was not necessary as I managed to get a backtrace with running gdb
in gdb. A short test showed that the addresses are the same as in this
backtrace.


(gdb) bt
#0  gnuv2_is_constructor_name (name=0x0)
    at ../../gdb-6.1.1/gdb/gnu-v2-abi.c:56
#1  0x00488bf8 in is_constructor_name (name=0x0)
    at ../../gdb-6.1.1/gdb/cp-abi.c:44
#2  0x004dda6c in c_type_print_base (type=0xa2b4b68, stream=0xa084088,
    show=1, level=0) at ../../gdb-6.1.1/gdb/c-typeprint.c:952
#3  0x004dc816 in c_print_type (type=0xa2b4b68, varstring=0x716c4d "",
    stream=0xa084088, show=1, level=0) at ../../gdb-6.1.1/gdb/c-typeprint.c:75
#4  0x004945af in type_print (type=0xa2b4b68, varstring=0x716c4d "",
    stream=0xa084088, show=1) at ../../gdb-6.1.1/gdb/typeprint.c:109
#5  0x0049482a in ptype_command (typename=0xa05180e "CMainTask", from_tty=1)
    at ../../gdb-6.1.1/gdb/typeprint.c:223
etc


But if memory corruption is the problem this is useless anyway. On the other hand
valgrind showed no error while loading the symbol file, only upon this exact command:


(gdb) file ~/tmp/dbg.x
Reading symbols from ~/tmp/dbg.x...done.
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) ptype CMainTask
type = class CMainTask : public CINOSTask {
 public:
   CMainTask & operator=(CMainTask const &);
   virtual ~CMainTask(void);
==26478== Invalid read of size 1
==26478==    at 0x8171B62: gnuv2_is_constructor_name (gnu-v2-abi.c:56)
==26478==    by 0x8085637: is_constructor_name (cp-abi.c:44)
==26478==    by 0x8160D5B: c_type_print_base (c-typeprint.c:952)
==26478==    by 0x815FAE5: c_print_type (c-typeprint.c:75)
==26478==    by 0x815F57E: type_print (typeprint.c:109)
==26478==    by 0x815F7F9: ptype_command (typeprint.c:223)
==26478==    by 0x80ADF78: do_cfunc (cli-decode.c:57)
==26478==    by 0x80AFE6B: cmd_func (cli-decode.c:1541)
==26478==    by 0x807F7E5: execute_command (top.c:743)
==26478==    by 0x810BC3E: command_handler (event-top.c:500)
==26478==    by 0x810C084: command_line_handler (event-top.c:793)
==26478==    by 0x81E0EA4: rl_callback_read_char (callback.c:123)
==26478==    by 0x810B58A: rl_callback_read_char_wrapper (event-top.c:166)
==26478==    by 0x810BB39: stdin_event_handler (event-top.c:416)
==26478==    by 0x810AE1D: handle_file_event (event-loop.c:721)
==26478==    by 0x810A8D8: process_event (event-loop.c:334)
==26478==    by 0x810A937: gdb_do_one_event (event-loop.c:371)
==26478==    by 0x807F410: do_catch_errors (top.c:523)
==26478==    by 0x807F28F: catcher (top.c:430)
==26478==    by 0x807F46F: catch_errors (top.c:535)
==26478==    by 0x80BC733: tui_command_loop (tui-interp.c:150)
==26478==    by 0x8108648: current_interp_command_loop (interps.c:277)
==26478==    by 0x807A91A: captured_command_loop (main.c:97)
==26478==    by 0x807F410: do_catch_errors (top.c:523)
==26478==    by 0x807F28F: catcher (top.c:430)
==26478==    by 0x807F46F: catch_errors (top.c:535)
==26478==    by 0x807B2E3: captured_main (main.c:805)
==26478==    by 0x807F410: do_catch_errors (top.c:523)
==26478==    by 0x807F28F: catcher (top.c:430)
==26478==    by 0x807F46F: catch_errors (top.c:535)
==26478==    by 0x807B762: gdb_main (main.c:814)
==26478==    by 0x807A8FD: main (gdb.c:35)
==26478==  Address 0x0 is not stack'd, malloc'd or free'd
==26478==
==26478== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==26478==  Access not within mapped region at address 0x0
==26478==    at 0x8171B62: gnuv2_is_constructor_name (gnu-v2-abi.c:56)
==26478==    by 0x8085637: is_constructor_name (cp-abi.c:44)
==26478==    by 0x8160D5B: c_type_print_base (c-typeprint.c:952)
==26478==    by 0x815FAE5: c_print_type (c-typeprint.c:75)
==26478==    by 0x815F57E: type_print (typeprint.c:109)
==26478==    by 0x815F7F9: ptype_command (typeprint.c:223)
==26478==    by 0x80ADF78: do_cfunc (cli-decode.c:57)
==26478==    by 0x80AFE6B: cmd_func (cli-decode.c:1541)
==26478==    by 0x807F7E5: execute_command (top.c:743)
==26478==    by 0x810BC3E: command_handler (event-top.c:500)
==26478==    by 0x810C084: command_line_handler (event-top.c:793)
==26478==    by 0x81E0EA4: rl_callback_read_char (callback.c:123)
==26478==    by 0x810B58A: rl_callback_read_char_wrapper (event-top.c:166)
==26478==    by 0x810BB39: stdin_event_handler (event-top.c:416)
==26478==    by 0x810AE1D: handle_file_event (event-loop.c:721)
==26478==    by 0x810A8D8: process_event (event-loop.c:334)
==26478==    by 0x810A937: gdb_do_one_event (event-loop.c:371)
==26478==    by 0x807F410: do_catch_errors (top.c:523)
==26478==    by 0x807F28F: catcher (top.c:430)
==26478==    by 0x807F46F: catch_errors (top.c:535)
==26478==    by 0x80BC733: tui_command_loop (tui-interp.c:150)
==26478==    by 0x8108648: current_interp_command_loop (interps.c:277)
==26478==    by 0x807A91A: captured_command_loop (main.c:97)
==26478==    by 0x807F410: do_catch_errors (top.c:523)
==26478==    by 0x807F28F: catcher (top.c:430)
==26478==    by 0x807F46F: catch_errors (top.c:535)
==26478==    by 0x807B2E3: captured_main (main.c:805)
==26478==    by 0x807F410: do_catch_errors (top.c:523)
==26478==    by 0x807F28F: catcher (top.c:430)
==26478==    by 0x807F46F: catch_errors (top.c:535)
==26478==    by 0x807B762: gdb_main (main.c:814)
==26478==    by 0x807A8FD: main (gdb.c:35)
==26478==
==26478== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 24 from 2)
==26478== malloc/free: in use at exit: 742482 bytes in 4289 blocks.
==26478== malloc/free: 10558 allocs, 6269 frees, 1079443 bytes allocated.
==26478== For a detailed leak analysis,  rerun with: --leak-check=yes
==26478== For counts of detected errors, rerun with: -v
Segmentation fault

Thanks

bye  Fabi

RE: gdb 6.1.1 (PPC) crash (long) AND gdb crash in cp_print_class_method

[Dave Korn]

> -----Original Message-----
> From: gdb-owner On Behalf Of Fabian Cenedese
> Sent: 02 September 2004 13:59

> Just out of curiosity I also tried gdb-5.3 on cygwin. This 
> works without crashing:
> 
> GNU gdb 5.3
> (gdb) ptype CMainTask
> type = class CMainTask : public CINOSTask {
>   public:
>     CMainTask & operator=(CMainTask const &);
>     CMainTask(CMainTask const &);
>     virtual ~CMainTask(void);
>     CMainTask(char *, unsigned long, unsigned long);
>     virtual void Action(void);
> }
> 
> So it looks like the error was introduced in stepping from 5.3 to 6.0.

  Or perhaps as a consequence of the C++ ABI changes between gcc 2.9x and
gcc 3.x, or recent improvements and upgrading of dwarf handling.

  Craig, is your code also compiled using an old gcc 2.95 as well, by any
chance?

> But if memory corruption is the problem this is useless 
> anyway. On the other hand
> valgrind showed no error while loading the symbol file, only 
> upon this exact command:

  Yep, the corruption happens to data in valid memory addresses (the
demangled string is stomped all over), and this is indistinguishable (from
valgrind's viewpoint) from legitimate writes to that memory area.  What
happens later to cause the SEGV is a knock-on consequence of the error: I
surmise that something is trying to parse the damaged name string, not
finding what it's looking for as a result of the name not making syntactical
sense owing to its having been overwritten; then passing the NULL pointer
that results from that failed search/parse operation to some later function
that ends up passing it to strcmp (Craig's bug) or trying to dereference it
directly (your example).


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

RE: gdb 6.1.1 (PPC) crash (long) AND gdb crash in cp_print_class_method

[Craig Jeffree]

On Fri, 2004-09-03 at 00:05, Dave Korn wrote:
>   Or perhaps as a consequence of the C++ ABI changes between gcc 2.9x and
> gcc 3.x, or recent improvements and upgrading of dwarf handling.
> 
>   Craig, is your code also compiled using an old gcc 2.95 as well, by any
> chance?
> 

Yes.  2.95.3 infact.  

Cheers,
Craig.

RE: gdb 6.1.1 (PPC) crash (long) AND gdb crash in cp_print_class_method

[Dave Korn]

> -----Original Message-----
> From: Craig Jeffree
> Sent: 02 September 2004 23:48
> To: Dave Korn
> Cc: 'Fabian Cenedese'; gdb
> Subject: RE: gdb 6.1.1 (PPC) crash (long) AND gdb crash in 
> cp_print_class_method
> 
> On Fri, 2004-09-03 at 00:05, Dave Korn wrote:
> >   Or perhaps as a consequence of the C++ ABI changes 
> between gcc 2.9x and
> > gcc 3.x, or recent improvements and upgrading of dwarf handling.
> > 
> >   Craig, is your code also compiled using an old gcc 2.95 
> as well, by any
> > chance?
> > 
> 
> Yes.  2.95.3 infact.  
> 
> Cheers,
> Craig.


  OK, we have our suspect then: some kind of backward incompatibility
between gdb-6.x (which is sync'ed with gcc-3.x) and the objects compiled by
gcc-2.x, and it is most likely to be caused by either a change in the
name-mangling relating to the new C++ ABI in series 3 gcc, or a change in
the debug info format.

  I'm not too familiar with the internals here, so my first recommendation
to both of you would be to revert to a 5.x gdb, which was the contemporary
version to 2.95, and as Fabian has already observed seems to handle the
object files in question without any problem.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....
 

Re: gdb 6.1.1 (PPC) crash (long)

[Daniel Jacobowitz]

On Thu, Sep 02, 2004 at 01:58:31PM +0200, Fabian Cenedese wrote:
> 
> >Hi
> >
> >I get a crash when trying to lookup a symbol with my cross compiled gdb. It's
> >just this one symbol (so far), others I can lookup with no problems.
> >Here's what happens:
> >
> >(gdb) ptype this
> >type = class CMainTask : public CINOSTask {
> >  public:
> >    CMainTask & operator=(CMainTask const &);
> >    virtual ~CMainTask(void);
> >      2 [main] gdb 2100 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
> >    329 [main] gdb 2100 open_stackdumpfile: Dumping stack trace to gdb.exe.stackdump
> 
> If anybody is interested in solving this, I can send a small debug-only file
> (objcopy --only-keep-debug, ~250KB) and the sources and the processed
> Assembler files (gcc -S). I still can't find how to solve this, debugging via
> gdb is quite new to me.

I'll take a look at it; could you send them to me (off-list)?

-- 
Daniel Jacobowitz

Re: gdb 6.1.1 (PPC) crash (long)

[Daniel Jacobowitz]

On Tue, Sep 07, 2004 at 05:13:41PM +0200, Fabian Cenedese wrote:
> 
> >> >Here's what happens:
> >> >
> >> >(gdb) ptype this
> >> >type = class CMainTask : public CINOSTask {
> >> >  public:
> >> >    CMainTask & operator=(CMainTask const &);
> >> >    virtual ~CMainTask(void);
> >> >      2 [main] gdb 2100 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
> >> >    329 [main] gdb 2100 open_stackdumpfile: Dumping stack trace to gdb.exe.stackdump
> >> 
> >> If anybody is interested in solving this, I can send a small debug-only file
> >> (objcopy --only-keep-debug, ~250KB) and the sources and the processed
> >> Assembler files (gcc -S). I still can't find how to solve this, debugging via
> >> gdb is quite new to me.
> >
> >I'll take a look at it; could you send them to me (off-list)?
> 
> Here it is. The cpp looks... not so good as I tried to comment out as much as
> possible to keep the info small. But I don't know if you even need it. The file
> dbg.x is the one I load into gdb and makes it crash with the above command,
> I just tested this again.
> 
> Thanks for your help.

OK, I can reproduce it.  It looks like a bug in the stab reader. 
Here's the stab; newlines added for clarity but I don't swear I got
them in the right place.

 CMainTask:Tt(0,25)=s148!1,020,(16,31);
   __as::(0,26)=##(0,27)=&(0,25);:RC9CMainTask;2A.;
   CMainTask::(0,28)=##(0,29)=*(0,25);:RC9CMainTask;2A.
	      (0,30)=#(0,25),(0,20),(0,29),(0,1),(0,20);:_._9CMainTask;2A*1;(16,31);
	      (0,31)=##(0,29);:PcUlUl;2A.;
   Action::(0,32)=##(0,20);:;2A*2;(16,31);;;~%(16,31);

We're completely botching up the parsing of the constructor.  The
problem seems to be the presence of constructor, destructor,
constructor.  The bug will be, in current CVS, in stabsread.c around
line 2468 in the has_destructor && has_other case.

It looks like I got the linked list management wrong; I have this
habitual problem with linked lists.  The bug may be pretty easy to spot
but I don't have time to dig for it today.

Hope this helps!

-- 
Daniel Jacobowitz

Re: gdb 6.1.1 (PPC) crash (long)

[Craig Jeffree]

On Wed, 2004-09-08 at 03:02, Daniel Jacobowitz wrote:
> It looks like I got the linked list management wrong; I have this
> habitual problem with linked lists.  The bug may be pretty easy to spot
> but I don't have time to dig for it today.
> 

Hi, we're having a lot of trouble with this bug and unfortunately we
don't have the resources here to fix it ourselves, although we've
tried.  Is this being worked on by anyone else?  If not can someone
please have a look at it - we're really stuck and starting to look for
other debuggers to use.

Thanks for you help,
Craig.