[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

--- Comment #18 from Jonathan Wakely  ---
But we can remove the [8 Regression] marker if it's messing with reports.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

--- Comment #17 from Jonathan Wakely  ---
Ideally I want the printer to still work for users with older versions of gdb.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

--- Comment #16 from Jakub Jelinek  ---
So just add a gdb >= 8.1 version test in
libstdc++-v3/testsuite/lib/gdb-test.exp
and guard this test on effective target gdb_8_1?

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|FIXED   |---

--- Comment #15 from Jonathan Wakely  ---
I'd like to add a workaround so it works with older GDB versions. There's more
to life than ensuring our testsuite has no FAILs :-)

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

H.J. Lu  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from H.J. Lu  ---
Fixed by gdb.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[palves at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

--- Comment #13 from Pedro Alves  ---
Fix is now in GDB's master, 8.1, and 8.0 branches.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[palves at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

--- Comment #12 from Pedro Alves  ---
GDB fix posted here:
 https://sourceware.org/ml/gdb-patches/2018-01/msg00482.html

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[palves at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

--- Comment #11 from Pedro Alves  ---
Running the testcase under valgrind and current gdb master I see:


==6118== Conditional jump or move depends on uninitialised value(s)
==6118==at 0x4C35CB0: bcmp (vg_replace_strmem.c:1100)
==6118==by 0x6F773A: check_types_equal(type*, type*,
VEC_type_equality_entry_d**) (gdbtypes.c:3515)
==6118==by 0x6F7B00: check_types_worklist(VEC_type_equality_entry_d**,
bcache*) (gdbtypes.c:3618)
==6118==by 0x6F7C03: types_deeply_equal(type*, type*) (gdbtypes.c:3655)
==6118==by 0x4D5B06: typy_richcompare(_object*, _object*, int)
(py-type.c:1007)
==6118==by 0x63D7E6C: PyObject_RichCompare (object.c:961)
==6118==by 0x646EAEC: PyEval_EvalFrameEx (ceval.c:4960)
==6118==by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118==by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118==by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118==by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118==by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)


AFAICT so far, looks like gdb is memcmp'ing two objects that only differ in
padding.  Looks like objects of this type range_bounds are always memset when
allocated, so I'm not sure that is going on.  (The type is trivial.)

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[palves at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

Pedro Alves  changed:

   What|Removed |Added

 CC||palves at redhat dot com

--- Comment #10 from Pedro Alves  ---
GDB starts inferiors with ASLR disabled by default:

 (gdb) show disable-randomization 
 Disabling randomization of debuggee's virtual address space is on.

so if this is ASLR, it's going to be ASLR of the gdb process.

Which sounds consistent with Jonathan's finding.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

Jakub Jelinek  changed:

   What|Removed |Added

 CC||palves at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
If I retry this while :; do echo -n .; make check
RUNTESTFLAGS=prettyprinters.exp=80276.cc > /dev/null 2>/dev/null; grep -q ^FAIL
testsuite/libstdc++.log && break; done
under setarch x86_64 -R /bin/sh shell, I see no random failures, 20 PASSes in a
row, then I've Ctrl-Ced it.
The question is if this is because of ASLR of the gdb process, or ASLR of the
debugger process.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #8 from Jonathan Wakely  ---
The bug is here:

if self.type_obj == type_obj:
return strip_inline_namespaces(self.name)

This assumes the two types resolve to the same gdb.Type but that isn't
guaranteed.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

--- Comment #7 from Jakub Jelinek  ---
Actually, the bug seems to FAIL at random, as shown by:
while :; do echo -n .; make check RUNTESTFLAGS=prettyprinters.exp=80276.cc >
/dev/null 2>/dev/null; grep -q ^FAIL testsuite/libstdc++.log && break; done
Got one FAIL after printing 3 dots, another time after 5 dots, then 1 dot, 1
dot again.

With patched 80276.cc with your patch, I get one FAIL after printing 2 dots,
then 1 dot, 1 dot, 5 dots.

So no, this patch doesn't help.  This was i686-linux build,
gdb-8.0.1-33.fc27.x86_64.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
I've even seen in one recent regtest:
FAIL: libstdc++-prettyprinters/80276.cc whatis p4
FAIL: libstdc++-prettyprinters/80276.cc whatis p4
where both normal15 and normal16 directories contained the FAILs.
Perhaps the parallelization of libstdc++ tests got out of sync?

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

--- Comment #5 from H.J. Lu  ---
(In reply to Jonathan Wakely from comment #4)
> Ah, or maybe the typedef std::__cxx11::string is not in the debug info, so
> the type printer doesn't know that std::__cxx11::basic_string is the
> same type as std::__cxx11::string.
> 
> In testsuite/libstdc++-prettyprinters/whatis.cc we have a relevant comment:
> 
> // This test is written in a somewhat funny way.
> // Each type under test is used twice: first, to form a pointer type,
> // and second, as a template parameter.  This is done to work around
> // apparent GCC oddities.  The pointer type is needed to ensure that
> // the typedef in question ends up in the debuginfo; while the
> // template type is used to ensure that a typedef-less variant is
> // presented to gdb.
> 
> 
> Does this patch help?
> 
> --- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
> +++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
> @@ -36,6 +36,7 @@ placeholder(const T *s)
>  int
>  main()
>  {
> +  std::string *string_ptr;
>using namespace std;
>unique_ptr>> p1;
>unique_ptr>[]> p2;
> @@ -50,6 +51,7 @@ main()
>placeholder();
>placeholder();
>placeholder();
> +  placeholder(_ptr);
>  
>std::cout << "\n";
>return 0;

This doesn't explain why does it fail at random.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

--- Comment #4 from Jonathan Wakely  ---
Ah, or maybe the typedef std::__cxx11::string is not in the debug info, so the
type printer doesn't know that std::__cxx11::basic_string is the same
type as std::__cxx11::string.

In testsuite/libstdc++-prettyprinters/whatis.cc we have a relevant comment:

// This test is written in a somewhat funny way.
// Each type under test is used twice: first, to form a pointer type,
// and second, as a template parameter.  This is done to work around
// apparent GCC oddities.  The pointer type is needed to ensure that
// the typedef in question ends up in the debuginfo; while the
// template type is used to ensure that a typedef-less variant is
// presented to gdb.


Does this patch help?

--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/80276.cc
@@ -36,6 +36,7 @@ placeholder(const T *s)
 int
 main()
 {
+  std::string *string_ptr;
   using namespace std;
   unique_ptr>> p1;
   unique_ptr>[]> p2;
@@ -50,6 +51,7 @@ main()
   placeholder();
   placeholder();
   placeholder();
+  placeholder(_ptr);

   std::cout << "\n";
   return 0;

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-19
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
That suggests the type printer for std::__cxx11::string is not being used, so
maybe it's conflicting with another printer, and so the result depends which
gets found first.

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

--- Comment #2 from H.J. Lu  ---
type =
std::unique_ptr>[]>>[99]>^M 
got: type =
std::unique_ptr>[]>>[99]>^M
FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

--- Comment #1 from Jonathan Wakely  ---
What is shown in the libstdc++.log file before the FAIL line?

[Bug libstdc++/83906] [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0