Re: Ctrl-C strange behavior

Re: Ctrl-C strange behavior

[Will Lentz]

Hi Leon & all,

Leon Pollak wrote:
> 
> Hello, gurus.
>     Please, can somebody describe rather strange behavior of Ctrl-C that I
have?
>     I run Insight from xterm and the program downloads to the target and
starts to run.
>     When I press Ctrl-C in command window, press "STOP" button or try
close Insignt -
>     nothing happens.
>     Even the windows are not redrawn and remain blank if I minimize them.
>     But when I press Ctrl-C from the xterm window, Insignt says that it
received
>     SGINT interrupt and stops the target.
> 

I was having the same problem under Linux and Windows 98 
with the 2000-05-15 insight+dejagnu snapshot (connecting
to an extended-remote target over TCP).

Under Linux, I found a workaround (see the diff below).
Under Windows, the Insight window now updates but I don't
get a stop button.  I also tried the patch about __CYGWIN32__
on gdbtk.c, and that did not work for me.  

There's most probably a better way to do the workaround, but basically:
 1- ser_unix_wait_for was getting called with a timeout=-1,
    so it hung the GUI.  Now everything has a timeout.
 2- read() was hanging when status==SERIAL_TIMEOUT.  I don't 
    know why I set status to 0 in this case (but it works).

Will

PS- Anyone have better luck with Ctrl-C and Insight in Windows?

