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

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 http://plugindoc.mozdev.org/linux.html a) downloaded and unpacked flash installer http://download.macromedia.com/pub/shockwave/flash/english/linux/6.0r79/install_flash_player_6_linux.tar.gz 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 packages 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

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.

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.

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...)

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.

It might be the case that XF86 4.3.0 doesn't have this problem. See http://cvsweb.xfree86.org/cvsweb/xc/lib/X11/imThaiIm.c 337. Fix a double free() that can cause a crash in XCloseIM() (based one #5303, Mo DeJong). I'll try XF86 4.3

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, user_data=0x8a73dc0) 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

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]). -----Backtrace--------------------- #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) at /prj/moz/src/mozilla/profile/dirserviceprovider/src/nsProfileLock.cpp:195#3 <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: -----------imTrX.c------------------------ _XimXFilterWaitEvent( 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.

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

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 server. $ env LC_ALL=C mozilla $ env XMODIFIERS= mozilla

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.

Adding bug 218507 as a depend, it seems to be another incarnation of these flash problems.

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. See http://www.mozilla.org/releases/mozilla1.6/known-issues-int.html#flash

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.

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.

(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.

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. https://bugzilla.mozilla.org/show_bug.cgi?id=137189 This bug is fixed in firefox 3.0.3