Bug 135255

Summary: Firefox doesn't start on ppc64
Product: [Fedora] Fedora Reporter: David Woodhouse <dwmw2>
Component: firefoxAssignee: Christopher Aillon <caillon>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: powerpc   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-22 16:44:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 135876    
Attachments:
Description Flags
strace of firefox working on ppc32 host
none
strace of the same binary failing on ppc64 host none

Description David Woodhouse 2004-10-11 13:00:56 UTC
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 13:02:48 UTC
Created attachment 105008 [details]
strace of firefox working on ppc32 host

Comment 2 David Woodhouse 2004-10-11 13:03:50 UTC
Created attachment 105009 [details]
strace of the same binary failing on ppc64 host

Comment 3 David Woodhouse 2004-10-20 11:26:29 UTC
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
+0100
+++ 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 04:53:33 UTC
See also https://bugzilla.mozilla.org/show_bug.cgi?id=242518

Comment 5 Christopher Aillon 2004-10-22 16:44:43 UTC
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