> 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).

From: lldb-dev <lldb-dev-boun...@lists.llvm.org> On Behalf Of Alexander 
Polyakov via lldb-dev
Sent: Thursday, February 21, 2019 9:54 PM
To: Jim Ingham <jing...@apple.com>
Cc: LLDB <lldb-dev@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 
<jing...@apple.com<mailto:jing...@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?


On Feb 14, 2019, at 1:50 PM, Alexander Polyakov 
<polyakov....@gmail.com<mailto:polyakov....@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 
<jing...@apple.com<mailto:jing...@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.


On Feb 14, 2019, at 11:50 AM, Alexander Polyakov 
<polyakov....@gmail.com<mailto:polyakov....@gmail.com>> wrote:

Sure, could you describe in more detail which example may help you?

чт, 14 февр. 2019 г. в 22:36, Jim Ingham 
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?


On Feb 14, 2019, at 11:10 AM, Alexander Polyakov 
<polyakov....@gmail.com<mailto:polyakov....@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 
<jing...@apple.com<mailto:jing...@apple.com>> wrote:
All SBValues have an error in them (SBValue.GetError).  Does that say anything 


On Feb 14, 2019, at 10:08 AM, Alexander Polyakov via lldb-dev 
<lldb-dev@lists.llvm.org<mailto:lldb-dev@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’, 

When I do `print(ready_tasks)` I get:
No value

At the same time, doing the same actions inside lldb embedded interpreter 
follows to:

(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?

lldb-dev mailing list




lldb-dev mailing list

Reply via email to