[meta] flash crash bugs with linux



External Software Affecting Firefox
Flash (Adobe)
14 years ago
4 years ago


(Reporter: Erich 'Ricky' Iseli, Assigned: Peter Lubczynski)


({crash, meta, relnote})

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [Flash issue])


(2 attachments)



14 years ago
There are quite some flash crasher bugs around, which might all be related.


14 years ago
Severity: normal → critical
Keywords: crash

Comment 1

14 years ago
My installation is a Mandrake 9.1 Linux RPM (Mozilla 1.3.1), Korean localization
(but also reproduced with English locale). The flash plugin was installed in the
following way:
1. installed Netscape 7.1 with flash
2. copied libflashplugin.so and flashplayer.xpt to /plugins
3. loaded http://www.kweather.co.kr/ (lots of flash on this page: NO crash)
4. went to http://mail.yahoo.co.kr and logged in (with korean yahoo address).
First the page displays correctly, but as soon as the flash movie is loaded, the
browser CRASHes
5. removed the two flash files from /plugins, reproduced step 3 and 4: NO crash
6. downloaded and installed flashplugin as described on
   a) downloaded and unpacked flash installer
   b) run the install script
   c) copied the flashplayer.xpt to /components (libflashplugin.so and
flashplayer.xpt were put to /plugins by the installer)
   NOTE: the installer mentioned that 'Macromedia Flash Player requires two font
   to be installed, ttfonts and urw-fonts' While urw-fonts is installed on my
system, I couldn't find
   any package called ttfonts. However, I have quite some true type fonts installed
7. loaded http://www.kweather.co.kr/ CRASH
8. logged in with http://mail.yahoo.co.kr/ CRASH as in 4
9. removed the flashplayer.xpt from the components directory
10. loaded http://www.kweather.co.kr/ NO crash
11. logged in with http://mail.yahoo.co.kr/ still CRASH
Keywords: meta

Comment 2

14 years ago
I suggest this issue to be added to the release notes next time. This is
obviously a highly visible problem, even if it's not a Mozilla but a Flash
issue. CCing asa because of that.
Whiteboard: [Flash issue]

Comment 3

14 years ago
I can confirm the same behaviour.
Mozilla 1.4
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701

My system is Redhat 8
    File name: libflashplayer.so
    Shockwave Flash 6.0 r79

MIME Type 	Description 	Suffixes 	Enabled
application/x-shockwave-flash 	Shockwave Flash 	swf 	Yes
application/futuresplash 	FutureSplash Player 	spl 	Yes

For me however this bug started appearing after upgrading from 1.3.1 to Mozilla
1.4, before that this wasn't a problem.  This confuses me.

Comment 4

14 years ago
In my case, this bug has been bugging me since who knows when.... I always have
to w3m-m17n (text browser with a great I18N support) handy when I browse Korean
pages (Koreans are especially fond of flash and most commercial web sites have
at least a couple of flash animations). 

This is more than critical for Korean (and possibly Chinese users because
Chinese sites seem to have similar penchant for flash animations)

