Adam

Unfortunately, when repeating tests on ANOTHER clean build folder, I get the issue again. Again, building with cb17.12, with a totally blank profile, with the only change being setting "-Og -g" to the base variable. This time, no matter what I do, deleting any of the built files and rebuilding, anything, does not result in a working build. Same behaviour: images work fine until opening a file, then images don't work, but work again once closing a file. I'm not doing anything magical or esoteric so...

I have been having a similar issue on Linux when setting up "sakura" as the terminal emulator. Specifically, when cb_console_runner launches sakura, it's supposed to launch sakura in the correct project folder (or the manually-specified launch folder as appropriate). What actually happens is nondeterministic - about ~75% of the time things work fine, but ~25% of the time sakura ends up being launched in ~ (/home/$USER), and thus any programs which read/write files fail spectacularly. I can't reproduce...

Additional "Plugin Disable" crash with ThreadSearch

There is in fact another issue with ThreadSearch, essentially identical to this, but more consistently reproducible. I think obfuscated is looking at it already, though, so I suspect a new report probably isn't necessary. Specifically in ThreadSearchViewManagerMessagesNotebook::RemoveViewFromManager() (), which is called by OnRelease().

There is in fact another issue with ThreadSearch, essentially identical to this, but more consistently reproducible. I think obfuscated is looking at it already, though, so I suspect a new report probably isn't necessary.

After yet more testing, I have two more data points which suggest essentially that the issue is user error of some kind. I made a build using the wx30 unix .workspace which suffered from the issue, ran the update30 script, and tried debugging it with gdb by adding gdb into debug30/run.sh appropriately. After struggling for a while to work out how to see when cbLoadBitmap was being called and which filenames was trying to access, it turned out that these occur in "bursts" which don't exactly correspond...

After yet more testing, I have two more data points which suggest essentially that the issue is user error of some kind. I made a build using the wx30 unix .workspace which suffered from the issue, ran the update30 script, and tried debugging it with gdb by adding gdb into debug30/run.sh appropriately. After struggling for a while to work out how to see when cbLoadBitmap was being called and which filenames was trying to access, it turned out that these occur in "bursts" which don't exactly correspond...

I can confirm that I can build svn versions of codeblocks on my system via the PKGBUILD in the AUR, appending #revision=[revision] into the source array where appropriate, and furthermore can confirm that everything I build using that script does not experience this issue. So, the problem was me, somehow. This seems to demonstrate that there's some sort of issue with me building codeblocks via the workspace file, which doesn't occur when using the bootstrap+configure method (which for some reason...