<div dir="ltr">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hi Matthew,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
One way to fix this would be:<br>
<br>
1. Don't push io handler when state is 'launching'<br>
2. Instead of manually calling HandlePrivateEvent, call
SetPublicState(). <br><br>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.<br>
<br>
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.<br>
<br>
Shawn.<br>
<br>
On 8/5/2014 6:59 AM, Matthew Gardiner wrote:<br>
</div>
<blockquote type="cite">Jim,
<br>
<br>
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:
<br>
<br>
(lldb) target create ~/me/i64-hello.elf
<br>
Current executable set to '~/me/i64-hello.elf' (x86_64).
<br>
(lldb) process launch
<br>
MG Process::HandlePrivateEvent launching stopped_count 0
should_broadcast 1
<br>
Process 31393 launching
<br>
MG Process::HandlePrivateEvent stopped stopped_count 1
should_broadcast 1
<br>
MG Process::HandlePrivateEvent running stopped_count 1
should_broadcast 1
<br>
Process 31393 launched: 'i64-hello.elf' (x86_64)
<br>
Process 31393 stopped
<br>
* thread #1: tid = 31393, 0x0000003675a011f0, name =
'i64-hello.elf', stop reason = trace
<br>
frame #0: 0x0000003675a011f0
<br>
-> 0x3675a011f0: movq %rsp, %rdi
<br>
0x3675a011f3: callq 0x3675a046e0
<br>
0x3675a011f8: movq %rax, %r12
<br>
0x3675a011fb: movl 0x21eb97(%rip), %eax
<br>
(lldb) MG Process::HandlePrivateEvent stopped stopped_count 2
should_broadcast 0
<br>
MG Process::HandlePrivateEvent running stopped_count 2
should_broadcast 0
<br>
MG Process::HandlePrivateEvent stopped stopped_count 3
should_broadcast 0
<br>
MG Process::HandlePrivateEvent running stopped_count 3
should_broadcast 0
<br>
<br>
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).
<br>
<br>
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).
<br>
<br>
What puzzled me was why ShouldBroadcastEvent return true for this
very first stop. Is this a bug?
<br>
<br>
I also spent sometime at ShouldBroadcastEvent and saw that this:
<br>
<br>
case eStateStopped:
<br>
case eStateCrashed:
<br>
case eStateSuspended:
<br>
{
<br>
....
<br>
if (was_restarted || should_resume ||
m_resume_requested)
<br>
{
<br>
<br>
evaluates as false, and hence the PrivateResume code is not
called... does this seem buggy to you for this very first stop?
<br>
<br>
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.
<br>
<br>
thanks for your help
<br>
Matt
<br>
<br>
Matthew Gardiner wrote:
<br>
<blockquote type="cite">Folks,
<br>
<br>
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.
<br>
<br>
(lldb) target create ~/mydir/i64-hello.elf
<br>
Current executable set to '~/mydir/i64-hello.elf' (x86_64).
<br>
(lldb) process launch
<br>
Process 27238 launching
<br>
Process 27238 launched: '64-hello.elf' (x86_64)
<br>
Process 27238 stopped
<br>
* thread #1: tid = 27238, 0x0000003675a011f0, name =
'i64-hello.elf'
<br>
frame #0:
<br>
(lldb) target list
<br>
Current targets:
<br>
* target #0: i64-hello.elf ( arch=x86_64-unknown-linux,
platform=host, pid=27238, state=running )
<br>
(lldb)
<br>
<br>
As you can see the "target list" reflects that the process is
running. Which I confirmed by looking at /proc/27238/status.
<br>
<br>
Anyone else seeing this?
<br>
<br>
thanks
<br>
Matt
<br>
<br>
<br>
<br>
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
<br>
More information can be found at <a href="http://www.csr.com" target="_blank">www.csr.com</a>. Keep up to date
with CSR on our technical blog, <a href="http://www.csr.com/blog" target="_blank">www.csr.com/blog</a>, CSR people
blog, <a href="http://www.csr.com/people" target="_blank">www.csr.com/people</a>, YouTube, <a href="http://www.youtube.com/user/CSRplc" target="_blank">www.youtube.com/user/CSRplc</a>,
Facebook, <a href="http://www.facebook.com/pages/CSR/191038434253534" target="_blank">www.facebook.com/pages/CSR/191038434253534</a>, or follow
us on Twitter at <a href="http://www.twitter.com/CSR_plc" target="_blank">www.twitter.com/CSR_plc</a>.
<br>
New for 2014, you can now access the wide range of products
powered by aptX at <a href="http://www.aptx.com" target="_blank">www.aptx.com</a>.
<br>
_______________________________________________
<br>
lldb-dev mailing list
<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a>
<br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a>
<br>
<br>
<br>
To report this email as spam click
<a href="https://www.mailcontrol.com/sr/EjKNgqvIx0TGX2PQPOmvUj!GOBh06pKKNwnTW0ZqkNYNbZeofOurgZMo6Cl2EgPiaCw7kl6fPUTCXaTERp6oIw==" target="_blank">https://www.mailcontrol.com/sr/EjKNgqvIx0TGX2PQPOmvUj!GOBh06pKKNwnTW0ZqkNYNbZeofOurgZMo6Cl2EgPiaCw7kl6fPUTCXaTERp6oIw==</a>
.
<br>
</blockquote>
<br>
_______________________________________________
<br>
lldb-dev mailing list
<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a>
<br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a>
<br>
</blockquote>
<br>
</div>
</div>