Re: [chromium-dev] Thread naming
Traceline is a good way to see how this happens. We generally name all of the Chrome threads (base::Thread), but the system is allowed to create threads of its own. Loads of APIs create threads, along with the windows worker pool (which we make good use of to help reuse threads). For example, wininet can create it's own thread pools, etc. I did some work on cutting down the number of threads and thread creation times. In specific thread creation can contend the main UI thread because of holding the loader lock for DLLMain initialization, etc. Here is an older example of traceline output: http://deanm.github.com/misc/traceline/traceline.xml#startup-release.json You can easily see which threads are created, when, and the call stacks for what created them by hovering on the lines. -- dean On Thu, Dec 31, 2009 at 7:09 PM, Jim Roskind j...@chromium.org wrote: I'm pretty sure we name all the threads we can (or at least used to), I *think* the problem is worker threads in a thread pool, which are started up and shut down automatically, and aren't named (and don't have message loops). When I was doing the work to generate the internal page about:tasks, it was critical to have names on all the threads (that I could), as the data also shows what threads sent and received tasks. Jim On Thu, Dec 31, 2009 at 1:11 AM, Berend-Jan Wever skyli...@chromium.org wrote: If you do not care about the way threads are run inside a process in Chromium, you can stop reading now. Some of our threads are named, while others are not. See below cdb.exe output for a renderer process: 2:020:x86 ~ 1 Id: d98.1588 Suspend: 1 Teb: 7efd8000 Unfrozen Chrome_ChildIOThread . 20 Id: d98.1440 Suspend: 1 Teb: 7efdb000 Unfrozen Main Thread 21 Id: d98.10d4 Suspend: 1 Teb: 7ef4d000 Unfrozen 22 Id: d98.171c Suspend: 1 Teb: 7efd5000 Unfrozen 2:020:x86 ~21 s ntdll32!ZwWaitForMultipleObjects+0x15: 76fa99fd c21400 ret 14h 2:021:x86 kp ChildEBP RetAddr 0399fcd4 7702787d ntdll32!ZwWaitForMultipleObjects+0x15 0399fe68 750feccb ntdll32!TppWaiterpThread+0x328 0399fe74 76fdd24d kernel32!BaseThreadInitThunk+0xe 0399feb4 76fdd45f ntdll32!__RtlUserThreadStart+0x23 0399fecc ntdll32!_RtlUserThreadStart+0x1b 2:021:x86 ~22 s ntdll32!NtWaitForWorkViaWorkerFactory+0x12: 76fab5ee c20800 ret 8 2:022:x86 kp ChildEBP RetAddr 0357f6ec 76f9b927 ntdll32!NtWaitForWorkViaWorkerFactory+0x12 0357f81c 750feccb ntdll32!TppWorkerThread+0x1f6 0357f828 76fdd24d kernel32!BaseThreadInitThunk+0xe 0357f868 76fdd45f ntdll32!__RtlUserThreadStart+0x23 0357f880 ntdll32!_RtlUserThreadStart+0x1b What are these threads and why are they nameless? Did we create these threads at all? (They could have been created by plugins/detours/etc. that we have no control over.) It would be nice if we could name all threads, so you know what you're looking at. Thanks! BJ Berend-Jan SkyLined Wever skyli...@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 Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Missing symbols for Chrome 3.0.195.38
FYI, the symbols were added on Dec 30. http://build.chromium.org/buildbot/symbols/3.0.195.38/chrome_dll.pdb http://build.chromium.org/buildbot/symsrv/chrome_dll.pdb/A94BABB37F7A4445A7A2C7BC2B796FD81/chrome_dll.pdb M-A On Tue, Dec 29, 2009 at 10:14 PM, yuhong yuhongbao_...@hotmail.com wrote: BTW, consider compressing symbols to make downloads faster. -- DBGHELP: c:\windows\symbols\chrome_dll.pdb - file not found DBGHELP: c:\windows\symbols\dll\chrome_dll.pdb - file not found DBGHELP: c:\windows\symbols\symbols\dll\chrome_dll.pdb - file not found SYMSRV: c:\downloads\symbols\chrome_dll.pdb \A94BABB37F7A4445A7A2C7BC2B796FD81\chrome_dll.pdb not found SYMSRV: http://msdl.microsoft.com/download/symbols/chrome_dll.pdb/A94BABB37F7A4445A7A2C7BC2B796FD81/chrome_dll.pdb not found SYMSRV: c:\downloads\symbols\chrome_dll.pdb \A94BABB37F7A4445A7A2C7BC2B796FD81\chrome_dll.pdb not found SYMSRV: http://build.chromium.org/buildbot/symsrv/chrome_dll.pdb/A94BABB37F7A4445A7A2C7BC2B796FD81/chrome_dll.pdb not found SYMSRV: c:\downloads\symbols\chrome_dll.pdb \A94BABB37F7A4445A7A2C7BC2B796FD81\chrome_dll.pdb not found SYMSRV: http://symbols.mozilla.org/firefox/chrome_dll.pdb/A94BABB37F7A4445A7A2C7BC2B796FD81/chrome_dll.pdb not found DBGHELP: C:\b\slave\chrome-official-2\build\src\chrome\Release \chrome_dll.pdb - file not found *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Users\bob\AppData\Local\Google\Chrome\Application \3.0.195.38\chrome.dll - DBGHELP: chrome_6206 - export symbols DBGHELP: c:\windows\symbols\chrome_exe.pdb - file not found DBGHELP: c:\windows\symbols\exe\chrome_exe.pdb - file not found DBGHELP: c:\windows\symbols\symbols\exe\chrome_exe.pdb - file not found SYMSRV: c:\downloads\symbols\chrome_exe.pdb \E909049038764DE8A2AB75715E30ACB31\chrome_exe.pdb not found SYMSRV: http://msdl.microsoft.com/download/symbols/chrome_exe.pdb/E909049038764DE8A2AB75715E30ACB31/chrome_exe.pdb not found SYMSRV: c:\downloads\symbols\chrome_exe.pdb \E909049038764DE8A2AB75715E30ACB31\chrome_exe.pdb not found SYMSRV: http://build.chromium.org/buildbot/symsrv/chrome_exe.pdb/E909049038764DE8A2AB75715E30ACB31/chrome_exe.pdb not found SYMSRV: c:\downloads\symbols\chrome_exe.pdb \E909049038764DE8A2AB75715E30ACB31\chrome_exe.pdb not found SYMSRV: http://symbols.mozilla.org/firefox/chrome_exe.pdb/E909049038764DE8A2AB75715E30ACB31/chrome_exe.pdb not found DBGHELP: C:\Users\bob\AppData\Local\Google\Chrome\Application \chrome_exe.pdb - file not found DBGHELP: C:\b\slave\chrome-official-2\build\src\chrome\Release \chrome_exe.pdb - file not found *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Users\bob\AppData\Local\Google\Chrome\Application \chrome.exe - DBGHELP: chrome - export symbols -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] code coverage on 3 platforms
Are these numbers generated by running all tests, eg unit, ui, browser, interactive .. ? -Scott On Thu, Dec 31, 2009 at 9:07 PM, John Grabowski j...@chromium.org wrote: I had an OKR to get code coverage working on 3 platforms for Chromium unit test bundles in Q409. If you're in PST, I made it! Dashboard (overview): http://build.chromium.org/buildbot/perf/dashboard/coverage.html Sample output for Windows: http://build.chromium.org/buildbot/coverage/xp-debug/35420/CHROMIUM/index.html Mac: http://build.chromium.org/buildbot/coverage/mac-debug/35422/CHROMIUM/index.html Linux: http://build.chromium.org/buildbot/coverage/linux-debug/35422/CHROMIUM/index.html Coverage is not perfect. For example, Mac coverage number generation is smart enough to exclude *_win.cc and *_linux.cc but can't tell base/file_version_info.cc and base/wmi_util.cc should be Windows-only. This is a trade-off to prevent a complete exclusion of files without unit tests at all. Lots of thanks to Randall and Bradley. jrg -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] jail tag to prevent javascript execution
Hello,
I am a student of computer science and want to implement a jail for
java-script or at least gather some information how one could do
that.
The idea is not new. Brandon Eich had it before.
So the idea is to tell the browser: do not execute java-script within
this area, although the domain where that code comes from is allowed
to execute java-script outside such specific areas.
html
...
here javascript allowed
jail id=someHash
code here
...
no javascript allowed
/jail id=someHash
...
/html
My questions are the following:
1. Are there any plans of implementing stuff like this in Google
Chrome or WebKit in general? Please note that there is a difference
compared to the approach of Mozilla called Content Security Policy.
2. How difficult would that be? I imagine a procedure like this:
- parse the HTML Document
- cut out the peaces wrapped by jail tags
- hand the rest to the java-script engine
- take the output of the engine and reinsert the clipped parts
But what about the dynamicpart? What if a link element within a
jail
tag contains code like a onclick=alert('onClick!') title=click
me/a? Would that be invisible to the java-script engine because it
was not registered when it is within a jail tag?
And is there any kind of architecture picture of Chrome/Chromium? I
imagine a simple image with the different modules and how they
interact. Thanks a lot.
Mathias Wagner
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] code coverage on 3 platforms
At this time, just the tests which run successfully on all 3 platforms. The list from chrome_tests.gypi: 'automated_ui_tests', '../app/app.gyp:app_unittests', '../base/base.gyp:base_unittests', '../ipc/ipc.gyp:ipc_tests', '../media/media.gyp:media_unittests', '../net/net.gyp:net_unittests', '../printing/printing.gyp:printing_unittests', 'unit_tests', I did not yet add unit test bundles which don't run on 3 platforms (interactive_ui_tests, browser_tests, courgette_tests). ui_tests runs on 3 platforms but chokes on OSX when run instrumented; I need to track down why. jrg On Mon, Jan 4, 2010 at 8:53 AM, Scott Violet s...@chromium.org wrote: Are these numbers generated by running all tests, eg unit, ui, browser, interactive .. ? -Scott On Thu, Dec 31, 2009 at 9:07 PM, John Grabowski j...@chromium.org wrote: I had an OKR to get code coverage working on 3 platforms for Chromium unit test bundles in Q409. If you're in PST, I made it! Dashboard (overview): http://build.chromium.org/buildbot/perf/dashboard/coverage.html Sample output for Windows: http://build.chromium.org/buildbot/coverage/xp-debug/35420/CHROMIUM/index.html Mac: http://build.chromium.org/buildbot/coverage/mac-debug/35422/CHROMIUM/index.html Linux: http://build.chromium.org/buildbot/coverage/linux-debug/35422/CHROMIUM/index.html Coverage is not perfect. For example, Mac coverage number generation is smart enough to exclude *_win.cc and *_linux.cc but can't tell base/file_version_info.cc and base/wmi_util.cc should be Windows-only. This is a trade-off to prevent a complete exclusion of files without unit tests at all. Lots of thanks to Randall and Bradley. jrg -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] code coverage on 3 platforms
You are looking at older data. Look at numbers from Dec31 or later. I wasn't exaggerating when I said just barely got three platforms working in Q409. The low linux number problem was caused by a switch from scons to make as the default builder on all bots a few weeks ago. There were a number of trailing problems from this switch; for example, buildbot's scripts/master/slaves.py still referenced sconsbuild for any clobber=True configuration, so Linux clobber was broken. I could go on and on here but you probably don't care. In short I've gained a new respect for people who manage to hide the complexity of a build system behind a just works. jrg On Mon, Jan 4, 2010 at 9:07 AM, Mike Pinkerton pinker...@google.com wrote: The linux graphs say they're covering 0.25% of both source and tests. That can't be right, can it? On Mon, Jan 4, 2010 at 11:53 AM, Scott Violet s...@chromium.org wrote: Are these numbers generated by running all tests, eg unit, ui, browser, interactive .. ? -Scott On Thu, Dec 31, 2009 at 9:07 PM, John Grabowski j...@chromium.org wrote: I had an OKR to get code coverage working on 3 platforms for Chromium unit test bundles in Q409. If you're in PST, I made it! Dashboard (overview): http://build.chromium.org/buildbot/perf/dashboard/coverage.html Sample output for Windows: http://build.chromium.org/buildbot/coverage/xp-debug/35420/CHROMIUM/index.html Mac: http://build.chromium.org/buildbot/coverage/mac-debug/35422/CHROMIUM/index.html Linux: http://build.chromium.org/buildbot/coverage/linux-debug/35422/CHROMIUM/index.html Coverage is not perfect. For example, Mac coverage number generation is smart enough to exclude *_win.cc and *_linux.cc but can't tell base/file_version_info.cc and base/wmi_util.cc should be Windows-only. This is a trade-off to prevent a complete exclusion of files without unit tests at all. Lots of thanks to Randall and Bradley. jrg -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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
Re: [chromium-dev] jail tag to prevent javascript execution
On Mon, Jan 4, 2010 at 6:09 AM, Mathias Wagner wolfsb...@googlemail.com wrote:
Hello,
I am a student of computer science and want to implement a jail for
java-script or at least gather some information how one could do
that.
The idea is not new. Brandon Eich had it before.
So the idea is to tell the browser: do not execute java-script within
this area, although the domain where that code comes from is allowed
to execute java-script outside such specific areas.
html
...
here javascript allowed
jail id=someHash
code here
...
no javascript allowed
/jail id=someHash
...
/html
My questions are the following:
1. Are there any plans of implementing stuff like this in Google
Chrome or WebKit in general? Please note that there is a difference
compared to the approach of Mozilla called Content Security Policy.
http://old.nabble.com/innerStaticHTML-td26506964.html sounds like
something similar.
2. How difficult would that be? I imagine a procedure like this:
- parse the HTML Document
- cut out the peaces wrapped by jail tags
- hand the rest to the java-script engine
- take the output of the engine and reinsert the clipped parts
But what about the dynamicpart? What if a link element within a
jail
tag contains code like a onclick=alert('onClick!') title=click
me/a? Would that be invisible to the java-script engine because it
was not registered when it is within a jail tag?
And is there any kind of architecture picture of Chrome/Chromium? I
imagine a simple image with the different modules and how they
interact. Thanks a lot.
Mathias Wagner
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] jail tag to prevent javascript execution
Hi Mathias. Thanks for your interest. See below: On Mon, Jan 4, 2010 at 6:09 AM, Mathias Wagner wolfsb...@googlemail.com wrote: 1. Are there any plans of implementing stuff like this in Google Chrome or WebKit in general? Please note that there is a difference compared to the approach of Mozilla called Content Security Policy. We already have an implementation of the HTML5's @sandbox attribute. We'd also like to add a lighter-weigh sanitization feature on par with IE8's toStaticHTML. The main difficultly is designing the API. There are a couple of designs floating around, including toStaticHTML, innerStaticHTML, and insertSanitizedHTML: http://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTJzbTY1cWJrNAhl=en There are various reasons why the jail tag, as such, as not caught on. For example: 1) It requires modifying the parser (i.e., the end tag attributes aren't valid HTML) 2) It's unclear whether authors will properly generate the randomness required 3) It doesn't address AJAX use cases (cross-origin XMLHttpRequest and postMessage) very well 4) It is fairly inflexible (i.e., we have to pick exactly the right set of things to block instead of giving authors control) If you have ideas for a better API, there's some discussion happening on the WHAT WG mailing list: http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org We'd certainly be happy to hear any ideas that you have. 2. How difficult would that be? I imagine a procedure like this: - parse the HTML Document - cut out the peaces wrapped by jail tags - hand the rest to the java-script engine - take the output of the engine and reinsert the clipped parts The issues are more the design if the API and not its implementation at this point. And is there any kind of architecture picture of Chrome/Chromium? I imagine a simple image with the different modules and how they interact. Thanks a lot. You can find a number of design documents here: http://www.chromium.org/developers/design-documents In particular, you might find these useful: http://www.chromium.org/developers/design-documents/multi-process-architecture http://www.chromium.org/developers/design-documents/displaying-a-web-page-in-chrome Adam -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Unit test in chromium which test javascript alert
See the ClickAppModalDialogButton automation IPC message (implementation is in chrome/browser/automation_provider.cc). I don't see any specifically testing just that message, and I don't see any in-process browser tests covering javascript alerts. Creating chrome/browser/app_modal_dialog_unittest.cc might be a good place to start start. -- Evan Stade @ chromium On Sun, Jan 3, 2010 at 11:28 PM, n179911 n179...@gmail.com wrote: Hi, Is there any Unit test in chromium which test javascript alert? Does it have automated test case which automatically clicks the pop up dialog cased by javascript alert? Thank you. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Faster linking for chromium on ubuntu
On Thu, Dec 31, 2009 at 7:24 PM, n179911 n179...@gmail.com wrote:
On Thu, Dec 31, 2009 at 3:17 PM, Dan Kegel d...@kegel.com wrote:
On Thu, Dec 31, 2009 at 3:14 PM, n179911 n179...@gmail.com wrote:
And I have put 'shared' library in my include gypi file
$ more ~/.gyp/include.gpyi
{'variables': {
'library': 'shared_library',
}}
How can I make sure that it is building in shared library and using
the gold linker?
I find linking chromium is still take a long time (~ 10 minutes) on my
machine.
Is it definitely the chrome link command that is taking 10 minutes, or
linking in general? Some of the shared libs, especially in debug
build, are very large, so will still take a while to link. The main
benefit is that the actual executables, like chrome, test_shell, etc.,
will no longer duplicate that shared lib code, so collectively they
should be much smaller and link much faster.
Did you rerun gyp, e.g. with the command
glient runhooks --force
after changing ~/.gyp/include.gypi ?
Yes, I did run 'glient runhooks --force' before I run 'make
out/Debug/chrome' again.
When I build chromium as a shared library, will the result binary(ies)
be different, is there something I can check to make sure the chromium
I built is 'shared library'?
Do you have a lib.target directory full of .so files in your build
output? Does 'ldd chrome | grep libv8' match anything? If so, you have
a proper shared library build.
Michael
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Unit test in chromium which test javascript alert
There's also a few in-process browser tests in chrome/browser/browser_browsertest.cc that call alert and dismiss the dialog as part of testing something else, though they don't explicitly test aspects of alert's behavior. Just search for alert in that file to see how to use ui_test_utils::WaitForAppModalDialog(), etc. Charlie On Mon, Jan 4, 2010 at 11:12 AM, Evan Stade est...@chromium.org wrote: See the ClickAppModalDialogButton automation IPC message (implementation is in chrome/browser/automation_provider.cc). I don't see any specifically testing just that message, and I don't see any in-process browser tests covering javascript alerts. Creating chrome/browser/app_modal_dialog_unittest.cc might be a good place to start start. -- Evan Stade @ chromium On Sun, Jan 3, 2010 at 11:28 PM, n179911 n179...@gmail.com wrote: Hi, Is there any Unit test in chromium which test javascript alert? Does it have automated test case which automatically clicks the pop up dialog cased by javascript alert? Thank you. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Chromium Arm, revision 35483
Automatically closing tree for compile on Chromium Arm http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Arm/builds/392 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Arm --= Automatically closing tree for compile on Chromium Arm =-- Revision: 35481, 35483 Blame list: dim...@google.com,osh...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Thread naming
Just for the record - Tp prefix stands for Thread Pool, and Tpp for Thread Pool Private (function). So yes, these are threads created by the system. On Thu, Dec 31, 2009 at 10:09 AM, Jim Roskind j...@chromium.org wrote: I'm pretty sure we name all the threads we can (or at least used to), I *think* the problem is worker threads in a thread pool, which are started up and shut down automatically, and aren't named (and don't have message loops). When I was doing the work to generate the internal page about:tasks, it was critical to have names on all the threads (that I could), as the data also shows what threads sent and received tasks. Jim On Thu, Dec 31, 2009 at 1:11 AM, Berend-Jan Wever skyli...@chromium.org wrote: If you do not care about the way threads are run inside a process in Chromium, you can stop reading now. Some of our threads are named, while others are not. See below cdb.exe output for a renderer process: 2:020:x86 ~ 1 Id: d98.1588 Suspend: 1 Teb: 7efd8000 Unfrozen Chrome_ChildIOThread . 20 Id: d98.1440 Suspend: 1 Teb: 7efdb000 Unfrozen Main Thread 21 Id: d98.10d4 Suspend: 1 Teb: 7ef4d000 Unfrozen 22 Id: d98.171c Suspend: 1 Teb: 7efd5000 Unfrozen 2:020:x86 ~21 s ntdll32!ZwWaitForMultipleObjects+0x15: 76fa99fd c21400 ret 14h 2:021:x86 kp ChildEBP RetAddr 0399fcd4 7702787d ntdll32!ZwWaitForMultipleObjects+0x15 0399fe68 750feccb ntdll32!TppWaiterpThread+0x328 0399fe74 76fdd24d kernel32!BaseThreadInitThunk+0xe 0399feb4 76fdd45f ntdll32!__RtlUserThreadStart+0x23 0399fecc ntdll32!_RtlUserThreadStart+0x1b 2:021:x86 ~22 s ntdll32!NtWaitForWorkViaWorkerFactory+0x12: 76fab5ee c20800 ret 8 2:022:x86 kp ChildEBP RetAddr 0357f6ec 76f9b927 ntdll32!NtWaitForWorkViaWorkerFactory+0x12 0357f81c 750feccb ntdll32!TppWorkerThread+0x1f6 0357f828 76fdd24d kernel32!BaseThreadInitThunk+0xe 0357f868 76fdd45f ntdll32!__RtlUserThreadStart+0x23 0357f880 ntdll32!_RtlUserThreadStart+0x1b What are these threads and why are they nameless? Did we create these threads at all? (They could have been created by plugins/detours/etc. that we have no control over.) It would be nice if we could name all threads, so you know what you're looking at. Thanks! BJ Berend-Jan SkyLined Wever skyli...@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 Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] chromium crash when load flash plugin
Hi: I build a Release chromium from latest trunk code.my Chromium always crash when page contain flash elements. on ubuntu 9.10 intel 32 build command make BUILDTYPE=Release and make chrome BUILDTYPE=Release -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] code coverage on 3 platforms
Good to see this. I don't see a reference to layout tests. Given that webkit is listed at 9% coverage, I'd guess that these aren't running either. Erik On Mon, Jan 4, 2010 at 10:00 AM, John Grabowski j...@chromium.org wrote: At this time, just the tests which run successfully on all 3 platforms. The list from chrome_tests.gypi: 'automated_ui_tests', '../app/app.gyp:app_unittests', '../base/base.gyp:base_unittests', '../ipc/ipc.gyp:ipc_tests', '../media/media.gyp:media_unittests', '../net/net.gyp:net_unittests', '../printing/printing.gyp:printing_unittests', 'unit_tests', I did not yet add unit test bundles which don't run on 3 platforms (interactive_ui_tests, browser_tests, courgette_tests). ui_tests runs on 3 platforms but chokes on OSX when run instrumented; I need to track down why. jrg On Mon, Jan 4, 2010 at 8:53 AM, Scott Violet s...@chromium.org wrote: Are these numbers generated by running all tests, eg unit, ui, browser, interactive .. ? -Scott On Thu, Dec 31, 2009 at 9:07 PM, John Grabowski j...@chromium.org wrote: I had an OKR to get code coverage working on 3 platforms for Chromium unit test bundles in Q409. If you're in PST, I made it! Dashboard (overview): http://build.chromium.org/buildbot/perf/dashboard/coverage.html Sample output for Windows: http://build.chromium.org/buildbot/coverage/xp-debug/35420/CHROMIUM/index.html Mac: http://build.chromium.org/buildbot/coverage/mac-debug/35422/CHROMIUM/index.html Linux: http://build.chromium.org/buildbot/coverage/linux-debug/35422/CHROMIUM/index.html Coverage is not perfect. For example, Mac coverage number generation is smart enough to exclude *_win.cc and *_linux.cc but can't tell base/file_version_info.cc and base/wmi_util.cc should be Windows-only. This is a trade-off to prevent a complete exclusion of files without unit tests at all. Lots of thanks to Randall and Bradley. jrg -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] code coverage on 3 platforms
You are correct; I am not running layout tests on the coverage bots. Definitely something else to work on. jrg On Mon, Jan 4, 2010 at 3:46 PM, Erik Kay erik...@chromium.org wrote: Good to see this. I don't see a reference to layout tests. Given that webkit is listed at 9% coverage, I'd guess that these aren't running either. Erik On Mon, Jan 4, 2010 at 10:00 AM, John Grabowski j...@chromium.org wrote: At this time, just the tests which run successfully on all 3 platforms. The list from chrome_tests.gypi: 'automated_ui_tests', '../app/app.gyp:app_unittests', '../base/base.gyp:base_unittests', '../ipc/ipc.gyp:ipc_tests', '../media/media.gyp:media_unittests', '../net/net.gyp:net_unittests', '../printing/printing.gyp:printing_unittests', 'unit_tests', I did not yet add unit test bundles which don't run on 3 platforms (interactive_ui_tests, browser_tests, courgette_tests). ui_tests runs on 3 platforms but chokes on OSX when run instrumented; I need to track down why. jrg On Mon, Jan 4, 2010 at 8:53 AM, Scott Violet s...@chromium.org wrote: Are these numbers generated by running all tests, eg unit, ui, browser, interactive .. ? -Scott On Thu, Dec 31, 2009 at 9:07 PM, John Grabowski j...@chromium.org wrote: I had an OKR to get code coverage working on 3 platforms for Chromium unit test bundles in Q409. If you're in PST, I made it! Dashboard (overview): http://build.chromium.org/buildbot/perf/dashboard/coverage.html Sample output for Windows: http://build.chromium.org/buildbot/coverage/xp-debug/35420/CHROMIUM/index.html Mac: http://build.chromium.org/buildbot/coverage/mac-debug/35422/CHROMIUM/index.html Linux: http://build.chromium.org/buildbot/coverage/linux-debug/35422/CHROMIUM/index.html Coverage is not perfect. For example, Mac coverage number generation is smart enough to exclude *_win.cc and *_linux.cc but can't tell base/file_version_info.cc and base/wmi_util.cc should be Windows-only. This is a trade-off to prevent a complete exclusion of files without unit tests at all. Lots of thanks to Randall and Bradley. jrg -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] chromium crash when load flash plugin
On Mon, Jan 4, 2010 at 3:38 PM, Peter Kasting pkast...@google.com wrote: On Mon, Jan 4, 2010 at 3:35 PM, if-ifone hello...@gmail.com wrote: Hi: I build a Release chromium from latest trunk code.my Chromium always crash when page contain flash elements. on ubuntu 9.10 intel 32 build command make BUILDTYPE=Release and make chrome BUILDTYPE=Release Please file bugs on crbug.com. In addition, if you build a binary yourself, it's pretty much your responsibility to first debug the issue to determine it's something that other people should care about/help with before reporting such bugs. Peter is exactly right, but it's probably http://code.google.com/p/chromium/issues/detail?id=28749 -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Replicated State among tabs in Chromium
Hello all, I'm interested in looking into replicated state between processes in Chromium to try to share more of that state and help reduce Chromium's memory footprint. I am unfamiliar with the Chromium source at this point in time, so I would appreciate if someone would point me to the problem areas to investigate. Thanks, Fady -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
There are some caches in webkit (the resource cache in particular, but there are others) that would be nice to share between processes. -Darin On Mon, Jan 4, 2010 at 4:43 PM, Fady Samuel fadysam...@gmail.com wrote: Hello all, I'm interested in looking into replicated state between processes in Chromium to try to share more of that state and help reduce Chromium's memory footprint. I am unfamiliar with the Chromium source at this point in time, so I would appreciate if someone would point me to the problem areas to investigate. Thanks, Fady -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Mon, Jan 4, 2010 at 4:58 PM, Darin Fisher da...@chromium.org wrote: There are some caches in webkit (the resource cache in particular, but there are others) that would be nice to share between processes. If you look into this, note that there are major tricky issues here around synchronization if you start trying to share caches between processes without hammering perf. Also, the gain from sharing these will not necessarily be large, for two reasons: * We already set a fairly small global size limit for the sum of all resource caches (and the other caches are pretty trivial) * Renderers in separate processes are very likely to be on separate sites and have mostly disjoint cacheable sets PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
Peter, I am aware there will be synchronization issues. I am a grad student who has been studying concurrent and lock-free data structures for a while now. I'm actually hoping to apply some of my research in Chromium as a proof of concept. I'm also interested in looking into state that is already shared but makes excessive use of locking and may be hindering performance. Any shared state applying iterators of some kind would be interesting as well for me. Thanks, Fady On Mon, Jan 4, 2010 at 8:02 PM, Peter Kasting pkast...@google.com wrote: On Mon, Jan 4, 2010 at 4:58 PM, Darin Fisher da...@chromium.org wrote: There are some caches in webkit (the resource cache in particular, but there are others) that would be nice to share between processes. If you look into this, note that there are major tricky issues here around synchronization if you start trying to share caches between processes without hammering perf. Also, the gain from sharing these will not necessarily be large, for two reasons: * We already set a fairly small global size limit for the sum of all resource caches (and the other caches are pretty trivial) * Renderers in separate processes are very likely to be on separate sites and have mostly disjoint cacheable sets PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Mon, Jan 4, 2010 at 5:17 PM, Fady Samuel fadysam...@gmail.com wrote: I'm also interested in looking into state that is already shared but makes excessive use of locking and may be hindering performance. I'm not aware of anything that really falls into this category. We share the visited link state but use a carefully-designed system to avoid excessive locking. Renderers can share bitmaps with the browser via shared memory, but there isn't contention here that I'm aware of. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Mon, Jan 4, 2010 at 5:17 PM, Fady Samuel fadysam...@gmail.com wrote: I am aware there will be synchronization issues. I am a grad student who has been studying concurrent and lock-free data structures for a while now. I'm actually hoping to apply some of my research in Chromium as a proof of concept. I'm also interested in looking into state that is already shared but makes excessive use of locking and may be hindering performance. Any shared state applying iterators of some kind would be interesting as well for me. On Linux (only) the Skia glyph caches are replicated across renderers. AGL -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Chromium XP, revision 35503
Automatically closing tree for check deps on Chromium XP http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/9486 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20XP --= Automatically closing tree for check deps on Chromium XP =-- Revision: 35498, 35499, 35500, 35501, 35502, 35503 Blame list: a...@chromium.org,al...@chromium.org,est...@chromium.org,e...@chromium.org,tha...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Mon, Jan 4, 2010 at 5:48 PM, Fady Samuel fadysam...@gmail.com wrote: So as Peter said a lot of this cache state will not be used in multiple tabs because many of these tabs will be different webpages. That's not to say that one doesn't open multiple pages from a single site however, in which case the image cache might have a lot replication overhead. However, opening multiple pages from a single site will usually also lead to those pages being in the same process (depending on how they were opened). PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
Thanks Adam, So as Peter said a lot of this cache state will not be used in multiple tabs because many of these tabs will be different webpages. That's not to say that one doesn't open multiple pages from a single site however, in which case the image cache might have a lot replication overhead. I am currently watching the Painting in Chromium video. Is the font cache replicated or shared? Thanks, Fady On Mon, Jan 4, 2010 at 8:22 PM, Adam Langley a...@chromium.org wrote: On Mon, Jan 4, 2010 at 5:17 PM, Fady Samuel fadysam...@gmail.com wrote: I am aware there will be synchronization issues. I am a grad student who has been studying concurrent and lock-free data structures for a while now. I'm actually hoping to apply some of my research in Chromium as a proof of concept. I'm also interested in looking into state that is already shared but makes excessive use of locking and may be hindering performance. Any shared state applying iterators of some kind would be interesting as well for me. On Linux (only) the Skia glyph caches are replicated across renderers. AGL -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
Sorry, one last thing I would be interested in looking into: fault Tolerance of shared state. In particular, can a crashing process currently break shared data structures thus breaking the whole browser (e.g. leaving shared data structures in an inconsistent state)? Thanks, Fady On Mon, Jan 4, 2010 at 8:22 PM, Adam Langley a...@chromium.org wrote: On Mon, Jan 4, 2010 at 5:17 PM, Fady Samuel fadysam...@gmail.com wrote: I am aware there will be synchronization issues. I am a grad student who has been studying concurrent and lock-free data structures for a while now. I'm actually hoping to apply some of my research in Chromium as a proof of concept. I'm also interested in looking into state that is already shared but makes excessive use of locking and may be hindering performance. Any shared state applying iterators of some kind would be interesting as well for me. On Linux (only) the Skia glyph caches are replicated across renderers. AGL -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
(re-adding chromium-dev) On Mon, Jan 4, 2010 at 5:58 PM, Fady Samuel fadysam...@gmail.com wrote: Was this done to reduce memory overhead? No, it was done because the newly opened pages and the original pages can script each other. From what I understand, making sites in different processes able to script each other is somewhere between very hard and impossible. Darin Fisher, Charlie Reis, Adam Barth and others know much more about this. Doesn't this introduce a fault tolerance issue? In that it increases the number of tabs affected by renderer crashes? Yes, but we don't really have a choice. That's how the web works. I believe MS' Gazelle project purposefully breaks scriptability here in order to maintain more robust separation. This pretty much breaks the web and wouldn't be shippable as a consumer browser. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Mon, Jan 4, 2010 at 6:32 PM, Fady Samuel fadysam...@gmail.com wrote: I know I'm asking you a lot of questions here. And you keep removing chromium-dev. Why? I'm not the knowledgeable person about much of this stuff, I'm just trying to be helpful. Alex mentioned the Webkit DOM tree, indicating that making the nodes of the DOM tree immutable in this fashion would be interesting. Why? AFAIK the DOM tree isn't shared across processes, and the renderer is effectively single-threaded as far as this is concerned. How does the current traversal of the DOM tree work? Does it require locking? Do you create a copy of the tree for rendering purposes? I assume scripting enables dynamic updates of the DOM tree to happen all the time? I haven't looked into this much myself yet. How is the synchronization handled there currently? As I said, I believe the DOM tree isn't shared across processes, so there is no synchronization that I know of. I am way out of my depth in this area so you really should not ask me specifically. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel fadysam...@gmail.com wrote: So a script cannot execute concurrently with the traversal of the DOM tree? Could this be a performance bottleneck? Pretty much nothing in the renderer can execute concurrently with other things in the renderer. There have been academic papers published about trying to parallelize parts of web rendering, and some though experiments from various smart Mozilla and WebKit folks, but from what I've seen it's not promising. The web wasn't really designed with thread- or process-level parallelism on the part of the UA in mind. (Witness, for example, the horror of sync XHR, or how difficult it is to make alert()s not be renderer-modal.) In particular, it's fairly well-defined that script sees a coherent state as it executes, so unless you can solve the halting problem, there are pretty severe limits on how much you could parallelize script execution with other stuff. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
Peter's right: as far as I understand, parsing, rendering, and script execution are all expected to take place on a single thread of execution. This includes any calls across multiple pages, which is why we place connected same-site pages (those in the same unit of related browsing contexts) in the same process. If one page calls a function in another page, we don't want to allow data races. For more info on the decisions we've made about which pages go to which process, see: http://dev.chromium.org/developers/design-documents/process-models We also have a Eurosys 2009 paper on the topic: http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf Hope that helps, Charlie On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting pkast...@google.com wrote: On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel fadysam...@gmail.com wrote: So a script cannot execute concurrently with the traversal of the DOM tree? Could this be a performance bottleneck? Pretty much nothing in the renderer can execute concurrently with other things in the renderer. There have been academic papers published about trying to parallelize parts of web rendering, and some though experiments from various smart Mozilla and WebKit folks, but from what I've seen it's not promising. The web wasn't really designed with thread- or process-level parallelism on the part of the UA in mind. (Witness, for example, the horror of sync XHR, or how difficult it is to make alert()s not be renderer-modal.) In particular, it's fairly well-defined that script sees a coherent state as it executes, so unless you can solve the halting problem, there are pretty severe limits on how much you could parallelize script execution with other stuff. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] PSA: new dev packages needed on linux
If you don't build on linux, you can stop reading now. For the incoming gpu plugin on linux, the following new packages are needed: * mesa-common-dev * libgl1-mesa-dev * libglu1-mesa-dev The gpu plugin change is not checked in yet (some of the slaves didn't get those packages), but will shortly (hopefully tomorrow), so you should go ahead and install those packages now. I updated http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisitesand build/install-build-deps.sh Thanks, Antoine -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
I'm not disagreeing with you. Yes, the script needs to see a coherent state as it executes BUT the renderer only needs a logically consistent snapshot, correct? So the script can work on the most current version of the DOM, while the renderer does its thing to produce a bitmap from the snapshot? Again, I may be spouting nonsense due to my ignorance of the details of the Webkit/Chromium architecture. I don't really know how the pieces fit together yet. I apologize for that. I'll spend a couple of days to better understand the architecture. Fady In particular, it's fairly well-defined that script sees a coherent state as it executes, so unless you can solve the halting problem, there are pretty severe limits on how much you could parallelize script execution with other stuff. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Replicated State among tabs in Chromium
Charles, this is awesome! Thanks! Fady On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis cr...@chromium.org wrote: Peter's right: as far as I understand, parsing, rendering, and script execution are all expected to take place on a single thread of execution. This includes any calls across multiple pages, which is why we place connected same-site pages (those in the same unit of related browsing contexts) in the same process. If one page calls a function in another page, we don't want to allow data races. For more info on the decisions we've made about which pages go to which process, see: http://dev.chromium.org/developers/design-documents/process-models We also have a Eurosys 2009 paper on the topic: http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf Hope that helps, Charlie On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting pkast...@google.com wrote: On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel fadysam...@gmail.com wrote: So a script cannot execute concurrently with the traversal of the DOM tree? Could this be a performance bottleneck? Pretty much nothing in the renderer can execute concurrently with other things in the renderer. There have been academic papers published about trying to parallelize parts of web rendering, and some though experiments from various smart Mozilla and WebKit folks, but from what I've seen it's not promising. The web wasn't really designed with thread- or process-level parallelism on the part of the UA in mind. (Witness, for example, the horror of sync XHR, or how difficult it is to make alert()s not be renderer-modal.) In particular, it's fairly well-defined that script sees a coherent state as it executes, so unless you can solve the halting problem, there are pretty severe limits on how much you could parallelize script execution with other stuff. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
