My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 154462: Chrome: Crash Report - Stack Signature: WebCore::freeV8NPObject-88d4d06b_9c80ff3c_0...
38 people starred this issue and may be notified of changes. Back to list
 
Project Member Reported by dhar...@chromium.org, Oct 6, 2012
jsbell@: could you please take a look?

Product: Chrome
Stack Signature: WebCore::freeV8NPObject-3AE2D54
New Signature Label: WebCore::freeV8NPObject
New Signature Hash: 88d4d06b_9c80ff3c_0c563f6b_ece1b24e_aabe2a27

Report link: http://go/crash/reportdetail?reportid=1488b06bca741d0e

Meta information:
Product Name: Chrome
Product Version: 24.0.1288.1
Report ID: 1488b06bca741d0e
Report Time: 2012/10/06 13:50:25, Sat
Uptime: 196 sec
Cumulative Uptime: 0 sec
OS Name: Windows NT
OS Version: 6.1.7601 Service Pack 1
CPU Architecture: x86
CPU Info: GenuineIntel family 6 model 42 stepping 7
ptype: renderer


Thread 0 *CRASHED* ( EXCEPTION_ACCESS_VIOLATION_READ @ 0x00000004 )

0x65335097	 [chrome.dll]	 - npv8object.cpp:85 (cs|src|ann)]	WebCore::freeV8NPObject
0x65334a3a	 [chrome.dll]	 - npruntime.cpp:310 (cs|src|ann)]	_NPN_DeallocateObject
0x65279a23	 [chrome.dll]	 - npruntime.cpp:323 (cs|src|ann)]	_NPN_ReleaseObject
0x6699fc08	 [chrome.dll]	 - npobject_stub.cc:57 (cs|src|ann)]	NPObjectStub::DeleteSoon()
0x6699fc58	 [chrome.dll]	 - npobject_stub.cc:114 (cs|src|ann)]	NPObjectStub::OnRelease(IPC::Message *)
0x669201f3	 [chrome.dll]	 - ipc_message_utils.h:876 (cs|src|ann)]	IPC::SyncMessageSchema<Tuple0,Tuple0>::DispatchDelayReplyWithSendParams<TestingAutomationProvider,void ( TestingAutomationProvider::*)(IPC::Message *)>(bool,Tuple0 const &,IPC::Message const *,TestingAutomationProvider *,void ( TestingAutomationProvider::*)(IPC::Message *))
0x66920856	 [chrome.dll]	 - automation_messages_internal.h:938 (cs|src|ann)]	AutomationMsg_WaitForProcessLauncherThreadToGoIdle::DispatchDelayReply<TestingAutomationProvider,void ( TestingAutomationProvider::*)(IPC::Message *)>(IPC::Message const *,TestingAutomationProvider *,void ( TestingAutomationProvider::*)(IPC::Message *))
0x669a0b2f	 [chrome.dll]	 - npobject_stub.cc:91 (cs|src|ann)]	NPObjectStub::OnMessageReceived(IPC::Message const &)
0x65125e53	 [chrome.dll]	 - message_router.cc:47 (cs|src|ann)]	MessageRouter::RouteMessage(IPC::Message const &)
0x6699f36f	 [chrome.dll]	 - np_channel_base.cc:174 (cs|src|ann)]	NPChannelBase::OnMessageReceived(IPC::Message const &)
0x6506daf5	 [chrome.dll]	 - ipc_channel_proxy.cc:261 (cs|src|ann)]	IPC::ChannelProxy::Context::OnDispatchMessage(IPC::Message const &)
0x650674fd	 [chrome.dll]	 - bind_internal.h:1256 (cs|src|ann)]	base::internal::Invoker<2,base::internal::BindState<base::internal::RunnableAdapter<void ( extensions::FileSystemEntryFunction::*)(FilePath const &)>,void (extensions::FileSystemEntryFunction *,FilePath const &),void (extensions::FileSystemChooseEntryFunction *,FilePath)>,void (extensions::FileSystemEntryFunction *,FilePath const &)>::Run(base::internal::BindStateBase *)
0x65067dbb	 [chrome.dll]	 - message_loop.cc:470 (cs|src|ann)]	MessageLoop::RunTask(base::PendingTask const &)
0x65067b2e	 [chrome.dll]	 - message_loop.cc:661 (cs|src|ann)]	MessageLoop::DoWork()
0x650680fe	 [chrome.dll]	 - message_pump_default.cc:28 (cs|src|ann)]	base::MessagePumpDefault::Run(base::MessagePump::Delegate *)
0x6506777e	 [chrome.dll]	 - message_loop.cc:427 (cs|src|ann)]	MessageLoop::RunInternal()
0x650676d6	 [chrome.dll]	 - run_loop.cc:45 (cs|src|ann)]	base::RunLoop::Run()
0x6506dd66	 [chrome.dll]	 - message_loop.cc:307 (cs|src|ann)]	MessageLoop::Run()
0x650d2fee	 [chrome.dll]	 - renderer_main.cc:239 (cs|src|ann)]	RendererMain(content::MainFunctionParams const &)
0x65058207	 [chrome.dll]	 - content_main_runner.cc:441 (cs|src|ann)]	content::RunNamedProcessTypeMain(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &,content::MainFunctionParams const &,content::ContentMainDelegate *)
0x6505818e	 [chrome.dll]	 - content_main_runner.cc:734 (cs|src|ann)]	content::ContentMainRunnerImpl::Run()
0x6504a5f0	 [chrome.dll]	 - content_main.cc:35 (cs|src|ann)]	content::ContentMain(HINSTANCE__ *,sandbox::SandboxInterfaceInfo *,content::ContentMainDelegate *)
0x6504a57c	 [chrome.dll]	 - chrome_main.cc:28 (cs|src|ann)]	ChromeMain
0x011751f0	 [chrome.exe]	 - client_util.cc:440 (cs|src|ann)]	MainDllLoader::Launch(HINSTANCE__ *,sandbox::SandboxInterfaceInfo *)
0x011778c3	 [chrome.exe]	 - chrome_exe_main_win.cc:76 (cs|src|ann)]	RunChrome(HINSTANCE__ *)
0x0117792e	 [chrome.exe]	 - chrome_exe_main_win.cc:92 (cs|src|ann)]	wWinMain
0x011d044c	 [chrome.exe]	 - crt0.c:275]	__tmainCRTStartup
0x75063399	 [kernel32.dll]	 + 0x00013399]	BaseThreadInitThunk
0x77149ef1	 [ntdll.dll]	 + 0x00039ef1]	__RtlUserThreadStart
0x77149ec4	 [ntdll.dll]	 + 0x00039ec4]	_RtlUserThreadStart
Oct 8, 2012
#1 jsbell@chromium.org
dharani@ - looking, but I'm not familiar with this code - doesn't appear to be an IDB-related issue. Anything I'm missing?
Oct 8, 2012
#2 dhar...@chromium.org
There aren't any crashes in M23. In M24, it started from 24.0.1282.0 build.
Status: Available
Owner: ---
Cc: wez@chromium.org fsam...@chromium.org
Oct 8, 2012
#3 jsbell@chromium.org
Ah, it appears I show up as I touched the line due to a revert in http://trac.webkit.org/changeset/123110

