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

Offline cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #345 on: November 23, 2010, 09:51:46 pm »
Ok.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #346 on: November 25, 2010, 08:40:59 pm »
BTW, I've one problem with the just committed patch:

When the disassembly is in mixed mode, both c/c++ and asm lines are coloured as asm lines.
Does someone knows if it is possible to disabled the syntax highlight for single line or a block of text?

I've looked at the code, but I couldn't find anything that would do the job.
(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 #347 on: November 25, 2010, 08:51:57 pm »
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0017.7.patch  (improved version of http://forums.codeblocks.org/index.php/topic,10908.msg89496.html#msg89496 )

1. Added GetIsRunning method to ProjectManager, it is used to query the plugin that is running the project (running the application, debugging the application, etc)
2. Added SetIsRunning method to ProjectManager, it is used to set the plugin that is running/executing the project, it is set only if the GetIsRunning returns NULL
3. Modified the Compiler plugin to use the new methods (set and reset correctly the running flag, modified the toolbar/menu updateui functions)
4. Modified the Debugger plugin to use the new methods (set and reset correctly the running flag, modified the toolbar/menu updateui functions)
5. Fixed all (almost), bugs I've encountered since v17.3

I think this patch could be applied now, Morten?
Also what about another nightly build, so the disassembly changes and the changes in v17.7 could be tested in the wild? :)
(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 #348 on: November 25, 2010, 08:54:15 pm »
...I got another 2 issues:
1.) I am not sure if this is related: But after applying the patch C::B does not startup anymore and I receive an error that the wxScintilla window could not be created in the constructor, in this line:
Code
    m_pCode = new wxScintilla(this, wxID_ANY);
...which goes back into the disassembly window (which was modified). I am still investigating though as in parallel I modified scintilla, too... unfortunately.
2.) From the logs I see a lot NULL pointer issues. meaning crash candidates, e.g.:
Code
    m_MixedModeCB = (wxCheckBox*)FindWindow(XRCID("chkMode"));
    m_MixedModeCB->SetValue(Manager::Get()->GetDebuggerManager()->IsDisassemblyMixedMode());
...or here:
Code
    DebuggerManager &manager = *Manager::Get()->GetDebuggerManager();
    bool newMode = !manager.IsDisassemblyMixedMode();
Please always make sure you verify pointers. The only exception might be singleton classes, but even then you must be careful if the app shuts down. The latter is strange anyways, why don't you operate with pointers here? This is the only place I know where a singleton class is used by reference. IMHO this is dangerous and violates somehow the concept of a singleton.

Concenring functionality: Well... I'll try to get it up and running... :lol:
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 #349 on: November 25, 2010, 10:30:47 pm »
...I got another 2 issues:
1.) I am not sure if this is related: But after applying the patch C::B does not startup anymore and I receive an error that the wxScintilla window could not be created in the constructor, in this line:
Code
    m_pCode = new wxScintilla(this, wxID_ANY);
...which goes back into the disassembly window (which was modified). I am still investigating though as in parallel I modified scintilla, too... unfortunately.
Running HEAD of the branch and I can start and use C::B, even the disassembly window works.

2.) From the logs I see a lot NULL pointer issues. meaning crash candidates, e.g.:
Code
    m_MixedModeCB = (wxCheckBox*)FindWindow(XRCID("chkMode"));
    m_MixedModeCB->SetValue(Manager::Get()->GetDebuggerManager()->IsDisassemblyMixedMode());
...or here:
Code
    DebuggerManager &manager = *Manager::Get()->GetDebuggerManager();
    bool newMode = !manager.IsDisassemblyMixedMode();
