Closed Bug 542263 Opened 15 years ago Closed 15 years ago

[OOPP] silverlight crashes eventually [@NPObjWrapper_NewResolve]

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking2.0 alpha1+)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- alpha1+

People

(Reporter: benjamin, Assigned: benjamin)

References

(
URL
)

Details

Attachments

(3 files)

Crucial stack
7.58 KB, text/plain
Details
Don't invalidate when objects are deallocated, rev. 1
2.54 KB, patch
bent.mozilla
: review+
Details | Diff | Splinter Review
Test
9.33 KB, patch
Details | Diff | Splinter Review
STR, using a debug build: * Visit http://timheuer.com/silverlight/bouncingplane/ * Let it sit there, bouncing, for a while... maybe 10-20 seconds or longer, enough to trigger some GCs and perhaps a CC. Eventually you will crash with the following stack: > NPObjWrapper_NewResolve(cx=0x04efaea0, obj=0x062d4040, id=0x02bccd94, flags=0x00000001, objp=0x0024ca88) Line 1574 C++ js_LookupPropertyWithFlags(cx=0x04efaea0, obj=0x062d4040, id=0x02bccd94, flags=0x00000001, objp=0x0024cad0, propp=0x0024cac4) Line 4718 C++ js_GetPropertyHelper(cx=0x04efaea0, obj=0x062d4020, id=0x02bccd94, getHow=0x00000000, vp=0x0024cbb0) Line 5132 C++ js_GetProperty(cx=0x04efaea0, obj=0x062d4020, id=0x02bccd94, vp=0x0024cbb0) Line 5218 C++ JSObject::getProperty(cx=0x04efaea0, id=0x02bccd94, vp=0x0024cbb0) Line 359 C++ JS_GetUCProperty(cx=0x04efaea0, obj=0x062d4020, name=0x046089f8, namelen=0x0000000b, vp=0x0024cbb0) Line 3774 C++ GetProperty(cx=0x04efaea0, obj=0x062d4020, identifier=0x02bccd94, rval=0x0024cbb0) Line 582 C++ nsJSObjWrapper::NP_GetProperty(npobj=0x06a92748, identifier=0x02bccd94, result=0x0024cc30) Line 805 C++ mozilla::plugins::parent::_getproperty(npp=0x06b9da18, npobj=0x06a92748, property=0x02bccd94, result=0x0024cc30) Line 1762 C++ mozilla::plugins::PluginScriptableObjectParent::AnswerGetProperty(aId=0x02bccd94, aResult=0x0024d17c, aSuccess=0x0024d17b) Line 1026 C++ mozilla::plugins::PPluginScriptableObjectParent::OnCallReceived(msg={...}, reply=0x00000000) Line 1231 C++ mozilla::plugins::PPluginModuleParent::OnCallReceived(msg={...}, reply=0x00000000) Line 424 C++ mozilla::ipc::RPCChannel::DispatchIncall(call={...}) Line 373 C++ mozilla::ipc::RPCChannel::Incall(call={...}, stackDepth=0x00000000) Line 359 C++ mozilla::ipc::RPCChannel::OnMaybeDequeueOne() Line 293 C++ DispatchToMethod<mozilla::ipc::RPCChannel,void (__thiscall mozilla::ipc::RPCChannel::*)(void)>(obj=0x06b2cb98, method=0x6d739e40, arg={...}) Line 384 C++ RunnableMethod<mozilla::ipc::RPCChannel,void (__thiscall mozilla::ipc::RPCChannel::*)(void),Tuple0>::Run() Line 307 C++ MessageLoop::RunTask(task=0x06acf1a8) Line 327 C++ MessageLoop::DeferOrRunPendingTask(pending_task={...}) Line 337 C++ MessageLoop::DoWork() Line 434 C++ mozilla::ipc::DoWorkRunnable::Run() Line 77 C++ nsThread::ProcessNextEvent(mayWait=0x00000001, result=0x0024d54c) Line 527 C++ NS_ProcessNextEvent_P(thread=0x021f5688, mayWait=0x00000001) Line 250 C++ mozilla::ipc::MessagePump::Run(aDelegate=0x021f2378) Line 142 C++ MessageLoop::RunInternal() Line 212 C++ MessageLoop::RunHandler() Line 195 C++ MessageLoop::Run() Line 169 C++ nsBaseAppShell::Run() Line 180 C++ nsAppShell::Run() Line 240 C++ nsAppStartup::Run() Line 182 C++ XRE_main(argc=0x00000004, argv=0x0045dc78, aAppData=0x021e3268) Line 3476 C++ In NPObjWrapper_NewResolve: + npobj 0x06c4fbe8 {_class=0xdddddddd referenceCount=0xdddddddd } NPObject * Oh how I want valgrind for Windows... but perhaps I can create a testplugin system which calls some methods over and over again. The property being requested in NPN_GetProperty is "clientWidth", and the `id` in NPNObjWrapper_NewResolve is also .clientWidth. The PluginScriptableObjectParent on the stack has a mProtectCount of 1. I *suspect* that the object we're calling NPObjWrapper_NewResolve is the plugin scriptable prototype, but I'm not sure, and I don't know why we'd be freeing it here.
Building this in record+replay now.
Assignee: nobody → bent.mozilla
Status: NEW → ASSIGNED
Blocks: LorentzBeta1
I get this crash on http://silverlight.net/. The area where the silverlight content should be just bounces around a bunch of black boxes then freezes Firefox. After reproducing this a few times, I got this crash. http://crash-stats.mozilla.com/report/index/c77962c7-f5e3-4d9e-9855-946d62100128
blocking2.0: --- → alpha1
Hi there. I'm experiencing the same sort of hang ups and crashes on Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100131 Minefield/3.7a1pre. Though not only with the Silverlight page. I also started having problems with youtube locking up the browser. Ending mozilla-runtime.exe solves the problem temporarily, but if I try to go back on youtube the flash player seems to not be able to connect with the youtube servers to pull data. I imagine this might be caused by a recent update, but I've updated flash player just to be sure.
Ben, do you believe bug 542915 solves this issue completely or partially, or did you just find it along the way?
Bug 542915 does not fix this bug, it was just a problem I encountered along the way.
Attached file Crucial stack —
Here's the stack that shows the problem. We have a race: 1. Parent is done with the plugin's scriptable object, calls releaseObject on the proxy for the object. 2. Dealloc hook of the proxy calls invalidate. 3. Child wins RPC race with a call to get the plugin element (which needs the plugin's scriptable object for proto chain). 4. Actor representing plugin's scriptable object is still alive (and not yet invalidated from child's perspective) and is returned. 5. Parent begins manipulating a doomed NPObject, sets it as a prototype for a live JS object.
Assignee: bent.mozilla → benjamin
This seems too simple, but I did a quick audit of our assumptions and I think they are all correct.
Attachment #424863 - Flags: review?(bent.mozilla)
Attached patch Test — — Splinter Review
Comment on attachment 424863 [details] [diff] [review] Don't invalidate when objects are deallocated, rev. 1 Fingers crossed!
Attachment #424863 - Flags: review?(bent.mozilla) → review+
Landed patch & testcase on bsmedberg's behalf: http://hg.mozilla.org/mozilla-central/rev/c502a1a0900a http://hg.mozilla.org/mozilla-central/rev/8006ad2d0c06
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Version: unspecified → Trunk
This bug's test 'test_GCrace.html' failed on its first cycle on OSX debug mochitest-plain-5 (the only platform to run them so far) http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1265163886.1265164889.19933.gz OS X 10.5.2 mozilla-central debug test mochitests-5/5 on 2010/02/02 18:24:46 4 ERROR TEST-UNEXPECTED-FAIL | /tests/modules/plugin/test/test_GCrace.html | Exception calling callback object: Error: Bad NPObject as private data! Backed out tests: http://hg.mozilla.org/mozilla-central/rev/e03e9d4315d8 and patch: http://hg.mozilla.org/mozilla-central/rev/c502a1a0900a
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Same failure on a "mochitest-other" box: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1265163886.1265166231.2115.gz OS X 10.5.2 mozilla-central debug test mochitest-other on 2010/02/02 18:24:46 3 ERROR TEST-UNEXPECTED-FAIL | /tests/modules/plugin/test/test_GCrace.html | Exception calling callback object: Error: Bad NPObject as private data! That strikes me as highlighting a testing bug -- it looks like we're running the plugins mochitests on both "mochitest-5" as well as "mochitest-other" boxes. Is that a known issue?
FWIW linux and windows were green with this fix, so we either have an IPP bug too or an OOPP-only testcase.
I'm running an hourly build, one of few lately that completed, that should contain this 'fix' prior to being backed-out, and when I visit: silverlight.net , I still see broken/dancing black boxes followed by crash. Since this is an hourly, the crash-report is useless, so not including the link. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100202 Minefield/3.7a1pre ID:20100202195454
I had the first actual crash when visiting silverlight.net just now. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100202 Minefield/3.7a1pre ID:20100202053418
(In reply to comment #15) > That strikes me as highlighting a testing bug -- it looks like we're running > the plugins mochitests on both "mochitest-5" as well as "mochitest-other" > boxes. Is that a known issue? Yeah, it's known. We added a "mochitest-ipcplugins" test run to run just the plugin mochitests with OOPP enabled (before OOPP became the default), so now we wind up running the same tests twice. We should actually probably invert that and run the plugin tests with OOPP disabled to keep coverage of the in-process codepaths.
Relanded with a fix to the test: if you implement NPClass.invoke you have to implement NPClass.invokedefault also due to a host bug. Filed as bug 543977. http://hg.mozilla.org/mozilla-central/rev/4c6d4be91aaa http://hg.mozilla.org/mozilla-central/rev/e9d8b376d014
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Am I missing something here? You've landed the tests, but was the patch itself relanded? I'm running today's nightly, which includes the test, but the patch itself doesn't seem to be included and it's still crashing as before.
Both the patch and the test were landed, and I can no longer reproduce a crash on the original page in question (http://timheuer.com/silverlight/bouncingplane/). If you are experiencing a crash on a different page or with a different signature, please file a new bug. If you are experiencing a crash on this page with this signature, please reopen this one.
My build is: http://hg.mozilla.org/mozilla-central/rev/e2119ce306c0 And the crashes are with the same page and have the same signature: http://crash-stats.mozilla.com/report/index/bp-01b75cfe-8f55-4b64-b495-3c3352100203 The nightly is supposed to have the patch, though I don't see it when I check about:buildconfig. I see the test, though. Did the patch get picked up by a later build?
Just tried the latest hourly and it's fixed. Not sure what's up with the nightly. Thanks
My build is http://hg.mozilla.org/mozilla-central/rev/e2119ce306c0 When I browse to gotmilk and use it or when I reload grooveshark, the browser freezes. I have to kill the mozilla-runtime.exe through the Task Manager to get it working normally again. Vitamin Water works fine. I had the Comment 4, 18 and 19 issue too. The crash report was: http://crash-stats.mozilla.com/report/index/bp-dabfb453-7c67-4e67-93d8-340312100203
(In reply to comment #27) > My build is http://hg.mozilla.org/mozilla-central/rev/e2119ce306c0 > > When I browse to gotmilk and use it or when I reload grooveshark, the browser > freezes. I have to kill the mozilla-runtime.exe through the Task Manager to get > it working normally again. > Vitamin Water works fine. > > I had the Comment 4, 18 and 19 issue too. > The crash report was: > http://crash-stats.mozilla.com/report/index/bp-dabfb453-7c67-4e67-93d8-340312100203 The crash signature matches up, but grooveshark, gotmilk, and vitamin water are certainly flash sites, not silverlight. If we're seeing this stack for flash sites also, should we edit the title?
No, please file a new bug. The bug which I caught in record-and-replay and created a test for here is definitely fixed, and I don't want to confuse other bugs which have the same signature.
sorry, bent caught in record-and-replay ;-)
(In reply to comment #30) > sorry, bent caught in record-and-replay ;-) And by "caught" you meant "spent a day staring at while pounding his head into the wall" ;)
Verified no longer crashes on the pages that I got this crash on Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100204 Minefield/3.7a1pre
Status: RESOLVED → VERIFIED
Same as Kurt with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100204 Minefield/3.7a1pre. The http://silverlight.net/ site shows correctly and doesn't crash any more.
(In reply to comment #27) > My build is http://hg.mozilla.org/mozilla-central/rev/e2119ce306c0 > > When I browse to gotmilk and use it or when I reload grooveshark, the browser > freezes. I have to kill the mozilla-runtime.exe through the Task Manager to get > it working normally again. > Vitamin Water works fine. > > I had the Comment 4, 18 and 19 issue too. > The crash report was: > http://crash-stats.mozilla.com/report/index/bp-dabfb453-7c67-4e67-93d8-340312100203 Gabriela. per comment 29, please file a new bug on the flash sites you are seeing with your crash signature and repro steps; if you can still reproduce on the latest nightly.
(In reply to comment #32) > Verified no longer crashes on the pages that I got this crash on > Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100204 > Minefield/3.7a1pre Strange, I was testing earlier today and the site listed in the URL now prompts to install SilverLight - BSM is aware as I spoke to him via IRC earlier today. Might double-check and make sure that OOPP is still enabled.
(In reply to comment # 34) Gabriela. per comment 29, please file a new bug on the flash sites you are seeing with your crash signature and repro steps; if you can still reproduce on the latest nightly. Tony, I can still reproduce on the latest nightly, on which the hangs are even worse than they were with yesterday's nightly. I'll file a new bug.
Regarding comment # 36) Tony, I've filed the new bug.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100205 Minefield/3.7a1pre Silverlight showcase either doesn't load or shows kinds of black squares and it freezes the browser. I have to kill mozill-runtimes exe to keep it working. It works fine with ipc disabled. Gotmilk loads up to 25% and stops loading whether ipc is enabled or not. Grooveshark, NBCOlympics, Youtube, Dailymotion, Bing Videos, Vitamin Water and the Java sites work fine.
I'm really sorry, the thing that landed on m-c was empty and the test wasn't enabled. comment #20 is right and I didn't notice it relative to my new commit. I'll reland correctly in a bit when the tree greens.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Blocks: LorentzAlpha
Any chance of this landing soon? :-)
This landed Wednesday, should be fixed in yesterday's nightlies. http://hg.mozilla.org/mozilla-central/rev/7a79644eccc5 http://hg.mozilla.org/mozilla-central/rev/ddf08d08b434
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100219 Minefield/3.7a2pre http://www.silverlight.net/showcase/ doesn't finish loading even after killing the m-r processes. It doesn't crash the browser nor it freezes the tabs though.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: