Closed Bug 1102304 Opened 10 years ago Closed 10 years ago

Firefox crashes on OS X when started in 32bit mode [@ libobjc.A.dylib@0x10a4 ]

Categories

(Core :: Widget: Cocoa, defect)

x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla36

People

(Reporter: andrei, Assigned: mstange)

References

Details

(Keywords: crash, Whiteboard: [mozmill])

Crash Data

Attachments

(1 file)

This is a regression in Firefox.
I tracked it down to:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c7eefbcb8e13&tochange=24a68796eb6e

Since bug 1097354 specifically targets Yosemite, that's the best bet of the 3 bugs.

With a debug build I can see this:
> (2.0.9)SL77-238:BROKEN andrei.eftimie$ mozmill -b inbound/NightlyDebug.app/ --manual
> arch: posix_spawnp: /Users/andrei.eftimie/work/mozilla/temp/BROKEN/inbound/NightlyDebug.app/Contents/MacOS/firefox: Bad CPU type in executable

Not sure what to make of this, this needs to be investigated further.
Can you check whether this patch fixes the bug?
Attachment #8526087 - Flags: feedback?(andrei.eftimie)
So mozrunner attempts to open Firefox with:
> arch -arch i386 /Users/andrei.eftimie/work/mozilla/temp/BROKEN/inbound/NightlyDebug.app/Contents/MacOS/firefox -foreground -profile /var/folders/9l/sn_p3bw914s360j602z20jsc0000gq/T/tmpKft_aa.mozrunner

If instead I use the following, it works fine:
> arch -arch x86_64 /Users/andrei.eftimie/work/mozilla/temp/BROKEN/inbound/NightlyDebug.app/Contents/MacOS/firefox -foreground -profile /var/folders/9l/sn_p3bw914s360j602z20jsc0000gq/T/tmpKft_aa.mozrunner

Oh, thanks for the quick response Markus, I'll give that a try.
Interesting, I was going to ask about that. So mozrunner forces Firefox to run in 32 bit mode. Do you know if that is intentional? Does it happen always or only for 32 bit specific test runs?
Hm, we are aware of problems with mozrunner on OS X 10.10, see bug 1079890. So the problem is that it always starts Firefox in 32bit mode. Given that this is broken now, we seem to have detected a real Firefox regression.

When running 'arch -arch i386 Nightly.app/Contents/MacOS/firefox' I indeed get a crash! So this is not a Mozmill bug. I will have details soon.
Crash report: bp-7e818cec-f4f7-4e05-9ea4-8fcde2141120

0 	libobjc.A.dylib 	libobjc.A.dylib@0x10a4 	
Ø 1 	AppKit 	AppKit@0xe19de 	
Ø 2 	AppKit 	AppKit@0x79660a 	
3 	XUL 	-[BaseWindow setContentView:] 	widget/cocoa/nsCocoaWindow.mm

So Markus seemed to be correct with his approach.
Severity: normal → critical
Crash Signature: [@ libobjc.A.dylib@0x10a4 ]
Component: Mozmill → Widget: Cocoa
Keywords: crash
Product: Testing → Core
QA Contact: hskupin
Summary: Mozmill can't open Firefox on OSX 10.10 → Firefox crashes on OS X when started in 32bit mode [@ libobjc.A.dylib@0x10a4 ]
Whiteboard: [mozmill]
Markus, I think you can easily test your patch now. :)
Interestingly there doesn't seem to be a crash if Firefox is getting restarted in the other architecture. Those tests were all running successfully today. Not sure what the difference is there.
Thanks Henrik, I'll set up a unified build environment on my machine later. It sounded like Andrei already had one, but now that I think about it, he probably just downloaded finished inbound builds.

(In reply to Henrik Skupin (:whimboo) from comment #7)
> Not sure what the difference is there.

"long long" is 64 bits wide on both architectures, but on 32 bit the _addKnownSubview method expects a 32 bit value and crashes when it gets a 64 bit one. At least that's my best guess at the moment.
Comment on attachment 8526087 [details] [diff] [review]
use NSWindowOrderingMode instead of "long long"

But since this patch is the right thing to do anyway, Steven can already start reviewing it.

NSWindow.h has: typedef NSInteger NSWindowOrderingMode;
"long long" an NSInteger are different types on 32 bit.

I got the "long long" from my AppKit class-dump, which apparently only looked at the 64 bit architecture.
Attachment #8526087 - Flags: review?(smichaud)
Attachment #8526087 - Flags: feedback?(mstange)
Attachment #8526087 - Flags: feedback?(andrei.eftimie)
Comment on attachment 8526087 [details] [diff] [review]
use NSWindowOrderingMode instead of "long long"

Good catch :-)

We should have looked at the definition for the documented -[NSView addSubview:positioned:relativeTo:] method, which is the exact counterpart of this (undocumented) method.
Attachment #8526087 - Flags: review?(smichaud) → review+
(In reply to Markus Stange [:mstange] from comment #8)
> Thanks Henrik, I'll set up a unified build environment on my machine later.
> It sounded like Andrei already had one, but now that I think about it, he
> probably just downloaded finished inbound builds.

Andrei only hit this by accident due to the known problem in the older mozrunner version Mozmill 2.0.x makes use of. So it was luck, and we should probably really add a full 32bit targeted testrun in our Mozmill CI.
Comment on attachment 8526087 [details] [diff] [review]
use NSWindowOrderingMode instead of "long long"

I have confirmed that this fixes the crash when running optimized builds through arch -arch i386. I used the inbound tinderbox build at http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-macosx64/1416507845/firefox-36.0a1.en-US.mac.dmg (which includes this patch) to test.

I was only able to launch optimized builds. Debug builds print the error mentioned in comment 0, and they have done that before bug 1097354:

arch: posix_spawnp: /Volumes/Nightly/NightlyDebug.app/Contents/MacOS/firefox: Bad CPU type in executable

I don't know what that is about, but it seems to be a separate issue.
Attachment #8526087 - Flags: feedback?(mstange)
https://hg.mozilla.org/mozilla-central/rev/f39fc9dc4c0d
Assignee: nobody → mstange
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.