Closed Bug 58937 Opened 24 years ago Closed 22 years ago

Flash crashes on remote display (XSHM problem in Flash plugin?)

Categories

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

Product:
External Software Affecting Firefox Graveyard
Component:
Flash (Adobe)
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: ataylor+origacct, Assigned: arun)

References

Details

(Keywords: crash, relnote, topembed-, Whiteboard: [NOT A MOZILLA ISSUE THIS IS A FLASH ISSUE -- NOT MOZILLA])

Attachments

(3 files)

stack trace
11.38 KB, text/plain
Details
xdpyinfo output with vnc, see Comment #41
1.68 KB, text/plain
Details
email petition, list of affected sites (totalling 126539 users)
31.98 KB, text/plain
Details 
The flash plugin crashes when viewing a flash document on a remote X display.

This can be reproduced consistantly with M17, M18 and the Nov 02 2000 nightly.

To reproduce:
1. Disable X access control (at your own risk :-): xhost +
2. Log into a remote Linux box
3. Export display for workstation
4. Launch mozilla on remote box
5. Navigate to site with gratuitous flash animation (e.g. http://www.montage.ca)

This causes mozilla to abruptly crash, rather than display the flash as
expected.
Keywords: flash
Keywords: crash
I just tried this with a Nov 7 CVS build, and using ssh X forwarding instead of
setting the DISPLAY variable (sorry, don't have telnetd installed anywhere).

Everything worked fine.
Some more information:

If the browser is left at its default size (i.e. 640x480), then the flash
displays properly.  If the browser is resized significantly larger or maximized,
it crashes.

It appears that if the browser window is larger than the flash content, it
crashes, otherwise it is okay.

This behavior appears to be consistant, regardless of whether X is remote
directly, or forwarded through ssh.

Reporter is this still a problem in the latest nightlies?
Yes.  I can still reproduce with build 2000121209 and version 4.0r12 of the
flash plugin.  ssh forwarding doesn't make a difference one way or the other.


Marking NEW as per reporters comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file stack trace — 

    
    

    
  
I've just stumbled across the same problem trying to debug a component I wrote 
that internally embeddeds the flash plugin.

In addition to crashing on remote displays, it seems can occur occasionally 
even on local displays.  From many runs it looks like something is not right in 
widget cleanup in the xtbin widget.

It's always dying in free (called ultimately from including a stack trace 
gtk_xtbin_destroy()).  I have a gdb stack trace illustrating the problem 
included with this note.



    
    

    
  
A note related to this - the xtbin widget is constructed and destructed 
multiple times (every time SetWindow() is called).  As most of the time nothing 
changes in the window structure (X, Y, and window remain constant), one can 
avoid this.

I coded this up and it allows me to view the flash animation -- until the 
instance is destroyed (when you leave the page).  At which point the problem 
crops up again.  I think this is even more comfirmation that there is a widget 
destruction issue.  Probably something is getting destroyed twice (resulting in 
a multiple frees or memory overrun).

I would suggest putting dumping information on all allocations and destructions 
(X and memory-wise) in the xtbin widget.  Or is it possible that the parent 
widget is destroyed before xtbin can do it's cleanup?



    
    

    
  
Flash crasher or backward incompatibility bug. Nominating for nsbeta1 as
high-quality plug-in support is a priority for embedded applications.
Keywords: nsbeta1

    
    

    
  
Moving to mozilla0.9
Target Milestone: --- → mozilla0.9

    
    

    
  
In Mozilla 0.8 with the flash version 5 plugin, the flash will usually play.  When the X server is Exceed 6.1 on a win95 machine and the client is Mozilla on linux, the problem does not seem to appear.  When the X server is Xfree86 version 4 (I tried on linux PPC and x86), the problem does appear but seems more symptomatic of bug 59052.  

    
    

    
  
Moving to m1.0.
Target Milestone: mozilla0.9 → mozilla1.0

    
    

    
  
I'd like to add this happens consistantly on local X display.
The browser crashes immediatly with an X error whenever I open
a page containing a Flash animation. This is with Netscape 6.01A
on a Solaris 8 SPARC box with Flash 5.0r52.


    
    

    
  
The crash, seen on Solaris 8 SPARC box (ns6.01A) with Flash 5.0r52, does not
look like caused by the same problem. It is a X server problem. It appears that
Flash is fine when deals with 24-bit display but crashs on 8 bit display. The
error msg are:

>> X Error of failed request:  BadMatch (invalid parameter attributes)
>>   Major opcode of failed request:  72 (X_PutImage)
>>   Serial number of failed request:  62
>>   Current serial number in output stream:  72
>>

    
    

    
  
Reassigning to dr.
Assignee: av → dr

    
    

    
  
So, I'm curious... Does this also happen with other plugins? Java, for example?
Does this happen in 4.x?
Status: NEW → ASSIGNED

    
    

    
  
Can't reproduce with java or realaudio plugins. I can reproduce the bug with the
flash plugins always with Xfree 3.3.x or 4.0.x, but I can't reproduce it on Xwin
32 (a X server for MS windows)

    
    

    
  
go to www.werner.de - initial flash loads - click on it - crash

see TB32179945M produced with Netscape 6.1PR1 on Linux, Kernel 2.4.2, Xfree
4.1.0, same Problem can be reproduced on different X-Terminal running Xfree 3.3.6.

    
    

    
  
Probably reproduced with 2001-06-20-21 on Linux using Xwin32 with ssh.
Talkback doesn't work. 

    
    

    
  
Reproduced with Konqueror! Could be a flash or Xfree bug?

    
    

    
  
Is there any status on this?

    
    

    
  
*** Bug 88818 has been marked as a duplicate of this bug. ***

    
    

    
  
peter: it's a bug in flash as far as i can tell by the reports. i've given the
bug the benefit of the doubt so far, and targeted it at 1.0 rather than resolved
it as invalid. but the temptation is great.

    
    

    
  
cc:ing Troy Evans from Macromedia to provide some insight on if this bug is also
inside Flash on Linux.


    
    

    
  
Crashes for me
Local display
Mozilla 2001071108

Shockwave Flash 5.0 r47
/tmp/mozilla/plugins % md5sum libflashplayer.so ShockwaveFlash.class
eb9c139d642c5a8cdf9ab95dca0f4022 libflashplayer.so
fe1ef284ccdcd8669b896e1374223f83 ShockwaveFlash.class


    
    

    
  
started mozilla, navigated to http://www.montage.ca

/tmp % /tmp/mozilla/mozilla                                      (altair) 21:44
/tmp/mozilla/run-mozilla.sh /tmp/mozilla/mozilla-bin
MOZILLA_FIVE_HOME=/tmp/mozilla
  LD_LIBRARY_PATH=/tmp/mozilla:/tmp/mozilla/plugins
     LIBRARY_PATH=/tmp/mozilla:/tmp/mozilla/components
       SHLIB_PATH=/tmp/mozilla
          LIBPATH=/tmp/mozilla
       ADDON_PATH=/tmp/mozilla
      MOZ_PROGRAM=/tmp/mozilla/mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
Failed to load XBL document
jar:file:///home/wtanaka/.mozilla/wtanaka-2/mu9rbe2y.slt/chrome/aqua-0627.jar!/navigator/skin/resources.xml
xmlencoding detect- iso-8859-1
xmlencoding detect- iso-8859-1
xmlencoding detect- iso-8859-1
Warning: Cannot convert string "<Key>Escape,_Key_Cancel" to type VirtualBinding
Warning: Cannot convert string "<Key>Home,_Key_Begin" to type VirtualBinding
Warning: Cannot convert string "<Key>F1,_Key_Help" to type VirtualBinding
Warning: Cannot convert string "Shift<Key>F10,_Key_Menu" to type VirtualBinding
Warning: Cannot convert string "<Key>F10,Shift_Key_Menu" to type VirtualBinding
Warning: Cannot convert string "<Key>KP_Enter,_Key_Execute" to type
VirtualBinding
Warning: Cannot convert string "Alt<Key>Return,Alt_Key_KP_Enter" to type
VirtualBinding
xmlencoding detect- iso-8859-1
xmlencoding detect- iso-8859-1
/tmp/mozilla/run-mozilla.sh: line 72:  9669 Segmentation fault      $prog
${1+"$@"}
/tmp/mozilla/mozilla  15.04s user 0.89s system 15% cpu 1:45.03 total


    
    

    
  
When I start Mozilla in a remote X-session, Mozilla crashes or hangs when I try
to open a page that uses the flash plugin.
Mozilla hangs when the window is smaller than the flash animation and crashes
when the browser is larger (maximized). 
Everything works fine when you try it in a "local" X-session (even on the
terminal server itself, with the same program, user et cetera).
I use the Linux Terminal Server Project (http://www.ltsp.org/): XFree 3.3.6 for
the clients (I use XFree 4.0.3 on the server, but that shouldn't be a problem)
Tried this with 0.9.1, 0.9.2 and 2001071021 (nightly). I tried it with both
Debian Linux and Mandrake Linux as terminal server.
The same plugin works fine with NS4.7, so maybe it's a Mozilla problem after all?
I submitted some TalkBack events:
TB32803679K (http://www.meerschap.nl/)
TB32802681Z (http://www.meerschap.nl/)
TB32803685E (http://www.flash.com/)

Could anyone extract stack traces from these events?

How about setting the severity to critical? This really is severe: some people
use remote X displays for use in internet cafes, not being able to handle flash
could be a reason not to choose Mozilla for a browser.

    
    

    
  
[spam] timecop, would you mind looking at this, or bouncing it to somebody who
could? thanks.
Assignee: dr → timecop
Status: ASSIGNED → NEW
Target Milestone: mozilla1.0 → ---

    
  
Status: NEW → ASSIGNED

    
    

    
  
Hmmm... it says here timecop is on vacation, maybe this should be assigned to
someone else?
This bug is quite a pain in the ass, making it critical really is a good idea
(see my previous comment for an explanation why). 
In my previous comment were some TalkbackIDs too, I don't know what to do with
such a number, could somebody please explain me or just have the stack traces
extracted?


    
    

    
  
This still happens with mozilla 0.9.2 and kernel 2.4.9.  If the mozilla window
is small (not sure how small) when the first page with Flash is loaded, there is
no problem.  Additionally, after the first page is loaded, subsequent pages show
no problem regardless of window size.
This would seem to indicate that the problem is in the plugin initialization stuff.

    
    

    
  
*** Bug 98586 has been marked as a duplicate of this bug. ***

    
    

    
  
I got segmentation fault when opening www.flash.com running mozilla with
exported X display. Exact the same happened when using X-WinPro as X-server.

I modified several settings, and I discovered that the only thing to get it to
work was changing the Image Format from LSB into MSB in the XSetting of X-WinPro.

Now it works for with X-WinPro, but I still can't figure out what to do for rsh
but perhaps someone else can. 

    
    

    
  
I am using mozilla on X terminals. On the server mozilla runs well, but on the
terminals mozilla always crashes when I am loading flash. Just 1 of aprox. 20
attempts is successful :(

    
  
Blocks: 104166

    
    

    
  
*** Bug 106556 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 81357 has been marked as a duplicate of this bug. ***

    
    

    
  
timecop, any progress on this?

This should probably go in the release notes.
Keywords: relnote

    
    

    
  
don't know who assigned this to me, but flash has always worked for me. 
especially after I added xlib plugin support for mozilla/xlib port, flash worked
remotely, too, but someone decided to let the xlib plugins patch just rot


    
    

    
  
*** Bug 114290 has been marked as a duplicate of this bug. ***

    
    

    
  
pocemit: You mean this can be fixed by checking in a patch that already exists? 

    
    

    
  
happens also with vnc. Error is: Gdk-ERROR **: BadMatch (invalid parameter 
attributes)  serial 62 error_code 8 request_code 129 minor_code 3
happens also with netscape and opera

    
    

    
  
Can you please post an output of xdpyinfo ?
I assume this issue occurs if the first visual is not the default visual for the
screen (raw guessing) ...

    
    

    
  
with help from Roland Mainz I found out that running the vnc server with
"vncserver -depth 16" or "vncserver -depth 24" solves the issue of
browser crash in case you visit a page with flash at least for Netscape 
Communicator 4.77 and Opera 6.0 TP2. Mozilla is still crashing, this time 
with 

/usr/local/mozilla/run-mozilla.sh: line 72: 28154 Segmentation fault      $prog 
${1+"$@"}

(for -depth 16)
and 

/usr/local/mozilla/run-mozilla.sh: line 72: 28444 Segmentation fault      $pro
g ${1+"$@"}

(for -depth 24)

    
    

    
  
now (I didn't change my mozilla in the last days, so I don't know what caused 
this) mozilla with VNC crashes only when reloading a page with flash or going 
from one page with flash to another page with flash. The first flash page is
displayed well. The error message when crashing is:

/usr/local/mozilla/run-mozilla.sh: line 72:  1255 Segmentation fault      $prog 
${1+"$@"}

this happens only with mozilla. Opera (with the same plugin) works fine.

    
    

    
  
*** Bug 110248 has been marked as a duplicate of this bug. ***

    
    

    
  
Using 2001122108, Kernel 2.4.4 and XFree 4.0.3 mozilla crashes with an
errormessage combarable to comment #44, but looking to the main window it seems
like mozilla sleeps a little while and after that it works fine.

    
    

    
  
Don't know if it's important in this context but Netscape 6.2.1 based on Gecko
20011126 works fine

    
    

    
  
I may have a fix for this issue, but it depends on the work in bug 112635 (which
is waiting for sr= since december... ;-( ) ...

    
    

    
  
Roland, since your fix for bug 112635 has been checked in, could you post your fix
for this bug here ? Thanks



    
    

    
  
This is what I get if I load www.tomshardware.com (which usually but not always
serves up flash banners) in a Mozilla run through ssh:

Document http://www.mozilla.org/start loaded successfully
XXX Damage rectangle (2982,840,8219,771) does not intersect the widget's view
(0,0,8218,770)!
XXX Damage rectangle (0,0,8233,785) does not intersect the widget's view
(0,0,0,0)!
pldhash: for the table at address 0x0x420d6364, the given entrySize of 28
probably favors chaining over double hashing.
###!!! ASSERTION: frame was not removed from primary frame map before
destruction or was readded to map after being removed:
'!PL_DHASH_ENTRY_IS_BUSY(entry) || entry->frame != aFrame', file
/u/jaggernaut/nscp-src/mozilla/layout/html/base/src/nsFrameManager.cpp, line
1003
###!!! Break: at file
/u/jaggernaut/nscp-src/mozilla/layout/html/base/src/nsFrameManager.cpp, line
1003
###!!! ASSERTION: frame was not removed from primary frame map before
destruction or was readded to map after being removed:
'!PL_DHASH_ENTRY_IS_BUSY(entry) || entry->frame != aFrame', file
/u/jaggernaut/nscp-src/mozilla/layout/html/base/src/nsFrameManager.cpp, line
1003
###!!! Break: at file
/u/jaggernaut/nscp-src/mozilla/layout/html/base/src/nsFrameManager.cpp, line
1003
###!!! ASSERTION: this doesn't do anything: 'NS_UNCONSTRAINEDSIZE !=
aReflowState.availableWidth', file
/u/jaggernaut/nscp-src/mozilla/layout/html/table/src/nsTableFrame.cpp, line 1958
###!!! Break: at file
/u/jaggernaut/nscp-src/mozilla/layout/html/table/src/nsTableFrame.cpp, line 1958
For application/x-shockwave-flash found plugin
/u/jaggernaut/nscp-src/debug/dist/bin/plugins/libflashplayer.so
LoadPlugin() /u/jaggernaut/nscp-src/debug/dist/bin/plugins/libflashplayer.so
returned 41c63c68
About to create new ws_info...
About to create new xtbin of 468 X 60 from 0x8388140...
About to show xtbin(0x8387cc0)...
completed gtk_widget_show(0x8387cc0)
About to create new ws_info...
About to create new xtbin of 468 X 60 from 0x8388140...
About to show xtbin(0x82af0f8)...
completed gtk_widget_show(0x82af0f8)
###!!! ASSERTION: this doesn't do anything: 'NS_UNCONSTRAINEDSIZE !=
aReflowState.availableWidth', file
/u/jaggernaut/nscp-src/mozilla/layout/html/table/src/nsTableFrame.cpp, line 1958
###!!! Break: at file
/u/jaggernaut/nscp-src/mozilla/layout/html/table/src/nsTableFrame.cpp, line 1958
###!!! ASSERTION: this doesn't do anything: 'NS_UNCONSTRAINEDSIZE !=
aReflowState.availableWidth', file
/u/jaggernaut/nscp-src/mozilla/layout/html/table/src/nsTableFrame.cpp, line 1958
###!!! Break: at file
/u/jaggernaut/nscp-src/mozilla/layout/html/table/src/nsTableFrame.cpp, line 1958
For application/x-shockwave-flash found plugin
/u/jaggernaut/nscp-src/debug/dist/bin/plugins/libflashplayer.so
bash$

I can't reproduce this if I ssh to localhost.

Roland, you had a patch for this?

    
    

    
  
jag:
My fix simply uses the first visual as argument for the plugin instead of using
the visual obtained from the GDK functions.
This fixed the first problem (de facto we have two issues).
But that does not fix the 2nd one - BadMatch X errors in SHM code of the plugin.

Does anyone know how the MIT-SHM support of the Flash plugin can be disabled ?

    
    

    
  
*** Bug 123600 has been marked as a duplicate of this bug. ***

    
    

    
  
This really should get it's priority moved up - with LTSP, X terminals are
becoming increasing popular and cost-effective.  We rely on X terminals heavily
here at the college...

    
    

    
  
  I agree with the previous post - we are using LTSP terminals either and we 
had to disable flash. (It's not that i like flash pages so much, but right now 
everybody and his uncle makes pages viewable only with flash enabled...) 
Actually i've found this thread recently, while we have this problem for more 
than a year now :-(. There were two comments (#48 and #49) which made me 
believe that this bug is about to be fixed, what hapened to the fix since the 
other bug (112635) was checked in?

    
    

    
  
I agree with the LTSP-argument.
The company I work for was planning to deploy a small number of ltsp-setups, but
this problem made my boss conclude linux was just not ready yet for such
setups... we just can't support systems that can't handle flash. 
The project is now frozen as a result... that is not hurting our business at
all, but it would have been a nice feat.
I already suggested setting the priority to critical in comment #27.

    
    

    
  
Nominating for Mozilla1.0 and nsbeta1. Raising severity to blocker as it looks
like it blocks may people from deploying Mozilla on X terminals. :(

pocemit, are you still working on this? If not, lets reassign.
Severity: normal → blocker
Keywords: mozilla1.0, 
          
            nsbeta1

    
    

    
  
I still have problems with the Flash5 plugin on Solaris. I have a patch for the
Xlib Mozilla (based on the new code introduced in bug 104166; a port to the
GTK+/GDK-based Zilla is possible) which makes all plugins working - except
Flash5...

Just for the log - we have at least two bugs here:
1. Plugins causing X errors because some expect that the visual in the plugin
context is the same as the root windows visual - which is not true for our
current code (my fix is to deliver the plugin what it wants... =:-)
2. Flash5 plugin causing X errors in plugins code XPutImage()/XShmPutImage()
code

[2] Is still a mystery for me, it happens with both custom visuals and the root
window's visual.

----

Question:
Where can I find the "original" NS4.x plugin support code (URL) ?

    
    

    
  
*** Bug 119656 has been marked as a duplicate of this bug. ***

    
    

    
  
I'm wondering if patch for bug 116924 will not fix this bug ?

    
    

    
  
the fix for bug 116924 is a good step to do a right thing on remote X display,
but this problem still exists:( 
with patch applied from bug 85959 I'm crashing with stack trace
#0  __libc_free (mem=0x43082008) at malloc.c:3136
#1  0x42ee2215 in ?? () from /u/serge/plugins/linux/libflashplayer5.so
#2  0x4225b149 in nsObjectFrame::Destroy (this=0x870fe68,
aPresContext=0x86ad3b0)
    at nsObjectFrame.cpp:673
#3  0x423a9a4f in nsFrameList::DestroyFrames (this=0x8706b20,
aPresContext=0x86ad3b0)
    at nsFrameList.cpp:130
#4  0x4221e30c in nsContainerFrame::Destroy (this=0x8706aec,
aPresContext=0x86ad3b0)
    at nsContainerFrame.cpp:138
#5  0x42251337 in nsLineBox::DeleteLineList (aPresContext=0x86ad3b0,
aLines=@0x87066fc)
    at nsLineBox.cpp:311
#6  0x42207deb in nsBlockFrame::Destroy (this=0x87066c0, aPresContext=0x86ad3b0)
    at nsBlockFrame.cpp:328
#7  0x42205e1d in nsAreaFrame::Destroy (this=0x87066c0, aPresContext=0x86ad3b0)
    at nsAreaFrame.cpp:168
...
and address mem=0x43082008 looks very suspicions to me

    
    

    
  
These X crashers are ugly; Troy, we've "plussed" this bug for Netscape purposes,
which means we're keen to see it fixed in a next release.  Please help out with
suggestions.
Keywords: nsbeta1 → nsbeta1+

    
    

    
  
*** Bug 130230 has been marked as a duplicate of this bug. ***

    
    

    
  
I think I've run into this bug as well in 0.9.9 (bug 130663). Local X though
(with a large window), no exported display.

Perhaps we could change the Summary to "Flash crashes Mozilla"? It is certainly
more prevelent than just exported displays.

I don't see how Moz 1.0 should ship without working Flash.


    
    

    
  
I have also crashes with exported display.
This makes mozilla usless on X-terminals.
I hope it will be fixed in 1.0.

    
    

    
  
Refering to comment #56, shouldn't the Target Milestone be set to mozilla1.0?

    
    

    
  
-->giving bug to Serge

Does anyone have any background info on what's causing this bug? Do we need to
contact Macromedia?
Assignee: timecop → serge
Status: ASSIGNED → NEW

    
    

    
  
putting back into moz1.0
Target Milestone: --- → mozilla1.0

    
    

    
  
I tried with Opera, Konqueror, Netscape 4, Mozilla:
this crash is universal.

Wouldn't it suggest that we are faced with an unsolvable
problem? (At least for flash player 5. And only god knows
what punishment we will get by player 6...)

(BTW, only Konqueror was capable to catch it, and not crash
the browser, just leave the place of the flash content
grey. I consider it a _very_ nice feature: not to die if
a 3rd party **** dies. The others all crashed along with the plugin.
Wouldn't at least that be implemented in mozilla, that kind of stability?
Solves the problem, partly of course...)





    
    

    
  
I really don't think Macromedia is willing to help us by fixing this bug. I've
already complained to their development team and they say they're always
"considering" plataforms for their products, what sounds no good. They also told me
to contact the "browser's tech support". Perhaps they didn't know what I was
talking about. I wonder if the guy who answered by e-mail was really a developer.

    
    

    
  
We've got exception handling on Windows:
http://lxr.mozilla.org/mozilla/source/modules/plugin/base/src/nsPluginSafety.h
Maybe someone wants to hack UNIX?


    
    

    
  
It's trivial to catch SIGSEGV, SIGBUS, SIGILL, and others, but what if the
plugin corrupts the malloc heap?  Oh well.

Want me to attempt a patch?

/be

    
    

    
  
From the redhat7.1 `man sigaction`:

       According  to  POSIX,  the behaviour of a process is unde­
       fined after it ignores a SIGFPE, SIGILL, or SIGSEGV signal
       that  was not generated by the kill() or the raise() func­
       tions.  Integer division by zero has undefined result.  On
       some  architectures  it  will  generate  a  SIGFPE signal.
       (Also dividing the most negative integer by -1 may  gener­
       ate  SIGFPE.)   Ignoring this signal might lead to an end­
       less loop.

Not sure how useful this will be on any given POSIX-conforming OS -- cc'ing
shaver and jdunn.

/be

    
    

    
  
Konqueror does the job, of course. When crashing with the Flash-Plugin, it shows
a messagebox with a hint that the signal 11 (SIGSEGV) was send by the
nspluginviewer. It seems to me Konqueror crashes more often then Mozilla ;-). 
Maybe Baldvin is right and the solution of the problem can be found outside of
Mozilla.

    
    

    
  
A guy at Macromedia was kind enough to finally answer to
my questions (Troy Evans, thanks for him!), here is 
some quotation from Q&A:

> 1st: the exported X display-crash is not a mozilla issue
> since it crashes ns4, opera, konqueror and mozilla.
> (http://bugzilla.mozilla.org/show_bug.cgi?id=58937)

> --- We are working on this, and will fix this in the near future

I think, this means they will do their part. Even then, I think
it is not OK to be so weak that if a plugin crashes, we crash.
This is simply not good, because now here is a promise that
the issues with this particular plugin will be solved, but mozilla
should make clear for all plugins in the future when they crash,
that not mozilla crashed, but the plugin! If the user see that
mozilla crashes, he will not think that it can be a plugin,
he will think that mozilla sucks... Which is not the case!

    
    

    
  
So what doing with this issue? Just putting it into the release notes for
moz1.0? Will someone hack this for Unix until freezing?

    
    

    
  
adding ADT3 to status whiteboard, as per discussion with beppe.  this happens in
a remote linux environment, which is not a typical user setup.
Whiteboard: [ADT3]

    
    

    
  
We are working on a project using X terminals and we tried several solutions to
get Flash working. The only result we have is that Mozilla-0.8.1 (old Ximian
package for Debian) displays Flash correctly, but segfault when you leave the
page. Is there a chance to see this bug resolved one day or another ?

    
    

    
  
I 've hacked the code to catch signals like SIGSEGV, SIGILL an so on. Signals
which are thrown by the plugins are easy to catch, but it seems like the Flash
plugin doesn't send a signal when crashing :-(.

    
    

    
  
*** Bug 126510 has been marked as a duplicate of this bug. ***

    
    

    
  
Does anyone have a clue about when is macromedia going to fix their plugin?
This is bug that really hurts (having free open access place based on X
terminals and disappointing users is not good)...

    
    

    
  
Hi,
BTW, how many people have submitted bug report to macromedia about this issue?
When I was looking at their mailing list, and people were asking for new flash
plugin, or shockwave, the response from macromedia was, that they don't have
enough resources to do it, and only a few people are using something else than
IE/Win.


    
    

    
  
In many ways it would be better if Macromedia simply withdrew support for the
Linux flash completely, rather than having this buggy one.

If anyone really needs this to work badly, and are prepared to spend a bit of
money ($25), as a workaround you can always use CodeWeaver's Crossover plugin to
run the Windows version of Flash on Linux - works pretty well.

Damian

    
    

    
  
> If anyone really needs this to work badly, and are prepared to   > spend a bit of money ($25), as a workaround you can always use   > CodeWeaver's Crossover plugin to run the Windows version of   > Flash on Linux - works pretty well.    Tried this.  This is not an option for most of my X thin clients because CrossOver Wine  requires the X RENDER extension in order to render fonts.  BTW, has anyone noticed that Macromedia released a new Flash plugin version last month?  It doesn't seem to crash Netscape anymore over exported X, but it seems to crash Mozilla quite often in both local and remote X.  Has anyone experienced this with the new Flash version? 

    
    

    
  
Do you thaink about version 5,0,48,0 ?

Using this version mozilla crashes every time on remote display, it hasn't
crashed on local.

    
    

    
  
Seeing crashes on local X with the new version of the Flash-plugin, too :-(.

    
    

    
  
*** Bug 137807 has been marked as a duplicate of this bug. ***

    
    

    
  
I think that if macromedia removes support for Linux player, that would be even
worse than it is now when we have at least half working version.

Anyway, is anyone in contact with macromedia, are they paying attention at all?
Is the problem really so deep?

There is another thing... someone did a flash player library that works quite
bad, but at least it works sometimes, unfortunately it also crushes a lot
http://www.swift-tools.com/Flash

maybe someone could develop it further, it is under GPL...

    
    

    
  
I was trying to get an access to Macromedia Flash Player 5 Source Code SDK
http://www.macromedia.com/software/flashplayer/licensing/sourcecode
Thanks to TSnedeker@Macromedia.com I got a response and  was allowed to post 
into this bug report: 
"The Macromedia Flash Player team is looking into this issue. 
If you have any questions you can contact:
Tucker Snedeker, TSnedeker@Macromedia.com or send email to 
wish-flashplayer@macromedia.com"

    
    

    
  
We're using LTSP which is a very good example of exported X displays.

We're using the same flash plugin (v5.0r47) for both netscape 4.78 and mozilla-0.9.9

Pages with flash content work in Netscape, but crash mozilla.

    
    

    
  
For us this is something that is important to fix.  We're keen to see LTSP being
used in schools and government, but without working flash support it's not going
to be an easy sell.

Unfortunately, whilst flash isn't used on every site, it's used on enough sites
that the browser crashing is a serious impediment.  Given that most desktops
only really use office software, a web browser and and email client, this really
does need to be addressed.

    
    

    
  
I concur.  The single greatest problem of our xterminals (similar to LTSP) thin 
client deployment in Honolulu, Hawaii is the inability to use Flash.

The latest update of Flash for Linux seems to crash local Mozilla too. =(

    
    

    
  
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-

    
    

    
  
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+

    
  
Blocks: 139820

    
    

    
  
Here using LTSP. On server everything works fine (flash plays and so on). On remote terminals Mozilla crashes and so Konqueror (KDE2.2 and KDE3). So this is not only Mozilla problem. 

    
    

    
  
Just to repeat myself again and again:
We face (at least) two _different_ bugs which should be split into two seperate
bugzilla bugs. Complaining here does not help.

bug 1: Mozilla's uses a visual which may be different than the default visual
(for example: default visual is 8bit PseudoColor, but GDK (Mozilla uses libGDK)
chooses a 24bit TrueColor visual).
Suggested workaround: Use Mozilla's Xlib toolkit mozilla which supports the
"-visual" option. Passing the ID of the default visual should cure this issue.
Suggested fix: Pass default visual to plugins

bug 2: Macromedia Flash does not handle the MIT-SHM extension correctly in the
case that the extension is available but the client runns remotely (this is the
LTSP case).
Suggested workaround: Compile the LTSP Xserver _without_ the MIT_SHM extension
and the problem should go away (unless the plugin code does not handle that case
correctly either).
Suggested fix: Fix the stupid plugin code.

    
    

    
  
Are you sure that the Macromedia Flash plugin is using MIT-SHM?  On my 
xterminals (similar to LTSP) network the Flash plugin works in certain browsers 
for a while then crashes.  In Netscape 4.7x it is okay in the first page view, 
but it subsequently segfaults the entire browser when you view another page 
with Flash.  Opera 6 TP2 used Flash just about perfectly, except when I close 
Opera a process "operamotifwrapper" uses 100% of the server CPU until it is 
manually killed.

If it used MIT-SHM, it shouldn't be able to display anything on remote X right?


    
    

    
  
moving to the next milestone
Target Milestone: mozilla1.0 → mozilla1.0.1

    
    

    
  
*** Bug 140542 has been marked as a duplicate of this bug. ***

    
    

    
  
This bug is mentioned in release notes but the link point to an unrelated bug in
bugzilla.

    
    

    
  
I have already reported this as a documentation problem. It is a typo.
Furthermore, the bug is three times in the last Release Notes.


    
    

    
  


  
This is an email petition of affected sites.  Listed are 481 sites for a total
of 126539 users who are unable to view sites using Flash because of this bug. 
This list only represents LTSP users and not even all of them.	Unreported LTSP
users and users of other `thin' clients, and/or other users of remote X make
the actual number of affected users even greater.  Thanks to Jim McQuillan for
gathering this data.

    
    

    
  
There isn't anything that can be done to resolve this via the netscape/mozilla
code. The fix would be within the Flash code.
Whiteboard: [ADT3] → [FLASH CODE]

    
    

    
  
I didn't see flash.com and macromedia.com on this list.  I would think that they
should definitely be on this list.  :-)


    
    

    
  
According to some, the flash version that comes with mandrake actually runs on
remote desktops! I do not think they got the solution, but it's worth knowing.

    
    

    
  
Well, I don't know where you saw that flash doesn't crash on Mandrake ???

It does crash (I know, I packaged both flash and mozilla for MandrakeSoft)

    
    

    
  
I understand this is most likely a Macromedia problem.  But, I have no idea how
to apply pressure to them, to get this fixed.  Any ideas how we can get them to
pay attention to this ?  Maybe we could twist their arm, and get them to
open-source the flash plug-in, then we could fix the damn thing ourselves.

    
    

    
  
:) don't get physical... Pls check serge's comment here in this same bug.
http://bugzilla.mozilla.org/show_bug.cgi?id=58937#c88

    
    

    
  
How can I add myself to the e-mail petition of LTSP sites affected by this bug?

    
    

    
  
RE: How can I add myself to the fix-the-flash petition:
Go to : www.ltsp.org

    
    

    
  
beppe wrote:
> There isn't anything that can be done to resolve this via the netscape/mozilla
> code. The fix would be within the Flash code.

I assume you did not read my comments in this bug, did you ?
We can do something against _ONE_ of the _TWO_ problems. We may not be able to
cure it completly but we can - at least - kill one issue.

    
    

    
  
yes Roland I have read your comments and everyone else's commetns in this bug,
based on the assessment of the plug-in team the resolution for this bug is
corrective action needs to come from the vendor.

If you believe this is comprised of two issues -- then do the following
1. modify the Summary of this bug to reflect one of those issues, enter a
comment specifically defining the one issue this bug should track. Then assist
in helping resolve that issue if you can.
2. open a new bug, in the comment specifiy it is a spinoff of this bug,
speicifically detail the issue. Then assist in helping resolve that issue of you
can.

    
    

    
  
Ok, _something_ is wrong in Mozilla.  I just tested Flash plugin 5.0r48, and it
works fine remotely in NS4.79, but crashes Mozilla.  I suspect Roland Mainz may
be right about the visual problem, but that's just my guess.  My only test was
to verify the version in about:plugins, then visit flash.com.  So, is NS4.79
doing anything else interesting that Mozilla isn't?

    
    

    
  
>So, is NS4.79 doing anything else interesting that Mozilla isn't?
surely its 2 completely different apps....
I'm more interesting what flash plugin is doing & why it crashes in
#0  __libc_free (mem=0x43082008) at malloc.c:3136
#1  0x42ee2215 in ?? () from /u/serge/plugins/linux/libflashplayer5.so
#2  0x4225b149 in nsObjectFrame::Destroy (this=0x870fe68, 
aPresContext=0x86ad3b0)
...
it's possible the cause of the crash is some flash hack around 4.x code,
similar to "form" widget hack discovered & fixed by rusty.lynch@intel.com
http://bugzilla.mozilla.org/show_bug.cgi?id=31012#c5
>Ok, I now have the source to Macromedia's Linux Flash plug-in and know
>why the Flash plug-in is crashing the browser.
>In SetWindow() the plug-in is trying to set an event handler for window 
>resizes.  There is an assumption that one of the widget ansestors (and the 
>widget to watch for resizes) is named "form".  The code walks through each of 
>the parent widgets looking for the "form" widget, but never considers that 
>eventually XtParent(somewidget) will return null, and then dies trying to 
>strcmp on a null string.
>I have never seen any Netscape plug-in documentation that promised a "form" 
>widget.  Is Macromedia's assumption valid?  Are there any other common 
>assuptions that the legacy wrapper should consider?

BTW: do not ask him for a source code please, I already did, he does not have it 
any more. 
Also see my comment #88 for macromedia response on my request to get Flash 
Player 5 Source Code SDK:(

    
    

    
  
Having finally read through this bug, I'm inclined to agree that
it's probably the same problem as bug 135655.  But as I said in
that bug, I'm NOT running on a remote display: I'm only running
on a non-default screen.

I have two screens on this display (not Xinerama, but :0.0 and :0.1).
Screen :0.0 is an 8-bit PseudoColor display, and :0.1 is a 24-bit
TrueColor display.  Mozilla is running on :0.1, the TrueColor screen
(that's what $DISPLAY is set to.)  XShm works on both screens, and
DRI/OpenGL/etc work on :0.1 (the TrueColor screen.)

As Roland said up in comment #95, there seem to be two bugs here.

 - The first is that Mozilla is handing the Flash plugin the wrong Screen
   and/or Visual (probably always using screen 0 instead of DefaultVisual.)
   This is causing Flash to crash.  Netscape 4 does not have this bug, 
   which is why the same Flash plugin continues to work fine in NS4 on
   my system: this bug is in Mozilla, not in Flash.

 - The second problem, that people on *remote* displays are experiencing,
   seems to be a bug in Flash, as someone from Macromedia acknowleged 
   back in comment #74.  That problem is that they're using XSHM 
   improperly.

It's pretty difficult to implement XSHM properly and have your program
still function on remote displays that may or may not support the
extension for local clients.  You have to do things in just the right
order, and catch X errors at just the right times.

In case anyone from Macromedia is reading this, I recommend you snarf my XSHM
code from xscreensaver: download it from http://www.jwz.org/xscreensaver/ and
look in xscreensaver/utils/xshm.c.  That handles XSHM on all manner of systems,
local and remote, manages shared segments properly including releasing them in
the case of abnormal exits, and has been field-tested on just about every
X-capable system that has existed over the last ~10 years.  It works, and it's
BSD-licensed, so feel free to copy it.


    
    

    
  
One additional note ragarding Netscape 4.77 and the apparently working flash plugin: - On a remote display the Flash Plugin seems to work in Netscape 4.77 ONLY if   Netscape's build-in JRE 1.0.8 is used. Using any Java plugin like JRE 1.3.0   will cause Netscape to crash as well. That's probably nothing the Mozilla developers can do about and the Macromedia guys will surely know it but it was not yet mentioned here so I thought it could not do any harm if I added it...  Greetinx,    Gunter Ohrner 

    
    

    
  
Regarding #115

This is a separate issue (with jre 1.3.X for linux). On most linux systems, there 
is a libc related issue with java.

You can work around it by having ulimit -s 2048 before calling java (or
Netscape, or any process that starts java).
These jdk/jre will not work reliably if the stack is greater than 2048 KB.


    
    

    
  
*** Bug 122090 has been marked as a duplicate of this bug. ***

    
    

    
  
For those who are wondering how to setup Flash to work on a remote display,
there is a trick :) 

You have the XDM server, Marley. 
You have the Xterminal, Picasso.

user BOB uses Picasso to into Marley.
BOB's .xsession looks for a running Xvnc process owned by BOB.

if there is a running process {
 execute vncviewer -fullscreen attaching to the running Xvnc.
}

if there is not a running process {
 execute Xvnc, grab the display name.
 execute vncviewer -fullscreen attaching to the running Xvnc
}

    
    

    
  
*** Bug 147096 has been marked as a duplicate of this bug. ***

    
    

    
  
Has anyone heard anything from Macromedia?  This is very annoying!

    
    

    
  
This affects probably a *lot* of people. Typically, many users within an
organization
are using the same Mozilla installation. Only some of them use Mozilla
on remote X displays (in our organization, all Solaris users do this, since
there is no mozilla Solaris build). So in order to avoid problems for some
flash cannot be installed at all.
A nice workaround to remedy the situation is to be able to individually
enable or disable the flash pluging: those affected disable it, all others
can use it. So a checkbox similar to "Enable Java" would greatly enhance the
situation. Even better, if mozilla could find out if it runs on a remote
display (wouldnt that be easy by checking the DISPLAY environment variable),
it could automatically disable the flash plugin as long as it has this bug.

    
    

    
  
[NOT A MOZILLA ISSUE THIS IS A FLASH ISSUE -- NOT MOZILLA]

-->aruner
Assignee: serge → aruner
Severity: blocker → critical
Whiteboard: [FLASH CODE] → [NOT A MOZILLA ISSUE THIS IS A FLASH ISSUE -- NOT MOZILLA]
Target Milestone: mozilla1.0.1 → Future

    
    

    
  
This IS mozilla issue.
It shouldn't crash if plugin crashes.

    
    

    
  
This is NO Mozilal issue !
Mozilla can't do anything if a plugin, that runs in the same process as mozilla
,crashes.


    
    

    
  
> Mozilla can't do anything if a plugin, 
> that runs in the same process as mozilla

... and therin lies the problem. It would certainly be difficult to fix though.

Again, note that Konqueror _using_ _Mozilla_ _plugins_ does NOT get crashed!

    
    

    
  
Right, which is why we should follow Konqueror's lead and run 4.x plugins out of
process, on Unix and any other platforms that would permit.  There's a bug on
that already filed, I'm sure you can find it.  Not sure if anyone in plugin-land
is working on it, but one of the strident MOZILLA MUST NOT BE BROKEN BY CRASHY
PLUGINS! people here could always step up and do the work.

(Of course, even out of process, plugins would run as the user in question, and
could therefore cause Mozilla to die, but it's harder for them to do it by
accident.)

    
    

    
  
There are plans to separate plugins out of Mozilla process. I think this bug can
be close as 'Flash crashes' is not a Mozilla issue, while 'Mozilla crashes'
definitely is and it is already covered.

    
    

    
  
Won't all of you who are arguing over whether this is or isn't a bug please
scroll back and read comment #114.

There are *two* bugs here, and at least *one* of them is fully and undeniably in
Mozilla, not in the plugin.  This is easily demonstrated by the fact that the
*very same plugin* will crash Mozilla but will not crash Netscape 4.7x.

    
    

    
  
*** Bug 145202 has been marked as a duplicate of this bug. ***

    
    

    
  
Is there any feedback from macromedia regarding a fix for this bug?

    
    

    
  
Since this bug report has been used to describe two seperate bugs, I've entered
a new report, bug 154427.

THIS bug describes the problem that Flash crashes when $DISPLAY is set to a
non-local host, due to XSHM bugs in the Flash plugin itself.  That problem can
likely only be fixed by Macromedia.

Bug 154427 describes a bug in Mozilla that causes flash to crash when $DISPLAY
is anything but :0.0.  That is, on a multi-head machine, the Flash plugin causes
Mozilla to crash if Mozilla is being run on any screen except screen 0.  Bug
154427 is a bug in Mozilla, not in Flash.

Summary: Flash crashes with exported X display → Flash crashes on remote display (XSHM problem in Flash plugin?)

    
    

    
  
Mh, well, the Plugin DOES work with netscape 4.77 on a remote display (X-Terminal) if no java plugin is installed. (App-Server Linux IA32 Intel DualCeleron + XFree 4.2.0, "X-Terminal" Linux IA32 AMD K5 + XFree 4.2.0) 

    
    

    
  
If that's true, that's what we call a smoking gun: that makes this a bug in
Mozilla, not in Flash.


    
    

    
  
If someone is interested in getting 33.33333% of this bug fixed then please file
a bug "Mozilla plugin API passes the wrong visual to plugin when screen's
default visual!=Mozilla's window visual" and assign it to me...

    
    

    
  
concerning #133:  I just tried to verify my first report of this problem (comment #115, same  configuration as in comment #132) to be absolutely sure and now I don't understand anything any more... On my system it DOES work with Communicator 4.79, but - it seems to work with Mozilla 1.0.0, too?!? It does not work perfectly as if I close Mozilla while displaying a flash movie one mozilla-bin process gets stuck, eating 100% CPU, but playing the flash movies works just fine... The Flash plugin installed is r48 and the Java plugin installed is the one from Sun's J2RE SDK 1.4.0. Can anybody explain that to me, please? It has NEVER worked before for me on a remote display before... 

    
    

    
  
About comment #135: Mozillia *plays* flash plugins with the current flash plugin
on 'remote' displays.  When you *then* go visit another page, libflashplayer.so
'mishandles' the MIT XSHM run down and crashes in free(), and takes mozilla down
with it.  That is the bug (two bugs: a flash bug (mishandling the MIT XSHM
extension in a remote display) and a mozilla bug (mishandling a crashed plugin)).

There is the *separate* bug in mozilla not handling a multi-head system (display
is not on screen #0).  But that is now in a different bug report.

    
    

    
  
I am new to using Red Hat Linux(version 7.3)and am amazed at what you can do 
with it versus other OSes.  Can someone please provide detailed instructions as 
to how to reproduce this problem?  The steps listed aren't very clear to me, so 
I would appreciate a little more information (for instance, how do I disable X 
access control, what do I need to do to export the display, and is logging in 
to a remote box easy as telnetting to the IP?). Any and all assistance is 
appreciated..... 

    
    

    
  
setenv DISPLAY 127.0.0.1:0 or an appropriate for your shell command
is enough to repro the crash.

    
    

    
  
Whats the status on this?  I am able to use Opera 6.02 with the Flash player,
but Mozilla crashes.

If it works in Opera and not Mozilla, how can it be a Flash bug?  

Please this is a serious bug, I am getting ready to deploy remote x displays to
several thousands desktops, and would prefer to use Mozilla, but seeing as this
has been open since 2000, and no Mozilla people are fixing it, guess Opera is
the choice I have to make :(



    
    

    
  
I too was able to get Flash to work in Opera 6 TP2 and 6.0, but when I close
Opera it would leave a "operamotifwrapper" process running using 100% CPU.  Does
Opera have this fixed in 6.02?

    
    

    
  
No problem with "operamotifwrapper" in Opera 6.02 on rh 7.3

Opera only supports Netscape 4x plugins, is their anyway to trick Mozilla to see
the flash plugin as a Netscape 4x plugin?


    
    

    
  
Update for everyone:

Flash crashes on X remote display

1) Linux Netscape 4x with flash plugin ver 4x and 5x, no crash
2) Linux Mozilla 9.x and 1x (all I've tested) Netscape 6 with flash plugin ver
4x and 5x, crash
3) Linux Opera 6.02 with flash plugin ver 4x and 5x, no crash.
4) All Linux browsers with the Codeweavers plugin and Windoze Flash ver 6, no crash

**** Opera 6.02, only supports Netscape 4x plugins.
**** After talking with Codeweavers, they also use the Netscape 4 plugins.

==== The flash player does work on remote x displays, but only when used as a
Netscape 4x plugin.

So I'm a little lost on how this is not a Mozilla bug, as that is stressed so
heavily in the Bugzilla Status Whiteboard.

So how can we force Mozilla 9x/1x to see the flash plugin as a Netscape 4x
plugin?  Or fix the problem?

    
    

    
  
It's still possible that this is not a Mozilla bug. Look at the comment #113 by
serge.

    
    

    
  
>> It's still possible that this is not a Mozilla bug. Look at the comment #113 by
>> serge.

Even if the flash plugin was riddled with bugs, the fact that *Mozilla* crashes
is a Mozilla bug.  It is really a bug that Mozilla is "sensitive" to plugin
crashes.  It ought to be treating plugins as "untrusted" code (no matter *where*
the plugin came from).  I understand that work is in progress to run plugins in
a separate process environment (or something).  I believe that konqueror does
this, for example.

    
    

    
  
Flash crashing on remote display is a Flash problem. Mozilla not surviving a
plugin crash is a Mozilla bug indeed, you are right. And we have it already
filed: bug 156493. But I still beleive that that bug and the present bug are
about different things.

    
    

    
  
<< It's still possible that this is not a Mozilla bug. Look at the comment #113 by
serge.

That post didn't help any, someone posted that they knew a fix, but does not
have the code or the fix?

Flash works on remote x displays.  But only as a Netscape 4 plugin.  If it works
in 1 one and not the other, why not look at Mozilla 1.0?  When using the
CrossOver  Plugin (which is a Netscape 4 plugin) it works fine, stress on
Netscape 4 plugin.

av@netscape.com are you 100% sure that its not a problem with how Mozilla 1.0
handles plugins?  The flash plugin works on a remote x display when used as a
netscape 4 plugin?  It is the same plugin, I didn't download a different one,
Opera reads it right out of the Mozilla Plugins directory and works like a champ.  

    
    

    
  
Bill Cavalieri, I am 99.99% sure this is a flash bug, it works with 4.x netscape
client, which is Xm/Xt based app, and  flash plugin also is Xt based,  but
mozilla does not use  Xt widget set for its UI, it only needs Xt  to support
legacy plugins, but if plugins use some hack we do not aware of, we never be
able to fix the problem. See my comment #113 about flash "form" widget hack. How
do you think it would be possible to discover that flash is looking for that
particular widget w/o having the flash source code? If you want an example of
another flash "feature" which corrupts the stack in mozilla but does well in 4x,
see bug 149336

    
    

    
  
I already mentioned this before (Comment #32 2001-09-19 05:59), the flash-plugin
works fine for me when using X-Winpro as X-server. ( I've been using it
successfully for about two years on several machines now) With the default
settings of X-WinPro the flash plugin crashes as described in this bug report.
In X-WinPro there is one setting that solves the problem. I don't know what is
really does but after changing the Image Format from LSB into MSB in the
XSetting of X-WinPro the flash-plugin doesn't crash anymore. So if any of you
could look into this, and find out what the Image Format means and does, I think
this bug can be solved.
Besides chaning the Image Format within X-WinPro, make sure you have the right
resolution and color-depth set in your client, I think this is relevant to.

    
    

    
  
What's terrifying is that this is _still_ a flash bug after a year and a half.

I can confirm this with moz 1.0 and Debian 3.0/woody on both client and server.
Anybody know of an alternative flash plugin? I can even live with a "null"
plugin that prevents flash loading and shuts up the default plugin. 

    
    

    
  
*** Bug 160570 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 153733 has been marked as a duplicate of this bug. ***

    
    

    
  
Hi All,

there's been a lot of dicussion about who's problem this bug is.  This is quite
natural and although fault often needs to be assigned, this bug needs to be fixed.

Is any work being done on fixing this bug?

I'm not capable of fixing this bug, but I do do a lot of work promoting open
source software.  At the moment LTSP has the potential to offer businesses an
enormous TCO saving, but before this can be promoted 100% there's a need for a
standards compliant browser that doesn't **** itself simply because a plugin
doesn't work properly.

I'm making a plea to see this bug taken more seriously.

regards


Rodd Clarkson

    
    

    
  
I couldn't agree with you more, except I think you are really interested in Bug
156493 (except that bug seems to be messed up somehow... I was thinking of bug
62460).

This bug is to get flash itself fixed. That is certainly not for Mozilla to do.

    
    

    
  
Someone mentioned earlier that the Linux Flash plugin works fine in the latest
Opera, but it doens't.  I just tested it with Linux Opera 6.02 on my LTSP
network again.  Just like earlier tests with 6.0 Preview and 6.0 beta, Flash
will work for a while but after you visit a few pages, performance will crumble
to almost nothing.

If you check top, you will find several operamotifwrapper processes using 100%
CPU, even after Opera is closed.  killall -9 is needed in order to make the
entire LTSP server usable again.

While different browsers have varying bad behaviors with the Flash plugin
(Mozilla crash, Netscape crash when loading 2nd Flash page, Opera 100% CPU
usage), what is ultimately at fault here is the Flash plugin itself.

MACROMEDIA, WHY IS THIS NOT FIXED YET?!

    
    

    
  
I don't mean to be overly critical, mozilla is a fine piece of software but...

If a badly written program crashes an operating system, who's fault is it?

It is usually the OS's place to make sure a program does not bring down the
system.  If mozilla took down X windows, we could not blame mozilla.  Because
whatever the exception is, crashing and burning is never an option for a well
designed program.

Mozilla should in my humble opinion...
(i) catch the exception.
(ii) notify the user that the plugin has crashed.
(iii)worse case, tell the user that mozilla will now terminate due to an error.
or best case stop the plugin and allow the user to continue.

Are we going to blame every developer or company who writes bad plugins?  Blame
them for *mozilla* crashing and taking *all* the current windows, mail, news,
etc. with it?

This issue, I believe, is clearly a mozilla issue.  

Thanks,
--Kervin

    
    

    
  
Kervin, I couldn't agree with you more. Unfortunately, all of this discussion
seems to be happening here, rather than Bug 156493 (or similar). There was some
good discussion about how to safeguard Moz from bad plugins a while ago, but
nothing recently.

How do we get people rallied behind Bug 156493, while leaving this bug to flash
specific issues? This bug should not be getting any traffic unless there's news.

    
    

    
  
I do not have the 100% problem with Opera 6.02, and ltsp 3.0.  I have 24
terminals hanging off server, and all running Opera with flash plugin.

using rh 7.3 with 2.4.18-3.

******Netscape 4/Opera no flash problem.  Fix mozilla use, the Netscape 4 way of
plugins.*******

-Bill

Comment #154 From Warren Togami
Someone mentioned earlier that the Linux Flash plugin works fine in the latest
Opera, but it doens't.  I just tested it with Linux Opera 6.02 on my LTSP
network again.  Just like earlier tests with 6.0 Preview and 6.0 beta, Flash
will work for a while but after you visit a few pages, performance will crumble
to almost nothing.

If you check top, you will find several operamotifwrapper processes using 100%
CPU, even after Opera is closed.  killall -9 is needed in order to make the
entire LTSP server usable again.

While different browsers have varying bad behaviors with the Flash plugin
(Mozilla crash, Netscape crash when loading 2nd Flash page, Opera 100% CPU
usage), what is ultimately at fault here is the Flash plugin itself.

    
    

    
  
Flash 5.0.50 for Linux is out, did it fix the problem ? There's no release notes
and I cannot test this myself.
(sorry for the spam)

    
    

    
  
Using http://www.flash.com as a test site and the new Flash plugin, 5.0 r50, and
Mozilla 1.0, no it did not fix the crashing problem.


    
    

    
  
Looks like Macromedia has other problems on their plate right now.  I would
guess that this (remote crashing) bug is probably not at the top of their
priority list if this article is any indication.  Check out this PC World article:

http://idg.net/ic_933538_1794_9-10000.html


    
    

    
  
Maybe if Macromedia just open-sourced their plug in, they would get the help
needed to fix this and all of the security problems.  They could then
concentrate on other stuff, like the software they actually make money on.

    
    

    
  
*** Bug 164025 has been marked as a duplicate of this bug. ***

    
    

    
  
I've heard that this may be fixed in the Flash 6 Linux beta.

    
    

    
  
You heard from someone at Macromedia?

    
    

    
  
Does anyone know of an email address to macromedia support? I have looked around
at their site but have not found it. Maybe put it in "Status Whiteboard"? No
reason being timid.

    
    

    
  
Macromedia haven't released a beta of the flash 6 for linux.

It seems that they are starting a beta testing program but you need to subscribe
and be accepted to test it for them.

    
    

    
  
This is so strange, I dont get it...
Summary: vnc-16-bit ok vnc-8-bin nogo:

client (tightvnc-win and vnc-linux 3.3.3.r1)
Flash5.0 r48 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

Server(linux2.4.18):XF3.3.6(image byte order:LSBFirst)Suse vnc-3.3.3r2-95.rpm

/usr/X11R6/bin/Xvnc :8 -query localhost -once -geometry 1024x768 -depth 16
!!!!FLASH WORKS!!!(inkl reload change page etc):)

/usr/X11R6/bin/Xvnc :8 -query localhost -once -geometry 1024x768 -depth 8
( true colour: max r 7 g 7 b 3, shift r 0 g 3 b 6 Using hextile encoding for
client 192.168.0.2)
!!CRASH!! Mozilla cries: Gtk-ERROR **: BadMatch ( invalid parameter attributes)
serial 61 error_code 8 request_code 129 minor_code 3

OT: Tip, ssh -C is really nice for compression.

    
  
Blocks: majorbugs

    
    

    
  
Flash plugin version 5.0.51 has just been released, and is available here:
<http://www.macromedia.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash&P5_Language=English>

I am experiencing a problem similar to this, so will test the latest plugin
and see whether the problem remains.

    
    

    
  
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed

    
    

    
  
this Gecko 2 reference paper is not available outside ns as far as i can see. ?!

CAn it be released pleese, and a new link provided on the bug

    
    

    
  
I tested the new 9/11/2002 version of Linux Flash 5 on my LTSP network.  It
immediately crashes Mozilla 0.9.9, but Mozilla 1.2a properly displays a flash
page.  Unfortunately, when you attempt to leave that page Mozilla locks up and
uses 100% CPU.  kill -9 is the only way to stop it.  Same thing happens with
Netscape 4.7x.  Opera 6.0.3 it happens too, but their operamotifwrapper is the
process that ends up using 100% CPU.  If you kill it you can successfully browse
another page... until it uses 100% CPU again.

My X servers are running 3.3.6 so no XRENDER support.

So no, this new Flash version is still broken.

Did somebody mention that Macromedia was beta testing Flash 6 on Linux?

    
    

    
  
*** Bug 170482 has been marked as a duplicate of this bug. ***

    
    

    
  
Don't know if anybody tried, but both Netscape 7 and Mozilla 1.x DO PLAY all the
Flash animation on a remote monitor, as long as it is NOT an Linux box :-) Just
tested it on Win98 laptop (8 Mb monitor) with Xmanager (32-bit X11R6 PC X server
from Netsarang), and everything works smoothly: nothing crashed, no CPU problems
etc.

    
    

    
  
It crashes for me with an exported X display to Exceed and Xwin32 4.0 for
Windows, as well as Linux.

    
    

    
  
Just tried 1.2 alpha. It constantly crashes when I use Cygwin/XFree86, but
worked fine with XWin32 5.1. It also crashes when running from remote Linux box.
Could it be bug in XFree86?

    
    

    
  
>> Just tried 1.2 alpha. It constantly crashes when I use Cygwin/XFree86, but
>> worked fine with XWin32 5.1. It also crashes when running from remote Linux
>> box. Could it be bug in XFree86?

2 Questions:

Does XWin32 5.1 use/implement the XSHM extension?

Does it crash with some other random UNIX X server eg a Solaris, OSF/True64,
Irix, or HP-UX system?

It is my understanding that the root of the problem is that the Flash plugin is
 using the XSHM extension/feature of X11 and not doing things properly when the
display is 'remote'.  I understand that messing with the XSHM feature with a
'remote' X display is highly tricky -- possibly not something for the 'faint
hearted' X11 programmer...

    
    

    
  
>Does XWin32 5.1 use/implement the XSHM extension?

How can I verify that?

>Does it crash with some other random UNIX X server eg a Solaris, OSF/True64,
>Irix, or HP-UX system?

I don't have any X servers other then linux, so can't help with that.



    
    

    
  
Anybody knows is it possible (and how) with XFree86 to turn off XSHM extension (when it is built-in extension)? This as I understand could be the workaround to get Flash working on remote terminals. 

    
    

    
  
On Gimp, we have the --no-xshm command line flag, but I don't know if we have
this on mozilla.

    
    

    
  
Output from 'xdpyinfo -ext all' (partial)
with Cygwin/XFree86:

Xlib:  extension "MIT-SHM" missing on display "pavel.netgame.co.il:1.0".
Xlib:  extension "XFree86-DGA" missing on display "pavel.netgame.co.il:1.0".
Xlib:  extension "XFree86-VidModeExtension" missing on display
"pavel.netgame.co.il:1.0".
Xlib:  extension "XFree86-Misc" missing on display "pavel.netgame.co.il:1.0".
Xlib:  extension "XInputExtension" missing on display "pavel.netgame.co.il:1.0".
Xlib:  extension "XINERAMA" missing on display "pavel.netgame.co.il:1.0".

with XWin32:

Xlib:  extension "MIT-SHM" missing on display "pavel.netgame.co.il:0.0".
Xlib:  extension "SYNC" missing on display "pavel.netgame.co.il:0.0".
Xlib:  extension "XFree86-DGA" missing on display "pavel.netgame.co.il:0.0".
Xlib:  extension "XFree86-VidModeExtension" missing on display
"pavel.netgame.co.il:0.0".
Xlib:  extension "XFree86-Misc" missing on display "pavel.netgame.co.il:0.0".
Xlib:  extension "RECORD" missing on display "pavel.netgame.co.il:0.0".
Xlib:  extension "XInputExtension" missing on display "pavel.netgame.co.il:0.0".
Xlib:  extension "RENDER" missing on display "pavel.netgame.co.il:0.0".
Xlib:  extension "XINERAMA" missing on display "pavel.netgame.co.il:0.0".

hope it helps.

    
    

    
  
>> >Does XWin32 5.1 use/implement the XSHM extension?
>>
>> How can I verify that?

Fire up XWin32 5.1 and then connect to a Linux box and start an Xterm.  In the
Xterm type:

xdpyinfo | less -X

You should get lots of info about what the X server (XWin32 5.1) supports.  I
believe you should be looking for "MIT-SHM" or something like that (I think).

>> >Does it crash with some other random UNIX X server eg a Solaris, 
>> OSF/True64, 
>> >Irix, or HP-UX system?
>>
>> I don't have any X servers other then linux, so can't help with that.

More of a thought question to other people following this.  XFree86 does
implement the XSHM feature and I suspect most *UNIX* X servers also implement
it, but it is possible that a MS-Windows X server might not, since SHM (SVr4
Shared Memory) is a UNIX thing and not a MS-Windows thing.  I believe that the
Flash problem has been definately tracked to mis-handling of the XSHM feature
when the display is remote, which is said to be tricky.


    
    

    
  
It looks that both XFree86/Cygwin and XWin32 do not support XSHM extention,
while Xfree86 for linux does. Also, mozilla has --no-xshm option, but it does
not help. Is it possible that --no-xshm does not affect flash plugin?


    
    

    
  
Can XSHM really be used over a network?  I was under the impression that you cannot.


    
    

    
  
You can't use SHM over the network.

The problem is that incorrectly-written XSHM-using code will do this:

  if "server supports XSHM" then
     do it the fast way
  else
     do it the slow way

when it needs to do this:

  if "server supports XSHM" -and- "XSHM can be initialized properly" then
     do it the fast way
  else
     do it the slow way

People who don't know what they're doing leave out the second part of the test,
and end up with programs that don't work on remote displays if that remote
display *does* advertise that it supports XSHM, and ironically, it may work if
the remote server *doesn't* support XSHM.



    
    

    
  
>> You can't use SHM over the network.
...
>> People who don't know what they're doing leave out the second part of the test,
>> and end up with programs that don't work on remote displays if that remote
>> display *does* advertise that it supports XSHM, and ironically, it may work if
>> the remote server *doesn't* support XSHM.

I suspect it is the case that the programmers at Macromedia, being mostly MacOS
and MS-Windows programers failed to realize that X11 is/can be a *network* based
graphics system and failed to realize that UNIX/Linux programmers do weird
things like run programs on machines *other* than the one they are sitting in
front of.  And even (for various reasons) will treat their desktop machine as if
it is in fact a remote machine -- I do this all of the time, since setting the
DISPLAY variable early in .xinitrc to `hostname`:0.0, and then passing this to
other machines later using rsh is a 'natural' thing to do under UNIX and Linux.

    
    

    
  
To be fair, a big part of the problem is that the design of the XSHM extension
is really, really stupid.  

It's pretty rare to encounter a program that uses XSHM that does so properly,
even when said program is written by Unix die-hards.  It's difficult (and not at
all obvious) to get it right.

    
    

    
  
just thinking aloud,

As a workaround mozilla could overload the XSHM X-server support test functions
for plugins making them fail if it detects it's being run remotely. 

ie., make the
   if "server supports XSHM" then
     ...
test always fail if over the network, by supplying wrappers for these functions,
which do the right thing and first test if we are running over the network.

This may be done using LD_PRELOAD and a library that supports these functions as
well maybe, if mozilla doesn't want to supply those functions.

    
    

    
  
http://radio.weblogs.com/0106797/2002/08/30.html

It appears that Macromedia is taking applications for a closed beta of Flash 6
plugin for Linux.  I hope this works over the network!

Is anyone interested in a flash-linux-discuss mailing list?  That may be a more
appropriate medium for discussing these Flash on Linux issues than this Mozilla
bugzilla.  I will create the mailing list if at least 2 people agree (mail me
directly please).


    
    

    
  
Why it crashes with Cygwin, if Cygwin doesn't support SHM?

From previous comment:
Output from 'xdpyinfo -ext all' (partial)
with Cygwin/XFree86:

Xlib:  extension "MIT-SHM" missing on display "pavel.netgame.co.il:1.0".

    
    

    
  
Announcing Linux Flash discussion project
This medium should be more appropriate to discuss the general problem of Flash
for Linux.  I don't think Bugzilla was meant to be a discussion list itself. =)

http://linuxflash.mplug.org

The LinuxFlash page and discussion list will organize information regarding the
technical problems and options of Flash browser plugins for Linux.  This
resource and discussion list is needed because of the growing need for the Flash
plugin and Macromedia's perceived inability of fixing their software, which for
nearly 2 years has been a serious problem for the adoption of Linux thin clients.

The project home page above is a Wiki, meaning anybody is free to add or update
information.  I encourage folks that know technical details about the current
Linux Flash plugin or alternatives to add more info to this page.  This will
help us to keep all of our info organized in one location.

http://videl.ics.hawaii.edu/mailman/listinfo/linuxflash

This is the discussion mailing list where we will talk about the latest
developments in the Linux Flash plugin front.  Major updates to page
information, testing of new versions of plugins, Open Source alternatives, and
petitions will be discussed here.

I would really appreciate it if someone from Macromedia can contact me and
become our official project contact.

Thanks,
Warren Togami
warren@togami.com
Mid-Pacific Linux Users Group
http://www.mplug.org

    
    

    
  
Well, I tried it with Solaris, and it crashes also. Solaris has XSHM extention.

Xlib:  extension "XFree86-DGA" missing on display "atlantis.netgame.co.il:0.0".
Xlib:  extension "XFree86-VidModeExtension" missing on display
"atlantis.netgame.co.il:0.0".
Xlib:  extension "XFree86-Misc" missing on display "atlantis.netgame.co.il:0.0".
Xlib:  extension "RENDER" missing on display "atlantis.netgame.co.il:0.0".
Xlib:  extension "XINERAMA" missing on display "atlantis.netgame.co.il:0.0".

XWin32 does not have RENDER and RECORD extentions, which present on other X
servers I tried.



    
    

    
  
Topembed- as this not currently needed by a major embeddor, and is NOT a Mozilla
issue.

--> Evangelism.
Component: Plug-ins → Plugins
Keywords: topembed → topembed-
Product: Browser → Tech Evangelism
Version: other → unspecified

    
    

    
  
I've just tried the Flash 6 Beta on my NCD X terminal and it appears to work.
Tried a variety of sites and the flash content worked, and better still I was
able to go to other pages afterwards. You can get the beta at
http://www.macromedia.com/software/flashplayer/special/beta/

Enjoy.


    
    

    
  
Wow, it works for me too!  Mozilla 1.2b, Flash 6.0 r60, Red Hat Linux 7.2.

    
    

    
  
Also works on Mozilla 1.1 (20020826), Flash 6.0 r60, Suse Linux 7.2 Pro.
Well done, Macromedia :-)

    
    

    
  
They actually have this relnoted in the release notes for the beta:

Some Issues Addressed

    * Linux Players
          o bug #58937 (in Bugzilla): Flash Player crashes on remote display.
          o bug #58339 (in Bugzilla): Flash Player hangs Mozilla, when it's trying
                                      to play audio, while audio device is active.

That's the quote (complete with Bugzilla bug numbers!) off their site
(http://www.macromedia.com/software/flashplayer/special/beta/release_notes/)


    
    

    
  
Under debian unstable (sid) it doesn't work even locally now... - tested on two
different machines

Plugin loads, but does not go on, if you click on the flash area with right
mouse button there is a menu that contains items "Settings" and "About
Macromedia Flash Player 6".
Clicking on settings does nothing while clicking About... opens up the correct
window.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1

    
    

    
  
Yup, the new flash player appears to have solved my problems.  RH 7.1 with Moz 1.01.

    
    

    
  
Comment #197 could be a Flash problem. Reporter: Does Flash work properly with
other browsers like Netscape or Konqueror?

    
    

    
  
Mozilla is the platform on which our QA team focuses.  Netscape 7 works OK but 
is not as extensively tested as Mozilla.  Konqueror, Opera and Galeon work for 
the most part but they all have various issues so are not officially supported.  
Netscape 4.x works on basic content.  It doesn't work at all for many advanced 
capabilities due to problems with threads so it is a deprecated browser. 
 
As for distro support, Red Hat 7.3 is what our QA team has been focusing on.  
They are in early stages of testing on Red Hat 8.0.  Your mileage may vary with 
other distro's, in particular early public beta feedback indicates Debian users 
are having significant problems. 
 
P.S. 
 
The flash 6 player is dependent on outline fonts, which flash 5 wasn't.  For 
best results you need ttfonts or urw-fonts installed which may be one source of 
problems on Debian among others. 

    
    

    
  
kudos to macromedia, doing the honors to mark this as fixed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

    
  
Be careful!  Mozilla has a warning about compiling against GCC 3.2, saying that
binary plugins may be incompatible unless rebuilt.

    
    

    
  
It doens't work here. Browser doens't crash anymore but flash contents aren't
displayed. Mozilla 1.0.0 - Debian 3.0 - Flash 6.0r60

    
    

    
  
> It doens't work here. Browser doens't crash anymore but flash contents aren't 
> displayed. Mozilla 1.0.0 - Debian 3.0 - Flash 6.0r60 
 
Known bug in the beta which is fixed.  Workaround is to install gtk-devel or 
create a symbolic link so there is a libgtk.so that points to libgtk-1.2.so. 

    
    

    
  
#204 made it work for us too. 
X-app-server here we go! :)
Tnx to macromedia & everyone else who spent time getting this bug fixed!


    
    

    
  
v
Status: RESOLVED → VERIFIED

    
  
Blocks: grouper

    
    

    
  
It should be noted that the currently released Linux beta has a bug which will 
result in byte sawpped colors if you are running the player on a remote display 
which is big endian such as MIPS or SPARC.  This has been fixed for 32 bit 
displays though the fix is not currently released.  The fix still needs to be 
done for 16 bit displays.  Its not an issue on 8 bit remote displays. 

    
    

    
  
I have experianced this bug in mozilla 1.2 with flash 6.0 r68

    
    

    
  
louie - can you try that with the current version which is 6.0.69

They are about to release this, so it would be great if you could confirm this ASAP.

    
    

    
  
Hi Rodd, could you please name us the link for downloading 6.0.69 ? Thanks.

    
    

    
  
I hope I don't get in trouble for this, but this site is wide open so it should
be fine (I'm under an NDA)

Try: http://macromedia.mplug.org/

    
    

    
  
As a follow up, please don't post this to any news groups - Just in case!

    
    

    
  
isnt secret the beta, there is a public beta for download here:&#013;&#013;http://www.macromedia.com/software/flashplayer/special/beta/&#013;&#013;i think its the RC1, the final should be very, very close to this, if not the same&#013;&#013;as far as i know, the official release is just beind the door, so if there isnt any big bug it will show up in some days

    
    

    
  
*** Bug 191318 has been marked as a duplicate of this bug. ***

    
    

    
  
SPAM: New Components
Component: Plugins → English US
Target Milestone: Future → ---

    
  
No longer blocks: majorbugs

    
  
Component: English US → Flash (Adobe)
Product: Tech Evangelism → Plugins
QA Contact: shrir → adobe-flash
Target Milestone: --- → 2002
Version: unspecified → 5.x

    
    

    
  
Version and milestone values are being reset to defaults as part of product refactoring.
Target Milestone: 2002 → ---
Version: 5.x → 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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: