From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16616 invoked by alias); 14 Nov 2005 18:58:32 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 16516 invoked by uid 22791); 14 Nov 2005 18:58:28 -0000 Received: from lon-del-01.spheriq.net (HELO lon-del-01.spheriq.net) (195.46.50.97) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 14 Nov 2005 18:58:28 +0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-01.spheriq.net with ESMTP id jAEIwPSB029246 for ; Mon, 14 Nov 2005 18:58:25 GMT Received: from lon-cus-01.spheriq.net (lon-cus-01.spheriq.net [195.46.50.37]) by lon-out-01.spheriq.net with ESMTP id jAEIwPWZ008859 for ; Mon, 14 Nov 2005 18:58:25 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-01.spheriq.net with ESMTP id jAEIwOBn027512 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 14 Nov 2005 18:58:24 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 EA8BDDA41 for ; Mon, 14 Nov 2005 18:58:19 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id C30CC4760E; Mon, 14 Nov 2005 19:01:17 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 8D7B475969 for ; Mon, 14 Nov 2005 19:01:17 +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 C00C0472F2 for ; Mon, 14 Nov 2005 19:01:16 +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 CGZ22371 (AUTH "andrew stubbs"); Mon, 14 Nov 2005 18:58:17 GMT Message-ID: <4378DDB4.3020702@st.com> Date: Mon, 14 Nov 2005 18:58:00 -0000 From: Andrew STUBBS User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: GDB List Subject: MI problem Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2005-11/txt/msg00272.txt.bz2 Hi all, When I run GDB with -i=mi1 I get a segmentation fault while running the 'load' command. (-i=mi2 works fine.) The fault occurs in ui_file_put() due to 'file' having no useful value. This value is taken from uiout.data->buffer (MI version of data). I have traced the 'source' of this rogue data to cli_interpreter_exec() which passes cli_uiout to safe_execute_command() which calls exceptions_state_mc_init() which changes the global uiout. The MI seems to be calling the CLI to interpret the 'load' command, but the CLI then clashes with the MI I/O routines causing the fault, in this case under generic_load(). Here is a backtrace from where the uiout gets switched: #0 exceptions_state_mc_init (func_uiout=0x94034f8, exception=0xbfff93c0, mask=155202808) at ../../src/gdb/exceptions.c:102 #1 0x080da1f8 in catch_exception (uiout=0x93f9b90, func=0x8085dac , func_args=0xbfff9418, mask=6) at ../../src/gdb/exceptions.c:467 #2 0x08085df1 in safe_execute_command (uiout=0x93f9b90, command=0x94034f8 "\002", from_tty=155202808) at ../../src/gdb/cli/cli-interp.c:132 #3 0x08085d7e in cli_interpreter_exec (data=0x0, command_str=0x83f8a40 "") at ../../src/gdb/cli/cli-interp.c:112 #4 0x080da86a in interp_exec (interp=0x83f8a40, command_str=0x9403380 "load") at ../../src/gdb/interps.c:313 #5 0x08088cfd in mi_cmd_interpreter_exec ( command=0x8314ac4 "-interpreter-exec", argv=0xbfff9520, argc=2) at ../../src/gdb/mi/mi-interp.c:242 #6 0x0808a393 in captured_mi_execute_command (uiout=0x93fa180, data=0xbfff95b0) at ../../src/gdb/mi/mi-main.c:1110 #7 0x080da226 in catch_exception (uiout=0x93fa180, func=0x808a338 , func_args=0xbfff95b0, mask=6) at ../../src/gdb/exceptions.c:469 #8 0x0808a5e0 in mi_execute_command (cmd=0x947e7f0 "\001", from_tty=1) at ../../src/gdb/mi/mi-main.c:1157 #9 0x08088e60 in mi_execute_command_wrapper (cmd=0x94c21d0 "load") at ../../src/gdb/mi/mi-interp.c:300 #10 0x080de108 in gdb_readline2 (client_data=0x0) at ../../src/gdb/event-top.c:873 #11 0x080dd7ee in stdin_event_handler (error=0, client_data=0x94034f8) at ../../src/gdb/event-top.c:424 #12 0x080dcb54 in handle_file_event (event_file_desc=138381888) at ../../src/gdb/event-loop.c:728 #13 0x080dc698 in process_event () at ../../src/gdb/event-loop.c:341 #14 0x080dc6e0 in gdb_do_one_event (data=0x0) at ../../src/gdb/event-loop.c:378 #15 0x080da3af in catch_errors (func=0x80dc6b0 , func_args=0x0, errstring=0x8307576 "", mask=6) at ../../src/gdb/exceptions.c:515 #16 0x080dc703 in start_event_loop () at ../../src/gdb/event-loop.c:404 #17 0x08088e71 in mi1_command_loop () at ../../src/gdb/mi/mi-interp.c:306 #18 0x080da7e2 in current_interp_command_loop () at ../../src/gdb/interps.c:275 #19 0x08050cdb in captured_command_loop (data=0x0) at ../../src/gdb/main.c:101 #20 0x080da3af in catch_errors (func=0x8050cd0 , func_args=0x0, errstring=0x8307576 "", mask=6) at ../../src/gdb/exceptions.c:515 #21 0x08051882 in captured_main (data=0x1) at ../../src/gdb/main.c:839 #22 0x080da3af in catch_errors (func=0x8050d08 , func_args=0xbfff9940, errstring=0x8307576 "", mask=6) at ../../src/gdb/exceptions.c:515 #23 0x080519d3 in gdb_main (args=0x83f8a40) at ../../src/gdb/main.c:848 #24 0x08050ccb in main (argc=155202808, argv=0x94034f8) at ../../src/gdb/gdb.c:35 The GDB simulator does not use generic_load() so that works fine, but as far as I can tell it should be possible to reproduce the problem using 'target remote'. However, I have no suitable targets with which to test this. I am using generic_load() from a custom target interface, but I do not think this is causing the problem. It worked fine for GDB 6.3. Could somebody with a 'remote' target please try to reproduce it? I'm really not sure where the problem actually is. I don't think it is related to generic_load() per se. That just happens to be where I see the problem. Is it the CLI that is wrong, or the MI or even the exception handling stuff? BTW, The three versions of 'struct ui_out_data' are very confusing. There is no way (I can see) to get GDB (when being used to debug GDB) to print the right one anywhere other than the specific file in which it is defined. Everywhere else it just selects one hopes it is right. It would be better if they were named differently and then typedefed to the same - then one could cast to the right thing and print them properly. Of course a union would be even less confusing ... Thanks, any help appreciated. If I sound confused it is because I am :(