-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Synchronous flush on crash #289
Comments
We are currently using CocoaLumberjack, and our next release really needs to implement this capability to synchronously flush all traces to disk while handling a crash. Here are the requirements:
Since we need this capability soon, we will start an implementation of our own. Here are two additional requirements for performance of this modification:
I'll let you know when our modification is complete. Perhaps you might be interested in integrating our changes. Please feel free to add comments on the requirements above, or to add comments with your design suggestions. Thanks, Bob |
I think that from CocoaLumberjack side it should ensure that As for comments you could open a pull request marking it as "in progress" so we don't merge it just yet but can discuss about the changes and code. We must:
It would be nice to:
|
@CloudBob what do you think? |
Did this ever go anywhere? |
@dalemyers unfortunately, not. But I do want to pick up and clean the issues, as the project is been silent for the past period. |
It's definitely not my area of expertise, so I wouldn't have much ability to do so. What I was curious about though was the custom uncaught exception handler. It's pretty well established at this point that crash handling libraries don't play nicely with multiple handlers. Those based on PLCrashReporter though (most of them I think?) have the ability to set callbacks. It seems to me that the best option for everyone is to not have a custom handler, and instead just have a force flush method. Something like this maybe: https://stackoverflow.com/a/35075346 (untested). |
As an update, we tried that fix with the callbacks and it's working perfectly for us. It probably won't work perfectly 100% of the time due to the nature of it, but it's good enough for our needs. It would still be good to have a method to force a flush of what's there rather than needing to wait on the queue. That way we'd avoid some later messages too, and the whole process would be faster. |
@dalemyers thanks for getting back with this update. I think it will help other people interested in this problem. I will leave the ticket open till we find a fix |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is still an issue, please make sure it is up to date and if so, add a comment that this is still an issue to keep it open. Thank you for your contributions. |
Over 5 years later, I've worked at multiple other companies and jobs. I'm once again seeing this issue unfortunately. |
When remotely debugging a crash (especially on iOS), it is a requirement to trace right up to the point of the crash. The user sends the trace files and the crash report.
Performance is also important, so asynchronous mode must be selected.
The problem is that trace data is left in the queue and not flushed when a crash occurs.
I am currently using the PlCrashReporter framework. That framework reliably drives a callback on every crash after the crash report has been written. I need to be able to make a CocoaLumberjack call in that crash callback to synchronously flush all of the trace.
The callback is driven on one thread, and all of the other threads are suspended, so the normal GCD background thread processing no longer occurs on the trace queue. The crash callback thread should synchronously flush the queue to the loggers.
Thanks, Bob
The text was updated successfully, but these errors were encountered: