Repository navigation
AsyncTask: fix double-unref crash on teardown after completion - #552
Merged
mtwebster merged 2 commits intoNov 13, 2026
Merged
Conversation
The two reader threads (read_stdout/read_stderr) cleared their stdout_is_open/stderr_is_open flags *before* closing and releasing their DataInputStream. Whichever reader finished first could therefore see both flags clear and call finish() — signalling completion (status = FINISHED, task_complete()) — while the peer thread was still inside dis_*.close() / dis_* = null. The owner, seeing the task finished, then tore it down while a reader was still unreffing its stream, double- unreffing the underlying UnixInputStream and crashing in g_object_unref (SIGSEGV during teardown, observed sporadically from `--check --scripted` cron runs). The reader threads were also created detached and never joined, so a reader could outlive completion signalling entirely. Fix: keep handles to both reader threads and add a small coordinator thread (wait_and_finish) that joins both readers — guaranteeing their streams are fully closed — before calling finish() exactly once. Remove the racy stdout_is_open/stderr_is_open flags and the finish() calls from the reader threads. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Finish synchronously if the waiter thread can't be created. - Close reader streams in a finally block so they're released on error. - Mark the task finished with exit code -1 if the script fails to spawn, so callers polling the status don't hang.
Member
|
I updated the final commit with what turned out to be the real explanation of this after running some trials. Thanks |
brahm
pushed a commit
to brahm/linux-para-todos-os-roles
that referenced
this pull request
Nov 13, 2026
…ida na 26.11.0 O Timeshift até a 26.11.0 tem uma corrida entre as threads que leem a saída do rsync: as duas podiam chamar finish() juntas e soltar o mesmo objeto duas vezes (SIGSEGV em g_object_unref). A correção entrou em linuxmint/timeshift#552. A segunda tentativa continua, porque o Ubuntu 24.04 traz a 24.01.1. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NiPLVTYxtUeTJLTpe2p517
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
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.
Fixes #551.
Problem
AsyncTask's reader threads (read_stdout/read_stderr) clear theirstdout_is_open/stderr_is_openflags before closing and releasing theirDataInputStream, so the first reader to finish can callfinish()(→status = FINISHED,task_complete()) while the other reader is still insidedis_*.close()/dis_* = null. The owner, pollingwhile (task.status == AppStatus.RUNNING), then tears the task down while a reader is still unreffing its stream → doubleg_object_unrefof the underlyingUnixInputStream→ SIGSEGV during teardown. The reader threads are also created detached and never joined, and thefinish_calledguard is unsynchronized. Sporadically observed from--check --scriptedcron runs. Full backtrace and ThreadSanitizer evidence are in #551.Fix
wait_and_finish) thatjoin()s both readers — guaranteeing their streams are fully closed — before callingfinish()exactly once.stdout_is_open/stderr_is_openflags and thefinish()calls from the reader threads.Verification
meson compileclean.--create --scriptedcreates a snapshot successfully with no crash.-Db_sanitize=thread) before/after: thefinish_called/ concurrent-finish()data race reported on the old code is gone after the fix; only pre-existing benign lock-free polling races on progress counters remain.🤖 Generated with Claude Code