[lldb-dev] More linux process control and IOHandler races

Matthew Gardiner mg11 at csr.com
Wed Aug 6 06:26:12 PDT 2014


Like I said earlier your patch worked. However I think the right fix is 
to arrange that ShouldBroadcast returns false for this first stop. I 
believe this, because firstly no stops should be reported here since the 
user is only interested in launching a program, and additionally because 
it enables us to fix lldb without removing the call to 
HandlePrivateEvent. This, I think, is important to preserve as the 
central point for process state change handling.


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