Porting from TRU64: structured exception handling

[arunava]

Hi All,
I am migrating an application from TRU64 to HPUX. The source includes excpt.h and uses the function "exc_raise_signal_exception" as a signal handler for SIGSEGV. HP UX doesnt have this header file. Can any one pls guide me what is the alternative. One alternative could be writing a custom signal handler that throws exceptions.
Thanks in advance .....

[Dennis Handly · Accepted solution]

This doesn't exist on HP-UX.

>could be writing a custom signal handler that throws exceptions.

Also the C++ Standard doesn't support throwing from a signal handler. While not disallowed by the aC++ runtime, the results are unpredictable.

[arunava]

Hi Dennis,
Thanks for the reply. Seems I need to take out the signal handling out of the existing code. Also, I need to compile the source for Itanium. I also read your article : http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=c5080055abe021100055abe02110275d6e10RCRD
Acc to your article, throwing out of a signal handler is not at all possible on itanium.

So was wondering, is there any other way I can simulate the functionality on hp ux. Will try this: catch the signal, set a flag and return from the signal handler. And based on the flag throw an exception. Will try to code this and post the results.

[Dennis Handly]

>Seems I need to take out the signal handling out of the existing code.

That's the only way to be supported.

>I need to compile the source for Integrity.

Things have changed since that was first written but it is still unsupported.
I guess it depends on close you want to skate to thin ice. ;-)

>is there any other way I can simulate the functionality on HP-UX? Will try this: catch the signal, set a flag and return from the signal handler.

No. Only by trying a throw and hope your opt level, where it aborts isn't too high.
Otherwise if you return you will get the trap again.

[arunava]

Hi Dennis,
I tried writing the following code with setjmp/longjmp. Assuming that I call the setjmp/longjump at the correct places, what other dangers could happen with this code. Thanks again for the replies ....
--------------------------------------
#include
#include
#include

int error=0;
jmp_buf jbuff;

struct sigaction foo;

void hand_x(int sig, siginfo_t *siginf, void *ptr){
printf("inside hanldler\n");
error =1;
longjmp(jbuff,sig);
}

main()
{
struct sigaction foo = {hand_x,0,0};
sigaction(SIGSEGV,&foo,0);
char * a= "hello";
try
{
setjmp(jbuff);
if(error == 1)
throw 1;
a[10]='a'; //Segmentation fault here
}
catch(...)
{
printf("exception raised\n");
}
}

[Dennis Handly]

>I tried writing the following code with setjmp/longjmp.

If you read the Release Notes, you'll also find that's not supported either with C++.
http://docs.hp.com/en/B3901-90031/ch05s08.html#v2649446
http://docs.hp.com/en/B3901-90031/ch05s08.html#v2649455

Your variable "error" isn't volatile and since setjmp returns a value, you should test that and not "error".

[arunava]

Hi Dennis, thanks for all the replies.
We are removing the signal handling from code, although this means at runtime we are going to get lots of dumps !!

[Dennis Handly]

>although this means at runtime we are going to get lots of dumps!

Do you know why you have bad pointers?

[arunava]

Hi ..

>>Do you know why you have bad pointers?
No .. Even going through the tons of source doesnt help.. I guess we have to fix the cause of the dumps as and when we get them.

Thanks a lot ..

[Dennis Handly]

>I guess we have to fix the cause of the dumps as and when we get them.

You didn't fix these completely when running under Tru64?

[arunava]

On TRU64, the signals (SIGSEGV) were converted to exceptions using the function "exc_raise_signal_exception". And there are huge try..catch blocks that i hav been trying to understand. Also, the code is written by guys who are no longer around. So I cant know in which part of the code or in what scenario, was the programmer expecting the signal. So will try to run and hope I find all causes of the signal.

[Dennis Handly]

Are you suggesting that the program got those signals all of the time? Or that try/catch was just for belts and suspenders type of programming?

[arunava]

>>Are you suggesting that the program got those signals all of the time?
Yes I think so ...
>>Or that try/catch was just for belts and suspenders type of programming?
Not sure about this. Could be a third party lib that caused lots of sigsegv. So .. as of now going through the code .... Thanks for all the help ...