Author Topic: code::blocks hangs at startup  (Read 62352 times)

Offline ChrisK

  • Single posting newcomer
  • *
  • Posts: 3
code::blocks hangs at startup
« on: September 25, 2025, 03:20:40 am »
Hi,

Firstly, I have been using code::blocks for years, thank you to all involved.

A few days ago, the IDE locked up on the splash screen at start up, and has been like that ever since. I would appriciate any pointers to help me fix this.

I am running Arch Linux & Plasma with all updates done.

Code
$ uname -a
Linux XPS13 6.16.8-arch3-1 #1 SMP PREEMPT_DYNAMIC Mon, 22 Sep 2025 22:08:35 +0000 x86_64 GNU/Linux
$ codeblocks -h
Starting Code::Blocks Release 25.03  rev 13644 Jun  7 2025, 18:00:35 - wxWidgets 3.2.8 - gcc 15.1.1 (Linux, unicode) - 64 bit

If I do an strace, it always hangs at the same "futex" line...

Code
$ strace codeblocks
...
...
...
openat(AT_FDCWD, "/usr/share/codeblocks/images/wxsmith/wxTreeCtrl32.png", O_RDONLY) = 17
fstat(17, {st_mode=S_IFREG|0644, st_size=1055, ...}) = 0
read(17, "\211PNG\r\n\32\n\0\0\0\rIHDR\0\0\0 \0\0\0 \10\2\0\0\0\374\30\355"..., 4096) = 1055
read(17, "", 4096)                      = 0
lseek(17, 0, SEEK_SET)                  = 0
getpid()                                = 2789
readlink("/proc/2789/fd/17", "/usr/share/codeblocks/images/wxs"..., 256) = 53
futex(0x7f5be561f5c0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x55bc86995120, FUTEX_WAIT_BITSET_PRIVATE, 16, NULL, FUTEX_BITSET_MATCH_ANY) = 0
socketpair(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0, [23, 24]) = 0
ioctl(23, FIONBIO, [1])                 = 0
ioctl(24, FIONBIO, [1])                 = 0
memfd_create("seccomp-bpf-filter", 0)   = 25
write(25, " \0\0\0\4\0\0\0\25\0\0f>\0\0\300 \0\0\0\0\0\0\0005\0\0\1\0\0\0@"..., 840) = 840
lseek(25, 0, SEEK_SET)                  = 0
mmap(NULL, 2101248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f5bb03ff000
madvise(0x7f5bb03ff000, 4096, MADV_GUARD_INSTALL) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
clone3({flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, child_tid=0x7f5bb05ff990, parent_tid=0x7f5bb05ff990, exit_signal=0, stack=0x7f5bb03ff000, stack_size=0x1ff280, tls=0x7f5bb05ff6c0} => {parent_tid=[2827]}, 88) = 2827
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0x55bc86995120, FUTEX_WAIT_BITSET_PRIVATE, 17, NULL, FUTEX_BITSET_MATCH_ANY

I have tried deleting all config and also tried with the "--safe-mode" command line parameters, neither helped.


Offline blauzahn

  • Almost regular
  • **
  • Posts: 222
Re: code::blocks hangs at startup
« Reply #1 on: September 25, 2025, 06:34:05 am »
Same here. I also use cb-trunk on Arch and tried wx-3.2.8 and trunk (3.3.2). Startup shows:

Code
$ LANG=C codeblocks --safe-mode
Starting Code::Blocks svn build  rev 13738 Sep 25 2025, 06:01:28 - wxWidgets 3.3.2 - gcc 15.2.1 (Linux, unicode) - 64 bit
Manager initialisiert
Initialize EditColourSet .....
Initialize EditColourSet: done.
Loading menubar...
ToolsPlus: loaded

When started from gdb and hit Ctrl-C, the backtrace is this:

Code
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff03ff6c0 (LWP 128732)]
[New Thread 0x7fffefbfe6c0 (LWP 128733)]
[New Thread 0x7fffef3fd6c0 (LWP 128734)]
[New Thread 0x7fffeebfc6c0 (LWP 128735)]
[New Thread 0x7fffee3fb6c0 (LWP 128736)]
[New Thread 0x7fffedbfa6c0 (LWP 128737)]
Starting Code::Blocks svn build  rev 13733 Sep 24 2025, 08:05:57 - wxWidgets 3.3.2 - gcc 15.2.1 (Linux, unicode) - 64 bit
Manager initialisiert
Initialize EditColourSet .....
[New Thread 0x7fffecabe6c0 (LWP 128772)]
[New Thread 0x7fffcffff6c0 (LWP 128773)]
[New Thread 0x7fffcf7fe6c0 (LWP 128774)]
Initialize EditColourSet: done.
Loading menubar...
[New Thread 0x7fffceffd6c0 (LWP 128775)]
[New Thread 0x7fffec24f6c0 (LWP 128776)]
[New Thread 0x7fffce7fc6c0 (LWP 128777)]
[New Thread 0x7fffce5fb6c0 (LWP 128778)]
[Detaching after fork from child process 128779]
[New Thread 0x7fffce3fa6c0 (LWP 128782)]
[Detaching after fork from child process 128783]
[New Thread 0x7fffce1f96c0 (LWP 128784)]
[New Thread 0x7fffcdff86c0 (LWP 128785)]
[New Thread 0x7fffcdd896c0 (LWP 128789)]
ToolsPlus: loaded
[New Thread 0x7fffcd3ff6c0 (LWP 128793)]
[New Thread 0x7fffcd1fe6c0 (LWP 128794)]
[New Thread 0x7fffccffd6c0 (LWP 128795)]
[New Thread 0x7fffccdfc6c0 (LWP 128796)]
[New Thread 0x7fffccbfb6c0 (LWP 128797)]
[New Thread 0x7fffcc9fa6c0 (LWP 128798)]
[New Thread 0x7fffcc7f96c0 (LWP 128799)]
[New Thread 0x7fffcc5f86c0 (LWP 128800)]
[New Thread 0x7fffcc3f76c0 (LWP 128801)]
[New Thread 0x7fff87fff6c0 (LWP 128802)]
[New Thread 0x7fff87dfe6c0 (LWP 128803)]
[New Thread 0x7fff87bfd6c0 (LWP 128804)]
[New Thread 0x7fff879fc6c0 (LWP 128805)]
[New Thread 0x7fff877fb6c0 (LWP 128806)]
[New Thread 0x7fff875fa6c0 (LWP 128807)]
[New Thread 0x7fff873f96c0 (LWP 128808)]
[New Thread 0x7fff871f86c0 (LWP 128809)]
[New Thread 0x7fff86ff76c0 (LWP 128810)]
[New Thread 0x7fff86df66c0 (LWP 128811)]
[New Thread 0x7fff86bf56c0 (LWP 128812)]
[New Thread 0x7fff869f46c0 (LWP 128813)]
[New Thread 0x7fff867f36c0 (LWP 128814)]
[New Thread 0x7fff865f26c0 (LWP 128815)]
[New Thread 0x7fff863f16c0 (LWP 128816)]
[New Thread 0x7fff861f06c0 (LWP 128817)]
[New Thread 0x7fff85fef6c0 (LWP 128818)]
[New Thread 0x7fff85dee6c0 (LWP 128819)]
[New Thread 0x7fff85bed6c0 (LWP 128820)]
[New Thread 0x7fff859ec6c0 (LWP 128821)]
[New Thread 0x7fff857eb6c0 (LWP 128822)]
[New Thread 0x7fff855ea6c0 (LWP 128823)]
[New Thread 0x7fff853e96c0 (LWP 128824)]
[Thread 0x7fffec24f6c0 (LWP 128776) exited]
^C[Thread 0x7fffcdd896c0 (LWP 128789) exited]

