[lldb-dev] problems with async mode in lldb-python script

[Greg Clayton]

On Mar 18, 2014, at 3:25 AM, Hikaru Gosun <hgosun at gmail.com> wrote:

> Oops, thanks Greg!
> 
> Also it seems that I was not setting up the listener in a proper way, I needed to do debugger.GetListener() instead of my lldb.SBListener("event_listener") which I copy&pasted from somewhere else :(

Yes, when you currently launch with SBLaunchInfo, you don't get to specify your own listener. We should fix this so that you can supply your own listener to the SBLaunchInfo, and if you don't specify a valid listener, then the debugger will be used. The debugger is currently always used as the listener when using the SBLaunchInfo based SBTarget::Launch() function. If you ever do want to use your own listener you can use the following SBTarget launch:

    lldb::SBProcess
    Launch (SBListener &listener, 
            char const **argv,
            char const **envp,
            const char *stdin_path,
            const char *stdout_path,
            const char *stderr_path,
            const char *working_directory,
            uint32_t launch_flags,   // See LaunchFlags
            bool stop_at_entry,
            lldb::SBError& error);

Then you could have specified your "listener" as the first parameter. You also would have needed to do the following line:

process.GetBroadcaster().AddListener(listener, lldb.SBProcess.eBroadcastBitStateChanged)

A process requires a listener up front when launching or attaching, so it always already has one when you get a valid SBProcess instance back. We also currently don't support more than one listener for a process' stop events. We need to have any additional listeners fail to be added, but we currently don't enforce that and that is a bug. Why you might ask? Because what does it mean to get a "I am a process and I have stopped" if someone else on another thread already received that event and sent a process.Continue()? Two clients currently can't react effectively to stop and run events as they would be stomping on each other. If you get a stop event and start asking the process for its thread list and the other thread that got the stop event had continued your process, you would have real trouble getting valid results.

So for now it is definitely best to only have 1 thing listening and reacting to process state change events.

Greg

> Working smoothly now. Thanks a lot,
> HG
> 
> 
> On Mon, Mar 17, 2014 at 6:14 PM, Greg Clayton <gclayton at apple.com> wrote:
> Yes, you aren't checking if the process state. See the python example in the SVN repository:
> 
> svn cat http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
> 
> It does the process events correctly and should serve as a great starting point for you.
> 
> 
> On Mar 17, 2014, at 9:29 AM, Hikaru Gosun <hgosun at gmail.com> wrote:
> 
> > Hi,
> >
> > I have a small script to debug a program in OSX that looks more or less like this:
> >
> > debugger = lldb.SBDebugger.Create()
> > target = debugger.CreateTargetWithFileAndArch(exe, lldb.LLDB_ARCH_DEFAULT_64BIT)
> > launch_info = lldb.SBLaunchInfo(args)
> > launch_info.SetLaunchFlags(lldb.eLaunchFlagNone)
> > error = lldb.SBError()
> > process = target.Launch(launch_info, error)
> > if not error.Success():
> >     print args, str(error)
> >     return
> >
> > listener = lldb.SBListener("event_listener")
> > process.GetBroadcaster().AddListener(listener, lldb.SBProcess.eBroadcastBitStateChanged)
> > done = 0
> > while not done:
> >     event = lldb.SBEvent()
> >     if listener.WaitForEvent(10, event):
> >       state = lldb.SBProcess.GetStateFromEvent(event)
> >       print state
> >       for thread in process:
> >         print thread, thread.GetFrameAtIndex(0)
> >       process.Continue()
> >     else:
> >       done = 1
> >
> > My intention is to debug the target with some kind of timeout, that's why I'm trying to use the async mode and use the timeout in WaitForEvent(). The problem that I'm facing is that once WaitForEvent() succeeds, there's no way I can get access to the thread information (for example to get frame info for each thread). This is the output from the script:
> >
> > 5
> > SBThread: tid = 0x2b9672 No value
> > SBThread: tid = 0x2b9686 No value
> > SBThread: tid = 0x2b9687 No value
> > SBThread: tid = 0x2b9689 No value
> > SBThread: tid = 0x2b968a No value
> > SBThread: tid = 0x2b96be No value
> > SBThread: tid = 0x2b96bf No value
> > SBThread: tid = 0x2b96c0 No value
> >
> > This is for the lldb version that comes with XCode (lldb-300.2.53)
> >
> > Any ideas? Is there anything wrong with my approach?
> >
> > Thanks,
> > HG
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 
>