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)

29 Branch
x86
macOS
defect
Not set
major

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)

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.
Attached image screenshot
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
When did this regress? Identical with Australis?
Flags: needinfo?(hskupin)
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)
Whiteboard: [mozmill]
(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)
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?
It's going a bit slowly, since I can't use mozregression.
Gijs, do you need further bisection?
Flags: needinfo?(gijskruitbosch+bugs)
(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)
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
Yeah, it was added via bug 935183. But not sure if it has been released yet. You might take a git checkout.
(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.
Holly 2014-01-15 works fine in 32-bit mode.
I'll get back with the range.
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)
(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)
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)
(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)
Well, the browser console doesn't open at all when running Firefox in 32bit mode with the above mentioned command line argument.
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)
So I assume this is a regression from bug 878791.
So it's not Australis! Good to know. :) Thanks Paul for finding the regression range.
No longer blocks: australis-merge
Summary: [australis] 32bit mode of Firefox is busted on OS X → 32bit mode of Firefox 29.0a1 is busted on OS X
Blocks: 944717
Assignee: nobody → dteller
Attached patch Loading libSystem (obsolete) — Splinter Review
Experimental patch. Can someone with access to a 32 bit Mac test this?
Flags: needinfo?
I cannot build on Mac as of now. So would it be possible for you to do a tryserver build?
Flags: needinfo?
No longer blocks: 874341
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)
(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
(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
Severity: normal → major
Is there anything we can do to test a regression like this in the testsuite?
Flags: in-testsuite?
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
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.
Attachment #8363084 - Flags: review?(mh+mozilla)
Component: Toolbars and Customization → OS.File
Product: Firefox → Toolkit
Attachment #8363084 - Flags: review?(mh+mozilla) → review+
https://hg.mozilla.org/integration/fx-team/rev/8edaa73d7bf1
Keywords: checkin-needed
Whiteboard: [mozmill] → [mozmill][fixed-in-fx-team]
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
Flagging for verification.
Keywords: verifyme
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)
(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)
Verified fixed FF 29.0a1(2014-01-29), Mac OS X 10.7.5/10.8.5 32-bit mode.
Status: RESOLVED → VERIFIED
Keywords: verifyme
.

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]

.
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)
Removing my name from in-qa-testsuite flag for a better query.
Flags: in-qa-testsuite?(hskupin) → in-qa-testsuite?
Depends on: 967055
Actually, all Mozmill test related work and discussion will happen on bug 967055.
Flags: in-qa-testsuite?
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: