Segfault in varobj.c

Segfault in varobj.c

[Robert Norton]

Hi,

I encountered a segfault whilst using our port of GDB with Eclipse. It
occurs when I add a number of global variables in the variables view and
expand them. Occasionally I observe something like the following in the
MI console:

(gdb) 
2247-var-list-children
var2.tx_ready_next.tx_ready_next.tx_ready_next.tx_suspended_next.tx_thre
ad_name
warning: Child of parent whose type does not allow children
&"warning: Child of parent whose type does not allow children\n"

Followed by gdb segfaulting. On loading the core file I observe:

#0  0x08152df9 in c_number_of_children (var=0x8b10410) at
../../../src/binutils/gdb/varobj.c:1764
1764      switch (TYPE_CODE (type))
(gdb) list
1759
1760      type = get_type (var);
1761      target = get_target_type (type);
1762      children = 0;
1763
1764      switch (TYPE_CODE (type))
1765        {
1766        case TYPE_CODE_ARRAY:
1767          if (TYPE_LENGTH (type) > 0 && TYPE_LENGTH (target) > 0
1768              && TYPE_ARRAY_UPPER_BOUND_TYPE (type) !=
BOUND_CANNOT_BE_DETERMINED)
(gdb) p type
$1 = (struct type *) 0x0
(gdb) p *var
$3 = {name = 0x8ad1f08 "*tx_thread_name", obj_name = 0x8ad6b70
"var14.1.tx_thread_name.*tx_thread_name", index = 0, type = 0x0, value =
0x0, error = 0, num_children = -1,
  parent = 0x8ab1f90, children = 0x0, root = 0x8ad97a0, format =
FORMAT_NATURAL, updated = 0}
(gdb) bt
#0  0x08152df9 in c_number_of_children (var=0x8b10410) at
../../../src/binutils/gdb/varobj.c:1764
#1  0x08152acf in number_of_children (var=0x8b10410) at
../../../src/binutils/gdb/varobj.c:1587
#2  0x08151769 in varobj_get_num_children (var=0x8b10410) at
../../../src/binutils/gdb/varobj.c:687
#3  0x08082c13 in mi_cmd_var_list_children (command=0x8b0ff60
"var-list-children", argv=0x8afd2c8, argc=1) at
../../../src/binutils/gdb/mi/mi-cmd-var.c:341
#4  0x08086be1 in mi_cmd_execute (parse=0x8797868) at
../../../src/binutils/gdb/mi/mi-main.c:1243
#5  0x0808660a in captured_mi_execute_command (uiout=0x875c9b8,
data=0xffff8cc0) at ../../../src/binutils/gdb/mi/mi-main.c:1055
#6  0x080e58b2 in catch_exception (uiout=0x875c9b8, func=0x8086583
<captured_mi_execute_command>, func_args=0xffff8cc0, mask=6) at
../../../src/binutils/gdb/exceptions.c:469
#7  0x08086968 in mi_execute_command (cmd=0x8ad4b10
"1928-var-list-children var14.1.tx_thread_name", from_tty=1) at
../../../src/binutils/gdb/mi/mi-main.c:1169
#8  0x08084b20 in mi_execute_command_wrapper (cmd=0x8ad4b10
"1928-var-list-children var14.1.tx_thread_name") at
../../../src/binutils/gdb/mi/mi-interp.c:302
#9  0x080ea7b4 in gdb_readline2 (client_data=0x0) at
../../../src/binutils/gdb/event-top.c:884
#10 0x080e9d9e in stdin_event_handler (error=0, client_data=0x0) at
../../../src/binutils/gdb/event-top.c:432
#11 0x080e8d41 in handle_file_event (event_file_desc=0) at
../../../src/binutils/gdb/event-loop.c:730
#12 0x080e85dd in process_event () at
../../../src/binutils/gdb/event-loop.c:343
#13 0x080e8626 in gdb_do_one_event (data=0x0) at
../../../src/binutils/gdb/event-loop.c:380
#14 0x080e5a83 in catch_errors (func=0x80e85f2 <gdb_do_one_event>,
func_args=0x0, errstring=0x85c2840 "", mask=6) at
../../../src/binutils/gdb/exceptions.c:515
#15 0x080e866a in start_event_loop () at
../../../src/binutils/gdb/event-loop.c:406
#16 0x08084b95 in mi_command_loop (mi_version=2) at
../../../src/binutils/gdb/mi/mi-interp.c:371
#17 0x08084b48 in mi2_command_loop () at
../../../src/binutils/gdb/mi/mi-interp.c:314
#18 0x080e5f56 in current_interp_command_loop () at
../../../src/binutils/gdb/interps.c:275
#19 0x0804d287 in captured_command_loop (data=0x0) at
../../../src/binutils/gdb/main.c:101
#20 0x080e5a83 in catch_errors (func=0x804d27c <captured_command_loop>,
func_args=0x0, errstring=0x8589f6d "", mask=6) at
../../../src/binutils/gdb/exceptions.c:515
#21 0x0804e10d in captured_main (data=0xffff90d0) at
../../../src/binutils/gdb/main.c:826
#22 0x080e5a83 in catch_errors (func=0x804d2bb <captured_main>,
func_args=0xffff90d0, errstring=0x8589f6d "", mask=6) at
../../../src/binutils/gdb/exceptions.c:515
#23 0x0804e143 in gdb_main (args=0xffff90d0) at
../../../src/binutils/gdb/main.c:835
#24 0x0804d278 in main (argc=8, argv=0xffff9174) at
../../../src/binutils/gdb/gdb.c:35

