[lldb-dev] [Bug 24895] New: "unexpected si_code for SIGBUS" assertion failure from TestGoroutines.py on FreeBSD
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: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: ema...@freebsd.org CC: llvm-b...@lists.llvm.org Classification: Unclassified Command invoked: timeout -s QUIT 4m /usr/local/bin/python2.7 /tank/emaste/src/llvm/tools/lldb/test/dotest.py -q --arch=x86_64 --executable /tank/emaste/src/llvm/build-nodebug/bin/lldb -s /tank/emaste/src/llvm/build-nodebug/lldb-test-traces -u CXXFLAGS -u CFLAGS -C /usr/bin/clang --inferior -p TestGoroutines.py /tank/emaste/src/llvm/tools/lldb/test --event-add-entries worker_index=5:int 97 out of 398 test suites processed - TestGoroutines.py Assertion failed: (false && "unexpected si_code for SIGBUS"), function GetCrashReasonForSIGBUS, file ../tools/lldb/source/Plugins/Process/POSIX/CrashReason.cpp, line 120. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 24896] New: "Process 1 was reported... but no stop reply packet was received" error from TestConnectRemote on FreeBSD
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
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: ema...@freebsd.org
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
==
FAIL: test_connect_remote (TestConnectRemote.ConnectRemoteTestCase)
Test "process connect connect:://localhost:[port]".
--
Traceback (most recent call last):
File "/tank/emaste/src/llvm/tools/lldb/test/lldbtest.py", line 615, in
wrapper
func(*args, **kwargs)
File "/tank/emaste/src/llvm/tools/lldb/test/lldbtest.py", line 615, in
wrapper
func(*args, **kwargs)
File
"/tank/emaste/src/llvm/tools/lldb/test/functionalities/connect_remote/TestConnectRemote.py",
line 42, in test_connect_remote
self.runCmd("process connect -p gdb-remote connect://localhost:" +
str(port))
File "/tank/emaste/src/llvm/tools/lldb/test/lldbtest.py", line 2542, in
runCmd
msg if msg else CMD_MSG(cmd))
AssertionError: False is not True : Command 'process connect -p gdb-remote
connect://localhost:42922' returns successfully
Config=x86_64-/usr/bin/clang
--
Error message is:
error: Process 1 was reported after connecting to 'connect://localhost:42922',
but no stop reply packet was received
--
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 14637] Missing input prompt, "(lldb)" on Linux, lldb version 178
https://llvm.org/bugs/show_bug.cgi?id=14637 lab...@google.com changed: What|Removed |Added Status|REOPENED|RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #12 from lab...@google.com --- Prompt handling was fixed a couple months back. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 18784] lldb fails to build with invalid conversion from 'const char*' to 'char*' [-fpermissive]
https://llvm.org/bugs/show_bug.cgi?id=18784 lab...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||lab...@google.com Resolution|--- |FIXED --- Comment #2 from lab...@google.com --- The code producing the error does not exist anymore. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] changing default test runner from multiprocessing-based to threading-based
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 the Python Global Interpreter Lock (GIL). And, at the time, I didn't have the time to break out the test runner strategies. We have verified the threading-based issue is no longer manifesting on OS X 10.10 and 10.11 beta. That being the case, I'd like to convert us back to being threading-based by default. Specifically, this will have the same effect as doing the following: (non-Windows): --test-runner-name threading (Windows): --test-runner-name threading-pool There are a couple benefits here: 1. We'll remove a fork for creating the worker queues. Each of those are just threads when using threading, rather than being forked processes. Depending on the underlying OS, a thread is typically cheaper. Also, some of the inter-worker communication now becomes cheap intra-process communication instead of heavier multiprocessing constructs. 2. Debugging is a bit easier. The worker queues make a lot of noise in 'ps aux'-style greps, and are a pain to debug relatively speaking vs. the threaded version. I'm not yet looking to remove the multiprocessing support. It is likely I'll check the OS X version and default to the multiprocessing test runner if it wasn't explicitly specified and the OS X version is < 10.10 as I'm pretty sure I hit the issue on 10.9's python. Thoughts? -- -Todd ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] changing default test runner from multiprocessing-based to threading-based
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 that test passes is equivalent to whether or not the test suite can even work without dying horribly. In other words, you are inherently relying on multiple debuggers working to even run the test suite. I don't know if that's a problem, but at the very least, it's kind of unfortunate. And of course the problem grows to other areas. What other things fail horribly when a single instance of LLDB is debugging 100 processes at the same time? It's worth adding this as an alternate run mode, but I don't think we should make it default until it's more battle-tested. On Mon, Sep 21, 2015 at 12:49 PM Todd Fiala via lldb-dev < lldb-dev@lists.llvm.org> wrote: > 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 the Python Global Interpreter Lock (GIL). And, at the time, I > didn't have the time to break out the test runner strategies. > > We have verified the threading-based issue is no longer manifesting on OS > X 10.10 and 10.11 beta. That being the case, I'd like to convert us back > to being threading-based by default. Specifically, this will have the same > effect as doing the following: > (non-Windows): --test-runner-name threading > (Windows): --test-runner-name threading-pool > > There are a couple benefits here: > 1. We'll remove a fork for creating the worker queues. Each of those are > just threads when using threading, rather than being forked processes. > Depending on the underlying OS, a thread is typically cheaper. Also, some > of the inter-worker communication now becomes cheap intra-process > communication instead of heavier multiprocessing constructs. > 2. Debugging is a bit easier. The worker queues make a lot of noise in > 'ps aux'-style greps, and are a pain to debug relatively speaking vs. the > threaded version. > > I'm not yet looking to remove the multiprocessing support. It is likely > I'll check the OS X version and default to the multiprocessing test runner > if it wasn't explicitly specified and the OS X version is < 10.10 as I'm > pretty sure I hit the issue on 10.9's python. > > Thoughts? > -- > -Todd > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
