-
Notifications
You must be signed in to change notification settings - Fork 22
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
Large exceptions (such as stack overflow error) can crash the library, eating the original exception #31
Comments
Thanks for reporting the issue. I'll try to investigate it over the weekend and get back to you. |
I tried to reproduce this issue locally by simulating a stack-overflow exception. I can confirm that such an error overrides the original exception, but I couldn't reproduce the library crashing. Can you give me a bit more info on when/how the library itself crashes due to large stack traces? As for handling extremely large stack traces, I think the issue is the limit on the size of IPC messages in Android. If it's too large, the IPC communication throws an error. Would it be an acceptable solution to you if we log every exception caught by WhatTheStack? |
Sorry, I was unclear. WhatTheStack still works normally and displays the exception, just the crash that happens inside WhatTheStack replaces the original exception.
Ideally, misleading WhatTheStack window with the parcel error would be replaced by something else, but since the issues is so rare, I think this compromise is okay. |
Fix available in |
When app crashes with a really large exception (such as stack overflow error with a really long stack trace), WhatTheStack will crash:
Even worse, this exception will override original exception, making it unaccessible unless I disable WhatTheStack.
Maybe in this rare case, WhatTheStack could try catch this error, print original exception to the logcat and just display the message (without the stacktrace)?
The text was updated successfully, but these errors were encountered: