SDL_crash -- fatal error catching with user callback

SDL Development
1

I wrote this little library because SDL’s parachute doesn’t let you
generate error reports.

Presently, code is only tested on Windows 7 32-bit built with the most
current version of MinGW. But it does include code that catches POSIX
signals as well, which requires sigaction.
The library compiles to 3kb on that platform with only -s and -O2, which
I think is pretty awesome.

There’s two things I’d like to add at some point: a backtrace wrapper
function that adds support for Windows, and a system-independent context
structure; so that handlers won’t require system-specific code to output
useful information.
But those will take quite a bit more time and effort.

Anyway, attached is a zip archive containing the source code for what
I’ve done at this point.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL_crash.zip
Type: application/zip
Size: 4784 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130319/24766e3d/attachment-0001.zip

2

and I really don’t see much use for it unless
someone is actually building SDL projects in C itself.

Or, phrased another way, is anyone actually programming with SDL in
C, and not some higher-level language that supports exception
handling?

Erm, of course. Actually, I was under the impression most SDL-based
code is written in C/C++, but I have nothing to back that up.

And on that note, I’m shutting up, altho nice flame bait ;)–
driedfruit

3

For anyone wondering, I have continued to work on SDL_Crash, and now have it uploaded to an hg repository on sourceforge.

Since it seemed silly to create a new project for a library as small as SDL_Crash, I created a project with a wider scope at https://sourceforge.net/p/libs4sdl2/

Anyway, SDL_Crash (and whatever else I work on in the future) can be cloned from http://hg.code.sf.net/p/libs4sdl2/code------------------------
Nate Fries

4

Fatal error catching with user callback?? Is this actually something anyone needs?

Or, phrased another way, is anyone actually programming with SDL in C, and not some higher-level language that supports exception handling?________________________________
From: Nathaniel J Fries
To: sdl at lists.libsdl.org
Sent: Thursday, March 28, 2013 11:57 AM
Subject: Re: [SDL] SDL_crash – fatal error catching with user callback

For anyone wondering, I have continued to work on SDL_Crash, and now have it uploaded to an hg repository on sourceforge.

Since it seemed silly to create a new project for a library as small as SDL_Crash, I created a project with a wider scope at https://sourceforge.net/p/libs4sdl2/

Anyway, SDL_Crash (and whatever else I work on in the future) can be cloned from http://hg.code.sf.net/p/libs4sdl2/code

Nate Fries

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

5

Mason Wheeler wrote:

Fatal error catching with user callback? Is this actually something anyone needs?

Or, phrased another way, is anyone actually programming with SDL in C, and not some higher-level language that supports exception handling?

This is 100% pure C, contained in two files (and now taking 7kb).
C++/C#/Java exceptions are not “fatal errors” - they can not only be caught, but any novice programmer can recover completely from a thrown exception.
Fatal errors refer to things like corrupted heaps, stack overflows, illegal instructions, null-pointer errors, etc; which are all errors that are actually more likely in lower-level languages such as C.

