Author Topic: Splitting debugger in two - specific debugger and common GUI  (Read 429064 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #510 on: August 14, 2011, 11:28:21 am »
Because scintilla on windows is not sending the dwell start event if the control or other key is pressed.
I don't know why it doesn't happen on linux, but I see no side effects here. Time will tell.

This is the discussion of Ollydbg with one of the Scintilla devs: http://groups.google.com/group/scintilla-interest/browse_thread/thread/7d109d6e9c6a18f5/700a7871969920da?lnk=gst&q=dwell#700a7871969920da

p.s. there seem to be more problems with the gdb 7.3...
(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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #511 on: October 11, 2011, 12:11:14 am »
On Topic: I should probably just read the thread/code, but do you have a cliff notes version of the status of your work on the debugger API, oBFus? (May have some free time to think about the python debugger again in coming months)
dmoore (and others of course):
I've almost finished the switch from raw pointer/references to cb::shared_ptr, only the watches are to be converted (will do it this week, hopefully).
Can you look at the API for some missing bits are things that you don't like?

After I'm finished with the watches I plan to add 'Supported features API', so different plugins can advertise what they support or doesn't support.
(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 dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #512 on: October 12, 2011, 10:57:34 pm »
oBFusCATed: That sounds good. I wil try to take a look in the next couple of weeks. Unfortunately, v.busy atm.

Offline tomjnx

  • Multiple posting newcomer
  • *
  • Posts: 34
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #513 on: October 19, 2011, 11:55:31 am »
ParseOutput expects to get debugger output line-wise - however the cbTextInputStream does not really guarantee ReadLine to always return a full line. Not being able to read does not mean we are at the end of a line, it could also be that the sending process hasn't written the remainder of the line or the operating system hasn't caught up getting everything to the receiving process. I haven't seen this problem under linux, but on quite a few windows machines it happens occasionally.

If we can no longer read but haven't seen an EOL, we need to buffer the already read characters, return an empty line, and continue on the next call. The attached patch fixes the problem for me.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #514 on: October 19, 2011, 12:46:16 pm »
Hm, OK, I'll give it a try, but I'm mostly on windows.

Edit: replace windows with linux...
« Last Edit: October 19, 2011, 02:40:01 pm 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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #515 on: October 19, 2011, 02:14:18 pm »
Hm, OK, I'll give it a try, but I'm mostly on windows.
Please, be very careful with that one. It changes a very sensitive core component of C::B. Basically all elements using PipedProcess will be affected and change it's behaviour.

Also, I don't understand why this:
Code
if (EatEOL(c)) {
  wxString line;
  line.swap(m_line);
  return line;
}
...is needed instead of this:
Code
if (EatEOL(c))
  return m_line;

...and why in the end instead of this:
Code
return wxString();
...not this is used:
Code
return wxEmptyString;
(...which would read better...)

Also, what is a test case to reproduce the actual issue? Because I never had such and I don't know anybody else suffering from this implementation.
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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #516 on: October 19, 2011, 02:39:33 pm »
Please, be very careful with that one. It changes a very sensitive core component of C::B. Basically all elements using PipedProcess will be affected and change it's behaviour.
Yes, I know, I've tried to modify this part already, as you know I've failed miserably :(

Also, I don't understand why this:
Code
if (EatEOL(c)) {
  wxString line;
  line.swap(m_line);
  return line;
}
...
This is the same as:
Code
wxString s=m_line;
m_line.clear();
return s;
But it is faster, it is pretty standard c++ trick :)

Also, what is a test case to reproduce the actual issue? Because I never had such and I don't know anybody else suffering from this implementation.
+1
(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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #517 on: October 19, 2011, 03:01:47 pm »
This is the same as:
Code
wxString s=m_line;
m_line.clear();
return s;
But it is faster, it is pretty standard c++ trick :)
Ah - I missed that the this is a member variable now that needs to be cleared. OK.
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 tomjnx

  • Multiple posting newcomer
  • *
  • Posts: 34
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #518 on: October 24, 2011, 03:03:06 pm »
Also, what is a test case to reproduce the actual issue? Because I never had such and I don't know anybody else suffering from this implementation.

Sorry, I don't have an easy testcase. I'd have to send you my computer 8-)

I have one machine where it happens pretty much always (Win XP), two where it happens occasionally (W2K), and quite a few where it never happens.

And it only happens if the debugger writes lots of output, which is seldom enough.

Under Linux, you're not going to see this. Because any debugger output less than 4kBytes (and provided the debugger only calls write for full lines, haven't checked whether gdb does it), is guaranteed by the OS to hit the receiver process atomically.

What are the intended semantics of cbTextInputStream::ReadLine()? What should happen if the writing process only writes part of a line (i.e. characters without terminating newline)? Should ReadLine() block? Should it return that part of the line even if it is not a full line? (and return the rest of the line should the writing process decide to continue the line in a second call to ReadLine(), leaving the caller with no way to determine where the real line ends were)?

Offline cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #519 on: November 01, 2011, 03:25:26 pm »
(peanut gallery chiming in, FWIW)
Can you get the debugger to write lots of output by opening a disassembly window, selecting mixed mode, and stepping through a large module, or possibly back-and-forth between two different large modules, while trying to see if your problem occurs?  The stepping can probably be in the normal source window, I think the disassembly window will still be (re-)populated in background.

(A large enough module should also be able to exceed the mentioned 4K size on linux, depending on how much disassembly changed since I was in in it...) 

Of course, if you need lots of output withOUT a line-ending present, that probably won't do, as the disassembly will most likely have line-endings fairly often...

Offline cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #520 on: November 01, 2011, 03:48:26 pm »
svn wxpropgrid_debugger branch R7550 fails to build:
        SqPlus::SQClassDef<wxArrayString>("wxArrayString").
                emptyCtor().
                func(&wxArrayString::Add, "Add").
                func(&wxArrayString::Clear, "Clear").
//                func(&wxArrayString::Index, "Index").
                staticFuncVarArgs(&wxArrayString_Index, "Index", "*").
                func(&wxArrayString::GetCount, "GetCount").
                func(&wxArrayString::Item, "Item");
C:\dev\codeblocks\svn_dbgbranch_on20111101\src\sdk\scripting\bindings\sc_wxtypes.cpp:251: error: no matching function for call to 'SqPlus::SQClassDef<wxArrayString>::func(<unresolved overloaded function type>, const char [5])'

Same problem exists in trunk R7550 retrieved shortly before debugger branch.

Additionally, debugger branch also seems to be missing parenthesis when build attempted with wx 2.9(.2)

sdk\cbplugin.cpp:640-644
Code
    #if wxCHECK_VERSION(2, 9, 0)
    Manager::Get()->GetLogManager()->DebugLog(F(_("Switching layout to \"%s\""), name.wx_str())); <<<==== I added final paren here
    #else
    Manager::Get()->GetLogManager()->DebugLog(F(_("Switching layout to \"%s\""), name.c_str()));
    #endif
« Last Edit: November 01, 2011, 03:58:17 pm by cbexaminr »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #521 on: November 01, 2011, 04:37:36 pm »
Debugger branch is not ported to wx2.9, sorry.
(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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #522 on: November 01, 2011, 11:44:29 pm »
The missing brace is fixed in the branch, thanks.
(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 Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #523 on: November 14, 2011, 04:21:39 pm »
svn build  rev 7587 (2011-11-12 18:16:49)   gcc 4.3.1 Windows/unicode - 32 bit

At compileroptionsdlg.cpp statement 2293
Code
    // compiler set buttons
    if (!m_pProject)
    {
        en = !data; // global options selected

m_pProject is always 0x0. If I place the following before 2293
Code
    if (!m_pProject) asm("int3"); /*trap*/

the trap never occurs whether there's a project loaded or not.

The old code used to read:
Code
    // compiler set buttons
    if (XRCCTRL(*this, "btnAddCompiler", wxButton)) // only if exist
    {
        en = !data; // global options selected

Something is strange here...
http://dl.dropbox.com/u/46870262/ScreenShot00749.jpg

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #524 on: November 14, 2011, 04:37:23 pm »
Here is the exact commit: http://svn.berlios.de/wsvn/codeblocks/trunk/src/plugins/compilergcc/compileroptionsdlg.cpp?op=diff&rev=6084&peg=7590

It is in trunk and have nothing to do with the branch. I guess Morten could tell you more about it.
(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!]