Description of problem: I am trying to track down a problem in the geos package that only manifests on s390x. I am doing side-by-side debugging sessions with x86_64 Rawhide (which produces the correct answer) and s390x Rawhide (which does not). The x86_64 debug session uses the python C++ pretty printers; the s390x session does not. For example, on x86_64: (gdb) print ee0 $17 = std::vector of length 6, capacity 8 = {0x41aa90, 0x41ab20, 0x41abb0, 0x41ac20, 0x41ac90, 0x41ad50} while on s390x: (gdb) print ee0 $17 = {<std::_Vector_base<geos::geomgraph::EdgeEnd*, std::allocator<geos::geomgraph::EdgeEnd*> >> = { _M_impl = {<std::allocator<geos::geomgraph::EdgeEnd*>> = {<__gnu_cxx::new_allocator<geos::geomgraph::EdgeEnd*>> = {<No data fields>}, <No data fields>}, <std::_Vector_base<geos::geomgraph::EdgeEnd*, std::allocator<geos::geomgraph::EdgeEnd*> >::_Vector_impl_data> = {_M_start = 0x10197d0, _M_finish = 0x10197f0, _M_end_of_storage = 0x10197f0}, <No data fields>}}, <No data fields>} Version-Release number of selected component (if applicable): gdb-9.1-7.fc33.s390x How reproducible: I have only tried with geos. Steps to Reproduce: 1. Build the geos package on s390x 2. Attempt to debug it 3. Print any variable containing a C++ standard container Actual results: Internal implementation details of the container. Expected results: Pretty-printed representation. Additional info:
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
I've reproduced this bug... On x86_64: [kevinb-fedora@rawhide-1 geos-3.8.1]$ gdb -q bin/example Reading symbols from bin/example... (gdb) b src/operation/relate/RelateComputer.cpp:188 No source file named src/operation/relate/RelateComputer.cpp. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (src/operation/relate/RelateComputer.cpp:188) pending. (gdb) run ... Breakpoint 1, geos::operation::relate::RelateComputer::computeIM ( this=this@entry=0x7fffffffd180) at /mesquite2/fedora/x86_64/geos/geos-3.8.1/src/operation/relate/RelateComputer.cpp:188 188 std::vector<EdgeEnd*> ee0 = eeBuilder.computeEdgeEnds((*arg)[0]->getEdges()); (gdb) n 189 insertEdgeEnds(&ee0); (gdb) p ee0 $1 = std::vector of length 0, capacity 0 On s390x: [kevinb-fedora@rawhide-s390x-m1 geos-3.8.1]$ gdb -q bin/example Reading symbols from bin/example... (gdb) b src/operation/relate/RelateComputer.cpp:188 No source file named src/operation/relate/RelateComputer.cpp. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (src/operation/relate/RelateComputer.cpp:188) pending. (gdb) run ... Breakpoint 1, geos::operation::relate::RelateComputer::computeIM ( this=this@entry=0x3ffffffe968) at /mesquite2/fedora/s390x/geos/geos-3.8.1/src/operation/relate/RelateComputer.cpp:188 188 std::vector<EdgeEnd*> ee0 = eeBuilder.computeEdgeEnds((*arg)[0]->getEdges()); (gdb) n 189 insertEdgeEnds(&ee0); (gdb) p ee0 $1 = std::vector of length -4237119, capacity -4310050 = {0x0, 0x0, 0x3fffdfaaf70, 0x3fffdcce7c0, 0x3fffdbe1520 <std::ostreambuf_iterator<char, std::char_traits<char> > std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_insert_int<unsigned long>(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, unsigned long) const+288>, 0x3ffffffe918, 0x0, 0x0, 0x7ff8000000000000, 0x0, 0x0, 0x7ff8000000000000, 0x2aa0002d560, 0x3fffdcd00d0, 0x3d1112177d97e0, 0x2aa00027620, 0x3ffffffe950, 0x3fffdf5df78 <vtable for geos::geomgraph::NodeMap+16>, 0x3ff00000002, 0x0, 0x2aa0002ddd0, 0x2aa0002ddd0, 0x2aa0002ddd0, 0x1, 0x3fffdf654d8 <geos::operation::relate::RelateNodeFactory::instance()::rnf>, 0x2aa0002dd40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7ff8000000000000, 0x3d1112177d97e0, 0x3fffdcd0c38, 0x0, 0x3fffdbe16f0 <std::__gnu_cxx_ldbl128::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::do_put(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, unsigned long) const>, 0x3ffffffeba0, 0x3fffdfaaf70, 0x3fffd9cb2a8 <__GI__IO_file_jumps>, 0x3ffffffecb8, 0x2aa000275a0, 0x3fffdff8b50, 0x2aa00025190, 0x3fffdff8b50, 0x3ffffffebb8, 0x3fffdfaaf70, 0x2aa0000aa20, 0x3fffde3750a <geos::geom::Geometry::relate(geos::geom::Geometry const*) const+42>, 0x3ffffffea70, 0x3ffffffea78, 0x3fffd88479e <fflush+158>, 0x3ffffffea88, 0x2aa0002ca58, 0x3d1112177d97e0, 0x13d1112177d97e0, 0x3fffdccf1d8 <std::cout>, 0x3ffffffeba0, 0x2aa0003dbd0, --Type <RET> for more, q to quit, c to continue without paging--
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
Created attachment 1711796 [details] Simple test case Attachment b.cc is a much simpler (and quicker to build) test case than using the geos package. Compile as follows: g++ -g -o b b.cc Running it in gdb: [kevinb-fedora@f32-s390x-m1 1842325]$ gdb -q ./b Reading symbols from ./b... (gdb) start Temporary breakpoint 1 at 0x1000ac0: file b.cc, line 7. Starting program: /mesquite2/fedora/1842325/b Temporary breakpoint 1, main () at b.cc:7 7 std::vector<int> v; (gdb) n 9 v.push_back (42); (gdb) p v $1 = std::vector of length 1099499031998, capacity 1099498952642 = {1023, -40717744, 0, 16779582, 0, 16779614, 0, 16779646, 0, 16779678, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0...} When gdb's pretty printers are working correctly, the output appears as follows: [root@ibm-z-103 1842325]# gdb -q b Reading symbols from b... (gdb) start Temporary breakpoint 1 at 0x1000ac0: file b.cc, line 7. Starting program: /root/1842325/b Temporary breakpoint 1, main () at b.cc:7 7 std::vector<int> v; (gdb) n 9 v.push_back (42); (gdb) p v $1 = std::vector of length 0, capacity 0
Jerry - Can you provide me with more information about your s390x environment? Specifically, is your s390x machine real hardware or an emulator (like QEMU)? I've been able to reproduce this problem in both Fedora 32 and rawhide when using an emulated virtual machine. However, when I run it on real hardware (though still a VM, but not an architecture emulation), it works correctly. The latter test was only run on Fedora 32; I haven't tried it yet on rawhide. Also, if using QEMU, do you know of a Fedora release when GDB pretty printing worked correctly? (I have more to say about all of this, but I don't want to clutter up the "needinfo" comment overly much...)
Dan Horák kindly gave me an account on lfedora1.lf-dev.marist.edu, which I believe is a VM running on real hardware. It is currently on Fedora 31, but I was in a Rawhide mock chroot when I encountered the problem. I do not know of a release when GDB pretty printing worked correctly, sorry.
(In reply to Jerry James from comment #6) > Dan Horák kindly gave me an account on lfedora1.lf-dev.marist.edu, which I > believe is a VM running on real hardware. It is currently on Fedora 31, but > I was in a Rawhide mock chroot when I encountered the problem. > > I do not know of a release when GDB pretty printing worked correctly, sorry. Thanks for the info. I'll see if I can get access to a non-emulated f31 s390x machine to run some more tests.
(In reply to Kevin Buettner from comment #4) > [kevinb-fedora@f32-s390x-m1 1842325]$ gdb -q ./b > Reading symbols from ./b... > (gdb) start > Temporary breakpoint 1 at 0x1000ac0: file b.cc, line 7. > Starting program: /mesquite2/fedora/1842325/b > > Temporary breakpoint 1, main () at b.cc:7 > 7 std::vector<int> v; > (gdb) n > 9 v.push_back (42); > (gdb) p v > $1 = std::vector of length 1099499031998, capacity 1099498952642 = {1023, > -40717744, 0, 16779582, 0, 16779614, 0, 16779646, 0, 16779678, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0...} That output, while incorrect, is actually still being pretty-printed. I think that there are two problems at play here, the first being the pretty-printing problem, and the second being a step / next problem with GDB when run on machines using QEMU emulation. I'll try to come up with a better test case which is short, but still demonstrated the pretty-printing problem.
I've just realized that I haven't been able to reproduce this problem at all! Even back in Comment 2 pretty printers were being used. The output is wrong, but it *is* still pretty-printed. (This incorrect output is due to a different problem entirely. I plan to file a bug report regarding that problem.) Pretty-printed output for variables of type std::vector will start with the string "std::vector of length...". When the variable is not pretty-printed, it'll begin with a string which looks something like this: "{<std::_Vector_base<int, std::allocator<int> >> =...". There are a number of conditions which might lead to the python pretty-printers not being used. These include, but are (probably) not limited to... 1) libstdc++.so.*-gdb.py is missing from /usr/share/gdb/auto-load/lib64 (or from wherever GDB's auto-load scripts-directory is set). 2) GDB's auto-load scripts-directory does not include the location of libstdc++.so.*-gdb.py. 3) GDB's auto-load safe-path" does not permit libstdc++.so.*-gdb.py to be loaded. Jerry, if you can still reproduce this problem, can you check to see if any of the three conditions listed above exist in your test environment?
Well, I can't reproduce it now. I don't know if something changed to make it go away or what, but C++ objects are being pretty printed as I expect. *shrug*
(In reply to Jerry James from comment #10) > Well, I can't reproduce it now. I don't know if something changed to make > it go away or what, but C++ objects are being pretty printed as I expect. > *shrug* Thanks for checking. I'll close this bug...