Code::Blocks Linux Stability Issues, Solutions?

[Spirrwell]

Hello there.

For a long time through different distros Code::Blocks on Linux has always been really unstable for me, but it's much more stable now. I'm not experiencing complete crashes or a FLOOD of asserts.

Currently I'm using Code::Blocks with Manjaro 64 bit 17.0.4. The version of Code::Blocks is 16.01 rev 10692 (Built April 25, 2017) that I installed directly from Manjaro's software manager.

So it seems as though randomly after running Code::Blocks for a while, if I try to open a file in one of my projects, the text editor will just be blank, grey, and inactive. Though I can switch to other already open files with seemingly no problem. Sometimes when I go to do an action like left click then immediately right click at about the same time I will get an assert.



Quite often after this the GUI will begin to screw up and not have elements sized correctly like when I try to edit the build options of a project.

Also I don't believe this is related, but it seems like Code::Blocks does not recognize the platform specifc macros like __linux__ as you can see in the image above. It greys out what's inside the preprocessor, however this is purely visual, as the code still compiles as expected.

Essentially I want to know if others have experienced similar issues and if there's solutions beyond "waiting for a fix." Are the nightly builds any better? Would there be any difference if I built Code::Blocks myself? For the most part it functions normally, but these issues constantly happen and I have to close and re-open Code::Blocks to get back to normal state more often than not.

I'm not sure if I should file bug reports or not, as if I search, I tend to come across a lot of posts about crashing and bugs with Code::Blocks on Linux.

Regardless, any insight and help is appreciated

[BlueHazzard]

Can you post what wxWidgets version you are using? You can get this information from the Help->About screen. Under the image there should be a line like "Build....... -wx2.8.12)...

It is probably a problem with the symbol browser. Try to disable it in the settings: Settings->Editor->code completion->Symbol browser->Disable symbol browser

Generally speaking the latest trunk version is the most stable version. So if you have the possibility to build codeblocks by yourself this would be the preferred way. Not long ago (1 month?) obfuscated fixed a lot crash and visual issues for ubuntu. Maybe this bug also affects you.

Also I don't believe this is related, but it seems like Code::Blocks does not recognize the platform specifc macros like __linux__ as you can see in the image above. It greys out what's inside the preprocessor, however this is purely visual, as the code still compiles as expected.

I think this feature is not aware of the standard defines the compiler does, so it can not work properly for them (this is only a guess)...

[oBFusCATed]

Try a night build. Most probably you'll have to build it yourself, but I guess finding a PKGBUILD file won't be that hard.
If the problem persists, please press the copy-to-clipboard button and paste the text here. Images aren't really useful.

[Spirrwell]

Alright, so I went through the build process of the latest nightly. I cannot disable the symbol browser as it's simply greyed out in the settings:



I have not used it extensively yet, but I can still trigger an assert on demand by left clicking and immediately right clicking at about the same time. Here is a pastebin of the backtrace https://pastebin.com/8qbiMfDh

The version for wxWidgets is wx3.0.3. I guess I'll continue to use it and see if there's any other odd behavior, but it doesn't look promising.

[oBFusCATed]

Yes, the symbol browser is disabled by default in now.

Can you post the exact steps required to reproduce the focus assert?
What happens if you press the ignore button instead of the stop button.
Most of the times the asserts generated by wx (this is one such assert) are not fatal.

[BlueHazzard]

i can reproduce this in windows wx3.0.3.
Simply open a project and move the mouse in an open editor. Then make a right click and immediately a left click.
If i press cancel codeblocks locks it self and i have to force kill it.

[BlueHazzard]

This is somehow funny, because according documentation only windows should get this error messages:
http://docs.wxwidgets.org/3.0/classwx_mouse_capture_lost_event.html

This event is currently emitted under Windows only.

If i press cancel codeblocks locks it self and i have to force kill it.

this is wrong. The cause of this lock was that the mouse does not work. If i use the keyboard to select "cancel" all works as the assert never triggered. If i use the mouse to select a button of the error message, the message box jumps into the background of the app and i am not able to bring anything into foreground but the task manager. So this messes pretty hard with the event and window system. I try now to process this event and look if the assert does not trigger and some unexpected behavior pops up...

[BlueHazzard]

This fixes the assert message on windows.

Code

diff --git a/src/include/cbstyledtextctrl.h b/src/include/cbstyledtextctrl.h
index 3dfe95161..54d271c82 100644
--- a/src/include/cbstyledtextctrl.h
+++ b/src/include/cbstyledtextctrl.h
@@ -78,6 +78,7 @@ class DLLIMPORT cbStyledTextCtrl : public wxScintilla
         void MakeNearbyLinesVisible(int line);
     private:
         void OnContextMenu(wxContextMenuEvent& event);
+        void OnMouseCaptureLost(wxMouseCaptureLostEvent& event);
         void OnKillFocus(wxFocusEvent& event);
         void OnSetFocus(wxFocusEvent& event);
         void OnMouseMiddleDown(wxMouseEvent& event);