As you can see the segfault is caused by the var having a NULL type. I'm
finding it a little tricky to reliably reproduce this bug but it does
occur quite often, always with the field tx_thread_name which is
actually of type char*.

So should c_number_of_children simply return 0 (or -1) in this case, or
is there some deeper mischief afoot? Could it be triggered by some
faulty debug information?

Cheers,

Robert

Re: Segfault in varobj.c

[Nick Roberts]

Robert Norton writes:
 > Hi,
 > 
 > I encountered a segfault whilst using our port of GDB with Eclipse. It
 > occurs when I add a number of global variables in the variables view and
 > expand them. Occasionally I observe something like the following in the
 > MI console:
 > 
 > (gdb) 
 > 2247-var-list-children
 > var2.tx_ready_next.tx_ready_next.tx_ready_next.tx_suspended_next.tx_thre
 > ad_name
 > warning: Child of parent whose type does not allow children
 > &"warning: Child of parent whose type does not allow children\n"
 > 
 > Followed by gdb segfaulting. On loading the core file I observe:

It might be more useful to set the breakpoint on the line where the initial
warning was issued.

This is your port of GDB and it's based on an old version of FSF GDB.  Does
it happen with FSF GDB or, at least, your port based on up-to-date FSF GDB?


-- 
Nick                                           http://www.inet.net.nz/~nickrob

RE: Segfault in varobj.c

[Robert Norton]

 

> -----Original Message-----
> From: Nick Roberts [mailto:nickrob@snap.net.nz] 
> Sent: 27 July 2007 12:52
> To: Robert Norton
> Cc: gdb@sourceware.org
> Subject: Re: Segfault in varobj.c
> 
> Robert Norton writes:
>  > Hi,
>  > 
>  > I encountered a segfault whilst using our port of GDB with 
> Eclipse. It
>  > occurs when I add a number of global variables in the 
> variables view and
>  > expand them. Occasionally I observe something like the 
> following in the
>  > MI console:
>  > 
>  > (gdb) 
>  > 2247-var-list-children
>  > 
> var2.tx_ready_next.tx_ready_next.tx_ready_next.tx_suspended_ne
> xt.tx_thre
>  > ad_name
>  > warning: Child of parent whose type does not allow children
>  > &"warning: Child of parent whose type does not allow children\n"
>  > 
>  > Followed by gdb segfaulting. On loading the core file I observe:
> 
> It might be more useful to set the breakpoint on the line 
> where the initial
> warning was issued.

Yes. After submitting the post I found where the warning was coming from
and am investigating. I can now reproduce reliably so am distilling down
to a minimal recipe for generating the bug, which hopefully will shed
some light.
 
> This is your port of GDB and it's based on an old version of 
> FSF GDB.  Does
> it happen with FSF GDB or, at least, your port based on 
> up-to-date FSF GDB?

The port is based on GDB 6.6.

Robert

> 
> 
> -- 
> Nick                                           
> http://www.inet.net.nz/~nickrob
> 
> 

RE: Segfault in varobj.c

[Nick Roberts]

 > > This is your port of GDB and it's based on an old version of FSF GDB.
 > > Does it happen with FSF GDB or, at least, your port based on up-to-date
 > > FSF GDB?
 > 
 > The port is based on GDB 6.6.

By up-to-date I meant GDB in CVS.  Presumably you could merge your changes to
that.  It may be that the problem has already been solved or no longer exists
in the repository.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

RE: Segfault in varobj.c

[Robert Norton]

> -----Original Message-----
> From: Nick Roberts [mailto:nickrob@snap.net.nz] 
> Sent: 27 July 2007 13:16
> To: Robert Norton
> Cc: gdb@sourceware.org
> Subject: RE: Segfault in varobj.c
> 
>  > > This is your port of GDB and it's based on an old 
> version of FSF GDB.
>  > > Does it happen with FSF GDB or, at least, your port 
> based on up-to-date
>  > > FSF GDB?
>  > 
>  > The port is based on GDB 6.6.
> 
> By up-to-date I meant GDB in CVS.  Presumably you could merge 
> your changes to
> that.  It may be that the problem has already been solved or 
> no longer exists
> in the repository.

Ah yes, I see there are quite a lot of changes to the varobjs file. In
particular the warning is no longer present. Unfortunately we're not
really in a position to upgrade to fix such a trivial bug, but due to my
analysis below I think the bug might still occur:

Breakpointing in c_type_of_child (now c_describe_child) we end up in the
default case of the switch because the parent has type code
TYPE_CODE_TYPEDEF, so could it be that the switch requires another case
to handle this situation? I'll see if I can come up with a minimal test
binary based on this.

Thanks,

Robert

> -- 
> Nick                                           
> http://www.inet.net.nz/~nickrob
> 
> 

Re: Segfault in varobj.c

[Daniel Jacobowitz]

On Fri, Jul 27, 2007 at 05:52:25AM -0700, Robert Norton wrote:
> Breakpointing in c_type_of_child (now c_describe_child) we end up in the
> default case of the switch because the parent has type code
> TYPE_CODE_TYPEDEF, so could it be that the switch requires another case
> to handle this situation? I'll see if I can come up with a minimal test
> binary based on this.

No, that won't happen any more.  See get_value_type.

-- 
Daniel Jacobowitz
CodeSourcery