[chromium-dev] Thread naming
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-dev] suppressing print dialog in kiosk mode
I have modified some code involving the print dialog and the printer settings on Linux. Whoever is interested in the details of this, please give feedback. I have made these changes in order to install Linux/Chromium onto an in-store kiosk for customers to place orders. This is a Linux-only modification because the print dialog and print settings on Linux do not go through the same code paths as the Mac OS X and Windows builds appear to do. Here is a summary of my changes and ideas: 1) If --kiosk is passed at the command-line, I assume the desired printer (GtkPrinter), print settings (GtkPrintSettings), and print setup (GtkPageSetup) are configured from other command-line switches. I am considering using a separate switch such as --supress-print- dialog, since kiosk mode and suppressing the print dialog are orthogonal features. 2) The command-line switches for the printer and its print settings are prefixed with --print-settings. The printer name is specified with --print-settings-printer. Since every printer may have different settings, the set of switches will differ for each printer. For example, Print to file may be specified as the printer name. If it is, then --print-settings-output is a valid option. For a physical printer, there are switches for things like opening a cash drawer, the pulse width, and so on. It does seem a little odd to break from the norm where command-line switches are static and well-documented in the switches source files. I had to add a function to CommandLine in order to enumerate the switches and look for ones with a particular prefix (--print- settings). Thoughts? 3) The switches for the page setup are prefixed with --page-setup and are not variable, since they map directly to member properties of the GtkPageSetup class. These are things like paper width and orientation. 4) WISH: Instead of putting this massive list of switches on the command-line, using an about:config seems ideal. Has anyone started this? 5) WISH: Ultimately, the linux code should be merged with the other platforms so that these new features could be shared. I do not have chromium building on Mac OS X or Windows. Can someone confirm that it is true that these code paths are not merged? I noticed that on these other platforms, there is functionality related to asking the user for the settings or using the default. Is this related to the feature I'm attempting to add? Thanks in advance for any guidance. Andy -- 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] suppressing print dialog in kiosk mode
On Thu, Dec 31, 2009 at 2:32 AM, Andy Ames a...@amesgames.net wrote: I am considering using a separate switch such as --supress-print- dialog, since kiosk mode and suppressing the print dialog are orthogonal features. They don't seem orthogonal, since in kiosk mode it doesn't seem like you would ever want to show a user a print dialog (or any other kind of system configuration dialog). 2) The command-line switches for the printer and its print settings are prefixed with --print-settings. The printer name is specified with --print-settings-printer. Ugh. Prefer descriptive individual names over groupwise patterns. It does seem a little odd to break from the norm where command-line switches are static and well-documented in the switches source files. I had to add a function to CommandLine in order to enumerate the switches and look for ones with a particular prefix (--print- settings). Thoughts? Why not instead make these things that can be configured in the preferences, which (being JSON) can be more descriptive without affecting the command-line parsing code? 4) WISH: Instead of putting this massive list of switches on the command-line, using an about:config seems ideal. Has anyone started this? See my comment above. 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] Thread naming
On Thu, Dec 31, 2009 at 1:11 AM, Berend-Jan Wever skyli...@chromium.org wrote: It would be nice if we could name all threads, so you know what you're looking at. It would be nice if threads were required to be given a name as part of creation, perhaps with a central registry to make sure things are unique. If this amount of overhead is enough to prevent you from spinning up a new thread sometimes ... I guess that's a benefit. If it's not important enough to register, maybe it's not important enough to be a thread, and bad thread usage causes a lot of our bugs. -scott (from chromium.org this time) -- 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
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.orgwrote: 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
Re: [chromium-dev] suppressing print dialog in kiosk mode
On Thu, Dec 31, 2009 at 5:51 AM, Peter Kasting pkast...@google.com wrote:
They don't seem orthogonal, since in kiosk mode it doesn't seem like you
would ever want to show a user a print dialog (or any other kind of system
configuration dialog).
I agree as well. 1+
Why not instead make these things that can be configured in the
preferences, which (being JSON) can be more descriptive without affecting
the command-line parsing code?
Thats the idea that was intended. Marc-Antoine, Sverrir and I actually did
basic printer settings preferences a way back, (the definition of it) you
can view the code here:
http://src.chromium.org/viewvc/chrome?view=revrevision=13426
The definition of the preferences for printing (so far) is defined as
follows:
printing: {
page: {
header: {
left: ,
center: ,
right:
},
footer: {
left: {date},
center: ,
right:
}
}
}
Those are not hooked up yet to our printing yet, and would be great to do
so. We can offer other preferences for printing there as well. But make sure
you inform Marc-Antoine (maruel@) and the group before doing anything.
I don't think its ideal to put --printer configurations in the command line
parameter, it shouldn't be like that and it becomes confusing and cluttered.
We already have a place in preferences for printing.
If you want, I can assist you on the Windows portion (I am an external
contributor so my time is usually limited). There is a lot printing related
issues related to threads that need to be fixed first before hooking it up
the preferences printer settings to chrome.
http://code.google.com/p/chromium/issues/list?q=label:Printing
Let us know and let me know if you need a Windows SideKick :)
--
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] Re: Running Chromebot on official builds from trunk
Driveby [possibly irrelevant] comment: I committed a patch to trunk after
the beta branch that changes the code path for reaping processes, you might
want to try to repro this on the beta branch and then try on trunk.
On Thu, Dec 31, 2009 at 7:33 AM, Mark Mentovai m...@chromium.org wrote:
Debugging tips:
1. What's the parent pid of your zombies? Is it a browser process or
something else?
2. Temporarily move /bin/ps to /bin/ps.real, and at /bin/ps put a
small script that writes the full argument list and maybe other
debuggery to a log file somewhere, and then invokes /bin/ps.real. For
example:
#!/bin/sh
(date ; echo ${$} ${PPID} $...@}) /tmp/pslog.${EUID}
exec ${0}.real $...@}
Then, using the logged data, you'll see what arguments ps is being
invoked with, and you'll be able to look to see where we make those ps
calls in our own code (if it's even happening in our own code).
3. Try to reproduce it in a developer build instead of a released
official build. You'll need to reproduce it to know if you've fixed
it once you think you've figured it out.
h-n-y,
Mark
--
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] suppressing print dialog in kiosk mode
Thanks for the tips.
I will put printer settings into the preferences as a dictionary
instead of on the command-line.
I'll create only one command-line switch called --suppress-print-
dialog. I will make sure --kiosk implies that switch. For easier
debugging, I will need to be able to suppress the print dialog when
not in kiosk mode.
I created 2 issues in the tracker for both the suppressing of the
dialog and the printer settings:
http://code.google.com/p/chromium/issues/detail?id=31395
http://code.google.com/p/chromium/issues/detail?id=31396
I will be working on these right away.
Andy
On Dec 31, 2009, at 12:11 PM, Mohamed Mansour wrote:
On Thu, Dec 31, 2009 at 5:51 AM, Peter Kasting pkast...@google.com
wrote:
They don't seem orthogonal, since in kiosk mode it doesn't seem like
you would ever want to show a user a print dialog (or any other kind
of system configuration dialog).
I agree as well. 1+
Why not instead make these things that can be configured in the
preferences, which (being JSON) can be more descriptive without
affecting the command-line parsing code?
Thats the idea that was intended. Marc-Antoine, Sverrir and I
actually did basic printer settings preferences a way back, (the
definition of it) you can view the code here:
http://src.chromium.org/viewvc/chrome?view=revrevision=13426
The definition of the preferences for printing (so far) is defined
as follows:
printing: {
page: {
header: {
left: ,
center: ,
right:
},
footer: {
left: {date},
center: ,
right:
}
}
}
Those are not hooked up yet to our printing yet, and would be great
to do so. We can offer other preferences for printing there as well.
But make sure you inform Marc-Antoine (maruel@) and the group
before doing anything.
I don't think its ideal to put --printer configurations in the
command line parameter, it shouldn't be like that and it becomes
confusing and cluttered. We already have a place in preferences for
printing.
If you want, I can assist you on the Windows portion (I am an
external contributor so my time is usually limited). There is a lot
printing related issues related to threads that need to be fixed
first before hooking it up the preferences printer settings to
chrome. http://code.google.com/p/chromium/issues/list?q=label:Printing
Let us know and let me know if you need a Windows SideKick :)
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
[chromium-dev] Faster linking for chromium on ubuntu
Hi,
I have installed gold linker mentioned here:
http://code.google.com/p/chromium/wiki/LinuxFasterBuilds
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.
Thank you for any ideas.
--
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 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.
Did you rerun gyp, e.g. with the command
glient runhooks --force
after changing ~/.gyp/include.gypi ?
--
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] suppressing print dialog in kiosk mode
Why wont you just remove --supress-print-dialog and just include it in kiosk
instead. I don't believe there is a reason to have an extra command line
option for that. Unless other people want that ... I believe preferences is
a better task for this since it is going to persisted in the near future.
-Mohamed Mansour
On Thu, Dec 31, 2009 at 5:39 PM, Andy Ames a...@amesgames.net wrote:
Thanks for the tips.
I will put printer settings into the preferences as a dictionary instead of
on the command-line.
I'll create only one command-line switch called --suppress-print-dialog. I
will make sure --kiosk implies that switch. For easier debugging, I will
need to be able to suppress the print dialog when not in kiosk mode.
I created 2 issues in the tracker for both the suppressing of the dialog
and the printer settings:
http://code.google.com/p/chromium/issues/detail?id=31395
http://code.google.com/p/chromium/issues/detail?id=31396
I will be working on these right away.
Andy
On Dec 31, 2009, at 12:11 PM, Mohamed Mansour wrote:
On Thu, Dec 31, 2009 at 5:51 AM, Peter Kasting pkast...@google.comwrote:
They don't seem orthogonal, since in kiosk mode it doesn't seem like you
would ever want to show a user a print dialog (or any other kind of system
configuration dialog).
I agree as well. 1+
Why not instead make these things that can be configured in the
preferences, which (being JSON) can be more descriptive without affecting
the command-line parsing code?
Thats the idea that was intended. Marc-Antoine, Sverrir and I actually did
basic printer settings preferences a way back, (the definition of it) you
can view the code here:
http://src.chromium.org/viewvc/chrome?view=revrevision=13426
The definition of the preferences for printing (so far) is defined as
follows:
printing: {
page: {
header: {
left: ,
center: ,
right:
},
footer: {
left: {date},
center: ,
right:
}
}
}
Those are not hooked up yet to our printing yet, and would be great to do
so. We can offer other preferences for printing there as well. But make sure
you inform Marc-Antoine (maruel@) and the group before doing anything.
I don't think its ideal to put --printer configurations in the command line
parameter, it shouldn't be like that and it becomes confusing and cluttered.
We already have a place in preferences for printing.
If you want, I can assist you on the Windows portion (I am an external
contributor so my time is usually limited). There is a lot printing related
issues related to threads that need to be fixed first before hooking it up
the preferences printer settings to chrome.
http://code.google.com/p/chromium/issues/list?q=label:Printing
Let us know and let me know if you need a Windows SideKick :)
--
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] How to launch chromium with Automation Provider
Hi, Can you please tell me what are the command line parameters I need to pass in when I launch chromium if I want chromium to start Automation Provider as well? Thank you. -- 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 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.
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'?
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-dev] code coverage on 3 platforms
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
