Adam Naumowicz wrote:
Is that the proper way to install a signal handler?
Yes.
program testsignal; uses gpc;
Procedure CatchSignal(sig:integer); begin case sig of 2: writeln('Interrupted'); end; end;
var o:TSignalHandler; b:boolean; i:longint; begin InstallSignalHandler(SigInt,CatchSignal,true,true,o,b); for i:=1 to 2000 do writeln(i); end.
I intended it to be a SIGINT handler, but the Ctrl+C in the console doesn't make the CatchSignal proc executed.
Seems to work for me. However, since the main loop is running on after the signal handler is done, the handler's output is hard to see. If you do a Sleep or something in the main program, it's easier to see.
Which system are you on? I think it should work on all Unix compatibles, but probably also DJGPP (but I can't test that here) and Cygwin/Mingw ...
I also don't know why I cannot write SigInt as the case label - the compiler complains that SigInt is not a constant or a variable of an ordinal type (but it is declared as an integer in the GPC unit). Any ideas?
It currently has to be declared as a variable internally (because of some infelicities with C headers), and variables can't be used in case labels.
The second question I would like to ask is about the 'segmentation fault' I get in one of my progs. I thought it can appear if I try to reference something that is already disposed, but this time my debugger says that it appears where a 'goto' statement is in the code. The executable is quite big (1,7 MB without the -s switch) and maybe that is the problem ? Anyone can tell me what actually the 'segmentation fault' is and what can be the reason of it?
Segfault is, in general, any invalid memory access, like (besides what you already mentioned) array overruns, memory corruption, invalid (uninitialized, dangling, overwritten, nil, ...) pointer dereference etc. Hard to tell from outside. gdb might help locating the place where it crashes (though the real problem might be earlier) ...
Frank