Author Topic: code::blocks hangs at startup  (Read 4694 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: 209
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: 209
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: 209
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: 1766
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: 209
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: 209
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: 7806
    • 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: 6090
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: code::blocks hangs at startup
« Reply #11 on: Yesterday at 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: Yesterday at 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.