Closed
Bug 960509
Opened 10 years ago
Closed 10 years ago
32bit mode of Firefox 29.0a1 is busted on OS X
Categories
(Toolkit Graveyard :: OS.File, defect)
Tracking
(firefox28 unaffected, firefox29+ verified)
VERIFIED
FIXED
mozilla29
Tracking | Status | |
---|---|---|
firefox28 | --- | unaffected |
firefox29 | + | verified |
People
(Reporter: whimboo, Assigned: Yoric)
References
Details
(Keywords: regression, Whiteboard: [mozmill])
Attachments
(2 files, 1 obsolete file)
39.81 KB,
image/jpeg
|
Details | |
968 bytes,
patch
|
glandium
:
review+
|
Details | Diff | Splinter Review |
I was running the latest Nightly on OS X while doing some mozmill tests and I have seen that the whole UI is completely busted when Firefox is run in 32bit mode. 64bit mode is fine. I will attach a picture in a moment.
Reporter | ||
Comment 1•10 years ago
|
||
Reporter | ||
Comment 2•10 years ago
|
||
Ok, it's not only the UI. Even functionality wise it doesn't work at all. I can't even open the browser console.
Summary: [australis] 32bit mode of Firefox is busted ui-wise on OS X → [australis] 32bit mode of Firefox is busted on OS X
Version: 26 Branch → 29 Branch
Comment 3•10 years ago
|
||
When did this regress? Identical with Australis?
Flags: needinfo?(hskupin)
Keywords: regressionwindow-wanted
Reporter | ||
Comment 4•10 years ago
|
||
It would be great if someone else could check for the regression range. I'm kinda swamped with work at the moment. As what I have seen this does not affect Aurora at the moment. I haven't tested a Holly build yet. Steps: 1. Install the latest nightly 2. Open the finder and navigate to the FirefoxNightly.app bundle 3. Right click and choose 'Get info' 4. Select 32bit mode 5. Open Firefox Mihaela, could you have a look at this bug? That would be pretty helpful. Thanks.
Flags: needinfo?(hskupin) → needinfo?(mihaela.velimiroviciu)
Reporter | ||
Updated•10 years ago
|
Whiteboard: [mozmill]
Comment 5•10 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #4) > It would be great if someone else could check for the regression range. I'll take care of this.
Flags: needinfo?(mihaela.velimiroviciu)
Comment 6•10 years ago
|
||
Last good nightly: 2014-01-13 First bad nightly: 2014-01-14 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=12d3ba62a599&tochange=34dddf6f7ec1
(In reply to Paul Silaghi, QA [:pauly] from comment #6) > Last good nightly: 2014-01-13 > First bad nightly: 2014-01-14 > > Pushlog: > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=12d3ba62a599&tochange=34dddf6f7ec1 Thanks Paul, can you please regress this further using tinderbox builds?
Comment 8•10 years ago
|
||
It's going a bit slowly, since I can't use mozregression. Gijs, do you need further bisection?
Flags: needinfo?(gijskruitbosch+bugs)
Comment 9•10 years ago
|
||
(In reply to Paul Silaghi, QA [:pauly] from comment #8) > It's going a bit slowly, since I can't use mozregression. > Gijs, do you need further bisection? It would certainly help understand this and whether it has anything or nothing to do with Australis.
Flags: needinfo?(gijskruitbosch+bugs)
Reporter | ||
Comment 10•10 years ago
|
||
Paul can you please try a holly build? If that works it might indeed not be related to australis. Otherwise please use tinderbox builds which you don't have to build: http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-macosx64/ AFAIK mozregression should support tinderbox builds now
Reporter | ||
Comment 11•10 years ago
|
||
Yeah, it was added via bug 935183. But not sure if it has been released yet. You might take a git checkout.
Comment 12•10 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #10) > AFAIK mozregression should support tinderbox builds now I'm talking about the 32-bit mode step.
Comment 13•10 years ago
|
||
Holly 2014-01-15 works fine in 32-bit mode. I'll get back with the range.
Comment 14•10 years ago
|
||
Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=5f86bd747899&tochange=ab211cc6d9d6
Comment 15•10 years ago
|
||
Thanks Paul. This narrows it down to a handful of possible changes: Bug 958865 - extensions/cookie/test should use standard Services.perms. r=jdm Bug 791784 - Add serialization to avoid a thread race when a plug-in crashes during Firefox shutdown. r=ted Bug 951150 - Sync notification system message with Notification API. r=mhenretty Bug 878791 - Link OS.File to 'libc.so' and 'a.out' without further niceties. r=glandium Bug 762083 - Fix default database size. r=mak Gijs, does this give you any leads?
Flags: needinfo?(gijskruitbosch+bugs)
Comment 16•10 years ago
|
||
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #15) > Thanks Paul. This narrows it down to a handful of possible changes: > > Bug 958865 - extensions/cookie/test should use standard Services.perms. r=jdm > Bug 791784 - Add serialization to avoid a thread race when a plug-in crashes > during Firefox shutdown. r=ted > Bug 951150 - Sync notification system message with Notification API. > r=mhenretty > Bug 878791 - Link OS.File to 'libc.so' and 'a.out' without further niceties. > r=glandium > Bug 762083 - Fix default database size. r=mak > > Gijs, does this give you any leads? Not really. We should probably do try builds with each single one of these backed out, and then test those. :-( I'll see if I have time to do this this weekend. It would help if we had any idea about JS errors. Paul or Henrik, if you start a broken version of the browser with --jsdebugger, and check the console then, do you see any errors there?
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(hskupin)
Comment 17•10 years ago
|
||
The problem is when I run ./firefox --jsdebugger the bug doesn't reproduce. Probably Firefox is not running in 32-bit mode.
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(hskupin)
Comment 18•10 years ago
|
||
(In reply to Paul Silaghi, QA [:pauly] from comment #17) > The problem is when I run ./firefox --jsdebugger the bug doesn't reproduce. > Probably Firefox is not running in 32-bit mode. You can prefix the shell command with: arch -i386 See http://stackoverflow.com/questions/1654837/run-an-os-x-universal-binary-in-32-bit-mode
Flags: needinfo?(paul.silaghi)
Reporter | ||
Comment 19•10 years ago
|
||
Well, the browser console doesn't open at all when running Firefox in 32bit mode with the above mentioned command line argument.
Reporter | ||
Comment 20•10 years ago
|
||
Ok, something I see when enabling all devtools preferences is: Error loading: resource://gre/modules/devtools/server/actors/webapps.js: Error: couldn't find function symbol in library - @resource://gre/modules/osfile/osfile_unix_allthreads.jsm:68 @resource://gre/modules/osfile/osfile_async_front.jsm:41 @resource://gre/modules/osfile.jsm:11 @resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/webapps.js:12 loadSubScript@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js:47 DS_addActors@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js:301 DebuggerServer.addBrowserActors@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js:354 BrowserToolboxProcess.prototype._initServer@resource://app/modules/devtools/ToolboxProcess.jsm:70 BrowserToolboxProcess@resource://app/modules/devtools/ToolboxProcess.jsm:35 BrowserToolboxProcess.init@resource://app/modules/devtools/ToolboxProcess.jsm:45 devtoolsCommandlineHandler.prototype.handleDebuggerFlag@resource://app/components/devtools-clhandler.js:56 devtoolsCommandlineHandler.prototype.handle@resource://app/components/devtools-clhandler.js:24
Flags: needinfo?(paul.silaghi)
Flags: needinfo?(gijskruitbosch+bugs)
Reporter | ||
Comment 21•10 years ago
|
||
So I assume this is a regression from bug 878791.
Blocks: 878791
Keywords: regressionwindow-wanted
Reporter | ||
Comment 22•10 years ago
|
||
So it's not Australis! Good to know. :) Thanks Paul for finding the regression range.
No longer blocks: australis-merge
status-firefox28:
--- → unaffected
Summary: [australis] 32bit mode of Firefox is busted on OS X → 32bit mode of Firefox 29.0a1 is busted on OS X
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → dteller
Assignee | ||
Comment 23•10 years ago
|
||
Experimental patch. Can someone with access to a 32 bit Mac test this?
Flags: needinfo?
Reporter | ||
Comment 24•10 years ago
|
||
I cannot build on Mac as of now. So would it be possible for you to do a tryserver build?
Flags: needinfo?
Assignee | ||
Comment 25•10 years ago
|
||
Try: https://tbpl.mozilla.org/?tree=Try&rev=e485687ccea3
Reporter | ||
Comment 26•10 years ago
|
||
Tested but nothing has been changed here. I still see the problems: *** ERROR addons.xpi: Failed to process extension changes at startup: Error: couldn't find function symbol in library (resource://gre/modules/osfile/osfile_unix_allthreads.jsm:69)
Comment 27•10 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #26) > Tested but nothing has been changed here. I still see the problems: > > *** ERROR addons.xpi: Failed to process extension changes at startup: Error: > couldn't find function symbol in library > (resource://gre/modules/osfile/osfile_unix_allthreads.jsm:69) bug 959554
Assignee | ||
Comment 29•10 years ago
|
||
Let's try this instead. Try: https://tbpl.mozilla.org/?tree=Try&rev=3091db88b08f
Attachment #8362701 -
Attachment is obsolete: true
Reporter | ||
Comment 30•10 years ago
|
||
(In reply to David Rajchenbach Teller [:Yoric] (please use "needinfo?") from comment #29) > Let's try this instead. > Try: https://tbpl.mozilla.org/?tree=Try&rev=3091db88b08f That version finally works. The error is gone and Firefox behaves as expected in 32bit mode. \/
Status: NEW → ASSIGNED
Assignee | ||
Updated•10 years ago
|
Severity: normal → major
Updated•10 years ago
|
Reporter | ||
Comment 31•10 years ago
|
||
Is there anything we can do to test a regression like this in the testsuite?
Flags: in-testsuite?
Assignee | ||
Comment 32•10 years ago
|
||
Henrik: Not trivially. Do you know if there is a way to force loading the 32 bit version of the executable? Try: https://tbpl.mozilla.org/?tree=Try&rev=3091db88b08f
Reporter | ||
Comment 33•10 years ago
|
||
As pointed out by Gujs above via the prefix 'arch -i386'. But not sure how or if mochitest can handle that. If nothing works we could do such a test in Mozmill. Actually we already have a similar one where we test restarting Firefox in 32bit and back into 64bit mode. We might be able to include some basic checks if the application came up correctly.
Assignee | ||
Updated•10 years ago
|
Attachment #8363084 -
Flags: review?(mh+mozilla)
Updated•10 years ago
|
Component: Toolbars and Customization → OS.File
Product: Firefox → Toolkit
Updated•10 years ago
|
Attachment #8363084 -
Flags: review?(mh+mozilla) → review+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 34•10 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/8edaa73d7bf1
Keywords: checkin-needed
Whiteboard: [mozmill] → [mozmill][fixed-in-fx-team]
Comment 35•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/8edaa73d7bf1
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [mozmill][fixed-in-fx-team] → [mozmill]
Target Milestone: --- → mozilla29
Reporter | ||
Comment 37•10 years ago
|
||
David, any further feedback regarding an automated test? Have you had a chance to try that out? Would it be possible? Or should we take care of it via Mozmill?
Flags: needinfo?(dteller)
Assignee | ||
Comment 38•10 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #37) > David, any further feedback regarding an automated test? Have you had a > chance to try that out? Would it be possible? Or should we take care of it > via Mozmill? I haven't had any opportunity to check this out, I'm afraid.
Flags: needinfo?(dteller)
Comment 39•10 years ago
|
||
Verified fixed FF 29.0a1(2014-01-29), Mac OS X 10.7.5/10.8.5 32-bit mode.
Comment 40•10 years ago
|
||
. Hi, I'm the person who opened bug 959554 which then became a dup of this one. Tuesday I saw this patch has been wormed into the m-c tinderbox builds, then saw that FF/Nightly does once-again work in arch -i386 mode. We had to wait for the Thunderbird/Daily c-c tinderbox builds to be fixed due to unrelated patches, so Wednesday finally had working builds with this patch, and saw it does once-again work, also, in arch -i386 mode. Hopefully all the usual nightly etc builds will contain this patch in whatever-else is based on the core code. I would like to vote for an auto-test for any verification that 32-bit mode continues to work. Please make sure the 10.6/SL etc users with non-64-bit CPUs can still use your product. Frankly, this 'outage' took quite a while to fix, which is the main reason I'm urging for such a test, please. I have an onery iMac with 32-bit EFI/BIOS but with Core-2-Duo (64-bit capable) CPU (it's the only 'puter I have presently). I know about the various hacks that might work (since we're in the same boat as early MacPros) to furnish 64-bit kernel capability. But as I've written elsewhere, I'm planning to jump off this fruity ship to build my own 100% F/OSS system (soon as my personal circumstances allow -- I'm on disability and effectively retired with nearly four-decades work on record -- I have much [paid and hobby] technical experience in this area, and this activity would help 'tickle' my brain). I'd like to briefly mention why I personally like to run 32-bit -- please see the graph here: <https://dl.dropboxusercontent.com/u/176364/SixtyFour.html> [should be self-explanatory] When I compile my own code from source, I always use arch -i386 in the various $xxFLAGs strings. (That means I don't trust/use such repos as Macports, Fink, Homebrew, etc. -- I do everything by hand the old-fashioned way.) Also, for closed-src products, I try to write to other vendors to urge them to stop forgetting us who must stick to older systems -- it's usually plain laziness of the programmer(s) involved to drop us. And I do try to send a donation (or pay a shareware fee) to show intent/seriousness. Lastly, I'm amazed this bug was fixed with the one-line patch by adding libSystem back to the libc_candidates list -- !! ;) Thank you for fixing, and for reading this long personal blurb. [I might entertain off-list discussions if possible/needed with anyone interested] .
Comment 41•10 years ago
|
||
I have filed bug 967055 to investigate running Mozmill tests periodically in 32-bit mode on Mac OSX. It might be a good idea to do a similar investigation for our other test frameworks. Henrik, I'm not sure the best place to raise this concern; please advise.
Flags: in-qa-testsuite?(hskupin)
Reporter | ||
Comment 42•10 years ago
|
||
Removing my name from in-qa-testsuite flag for a better query.
Flags: in-qa-testsuite?(hskupin) → in-qa-testsuite?
Reporter | ||
Comment 43•10 years ago
|
||
Actually, all Mozmill test related work and discussion will happen on bug 967055.
Flags: in-qa-testsuite?
Updated•11 months ago
|
Product: Toolkit → Toolkit Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•