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.
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 [...]
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.
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>}
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.
[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
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.