Built-in Icons Missing/Broken/Wrong in GCC 4 Build

[bonefish]

hrev35401

In gcc 4 images built-in icons for volumes, directories, and symlinks are often missing (i.e. fully transparent), broken, or wrong (e.g. some application's icon for a directory). The attached screenshot shows all three phenomena.

I verified that the concerned files don't have any icon-related attributes. I also verified for the ~/config/be/Applications directory, that the "R_AppsDirIcon" VICN type resource in /system/lib/libtracker.so contains the correct value. This should rule out a build system problem.

GCC 2 images seem to work fine.

Before updating to hrev35401 I used hrev35274 as a base with only my own changes. The problem didn't exist with that version.

[bonefish]

Screenshot with broken icons

[anevilyak]

I did try to look into this one...what's puzzling me is that I only see it with a cross built libtracker.so, but never with one built with Haiku's native gcc4. There are some differences between the two library binaries, but I haven't yet managed to determine what it is. It does consistently make the resource-based icons nonfunctional though (hence missing volumes, disks) despite the corresponding resources being identical in both builds according to xres -l.

[stippi]

What about hrev35118? Has this perhaps introduced the problem?

[anevilyak]

Replying to stippi:

What about hrev35118? Has this perhaps introduced the problem?

Unfortunately it doesn't appear to be quite that simple, I had builds randomly do that to me here and there while working on refactoring Tracker, but nothing ever consistently caused it, nor did anything obviously related fix it. Also note, hrev35118 only affects icon definitions retrieved from resources, whereas the currently observed issue touches both those as well as random icons retrieved from the FS/mime database.

[bonefish]

Via binary search I've identified hrev35396 as the revision that introduced the problem. Will investigate.

AFAICT it doesn't seem to be related to #5351. At least I can reliably reproduce the problem with hrev35396 or later while everything works fine here with earlier revisions.

[anevilyak]

It's the same root issue, 5351 is caused by the navigator failing to pull an icon from resources without error checking it, and then blindly trying to draw a BPictureButton using said null resource.

[bonefish]

In fact hrev35396 is not the culprit. If I also revert build/BuildConfig, hrev35395 exposes the same problem. Otherwise it would have linked against the static instead of the shared C++ libraries. Linking against the shared C++ libraries was introduced between hrev31344 and hrev31443 (originating from hrev31346) by Oliver. I have just tested that hrev35338 works fine, though. Trying binary search again...

[bonefish]

hrev35375 identified as first broken revision. I'm thinking out of bounds writes.

[bonefish]

Fixed in hrev35407.

[bonefish]

(In #5351) Fixed in hrev35407.