Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 135255 - Firefox doesn't start on ppc64
Firefox doesn't start on ppc64
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
Depends On:
Blocks: 135876
  Show dependency treegraph
Reported: 2004-10-11 09:00 EDT by David Woodhouse
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-22 12:44:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace of firefox working on ppc32 host (923.77 KB, text/plain)
2004-10-11 09:02 EDT, David Woodhouse
no flags Details
strace of the same binary failing on ppc64 host (148.02 KB, text/plain)
2004-10-11 09:03 EDT, David Woodhouse
no flags Details

  None (edit)
Description David Woodhouse 2004-10-11 09:00:56 EDT
Description of problem:
Firefox does not start up on ppc64.

If started with no previous firefox configuration, it attempts to
bring up the dialog box asking where to import a configuration from.
However the dialog box isn't functional -- the radio buttons don't
'take' when you click on them, and the back/next/cancel buttons are
empty. See http://david.woodhou.se/firefox-import.jpeg 

If I first run firefox elsewhere to give me a working configuration,
then firefox on ppc64 just exits silently. However, precisely the same
binaries work on a ppc32 kernel. I've attached the results of 'strace
-f /usr/lib/firefox-0.10.1/firefox' on both ppc32 and ppc64 machines. 

Mozilla has problems which may be related. On ppc64, mozilla starts up
but the GUI seems not to be actually attached to anything useful. The
menus all appear to behave normally but don't actually _do_ anything.
You can select 'File.. Quit' but it won't actually happen. Likewise
typing into the location box doesn't cause it to attempt to load a
page. The bookmarks menu and toolbar are empty. Again, precisely the
same binaries work fine on ppc32 kernel. 

My initial thought was to blame this on the 64-bit kernel's emulation
of 32-bit syscalls. But bizarrely, my own build of mozilla-1.7.3-11
has precisely the same problems even on a 32-bit kernel. I'm assuming
the two are the same problem, and that they're both related to the
firefox bug too. Even if it's a kernel bug, I have no idea what the
problem might be, so could do with some mozilla-fu in finding what's
going wrong.
Comment 1 David Woodhouse 2004-10-11 09:02:48 EDT
Created attachment 105008 [details]
strace of firefox working on ppc32 host
Comment 2 David Woodhouse 2004-10-11 09:03:50 EDT
Created attachment 105009 [details]
strace of the same binary failing on ppc64 host
Comment 3 David Woodhouse 2004-10-20 07:26:29 EDT
There were two problems. First, when building on a ppc64 host the
libxptcmd Makefile selects the known-nonfunctional 'unsupported'
version rather than the ppc_linux version instead of just refusing to
build on a system which it doesn't recognise.

Secondly -- and this was the one which actually broke our RPM build --
there was a very broken method used to detect the stack direction,
which got it wrong when a static function got inlined by the compiler.
The following patch (also sent unmangled by bugzilla in private mail)
fixes that for both firefox and mozilla:

--- mozilla/js/src/jscpucfg.c.orig      2004-10-19 18:46:55.253506232
+++ mozilla/js/src/jscpucfg.c   2004-10-19 18:47:33.160743456 +0100
@@ -160,7 +160,7 @@
     int dummy2;
-    return (&dummy2 < dummy1addr) ? -1 : 1;
+    return -1; /* It always grows down on supported Linux platforms */
 int main(int argc, char **argv)
Comment 4 Christopher Aillon 2004-10-22 00:53:33 EDT
See also https://bugzilla.mozilla.org/show_bug.cgi?id=242518
Comment 5 Christopher Aillon 2004-10-22 12:44:43 EDT
I commited a different patch, which prevents inlining of the method in
question, so the check which is a valid check, can stay.  This is more
in line with what will need to happen for upstream, to where I
submitted the patch.  Marking UPSTREAM, since further work on this
issue will happen there.

This will be fixed in the mozilla -18, firefox -21, and thunderbird
-10 versions

Note You need to log in before you can comment on or make changes to this bug.