C::B reports wxRecursionGuards error when loading a cbp project

[ollydbg]

I just build C::B against wx 3.3.1, and the result C::B report many error messages when I load a project, the message looks like below:

Code

[Window Title]
wxWidgets Debug Alert

[Main Instruction]
A debugging check in this application has failed.

[Content]
..\..\include/wx/recguard.h(36): assert "m_flag > 0" failed in ~wxRecursionGuard(): unbalanced wxRecursionGuards!?

[ ] Don't show this dialog again  [Stop] [Continue]

Any ideas which cause this issue?


EDIT:

Here is the crash report from the RPT file:

Code

codeblocks.exe caused a Breakpoint at location 00007FF94B7822BA in module wxmsw331u_gcc_custom.dll.

AddrPC           Params
00007FF94B7822BA 00000260EFC92E70 0000000000000000 0000000000000000  wxmsw331u_gcc_custom.dll!wxEvtHandler::SearchDynamicEventTable+0x12a
00007FF94B7828FB 0000000000000001 00000260F4764260 0000009E3CBFF750  wxmsw331u_gcc_custom.dll!wxEvtHandler::TryHereOnly+0x2b
00007FF94B782983 00000260F4763FD0 0000009E3CBFF6F0 00000260F4764260  wxmsw331u_gcc_custom.dll!wxEvtHandler::ProcessEventLocally+0x33
00007FF94B782A61 0000000000011A38 0000000000000000 0000000000000000  wxmsw331u_gcc_custom.dll!wxEvtHandler::ProcessEvent+0xc1
00007FF94BA75018 0000009E3CBFF8E0 0000000000000001 00000260F4762440  wxmsw331u_gcc_custom.dll!wxWindowBase::TryAfter+0x58
00007FF94BA557DC 00007FF94C8F48E0 00007FF900000002 00000260F00FF3D0  wxmsw331u_gcc_custom.dll!wxToolBarBase::UpdateWindowUI+0x19c
00007FF94BA68217 0000000000000000 0000000000000000 0000000000000000  wxmsw331u_gcc_custom.dll!wxWindowBase::SendIdleEvents+0x17
00007FF94BA6824F 0000000000000000 0000000000000000 0000000000000000  wxmsw331u_gcc_custom.dll!wxWindowBase::SendIdleEvents+0x4f
00007FF94B969B04 00000260F4810D60 00000260F4810D60 0000000000000000  wxmsw331u_gcc_custom.dll!wxAppBase::ProcessIdle+0xc4
00007FF94B669CB3 0000000000000028 00007FF94C8C4150 0000009E3CBFFB40  wxmsw331u_gcc_custom.dll!wxEventLoopManual::DoRunLoop+0x83
00007FF94B669DC8 00000260EF70B960 00000260F4810D60 0000000000000000  wxmsw331u_gcc_custom.dll!wxEventLoopManual::DoRun+0x38
00007FF94B6698D8 0000000000000048 00007FF9BCFDC9D0 0000009E3CBFFAC0  wxmsw331u_gcc_custom.dll!wxEventLoopBase::Run+0x58
00007FF94B63619F 00000260EF75D0C0 00000260EF7128B0 00007FF94D0D95C8  wxmsw331u_gcc_custom.dll!wxAppConsoleBase::MainLoop+0x7f
00007FF62CCA62CA 00000260EF70B960 0000000000000000 0000000000000000  codeblocks.exe!0x62ca
00007FF94B6A879E FFFFFFFFFFFFFFFF 0000000000000008 0000000000000048  wxmsw331u_gcc_custom.dll!wxInitialize+0x12e
00007FF62CCA2A97 00007FF62CCA0000 0000000000000000 00000260EDC8365C  codeblocks.exe!0x2a97
00007FF62CCA12E9 0000000000000000 0000000000000000 0000000000000000  codeblocks.exe!0x12e9
00007FF62CCA13D6 0000000000000000 0000000000000000 0000000000000000  codeblocks.exe!0x13d6
00007FF9BCFB7374 0000000000000000 0000000000000000 0000000000000000  KERNEL32.DLL!BaseThreadInitThunk+0x14
00007FF9BEBBCC91 0000000000000000 0000000000000000 0000000000000000  ntdll.dll!RtlUserThreadStart+0x21

[stahta01]

I did not see the problem.

Code

Name                    : Code::Blocks
Version                 : svn-r13746
SDK Version             : 2.25.0
Scintilla Version       : 3.7.5
OS                      : Windows 10 (build 19045), 64-bit edition
wxWidgets Library (wxMSW port)
Version 3.3.1 (Unicode: wchar_t, debug level: 1),
compiled at Oct  9 2025 07:51:44