SDL_Crash wraps Windows and POSIX methods for catching fatal errors to provide a single portable interface. On Windows in particular, the APIs are poorly documented and rarely used (in fact, the only good source of information on the matter that I’m aware of comes from Matt Pietrick’s ‘Under the Hood’ column in MSJ from the late '90s). On POSIX, these are just signals, which are both well documented and frequently used (see SDL, which uses these to catch fatal errors and exit gracefully, but unfortunately doesn’t provide support for a callback).

I’ve used similar [but C+±restricted] methods before (specifically, in Open-Tibia Server and Yet Another Tibia Client), and found them to be extremely useful in identifying the source of a fatal error.------------------------
Nate Fries

6

…and most high-level languages will catch “fatal errors” and translate them into exceptions.? In Delphi, for example, probably the most common exception encountered while debugging is EAccessViolation–usually as a result of a null pointer dereference–which is caused by the runtime catching Windows error code C0000005 (or its equivalent signal on other OSs) and translating it into an exception.? Stack overflows and illegal instructions are handled similarly.? Heap corruption can be detected by the memory manager if you enable its Full Debug Mode, and it will raise an exception (and write you out a log file full of debug information) if it detects any corruption.

Again, this is the sort of thing that your language ought to be handling for you, and I really don’t see much use for it unless someone is actually building SDL projects in C itself.________________________________
From: Nathaniel J Fries
To: sdl at lists.libsdl.org
Sent: Thursday, March 28, 2013 1:49 PM
Subject: Re: [SDL] SDL_crash – fatal error catching with user callback

Mason Wheeler wrote:
Fatal error catching with user callback? Is this actually something anyone needs?

Or, phrased another way, is anyone actually programming with SDL in C, and not some higher-level language that supports exception handling?

This is 100% pure C, contained in two files (and now taking 7kb).
C++/C#/Java exceptions are not “fatal errors” - they can not only be caught, but any novice programmer can recover completely from a thrown exception.
Fatal errors refer to things like corrupted heaps, stack overflows, illegal instructions, null-pointer errors, etc; which are all errors that are actually more likely in lower-level languages such as C.

SDL_Crash wraps Windows and POSIX methods for catching fatal errors to provide a single portable interface. On Windows in particular, the APIs are poorly documented and rarely used (in fact, the only good source of information on the matter that I’m aware of comes from Matt Pietrick’s ‘Under the Hood’ column in MSJ from the late '90s). On POSIX, these are just signals, which are both well documented and frequently used (see SDL, which uses these to catch fatal errors and exit gracefully, but unfortunately doesn’t provide support for a callback).

I’ve used similar [but C+±restricted] methods before (specifically, in Open-Tibia Server and Yet Another Tibia Client), and found them to be extremely useful in identifying the source of a fatal error.

Nate Fries

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

7

Mason Wheeler wrote:

…and most high-level languages will catch “fatal errors” and translate them into exceptions. In Delphi, for example, probably the most common exception encountered while debugging is EAccessViolation–usually as a result of a null pointer dereference–which is caused by the runtime catching Windows error code C0000005 (or its equivalent signal on other OSs) and translating it into an exception. Stack overflows and illegal instructions are handled similarly. Heap corruption can be detected by the memory manager if you enable its Full Debug Mode, and it will raise an exception (and write you out a log file full of debug information) if it detects any corruption.

Again, this is the sort of thing that your language ought to be handling for you, and I really don’t see much use for it unless someone is actually building SDL projects in C itself.

I see what you mean now. No, if you are using those languages, I don’t see how this could possibly benefit you. This is meant for developers using C or C++ (or even D) to develop with SDL directly.------------------------
Nate Fries

8

…doesn’t C++ have exceptions?? That’s why I was singling C out.? Is there any modern language still in use for serious development that isn’t capable of this, aside from C?

Mason________________________________
From: Driedfruit
To: sdl at lists.libsdl.org
Sent: Wednesday, March 27, 2013 7:16 AM
Subject: Re: [SDL] SDL_crash – fatal error catching with user callback

and I really don’t see much use for it unless
someone is actually building SDL projects in C itself.

Or, phrased another way, is anyone actually programming with SDL in
C, and not some higher-level language that supports exception
handling?

Erm, of course. Actually, I was under the impression most SDL-based
code is written in C/C++, but I have nothing to back that up.

And on that note, I’m shutting up, altho nice flame bait :wink:

–
driedfruit

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

9

Mason Wheeler wrote:

…doesn’t C++ have exceptions? That’s why I was singling C out. Is there any modern language still in use for serious development that isn’t capable of this, aside from C?

Mason

No it does not. All C++ exceptions must be thrown by use of the “throw” keyword, and don’t even need to represent an error at all (for example, GCC’s implementation of C++11’s cooperative thread termination works by throwing an exception, to ensure destructors are called for all objects on the thread’s stack).------------------------
Nate Fries

10

…doesn’t C++ have exceptions? That’s why I was singling C out. Is there
any modern language still in use for serious development that isn’t
capable of this, aside from C?

Mason

You don’t get a C++ exception when there’s a segmentation fault (for example).
And segfaults are quite common errors. I think that a portable way to
handle them (you can’t recover, but you can at least output helpful
debug information) may be quite handy.

Cheers,

  • DanielOn Thu, Mar 28, 2013 at 11:44 PM, Mason Wheeler wrote:

From: Driedfruit
To: sdl at lists.libsdl.org
Sent: Wednesday, March 27, 2013 7:16 AM

Subject: Re: [SDL] SDL_crash – fatal error catching with user callback

and I really don’t see much use for it unless
someone is actually building SDL projects in C itself.

Or, phrased another way, is anyone actually programming with SDL in
C, and not some higher-level language that supports exception
handling?

Erm, of course. Actually, I was under the impression most SDL-based
code is written in C/C++, but I have nothing to back that up.

And on that note, I’m shutting up, altho nice flame bait :wink:

–
driedfruit

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

11

Yes, but all of those languages you’re thinking of are built upon C. When C
crashes, it takes them down with it. SDL_crash appears to provide a portable
way to log a backtrace in production code. It’s not intended to provide
general-purpose exception handling.On 03/28/2013 06:44 PM, Mason Wheeler wrote:

…doesn’t C++ have exceptions? That’s why I was singling C out. Is there
any modern language still in use for serious development that isn’t capable of
this, aside from C?

Mason

From: Driedfruit
To: sdl at lists.libsdl.org
Sent: Wednesday, March 27, 2013 7:16 AM
Subject: Re: [SDL] SDL_crash – fatal error catching with user callback

and I really don’t see much use for it unless
someone is actually building SDL projects in C itself.

Or, phrased another way, is anyone actually programming with SDL in
C, and not some higher-level language that supports exception
handling?

Erm, of course. Actually, I was under the impression most SDL-based
code is written in C/C++, but I have nothing to back that up.

And on that note, I’m shutting up, altho nice flame bait :wink:

–
driedfruit

SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

12

callback
Message-ID: <1364513053.m2f.36342 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

Mason Wheeler wrote:

…doesn’t C++ have exceptions? That’s why I was singling C out. Is there
any modern language still in use for serious development that isn’t
capable of this, aside from C?

Mason

No it does not. All C++ exceptions must be thrown by use of the "throw"
keyword, and don’t even need to represent an error at all (for example,
GCC’s implementation of C++11’s cooperative thread termination works by
throwing an exception, to ensure destructors are called for all objects on
the thread’s stack).

Nate Fries

It doesn’t even matter, anyways. If every language other than C
already provided this then having this library for C would be
perfectly reasonable. If noone ever used it then it would STILL be
reasonable. For that matter, it isn’t part of SDL 2, so it has no
impact on SDL 2.

Mason, I don’t know why you’re fussing over this, but stop. The only
people who have any right to question this are employees of
Sourceforge, since that’s where it’s hosted. You shouldn’t keep
letting yourself get so worked up when something departs from how you
expect things to be.> Date: Thu, 28 Mar 2013 16:24:13 -0700

From: “Nathaniel J Fries”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL_crash – fatal error catching with user

13

One more note - C++ exceptions are frequently disabled in games because of significant performance overhead from supporting them. Given how often SDL is used for games, I think it is meaningful to
assume they MAY not be available, even in C++.On 03/28/2013 07:20 PM, Jared Maddox wrote:

Date: Thu, 28 Mar 2013 16:24:13 -0700
From: “Nathaniel J Fries”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL_crash – fatal error catching with user
callback
Message-ID: <1364513053.m2f.36342 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

Mason Wheeler wrote:

…doesn’t C++ have exceptions? That’s why I was singling C out. Is there
any modern language still in use for serious development that isn’t
capable of this, aside from C?

Mason

No it does not. All C++ exceptions must be thrown by use of the "throw"
keyword, and don’t even need to represent an error at all (for example,
GCC’s implementation of C++11’s cooperative thread termination works by
throwing an exception, to ensure destructors are called for all objects on
the thread’s stack).

Nate Fries

It doesn’t even matter, anyways. If every language other than C
already provided this then having this library for C would be
perfectly reasonable. If noone ever used it then it would STILL be
reasonable. For that matter, it isn’t part of SDL 2, so it has no
impact on SDL 2.

Mason, I don’t know why you’re fussing over this, but stop. The only
people who have any right to question this are employees of
Sourceforge, since that’s where it’s hosted. You shouldn’t keep
letting yourself get so worked up when something departs from how you
expect things to be.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

14

I was under the impression that actually was because on some platforms
(i.e. consoles) exceptions are not really usable at all in the first
place.

2013/3/29, Forest Hale :> One more note - C++ exceptions are frequently disabled in games because of

significant performance overhead from supporting them. Given how often SDL
is used for games, I think it is meaningful to
assume they MAY not be available, even in C++.

On 03/28/2013 07:20 PM, Jared Maddox wrote:

Date: Thu, 28 Mar 2013 16:24:13 -0700
From: “Nathaniel J Fries”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL_crash – fatal error catching with user
callback
Message-ID: <1364513053.m2f.36342 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

Mason Wheeler wrote:

…doesn’t C++ have exceptions? That’s why I was singling C out. Is
there
any modern language still in use for serious development that isn’t
capable of this, aside from C?

Mason

No it does not. All C++ exceptions must be thrown by use of the "throw"
keyword, and don’t even need to represent an error at all (for example,
GCC’s implementation of C++11’s cooperative thread termination works by
throwing an exception, to ensure destructors are called for all objects
on
the thread’s stack).

Nate Fries

It doesn’t even matter, anyways. If every language other than C
already provided this then having this library for C would be
perfectly reasonable. If noone ever used it then it would STILL be
reasonable. For that matter, it isn’t part of SDL 2, so it has no
impact on SDL 2.

Mason, I don’t know why you’re fussing over this, but stop. The only
people who have any right to question this are employees of
Sourceforge, since that’s where it’s hosted. You shouldn’t keep
letting yourself get so worked up when something departs from how you
expect things to be.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

15

My most recent commit includes a modification to Crash_getsym on Windows which is a vast improvement.

Namely, the functions for symbol name lookup that Microsoft provides in imagehlp.dll and dbghelp.dll, while useful for Visual C++ programs with debugging information, are useless for any compiler which does not output Visual C++ debugging files (namely, MinGW and Cygwin’s GCC), and are also useless for most product releases for programs built with Visual C++ (seriously, who ships debugging symbols with their production-ready software?)

The new Crash_getsym will naturally check for these debugging symbols first - afterall, most Windows development is done with Visual C++, and most fatal errors will be found while you’re still developing and have those debug symbols around - but will also check the relevant modules’ function export tables (meaning that the name for any function declared with dllexport should be successfully found with Crash_getsym).

Obviously, it’s still not perfect, but this appears to be a limitation of Windows itself.------------------------
Nate Fries

16

It’s largely a myth nowadays. GCC and CLANG implement exception support with
zero performance overhead. Of SDL supported platforms (listed in
README.Platforms), all but Windows support zero-overhead exceptions. And even on
Windows, take any claims of “overhead” with a grain of salt. If you can even
measure it in your game, then your game is probably spinning at 100% CPU already.On 03/28/2013 11:53 PM, Sik the hedgehog wrote:

I was under the impression that actually was because on some platforms
(i.e. consoles) exceptions are not really usable at all in the first
place.

2013/3/29, Forest Hale :

One more note - C++ exceptions are frequently disabled in games because of
significant performance overhead from supporting them. Given how often SDL
is used for games, I think it is meaningful to
assume they MAY not be available, even in C++.

On 03/28/2013 07:20 PM, Jared Maddox wrote:

Date: Thu, 28 Mar 2013 16:24:13 -0700
From: “Nathaniel J Fries”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL_crash – fatal error catching with user
callback
Message-ID: <1364513053.m2f.36342 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

Mason Wheeler wrote:

…doesn’t C++ have exceptions? That’s why I was singling C out. Is
there
any modern language still in use for serious development that isn’t
capable of this, aside from C?

Mason

No it does not. All C++ exceptions must be thrown by use of the "throw"
keyword, and don’t even need to represent an error at all (for example,
GCC’s implementation of C++11’s cooperative thread termination works by
throwing an exception, to ensure destructors are called for all objects
on
the thread’s stack).

Nate Fries

It doesn’t even matter, anyways. If every language other than C
already provided this then having this library for C would be
perfectly reasonable. If noone ever used it then it would STILL be
reasonable. For that matter, it isn’t part of SDL 2, so it has no
impact on SDL 2.

Mason, I don’t know why you’re fussing over this, but stop. The only
people who have any right to question this are employees of
Sourceforge, since that’s where it’s hosted. You shouldn’t keep
letting yourself get so worked up when something departs from how you
expect things to be.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

17

Fatal error catching with user callback? Is this actually something
anyone needs?

Um, yes.

Or, phrased another way, is anyone actually programming with SDL in C,
and not some higher-level language that supports exception handling?

Um, yes.

Fwiw, Nathaniel, I messed around with building something like this a few
years ago, just in time for Google Breakpad to show up and make it
irrelevant. It’s been stripped for parts and used for other projects, so
it wasn’t a complete waste, but you might as well see if there’s
anything worth stealing, too:

http://hg.icculus.org/icculus/mojocrash/

The README is pretty detailed for what I was trying to accomplish here:

http://hg.icculus.org/icculus/mojocrash/file/def285643924/README.txt

–ryan.

18

Ryan C. Gordon wrote:

Fwiw, Nathaniel, I messed around with building something like this a few
years ago, just in time for Google Breakpad to show up and make it
irrelevant. It’s been stripped for parts and used for other projects, so
it wasn’t a complete waste, but you might as well see if there’s
anything worth stealing, too:

http://hg.icculus.org/icculus/mojocrash/

The README is pretty detailed for what I was trying to accomplish here:

http://hg.icculus.org/icculus/mojocrash/file/def285643924/README.txt

–ryan.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Was not aware of this!

I was aware of breakpad, but…

  1. It’s C++, so C purists (like some of the guys I’ve been deving with lately) won’t touch it.
  2. It’s a rather large program, which isn’t as much of an issue now as it used to be, but still matters to some people.
  3. It’s designed to run in a separate process (why waste the precious resources? Especially on an embedded system such as Android or iOS).
  4. It only supports writing minidump AFAIK, and I’m not a fan.
  5. It won’t work for Windows 2000, which might not be used much anymore, but is still supported in MSDN, and so should still be supported by new software when possible (maybe SDL itself doesn’t even support Windows 2000, though).

Of course, Breakpad has support for platforms I’ve never even touched or researched (like Solaris and ARM), so it is likely far more portable than anything I’m going to write and test on my own for SDL_Crash.

I will certainly see if there’s anything useful I can borrow from MojoCrash! I guess I probably should’ve checked your repository first anyway, it’s got all sorts of useful stuff.------------------------
Nate Fries

19

If you wanted to update mojocrash to support versions of OS X before they added libdl, you might find this useful:

Code:

void *OS_X_dlopen(const char *name)
{
const struct mach_header *hdr = NSAddImage(name, NSADDIMAGE_OPTION_RETURN_ON_ERROR | NSADDIMAGE_OPTION_WITH_SEARCHING);
return (void *)hdr;
}

void *OS_X_dlsym(void *handle, const char *symbol)
{
NSSymbol sym = NSLookupSymbolInImage((struct mach_header *)(handle), symbol,
NSLOOKUPSYMBOLINIMAGE_OPTION_BIND_NOW, NSLOOKUPSYMBOLINIMAGE_OPTION_RETURN_ON_ERROR);
if(sym != 0)
{
return NSAddressOfSymbol(sym);
}

return 0;

}

#define dlopen(name, op) OS_X_dlopen(name)
#define dlclose(handle)
#define dlsym(handle, symbol) OS_X_dlsym(handle, symbol)

The reason dlclose() doesn’t do anything is because the dynamic loader for OS X wasn’t built to unload dynamic libraries, apparently. There’s the API for bundles, but that won’t work for a library that wasn’t built as a bundle (which I’d imagine libSystem.dylib wasn’t).------------------------
Nate Fries

20

FYI, I haven’t actually gotten around to testing the non-Windows version yet, because my only machine right now is a laptop with Windows on it. :P------------------------
Nate Fries