Bug 1279406 - Pretty-printing of STL objects switching on / off
Summary: Pretty-printing of STL objects switching on / off
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-09 11:48 UTC by Duco van Amstel
Modified: 2016-11-27 16:09 UTC (History)
12 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-11-27 16:09:42 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
GDB log with comments showcasing the behaviour (9.19 KB, text/plain)
2015-11-17 15:35 UTC, Duco van Amstel
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 68448 0 None None None Never

Description Duco van Amstel 2015-11-09 11:48:08 UTC
Description of problem:
While debugging various C++ codes pretty-printing of STL objects randomly switches off. Initial printing of such objects has the expected pretty-print formatting but somewhere after doing an n-th rerun or adding another breakpoint all STL prints give the raw data containers instead of pretty-print formatting. Once the "switch" has occurred the only way back is to exit gdb and run it again fresh. I've been able to rule out memory corruption for most cases so it looks like it is not caused by the raw container data within my programs becoming invalid.

This has been going on for several months now and was already happening in Fedora 22.

Here is a link to the ArchLinux forum where somebody has been experiencing the same issue back in 2014: https://bbs.archlinux.org/viewtopic.php?id=177967


Version-Release number of selected component (if applicable):
Currently 7.10-29 of GDB but this has been observed since at least May 2015 (if not before). GDB / GCC and libstdc++ versions have always been up-to-date with the current stable release in Fedora 22 & 23 with no specific plugins or add-ons.


How reproducible:
I have not managed until now to find a deterministic reproducible case. However the bug has been occurring consistently over multiple months of developing multiple unrelated C++ projects. This inability to provide a reproducible test-case stopped me from submitting a bug report until now but I'm getting tired of it and wanted to see if anybody else has been running into the same issue.


Actual results:
Printing of STL objects in GDB returns the raw container data of the object.


Expected results:
Printing of STL objects in GDB returns the pretty-printed content of the object.

Comment 1 Jan Kratochvil 2015-11-13 18:17:25 UTC
I have never seen that.  Although I re-run GDB together with inferiors, I never reload inferiors in GDB.

When that happens check at least:
(gdb) disable pretty-printer 
129 printers disabled
0 of 129 printers enabled
(gdb) info pretty-printer 
global pretty-printers:
  builtin [disabled]
    mpx_bound128
  objfile /lib64/libstdc++.so.6 pretty-printers:
  libstdc++-v6 [disabled]
[...]
(gdb) enable pretty-printer 
129 printers enabled
129 of 129 printers enabled
(gdb) info pretty-printer 
global pretty-printers:
  builtin
    mpx_bound128
  objfile /lib64/libstdc++.so.6 pretty-printers:
  libstdc++-v6
[...]

Comment 2 Duco van Amstel 2015-11-17 15:35:40 UTC
Created attachment 1095529 [details]
GDB log with comments showcasing the behaviour

You may have stumbled onto something. Even if it does not explain yet the reason for which this behaviour occurs.

Apparently my pretty-printers disappear somewhere along the road...

I'm providing a GDB log as an attachment where you can see the behaviour occurring (with some commments by myself) and the different outputs for the pretty-printer commands at separate points of execution.

Comment 3 Jan Kratochvil 2015-11-17 20:29:43 UTC
I have it reproducible now although I do not know the reason yet:

echo -e '#include <vector>\nint main(){std::vector<int> l;\nreturn 0;}'|g++ -g -Wall -x c++ -;gdb -q ./a.out -batch -ex 'b 3' -ex r -ex 'p l' -ex r -ex 'p l' 
[...]
$1 = std::vector of length 0, capacity 0
[...]
$2 = {<std::_Vector_base<int, std::allocator<int> >> = {_M_impl = {<std::allocator<int>> = {<__gnu_cxx::new_allocator<int>> = {<No data fields>}, <No data fields>}, _M_start = 0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}}, <No data fields>}

Comment 4 Duco van Amstel 2015-11-18 07:46:32 UTC
That's great news!

I never actually managed to get such a short example (hadn't thought of going THAT short...) where it occurs but I confirm that your command exhibits the same behaviour on my side. If I can be of any help just ask.

Some further info :
The example for which I gave the GDB log is actually reproducible (that's not always been the case on other occurrences) so I've been playing around a little bit. By trying different orderings of breakpoint, run and other commands I've become quite confident that the problems occurs at the second 'run' command: I was able to set a breakpoint before running and on the first run I was still able to pretty-print STL objects.

Comment 5 Jan Kratochvil 2015-11-19 20:22:52 UTC
[patch] Python Pretty Printers get disabled on libstdc++ reload by GDB (PR libstdc++/68448)
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02418.html

Comment 6 Fedora End Of Life 2016-11-24 13:14:07 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.


Note You need to log in before you can comment on or make changes to this bug.