#1168 CB hangs then crashes when editing code. Seldom & hard to reproduce

[Elena]

I must say in advance that it is HARD to replicate because happens veryseldom.
It affects all CB versions and NB I tried since Apr 2021, when I started using CB and it was never fixed.
Here it happens when I reactivate CB window by clicking in the code editor. I move the mouse wheel and realize that everything is frozen. CB remains then unresponsive for even 30 or more seconds, and only then the Windows crash requester appears. Windows crash report attached.

[Andrew Cottrell]

I just suffered a crash after editing a file in Notepad++ and then when I clicked on the C::B editot it cashes. I am using a local build that has the SVN changes up to and including 12770, but unfortunately the C::B is in C:\program files and as such there is no RPT file produced.

I am wondering if it is possible to mod the RPT file save code to save the file in the config directory if saving it to the same directory as C::B exe is in fails.

I get it cashing about once every day or two, but only after I edit or use another Windows app for a few minutes as I think there is some timeout somewhere that fires and then when you go back to C::B the crash occurs as if I edit a file quickly and go back to C::B no cash occurs. The longer I am away from C::B the greater the chance of a crash.

[Elena]

Thanks. No build yet ?

[Miguel Gimenez]

You must wait for the next nightly, probably released on next weekend.

Anyway, Andrew has checked the modified version and he still gets crashes.

[Andrew Cottrell]

I have modded my local app.cpp CodeBlocksApp::InitExceptionHandler() as follows, which will hopefully allow if it works to capture some crashes as I run my local build from program files, but I have modded the update batch to not strip the files.

void CodeBlocksApp::InitExceptionHandler()
{
#ifdef __WXMSW__
    ExcHndlInit();

    wxString appdir = ConfigManager::GetFolder(sdBase);
    if (appdir.Contains("Program Files"))
    {
        wxDateTime datetimeNow  =  wxDateTime::Now();
        wxString dtDisplay = datetimeNow.Format("%d-%b-%Y_%H:%M:%S");
        wxString rpt_crashfile = wxString::Format("%s\\CodeBlocks_%s_SVN_%d.rpt", ConfigManager::GetFolder(sdDataUser), dtDisplay, autorevision::svn_revision);

        ExcHndlSetLogFileNameA(rpt_crashfile.c_str());
    }
#endif

}

If I get a cash I can see if I get a RPT file in c:\users....... directory.

[Andrew Cottrell]

No crashes today.

[Andrew Cottrell]

Crashed about 5 minutes ago, but no rpt file. gr.....

And another one:
The wxwidget dialog
[Window Title] wxWidgets Debug Alert
[Main Instruction] A debugging check in this application has failed.

[Content] ../../src/common/wincmn.cpp(3345): assert "!wxMouseCapture::IsInCaptureStack(this)" failed in CaptureMouse(): Recapturing the mouse in the same window?

[Andrew Cottrell]

Crash RPT attached.

[Miguel Gimenez]

This last RPT looks different, the crash is in wxAUI.

[Elena]

Nightly build of Apr, 24 sadly does not fix the bug. It just happened again. This time I did not activate cb coming from another program, I was simply scrolling and editing code. Once more, turning the mouse wheel to scroll caused the crash. Rpt attached

[bluehazzard]

0000000070CB66A1 0000000009BFE190 000000000022EEDC 000000000022EED8  codeblocks.dll!cbThreadPool::Done
0000000070CB62D7 000000000022EF30 0000000009BFE190 0000000000290000  codeblocks.dll!cbThreadPool::Done
0000000070982F9A 0000000006F2DCD0 000000000022F240 0000000009AA7860  codeblocks.dll!CCManager::OnPopupScroll

quite funny...
In OnPopupScroll Done is never called, so it is a destructor call? Done never calls Done...
ThreadPool::Done is never called in an destructor...
Sadly I have no experience in debugging this kind of multithreading problems...

Have you tried the clang code completion plugin? Maybe it has not this bug...

[Andrew Cottrell]

Crash report attached that may be related to this report. The report has line and code info in it, so it may be useful to see if anything is obvious.

The issue occurred after editing a file in NotePad++ on the second monitor and then clicked on the C::B editor that had the same file. The crash does NOT occur every time this is done. The last crash was in late August, so it is rare.

[pecan]

The attached patch (ccManagerMouseTrap220915-1.patch) resolves the above described conditions and add further fixes for the following conditions:
1) The HtmlDocumentationPopup gets stuck showing and cannot be closed.
2) The user did a double-click to select from the AutocompPopup, the HtmlDocumentationPopup got left showing and CB is frozen (and may crash).
3) The AutocompPopup and the HtmlPopup are showing, the user unfocused CB then re-focused CB and CB is frozen and must be killed.
4) The user has unChecked Documentation popup in options and now AutocompPopups cannot be scrolled.
5) The AutocompPopup is stuck showing and cannot be closed.
Ref: https://forums.codeblocks.org/index.php?topic=24357.msg171121#msg171121

[pecan]

Modified ccManagerMouseTrap patch to include some comments.
Also add code to clear wxEVT_MOUSEWHEEL connection when closing non-active editors.

[Miguel Gimenez]

Patch applied in [r12899], thank you.

[Manuel MS]

I'm using CB nightly 12864 (August 2022) and suffer the same issue.
Minimal steps:
1. Open CB
2. Open a file ( I use a wx header)
3. Use the mouse-wheel to scroll down the editor several pages.
The editor freezes for a few seconds. CB quits without a log.
Using the scroll bar works, only the wheel is buggy.

[Miguel Gimenez]

Try next nightly (or compile current trunk) to check if this is fixed.

[Manuel MS]

Still broken in nightly 12969 (08 October 2022)

[Andrew Cottrell]

Can you please supply a crash rpt?

[Elena]

Damn... I can't say if this is the same bug which just showed up in an unusual way or another bug... I was editing my code, I had just switched from one source tab to another, I disn't move the mouse wheel, I was selecting some text when I realized CB became unresponsive. I then waited some minutes as usual but no Windows crash requester popped up. I waited 10 minutes: still unrrsponsive. So I had to close it forcibly, and there is no .RPT file or Windows log available. Clearly tjat is not quite a 'crash' but the program (possibly the GUI ?) entering a deadloop.
Using latest NB & accessory libs