256603 - Firefox and Mozilla crash at startup on linux alpha (and possibly other 64 bits arches).

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Mike Hommey [:glandium]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.7) Gecko/20040822 Firefox/0.9.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.7) Gecko/20040822 Firefox/0.9.3

in accessible/src/atk/nsAccessibleWrap.cpp,
nsAccessibleWrap::GetMaiAtkType returns a GType into a PRUint32, and... that
breaks on 64 bits arches.

see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=259836 for initial report
on firefox.
Interestingly, the issue shows up only on some systems, not all, but does every
time on systems where it does.

A patch has been provided on the Debian BTS (basically replacing PRUint32 by
GType for nsAccessibleWrap::GetMaiAtkType return type) but is not enough (it is
missing an include to get GType definition in nsAccessibleWrap.h, and several
Makefile.in updates for include paths to fit this change).
An easier fix is to replace PRUint32 by unsigned long int (doesn't need
additional changes), and it has been verified to fix the issue on broken systems.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Jungshik Shin]

confirming based on the Debian report.
Can you upload a complete patch here? 
So, GType is differently typedef'd on different platforms (32bit vs 64bit)? 
 

Comment 2

[Philip K. Warren]

From gtype.h:

/* Typedefs
 */
#if GLIB_SIZEOF_LONG == GLIB_SIZEOF_SIZE_T
typedef gulong                          GType;
#else   /* hm, shouldn't happen? */
typedef gsize                           GType;
#endif

Comment 3

[Philip K. Warren]

Attachment: Patch v1

I would prefer to use GType as the return type of the function instead of
unsigned long. I have removed the class members for those functions, and just
made them static (they are not called from any other code).

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 263543 has been marked as a duplicate of this bug. ***

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

See also https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133812

Comment 6

[Christopher Aillon (sabbatical, not receiving bugmail)]

This is a mustfix for 1.0 IMO.  There is no point in shipping/supporting Firefox
for AMD64 or any other 64bit platform without fixing this bug since it is highly
visible.  I've already got two reports in Red Hat bugzilla about this from
Rawhide.  I expect if we ship with this, I will be inundated with such reports,
as will mozilla.org.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 156851 [details] [diff] [review]
Patch v1

Does this patch still apply?

Comment 8

[Kyle Yuan]

Comment on attachment 156851 [details] [diff] [review]
Patch v1

Louie should review this.

Comment 9

[Philip K. Warren]

Can someone with access to a 64-bit system confirm that this patch actually
fixes the crash before we check it in to all the branches?

Comment 10

[Philip K. Warren]

Comment on attachment 156851 [details] [diff] [review]
Patch v1

Requesting approval for checking in the fix on aviary and 1.7 branches.

Comment 11

[Mike Kaply [:mkaply]]

> Can someone with access to a 64-bit system confirm that this patch actually
> fixes the crash before we check it in to all the branches?

Where is this confirmation?

Comment 12

[chris hofmann]

Comment on attachment 156851 [details] [diff] [review]
Patch v1

a=chofmann for the branches

Comment 13

[Zack Cerza]

The issue seems to be gone in rawhide's firefox-0.10.1-1.0PR1.10.

Comment 14

[Brian Ryner (not reading)]

Landed on trunk and branches per confirmation that the fix works.