From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24282 invoked by alias); 27 Jul 2007 11:02:53 -0000 Received: (qmail 24273 invoked by uid 22791); 27 Jul 2007 11:02:52 -0000 X-Spam-Check-By: sourceware.org Received: from mms2.broadcom.com (HELO mms2.broadcom.com) (216.31.210.18) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Jul 2007 11:02:46 +0000 Received: from [10.10.64.154] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.1)); Fri, 27 Jul 2007 04:02:34 -0700 X-Server-Uuid: A6C4E0AE-A7F0-449F-BAE7-7FA0D737AC76 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id BCBAB2B1; Fri, 27 Jul 2007 04:02:34 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id A92282B0 for ; Fri, 27 Jul 2007 04:02:34 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id FMV51342; Fri, 27 Jul 2007 04:02:34 -0700 (PDT) Received: from NT-IRVA-0752.brcm.ad.broadcom.com ( nt-irva-0752.brcm.ad.broadcom.com [10.8.194.67]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 6958069CA4 for ; Fri, 27 Jul 2007 04:02:34 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Segfault in varobj.c Date: Fri, 27 Jul 2007 11:51:00 -0000 Message-ID: From: "Robert Norton" To: gdb@sourceware.org X-WSS-ID: 6AB70F403DG14595801-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-07/txt/msg00190.txt.bz2 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)=20 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=3D0x8b10410) at ../../../src/binutils/gdb/varobj.c:1764 1764 switch (TYPE_CODE (type)) (gdb) list 1759 1760 type =3D get_type (var); 1761 target =3D get_target_type (type); 1762 children =3D 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) !=3D BOUND_CANNOT_BE_DETERMINED) (gdb) p type $1 =3D (struct type *) 0x0 (gdb) p *var $3 =3D {name =3D 0x8ad1f08 "*tx_thread_name", obj_name =3D 0x8ad6b70 "var14.1.tx_thread_name.*tx_thread_name", index =3D 0, type =3D 0x0, value = =3D 0x0, error =3D 0, num_children =3D -1, parent =3D 0x8ab1f90, children =3D 0x0, root =3D 0x8ad97a0, format =3D FORMAT_NATURAL, updated =3D 0} (gdb) bt #0 0x08152df9 in c_number_of_children (var=3D0x8b10410) at ../../../src/binutils/gdb/varobj.c:1764 #1 0x08152acf in number_of_children (var=3D0x8b10410) at ../../../src/binutils/gdb/varobj.c:1587 #2 0x08151769 in varobj_get_num_children (var=3D0x8b10410) at ../../../src/binutils/gdb/varobj.c:687 #3 0x08082c13 in mi_cmd_var_list_children (command=3D0x8b0ff60 "var-list-children", argv=3D0x8afd2c8, argc=3D1) at ../../../src/binutils/gdb/mi/mi-cmd-var.c:341 #4 0x08086be1 in mi_cmd_execute (parse=3D0x8797868) at ../../../src/binutils/gdb/mi/mi-main.c:1243 #5 0x0808660a in captured_mi_execute_command (uiout=3D0x875c9b8, data=3D0xffff8cc0) at ../../../src/binutils/gdb/mi/mi-main.c:1055 #6 0x080e58b2 in catch_exception (uiout=3D0x875c9b8, func=3D0x8086583 , func_args=3D0xffff8cc0, mask=3D6) at ../../../src/binutils/gdb/exceptions.c:469 #7 0x08086968 in mi_execute_command (cmd=3D0x8ad4b10 "1928-var-list-children var14.1.tx_thread_name", from_tty=3D1) at ../../../src/binutils/gdb/mi/mi-main.c:1169 #8 0x08084b20 in mi_execute_command_wrapper (cmd=3D0x8ad4b10 "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=3D0x0) at ../../../src/binutils/gdb/event-top.c:884 #10 0x080e9d9e in stdin_event_handler (error=3D0, client_data=3D0x0) at ../../../src/binutils/gdb/event-top.c:432 #11 0x080e8d41 in handle_file_event (event_file_desc=3D0) 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=3D0x0) at ../../../src/binutils/gdb/event-loop.c:380 #14 0x080e5a83 in catch_errors (func=3D0x80e85f2 , func_args=3D0x0, errstring=3D0x85c2840 "", mask=3D6) 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=3D2) 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=3D0x0) at ../../../src/binutils/gdb/main.c:101 #20 0x080e5a83 in catch_errors (func=3D0x804d27c , func_args=3D0x0, errstring=3D0x8589f6d "", mask=3D6) at ../../../src/binutils/gdb/exceptions.c:515 #21 0x0804e10d in captured_main (data=3D0xffff90d0) at ../../../src/binutils/gdb/main.c:826 #22 0x080e5a83 in catch_errors (func=3D0x804d2bb , func_args=3D0xffff90d0, errstring=3D0x8589f6d "", mask=3D6) at ../../../src/binutils/gdb/exceptions.c:515 #23 0x0804e143 in gdb_main (args=3D0xffff90d0) at ../../../src/binutils/gdb/main.c:835 #24 0x0804d278 in main (argc=3D8, argv=3D0xffff9174) 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