New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 154462 link

Starred by 38 users

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

Chrome: Crash Report - Stack Signature: WebCore::freeV8NPObject-88d4d06b_9c80ff3c_0...

Reported by dharani@chromium.org, Oct 6 2012

Issue description

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
 
dharani@ - looking, but I'm not familiar with this code - doesn't appear to be an IDB-related issue. Anything I'm missing?
Cc: w...@chromium.org fsam...@chromium.org
Owner: ----
Status: Available
There aren't any crashes in M23. In M24, it started from 24.0.1282.0 build.
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?
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)

Comment 5 by w...@chromium.org, Oct 9 2012

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.

Comment 6 by w...@chromium.org, Oct 9 2012

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?

Comment 8 by dharani@google.com, Oct 12 2012

Cc: -fsam...@chromium.org
Owner: fsam...@chromium.org
Status: Assigned
Cc: abarth@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?

Comment 10 by dharani@google.com, Oct 29 2012

Labels: ReleaseBlock-Stable
Maybe this is caused by the aux context used by IDB?

https://bugs.webkit.org/show_bug.cgi?id=99975
Cc: jsb...@chromium.org
+jsbell for the possible aux context connection.
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.

Labels: Feature-Apps-BrowserTag Iteration-69

Comment 15 Deleted

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.
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!
>>> 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
Labels: Iteration-70
Bulk moving open items that are actively being worked on to Iteration-70
Owner: lazyboy@chromium.org
Status: Started
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.
 

Comment 22 by dharani@google.com, Nov 27 2012

Labels: webkit-id-103356
Project Member

Comment 23 by bugdroid1@chromium.org, Nov 27 2012

Labels: -webkit-id-103356 WebKit-ID-103356-RESOLVED WebKit-Rev-135874
Summary: Chrome: Crash Report - Stack Signature: WebCore::freeV8NPObject-88d4d06b_9c80ff3c_0...
https://bugs.webkit.org/show_bug.cgi?id=103356
http://trac.webkit.org/changeset/135874
After following instructions in comment#18 was able to reproduce this issue on win chrome 25.0.1323.1 (Official Build 167142).
Labels: Merge-Requested
Status: Fixed
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.

Comment 26 by dharani@google.com, Nov 28 2012

Labels: -Merge-Requested Merge-Approved

Comment 27 by dharani@google.com, Nov 28 2012

Labels: -Merge-Approved Merge-Merged-1312
Is there any chance of fixing this bug in Chrome 24 stable release? It's critical for NP plugin developing.
@TerekhovM yes it should be.

Comment 30 by dharani@google.com, Nov 29 2012

TerekhovM: I'm pushing a Chrome 24 beta today with the fix.
Thanks again TerekhovM@ for your repro description and test case!
Cc: nyerramilli@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)


Project Member

Comment 33 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Mstone-24 -Area-WebKit -Feature-Apps-BrowserTag Cr-Content Cr-Platform-Apps-BrowserTag M-24
Project Member

Comment 34 by bugdroid1@chromium.org, Apr 5 2013

Labels: -Cr-Content Cr-Blink
Labels: hasTestcase

Sign in to add a comment