The test variant 'data_formatter_commands_after_steps' exposes a loss of every second "next" command. This variant sets a breakpoint before a list is populated, and steps 4 times to populate the list with 4 items.

When this script is run using dotest, dosep or manually at the lldb command prompt, 2 "next" commands are required to populate a single list item. Note that this does not occur if the std::list contains integers rather than elements of type std::string. Note that a single line of code constructs an std::string and adds an element to the list.

Also, this specific failure cannot be reproduced with clang r182733, whereas it reproduces reliably with gcc 4.6.3 (Ubuntu 12.04) gcc 4.6.2 (Debian buildbot) and icc 13.1 (Ubuntu 12.04).

Related issue on FreeBSD:

runCmd: frame variable --show-declaration --show-globals i
output: main.cpp:12: (int) _GLOBAL__N_1::i = 3

Expecting start string: main.cpp:12: (int) (anonymous namespace)::i = 3
Not matched

FAILURE

The FreeBSD issue is just a bug in FreeBSD's __cxa_demangle in libcxxrt. For example, using one of the testcases from libcxxabi:

% ./demangle-cxxrt _ZN12_GLOBAL__N_113ASTTypeWriter15VisitVectorTypeEPKN5clang10VectorTypeE
_GLOBAL__N_1::ASTTypeWriter::VisitVectorType(clang::VectorType const*)

% c++filt _ZN12_GLOBAL__N_113ASTTypeWriter15VisitVectorTypeEPKN5clang10VectorTypeE
(anonymous namespace)::ASTTypeWriter::VisitVectorType(clang::VectorType const*)

The FreeBSD issue is now fixed in two ways - the in-tree __cxa_demangle has been updated to address this case, and FreeBSD now uses the built-in demangler recently re-added to lldb (because the in-tree __cxa_demangle still has some other limitations).

Looks like the test passes now.