V 20.03 startup fails w/debugging assertion failure if not running as admin

[caonen8425]

Running C::B on Windows 7 Pro 64

Just installed v20.03 a few days ago.  About day 2 into using it, startup began failing with a 'debugging check...assertion failure' in GetWeightClosestToNumericValue(). Screen snippet attached (hopefully).  I never quit out of C::B with the debugger running. Admittedly, during the time period this failure began, I was still tweaking the toolchain and search directory settings, so that is certainly suspect. But I fail to understand how ensuring the use of 64-bit tools, libs, et al would throw a debugger check assertion at startup when the debugger is not even running.

If I start C::B with 'run as administrator', the error does NOT occur.

In all other respects, to-date, v20.03 has been solid for me.

I've never before needed to run C::B with admin privileges, and it seems insane to do so unless needed by the specific app under development.

[oBFusCATed]

What happens if you click continue?

This is supposedly a known problem in wx which we should have fixed.
@Killerbot have you applied the patch for the font issue to our version of wx?

[killerbot]

which specific path are you talking about ?
I will compare with the patches I have carried out, somewhere described in the forum, but also in a log file in my windows partition.

[oBFusCATed]

The one related to the fonts or fontinfo. There was some rounding problem. Ollydbg reported it and it was fixed.

[stahta01]

Attached patch file. I am using to patch wx3.1.3.

Date: Thu, 16 Jan 2020 00:07:06 +0100
Subject: Allow parsing all fractional sizes in wxFont descriptions

Tim S.

[caonen8425]

Obfuscated,

Sorry for the delay in responding.  Hitting 'continue' results in a repetition of the same assertion failure.  I see that a patch has been offered.  I have never before applied a patch...I will check this out. 

[stahta01]

Obfuscated,

Sorry for the delay in responding.  Hitting 'continue' results in a repetition of the same assertion failure.  I see that a patch has been offered.  I have never before applied a patch...I will check this out.

My patch had to do with fonts; I have no idea if it will help the debugging issue.

Edit: oBFusCATed suggested it would.
Edit2: You also need or should apply the other wxWidgets changes done by Killerbot.
And, use the same build/make options. This should result in wxWidgets DLL that could be replacing the current one. Note: The same GCC Compiler is needed to avoid have to rebuild Code::Blocks.

Tim S.

[caonen8425]

This is my first experience with C::B patches, and I see it is in source form.

I am not currently set up to build C::B components from source. Before I go down that road to apply a patch, I'd like more certainty this patch will fix my specific problem. If there is more documentation I can provide to verify this, please advise. Secondly, where do I find a list (and access) to any pre/co-req patches that must be applied with this patch.  And, finally, since I've never applied a patch, is there some 'how to' documentation for applying patches (haven't found any yet)?.

And then, none of this discussion explains (to me) why this debugging assertion failure vanishes when I run C::B as Administrator.

[oBFusCATed]

Because the administrator has a different config file probably.
Can you find the default.conf in AppData/Codeblocks and open it in text editor and search for something like

Code Select Expand


<FONT>
<str>
<![CDATA[Fira Code Light 9]]>
</str>
</FONT>


What is the value you're using?

[sodev]

I am pretty sure this is the fontsize bug of wxWidgets, the easiest way to fix it is to simply edit the configuration file and choose another font size that doesn't cause the rounding error. However depending on the chosen value, editing codeblocks settings through its dialogs might change the value again to something that causes the error.

The bug is not in CodeBlocks but wxWidgets, you need to update that library. Instead of applying that patch i would simply build a recent snapshot of master instead.

About fixing the issue by launching CodeBlocks as admin, most probably your regular user account doesn't have admin rights so launching as admin does not simply upgrade your rights through UAC but switches to another account and on that one you have your own configuration file that uses other settings that don't trigger that bug.

[oBFusCATed]

The bug is not in CodeBlocks but wxWidgets, you need to update that library. Instead of applying that patch i would simply build a recent snapshot of master instead.

I would advice against this practice, especially if one is to keep using the same codeblocks.exe without a rebuild.

[oBFusCATed]

@killerbot: Do you have the patch from this post http://forums.next.codeblocks.org/index.php/topic,23801.msg162332.html#msg162332 applied to the shipped version of wx?

[caonen8425]

Obfuscated,

I see one straightforward difference (10 v 10.2) between the admin and user font settings.
Changing the user setting from '10.2' to '10' resolved the start up assertion failure. 

admin:
      <FONT>
         <str>
            <![CDATA[1;10;-17;0;0;0;400;0;0;0;1;0;0;2;48;Courier New]]>
         </str>
      </FONT>

user:
      <FONT>
         <str>
            <![CDATA[1;10.2;-17;0;0;0;400;0;0;0;1;0;0;2;48;Courier New]]>
         </str>
      </FONT>

Thanks much.

[stahta01]

I built the DLL with the font patch it can be found https://github.com/stahta01/stahta01.github.io/blob/master/wxWidgets/wxmsw313u_gcc_cb.dll

Build command used

Code Select Expand


mingw32-make -f makefile.gcc VENDOR=cb CXXFLAGS+="-std=c++11" MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release


Edit: I built this code https://github.com/stahta01/wxwidgets_master_fork/commits/wxwidgets3.1.3_git
Note: I had to run this command before building.

Code Select Expand

rm -f include/wx/msw/setup.h

Edit: Built using the Compiler packaged with CB 20.03 64 bit.

Tim S.