[Bug c++/12126] New: gdb does not display source-level debugging for member function of a templated iterator.

[Bug c++/12126] New: gdb does not display source-level debugging for member function of a templated iterator.

[tfogal at alumni dot unh.edu]

http://sourceware.org/bugzilla/show_bug.cgi?id=12126

           Summary: gdb does not display source-level debugging for member
                    function of a templated iterator.
           Product: gdb
           Version: archer
            Status: NEW
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned@sourceware.org
        ReportedBy: tfogal@alumni.unh.edu


I'm seeing the following from a backtrace in some code I'm working on:

 #0  0x00007ffff574eed5 in raise () from /lib/libc.so.6
 #1  0x00007ffff57503f3 in abort () from /lib/libc.so.6
 #2  0x00007ffff5f6c4bc in __gnu_debug::_Error_formatter::_M_error() const ()
    from /usr/lib/libstdc++.so.6
 #3  0x00000000005c6e23 in std::__debug::vector<std::__debug::vector<unsigned
long, std::allocator<unsigned long> >,
std::allocator<std::__debug::vector<unsigned long, std::allocator<unsigned 
long> > > >::operator[](unsigned long) const ()
 #4  0x00000000005ed64b in RasterDataBlock::GetBrickSize (this=0xedbd60, 
vLOD=..., vBrick=...)
     at IO/UVF/RasterDataBlock.cpp:741
 #5  0x00000000005edbaa in RasterDataBlock::GetBrickByteSize (this=0xedbd60, 
vLOD=..., 
     vBrick=...) at IO/UVF/RasterDataBlock.cpp:1168
 #6  0x00000000005efa09 in RasterDataBlock::GetData (this=0xedbd60, vData=..., 
vLOD=..., 
     vBrick=...) at IO/UVF/RasterDataBlock.cpp:1229
 #7  0x0000000000500f87 in LODBrickIterator<unsigned short, -2>::NextBrick() ()
 #8  0x000000000050110b in LODBrickIterator<unsigned short, -2>::operator*() ()
 #9  0x00000000004d2eed in (anonymous namespace)::minmax_input<unsigned short,
LODBrickIterator<unsigned short, -0x00000000000000002> > (begin=..., end=...) 
at IO/IOManager.cpp:1588
 #10 0x00000000004d5a68 in IOManager::EvaluateExpression (this=0x7fffffffd6c0, 
    expr=0xb7c3b8 "v[0] + v[1]", volumes=..., out_fn=...) at 
IO/IOManager.cpp:1726
 #11 0x0000000000480d8b in main (argc=9, argv=0x7fffffffe118) at main.cpp:180
 (gdb) up 7
 #7  0x0000000000500f87 in LODBrickIterator<unsigned short, -2>::NextBrick() ()
 (gdb)

Both "NextBrick" and "operator*" are instantiated from a template, so of course
their definitions are available.  LODBrickIterator is define in
RasterDataBlock.h; IOManager.cpp is compiled with the options:

 g++ -c -ggdb -Wall -Wextra -O0 -D_DEBUG -D_FORTIFY_SOURCE=2 -D_GLIBCXX_DEBUG
-D_GLIBCXX_CONCEPT_CHECKS -fvisibility-inlines-hidden -fvisibility=hidden
-DDEBUG_DICOM -Werror -fno-strict-aliasing -fPIC -D_REENTRANT -Wall -W
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_OPENGL_LIB
-DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I.
-I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui
-I/usr/include/qt4/QtGui -I/usr/include/qt4/QtOpenGL
-I/usr/include/qt4/QtOpenGL -I/usr/include/qt4 -I. -I3rdParty/GLEW
-IIO/3rdParty/boost -IIO/3rdParty/zlib -IBasics -I/usr/X11R6/include -I. -I.
-I../Tuvok -o Build/objects/IOManager.o IO/IOManager.cpp

Yet when one uses 'up' to get to those methods, only their signature is
displayed.  'list' returns some other block of code, typically main.

This is using g++ 4.3.2 (Debian 4.3.2-1.1) on x86_64 Linux.  I'm using archer
a96476131a8045900eb407d2cc1fc712bcded2bc.  With stock gdb (6.8) on this
machine, I get warnings such as:

   warning: (Internal error: pc 0x5010b8 in read in psymtab, but not in
symtab.)

for the erroneous symbols as well as other ones.  This error does not occur
with archer, though with stock gdb I can actually see the correct source lines.

I'm attaching the core file and then the binary.  Apologies for their size.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug c++/12126] gdb does not display source-level debugging for member function of a templated iterator.

[tfogal at alumni dot unh.edu]

http://sourceware.org/bugzilla/show_bug.cgi?id=12126

--- Comment #1 from tom fogal <tfogal at alumni dot unh.edu> 2010-10-15 21:09:44 UTC ---
Created attachment 5063
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5063
header file where the given template appears.

This is where the LODBrickIterator template lives.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug c++/12126] gdb does not display source-level debugging for member function of a templated iterator.

[tfogal at alumni dot unh.edu]

http://sourceware.org/bugzilla/show_bug.cgi?id=12126

--- Comment #2 from tom fogal <tfogal at alumni dot unh.edu> 2010-10-15 21:10:19 UTC ---
Attaching the core failed; presumably it's too large.  The core and binary are
available on the web:

  http://www.sci.utah.edu/~tfogal/tmp/uvfconvert-src-bug/

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug c++/12126] gdb does not display source-level debugging for member function of a templated iterator.

[aegges at web dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=12126

Axel Müller <aegges at web dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aegges at web dot de

--- Comment #3 from Axel Müller <aegges at web dot de> 2011-09-13 12:05:04 UTC ---
I have a similar problem with inlined methods. gdb and addr2line are not able
to resolve the source file and line of the corresponding address. I am using
gdb 7.2 but gdb 7.3 fails, too. Interestingly, Valgrind can resolve it and nm
shows clearly that the debug info is actually in the executable. Unfortunately,
I was not able to construct a simple testcase to show the problem here.

After some changes on a different source file and recompilation the problem
went away. The only difference I saw in the disassembler code was that the
following line was added in the case where gdb has a problem:
call <i686.get_pc_thunk.bx>

Usually, this call is inserted in case of position independent code (option
-fPIC for gcc). I don't know why it was inserted in my executable as I don't
use this option. Perhaps this information can help to identify the cause of
this bug and solve it.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.