-data-disassemble segmetation fault

-data-disassemble segmetation fault

[Bob Rossi]

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

Hi,

I tried using the -data-disassemble command on the attached file.
I ran this command,
-data-disassemble -f basic.c -l 25 -n -1 -- 1
and gdb segfaulted.

I am concerned that the MI code is being presented as an alternative 
interface to GDB, but it is mainly untested when it comes to building 
a practical application on top of it. Either that, or I just found the
needle in the haystack crash, since it was the first or second command I
ran.

Please let me know if I am doing anything wrong.

I have attached the file that reproduced the crash ( basic.c ), and I also
attached a backtrace. I was running a gdb out of cvs, freshly updated
tonight ( 07/29/2003 ).

Thanks,
Bob Rossi

[-- Attachment #2: basic.c --]
[-- Type: text/x-csrc, Size: 1110 bytes --]

#include <stdio.h>
#include <unistd.h>

int two(int a){
   return a*a;
}

int one(int a, int b){
   return two(a) + two(b);
}

void short_func(void){
   int i = 0;
   i = 1;
   i = 2;
}

void long_func(void){
   int k = 0;
   k = 1;
   k = 2;
}

#define SIZE 100000

struct test {
   int a;
   int b;
   int c;  
} a = { 1, 2, 3 };

int main(int argc, char **argv){
   int i = 3;
   int j = 4;
   char temp[SIZE];

   long_func();

   fprintf(stderr, "ABCDEFGHI\n");
   fprintf(stderr, "ABCDEFGH\n");
   fprintf(stderr, "ABCDEFG\n");
   fprintf(stderr, "ABCDEF\n");
   fprintf(stderr, "ABCDE\n");
   fprintf(stderr, "ABCD\n");
   fprintf(stderr, "ABC\n");
   fprintf(stderr, "AB\n");
   fprintf(stderr, "A\n");

   for ( i = 0; i < 100; i++)
       fprintf(stderr, "Yo\n");

   long_func();

   short_func();
   short_func();
   short_func();

   /* A simple loop */
   for(i = 0; i < 100000; ++i)
      j++;

   i = one(i, j);
   j = two(i);

   for(i = 0; i < 6; ++i)
      fprintf(stderr, "returned from init\n");

   for(i = 0; i < SIZE; ++i)
      temp[i] = (i % 40) + 40;

   i += j;
   
   return 0;
}


[-- Attachment #3: gdb.bt --]
[-- Type: text/plain, Size: 4975 bytes --]

$ gdb /home/bob/cvs/src/gdb/gdb core 
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...
Core was generated by `/home/bob/cvs/src/gdb/gdb -i=mi ./basic'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Loaded symbols for /usr/X11R6/lib/libX11.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libncurses.so.5...done.
Loaded symbols for /lib/libncurses.so.5
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libthread_db.so.1...done.
Loaded symbols for /lib/libthread_db.so.1
#0  0x08122735 in ui_file_rewind (file=0x0) at ui-file.c:184
184     file->to_rewind (file);
(gdb) bt
#0  0x08122735 in ui_file_rewind (file=0x0) at ui-file.c:184
#1  0x080afa2a in dump_insns (uiout=0x83f7808, di=0xbfffef28, low=134514080, high=134514102, 
    how_many=-1, stb=0x8400510) at disasm.c:134
#2  0x080afdce in do_mixed_source_and_assembly (uiout=0x83f7808, di=0xbfffef28, nlines=58, 
    le=0x84340ac, low=134513836, high=134514396, symtab=0x8434054, how_many=-1, stb=0x8400510)
    at disasm.c:281
#3  0x080b0032 in gdb_disassembly (uiout=0x83f7808, file_string=0x841a300 "basic.c", line_num=25, 
    mixed_source_and_assembly=1, how_many=-1, low=134513836, high=134514396) at disasm.c:370
#4  0x080977a1 in mi_cmd_disassemble (command=0x83edf80 "data-disassemble", argv=0x8400674, argc=8)
    at ./mi/mi-cmd-disas.c:157
#5  0x08099877 in mi_cmd_execute (parse=0x83f0a48) at ./mi/mi-main.c:1276
#6  0x0809944e in captured_mi_execute_command (uiout=0x83f7808, data=0xbffff1d0)
    at ./mi/mi-main.c:1105
#7  0x0811dc25 in catcher (func=0x80993f0 <captured_mi_execute_command>, func_uiout=0x83f7808, 
    func_args=0xbffff1d0, func_val=0xbffff184, func_caught=0xbffff188, errstring=0x82f7e1e "", 
    mask=6) at top.c:429
#8  0x0811dce1 in catch_exceptions (uiout=0x83f7808, func=0x80993f0 <captured_mi_execute_command>, 
    func_args=0xbffff1d0, errstring=0x82f7e1e "", mask=6) at top.c:479
#9  0x080996a6 in mi_execute_command (
    cmd=0x841a1d0 "-data-disassemble -f basic.c -l 25 -n -1 -- 1", from_tty=1)
    at ./mi/mi-main.c:1205
#10 0x08097dd1 in mi_execute_command_wrapper (
    cmd=0x841a1d0 "-data-disassemble -f basic.c -l 25 -n -1 -- 1") at ./mi/mi-interp.c:321
#11 0x080ddb6c in gdb_readline2 (client_data=0x0) at event-top.c:877
#12 0x080dd2bd in stdin_event_handler (error=0, client_data=0x0) at event-top.c:416
#13 0x080dc6b6 in handle_file_event (event_file_desc=0) at event-loop.c:721
#14 0x080dc1c6 in process_event () at event-loop.c:334
#15 0x080dc205 in gdb_do_one_event (data=0x0) at event-loop.c:371
#16 0x0811dd53 in do_catch_errors (uiout=0x83f7808, data=0xbffff414) at top.c:497
#17 0x0811dc25 in catcher (func=0x811dd40 <do_catch_errors>, func_uiout=0x83f7808, 
    func_args=0xbffff414, func_val=0xbffff40c, func_caught=0xbffff410, errstring=0x830dd00 "", 
    mask=6) at top.c:429
#18 0x0811dd93 in catch_errors (func=0x80dc1dc <gdb_do_one_event>, func_args=0x0, 
    errstring=0x830dd00 "", mask=6) at top.c:509
#19 0x080dc243 in start_event_loop () at event-loop.c:422
#20 0x08097e55 in mi_command_loop (mi_version=2) at ./mi/mi-interp.c:387
#21 0x08097df8 in mi2_command_loop () at ./mi/mi-interp.c:333
#22 0x080dbc49 in current_interp_command_loop () at interps.c:274
#23 0x0808d48b in captured_command_loop (data=0x0) at ./main.c:97
#24 0x0811dd53 in do_catch_errors (uiout=0x83f7808, data=0xbffff5d4) at top.c:497
#25 0x0811dc25 in catcher (func=0x811dd40 <do_catch_errors>, func_uiout=0x83f7808, 
    func_args=0xbffff5d4, func_val=0xbffff5cc, func_caught=0xbffff5d0, errstring=0x82f0b60 "", 
    mask=6) at top.c:429
#26 0x0811dd93 in catch_errors (func=0x808d480 <captured_command_loop>, func_args=0x0, 
    errstring=0x82f0b60 "", mask=6) at top.c:509
#27 0x0808e203 in captured_main (data=0xbffff8bc) at ./main.c:811
#28 0x0811dd53 in do_catch_errors (uiout=0x8398b00, data=0xbffff874) at top.c:497
#29 0x0811dc25 in catcher (func=0x811dd40 <do_catch_errors>, func_uiout=0x8398b00, 
    func_args=0xbffff874, func_val=0xbffff86c, func_caught=0xbffff870, errstring=0x82f0b60 "", 
    mask=6) at top.c:429
#30 0x0811dd93 in catch_errors (func=0x808d4c0 <captured_main>, func_args=0xbffff8bc, 
    errstring=0x82f0b60 "", mask=6) at top.c:509
#31 0x0808e22b in gdb_main (args=0xbffff8bc) at ./main.c:820
#32 0x0808d47c in main (argc=3, argv=0xbffff934) at gdb.c:35
(gdb)

Re: -data-disassemble segmetation fault

[Andrew Cagney]

> Hi,
> 
> I tried using the -data-disassemble command on the attached file.
> I ran this command,
> -data-disassemble -f basic.c -l 25 -n -1 -- 1
> and gdb segfaulted.
> 
> I am concerned that the MI code is being presented as an alternative 
> interface to GDB, but it is mainly untested when it comes to building 
> a practical application on top of it.   Either that, or I just found the
> needle in the haystack crash, since it was the first or second command I
> ran.

Given that a quick glance at GDBs testsuite reveals that it is trying 
all the following combinations:

111-data-disassemble -s $pc -e "$pc + 12" -- 0
222-data-disassemble  -f basics.c -l 32 -- 0
002-data-disassemble -f basics.c -l 21 -- 1
003-data-disassemble -s $pc -e "$pc+4" -- 1
123-data-disassemble -f foo -l abc -n 0 -- 0
321-data-disassemble -s foo -e bar -- 0
456-data-disassemble -s $pc -f basics.c -- 0
789-data-disassemble -f basics.c -l 32 -- 9
222-data-disassemble  -f basics.c -l 32 -n 20 -- 0
222-data-disassemble  -f basics.c -l 32 -n 0 -- 0
222-data-disassemble  -f basics.c -l 32 -n 50 -- 0
222-data-disassemble  -f basics.c -l 32 -n 20 -- 1
222-data-disassemble  -f basics.c -l 32 -n 0 -- 1
222-data-disassemble  -f basics.c -l 32 -n 50 -- 1
111-data-disassemble -s $pc -e "$pc + 12" -- 0
222-data-disassemble  -f basics.c -l 32 -- 0
002-data-disassemble -f basics.c -l 21 -- 1
003-data-disassemble -s $pc -e "$pc+4" -- 1
123-data-disassemble -f foo -l abc -n 0 -- 0
321-data-disassemble -s foo -e bar -- 0
456-data-disassemble -s $pc -f basics.c -- 0
789-data-disassemble -f basics.c -l 32 -- 9
222-data-disassemble  -f basics.c -l 32 -n 20 -- 0
222-data-disassemble  -f basics.c -l 32 -n 0 -- 0
222-data-disassemble  -f basics.c -l 32 -n 50 -- 0
222-data-disassemble  -f basics.c -l 32 -n 20 -- 1
222-data-disassemble  -f basics.c -l 32 -n 0 -- 1
222-data-disassemble  -f basics.c -l 32 -n 50 -- 1

I'd assume that you've tickled an edge case.

> Please let me know if I am doing anything wrong.
> 
> I have attached the file that reproduced the crash ( basic.c ), and I also
> attached a backtrace. I was running a gdb out of cvs, freshly updated
> tonight ( 07/29/2003 ).

Can you turn this into a bug report (transcript of what lead to the 
sigseg) and an addition gdb<PRNUM> to the testsuite.  That way it can be 
added to the repository.  Of course, if you've also got a patch.

Andrew

Re: -data-disassemble segmetation fault

[Bob Rossi]

Hi,

I haven't added the PR yet because I plan on trying to fix the bug when
I get some time.

Should I add the PR first, and then fix the bug if I get time?

Also, I didn't know if you realized that the file I sent in 
called 'basics.c' is not the same file as the one in the gdb
testsuite directory. This is probably why I found the crash, it does
look as if basics.c in the testsuite is tested well.

Thanks,
Bob Rossi

On Wed, Jul 30, 2003 at 10:45:33AM -0400, Andrew Cagney wrote:
> >Hi,
> >
> >I tried using the -data-disassemble command on the attached file.
> >I ran this command,
> >-data-disassemble -f basic.c -l 25 -n -1 -- 1
> >and gdb segfaulted.
> >
> >I am concerned that the MI code is being presented as an alternative 
> >interface to GDB, but it is mainly untested when it comes to building 
> >a practical application on top of it.   Either that, or I just found the
> >needle in the haystack crash, since it was the first or second command I
> >ran.
> 
> Given that a quick glance at GDBs testsuite reveals that it is trying 
> all the following combinations:
> 
> 111-data-disassemble -s $pc -e "$pc + 12" -- 0
> 222-data-disassemble  -f basics.c -l 32 -- 0
> 002-data-disassemble -f basics.c -l 21 -- 1
> 003-data-disassemble -s $pc -e "$pc+4" -- 1
> 123-data-disassemble -f foo -l abc -n 0 -- 0
> 321-data-disassemble -s foo -e bar -- 0
> 456-data-disassemble -s $pc -f basics.c -- 0
> 789-data-disassemble -f basics.c -l 32 -- 9
> 222-data-disassemble  -f basics.c -l 32 -n 20 -- 0
> 222-data-disassemble  -f basics.c -l 32 -n 0 -- 0
> 222-data-disassemble  -f basics.c -l 32 -n 50 -- 0
> 222-data-disassemble  -f basics.c -l 32 -n 20 -- 1
> 222-data-disassemble  -f basics.c -l 32 -n 0 -- 1
> 222-data-disassemble  -f basics.c -l 32 -n 50 -- 1
> 111-data-disassemble -s $pc -e "$pc + 12" -- 0
> 222-data-disassemble  -f basics.c -l 32 -- 0
> 002-data-disassemble -f basics.c -l 21 -- 1
> 003-data-disassemble -s $pc -e "$pc+4" -- 1
> 123-data-disassemble -f foo -l abc -n 0 -- 0
> 321-data-disassemble -s foo -e bar -- 0
> 456-data-disassemble -s $pc -f basics.c -- 0
> 789-data-disassemble -f basics.c -l 32 -- 9
> 222-data-disassemble  -f basics.c -l 32 -n 20 -- 0
> 222-data-disassemble  -f basics.c -l 32 -n 0 -- 0
> 222-data-disassemble  -f basics.c -l 32 -n 50 -- 0
> 222-data-disassemble  -f basics.c -l 32 -n 20 -- 1
> 222-data-disassemble  -f basics.c -l 32 -n 0 -- 1
> 222-data-disassemble  -f basics.c -l 32 -n 50 -- 1
> 
> I'd assume that you've tickled an edge case.
> 
> >Please let me know if I am doing anything wrong.
> >
> >I have attached the file that reproduced the crash ( basic.c ), and I also
> >attached a backtrace. I was running a gdb out of cvs, freshly updated
> >tonight ( 07/29/2003 ).
> 
> Can you turn this into a bug report (transcript of what lead to the 
> sigseg) and an addition gdb<PRNUM> to the testsuite.  That way it can be 
> added to the repository.  Of course, if you've also got a patch.
> 
> Andrew
> 

Re: -data-disassemble segmetation fault

[Andrew Cagney]

> Hi,
> 
> I haven't added the PR yet because I plan on trying to fix the bug when
> I get some time.
> 
> Should I add the PR first, and then fix the bug if I get time?

If you intend posting a patch (with addition to the existing disasm 
tests), no skip all that.

Andrew


> Also, I didn't know if you realized that the file I sent in 
> called 'basics.c' is not the same file as the one in the gdb
> testsuite directory. This is probably why I found the crash, it does
> look as if basics.c in the testsuite is tested well.
> 
> Thanks,
> Bob Rossi
> 
> On Wed, Jul 30, 2003 at 10:45:33AM -0400, Andrew Cagney wrote:
> 
>> >Hi,
>> >
>> >I tried using the -data-disassemble command on the attached file.
>> >I ran this command,
>> >-data-disassemble -f basic.c -l 25 -n -1 -- 1
>> >and gdb segfaulted.
>> >
>> >I am concerned that the MI code is being presented as an alternative 
>> >interface to GDB, but it is mainly untested when it comes to building 
>> >a practical application on top of it.   Either that, or I just found the
>> >needle in the haystack crash, since it was the first or second command I
>> >ran.
> 
>> 
>> Given that a quick glance at GDBs testsuite reveals that it is trying 
>> all the following combinations:
>> 
>> 111-data-disassemble -s $pc -e "$pc + 12" -- 0
>> 222-data-disassemble  -f basics.c -l 32 -- 0
>> 002-data-disassemble -f basics.c -l 21 -- 1
>> 003-data-disassemble -s $pc -e "$pc+4" -- 1
>> 123-data-disassemble -f foo -l abc -n 0 -- 0
>> 321-data-disassemble -s foo -e bar -- 0
>> 456-data-disassemble -s $pc -f basics.c -- 0
>> 789-data-disassemble -f basics.c -l 32 -- 9
>> 222-data-disassemble  -f basics.c -l 32 -n 20 -- 0
>> 222-data-disassemble  -f basics.c -l 32 -n 0 -- 0
>> 222-data-disassemble  -f basics.c -l 32 -n 50 -- 0
>> 222-data-disassemble  -f basics.c -l 32 -n 20 -- 1
>> 222-data-disassemble  -f basics.c -l 32 -n 0 -- 1
>> 222-data-disassemble  -f basics.c -l 32 -n 50 -- 1
>> 111-data-disassemble -s $pc -e "$pc + 12" -- 0
>> 222-data-disassemble  -f basics.c -l 32 -- 0
>> 002-data-disassemble -f basics.c -l 21 -- 1
>> 003-data-disassemble -s $pc -e "$pc+4" -- 1
>> 123-data-disassemble -f foo -l abc -n 0 -- 0
>> 321-data-disassemble -s foo -e bar -- 0
>> 456-data-disassemble -s $pc -f basics.c -- 0
>> 789-data-disassemble -f basics.c -l 32 -- 9
>> 222-data-disassemble  -f basics.c -l 32 -n 20 -- 0
>> 222-data-disassemble  -f basics.c -l 32 -n 0 -- 0
>> 222-data-disassemble  -f basics.c -l 32 -n 50 -- 0
>> 222-data-disassemble  -f basics.c -l 32 -n 20 -- 1
>> 222-data-disassemble  -f basics.c -l 32 -n 0 -- 1
>> 222-data-disassemble  -f basics.c -l 32 -n 50 -- 1
>> 
>> I'd assume that you've tickled an edge case.
>> 
> 
>> >Please let me know if I am doing anything wrong.
>> >
>> >I have attached the file that reproduced the crash ( basic.c ), and I also
>> >attached a backtrace. I was running a gdb out of cvs, freshly updated
>> >tonight ( 07/29/2003 ).
> 
>> 
>> Can you turn this into a bug report (transcript of what lead to the 
>> sigseg) and an addition gdb<PRNUM> to the testsuite.  That way it can be 
>> added to the repository.  Of course, if you've also got a patch.
>> 
>> Andrew
>> 
> 
>