Closed Bug 37477 Opened 25 years ago Closed 25 years ago

Browser crashes on this page (uses flash)

Categories

(Core Graveyard :: Plug-ins, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: shrir, Assigned: bryner)

References

()

Details

(Keywords: crash, Whiteboard: [nsbeta2+] ETA: 7/19)

Attachments

(7 files)

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)
I can reproduce this on build 2000-04-24-09 (Red Hat 6.2, kernel 2.2.12). Adding 'crash' & 'flash' keywords.
Summary: Browser crashes upon visiting this page → Browser crashes on this page (uses flash)
*** Bug 38268 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Flash crasher-->nsbeta2. Flash is on b2 criteria.
Keywords: nsbeta2
Mozilla does not crash on this page. Tries sereval times on different machines browser - N6 Preview release 1
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
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 → ---
[nsbeta2+] How is this related to 36568?
Whiteboard: [nsbeta2+]
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: 25 years ago25 years ago
Resolution: --- → DUPLICATE
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 → ---
yes, this crashes on linux.(2000052208)
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.
Eric, this worksforme on winNT Sp4(build:2000060814M16). But still crashes on linux (2000060811m17)
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!
Thanks so much Eric!
heh, i was hacking on this today... i'll post more in a few
reassigning to self
Assignee: av → pavlov
Status: REOPENED → NEW
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.
Status: NEW → ASSIGNED
I have also verified that the real player 7 plugin works as well.
Thanks, Stuart, for taking care of this one. Eric, would please review the patch. Since it is still my module (doh), a=av.
adding blizzard to cc list
Attached patch new patchSplinter Review
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?
Attached patch new patchSplinter Review
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?
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.
Attached patch new patchSplinter Review
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.
I just sent an initial review of the changes to Pav.
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.
Attached patch newest patchSplinter Review
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.
Attached patch full patchSplinter Review
whoops, i missed the plugin part of the patch.. this is the full one
Blocks: 37622
fixes checked in. see bug 45162 for some stuff that still needs to be done for unix plugins
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Verified with linux build 2000071208 and shockwave flashplayer 4.0 that this page is loading fine. Marking as such.
Status: RESOLVED → VERIFIED
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'
reopening.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
ok, i'm working on the fullscreen bug
Status: REOPENED → ASSIGNED
Keywords: 4xp
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?
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?
I will be in Canada until 7-25-2000.. I would appriciate it if someone could check in the patch for me. r=pavlov
reassigning to bryner. Brian, would you please review and test this patch, and check it in?
Assignee: pavlov → bryner
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Whiteboard: [nsbeta2+] → [nsbeta2+] ETA: 7/19
Looks fine to me, and fixes the problem. pinkerton is testing this on mac.
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
verified on linux build (2000072408)
Status: RESOLVED → VERIFIED
*** Bug 45869 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: