[RFA/RFC] QUIT doesn't seem to be working !?

[RFA/RFC] QUIT doesn't seem to be working !?

[Joel Brobecker]

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

Hello,

it's bizarre, we noticed that we were unable to interrupt certain
commands that can be time greedy. For instance, when messing up in the
addresses given to the "disass" command, it can take GDB a loooooong
time to print all instructions. Unexpectedly, hitting Control-C did not
interrupt the command.

I see in disassemble_command() that there is a call to QUIT in the while
loop that prints all instructions. But this macro tests for quit_flag
to see if we should stop now or not. However, handle_sigint() does
not set this flag when Control-C is pressed, unless immediate_quit is
set. But immediate_quit is not really what we are looking for, because
it tells GDB that SIGINT events should be processed immediately, which
obviously means that GDB does not wait for the next call to QUIT to
perform the abortion.

So far, what handle_sigint() does is set the "ready" flag in GDB's
SIGINT async signal handler. This flag seems to take effect only
at the top-level loop level. So in our case, its effect arrives too
late.

So I couldn't understand how QUIT was working....

I applied the following change, which allows GDB to aboart at QUIT
points if the user has pressed C-c. But I feel like I'm missing
something...

2003-08-12  J. Brobecker  <brobecker@gnat.com>

        * event-top.c (handle_sigint): Set quit_flag.

Comments? Ok to apply?

-- 
Joel

[-- Attachment #2: event-top.c.diff --]
[-- Type: text/plain, Size: 974 bytes --]

Index: event-top.c
===================================================================
RCS file: /nile.c/cvs/Dev/gdb/gdb-5.3/gdb/event-top.c,v
retrieving revision 1.1
diff -u -p -r1.1 event-top.c
--- event-top.c	16 Jan 2003 09:46:22 -0000	1.1
+++ event-top.c	12 Aug 2003 21:27:57 -0000
@@ -967,9 +967,14 @@ handle_sigint (int sig)
   if (immediate_quit)
     async_request_quit (0);
   else
-    /* If immediate quit is not set, we process SIGINT the next time
-       through the loop, which is fine. */
-    mark_async_signal_handler_wrapper (sigint_token);
+    {
+      /* If immediate quit is not set, we process SIGINT the next time
+         through the loop, which is fine. */
+      mark_async_signal_handler_wrapper (sigint_token);
+      /* We can also process the signal at certain specific locations
+         which are explicitely marked by a call to QUIT.  */
+      quit_flag = 1;
+    }
 }
 
 /* Do the quit. All the checks have been done by the caller. */

Re: [RFA/RFC] QUIT doesn't seem to be working !?

[Daniel Jacobowitz]

On Tue, Aug 12, 2003 at 03:22:11PM -0700, Joel Brobecker wrote:
> Hello,
> 
> it's bizarre, we noticed that we were unable to interrupt certain
> commands that can be time greedy. For instance, when messing up in the
> addresses given to the "disass" command, it can take GDB a loooooong
> time to print all instructions. Unexpectedly, hitting Control-C did not
> interrupt the command.
> 
> I see in disassemble_command() that there is a call to QUIT in the while
> loop that prints all instructions. But this macro tests for quit_flag
> to see if we should stop now or not. However, handle_sigint() does
> not set this flag when Control-C is pressed, unless immediate_quit is
> set. But immediate_quit is not really what we are looking for, because
> it tells GDB that SIGINT events should be processed immediately, which
> obviously means that GDB does not wait for the next call to QUIT to
> perform the abortion.
> 
> So far, what handle_sigint() does is set the "ready" flag in GDB's
> SIGINT async signal handler. This flag seems to take effect only
> at the top-level loop level. So in our case, its effect arrives too
> late.
> 
> So I couldn't understand how QUIT was working....
> 
> I applied the following change, which allows GDB to aboart at QUIT
> points if the user has pressed C-c. But I feel like I'm missing
> something...
> 
> 2003-08-12  J. Brobecker  <brobecker@gnat.com>
> 
>         * event-top.c (handle_sigint): Set quit_flag.
> 
> Comments? Ok to apply?

