[chromium-dev] Re: Sending FDs between processes in the face of the OS X Sandbox.
Well, we don't have a sandbox on Linux. The normal fd-passing recvmesg() should work fine. Who knows if it will work if we ever get a sandbox. On Tue, Jan 27, 2009 at 5:55 AM, Andrew Scherkus scher...@chromium.org wrote: Great! I'm really interested in using shared FDs. Just to clarify, we're unsure whether this works for Linux? Thanks again, Andrew On Mon, Jan 26, 2009 at 2:17 PM, Jeremy Moskovich jer...@chromium.org wrote: There's been discussion recently about sending FDs between processes so that renderer processes can access files directly. I ran some tests on OS X to see whether you can send an FD when the receiving process is sandboxed. It turns out that this does indeed work, even when using the more restrictive kSBXProfilePureComputation sandbox profile. Note that support for this still needs to be added to the POSIX version of IPC::Channel. Best regards, Jeremy --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Browser Bootstrapping Plan
I've hung off this page another page for Mac issues that will need followup ( http://sites.google.com/a/chromium.org/dev/developers/browser-bootstrapping/mac-followup). As you hit other issues, please note them there so they are all in one place. TVL On Tue, Jan 20, 2009 at 10:18 AM, Mike Pinkerton pinker...@chromium.orgwrote: We had a meeting last week to talk about how to get to a running multi-process browser by mid-Feb. I was asked to follow-up with a document where we could collaborate, and have done so: http://sites.google.com/a/chromium.org/dev/developers/browser-bootstrapping Let me know if you have any feedback. -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] mismatched new/delete[] in webkit?
Noticed in passing while looking for something else this morning (though they may have been there a while). These sound potentially nasty; is anybody looking at them already? $ valgrind --track-origins=yes Hammer/test_shell_tests ... [ RUN ] WebFrameTest.GetContentAsPlainText UNIMPLEMENTED: (/home/dank/chromium/src/webkit/port/bindings/v8/ScriptController.cpp:143 updatePlatformScriptObjects) Mismatched free() / delete / delete [] at free (vg_replace_malloc.c:323) by WTF::fastFree(void*) (FastMalloc.cpp:216) by WebCore::CSSSelectorList::adoptSelectorVector(WTF::VectorWebCore::CSSSelector*, 0u) (CSSSelectorList.cpp:57) by WebCore::CSSStyleRule::adoptSelectorVector(WTF::VectorWebCore::CSSSelector*, 0u) (CSSStyleRule.h:53) by WebCore::CSSParser::createStyleRule(WTF::VectorWebCore::CSSSelector*, 0u*) (CSSParser.cpp:4547) by cssyyparse(void*) (CSSGrammar.y:792) by WebCore::CSSParser::parseSheet(WebCore::CSSStyleSheet*, WebCore::String const) (CSSParser.cpp:224) by WebCore::CSSStyleSheet::parseString(WebCore::String const, bool) (CSSStyleSheet.cpp:164) by WebCore::parseUASheet(WebCore::String const) (CSSStyleSelector.cpp:486) by WebCore::parseUASheet(char const*, unsigned int) (CSSStyleSelector.cpp:492) by WebCore::loadSimpleDefaultStyle() (CSSStyleSelector.cpp:531) by WebCore::CSSStyleSelector::CSSStyleSelector(WebCore::Document*, WebCore::String const, WebCore::StyleSheetList*, WebCore::CSSStyleSheet*, bool, bool) (CSSStyleSelector.cpp:406) Address 0x127ac840 is 0 bytes inside a block of size 16 alloc'd at operator new(unsigned int) (vg_replace_malloc.c:224) by WebCore::CSSParser::createFloatingSelector() (CSSParser.cpp:4382) by cssyyparse(void*) (CSSGrammar.y:883) by WebCore::CSSParser::parseSheet(WebCore::CSSStyleSheet*, WebCore::String const) (CSSParser.cpp:224) by WebCore::CSSStyleSheet::parseString(WebCore::String const, bool) (CSSStyleSheet.cpp:164) by WebCore::parseUASheet(WebCore::String const) (CSSStyleSelector.cpp:486) by WebCore::parseUASheet(char const*, unsigned int) (CSSStyleSelector.cpp:492) by WebCore::loadSimpleDefaultStyle() (CSSStyleSelector.cpp:531) by WebCore::CSSStyleSelector::CSSStyleSelector(WebCore::Document*, WebCore::String const, WebCore::StyleSheetList*, WebCore::CSSStyleSheet*, bool, bool) (CSSStyleSelector.cpp:406) by WebCore::Document::attach() (Document.cpp:1383) by WebCore::Frame::setDocument(WTF::PassRefPtrWebCore::Document) (Frame.cpp:272) by WebCore::FrameLoader::begin(WebCore::KURL const, bool, WebCore::SecurityOrigin*) (FrameLoader.cpp:949) Mismatched free() / delete / delete [] at operator delete(void*) (vg_replace_malloc.c:342) by WebCore::V8Proxy::InitContextIfNeeded() (v8_proxy.cpp:2318) by WebCore::V8Proxy::GetContext(WebCore::Frame*) (v8_proxy.cpp:2473) by WebCore::ScriptController::BindToWindowObject(WebCore::Frame*, WebCore::String const, NPObject*) (ScriptController.cpp:278) by WebFrameImpl::BindToWindowObject(std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t const, NPObject*) (webframe_impl.cc:689) by CppBoundClass::BindToJavascript(WebFrame*, std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t const) (cpp_bound_class.cc:255) by TestShell::BindJSObjectsToWindow(WebFrame*) (test_shell.cc:409) by TestWebViewDelegate::WindowObjectCleared(WebFrame*) (test_webview_delegate.cc:122) by WebFrameLoaderClient::windowObjectCleared() (webframeloaderclient_impl.cc:100) by WebCore::FrameLoader::dispatchWindowObjectAvailable() (FrameLoader.cpp:5180) by WebCore::FrameLoader::receivedFirstData() (FrameLoader.cpp:878) by WebCore::FrameLoader::setEncoding(WebCore::String const, bool) (FrameLoader.cpp:1899) Address 0x11c66678 is 0 bytes inside a block of size 4 alloc'd at operator new[](unsigned int) (vg_replace_malloc.c:268) by WebCore::V8Proxy::InitContextIfNeeded() (v8_proxy.cpp:2309) by WebCore::V8Proxy::GetContext(WebCore::Frame*) (v8_proxy.cpp:2473) by WebCore::ScriptController::BindToWindowObject(WebCore::Frame*, WebCore::String const, NPObject*) (ScriptController.cpp:278) by WebFrameImpl::BindToWindowObject(std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t const, NPObject*) (webframe_impl.cc:689) by CppBoundClass::BindToJavascript(WebFrame*, std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t const) (cpp_bound_class.cc:255) by TestShell::BindJSObjectsToWindow(WebFrame*) (test_shell.cc:409) by TestWebViewDelegate::WindowObjectCleared(WebFrame*) (test_webview_delegate.cc:122) by WebFrameLoaderClient::windowObjectCleared() (webframeloaderclient_impl.cc:100) by WebCore::FrameLoader::dispatchWindowObjectAvailable() (FrameLoader.cpp:5180) by WebCore::FrameLoader::receivedFirstData() (FrameLoader.cpp:878) by WebCore::FrameLoader::setEncoding(WebCore::String const, bool) (FrameLoader.cpp:1899) UNIMPLEMENTED:
[chromium-dev] Re: mismatched new/delete[] in webkit?
The last one looks similar to https://bugs.webkit.org/show_bug.cgi?id=23473 or https://bugs.webkit.org/show_bug.cgi?id=22834, which Brett Wilson and Dean McNamee appear to be working on. - James On Tue, Jan 27, 2009 at 11:45 AM, Dan Kegel daniel.r.ke...@gmail.comwrote: Noticed in passing while looking for something else this morning (though they may have been there a while). These sound potentially nasty; is anybody looking at them already? $ valgrind --track-origins=yes Hammer/test_shell_tests ... [ RUN ] WebFrameTest.GetContentAsPlainText UNIMPLEMENTED: (/home/dank/chromium/src/webkit/port/bindings/v8/ScriptController.cpp:143 updatePlatformScriptObjects) Mismatched free() / delete / delete [] at free (vg_replace_malloc.c:323) by WTF::fastFree(void*) (FastMalloc.cpp:216) by WebCore::CSSSelectorList::adoptSelectorVector(WTF::VectorWebCore::CSSSelector*, 0u) (CSSSelectorList.cpp:57) by WebCore::CSSStyleRule::adoptSelectorVector(WTF::VectorWebCore::CSSSelector*, 0u) (CSSStyleRule.h:53) by WebCore::CSSParser::createStyleRule(WTF::VectorWebCore::CSSSelector*, 0u*) (CSSParser.cpp:4547) by cssyyparse(void*) (CSSGrammar.y:792) by WebCore::CSSParser::parseSheet(WebCore::CSSStyleSheet*, WebCore::String const) (CSSParser.cpp:224) by WebCore::CSSStyleSheet::parseString(WebCore::String const, bool) (CSSStyleSheet.cpp:164) by WebCore::parseUASheet(WebCore::String const) (CSSStyleSelector.cpp:486) by WebCore::parseUASheet(char const*, unsigned int) (CSSStyleSelector.cpp:492) by WebCore::loadSimpleDefaultStyle() (CSSStyleSelector.cpp:531) by WebCore::CSSStyleSelector::CSSStyleSelector(WebCore::Document*, WebCore::String const, WebCore::StyleSheetList*, WebCore::CSSStyleSheet*, bool, bool) (CSSStyleSelector.cpp:406) Address 0x127ac840 is 0 bytes inside a block of size 16 alloc'd at operator new(unsigned int) (vg_replace_malloc.c:224) by WebCore::CSSParser::createFloatingSelector() (CSSParser.cpp:4382) by cssyyparse(void*) (CSSGrammar.y:883) by WebCore::CSSParser::parseSheet(WebCore::CSSStyleSheet*, WebCore::String const) (CSSParser.cpp:224) by WebCore::CSSStyleSheet::parseString(WebCore::String const, bool) (CSSStyleSheet.cpp:164) by WebCore::parseUASheet(WebCore::String const) (CSSStyleSelector.cpp:486) by WebCore::parseUASheet(char const*, unsigned int) (CSSStyleSelector.cpp:492) by WebCore::loadSimpleDefaultStyle() (CSSStyleSelector.cpp:531) by WebCore::CSSStyleSelector::CSSStyleSelector(WebCore::Document*, WebCore::String const, WebCore::StyleSheetList*, WebCore::CSSStyleSheet*, bool, bool) (CSSStyleSelector.cpp:406) by WebCore::Document::attach() (Document.cpp:1383) by WebCore::Frame::setDocument(WTF::PassRefPtrWebCore::Document) (Frame.cpp:272) by WebCore::FrameLoader::begin(WebCore::KURL const, bool, WebCore::SecurityOrigin*) (FrameLoader.cpp:949) Mismatched free() / delete / delete [] at operator delete(void*) (vg_replace_malloc.c:342) by WebCore::V8Proxy::InitContextIfNeeded() (v8_proxy.cpp:2318) by WebCore::V8Proxy::GetContext(WebCore::Frame*) (v8_proxy.cpp:2473) by WebCore::ScriptController::BindToWindowObject(WebCore::Frame*, WebCore::String const, NPObject*) (ScriptController.cpp:278) by WebFrameImpl::BindToWindowObject(std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t const, NPObject*) (webframe_impl.cc:689) by CppBoundClass::BindToJavascript(WebFrame*, std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t const) (cpp_bound_class.cc:255) by TestShell::BindJSObjectsToWindow(WebFrame*) (test_shell.cc:409) by TestWebViewDelegate::WindowObjectCleared(WebFrame*) (test_webview_delegate.cc:122) by WebFrameLoaderClient::windowObjectCleared() (webframeloaderclient_impl.cc:100) by WebCore::FrameLoader::dispatchWindowObjectAvailable() (FrameLoader.cpp:5180) by WebCore::FrameLoader::receivedFirstData() (FrameLoader.cpp:878) by WebCore::FrameLoader::setEncoding(WebCore::String const, bool) (FrameLoader.cpp:1899) Address 0x11c66678 is 0 bytes inside a block of size 4 alloc'd at operator new[](unsigned int) (vg_replace_malloc.c:268) by WebCore::V8Proxy::InitContextIfNeeded() (v8_proxy.cpp:2309) by WebCore::V8Proxy::GetContext(WebCore::Frame*) (v8_proxy.cpp:2473) by WebCore::ScriptController::BindToWindowObject(WebCore::Frame*, WebCore::String const, NPObject*) (ScriptController.cpp:278) by WebFrameImpl::BindToWindowObject(std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t const, NPObject*) (webframe_impl.cc:689) by CppBoundClass::BindToJavascript(WebFrame*, std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t const) (cpp_bound_class.cc:255) by TestShell::BindJSObjectsToWindow(WebFrame*) (test_shell.cc:409) by TestWebViewDelegate::WindowObjectCleared(WebFrame*) (test_webview_delegate.cc:122) by WebFrameLoaderClient::windowObjectCleared() (webframeloaderclient_impl.cc:100) by
[chromium-dev] Re: Accessing DOM from extension process
It seemed complicated to allow other processes direct access to the DOM, so we were not going to do that. For something like the inspector, what we were thinking is a client/server model, with the client being JS that interacts with the DOM and the server being in another process and showing the inspector UI. What are the goals for moving the inspector out of the renderer process? - a On Tue, Jan 27, 2009 at 6:35 AM, Yury Semikhatsky yu...@chromium.org wrote: Hi, I work on Web Inspector/JS Debugger in Chrome. Currently we're trying to move it out of the renderer process of the inspected page. To be able to run Web Inspector in its own process we need a way to access inspected page resources, DOM and v8 instance from outside of the page's renderer process. Since extensions are also supposed to live in separate processes it seems that we could share the framework for resource access with them or even better implement Web Inspector as a regular extension. I wonder what the current state of the extension framework is and if there are still plans to give extensions access to the inspected page that we can reuse in Web Inspector? Thanks, Yury --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Accessing DOM from extension process
On Tue, Jan 27, 2009 at 8:08 PM, Aaron Boodman a...@chromium.org wrote: It seemed complicated to allow other processes direct access to the DOM, so we were not going to do that. But many extensions will need to access the DOM one way or another. Are you going to restrict this access or probably inject extensions code directly into the page(as it's described in early design document)? For something like the inspector, what we were thinking is a client/server model, with the client being JS that interacts with the DOM and the server being in another process and showing the inspector UI. What are the goals for moving the inspector out of the renderer process? The main goal for moving Web Inspector into separate renderer process is to reduce impact of the inspector code on the inspected page. In particular as inspector UI implemented in JS it may interfere with the page execution. So the question was exactly about that client/server model for inspector/page communication. - a On Tue, Jan 27, 2009 at 6:35 AM, Yury Semikhatsky yu...@chromium.org wrote: Hi, I work on Web Inspector/JS Debugger in Chrome. Currently we're trying to move it out of the renderer process of the inspected page. To be able to run Web Inspector in its own process we need a way to access inspected page resources, DOM and v8 instance from outside of the page's renderer process. Since extensions are also supposed to live in separate processes it seems that we could share the framework for resource access with them or even better implement Web Inspector as a regular extension. I wonder what the current state of the extension framework is and if there are still plans to give extensions access to the inspected page that we can reuse in Web Inspector? Thanks, Yury --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Accessing DOM from extension process
With regard to moving the DOM inspector out of process Sergey Ryazanov have filed https://bugs.webkit.org/show_bug.cgi?id=23502 with a rather large patch where the inspector access to the DOM is being factored to an interface layer which will allow us to move the DOM inspector out-of-process. /Søren On Tue, Jan 27, 2009 at 7:05 PM, Yury Semikhatsky yu...@chromium.orgwrote: On Tue, Jan 27, 2009 at 8:08 PM, Aaron Boodman a...@chromium.org wrote: It seemed complicated to allow other processes direct access to the DOM, so we were not going to do that. But many extensions will need to access the DOM one way or another. Are you going to restrict this access or probably inject extensions code directly into the page(as it's described in early design document)? For something like the inspector, what we were thinking is a client/server model, with the client being JS that interacts with the DOM and the server being in another process and showing the inspector UI. What are the goals for moving the inspector out of the renderer process? The main goal for moving Web Inspector into separate renderer process is to reduce impact of the inspector code on the inspected page. In particular as inspector UI implemented in JS it may interfere with the page execution. So the question was exactly about that client/server model for inspector/page communication. - a On Tue, Jan 27, 2009 at 6:35 AM, Yury Semikhatsky yu...@chromium.org wrote: Hi, I work on Web Inspector/JS Debugger in Chrome. Currently we're trying to move it out of the renderer process of the inspected page. To be able to run Web Inspector in its own process we need a way to access inspected page resources, DOM and v8 instance from outside of the page's renderer process. Since extensions are also supposed to live in separate processes it seems that we could share the framework for resource access with them or even better implement Web Inspector as a regular extension. I wonder what the current state of the extension framework is and if there are still plans to give extensions access to the inspected page that we can reuse in Web Inspector? Thanks, Yury --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Accessing DOM from extension process
On Tue, Jan 27, 2009 at 12:04 PM, Søren Gjesse sgje...@chromium.org wrote: With regard to moving the DOM inspector out of process Sergey Ryazanov have filed https://bugs.webkit.org/show_bug.cgi?id=23502 with a rather large patch where the inspector access to the DOM is being factored to an interface layer which will allow us to move the DOM inspector out-of-process. Wow, that's a serious patch. I see that the DOM facade is stateful... will updates to the page DOM be asynchronous or synchronous? I think for extensions we actually like the idea of separating the code that interacts with the DOM and the privileged code that will run in extensions, and having a high-level message-passing style API between them. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: mismatched new/delete[] in webkit?
(apologies for resend) Yes. This is the same issue. This was also reported in: http://code.google.com/p/chromium/issues/detail?id=5464 where we decided to filter the errors in Purify because the code was argued to be correct and an important optimization (and they didn't want to change it). Dean's making an attempt to get a real fix on the WebKit side of things in the bug James linked to. Erik On Tue, Jan 27, 2009 at 8:52 AM, James Robinson jam...@google.com wrote: The last one looks similar to https://bugs.webkit.org/show_bug.cgi?id=23473 or https://bugs.webkit.org/show_bug.cgi?id=22834, which Brett Wilson and Dean McNamee appear to be working on. - James On Tue, Jan 27, 2009 at 11:45 AM, Dan Kegel daniel.r.ke...@gmail.com wrote: Noticed in passing while looking for something else this morning (though they may have been there a while). These sound potentially nasty; is anybody looking at them already? $ valgrind --track-origins=yes Hammer/test_shell_tests ... [ RUN ] WebFrameTest.GetContentAsPlainText UNIMPLEMENTED: (/home/dank/chromium/src/webkit/port/bindings/v8/ScriptController.cpp:143 updatePlatformScriptObjects) Mismatched free() / delete / delete [] at free (vg_replace_malloc.c:323) by WTF::fastFree(void*) (FastMalloc.cpp:216) by WebCore::CSSSelectorList::adoptSelectorVector(WTF::VectorWebCore::CSSSelector*, 0u) (CSSSelectorList.cpp:57) by WebCore::CSSStyleRule::adoptSelectorVector(WTF::VectorWebCore::CSSSelector*, 0u) (CSSStyleRule.h:53) by WebCore::CSSParser::createStyleRule(WTF::VectorWebCore::CSSSelector*, 0u*) (CSSParser.cpp:4547) by cssyyparse(void*) (CSSGrammar.y:792) by WebCore::CSSParser::parseSheet(WebCore::CSSStyleSheet*, WebCore::String const) (CSSParser.cpp:224) by WebCore::CSSStyleSheet::parseString(WebCore::String const, bool) (CSSStyleSheet.cpp:164) by WebCore::parseUASheet(WebCore::String const) (CSSStyleSelector.cpp:486) by WebCore::parseUASheet(char const*, unsigned int) (CSSStyleSelector.cpp:492) by WebCore::loadSimpleDefaultStyle() (CSSStyleSelector.cpp:531) by WebCore::CSSStyleSelector::CSSStyleSelector(WebCore::Document*, WebCore::String const, WebCore::StyleSheetList*, WebCore::CSSStyleSheet*, bool, bool) (CSSStyleSelector.cpp:406) Address 0x127ac840 is 0 bytes inside a block of size 16 alloc'd at operator new(unsigned int) (vg_replace_malloc.c:224) by WebCore::CSSParser::createFloatingSelector() (CSSParser.cpp:4382) by cssyyparse(void*) (CSSGrammar.y:883) by WebCore::CSSParser::parseSheet(WebCore::CSSStyleSheet*, WebCore::String const) (CSSParser.cpp:224) by WebCore::CSSStyleSheet::parseString(WebCore::String const, bool) (CSSStyleSheet.cpp:164) by WebCore::parseUASheet(WebCore::String const) (CSSStyleSelector.cpp:486) by WebCore::parseUASheet(char const*, unsigned int) (CSSStyleSelector.cpp:492) by WebCore::loadSimpleDefaultStyle() (CSSStyleSelector.cpp:531) by WebCore::CSSStyleSelector::CSSStyleSelector(WebCore::Document*, WebCore::String const, WebCore::StyleSheetList*, WebCore::CSSStyleSheet*, bool, bool) (CSSStyleSelector.cpp:406) by WebCore::Document::attach() (Document.cpp:1383) by WebCore::Frame::setDocument(WTF::PassRefPtrWebCore::Document) (Frame.cpp:272) by WebCore::FrameLoader::begin(WebCore::KURL const, bool, WebCore::SecurityOrigin*) (FrameLoader.cpp:949) Mismatched free() / delete / delete [] at operator delete(void*) (vg_replace_malloc.c:342) by WebCore::V8Proxy::InitContextIfNeeded() (v8_proxy.cpp:2318) by WebCore::V8Proxy::GetContext(WebCore::Frame*) (v8_proxy.cpp:2473) by WebCore::ScriptController::BindToWindowObject(WebCore::Frame*, WebCore::String const, NPObject*) (ScriptController.cpp:278) by WebFrameImpl::BindToWindowObject(std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t const, NPObject*) (webframe_impl.cc:689) by CppBoundClass::BindToJavascript(WebFrame*, std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t const) (cpp_bound_class.cc:255) by TestShell::BindJSObjectsToWindow(WebFrame*) (test_shell.cc:409) by TestWebViewDelegate::WindowObjectCleared(WebFrame*) (test_webview_delegate.cc:122) by WebFrameLoaderClient::windowObjectCleared() (webframeloaderclient_impl.cc:100) by WebCore::FrameLoader::dispatchWindowObjectAvailable() (FrameLoader.cpp:5180) by WebCore::FrameLoader::receivedFirstData() (FrameLoader.cpp:878) by WebCore::FrameLoader::setEncoding(WebCore::String const, bool) (FrameLoader.cpp:1899) Address 0x11c66678 is 0 bytes inside a block of size 4 alloc'd at operator new[](unsigned int) (vg_replace_malloc.c:268) by WebCore::V8Proxy::InitContextIfNeeded() (v8_proxy.cpp:2309) by WebCore::V8Proxy::GetContext(WebCore::Frame*) (v8_proxy.cpp:2473) by WebCore::ScriptController::BindToWindowObject(WebCore::Frame*, WebCore::String const, NPObject*) (ScriptController.cpp:278) by WebFrameImpl::BindToWindowObject(std::basic_stringwchar_t,
[chromium-dev] [linux] plugin info caching
I'd been sending this sort of stuff to Dean and John but maybe other people will find it interesting. Plugin loading works in two phases: - at startup, we scan the plugin directories for metadata, like plugin names and which mime-types they apply to; - at runtime, when we're asked for a specific plugin by mime type, we open the appropriate library and have at it. On Windows and Mac, the startup step queries file metadata (version info on Windows, plists on Mac). On Linux, that step must dlopen() the plugin and poke a function in it. This means if a plugin ends up getting used we open it twice, which is especially brutal because Flash can take multiple seconds to open for me (complicated story, Adobe is working on it). It appears that Mozilla (maybe for similar reasons) caches this info across browser runs and relies on the file mtime to see when its cache has expired, much to some users' dismay: https://bugzilla.mozilla.org/show_bug.cgi?id=125469 Or at least they did in 2002. ;) For now (for test_shell) I think I'll just pay the double-load cost. The alternative is leaving plugins open, which I think wastes memory and hurts load time. At some point we'll have to look at performance and decide about the cache thing. PS: Do we scan for plugins on a background thread in the normal browser startup? If so, how do we prevent races between that scan and someone's home page requesting a plugin? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] plugin info caching
On Tue, Jan 27, 2009 at 6:38 PM, Evan Martin e...@chromium.org wrote: I'd been sending this sort of stuff to Dean and John but maybe other people will find it interesting. Plugin loading works in two phases: - at startup, we scan the plugin directories for metadata, like plugin names and which mime-types they apply to; - at runtime, when we're asked for a specific plugin by mime type, we open the appropriate library and have at it. On Windows and Mac, the startup step queries file metadata (version info on Windows, plists on Mac). On Linux, that step must dlopen() the plugin and poke a function in it. This means if a plugin ends up getting used we open it twice, which is especially brutal because Flash can take multiple seconds to open for me (complicated story, Adobe is working on it). It appears that Mozilla (maybe for similar reasons) caches this info across browser runs and relies on the file mtime to see when its cache has expired, much to some users' dismay: https://bugzilla.mozilla.org/show_bug.cgi?id=125469 Or at least they did in 2002. ;) For now (for test_shell) I think I'll just pay the double-load cost. I think that's the way to go. Also, in the future you'll really be opening it in another process, so you'll have to open it twice anyways... The alternative is leaving plugins open, which I think wastes memory and hurts load time. At some point we'll have to look at performance and decide about the cache thing. I don't think you'd ever want to do this, because of memory as you say. PS: Do we scan for plugins on a background thread in the normal browser startup? yes If so, how do we prevent races between that scan and someone's home page requesting a plugin? PluginService has a lock around PluginList --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Responsibility reviewing patches with multiple reviewers
There are a lot of patches lately with a lot of reviewers on them, especially related to porting since a lot of people might need to be in the loop for some changes. The problem is that there's no clear responsibility given in these reviews. If I'm the sole reviewer on a change, I know I have to do a good job. When there are three other people, I sometimes assume that somebody else must have looked carefully at some part of the review. I'm sure sometimes all the reviewers think this and the change isn't reviewed properly. In other cases, some reviewers say LGTM for a patch, while others are still expecting changes. The author can get confused as to the status of the review, and I also know some patches have been checked in lately where at least one reviewer expected further changes before checkin. At the same time, we want to encourage many people to participate in the review process and keep tabs on what's going on. I propose several changes to best practices: 1. When a patch author requests more than one reviewer, they should make clear in the review request email what they expect the responsibility of each reviewer to be. Example: agl: bitmap changes evanm: process hacks everybody else: FYI In this case, I might be on the review list because I've asked to be in the loop for multiprocess changes, but I wouldn't be the primary reviewer and the author and other reviewers wouldn't be expecting me to review all the diffs in detail. 2. If you get a review that includes many other people, and the author didn't do (1), please ask them what part you're responsible for if you don't want to review the whole thing in detail. 3. The author should wait for approval from everybody on the reviewer list before checking in. 4. People who are on a review without clear review responsibility should be super responsive and not hold up the review. The patch author should feel free to ping them mercilessly if they are. 5. If you're on FYI person on a review and you didn't actually review in detail (or at all), but don't have a problem with the patch, note this. You could say something like rubber stamp or ACK instead of LGTM. This way the real reviewers know not to trust that you did their work for them, but the author of the patch knows they don't have to wait for further feedback from you. Hopefully we can still keep everybody in the loop but have clear ownership and detailed reviews. It might even speed up some patches since I can quickly ACK patches I don't care about, and the patch author knows they don't have to wait for feedback from me. Or do you think this has too much overhead? Comments? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Responsibility reviewing patches with multiple reviewers
I think specifying the reviewer's responsibility in the description/message is a good start. It might also help when requesting specific feedback about design details as opposed to checking code style. Andrew On Tue, Jan 27, 2009 at 10:13 PM, Amanda Walker ama...@chromium.org wrote: On Wed, Jan 28, 2009 at 1:04 AM, Brett Wilson bre...@chromium.org wrote: 1. When a patch author requests more than one reviewer, they should make clear in the review request email what they expect the responsibility of each reviewer to be. [...] 5. If you're on FYI person on a review and you didn't actually review in detail (or at all), but don't have a problem with the patch, note this. You could say something like rubber stamp or ACK instead of LGTM. This way the real reviewers know not to trust that you did their work for them, but the author of the patch knows they don't have to wait for further feedback from you. These are excellent suggestions. Hopefully we can still keep everybody in the loop but have clear ownership and detailed reviews. It might even speed up some patches since I can quickly ACK patches I don't care about, and the patch author knows they don't have to wait for feedback from me. Or do you think this has too much overhead? Comments? I like it. Explicit flow control is almost always better than waiting for a timeout to expire :-). --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] plugin info caching
Wow. It sucks that we'll need to load plugins in the main browser process. That gives plugins a nice opportunity to hose the browser. Oh well :-( If we really wanted to, I suppose we could have a plugin scanner process, but that seems unfortunately heavyweight. -Darin On Tue, Jan 27, 2009 at 6:38 PM, Evan Martin e...@chromium.org wrote: I'd been sending this sort of stuff to Dean and John but maybe other people will find it interesting. Plugin loading works in two phases: - at startup, we scan the plugin directories for metadata, like plugin names and which mime-types they apply to; - at runtime, when we're asked for a specific plugin by mime type, we open the appropriate library and have at it. On Windows and Mac, the startup step queries file metadata (version info on Windows, plists on Mac). On Linux, that step must dlopen() the plugin and poke a function in it. This means if a plugin ends up getting used we open it twice, which is especially brutal because Flash can take multiple seconds to open for me (complicated story, Adobe is working on it). It appears that Mozilla (maybe for similar reasons) caches this info across browser runs and relies on the file mtime to see when its cache has expired, much to some users' dismay: https://bugzilla.mozilla.org/show_bug.cgi?id=125469 Or at least they did in 2002. ;) For now (for test_shell) I think I'll just pay the double-load cost. The alternative is leaving plugins open, which I think wastes memory and hurts load time. At some point we'll have to look at performance and decide about the cache thing. PS: Do we scan for plugins on a background thread in the normal browser startup? If so, how do we prevent races between that scan and someone's home page requesting a plugin? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Responsibility reviewing patches with multiple reviewers
On Tue, Jan 27, 2009 at 10:04 PM, Brett Wilson bre...@chromium.org wrote: There are a lot of patches lately with a lot of reviewers on them, especially related to porting since a lot of people might need to be in the loop for some changes. The problem is that there's no clear responsibility given in these reviews. If I'm the sole reviewer on a change, I know I have to do a good job. When there are three other people, I sometimes assume that somebody else must have looked carefully at some part of the review. I'm sure sometimes all the reviewers think this and the change isn't reviewed properly. In other cases, some reviewers say LGTM for a patch, while others are still expecting changes. The author can get confused as to the status of the review, and I also know some patches have been checked in lately where at least one reviewer expected further changes before checkin. At the same time, we want to encourage many people to participate in the review process and keep tabs on what's going on. I propose several changes to best practices: 1. When a patch author requests more than one reviewer, they should make clear in the review request email what they expect the responsibility of each reviewer to be. Example: agl: bitmap changes evanm: process hacks everybody else: FYI In this case, I might be on the review list because I've asked to be in the loop for multiprocess changes, but I wouldn't be the primary reviewer and the author and other reviewers wouldn't be expecting me to review all the diffs in detail. 2. If you get a review that includes many other people, and the author didn't do (1), please ask them what part you're responsible for if you don't want to review the whole thing in detail. 3. The author should wait for approval from everybody on the reviewer list before checking in. 4. People who are on a review without clear review responsibility should be super responsive and not hold up the review. The patch author should feel free to ping them mercilessly if they are. 5. If you're on FYI person on a review and you didn't actually review in detail (or at all), but don't have a problem with the patch, note this. You could say something like rubber stamp or ACK instead of LGTM. This way the real reviewers know not to trust that you did their work for them, but the author of the patch knows they don't have to wait for further feedback from you. Hopefully we can still keep everybody in the loop but have clear ownership and detailed reviews. It might even speed up some patches since I can quickly ACK patches I don't care about, and the patch author knows they don't have to wait for feedback from me. Or do you think this has too much overhead? Comments? Brett This is a great idea! -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] plugin info caching
One of my goals with the out of process worker code is it to make it easier to have many different types of child processes. Perhaps it makes sense to have the linux port do this stuff in a child process once that code is ready. On Tue, Jan 27, 2009 at 10:49 PM, Darin Fisher da...@chromium.org wrote: Wow. It sucks that we'll need to load plugins in the main browser process. That gives plugins a nice opportunity to hose the browser. Oh well :-( If we really wanted to, I suppose we could have a plugin scanner process, but that seems unfortunately heavyweight. -Darin On Tue, Jan 27, 2009 at 6:38 PM, Evan Martin e...@chromium.org wrote: I'd been sending this sort of stuff to Dean and John but maybe other people will find it interesting. Plugin loading works in two phases: - at startup, we scan the plugin directories for metadata, like plugin names and which mime-types they apply to; - at runtime, when we're asked for a specific plugin by mime type, we open the appropriate library and have at it. On Windows and Mac, the startup step queries file metadata (version info on Windows, plists on Mac). On Linux, that step must dlopen() the plugin and poke a function in it. This means if a plugin ends up getting used we open it twice, which is especially brutal because Flash can take multiple seconds to open for me (complicated story, Adobe is working on it). It appears that Mozilla (maybe for similar reasons) caches this info across browser runs and relies on the file mtime to see when its cache has expired, much to some users' dismay: https://bugzilla.mozilla.org/show_bug.cgi?id=125469 Or at least they did in 2002. ;) For now (for test_shell) I think I'll just pay the double-load cost. The alternative is leaving plugins open, which I think wastes memory and hurts load time. At some point we'll have to look at performance and decide about the cache thing. PS: Do we scan for plugins on a background thread in the normal browser startup? If so, how do we prevent races between that scan and someone's home page requesting a plugin? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
