Debugging with gdb showing segfault in question marks function "?? ()"

Question

I have been trying to debug a segfault with gdb, but it shows error occurs in "?? ()" step which I can't figure out the meaning. Anyone can give a hint what that means?

The relevant backtrace is posted below.

(gdb) run
> (list-partition gt3 (quote (1 2 3 4 5)))

Program received signal SIGSEGV, Segmentation fault. 0xb7d900ac in ?? () from /lib/i386-linux-gnu/libc.so.6 

(gdb) bt 10
#0  0xb7d900ac in ?? () from /lib/i386-linux-gnu/libc.so.6
#1  0xb7d92dec in malloc () from /lib/i386-linux-gnu/libc.so.6
#2  0xb7f8d627 in operator new(unsigned int) ()    from /usr/lib/i386-linux-gnu/libstdc++.so.6
#3  0xb7f727d4 in std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#4  0xb7f74a48 in char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) ()    from /usr/lib/i386-linux-gnu/libstdc++.so.6
#5  0xb7f74bb6 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) ()    from /usr/lib/i386-linux-gnu/libstdc++.so.6
#6  0x080527fa in SymbolCell::get_symbol (this=0x80641e0) at SymbolCell.cpp:63
#7  0x080524c2 in SymbolCell::get_value (this=0x80641e0) at SymbolCell.cpp:88
#8  0x08053c20 in ConsCell::get_value (this=0x8064190) at ConsCell.cpp:195
#9  0x0804f287 in eval_pure (c=0x8064190) at eval_util.cpp:683 (More stack frames follow...)

Another thing worth noticing is that the program actually runs a few seconds before generate this bug, which is quite abnormal in the context of the behavior of the program.

Appreciate any suggestions! Thanks in advance!

Answer 1

??() means that gdb can't find symbolic information. This is not necessary for your problem because the stack is already deep in the library code and string/new/malloc are well tested. Start at frame 6 in SymbolCell::get_symbol to look for problems.

edit: I just noticed that you are actually running lisp-code, so you might have run into some issues with the lisp environment or more likely are running out of memory.