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
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
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
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/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
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)
#2 0x41b63f6a in nsProfileLock::FatalSignalHandler(int) (signo=11)
#3 <signal handler called>
#4 0x407f5207 in _XimWrite ()
#5 0x407f56c7 in _XimFilterWaitEvent ()
#6 0x407f438e in _XimThaiCloseIM ()
#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,
#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)
#17 0x41a5de47 in nsAppShellService::Run() (this=0x81b5f20)
#18 0x080685b9 in main1 (argc=1, argv=0xbfffec24, nativeApp=0x812cfe8)
#19 0x08069148 in main (argc=1, argv=0xbfffec24)
#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 0x08070e3a in ah_crap_handler(int) (signum=11)
#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)
#15 0x41a48e47 in nsAppShellService::Run() (this=0x81b6828)
Line 116 in imTrX.c is marked below:
if ((void *) arg == NULL)
im = (Xim) arg;
spec = (XSpecRec *)im->private.proto.spec;
if ((void *) spec == NULL)
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??
 Under LC_ALL=C, Mozilla doesn't crash. So, it's definitely got to do with XIM.
Created attachment 129089 [details] [diff] [review]
XF86 patch : not effective
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
$ env LC_ALL=C mozilla
$ env XMODIFIERS= mozilla
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.
Adding bug 218507 as a depend, it seems to be another incarnation of these flash
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.
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.
This bug is fixed in firefox 3.0.3