svaante
Timeout with gdb/C++ application
Hi,
when I try to debug a c++ application after some time the debugger becomes unresponsive and i have a "timed out" error, and some time after that emacs is shutdown for memory consumption. Debugging with Eclipse or other GUI do dbg does not show this behaviour.
Andrea
Hello and thank you for your bug report.
A similar issue was recently solved in dape. Which version of dape and gdb are you using? If you are not using 0.25.0 please update and try again.
If this does not work could you (1) eval (setq dape-debug t), (2) start debugging with gdb and (3) share the contents of *dape-connection events* buffer.
Hi! I believe I have the same problem:
GDB version: GNU gdb (Debian 16.3-1) 16.3 dape version : 0.25.0 dape_connection_events.txt
Context: a very simple C++ program:
#include <vector>
#include <cstdio>
int main() {
std::vector<int> myVector = {3, 5, 6, 9, 1756};
printf("%d", myVector[2]);
return 0;
}
Compiled with (GCC 14.2):
g++ foocpp.cpp -o foocpp -g
I didn't spend much time looking for the conditions to reproduce the problem, though, when I removed the std::vector and put more trivial variables, there was no more timeout. Also, it could be an issue in GDB since its RAM consumption was up to 4GB before I killed it (emacs was fine).
@MatthieuHAMEL this looks like an gdb bug. If I would have to guess its probably when resolving the printable value/name for myVector by the way of some script like /usr/share/gcc-<version>/python/libstdcxx/v6/printers.py.
I don't have a gdb capable machine to test with (damn m1 mac). I will continue the investigating as soon as I have the time and a running gdb.
In the meantime I would recommend cpptools, it usually works better then using gdb directly.
If someone tells me how to test gdb with the DAP interface I can test it and see if it's a gdb bug or not.
Hi, I had a quick look: When dape sends the request/variables message, it's at the beginning of the main(), and the vector is not even declared. Though, GDB lookups the value of every variable in the scope and for myVector it ends up constructing an iterator on "children" (elements of the vector):
def children(self): # In StdVectorPrinter (printers.py)
return self._iterator(self._val['_M_impl']['_M_start'],
self._val['_M_impl']['_M_finish'],
self._is_bool)
_M_start, _M_impl... are data members from std::vector. But since the vector doesn't exist yet, those are garbage values, and in my case the offset (_M_finish - _M_start), that determines the number of iterations, is really close to 2^64 ... :-)
Intuitively it is both the fault:
- Of the GCC StdVectorPrinter (a pretty-printer for an interactive debugger shouldn't iterate on trillions of structures, for a vector 1000 or 10000 elements should be enough...)
- Of the above GDB python layer too ? I've always thought it was strange in a debugger to see "Locals" populated with non-yet-declared variables. Since GDB should have the program counter, the line of the current context, etc, maybe it should not even call the printer at that point. I don't know GDB enough to have a clear idea...
So that is how we loop infinitely on the iterator:
next (printers.py:558)
cache_children (/usr/share/gdb/python/gdb/dap/varref.py:214)
child_count (/usr/share/gdb/python/gdb/dap/varref.py:227)
to_object (/usr/share/gdb/python/gdb/dap/varref.py:234)
variables (/usr/share/gdb/python/gdb/dap/evaluate.py:109)
check_arguments (/usr/share/gdb/python/gdb/dap/typecheck.py:86)
ensure_gdb_thread (/usr/share/gdb/python/gdb/dap/startup.py:127)
Excellent job @MatthieuHAMEL! I could not see a bugreport upstream, so I went ahead and created one.
https://sourceware.org/bugzilla/show_bug.cgi?id=33594
This has now been fixed upstream in (Rust and libstdc gdb printers) I dont' know when the changes will land on debian's packaging of libstdc. I am guessing it will take a while.