The following situation occured if we were stopping a process (due to breakpoint, watchpoint, ...
hit) while a new thread was being created.
- process has two threads: A and B.
- thread A hits a breakpoint: we send a STOP signal to thread B and register a callback with
ThreadStateCoordinator to send a stop notification after the thread stops.
- thread B stops, but not due to the SIGSTOP, but on a thread creation event (of a new thread C).
We are unaware of our desire to stop, so we queue ThreadStopped and RequestResume operations
with TSC, so the thread can continue running.
- TSC receives the ThreadStopped event, sees that all threads are stopped and fires the delayed
stop notification.
- immediately after that TSC gets the RequestResume operation, so it resumes the thread.
At this point the state is inconsistent because LLDB thinks the process is stopped and will start
issuing commands to it, but one of the threads is in fact running. Things eventually break.
I address this problem by omitting the two TSC events altogether and Resuming the thread B
directly. This way the short stop is invisible to the TSC and the delayed notification will not
fire. We will fire the notification when we actually process the SIGSTOP on thread B.
When we get the initial SIGSTOP for thread C, we also resume the thread and send a
ThreadWasCreated message (is_stopped = false) to the TSC. This way, the TSC can stop the thread
on its own and handle the stop event later. This way the state of the new thread is correctly
handled as well (thanks Chaoren for the idea).
This patch also removes the synchronisation between the thread creation notifications on threads
B and C. The need for this synchronisation is unclear (the comments seem to hint that the new
thread is "fully created" only after we process both events, but I have noticed no regressions in
treating it as "created" even after just processing the initial C event), but it is a source for
many kinds of obscure races, since it introduces a new thread state "Launching" and the rest of
the code does not handle this state at all (what happens if we get a resume request from LLDB
while this thread is launching? what happens if we get a stop request? etc.).
This fixes the "spurious $O packet" problem in TestPrintStackTraces.py. However, the test remains
disabled on i386 due to the VDSO issue.
Test Plan:
TestPrintStackTraces works on x86_64. No regressions in the rest of the test suite.
Reviewers: vharron, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9145
llvm-svn: 235579
* Fixes the local stack variable return pointer usage in NativeThreadLinux::GetName().
* Changes NativeThreadProtocol::GetName() to return a std::string.
* Adds a unit test to verify thread names don't regress in the future. Currently only run on Linux since I know default thread names there.
llvm-svn: 217717
* Sends a SIGSTOP to the process.
* Fixes busted SIGSTOP handling. Now builds a list of non-stopped
that we wait for the PTRACE group-stop for. When the final must-stop
tid gets its group stop, we propagate the process state change.
Only the signal receiving the notification of the pending SIGSTOP
is marked with the SIGSTOP signal. All the rest, if they weren't
already stopped, are marked as stopped with signal 0.
* Fixes a few broken tests.
* Marks the Linux test I added earlier as expect-pass (no longer XFAIL).
Implements fix for http://llvm.org/bugs/show_bug.cgi?id=20908.
llvm-svn: 217647
This change:
* properly captures execs in NativeProcessLinux.
* clears out all non-main-thread thread metadata in NativeProcessLinux on exec.
* adds a DidExec() method to the NativeProcessProtocol delegate.
* clears out the auxv data cache when we exec (on Linux).
This is a small part of the llgs for local Linux debugging work going on here:
https://github.com/tfiala/lldb/tree/dev-llgs-local
I'm breaking it into small patches.
llvm-svn: 216670
This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64.
(More architectures coming soon).
Not every debugserver option is covered yet. Currently
the lldb-gdbserver command line can start unattached,
start attached to a pid (process-name attach not supported yet),
or accept lldb attaching and launching a process or connecting
by process id.
The history of this large change can be found here:
https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64
Until mid/late April, I was not sharing the work and continued
to rebase it off of head (developed via id tfiala@google.com). I switched over to
user todd.fiala@gmail.com in the middle, and once I went to github, I did
merges rather than rebasing so I could share with others.
llvm-svn: 212069
