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.
Created attachment 5063 [details] header file where the given template appears. This is where the LODBrickIterator template lives.
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/
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.