Splitting debugger in two - specific debugger and common GUI

[ollydbg]

Hey, I found a potential issue.

I have two project opened.(one have space in path, the other does not), both have main.cpp and I set one breakpoint per file.

I'm debugging the project with no space(active project), but the log shows that the BP in file with space (non active project) are still sent.

You see the second log:

Code

[debug]> break "E:/code/cb/test_code/space folder/hi/main.cpp:8"
[debug]No source file named E:/code/cb/test_code/space folder/hi/main.cpp.
[debug]Breakpoint 2 ("E:/code/cb/test_code/space folder/hi/main.cpp:8) pending.
[debug]>>>>>>cb_gdb:
[debug]> break "E:/code/cb/test_code/nospace/hi/main.cpp:7"
[debug]Breakpoint 3 at 0x4013de: file E:\code\cb\test_code\nospace\hi\main.cpp, line 7.

Maybe, we should give a message or warning on this cases?

[oBFusCATed]

ollydbg: This is not a bug, but a feature. All breakpoints from all projects are sent, this is done in order to be able to debug inside shared libraries.

[ollydbg]

ollydbg: This is not a bug, but a feature. All breakpoints from all projects are sent, this is done in order to be able to debug inside shared libraries.

Yes, I see. No need to change anything on this feature.

[MortenMacFly]

-> No closing quotation mark, so the debugger reads garbage!

@oBFusCATed: I think I found the reason. Should I commit at will or do you have stuff pending?

[MortenMacFly]

Can you try this patch and then tell me if it works:

Full stop. This doesn't work completely. It correctly spits out the debuggee could not be found and I could re-start the debugger, but the internal state seems screwed. Because if I hit the "run-debugger" button several times the "build buttons" and everything never gets back and remain greyed. In addition I don't see any output in the debugger console anymore.

I have to re-start C::B to get it back into a normal state. :-(

[oBFusCATed]

Morten: About the Chinese chars: If you've tested it and it works, commit at will:) I guess this is related to the additional arguments patch.
Hm, strange. Can you try to debug this, too?

ollydbg: I don't get what is your problem? As far as I know the newly shown windows are not placed by C::B, but by your Explorer.exe.

[MortenMacFly]

If you've tested it and it works, commit at will:) I guess this is related to the additional arguments patch.

Nope, its not. I've committed.

[oBFusCATed]

Morten:
Can I ask you to stop committing real changes and style changes in a single commit?
I don't know if you have something that automatically fixes the formatting, but it is pretty hard to look at your commits, because mostly they are full of formatting noise.

BTW: you don't follow your style 100%, because you fix code like "if(!test)", to "if (!test)" or "if ( !test )".
At my current company we have the following rule: "you must not change the formatting of code you're not changing"; which is one pretty good rule.

[MortenMacFly]

Can I ask you to stop committing real changes and style changes in a single commit?

I think all you need is a good diff tool. The one I use can simply hide "whitespace" changes so you only see what is really changed.

Concerning style: I use an automated astyle run whenever I save a file. My settings are usually consistent and follow the following (in-house company) rules:
1.) After if, for, while follows a space
2.) After the opening and before the closing bracket follows a space only in case a function call is done inside the clause.

I'll try to turn automatic formatting off next time. By default its enabled and I cannot set it "per-project".

BTW: If works even if you use the WEB-SVN:
http://svn.berlios.de/wsvn/codeblocks/branches/wxpropgrid_debugger/src/plugins/debuggergdb/debuggergdb.cpp?op=diff&rev=7703&peg=7703
Only the green and red lines are true changes. You can even enable there to "ignore whitespace changes":
http://svn.berlios.de/wsvn/codeblocks/branches/wxpropgrid_debugger/src/plugins/debuggergdb/debuggergdb.cpp?op=diff&rev=7703&peg=7703&ignorews=1
Easy to catch... ;-)

[oBFusCATed]

http://svn.berlios.de/wsvn/codeblocks?op=comp&compare[]=%2Fbranches%2Fwxpropgrid_debugger%2Fsrc%2Fplugins%2Fdebuggergdb%2Fdebuggergdb.cpp@7688&compare[]=%2Fbranches%2Fwxpropgrid_debugger%2Fsrc%2Fplugins%2Fdebuggergdb%2Fdebuggergdb.cpp@7703

I'm looking at this one and it is pretty broken. I use it because it is the easiest to reach.

My diff tool is set up to show any differences, so I don't commit random changes caused by stripping trailing whitespaces, line ending differences and so on.

p.s. we should add per project/workspace style, because the current global style settings are pretty limiting

edit:
seems there is an ignore whitespace button there, too

[oBFusCATed]

Morten:
Hm, I don't understand your last fix. Can you explain?
Are you sure you've fixed it and not added a workaround for some kind of memory corruption?

[MortenMacFly]

Hm, I don't understand your last fix. Can you explain?

I fully agree that it looks a completely weird but I've seen this in my own applications, too. If you sum a wxString by reference, the and have the reference itself in the equation, too sometimes garbage comes out. I don't know why (maybe I should have look at the affected operators of wxString), but I do know that introducing a temporary (copied) variable works. And in fact the Chinese characters are gone for me.

[MortenMacFly]

Morten: I wouldn't be surprised if the wx guys have messed the API, once again. But I'll be happy if you take some time and try to find the real cause for the problem.

I did and I found it. This caused a reversal of the initial fix. The problem was in a wrong use of the WinAPI function to retrieve the 8.3 path notation in case the file is not present. (The latter was not handeled correctly). I've fixed this now and forever. However, one thing must be clear: If the file is not present (on Windows) the trial to obtain a 8.3 path (either with or without file) will not succeed. In that case the file name is left as it is, so the argument will be provided "some string" with spaces in it, as you simple cannot convert it to "something without spaces" using Windows file API. This means, the -args argument might indeed get something with spaces and also the path to the debuggee might still contain spaces. This might cause side effects but there is no way to do it properly in the place where I did the modifications.

I also used the wx function now which is cross-platform, so no need for this ugly "GetShortPathNBame" hack for Unixes anymore.

[tomjnx]

obFus: are you sure the following does the right thing? It seems to me that only every second command is deleted...

from debuggerdriver.cpp:
void DebuggerDriver::ClearQueue()
{
    int idx = 0;
    // if the first command in the queue is running, delete all others
    // (this will be deleted when done)
    if (m_QueueBusy && !m_DCmds.GetCount())
        idx = 1;
    for (int i = idx; i < (int)m_DCmds.GetCount(); ++i)
    {
        delete m_DCmds;
        m_DCmds.RemoveAt(i);
    }
}

[oBFusCATed]

No, I'm not sure, but I've fixed it just in case, thank you for the report