Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

I would like to be able to inspect the contents of the map running the program from gdb.
If I try using the subscript operator I get:

(gdb) p m[1]
Attempt to take address of value not located in memory.

Using the find method does not yield better results:

(gdb) p m.find(1)
Cannot evaluate function -- may be inlined

Is there a way to accomplish this?

To print all elements without truncating large maps: stackoverflow.com/questions/47743215/… A more "Cannot evaluate function maybe inlined" focused: stackoverflow.com/questions/40633787/… – Ciro Santilli OurBigBook.com Sep 24, 2020 at 12:09

The existing answers to this question are very out of date. With a recent GCC and GDB it Just WorksTM thanks to the built-in Python support in GDB 7.x and the libstdc++ pretty printers that come with GCC.

For the OP's example I get:

(gdb) print m
$1 = std::map with 2 elements = {[1] = 2, [2] = 4}

If it doesn't work automatically for you see the first bullet point on the STL Support page of the GDB wiki.

You can write Python pretty printers for your own types too, see Pretty Printing in the GDB manual.

Yes, but other questions are getting closed as duplicates of it, so I wanted it to have recent information. – Jonathan Wakely Mar 11, 2013 at 9:12 I am using GDB 7.2 and the above works ... if you have a small collection. I still haven't found any way to print say element 1543 from a 4K vector, other than resorting to using internal structures of the STL implementation. – pavon Oct 9, 2013 at 18:35 Unfortunately it doesn't "Just Work" in all the distros. It isn't installed by default in Ubuntu 13.10 and there are problems when you try to install it manually – nietaki Jan 9, 2014 at 22:18 @razeh, Fedora, RHEL (and RHEL clones). There's a fix in progress to make the printers also work on distros where GDB is linked to Python 3 – Jonathan Wakely Jul 10, 2014 at 16:33

I think there isn't, at least not if your source is optimized etc. However, there are some macros for gdb that can inspect STL containers for you:

http://sourceware.org/ml/gdb/2008-02/msg00064.html

However, I don't use this, so YMMV

Thanks for the link; the only thing is that macros are dependent from the stl libraries version, which I'd prefer to avoid. +1 – Paolo Tedesco Jan 9, 2009 at 10:41 Its also a bit frustrating that commands like "plist foo std::string" give syntax errors. It appears that the value_type can't contain any punctuation. – Bklyn Jan 9, 2009 at 21:49 I haven't tried, but if this works the same as the rest of GDB, enclosing the name with punctuated name in single quotes should do it. – jpalecek Jan 9, 2009 at 23:35 Note: the std::map functionality in these scripts assumes 32-bit pointer types. For 64-bit machines, replace "+ 4" to "+ 8" everywhere in the file. – Kyle Simek May 20, 2012 at 20:22

There's always the obvious: Define your own test-function... Call it from gdb. E.g.:

#define SHOW(X) cout << # X " = " << (X) << endl
void testPrint( map<int,int> & m, int i )
  SHOW( m[i] );
  SHOW( m.find(i)->first );
main()
    std::map<int,int> m;
    m[1] = 2;
    m[2] = 4;
    return 0;  // Line 15.
Breakpoint 1 at 0x400e08: file foo.C, line 15.
(gdb) run
Starting program: /tmp/z/qD 
Breakpoint 1, main () at qD.C:15
(gdb) call testPrint( m, 2)
m[i] = 4
(*m.find(i)).first = 2
(gdb) 
                This is useful advice debug GDB in general, not just with STL.  I keep a whole library of gdb helper functions for lots of hard-to-retrieve data, e.g. write_cuda_array_as_image().  Note that some compilers will strip out any functions that aren't called, so I place a call to each helper function after my main's "return 0;".  Also declaring them with extern "C" makes calling them from gdb easier.
– Kyle Simek
                May 20, 2012 at 20:30
                @KyleSimek gcc also supports ` __attribute__((used))` so the linker won't toss the symbol if unused
– Dodgie
                Jun 2, 2021 at 14:15

The stl-views.gdb used to be the best answer there was, but not anymore.

This isn't integrated into the mainline GDB yet, but here is what you get using the 'archer-tromey-python' branch:

(gdb) list
1   #include <map>
2   int main(){
3       std::map<int,int> m;
4       m[1] = 2;
5       m[2] = 4;
6       return 0;
7   }
(gdb) break 6
Breakpoint 1 at 0x8048274: file map.cc, line 6.
(gdb) run
Breakpoint 1, main () at map.cc:6
6       return 0;
(gdb) print m
$1 = std::map with 2 elements = {
  [1] = 2,
  [2] = 4
(gdb) quit
                They're actually the same macros as in the previous answer :) I'm afraid there's no simpler solution.
– Paolo Tedesco
                Jan 9, 2009 at 14:59
                What is the command? You managed to run us off-site with copious amounts of irrelevant information. I'm not interested in "How to start GDB" and the others.
– jww
                Apr 10, 2016 at 1:30

The answers above are working and fine. In case you are using stl-views.gdb, here is the proper way of viewing the maps and elements inside it. Let your map is as follows : std::map<char, int> myMap;

(gdb) pmap myMap char int

i.e. pmap <variable_name> <left_element_type> <right_element_type> to see the elements in the map.

Hope that helps.

You can get around the second problem (Cannot evaluate function -- may be inlined) by making sure that your compiler uses DWARF-2 (or 3 or 4) debugging information when you compile your program. DWARF-2 includes inlining information, so you should be able to use either of the methods you described to access elements of your std::map container.

To compile with DWARF-2 debug info, add the -gdwarf-2 flag to your compile command.

Um, knowing where a function has been inlined does not make it possible for GDB to evaluate calls to that function; GDB really needs access to an out-of-line copy of the function! – SamB Feb 3, 2015 at 3:09

Thanks for contributing an answer to Stack Overflow!

  • Please be sure to answer the question. Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.