Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 211213 - [meta] flash crash bugs with linux
: [meta] flash crash bugs with linux
[Flash issue]
: crash, meta, relnote
Product: External Software Affecting Firefox
Classification: Components
Component: Flash (Adobe) (show other bugs)
: unspecified
: x86 Linux
: -- critical with 2 votes (vote)
: ---
Assigned To: Peter Lubczynski
Depends on: 92012 182931 189483 190007 191547 196473 200829 201314 202013 208947 209429 212824 218507 220189 223922 224680 230808 238073 238167 239972 240373 246189 252230 266449 282449 285979 287422 384880
Blocks: 139820 200511 243357 327620 353100
  Show dependency treegraph
Reported: 2003-07-01 01:16 PDT by Erich 'Ricky' Iseli
Modified: 2013-12-27 14:31 PST (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

XF86 patch : not effective (4.19 KB, patch)
2003-08-03 01:00 PDT, Jungshik Shin
no flags Details | Diff | Splinter Review
release note patch (4.90 KB, patch)
2003-08-30 20:51 PDT, Jungshik Shin
no flags Details | Diff | Splinter Review

Description Erich 'Ricky' Iseli 2003-07-01 01:16:22 PDT
There are quite some flash crasher bugs around, which might all be related.
Comment 1 Erich 'Ricky' Iseli 2003-07-01 01:34:51 PDT
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 and flashplayer.xpt to /plugins
3. loaded (lots of flash on this page: NO crash)
4. went to 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 ( 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 CRASH
8. logged in with CRASH as in 4
9. removed the flashplayer.xpt from the components directory
10. loaded NO crash
11. logged in with still CRASH
Comment 2 Erich 'Ricky' Iseli 2003-07-01 01:48:31 PDT
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.
Comment 3 Maron Kristofersson 2003-07-11 03:02:51 PDT
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:
    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 Jungshik Shin 2003-08-01 09:28:17 PDT
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 Jungshik Shin 2003-08-01 09:51:36 PDT
Anyone tried this with XF86 4.3.0? I've just filed a bug on XF86 bugzilla
( If it's reproducible on 4.3.0,
it'll draw more immediate attention from the XF86 side. 
Comment 6 Jungshik Shin 2003-08-01 15:10:54 PDT
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 Jungshik Shin 2003-08-02 01:29:02 PDT
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/
#5  0x407f56c7 in _XimFilterWaitEvent ()
   from /usr/X11R6/lib/X11/locale/lib/common/
#6  0x407f438e in _XimThaiCloseIM ()
   from /usr/X11R6/lib/X11/locale/lib/common/
#7  0x40347515 in XFilterEvent () from /usr/X11R6/lib/
#8  0x432d7460 in _XtOnGrabList () from /usr/X11R6/lib/
#9  0x432d757f in XtDispatchEvent () from /usr/X11R6/lib/
#10 0x432e372b in XtAppProcessEvent () from /usr/X11R6/lib/
#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/
#13 0x402cce89 in g_get_current_time () from /usr/lib/
#14 0x402cd124 in g_main_run () from /usr/lib/
---Type <return> to continue, or q <return> to quit---
#15 0x401d827f in gtk_main () from /usr/lib/
#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/
Comment 8 Jungshik Shin 2003-08-03 00:42:08 PDT
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 (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/
#11 0x402cce89 in g_get_current_time () from /usr/lib/
#12 0x402cd124 in g_main_run () from /usr/lib/
#13 0x401d827f in gtk_main () from /usr/lib/
#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 Jungshik Shin 2003-08-03 01:00:14 PDT
Created attachment 129089 [details] [diff] [review]
XF86 patch : not effective

I added several null checks to XFree86 ximp code, but they didn't help.
Comment 10 Jungshik Shin 2003-08-26 03:56:23 PDT
This bug was fixed by the patch for XFree86 bug 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

Comment 11 Jungshik Shin 2003-08-30 20:51:49 PDT
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 Jason Faulkner 2003-09-06 22:28:28 PDT
Adding bug 218507 as a depend, it seems to be another incarnation of these flash
Comment 13 Jungshik Shin 2004-03-11 03:17:53 PST
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.
Comment 14 Jungshik Shin 2004-03-20 23:57:10 PST
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. 
Comment 15 Leszek Matok 2006-08-24 13:35:48 PDT
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.
Comment 16 Wayne Mery (:wsmwk, NI for questions) 2007-07-30 08:48:53 PDT
(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.
Comment 17 Steven 2008-12-16 19:16:01 PST
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

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