www.delorie.com/djgpp/bugs/show.cgi   search  
Bug 000044

When Created: 12/16/1995 12:03:26
Against DJGPP version: 2.00.beta3
By whom: Xavier.Leroy@inria.fr
Abstract: When trapping SIGINT, first ctrl-C generates signal, but not subsequent ctrl-C
Consider the following program:

#include <signal.h>

volatile int finished;

void brkhandler()
{
  printf("Ctrl-C, huh?\n");
  finished++;
  signal(SIGINT, &brkhandler);
}

main()
{
  int count;
  signal(SIGINT, &brkhandler);
  finished = 0;
  count = 50000000;
  while (count >= 0) count--;
  printf("Ctrl-C pressed %d times\n", finished);
  return 0;
}

Pressing ctrl-C once during the execution of the program prints as expected:
	Ctrl-C, huh?
	Ctrl-C pressed 1 times

Pressing ctrl-C twice (at 1 sec interval) prints:
	Ctrl-C, huh?	   [first ctrl-C]
			   [nothing is printed after second ctrl-C]
	Ctrl-C pressed 1 times
	^C		   [this seems to be printed by DOS]

It looks as if the second ctrl-C did not generate the SIGINT signal,
even though it did not terminate the program either.
I don't think this is the classic race condition between signal delivery
and the call to signal() in the sighandler, because it happens even if the 
two ctrl-C are well separated (1 second delay). 

[The DPMI host used is Windows 3.1, in case it matters.]

Note added: 12/16/1995 17:18:07
By whom: sandmann@clio.rice.edu
This program works as V2 is designed, which probably needs a bit of
explaination.  Because of the design of DPMI, it is impossible to
transfer control from a hardware interrupt or real-mode call back.
When an external event occurs, we have to get the program's attention
somehow (so control can be re-directed).  This is done in V2 by 
making any memory access to the program space generate a fault.
This test program does not touch any memory while waiting, so only
sees a single pending CTRL-C at the end of the loop.  In virtually
any real program, you will touch memory occasionally and then be
re-directed.
If you compile the program without optimization, you see it works as
intended.  If you make the decrement wait count a volatile
variable, it will also work.  You just have to touch memory!

Note added: 12/20/1995 14:49:19
By whom: Xavier.Leroy@inria.fr
Thank you for the explanation of how signals are implemented in DJGPP.
However, I'm afraid this does not explain what happens.
The program was actually compiled without -O, and accesses the stack twice at
each iteration (I checked that with gcc -S). Making more memory accesses
inside the loop, as you suggested, did not change the observed behavior.
Besides, the first ctrl-C is perfectly well detected; it's only the
following ctrl-C's that got ignored till the next I/O operation.

Note added: 12/29/1995 16:15:00
By whom: sandmann@clio.rice.edu
Try it with beta 4.  Your test program worked fine for me with my
patched beta 3 area.  If it doesn't work with beta 4, I'm at a loss to
explain it.

Note added: 01/03/1996 15:00:56
By whom: Xavier.Leroy@inria.fr
I have just tried with beta 4 and everything works as expected. Great!
Many thanks for the fix.

Closed on 01/23/1996 21:52:43: problem gone in beta4
By whom: dj@delorie.com



  webmaster   donations   bookstore     delorie software   privacy  
  Copyright 2010   by DJ Delorie     Updated Jul 2010