Opened 13 years ago

Closed 13 years ago

#5361 closed bug (fixed)

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

Reported by: bonefish Owned by: bonefish
Priority: normal Milestone: R1
Component: System/runtime_loader Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #5351
Platform: All



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

Attachments (1)

broken-tracker-icons.png (57.6 KB ) - added by bonefish 13 years ago.
Screenshot with broken icons

Download all attachments as: .zip

Change History (11)

by bonefish, 13 years ago

Attachment: broken-tracker-icons.png added

Screenshot with broken icons

comment:1 by anevilyak, 13 years ago

I did try to look into this one...what's puzzling me is that I only see it with a cross built, 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.

comment:2 by anevilyak, 13 years ago

Blocking: 5351 added

comment:3 by stippi, 13 years ago

What about hrev35118? Has this perhaps introduced the problem?

in reply to:  3 comment:4 by anevilyak, 13 years ago

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.

comment:5 by bonefish, 13 years ago

Blocking: 5351 removed
Owner: changed from anevilyak to bonefish
Status: newin-progress

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.

comment:6 by anevilyak, 13 years ago

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.

in reply to:  6 comment:7 by bonefish, 13 years ago

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

comment:8 by bonefish, 13 years ago

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

comment:9 by bonefish, 13 years ago

Component: Kits/libtracker.soSystem/runtime_loader
Resolution: fixed
Status: in-progressclosed

Fixed in hrev35407.

comment:10 by bonefish, 13 years ago

Blocking: 5351 added

(In #5351) Fixed in hrev35407.

Note: See TracTickets for help on using tickets.