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)
Tracking
()
RESOLVED
FIXED
mozilla36
People
(Reporter: andrei, Assigned: mstange)
References
Details
(Keywords: crash, Whiteboard: [mozmill])
Crash Data
Attachments
(1 file)
1.13 KB,
patch
|
smichaud
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•10 years ago
|
||
Can you check whether this patch fixes the bug?
Attachment #8526087 -
Flags: feedback?(andrei.eftimie)
Reporter | ||
Comment 2•10 years ago
|
||
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.
Assignee | ||
Comment 3•10 years ago
|
||
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?
Comment 4•10 years ago
|
||
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.
Comment 5•10 years ago
|
||
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 ]
Updated•10 years ago
|
Whiteboard: [mozmill]
Comment 6•10 years ago
|
||
Markus, I think you can easily test your patch now. :)
Comment 7•10 years ago
|
||
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.
Assignee | ||
Comment 8•10 years ago
|
||
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.
Assignee | ||
Comment 9•10 years ago
|
||
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 10•10 years ago
|
||
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+
Comment 11•10 years ago
|
||
(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.
Assignee | ||
Comment 12•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/f39fc9dc4c0d
Assignee | ||
Comment 13•10 years ago
|
||
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.
Description
•