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

[Malea, Daniel]

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