Well. Are you checking the return of load_bitmap ?

https://www.allegro.cc/manual/5/al_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.

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?

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.