Related to crbug.com/152318 perhaps?
Oct 8, 2012
#4 jsbell@chromium.org
http://trac.webkit.org/changeset/129933 is the likely culprit

(And FYI, there's one similar stack in 22, possibly from the code that was reverted)
Oct 9, 2012
#5 wez@chromium.org
It looks like we're somehow getting a NULL pointer to an WTF::Vector in the reference returned from WTF::HashMap for the context; I've no idea how that can happen, though.
Oct 9, 2012
#6 wez@chromium.org
http://trac.webkit.org/changeset/129933 was in Chrome 24.0.1281.0, for which there was only a Mac Canary, not a Windows one; do we see stacks similar to this from Mac at all?
Oct 12, 2012
#8 dhar...@google.com
(No comment was entered for this change.)
Status: Assigned
Owner: fsam...@chromium.org
Cc: -fsam...@chromium.org
Oct 15, 2012
#9 fsam...@chromium.org
This stack trace doesn't make sense to me. V8NPObjectVector is stored by value in each pair in V8NPObjectMap. For the vector to be null, then the map is most likely also invalid. If the map is invalid, then so is the PerContextData. Yet, the per-context data is non-NULL. This suggests that we're returning an invalid per-context data pointer. Adam, thoughts? Is it possible for V8PerContextData::from to return an invalid (already deleted) pointer?
Cc: abarth@chromium.org
Oct 29, 2012
#10 dhar...@google.com
(No comment was entered for this change.)
Labels: ReleaseBlock-Stable
Oct 29, 2012
#11 abarth@chromium.org
Maybe this is caused by the aux context used by IDB?

https://bugs.webkit.org/show_bug.cgi?id=99975
Oct 29, 2012
#12 abarth@chromium.org
+jsbell for the possible aux context connection.
Cc: jsbell@chromium.org
Oct 29, 2012
#13 jsbell@chromium.org
I suppose it's possible, but there's no indication that IDB is involved. The URLs given in the crash report, when loaded, don't appear to show any IDB activity, nor is there anything on the stack. (Could be hidden or leaving V8 in a bad state?) There's also the similar stack from M22, which predates the problematic IDB use of aux context.

Nov 15, 2012
#14 fsam...@chromium.org
(No comment was entered for this change.)
Labels: Feature-Apps-BrowserTag Iteration-69
Nov 23, 2012
#16 TerekhovM
I can reproduce this issue.
OS: Windows 7 x64.
Version: 24.0.1312.14 beta-m

1. My web page contains frame. There is a hyperlink in frame document A, that loads other document B in frame. 
2. My web page contains NP plugin instance. NP holds the NPObject* reference to object from frame document A.

Steps:
1. Get NPObject* reference to object from frame document A inside NP plugin.
2. Click on hyperlink in frame.
3. Try to release gotten object reference inside NP plugin.

Renderer process crashes with the same exception and stack, "Aw, snap!" error message appears.
Nov 23, 2012
#17 fsam...@chromium.org
Interesting! This repro description helps a lot. If you have a sample page that has that repro that would be even better but we'll try to repro this locally based on your description. Thanks!
Nov 26, 2012
#18 TerekhovM
>>> If you have a sample page that has that repro that would be even better but we'll try to repro this locally based on your description.

Steps to reproduce:
1. Unpack CrBug.zip.
2. Install extension (in developer mode as unpacked) from the folder CrBug\Extension. It will register NP plugin without Windows registry witchcraft. You can find NP plugin sources in CrBug\Src directory (C++, VS 2005, NP API headers are not included!!).
3. Run Chrome with comand line switch --allow-file-access-from-files
4. Open page CrBug\Page\main.html
5. Click "Save object from frame" button.
6. Click hyperlink "Go to B document" in frame document.
7. Click "Drop object from frame" button.
Renderer process crashes with the same exception and stack, "Aw, snap!" error message appears.

Details:
Web page contains frame. There is a hyperlink in frame document A, that loads other document B in frame. Web page also contains NP plugin instance.
On step 5: NP holds the NPObject* reference to object from frame document A. It is important: this NPObject "is" frame.contentWindow. See CnpSampleInstanceScriptableObject::DoSetProperty (npSampleInstanceScriptableObject.cpp).
On step 6: New document appears in frame.
On step 7: NP releases gotten object reference. See CnpSampleInstanceScriptableObject::DoSetProperty (npSampleInstanceScriptableObject.cpp). And it crashes renderer process.

I observe this behavior only for in-frame Window object. Not for elements, not for document. It was quite difficult to create this minimal reproduction. I hope steps above will help you fix this bug before 24 Release :).




