This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Ctrl-C interrupt problem.


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.
> 
[...]

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]