PPS-
Here's the diff -u -p :
--- ser-unix.c  Tue Mar 28 00:24:28 2000
+++ ser-unix2.c Tue May 16 10:36:53 2000
@@ -875,11 +875,13 @@ ser_unix_wait_for (serial_t scb, int tim
 
   while (1)
     {
-      if (timeout >= 0)
+      if (timeout > 0)
        numfds = select (scb->fd + 1, &readfds, 0, &exceptfds, &tv);
-      else
-       numfds = select (scb->fd + 1, &readfds, 0, &exceptfds, 0);
-
+      else {
+        tv.tv_sec = 1;
+        tv.tv_usec = 0;
+        numfds = select (scb->fd + 1, &readfds, 0, &exceptfds, &tv);
+      }
       if (numfds <= 0)
        {
          if (numfds == 0)
@@ -936,7 +938,10 @@ do_unix_readchar (serial_t scb, int time
       if (status == SERIAL_ERROR)
         return status;
 
-      status = read (scb->fd, scb->buf, BUFSIZ);
+      if( status != SERIAL_TIMEOUT )
+        status = read (scb->fd, scb->buf, BUFSIZ);
+      else
+        status = 0;
 
       if (status <= 0)
         {

Re: Ctrl-C strange behavior

[Elena Zannoni]

Will Lentz writes:
 > Hi Leon & all,
 > 
 > Leon Pollak wrote:
 > > 
 > > Hello, gurus.
 > >     Please, can somebody describe rather strange behavior of Ctrl-C that I
 > have?
 > >     I run Insight from xterm and the program downloads to the target and
 > starts to run.
 > >     When I press Ctrl-C in command window, press "STOP" button or try
 > close Insignt -
 > >     nothing happens.
 > >     Even the windows are not redrawn and remain blank if I minimize them.
 > >     But when I press Ctrl-C from the xterm window, Insignt says that it
 > received
 > >     SGINT interrupt and stops the target.
 > > 


Will, 
I just committed the patch I posted a few days back for this
problem. Can you see if it helps?

Thanks
Elena

 > 
 > I was having the same problem under Linux and Windows 98 
 > with the 2000-05-15 insight+dejagnu snapshot (connecting
 > to an extended-remote target over TCP).
 > 
 > Under Linux, I found a workaround (see the diff below).
 > Under Windows, the Insight window now updates but I don't
 > get a stop button.  I also tried the patch about __CYGWIN32__
 > on gdbtk.c, and that did not work for me.  
 > 
 > There's most probably a better way to do the workaround, but basically:
 >  1- ser_unix_wait_for was getting called with a timeout=-1,
 >     so it hung the GUI.  Now everything has a timeout.
 >  2- read() was hanging when status==SERIAL_TIMEOUT.  I don't 
 >     know why I set status to 0 in this case (but it works).
 > 
 > Will
 > 
 > PS- Anyone have better luck with Ctrl-C and Insight in Windows?
 > 
 > PPS-
 > Here's the diff -u -p :
 > --- ser-unix.c  Tue Mar 28 00:24:28 2000
 > +++ ser-unix2.c Tue May 16 10:36:53 2000
 > @@ -875,11 +875,13 @@ ser_unix_wait_for (serial_t scb, int tim
 >  
 >    while (1)
 >      {
 > -      if (timeout >= 0)
 > +      if (timeout > 0)
 >         numfds = select (scb->fd + 1, &readfds, 0, &exceptfds, &tv);
 > -      else
 > -       numfds = select (scb->fd + 1, &readfds, 0, &exceptfds, 0);
 > -
 > +      else {
 > +        tv.tv_sec = 1;
 > +        tv.tv_usec = 0;
 > +        numfds = select (scb->fd + 1, &readfds, 0, &exceptfds, &tv);
 > +      }
 >        if (numfds <= 0)
 >         {
 >           if (numfds == 0)
 > @@ -936,7 +938,10 @@ do_unix_readchar (serial_t scb, int time
 >        if (status == SERIAL_ERROR)
 >          return status;
 >  
 > -      status = read (scb->fd, scb->buf, BUFSIZ);
 > +      if( status != SERIAL_TIMEOUT )
 > +        status = read (scb->fd, scb->buf, BUFSIZ);
 > +      else
 > +        status = 0;
 >  
 >        if (status <= 0)
 >          {
 > 

RE: Ctrl-C strange behavior

[Will Lentz]

Elena,

ok - I'll give it a shot tonight.  Does the 20000522
snapshot contain the patch?

Thanks,
Will

PS- I did try the patch manually when it was first 
 posted, but maybe I screwed up :).

> -----Original Message-----
> From: Elena Zannoni [ mailto:ezannoni@cygnus.com ]
> Sent: Monday, May 22, 2000 7:57 AM
> To: Will Lentz
> Cc: leonp@plris.com; Insight
> Subject: Re: Ctrl-C strange behavior
> 
> 
> Will, 
> I just committed the patch I posted a few days back for this
> problem. Can you see if it helps?
> 
> Thanks
> Elena
> 

RE: Ctrl-C strange behavior

[Elena Zannoni]

Will Lentz writes:
 > Elena,
 > 
 > ok - I'll give it a shot tonight.  Does the 20000522
 > snapshot contain the patch?

Probably not. I just committed the patch when I sent the mail.

 > 
 > Thanks,
 > Will
 > 
 > PS- I did try the patch manually when it was first 
 >  posted, but maybe I screwed up :).
 > 

I may legitimately be another error. Let me know.

Elena


 > > -----Original Message-----
 > > From: Elena Zannoni [ mailto:ezannoni@cygnus.com ]
 > > Sent: Monday, May 22, 2000 7:57 AM
 > > To: Will Lentz
 > > Cc: leonp@plris.com; Insight
 > > Subject: Re: Ctrl-C strange behavior
 > > 
 > > 
 > > Will, 
 > > I just committed the patch I posted a few days back for this
 > > problem. Can you see if it helps?
 > > 
 > > Thanks
 > > Elena
 > > 

Re: Ctrl-C strange behavior

[Scott A Sumner]

Chris (& others)--

Actually it looked like there were three routines to hit:

1) gdbtk_start_timer
2) gdbtk_stop_timer
3) target_should_use_timer

I pulled the #ifdef conditionals out, and left the 'return's in.
Did I make the right call here?



>>My problem:  If my target runs at full speed, I have no way to tell
>>Insight I want to break execution wherever it happens to be.  As 
>>soon as
>>I hit the continue button, Insight changes the cursor to an 
>>hourglass and
>>just hangs (if I don't have a breakpoint set that execution will 
>>hit).  I
>>can't do anything except kill gdb and restart it.  I want to press 
>>the
>>stop button but as Insight appears to be hung at this point, it 
>>doesn't
>>work.  This is *extremely* annoying; anyone have any idea why it 
>>does
>>this and what the solution/workaround might be?
 
> Try removing the "#ifdef __CYGWIN32__" (sic) conditional in 
> gdbtk_start_timer
> and also try using the latest cygwin net release.  It's available 
> at:
> 
> http://sourceware.cygnus.com/cygwin/
> 
> cgf

Re: Ctrl-C strange behavior

[Elena Zannoni]

I verified this.
Here is a patch, which I will commit shortly.

Elena

2000-05-12  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>

	* gdbtk.c: Remove CYGWIN32 conditional around timer machinery.
  	Cygwin can handle timers fine now.	


Index: gdbtk.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/gdbtk/generic/gdbtk.c,v
retrieving revision 1.3
diff -u -p -r1.3 gdbtk.c
--- gdbtk.c	2000/05/01 04:46:49	1.3
+++ gdbtk.c	2000/05/12 18:03:12
@@ -67,7 +67,6 @@
 
 extern void _initialize_gdbtk (void);
 
-#ifndef __CYGWIN32__
 /* For unix natives, we use a timer to periodically keep the gui alive.
    See comments before x_event. */
 static sigset_t nullsigmask;
@@ -81,7 +80,6 @@ x_event_wrapper (signo)
 {
   x_event (signo);
 }
-#endif
 
  /*
   * These two variables control the interaction with an external editor.
@@ -104,9 +102,7 @@ static void cleanup_init PARAMS ((int));
 
 static void tk_command PARAMS ((char *, int));
 
-#ifndef __CYGWIN32__
 static int target_should_use_timer PARAMS ((struct target_ops * t));
-#endif
 
 int target_is_native PARAMS ((struct target_ops *t));
 
@@ -115,9 +111,7 @@ int gdbtk_test PARAMS ((char *));
 /* Handle for TCL interpreter */
 Tcl_Interp *gdbtk_interp = NULL;
 
-#ifndef __CYGWIN32__
 static int gdbtk_timer_going = 0;
-#endif
 
 /* linked variable used to tell tcl what the current thread is */
 int gdb_context = 0;
@@ -266,7 +260,6 @@ gdbtk_interactive ()
 void
 gdbtk_start_timer ()
 {
-#ifndef __CYGWIN32__
   static int first = 1;
 
   if (first)
@@ -303,28 +296,22 @@ gdbtk_start_timer ()
 	  gdbtk_timer_going = 1;
 	}
     }
-#else /* __CYGWIN32__ */
   return;
-#endif
 }
 
 /* Stop the timer if it is running. */
 void
 gdbtk_stop_timer ()
 {
-#ifndef __CYGWIN32__
   if (gdbtk_timer_going)
     {
       gdbtk_timer_going = 0;
       setitimer (ITIMER_REAL, &it_off, NULL);
       sigaction (SIGALRM, &act2, NULL);
     }
-#else /* __CYGWIN32__ */
   return;
-#endif
 }
 
-#ifndef __CYGWIN32__
 /* Should this target use the timer? See comments before
    x_event for the logic behind all this. */
 static int
@@ -333,7 +320,6 @@ target_should_use_timer (t)
 {
   return target_is_native (t);
 }
-#endif /* !__CYGWIN32__ */
 
 /* Is T a native target? */
 int




Scott A Sumner writes:
 > Chris (& others)--
 > 
 > Actually it looked like there were three routines to hit:
 > 
 > 1) gdbtk_start_timer
 > 2) gdbtk_stop_timer
 > 3) target_should_use_timer
 > 
 > I pulled the #ifdef conditionals out, and left the 'return's in.
 > Did I make the right call here?
 > 
 > 
 > 
 > >>My problem:  If my target runs at full speed, I have no way to tell
 > >>Insight I want to break execution wherever it happens to be.  As 
 > >>soon as
 > >>I hit the continue button, Insight changes the cursor to an 
 > >>hourglass and
 > >>just hangs (if I don't have a breakpoint set that execution will 
 > >>hit).  I
 > >>can't do anything except kill gdb and restart it.  I want to press 
 > >>the
 > >>stop button but as Insight appears to be hung at this point, it 
 > >>doesn't
 > >>work.  This is *extremely* annoying; anyone have any idea why it 
 > >>does
 > >>this and what the solution/workaround might be?
 >  
 > > Try removing the "#ifdef __CYGWIN32__" (sic) conditional in 
 > > gdbtk_start_timer
 > > and also try using the latest cygwin net release.  It's available 
 > > at:
 > > 
 > > http://sourceware.cygnus.com/cygwin/
 > > 
 > > cgf

Re: Ctrl-C strange behavior

[Scott A Sumner]

Hi Leon and everyone,

I've noticed some strange behavior with Insight similar to Leon's.  BTW,
my Insight is configured as "--host=i586-pc-cygwin --target=m68k-coff"
and is the 20000314 snapshot.

My problem:  If my target runs at full speed, I have no way to tell
Insight I want to break execution wherever it happens to be.  As soon as
I hit the continue button, Insight changes the cursor to an hourglass and
just hangs (if I don't have a breakpoint set that execution will hit).  I
can't do anything except kill gdb and restart it.  I want to press the
stop button but as Insight appears to be hung at this point, it doesn't
work.  This is *extremely* annoying; anyone have any idea why it does
this and what the solution/workaround might be?

Many thanks,
Scott


On Tue, 02 May 2000 19:34:35 +0300 Leon Pollak <leonp@plris.com> writes:
> Hello, gurus.
>     Please, can somebody describe rather strange behavior of Ctrl-C 
> that
> I have?
>     I run Insight from xterm and the program downloads to the target
> and starts to run.
>     When I press Ctrl-C in command window, press "STOP" button or 
> try to
> close Insignt - nothing happens.
>     Even the windows are not redrawn and remain blank if I minimize
> them.
>     But when I press Ctrl-C from the xterm window, Insignt says that 
> it
> received SGINT interrupt and stops the target.
> 
>     May thanks ahead.
> 
> leonp@plris.com
> 

Re: Ctrl-C strange behavior

[Chris Faylor]

On Wed, May 03, 2000 at 07:23:59PM -0400, Scott A Sumner wrote:
>Hi Leon and everyone,
>
>I've noticed some strange behavior with Insight similar to Leon's.  BTW,
>my Insight is configured as "--host=i586-pc-cygwin --target=m68k-coff"
>and is the 20000314 snapshot.
>
>My problem:  If my target runs at full speed, I have no way to tell
>Insight I want to break execution wherever it happens to be.  As soon as
>I hit the continue button, Insight changes the cursor to an hourglass and
>just hangs (if I don't have a breakpoint set that execution will hit).  I
>can't do anything except kill gdb and restart it.  I want to press the
>stop button but as Insight appears to be hung at this point, it doesn't
>work.  This is *extremely* annoying; anyone have any idea why it does
>this and what the solution/workaround might be?

Try removing the "#ifdef __CYGWIN32__" (sic) conditional in gdbtk_start_timer
and also try using the latest cygwin net release.  It's available at:

http://sourceware.cygnus.com/cygwin/

cgf

Re: Ctrl-C strange behavior

[Keith Seitz]

Scott A Sumner wrote:
> 
> My problem:  If my target runs at full speed, I have no way to tell
> Insight I want to break execution wherever it happens to be.  As soon as
> I hit the continue button, Insight changes the cursor to an hourglass and
> just hangs (if I don't have a breakpoint set that execution will hit).  I
> can't do anything except kill gdb and restart it.  I want to press the
> stop button but as Insight appears to be hung at this point, it doesn't
> work.  This is *extremely* annoying; anyone have any idea why it does
> this and what the solution/workaround might be?

The problem which everyone is seeing is the same. Chris Faylor has
already pointed out a very likely fix for the problem. Allow me to
vent^H^H^H^Hexplain what's happening.

(Some of this may be a little out of date: it's been a while since I've
looked at this code.)
The real problem is simple: gdb has a minimum of three event loops: the
gui's event loop or the command processor's event loop, two (or more)
target event loops, and there are probably more that I'm neglecting (or
I've erased from my memory).

Cygnus/Red Hat is working to collapse these down to one, but I can tell
you, this is definitely a non-trivial task. Gdb is an OLD program, and
it was state-of-the-art (more or less) for it's time, when the command
line ruled and "GUI" described brownies. Gdb has, with this one
exception, lived quite well. Not many other programs have a lifespan as
long as gdb's, and with such expandability. It really is quite
remarkable when you think about it.

Let me go into a little detail about what these event loops do... The Tk
event loop and the command processor event loops were collapsed many
years ago with Stu Grossman's original gdbtk. These event loops are
responsible for processing user-interface events, like command input
from the command line or window and mouse events from X/Windows. So far
so good. The problem is, now, when someone runs the inferior (let's say
a over a serial line), gdb BLOCKS in a system call to read (), waiting
for the target to take an exception (breakpoint, illegal instructions,
and so on). Now, while this is happening, the UI's event loop cannot
run. So the user observes a "freeze" or "lock-up" in the user interface.
This is not at all noticeable in command-line interfaces, but it is
especially damaging in graphical interfaces like gdbtk.

Stu's initial solution to the problem was to set SIGIO on the socket for
X, running through all the events in the event queue whenever the signal
handler was called. Worked great, except that we could never seem to get
all unices (SunOS4, in particular) to work properly. There was one other
problem, too: interrupting remote targets. When a user requests to
interrupt a remote target, two things can happen: 1) the target ignores
the request (this is the most likely case; there are only a handful of
remotes that know how to interrupt a running target) and 2) the target
stops, sends and exception (SIGINT) to gdb, and gdb exits the target
event loop, returing to wait_for_inferior, and back out to the GUI. This
is the least likely thing to happen. In fact, I've only seen two or
three (remote) targets that could do this.

To make matters worse, we throw Windows into the mix. SIGIO on Windows?
I don't think so. Even if it did, could we find an X socket to attach it
to? Nope, so we had to do something else. The first step was an itimer.
Worked well on unix, but too flaky on Windows/Cygwin32. Sigh.

To make a long story short(er), we use timers on all native unix
targets. Otherwise, we must place explicit calls to ui_loop_hook in the
target event loop, which is scattered all over the place in various
places. For example, all the simulators were modified to make sure that
they call the simulator's os_poll_quit hook. This maps back to
gdb_os_poll_quit in remote-sim.c, which, calls ui_loop_hook at the
beginning. This forces the GUI's event loop to run.

Need to interrupt targets which don't support it? Well, that's a little
tougher. When this happens in the command line, gdb will ask the user if
he wants to detach from the target and stop debugging it. If the user
says "yes", then gdb longjmps () over the read (), back to the
"top_level", the main UI event loop. Well, as you might expect,
longjmp'ing over an interpreter is bad news. That's why ui_loop_hook
returns a value. If this value is non-zero, this tells the caller to
break out of his event loop, because the user wants to force a
disconnect. See the example in do_hardwire_readchar in ser-unix.c. We
modified the blocking call to read () to do one second polls, allowing
the UI to run through the event loop each time. This is why gdbtk gets
choppy when a remote target is running.

Wow. Well, I think I've over answered your question, but now you have a
better understanding of what's going on behind the scenes.

Keith
-- 
Why chat when you can Firetalk?
Firetalk ID: Keith (10320)
www.firetalk.com

Ctrl-C strange behavior

[Leon Pollak]

Hello, gurus.
    Please, can somebody describe rather strange behavior of Ctrl-C that
I have?
    I run Insight from xterm and the program downloads to the target
and starts to run.
    When I press Ctrl-C in command window, press "STOP" button or try to
close Insignt - nothing happens.
    Even the windows are not redrawn and remain blank if I minimize
them.
    But when I press Ctrl-C from the xterm window, Insignt says that it
received SGINT interrupt and stops the target.

    May thanks ahead.

leonp@plris.com

Re: Ctrl-C strange behavior

[Keith Seitz]

Leon Pollak wrote:
> 
> Hello, gurus.
>     Please, can somebody describe rather strange behavior of Ctrl-C that I have?
>     I run Insight from xterm and the program downloads to the target and starts to run.
>     When I press Ctrl-C in command window, press "STOP" button or try close Insignt -
>     nothing happens.
>     Even the windows are not redrawn and remain blank if I minimize them.
>     But when I press Ctrl-C from the xterm window, Insignt says that it  received
>     SGINT interrupt and stops the target.
> 

Sigh. Read my previous message to this group under the same subject for
a basic description of the things going on behind the scenes and Chris
Faylor's message for a possible solution.

Now, onto the "weird" behavior: gdbtk does not know how to deal with
terminals very well. For example, stdin/stdout/stderr all map to gdbtk's
controlling terminal (usually the xterm from which you launched gdbtk).
So an interrupt to this controlling terminal will cause gdbtk to attempt
to interrupt the target.

Just think of gdbtk rerouting all output to stdout (gdb's stdout) to the
console window. The problem is that all inferior I/O still goes through
the xterm, just like when you use the command line. So when you hit ^C
in the terminal from which gdbtk was launched, you are sending the
inferior a signal, SIGINT, which gdb catches. Fun, eh? No one has yet to
attempt to fix this properly (for remotes), but Tom Tromey had a
solution to this for natives quite some time ago.

(This is also the reason why you cannot use gdbtk by double-clicking it
in a window manager. Gdbtk MUST have a controlling terminal, so you MUST
launch it from a shell. Code Fusion works around this problem by giving
gdbtk a controlling terminal. Tom's solution is the similar, but it
teaches gdb how to get its own controlling terminal.)

Boy, I sound like the bearer of bad news today...
Keith
-- 
Why chat when you can Firetalk?
Firetalk ID: Keith (10320)
www.firetalk.com