Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crash with debuggable snapshot on programming error e.g. ReferenceError #336

Closed
dckc opened this issue Mar 12, 2020 · 4 comments
Closed

Comments

@dckc
Copy link
Contributor

dckc commented Mar 12, 2020

I was bouncing some ideas about snapshots (Agoric/agoric-sdk#511) around with @kriskowal and he said that based on experience with node in production, it would be handy for a js engine to crash and leave a snapshot when it hits reference error... for example, you might have thousands of nodes and every once in a while one of them hits a sporadic bug.

I suggested that normal unix core dumps might work fine; I've had reasonably good luck just using gdb to debug xs work.

This is not a microcontroller use-case, so perhaps it belongs in https://github.com/agoric-labs/moddable , but issues aren't turned on there.

@phoddie
Copy link
Collaborator

phoddie commented Nov 17, 2020

The new snapshot mechanism would work for this in many cases. It wouldn't work if there are pending promises. Though... if you weren't interested in being able resume execution of the snapshot, it could probably be adapted for that too.

In any case, this doesn't really feel like a Moddable SDK. As you note, it isn't really practical for a microcontroller. Maybe we should move this to an Agoric repo? Thanks.

@dckc
Copy link
Contributor Author

dckc commented Nov 17, 2020

@kriskowal is this worth tracking further? If so, please suggest a place for it.

@phoddie if you don't hear back in a day or so, feel free to close it.

@kriskowal
Copy link
Contributor

Aye, this inquiry was not motivated by an Agoric use-case, but by an observation about debugging production systems at scale. In a previous life, we had considerable difficulty isolating this class of errors, because the stack would unwind before the process would dump core. Promises exacerbated the problem by catching these exceptions and not reliably reporting them, and since we ran with an uncaught exception handler, the process would proceed in an inconsistent but lively state. If reference errors and similar would simply abort and drop a heap dump, we’d have had considerably better telemetry. Resumability was not a concern.

I’d say, keep the issue at your discretion. The feature might be useful for operating Agoric systems, even without resumability, but we do not yet have a motivation.

@phoddie
Copy link
Collaborator

phoddie commented Nov 17, 2020

Thanks for the clarification @kriskowal. Your point is entirely valid. But, as there's no use in sight for either Agoric or embedded uses, I'm going to close this for now.

The work on snapshots will be a good foundation should we get here. That can be triggered from the XS abort handler (which mostly exists in its current for because of strong advice from @erights).

@phoddie phoddie closed this as completed Nov 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants