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

RESOLVED FIXED

Status

RESOLVED FIXED
13 years ago
9 years ago

People

(Reporter: jruderman, Assigned: jaas)

Tracking

({assertion, fixed1.8.1, regression})

Trunk
PowerPC
Mac OS X
assertion, fixed1.8.1, regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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.
(Reporter)

Updated

13 years ago
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?
(Reporter)

Comment 5

13 years ago
I'm using Mac OS X 10.4.6, but I don't know whether this started happening just when I upgraded.

Comment 6

13 years ago
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.

Comment 7

13 years ago
Created attachment 220431 [details] [diff] [review]
Death to FSSpec
Attachment #220431 - Flags: review?(joshmoz)
(Assignee)

Updated

13 years ago
Attachment #220431 - Flags: review?(joshmoz) → review+

Updated

13 years ago
Attachment #220431 - Flags: superreview?(mikepinkerton)
Comment on attachment 220431 [details] [diff] [review]
Death to FSSpec

sr=pink
Attachment #220431 - Flags: superreview?(mikepinkerton) → superreview+

Comment 9

13 years ago
Checked in, trunk.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
(Assignee)

Updated

13 years ago
Flags: blocking1.9a1?

Updated

13 years ago
Attachment #220431 - Flags: approval-branch-1.8.1+

Comment 10

13 years ago
Checked in, MOZILLA_1_8_BRANCH before 1.8.1b1.
Keywords: fixed1.8.1

Updated

9 years ago
Component: Widget: Mac → Widget: Mac
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.