https://llvm.org/bugs/show_bug.cgi?id=24895
Bug ID: 24895
Summary: "unexpected si_code for SIGBUS" assertion failure from
TestGoroutines.py on FreeBSD
Product: lldb
Version: unspecified
Hardware: PC
OS: Free
https://llvm.org/bugs/show_bug.cgi?id=24896
Bug ID: 24896
Summary: "Process 1 was reported... but no stop reply packet
was received" error from TestConnectRemote on FreeBSD
Product: lldb
Version: unspecified
Hardware: PC
https://llvm.org/bugs/show_bug.cgi?id=14637
lab...@google.com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
CC|
https://llvm.org/bugs/show_bug.cgi?id=18784
lab...@google.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Hi all,
I'm considering changing the default lldb test runner from
multiprocessing-based to threading-based. Long ago I switched it from
threading to multiprocessing. The only reason I did this was because OS X
was failing to allow more than one exec at a time in the worker threads -
way down in
After our last discussion, I thought about it some more and there are at
least some problems with this. The biggest problem is that with only a
single process, you are doing all tests from effectively a single instance
of LLDB. There's a TestMultipleDebuggers.py for example, and whether or
not th
