This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: lazily call save_current_space_and_thread
On Tuesday 08 March 2011 17:49:29, Tom Tromey wrote:
> Pedro> I'm guessing you're trying all-stop. In non-stop, I _think_
> Pedro> you'll much more rarely see a NULL selected frame here.
>
> Nope, I do this before my test:
>
> set target-async on
> set schedule-multiple on
> set pagination off
> set detach-on-fork off
> set non-stop on
Okay. In any case, what I was aluding to, is that
in non-stop mode gdb is making sure the user selected
frame is constant between events (fetch_inferior_event),
so in that case, there's a selected frame to restore back
to. But thinking a bit more, that obviously doesn't matter
because if the user had a frame selected, then the debug info
for that frame has already been read anyway, and there's nothing
to optimize.
> I can't say that I understand everything that happens in this mode.
>
> "run" appears to work in the background, which is mysterious to me.
Hmm. It shouldn't. Well, behind the scenes it does run
asynchronously, but only "run&" should work in the background,
from the user's perpective.
Boo, something's seriously broken :-/ :
[Thread debugging using libthread_db enabled]
process 2857 is executing new program: /usr/bin/iconv
Error in re-setting breakpoint 1: Cannot access memory at address 0x45e22a
Error in re-setting breakpoint 2: Cannot access memory at address 0x4e2e5a
warning: Error removing breakpoint 1
warning: Error removing breakpoint 2
warning: Error removing breakpoint 1
warning: Error removing breakpoint 2
warning: Error removing breakpoint 1
warning: Error removing breakpoint 2
warning: Error removing breakpoint 1
warning: Error removing breakpoint 2
warning: Error removing breakpoint 1
...
I suspect it's related to spawning iconv (or rather, that's
triggering some bug).
>
> And, if I C-c gdb, I just get "Quit." back,
That just means you have the prompt, and the inferior is either
backgrounded, or not running at all. To interrupt the target
in async/non-stop modes, we use "interrupt", not C-c.
> and then gdb is in a weird
> state (I can't "continue" any inferior and if I try "run" I get an
> internal error).
>
> I am planning to debug these next; but if you know what is going on
> already...
Can't say I do.
--
Pedro Alves