From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115072 invoked by alias); 19 Jun 2019 15:54:36 -0000 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 Received: (qmail 115060 invoked by uid 89); 19 Jun 2019 15:54:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-18.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Jun 2019 15:54:33 +0000 Received: from [172.16.0.120] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1121A1E7CE; Wed, 19 Jun 2019 11:54:31 -0400 (EDT) Subject: Re: MI commands with --thread (--frame?) do not preserve user selected thread / frame To: Jan Vrany , gdb@sourceware.org References: <5df1c9d79778a5d6703bba442031b5a1bbeda141.camel@fit.cvut.cz> <3b34a5e356a75454b6b7903048c0d62a409673d5.camel@fit.cvut.cz> From: Simon Marchi Message-ID: <8b3e78c4-fd5d-598e-4dcf-712807102072@simark.ca> Date: Wed, 19 Jun 2019 15:54:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <3b34a5e356a75454b6b7903048c0d62a409673d5.camel@fit.cvut.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-06/txt/msg00057.txt.bz2 On 2019-06-19 11:10 a.m., Jan Vrany wrote: > On Wed, 2019-06-19 at 11:53 +0100, Jan Vrany wrote: >> Hi, >> >> I was debugging a multithreaded program and realized that using --thread option to >> verious MI command silently changes user selected thread - here's an example using >> separate UI and CLI chahhel (tested on commit 6f5601c4d0) >> >> > ... >> >> >> As you can see, there was no `frame`, `thread`, `-select-frame` or `-thread-select` command between >> first and second info thread / frame commands on CLI, yet the selected thread / frame changed (silently). >> >> Is this intended behavior? If so what's the rationale? No, this is indeed a known bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20684 > Simple patch that preserves user selected context: > > --- > > diff --git a/gdb/mi/mi-main.c b/gdb/mi/mi-main.c > index 13c310d494..ac3969f1b4 100644 > --- a/gdb/mi/mi-main.c > +++ b/gdb/mi/mi-main.c > @@ -2060,6 +2060,7 @@ mi_cmd_execute (struct mi_parse *parse) > set_current_program_space (inf->pspace); > } > > + gdb::optional thread_saver; > if (parse->thread != -1) > { > thread_info *tp = find_thread_global_id (parse->thread); > @@ -2070,9 +2071,11 @@ mi_cmd_execute (struct mi_parse *parse) > if (tp->state == THREAD_EXITED) > error (_("Thread id: %d has terminated"), parse->thread); > > + thread_saver.emplace (); > switch_to_thread (tp); > } > > + gdb::optional frame_saver; > if (parse->frame != -1) > { > struct frame_info *fid; > @@ -2080,8 +2083,11 @@ mi_cmd_execute (struct mi_parse *parse) > > fid = find_relative_frame (get_current_frame (), &frame); > if (frame == 0) > - /* find_relative_frame was successful */ > - select_frame (fid); > + { > + /* find_relative_frame was successful */ > + frame_saver.emplace (); > + select_frame (fid); > + } > else > error (_("Invalid frame id: %d"), frame); > } > This is what I get: i th &"i th\n" ~" Id Target Id Frame \n" ~"* 1 Thread 0x7f792bce6e40 (LWP 4439) \"gnome-calculato\" 0x00007f7929316bf9 in poll () from /lib/x86_64-linux-gnu/libc.so.6\n" ~" 2 Thread 0x7f791d00b700 (LWP 4441) \"gmain\" 0x00007f7929316bf9 in poll () from /lib/x86_64-linux-gnu/libc.so.6\n" ~" 3 Thread 0x7f791c80a700 (LWP 4442) \"gdbus\" 0x00007f7929316bf9 in poll () from /lib/x86_64-linux-gnu/libc.so.6\n" ~" 4 Thread 0x7f7917981700 (LWP 4443) \"dconf worker\" 0x00007f7929316bf9 in poll () from /lib/x86_64-linux-gnu/libc.so.6\n" ^done (gdb) -stack-info-depth --thread 3 ^done,depth="7" ~"[Switching to thread 1 (Thread 0x7f792bce6e40 (LWP 4439))]\n" ~"#0 0x00007f7929316bf9 in poll () from /lib/x86_64-linux-gnu/libc.so.6\n" =thread-selected,id="1",frame={level="0",addr="0x00007f7929316bf9",func="poll",args=[],from="/lib/x86_64-linux-gnu/libc.so.6",arch="i386:x86-64"} (gdb) i th &"i th\n" ~" Id Target Id Frame \n" ~"* 1 Thread 0x7f792bce6e40 (LWP 4439) \"gnome-calculato\" 0x00007f7929316bf9 in poll () from /lib/x86_64-linux-gnu/libc.so.6\n" ~" 2 Thread 0x7f791d00b700 (LWP 4441) \"gmain\" 0x00007f7929316bf9 in poll () from /lib/x86_64-linux-gnu/libc.so.6\n" ~" 3 Thread 0x7f791c80a700 (LWP 4442) \"gdbus\" 0x00007f7929316bf9 in poll () from /lib/x86_64-linux-gnu/libc.so.6\n" ~" 4 Thread 0x7f7917981700 (LWP 4443) \"dconf worker\" 0x00007f7929316bf9 in poll () from /lib/x86_64-linux-gnu/libc.so.6\n" ^done (gdb) So it seems to work (at least for a simple case, there might be some edge cases I don't recall). I think that the CLI and MI events about the thread change should not appear though, since the goal is to make it appear as if there is no user selection changes. Simon