Best practices for logging crash dumps (hxcpp)

[Lars Doucet]

Hey everyone!

I was wondering if there is a 'best practice' out there for outputting "crash dump" log files when your program crashes. Obviously this would vary between targets, so for now I'm limiting my efforts to desktop c++ targets, specifically windows/mac/linux, with a particular focus on windows for now.

I know I can just wrap my main gameplay loop in a try/catch block, but I'm wondering what sort of performance hit I'll take for that, and if there's a better, more low-level way. Is there some super easy-to-capture method like crash errors magically bubbling up to standard out when your program crashes? And if not, is there some better method than the "anti-pattern" of a giant try/catch block at the very top of your program?

Asked another way: on a desktop target, if you needed to output crash log files, how would you do it?

I'd like these not only for my own debugging purposes, but more importantly, I'd like regular users of the program to have them generated on crash, so the program can detect crash logs and ask the user if the program can email them back to me, so I can automatically get crash reports "from the wild."

I also happen to be using OpenFL and HaxeFlixel, in case there's any features in those two frameworks that aid this process.

Thanks for your time.
Lars Doucet
Level Up Labs

[David Elahee]

Hi Lars,
Here we use the uncaught exception handler for this but it Is not deployed on a very wide spread products.

Nesting entry points in try catch blocks shouldn't suck too much perf either...

Real problem is that some targets won t give you callstacks...

Good luck.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Lars Doucet]

Thanks David!

Uncaught Exception Handler is an OpenFL feature, yes? I tried to use it, but I don't think I'm doing it right. Where should the listener for it be attached?

As for some targets not giving callstacks, which ones in particular have you had trouble with?

[David Elahee]

Uncaught exception handler is an event listener, it is a flash feature and we tried to have the same use pattern as flash in ofl native.

If it is not sufficient I ll give you a snippet Monday. We use it to intercept and pop a form in twinoid app.

If it does not suffice, You will have to resort to more aggressive stack and exception interception using native code.

As for readable call stack for example the flash player used to not give one in release build but I believe there are now a trigger to have some.

If I were you, I would add a save/replay system to your game, try catch the update/uncaught error listener, do everything on update (no out of frame async) and just send myself a replay/save with the dump, for your game scale it will be an awesomely more easy solution I dare think. :)

Uncatchable bugs are C bugs but they are rare enough...

If you want a more detailed approach, ping me out of the list.

Xoxo

[Lars Doucet]

Cool, thanks very much.

It would be nice to see a snippet for using Uncaught Exception Handler. I tried to use it the other day but I couldn't find the right object to attach the listener to where it would catch the errors I was generating (or perhaps I was doing it wrong). Do you just attach it to Lib.current? Lib.current.stage? The Main class that extends Sprite?

I'm using HaxeFlixel, which does indeed come with a built-in replay system, the scheme you mention is exactly what I was planning on doing, on crash the game would write the following out:
-- A copy of the game's save information on program startup (save and configuration files)
-- Replay data for the player from the start of the program
-- Crash log with as much detailed information as possible

And then email that back to the developer (ie me).

[David Elahee]

Ok digg it...wow nobody can find it on its own...

flash.Lib.current.loaderInfo.uncaughtErrorEvents.addEventListener( flash.events.UncaughtErrorEvent.UNCAUGHT_ERROR, onErrorEvent );

Don t spend too much time on native crash dump, from experience tracking call stack hex address in disassembled asm is barely useful ( or you will wish so...) and
Don't forget to retrieve user device hardware info (Motorola square screen you know...).

Good luck pal !

--

[Lars Doucet]

Great! THAT's what I was looking for.

Device hardware info can be grabbed from OpenFL Capabilities API, yes?

[David Elahee]

Capabilities + gl.getParameter + gl.getExtensions + some native ones like android build.

Maybe you should write a blog post on all that.. I ll accept cookies and beta code as payment :D

Xoxo

Ps: ship us a nice one !
Pps:  did I mention beta code !)

[Lars Doucet]

I'll let you know how it goes!

You received this message because you are subscribed to a topic in the Google Groups "Haxe" group.

For more options, visit https://groups.google.com/d/optout.

--
www.fortressofdoors.com -- Games, Art, Design

[Lars Doucet]

Here's an early proof of concept:
https://github.com/larsiusprime/crashdumper

[David Elahee]

Nice :)