Hello, I have two questions: Is that the proper way to install a signal handler?
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. 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?
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? Thanks in advance. Regards, Adam Naumowicz
-------------------------------------- WWW: http://math.uwb.edu.pl/~adamn/ --------------------------------------
On Mon, 6 Aug 2001, Adam Naumowicz wrote:
Hello, I have two questions: Is that the proper way to install a signal handler?
program testsignal; uses gpc;
Procedure CatchSignal(sig:integer); begin case sig of 2: writeln('Interrupted');
{ <=====================} otherwise {do nothing} { this may help if sig is} { not guaranteed to be 2}
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. 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?
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? Thanks in advance. Regards, Adam Naumowicz
WWW: http://math.uwb.edu.pl/~adamn/
On Mon, 6 Aug 2001, Ernst-Ludwig Bohnen wrote:
On Mon, 6 Aug 2001, Adam Naumowicz wrote:
Hello, I have two questions: Is that the proper way to install a signal handler?
program testsignal; uses gpc;
Procedure CatchSignal(sig:integer); begin case sig of 2: writeln('Interrupted');
{ <=====================}
otherwise {do nothing} { this may help if sig is} { not guaranteed to be 2}
Actually it doesn't make much sense as the InstallSignalHandler should install a new install handler for a fixed signal (in my case for SIGINT=2). I just put the case statement as if the CatchSignal was prepared as a universal handler.
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. 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?
Regards, Adam Naumowicz
-------------------------------------- WWW: http://math.uwb.edu.pl/~adamn/ --------------------------------------
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
On Mon, 6 Aug 2001, Frank Heckenbach wrote:
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 ...
Thanks very much, I tested it under Solaris. Sorry, now I wrote 'halt' in the handler and now I see it's working. It's the first time I wish I had a slower machine :-) Can you simply explain what is the meaning of the boolean parameters of InstallSignalHandler ? Can one of them prevent from appearing the '^C' in the console (calling the default handler I suppose)?
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) ...
I used the debugger from RHIDE and it seems that the error occurs when calling a 'goto' statement. I actually tried to comment the block of FreeMems prepending it, but the error still existed in the same place. So I suppose the most probable reason is some memory corruption during execution of the program ? Thanks once again, Adam Naumowicz
-------------------------------------- WWW: http://math.uwb.edu.pl/~adamn/ --------------------------------------
Adam Naumowicz wrote:
Can you simply explain what is the meaning of the boolean parameters of InstallSignalHandler ?
Restart means whether interrupted system calls should be retried after the handler (not supported on all systems AFAIK). UnlessIgnored means you only want to set the handler if the signal isn't ignored, anyway.
Can one of them prevent from appearing the '^C' in the console (calling the default handler I suppose)?
I suppose (can't make sure right now) this is done by the terminal handler before actually generating the signal. So you't probably have to change the terminal settings (see termios, but there's no general Pascal interface -- there's the procedure SetInputSignals; it's quite specialized, just for emulating some routine in the BP compatible Dos units, but maybe it might help you).
I used the debugger from RHIDE and it seems that the error occurs when calling a 'goto' statement. I actually tried to comment the block of FreeMems prepending it, but the error still existed in the same place. So I suppose the most probable reason is some memory corruption during execution of the program ?
I could likely be corruption of data on the stack (which overwrites some frame pointer used after the goto or something). If it's a non-local goto, it could well also be a GPC bug, since these are quite tricky and not very well tested ...
Frank
On Mon, 6 Aug 2001, Frank Heckenbach wrote:
Adam Naumowicz wrote:
Can you simply explain what is the meaning of the boolean parameters of InstallSignalHandler ?
Restart means whether interrupted system calls should be retried after the handler (not supported on all systems AFAIK). UnlessIgnored means you only want to set the handler if the signal isn't ignored, anyway.
I see.
Can one of them prevent from appearing the '^C' in the console (calling the default handler I suppose)?
I suppose (can't make sure right now) this is done by the terminal handler before actually generating the signal. So you't probably have to change the terminal settings (see termios, but there's no general Pascal interface -- there's the procedure SetInputSignals; it's quite specialized, just for emulating some routine in the BP compatible Dos units, but maybe it might help you).
That is really of not big importence for me, just asked to check if there is a easy possibility to do that 'cosmetic' stuff.
I used the debugger from RHIDE and it seems that the error occurs when calling a 'goto' statement. I actually tried to comment the block of FreeMems prepending it, but the error still existed in the same place. So I suppose the most probable reason is some memory corruption during execution of the program ?
I could likely be corruption of data on the stack (which overwrites some frame pointer used after the goto or something). If it's a non-local goto, it could well also be a GPC bug, since these are quite tricky and not very well tested ...
The code works good with Delphi, Kylix, FPC and it used to work with BP, however the memory layout is different in all that cases and it is not in fact a good proof, that the error is caused by GPC ... The problem is that the code is so large and unfortunatelly filled up with tricks that gave some optimalisation 15 years ago. Thanks, Adam Naumowicz
-------------------------------------- WWW: http://math.uwb.edu.pl/~adamn/ --------------------------------------
Adam Naumowicz wrote:
Is that the proper way to install a signal handler?
Yes.
Doesn't he need something to indicate C calling conventions for the handler? Or does GPC install a default handler that calls user handlers in the pascal convention?
Marco van de Voort (MarcoV@Stack.nl or marco@freepascal.org)
Marco van de Voort wrote:
Adam Naumowicz wrote:
Is that the proper way to install a signal handler?
Yes.
Doesn't he need something to indicate C calling conventions for the handler? Or does GPC install a default handler that calls user handlers in the pascal convention?
GPC uses the same calling convention as C by default (which makes these and other things so easy :-).
Frank