[lldb-dev] More linux process control and IOHandler races
Matthew Gardiner
mg11 at csr.com
Wed Aug 6 03:30:08 PDT 2014
Hi Shawn,
Thanks for your additional patch. I tried it and fixes this issue. This
patch and the IOHandler one certainly fix a bunch of problems. I'll help
you push to get these patches upstream when Todd and Greg come back off
vacation.
I see what you mean about the launching code pushing an IOHandler.
Perhaps it's because the launching sequence fork/ptrace(TRACEME)/exec
may result in some output before the process traps? That's the only
rationale I can think of... but since the main thread (the one doing the
Launch) blocks in WaitForProcessStopPrivate, that's not adequate reason IMO.
Your point about the first stop being made public/broadcasted being by
design seems possible, but it seems wrong to me since the average user
when they launch a program in a debugger is probably not interested in
knowing that ptrace causes a stop in the TRACEME invocation. gdb
certainly does not:
(gdb) file ./i64-hello.elf
Reading symbols from
/home/mg11/src/main/devtools/main/heracles/csrgdbserver/test/examples/simple/i64-hello.elf...done.
(gdb) run
Starting program: ./i64-hello.elf
I think I'll spend the rest of the day trying to figure out why
ShouldBroadcast is returning true for this first stop. Keep your ideas
coming in - we need to get these fixes in!
thanks
Matt
Shawn Best wrote:
> 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 <http://www.csr.com>.
>>> Keep up to date with CSR on our technical blog, www.csr.com/blog
>>> <http://www.csr.com/blog>, CSR people blog, www.csr.com/people
>>> <http://www.csr.com/people>, YouTube, www.youtube.com/user/CSRplc
>>> <http://www.youtube.com/user/CSRplc>, Facebook,
>>> www.facebook.com/pages/CSR/191038434253534
>>> <http://www.facebook.com/pages/CSR/191038434253534>, or follow us on
>>> Twitter at www.twitter.com/CSR_plc <http://www.twitter.com/CSR_plc>.
>>> New for 2014, you can now access the wide range of products powered
>>> by aptX at www.aptx.com <http://www.aptx.com>.
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu <mailto: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==
>>> <https://www.mailcontrol.com/sr/EjKNgqvIx0TGX2PQPOmvUj%21GOBh06pKKNwnTW0ZqkNYNbZeofOurgZMo6Cl2EgPiaCw7kl6fPUTCXaTERp6oIw==>
>>> .
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu <mailto:lldb-dev at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
More information about the lldb-dev
mailing list