Splitting debugger in two - specific debugger and common GUI

[MortenMacFly]

There is a missing wxIsIdOk or something like that when the compatibility is off.

Ah! yes, I had fixed this already... Seems I forgot to commit a file... I'll sort it out... Sorry.

[MortenMacFly]

Ah! yes, I had fixed this already... Seems I forgot to commit a file... I'll sort it out... Sorry.

Could you try again, please. The issue here is, that I also manage the wxSmith branch which has a lot more wxSmith related changes / patches... man - we should really consider to finally merge at least this branch into trunk.

Concerning wxPropGrid. I'll try to back-port the whole wxPropGrid stuff into trunk. Then both should be in sync for this component. Would that be OK for you?

[oBFusCATed]

Don't worry, I've not compiled it. But I didn't commit the change because I didn't have the time to fix trunk.

Yes, syncing wxPropGrid is OK with me.

About the merging of the branch,
I have probably one last API breaking change (it will be committed this week) and I think I'll be ready for a merge.
My current target is the end of January. Stay tuned

[oBFusCATed]

Ok, I've committed the API change (maybe the last major one) and a fix for the batch mode, please test and report if there are any problems.

[Jenna]

Ah! yes, I had fixed this already... Seems I forgot to commit a file... I'll sort it out... Sorry.

Could you try again, please. The issue here is, that I also manage the wxSmith branch which has a lot more wxSmith related changes / patches... man - we should really consider to finally merge at least this branch into trunk.

Can we wait with a merge, until the linux and windows build fixes (and directory layout changes) are made ?
I work on it, but sometimes my family (and my boss) need my time also.

[oBFusCATed]

But then you'll have to do the job twice, I guess.

[Jenna]

But then you'll have to do the job twice, I guess.

I do it in the wxsmith-branch, and if it is ready, it can be merged back into trunk.

[MortenMacFly]

Can we wait with a merge, until the linux and windows build fixes (and directory layout changes) are made ?

Yes, sure - I won't do it overnight. ;-) Although I wonder what is still pending. It looks pretty good now.

I have (however) prepared to merge the wxPropGrid changes from the debugger branch into trunk. This will than also land (sooner or later) in the wxsmith branch.

[MortenMacFly]

I had the following issue several times now:
While debugging, I pressed "Next" several times to debug step-by-step and suddenly all debugger buttons are greyed out, except the "Pause " and "Stop". But hitting these does nothing. I have to kill the debugger (notice that killing the debugger's debuggee does nothing, too) to get C::B back to work.
In the debuggers debug log I see:

Code

[debug]> next
[debug]Cannot find bounds of current function
[debug]>>>>>>cb_gdb:

Trying to pause the running process...

And that's basically it. Even if hitting the "Stop" button several times.
What's causing this? Anybody here experiencing the same?

[oBFusCATed]

Do you have the full log?
Do you have a 100% reproduction case?
My guess is broken GDB/Debug info and also it is caused by not well parsed output from "next".

[MortenMacFly]

Do you have the full log?

That *is* the full log. Everything before is related to the last frame/debug info being shown.

[oBFusCATed]

Test case?

[MortenMacFly]

Test case?

I didn't find one yet... let me further investigate.

Another one: Concerning the issue that I cannot see the triangle: It is related to the settings! When I run a clean instance of C::B I see the triangle. "Re-installing" my old config makes the triangle go away. Must be either something with the layouts or editor settings... I'll investigate, too.

But: I got another serious one:
- Create a hello world project
- Set a BP
- Goto editor settings
- Don't change anything, but quit the dialog wit "OK"
- Try to remove (toggle) the BP -> does not work!!!

[MortenMacFly]

I didn't find one yet... let me further investigate.

Got one!
- Create a hello world project
- Set a BP in the first line in "main".
- Step though the code using F7
- After a few steps I come to that point.

Here is the log:

Code

[debug]>>>>>>cb_gdb:

At c:\users\morten\desktop\mycon\main.cpp:7

[debug]> set debugevents off
[debug]>>>>>>cb_gdb:
[debug]> next
[debug]c:\users\morten\desktop\mycon\main.cpp:8:99:beg:0x401342
[debug]>>>>>>cb_gdb:

At c:\users\morten\desktop\mycon\main.cpp:8

[debug]> next
[debug]c:\users\morten\desktop\mycon\main.cpp:9:114:beg:0x401347
[debug]>>>>>>cb_gdb:

At c:\users\morten\desktop\mycon\main.cpp:9

[debug]> next
[debug]250	../mingw/crt1.c: No such file or directory.
[debug]__mingw_CRTStartup () at ../mingw/crt1.c:250
[debug]	in ../mingw/crt1.c
[debug]>>>>>>cb_gdb:

Trying to pause the running process...
Trying to pause the running process...
Trying to pause the running process...

Note that "Trying to pause the running process..." comes from trying to press pause or stop. And also notice that I hit far more on "Step" than shown in the log...

[oBFusCATed]

But: I got another serious one:
- Create a hello world project
- Set a BP
- Goto editor settings
- Don't change anything, but quit the dialog wit "OK"
- Try to remove (toggle) the BP -> does not work!!!

This is caused by
1. cbEditor::SaveFoldState() calling cbEditor::OnEditorModified
2 which then calls debugger->EditorLinesAddedOrRemoved,
3. which shifts the breakpoints after the end of the file.

I'm not really sure what should we do, so any suggestions are welcome.
By the way this is broken in trunk, too and I guess it has been broken for years.

I guess this easiest thing is to hack it with some kind of m_noBreakpointShift flag, but I don't want to do it this way. I want a proper fix.