From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 470 invoked by alias); 8 Aug 2003 18:13:14 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 462 invoked from network); 8 Aug 2003 18:13:13 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 8 Aug 2003 18:13:13 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h78IDDt09814 for ; Fri, 8 Aug 2003 14:13:13 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h78IDCx15241 for ; Fri, 8 Aug 2003 14:13:13 -0400 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h78IDB717940; Fri, 8 Aug 2003 14:13:12 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 76BBE2CB33; Fri, 8 Aug 2003 14:20:50 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16179.59905.880712.656312@localhost.redhat.com> Date: Fri, 08 Aug 2003 18:13:00 -0000 To: Michael Elizabeth Chastain Cc: ac131313@redhat.com, gdb@sources.redhat.com Subject: Re: gdb crash with -i=mi2 In-Reply-To: <200308081712.h78HCqKM015964@duracef.shout.net> References: <200308081712.h78HCqKM015964@duracef.shout.net> X-SW-Source: 2003-08/txt/msg00119.txt.bz2 Try this as a workaround, seems to work for me: Index: mi-interp.c =================================================================== RCS file: /cvs/uberbaum/gdb/mi/mi-interp.c,v retrieving revision 1.5 diff -u -p -r1.5 mi-interp.c --- mi-interp.c 7 Aug 2003 17:47:42 -0000 1.5 +++ mi-interp.c 8 Aug 2003 18:12:49 -0000 @@ -409,7 +409,7 @@ _initialize_mi_interp (void) /* The various interpreter levels. */ interp_add (interp_new (INTERP_MI1, NULL, mi_out_new (1), &procs)); - interp_add (interp_new (INTERP_MI2, NULL, mi_out_new (2), &procs)); + /*interp_add (interp_new (INTERP_MI2, NULL, mi_out_new (2), &procs));*/ interp_add (interp_new (INTERP_MI3, NULL, mi_out_new (3), &procs)); /* "mi" selects the most recent released version. "mi2" was Michael Elizabeth Chastain writes: > The new mi2 tests are bombing out big time for me! > > % gdb -i=mi2 > Segmentation fault (core dumped) > > Here is a backtrace. > > #0 0x080c6e2a in interp_set (interp=0x0) > at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/interps.c:160 > #1 0x080c6ee5 in interp_set (interp=0x82a1bc8) > at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/interps.c:186 > #2 0x08077d69 in captured_main (data=0x0) > at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/main.c:582 > #3 0x0810cd91 in do_catch_errors (uiout=0x8261fa0, data=0x1) > at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:497 > #4 0x0810ccc0 in catcher (func=0x810cd80 , > func_uiout=0x8261fa0, func_args=0xbffff7d0, func_val=0xbffff7c8, > func_caught=0xbffff7cc, errstring=0x1
, mask=6) > at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:429 > #5 0x0810cdea in catch_errors (func=0x1, func_args=0x1, > errstring=0x1
, mask=1) > at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:509 > #6 0x08078591 in gdb_main (args=0x829b5c0) > at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/main.c:820 > #7 0x0807772e in main (argc=1, argv=0x1) > at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/gdb.c:35 > #8 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 > > This happens with: > > gdb HEAD 2003-08-07 20:28:13 UTC > > It also happens with: > > gdb HEAD 2003-08-07 20:31:55 UTC > > native i686-pc-linux-gnu, red hat linux 8. > gdb built with gcc 3.3, binutils 2.14. > > It's happening in this code: > > 180 /* Clear out any installed interpreter hooks/event handlers. */ > 181 clear_interpreter_hooks (); > 182 > 183 if (interp->procs->resume_proc != NULL > 184 && (!interp->procs->resume_proc (interp->data))) > 185 { > 186 if (!interp_set (old_interp)) > 187 internal_error (__FILE__, __LINE__, > 188 "Failed to initialize new interp \"%s\" %s", > 189 interp->name, "and could not restore old interp! > \n"); > > This is calling interp_set recursively with old_interp=0x0 > (as shown in the stack trace). > > Michael C