- Online Community Forums » Installation, Setup & Configuration » What happens with un-destroyed objects when a program encounters SIGSGEV?

This thread is locked; no one can reply to it. rss feed Print
What happens with un-destroyed objects when a program encounters SIGSGEV?
Member #18,873
December 2020

I have a pretty simple program just opening a new window and drawing a bitmap, and I had been running into weird hang issues until I realized that I was calling al_load_bitmap() on a misspelled file name.

Knowing that my question is now what was happening when it failed to load that bitmap? GDB shows that it hits a SIGSEGV when trying to draw the bitmap, but the process doesn't seem to close, and the display (as well as presumably the timer and event queue) gets stuck open. Is Windows not capable of cleaning this stuff up if it isn't destroyed?

Member #3,861
September 2003

Well. Are you checking the return of load_bitmap ? says it's returning NULL if a problem occurs.

My guess is that you're not checking the returned value and directly try to blast it on screen, hence the sigsegv.

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Member #18,873
December 2020

The question isn't about the actual return, because I understand what the issue is now. I just wanted to know what was actually happening after the SIGSEGV was received, but all the allegro components seemed to still "exist".

Peter Hull
Member #1,136
March 2001

If your program's hit an error then all bets are off, anything 'could' happen. In your case, as soon as you try to dereference the null pointer that al_load_bitmap returned, your program will be signalled with SEGV. If you have a handler installed, it will be called, and you can try to do something to recover - though in practice there's not usually much can be done. If you don't have a handler, your program will be killed. Any open files etc. will be closed and all its memory will be returned to the system.

However, if you're running in a debugger, the debugger will handle signals for you, and will pause the program so you can examine memory, get a back-trace or whatever. Once you've got the info you need, you can end the process manually (`kill` in GDB) and everything should get cleaned up as before.

Sometimes it's not so neat and your program will just get stuck (apparently) doing nothing. This is, in my experience, because you've passed some garbage memory to an Allegro function. A lot of allegro objects (bitmaps, displays, ...) have virtual function tables, which are arrays of pointers to functions. If you send in an invalid pointer, the flow of execution will just jump off to some random place in memory. If you're running in the debugger you can usually break in (`ctrl-C` in GDB), and in that case you'll see a weird back-trace starting from code you don't recognise.

Hope that helps?

Member #5,749
April 2005

Is Windows not capable of cleaning this stuff up if it isn't destroyed?

As Peter Hull mentioned, getting a segfault when running your program with GDB will cause it to freeze so you can get to debugging.

Normally (when not using a debugger), the process will just be killed. When this happens, the vast majority of modern OSes will then clean up the process's memory for you - including the heap and data on the GPU. File handles that the process left often can still be a problem, though they're also normally handled pretty well these days.

Website. It was
This isn't a game!

Edgar Reynaldo
Major Reynaldo
May 2007

You might also want to think about what happens when an exception is thrown. The stack unwinds, and destructors are called up to the point where the exception is caught.

Go to: