#775 Assertion Error / Segmentation Fault around bitmap errors

[Adam]

Steps to reproduce:

• Fetch Code::Blocks from SVN and build it using CodeBlocks_wx30-unix.workspace, then run sh update30
• I used the stable version of codeblocks (17.12) from my distro's repo to perform this build, and set -Og -g into "base" to ensure I get debug symbols. Build took a while first time, but ccache helps subsequent rebuilds.
• Clear my ~/.config/codeblocks and ~/.local/share/codeblocks folders and run run.shfrom my build tree's devel30 folder.
• Move around the UI, open some files in the editor, open some projects, view the About page, etc.

Expected behaviour

• All images/icons/etc. in Code::Blocks appear fine, no error messages, normal operation

Actual behaviour

• At some point (sometimes almost immediately, sometimes after a few minutes), "new" images in the UI fail to load (including icon bitmaps, and the big image on the About page, see the attached screenshot).
• Assert error popups galore, console output, all manner of complaints about bitmap failures, see the attached screenshot/log.

The errors are 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

Eventually, Code::Blocks seems to hard crash, but while gathering information for my previous report #774 I have lost track of which backtrace was due to this cause. As and when I can reproduce this again to the point of crashing, I will provide a backtrace.

Further notes
The issue doesn't occur in my repo's version of 17.12, nor if I build 17.12 myself (fetching that release from SVN and following the same steps as above, with wx30).
The issue occurs in svn trunk also when using the wx28 build.
* I used Code::Blocks to build mainly because I couldn't work out how to get the ./configure + make approach working, but that's a separate issue.

System: Arch Linux x86_64, GCC 8.2.x, wxgtk 3.0.4

If anyone has further questions about my build process, my setup, or about the issue itself, please don't hesitate to ask. As mentioned in my previous report, I will now attempt a bisection to find the responsible change(s).

[Adam]

I neglected to mention it, but the current svn commit at time of writing is r11521.

[Adam]

I am in the process of bisecting now, but I get best results at consistently triggering this error if I:

1. open codeblocks
2. view the Help > About page
3. open an existing project or workspace
4. (build and run it)
5. view the Help > About page again

Sometimes I have to repeat this a few times in one session for the error to trigger - as with almost all issues which plague me, it's not "consistently reproducible".

[Adam]

Bisection is taking forever on my current setup, with a lot of intereference from previously compiled objects (and cleaning them obviously means it takes forever), but so far it seems that this behaviour was introduced between r11329 and r11390.

[Adam]

It turns out I still get the issue in r11329. I'm going to re-rest for commit r11261, which is just after the 17.12 release.

If I still get the issue there, then I'm going to do a full clean and a full rebuild, since it means the issue has something to do with the build system.

Is there anything more I need to do other than sh update30 after I change the current svn/git commit and rebuild using the .workspace file?

[Adam]

OK. After rebuilding r11261 I got the issue again, so I think the problem is actually some sort of horrible persistence in the build folder.

I've deleted the directories .objs, devel30 and output30, reset to most recent trunk (actually not quite the most recent - I'm using the git mirror of codeblocks for now whose most recent commit currently corresponds to r11511, not r11521 which is the actual current svn trunk), and am now doing a hopefully fresh build again with the .workspace file.

This will take a while, but either way, I'll need further input from there to verify what I'm actually supposed to be doing to get my builds to work properly. In my opinion, I'm making builds in the most obvious "minimum amount of steps" way possible, so if we can work out what I'm missing, it will surely help someone else later on.

[Adam]

OK. I pulled a fresh svn head and built it. I still get the same error. I also cannot seem to reproduce the cases I seemed to get before where the issue didn't occur, so my current information has to be that all builds I make suffer from this issue.

There must be something wrong with my build process, which I've detailed through the thread. I hope very much that this can be resolved so as to help others who inevitably encounter similar issues if building for themselves.

[Adam]

I can, however, make a new observation about when the issue does and doesn't occur:

1. Open C::B build which I made
2. Help -> About
3. Image appears fine, no errors
4. Open .cbp project
5. Help -> About
6. Error occurs, popup dialog with details; Image does not appear
7. Close .cbp project
8. Help -> About
9. Image appears fine, no errors

This seems to apply to all the builds I made, so the times I previously thought the issue wasn't present were presumably false negatives due to having not followed this specific reproduction pattern.

I'd like to however re-state that the issue does not occur with the 17.12 build provided in my distribution's repository. This means that despite my compiled version of ~17.12 having the issue, it must be possible to build properly for my distro.

The one final test I will make today is to download the official 17.12 source package (intead of using svn), build that from scratch, and see if this issue also occurs there.

[Teodor Petrov]

What plugins do you have enabled?
The .objs30 folder contains the object files for wx3x builds, not .objs.
What variant of wxgtk are you using? gtk2 or gtk3?
What happens if you put a breakpoint in cbLoadBitmap and inspect the given paths?
Are you running ./update30 from the src folder?

[Adam]

1. In each case, the plugins which are enabled are the ones which are built and enabled by default, because I'm nuking my .config/codeblocks and .local/share/codeblocks each time before running.
2. It's the wx30 build I'm making
3. I have both versions of wxgtk on my machine due to how it's packaged, but it's the gtk3 one which is being used based on how the UI elements render. I can double check this later on.
4. I could try that but I'd first have to work out how to do that manually with gdb, since running codeblocks with codeblocks (and different builds to boot) seems like a recipe for config disaster.
5. I am running update30 every time, yes, and running the devel30/run.sh script for actually running cb

[Adam]

If I set a breakpoint for cbLoadBitmap, gdb passes over control when the error dialog comes up, but I can't figure out how to inspect what the filename path was. Could you perhaps give some more specific advice? (Or alternatively are you in the Freenode IRC channel? I'm there until 01:00 GMT most days, including today.)

[Adam]

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 I couldn't work out how to use on my own).

If I can work out what that was, I'll be satisfied, but I think technically speaking this counts as "not a bug" unless someone else can reproduce the same issue when building using the .workspace files on Linux. (i.e. it's either a legit .workspace issue, or missing flags/steps on my part)

[Adam]

After yet more testing, I have two more data points which suggest essentially that the issue is user error of some kind.

1. 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.
2. 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 to when the images get put on screen.
   1. The first burst is during loading the application. In this current state, all images seem to work.
   2. The second burst is while opening a project or source file. Specifically C::B seems to try to access breakpoint related PNGs from ./share/codeblocks/manager_resources.zip. In this current state, opening the About dialog raises the aforementioned assertions, and the splash screen doesn't appear in it.
   3. There doesn't appear do be a third burst of calls when closing any open files, but after doing so, it becomes possible again to view the splash screen in the About dialog (and with no assertion errors).
3. I then went back into the .workspace file (in system codeblocks) and did another build, this time making sure to select the "All" target. I had previously had the option set which only build C::B with core plugins.
4. The resulting build did not suffer from any of the issues. I noticed that the timestamp of manager_resources.zip had been updated.

The bottom line is that this is not-a-bug, caused by incomplete/partial builds and previous build information, and my recommendation to anyone experiencing it is to clear out their /devel* folder and build again, If that doesn't work, hopefully they find this thread and can perhaps continue their investigation here.

[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 really have no idea why it's happening or why no-one else seems to be able to reproduce it. I'm totally at a loss - all I know is what I see.