In the middle of a session the debugger no longer responds. It does not
respond to the bar button nor to the menu nor the keyboard shortcut. Is there
any implicit calls limit or time limit or procedure to keep the debugger
responding? Any other process condition? I am debugging under Windows in
WinMain functions before any windows are created.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dev-C++'s debugger integration is primitive at best and extraordinarily buggy.
It is Dev-C++'s worst and least complete feature, and is a good reason on its
own to stop using Dev-C++ since it will never be fixed.
I suspect the IDE-gdb connection is low priority and very slow. If gdb gets
more than one request before it finishes serving the previous request it gets
lost, so the problem is in gbd or the connection, not in the IDE. This can
happen depending on what message IDE uses to handle the keyboard, whether
WM_KEYDOWN or WM_KEYUP because keyboard messages in Windows are not properly
serialized. It becomes worse since debugger controls are virtual keys so the
IDE has to handle more than one type of keyboard message. But the problem
would still be in the gdb handling of requests. It also seems that gbd takes
progressively more time servicing requests as the debugging session advances
or after more than one session was initiated and finished. In this laptop it
is typical that the mousepad sends more than one click or no click at all
though I am already used to its sensibility. The debugger watch function is
also idiosincratic at best. It does not pick up watched variables between
sessions even if the variables are still in the IDE window. Sometimes it reads
from the mouse caret and sometimes it does not. Some this->variable get marked
as unwatchable to, then nothing can watch them, but sometimes pointer
variables show the full content of the pointed to object, even polymorphically
(actual class) while others it shows only the pointer memory value. It
sometimes adds a number=variable=content pseudoequation as observed variable
name, while arrays are not always shown in extenso but only sometimes, with no
fix rule I can discern... It feels like some of these idiosincracies can be
circumvented in the debugged code particularly with array notation and making
temporary variables explicit so they can be watched or other compiling tricks.
In any case it seems the problem is in gdb processing, not the integration to
IDE itself, but this requires inspecting the debugger s code to find out rules
of thumb to better use it.
I downloaded the insight app but it seems to be a tcl interpreter and no
better solution with a lot of documentation to assimilate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think you are drawing some bold conclusions about how Dev-C++ integrated GDB
with no real evidence (and pointlessly writing at length about it since I
doubt anyone cared much). But even if it worked, the IDE exposes only a bare
minimum of GDB functionality.
Insight is indeed implemented with Tcl - so what, why would you care how it
was implemented? It is more comprehensive and more reliable than Dev-C++'s
weak integration. It is also far more intuitive, I have used it often without
reading any documentation. You need to download the executable not the source
code package; perhaps that is what you are referring to?
VC++ Express remains the far better solution. I doubt anyone seriously uses
Dev-C++any longer except a few schools whose course material is based upon it
and who are too clueless to update it. Still, better than Turbo C++ which many
still seem to be using I suppose, but at least that has a working debugger.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the middle of a session the debugger no longer responds. It does not
respond to the bar button nor to the menu nor the keyboard shortcut. Is there
any implicit calls limit or time limit or procedure to keep the debugger
responding? Any other process condition? I am debugging under Windows in
WinMain functions before any windows are created.
Dev-C++'s debugger integration is primitive at best and extraordinarily buggy.
It is Dev-C++'s worst and least complete feature, and is a good reason on its
own to stop using Dev-C++ since it will never be fixed.
If you must use Dev-C++, you are best off using the external Insight Debugger:
https://sourceforge.net/downloads/mingw/UserContributed/insight/ It is possible to
loosely integrate it with Dev-C++ via the Tools menu customisation feature.
A better alternative is simply to use VC++ Express which has a best in class
debugger for free. http://www.microsoft.com/express/windows/
I suspect the IDE-gdb connection is low priority and very slow. If gdb gets
more than one request before it finishes serving the previous request it gets
lost, so the problem is in gbd or the connection, not in the IDE. This can
happen depending on what message IDE uses to handle the keyboard, whether
WM_KEYDOWN or WM_KEYUP because keyboard messages in Windows are not properly
serialized. It becomes worse since debugger controls are virtual keys so the
IDE has to handle more than one type of keyboard message. But the problem
would still be in the gdb handling of requests. It also seems that gbd takes
progressively more time servicing requests as the debugging session advances
or after more than one session was initiated and finished. In this laptop it
is typical that the mousepad sends more than one click or no click at all
though I am already used to its sensibility. The debugger watch function is
also idiosincratic at best. It does not pick up watched variables between
sessions even if the variables are still in the IDE window. Sometimes it reads
from the mouse caret and sometimes it does not. Some this->variable get marked
as unwatchable to, then nothing can watch them, but sometimes pointer
variables show the full content of the pointed to object, even polymorphically
(actual class) while others it shows only the pointer memory value. It
sometimes adds a number=variable=content pseudoequation as observed variable
name, while arrays are not always shown in extenso but only sometimes, with no
fix rule I can discern... It feels like some of these idiosincracies can be
circumvented in the debugged code particularly with array notation and making
temporary variables explicit so they can be watched or other compiling tricks.
In any case it seems the problem is in gdb processing, not the integration to
IDE itself, but this requires inspecting the debugger s code to find out rules
of thumb to better use it.
I downloaded the insight app but it seems to be a tcl interpreter and no
better solution with a lot of documentation to assimilate.
I think you are drawing some bold conclusions about how Dev-C++ integrated GDB
with no real evidence (and pointlessly writing at length about it since I
doubt anyone cared much). But even if it worked, the IDE exposes only a bare
minimum of GDB functionality.
Insight is indeed implemented with Tcl - so what, why would you care how it
was implemented? It is more comprehensive and more reliable than Dev-C++'s
weak integration. It is also far more intuitive, I have used it often without
reading any documentation. You need to download the executable not the source
code package; perhaps that is what you are referring to?
VC++ Express remains the far better solution. I doubt anyone seriously uses
Dev-C++any longer except a few schools whose course material is based upon it
and who are too clueless to update it. Still, better than Turbo C++ which many
still seem to be using I suppose, but at least that has a working debugger.