Building C::B on Arch Linux - assert "image.IsOk()" failed in wxBitmap()

[aphirst]

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:

Code

./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.

[BlueHazzard]

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

Does the images exist? Are the paths valid?

Have you tried to kill codeblocks if the Assert dialog pops up with gdb and then go the call stack upwards to see why the image is not valid? You can use codeblocks to debug codeblocks:
Open the Codeblocks workspace, and start the debugger with the red arrow. Then select the "src" target. Codeblocks will open, then you do your things until you get the assert dialog. Hit "Ok" in the assert dialog. The other codeblocks instance should come to front with a call stack in the Debugger->Debugging windows->Call stack (if not make one step with F7 or Debug->One line).
Now you can double click in the stack window to switch to the selected frame. Then you can inspect the variables (specially the img variable) that caused the assert. Check why it is not valid...

I somehow can not reproduce this on mint... Will have to set up arch to investigate this, but i have no time at the moment -.-'

[Huki]

I can confirm this bug when building codeblocks using the provided project file(s) on Arch Linux. The images do exist, all paths are valid, but they show up / disappear / reappear, with the same sequence of steps as described by the OP.

I worked around the bug by building codeblocks with 'configure / make / make install'. In this case it works fine (been using this custom build for a couple of months now).

[aphirst]

@Huki - Thanks for confirming! I'm not insane after all!

@BlueHazzard - I've not had as much time today for debugging as I'd hoped, but what I have been able to do is make a Google Drive folder with the following contents:

• trunk.tar.xz - the source tree I'm building, exactly as it is when I start
• built_pre_updatescript.tar.xz - the contents of "devel" and "output" when building against wx28, and "devel30" and "output30" BEFORE running the update/update30 scripts
• built_post_updatescript.tar.xz - the contents of "devel" and "output" when building against wx28, and "devel30" and "output30" AFTER running the update/update30 scripts
• objects.tar.xz - the entire contents of .objs and .objs30, the intermediate files from the build process
• build_log_wx28.txt.tar.xz and build_log_wx30.txt.tar.xz - the complete logs of both build processes

The link is: https://drive.google.com/open?id=1p6_cDMnmAyq_AKoDyr859IzuQgpGWX-O

[BlueHazzard]

Do you have tried to configure/build codeblocks with a --prefix option and then make a diff with the devel build? There has to be some difference...

[Edit:] checking why IsOk fails would also help, and probably be more easy...

[Huki]

Below is cbLoadBitmap() from sdk/globals.cpp:

Code

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.

[oBFusCATed]

You can build a debug version of your wxgtk and try to debug it. It doesn't happen with my version in gentoo...