Canceling a long running gdb/mi command

Canceling a long running gdb/mi command

[Dmitry Neverov]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

Is there a way to interrupt (cancel) a long running gdb/mi command?
Similar to what happens on Ctrl-C when gdb owns a terminal.

-- 
Dmitrii Neverov
JetBrains GmbH
Christoph-Rapparini-Bogen 23
80639 München
Handelsregister: Amtsgericht München, HRB 187151
Geschäftsführer: Olga Dyka

Re: Canceling a long running gdb/mi command

[Tom Tromey]

>>>>> "Dmitry" == Dmitry Neverov via Gdb <gdb@sourceware.org> writes:

Dmitry> Is there a way to interrupt (cancel) a long running gdb/mi command?
Dmitry> Similar to what happens on Ctrl-C when gdb owns a terminal.

I am not 100% sure about this but I think you can just send a SIGINT to
gdb.

Tom

Re: Canceling a long running gdb/mi command

[Dmitry Neverov]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

I've tried to send SIGINT before asking and got an impression
that it doesn't cancel the gdb/mi command.

I was wrong, it works, but one might need to send several
SIGINTs. In my case, the first exception thrown by quit() was
caught and ignored in cp-support.c replace_typedefs(), and the
gdb/mi command continued running. The second one was caught
and handled in cp-support.c inspect_type() which made a slow
-var_list_children command to complete.

This also happens in a terminal, sometimes more than one Ctrl-C is
needed to cancel a command.

Is it by design and clients should send SIGINTs repeatedly?

Do I understand correctly, that it is safe to send a SIGINT when
no gdb/mi command is running? Meaning it won't terminate
gdb. I've tried and it works, but maybe I was lucky.

Re: Canceling a long running gdb/mi command

[Tom Tromey]

Dmitry> I was wrong, it works, but one might need to send several
Dmitry> SIGINTs. In my case, the first exception thrown by quit() was
Dmitry> caught and ignored in cp-support.c replace_typedefs(), and the
Dmitry> gdb/mi command continued running. The second one was caught 
Dmitry> and handled in cp-support.c inspect_type() which made a slow
Dmitry> -var_list_children command to complete.

Catching and ignoring like that seems bad.  IMO only non-QUIT exceptions
should be caught in this way, at least in most places.

I see a lot of violations of this idea though -- grep says 282.  So that
is not good.  Though on reflection, not all of these are really
incorrect, because the 'try' block may not end up calling QUIT.

Fixing this seems like a bit of a pain.  Probably some of those catches
really should handle QUIT as well.  Also it seems like some kind of
region-based QUIT suppression has to be done, because there are parts of
gdb that can't really be QUIT from (e.g., the DWARF reader is basically
unprepared for this).

I wonder whether varobj can really handle interruption.
That code is pretty hard to work on... anyway it would be interesting to
see a stack trace from your scenario.

Dmitry> Is it by design and clients should send SIGINTs repeatedly?

No.

Dmitry> Do I understand correctly, that it is safe to send a SIGINT when
Dmitry> no gdb/mi command is running? Meaning it won't terminate
Dmitry> gdb. I've tried and it works, but maybe I was lucky.

Yes, I think this should be fine.  However, if the inferior is running,
I think it may cause an inferior stop.

Tom