[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:Welcome to the Digital UNIX Conference
Moderator:SMURF::DENHAM
Created:Thu Mar 16 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:10068
Total number of notes:35879

8841.0. "Continuing execution after SEGV?" by CADSYS::BOGDANOV () Fri Feb 14 1997 17:45

Hi,
	Is there is a simple way to force computer to execute a next instruction
after segmentation violation from a signal handler. Basically I want to
increment pc to skip a faulty instruction without updating Istream.
T.RTitleUserPersonal
Name
DateLines
8841.1why do you want to do this?VAXCPU::michaudJeff Michaud - ObjectBrokerFri Feb 14 1997 21:547
	Why don't you explain why you want to do this and we can
	proceed from there.

	The only supported (and relatively portable, at least to
	other UNIX platforms) way I know of to recover from a
	SEGV or BUS error is to use setjmp and then longjmp from
	the signal handler.
8841.2sc_pc in sig_context structureSTEVEN::hobbsSteven HobbsSat Feb 15 1997 17:4614
The -speculate optimization option on the various compiler command
lines uses an additional supported way to continue after a SEGV or BUS
error but that is probably no useful in the current situation.

I often write code that continues from FPE faults.  All I need to do
is increment by 4 the sc_pc field in the sig_context structure before
returning from the signal handler.

Note: I must be careful when continuing from FPE signals since some
signals are faults and others others are traps.  Only the faults need
sc_pc incremented.  On Unix, both SEGV and BUS are faults but if you
are writing code that will run on both Unix and VMS then you should be
careful.  I believe that the BUS exceptions on VMS caused by
misaligned memory references are synchronous traps rather than faults.
8841.3CADSYS::BOGDANOVMon Feb 17 1997 13:1615
.1
>	Why don't you explain why you want to do this and we can
>	proceed from there.
	
	I need a memory probe mechanism where request, address  and data is
known to the program. I can analyze a current instruction to see whwt is going
on. Then the program should continue, returning normally from a handler.


.2 
	Thank you for an idea. I did not expect that incrementing pc in the
sig_context is going to work but looks like it does. Is it a reliable mechanism
on Dunix?

>> Serge
8841.4sigreturnCADSYS::BOGDANOVMon Feb 17 1997 17:3222
I think that I've found an answer in man pages. The sigreturn routine should be
able to help. 


  #include <signal.h>
  int sigreturn(
          struct sigcontext *scp) ;

PARAMETERS

  scp       Points to a sigcontext structure whose members contain the pro-
            cessor state to be restored. The contents of the sigcontext
            structure should have been previously obtained by entry to a sig-
            nal handler or by the setjmp() or sigsetjmp() function.

DESCRIPTION
  The sigreturn() function restores the processor state of the calling pro-
  cess from a sigcontext structure...

Thanks

>> Serge