| trouble debugging C++ python extension with eclipse/CDT/gdb [message #198807] |
Wed, 01 August 2007 10:12  |
Eclipse User |
|
|
|
Originally posted by: andrew.murray.ihatespam.com
I'm having trouble debugging a C++ Python extension that I've written.
I know that there in no fundamental problem in debugging the combination
of executables and shared objects using gdb on this (windows) machine - as
I can successfully debug them using a command line gdb session started in
an MSYS shell (gdb 5.2.1 'i686-pc-mingw32'). This works fine - I can list
the source code, examine variables and step through the code. Alas, I
find using command line debuggers very painful, so I want to get this
working in eclipse (which I'm happily using for the code development
anyway).
When I try to debug the same setup in eclipse/CDT, gdb successfully
catches SIGTRAP signal that my code (intentionally) generates, but the
resulting graphical debug session is unresponsive (no cursor in the source
window, step/step-over buttons are grayed-out etc). There are also
several "Cannot access memory at address 0x2" error messages in various
tabs. Interestingly, if I 'resume' the application it does so, then stops
again when it hits a breakpoint that I've set in an eclipse source window
(so the debugger is able to set breakpoints in the shared object).
The results of searching for combinations of the error messages and
subject suggests that the problem is to do with eclipse being unhappy that
gdb is unable to read all frames of the stack trace. Exploring the stack
in my command line gdb session would support this as issuing the command
'bt' gives results like this...
(gdb) bt
#0 0x10001424 in Image::generateTrapSignalForDebugger() (this=0x9229b8)
at w:/aamu/projects/image/src/image.cpp:272
#1 0x100a37e0 in std::cout ()
#2 0x1001cfee in _wrap_Image_generateTrapSignalForDebugger (args=0xb617b0)
at image_wrap.cpp:8293
#3 0x1e08dc97 in _libmsvcrt_a_iname ()
#4 0x1e1e69c8 in _libmsvcrt_a_iname ()
(gdb) Cannot access memory at address 0x2
I assume it was an attempt to access frame 5 that resulted in that same
error message. I don't really care about the inability to see these
frames as I'm only interested in what might be happening in the 'newer'
ones (that represent calls in my code).
Explicit exploration of the stack frames also seems to indicate that the
within-eclipse gdb session is relatively happy. If I ask gdb for "info
frame 0" after it catches the initial SIGTRAP I get identical results from
within eclipse and outwith. Rather, they are _almost_ identical - the
only difference being that the "args:" list is empty when inside eclipse
whereas it includes a reference to the 'this' pointer of the instance when
outside, eg...
(gdb) info frame 0
Stack frame at 0x21f650:
eip = 0x10001424 in Image::generateTrapSignalForDebugger()
(w:/aamu/projects/image/src/image.cpp:272);
saved eip 0x1001cfee
(FRAMELESS), called by frame at 0x21f650
source language c++.
Arglist at 0x21f650, args: this=0x9229b8
Locals at 0x21f650, Previous frame's sp is 0x0
Saved registers:
ebp at 0x21f650, eip at 0x21f654
even though 'this' is not mentioned in the within-eclipse frame info
output I can get the same gdb session to "print this" and it happily
returns...
$1 = (Image * const) 0x922718
Thus, to me it appears that gdb is relatively happy, but that some part of
eclipse or the CDT is unwilling to continue with the GUI side of things
due to gdb reporting an error when asked to explore the full backtrace.
Is there some way I can convince eclipse to not view the inability of gdb
to access all frames of the backtrace as such a fundamental problem?
Any help would be greatly appreciated. (I'm happy to be told I've got
completely the wrong end of the stick!)
Andrew ;)
ps. I've checked my ~workspace/.metadata/.log file but these debugging
sessions do not create any entries there
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02255 seconds
] 
Search
Help
Register
Login
Home
