32bit mode of Firefox 29.0a1 is busted on OS X

VERIFIED FIXED in Firefox 29

Status

()

Toolkit
OS.File
--
major
VERIFIED FIXED
4 years ago
3 years ago

People

(Reporter: whimboo, Assigned: Yoric)

Tracking

({regression})

29 Branch
mozilla29
x86
Mac OS X
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox28 unaffected, firefox29+ verified)

Details

(Whiteboard: [mozmill])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

4 years ago
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

4 years ago
Created attachment 8361020 [details]
screenshot
(Reporter)

Comment 2

4 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

4 years ago
When did this regress? Identical with Australis?
Flags: needinfo?(hskupin)
Keywords: regressionwindow-wanted
(Reporter)

Comment 4

4 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

4 years ago
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)

Comment 9

4 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

4 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

4 years ago
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)

Comment 16

4 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)
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

4 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

4 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

4 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

4 years ago
So I assume this is a regression from bug 878791.
Blocks: 878791
Keywords: regressionwindow-wanted
(Reporter)

Comment 22

4 years ago
So it's not Australis! Good to know. :) Thanks Paul for finding the regression range.
No longer blocks: 939862
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
(Reporter)

Updated

4 years ago
Blocks: 944717
Assignee: nobody → dteller
Created attachment 8362701 [details] [diff] [review]
Loading libSystem

Experimental patch. Can someone with access to a 32 bit Mac test this?
Flags: needinfo?
(Reporter)

Comment 24

4 years ago
I cannot build on Mac as of now. So would it be possible for you to do a tryserver build?
Flags: needinfo?
(Reporter)

Updated

4 years ago
No longer blocks: 874341
(Reporter)

Comment 26

4 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)
(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

Updated

4 years ago
Duplicate of this bug: 959554
Created attachment 8363084 [details] [diff] [review]
Loading libSystem, v2

Let's try this instead.
Try: https://tbpl.mozilla.org/?tree=Try&rev=3091db88b08f
Attachment #8362701 - Attachment is obsolete: true
(Reporter)

Comment 30

4 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
Severity: normal → major
tracking-firefox29: ? → +
(Reporter)

Comment 31

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

Comment 33

4 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.
Attachment #8363084 - Flags: review?(mh+mozilla)
Component: Toolbars and Customization → OS.File
Product: Firefox → Toolkit
Attachment #8363084 - Flags: review?(mh+mozilla) → review+
Keywords: checkin-needed
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
Last Resolved: 4 years ago
status-firefox29: affected → fixed
Resolution: --- → FIXED
Whiteboard: [mozmill][fixed-in-fx-team] → [mozmill]
Target Milestone: --- → mozilla29
Flagging for verification.
Keywords: verifyme
(Reporter)

Comment 37

4 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)
(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
status-firefox29: fixed → verified
Keywords: verifyme

Comment 40

4 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]

.
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

3 years ago
Removing my name from in-qa-testsuite flag for a better query.
Flags: in-qa-testsuite?(hskupin) → in-qa-testsuite?
(Reporter)

Updated

3 years ago
Depends on: 967055
(Reporter)

Comment 43

3 years ago
Actually, all Mozmill test related work and discussion will happen on bug 967055.
Flags: in-qa-testsuite?
You need to log in before you can comment on or make changes to this bug.