Repository navigation
tracer: Fix MemoryRepository and messages arriving after stop() - #209
Merged
Merged
Conversation
MemoryRepository keyed its handlers by TraceTarget, which is unhashable, so every handlers:get request raised a TypeError. Key by its identifier instead. A message queued on the reactor before stop() could be handled after it, reaching self._script.post() with _script set to None. Ignore messages once stopped. Make test_basics fail when the reactor thread raises, and add tests for both cases. Fixes frida#150
oleavr
force-pushed
the
fix/150-tracer-stop
branch
from
November 5, 2026 19:21
1f298f0 to
9ed30e6
Compare
Member
|
Thanks! 🙌 |
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 #150
Running
tests/test_tracer.pycould print a traceback from the reactor thread while still reporting OK. On currentmainthere are two bugs on that path:MemoryRepositoryusedTraceTargetas a dict key.TraceTargethas been an unhashable dataclass since 5a5cdc8 ("tracer: Add a basic web UI"), so everyhandlers:getrequest throughMemoryRepositoryraisedTypeError: unhashable type: 'TraceTarget'. It now keys bytarget.identifier, likeFileRepositorydoes.stop(). A message queued on the reactor beforestop()could be handled after it, reachingself._script.post()with_scriptalreadyNone. That is theAttributeErrorfrom the issue._on_messagenow ignores messages once the tracer has stopped, since there is no script left to reply to.Both exceptions happen on the reactor thread, so
test_basicsnever failed. It now fails if a reactor thread raises. That check is timing dependent, so two new tests cover both cases deterministically, without a target process.Test results
The new tests were written before the fixes:
mainTypeError: unhashable type: 'TraceTarget'in the new teststest_message_after_stop_is_ignored:AttributeError: 'NoneType' object has no attribute 'post'tests/test_tracer.pypass,test_basicsclean on 10 repeated runsThe whole
tests/directory passes: 35 tests, 33 before plus the 2 new ones.blackandisortpass.frida-trace -i 'open*' -f /bin/cat -- /etc/hostname /etc/os-releasetraces the same twoopen()calls with and without this change.FileRepositoryis not touched.Tested on Ubuntu 24.04 (WSL2), Python 3.12, frida 17.24.3. The agent and UI were taken from the frida-tools 14.11.0 wheel rather than built from source.
Not changed here: an exception other than
OperationCancelledErrorin a scheduled task still endsReactor._run, which is how these errors stopped the worker thread.The code was written with AI assistance.