I see two functions which are intended to handle SIGINT.  One of them
is handle_sigint; the other is request_quit.  If event_loop_p, we use
the async version, which does not quit immediately.  This is the case
unless gdb is started with --noasync.

The comments in handle_sigint suggest that deferring the C-c to the
next time through the event loop is desired behavior.  I'm not entirely
sure why.  It loses the use of the QUIT macro entirely.  There's a
whole lot of complicated async infrastructure in event-top.c and
event-loop.c but it seems that the async handlers are never called
except from gdb_do_one_event, and I don't see any actual asynchronous
way of getting there.

Elena seems to have written most of this code.  She might have a better
idea of how this is supposed to work - and conveniently, she's listed
as its maintainer, too :)

I suspect your patch is right, but I don't know if some additional
cleanup is required for the asynchronous signal handlers, to prevent
the quit from being processed twice.

> Index: event-top.c
> ===================================================================
> RCS file: /nile.c/cvs/Dev/gdb/gdb-5.3/gdb/event-top.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 event-top.c
> --- event-top.c	16 Jan 2003 09:46:22 -0000	1.1
> +++ event-top.c	12 Aug 2003 21:27:57 -0000
> @@ -967,9 +967,14 @@ handle_sigint (int sig)
>    if (immediate_quit)
>      async_request_quit (0);
>    else
> -    /* If immediate quit is not set, we process SIGINT the next time
> -       through the loop, which is fine. */
> -    mark_async_signal_handler_wrapper (sigint_token);
> +    {
> +      /* If immediate quit is not set, we process SIGINT the next time
> +         through the loop, which is fine. */
> +      mark_async_signal_handler_wrapper (sigint_token);
> +      /* We can also process the signal at certain specific locations
> +         which are explicitely marked by a call to QUIT.  */
> +      quit_flag = 1;
> +    }
>  }
>  
>  /* Do the quit. All the checks have been done by the caller. */


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/RFC] QUIT doesn't seem to be working !?

[Daniel Jacobowitz]

On Thu, Aug 28, 2003 at 10:41:16AM -0400, Daniel Jacobowitz wrote:
> On Tue, Aug 12, 2003 at 03:22:11PM -0700, Joel Brobecker wrote:
> > Hello,
> > 
> > it's bizarre, we noticed that we were unable to interrupt certain
> > commands that can be time greedy. For instance, when messing up in the
> > addresses given to the "disass" command, it can take GDB a loooooong
> > time to print all instructions. Unexpectedly, hitting Control-C did not
> > interrupt the command.
> > 
> > I see in disassemble_command() that there is a call to QUIT in the while
> > loop that prints all instructions. But this macro tests for quit_flag
> > to see if we should stop now or not. However, handle_sigint() does
> > not set this flag when Control-C is pressed, unless immediate_quit is
> > set. But immediate_quit is not really what we are looking for, because
> > it tells GDB that SIGINT events should be processed immediately, which
> > obviously means that GDB does not wait for the next call to QUIT to
> > perform the abortion.
> > 
> > So far, what handle_sigint() does is set the "ready" flag in GDB's
> > SIGINT async signal handler. This flag seems to take effect only
> > at the top-level loop level. So in our case, its effect arrives too
> > late.
> > 
> > So I couldn't understand how QUIT was working....
> > 
> > I applied the following change, which allows GDB to aboart at QUIT
> > points if the user has pressed C-c. But I feel like I'm missing
> > something...
> > 
> > 2003-08-12  J. Brobecker  <brobecker@gnat.com>
> > 
> >         * event-top.c (handle_sigint): Set quit_flag.
> > 
> > Comments? Ok to apply?
> 
> I see two functions which are intended to handle SIGINT.  One of them
> is handle_sigint; the other is request_quit.  If event_loop_p, we use
> the async version, which does not quit immediately.  This is the case
> unless gdb is started with --noasync.
> 
> The comments in handle_sigint suggest that deferring the C-c to the
> next time through the event loop is desired behavior.  I'm not entirely
> sure why.  It loses the use of the QUIT macro entirely.  There's a
> whole lot of complicated async infrastructure in event-top.c and
> event-loop.c but it seems that the async handlers are never called
> except from gdb_do_one_event, and I don't see any actual asynchronous
> way of getting there.
> 
> Elena seems to have written most of this code.  She might have a better
> idea of how this is supposed to work - and conveniently, she's listed
> as its maintainer, too :)
> 
> I suspect your patch is right, but I don't know if some additional
> cleanup is required for the asynchronous signal handlers, to prevent
> the quit from being processed twice.

Hi Elena,

Do you have any comments on this patch?

> 
> > Index: event-top.c
> > ===================================================================
> > RCS file: /nile.c/cvs/Dev/gdb/gdb-5.3/gdb/event-top.c,v
> > retrieving revision 1.1
> > diff -u -p -r1.1 event-top.c
> > --- event-top.c	16 Jan 2003 09:46:22 -0000	1.1
> > +++ event-top.c	12 Aug 2003 21:27:57 -0000
> > @@ -967,9 +967,14 @@ handle_sigint (int sig)
> >    if (immediate_quit)
> >      async_request_quit (0);
> >    else
> > -    /* If immediate quit is not set, we process SIGINT the next time
> > -       through the loop, which is fine. */
> > -    mark_async_signal_handler_wrapper (sigint_token);
> > +    {
> > +      /* If immediate quit is not set, we process SIGINT the next time
> > +         through the loop, which is fine. */
> > +      mark_async_signal_handler_wrapper (sigint_token);
> > +      /* We can also process the signal at certain specific locations
> > +         which are explicitely marked by a call to QUIT.  */
> > +      quit_flag = 1;
> > +    }
> >  }
> >  
> >  /* Do the quit. All the checks have been done by the caller. */
> 
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/RFC] QUIT doesn't seem to be working !?

[Daniel Jacobowitz]

On Thu, Aug 28, 2003 at 10:41:16AM -0400, Daniel Jacobowitz wrote:
> On Tue, Aug 12, 2003 at 03:22:11PM -0700, Joel Brobecker wrote:
> > Hello,
> > 
> > it's bizarre, we noticed that we were unable to interrupt certain
> > commands that can be time greedy. For instance, when messing up in the
> > addresses given to the "disass" command, it can take GDB a loooooong
> > time to print all instructions. Unexpectedly, hitting Control-C did not
> > interrupt the command.
> > 
> > I see in disassemble_command() that there is a call to QUIT in the while
> > loop that prints all instructions. But this macro tests for quit_flag
> > to see if we should stop now or not. However, handle_sigint() does
> > not set this flag when Control-C is pressed, unless immediate_quit is
> > set. But immediate_quit is not really what we are looking for, because
> > it tells GDB that SIGINT events should be processed immediately, which
> > obviously means that GDB does not wait for the next call to QUIT to
> > perform the abortion.
> > 
> > So far, what handle_sigint() does is set the "ready" flag in GDB's
> > SIGINT async signal handler. This flag seems to take effect only
> > at the top-level loop level. So in our case, its effect arrives too
> > late.
> > 
> > So I couldn't understand how QUIT was working....
> > 
> > I applied the following change, which allows GDB to aboart at QUIT
> > points if the user has pressed C-c. But I feel like I'm missing
> > something...
> > 
> > 2003-08-12  J. Brobecker  <brobecker@gnat.com>
> > 
> >         * event-top.c (handle_sigint): Set quit_flag.
> > 
> > Comments? Ok to apply?
> 
> I see two functions which are intended to handle SIGINT.  One of them
> is handle_sigint; the other is request_quit.  If event_loop_p, we use
> the async version, which does not quit immediately.  This is the case
> unless gdb is started with --noasync.
> 
> The comments in handle_sigint suggest that deferring the C-c to the
> next time through the event loop is desired behavior.  I'm not entirely
> sure why.  It loses the use of the QUIT macro entirely.  There's a
> whole lot of complicated async infrastructure in event-top.c and
> event-loop.c but it seems that the async handlers are never called
> except from gdb_do_one_event, and I don't see any actual asynchronous
> way of getting there.
> 
> Elena seems to have written most of this code.  She might have a better
> idea of how this is supposed to work - and conveniently, she's listed
> as its maintainer, too :)
> 
> I suspect your patch is right, but I don't know if some additional
> cleanup is required for the asynchronous signal handlers, to prevent
> the quit from being processed twice.

Hi Elena,

Do you have any comments on this patch for the event loop?

> > Index: event-top.c
> > ===================================================================
> > RCS file: /nile.c/cvs/Dev/gdb/gdb-5.3/gdb/event-top.c,v
> > retrieving revision 1.1
> > diff -u -p -r1.1 event-top.c
> > --- event-top.c	16 Jan 2003 09:46:22 -0000	1.1
> > +++ event-top.c	12 Aug 2003 21:27:57 -0000
> > @@ -967,9 +967,14 @@ handle_sigint (int sig)
> >    if (immediate_quit)
> >      async_request_quit (0);
> >    else
> > -    /* If immediate quit is not set, we process SIGINT the next time
> > -       through the loop, which is fine. */
> > -    mark_async_signal_handler_wrapper (sigint_token);
> > +    {
> > +      /* If immediate quit is not set, we process SIGINT the next time
> > +         through the loop, which is fine. */
> > +      mark_async_signal_handler_wrapper (sigint_token);
> > +      /* We can also process the signal at certain specific locations
> > +         which are explicitely marked by a call to QUIT.  */
> > +      quit_flag = 1;
> > +    }
> >  }
> >  
> >  /* Do the quit. All the checks have been done by the caller. */
> 
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/RFC] QUIT doesn't seem to be working !?

[Elena Zannoni]

Joel Brobecker writes:
 > Hello,
 > 
 > it's bizarre, we noticed that we were unable to interrupt certain
 > commands that can be time greedy. For instance, when messing up in the
 > addresses given to the "disass" command, it can take GDB a loooooong
 > time to print all instructions. Unexpectedly, hitting Control-C did not
 > interrupt the command.
 > 

