[Lldb-commits] [PATCH] C++ API tests review request

[jingham at apple.com]

BTW, just to give a little background on this.  If there are no listeners for an event, Broadcasters in lldb just discard them.  That's useful, for instance if nobody cares about breakpoint changed events, there's no reason for the target to hold onto all of them just in case somebody might later care.  But that means if you start up a process with no listener, then there's a race condition with whether your listener will be in time to get the initial stopped event.  If it gets added after the process is launched and stopped, for instance, it could miss it.  

I was going to solve that by having each Broadcaster have a "Prime a new listener with relevant events" method, so that the Process Broadcaster would hold onto all the events it had gotten till some listener signed up with it.  In fact, the method is still there (Broadcaster::AddInitialEventsToListener.)  But Greg didn't like that in the case of the Process for what are I am sure good reasons though I can no longer recall them.  So we decided to just force the Process to be created with a listener.

Jim

On May 3, 2013, at 8:29 AM, jingham at apple.com wrote:

> The way the SB API's work for creating processes, if you don't register a listener at construction, your Process gets hooked up to the Debugger's listener, which you can get with SBDebugger.GetListener.  So you do have two.  Better to either construct it with a listener explicitly, or use the debugger's.
> 
> Jim
> 
> On May 3, 2013, at 5:50 AM, "Malea, Daniel" <daniel.malea at intel.com> wrote:
> 
>> Thanks for the heads up; will keep this in mind. The tests only register one SBListener with each process; but it's not done at construction, but via:
>> 
>> Process.GetBroadcaster.AddListener(listener, eBroadcastBitStateChanged);
>> 
>> However, I should note that the tests call the listener's waitForEvent() from another thread, which I imagine is a popular use case for frontends.
>> 
>> 
>> Any comments appreciated; the (svn) patch is attached to the previous email (addressed to Greg/the list) in this thread.
>> 
>> 
>> Cheers,
>> Dan
>> 
>> 
>> 
>> -----Original Message-----
>> From: jingham at apple.com [mailto:jingham at apple.com] 
>> Sent: Thursday, May 02, 2013 6:04 PM
>> To: Malea, Daniel
>> Cc: lldb-commits at cs.uiuc.edu
>> Subject: Re: [Lldb-commits] [PATCH] C++ API tests review request
>> 
>> One thing to be wary of with the process and listeners is that although it is possible to have two listeners listening to process events, and at some point that should work, at present it doesn't work all that well.  For the nonce, if you are going to write test cases that involve consuming process events, just use the listener that you passed to the process when you created it.
>> 
>> Jim 
>> 
>> 
>> On May 2, 2013, at 2:55 PM, "Malea, Daniel" <daniel.malea at intel.com> wrote:
>> 
>>> Hi all,
>>> 
>>> I'm trying to nail down exactly what multithreaded problems there are with the LLDB API, so I wrote some tests that use it via C++. The same stuff could have been done from Python, but I figured since there's so few C++ tests (one that I found "check_public_api_headers") I figured I'd write some to keep things interesting.
>>> 
>>> When someone has a moment, could you provide some feedback, as I'm seeing 3 out of 4 tests fail on Linux/Mac OS X - wondering if these are LLDB bugs I'm uncovering, or more likely, that the tests are using the API incorrectly.
>>> 
>>> Here's a brief description of what the tests do:
>>> 
>>> 
>>> 1.  Test that a function registered with SBBreakpoint.SetCallback() 
>>> is called when a breakpoint is hit. -- the function is not invoked  2.  Test that an SBListener registered with a process receives an event.
>>> 3.  Test that a process retrieved from an SBEvent can be used to 
>>> query thread/frame information - retrieving thread/frame works ok, but querying a function name does not  4.  Test that a process can be resumed from a thread that did not start it - This one's weird: SBProcess::GetState() returns eStateStopped() but calling Process::Resume() fails with error "process is running".
>>> 
>>> Currently, only #2 passes, which is the simplest case. There's a bunch of boiler plate code in there that is not too interesting. The meat of the test logic are in the .cpp files that are prefixed with "test_".
>>> 
>>> 
>>> Thanks a bunch,
>>> Dan
>>> 
>>> _______________________________________________
>>> lldb-commits mailing list
>>> lldb-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits