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 llvm.org/apt/
I need to kill some processes manually to complete lldb testsuite..

Cheers
Sylvesre

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:

-Todd

Hi,

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.

Cheers,
Luke

Hey Todd, I think this is due to http://llvm.org/bugs/show_bug.cgi?id=19347

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,
Andrew

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

In the case of llvm.org/pr19347, 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
trickier.