[Bug c++/17139] New: 'info locals' crashes in presence of unordered_map

[Bug c++/17139] New: 'info locals' crashes in presence of unordered_map

[MikeGebirge at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17139

            Bug ID: 17139
           Summary: 'info locals' crashes in presence of unordered_map
           Product: gdb
           Version: 7.7
            Status: NEW
          Severity: critical
          Priority: P2
         Component: c++
          Assignee: unassigned at sourceware dot org
          Reporter: MikeGebirge at gmail dot com

Created attachment 7693
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7693&action=edit
small program that gdb can't handle on my machine

Crash on 'info locals' in presence of unordered_map

Steps to reproduce: Download the attached file gdbcrash.cpp and follow
the instructions (compile, run, debug), including the final call 'info locals'.

Expected behaviour: Any meaningful output.

Observed behaviour: gdb hangs, consumes 100% CPU (a single core), and 
"slowly" (tens of seconds) allocates more and more memory, 
eventually allocating >10 GiB memory and exhausting my machine. The 
call 'info locals' never returns or prints any useful information.

Discovered while trying to debug an application using an unordered_map. 
As soon as I remove the unordered_map, gdb works as expected.
The thing with unordered_map is pure speculation, though.

I marked this 'critical' as it makes it impossible for me to do any 
meaningful debugging using gdb on an application I'm writing.

First encountered in gdb 7.6.2, but still present in gdb 7.7.1

Versions:
GNU gdb (Debian 7.7.1-2) 7.7.1
  'This GDB was configured as "x86_64-linux-gnu".'
GNU gdbserver (Debian 7.7.1-2) 7.7.1
gcc version 4.9.0 (Debian 4.9.0-7)
  Note that your compiler must support c++11 to support unordered_map
Linux 3.14-1-amd64
Debian Testing, with gdb & gdbserver (and only those two) from Sid

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/17139] 'info locals' crashes in presence of unordered_map

[MikeGebirge at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17139

MikeGebirge at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |MikeGebirge at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/17139] 'info locals' crashes in presence of unordered_map

[MikeGebirge at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17139

--- Comment #1 from MikeGebirge at gmail dot com ---
I've downloaded the deb-src of gdb, built it locally (./configure, make, sudo
make install, just as the README described), which yielded this version:

$ gdb -v
GNU gdb (GDB) 7.7.1
This GDB was configured as "x86_64-unknown-linux-gnu".

... and this version doesn't crash anymore. Instead, it behavves as expected:
It prints information about the local variables.

I'm very sure that it is *this* change that caused it, as I haven't changed
anything else; I didn't even recompile gdbcrash.cpp. (Thanks to Marc-Andre
Laperle https://bugs.eclipse.org/bugs/show_bug.cgi?id=439160#c5 for confirming
this).

As the two gdb versions report different 'This GDB was configured for', I'd
like to suggest that the bug is still there, but now just hidden. Therefore I
see this as a workaround, not a fix.

I still have the faulty, 'original' installation available, so if anyone has
any idea and wants me to test something, I'd be glad to help.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/17139] 'info locals' crashes in presence of unordered_map

[malaperle at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17139

Marc-Andre Laperle <malaperle at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |malaperle at gmail dot com

--- Comment #2 from Marc-Andre Laperle <malaperle at gmail dot com> ---
Hi Mike. When you compiled from debian sources, were the debian patches
applied? I'm talking about the patches in debian/patches. It would be good to
confirm that those are not causing the crash.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/17139] 'info locals' crashes in presence of unordered_map

[MikeGebirge at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17139

--- Comment #3 from MikeGebirge at gmail dot com ---
Yes, I did, because apt-get source automatically applies all debian patches. 

So I'm in the situation:
- Debian testing's .deb does NOT work
  ("GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1.1+b1)", "x86_64-linux-gnu")
- Debian sid's .deb does NOT work
  ("GNU gdb (Debian 7.7.1-2) 7.7.1", "x86_64-linux-gnu")
- Debian sid's deb-src (including patches) DOES work
  ("GNU gdb (GDB) 7.7.1", "x86_64-unknown-linux-gnu")

I took the time to test each of the above four sentences (three about versions
and one about 'apt-get source' and really really applying the patches.)

I have no idea what the problem is, but at least I have that workaround, so I'd
be curious and open for suggestions, but it doesn't seem like anyone else is
affected(?)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug c++/17139] 'info locals' crashes in presence of unordered_map

[jan.kratochvil at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17139

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan.kratochvil at redhat dot com

--- Comment #4 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
(gdb) info locals 
edges = std::unordered_multimap with 4203821 elements<error reading variable:
Cannot access memory at address 0x2>

This means the variable is uninitialized.  This is a known problem of GDB
pretty printers - when the size is valid vs. when it should be considered
invalid. Some users have really very large arrays in the programs.

The real fix would be to make all the GDB values processing and pretty printers
evaluated iteratively - not fetching the whole array object from inferior.  But
that is a larger change.

One should use 'ulimit -v 2000000' for GDB plus Fedora uses one hack:
 
http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-bz568248-oom-is-error.patch

Also one solution would be if GCC provided proper annotations when the variable
is initialized - this works only for -O2 -g code which is not much suitable for
debugging.  Not sure about -Og.  For some unknown reason -O2 -g does not mark
the variable as <optimized out> before its initialization in this case, though.

wrt reproducibility - this should rather depend on the inferior compilation
than on GDB itself.

-- 
You are receiving this mail because:
You are on the CC list for the bug.