Hmmm, this has probably been broken for 4+ years. :-(

 > I see in disassemble_command() that there is a call to QUIT in the while
 > loop that prints all instructions. But this macro tests for quit_flag
 > to see if we should stop now or not. However, handle_sigint() does
 > not set this flag when Control-C is pressed, unless immediate_quit is
 > set. But immediate_quit is not really what we are looking for, because
 > it tells GDB that SIGINT events should be processed immediately, which
 > obviously means that GDB does not wait for the next call to QUIT to
 > perform the abortion.
 > 
 > So far, what handle_sigint() does is set the "ready" flag in GDB's
 > SIGINT async signal handler. This flag seems to take effect only
 > at the top-level loop level. So in our case, its effect arrives too
 > late.
 > 
 > So I couldn't understand how QUIT was working....
 > 

I think your observations are correct. quit_flag is not set when we
hit the QUITs, if we use the event loop.  I remember testing the
behavior of ^-C several times, when I wrote that stuff, but I focused
more on interrupting a running target (launched with run&, etc) for
the async remote case. There is even a mechanism in gdb to handle a
^-C hit twice.  

Unfortunately I think that your patch is not completely correct. You
set up *both* the QUIT machinery and the event-loop to process *one*
SIGINT the next time through.  Whatever one you reach first, it will
leave a non-existant event set for the other.

Probably for the event-loop case we should forget quit_flag and just
rely on the markers being set in the event-loop machinery. Which means
that QUIT (or equivalent) will have to figure out if there are any
high priority events to be processed. Which, if you think about it, is
like saying that there will be a 'lower-level/inner-level/secondary'
event loop. In this sigint case, for QUIT to be able to pull out the
interrupt related markers from the event loop, it means that those
markers now need to identify themselves somehow. The event loop is
currently completely agnostic about the kind of events to be
processed. It only knows that they are generated by a signal (any
signal), while we want to pull out only the sigint ones. 

Actually the event loop knows only about 2 kinds (well, 3) kinds of
events: signals and file-descriptors related events (and timers).  We
are talking here about subverting that categorization by introducing a
urgent/high priority kind of event that needs to be processed
right now, w/o waiting until you get back to the event loop proper.

So, since 6.1 is approaching, I would mark this as a known problem,
and try to solve it in mainline, after the branch is cut.

elena


 > I applied the following change, which allows GDB to aboart at QUIT
 > points if the user has pressed C-c. But I feel like I'm missing
 > something...
 > 
 > 2003-08-12  J. Brobecker  <brobecker@gnat.com>
 > 
 >         * event-top.c (handle_sigint): Set quit_flag.
 > 
 > Comments? Ok to apply?
 > 
 > -- 
 > Joel
 > Index: event-top.c
 > ===================================================================
 > RCS file: /nile.c/cvs/Dev/gdb/gdb-5.3/gdb/event-top.c,v
 > retrieving revision 1.1
 > diff -u -p -r1.1 event-top.c
 > --- event-top.c	16 Jan 2003 09:46:22 -0000	1.1
 > +++ event-top.c	12 Aug 2003 21:27:57 -0000
 > @@ -967,9 +967,14 @@ handle_sigint (int sig)
 >    if (immediate_quit)
 >      async_request_quit (0);
 >    else
 > -    /* If immediate quit is not set, we process SIGINT the next time
 > -       through the loop, which is fine. */
 > -    mark_async_signal_handler_wrapper (sigint_token);
 > +    {
 > +      /* If immediate quit is not set, we process SIGINT the next time
 > +         through the loop, which is fine. */
 > +      mark_async_signal_handler_wrapper (sigint_token);
 > +      /* We can also process the signal at certain specific locations
 > +         which are explicitely marked by a call to QUIT.  */
 > +      quit_flag = 1;
 > +    }
 >  }
 >  
 >  /* Do the quit. All the checks have been done by the caller. */

Re: [RFA/RFC] QUIT doesn't seem to be working !?

[Andrew Cagney]

Some related history:

non-blocking reads/writes and event loops
http://sources.redhat.com/ml/gdb/2000-06/msg00088.html

remote.c's "async", "extended-async" back ends
http://sources.redhat.com/ml/gdb/2001-02/msg00016.html

remote.c and a re-entrant event-loop
http://sources.redhat.com/ml/gdb/2000-06/msg00144.html

> I think your observations are correct. quit_flag is not set when we
> hit the QUITs, if we use the event loop.  I remember testing the
> behavior of ^-C several times, when I wrote that stuff, but I focused
> more on interrupting a running target (launched with run&, etc) for
> the async remote case. There is even a mechanism in gdb to handle a
> ^-C hit twice.  
> 
> Unfortunately I think that your patch is not completely correct. You
> set up *both* the QUIT machinery and the event-loop to process *one*
> SIGINT the next time through.  Whatever one you reach first, it will
> leave a non-existant event set for the other.
> 
> Probably for the event-loop case we should forget quit_flag and just
> rely on the markers being set in the event-loop machinery. Which means
> that QUIT (or equivalent) will have to figure out if there are any
> high priority events to be processed. Which, if you think about it, is
> like saying that there will be a 'lower-level/inner-level/secondary'
> event loop. In this sigint case, for QUIT to be able to pull out the
> interrupt related markers from the event loop, it means that those
> markers now need to identify themselves somehow. The event loop is
> currently completely agnostic about the kind of events to be
> processed. It only knows that they are generated by a signal (any
> signal), while we want to pull out only the sigint ones. 

Based on the above links.  So this means that QUIT:

#define QUIT { \
   if (quit_flag) quit (); \
   if (interactive_hook) interactive_hook (); \
}

should be replaced by something like:

#define QUIT keep_event_loop_alive ();

> Actually the event loop knows only about 2 kinds (well, 3) kinds of
> events: signals and file-descriptors related events (and timers).  We
> are talking here about subverting that categorization by introducing a
> urgent/high priority kind of event that needs to be processed
> right now, w/o waiting until you get back to the event loop proper.
> 
> So, since 6.1 is approaching, I would mark this as a known problem,
> and try to solve it in mainline, after the branch is cut.

Yes.  I did a quick user poll over lunch and everyone indicated that 
contrl-c "works for me" (the sample included heavy java and C++ users!).

Andrew

Re: [RFA/RFC] QUIT doesn't seem to be working !?

[Joel Brobecker]

Hello Elena,

> So, since 6.1 is approaching, I would mark this as a known problem,
> and try to solve it in mainline, after the branch is cut.

Sounds good to me. I will take care of documenting the problem.

Could you take care of fixing it? I remember not being completely sure
of how things were supposed to work when I was looking at this...

Thanks,

-- 
Joel


>  > 2003-08-12  J. Brobecker  <brobecker@gnat.com>
>  > 
>  >         * event-top.c (handle_sigint): Set quit_flag.
>  > 
>  > Comments? Ok to apply?
>  > 
>  > -- 
>  > Joel
>  > Index: event-top.c
>  > ===================================================================
>  > RCS file: /nile.c/cvs/Dev/gdb/gdb-5.3/gdb/event-top.c,v
>  > retrieving revision 1.1
>  > diff -u -p -r1.1 event-top.c
>  > --- event-top.c	16 Jan 2003 09:46:22 -0000	1.1
>  > +++ event-top.c	12 Aug 2003 21:27:57 -0000
>  > @@ -967,9 +967,14 @@ handle_sigint (int sig)
>  >    if (immediate_quit)
>  >      async_request_quit (0);
>  >    else
>  > -    /* If immediate quit is not set, we process SIGINT the next time
>  > -       through the loop, which is fine. */
>  > -    mark_async_signal_handler_wrapper (sigint_token);
>  > +    {
>  > +      /* If immediate quit is not set, we process SIGINT the next time
>  > +         through the loop, which is fine. */
>  > +      mark_async_signal_handler_wrapper (sigint_token);
>  > +      /* We can also process the signal at certain specific locations
>  > +         which are explicitely marked by a call to QUIT.  */
>  > +      quit_flag = 1;
>  > +    }
>  >  }
>  >  
>  >  /* Do the quit. All the checks have been done by the caller. */

Re: [RFA/RFC] QUIT doesn't seem to be working !?

[Joel Brobecker]

> Yes.  I did a quick user poll over lunch and everyone indicated that 
> contrl-c "works for me" (the sample included heavy java and C++ users!).

I am a bit surprised by this, because, as far as I can remember, I
couldn't understand how this feature could work (no offense meant,
just to say that it appeared that this functionality was not just
broken under certain circumstances, but instead was never working).

For me, Control-C is working when the debugger is waiting for an event
from the inferior. However, it is not working when the debugger is
busy inside a greedy loop (ie the QUIT macro does not abort the
loop).

-- 
Joel

Re: [RFA/RFC] QUIT doesn't seem to be working !?

[Andrew Cagney]

