A recovered native fault still kills the app 30 seconds later - #160
Merged
Conversation
coffeecatch arms alarm(30) when it catches a fault, and SIGALRM kills the process by default. The alarm is a watchdog for a handler wedged inside a function that is not signal safe, and the caller is expected to disarm it if it means to keep running. We never did: the fault surfaces as a java.lang.Error, the activity reports it and the app carries on, then the process dies half a minute later looking like an unrelated crash. Cancel inside the catch, after the throw whose allocations the watchdog covers and before COFFEE_END() frees the state the cancel reads. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QyhFS2PjPDhJzmBRUoEJeB Signed-off-by: Xavier Roche <roche@httrack.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
xroche
added a commit
that referenced
this pull request
Aug 26, 2026
The engine moves to 26f24acb, the tagged 3.49.24. Nothing it changes reaches the Android binary: the delta is the WebHTTrack server and the guide, and htsserver.c is not in Android.mk. The docs bundle does ship, built from the pinned engine. It now covers the reshot Android screenshots and the all-files-access and notification steps the guide never described. The droid/* anchors Help deep-links to are unchanged. Release notes are rewritten for the round: the outcome fixes (#158, #159, #162, #163, #169), the native-fault ones (#160, #165, #168), the storage warning (#155) and the import prompt a fresh install could not answer (#164). The resume-offer note claims only what #158 delivers, since markers already on disk are left alone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
coffeecatch arms
alarm(30)when it catches a fault, as a watchdog against a handler wedged inside a function that is not signal safe. The caller is expected to disarm it if it intends to keep running, and we never did.COFFEE_TRY_JNIreports the fault as ajava.lang.Error,HTTrackActivitycatches it, shows the error panel, and the app carries on until SIGALRM kills the process half a minute later. To the user that looks like an unrelated crash.The three protected JNI entry points now go through a local wrapper that cancels the alarm inside the catch block. Placement matters in both directions: after
coffeecatch_throw_exception(), because the throw allocates and that is the hang the watchdog covers, and beforeCOFFEE_END(), which frees the per-thread state the cancel reads. A host probe confirms the behaviour, with a recovered SIGSEGV killing the process at t+30 without the cancel and surviving with it. Upstream coffeecatch has the matching defect that a cancel placed after the block silently does nothing (xroche/coffeecatch#71), so the submodule pin bump is a separate step once that lands.