Debugger gets confused (by file dialog?)

[mattday]

I have a problem debugging an application I am building using wxWidgets and codelite under Windows (XP 32- and 64-bit versions). After a certain point in the program execution, it is no longer possible to step one line at a time. Breakpoints are still hit, but if I then try and step to the next line, the marker arrow (for the current line) disappears and then subsequent stepping requests will generate a debugger message like so:

Code: Select all

DEBUG>>00000555-exec-next
DEBUG>>00000555^error,msg="Warning:\nCannot insert breakpoint -289.\nError accessing memory address 0x785947b8: Input/output error.\n"
Warning:\nCannot insert breakpoint -289.\nError accessing memory address 0x785947b8: Input/output error.

The closest I have come to identifying what leads to this problem is as follows. I have a form with a couple of wxTextCtrls used to specify some paths. The OnLeftDown event for these will show an open dialog if they are currently empty, and showing this dialog seems to be the trigger. If I remove the OnLeftDown functionality (i.e. the paths must be entered manually) I don't have the problem. I also tried replacing the use of wxFileDialog with some win32 API code, but the same problem still occurs.

My codelite version is 4.1.5770 (latest binary package with wxWidgets & MinGW) and a full debugger log is attached. Any pointers are greatly appreciated.

[eranif]

I think its a problem of GDB.

I found that the standard GDB does not work well when debugging wxWidgets (especially large applications, like codelite itself)

I managed to find a debugger build that works very well (and much faster than the official one released by MinGW)

GDB 7.4.5 with Python

You will need to install python to make it work, download version 2.7 from here:
Python 32 bit, 2.7.3

Once installed, (e.g. under C:\GDB-7.4.5) tell codelite to use this debugger from:
settings -> debugger settings -> debugger path

Eran

[mattday]

Many thanks Eran, I have switched to this version of GDB, although unfortunately it still has the problem.

Is it possible to use WinDbg with codelite by any chance?

I can probably work around this for now, but not sure where to start if I need to find a definite solution later.

[eranif]

Is it possible to use WinDbg with codelite by any chance?

]
Nope.

Which toolchain do you use?
Have you tried debugging another application within codelite and see if the problem persists?

Eran

[mattday]

I'm using the GNU toolchain from the latest codelite/mingw/wx bundle.

I have tried to create a minimal program to reproduce the problem. However, this has only shown the issue is potentially dependent on some unknown environmental factors...

On the main development machine (Win XP Pro x64), the minimal program consistently works (both using packaged GDB and GDB 7.4.5).
On another machine (Win XP Pro), the minimal program consistently demonstrates the issue (only tested with packaged GDB).
On a further machine (Win XP Home laptop), the minimal program consistently works (only tested with packaged GDB).

[eranif]

I am afraid it is a gdb problem which codelite can not fix / overcome
You should take it upstream to the gdb devs..

codelite is merely an interface to gdb, if gdb can't handle it - there is nothing that codelite can do about it.

Have you tried debugging it from a command line? and see if the problem persists?

Eran

[mattday]

I did try running GDB from the command line and the result was always the same as within codelite. So you are right, it is most likely MinGWs GDB.

I switched to the latest releases of GCC/GDB by using this package, thinking there would be little point in reporting bugs that may have already been fixed. This made no difference as far as the issue is concerned.

Ultimately, I was not able to pin it down sufficiently, and have now given up chasing it. In case it is useful to anyone, attached is the closest I came to having a minimal sample to demonstrate the problem. It consistently reproduced it on one of the machines mentioned above, and almost always on another, but I never managed to reproduce it on a third machine.