The 06 May 2023 build (13268) is out.

[killerbot]

We switched to wx 3.2.2.1 (on 05 may 2023) --> download the new wx dll's see link below

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_wx3221_2D_gcc810-mingw64.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls8.1.0.7z


The 06 May 2023 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2023/CB_20230506_rev13268_win64.7z
  - Linux :
   none

The current SDK version is : 2.24.0

Resolved Fixed:

• SWITCH TO WX 3.2.2.1

Regressions/Confirmed/Annoying/Common bugs:

[Commaster]

I am having a problem on both Linux and windows passing a pointer back from a function, it is sign extending the pointer from 32 bits to 64 invalidating the pointer. Build from SVN revision 13268.
So for example if I have a pointer 0x269e9e9d040, on returning from the function the pointer will become 0xffffffffe9e9d040
<snip>
A workaround seems to be to use MinGW32 (on Windows of course) as pointers are only 32 bit.

This seems to be a programming issue, not a Code::Blocks issue?
Code::Blocks is not a compiler

[cbuser1]

Hello,

Code::blocks nightly becomes unresponsive when I add a new C++ class to an existing project.
Title would say Code::Blocks svn build (Not Responding).

This problem happened in older nightly builds as well.

CB 20.03 seems to work fine. Also, I'm on Windows 7.

To reproduce, Create a new C++ console project. Save it, and exit code::blocks. Launch code::blocks again and open the project. Opening an existing project seems to matter for some reason. It wouldn't freeze if I have created the class right away.

Click File->New->Class... and create a Dummy class.
Click on Create then click on Yes for the Add to project dialog box.
Click Ok on the Multiple selection dialog box.

Code::Blocks then becomes unresponsive for me.

Another issue, could you please include spell check with the nightly build?

Thanks

[Miguel Gimenez]

@cbuser1, can you check if the 18 February nightly works?

[cbuser1]

@cbuser1, can you check if the 18 February nightly works?

I installed CB_20230218_rev13215_win64.7z and it froze as well.
But, the unresponsiveness was not consistent. Sometimes, it added the files to the project and didn't freeze, other times it froze like mentioned before.

Please let me know if you want me to try another nightly version.

Oh, I just remembered another unrelated issue. When converting VS dsp project to codeblocks, sometimes I would get an assert error dialog, but didn't crash. Just click skip or ok to carry on.
I don't know if that's a known issue. It happened in 20.03 as well.

[Miguel Gimenez]

Thank you for testing. Can you check the 29 January nightly?

Regarding the VS dsp project conversion issue, please create a ticket including the contents of the assertion and, if possible, a test project.

[cbuser1]

Unfortunately, CB_20230129_rev13166_win64 froze too.
Let me know if you want me to try an older nightly. I don't mind.

About the assert, the error says "A debugging check in this application has failed.
../../src/msw/treectrl.cpp(1132): assert "item.IsOk" failed in SetItemBold(): invalid tree item.

I used the latest nightly to show that message.

For the project, clone github.com/id-Software/Quake-2 and select File->Import Project->MS Visual C++ workspace and select quake2.dsw

Thanks

[cbuser1]

In the code::blocks bottom panel, when it doesn't freeze it would put a message about the NativeParser switching project to my project name.
When it does freeze, it gets stuck on
NativeParser::OnParserEnd: Project "NONE" parsing stage done!.

It doesn't say
Switch parser to project 'Whatever'

I hope that could be useful to you.

[Miguel Gimenez]

I am pretty sure it is a mutex problem in CodeCompletion. I also suffer it, but currently have no time to debug, so your help is welcome.

Can you do a bisection from, say, 19 june to the one before 13166?. Beware, they are not sorted by date in the nightlies post because of replies.

[cbuser1]

No luck, CB_20220619_rev12839_win64.7z froze too.
I'll try older nightlies.

Update:
It's somewhere between
CB_20210709_rev12487_win64.7z
and
CB_20211220_rev12596_win64.7z

I couldn't get 12487 to freeze.
12596 froze like all the newer ones.

Update 2:
CB_20211214_rev12579_win64.7z Seems to be the latest nightly that didn't freeze.
Which would make CB_20211220_rev12596_win64.7z as the version that introduced this bug.

[Miguel Gimenez]

Many thanks for locating the culprit.

Regarding assertions when importing MSVC++ workspaces, I have just fixed them in r13269. This has uncovered another problem after importing, I have created ticket #1392 so it is not forgotten.

[Miguel Gimenez]

Ticket #1392 fixed in r13270

[cbuser1]

Thanks for fixing the assertion bug.

I might have been wrong about CB_20211214_rev12579_win64.7z. It just froze on me
I'll test older nightlies.

[ccdric]

Hi everybody,
after switching my Ubuntu to Lunar, I meet some crash with nigtly 13254.I tryed 13268 then 13270 rev. It's the same.
It's crashing randomly (but very often) during tapping code when auto-completion popup is on.
Lunar uses wxw rev 3.2.2
I joined codeblocks bug report fron 13270 crash

[stahta01]

Hi everybody,
after switching my Ubuntu to Lunar, I meet some crash with nigtly 13254.I tryed 13268 then 13270 rev. It's the same.
It's crashing randomly (but very often) during tapping code when auto-completion popup is on.
Lunar uses wxw rev 3.2.2
I joined codeblocks bug report fron 13270 crash

Looks like Lunar uses "wayland".

Edit: Link to possible workaround https://forums.codeblocks.org/index.php/topic,25206.msg171903.html#msg171903

Tim S.