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/ --------------------------------------