diff --git a/src/sdk/cbstyledtextctrl.cpp b/src/sdk/cbstyledtextctrl.cpp
index 2382a3396..fd256f354 100644
--- a/src/sdk/cbstyledtextctrl.cpp
+++ b/src/sdk/cbstyledtextctrl.cpp
@@ -35,6 +35,7 @@ std::map<int, std::set<int> > cbStyledTextCtrl::CommentLexerStyles;

 BEGIN_EVENT_TABLE(cbStyledTextCtrl, wxScintilla)
     EVT_CONTEXT_MENU(cbStyledTextCtrl::OnContextMenu)
+    EVT_MOUSE_CAPTURE_LOST(cbStyledTextCtrl::OnMouseCaptureLost)
     EVT_KILL_FOCUS  (cbStyledTextCtrl::OnKillFocus)
     EVT_MIDDLE_DOWN (cbStyledTextCtrl::OnMouseMiddleDown)
     EVT_MIDDLE_UP   (cbStyledTextCtrl::OnMouseMiddleClick)
@@ -112,6 +113,11 @@ void cbStyledTextCtrl::OnContextMenu(wxContextMenuEvent& event)
     }
 }

+void cbStyledTextCtrl::OnMouseCaptureLost(wxMouseCaptureLostEvent& event)
+{
+
+}
+
 void cbStyledTextCtrl::OnMouseMiddleDown(wxMouseEvent& event)
 {
     m_middleClickPos = PositionFromPoint(wxPoint(event.GetX(), event.GetY()));

There is still a cosmetic flaw that the context menu is displayed ater the left click is triggered.
The cause of this bug is probably that the context menu needs to much time to build and display. The context event handler is not exited in time before the new mouse event is triggered and so the second event gets lost. At the moment i have no idea for a proper fix, because we have to close the context menu (but how to close before it even is finished with building), or resend the mouse event with some time delay (really bad hack in my opinion).

[oBFusCATed]

I cannot reproduce this issue on linux using rev11166...

The context menu opens and I click on run to cursor item. Using wx3.0.2...

[BlueHazzard]

i am also not able to reproduce this on linux mint 18 gtk2 wx3.0.2

[Spirrwell]

Well so far it seems that aside from the weird assert that stability has been largely improved by switching to the nightly build.

I will note the version of Code::Blocks I was using before I switched to nightly was wx3.0.2 as well, so I'm sure it doesn't have to do with the the wxWidgets version entirely. And I was a bit wrong about how this assert happens. All you have to do is hold down the left mouse button in the text editor and then press the right mouse button. The text editor must first be in focus as well it seems. Just as an extra note I'm running the same nightly as before which was svn 11176 using wx3.0.3.

Code::Blocks still seems to be unaware of platform specifc #defines like __linux__ so if there is a way to fix that I would appreciate it. It seems to be aware of stuff like __GNUC__ But not the platform ones.

[oBFusCATed]

All you have to do is hold down the left mouse button in the text editor and then press the right mouse button. The text editor must first be in focus as well it seems. Just as an extra note I'm running the same nightly as before which was svn 11176 using wx3.0.3.

I can reproduce it now.

Code::Blocks still seems to be unaware of platform specifc #defines like __linux__ so if there is a way to fix that I would appreciate it. It seems to be aware of stuff like __GNUC__ But not the platform ones.

To fix it just disable it in the settings. I should make it off by default because this is one of the more frequent questions.

[Spirrwell]

To fix it just disable it in the settings. I should make it off by default because this is one of the more frequent questions.

Huh? Disable? You mean Settings->Editor->C/C++ Editor settings->Interpret #if, #else, #endif to grey out inactive preprocessor-code?

I wasn't wanting to disable it, I was wanting it to recognize the platform preproccesor. It does work properly for everything else, but it's greying out the platform macros like __linux__ when it shouldn't. I am on Linux, The compiler knows it, I know it, but Code::Blocks apparently doesn't. I don't quite understand why.

[Spirrwell]

Apologies for the double post, but now I'm having crashes. Code::Blocks generated a debug report in the form of an XML file, here is a pastebin of it: https://pastebin.com/TBFMefKK

I was able to make it happen twice. I'm not 100% sure what causes it, but I'm certain it's another wxWidgets issue.

I was writing a call to printf(). It was supposed to be printf( "Renderer: %s\n", SDL_GetError() );

It's when I typed the comma and immediately started typing SDL_GetError() that Code::Blocks crashed. I think it had something to do with it trying to show the arguments for the function I was writing, in this case printf() and trying to do code completion at the same time, in this case looking for SDL_GetError(). That's my best guess.

[oBFusCATed]

I wasn't wanting to disable it, I was wanting it to recognize the platform preproccesor. It does work properly for everything else, but it's greying out the platform macros like __linux__ when it shouldn't. I am on Linux, The compiler knows it, I know it, but Code::Blocks apparently doesn't. I don't quite understand why.

Then you need to provide a patch which fixes this limitation of the feature in its current implementation...