CrBug.zip
39.0 KB   Download
Nov 26, 2012
#19 fsam...@chromium.org
Bulk moving open items that are actively being worked on to Iteration-70
Labels: Iteration-70
Nov 26, 2012
#20 lazyboy@chromium.org
I've started looking into this.
@TerekhovM, the test case very much appreciated! Thank you.
I can reproduce a crash with TestNetscapePlugin, hopefully that's for the similar cause @TerekhovM describes and this bug's crash reports.

It seems in freeV8NPObject() we used to ignore removing V8NPObject* if the object was not found in the context map, now it tries to assert and then removing it triggers the crash (ref: https://bugs.webkit.org/attachment.cgi?id=166285&action=review).

I will upload a webkit patch when I'm done writing test for this.
 
Status: Started
Owner: lazyboy@chromium.org
Nov 27, 2012
#22 dhar...@google.com
(No comment was entered for this change.)
Labels: webkit-id-103356
Nov 27, 2012
#23 bugdro...@chromium.org
https://bugs.webkit.org/show_bug.cgi?id=103356
http://trac.webkit.org/changeset/135874
Summary: Chrome: Crash Report - Stack Signature: WebCore::freeV8NPObject-88d4d06b_9c80ff3c_0...
Labels: -webkit-id-103356 WebKit-ID-103356-RESOLVED WebKit-Rev-135874
Nov 28, 2012
#24 pnihal...@chromium.org
After following instructions in comment#18 was able to reproduce this issue on win chrome 25.0.1323.1 (Official Build 167142).
Nov 28, 2012
#25 lazyboy@chromium.org
Verified following with TestNetscapePlugin and my sample page.

(Windows builds)
r169963, version 25.0.1338.0 (webkit r135920): No crash.
r169641, version 25.0.1337.0 (webkit r135721): Crashes the renderer.
So the regression should be fixed @r169963.

Requesting merge.

Status: Fixed
Labels: Merge-Requested
Nov 28, 2012
#26 dhar...@google.com
(No comment was entered for this change.)
Labels: -Merge-Requested Merge-Approved
Nov 28, 2012
#27 dhar...@google.com
(No comment was entered for this change.)
Labels: -Merge-Approved Merge-Merged-1312
Nov 29, 2012
#28 TerekhovM
Is there any chance of fixing this bug in Chrome 24 stable release? It's critical for NP plugin developing.
Nov 29, 2012
#29 lazyboy@chromium.org
@TerekhovM yes it should be.
Nov 29, 2012
#30 dhar...@google.com
TerekhovM: I'm pushing a Chrome 24 beta today with the fix.
Nov 29, 2012
#31 fsam...@chromium.org
Thanks again TerekhovM@ for your repro description and test case!
Dec 13, 2012
#32 nyerrami...@chromium.org
Followed the steps given in Comment #18,
not able to repro this issue on Chrome Beta 24.0.1312.40 ,Dev 25.0.1359.3 and Canary 25.0.1359.3 on Win7 (x64 bit)


Cc: nyerrami...@chromium.org
Mar 10, 2013
#33 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Mstone-24 -Area-WebKit -Feature-Apps-BrowserTag Cr-Content Cr-Platform-Apps-BrowserTag M-24
Apr 5, 2013
#34 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Cr-Content Cr-Blink
Jun 20, 2014
#35 srsrid...@chromium.org
(No comment was entered for this change.)
Labels: hasTestcase
Sign in to add a comment

Powered by Google Project Hosting