segfault

segfault

[Erik Leunissen]

I ran into a segfault when using gdb-6.4 from within the graphical 
debugger ddd. See below for the back trace.

My (casual) interpretation of the back trace:
It appears that somehow xstrvprintf() in utils.c is called with an empty 
string '\0' to append, upon which strlen() explodes.

I did not encounter any issues when running gdb straight (i.e. without a 
graphical driver program). So this issue may be specific to the 
combination of gdb - ddd.

Nevertheless, a segfault appears a response a bit too rough.

Sincerely,

Erik Leunissen

== back trace from core file ==

GNU gdb 6.4
Copyright 2005 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-linux-gnu"...Using host libthread_db 
library "/lib/libthread_db.so.1".

Core was generated by `gdb -q -fullname /usr/bin/tclsh 4282'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libncurses.so.5...done.
Loaded symbols for /lib/libncurses.so.5
Reading symbols from /lib/i686/libm.so.6...done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/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
Reading symbols from /usr/lib/gconv/ISO8859-1.so...done.
Loaded symbols for /usr/lib/gconv/ISO8859-1.so
#0  0x4011621b in strlen () from /lib/i686/libc.so.6
(gdb) bt
#0  0x4011621b in strlen () from /lib/i686/libc.so.6
#1  0x400e77d8 in vfprintf () from /lib/i686/libc.so.6
#2  0x40106c62 in vasprintf () from /lib/i686/libc.so.6
#3  0x08084b07 in xstrvprintf (format=0x825064e "Current source file is 
%s\n", ap=0xbfffeaf4 "\n")
     at /usr/local/src/gdb-6.4/gdb/utils.c:1070
#4  0x080861a1 in vfprintf_maybe_filtered (stream=0xa, format=0x1b01 
<Address 0x1b01 out of bounds>,
     args=0x2 <Address 0x2 out of bounds>, filter=1) at 
/usr/local/src/gdb-6.4/gdb/utils.c:2165
#5  0x08086284 in printf_filtered (format=0x825064e "Current source file 
is %s\n")
     at /usr/local/src/gdb-6.4/gdb/utils.c:2241
#6  0x080e3254 in source_info (ignore=0x0, from_tty=0) at 
/usr/local/src/gdb-6.4/gdb/source.c:594
#7  0x08083053 in execute_command (p=0x82d1fab "", from_tty=0) at 
/usr/local/src/gdb-6.4/gdb/top.c:451
#8  0x0811d67b in command_handler (command=0x82d1fa0 "info source")
     at /usr/local/src/gdb-6.4/gdb/event-top.c:508
#9  0x0811e359 in command_line_handler (rl=0x8342198 "Ø\234U\b")
     at /usr/local/src/gdb-6.4/gdb/event-top.c:793
#10 0x081c551f in rl_callback_read_char () at 
/usr/local/src/gdb-6.4/readline/callback.c:123
#11 0x0811d83b in rl_callback_read_char_wrapper (client_data=0x0)
     at /usr/local/src/gdb-6.4/gdb/event-top.c:174
#12 0x0811d1b2 in handle_file_event (event_file_desc=0) at 
/usr/local/src/gdb-6.4/gdb/event-loop.c:728
#13 0x0811c65d in process_event () at 
/usr/local/src/gdb-6.4/gdb/event-loop.c:341
#14 0x0811ce25 in gdb_do_one_event (data=0x0) at 
/usr/local/src/gdb-6.4/gdb/event-loop.c:378
#15 0x08119b5b in catch_errors (func=0x811cd10 <gdb_do_one_event>, 
func_args=0x0, errstring=0x8237ff8 "",
     mask=6) at /usr/local/src/gdb-6.4/gdb/exceptions.c:515
#16 0x080c3b64 in tui_command_loop (data=0x0) at 
/usr/local/src/gdb-6.4/gdb/tui/tui-interp.c:151
#17 0x0811a18f in current_interp_command_loop () at 
/usr/local/src/gdb-6.4/gdb/interps.c:278
#18 0x0807c1bb in captured_command_loop (data=0x0) at 
/usr/local/src/gdb-6.4/gdb/main.c:101
#19 0x08119b5b in catch_errors (func=0x807c1b0 <captured_command_loop>, 
func_args=0x0,
     errstring=0x8237ff8 "", mask=6) at 
/usr/local/src/gdb-6.4/gdb/exceptions.c:515
#20 0x0807c9c4 in captured_main (data=0xbfffeeb4) at 
/usr/local/src/gdb-6.4/gdb/main.c:829
#21 0x08119b5b in catch_errors (func=0x807c1f0 <captured_main>, 
func_args=0xbfffeeb4,
     errstring=0x8237ff8 "", mask=6) at 
/usr/local/src/gdb-6.4/gdb/exceptions.c:515
#22 0x0807c1a3 in gdb_main (args=0xbfffeeb4) at 
/usr/local/src/gdb-6.4/gdb/main.c:838
#23 0x0807c165 in main (argc=Cannot access memory at address 0x2
) at /usr/local/src/gdb-6.4/gdb/gdb.c:35

== end of message ==

Re: segfault

[Erik Leunissen]

Erik Leunissen wrote:
> 
> My (casual) interpretation of the back trace:
> It appears that somehow xstrvprintf() in utils.c is called with an empty 
> string '\0' to append, upon which strlen() explodes.
> 

Well that's too casual! A newline character is being appended, not an 
empty string.

Erik

Re: segfault

[Daniel Jacobowitz]

On Mon, Nov 06, 2006 at 11:21:49AM +0100, Erik Leunissen wrote:
> #6  0x080e3254 in source_info (ignore=0x0, from_tty=0) at 
> /usr/local/src/gdb-6.4/gdb/source.c:594

Is s->filename NULL?


-- 
Daniel Jacobowitz
CodeSourcery

Re: segfault

[Erik Leunissen]

Daniel Jacobowitz wrote:
> 
> Is s->filename NULL?
> 

I'm rather occupied by another segfault (in a different project) right now.

In the coming weekend I'll attach gdb onto itself and report back about 
this.


Erik Leunissen.

Re: segfault

[Erik Leunissen]

Daniel Jacobowitz wrote:
> 
> Is s->filename NULL?
> 

It appears that segfaults occur in more programs/libraries on my system
since a week or so. These programs have in common that they were
compiled with a home-compiled upgrade of gcc-4.1.1. Gdb-6.4 was one of
the programs compiled with the upgraded compiler.

I am now recompiling with the system supplied compiler (gcc-3.1.1). 
Whether the segfault persists, I will report later.

Erik Leunissen
=============

Re: segfault

[Erik Leunissen]

Erik Leunissen wrote:
> Daniel Jacobowitz wrote:
>>
>> Is s->filename NULL?
>>
> 
> It appears that segfaults occur in more programs/libraries on my system
> since a week or so. These programs have in common that they were
> compiled with a home-compiled upgrade of gcc-4.1.1. Gdb-6.4 was one of
> the programs compiled with the upgraded compiler.
> 
> I am now recompiling with the system supplied compiler (gcc-3.1.1). 
> Whether the segfault persists, I will report later.
> 
> Erik Leunissen
> =============
> 
> 

The segfault does not occur anymore with gdb-6.4 compiled by the system 
supplied compiler. Therefore, I attribute the observed segfault to a 
broken gcc-4.1.1 and not to gdb-6.4

Sorry for the noise.

Erik.