Closed
Bug 37477
Opened 24 years ago
Closed 24 years ago
Browser crashes on this page (uses flash)
Categories
(Core Graveyard :: Plug-ins, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M18
People
(Reporter: shrir, Assigned: bryner)
References
()
Details
(Keywords: crash, Whiteboard: [nsbeta2+] ETA: 7/19)
Attachments
(7 files)
|
6.81 KB,
patch
|
Details | Diff | Splinter Review | |
|
6.83 KB,
patch
|
Details | Diff | Splinter Review | |
|
21.08 KB,
patch
|
Details | Diff | Splinter Review | |
|
22.53 KB,
patch
|
Details | Diff | Splinter Review | |
|
11.29 KB,
patch
|
Details | Diff | Splinter Review | |
|
23.06 KB,
patch
|
Details | Diff | Splinter Review | |
|
628 bytes,
patch
|
Details | Diff | Splinter Review |
Plugin: Flash Player 4.0
I see this crash when I try to visit this url.
Console output:
debug: edburns ns4xPlugin :: CreatePlugin
debug: edburns ns4xPlugin :: CreatePlugin : Cleared callbacks
debug: edburns ns4xPlugin :: CreatePlugin : callbacks -> newstream : 0x4107c380
About to show xtbin(0x892f710)...
+ [1]
+ [-f core]
+ [ !=]
Stack trace:
Trigger Type: Program Crash
Trigger Reason: SIGSEGV: Segmentation Fault: (signal 11)
Call Stack: (Signature = libXt.so.6 + 0x40bc2 (0x41006bc2) c542a772)
libXt.so.6 + 0x40bc2 (0x41006bc2)
libXt.so.6 + 0x3fdad (0x41005dad)
libgtkxtbin.so + 0x18fe (0x407438fe)
libgtk-1.2.so.0 + 0x8db4d (0x4059eb4d)
libgtk-1.2.so.0 + 0xba2db (0x405cb2db)
libgtk-1.2.so.0 + 0xb8575 (0x405c9575)
libgtk-1.2.so.0 + 0xeadb8 (0x405fbdb8)
libgtk-1.2.so.0 + 0xf4396 (0x40605396)
libgtk-1.2.so.0 + 0x8db4d (0x4059eb4d)
libgtk-1.2.so.0 + 0xba2db (0x405cb2db)
libgtk-1.2.so.0 + 0xb8575 (0x405c9575)
libgtk-1.2.so.0 + 0xea30c (0x405fb30c)
libraptorplugin.so + 0xfe01 (0x40fbae01)
libraptorplugin.so + 0xc2c3 (0x40fb72c3)
libraptorhtml.so + 0x1c04f4 (0x40c414f4)
libraptorhtml.so + 0x1bff3b (0x40c40f3b)
libraptorhtml.so + 0x1bc8cc (0x40c3d8cc)
libraptorhtml.so + 0x1b98ba (0x40c3a8ba)
libraptorhtml.so + 0x1b95d4 (0x40c3a5d4)
libraptorhtml.so + 0x1b9436 (0x40c3a436)
libraptorhtml.so + 0x1bc8cc (0x40c3d8cc)
libraptorhtml.so + 0x19decd (0x40c1eecd)
libraptorhtml.so + 0x19dd17 (0x40c1ed17)
libraptorhtml.so + 0x19dad5 (0x40c1ead5)
libraptorhtml.so + 0x19da0f (0x40c1ea0f)
libraptorhtml.so + 0x19c838 (0x40c1d838)
libraptorhtml.so + 0x19c178 (0x40c1d178)
libraptorhtml.so + 0x19af50 (0x40c1bf50)
libraptorhtml.so + 0x1a44c7 (0x40c254c7)
libraptorhtml.so + 0x2ee639 (0x40d6f639)
libraptorhtml.so + 0x1a44c7 (0x40c254c7)
libraptorhtml.so + 0x2fc55b (0x40d7d55b)
libraptorhtml.so + 0x2fd4dd (0x40d7e4dd)
libraptorhtml.so + 0x1a44c7 (0x40c254c7)
libraptorhtml.so + 0x2fe293 (0x40d7f293)
libraptorhtml.so + 0x2ff6e2 (0x40d806e2)
libraptorhtml.so + 0x1a44c7 (0x40c254c7)
libraptorhtml.so + 0x2f5c14 (0x40d76c14)
libraptorhtml.so + 0x2f3ef4 (0x40d74ef4)
libraptorhtml.so + 0x2f3527 (0x40d74527)
libraptorhtml.so + 0x1a44c7 (0x40c254c7)
libraptorhtml.so + 0x2f9fb8 (0x40d7afb8)
libraptorhtml.so + 0x2f97aa (0x40d7a7aa)
libraptorhtml.so + 0x2f976c (0x40d7a76c)
libraptorhtml.so + 0x2f96b6 (0x40d7a6b6)
libraptorhtml.so + 0x2fa9a3 (0x40d7b9a3)
libraptorhtml.so + 0x1a1907 (0x40c22907)
libraptorhtml.so + 0x19d48c (0x40c1e48c)
libraptorhtml.so + 0x19c526 (0x40c1d526)
libraptorhtml.so + 0x19c178 (0x40c1d178)
libraptorhtml.so + 0x19af50 (0x40c1bf50)
libraptorhtml.so + 0x1a44c7 (0x40c254c7)
libraptorhtml.so + 0x2ee639 (0x40d6f639)
libraptorhtml.so + 0x1a44c7 (0x40c254c7)
libraptorhtml.so + 0x2fd129 (0x40d7e129)
libraptorhtml.so + 0x2fce56 (0x40d7de56)
libraptorhtml.so + 0x2fd4ff (0x40d7e4ff)
libraptorhtml.so + 0x1a44c7 (0x40c254c7)
libraptorhtml.so + 0x3002f0 (0x40d812f0)
libraptorhtml.so + 0x2ff9b7 (0x40d809b7)
libraptorhtml.so + 0x2ff694 (0x40d80694)
libraptorhtml.so + 0x1a44c7 (0x40c254c7)
libraptorhtml.so + 0x2f54b0 (0x40d764b0)
libraptorhtml.so + 0x2f5051 (0x40d76051)
libraptorhtml.so + 0x2f3325 (0x40d74325)
libraptorhtml.so + 0x1a44c7 (0x40c254c7)
libraptorhtml.so + 0x2f9fb8 (0x40d7afb8)
libraptorhtml.so + 0x2f97aa (0x40d7a7aa)
libraptorhtml.so + 0x2f976c (0x40d7a76c)
libraptorhtml.so + 0x2f96b6 (0x40d7a6b6)
libraptorhtml.so + 0x2fa9a3 (0x40d7b9a3)
libraptorhtml.so + 0x1a1907 (0x40c22907)
libraptorhtml.so + 0x19d48c (0x40c1e48c)
libraptorhtml.so + 0x19c526 (0x40c1d526)
libraptorhtml.so + 0x19c178 (0x40c1d178)
libraptorhtml.so + 0x19af50 (0x40c1bf50)
libraptorhtml.so + 0x1a44c7 (0x40c254c7)
libraptorhtml.so + 0x2ee639 (0x40d6f639)
libraptorhtml.so + 0x1a44c7 (0x40c254c7)
libraptorhtml.so + 0x2fd129 (0x40d7e129)
libraptorhtml.so + 0x2fce56 (0x40d7de56)
libraptorhtml.so + 0x2fd4ff (0x40d7e4ff)
libraptorhtml.so + 0x1a44c7 (0x40c254c7)
libraptorhtml.so + 0x3002f0 (0x40d812f0)
libraptorhtml.so + 0x2ff9b7 (0x40d809b7)
libraptorhtml.so + 0x2ff694 (0x40d80694)
libraptorhtml.so + 0x1a44c7 (0x40c254c7)
libraptorhtml.so + 0x2f54b0 (0x40d764b0)
libraptorhtml.so + 0x2f5051 (0x40d76051)
libraptorhtml.so + 0x2f3325 (0x40d74325)
libraptorhtml.so + 0x1a44c7 (0x40c254c7)
libraptorhtml.so + 0x2f9fb8 (0x40d7afb8)
libraptorhtml.so + 0x2f97aa (0x40d7a7aa)
libraptorhtml.so + 0x2f976c (0x40d7a76c)
libraptorhtml.so + 0x2f96b6 (0x40d7a6b6)
libraptorhtml.so + 0x2fa9a3 (0x40d7b9a3)
libraptorhtml.so + 0x1a1907 (0x40c22907)
libraptorhtml.so + 0x19d48c (0x40c1e48c)
libraptorhtml.so + 0x19c526 (0x40c1d526)
libraptorhtml.so + 0x19c178 (0x40c1d178)
|
||
Comment 1•24 years ago
|
||
I can reproduce this on build 2000-04-24-09 (Red Hat 6.2, kernel 2.2.12). Adding 'crash' & 'flash' keywords.
|
||
Updated•24 years ago
|
Summary: Browser crashes upon visiting this page → Browser crashes on this page (uses flash)
|
||
Comment 4•24 years ago
|
||
Mozilla does not crash on this page. Tries sereval times on different machines browser - N6 Preview release 1
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
|
|
||
Comment 5•24 years ago
|
||
NS6 PR1 is well over a month old, and the page still does crash for me on Linux build 2000-05-21-09. Reopening.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
|
||
Comment 7•24 years ago
|
||
this is an exact dup of bug#36568. if this is still a crash, report under that bug *** This bug has been marked as a duplicate of 36568 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
|
|
||
Comment 8•24 years ago
|
||
I don't think this is a dup. Bug 36568 reports a crash happening only when Shockwave Player is installed, while this one deals with a Flash Player crash. Shockwave Player isn't even available for Linux. Furthermore, Linux build 2000-05-22-08 still crashes on the page, even though bug 36568 has been marked Worksforme. Reopening this one.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
|
Reporter | |
Comment 9•24 years ago
|
||
yes, this crashes on linux.(2000052208)
|
||
Comment 10•24 years ago
|
||
Visiting above URL in 2000060808 Commercial on WinNT 4.0 SP4 still crashes. I think I have found another method to reproduce this same crash: On this page: http://www.macromedia.com/?m=g Click this link: If you know you have the Flash Player installed, click _here_. Browser crashes. I filed a Talkback report, 8 June from my email. Seeing that with 2000060808 Commercial on WinNT 4.0 SP4. I think this is the same issue as already documented in this report. QA, when this bug is fixed, please verify that both paths now work without crashing. Or, if someone does deep analysis like a stack trace on the crash method I just reported and determines it to be a separate issue, please fork the problem off into a separate report.
|
|
Reporter | |
Comment 11•24 years ago
|
||
Eric, this worksforme on winNT Sp4(build:2000060814M16). But still crashes on linux (2000060811m17)
|
||
Comment 12•24 years ago
|
||
With today's build and an flash player download from today, I see a crash when leaving this page but not when viewing it (flash is appearing fine for me). Same for the testcase on bug 38268. Andre, I'm doing a full clobber-pull-build now so if you want to debug this anytime tomorrow is fine with me, just stop by!
|
||
Comment 13•24 years ago
|
||
Thanks so much Eric!
|
||
Comment 14•24 years ago
|
||
heh, i was hacking on this today... i'll post more in a few
|
|
||
Comment 16•24 years ago
|
||
|
|
||
Comment 17•24 years ago
|
||
ok, here is a patch that fixes the problem(s). I made GtkXtBin inherit from GtkWidget instead of GtkWindow since we were not creating a toplevel window. This might speed things up a tad, but definatly removes a lot of code paths through gtk dealing with GtkWindows and GtkBins and containers and such. I added a handler for destroy which properly gets rid of the XtWidget so that xt no longer tries to process events on it. The only slightly iffy change I made is the one to ns4xPluginInstance.cpp where if we get a null window, we try and destroy the xtbin. This works fine with the flash plugin, but I don't know about others... It seems that we should be doing this also in Stop so that we know we are destroying the XtWidget properly.
|
|
||
Updated•24 years ago
|
Status: NEW → ASSIGNED
|
|
||
Comment 18•24 years ago
|
||
I have also verified that the real player 7 plugin works as well.
|
|
||
Comment 19•24 years ago
|
||
Thanks, Stuart, for taking care of this one. Eric, would please review the patch. Since it is still my module (doh), a=av.
|
|
||
Comment 20•24 years ago
|
||
adding blizzard to cc list
|
|
||
Comment 21•24 years ago
|
||
|
|
||
Comment 22•24 years ago
|
||
this patch should make us not spike the cpu after we've loaded a page with a plugin in it... I have one serious problem with this patch (well, code that was there before) in the way that we tell glib to listen to Xt events... we poll the Display connection... this seems like something we shouldn't be doing. I can't currently think of a good way to do this short of running XtAppMainLoop on another thread and proxying Xt events back to glib to be handled there... anyone have any ideas?
|
|
||
Comment 23•24 years ago
|
||
|
|
||
Comment 24•24 years ago
|
||
this bug is pissing me off. I have everything "working" but: we leak widgets and we don't destroy our connection with Xt us destroying our connection to Xt should be as simple as removing some if 0'd code I have in this patch, but this code won't get called as long as we are leaking widgets. us leaking widgets is due to ns4xPluginInstance::SetWindow... we just create a new widget. I have tried both (both with bad results): destroying the old widget if it is non-null and using the old widget and just resizing it I don't know how to make us not leak. SetWindow gets called first from nsPluginHostImpl::InstantiateEmbededPlugin and then again from nsObjectFrame::DidReflow Why would we be setting the window in DidReflow? http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsObjectFrame.cpp#1106 unless this is how it thinks it should move the widget... if this is the case, please shoot me now. av?
|
|
||
Comment 25•24 years ago
|
||
According to the plugin API we call SetWindow not only when we set it but any time something changed, e.g. window has been resized, so the plugin knows something is happening.
|
|
||
Comment 26•24 years ago
|
||
|
|
||
Comment 27•24 years ago
|
||
please review this patch I just attached. The only issues I have with it is some code in ns4xPluginInstance::SetWindow, which I have added a good sized comment to, and that we don't ever stop listening to the Xt event queue, because doing so and starting it back up causes crashes for me. I am happy with seeing this code checked in as it is now. Please review this and let me know when it is ok to check in.
|
|
||
Comment 28•24 years ago
|
||
I just sent an initial review of the changes to Pav.
|
|
||
Comment 29•24 years ago
|
||
Ah, my bad. I meant to say. "I sent a partial review to you Pav." I haven't reviewd the gtk changes because they are a bit over my head. If anyone else wants to take a look at them, it is the diffs in the last two files of the attachment. Pav, if you want me to work on those too, please just give me a call anytime.
|
|
||
Comment 30•24 years ago
|
||
|
|
||
Comment 31•24 years ago
|
||
few cleanups.. added #ifdef NS_DEBUG around two printfs as pollmann had suggested. cleaned up the xtbin code a little bit more... blizzard had a few suggestions about this code, but I misunderstood them I think and so i'm waiting to talk to him again... I'm happy with this patch, so once I get blizzard happy, i'll check in.
|
|
||
Comment 32•24 years ago
|
||
|
|
||
Comment 33•24 years ago
|
||
whoops, i missed the plugin part of the patch.. this is the full one
|
|
||
Comment 34•24 years ago
|
||
fixes checked in. see bug 45162 for some stuff that still needs to be done for unix plugins
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
|
|
Reporter | |
Comment 35•24 years ago
|
||
Verified with linux build 2000071208 and shockwave flashplayer 4.0 that this page is loading fine. Marking as such.
Status: RESOLVED → VERIFIED
|
|
||
Comment 36•24 years ago
|
||
Stuart, would you please try full-page mode: http://www.prometheus-music.com/gecko/Thankyou.swf It crashes on my today's build with the following output: Gtk-WARNING **: invalid cast from `(unknown)' to `GtkSuperWin'
|
|
Reporter | |
Comment 39•24 years ago
|
||
updated test url
|
|
||
Comment 40•24 years ago
|
||
look at: http://lxr.mozilla.org/seamonkey/source/layout/base/src/nsPluginViewer.cpp#799 Is there a problem with us changing this line to use NS_NATIVE_PLUGIN_PORT instead of NS_NATIVE_WINDOW? The reason we are crashing is because the object we get is different. There are some more changes I would like to make in the way NS_NATIVE_PLUGIN_PORT returns on unix, but we need to be consistant when using it with plugins I think. windows returns the same thing for both plugin and window.. mac does things a little differently.. could someone please test this change on mac?
|
|
||
Comment 41•24 years ago
|
||
|
|
||
Comment 42•24 years ago
|
||
the new attached patch fixes the crash for me and allows me to load files that require plugins directly. Could someone on the mac please verify this does not break anything? Could I get a review?
|
|
||
Comment 43•24 years ago
|
||
I will be in Canada until 7-25-2000.. I would appriciate it if someone could check in the patch for me. r=pavlov
|
||
Comment 44•24 years ago
|
||
reassigning to bryner. Brian, would you please review and test this patch, and check it in?
Assignee: pavlov → bryner
Status: ASSIGNED → NEW
|
Assignee | |
Updated•24 years ago
|
Status: NEW → ASSIGNED
|
|
Assignee | |
Updated•24 years ago
|
Whiteboard: [nsbeta2+] → [nsbeta2+] ETA: 7/19
|
|
Assignee | |
Comment 45•24 years ago
|
||
Looks fine to me, and fixes the problem. pinkerton is testing this on mac.
|
|
Assignee | |
Comment 46•24 years ago
|
||
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
|
|
||
Comment 48•24 years ago
|
||
*** Bug 45869 has been marked as a duplicate of this bug. ***
|
||
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•