I'll bring up this issue in XF86-i18n list and see whether the patch can come
from the XF86 side because most of crashes occur in 'ThaiXIM....' (I don't know
why it's ThaiXIM...)

Comment 5

14 years ago
Anyone tried this with XF86 4.3.0? I've just filed a bug on XF86 bugzilla
(http://bugs.xfree86.org/show_bug.cgi?id=546). If it's reproducible on 4.3.0,
it'll draw more immediate attention from the XF86 side. 

Comment 6

14 years ago
It might be the case that XF86 4.3.0 doesn't have this problem. See

 337. Fix a double free() that can cause a crash in XCloseIM() (based one
      #5303, Mo DeJong).

I'll try XF86 4.3

Comment 7

14 years ago
XF86 4.3.0 with the fix mentioned in comment #6 didn't fix the problem. Now it's
crashing in _XimWrite().

 #0  0xffffe002 in ?? ()
#1  0x08070e3a in ah_crap_handler(int) (signum=11)
    at /prj/moz/src/mozilla/xpfe/bootstrap/nsSigHandlers.cpp:135
#2  0x41b63f6a in nsProfileLock::FatalSignalHandler(int) (signo=11)
    at /prj/moz/src/mozilla/profile/dirserviceprovider/src/nsProfileLock.cpp:195
#3  <signal handler called>
#4  0x407f5207 in _XimWrite ()
   from /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
#5  0x407f56c7 in _XimFilterWaitEvent ()
   from /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
#6  0x407f438e in _XimThaiCloseIM ()
   from /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
#7  0x40347515 in XFilterEvent () from /usr/X11R6/lib/libX11.so.6
#8  0x432d7460 in _XtOnGrabList () from /usr/X11R6/lib/libXt.so.6
#9  0x432d757f in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6
#10 0x432e372b in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6
#11 0x41ff2b18 in xt_event_dispatch (source_data=0x0, current_time=0xbfffe8a0, 
    at /prj/moz/src/mozilla/widget/src/gtkxtbin/gtkxtbin.c:123
#12 0x402cc9ae in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#13 0x402cce89 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#14 0x402cd124 in g_main_run () from /usr/lib/libglib-1.2.so.0
---Type <return> to continue, or q <return> to quit---
#15 0x401d827f in gtk_main () from /usr/lib/libgtk-1.2.so.0
#16 0x41ab925a in nsAppShell::Run() (this=0x81b3608)
    at /prj/moz/src/mozilla/widget/src/gtk/nsAppShell.cpp:327
#17 0x41a5de47 in nsAppShellService::Run() (this=0x81b5f20)
    at /prj/moz/src/mozilla/xpfe/appshell/src/nsAppShellService.cpp:477
#18 0x080685b9 in main1 (argc=1, argv=0xbfffec24, nativeApp=0x812cfe8)
    at /prj/moz/src/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1289
#19 0x08069148 in main (argc=1, argv=0xbfffec24)
    at /prj/moz/src/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1668
#20 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6

Comment 8

14 years ago
I compiled the cvs snapshot of XF86 with '-g' (I removed '-O2' flag) with
several null checks added. I still have a crash. Strange is that under the gdb,
Mozilla doesn't crash. However, run standalone, it always crash at
http://www.ohmynews.com (when XIM is used [1]). 

#1  0x08070e3a in ah_crap_handler(int) (signum=11)
    at /prj/moz/src/mozilla/xpfe/bootstrap/nsSigHandlers.cpp:135
#2  0x41b4ef6a in nsProfileLock::FatalSignalHandler(int) (signo=11)
<signal handler called>
#4  0x407fb7cc in _XimXFilterWaitEvent (d=0xbfffd3c0, w=0, ev=0x0,
    arg=0x432c334d "[\201&&&&&&&&&\003") at imTrX.c:116
#5  0x40353a9e in XFilterEvent (ev=0xbfffd3c0, window=0) at FilterEv.c:91
#6  0x432c349e in _XtDefaultDispatcher (event=0xbfffd3c0) at Event.c:1321
#7  0x432c390a in XtDispatchEvent (event=0xbfffd3c0) at Event.c:1410
#8  0x432d1438 in XtAppProcessEvent (app=0x8c029c0, mask=1) at NextEvent.c:1381
#9  0x41fddb18 in xt_event_dispatch (source_data=0x0, current_time=0xbfffd550,
    user_data=0x8c34098) at /prj/moz/src/mozilla/widget/src/gtkxtbin/gtkxtbin.c:123
#10 0x402cc9ae in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#11 0x402cce89 in g_get_current_time () from /usr/lib/libglib-1.2.so.0
#12 0x402cd124 in g_main_run () from /usr/lib/libglib-1.2.so.0
#13 0x401d827f in gtk_main () from /usr/lib/libgtk-1.2.so.0
#14 0x41aa425a in nsAppShell::Run() (this=0x81b6988)
    at /prj/moz/src/mozilla/widget/src/gtk/nsAppShell.cpp:327
#15 0x41a48e47 in nsAppShellService::Run() (this=0x81b6828)

Line 116 in imTrX.c is marked below:

    Display     *d,
    Window       w,
    XEvent      *ev,
    XPointer     arg)
    Xim          im;
    XSpecRec    *spec;
    Bool ret;
    if ((void *) arg == NULL)
        return False;
    im = (Xim) arg;
    spec = (XSpecRec *)im->private.proto.spec;
    if ((void *) spec == NULL)
        return False;
    printf ("XimXFilterWaitEnvent: ev= %p\n", (void *) ev);
    spec->ev = (XPointer)ev;      <====  line 116
    ret = _XimFilterWaitEvent(im);

Another strange thing is that 'ev' in the stack backtrace is '0' but the prinf
statement (I added) gave me '0xbfffd3c0' (the value passed from the caller. see
#4 and #5 in the stack trace). Something screwy is going on??  

[1] Under LC_ALL=C, Mozilla doesn't crash. So, it's definitely got to do with XIM. 

Comment 9

14 years ago
Created attachment 129089 [details] [diff] [review]
XF86 patch : not effective

I added several null checks to XFree86 ximp code, but they didn't help.


14 years ago
Depends on: 202013

Comment 10

14 years ago
This bug was fixed by the patch for XFree86 bug 618
(http://bugs.xfree86.org/show_bug.cgi?id=618). Once Linux distribution builders
pick up the fix, ordinary Linux users won't have to suffer from this bug  any more. 

In the meantime, the following has to be release-noted:

1. Upgrading to the newest XFree86 (refering to XFree86 bug 618) would solve the
problem. XFree86 with this patch hasn't been yet released (although the fix is
checked in to the XFree86 trunk). When it's released (or Linux distribution
builders release a new XF86 package), the version has to be mentioned.

2. A temporary work-around is to launch Mozilla under C locale or disable an XIM
    $ env  LC_ALL=C mozilla
    $ env XMODIFIERS=   mozilla

Keywords: relnote

Comment 11

14 years ago
Created attachment 130669 [details] [diff] [review]
release note patch

Asa, what do you think of the following change to 1.5b release notes? I added
an entry to 'known-issues.html' with a link to 
'known-issues-intl.html' If it's OK, I'll just commit.

Comment 12

14 years ago
Adding bug 218507 as a depend, it seems to be another incarnation of these flash
Depends on: 218507

Comment 13

14 years ago
Sorry I forgot to report that I added the release note about this issue. As long
as one installs the latest release of XFree86 (available for one's Linux
distribution), there's no more problem.


14 years ago
Depends on: 200829


14 years ago
Depends on: 189483


14 years ago
Depends on: 238073

Comment 14

14 years ago
re comment #13:
I didn't realize that there are flash-crash issues other than a couple of bugs
involving XIM and flash (bug 191547, bug 209429). XFree86 update fixed bug
191547 and bug 209429, but not others. 


14 years ago
Depends on: 224680


14 years ago
Depends on: 238167


14 years ago
Depends on: 201314


14 years ago
Depends on: 182931


14 years ago
Depends on: 240373


13 years ago
Depends on: 212824


13 years ago
Blocks: 243357


13 years ago
Blocks: 139820


13 years ago
Depends on: 230808


13 years ago
Depends on: 239972


13 years ago
Depends on: 246189


13 years ago
Depends on: 252230


13 years ago
Blocks: 200511


13 years ago
Depends on: 208947


13 years ago
Depends on: 223922


13 years ago
Depends on: 220189


13 years ago
Depends on: 266449


13 years ago
Depends on: 282449


13 years ago
Depends on: 285979


12 years ago
Depends on: 287422

Comment 15

11 years ago
I saw this bug linked from the release notes and just want to tell other poor people looking here for help that Flash 7.0r63 doesn't like 16bpp X displays (or at least mine, Xorg tdfx driver). In fact, it crashes SeaMonkey 1.5 (and Mozilla 1.7, tried it also with Opera 9, where it crashes Opera's plugin wrapper leaving grey area). No XIM involved (release notes tell about it), just simple depth change from 16 to 24 made it work. Even if it's driver-dependant, it may be worth noting in the release notes.
Blocks: 353100
Blocks: 327620


10 years ago
Depends on: 384880
(In reply to comment #15)
> I saw this bug linked from the release notes 

those release notes are for v1.5, circa 2003.

Closing => INVALID. Only open bug left in the list.
QA Contact: bmartin → plugins
Last Resolved: 10 years ago
Resolution: --- → INVALID

Comment 17

9 years ago
The release notes for SeaMonkey 1.1.13 still point to this bug.
Fedora 9,Latest SeaMonkey, Latest Flash Player still crashes.
Seems like the notes should be pointing to this bug.


This bug is fixed in firefox 3.0.3


7 years ago
Component: Plug-ins → Flash (Adobe)
Product: Core → Plugins
QA Contact: plugins → adobe-flash
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.