Linux x86_64 tests

Hi all,

I’m seeing the Ubuntu 12.04 x86_64 lldb tests just hang. Anyone else seeing this on Linux?

You are not alone!
I have the same issues on my jenkins job to update
I need to kill some processes manually to complete lldb testsuite..


Ok - I will start tracking this down. I’ve been away from it for a couple weeks and thought I might have missed the memo :slight_smile:



Yes, we had spotted that some time ago!
The problem seems to be caused by the commit @205497.

We have a patch for Linux which we are currently testing.


Hey Todd, I think this is due to

I ran into this last week but haven’t been working much with LLDB so haven’t looked into it any further.

Hope that helps,

Thanks, Andrew. Yes, this looks exactly like what I’m hitting. I’ll get on the bug.

Thanks, Luke.

Just updated the bug - I’ll likely just disable the never-ending tests on Linux until either Ed’s or your fix comes in.

Linux tests should be green again.

I had one test I had to mark xfail for the moment. Hopefully Ed’s or Luke’s patch in progress will address the underlying issue - a breakpoint is showing up as hit twice when it should be once according to the test. It’s quite possibly fallout from the fix to stop the tests from hanging. But I’ll take an xfail over a hang.

Please don’t hesitate to make noise on lldb-dev if you have tests failing and nobody seems to be doing anything about it.

My change will probably be FreeBSD-specific -- the thread handling is
the one aspect in which the FreeBSD and Linux implementations differ

In the case of, the second thread encounters a
breakpoint after the first thread is in kernel, handling its
breakpoint. On FreeBSD all threads are stopped by the time we return
from waitpid(), although only the first thread's SIGTRAP is delivered.
It is possible, although not efficient, to determine that the 2nd
thread has encountered a breakpoint or other signal as well. My plan
is to just loop over waitpid() calls for this case, draining (and
delivering) all waiting signals.

As far as I can tell, on Linux the Debugger must explicitly stop the
other threads, so the handling of other pending signals will be a bit