diff options
author | Jason Molenda <jmolenda@apple.com> | 2023-11-01 16:14:36 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2023-11-01 16:14:36 -0700 |
commit | 66b92830c963158c9f74dd5533265c28d60cc265 (patch) | |
tree | f75075b0db477a1da3d18205389996b64f7b485e /llvm/lib/IR/Module.cpp | |
parent | ec350ad418a24f70c88758259c774a1e11c06d74 (diff) | |
download | llvm-66b92830c963158c9f74dd5533265c28d60cc265.zip llvm-66b92830c963158c9f74dd5533265c28d60cc265.tar.gz llvm-66b92830c963158c9f74dd5533265c28d60cc265.tar.bz2 |
[lldb] [debugserver] Shut down the exception thread when clearing (#70979)
MachProcess has a MachTask as an ivar. In the MachProcess dtor, we call
MachTask::Clear() to clear its state, before running the dtor of all our
ivars, including the MachTask one.
When we attach on darwin, MachProcess calls
MachTask::StartExceptionThread which does the task_for_pid and then
starts a thread to listen for mach messages. Then MachProcess calls
ptrace(PT_ATTACHEXC). If that ptrace() fails, MachProcess will call
MachTask::Clear. But the exception thread is now up & running and is not
stopped; its ivars will be reset by the Clear() method, and its object
will be freed after the dtor runs.
Actually eliciting a crash in this scenario is very timing sensitive; I
hand-modified debugserver to fail to PT_ATTACHEXC trying to simulate it
on my desktop and was unable. But looking at the source, and an
occasional crash report we've received, it's clear that this is
possible.
rdar://117521198
Diffstat (limited to 'llvm/lib/IR/Module.cpp')
0 files changed, 0 insertions, 0 deletions