[lldb-dev] [Bug 24896] New: "Process 1 was reported... but no stop reply packet was received" error from TestConnectRemote on FreeBSD

2015-09-21 Thread via lldb-dev
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

Re: [lldb-dev] changing default test runner from multiprocessing-based to threading-based

2015-09-21 Thread Zachary Turner via lldb-dev
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

[lldb-dev] [Bug 14637] Missing input prompt, "(lldb)" on Linux, lldb version 178

2015-09-21 Thread via lldb-dev
https://llvm.org/bugs/show_bug.cgi?id=14637 lab...@google.com changed: What|Removed |Added Status|REOPENED|RESOLVED CC|

[lldb-dev] [Bug 24895] New: "unexpected si_code for SIGBUS" assertion failure from TestGoroutines.py on FreeBSD

2015-09-21 Thread via lldb-dev
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:

[lldb-dev] changing default test runner from multiprocessing-based to threading-based

2015-09-21 Thread Todd Fiala via lldb-dev
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