[lldb-dev] More linux process control and IOHandler races
Shawn Best
sbest at blueshiftinc.com
Tue Aug 5 09:48:41 PDT 2014
Hi Matthew,
I have also been tracking this bug. I believe there are other bugs in the
unit tests failing indirectly because of this. I also have a patch that
will fix it, but was sitting on it until the other one landed. These bugs
do not show up on OSX since the inferiors are launched separately then
attached to.
The first odd thing the launching code does is push an IOHandler when it
sees the state transition to 'launching'. This is odd because I believe
the launching program will always come up in a stopped state which will
immediately pop the IOHandler.
At launch, the process comes up in the stopped state. The launch code
manually calls HandlePrivateEvent() with the stop event, which then
broadcasts the Event. When HandleProcessEvent gets the public stop, it
dumps out the current thread state just as if an executing inferior hit a
breakpoint and stopped.
One way to fix this would be:
1. Don't push io handler when state is 'launching'
2. Instead of manually calling HandlePrivateEvent, call SetPublicState().
Alternately, we could try and debug why ShouldBroadcast() returns true, but
that appears to be by design since it is expecting the public stop event to
pop the IOHandler that had been pushed when launching.
I have attached a patch demonstrating this. In conjunction with the other
patch for IOHandler race condition, it will fix a bunch of this kind of
behaviour.
Shawn.
On 8/5/2014 6:59 AM, Matthew Gardiner wrote:
Jim,
I've been trying to debug an issue (I see it on 64-bit linux) where, I do
"target create" and "process launch" and despite not requesting *stop at
entry*, the first stop (which I believe is just the initial ptrace attach
stop) is reported to the lldb command line. I added some fprintf to
Process::HandlePrivateEvent, which counts the number of eStoppedState
events seen and whether ShouldBroadcastEvent returns true for this event.
Here's the output from my program with diagnostic:
(lldb) target create ~/me/i64-hello.elf
Current executable set to '~/me/i64-hello.elf' (x86_64).
(lldb) process launch
MG Process::HandlePrivateEvent launching stopped_count 0 should_broadcast 1
Process 31393 launching
MG Process::HandlePrivateEvent stopped stopped_count 1 should_broadcast 1
MG Process::HandlePrivateEvent running stopped_count 1 should_broadcast 1
Process 31393 launched: 'i64-hello.elf' (x86_64)
Process 31393 stopped
* thread #1: tid = 31393, 0x0000003675a011f0, name = 'i64-hello.elf', stop
reason = trace
frame #0: 0x0000003675a011f0
-> 0x3675a011f0: movq %rsp, %rdi
0x3675a011f3: callq 0x3675a046e0
0x3675a011f8: movq %rax, %r12
0x3675a011fb: movl 0x21eb97(%rip), %eax
(lldb) MG Process::HandlePrivateEvent stopped stopped_count 2
should_broadcast 0
MG Process::HandlePrivateEvent running stopped_count 2 should_broadcast 0
MG Process::HandlePrivateEvent stopped stopped_count 3 should_broadcast 0
MG Process::HandlePrivateEvent running stopped_count 3 should_broadcast 0
In summary, lldb reports the inferior to be stopped (even though
/proc/pid/status and lldb "target list" say it is running). Clearly this is
wrong (hence my earlier post).
Am I correct in assuming that when ShouldBroadcastEvent returns true this
means that lldb should show this event to the debug user? (And thus hide
other events where ShouldBroadcastEvent=false).
What puzzled me was why ShouldBroadcastEvent return true for this very
first stop. Is this a bug?
I also spent sometime at ShouldBroadcastEvent and saw that this:
case eStateStopped:
case eStateCrashed:
case eStateSuspended:
{
....
if (was_restarted || should_resume || m_resume_requested)
{
evaluates as false, and hence the PrivateResume code is not called... does
this seem buggy to you for this very first stop?
I thought I'd try asking you, since in a previous mail from Greg, he cited
you as being a thread-plan expert. (Hope that's ok!). I'd really appreciate
your help in clarifying the above questions for me, and if you have time,
giving me some ideas as to how to trace this one further e.g. how
m_thread_list.ShouldStop and m_thread_list.ShouldReportStop should behave,
etc.
thanks for your help
Matt
Matthew Gardiner wrote:
Folks,
In addition to the overlapping prompt race Shawn Best and myself are
looking at, I'm seeing another issue where if I launch a process, I get a
stop (presumably the in) being reported to the UI.
(lldb) target create ~/mydir/i64-hello.elf
Current executable set to '~/mydir/i64-hello.elf' (x86_64).
(lldb) process launch
Process 27238 launching
Process 27238 launched: '64-hello.elf' (x86_64)
Process 27238 stopped
* thread #1: tid = 27238, 0x0000003675a011f0, name = 'i64-hello.elf'
frame #0:
(lldb) target list
Current targets:
* target #0: i64-hello.elf ( arch=x86_64-unknown-linux, platform=host,
pid=27238, state=running )
(lldb)
As you can see the "target list" reflects that the process is running.
Which I confirmed by looking at /proc/27238/status.
Anyone else seeing this?
thanks
Matt
Member of the CSR plc group of companies. CSR plc registered in England and
Wales, registered number 4187346, registered office Churchill House,
Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on
our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people,
YouTube, www.youtube.com/user/CSRplc, Facebook,
www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX
at www.aptx.com.
_______________________________________________
lldb-dev mailing list
lldb-dev at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
To report this email as spam click
https://www.mailcontrol.com/sr/EjKNgqvIx0TGX2PQPOmvUj!GOBh06pKKNwnTW0ZqkNYNbZeofOurgZMo6Cl2EgPiaCw7kl6fPUTCXaTERp6oIw==
.
_______________________________________________
lldb-dev mailing list
lldb-dev at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140805/16e79065/attachment.html>
-------------- next part --------------
diff --git a/source/Target/Process.cpp b/source/Target/Process.cpp
index 7e09e7e..5fc5f1d 100644
--- a/source/Target/Process.cpp
+++ b/source/Target/Process.cpp
@@ -2771,9 +2771,12 @@ Process::Launch (ProcessLaunchInfo &launch_info)
system_runtime->DidLaunch();
m_os_ap.reset (OperatingSystem::FindPlugin (this, NULL));
- // This delays passing the stopped event to listeners till DidLaunch gets
- // a chance to complete...
- HandlePrivateEvent (event_sp);
+
+ // note, the stop event was consumed above, but not handled. This was done
+ // to give DidLaunch a chance to run. The target is either stopped or crashed.
+ // Directly set the state. This is done to prevent a stop message with a bunch
+ // of spurious output on thread status, as well as not pop a ProcessIOHandler
+ SetPublicState(state, false);
if (PrivateStateThreadIsValid ())
ResumePrivateStateThread ();
@@ -3876,7 +3879,8 @@ Process::HandlePrivateEvent (EventSP &event_sp)
{
// Only push the input handler if we aren't fowarding events,
// as this means the curses GUI is in use...
- if (!GetTarget().GetDebugger().IsForwardingEvents())
+ // or dont push it if we are launching since it will come up stopped
+ if (!GetTarget().GetDebugger().IsForwardingEvents() && new_state != eStateLaunching)
PushProcessIOHandler ();
}
else if (StateIsStoppedState(new_state, false))
More information about the lldb-dev
mailing list