Error screen does not work if the app crashes very quickly after launching

[haroldadmin]

The library relies on a service running in a different process to process and display the error screen. This means that if the application crashes immediately after start, the service might not get enough time to be prepared for accepting new messages.

Unfortunately it looks like there is no easy solution for this problem.

[prudhvir3ddy]

@haroldadmin does this mean that issue is in app startup library ?

[prudhvir3ddy]

verified using debugger that whatthestack is getting initialised first but the service starting is taking the time.

[haroldadmin]

You got it right, the problem occurs because the service takes a short while to start.

The issue has been open for so long because, unfortunately, I have not found a good solution for it.

[matejdro]

Here is a possible way:

1. If crash happens and service has not yet been connected store stacktrace to the disk
2. When service (in another process) starts, poll disk for couple of seconds in case crash has been written
3. Display crash from disk

[haroldadmin]

I'll have to verify if the app crash halts the service's startup process, otherwise serializing the crash for later consumption is a nice idea. Can't promise an ETA :)

[haroldadmin]

I experimented with the idea of serializing the crash for deferred use in the service. I opted to use a JSON file in the app's private directory because:

• No storage permission required
• No external libraries required: JVM File IO, JSONObject and FileObserver are all built in.
• Simpler than creating a local database
• Just as reliable as using a separate SharedPreferences file

Here's the system I implemented:

• Modify WhatTheStackExceptionHandler to serialize the exception as a JSON object and write it to a private file (blocking IO) instead of sending the serialized exception as a Message to WhatTheStackService.
• Modify WhatTheStackService to use a FileObserver to watch the private file for changes, and trigger the error screen on each change event.

The idea was that now the FileObserver would trigger the error screen instead of a Message from the exception handler. I also added code to account for the observer not getting a change notification right at the start of the service, as well as cleaning up the private file after triggering the error screen to prevent duplicate notifications.

This system works, but unreliably. It missed roughly 1 out of every 5 crashes, and I suspect that's down to multi-process file IO synchronization issues. It's a neat solution to the problem in theory, but falls apart in reliability. I might experiment with DB-based serialization in the future.

An important observation from this experiment was that the service continues its init process as usual even if the main application crashes.

[matejdro]

Maybe instead of file observer, you could rely on service like in the current version + polling the file for first couple of seconds (until service is connected)?