I've already reported this as a "bug" at https://sourceforge.net/p/codeblocks/tickets/775/ but since so far no-one else seems to be able to reproduce the problem, and since it doesn't seem especially consistent for me either, I think it makes sense to try to slog this one out on the forums rather than in a SF ticket.
I'm trying to build C::B from svn on my Arch Linux machine using the various -unix workspaces provided. I (now) have no issues using the bootstrap+configure+make approach, which I can use (in conjunction with a PKGBUILD) to make an installable package, but I also want to generate some "portable"-style builds as seems to be the intended output from these workspaces.
Essentially, as far as I'm concerned, I'm doing nothing exotic, and am following the instructions each time from a completely clean C::B profile, and yet my resulting binaries by this approach (regardless of which wx version I choose) all suffer from the same issue.
How I built C::B
- install vanilla codeblocks stable (17.12) from my package manager
- download codeblocks fresh from svn
- open one of the -unix .workspace files from the /src subfolder
- since it's a fresh C::B profile, set the "base" variable to something like "-Og -g" or "-O0 -g"
- (for the -wx30 option, change a reference from "hunspell-1.6" to "hunspell" to avoid a missing library linker error)
- right-click on the entire Workspace in the left panel and choose "Build Workspace"
- after a long time (>30 minutes), the build finishes with 0 errors - close C::B and run the "update" script (or "update30" if I chose the wx30 build)
How I produce the bug
- launch my freshly-build C::B via the "/devel/run.sh" script
- observe all images/icons in the application working fine (including in the About dialog)
- open a source file or a project/workspace
- observe that some icons (e.g. the breakpoint icons) don't render (e.g. when I set breakpoints by clicking to the side of the source lines)
- observe an Assertion Error dialog when trying to open the About page, and after clearing the chain of these error dialogs, mysteriously observe no splash image in the About dialog
- close any open source files
- observe no errors when opening the About dialog, and observe the splash image mysteriously reappearing
The error messages were something like this:
./src/gtk/bitmap.cpp(627): assert "image.IsOk()" failed in wxBitmap(): invalid image
./src/gtk/dcclient.cpp(1832): assert "IsOk()" failed in SetTextForeground(): invalid window dc
./src/common/image.cpp(1746): assert "IsOk()" failed in GetHeight(): invalid image
./src/common/image.cpp(1739): assert "IsOk()" failed in GetWidth(): invalid image
./src/gtk/bitmap.cpp(924): assert "IsOk()" failed in GetWidth(): invalid bitmap
./src/gtk/bitmap.cpp(917): assert "IsOk()" failed in GetHeight(): invalid bitmap
./src/gtk/dcclient.cpp(1088): assert "bitmap.IsOk()" failed in DoDrawBitmap(): invalid bitmap
./src/gtk/dcclient.cpp(1088): assert "bitmap.IsOk()" failed in DoDrawBitmap(): invalid bitmap
On advice from Obfuscated, I tried launching my C::B binary in gdb (by prepending "gdb" to the final line in run.sh), and setting a breakpoint for "cbLoadBitmap", from which I learned the following:
- images seem to get loaded in two "waves", one while first opening the application, and another while opening a source file (or project/workspace) - NOT while actually trying to view UI elements with images (e.g. the About dialog)
- it's after this second wave of calls to "cbLoadBitmap" that the issue manifests itself
- playing around with gdb it seems that C::B is repeatedly trying to access "breakpoint-" related PNG files from the "share/codeblocks/manager_resources.zip" archive - notice that those were some of the UI icons which don't render for me
I initially thought I'd devised a workaround based on clearing parts of the build space, but I am no longer able to reproduce this, so am still stuck with the issue. As mentioned, I don't get this issue when building via (bootstrap+)configure+make, so I'm inclined to believe that there's something flakey about the .cbp or .workspace files themselves, as opposed to it being an issue with my system configuration.
If anyone can suggest any further modes of enquiry, I'd really appreciate it. I'm at a bit of a loss, and given how long it takes each build, I'm starting to get driven a little bit mad by it.
Below is cbLoadBitmap() from sdk/globals.cpp:
wxBitmap cbLoadBitmap(const wxString& filename, wxBitmapType bitmapType)
{
// cache this, can't change while we 're running :)
static bool oldCommonControls = !UsesCommonControls6();
wxImage im;
wxFileSystem* fs = new wxFileSystem;
wxFSFile* f = fs->OpenFile(filename);
if (f)
{
wxInputStream* is = f->GetStream();
im.LoadFile(*is, bitmapType);
delete f;
}
delete fs;
if (oldCommonControls && im.HasAlpha())
im.ConvertAlphaToMask();
return wxBitmap(im);
}
When the bug happens, the call fs->OpenFile(filename) returns NULL. This means the empty wxImage im is passed as-is to wxBitmap(im). This triggers all those wxBitmap asserts.
There is something wrong with the way wxFileSystem::OpenFile() tries to resolve relative file paths. When I manually prepend my current working directory to filename, the call always succeeds. It's relative paths that behave oddly.
Again, there is no such problem when CB is build using configure / make.