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)
Tracking
(Not tracked)
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)
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.
Comment 1•24 years ago
|
||
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.
Reporter | ||
Comment 2•24 years ago
|
||
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.
Comment 3•24 years ago
|
||
Reporter is this still a problem in the latest nightlies?
Reporter | ||
Comment 4•24 years ago
|
||
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.
Comment 5•24 years ago
|
||
Marking NEW as per reporters comments.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•24 years ago
|
||
Comment 7•24 years ago
|
||
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.
Comment 8•24 years ago
|
||
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?
Comment 9•24 years ago
|
||
Flash crasher or backward incompatibility bug. Nominating for nsbeta1 as high-quality plug-in support is a priority for embedded applications.
Keywords: nsbeta1
Comment 11•23 years ago
|
||
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.
Comment 13•23 years ago
|
||
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.
Comment 14•23 years ago
|
||
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
>>
Comment 16•23 years ago
|
||
So, I'm curious... Does this also happen with other plugins? Java, for example? Does this happen in 4.x?
Status: NEW → ASSIGNED
Comment 17•23 years ago
|
||
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)
Comment 18•23 years ago
|
||
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.
Comment 19•23 years ago
|
||
Probably reproduced with 2001-06-20-21 on Linux using Xwin32 with ssh. Talkback doesn't work.
Comment 20•23 years ago
|
||
Reproduced with Konqueror! Could be a flash or Xfree bug?
Comment 21•23 years ago
|
||
Is there any status on this?
Comment 22•23 years ago
|
||
*** Bug 88818 has been marked as a duplicate of this bug. ***
Comment 23•23 years ago
|
||
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.
Comment 24•23 years ago
|
||
cc:ing Troy Evans from Macromedia to provide some insight on if this bug is also inside Flash on Linux.
Comment 25•23 years ago
|
||
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
Comment 26•23 years ago
|
||
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
Comment 27•23 years ago
|
||
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.
Comment 28•23 years ago
|
||
[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 → ---
Comment 29•23 years ago
|
||
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?
Comment 30•23 years ago
|
||
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.
Comment 31•23 years ago
|
||
*** Bug 98586 has been marked as a duplicate of this bug. ***
Comment 32•23 years ago
|
||
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.
Comment 33•23 years ago
|
||
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 :(
Comment 34•23 years ago
|
||
*** Bug 106556 has been marked as a duplicate of this bug. ***
Comment 35•23 years ago
|
||
*** Bug 81357 has been marked as a duplicate of this bug. ***
Comment 36•23 years ago
|
||
timecop, any progress on this? This should probably go in the release notes.
Keywords: relnote
Comment 37•23 years ago
|
||
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
Comment 38•23 years ago
|
||
*** Bug 114290 has been marked as a duplicate of this bug. ***
Comment 39•23 years ago
|
||
pocemit: You mean this can be fixed by checking in a patch that already exists?
Comment 40•23 years ago
|
||
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
Comment 41•23 years ago
|
||
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) ...
Comment 42•23 years ago
|
||
Comment 43•23 years ago
|
||
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)
Comment 44•23 years ago
|
||
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.
Comment 45•23 years ago
|
||
*** Bug 110248 has been marked as a duplicate of this bug. ***
Comment 46•23 years ago
|
||
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.
Comment 47•23 years ago
|
||
Don't know if it's important in this context but Netscape 6.2.1 based on Gecko 20011126 works fine
Comment 48•23 years ago
|
||
I may have a fix for this issue, but it depends on the work in bug 112635 (which is waiting for sr= since december... ;-( ) ...
Comment 49•23 years ago
|
||
Roland, since your fix for bug 112635 has been checked in, could you post your fix for this bug here ? Thanks
Comment 50•23 years ago
|
||
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?
Comment 51•23 years ago
|
||
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 ?
Comment 52•23 years ago
|
||
*** Bug 123600 has been marked as a duplicate of this bug. ***
Comment 53•23 years ago
|
||
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...
Comment 54•23 years ago
|
||
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?
Comment 55•23 years ago
|
||
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.
Comment 56•23 years ago
|
||
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
Comment 57•23 years ago
|
||
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) ?
Comment 58•23 years ago
|
||
*** Bug 119656 has been marked as a duplicate of this bug. ***
Comment 59•23 years ago
|
||
I'm wondering if patch for bug 116924 will not fix this bug ?
Comment 60•23 years ago
|
||
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
Assignee | ||
Comment 61•23 years ago
|
||
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.
Comment 62•22 years ago
|
||
*** Bug 130230 has been marked as a duplicate of this bug. ***
Comment 63•22 years ago
|
||
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.
Comment 64•22 years ago
|
||
I have also crashes with exported display. This makes mozilla usless on X-terminals. I hope it will be fixed in 1.0.
Comment 65•22 years ago
|
||
Refering to comment #56, shouldn't the Target Milestone be set to mozilla1.0?
Comment 66•22 years ago
|
||
-->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
Comment 68•22 years ago
|
||
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...)
Comment 69•22 years ago
|
||
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.
Comment 70•22 years ago
|
||
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?
Comment 71•22 years ago
|
||
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
Comment 72•22 years ago
|
||
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
Comment 73•22 years ago
|
||
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.
Comment 74•22 years ago
|
||
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!
Comment 75•22 years ago
|
||
So what doing with this issue? Just putting it into the release notes for moz1.0? Will someone hack this for Unix until freezing?
Comment 76•22 years ago
|
||
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]
Comment 77•22 years ago
|
||
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 ?
Comment 78•22 years ago
|
||
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 :-(.
Comment 79•22 years ago
|
||
*** Bug 126510 has been marked as a duplicate of this bug. ***
Comment 80•22 years ago
|
||
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)...
Comment 81•22 years ago
|
||
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.
Comment 82•22 years ago
|
||
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
Comment 83•22 years ago
|
||
> 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?
Comment 84•22 years ago
|
||
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.
Comment 85•22 years ago
|
||
Seeing crashes on local X with the new version of the Flash-plugin, too :-(.
Comment 86•22 years ago
|
||
*** Bug 137807 has been marked as a duplicate of this bug. ***
Comment 87•22 years ago
|
||
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...
Comment 88•22 years ago
|
||
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"
Comment 89•22 years ago
|
||
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.
Comment 90•22 years ago
|
||
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.
Comment 91•22 years ago
|
||
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. =(
Comment 92•22 years ago
|
||
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-
Comment 93•22 years ago
|
||
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+
Comment 94•22 years ago
|
||
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.
Comment 95•22 years ago
|
||
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.
Comment 96•22 years ago
|
||
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?
Comment 98•22 years ago
|
||
*** Bug 140542 has been marked as a duplicate of this bug. ***
Comment 99•22 years ago
|
||
This bug is mentioned in release notes but the link point to an unrelated bug in bugzilla.
Comment 100•22 years ago
|
||
I have already reported this as a documentation problem. It is a typo. Furthermore, the bug is three times in the last Release Notes.
Comment 101•22 years ago
|
||
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.
Comment 102•22 years ago
|
||
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]
Comment 103•22 years ago
|
||
I didn't see flash.com and macromedia.com on this list. I would think that they should definitely be on this list. :-)
Comment 104•22 years ago
|
||
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.
Comment 105•22 years ago
|
||
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)
Comment 106•22 years ago
|
||
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.
Comment 107•22 years ago
|
||
:) don't get physical... Pls check serge's comment here in this same bug. http://bugzilla.mozilla.org/show_bug.cgi?id=58937#c88
Comment 108•22 years ago
|
||
How can I add myself to the e-mail petition of LTSP sites affected by this bug?
Comment 109•22 years ago
|
||
RE: How can I add myself to the fix-the-flash petition: Go to : www.ltsp.org
Comment 110•22 years ago
|
||
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.
Comment 111•22 years ago
|
||
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.
Comment 112•22 years ago
|
||
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?
Comment 113•22 years ago
|
||
>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:(
Comment 114•22 years ago
|
||
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.
Comment 115•22 years ago
|
||
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
Comment 116•22 years ago
|
||
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.
Comment 117•22 years ago
|
||
*** Bug 122090 has been marked as a duplicate of this bug. ***
Comment 118•22 years ago
|
||
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 }
Comment 119•22 years ago
|
||
*** Bug 147096 has been marked as a duplicate of this bug. ***
Comment 120•22 years ago
|
||
Has anyone heard anything from Macromedia? This is very annoying!
Comment 121•22 years ago
|
||
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.
Comment 122•22 years ago
|
||
[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
Comment 123•22 years ago
|
||
This IS mozilla issue. It shouldn't crash if plugin crashes.
Comment 124•22 years ago
|
||
This is NO Mozilal issue ! Mozilla can't do anything if a plugin, that runs in the same process as mozilla ,crashes.
Comment 125•22 years ago
|
||
> 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.)
Comment 127•22 years ago
|
||
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.
Comment 128•22 years ago
|
||
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.
Comment 129•22 years ago
|
||
*** Bug 145202 has been marked as a duplicate of this bug. ***
Comment 130•22 years ago
|
||
Is there any feedback from macromedia regarding a fix for this bug?
Comment 131•22 years ago
|
||
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?)
Comment 132•22 years ago
|
||
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)
Comment 133•22 years ago
|
||
If that's true, that's what we call a smoking gun: that makes this a bug in Mozilla, not in Flash.
Comment 134•22 years ago
|
||
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...
Comment 135•22 years ago
|
||
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...
Comment 136•22 years ago
|
||
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.
Comment 137•22 years ago
|
||
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.....
Comment 138•22 years ago
|
||
setenv DISPLAY 127.0.0.1:0 or an appropriate for your shell command is enough to repro the crash.
Comment 139•22 years ago
|
||
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 :(
Comment 140•22 years ago
|
||
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?
Comment 141•22 years ago
|
||
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?
Comment 142•22 years ago
|
||
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?
Comment 143•22 years ago
|
||
It's still possible that this is not a Mozilla bug. Look at the comment #113 by serge.
Comment 144•22 years ago
|
||
>> 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.
Comment 145•22 years ago
|
||
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.
Comment 146•22 years ago
|
||
<< 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.
Comment 147•22 years ago
|
||
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
Comment 148•22 years ago
|
||
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.
Comment 149•22 years ago
|
||
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.
Comment 150•22 years ago
|
||
*** Bug 160570 has been marked as a duplicate of this bug. ***
Comment 151•22 years ago
|
||
*** Bug 153733 has been marked as a duplicate of this bug. ***
Comment 152•22 years ago
|
||
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
Comment 153•22 years ago
|
||
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.
Comment 154•22 years ago
|
||
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?!
Comment 155•22 years ago
|
||
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
Comment 156•22 years ago
|
||
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.
Comment 157•22 years ago
|
||
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.
Comment 158•22 years ago
|
||
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)
Comment 159•22 years ago
|
||
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.
Comment 160•22 years ago
|
||
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
Comment 161•22 years ago
|
||
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.
Comment 162•22 years ago
|
||
*** Bug 164025 has been marked as a duplicate of this bug. ***
Comment 163•22 years ago
|
||
I've heard that this may be fixed in the Flash 6 Linux beta.
Comment 164•22 years ago
|
||
You heard from someone at Macromedia?
Comment 165•22 years ago
|
||
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.
Comment 166•22 years ago
|
||
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.
Comment 167•22 years ago
|
||
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.
Comment 168•22 years ago
|
||
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.
Comment 169•22 years ago
|
||
batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
Comment 170•22 years ago
|
||
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
Comment 171•22 years ago
|
||
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?
Comment 172•22 years ago
|
||
*** Bug 170482 has been marked as a duplicate of this bug. ***
Comment 173•22 years ago
|
||
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.
Comment 174•22 years ago
|
||
It crashes for me with an exported X display to Exceed and Xwin32 4.0 for Windows, as well as Linux.
Comment 175•22 years ago
|
||
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?
Comment 176•22 years ago
|
||
>> 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...
Comment 177•22 years ago
|
||
>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.
Comment 178•22 years ago
|
||
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.
Comment 179•22 years ago
|
||
On Gimp, we have the --no-xshm command line flag, but I don't know if we have this on mozilla.
Comment 180•22 years ago
|
||
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.
Comment 181•22 years ago
|
||
>> >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.
Comment 182•22 years ago
|
||
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?
Comment 183•22 years ago
|
||
Can XSHM really be used over a network? I was under the impression that you cannot.
Comment 184•22 years ago
|
||
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.
Comment 185•22 years ago
|
||
>> 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.
Comment 186•22 years ago
|
||
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.
Comment 187•22 years ago
|
||
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.
Comment 188•22 years ago
|
||
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).
Comment 189•22 years ago
|
||
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".
Comment 190•22 years ago
|
||
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
Comment 191•22 years ago
|
||
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.
Comment 192•22 years ago
|
||
Topembed- as this not currently needed by a major embeddor, and is NOT a Mozilla issue. --> Evangelism.
Comment 193•22 years ago
|
||
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.
Comment 194•22 years ago
|
||
Wow, it works for me too! Mozilla 1.2b, Flash 6.0 r60, Red Hat Linux 7.2.
Comment 195•22 years ago
|
||
Also works on Mozilla 1.1 (20020826), Flash 6.0 r60, Suse Linux 7.2 Pro. Well done, Macromedia :-)
Comment 196•22 years ago
|
||
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/)
Comment 197•22 years ago
|
||
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
Comment 198•22 years ago
|
||
Yup, the new flash player appears to have solved my problems. RH 7.1 with Moz 1.01.
Comment 199•22 years ago
|
||
Comment #197 could be a Flash problem. Reporter: Does Flash work properly with other browsers like Netscape or Konqueror?
Comment 200•22 years ago
|
||
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.
Comment 201•22 years ago
|
||
kudos to macromedia, doing the honors to mark this as fixed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 202•22 years ago
|
||
Be careful! Mozilla has a warning about compiling against GCC 3.2, saying that binary plugins may be incompatible unless rebuilt.
Comment 203•22 years ago
|
||
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
Comment 204•22 years ago
|
||
> 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.
Comment 205•22 years ago
|
||
#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!
Comment 207•22 years ago
|
||
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.
Comment 208•22 years ago
|
||
I have experianced this bug in mozilla 1.2 with flash 6.0 r68
Comment 209•22 years ago
|
||
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.
Comment 210•22 years ago
|
||
Hi Rodd, could you please name us the link for downloading 6.0.69 ? Thanks.
Comment 211•22 years ago
|
||
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/
Comment 212•22 years ago
|
||
As a follow up, please don't post this to any news groups - Just in case!
Comment 213•22 years ago
|
||
isnt secret the beta, there is a public beta for download here:

http://www.macromedia.com/software/flashplayer/special/beta/

i think its the RC1, the final should be very, very close to this, if not the same

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
Comment 214•22 years ago
|
||
*** Bug 191318 has been marked as a duplicate of this bug. ***
Comment 215•21 years ago
|
||
SPAM: New Components
Component: Plugins → English US
Target Milestone: Future → ---
Component: English US → Flash (Adobe)
Product: Tech Evangelism → Plugins
QA Contact: shrir → adobe-flash
Target Milestone: --- → 2002
Version: unspecified → 5.x
Comment 216•8 years ago
|
||
Version and milestone values are being reset to defaults as part of product refactoring.
Target Milestone: 2002 → ---
Version: 5.x → unspecified
Updated•2 years ago
|
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.
Description
•