11
Using Code::Blocks / Re: CB crash today ... but I can continue to use
« Last post by blauzahn on March 13, 2026, 06:36:31 am »patch attached
News:
Accounts with zero posts and zero activity during the last months will be deleted periodically to fight SPAM!
Recent Posts
12
Using Code::Blocks / Re: CB crash today ... but I can continue to use
« Last post by blauzahn on March 12, 2026, 10:32:45 pm »Hi Lieven. Thank you.
13
Using Code::Blocks / Re: CB crash today ... but I can continue to use
« Last post by killerbot on March 12, 2026, 10:31:42 pm »good suggestions to apply.
14
Using Code::Blocks / Re: CB crash today ... but I can continue to use
« Last post by blauzahn on March 12, 2026, 10:27:36 pm »nice work; Thank you!
remarks:
svn13822:
* devcpploader.cpp:43: possibly dereferencing null pointer of non-owning data member m_pProject; An additional guard clause could return early in that case.
* devcpploader.cpp:48 and :156: Shouldn't the (2nd) pointer arg to Read be a nullptr instead of 0?
* devcpploader.cpp:47, 52, 134: uninitialized local variables used as out args to dev->Read:
int unitcount,
int typ,
bool compile,
bool compileCpp,
bool link
We could consider to value initialize them. Read potentially does not assign to them.
* devcpploader.cpp:45: The local variable dev is an owning raw pointer wxFileConfig* without any obvious need. As such, it lacks basic exception safety and could leak. We could consider replacing it with a std::unique_ptr<wxFileConfig> or, even better, just a stack variable wxFileConfig dev.
* devcpploader.h:17: The ctor of DevCppLoader might become explicit.
* devcpploader.h:25: The default ctor might be =deleted instead of defined in private section.
* svn13818: When override is used, we may consider to omit virtual. (see: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#rh-override)
remarks:
svn13822:
* devcpploader.cpp:43: possibly dereferencing null pointer of non-owning data member m_pProject; An additional guard clause could return early in that case.
* devcpploader.cpp:48 and :156: Shouldn't the (2nd) pointer arg to Read be a nullptr instead of 0?
* devcpploader.cpp:47, 52, 134: uninitialized local variables used as out args to dev->Read:
int unitcount,
int typ,
bool compile,
bool compileCpp,
bool link
We could consider to value initialize them. Read potentially does not assign to them.
* devcpploader.cpp:45: The local variable dev is an owning raw pointer wxFileConfig* without any obvious need. As such, it lacks basic exception safety and could leak. We could consider replacing it with a std::unique_ptr<wxFileConfig> or, even better, just a stack variable wxFileConfig dev.
* devcpploader.h:17: The ctor of DevCppLoader might become explicit.
* devcpploader.h:25: The default ctor might be =deleted instead of defined in private section.
* svn13818: When override is used, we may consider to omit virtual. (see: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#rh-override)
15
Nightly builds / The 12 March 2026 build (13823) is out.
« Last post by killerbot on March 12, 2026, 07:54:31 pm »We switched to gcc 15.1.0 (on 23 May 2025) --> download the new wx/mingw dll's see link below
Get the compiler we use here : https://github.com/brechtsanders/winlibs_mingw/releases/download/15.1.0posix-12.0.0-ucrt-r1/winlibs-x86_64-posix-seh-gcc-15.1.0-mingw-w64ucrt-12.0.0-r1.7z
Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
Before you use a nightly make sure you understand how it works.
A link to the unicode windows wxWidget dll(s) for Code::Blocks : https://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw32u_gcc_cb_wx328_2D_gcc1510-mingw64.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls15.1.0.7z
The 12 March 2026 build is out.
- Windows :
http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2026/CB_20260312_rev13823_win64.7z
- Linux :
none
The current SDK version is : 2.25.0
Resolved Fixed:
Regressions/Confirmed/Annoying/Common bugs:
Get the compiler we use here : https://github.com/brechtsanders/winlibs_mingw/releases/download/15.1.0posix-12.0.0-ucrt-r1/winlibs-x86_64-posix-seh-gcc-15.1.0-mingw-w64ucrt-12.0.0-r1.7z
Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
Before you use a nightly make sure you understand how it works.
A link to the unicode windows wxWidget dll(s) for Code::Blocks : https://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw32u_gcc_cb_wx328_2D_gcc1510-mingw64.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls15.1.0.7z
The 12 March 2026 build is out.
- Windows :
http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2026/CB_20260312_rev13823_win64.7z
- Linux :
none
The current SDK version is : 2.25.0
Resolved Fixed:
- cbp: add -Wextra to clangd_client_Windows.cbp and codesnippets_Windows.cbp, move WX_VER setting to a higher level(thanks gd_on)
- update.bat: replace some wilcards by a for...do syntax(thanks gd_on)
- CompilerOW: Remove null pointer dereferencing.
- FileManager: Fix wxString::Format() specifiers.
- DebuggerGDB: Fix wxString::Format specifiers and remove redundant comparison.
- ProjectImporter: Fix null pointer dereference replacing Read() with ReadLong().
- CompilerOW: Remove leading comma after "file" when linking.
Regressions/Confirmed/Annoying/Common bugs:
16
Using Code::Blocks / Re: CB crash today ... but I can continue to use
« Last post by Miguel Gimenez on March 12, 2026, 07:39:21 pm »The issue with the leading comma should be fixed in r13823.
17
Using Code::Blocks / Re: CB crash today ... but I can continue to use
« Last post by Miguel Gimenez on March 12, 2026, 10:24:53 am »Null pointer dereferencing fixed in r13813, thank you for reporting.
18
Using Code::Blocks / Re: CB crash today ... but I can continue to use
« Last post by blauzahn on March 11, 2026, 09:24:21 pm »When compiling cb (svn13805) with scan-build, its log contains a potential "dereferencing null pointer" in the compiler plugin in file compilerOWgenerator.cpp. See attached screen-shot. Not sure, whether it actually is the reason for the current problem.
for scan-build, see: https://clang.llvm.org/docs/analyzer/user-docs/CommandLineUsage.html#scan-build
Cheers.
for scan-build, see: https://clang.llvm.org/docs/analyzer/user-docs/CommandLineUsage.html#scan-build
Cheers.
19
Using Code::Blocks / Re: CB crash today ... but I can continue to use
« Last post by ThierryD on March 11, 2026, 05:52:31 pm »Sorry, site indicated before is not for source files of Glut32 library, only runtime version of GLUT and Freeglut with MinGW (32 bit) or MSVC (32 bit).
Source files of "glut32" library can be search on https://www.opengl.org/resources/libraries/glut/glut37.zip (in directory \lib\glut\* once unzipped).
Sincerly.
Source files of "glut32" library can be search on https://www.opengl.org/resources/libraries/glut/glut37.zip (in directory \lib\glut\* once unzipped).
Sincerly.
20
Using Code::Blocks / Re: CB crash today ... but I can continue to use
« Last post by ThierryD on March 11, 2026, 02:28:49 pm »Ok, I try to remember my previous actions.
Just to be precise, I use sometimes two screens to have more "surface", principal one of my laptop, secondary two in HDMI mode, but sometimes one screen only (other connected to my old fix PC).
Crash arrived on my laptop (much recent) with two screens, and after choose on "real" target to rebuild and try to use (Open WATCOM compiler), I don't know why but CB signal me that virtual target "glut32" has loose his "asociated" compiler. Just "in aparte", I find strange this mandatory association of compiler into CB to "virtual target", if I use this it's because I want run all build describe into "real target". Maybe, because I don't understand real need of this.
I join CB project in attachement (just add extension .txt to permit loading on forum). Dam that CB forum don't permit directly load of CB project
Source file of "glut32" library can be search on this site : https://www.transmissionzero.co.uk/files/software/development/GLUT/
Sorry, I have not exactly the order of my different actions into CB before crash (I'm just an "normal" user of CB that search to success build ... with many manipulations into IDE).
Regards.
PS : Examine properties of Open WATCM targets into CB project, to understand reason of my others remark in first post.
Just to be precise, I use sometimes two screens to have more "surface", principal one of my laptop, secondary two in HDMI mode, but sometimes one screen only (other connected to my old fix PC).
Crash arrived on my laptop (much recent) with two screens, and after choose on "real" target to rebuild and try to use (Open WATCOM compiler), I don't know why but CB signal me that virtual target "glut32" has loose his "asociated" compiler. Just "in aparte", I find strange this mandatory association of compiler into CB to "virtual target", if I use this it's because I want run all build describe into "real target". Maybe, because I don't understand real need of this.
I join CB project in attachement (just add extension .txt to permit loading on forum). Dam that CB forum don't permit directly load of CB project
Source file of "glut32" library can be search on this site : https://www.transmissionzero.co.uk/files/software/development/GLUT/
Sorry, I have not exactly the order of my different actions into CB before crash (I'm just an "normal" user of CB that search to success build ... with many manipulations into IDE).
Regards.
PS : Examine properties of Open WATCM targets into CB project, to understand reason of my others remark in first post.