[libcxx-dev] gdb on libcxx-libcxxabi-libunwind-armv7-linux build bot

Adhemerval Zanella via libcxx-dev libcxx-dev at lists.llvm.org
Tue Sep 10 14:54:31 PDT 2019


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:

---
Index: test/pretty_printers/gdb_pretty_printer_test.py
===================================================================
--- test/pretty_printers/gdb_pretty_printer_test.py     (revision 371324)
+++ test/pretty_printers/gdb_pretty_printer_test.py     (working copy)
@@ -50,8 +50,9 @@
                 check_literal = expectation_val.string()
                 test_fails = not re.match(check_literal, value)
             else:
-                check_literal_string = expectation_val.string(encoding="utf-8")
-                check_literal = check_literal_string.encode("utf-8")
+                #check_literal_string = expectation_val.string(encoding="utf-8")
+                #check_literal = check_literal_string.encode("utf-8")
+                check_literal = expectation_val.string(encoding="utf-8")
                 test_fails = value != check_literal

             if test_fails:
Index: utils/gdb/libcxx/printers.py
===================================================================
--- utils/gdb/libcxx/printers.py        (revision 371324)
+++ utils/gdb/libcxx/printers.py        (working copy)
@@ -13,9 +13,15 @@

 from __future__ import print_function

+import sys
 import re
 import gdb

+if sys.version_info >= (3, 0):
+  py3k = True
+else:
+  py3k = False
+
 # One under-documented feature of the gdb pretty-printer API
 # is that clients can call any other member of the API
 # before they call to_string.
@@ -131,18 +137,23 @@
         def __init__(self, val):
             self.val = val
             self.child_iter = iter(self.val["__base_"].type.fields())
+            if not py3k:
+                self.child_iter.next == self.child_iter.__next__
             self.count = 0

         def __iter__(self):
             return self

-        def next(self):
+        def __next__(self):
             # child_iter raises StopIteration when appropriate.
-            field_name = self.child_iter.next()
+            field_name = self.child_iter.__next__()
             child = self.val["__base_"][field_name]["__value_"]
             self.count += 1
             return ("[%d]" % self.count, child)

+        if not py3k:
+            next = __next__
+
     def __init__(self, val):
         self.val = val

@@ -315,7 +326,7 @@
         def __iter__(self):
             return self

-        def next(self):
+        def __next__(self):
             """Retrieve the next element."""

             self.count += 1
@@ -332,6 +343,9 @@
                 self.offset = 0
             return ("[%d]" % self.count, outbit)

+        if not py3k:
+            next = __next__
+
     class _VectorIterator(object):
         """Class to iterate over the non-bool vector's children."""

@@ -343,7 +357,7 @@
         def __iter__(self):
             return self

-        def next(self):
+        def __next__(self):
             self.count += 1
             if self.item == self.end:
                 raise StopIteration
@@ -351,6 +365,9 @@
             self.item += 1
             return ("[%d]" % self.count, entry)

+        if not py3k:
+            next = __next__
+
     def __init__(self, val):
         """Set val, length, capacity, and iterator for bool and normal vectors."""
         self.val = val
@@ -404,7 +421,7 @@
         while value:
             index += 1
             will_yield = value % 2
-            value /= 2
+            value //= 2
             if will_yield:
                 yield index
---


On 10/09/2019 18:45, Sterling Augustine wrote:
> I'll look into sorting this out. Strange that no other build bots are using python3 by default.
> 
> On Tue, Sep 10, 2019 at 12:38 PM Adhemerval Zanella <adhemerval.zanella at linaro.org <mailto:adhemerval.zanella at linaro.org>> wrote:
> 
>     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.
> 
>     On 09/09/2019 16:24, Adhemerval Zanella wrote:
>     > 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 at 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'
>     >
>     >
>     > On 09/09/2019 15:29, Sterling Augustine wrote:
>     >> 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.
>     >>
>     >> On Mon, Sep 9, 2019 at 11:15 AM Adhemerval Zanella <adhemerval.zanella at linaro.org <mailto:adhemerval.zanella at linaro.org> <mailto:adhemerval.zanella at linaro.org <mailto:adhemerval.zanella at linaro.org>>> wrote:
>     >>
>     >>     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.
>     >>
> 


More information about the libcxx-dev mailing list