Under MSys2 UCRT64 with Code::Blocks in dark mode and using multilib wxWidgets.
Edit: Code::Blocks built using configure/make build under MSys2 UCRT64

Tim S.

[blauzahn]

It is the Clangd_client that has or triggers this bug at least on Linux. After a while it crashes cb. I have seen it on numerous occasions.

That's why I usually leave it disabled. I enable is only sporadically to use its hints analogue to clang-tidy or IWYU and immediately
disable it thereafter. Please be aware that the IWYU function has many false positives. Those you can silence with // IWYU pragma: keep

[ollydbg]

I'm under Windows 10 64bit system.

I never see this wxRecursionGuards error message before when I used C::B(built with wx 3.2.x) when using clangd-client.

For C::B(built with wx 3.3.x), it is hard to reproduce the error again. 

[blauzahn]

I can reproduce the error with wx 3.3.2 on Linux.

The analysers scan-build or cppcheck show several issues with Clangd_client.

[Pecan]

I can reproduce the error with wx 3.3.2 on Linux.

The analysers scan-build or cppcheck show several issues with Clangd_client.

Would you care to share those issues with us?
Can you tell us how to reproduce the issue?

[ollydbg]

I see this issue again and again. Sometimes, the C::B just existed(crashed) without any message, this happens after when I click the "Cancel" button in the message box to continue the application. When I looked at the RPT(call stack), it just empty, so I don't have much information to share.

[stahta01]

I see this issue again and again. Sometimes, the C::B just existed(crashed) without any message, this happens after when I click the "Cancel" button in the message box to continue the application. When I looked at the RPT(call stack), it just empty, so I don't have much information to share.

It is normal for crashing to happen if you click the cancel button in a wxWidgets assert style message; but it should give you a RPT file to help find the location of the crash. I have done it to track down the location where the code needs changed.

Tim S.

[Pecan]

Since some users report this assert in relation to clangd_client plugin,
I'll try to recreate the situation and find the cause.
It may take some time since I'm not proficient with Linux.

Gemini 3.0 explains this error as follows:

My query to Gemini 3.0:

Code

 Please explain this message from wxWidgets that occurs more and more with Codeblocks IDE.

wxWidgets Debug Alert

A debugging check in this application has failed.
..\..\include/wx/recguard.h(36): assert "m_flag > 0" failed in ~wxRecursionGuard(): unbalanced wxRecursionGuards!?

Gemini responded;

This specific error is a classic "housekeeping" alert from the wxWidgets library. In short, the program is telling you that it tried to clean up a safety mechanism, but the math didn't add up.
What is a Recursion Guard?

A wxRecursionGuard is a tool developers use to prevent a function from calling itself infinitely (which would crash the program). Think of it like a "Do Not Enter" sign that a function hangs on its door when it starts working. When the function finishes, it takes the sign down.

The error assert "m_flag > 0" failed means that when the function finished and went to take the sign down, it found the sign was already gone - or it found "negative" signs. This is what the message means by "unbalanced."
Why is this happening in Code::Blocks?

Code::Blocks is built using wxWidgets. You are seeing this more often likely due to one of three reasons:

    UI Event Races: Code::Blocks is trying to process a UI event (like a mouse click or a window redraw) while another event is still finishing. This is common if you are clicking rapidly or if the IDE is lagging.

    Plugin Conflicts: A specific plugin (like Code Completion or Symbol Browser) might be triggering a "re-entrant" call, where it starts a task, gets interrupted, and fails to clean up its state properly.

    Build/Version Mismatch: If you recently updated your OS or the IDE, there might be a slight incompatibility in how messages are passed between the system and the wxWidgets layer.

How to Fix or Bypass It

Since this is a Debug Alert, it is technically a warning for the developers of Code::Blocks, not necessarily a sign that your code is broken.

    The "Ignore" Method: Click "Yes" to continue (this usually ignores the specific failure) or "No" to stop debugging. If you click "Cancel," it will likely crash the IDE to trigger a debugger.

    Update Code::Blocks: Check if there is a newer "Nightly Build" or stable release. These "unbalanced guard" bugs are frequently patched in newer revisions.

    Disable Heavy Plugins: Go to Plugins -> Manage plugins and try disabling non-essential ones (like "SpellChecker" or "Occurrences Highlight") to see if the frequency drops.

    The "Silent" Route: If it is driving you crazy, you can run the "non-debug" version of Code::Blocks (the release build), which typically strips out these assert checks so they don't pop up.

clangd_client has some re-entrancy guards. But I do not remember calling wxWidgets to do the guarding.
But I'll check them out to see if there are some logic violations or any use of wxWidgets recursion guards.

[Pecan]

The only reference to recguard.h in CB is in headerfixup plugin.

