Closed Bug 300572 Opened 17 years ago Closed 17 years ago

FF11a2 Crash in [@ js_SetSlotThreadSafe] with new Shockwave Flash beta 8.0 b434 [@ 0x65746167][@ 0x6e616272][@ 0x69676972]

Categories

(Core Graveyard :: Plug-ins, defect)

defect
Not set
critical

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 300756

People

(Reporter: stephend, Assigned: timeless)

References

Details

(Keywords: crash, topcrash+)

Crash Data

Attachments

(2 files)

Build ID: 2005-07-12-05, Windows XP SeaMonkey trunk.

Summary: Crash in [@ js_SetSlotThreadSafe] with new Shockwave Flash beta 8.0 b434

Steps to Reproduce:

1. Load http://www.fox.com
2. Click "Shows"
3. Click "The Inside"
4. Scroll to the bottom and click on the Fox.com logo
5. Crash here:

js_SetSlotThreadSafe 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jslock.c,
line 662]
JS_SetPrivate 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c, line
2158]
nsJSNPRuntime::OnPluginDestroy 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/plugin/base/src/nsJSNPRuntime.cpp,
line 1330]
StopPluginInstance 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 6555]
PresShell::EnumeratePlugins 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 7230]
PresShell::Freeze 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 6581]
DocumentViewerImpl::Destroy 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsDocumentViewer.cpp,
line 1336]
DocumentViewerImpl::Show 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsDocumentViewer.cpp,
line 1710]
nsPresContext::EnsureVisible 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresContext.cpp,
line 1256]
nsPluginInstanceOwner::Init 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsObjectFrame.cpp,
line 4093]
nsObjectFrame::Reflow 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsObjectFrame.cpp,
line 1075]
nsLineLayout::ReflowFrame 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsLineLayout.cpp,
line 995]
nsBlockFrame::ReflowInlineFrame 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 4145]
nsBlockFrame::DoReflowInlineFrames 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 3800]
nsBlockFrame::ReflowInlineFrames 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 3683]
nsBlockFrame::ReflowLine 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 2678]
nsBlockFrame::ReflowDirtyLines 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 2228]
nsBlockFrame::Reflow 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 872]
nsBlockReflowContext::ReflowBlock 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockReflowContext.cpp,
line 574]
nsBlockFrame::ReflowBlockFrame 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 3398]
nsBlockFrame::ReflowLine 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 2559]
nsBlockFrame::ReflowDirtyLines 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 2228]
nsBlockFrame::Reflow 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 872]
nsBlockReflowContext::ReflowBlock 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockReflowContext.cpp,
line 574]
nsBlockFrame::ReflowBlockFrame 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 3398]
nsBlockFrame::ReflowLine 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 2559]
nsBlockFrame::ReflowDirtyLines 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 2228]
nsBlockFrame::Reflow 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsBlockFrame.cpp,
line 872]
nsContainerFrame::ReflowChild 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsContainerFrame.cpp,
line 899]
CanvasFrame::Reflow 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsHTMLFrame.cpp,
line 522]
nsContainerFrame::ReflowChild 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsContainerFrame.cpp,
line 899]
nsHTMLScrollFrame::ReflowScrolledFrame 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsGfxScrollFrame.cpp,
line 516]
nsHTMLScrollFrame::ReflowContents 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsGfxScrollFrame.cpp,
line 564]
nsHTMLScrollFrame::Reflow 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsGfxScrollFrame.cpp,
line 754]
nsContainerFrame::ReflowChild 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsContainerFrame.cpp,
line 899]
ViewportFrame::Reflow 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsViewportFrame.cpp,
line 240]
IncrementalReflow::Dispatch 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 913]
PresShell::ProcessReflowCommands 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 6846]
ReflowEvent::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 6672]
PL_HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/threads/plevent.c,
line 686]
0x778b0c24
0x006e006f
WARNING: NS_ENSURE_TRUE(sgo) failed, file
r:/mozilla/modules/plugin/base/src/nsJSNPRuntime.cpp, line 209

the crash is because JS_SetPrivate and friends require a non null cx.

    if (CX_THREAD_IS_RUNNING_GC(cx) ||
        ^^^^^^^^^^^^^^^^^^^^^^^ ^0 - crash

 	js3250.dll!js_GetSlotThreadSafe(JSContext * cx=0x00000000, JSObject *
obj=0x03386c90, unsigned long slot=2)  Line 572 + 0x3	C
 	js3250.dll!JS_SetPrivate(JSContext * cx=0x00000000, JSObject * obj=0x03386c90,
void * data=0x00000000)  Line 2157 + 0xe7	C
>	gkplugin.dll!NPObjWrapperPluginDestroyedCallback(PLDHashTable *
table=0x043fe8e4, PLDHashEntryHdr * hdr=0x04b4a740, unsigned int number=0, void
* arg=0x04eaa3a4)  Line 1311 + 0x13	C++
 	xpcom_core.dll!PL_DHashTableEnumerate(PLDHashTable * table=0x043fe8e4,
PLDHashOperator (PLDHashTable *, PLDHashEntryHdr *, unsigned int, void *)*
etor=0x043e1600, void * arg=0x04eaa3a4)  Line 619 + 0x19	C
 	gkplugin.dll!nsJSNPRuntime::OnPluginDestroy(_NPP * npp=0x04eaa3a4)  Line
1330 + 0x13	C++

Assignee: timeless → timeless
i claim this is at least partly a bug in the plugin:

   // Check whether the plugin wants SetWindow to be called before or after
   // Stop/Destroy.  This is similar to nsObjectFrame::Destroy(), but we
   // don't want to destroy the frame just yet.
   instance->GetValue(nsPluginInstanceVariable_CallSetWindowAfterDestroyBool,
                      (void *) &callSetWindowLast);

we take the:
  } else {
    instance->SetWindow(nsnull);
    instance->Stop();
    instance->Destroy();
  }
path, which is unfortunate since SetWindow almost certainly results in Stop not
having a SGO.
Attached patch seems to workSplinter Review
note that flash is a 4x plugin, so it takes this path:
     case nsPluginInstanceVariable_CallSetWindowAfterDestroyBool:
       *(PRBool *)value = 0;  // not supported for 4.x plugins
Attachment #189150 - Flags: superreview?(jst)
Attachment #189150 - Flags: review?(jst)
Not sure if I should file another bug report, I get crashes with Flash 8.0b434
on WinXP with Deer Park Alpha 2 (not FF 1.0.4) with different stack:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=tb7437194z
it doesn't seem to happen for me (patched or unpatched), so you'll need to give
me lots of hints about how to trigger it. note that stephend's steps didn't work
for me either, he just happened to luck out that i was able to trigger it via
some other mechanism.

the pages i went to where:
http://www.macromedia.com/software/flash/fl4about
http://www.macromedia.com/software/flash/about/
and then i clicked on "Site of the Day"
http://www.macromedia.com/cfusion/showcase/index.cfm
(that page did not finish loading [as measured by "Document {url} loaded
successfully"] before i crashed)

based on where you're crashing, i think it's almost a perfectly reasonable
related bug, except i'm not quite sure how we'd manage to do that.
Adding FF11a2 to summary and topcrash+ keyword since we have a patch. This is
currently the #1 topcrasher for Deer Park Alpha 2:
http://talkback-public.mozilla.org/reports/firefox/FF11a2/FF11a2-topcrashers.html

Looks like we have a good idea of what's going on here, but you can always
browse through Talkback data for more info:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=js_SetSlotThreadSafe&vendor=MozillaOrg&product=FirefoxTrunk&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid
Keywords: topcrash+
Summary: Crash in [@ js_SetSlotThreadSafe] with new Shockwave Flash beta 8.0 b434 → FF11a2 Crash in [@ js_SetSlotThreadSafe] with new Shockwave Flash beta 8.0 b434
Blocks: 300756
    
For those members that have WinXP, I just reveiwed a comment from Ria:
Question from FF Dev:
Does it also happen if you disable bfcache ?

Answer from Ria:
I get a crash every time with bfcache to 3 (default);
I get no crashes so far with bfcache to 0.

TB7498968H TB7499076K Sorry no links; the TB-server is too busy..
[url]https://bugzilla.mozilla.org/show_bug.cgi?id=300756[/url]

So I too just set bfcache to '0'

Go to 'about:config'--->browser:sessionhistory.max_viewers--->by default this
value is set to '3'

Results after replacing my plugins folder with new Flash beta 8.0 b434 @
[url]http://www.macromedia.com/shockwave/welcome/[/url]
[url]http://www.freerangestudios.com/flash/flash3.html[/url]

No Crashes...
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050714
Firefox/1.0+ ID:2005071406
Flags: blocking1.8b4?
*** Bug 301242 has been marked as a duplicate of this bug. ***
Hardware/OS -> All/All (since this seems to affect Camino too).
OS: Windows XP → All
Hardware: PC → All
From the Flash Player team: I am encountering crashes with these links with the 
Deer Park Alpha, but not with Camino. I'll log a bug internally for us to 
investigate as well.
Clarification: I can repro a crash with Deer Park and the Flash Player beta by 
following these steps:

1. Load http://www.fox.com
2. Click "Shows"
3. Click "The Inside"

Crashes when you click "The Inside". It's an intermittant bug and it may only 
happen when you click "The Inside" quickly just after www.fox.com loads. Again, 
we'll investigate from the Flash Player side too.
Comment on attachment 189150 [details] [diff] [review]
seems to work

r+sr=jst
Attachment #189150 - Flags: superreview?(jst)
Attachment #189150 - Flags: superreview+
Attachment #189150 - Flags: review?(jst)
Attachment #189150 - Flags: review+
Attachment #189150 - Flags: approval1.8b4?
Comment on attachment 189150 [details] [diff] [review]
seems to work

a=shaver.
Attachment #189150 - Flags: approval1.8b4? → approval1.8b4+
Comment on attachment 189150 [details] [diff] [review]
seems to work

This patch was checked in by timeless on: 2005-07-20 05:36 PDT.

Wait for builds that have it and then report back the results.
*** Bug 301242 has been marked as a duplicate of this bug. ***
Still crashing, but now in slightly different call stacks (same steps to
reproduce).
msintov@macromedia.com: can you give an indication as to what's happening from
the flash side of the new flavor of the crash?
Flags: blocking1.8b4? → blocking1.8b4+
Summary: FF11a2 Crash in [@ js_SetSlotThreadSafe] with new Shockwave Flash beta 8.0 b434 → FF11a2 Crash in [@ js_SetSlotThreadSafe] with new Shockwave Flash beta 8.0 b434 [@ 0x65746167]
Summary: FF11a2 Crash in [@ js_SetSlotThreadSafe] with new Shockwave Flash beta 8.0 b434 [@ 0x65746167] → FF11a2 Crash in [@ js_SetSlotThreadSafe] with new Shockwave Flash beta 8.0 b434 [@ 0x65746167][@ 0x6e616272]
Summary: FF11a2 Crash in [@ js_SetSlotThreadSafe] with new Shockwave Flash beta 8.0 b434 [@ 0x65746167][@ 0x6e616272] → FF11a2 Crash in [@ js_SetSlotThreadSafe] with new Shockwave Flash beta 8.0 b434 [@ 0x65746167][@ 0x6e616272][@ 0x69676972]
Unfortunately I can't provide any info; we aren't in the Flash Player's
callstack. All I see is a crash in routine js3250.dll!600c749a() with an
unhandled exception at 0x600c749a in firefox.exe: 0xC0000005: Access violation
reading location 0x00000014.

I can't repro this on Mac, maybe b/c the Flash Player's slowness on Mac makes it
impossible to reproduce. For this bug, timing seems crucial: I think you have to
quickly select "The Inside" to see this bug on Windows.

Note that for bug https://bugzilla.mozilla.org/show_bug.cgi?id=301242, I see a
very descriptive Mozilla stack, so from my perspective these don't seem like the
same bugs but I'll take your word for it.
msintov@macromedia.com: err... how about, have we cleanly released your objects?
are their outstanding references? do things appear to have been torn down in the
expected order?

also, what version of firefox were you using
New build is out of Flash Player 8
Still having strange crashes. Like after closing Deer Park (window with flash
content), etc.
FYI: The currently available Flash Player 8 beta is version 8r5.

For which urls do you see a crash with Deer Park upon closing the browser? I
didn't see this problem yet for fox.com.

By the way, humorously, "The Inside" appears to be cut from the Fox line-up (or
something) as it's no longer available in the Shows dropdown.
With the Studio 8 showcase. http://www.macromedia.com/software/studio/experience/

It happens randomly
Michelle Sintov, can you keep us up to date on what's going on on your end? It
looks like we've patched one of the main symptoms but this (and bug 300756,
which may now be the same thing) are still a problem. 
Asa, this is most certainly an issue with bfcache interaction (though it might
very well be that our plugin code needs to be updated to take bfcache into
consideration).  When I disable bfcache, as others have said both here and in
bug 300756, I don't crash.
Brendan, once you've debugged, I'm pretty sure you'll confirm this and bug
300756 are one-and-the-same.
New build.

http://fileforum.betanews.com/detail/Macromedia_Flash_Player_for_Windows_Netscape_Mozilla_Opera/964714156/2

Macromedia Flash Player for Windows (Netscape, Mozilla & Opera) 8.0.15.0 Beta
(In reply to comment #27)
> New build.
> 
>
http://fileforum.betanews.com/detail/Macromedia_Flash_Player_for_Windows_Netscape_Mozilla_Opera/964714156/2
> 
> Macromedia Flash Player for Windows (Netscape, Mozilla & Opera) 8.0.15.0 Beta

Tried it.  It still crashes.  I got through the complete flash 8 promotion thing
but when I tried to goto macromedia's home page, it crashed.
I'm crashing too! Went back to 7
Marking a dup of bug 300756 now that the bug is understood.

/be

*** This bug has been marked as a duplicate of 300756 ***
No longer blocks: 300756
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
*** Bug 301242 has been marked as a duplicate of this bug. ***
Flags: blocking1.8b4+
Attachment #189150 - Flags: approval1.8b4+
Crash Signature: [@ js_SetSlotThreadSafe] [@ 0x65746167] [@ 0x6e616272] [@ 0x69676972]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.