Closed Bug 211213 Opened 21 years ago Closed 17 years ago

[meta] flash crash bugs with linux

Categories

(External Software Affecting Firefox Graveyard :: Flash (Adobe), defect)

x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: Erich.Iseli, Assigned: peterlubczynski-bugs)

References

Details

(Keywords: crash, meta, relnote, Whiteboard: [Flash issue])

Attachments

(2 files)

There are quite some flash crasher bugs around, which might all be related.
Severity: normal → critical
Keywords: crash
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
Keywords: meta
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]
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.
Depends on: 202013
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

Keywords: relnote
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.
Depends on: 218507
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
Depends on: 200829
Depends on: 189483
Depends on: 238073
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. 
Depends on: 224680
Depends on: 238167
Depends on: 201314
Depends on: 182931
Depends on: 240373
Depends on: 212824
Blocks: 243357
Blocks: 139820
Depends on: 230808
Depends on: 239972
Depends on: 246189
Depends on: 252230
Blocks: 200511
Depends on: 208947
Depends on: 223922
Depends on: 220189
Depends on: 266449
Depends on: 282449
Depends on: 285979
Depends on: 287422
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.
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
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
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
Component: Plug-ins → Flash (Adobe)
Product: Core → Plugins
QA Contact: plugins → adobe-flash
Version: Trunk → unspecified
Product: External Software Affecting Firefox → External Software Affecting Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.