Do any of the posters here (and getting the assert) use headerfixup plugin?
If so, just for testing, please disable the plugin and run without it for awhile and post back your experience.

This is a "Hail Mary" because headerguard does not actually use the wxRecursionGuard code. It only references the name. And no other code in CB uses it either.
So... must be wxWidgets using it itself.

Thanks

Edit: 2026/02/21 10:45:13
Well.. It seems that all code uses it that uses the event loop. This shoud be fun ):

[Pecan]

@ ollydbg

I just build C::B against wx 3.3.1, and the result C::B report many error messages when I load a project, the message looks like below:

Code

[Window Title]
wxWidgets Debug Alert

[Main Instruction]
A debugging check in this application has failed.

[Content]
..\..\include/wx/recguard.h(36): assert "m_flag > 0" failed in ~wxRecursionGuard(): unbalanced wxRecursionGuards!?

[ ] Don't show this dialog again  [Stop] [Continue]

Any ideas which cause this issue?


EDIT:

Here is the crash report from the RPT file:

Code

codeblocks.exe caused a Breakpoint at location 00007FF94B7822BA in module wxmsw331u_gcc_custom.dll.

AddrPC           Params
00007FF94B7822BA 00000260EFC92E70 0000000000000000 0000000000000000  wxmsw331u_gcc_custom.dll!wxEvtHandler::SearchDynamicEventTable+0x12a
00007FF94B7828FB 0000000000000001 00000260F4764260 0000009E3CBFF750  wxmsw331u_gcc_custom.dll!wxEvtHandler::TryHereOnly+0x2b
00007FF94B782983 00000260F4763FD0 0000009E3CBFF6F0 00000260F4764260  wxmsw331u_gcc_custom.dll!wxEvtHandler::ProcessEventLocally+0x33
00007FF94B782A61 0000000000011A38 0000000000000000 0000000000000000  wxmsw331u_gcc_custom.dll!wxEvtHandler::ProcessEvent+0xc1
00007FF94BA75018 0000009E3CBFF8E0 0000000000000001 00000260F4762440  wxmsw331u_gcc_custom.dll!wxWindowBase::TryAfter+0x58
00007FF94BA557DC 00007FF94C8F48E0 00007FF900000002 00000260F00FF3D0  wxmsw331u_gcc_custom.dll!wxToolBarBase::UpdateWindowUI+0x19c
00007FF94BA68217 0000000000000000 0000000000000000 0000000000000000  wxmsw331u_gcc_custom.dll!wxWindowBase::SendIdleEvents+0x17
00007FF94BA6824F 0000000000000000 0000000000000000 0000000000000000  wxmsw331u_gcc_custom.dll!wxWindowBase::SendIdleEvents+0x4f
00007FF94B969B04 00000260F4810D60 00000260F4810D60 0000000000000000  wxmsw331u_gcc_custom.dll!wxAppBase::ProcessIdle+0xc4
00007FF94B669CB3 0000000000000028 00007FF94C8C4150 0000009E3CBFFB40  wxmsw331u_gcc_custom.dll!wxEventLoopManual::DoRunLoop+0x83
00007FF94B669DC8 00000260EF70B960 00000260F4810D60 0000000000000000  wxmsw331u_gcc_custom.dll!wxEventLoopManual::DoRun+0x38
00007FF94B6698D8 0000000000000048 00007FF9BCFDC9D0 0000009E3CBFFAC0  wxmsw331u_gcc_custom.dll!wxEventLoopBase::Run+0x58
00007FF94B63619F 00000260EF75D0C0 00000260EF7128B0 00007FF94D0D95C8  wxmsw331u_gcc_custom.dll!wxAppConsoleBase::MainLoop+0x7f
00007FF62CCA62CA 00000260EF70B960 0000000000000000 0000000000000000  codeblocks.exe!0x62ca
00007FF94B6A879E FFFFFFFFFFFFFFFF 0000000000000008 0000000000000048  wxmsw331u_gcc_custom.dll!wxInitialize+0x12e
00007FF62CCA2A97 00007FF62CCA0000 0000000000000000 00000260EDC8365C  codeblocks.exe!0x2a97
00007FF62CCA12E9 0000000000000000 0000000000000000 0000000000000000  codeblocks.exe!0x12e9
00007FF62CCA13D6 0000000000000000 0000000000000000 0000000000000000  codeblocks.exe!0x13d6
00007FF9BCFB7374 0000000000000000 0000000000000000 0000000000000000  KERNEL32.DLL!BaseThreadInitThunk+0x14
00007FF9BEBBCC91 0000000000000000 0000000000000000 0000000000000000  ntdll.dll!RtlUserThreadStart+0x21

@ ollydbg
Did this backtrace come from click cancel/stop when the assert applied, or at some other time?