RE: Ctrl-C interrupt problem.

RE: Ctrl-C interrupt problem.

[Fabrice Gautier]

Hi,

Me again,

Ctrl-C has definitely some strange behaviours for me.

Now I hve tried to do some test with natives cygwin programs. The very
simple sample below crashes in some circumstances with ctrl-C:

First Ctrl-C - everything is fine:

Program received signal SIGINT, Interrupt.
[Switching to thread 325.0x140]
0x77f2b5b4 in ?? ()


Second Ctrl-C - bad karma:
(gdb) c
Continuing.
      0 [main] gdb 9049 handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
    669 [main] gdb 9049 stackdump: Dumping stack trace to gdb.exe.stackdump
Segmentation fault (core dumped)


The program is just:

int main(void)
{
	while(1);
}

[To be honest, I didn't think to try *so* simple first but finally it came
to this...]

If you had a "printf" in the while loop it's eaxctely the same.

But in some case you can be safe. With this loop:
while(1){
	unsigned int i=1600000000;
	while(i-->0);
	printf("test\n");
}

the printf is just here to have a line where to put a breakpoint.
So you put a breakpoint on the printf, you run the program:

First ctrl-C: before breakpoint - everything Ok - continue
BreakPoint: everything ok - continue
First ctrl-C: before breakpoint - ok - continue
Second ctrl-C: *before breakpoint* - same crash


I've done some tracing with "set debug target 1" but didn't find any meaning
in the output.

Maybe the only thing is in the target_wait message.
In case of a ctrl-C there are two target_wait.
The first is the result of you hitting ctrl-C and the second, I guess, is
the result of the breakpoint instruction set by the ctrl-C handler.

These message are like:
target_wait (-1, status) = 176,   status->kind = spurious
but the status value change each time (it's always the same when the mesage
appears as a result of a breakpoint)

When it crashes, it is just after the first message.


Now there is another interresting behaviour:
When i hit ctrl-C when the program is already stopped, gdb print a "Quit"
but doesn't really quit.
The interresting thing about that is in the case of my remote target via
TCP.
If you remember, when i hit a first ctrl-C that won't stop the target. Then
after a O packet has been received i hit ctrl-C again and then it stop and i
have in Bonus a "Quit" printed, as if my first ctrl-C was not lost, but
delivered to gdb later.
If press ctrl-C only one time after the O packet, it won't print the "Quit".

Well, is not that it works better, but if someone can make sense of my
experiments....

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 


> -----Original Message-----
> From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> Subject: RE: Ctrl-C interrupt problem.
> 
[...]

Re: Ctrl-C interrupt problem.

[Eli Zaretskii]

> From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
> Date: Tue, 14 Nov 2000 20:18:11 -0800
> 
> Now I hve tried to do some test with natives cygwin programs. The very
> simple sample below crashes in some circumstances with ctrl-C:
> 
> First Ctrl-C - everything is fine:
> 
> Program received signal SIGINT, Interrupt.
> [Switching to thread 325.0x140]
> 0x77f2b5b4 in ?? ()
> 
> 
> Second Ctrl-C - bad karma:
> (gdb) c
> Continuing.
>       0 [main] gdb 9049 handle_exceptions: Exception:
> STATUS_ACCESS_VIOLATION
>     669 [main] gdb 9049 stackdump: Dumping stack trace to gdb.exe.stackdump
> Segmentation fault (core dumped)

I don't know whether this is connected, but Ctrl-C gets some special
handling from the NT DOS Box.  I don't know the particulars (Microsoft
won't distribute NTVDM as Free Software ;-), but it is a known problem
that NTVDM crashes or silently swallows Ctrl-C presses in some cases.

I don't know if this is relevant for native Win32 console applications
such as GDB compiled with Cygwin.

Re: Ctrl-C interrupt problem.

[Christopher Faylor]

On Wed, Nov 15, 2000 at 06:27:38AM -0500, Eli Zaretskii wrote:
>> From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
>> Date: Tue, 14 Nov 2000 20:18:11 -0800
>> 
>> Now I hve tried to do some test with natives cygwin programs. The very
>> simple sample below crashes in some circumstances with ctrl-C:
>> 
>> First Ctrl-C - everything is fine:
>> 
>> Program received signal SIGINT, Interrupt.
>> [Switching to thread 325.0x140]
>> 0x77f2b5b4 in ?? ()
>> 
>> 
>> Second Ctrl-C - bad karma:
>> (gdb) c
>> Continuing.
>>       0 [main] gdb 9049 handle_exceptions: Exception:
>> STATUS_ACCESS_VIOLATION
>>     669 [main] gdb 9049 stackdump: Dumping stack trace to gdb.exe.stackdump
>> Segmentation fault (core dumped)
>
>I don't know whether this is connected, but Ctrl-C gets some special
>handling from the NT DOS Box.  I don't know the particulars (Microsoft
>won't distribute NTVDM as Free Software ;-), but it is a known problem
>that NTVDM crashes or silently swallows Ctrl-C presses in some cases.
>
>I don't know if this is relevant for native Win32 console applications
>such as GDB compiled with Cygwin.

gdb should be using the same signal semantics for cygwin as it does on
UNIX.  I'm not aware of any problems handling CTRL-C in normal cygwin
processes but I have seen cases where gdb didn't want to wake up after
hitting a CTRL-C.  This may be because WaitForDebugEvent is not
interruptible by a CTRL-C.  I think that Keith Seitz made this call time
out some time ago to work around this fact, though.

If there is a problem, it needs to be debugged.  If you debug gdb using
gdb you (Fabrice) should be able to figure out where the SIGSEGV is
coming from.  That doesn't necessarily mean that it will be immediately
obvious how to fix it, of course, but at least you'll have more of a
clue as to where gdb is dying.

However, if you are going to be debugging gdb using, gdb, it makes sense
to rebuild a new windows version from CVS.  The gdb released with cygwin
net release is somewhat out-of-date, right now.

cgf

RE: Ctrl-C interrupt problem.

[Fabrice Gautier]

[eCos and RedBoot guys, I think this may concern you 
 its about a ctrl-C problem which only happen when debugging via ethernet.
 full story in the gdb list archives ]

I Got it! 
Well, i hope....

And it make sens why it only happens with TCP...

The problem is that when gdb send the continue packet to the target, it wait
for the target to send the '+' Ack. During this time the SIGINT handler is
not set.

My guess is that RedBoot intedn to send it BUT (tata) the ethernet driver
just wait to have a full packet before really sending! So this happen when a
O packet is sent.

So i guess the only thing needed in RedBoot is to add a "flush" somewhere.
I'm not sure at what level, but i'll look at it tomorrow if nobody does it
before.

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: Ctrl-C interrupt problem.

[Fernando Nasser]

Fabrice Gautier wrote:
> 
> [eCos and RedBoot guys, I think this may concern you
>  its about a ctrl-C problem which only happen when debugging via ethernet.
>  full story in the gdb list archives ]
> 
> I Got it!
> Well, i hope....
> 
> And it make sens why it only happens with TCP...
> 
> The problem is that when gdb send the continue packet to the target, it wait
> for the target to send the '+' Ack. During this time the SIGINT handler is
> not set.
> 
> My guess is that RedBoot intedn to send it BUT (tata) the ethernet driver
> just wait to have a full packet before really sending! So this happen when a
> O packet is sent.
> 
> So i guess the only thing needed in RedBoot is to add a "flush" somewhere.
> I'm not sure at what level, but i'll look at it tomorrow if nobody does it
> before.
> 

Fabrice, if this is true (and it is a very plausible explanation), you have
caught a very nasty bug that was going to bother many people.

For instance, the GUI presently (with the new sources you got from cvs) is
kept active while the target is running, but not while waiting for an ACK!


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Ctrl-C interrupt problem.

[Mark Salter]

>>>>> Fabrice Gautier writes:

> [eCos and RedBoot guys, I think this may concern you 
>  its about a ctrl-C problem which only happen when debugging via ethernet.
>  full story in the gdb list archives ]

> I Got it! 
> Well, i hope....

> And it make sens why it only happens with TCP...

> The problem is that when gdb send the continue packet to the target, it wait
> for the target to send the '+' Ack. During this time the SIGINT handler is
> not set.

> My guess is that RedBoot intedn to send it BUT (tata) the ethernet driver
> just wait to have a full packet before really sending! So this happen when a
> O packet is sent.

> So i guess the only thing needed in RedBoot is to add a "flush" somewhere.
> I'm not sure at what level, but i'll look at it tomorrow if nobody does it
> before.

> Thanks

> -- 
> Fabrice Gautier
> fabrice_gautier@sdesigns.com 


Yes, it appears that redboot only flushes the output stream when
it sees the end of a packet. This causes the problem you see.

Look at .../redboot/current/src/net/net_io.c:net_io_putc().

A quick workaround would be to also flush if a '+' is seen. This
has a downside as it may severely impact download speeds, but at
least it is functionally correct. YMMV.

This needs to be fixed with a flush of the output stream prior
to continuing or stepping the target. Its not clear to me right
now how this can be done.

--Mark

Re: Ctrl-C interrupt problem.

[Fernando Nasser]

Nice catch Fabrice.

Congratulations on your persistence.

Fernando



Mark Salter wrote:
> 
> >>>>> Fabrice Gautier writes:
> 
> > [eCos and RedBoot guys, I think this may concern you
> >  its about a ctrl-C problem which only happen when debugging via ethernet.
> >  full story in the gdb list archives ]
> 
> > I Got it!
> > Well, i hope....
> 
> > And it make sens why it only happens with TCP...
> 
> > The problem is that when gdb send the continue packet to the target, it wait
> > for the target to send the '+' Ack. During this time the SIGINT handler is
> > not set.
> 
> > My guess is that RedBoot intedn to send it BUT (tata) the ethernet driver
> > just wait to have a full packet before really sending! So this happen when a
> > O packet is sent.
> 
> > So i guess the only thing needed in RedBoot is to add a "flush" somewhere.
> > I'm not sure at what level, but i'll look at it tomorrow if nobody does it
> > before.
> 
> > Thanks
> 
> > --
> > Fabrice Gautier
> > fabrice_gautier@sdesigns.com
> 
> Yes, it appears that redboot only flushes the output stream when
> it sees the end of a packet. This causes the problem you see.
> 
> Look at .../redboot/current/src/net/net_io.c:net_io_putc().
> 
> A quick workaround would be to also flush if a '+' is seen. This
> has a downside as it may severely impact download speeds, but at
> least it is functionally correct. YMMV.
> 
> This needs to be fixed with a flush of the output stream prior
> to continuing or stepping the target. Its not clear to me right
> now how this can be done.
> 
> --Mark


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

RE: Ctrl-C interrupt problem.

[Fabrice Gautier]

Well, 

I don't know how, but half the problem is resolved by upgrading to CVS
version.

"half" means that i can't crash gdb with ctrl-C anymore with a native
target.

However the frist half (second ctrl-C is not caught by a remote i386-elf
target) is still there.

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

RE: Ctrl-C interrupt problem.

[Fabrice Gautier]

> -----Original Message-----
> From: Christopher Faylor [ mailto:cgf@redhat.com ]
> Subject: Re: Ctrl-C interrupt problem.
> 
> 
> If there is a problem, it needs to be debugged.

I think the first thing to do is to reproduce the problem on another cygwin
machine.
I'm really surprised to be the first having this problem. Maybe it has
alreadby corrected in a recent gdb snapshot (i'm using gdb 5.0).

> If you debug 
> gdb using
> gdb you (Fabrice) should be able to figure out where the SIGSEGV is
> coming from.  That doesn't necessarily mean that it will be 
> immediately
> obvious how to fix it, of course, but at least you'll have more of a
> clue as to where gdb is dying.

I won't be able to debug anything unless i know how to make so that the
Ctrl-C is interpreted by the debugged gdb and not the debugger. When i hit
ctrl-C the top debugger get the sigint. I've tried to use "signal SIGINT" to
have send the signal back to the debuggee but then the top debugger crash,
with exactly the same sequence, as if the signal I wanted to send back to
the debuggee is caught again byt the top gdb, and so we are in the same
crash situation for the top gdb.

> 
> However, if you are going to be debugging gdb using, gdb, it 
> makes sense
> to rebuild a new windows version from CVS.  The gdb released 
> with cygwin
> net release is somewhat out-of-date, right now.

Well, I'll see that, but actually i'm more interrested in correcting the
somewhat similar bug that appears when I do remote debugging... 

A+
-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

RE: Ctrl-C interrupt problem.

[Fabrice Gautier]

Hi,

I forward here a answer to my problem made by Fernando on the insight mail
list. I posted something on insight list because the problem appeared a
little different.

Following Fernando suggestion, I will continue discussion (it's more a
monologue for now but...) here trying to solve the 'pure' gdb problem first.


I've added my comments and answers to Fernando message...

> -----Original Message-----
> From: Fernando Nasser [ mailto:fnasser@cygnus.com ]
> Subject: Re: Ctrl-C interrupt
> 
> Fabrice,
> 
> I have no idea of what is going on.  At the moment, I do not 
> have the right setup to reproduce this situation (it may
> change in a couple of months, but I guess you
> would not want to wait that long).

Well no for sure,

So if anybody try to reproduce the problem with a similar configuration,
please let us know.

As a reminder, the problem appeared on a NT4+cygwin host connected via TCP
to a i386 target.

I don't think the target is involved. I think the bug is either in the way
cygwin handle ctrl-C and signal, or in the way gdb handle signal in the TCP
case.

I would like to test the case with a linux host, but i don't have any here
right now.
So if somebody try to reproduce the problem with a linux host, please let us
know the outcome.

It maybe a cygwin related problem, so if anybody has heard of a similar
problem with something else than gdb please let us know. 

I also tried to debug my i386-elf-gdb with native cygwin insight but the
problem is that a Ctrl-C will be caught by the native debugger not the
debuggee. 
I have absolutely no experience in debugging a debugger so if you have
tips,please let me know....

(Yes, there's a lot of thing that I need you to let me know)

Thanks
-- Fabrice Gautier

(And now then end of forwarded fernando message:)
 
> You stated debugging it right, so I guess you have a good 
> chance to nail it.
> I suggest you leave the GUI debug to after you figure out 
> what is going on
> in the command line mode. The text mode is an easier execution model.
> 
> As you already know that the interrupt is not caught the 
> second time around,
> all you have to figure now is right.
> 
> At some point, the interrupt handler for Ctrl-C is installed. 
>  If I recall right
> (I have no time to look at this now), it is replaced when the 
> inferior stops and
> has to be reinstalled again.  I would bet that is not being 
> reinstalled.
> 
> Post your findings so we can help you with the next step, but 
> do it at the
> gdb list as (on this first moment) the GUI is not involved.
> 
> P.S.: When you say "target remote" you are using the 
> non-async version,
> so don't worry about the async code in remote.c
> 
> Fernando

RE: Ctrl-C interrupt problem.

[Fabrice Gautier]

Hi,

Anybody have a clue for this??

Does somebody tried to reproduce the problem either with a cygwin host or a
linux host?

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

> -----Original Message-----
> From: Fabrice Gautier [ mailto:Fabrice_Gautier@sdesigns.com ]
> Sent: Friday, November 10, 2000 4:12 PM
> To: GDB (E-mail)
> Subject: Ctrl-C interrupt problem.
> 
> 
> Hi,
> 
> I'm using gdb (insight)  to debug an eCos program running 
> above RedBoot. I
> have a problem when running some test program to make the ctrl-C works
> correctly. The target is a remote i386 PC.
> 
> My program only do some printf (which are sent to gdb as O 
> packets) in a
> loop wiht some delay betwen the printfs. 
> 
> What happenif that I can interrupt with Ctrl-C a first time, then if I
> continue Ctrl-C doesn't work again immediately, i have to 
> wait for another
> printf (and so a O packet) in order to be abble to use ctrl-C again.
> 
> This happen only when using Ethernet not when debugging 
> through serial port.
> 
> I first thought it was a problem  with the gdb stub in 
> RedBoot/eCos. But
> when I "set remote debug 1" i can see that the first time i 
> hit ctrl-C i
> have:
> 
> remote_interrupt called
> remote_stop called
> 
> but the second time (when it doesn't works) i have nothing. 
> So it looked
> like the SIGINT didn't reach the correct gdb function somewhere. 
> 
> 
> I have been looking a bit in the gdb code to figure out what 
> was the path
> when receving a ctrl-C, but i'm not sure which function 
> exaclty is called.
> remote_interrupt or async_remote_interrupt (which) seems to 
> be called when
> it works, but i've also seen some SIGINT handling with 
> handle_remote_sigint
> or request_quit.
> 
> So can someone teach me what happen when i hit ctrl-C in the 
> remote TCP case
> ?
> 
> Thanks
> 
> -- 
> Fabrice Gautier
> fabrice_gautier@sdesigns.com 
> 
> 
> 

Ctrl-C interrupt problem.

[Fabrice Gautier]

Hi,

I'm using gdb (insight)  to debug an eCos program running above RedBoot. I
have a problem when running some test program to make the ctrl-C works
correctly. The target is a remote i386 PC.

My program only do some printf (which are sent to gdb as O packets) in a
loop wiht some delay betwen the printfs. 

What happenif that I can interrupt with Ctrl-C a first time, then if I
continue Ctrl-C doesn't work again immediately, i have to wait for another
printf (and so a O packet) in order to be abble to use ctrl-C again.

This happen only when using Ethernet not when debugging through serial port.

I first thought it was a problem  with the gdb stub in RedBoot/eCos. But
when I "set remote debug 1" i can see that the first time i hit ctrl-C i
have:

remote_interrupt called
remote_stop called

but the second time (when it doesn't works) i have nothing. So it looked
like the SIGINT didn't reach the correct gdb function somewhere. 


I have been looking a bit in the gdb code to figure out what was the path
when receving a ctrl-C, but i'm not sure which function exaclty is called.
remote_interrupt or async_remote_interrupt (which) seems to be called when
it works, but i've also seen some SIGINT handling with handle_remote_sigint
or request_quit.

So can someone teach me what happen when i hit ctrl-C in the remote TCP case
?

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com