with no delay between successive test cases. This one happend to capture a test failure where
the inferior shoud stop at a breakpoint but did not (radar will be filed to capture the log files
as well as the test session files):
[12:40:37] johnny:/Volumes/data/lldb/svn/trunk/test $ DEBUG_LLDB_LOG=/tmp/lldb.log DEBUG_GDB_REMOTE_LOG=/tmp/gdb-remote.log ./dotest.py -v -p TestFailures.py
LLDB-63
Path: /Volumes/data/lldb/svn/trunk
URL: https://johnny@llvm.org/svn/llvm-project/lldb/trunk
Repository Root: https://johnny@llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 133529
Node Kind: directory
Schedule: normal
Last Changed Author: jmolenda
Last Changed Rev: 133500
Last Changed Date: 2011-06-20 19:57:15 -0700 (Mon, 20 Jun 2011)
Session logs for test failures/errors/unexpected successes will go into directory '2011-06-21-12_40_42'
Command invoked: python ./dotest.py -v -p TestFailures.py
----------------------------------------------------------------------
Collected 10 tests
1: test_char_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that char-type variables are displayed correctly. ... ok
2: test_char_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that char-type variables are displayed correctly. ... ok
3: test_int_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that int-type variables are displayed correctly. ... ok
4: test_int_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that int-type variables are displayed correctly. ... ok
5: test_long_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that 'long long'-type variables are displayed correctly. ... FAIL
6: test_long_long_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that 'long long'-type variables are displayed correctly. ... ok
7: test_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that long-type variables are displayed correctly. ... TestFailures.DebugIntegerTypesFailures.test_long_type_with_dsym
FAIL
8: test_long_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that long-type variables are displayed correctly. ... FAIL
9: test_short_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that short-type variables are displayed correctly. ... ok
10: test_short_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that short-type variables are displayed correctly. ... ok
======================================================================
FAIL: test_long_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that 'long long'-type variables are displayed correctly.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 102, in test_long_long_type_with_dsym
self.long_long_type()
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 129, in long_long_type
self.generic_type_tester(set(['long long']))
File "/Volumes/data/lldb/svn/trunk/test/types/AbstractBase.py", line 67, in generic_type_tester
"stop reason = breakpoint"])
File "/Volumes/data/lldb/svn/trunk/test/lldbtest.py", line 863, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Process should be stopped due to breakpoint
======================================================================
FAIL: test_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that long-type variables are displayed correctly.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 87, in test_long_type_with_dsym
self.long_type()
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 125, in long_type
self.generic_type_tester(set(['long']))
File "/Volumes/data/lldb/svn/trunk/test/types/AbstractBase.py", line 67, in generic_type_tester
"stop reason = breakpoint"])
File "/Volumes/data/lldb/svn/trunk/test/lldbtest.py", line 863, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Process should be stopped due to breakpoint
======================================================================
FAIL: test_long_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that long-type variables are displayed correctly.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 94, in test_long_type_with_dwarf
self.long_type()
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 125, in long_type
self.generic_type_tester(set(['long']))
File "/Volumes/data/lldb/svn/trunk/test/types/AbstractBase.py", line 67, in generic_type_tester
"stop reason = breakpoint"])
File "/Volumes/data/lldb/svn/trunk/test/lldbtest.py", line 863, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Process should be stopped due to breakpoint
----------------------------------------------------------------------
Ran 10 tests in 5.617s
FAILED (failures=3)
Session logs for test failures/errors/unexpected successes can be found in directory '2011-06-21-12_40_42'
[12:40:47] johnny:/Volumes/data/lldb/svn/trunk/test $
llvm-svn: 133537
while back. By default its output will be less verbose than the
old examine-threads.c but adding the '-v' command line flag will
give all the information that examine-threads.c provided plus some.
Of note, this implementation can take a process name -- and it will
use the libproc API so it can match program names longer than 16
characters.
llvm-svn: 133500
if not already specified by the test driver (via ./dotest -w). Remove the AbstractBase.setUp()
method definition when/if we find out the cause of the failures if no delays are inserted
between these test cases.
llvm-svn: 133495
We still have the the issue where running:
./dotest.py -v types
we have test failures where the inferior either runs to exited with status 0 or
the inferior stops but not because of breakpoint (for example):
runCmd: process status
output: Process 90060 stopped
* thread #1: tid = 0x2d03, 0x000000010000e2ca, stop reason = EXC_BAD_ACCESS (code=2, address=0x10000e2ca)
frame #0: 0x000000010000e2ca
There are two cases where the inferior stops for the breakpoint (good), but the expression parser
prints out the wrong information. The two failures are:
Failure-TestFloatTypesExpr.FloatTypesExprTestCase.test_double_type_with_dsym.log
Failure-TestFloatTypesExpr.FloatTypesExprTestCase.test_double_type_with_dwarf.log
I'll file a radar on the two expression parser misbehave, while continue investigating why the
inferior stops for the wrong reason or does not stop at all.
For now, you'll need to do:
./dotest.py -v -w types
llvm-svn: 133488
after initial construction.
There are two exceptions to the above general rules, though; the API objects are
SBCommadnReturnObject and SBStream.
llvm-svn: 133475
level is not eDescriptionLevelBrief. It broke test/TestAliases.py. Besides, to have a brief breakpoint list,
you can do "breakpoint list -b".
llvm-svn: 133455
operator counts due to bad debug DWARF debug info. We now verify the operator
has a valid number of params using the clang operator tables.
llvm-svn: 133375
const char *
SBFrame::GetFunctionName();
bool
SBFrame::IsInlined();
The first one will return the correct name for a frame. The name of a frame is:
- the name of the inlined function (if there is one)
- the name of the concrete function (if there is one)
- the name of the symbol (if there is one)
- NULL
We also can now easily check if a frame is an inline function or not.
llvm-svn: 133357
This us useful because sometomes you have to show a single character as: 'a'
(using eFormatChar) and other times you might have an array of single
charcters for display as: 'a' 'b' 'c', and other times you might want to
show the contents of buffer of characters that can contain non printable
chars: "\0\x22\n123".
This also fixes an issue that currently happens when you have a single character
C string (const char *a = "a"; or char b[1] = { 'b' };) that was being output
as "'a'" incorrectly due to the way the eFormatChar format output worked.
llvm-svn: 133316
issue in the way block variables are marked as parsed. In the DWARF parser we
always parse all blocks for a function at once, so we can mark all blocks as
having all variables parsed and avoid recursive function calls to try and
reparse things that have already been handled.
Fixed an issue with how variables get scoped into blocks. The DWARF parser can
now handle abtract class definitions that contain concrete static variables.
When the concrete instance of the class functions get instantiated, they will
track down the concrete block for the abtract block and add the variable to
each block.
llvm-svn: 133302
Among them are test cases to exercise SBTarget.AttachToProcessWithName(); we attach to "hello_world",
and verify that, after attachment, the currently selected target indeed matches "hello_world".
llvm-svn: 133279
libraries and headers exist. This can be specified using the platform select
function:
platform select --sysroot /Volumes/remote-root remote-macosx
Each platform subclass is free to interpret the sysroot as needed.
Expose the new SDK root directory through the SBDebugger class.
Fixed an issue with the GDB remote protocol where unimplemented packets were
not being handled correctly.
llvm-svn: 133231
darwin (not sure about other platforms).
Modified the communication and connection classes to not require the
BytesAvailable function. Now the "Read(...)" function has a timeout in
microseconds.
Fixed a lot of assertions that were firing off in certain cases and replaced
them with error output and code that can deal with the assertion case.
llvm-svn: 133224
Add a test case for the SBTarget::AttachToProcessWithID() API call.
o main.c:
The change goes with the added test case test_with_dwarf_and_attach_to_process_with_id_api() above.
o SBTarget.cpp:
Checks whether we're in synchronous mode. If yes, let's wait for the process to stop right after attaching.
llvm-svn: 133223
For the print_stacktrace(thread, string_buffer = False) function, if we have debug info
for a frame function, let's also emit the args for the current function.
o TestFrameUtils.py:
Add stronger assertTrue for frame0's args.
o TestPrintStackTraces.py:
Launch the inferior with ["abc", "xyz"] and expect '(int)argc=3' in the stack traces, since
by design the inferior is built with debug info.
llvm-svn: 133204
not write output (prompts, instructions,etc.) if the CommandInterpreter
is in batch_mode.
Also, finish updating InputReaders to write to the asynchronous stream,
rather than using the Debugger's output file directly.
llvm-svn: 133162
remove the self.runStarted attribute since the automatic shutdown of processes associated
with the targets are now performed automatically.
llvm-svn: 133092
bool SBDebugger::DeleteTarget(lldb::SBTarget &target);
which is used in the test tearDown() phase to cleanup the debugger's target list
so that it won't grow larger and larger as test cases are executed. This is also
a good opportunity to get rid of the arcane requirement that test cases exercising
the Python API must assign the process object to self.process so that it gets
shutdown gracefully. Instead, the shutdown of the process associated with each
target is now being now automatically.
Also get rid of an API from SBTarget class:
SBTarget::DeleteTargetFromList(lldb_private::TargetList *list);
llvm-svn: 133091
like the doc's say it should. Make sure we have a condition before we set up a test whether
we have one, so we only present a "could not parse condition" error if we actually have a condition.
llvm-svn: 133088
Greg Clayton