Community
Participate
Working Groups
The following error occurs while debugging a C++ source code (the code can't be attached because it's proprietary): Traceback (most recent call last): File "/usr/lib64/../share/gcc-4.5.1/python/libstdcxx/v6/printers.py", line 61, in next elt = self.base.cast(self.nodetype).dereference() RuntimeError: Cannot access memory at address 0x71 Traceback (most recent call last): File "/usr/lib64/../share/gcc-4.5.1/python/libstdcxx/v6/printers.py", line 549, in to_string return self.val['_M_dataplus']['_M_p'].lazy_string (length = len) OverflowError: signed integer is less than minimum Traceback (most recent call last): File "/usr/lib64/../share/gcc-4.5.1/python/libstdcxx/v6/printers.py", line 549, in to_string return self.val['_M_dataplus']['_M_p'].lazy_string (length = len) RuntimeError: Cannot access memory at address 0x8befffffe48 Traceback (most recent call last): File "/usr/lib64/../share/gcc-4.5.1/python/libstdcxx/v6/printers.py", line 61, in next elt = self.base.cast(self.nodetype).dereference() RuntimeError: Cannot access memory at address 0x858d48c28900002a Traceback (most recent call last): File "/usr/lib64/../share/gcc-4.5.1/python/libstdcxx/v6/printers.py", line 61, in next elt = self.base.cast(self.nodetype).dereference() RuntimeError: Cannot access memory at address 0x48535441e5894855 Traceback (most recent call last): File "/usr/lib64/../share/gcc-4.5.1/python/libstdcxx/v6/printers.py", line 549, in to_string return self.val['_M_dataplus']['_M_p'].lazy_string (length = len) RuntimeError: Cannot access memory at address 0xf0758948f87d8930 Traceback (most recent call last): File "/usr/lib64/../share/gcc-4.5.1/python/libstdcxx/v6/printers.py", line 61, in next elt = self.base.cast(self.nodetype).dereference() RuntimeError: Cannot access memory at address 0x3aeae8c78948 Traceback (most recent call last): File "/usr/lib64/../share/gcc-4.5.1/python/libstdcxx/v6/printers.py", line 61, in next elt = self.base.cast(self.nodetype).dereference() RuntimeError: Cannot access memory at address 0xf87d8948e5894855 Traceback (most recent call last): File "/usr/lib64/../share/gcc-4.5.1/python/libstdcxx/v6/printers.py", line 61, in next elt = self.base.cast(self.nodetype).dereference() RuntimeError: Cannot access memory at address 0x7fffffffffff Traceback (most recent call last): File "/usr/lib64/../share/gcc-4.5.1/python/libstdcxx/v6/printers.py", line 549, in to_string return self.val['_M_dataplus']['_M_p'].lazy_string (length = len) OverflowError: signed integer is greater than maximum Traceback (most recent call last): File "/usr/lib64/../share/gcc-4.5.1/python/libstdcxx/v6/printers.py", line 549, in to_string return self.val['_M_dataplus']['_M_p'].lazy_string (length = len) RuntimeError: Cannot access memory at address 0x48de8948f0894990 Traceback (most recent call last): File "/usr/lib64/../share/gcc-4.5.1/python/libstdcxx/v6/printers.py", line 61, in next elt = self.base.cast(self.nodetype).dereference() RuntimeError: Cannot access memory at address 0x58a8a0b919ebef45 Traceback (most recent call last): File "/usr/lib64/../share/gcc-4.5.1/python/libstdcxx/v6/printers.py", line 61, in next elt = self.base.cast(self.nodetype).dereference() RuntimeError: Cannot access memory at address 0x758b4840ebef4588 -- Configuration Details -- Product: Eclipse Platform 3.6.1.r361_v20100714-0800 (org.eclipse.platform.ide) Installed Features: org.eclipse.platform 3.6.1.r361_v20100909-9pF78H4oFrRqo0jLjjFxXoSz-RKIN_OZboW
CC'ing Tom Tromey since this looks to be gdb Python scripting-related.
Over on GDB I tend to see this from users. There are generally two possibilities: - The variable has been optimized out by GCC, and GCC does not mark optimized data so we cannot pre-check it. - The variable is uninitialized or is corrupted. (IE printing a data-structure right after breaking at "main"). The printer is basically trying to interpret the content inside the data-structure (in this case, a C++ class). As it tries to understand the data to give a better interpretation of what is in it (IE as in a vector: 1,2,3,4) instead of the actual class mechanics, this is what happens. I'm not sure how to fix this. Given that the two scenarios above are something we cannot detect. It would help if some more context was given when this trace was produced. Was it (the variable) uninitialized? What were the optimize flags passed to the build?
The optimisation flag was -O0 (and the debug one was -g3 if that's any help). The debugging had worked fine in DDD (even when I had displayed the variables involved). However, after I read the last input I tried the debugging in Eclipse as well - with the "Variables" tab closed. It worked just fine. What troubles me is the fact that all the variables are valid and defined just before the collaps and it fails on a line that doesn't do anything extraordinary. Here is the particular piece of code (I'm sorry I can't provide more): if (xx != yy) { list_of_strings.push_back(ZZ->string_atr); //<--HERE IT COLLAPSES ... ZZ is fully defined, list_of_strings was empty at the moment. Thank you for your help. Feel free to close this bug as "fixed-worksforme".
What version of gdb is this? The presence of RuntimeError in the trace leads me to believe this is a bug that was fixed -- well, at least partially fixed, in a way that hopefully would cause gdb front ends to show something nice instead of a Python trace.
Here's the gdb patch that fixed this: http://sourceware.org/ml/gdb-patches/2010-10/msg00301.html
