How to diagnose Dartium "Aw, Snap!"

[Rupert Key]

TL;DR How best to diagnose and report an as-yet undiagnosed "Aw, Snap!" crash from Dartium?

I have a [presently] repeatable "Aw, Snap!" crash from Dartium (IDE build 8370).  I'd like to feed-back useful info but I'm not sure how best to. 

I'm trying to trace the causal factors but so far I haven't been able to narrow down for a reproducible test-case -- it only occurs in one particular case in the game I'm developing using DartBox2D (*1).

The problem does not happen when the same code is dart2js'd and run in Chrome (or on Android browser/Chrome).  Obviously, this is my expected first distribution channel so this bug is ignorable however, while developing, it's kind'a annoying to have to keep avoiding the problem case (*1).

Adding breakpoints /appears/ to remove the problem (hinting timing related?).  Obviously, this makes debugging annoying and has, pending better suggestions, reduced me to sprinkling good old print() commands :-\  Obviously, I fear these may also have Heisenberg effects (see below).  There's definitely a lag between "Aw, Snap!" appearing and the logging finishing appearing (I've waited perhaps 10s for it to finish).  It looks like Dartium-DartIDE log output is run through a local socket.  Question is: can I rely upon Dartium sending all logged output up to the crash?  (no print() calls being lost due to buffering.)

...(continues debugging)...

Well, my print() calls have just indicated the error moved back to somewhere I'd already ruled-out so looks like either my logging isn't reliable or it's timing related :-(

The obvious next move seems to be to try with an instrumented or crash-dump capable binary.  Sorry to say I don't have time to build from source myself.  In the absence of better diagnosis techniques, could someone send me one?  (Linux or Windows -- it reproduces on both)  Alternatively, I could privately send someone my projects?

*1: For the curious and recognizing it's not a particularly useful description, the crash occurs when my game's rope's sticky end touches a 'static' object (wall).  It doesn't occur when it touches a 'dynamic' object (boxes).  My print() diagnosis described above hints the crash is occurring within DartBox2D's RevoluteJoint.solvePositionConstraints() -- these hold rope segments together.  Obviously, whatever this dodgy dart code, it shouldn't be able to take out the browser!

One side note: I'm using Canvas and rendering debug graphics with line-drawing calls.  Current diagnosis /suggests/ we're dying in logic (rather than drawing code) but if the log buffering concern above is true, perhaps this might better explain the crash?

Thanks in advance for any thoughts, Rupert

[Seth Ladd]

Hi Rupert,

Sorry you ran into this, thanks for bringing it up. We can try a few different things. Do you have a reduced test case for us? If you are using Box2D, we should check if the stand-alone VM crashes or if this is indeed a Dartium thing.

Getting to the smallest bit of code that reproduces the crash is the biggest help for us. We'd really appreciate if you can reduce the condition down. Once you do, please open a bug and ping the list again.

Thanks,

Seth

[Anton Muhin]

Rupert, all,

sorry for late response.

Unfortunately, as of now we cannot collect crash dumps for you.

If your problem is easy to reproduce and you can share with us your
code, please, just file a bug at code.google.com/p/dart or send
details to this thread and I'll file bug for you.

Thanks a lot for trying Dart out.

yours,
anton.

[Bernhard Pichler]

Rupert, i just found your comment. It's pretty old but did you ever found a solution for this problem?

I work with the latest Dart Editor and have the same issue. I also tried to narrow it down but failed. It is interesting that you worked with Canvas, same for me - so maybe it's related to the Canvas element. This is my bug report: http://dartbug.com/5586

Did the problem disappear or do you still see crashes? Maybe you found a workaround?

[Rupert Key]

Hi, Bernhard

Sadly IIRC I worked around the problem. Specifically since I wasn't intending keeping DebugDraw (which uses lots of slow line draws), I advanced implementing my drawImage()-based sprite system (which didn't & doesn't see this problem at all!?).

If you'd like, later in the week I can re-enable and test debug graphics (have I mentioned how much I love the #ifdef-like ability of dart2js with static const bools :-) ). Obviously I haven't checked lately but it's fundamentally the same so might reproduce?

Perhaps usefully, I remember reading that "Aw snap"s are/were likely with bad(?) breakpoints and the workaround was delete *all* breakpoints and retry. This /could/ have been relevant for mine. Perhaps worth a try? (though reading your bug, I see you may already be investigating this sort of thing?)

A while back I noticed (a) a thread on diagnosing "Aw snap"s including (b) that Chrome command-line output can now be shown.  Perhaps enable this in case something shows there? (sorry don't recall other details... )

Lastly, did the Dart/Editor team have thoughts on logging buffering? (from my original e-mail) At least this knowledge would allow us to narrow things down. (it seemed there must be buffering since the bug moved so much)

HTH & sorry can't be of more assistance! Good luck!
R.

[Bernhard Pichler]

Hi, Rupert

Thanks for the reply and your thoughts. In the meantime the Dart team was able to fix the bug! Hurray!

http://code.google.com/p/dart/issues/detail?id=5586

Bernhard