This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Segfault in varobj.c


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]