[lldb-dev] SB API is not working properly with OSPython plugin
Tatyana Krasnukha via lldb-dev
lldb-dev at lists.llvm.org
Mon Feb 25 08:45:59 PST 2019
This is ThreadList::GetSelectedThread, it calls OperatingSystemPython::UpdateThreadList indirectly.
However, I cannot reproduce the error Alexander gets, due to a deadlock.
-----Original Message-----
From: jingham at apple.com <jingham at apple.com>
Sent: Friday, February 22, 2019 2:14 AM
To: Tatyana Krasnukha <tatyana.krasnukha at synopsys.com>
Cc: Alexander Polyakov <polyakov.alx at gmail.com>; LLDB <lldb-dev at lists.llvm.org>
Subject: Re: [lldb-dev] SB API is not working properly with OSPython plugin
What's triggering one of the OS Plugin methods to get run on this separate thread? I would expect SetPrivateState would just cause the private stop event to get broadcast to the private state thread, and then that would wake up and then it would be the one to call the OS Plugin to do it's job. That's how the GDBRemote plugin works, for instance.
Jim
> On Feb 21, 2019, at 2:54 PM, Tatyana Krasnukha <tatyana.krasnukha at synopsys.com> wrote:
>
> That clarified things, thanks!
>
> I think, this is the reason:
>
> ProcessRunLock &Process::GetRunLock() { if
> (m_private_state_thread.EqualsThread(Host::GetCurrentThread()))
> return m_private_run_lock;
> else
> return m_public_run_lock;
> }
>
> In our case the current thread is not m_private_state_thread. I create a separate thread for waiting a processor to halt and then SetPrivateState. It seems, that was an inappropriate approach.
>
> -----Original Message-----
> From: jingham at apple.com <jingham at apple.com>
> Sent: Thursday, February 21, 2019 11:58 PM
> To: Tatyana Krasnukha <tatyana.krasnukha at synopsys.com>
> Cc: Alexander Polyakov <polyakov.alx at gmail.com>; LLDB
> <lldb-dev at lists.llvm.org>
> Subject: Re: [lldb-dev] SB API is not working properly with OSPython
> plugin
>
>
>
>> On Feb 21, 2019, at 11:22 AM, Tatyana Krasnukha via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>
>>> lldb Process::SetPrivateState (stopped) stop_id = 2
>>> error: error: process must be stopped.
>>
>> These two lines are printed from different threads, you cannot be sure the real order of execution is the same.
>>
>> The plugin should subscribe on public state change events and wait until one comes (correct me if I’m wrong about that).
>
> That's not right. When the process stops, but before lldb broadcasts a public stop event, it will query the OS Plugin directly to build up the thread list. It needs to do that before it declares a public stop because it uses the thread list to reason about whether to declare a public stop or not. So the OS Plugin (and BTW the Thread Step Plan plugin is in the same boat) have to run after a private stop but before public one. There isn't a principled way to do that. The best we have at present is a hack that says "if you are running on the private state thread, then you get to do things between private & public stop as if there were a public stop". Cleaning that up is item 5 on the lldb Projects page if anyone is interested...
>
> Jim
>
>>
>> From: lldb-dev <lldb-dev-bounces at lists.llvm.org> On Behalf Of
>> Alexander Polyakov via lldb-dev
>> Sent: Thursday, February 21, 2019 9:54 PM
>> To: Jim Ingham <jingham at apple.com>
>> Cc: LLDB <lldb-dev at lists.llvm.org>
>> Subject: Re: [lldb-dev] SB API is not working properly with OSPython
>> plugin
>>
>> It seems that the process plugin uses the Process::SetPrivateState at the right time. If you look at the log, you will see that the process is already in the 'private stopped' state when the OS plugin is invoked.
>>
>> (lldb) c
>> lldb Process::Resume -- locking run lock
>> lldb Process::PrivateResume() m_stop_id = 1, public state: stopped private state: stopped
>> lldb Process::SetPrivateState (running)
>> intern-state Process::ShouldBroadcastEvent (0x1abea90) => new state: running, last broadcast state: running - YES
>> intern-state Process::HandlePrivateEvent (pid = 1) broadcasting new state running (old state stopped) to public
>> intern-state Process::PushProcessIOHandler pushing IO handler
>> intern-state Process::HandlePrivateEvent updated m_iohandler_sync to 1
>> lldb Process thinks the process has resumed.
>> intern-state timeout = <infinite>, event_sp)...
>> lldb waited from m_iohandler_sync to change from 0. New value is 1.
>> dbg.evt-handler Process::SetPublicState (state = running, restarted
>> =
>> 0) Process 1 resuming
>> lldb Process::SetPrivateState (stopped)
>> lldb Process::SetPrivateState (stopped) stop_id = 2
>> error: error: process must be stopped.
>> intern-state Process::ShouldBroadcastEvent (0x7f3e9c007450) => new state: stopped, last broadcast state: stopped - YES
>> intern-state Process::HandlePrivateEvent (pid = 1) broadcasting new state stopped (old state running) to public
>> intern-state timeout = <infinite>, event_sp)...
>> dbg.evt-handler Process::SetPublicState (state = stopped, restarted
>> =
>> 0) dbg.evt-handler Process::SetPublicState (stopped) -- unlocking
>> run lock
>>
>>
>> On Fri, Feb 15, 2019 at 1:38 AM Jim Ingham <jingham at apple.com> wrote:
>> Your plugin should have set the private state to stopped when it figures out however it does that the process has stopped. The API is Process::SetPrivateState. Is that happening at the right time?
>>
>> Jim
>>
>>
>>
>> On Feb 14, 2019, at 1:50 PM, Alexander Polyakov <polyakov.alx at gmail.com> wrote:
>>
>> I found out that the plugin works well with an x86 application, so I think that the problem is in my process plugin. Maybe you know a place where to start looking for an issue?
>>
>> On Thu, Feb 14, 2019 at 10:56 PM Jim Ingham <jingham at apple.com> wrote:
>> The simplest thing possible to reproduce the failure. So some OS_Plugin implementation which tries to look up a global like this and fails, and some program source I can run it under that provides said global. That way I can easily watch it fails as you describe when the plugin gets activated, and see why it isn’t allowing this call on private stop.
>>
>> Jim
>>
>>
>>
>> On Feb 14, 2019, at 11:50 AM, Alexander Polyakov <polyakov.alx at gmail.com> wrote:
>>
>> Sure, could you describe in more detail which example may help you?
>>
>> чт, 14 февр. 2019 г. в 22:36, Jim Ingham <jingham at apple.com>:
>> That’s a little complicated…
>>
>> lldb has two levels of stop state - private stops and public stops. When the process gets notification from the underlying process plugin that the process stopped, it raises a private stop event. That gets handled by the ShouldStop mechanism on the private state thread in lldb, and then if the stop is judged interesting to the user, it gets rebroadcast as a public stop.
>>
>> For instance, when you issue a “step” command, lldb will stop and start the process multiple times as it walks through the source line. But only the last of those stops are relevant to the user of LLDB, so all the other ones exist only as private stops.
>>
>> The SB API’s for the most part should only consider a “publicly stopped” process accessible. After all, you wouldn’t want some API to succeed sometimes if you happen to catch it in the middle of a private stop.
>>
>> But the OperatingSystem plugin needs to get called right after a private stop, so it can provide threads for the ShouldStop mechanism. We should really have some formal mechanism whereby things like the OS plugin can request elevated rights in the SB API’s, so that they can run at private stop time. IIRC, we instead have a hack where SB API calls that run on the private state thread are blanket allowed to run at private stop. The xnu Operating System plugin successfully gets global values to look up its threads. So I’m not sure why that isn’t working for you.
>>
>> Can you cook up a simple example showing the failure and I’ll have a look?
>>
>> Jim
>>
>>
>>
>> On Feb 14, 2019, at 11:10 AM, Alexander Polyakov <polyakov.alx at gmail.com> wrote:
>>
>> It is, the error is: error: error: process must be stopped.
>>
>> I thought that the plugin (get_thread_info in my case) is invoked when the process is already stopped, but it's not. Is it ok?
>>
>> On Thu, Feb 14, 2019 at 9:53 PM Jim Ingham <jingham at apple.com> wrote:
>> All SBValues have an error in them (SBValue.GetError). Does that say anything interesting?
>>
>> Jim
>>
>>
>>
>>
>>
>> On Feb 14, 2019, at 10:08 AM, Alexander Polyakov via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>
>> Hi lldb-dev,
>>
>> I work on a custom implementation of OperatingSystem plugin using Python and SB API. I’m trying to fetch information about some variables from the target into the plugin, to do that I’m using the following Python code:
>> ready_tasks = self._target.FindGlobalVariables(‘pxReadyTasksLists’,
>> 1).GetValueAtIndex(0)
>>
>> When I do `print(ready_tasks)` I get:
>> No value
>>
>> At the same time, doing the same actions inside lldb embedded interpreter follows to:
>> `
>> print(lldb.target.FindGlobalVariables('pxReadyTasksLists',1).GetValue
>> A
>> tIndex(0))`
>>
>> (List_t [5]) pxReadyTasksLists = {
>> [0] = {
>> uxNumberOfItems = 0
>> pxIndex = 0x00000000
>> xListEnd = {
>> xItemValue = 0
>> pxNext = 0x00000000
>> pxPrevious = 0x00000000
>> }
>> }
>> …
>>
>> Does anybody know what may cause such a behavior?
>>
>> --
>> Alexander
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_c
>> g
>> i-2Dbin_mailman_listinfo_lldb-2Ddev&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg
>> &
>> r=yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0&m=WSyRR4BN6X_gz6_8T2fa0
>> 8
>> 4mE5gtQoySTdLAbss52z8&s=WwMtr2kl4vphhXJdM2gFv9aEZVPMgghJUnsTikIzfNE&e
>> =
>>
>>
>>
>> --
>> Alexander
>>
>> --
>> Alexander
>>
>>
>>
>> --
>> Alexander
>>
>>
>>
>> --
>> Alexander
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_c
>> g
>> i-2Dbin_mailman_listinfo_lldb-2Ddev&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg
>> &r=yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0&m=WSyRR4BN6X_gz6_8T2fa
>> 084mE5gtQoySTdLAbss52z8&s=WwMtr2kl4vphhXJdM2gFv9aEZVPMgghJUnsTikIzfNE
>> &e=
More information about the lldb-dev
mailing list