Closed Bug 335166 Opened 15 years ago Closed 15 years ago

ASSERTION: Can't load cursor, is the resource file installed correctly?

Categories

(Core Graveyard :: Widget: Mac, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: jaas)

Details

(Keywords: assertion, fixed1.8.1, regression)

Attachments

(1 file)

I get a these once a second while starting up and while/after loading some pages:

###!!! ASSERTION: Can't load cursor, is the resource file installed correctly?: 'cursHandle', file /Users/admin/trunk/mozilla/widget/src/mac/nsWindow.cpp, line 765
Me too. Makes running in a debugger with "XPCOM_DEBUG_BREAK=trap" a pain. aCursorResourceNum is in the 200's (200, 201, 202, 203), but I don't see cursor resources in firefox-bin.rsrc.
Flags: blocking1.9a1?
(In reply to comment #1)
> Me too. Makes running in a debugger with "XPCOM_DEBUG_BREAK=trap" a pain.
> aCursorResourceNum is in the 200's (200, 201, 202, 203), but I don't see cursor
> resources in firefox-bin.rsrc.
> 

(Me too).
I think these resources are in fact in libwidget.rsrc. Not sure why it doesn't find them there.
Replacing the libwidget.rsrc alias inside the app bundle with the actual file (from /widget/src/mac/) makes the assertions go away. At least as a workaround, this works for me.
When libwidget.rsrc is an alias, what happens is that the call to FSOpenResourceFile() in http://lxr.mozilla.org/mozilla/source/widget/src/mac/nsMacResources.cpp#104 fails, with error code -39 (eofErr).

Since I can't see that any of the code was changed recently, I wonder if what broke this was the latest System update. Are all those seeing this problem using 10.4.6? If so, can you say if you started seeing this right after upgrading to 10.4.6? (I myself am not sure, but I think it was around the same time).

Who would be the Mac person we can CC on this to get some real help?
I'm using Mac OS X 10.4.6, but I don't know whether this started happening just when I upgraded.
This isn't a new bug.  It's caused by evil and inappropriate use of FSSpec:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/mac/nsMacResources.cpp&rev=1.11&mark=60-63#60

FSpMakeFSRef doesn't resolve symbolic links.  The FSSpecs should really be eliminated and we should do something that gets the app dir and looks for the file in there, all with FSRefs.
Attached patch Death to FSSpecSplinter Review
Attachment #220431 - Flags: review?(joshmoz)
Attachment #220431 - Flags: review?(joshmoz) → review+
Attachment #220431 - Flags: superreview?(mikepinkerton)
Comment on attachment 220431 [details] [diff] [review]
Death to FSSpec

sr=pink
Attachment #220431 - Flags: superreview?(mikepinkerton) → superreview+
Checked in, trunk.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Flags: blocking1.9a1?
Attachment #220431 - Flags: approval-branch-1.8.1+
Checked in, MOZILLA_1_8_BRANCH before 1.8.1b1.
Keywords: fixed1.8.1
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.