Unhandled exception on MAC

MacOSX and iOS
1

Hello,

I am not very sure whether this problem has been discussed here before.I am very sorry if it has already been discussed.

The issue :

I have some serious clean up work to do before my JUCE application quits.This is fine as long as my application quits normally.What if it crashes ? I cannot afford NOT to do the clean up in any case.

Yes, the code has to be “exception handled”, but in an event of an unhandled exception it becomes an issue.

I tried over-ridding the “unhandledException” function from the JUCEApplication class.In the event of any crash ( i had to force generate this crash :slight_smile: ) the control comes to this function on Windows and I could safely do my clean up.

But on MAC, the control just does not come to this function.Is this known behavior ? How do I then do the required clean up in the event of a crash on MAC ?

Any help in this regard would be greatly appreciated.

Thanks in advance,
Anil.

2

Yes, it’s true that you don’t get the same exception catching abilities on the mac.

On the other hand, that’s not a bad thing, because it encourages you to be more vigilant about crashing! It’s actually a bit worrying on windows that you can do something nasty and carry on with possibly corrupted memory everywhere…

3

Hello Jules,

What intrigues me more is the reason behind this behavior ? Is it to do with gcc or the way the MAC event loop is handled ?

And for your prompt response as usual, thanks very much.

Regards,
Anil

4

I’m actually not entirely sure if it’s because of the compiler or the OS. (It’s nothing to do with events, though).

5

Jules,

Sorry if i miscommunicated my intention.When I said," event loop" I meant the OS handling and not the events themselves.

If you get any heads up , please let me know as well.It would be greatly appreciated.

Regards,
Anil

6

[quote=“Anil”]Hello,

I am not very sure whether this problem has been discussed here before.I am very sorry if it has already been discussed.

The issue :

I have some serious clean up work to do before my JUCE application quits.This is fine as long as my application quits normally.What if it crashes ? I cannot afford NOT to do the clean up in any case.

Yes, the code has to be “exception handled”, but in an event of an unhandled exception it becomes an issue.

I tried over-ridding the “unhandledException” function from the JUCEApplication class.In the event of any crash ( i had to force generate this crash :slight_smile: ) the control comes to this function on Windows and I could safely do my clean up.

But on MAC, the control just does not come to this function.Is this known behavior ? How do I then do the required clean up in the event of a crash on MAC ?

Any help in this regard would be greatly appreciated.

Thanks in advance,
Anil.[/quote]

Yeah, the world of unix…

You set up a signal handler:

#include <signal.h>

pid_t mainpid;

void finish(int sig){
  if(getpid()==mainpid){
     fprintf(stderr,"Hey, I was shut down!\n");
 }
  exit(0);
}

int main(void){
  mainpid=getpid();
  signal(SIGINT,finish);
  ...
}

The above is good enough for most uses, but if you are really serious, you fork() your program, and let the parent monitors the status of the child.
[/u]

7

kjetil,

Wow ! A cool idea…But my doubts on this solution :

1 ) Since START_JUCE_APPLICATION is used , there is no access to the main function directly in a JUCE application , so where do I actually register the handler for SIGINT.In App::initialise ?

2 ) Now think of a scenario where I am loading an image using the ImageFileFormat::loadFrom function where the image file actually does not exist.So the image is NULL.What happens when I call image->getHeight() ( or any other function on any NULL pointer ) .Will it come to the handler ?
I tried and it did not work.

( This is of course in the backdrop of the assumption that the exception is unhandled by the app )

Regards,
Anil.

8

IMHO I’d recommend you spend your time fixing the cause of the crashes rather than trying to limp along after they’ve happened!

9

Further to my previous post, please note that I am NOT trying to equate a null pointer operation with SIGINT.

I am just trying to say that the control does not come to the handler, whatever the signal be.

Jules, I more than hundred percent agree with you and I am already on my way to make my code exception safe and hence do my clean up as well.

I just wanted to explore other possibilities in the meantime .( so that at least the critical clean up happens )

Regards,
Anil.

10

[quote=“Anil”]kjetil,

Wow ! A cool idea…But my doubts on this solution :

1 ) Since START_JUCE_APPLICATION is used , there is no access to the main function directly in a JUCE application , so where do I actually register the handler for SIGINT.In App::initialise ?
[/quote]

You don’t have to do it in main.

No it doesn’t. Try SIGSEGV instead of SIGINT. (But you need a SIGINT handler as well, since that is the way to signal the process to stop)

I’m not a mac expert. But since its a UNIX, its likely, that you can allways kill a program just by calling “kill -9 ”. And when you do that (which quite often is done by the user, since its a safe way to ensure the process stops), there is no way your program can know it has been shut down.

In that scenario, you have to use fork() or other mechanisms where another process monitors your program.