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

Adhemerval Zanella via libcxx-dev libcxx-dev at lists.llvm.org
Wed Sep 11 05:05:22 PDT 2019


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

On 10/09/2019 18:59, Sterling Augustine wrote:
> 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. 
> 
> On Tue, Sep 10, 2019 at 2:54 PM Adhemerval Zanella <adhemerval.zanella at linaro.org <mailto:adhemerval.zanella at linaro.org>> wrote:
> 
>     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> <mailto: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>> <mailto: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