[Bug libstdc++/53006] New: libstdc++-prettyprinters/shared_ptr.cc FAILs

[Bug libstdc++/53006] New: libstdc++-prettyprinters/shared_ptr.cc FAILs

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53006

             Bug #: 53006
           Summary: libstdc++-prettyprinters/shared_ptr.cc FAILs
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ro@gcc.gnu.org
                CC: tromey@gcc.gnu.org
              Host: i386-pc-solaris2.11
            Target: i386-pc-solaris2.11
             Build: i386-pc-solaris2.11


Since prettyprinters.exp has been enabled recently, the shared_ptr.cc test
FAILs on Solaris 11/x86 only:

FAIL: libstdc++-prettyprinters/shared_ptr.cc print esp
FAIL: libstdc++-prettyprinters/shared_ptr.cc print ewp1
FAIL: libstdc++-prettyprinters/shared_ptr.cc print ewp2
FAIL: libstdc++-prettyprinters/shared_ptr.cc print sp1
FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp1
FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp2

I'm using a 64-bit gdb 7.4 linked with the vendor-supplied libpython2.6.so
(same problem with libpython2.7.so).

In libstdc++.log, I find:

$1 = skipping: 80         return 0;^M
Python Exception <type 'exceptions.TypeError'> expected string or buffer: ^M
Python Exception <type 'exceptions.TypeError'> expected string or buffer: ^M
got: $1 = Python Exception <type 'exceptions.TypeError'> expected string or
buffer: ^M
FAIL: libstdc++-prettyprinters/shared_ptr.cc print esp
skipping: Python Exception <type 'exceptions.TypeError'> expected string or
buffer: ^M
std::shared_ptr (empty) 0x0^M

Manually running gdb with the equivalent of the generated shared_ptr.gdb file,
I
get:

(gdb) print esp
Python Exception <type 'exceptions.TypeError'> expected string or buffer: 
Python Exception <type 'exceptions.TypeError'> expected string or buffer: 
$1 = std::shared_ptr (empty) 0x0

Unfortunately, expect/dejagnu merge stdout and stderr here, causing the mixture
of both streams.

When I set python print-stack full first, I get:

(gdb) print esp
$1 = Traceback (most recent call last):
  File
"/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/../python/libstdcxx/v6/printers.py",
line 777, in __call__
    match = self.compiled_rx.match(typename)
TypeError: expected string or buffer

Traceback (most recent call last):
  File
"/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/../python/libstdcxx/v6/printers.py",
line 777, in __call__
    match = self.compiled_rx.match(typename)
TypeError: expected string or buffer
std::shared_ptr (empty) 0x0

I cannot really make sense of that (barely knowing python), but if I add

    print type(typename)

in printers.py, I find:

<type 'NoneType'>

Strangely, the same gdb binary works on Solaris 10 with the bundled
libpython2.6.so, so this might be a bug in that library on Solaris 11.

Suggestions?

  Rainer

[Bug libstdc++/53006] libstdc++-prettyprinters/shared_ptr.cc FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53006

--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-04-16 12:27:06 UTC ---
> Strangely, the same gdb binary works on Solaris 10 with the bundled
> libpython2.6.so, so this might be a bug in that library on Solaris 11.

Indeed when I point gdb at a copy of the Solaris 10 libpython2.6.so on
Solaris 11 via LD_LIBRARY_PATH_64, the test passes as well ;-(  Seems
like a bug in the Solaris 11 libpython, after all.

    Rainer

[Bug libstdc++/53006] libstdc++-prettyprinters/shared_ptr.cc FAILs

[tromey at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53006

--- Comment #2 from Tom Tromey <tromey at gcc dot gnu.org> 2012-04-16 18:01:17 UTC ---
(In reply to comment #0)

>     match = self.compiled_rx.match(typename)

>     print type(typename)
> <type 'NoneType'>

This is very odd.  The code in context:

        typename = self.get_basic_type(val.type)
        if not typename:
            return None

        # All the types we match are template types, so we can use a
        # dictionary.
        match = self.compiled_rx.match(typename)

If typename is None, we should have taken the "return None" branch.

I tend to agree it is a python problem as you stated in comment #1.

[Bug libstdc++/53006] libstdc++-prettyprinters/shared_ptr.cc FAILs

[bkoz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53006

Benjamin Kosnik <bkoz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bkoz at gcc dot gnu.org

--- Comment #3 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2012-04-25 00:07:37 UTC ---

Any suggestions on how to resolve this Ranier?

[Bug libstdc++/53006] libstdc++-prettyprinters/shared_ptr.cc FAILs

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53006

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Rainer Orth <ro at gcc dot gnu.org> ---
It turned out this is caused by the way libpython is built on Solaris 11.  This
is
covered by Solaris bug

        16803687 libpython exports protected data - compromises COPY
relocations

It has already be fixed in Solaris 12; the fix may be backported to Solaris 11
updates.

  Rainer