From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11727 invoked by alias); 17 Nov 2005 19:36:58 -0000 Received: (qmail 11616 invoked by uid 22791); 17 Nov 2005 19:36:55 -0000 Received: from fra-del-02.spheriq.net (HELO fra-del-02.spheriq.net) (195.46.51.98) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 17 Nov 2005 19:36:55 +0000 Received: from fra-out-02.spheriq.net (fra-out-02.spheriq.net [195.46.51.130]) by fra-del-02.spheriq.net with ESMTP id jAHJapDT032691 for ; Thu, 17 Nov 2005 19:36:51 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-02.spheriq.net with ESMTP id jAHJaou9004670 for ; Thu, 17 Nov 2005 19:36:51 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-01.spheriq.net with ESMTP id jAHJakUv017350 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 17 Nov 2005 19:36:49 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 838F1DA4D; Thu, 17 Nov 2005 19:36:45 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 76BBC475A0; Thu, 17 Nov 2005 19:22:38 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 357B075994; Thu, 17 Nov 2005 19:22:38 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id B70344758F; Thu, 17 Nov 2005 19:22:37 +0000 (GMT) Received: from [164.129.15.13] (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.5.8-GR) with ESMTP id CGZ47959 (AUTH "andrew stubbs"); Thu, 17 Nov 2005 19:19:37 GMT Message-ID: <437CD72D.70104@st.com> Date: Thu, 17 Nov 2005 19:53:00 -0000 From: Andrew STUBBS User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: MI problem References: <4378DDB4.3020702@st.com> <20051117042008.GE3513@nevyn.them.org> In-Reply-To: <20051117042008.GE3513@nevyn.them.org> Content-Type: multipart/mixed; boundary="------------040001000505050202080506" X-O-Spoofed: Not Scanned X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 4.1.07 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00299.txt.bz2 This is a multi-part message in MIME format. --------------040001000505050202080506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 2051 Daniel Jacobowitz wrote: > The interesting question isn't where it gets switched, but where we're > expecting the wrong contents. If we're accessing uiout.data->buffer > then we must have reached mi_out_put. So where from, and how did we > get there without switching the global uiout back to MI's? > mi_cmd_interpreter_exec ought to be doing that on the way out. This is the backtrace from the core dump file: #0 0x0805a220 in ui_file_put (file=0x19, write=0x80863f8 , dest=0xa030f18) at ../../src/gdb/ui-file.c:192 #1 0x0808642a in mi_out_put (uiout=0xa028b90, stream=0xa030f18) at ../../src/gdb/mi/mi-out.c:376 #2 0x0808adc9 in mi_load_progress (section_name=0xa11f79f ".init", sent_so_far=54, total_section=54, total_sent=54, grand_total=523177) at ../../src/gdb/mi/mi-main.c:1402 #3 0x080c4857 in load_section_callback (abfd=0xa0a5278, asec=0x36, data=0xbfffb930) at ../../src/gdb/symfile.c:1597 #4 0x0818c69d in bfd_map_over_sections (abfd=0xa0a5278, operation=0x80c4670 , user_storage=0xbfffb930) at ../../src/bfd/section.c:1226 #5 0x080c4a17 in generic_load (args=0xbfffb930 "", from_tty=1) at ../../src/gdb/symfile.c:1670 #6 0x080edf1f in target_load (arg=0xa0322b0 "/home/afra/users/stubbsa/os21test-microdev", from_tty=1) at ../../src/gdb/target.c:268 mi_load_progress is actually called through the function pointer deprecated_show_load_progress. The problem appears to be that the program is finding it's way into the MI through deprecated_show_load_progress when uiout is not set as expected. The problem only occurs in -i=mi (no number) and -i=mi1 because mi_load_progress does not do anything in other versions. Strangely -i=mi is supposed to be the same as -i=mi2, but it isn't in this respect. I attach a patch which fixes both the crash and the inconsistency. I have tested it and got no unexpected failures. Of course I doubt the testsuite covers this feature ... OK? I would like to see this issued fixed in 6.4 also. Andrew Stubbs --------------040001000505050202080506 Content-Type: text/plain; name="mi-load-crash.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mi-load-crash.patch" Content-length: 1276 2005-11-17 Andrew Stubbs * mi/mi-main.c (mi_load_progress): Don't do anything for -i=mi. Ensure the use of mi1 uiout for the duration of the function. Index: src/gdb/mi/mi-main.c =================================================================== --- src.orig/gdb/mi/mi-main.c 2005-06-13 23:21:57.000000000 +0100 +++ src/gdb/mi/mi-main.c 2005-11-17 18:58:45.000000000 +0000 @@ -1365,11 +1365,17 @@ mi_load_progress (const char *section_na static struct timeval last_update; static char *previous_sect_name = NULL; int new_section; + struct ui_out *saved_uiout; - if (!current_interp_named_p (INTERP_MI) - && !current_interp_named_p (INTERP_MI1)) + if (!current_interp_named_p (INTERP_MI1)) return; + /* This function is called through deprecated_show_load_progress + which means uiout may not be correct. Fix it for the duration + of this function. */ + saved_uiout = uiout; + uiout = mi_out_new (1); + update_threshold.tv_sec = 0; update_threshold.tv_usec = 500000; gettimeofday (&time_now, NULL); @@ -1424,6 +1430,9 @@ mi_load_progress (const char *section_na fputs_unfiltered ("\n", raw_stdout); gdb_flush (raw_stdout); } + + xfree (uiout); + uiout = saved_uiout; } void --------------040001000505050202080506--