gdb on libcxx-libcxxabi-libunwind-armv7-linux build bot

Hi Sterling,

Maxim has asked to take a loot at it. The failure is essentially:

FAIL: /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.sh.cpp:137
GDB printed:
   <incomplete type>
Value should match:
Traceback (most recent call last):
  File "/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.py", line 64, in invoke
    print(" " + check_literal)
TypeError: Can't convert 'bytes' object to str implicitly

I am not sure if it is something related to python2/3. The system does have
both installed (python 2.7.12 and 3.5.2, with 2 being the default). I tried
to issue the faulty testcase with python3, and it shows the same issue

I am not very familiar with this code, but trying to make peace with
the types by changing it to:

52 else:
53 check_literal = expectation_val.string(encoding="utf-8")
54 check_literal_utf8 = check_literal.encode("utf-8")
55 test_fails = value.encode("utf-8") != check_literal_utf8

Also does not help either. For the change above, the first failure shows:

FAIL: /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.sh.cpp:137
GDB printed:
   Traceback (most recent call last):
  File "/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/utils/gdb/libcxx/printers.py", line 221, in to_string
    value_field = _value_of_pair_first(self.val["__r_"])
gdb.error: There is no member named __r_.

Value should match:
   "kdjflskdjf"

Which indicates that something is still missing here. I am checking if it
is possible to give you direct access to the bot.

I think the encoding failure (which would be python 2 vs 3) is a secondary failure–already deep inside the error handling. The real problem is the

File “/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/utils/gdb/libcxx/printers.py”, line 221, in to_string
value_field = _value_of_pair_first(self.val["_r"])
gdb.error: There is no member named _r.

Which means that maybe the test case is getting compiled or linked differently. At least in such a way that the field “_r” doesn’t exist (at least not in debug info). But I would be quite puzzled as to why this bot has a different libcxx build or debug info than all the others.

At least on my testing it seems the __r_ field does exist:

$ gdb ./gdb_pretty_printer_test.sh.cpp.tmp.exe
[...]
(gdb) b string_test
(gdb) r
[1]+ Stopped gdb ./gdb_pretty_printer_test.sh.cpp.tmp.exe
$ fg
[...]
Breakpoint 1, string_test () at /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.sh.cpp:135
135 std::string short_string("kdjflskdjf");
(gdb) n
(gdb) p short_string
$1 = {<std::__1::__basic_string_common<true>> = {<No data fields>}, static __short_mask = 1, static __long_mask = 1,
  __r_ = {<std::__1::__compressed_pair_elem<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__rep, 0, false>> = {__value_ = {{__l = {__cap_ = 1784965908,
            __size_ = 1802726502, __data_ = 0x666a64 <error: Cannot access memory at address 0x666a64>}, __s = {{__size_ = 20 '\024', __lx = 20 '\024'}, __data_ = "kdjflskdjf"}, __r = {__words = {
              1784965908, 1802726502,
              6711908}}}}}, <std::__1::__compressed_pair_elem<std::__1::allocator<char>, 1, true>> = {<std::__1::allocator<char>> = {<No data fields>}, <No data fields>}, <No data fields>},
  static npos = 4294967295}

The only unexpected thing is for some reason gdb is being stopped just after
the program start (not sure how it influences the testcase or if it is something
expected).

Also adding a 'print("VALUE_FIELD: ", value_field)' just after the value_field
attribution I am seeing:

$ /usr/bin/gdb -nx -batch -iex "set autoload off" -ex "source /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/utils/gdb/libcxx/printers.py" -ex "python register_libcxx_printer_loader()" -ex "source /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.py" gdb_pretty_printer_test.sh.cpp.tmp.exe 2>&1 | tee _out No symbol table is loaded. Use the "file" command. Breakpoint 1 at 0x1179c: file /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.sh.cpp, line 57. Loading libc++ pretty-printers. Cannot parse expression `.L1185 4@r4'. warning: Probes-based dynamic linker interface failed. Reverting to original interface.

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
FAIL: /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.sh.cpp:137
GDB printed:
   VALUE_FIELD: {{__l = {__cap_ = 1784965908, __size_ = 1802726502, __data_ = 0x666a64 <error: Cannot access memory at address 0x666a64>}, __s = {{__size_ = 20 '\024', __lx = 20 '\024'}, __data_ = "kdjflskdjf"}, __r = {__words = {1784965908, 1802726502, 6711908}}}}
"kdjflskdjf"
Value should match:
Traceback (most recent call last):
  File "/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.py", line 64, in invoke
    print(" " + check_literal)
TypeError: Can't convert 'bytes' object to str implicitly
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'

Hi Sterling,

It in indeed a python3 issue, where it is being used as default on the
bot. Besides the check_literal format issue, python3 next iteration
method has changed its name to __next__ which requires some internal
adjustments. I am not trying to fix a remaining issue with bitset
printer.

I’ll look into sorting this out. Strange that no other build bots are using python3 by default.

I have fixed most of the issue, the missing one is for vector<bool>
that I can't understand why gdb and pretty-printer are differing.

The testcase code:

380 void vector_test() {
381 std::vector<bool> test0 = {true, false};
382 ComparePrettyPrintToChars(test0,
383 "std::vector<bool> of "
384 "length 2, capacity 64 = {1, 0}");

and

390 ComparePrettyPrintToRegex(
391 test0,
392 "std::vector<bool> of length 64, "
393 "capacity 64 = {1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, "
394 "0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, "
395 "0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0}");
396 test0.push_back(true);

Are failing with

FAIL: /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.sh.cpp:382
GDB printed:
   std::vector<bool> of length 2, capacity 32 = {1, 0}
Value should match:
   std::vector<bool> of length 2, capacity 64 = {1, 0}
PASS: /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.sh.cpp:390
FAIL: /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.sh.cpp:398
GDB printed:
   std::vector<bool> of length 65, capacity 96 = {1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1}
Value should match:
   std::vector<bool> of length 65, capacity 128 = {1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1}

Debugging a little it seems the pretty-printer obtains 1 and 3
respectively for test0.__cap_alloc_.__value_ in such cases. However
attaching gdb directly shows it does contain 2 and 4 as expected.

I am trying to find out exactly what is happening here.

These are the changes I am using so far:

I think the capacity mismatch failures are machine specific, and I’m guessing they are tuned differently on armv7 vs x86. So probably just need to change the expectation to be generic.

It still don't explain why dumping using gdb interactively differs from the
pretty-printer.