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

Allow formatters to display stack traces on crash #541

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

lrascao
Copy link

@lrascao lrascao commented Feb 18, 2021

Only the last stack frame (ie. the place that cause the crash) is currently being
shown in the message provided to the formatters, if you're interested in more
information you'll need to dig into the crash.log for it.
This is not ideal when using containerized environments with custom formatters,
we want as much as data as possible to be available in the console backend.

Only the last stack frame (ie. the place that cause the crash) is currently being
shown in the message provided to the formatters, if you're interested in more
information you'll need to dig into the crash.log for it.
This is not ideal when using containerized environments with custom formatters,
we want as much as data as possible to be available in the console backend.
@jadeallenx
Copy link
Member

IIRC we are only printing the last frame in the stack trace for safety reasons; that is, if you emit the entire stack trace you may be liable to OOM your VM if a gen_server with a giant 10MB state dies and gets printed over and over and over and over. So I am mildly concerned this patch opens a potentially unsafe log path.

Trust me, though I get why you want more information from a container environment, but I think it should be carefully considered.

@lrascao
Copy link
Author

lrascao commented Feb 19, 2021

That would indeed be bad, fortunately the crash report (to which this applies) does not carry the process state, that is left to the =ERROR REPORT==== report.
However i understand your concern in terms of depth of trace, a very deeply nested function crash would fall into this issue. Would a (low default) configurable value to cap the maximum length for this list help in this regard? I'm thinking a depth of 3 or 4 would be enough to help sort out most crash origins.

@jadeallenx
Copy link
Member

I would prefer to have a reasonable limit somewhere on the depth, yes, please.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants