Author Topic: The 07 January 2012 build (7678) DEBUGGER BRANCH version is out.  (Read 70903 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 07 January 2012 build (7678) DEBUGGER BRANCH version is out.
« Reply #45 on: January 31, 2012, 07:22:02 am »
Ok, I just find that I may find the reason of this issue:

GDB will return a ">>>>>>cb_gdb:" (we call it FULL_GDB_PROMPT or GDB_PROMPT string, this is the customized gdb prompt by codeblocks) to indicate the previous command is executed correctly.

But it looks like every gdb command should return a GDB_PROMPT.

But when I have many custom script in the debugger setting dialog, such as: I put three command here.
Code
source $(TARGET_COMPILER_DIR)bin\stl.gdb
source $(TARGET_COMPILER_DIR)bin\wx.gdb
set print elements 200
Those three command will return three GDB_PROMPT.

Also, the command like setting the directory command will also return a GDB_PROMPT.

After that, we are sending setting break point command, then wait to receive the bp index from gdb. This is a handshake, gdb will return the correct bp index.
Now, if we do not eat/clear the previous GDB_PROMPT, they will be buffered, and serves as the response string from gdb, so we get a bp index mismatch.

So, the solution should be simple:
We should clear/wait the GDB_PROMPT after the custom gdb command, this will not later confuse the normal breakpoint command handshake.

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: The 07 January 2012 build (7678) DEBUGGER BRANCH version is out.
« Reply #46 on: January 31, 2012, 07:24:07 am »
Can you see the difference? when you delete the same line, the debugger plugin send different index command.
Mmmhh... that is weird, indeed. Looks like the output parsing queue is somehow corrupted, too. There should not be two ">>>>>>cb_gdb:" in one line...?! Is the GBD 7.4 debugger threaded?! Is the MinGW official the TDM-GCC one?
« Last Edit: January 31, 2012, 07:25:44 am by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 07 January 2012 build (7678) DEBUGGER BRANCH version is out.
« Reply #47 on: January 31, 2012, 07:32:38 am »
Can you see the difference? when you delete the same line, the debugger plugin send different index command.
Mmmhh... that is weird, indeed. Looks like the output parsing queue is somehow corrupted, too. There should not be two ">>>>>>cb_gdb:" in one line...?!
Yes, I have debugged some hours, and find the reason in my previous posts.
Quote
Is the GBD 7.4 debugger threaded?! Is the MinGW official the TDM-GCC one?
Threat? dangerous? No, both should works quite well.
The gdb 7.4 was branched from the main trunk cvs about one or two months ago, and there are not many bug fixes targets to MinGW.
But the gdb cvs recently has many things changed targets to mingw, at least the "relocated feature", maybe other things. (you may see some discussions in gdb patches mail lists)

So, currently, I'm still use gdb cvs build myself. :)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: The 07 January 2012 build (7678) DEBUGGER BRANCH version is out.
« Reply #48 on: January 31, 2012, 07:38:47 am »
Threat? dangerous? No, both should works quite well.
LOL, no - I meant it may use threads to speed up things and then the output can come mixed. But this really should not be the case.

We should clear/wait the GDB_PROMPT after the custom gdb command, this will not later confuse the normal breakpoint command handshake.
Still weird that this does not happen with earlier versions of GDB.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 07 January 2012 build (7678) DEBUGGER BRANCH version is out.
« Reply #49 on: January 31, 2012, 07:50:57 am »
Threat? dangerous? No, both should works quite well.
LOL, no - I meant it may use threads to speed up things and then the output can come mixed. But this really should not be the case.
I do not know whether gdb internally handle command by thread or not.

Quote
We should clear/wait the GDB_PROMPT after the custom gdb command, this will not later confuse the normal breakpoint command handshake.
Still weird that this does not happen with earlier versions of GDB.
That's because the later gdb, namely the gdb cvs I tested runs faster.
I have a compare test case:
1, the same test project
2, the same setting breakpoint before debugger started.
3, the same gdb cvs version and same gdb custom command.
The only difference is:
CaseA: I have a debug log code in the line 837 of gdb_dirver.cpp: (which log out a full send command and received text)
Code
DebugLog(wxString::Format(_T("###Handshake: %s #### %s #####"), cmd->m_Cmd.c_str(), buffer.c_str()));
CaseB: I just comment out the above debug log code.

The result is:
CaseA works Ok, no bp index mismatch.
CaseB works badly.

So, you see, The DebugLog code generally does not cause anything, but only a time delay, but this hide the issue.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 07 January 2012 build (7678) DEBUGGER BRANCH version is out.
« Reply #50 on: January 31, 2012, 08:49:48 am »
I have a feeling that the output of gdb 7.4 has changed.
But I have very little intentions to fix it, sorry.
I'm switching all my energy to the gdb/mi plugin as I've said, before.

Edit: Probably you have to change the RunQueue and ParseOutput to wait for the prompt.
« Last Edit: January 31, 2012, 08:51:24 am by oBFusCATed »
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 07 January 2012 build (7678) DEBUGGER BRANCH version is out.
« Reply #51 on: January 31, 2012, 08:58:09 am »
I have a feeling that the output of gdb 7.4 has changed.
But I have very little intentions to fix it, sorry.
I'm switching all my energy to the gdb/mi plugin as I've said, before.
Ok, gdb/mi is better to do the handshake with an IDE.  :)
Quote
Edit: Probably you have to change the RunQueue and ParseOutput to wait for the prompt.
I will try that if I have time, BTW: do you have a simple direction on which part/code snippet should be changed to wait the prompt?
Thanks.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 07 January 2012 build (7678) DEBUGGER BRANCH version is out.
« Reply #52 on: January 31, 2012, 09:11:36 am »
The runqueue should not be called, before the next prompt has arrived, probably.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 07 January 2012 build (7678) DEBUGGER BRANCH version is out.
« Reply #53 on: February 01, 2012, 02:16:46 am »
I have tried to fix this, but finally failed. So I decided to find a workaround. :)

Finally I find one workaround. That is: group all the custom gdb command in one *.gdb file.

Before:
Code
source $(TARGET_COMPILER_DIR)bin\stl.gdb
source $(TARGET_COMPILER_DIR)bin\wx.gdb
set print elements 200

After:
Code
source $(TARGET_COMPILER_DIR)bin\custom.gdb

Note: custom.gdb contains all the contents of the previous three command. Now, it works OK.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 07 January 2012 build (7678) DEBUGGER BRANCH version is out.
« Reply #54 on: February 01, 2012, 09:34:57 am »
ollydbg: you can remove the "set print elements 200", we have an option now.
Click the button in the debugger toolbar next to the button for the debug windows :)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 07 January 2012 build (7678) DEBUGGER BRANCH version is out.
« Reply #55 on: February 01, 2012, 03:09:34 pm »
ollydbg: you can remove the "set print elements 200", we have an option now.
Click the button in the debugger toolbar next to the button for the debug windows :)
Thanks for the hint, your suggest way works Ok.
There is a minor issue that the print element number value is not persistent. (When I close C::B, and restart it again, it was reset to 0 again). Then puting it in a gdb script file is surely persistent. ;)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.