* Canceling a long running gdb/mi command @ 2023-07-24 8:58 Dmitry Neverov 2023-07-26 16:11 ` Tom Tromey 0 siblings, 1 reply; 4+ messages in thread From: Dmitry Neverov @ 2023-07-24 8:58 UTC (permalink / raw) To: gdb [-- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Canceling a long running gdb/mi command 2023-07-24 8:58 Canceling a long running gdb/mi command Dmitry Neverov @ 2023-07-26 16:11 ` Tom Tromey 2023-07-28 10:02 ` Dmitry Neverov 0 siblings, 1 reply; 4+ messages in thread From: Tom Tromey @ 2023-07-26 16:11 UTC (permalink / raw) To: Dmitry Neverov via Gdb; +Cc: Dmitry Neverov >>>>> "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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Canceling a long running gdb/mi command 2023-07-26 16:11 ` Tom Tromey @ 2023-07-28 10:02 ` Dmitry Neverov 2023-07-28 20:50 ` Tom Tromey 0 siblings, 1 reply; 4+ messages in thread From: Dmitry Neverov @ 2023-07-28 10:02 UTC (permalink / raw) To: Tom Tromey; +Cc: Dmitry Neverov via Gdb [-- 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Canceling a long running gdb/mi command 2023-07-28 10:02 ` Dmitry Neverov @ 2023-07-28 20:50 ` Tom Tromey 0 siblings, 0 replies; 4+ messages in thread From: Tom Tromey @ 2023-07-28 20:50 UTC (permalink / raw) To: Dmitry Neverov; +Cc: Tom Tromey, Dmitry Neverov via Gdb 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-07-28 20:50 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-07-24 8:58 Canceling a long running gdb/mi command Dmitry Neverov 2023-07-26 16:11 ` Tom Tromey 2023-07-28 10:02 ` Dmitry Neverov 2023-07-28 20:50 ` Tom Tromey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).