>>Yes.  I did a quick user poll over lunch and everyone indicated that 
>>> contrl-c "works for me" (the sample included heavy java and C++ users!).
> 
> 
> I am a bit surprised by this, because, as far as I can remember, I
> couldn't understand how this feature could work (no offense meant,
> just to say that it appeared that this functionality was not just
> broken under certain circumstances, but instead was never working).

So was I - a more exact quote of the response was "It's broken!?!?".  It 
turns out that cntrl-c is being polled sufficiently often for people to 
not notice that there is a problem vis:

(gdb) set height 2
(gdb) info frame
Stack level 0, frame at 0x7fffe5c0:
---Type <return> to continue, or q <return> to quit---Quit

 > For me, Control-C is working when the debugger is waiting for an event
 > from the inferior. However, it is not working when the debugger is
 > busy inside a greedy loop (ie the QUIT macro does not abort the
 > loop).

Just don't try this at home:

(gdb) while 1
end

(but I suspect that's always been broken as well).

Andrew

Re: [RFA/RFC] QUIT doesn't seem to be working !?

[Elena Zannoni]

Joel Brobecker writes:
 > Hello Elena,
 > 
 > > So, since 6.1 is approaching, I would mark this as a known problem,
 > > and try to solve it in mainline, after the branch is cut.
 > 
 > Sounds good to me. I will take care of documenting the problem.
 > 

thanks

 > Could you take care of fixing it? I remember not being completely sure
 > of how things were supposed to work when I was looking at this...
 > 

yes.

elena

Re: [RFA/RFC] QUIT doesn't seem to be working !?

[Daniel Jacobowitz]

On Fri, Feb 20, 2004 at 12:51:10PM -0500, Andrew Cagney wrote:
> >>Yes.  I did a quick user poll over lunch and everyone indicated that 
> >>>contrl-c "works for me" (the sample included heavy java and C++ users!).
> >
> >
> >I am a bit surprised by this, because, as far as I can remember, I
> >couldn't understand how this feature could work (no offense meant,
> >just to say that it appeared that this functionality was not just
> >broken under certain circumstances, but instead was never working).
> 
> So was I - a more exact quote of the response was "It's broken!?!?".  It 
> turns out that cntrl-c is being polled sufficiently often for people to 
> not notice that there is a problem vis:
> 
> (gdb) set height 2
> (gdb) info frame
> Stack level 0, frame at 0x7fffe5c0:
> ---Type <return> to continue, or q <return> to quit---Quit
> 
> > For me, Control-C is working when the debugger is waiting for an event
> > from the inferior. However, it is not working when the debugger is
> > busy inside a greedy loop (ie the QUIT macro does not abort the
> > loop).

Right - I think that the "when running" case is the only thing that's
got high user visibility for our average user.  Me, I run into the
problem Joel is patching all the time.  I just did five minutes ago.
I mean to type
(gdb) info addr to_offset
and instead type
(gdb) info var to_offset

which sends GDB off into an expensive (5sec or so on this app) search.

(gdb) info var to_offset
^C^C^Cdarnit
^C
(gdb) Quit
(gdb) Quit
(gdb) Quit
Undefined command: "darnit".  Try "help".
(gdb) Quit
(gdb)


> Just don't try this at home:
> 
> (gdb) while 1
> end
> 
> (but I suspect that's always been broken as well).

Is there even a QUIT in that code path?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/RFC] QUIT doesn't seem to be working !?

[Joel Brobecker]

> > Just don't try this at home:
> > 
> > (gdb) while 1
> > end
> > 
> > (but I suspect that's always been broken as well).
> 
> Is there even a QUIT in that code path?

I think so. With the patch I suggested, I can interrupt this loop
using Control-C. But I also see the 2 "Quit" acknoledgements, the
problem you mentionned long ago when you first reviewed my patch...

        (gdb) while 1
         >end
        ^CQuit
        (gdb) Quit

-- 
Joel