We are taking a look at this, and we will let you know.
In general there should only be one listener that is getting process stopped
events, as when the event in consumed, it does some work (DoOnRemoval for
instance). I think we enforce this, but if we don't and there are two consumers
of the events, we might have the issue you are seeing?
We will look into this and get back to you.
On May 8, 2012, at 10:59 AM, Filipe Cabecinhas wrote:
> Hi again,
>
> It seems that, if I use the debugger's listener (like Driver.cpp does), it
> works:
>
> If I change the test to do this:
> listener = self.dbg.GetListener()
> instead of:
> listener = lldb.SBListener("test-listener")
>
>
> Everything works (after we take into account the additional events related to
> the program's STDOUT). But shouldn't my first version work? I setup the
> SBListener before doing anything that will use it, and the events should be
> propagated to every listener that is hanging to the Process broadcaster. Or
> am I missing something?
>
> Thanks,
>
> Filipe
>
>
> On Tuesday, May 8, 2012 at 12:02 PM, Filipe Cabecinhas wrote:
>
>> Hi all!
>>
>> I'm having some weird problems with asynchronous API usage. I will address
>> it in this email as if it was a bug, but it may be wrong API usage from my
>> part.
>>
>> The main problem is the run lock being write locked when the process is
>> stopped (and I got a state changed event).
>> What happens is:
>>
>> Create a target (a simple 'hello world'-like program) and set a breakpoint
>> Set Async mode.
>>
>> Set up an SBListener that will listen (on the SBDebugger) for
>> lldb.SBProcess.eBroadcastBitStateChanged, from event class
>> lldb.SBProcess.GetBroadcasterClassName().
>> Call SBTarget::LaunchSimple(None, None, os.getcwd())
>> Wait for an event
>> The process is now in a stopped state (checked using GetStateFromEvent() ==
>> eStateStopped)
>> Try to get the stopped thread. There isn't any (the only thread has
>> eStopReasonInvalid).
>>
>> Why does this happen?
>>
>> SBTarget::Launch() will start the process (the run_lock gets created
>> write-locked, the Process' public state will be eStateRunning) and wait for
>> it to stop (when it stops, the Event's DoOnRemoval will change the public
>> state (to eStateStopped) of the Process and call WriteUnlock()).
>> After the process stopped on entry, we want to continue until we hit our
>> breakpoint. SBTarget::Launch calls Process::Resume, which will call
>> WriteTryLock (succeeding) and call into Process::PrivateResume()
>>
>> The lock will not be unlocked again.
>> The Process' private state will toggle between the stopped and running
>> states several times, before stopping at the breakpoint. When it stops at
>> the breakpoint, it will set the Process' public state to eStateStopped. But
>> the public state was already eStateStopped, so we won't call WriteUnlock on
>> Process.cpp:1310.
>>
>> Any clues on where to look for? I've started debugging it but maybe Greg
>> will know best where to look and how to fix this.
>>
>> Attached is a test that show the problem (main.cpp is from
>> python_api/process).
>>
>> Thanks,
>>
>> Filipe
>>
>>
>> Attachments:
>> - main.cpp
>>
>> - Makefile
>>
>> - TestProcessRWLock.py
>>
>
>
>
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
