[lldb-dev] [Bug 25470] New: TestMiInterpreterExec is flaky on linux
https://llvm.org/bugs/show_bug.cgi?id=25470
Bug ID: 25470
Summary: TestMiInterpreterExec is flaky on linux
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
ERROR: test_lldbmi_thread_continue
(TestMiInterpreterExec.MiInterpreterExecTestCase)
Test that 'lldb-mi --interpreter' can continue execution by "thread
continue" command.
--
Traceback (most recent call last):
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-mi/interpreter/TestMiInterpreterExec.py",
line 227, in test_lldbmi_thread_continue
self.expect("@\"argc=1rn")
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-mi/lldbmi_testcase.py",
line 54, in expect
return self.child.expect(pattern, *args, **kwargs)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1316, in expect
return self.expect_list(compiled_pattern_list, timeout, searchwindowsize)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1330, in expect_list
return self.expect_loop(searcher_re(pattern_list), timeout,
searchwindowsize)
File
"/lldb-buildbot/lldbSlave/buildWorkingDir/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
line 1414, in expect_loop
raise TIMEOUT (str(e) + '\n' + str(self))
TIMEOUT: Timeout exceeded in read_nonblocking().
version: 2.4 ($Revision: 516 $)
command: /lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/lldb-mi
args: ['/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/lldb-mi',
'--interpreter']
searcher: searcher_re:
0: re.compile("@"argc=1\\r\\n")
buffer (last 100 chars): roup-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
(gdb)
before (last 100 chars): roup-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
(gdb)
--
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 25478] New: backtick syntax is undocumented (and interacts oddly with strings)
https://llvm.org/bugs/show_bug.cgi?id=25478 Bug ID: 25478 Summary: backtick syntax is undocumented (and interacts oddly with strings) Product: lldb Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: andi.m.mccl...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified I am running lldb-340.4.110.1 (obtained via XCode 7.1.1) at the command line on Mac OS X. I type the innocuous expression: break set -F the_function_name -condition '0 == (int)strcmp(str1, "IDictionary`2") && 0 == (int)strcmp(str2, "IDictionary`2")' I get the totally baffling set of errors: error: error: invalid suffix on literal; C++11 requires a space between literal and identifier error: expected ';' after expression error: expected ';' after expression error: use of undeclared identifier 'IDictionary' error: 4 errors parsing expression I find if the condition is '0 == (int)strcmp(str1, "IDictionary`2")' only, it works fine. Several days pass before I figure out what is happening here. A note in the "GDB to LLDB command map" document explains: "NOTE: any command can inline a scalar expression result (as long as the target is stopped) using backticks around any expression" Once I realize this, I try placing backslashes before the backticks in my expression: break set -F the_function_name -condition '0 == (int)strcmp(str1, "IDictionary\`2") && 0 == (int)strcmp(str2, "IDictionary\`2")' Now it works. I see three problems here. First off, my opinion is that this is not very good behavior. I don't expect backtick evaluation or any kind of other string mutation to silently trigger occur *inside* of a single-quoted string (crossing between two quoted strings, in this case!). However, I can imagine that backtick evaluation inside a string would probably be very useful for someone somewhere, so I will assume that this is the intentional design of the feature. Second off, I do not think this error was well reported. The important thing, in my case, for deciphering the error message was to understand that the backtick substitution feature was triggering at all. The error message did not indicate that the "error" reported was from a backtick expression. Third and most importantly, this feature and its behavior is undocumented. Looking at the docs on lldb.llvm.org I find the backticks are mentioned only in the GDB->LLDB transition guide, and there only parenthetically. The transition guide is not a good place to introduce an entire feature, and worse, the details of how the feature work are not described (that it works even inside of a string, that it can be neutralized with a backtick). Expected behavior: The lldb.llvm.org documentation should fully document the backticks in the place where expression features would normally be documented (I recommend the "COMMAND STRUCTURE" section of the tutorial). The documentation should explain "when" the backticks are evaluated (i.e.: before interpreting quote characters or anything else) and any quirks or neutralization methods the backtick has, such as the backslash escape. (The tutorial mentions backslash-escaping now, but the only characters mentioned are double-quote and backslash). Finally, IMO, when you are printing an error message related to a backtick expression, the error message should actually begin with "error in backtick expression" or "error in backslash expression". Thanks -- 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 25484] New: TestTerminal.LaunchInTerminalTestCase.test_launch_in_terminal failing on Darwin
https://llvm.org/bugs/show_bug.cgi?id=25484 Bug ID: 25484 Summary: TestTerminal.LaunchInTerminalTestCase.test_launch_in_t erminal failing on Darwin Product: lldb Version: unspecified Hardware: Macintosh OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified On OS X 10.11 (10.11.1 (15B42)), using the following build: xcodebuild -scheme desktop -configuration Debug DEBUGSERVER_USE_FROM_SYSTEM=1 I have gotten a test failure on: TestTerminal.LaunchInTerminalTestCase.test_launch_in_terminal 2 out of 2 times. FAIL >>: success Traceback (most recent call last): File "/Users/tfiala/src/lldb/git-svn/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 508, in wrapper return func(self, *args, **kwargs) File "/Users/tfiala/src/lldb/git-svn/lldb/packages/Python/lldbsuite/test/functionalities/tty/TestTerminal.py", line 37, in test_launch_in_terminal self.assertTrue(error.Success(), "Make sure launch happened successfully in a terminal window") AssertionError: False is not True : Make sure launch happened successfully in a terminal window Config=x86_64-clang Session info generated @ Tue Nov 10 19:33:34 2015 To rerun this test, issue the following command from the 'test' directory: ./dotest.py -A x86_64 -C clang -v -t -f LaunchInTerminalTestCase.test_launch_in_terminal -- 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 25485] New: TestCompletion.CommandLineCompletionTestCase.test_symbol_name_dwarf failing intermittently under load on Darwin
https://llvm.org/bugs/show_bug.cgi?id=25485 Bug ID: 25485 Summary: TestCompletion.CommandLineCompletionTestCase.test_symb ol_name_dwarf failing intermittently under load on Darwin Product: lldb Version: unspecified Hardware: Macintosh OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified On OS X 10.11.2 Beta (15C31f), TestCompletion.CommandLineCompletionTestCase.test_symbol_name_dwarf is failing intermittently (2 out of 3 times on my system) when the parallel test runner is used. Test trace follows: os command: make clean with pid: 48966 stdout: rm -f main.o main.d main.d.tmp main.dwo rm -f -r "a.out.dSYM" rm -f "a.out" stderr: retcode: 0 os command: make MAKE_DSYM=NO ARCH=x86_64 CC="clang" with pid: 49028 stdout: clang++ -std=c++11 -g -O0 -fno-builtin -arch x86_64 -I/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/make/../../../../../include -include /Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/make/test_common.h -c -o main.o main.cpp clang++ main.o -g -O0 -fno-builtin -arch x86_64 -I/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/make/../../../../../include -include /Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/make/test_common.h -o "a.out" stderr: retcode: 0 looking at: (lldb) file a.out Current executable set to 'a.out' (x86_64). (lldb) breakpoint set -n Fo [K(lldb) Expecting sub string: breakpoint set -n Foo::Bar(int,\ int) Not matched FAIL tearing down the child process Traceback (most recent call last): File "/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 536, in wrapper return func(self, *args, **kwargs) File "/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2228, in dwarf_test_method return attrvalue(self) File "/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 608, in wrapper func(*args, **kwargs) File "/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/functionalities/completion/TestCompletion.py", line 262, in test_symbol_name turn_off_re_match=True) File "/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/functionalities/completion/TestCompletion.py", line 320, in complete_from_to substrs = [p]) File "/Users/tfiala/lldb/tot/git-svn/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2764, in expect msg if msg else EXP_MSG(str, exe)) AssertionError: False is not True : 'file a.out breakpoint set -n Fo' successfully completes to 'breakpoint set -n Foo::Bar(int,\ int)' Config=x86_64-clang Session info generated @ Tue Nov 10 20:26:58 2015 To rerun this test, issue the following command from the 'test' directory: ./dotest.py -A x86_64 -C clang -v -t -f CommandLineCompletionTestCase.test_symbol_name_dwarf -- 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 25486] New: test_qRegisterInfo_returns_{one_valid_result, all_valid_results} fails under heavy load
https://llvm.org/bugs/show_bug.cgi?id=25486
Bug ID: 25486
Summary: test_qRegisterInfo_returns_{one_valid_result,all_valid
_results} fails under heavy load
Product: lldb
Version: unspecified
Hardware: Macintosh
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: todd.fi...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
Created attachment 15263
--> https://llvm.org/bugs/attachment.cgi?id=15263&action=edit
Failure test client and debugserver logs
On OS X 10.11.2 Beta (15C31f), I'm seeing these failures:
TestLldbGdbServer.LldbGdbServerTestCase.test_qRegisterInfo_returns_all_valid_results
TestLldbGdbServer.LldbGdbServerTestCase.test_qRegisterInfo_returns_one_valid_result
I've attached the traces.
I will look into this. I'll mark them XFAIL on Darwin until I figure out
what's up.
--
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 25486] test_qRegisterInfo_returns_{one_valid_result, all_valid_results} fails under heavy load
https://llvm.org/bugs/show_bug.cgi?id=25486 Todd Fiala changed: What|Removed |Added Assignee|lldb-dev@lists.llvm.org |todd.fi...@gmail.com -- 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 25487] New: TestDataFormatterObjC.py times out under load on Darwin
https://llvm.org/bugs/show_bug.cgi?id=25487 Bug ID: 25487 Summary: TestDataFormatterObjC.py times out under load on Darwin Product: lldb Version: unspecified Hardware: Macintosh OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified On OS X 10.11.2 Beta (15C31f), I am seeing TestDataFormatterObjC.py TIMEOUT after what looks like no progress is made at some point. I am not able to get this hang to occur when running it over and over in a no-load situation. -- 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
