#701 CodeCompletion freezes C::B

[FViktor]

Ubuntu 16.04, CodeBlocks svn 11400 with wxWidgets 3.1.1

I have found a strange bug in CodeCompletion. Sometimes Code::Blocks freezes (and has to be killed) after a code completion popup was shown. This only happens for a specific editor window width range, which is dependent on the context where CodeCompletion is triggered.
Here is an example to reproduce.
- Delete all CodeBlock setting files from ~/.config/codeblocks
- Start Code::Blocks, create a new (console) project, and insert this example code:

class MyClass
{
public:
    void ABCDEFGHIJKLMN();
};

int main()
{
    MyClass * obj;
}

• This is the tricky part: try to resize the editor to a problematic size. See the screenshot bellow.
• Now hit enter after the declaration of obj, and type obj->
• Code completion opens with the function ABCDEFGHIJKLM(), and Code::Blocks hangs, while using a lot of CPU.

I've tracked down the problem to the call
bool rv = BaseClass::Show(show);
in UnfocusablePopupWindow::Show in src/sdk/ccmanager.cpp. This call doesn't return. I've given up from here, the problem may be in wxWidgets. Probably not in wxPopupWindow, as the same thing happens if I inherit UnfocusablePopupWindow from wxFrame.

[Teodor Petrov]

Do you have the documentation tooltips enabled? If you have does it fix the problem if you disabled them? Do you have some other wm or desktop environment to test if the problem is not caused by unity?

[Teodor Petrov]

Does the problem happens if you just move codeblocks to the right of the screen without resizing the management pane?

[FViktor]

Yes, I've reset all settings to default. Turns out the problem is indeed with the documentation popup which is a wxHtmlWindow. This widget tends to freeze programs if resized to some environment (and content etc.) specific size. So yes, it happens if you just move codeblocks to the right.
I've tested on Ubuntu 18.04 which comes without Unity, and experienced the same bug. I've attached a small example for testing here:
https://trac.wxwidgets.org/ticket/18141
I have given up digging deeper into wxHtmlWindow or GTK+, I'll simply disable documentation popups.

[Teodor Petrov]

I think, I've reproduced it with your sample. Thanks for digging deep and finding a repro case. Lets see if wx people could fix this.

[Teodor Petrov]

This is a report for the same thing: http://forums.codeblocks.org/index.php/topic,22264.0.html

[FViktor]

Seems like it. As you can see from the linked wxWidgets bug report, I've found the cause and also posted a patch. Also, another bug that was part of this crash has already been fixed since, and that effectively fixes this bug too.

[Teodor Petrov]

Do you know if wxWidgets' devs would backport the fixes to 3.0?

[FViktor]

Not sure. I've posted a question about that.

[FViktor]

My fix was committed to the development branch here. There is another commit that is enough to overcome this issue. It was committed to master here, and it was also backported to the WX_3_0_BRANCH here, so there is no need to backport my fix.

[Teodor Petrov]

Cool now you need to convince ubuntu's maintainers to apply the patch on their version of wxGTK.

[FViktor]

Or I could just use a custom build of wxWidgets for Code::Blocks... Oh wait, I already do.

[Teodor Petrov]

Yes, but what about the rest of the ubuntu users? :)

[FViktor]

I know, that's sad.. I’m not at all familiar with the update cycle, but doesn’t wx 3.0.5 and 3.1.2 need to be released first? At least the fix is on its way, thanks to me so I won’t lose any sleep over it. Until then documentation popups can be disabled… you just need to figure out they are the cause of the issue and be aware that there is a setting to disable them.

[Teodor Petrov]

Distro maintainers don't need a release. They often apply single patches when the benefit is larger than the cost or the risk is low. So letting them know about the problem and if they find time they'll do it...