In article <11************ **********@80g2 000cwy.googlegr oups.com>
subramanian <su************ **@yahoo.comwro te:
>void SIGSEGV_handler (int num);
int main(void)
{
char *str = NULL;
signal(SIGSEGV, SIGSEGV_handler );
strcpy(str, "TEST");
printf("After signal handling\n");
return 0;
}
void SIGSEGV_handler (int num)
{
printf("SIGSEGV _handler called with the argument %d\n", num);
return;
}
This code is full of simple mechanical errors (does not compile
because, e.g., SIGSEGV is not defined at all, since you did not
"#include" the appropriate headers). If you fix those, however,
the code remains undefined by the C Standards, and full of more
important errors even on those systems where the behavior *is*
predictable.
In particular, those systems that (a) somehow catch the invalid
first value in the strcpy() call and (b) actually enter your
SIGSEGV handler in a useful way will generally either:
- reset the SIGSEGV handler to the default ("terminate program
with core dump" behavior), or
- temporarily defer additional SIGSEGVs, keeping the handler
installed and re-enabling it upon return from the handler.
They will also provide -- in a manner that cannot be obtained using
the simple Standard C handler shown above -- additional arguments
pinpointing (or perhaps just "generally getting close to", depending
on the hardware) the instruction pointer at the time the signal
occurred. To get this information you should[%] use a different
call, such as the POSIX sigaction(), to install the handler. Then,
inside the handler, you may be required to modify the provided
machine state -- which is rather naturally machine-dependent, i.e.,
will differ on an Intel vs a PowerPC vs a SPARC vs a MIPS -- if
you intend for the program to do anything useful upon returning
from the handler. If you leave the state unchanged, there is a
significant possibility that returning from the handler will take
you back to the faulting instruction, which will just immediately
fault again, calling the handler again (assuming you have set the
correct options for sigaction() or whatever the correct call may
be), and leading to an endless loop that, aside from the complexities
of signal handling, is effectively identical to:
for (;;)
;
Hence, the code you really need is OS- and machine-dependent and
cannot be written in portable C. You therefore need some other
newsgroup(s), such as comp.unix.progr ammer, comp.os.linux.* ,
comp.os.ms-windows.*, etc., or (probably better) the documentation
for your hardware, compiler, and/or operating system.
[% It may or may not be possible to get the extra information when
using the Standard C "signal" interface, but it is probably unwise
to attempt this unless the documentation for your system specifically
says to do so. In some cases, the extra information is available
more or less "by accident", and a future version of the system may
move it elsewhere without warning.]
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it
http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