Thread 1 "codeblocks" received signal SIGINT, Interrupt.
0x00007ffff471876d in syscall () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff471876d in syscall () from /usr/lib/libc.so.6
#1  0x00007ffff3cb0555 in ?? () from /usr/lib/libglycin-2.so.0
#2  0x00007ffff3bdf779 in gly_image_get_specific_frame () from /usr/lib/libglycin-2.so.0
#3  0x00007ffff705228c in ?? () from /usr/lib/libgdk_pixbuf-2.0.so.0
#4  0x00007ffff703a865 in gdk_pixbuf_new_from_file () from /usr/lib/libgdk_pixbuf-2.0.so.0
#5  0x00007ffff6361f35 in wxBitmap::LoadFile (this=0x7fffcd965f10 <(anonymous namespace)::Reg+432>, name=...,
    type=wxBITMAP_TYPE_PNG) at ../trunk/src/gtk/bitmap.cpp:1164
#6  0x00007fffcd732daf in wxsRegisterItem<wxsDataViewListCtrl>::wxsRegisterItem (
    this=0x7fffcd965d60 <(anonymous namespace)::Reg>, ClassNameWithoutWx=..., Type=wxsTWidget, Category=...,
    Priority=277, AllowInXRC=true)
    at ../../../../../../../trunk/src/plugins/contrib/wxSmith/wxwidgets/defitems/../wxsitemfactory.h:224
#7  0x00007fffcd7311a8 in __static_initialization_and_destruction_0 ()
    at ../../../../../../../trunk/src/plugins/contrib/wxSmith/wxwidgets/defitems/wxsdataviewlistctrl.cpp:23
#8  0x00007fffcd732a6b in _GLOBAL__sub_I_wxsdataviewlistctrl.cpp(void) ()
    at ../../../../../../../trunk/src/plugins/contrib/wxSmith/wxwidgets/defitems/wxsdataviewlistctrl.cpp:143
#9  0x00007ffff7fc82a7 in ?? () from /lib64/ld-linux-x86-64.so.2
#10 0x00007ffff7fc837d in ?? () from /lib64/ld-linux-x86-64.so.2
#11 0x00007ffff7fc44f5 in _dl_catch_exception () from /lib64/ld-linux-x86-64.so.2
#12 0x00007ffff7fcf2a9 in ?? () from /lib64/ld-linux-x86-64.so.2
#13 0x00007ffff7fc4456 in _dl_catch_exception () from /lib64/ld-linux-x86-64.so.2
#14 0x00007ffff7fcf75a in ?? () from /lib64/ld-linux-x86-64.so.2
#15 0x00007ffff4692d04 in ?? () from /usr/lib/libc.so.6
#16 0x00007ffff7fc4456 in _dl_catch_exception () from /lib64/ld-linux-x86-64.so.2
#17 0x00007ffff7fc45a9 in ?? () from /lib64/ld-linux-x86-64.so.2
#18 0x00007ffff46927f3 in ?? () from /usr/lib/libc.so.6
#19 0x00007ffff4692dbb in dlopen () from /usr/lib/libc.so.6
#20 0x00007ffff5de6cbb in wxDynamicLibrary::RawLoad (libname=..., flags=2) at ../trunk/src/unix/dlunix.cpp:84
#21 0x00007ffff5cef07c in wxDynamicLibrary::Load (this=0x555556a5cb90, libnameOrig=..., flags=2)
    at ../trunk/src/common/dynlib.cpp:77
#22 0x00007ffff78858d9 in LibLoader::LoadLibrary (filename=...) at ../../../trunk/src/sdk/pluginmanager.cpp:121
#23 0x00007ffff7881c7e in PluginManager::LoadPlugin (this=0x5555568ee2e0, pluginName=...)
    at ../../../trunk/src/sdk/pluginmanager.cpp:1104
#24 0x00007ffff78818c3 in PluginManager::ScanForPlugins (this=0x5555568ee2e0, path=...)
    at ../../../trunk/src/sdk/pluginmanager.cpp:1067
#25 0x00005555556e9e4d in MainFrame::ScanForPlugins (this=0x5555560c4b10) at ../../../trunk/src/src/main.cpp:1501
#26 0x00005555556e25af in MainFrame::MainFrame (this=0x5555560c4b10, parent=0x0) at ../../../trunk/src/src/main.cpp:794
#27 0x000055555564d747 in CodeBlocksApp::InitFrame (this=0x55555591b6e0) at ../../../trunk/src/src/app.cpp:523
#28 0x000055555564f0e8 in CodeBlocksApp::OnInit (this=0x55555591b6e0) at ../../../trunk/src/src/app.cpp:754
#29 0x0000555555657b37 in wxAppConsoleBase::CallOnInit (this=0x55555591b6e0) at /opt/wx/include/wx-3.3/wx/app.h:92
#30 0x00007ffff5d3ec41 in operator() (__closure=0x7fffffffde08) at ../trunk/src/common/init.cpp:560
#31 0x00007ffff5d3efe4 in wxSafeCall<int, wxEntry(int&, wxChar**)::<lambda()>, wxEntry(int&, wxChar**)::<lambda()> >(const struct {...} &, const struct {...} &) (func=..., handler=...) at ../trunk/include/wx/private/safecall.h:40
#32 0x00007ffff5d3ee12 in wxEntry (argc=@0x7ffff5f1cdc0: 2, argv=0x55555591b5c0) at ../trunk/src/common/init.cpp:557
#33 0x00007ffff5d3eeb5 in wxEntry (argc=@0x7fffffffde9c: 2, argv=0x7fffffffdfc8) at ../trunk/src/common/init.cpp:590
#34 0x000055555564cf49 in main (argc=2, argv=0x7fffffffdfc8) at ../../../trunk/src/src/app.cpp:334
(gdb)

One line in the stracktrace suggested, a library libglycin might be involved:

Code
#1  0x00007ffff3cb0555 in ?? () from /usr/lib/libglycin-2.so.0

It looks updated a few days ago.

Code
$ ll /usr/lib/libglycin-*
lrwxrwxrwx 1 root root      16 16. Sep 02:35 /usr/lib/libglycin-1.so -> libglycin-1.so.0
-rwxr-xr-x 1 root root 2524600 16. Sep 02:35 /usr/lib/libglycin-1.so.0
lrwxrwxrwx 1 root root      16 23. Sep 02:23 /usr/lib/libglycin-2.so -> libglycin-2.so.0
-rwxr-xr-x 1 root root 4315200 23. Sep 02:23 /usr/lib/libglycin-2.so.0

The lecacy version I installed after these hangs on cb started. Ootb it did not resolve the problem because it is not selected automatically.

Code
$ ldd /usr/local/bin/codeblocks |grep glycin
libglycin-2.so.0 => /usr/lib/libglycin-2.so.0 (0x00007f4aa6400000)

Code
$ LANG=C pacman -Ss glycin
extra/glycin 2.0.0-4 [installed]
    Sandboxed and extendable image decoding
extra/glycin-gtk4 2.0.0-4
    Sandboxed and extendable image decoding - GTK4 integration
extra/glycin1 1.2.4-2 [installed]
    Sandboxed and extendable image decoding (legacy version)
extra/glycin1-gtk4 1.2.4-2
    Sandboxed and extendable image decoding (legacy version) - GTK4 integration

Btw: Some gnome packages have been updated to 49 as well a few days ago, using more gtk4.

I have not yet figured out how to use the legacy version.

Any help appreciated.
« Last Edit: September 25, 2025, 06:38:11 am by blauzahn »

Offline ChrisK

  • Single posting newcomer
  • *
  • Posts: 3
Re: code::blocks hangs at startup
« Reply #2 on: September 25, 2025, 06:51:48 am »
Good research, thank you.

I tried hacking in the old library but it didn't help.

FYI...

Code
$ cd /usr/lib/
$ sudo mv libglycin-2.so.0 libglycin-2.so.0.bak
$ sudo ln -s libglycin-1.so.0 libglycin-2.so.0
$ ls -l libglycin*
lrwxrwxrwx 1 root root      16 Sep 16 08:35 libglycin-1.so -> libglycin-1.so.0
-rwxr-xr-x 1 root root 2524600 Sep 16 08:35 libglycin-1.so.0
lrwxrwxrwx 1 root root      16 Sep 25 12:46 libglycin-2.so -> libglycin-2.so.0
lrwxrwxrwx 1 root root      16 Sep 25 12:47 libglycin-2.so.0 -> libglycin-1.so.0
-rwxr-xr-x 1 root root 4315200 Sep 23 08:23 libglycin-2.so.0.bak

Got me...

Code
$ codeblocks 
codeblocks: symbol lookup error: /usr/lib/libgdk_pixbuf-2.0.so.0: undefined symbol: gly_creator_add_metadata_key_value

I don't know if it helps, but when it's hung, "ps ax" shows this, involving bubblewrap & glycin:

Code
   7029 pts/2    Sl+    0:00 codeblocks
   7046 pts/2    S+     0:00 bwrap --unshare-all --die-with-parent --chdir / --ro-bind /usr /usr --dev /dev --ro-bind-try /etc/ld.so.cache /etc/l
   7049 pts/2    S+     0:00 bwrap --unshare-all --die-with-parent --chdir / --ro-bind /usr /usr --dev /dev --ro-bind-try /etc/ld.so.cache /etc/l
   7050 pts/2    Sl+    0:00 /usr/lib/glycin-loaders/2+/glycin-svg --dbus-fd 22
« Last Edit: September 25, 2025, 07:03:01 am by ChrisK »

Offline blauzahn

  • Almost regular
  • **
  • Posts: 222
Re: code::blocks hangs at startup
« Reply #3 on: September 25, 2025, 07:09:46 am »
Changing the link is definitely bad.

Instead, I searched for a cmake option to allow to compile cb including the legacy version. But I haven't seen any on first glimpse. I will try to look at it in the evening. Until now, I was not aware of bwrap. I have no knowledge about sandboxing.
« Last Edit: September 25, 2025, 07:11:49 am by blauzahn »

Offline ChrisK

  • Single posting newcomer
  • *
  • Posts: 3
Re: code::blocks hangs at startup
« Reply #4 on: September 25, 2025, 07:12:49 am »
Yeah, I know, but sometimes it can get you out of a fix.   ;)

Looking at the Arch Archive for "glycin", on 22 Sept https://archive.archlinux.org/repos/2025/09/22/extra/os/x86_64/ we have
Code
glycin-1.2.3-1-x86_64.pkg.tar.zst                  02-Aug-2025 01:40      3M
glycin-1.2.3-1-x86_64.pkg.tar.zst.sig              02-Aug-2025 01:40     119

But on 23 Sept (https://archive.archlinux.org/repos/2025/09/23/extra/os/x86_64/) we have
Code
glycin-2.0.0-4-x86_64.pkg.tar.zst                  23-Sep-2025 00:56      4M
glycin-2.0.0-4-x86_64.pkg.tar.zst.sig              23-Sep-2025 00:56     119
glycin-gtk4-2.0.0-4-x86_64.pkg.tar.zst             23-Sep-2025 00:56    135K
glycin-gtk4-2.0.0-4-x86_64.pkg.tar.zst.sig         23-Sep-2025 00:56     119
glycin1-1.2.4-2-x86_64.pkg.tar.zst                 16-Sep-2025 00:46      2M
glycin1-1.2.4-2-x86_64.pkg.tar.zst.sig             16-Sep-2025 00:46     119
glycin1-gtk4-1.2.4-2-x86_64.pkg.tar.zst            16-Sep-2025 00:46    135K
glycin1-gtk4-1.2.4-2-x86_64.pkg.tar.zst.sig        16-Sep-2025 00:46     119

I guess it's related to that.

Offline blauzahn

  • Almost regular
  • **
  • Posts: 222
Re: code::blocks hangs at startup
« Reply #5 on: September 25, 2025, 07:18:50 am »
Both glycin libraries themselves do not link (dynamically) to any library whose name includes wrap:

Code
$ ldd /usr/lib/libglycin-*.so |grep wrap
$

Offline Lufex

  • Single posting newcomer
  • *
  • Posts: 2
Re: code::blocks hangs at startup
« Reply #6 on: September 25, 2025, 11:45:02 am »
Same problem here, Arch KDE Plasma.

Not sure if this helps but I got around the start up freeze by turning off (removing) all the wxsmith.zips from /usr/share/codeblocks/


Hope this helps at least narrowing down the issue.
« Last Edit: September 25, 2025, 11:53:32 am by Lufex »

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1822
Re: code::blocks hangs at startup
« Reply #7 on: September 25, 2025, 12:05:48 pm »
wxSmith is the only plugin still using PNG, every other plugins are now using SVG. Maybe glycin has problems loading these PNG, but booting in safe mode should work.

Offline blauzahn

  • Almost regular
  • **
  • Posts: 222
Re: code::blocks hangs at startup
« Reply #8 on: September 25, 2025, 01:05:59 pm »
I might have skipped all wxSmith stuff in cmake with
Code
-with-contrib-plugins=all,-wxsmith,-wxsmithaui,-wxsmithcontrib ...

Will check this evening. Deleting the corresponding zip-files is a quick way. 

--safe-mode unfortunately does not work as I stated before.

Thanks for your answers.

Offline blauzahn

  • Almost regular
  • **
  • Posts: 222
Re: code::blocks hangs at startup (solved for now)
« Reply #9 on: September 25, 2025, 07:57:24 pm »
cb works again when the zip-files of the three wxsmith plugins are deleted. Alternatively, disabling them when calling configure (not cmake) works as well as expected.

Obviously, wxSmith can not be used in that case.

Thanks again for the help.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7815
    • My Best Post
Re: code::blocks hangs at startup
« Reply #10 on: September 25, 2025, 10:31:39 pm »
wxSmith is the only plugin still using PNG, every other plugins are now using SVG. Maybe glycin has problems loading these PNG, but booting in safe mode should work.

Thank you for that info; I have been having issues building/runtime with wxWidgets 3.3.x and the wxSmith plugin under MSys2 MINGW64 and now I have a possible cause to look into. wxWidgets 3.2.8 was working okay.
Edit: The issue is only seen when three things is true: wxWidgets 3.3.x, MINGW64, and wxSmith plugin is built; UCRT64 and MINGW32 do not have the problem for example. I can now see if an wxWidgets sample has the problem that uses PNG images.

Tim S.
« Last Edit: September 25, 2025, 10:41:47 pm by stahta01 »
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6147
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: code::blocks hangs at startup
« Reply #11 on: September 26, 2025, 09:18:34 am »
I don't see the hang issue when I build the C::B under the msys2/mingw64, but I see a crash when C::B load a wxWidgets project, and after I try to open a wxs wxsmith file.

See the call stack here:

Code
[debug]> frame 4
[debug]#4  0x00007ff8ad97d270 in wxPGProperty::GetValueAsString (this=0x11daa950, flags=0) at F:\code\wxWidgets-3.3.1\include\wx\propgrid\property.h:1427
[debug]F:\code\wxWidgets-3.3.1\include\wx\propgrid\property.h:1427:53089:beg:0x7ff8ad97d270
[debug]>>>>>>cb_gdb:

#4  0x00007ff8ad97d270 in wxPGProperty::GetValueAsString (this=0x11daa950, flags=0) at F:\code\wxWidgets-3.3.1\include\wx\propgrid\property.h:1427
F:\code\wxWidgets-3.3.1\include\wx\propgrid\property.h:1427:53089:beg:0x7ff8ad97d270
At F:\code\wxWidgets-3.3.1\include\wx\propgrid\property.h:1427

[debug]> show language
[debug]The current source language is "auto; currently c++".
[debug]>>>>>>cb_gdb:
[debug]> bt 30
[debug]#0  0x00007ff8d4ca71b1 in wxDefaultAssertHandler(wxString const&, int, wxString const&, wxString const&, wxString const&) () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#1  0x00007ff8d4ca49ec in wxOnAssert(char const*, int, char const*, char const*, wxString const&) () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#2  0x00007ff8d534b68e in wxPGProperty::ValueToStringWithCheck(wxVariant&, wxPGPropValFormatFlags) const () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#3  0x00007ff8d534f73e in wxPGProperty::GetValueAsString(wxPGPropValFormatFlags) const () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#4  0x00007ff8ad97d270 in wxPGProperty::GetValueAsString (this=0x11daa950, flags=0) at F:\code\wxWidgets-3.3.1\include\wx\propgrid\property.h:1427
[debug]#5  0x00007ff8d534c06e in wxPGProperty::GetValueAsStringWithCheck(wxPGPropValFormatFlags) const () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#6  0x00007ff8d53521ca in wxPGProperty::GetDisplayInfo(unsigned int, int, int, wxString*, wxPGCell*) () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#7  0x00007ff8d53545b2 in wxPGDefaultRenderer::Render(wxDC&, wxRect const&, wxPropertyGrid const*, wxPGProperty*, int, int, int) const () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#8  0x00007ff8d535de13 in wxPropertyGrid::DoDrawItems(wxDC&, wxRect const*) const () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#9  0x00007ff8d535efae in wxPropertyGrid::DrawItems(wxDC&, unsigned int, unsigned int, wxRect const*) () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#10 0x00007ff8d536bf78 in wxPropertyGrid::OnPaint(wxPaintEvent&) () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#11 0x00007ff8d4ca3467 in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#12 0x00007ff8d4deff55 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#13 0x00007ff8d4df28b3 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#14 0x00007ff8d4df2916 in wxEvtHandler::TryHereOnly(wxEvent&) () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#15 0x00007ff8d4df2983 in wxEvtHandler::ProcessEventLocally(wxEvent&) () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#16 0x00007ff8d4df2a61 in wxEvtHandler::ProcessEvent(wxEvent&) () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#17 0x00007ff8d512453f in wxScrollHelperEvtHandler::ProcessEvent(wxEvent&) () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#18 0x00007ff8d4df0262 in wxEvtHandler::SafelyProcessEvent(wxEvent&) () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#19 0x00007ff8d4ed7dbb in wxWindow::HandlePaint() () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#20 0x00007ff8d4eda158 in wxWindow::MSWHandleMessage(long long*, unsigned int, unsigned long long, long long) () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#21 0x00007ff8d4ec573c in wxWindow::MSWWindowProc(unsigned int, unsigned long long, long long) () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#22 0x00007ff8d58f03ac in wxScrolled<wxControl>::MSWWindowProc(unsigned int, unsigned long long, long long) () from F:\code\wxWidgets-3.3.1\lib\gcc_dll\wxmsw331u_gcc_custom.dll
[debug]#23 0x00007ff963c1ef5c in USER32!CallWindowProcW () from C:\WINDOWS\System32\user32.dll
[debug]#24 0x00007ff963c1e8cc in USER32!DispatchMessageW () from C:\WINDOWS\System32\user32.dll
[debug]#25 0x00007ff963c310c3 in USER32!SendMessageTimeoutW () from C:\WINDOWS\System32\user32.dll
[debug]#26 0x00007ff9657f1374 in ntdll!KiUserCallbackDispatcher () from C:\WINDOWS\SYSTEM32\ntdll.dll
[debug]#27 0x00007ff9634a2be4 in win32u!NtUserRealInternalGetMessage () from C:\WINDOWS\System32\win32u.dll
[debug]#28 0x00007ff934b9d559 in GetMessageExA () from C:\WINDOWS\SYSTEM32\duser.dll
[debug]#29 0x00007ff934b9d348 in GetMessageExA () from C:\WINDOWS\SYSTEM32\duser.dll
[debug](More stack frames follow...)

Strange that it does not contains function calls from C::B's source code, maybe, "More stack frames follow...)


EDIT:

In the crash, I see that:

Code
    virtual wxString GetValueAsString(int flags) const
    {
        m_oldGetValueAsString = true;
        return GetValueAsString(static_cast<wxPGPropValFormatFlags>(flags));
    }

the flags is 0.
« Last Edit: September 26, 2025, 01:29:46 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline blauzahn

  • Almost regular
  • **
  • Posts: 222
Re: code::blocks hangs at startup
« Reply #12 on: September 27, 2025, 11:20:51 pm »
When analyzing cb trunk with scan-build the list of issues contains several with wxSmith, e.g. "Dereference of null pointer".


https://clang.llvm.org/docs/analyzer/user-docs/CommandLineUsage.html


Btw: Today, glycin got two updates on Arch Linux. Starting cb with wxSmith zip-files installed still hangs.

Offline cet_ivan

  • Single posting newcomer
  • *
  • Posts: 1
Re: code::blocks hangs at startup
« Reply #13 on: September 28, 2025, 11:02:14 pm »
I encountered the same problem yesterday, on Arch with most packages up to date, but with an old version of KDE.

My current workaround is to install gdk-pixbuf2 version 2.42.12-2, instead of the latest version, 2.44.2-1. The latest version introduced glycin as a dependency.

Since glycin performs some kind of sandboxing for image loading/decoding and that involves starting additional processes and interprocess communication, there seems to be a bug with IPC which causes the hang.

This is not a permanent solution and I am not sure whether this can cause problems for other applications using gdk-pixbuf2, but the two versions seem binary compatible, and so far all the apps which require gdk-pixbuf2 seem to work properly. Another way might be to rebuild the latest gdk-pixbuf2 without glycin as its dependency (i.e. create a custom PKGBUILD), but I haven't tried that.

Offline JorgenBest

  • Single posting newcomer
  • *
  • Posts: 4
Re: code::blocks hangs at startup
« Reply #14 on: October 02, 2025, 07:51:35 am »
on 30/9/25 gdk-pixbuf2 upgraded in Arch Linux to 2.44.3-1, but CodeBlocks still hangs on wxSmith plugin
« Last Edit: October 02, 2025, 10:42:12 am by JorgenBest »

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5547
Re: code::blocks hangs at startup
« Reply #15 on: January 21, 2026, 09:58:26 am »
2 days ago, since a very long time, I did a fresh build of CB on linux, in Tumbleweed.
Build goes fine, but launching fails. With a similar problem as mentioned above, and the 'renaming' the 3 wxSmith zip files.
Probably when starting a build by excluding these plug-in(s) things would have been ok too.

Code
sudo mv /usr/local/share/codeblocks/wxSmithAui.zip /usr/local/share/codeblocks/wxSmithAui.old
sudo mv /usr/local/share/codeblocks/wxsmithcontribitems.zip /usr/local/share/codeblocks/wxsmithcontribitems.old
sudo mv /usr/local/share/codeblocks/wxsmith.zip /usr/local/share/codeblocks/wxsmith.old

Conclusion: this problem is not solved yet, did anyone in the meantime had a look at it ?



for reference, I stumbled also upon: https://bbs.archlinux.org/viewtopic.php?id=308575

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7815
    • My Best Post
Re: code::blocks hangs at startup
« Reply #16 on: January 21, 2026, 11:36:16 am »
2 days ago, since a very long time, I did a fresh build of CB on linux, in Tumbleweed.
Build goes fine, but launching fails. With a similar problem as mentioned above, and the 'renaming' the 3 wxSmith zip files.
Probably when starting a build by excluding these plug-in(s) things would have been ok too.

Code
sudo mv /usr/local/share/codeblocks/wxSmithAui.zip /usr/local/share/codeblocks/wxSmithAui.old
sudo mv /usr/local/share/codeblocks/wxsmithcontribitems.zip /usr/local/share/codeblocks/wxsmithcontribitems.old
sudo mv /usr/local/share/codeblocks/wxsmith.zip /usr/local/share/codeblocks/wxsmith.old

Conclusion: this problem is not solved yet, did anyone in the meantime had a look at it ?



for reference, I stumbled also upon: https://bbs.archlinux.org/viewtopic.php?id=308575

What wxWidget version is being used?
My wild guess is the png images; I checked one image file and if not wxCHECK_VERSION(3, 1, 6) then png images are used.
Edit: The single source file (wxsitemeditor.cpp) I checked was the only one that used the svg images if 3.1.6 or newer.

Tim S.
« Last Edit: January 21, 2026, 11:41:31 am by stahta01 »
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1822
Re: code::blocks hangs at startup
« Reply #17 on: January 21, 2026, 11:44:33 am »
Works OK on Ubuntu 22.04 with wxWidgets 3.2.6, I cannot check on other Linux. wxSmith uses some initialization tricks that may be non-portable.

This ticket reports that downgrading gdk-pixbuf2 from 2.44.2-1 to 2.42.12-2 fixes the problem.

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1822
Re: code::blocks hangs at startup
« Reply #18 on: January 21, 2026, 01:44:53 pm »
On 2.43 gdk-pixbuf deprecated the XPM api and disabled XPM loader by default, see release notes.

wxSmith defines a XPM in wxSmith.cpp:50 and uses it during plugin attachment in wxSmith.cpp:211; Probably changing this XPM to a PNG or SVG fixes the issue.

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1822
Re: code::blocks hangs at startup
« Reply #19 on: January 21, 2026, 03:48:13 pm »
Replaced XPM with PNG in OnAttach(), see r13773, this may fix the issue (untested).

There are more XPM bitmaps in other parts.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5547
Re: code::blocks hangs at startup
« Reply #20 on: January 21, 2026, 03:52:05 pm »
the wxwidgets I used is : 3.2.8

I updated with your latest commit, the problem is still there.

fyi: my gdk-pixbug version is 2.44.4
« Last Edit: January 21, 2026, 03:54:38 pm by killerbot »

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1822
Re: code::blocks hangs at startup
« Reply #21 on: January 21, 2026, 03:56:41 pm »
Can you put a breakpoint in OnAttach() and check where it hangs?

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7815
    • My Best Post
Re: code::blocks hangs at startup
« Reply #22 on: January 22, 2026, 12:28:16 am »
Patch for my wild guess at the cause, could be multiple causes since wxSmith was written for old wxWidgets version. Edit: My wild guess is that the png files are old enough to break something.

Deleted outdated patch code

Tim S.
« Last Edit: January 23, 2026, 03:37:11 pm by stahta01 »
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5547
Re: code::blocks hangs at startup
« Reply #23 on: January 22, 2026, 08:35:50 am »
I applied this, but no luck, problem still present.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5547
Re: code::blocks hangs at startup
« Reply #24 on: January 22, 2026, 03:12:34 pm »
#0  0x00007ffff4f1e80d in syscall () at /lib64/libc.so.6
#1  0x00007ffff4747e95 in std::sys::sync::condvar::futex::Condvar::wait () at /lib64/libglycin-2.so.0
#2  0x00007ffff46cb1bb in parking::Inner::park () at /lib64/libglycin-2.so.0
#3  0x00007ffff45fd656 in gly_loader_load () at /lib64/libglycin-2.so.0
#4  0x00007ffff712325e in ??? () at /lib64/libgdk_pixbuf-2.0.so.0
#5  0x00007ffff7123637 in ??? () at /lib64/libgdk_pixbuf-2.0.so.0
#6  0x00007ffff7113158 in gdk_pixbuf_new_from_file () at /lib64/libgdk_pixbuf-2.0.so.0
#7  0x00007ffff6b7d3b0 in wxBitmap::LoadFile(wxString const&, wxBitmapType) () at /lib64/libwx_gtk3u_core-suse-nostl.so.16.0.0
#8  0x00007fffc8ebe80f in wxsRegisterItem<wxsAnimationCtrl>::wxsRegisterItem(wxString, wxsItemType, wxString, long, bool) ()
    at /usr/local/lib/libwxsmithlib.so.0
#9  0x00007fffc8d6bacf in _GLOBAL__sub_I_wxsanimationctrl.cpp () at /usr/local/lib/libwxsmithlib.so.0


not sure if really usable, can not reproduce, ran in gdb, when it hang : ctrl-c and then bt.
but most of the other times I get something else ...
« Last Edit: January 22, 2026, 03:21:13 pm by killerbot »

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1822
Re: code::blocks hangs at startup
« Reply #25 on: January 22, 2026, 04:34:43 pm »
Quote
not sure if really usable

It is very helpful indeed.

IMHO the problem is wxSmith uses global objects to register items:
Code
namespace
{
    wxsRegisterItem<wxsAnimationCtrl> Reg(_T("AnimationCtrl"),wxsTWidget,_T("Standard"),370);

The constructor of wxsRegisterItem (in wxsitemfactory.h:200) calls wxBitmap::LoadFile(), but this call will happen before the image handlers have been initialized because global objects are constructed before program starts.

Code
            wxString DataPath = ConfigManager::GetDataFolder() + _T("/images/wxsmith/");
            Info.Icon32.LoadFile(DataPath+Info.ClassName+_T("32.png"),wxBITMAP_TYPE_PNG);
            Info.Icon16.LoadFile(DataPath+Info.ClassName+_T("16.png"),wxBITMAP_TYPE_PNG);

One possible solution would be delay loading the icons, i.e. load them the first time they are needed.

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1822
Re: code::blocks hangs at startup
« Reply #26 on: January 22, 2026, 07:20:23 pm »
I have just commited r13775 implementing delay-load of most images. This commit will make easier changing to SVG in the near future.

wxsresourcetree must still be modified before checking if C::B still hangs at startup.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5547
Re: code::blocks hangs at startup
« Reply #27 on: January 23, 2026, 07:57:18 am »
I will test later today

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1822
Re: code::blocks hangs at startup
« Reply #28 on: January 23, 2026, 08:23:17 am »
The change is not finished, wxsresourcetree must be modified.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5547
Re: code::blocks hangs at startup
« Reply #29 on: January 23, 2026, 08:36:39 am »
I reverted the patch that was posted here above yesterday,and used your latest commit.

CB now starts up for me without problems (or at least not directly visible to me ;-) )

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1822
Re: code::blocks hangs at startup
« Reply #30 on: January 23, 2026, 10:06:29 am »
Thanks for testing. If this works then I will leave wxsresourcetree as is, because the change would be complex.

Probably works because wxsresourcetree uses cbLoadBitmap(), which calls wxImage::LoadFile() instead of wxBitmap::LoadFile().

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5547
Re: code::blocks hangs at startup
« Reply #31 on: January 23, 2026, 05:49:17 pm »
@ChrisK , @blauzahn, @Lufex, @cet_ivan, @JorgenBest : would you be able to verify, if with the latest state of the code the problem is also gone on your side ?
« Last Edit: January 23, 2026, 05:52:06 pm by killerbot »

Offline JorgenBest

  • Single posting newcomer
  • *
  • Posts: 4
Re: code::blocks hangs at startup
« Reply #32 on: January 25, 2026, 10:20:07 am »
The 25-03-2 version that I have still has this problem, but that's the regular version and not a nightly build or so.

I have difficulties installing all kinds of sources. I think I need something that is not yet out and I'm not to trusted with finding the right sources, dependencies and compilation myself. I use Arch Linux as rolling release platform (version 25-03-2), but there are no updates that yet worked to solve this problem. Also on aur nothing is yet more recent available.

So you help me I gladly test something if I can install and reverse it easily on my system.

Offline blauzahn

  • Almost regular
  • **
  • Posts: 222
Re: code::blocks hangs at startup
« Reply #33 on: January 25, 2026, 11:02:50 am »
cb still hangs at startup on arch Linux, cb-trunk build with the distributed wx-3.2.9. In my Makefile, wxSmith plugins are disabled at configure:

Code
  (cd $(build) && \
  LT_SYS_LIBRARY_PATH=$(WX_PREFIX)/lib \
  CC=${CC} CXX=${CXX} ../$(trunk)/configure \
  --enable-debug=yes \
  --enable-pch=no \
  --prefix=$(PREFIX) \
  --with-wx-config=$(WX_PREFIX)/bin/wx-config --with-wx-prefix=$(WX_PREFIX) \
  --with-contrib-plugins=all,\
         -wxsmith,-wxsmithaui,-wxsmithcontrib,\
         -NassiShneiderman,-codesnippets,-dragscroll)

Console output at startup is:

Code
$ codeblocks
Starting Code::Blocks svn build  rev 13776 Jan 25 2026, 09:09:29 - wxWidgets 3.2.9 - gcc 15.2.1 (Linux, unicode) - 64 bit
Manager initialisiert
Initialize EditColourSet .....
Initialize EditColourSet: done.
Loading menubar...
/usr/src/debug/wxwidgets/wxWidgets/src/common/object.cpp(233):
assert "classTable->Get(m_className) == __null" failed in Register(): Class "wxAnyValueTypeGlobalsManager"
already in RTTI table - have you used wxIMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?


Please note the assert. I have seen this a few times over the years. I use an out of tree build. The installation directories of cb are pristine and without stale files. I verified this, recompiled, reinstalled but the assert remains.

Run in gdb, similar lines replaced with [...]:

Code
$ gdb /usr/local/bin/codeblocks
GNU gdb (GDB) 17.1
[...]
Reading symbols from /usr/local/bin/codeblocks...
(gdb) r
Starting program: /usr/local/bin/codeblocks
[...]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffefdff6c0 (LWP 143300)]
[...]
[New Thread 0x7fffed5fa6c0 (LWP 143305)]
Starting Code::Blocks svn build  rev 13776 Jan 25 2026, 09:09:29 - wxWidgets 3.2.9 - gcc 15.2.1 (Linux, unicode) - 64 bit
Manager initialisiert
Initialize EditColourSet .....
[New Thread 0x7fffd7fff6c0 (LWP 143705)]
[New Thread 0x7fffd77fe6c0 (LWP 143706)]
[New Thread 0x7fffd6ffd6c0 (LWP 143707)]
Initialize EditColourSet: done.
Loading menubar...
[New Thread 0x7fffd67fc6c0 (LWP 143906)]
[...]
[New Thread 0x7fffd4ff96c0 (LWP 143912)]
[Detaching after fork from child process 143913]
[New Thread 0x7fffd4df86c0 (LWP 143916)]
[Detaching after fork from child process 143917]
/usr/src/debug/wxwidgets/wxWidgets/src/common/object.cpp(233): assert "classTable->Get(m_className) == __null" failed in Register(): Class "wxAnyValueTypeGlobalsManager" already in RTTI table - have you used wxIMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)?
[New Thread 0x7fffd43ff6c0 (LWP 143923)]
[Thread 0x7fffd4ff96c0 (LWP 143912) exited]
^C
Thread 1 "codeblocks" received signal SIGINT, Interrupt.
0x00007ffff4d1876d in syscall () from /usr/lib/libc.so.6

cb hangs here; Ctrl-C pressed yields this backtrace:

Code

(gdb) bt
#0  0x00007ffff4d1876d in syscall () from /usr/lib/libc.so.6
#1  0x00007ffff4230905 in ?? () from /usr/lib/libglycin-2.so.0
#2  0x00007ffff416532e in gly_loader_load () from /usr/lib/libglycin-2.so.0
#3  0x00007ffff647a704 in ?? () from /usr/lib/libgdk_pixbuf-2.0.so.0
#4  0x00007ffff647ac62 in ?? () from /usr/lib/libgdk_pixbuf-2.0.so.0
#5  0x00007ffff6464e32 in gdk_pixbuf_loader_close () from /usr/lib/libgdk_pixbuf-2.0.so.0
#6  0x00007ffff5f04014 in ?? () from /usr/lib/libgtk-3.so.0
[...]
#21 0x00007ffff5f009b5 in ?? () from /usr/lib/libgtk-3.so.0
#22 0x00007ffff612197c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#23 0x00007ffff6140bf3 in ?? () from /usr/lib/libgobject-2.0.so.0
#24 0x00007ffff6142b0f in ?? () from /usr/lib/libgobject-2.0.so.0
#25 0x00007ffff6142d89 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#26 0x00007ffff6142e44 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#27 0x00007ffff5eddde2 in gtk_widget_show () from /usr/lib/libgtk-3.so.0
#28 0x00007ffff5cc4089 in gtk_dialog_run () from /usr/lib/libgtk-3.so.0
#29 0x00007ffff6b40935 in wxGUIAppTraits::ShowAssertDialog(wxString const&) () from /usr/lib/libwx_gtk3u_core-3.2.so.0
#30 0x00007ffff6282382 in ?? () from /usr/lib/libwx_baseu-3.2.so.0
#31 0x00007ffff6282589 in wxAppConsoleBase::OnAssertFailure(wchar_t const*, int, wchar_t const*, wchar_t const*, wchar_t const*) ()
   from /usr/lib/libwx_baseu-3.2.so.0
#32 0x00007ffff6b0448d in wxApp::OnAssertFailure(wchar_t const*, int, wchar_t const*, wchar_t const*, wchar_t const*) ()
   from /usr/lib/libwx_gtk3u_core-3.2.so.0
#33 0x00007ffff62827a2 in ?? () from /usr/lib/libwx_baseu-3.2.so.0
#34 0x00007ffff627ca5e in wxOnAssert(char const*, int, char const*, char const*, wxString const&) () from /usr/lib/libwx_baseu-3.2.so.0
#35 0x00007ffff6300c0d in wxClassInfo::Register() () from /usr/lib/libwx_baseu-3.2.so.0
#36 0x00007fffd449bb33 in wxClassInfo::wxClassInfo (this=0x7fffd4721ec0 <wxAnyValueTypeGlobalsManager::ms_classInfo>,
    className=0x7fffd463d368 L"wxAnyValueTypeGlobalsManager", baseInfo1=0x7ffff6441860 <wxModule::ms_classInfo>, baseInfo2=0x0, size=72,
    ctor=0x7fffd449a3e2 <wxAnyValueTypeGlobalsManager::wxCreateObject()>) at ../trunk/include/wx/rtti.h:87
#37 0x00007fffd449ae7a in __static_initialization_and_destruction_0 () at ../trunk/src/common/any.cpp:226
#38 0x00007fffd449b2d8 in _GLOBAL__sub_I_any.cpp(void) () at ../trunk/src/common/any.cpp:499
#39 0x00007ffff7fc82a7 in ?? () from /lib64/ld-linux-x86-64.so.2
#40 0x00007ffff7fc837d in ?? () from /lib64/ld-linux-x86-64.so.2
#41 0x00007ffff7fc44f5 in _dl_catch_exception () from /lib64/ld-linux-x86-64.so.2
#42 0x00007ffff7fcf2a9 in ?? () from /lib64/ld-linux-x86-64.so.2
#43 0x00007ffff7fc4456 in _dl_catch_exception () from /lib64/ld-linux-x86-64.so.2
#44 0x00007ffff7fcf75a in ?? () from /lib64/ld-linux-x86-64.so.2
#45 0x00007ffff4c92cc4 in ?? () from /usr/lib/libc.so.6
#46 0x00007ffff7fc4456 in _dl_catch_exception () from /lib64/ld-linux-x86-64.so.2
#47 0x00007ffff7fc45a9 in ?? () from /lib64/ld-linux-x86-64.so.2
#48 0x00007ffff4c927b3 in ?? () from /usr/lib/libc.so.6
--Type <RET> for more, q to quit, c to continue without paging--
#49 0x00007ffff4c92d7b in dlopen () from /usr/lib/libc.so.6
#50 0x00007ffff6372388 in wxDynamicLibrary::RawLoad(wxString const&, int) () from /usr/lib/libwx_baseu-3.2.so.0
#51 0x00007ffff62a6c4c in wxDynamicLibrary::Load(wxString const&, int) () from /usr/lib/libwx_baseu-3.2.so.0
#52 0x00007ffff7a0e381 in LibLoader::LoadLibrary (filename=...) at ../../../trunk/src/sdk/pluginmanager.cpp:121
#53 0x00007ffff7a0a216 in PluginManager::LoadPlugin (this=0x55555692ece0, pluginName=...) at ../../../trunk/src/sdk/pluginmanager.cpp:1104
#54 0x00007ffff7a09c53 in PluginManager::ScanForPlugins (this=0x55555692ece0, path=...) at ../../../trunk/src/sdk/pluginmanager.cpp:1067
#55 0x00005555556d3423 in MainFrame::ScanForPlugins (this=0x5555560feed0) at ../../../trunk/src/src/main.cpp:1496
#56 0x00005555556caef3 in MainFrame::MainFrame (this=0x5555560feed0, parent=0x0) at ../../../trunk/src/src/main.cpp:794
#57 0x0000555555639fb3 in CodeBlocksApp::InitFrame (this=0x555555909dd0) at ../../../trunk/src/src/app.cpp:554
#58 0x000055555563ba4d in CodeBlocksApp::OnInit (this=0x555555909dd0) at ../../../trunk/src/src/app.cpp:785
#59 0x00005555556454e7 in wxAppConsoleBase::CallOnInit (this=0x555555909dd0) at /usr/include/wx-3.2/wx/app.h:93
#60 0x00007ffff62ec1b2 in wxEntry(int&, wchar_t**) () from /usr/lib/libwx_baseu-3.2.so.0
#61 0x00005555556397b6 in main (argc=1, argv=0x7fffffffdf88) at ../../../trunk/src/src/app.cpp:365
(gdb)

As before, libglycin-2 seems to be involved.

When I build and install curren wx trunk locally in /opt/wx trunk cb fails to compile:

Code
make[5]: Entering directory 'src/sdk/scripting/bindings'
depbase=`echo sc_wxtypes.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../../../libtool  --tag=CXX   --mode=compile g++ -std=c++11 -DHAVE_CONFIG_H -I. -I../../../../../trunk/src/sdk/scripting/bindings -I../../../../src/include  -I/opt/wx/lib/wx/include/gtk3-unicode-3.3 -I/opt/wx/include/wx-3.3 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I../../../../../trunk/src/include/scripting/include -I../../../../../trunk/src/include -I../../../../../trunk/src/sdk/wxscintilla/include  -DCB_AUTOCONF -DDEBUG -DcbDEBUG  -DPIC -I../../../../../trunk/src/include/tinyxml -DTIXML_USE_STL=YES  -g  -fPIC -fexceptions -MT sc_wxtypes.lo -MD -MP -MF $depbase.Tpo -c -o sc_wxtypes.lo ../../../../../trunk/src/sdk/scripting/bindings/sc_wxtypes.cpp &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  g++ -std=c++11 -DHAVE_CONFIG_H -I. -I../../../../../trunk/src/sdk/scripting/bindings -I../../../../src/include -I/opt/wx/lib/wx/include/gtk3-unicode-3.3 -I/opt/wx/include/wx-3.3 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I../../../../../trunk/src/include/scripting/include -I../../../../../trunk/src/include -I../../../../../trunk/src/sdk/wxscintilla/include -DCB_AUTOCONF -DDEBUG -DcbDEBUG -DPIC -I../../../../../trunk/src/include/tinyxml -DTIXML_USE_STL=YES -g -fPIC -fexceptions -MT sc_wxtypes.lo -MD -MP -MF .deps/sc_wxtypes.Tpo -c ../../../../../trunk/src/sdk/scripting/bindings/sc_wxtypes.cpp  -fPIC -DPIC -o .libs/sc_wxtypes.o
../../../../../trunk/src/sdk/scripting/bindings/sc_wxtypes.cpp: In function 'void ScriptBindings::Register_wxTypes(HSQUIRRELVM)':
../../../../../trunk/src/sdk/scripting/bindings/sc_wxtypes.cpp:1078:19: error: no matches converting function 'NoParamGetterInt' to type 'SQFUNCTION' {aka 'long long int (*)(struct SQVM*)'}
 1078 |         BindMethod(v, _SC("Blue"), NoParamGetterInt<wxColour::ChannelType, wxColour, &wxColour::Blue>, _SC("wxColour::Blue"));
      |         ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../../../../../trunk/src/sdk/scripting/bindings/sc_wxtypes.cpp:17:
../../../../../trunk/src/include/scripting/bindings/sc_utils.h:992:11: note: candidate is: 'template<class ReturnType, class ClassType, ReturnType (ClassType::* func)() const> SQInteger ScriptBindings::NoParamGetterInt(HSQUIRRELVM)'
  992 | SQInteger NoParamGetterInt(HSQUIRRELVM v)
      |           ^~~~~~~~~~~~~~~~
../../../../../trunk/src/sdk/scripting/bindings/sc_wxtypes.cpp:1079:19: error: no matches converting function 'NoParamGetterInt' to type 'SQFUNCTION' {aka 'long long int (*)(struct SQVM*)'}
 1079 |         BindMethod(v, _SC("Green"), NoParamGetterInt<wxColour::ChannelType, wxColour, &wxColour::Green>, _SC("wxColour::Green"));
      |         ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../../trunk/src/include/scripting/bindings/sc_utils.h:992:11: note: candidate is: 'template<class ReturnType, class ClassType, ReturnType (ClassType::* func)() const> SQInteger ScriptBindings::NoParamGetterInt(HSQUIRRELVM)'
  992 | SQInteger NoParamGetterInt(HSQUIRRELVM v)
      |           ^~~~~~~~~~~~~~~~
../../../../../trunk/src/sdk/scripting/bindings/sc_wxtypes.cpp:1080:19: error: no matches converting function 'NoParamGetterInt' to type 'SQFUNCTION' {aka 'long long int (*)(struct SQVM*)'}
 1080 |         BindMethod(v, _SC("Red"), NoParamGetterInt<wxColour::ChannelType, wxColour, &wxColour::Red>, _SC("wxColour::Red"));
      |         ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../../trunk/src/include/scripting/bindings/sc_utils.h:992:11: note: candidate is: 'template<class ReturnType, class ClassType, ReturnType (ClassType::* func)() const> SQInteger ScriptBindings::NoParamGetterInt(HSQUIRRELVM)'
  992 | SQInteger NoParamGetterInt(HSQUIRRELVM v)
      |           ^~~~~~~~~~~~~~~~
../../../../../trunk/src/sdk/scripting/bindings/sc_wxtypes.cpp:1081:19: error: no matches converting function 'NoParamGetterInt' to type 'SQFUNCTION' {aka 'long long int (*)(struct SQVM*)'}
 1081 |         BindMethod(v, _SC("Alpha"), NoParamGetterInt<wxColour::ChannelType, wxColour, &wxColour::Alpha>, _SC("wxColour::Alpha"));
      |         ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../../trunk/src/include/scripting/bindings/sc_utils.h:992:11: note: candidate is: 'template<class ReturnType, class ClassType, ReturnType (ClassType::* func)() const> SQInteger ScriptBindings::NoParamGetterInt(HSQUIRRELVM)'
  992 | SQInteger NoParamGetterInt(HSQUIRRELVM v)
      |           ^~~~~~~~~~~~~~~~
make[5]: *** [Makefile:534: sc_wxtypes.lo] Error 1

I had this compile error since autum. Currently, I am able to compile and run cb with wx-trunk set back to this commit:

Code
Autor: Eran Ifrah <eran@codelite.org>  2025-10-29 19:13:14
Eintragender: Vadim Zeitlin <vadim@wxwidgets.org>  2025-11-01 16:06:17
Eltern: 4bf58e23b69480166b34d326ce06385e6c97f916 (Fix a small typo in wxStyledTextCtrlMiniMap comment)

My wxWidgets has been configured for years this way:

Code
  mkdir -p $(BUILD)
  (cd $(BUILD) && ../$(TRUNK)/configure --prefix=$(WX_PREFIX) --with-cxx=17 --with-gtk --without-libtiff --enable-debug)

Please note: wx installed in /opt/wx requires ld to find it when linking cb:

Code
echo $(WX_PREFIX)/lib >/etc/ld.so.conf.d/wxwidgets.conf

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7815
    • My Best Post
Re: code::blocks hangs at startup
« Reply #34 on: January 26, 2026, 02:05:38 am »
I get the build error in sc_wxtypes.cpp when building with a 2 days old wxWidgets git master; I gave up using wxWidgets git master it will need a better wxWidgets and C::B programmer to fix. My Build system was Windows 11 MSys2 UCRT64 using configure/make.

Tim S.
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org