Splitting debugger in two - specific debugger and common GUI

[cbexaminr]

Ok.

[oBFusCATed]

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.

[oBFusCATed]

Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0017.7.patch  (improved version of http://forums.next.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?

[MortenMacFly]

...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 Select Expand


   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 Select Expand

   m_MixedModeCB = (wxCheckBox*)FindWindow(XRCID("chkMode"));
   m_MixedModeCB->SetValue(Manager::Get()->GetDebuggerManager()->IsDisassemblyMixedMode());

...or here:

Code Select Expand

   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:

[oBFusCATed]

...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 Select Expand


   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 Select Expand

   m_MixedModeCB = (wxCheckBox*)FindWindow(XRCID("chkMode"));
   m_MixedModeCB->SetValue(Manager::Get()->GetDebuggerManager()->IsDisassemblyMixedMode());

...or here:

Code Select Expand

   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

[MortenMacFly]

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).

[oBFusCATed]

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

[MortenMacFly]

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.

[killerbot]

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.

[oBFusCATed]

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).

[Jenna]

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.

[oBFusCATed]

The same happens here from time to time,too.

In dbg-branch or in trunk?

[Jenna]

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.

[Jenna]

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).

[MortenMacFly]

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. :?