Please always make sure you verify pointers. The only exception might be singleton classes, but even then you must be careful if the app shuts down. The latter is strange anyways, why don't you operate with pointers here? This is the only place I know where a singleton class is used by reference. IMHO this is dangerous and violates somehow the concept of a singleton.
Which logs?
Morten, you can find code like "SomeManager *manager =  Manager::Get()->GetSomeManager();" all over C::B's sources and very few times the pointer is checked.
Also the "SomeManager *manager =  Manager::Get()->GetSomeManager();" and "SomeManager &manager =  *Manager::Get()->GetSomeManager();" is pretty much the same.
If you don't like it, you can rewrite it the style you prefer :)
(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 #350 on: November 26, 2010, 06:36:06 am »
Running HEAD of the branch and I can start and use C::B, even the disassembly window works.
Well - the strange thing is: If I disable the debugger plugin all works fine again. All editors (based on wxScintilla) are able to create their windows, just not the disassembly window. This error remains which makes the debugger plugin unusable for me atm. :-(

Which logs?
The SVN diff I meant, not log.

Morten, you can find code like "SomeManager *manager =  Manager::Get()->GetSomeManager();" all over C::B's sources and very few times the pointer is checked.
That is exactly what I meant! This version is the standard and it's OK to use this even without pointer check (as I've written:)
The only exception might be singleton classes, but even then you must be careful if the app shuts down.
All I am asking for is to use the same style everywhere, so use the managers as pointers (SomeManager *manager =...) and not as reference (SomeManager &manager =...), that's it.
If you don't like it, you can rewrite it the style you prefer :)
I can do so. But please keep the "correct" style in mind in the future just for consistency (not functionality).
« Last Edit: November 26, 2010, 06:42:10 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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #351 on: November 26, 2010, 09:59:43 am »
Running HEAD of the branch and I can start and use C::B, even the disassembly window works.
Well - the strange thing is: If I disable the debugger plugin all works fine again. All editors (based on wxScintilla) are able to create their windows, just not the disassembly window. This error remains which makes the debugger plugin unusable for me atm. :-(
Stupid questions: have you tried full rebuild or checkout of a clean version in another directory?
Anyone else having the same problems?

I can do so. But please keep the "correct" style in mind in the future just for consistency (not functionality).
Okay :)
(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 #352 on: November 26, 2010, 02:40:08 pm »
Stupid questions: have you tried full rebuild or checkout of a clean version in another directory?
Yes, several times, different machines. On all machines I have the same effect (they all have a common OS though...).

Anyone else having the same problems?
I would be interested in this very much, too. I'll try to compile the debugger version only (thus not having applied my local modification of wxScintilla). Still I believe that is not the reason as wxScintilla works well in all other editors / plugins (e.g. cbEditor, the preview in ThreadSearch and alike...).

Maybe Lieven can give some hints when compiling another nightly of the branch... at any time.
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 killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #353 on: November 26, 2010, 03:57:44 pm »
I had plan to build a new version somewhere either Sunday morning, or Sunday evening.

Since trunk has been merged to debugger_branch, it is a good time indeed ...


PS : something that occurs to me from time to time on trunk while debugging :
CB stops the debug sessions (or the debug sessions was stopped because the program ran till completion), nevertheless CB keeps showing that the debugger is still running (and it is actually, asking through CB [toolbar- button or menu] to stop doesn't help). Only solution is to kill gdb, and then we are back in bizznizz.
Oh yeah : on linux.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #354 on: November 26, 2010, 04:20:36 pm »
killerbot:
Can you try the branch to see if this behavior happens there, too?
I think, I've seen this in the past with trunk's version, the branch's version doesn't have this problem or I've not seen it lately (unfortunately I'm not using C::B much).
(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 Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #355 on: November 26, 2010, 04:32:44 pm »
I had plan to build a new version somewhere either Sunday morning, or Sunday evening.

Since trunk has been merged to debugger_branch, it is a good time indeed ...


PS : something that occurs to me from time to time on trunk while debugging :
CB stops the debug sessions (or the debug sessions was stopped because the program ran till completion), nevertheless CB keeps showing that the debugger is still running (and it is actually, asking through CB [toolbar- button or menu] to stop doesn't help). Only solution is to kill gdb, and then we are back in bizznizz.
Oh yeah : on linux.
The same happens here from time to time,too.

Newest dbg-branch works, without th issue described by MortenMacFly.

Another issue, to see the checkbox and the buttons of the disassembly dialog, I have to undock and resize it.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #356 on: November 26, 2010, 05:28:48 pm »
The same happens here from time to time,too.
In dbg-branch or in trunk?
(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 Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #357 on: November 26, 2010, 05:32:24 pm »
The same happens here from time to time,too.
In dbg-branch or in trunk?
In trunk, but I fo not use the debugger-branch very often, so it might also happen here.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #358 on: November 27, 2010, 12:28:50 am »
Another issue, to see the checkbox and the buttons of the disassembly dialog, I have to undock and resize it.

I fixed this issue in trunk (svn r6862) and debugger-branch (svn r6863).

If wxScinitll is created wit wxDefaultSize, the MinSize was set to large, so that parts of the dialog have been hidden in any useful size (seems to happen only with wxGTK not wxMSW), setting it after creation seems to have no effect.
Setting the initial size to wxSize(1,1) fixes the issue and seems to be without side-efects (at least I did not find any on linux and windows).

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Splitting debugger in two - specific debugger and common GUI
« Reply #359 on: November 28, 2010, 08:22:47 pm »
Anyone else having the same problems?
I would be interested in this very much, too. I'll try to compile the debugger version only (thus not having applied my local modification of wxScintilla). Still I believe that is not the reason as wxScintilla works well in all other editors / plugins (e.g. cbEditor, the preview in ThreadSearch and alike...).
Argh! Forget about it, I finally found the reason: When merging the disassembly XRC I forgot a closing </object> tag. Thus this file was invalid and the error was raised. I was looking in cpp source code though. Nevermind - stupid error message for what was actually going wrong. :?
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