Re: [chromium-dev] Symbolized backtrace on Linux chromium?
On Mon, Nov 30, 2009 at 9:37 AM, Chris Bentzel cbent...@google.com wrote: When DCHECK's trigger on my debug chromium build, I get an unsymbolized stacktrace like [7036:25234:31462940569:FATAL:net/ocsp/nss_ocsp.cc(251)] Check failed: !request_. [7036:25234:31462940569:FATAL:net/ocsp/nss_ocsp.cc(251)] Check failed: !request_. Backtrace: out/Debug/chrome [0x8d7d9bc] out/Debug/chrome [0x8d99838] out/Debug/chrome [0x8fba726] out/Debug/chrome [0x8fb7f7b] out/Debug/chrome [0x8fb7f8f] out/Debug/chrome [0x8fb90e1] out/Debug/chrome [0x8fb9444] /usr/lib/libnss3.so.1d [0xb7884ed4] /usr/lib/libnss3.so.1d [0xb788ed68] /usr/lib/libnss3.so.1d [0xb783533a] /usr/lib/libnss3.so.1d [0xb7836020] /usr/lib/libnss3.so.1d [0xb784e8dd] /usr/lib/libnss3.so.1d [0xb7852527] /usr/lib/libnss3.so.1d [0xb78535a7] /usr/lib/libnss3.so.1d [0xb7858548] /usr/lib/libnss3.so.1d [0xb785a5b6] /usr/lib/libnss3.so.1d(CERT_PKIXVerifyCert+0x464) [0xb77d7ce4] out/Debug/chrome [0x90ee205] out/Debug/chrome [0x90eeed7] out/Debug/chrome [0x90b3ed5] out/Debug/chrome [0x90b399e] out/Debug/chrome [0x90b39d9] out/Debug/chrome [0xa00ec3c] out/Debug/chrome [0x8dafe2e] /lib/tls/i686/cmov/libpthread.so.0 [0xb77044fb] /lib/tls/i686/cmov/libc.so.6(clone+0x5e) [0xb73a2e5e] It looks like this was built with the -g option, and file out/Debug/chrome shows that it's not stripped. This was built from head this morning. Is there a reason I'm not getting symbols to display here? I'm not really sure, but it's sort of interesting that you do seem to get it for certain functions in the system libs. I noticed this issue too recently. I think it's been the case for perhaps the past few weeks or so. My almost completely ungrounded suspicion is it has to do with some of the changes Evan made to shrink the chrome binary size, but I haven't investigated. -- 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] Re: Are we going to use tcmalloc on Mac?
On Tue, Oct 27, 2009 at 9:10 PM, Mike Belshe mbel...@google.com wrote: On Tue, Oct 27, 2009 at 3:24 PM, Jens Alfke s...@chromium.org wrote: Do we plan to switch the Mac build of Chromium to use tcmalloc instead of the system malloc? I thought this was the case, but I can't find any bug covering the task to do that. I'm on the memory task force, and this decision could definitely have an impact (one direction or the other) on footprint on Mac. From a performance perspective, it may be critical to use tcmalloc to match safari performance. It was literally a 50% speedup on most of the DOM perf when running on WinXP. Just thought I'd throw in the data point that I've experimented with enabling tcmalloc for Linux builds of Chromium and the perfbots had negligible changes. I haven't had time to investigate why. I'd recommend you enable it for a run on the perfbots before you spend much time tweaking the mac port of tcmalloc. I just tried enabling tcmalloc (by changing USE_SYSTEM_MALLOC to 0 in JavaScriptCore.gyp), and Chromium launches but logs a ton of warnings about unknown pointers being freed. I suspect this will use the version of TCMalloc which is embedded in WTF. I'd recommend against this approach. We should try to use a single allocator for the entire app, and specialize when necessary. Having the rendering engine drive the allocator is a bit backwards; it seems better for chrome itself to choose the allocator and then the rendering engine should use that. To make this work, you'll need to figure out whatever build magic is necessary on the Mac; I'm kinda clueless in that regard, but if you want to know what we did on Windows, I'm happy to share. You'll find the tcmalloc version that we use on windows available in third_party/tcmalloc. Keep in mind also that the version of tcmalloc in webcore is heavily modified by apple. Some of those changes have been similarly made in tcmalloc's open source project, but others have not. Apple has not seemed interested in syncing back and appears to be on the fork it route. Using third_party/tcmalloc will offer a couple of advantages: - we are continuing to improve it all the way from google3 to the google-perftools to chrome. - it will provide the same allocator on windows and mac (easier debugging) - the chromium implementation allows for selection of multiple allocators fairly easily. Using the allocator_shim.cc, you can plug in your own allocators pretty quickly. There is a disadvantage. I suspect Apple is farther along in optimizing the mac-specific optimizations of tcmalloc than the google3 guys are. You may have to stumble into these. Either Jim or I could probably give you some pointers for what to look at. tcmalloc is solid, but the ports other than linux have had some very serious port related bugs. Mike I think this happens because tcmalloc is built by the 'wtf' target of JavaScriptCore.xcodeproj, which is a static library, so we may be ending up with multiple instances of the library with their own copies of its globals, leading to this problem if one instance allocates a block and another one tries to free it. But this usually happens only if there are multiple dynamic libraries using the same static library — do we have more than just Chromium.framework? —Jens --~--~-~--~~~---~--~~ 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: Chromium Linux 64-bit
w00t, nice job. On Thu, Aug 20, 2009 at 8:44 AM, Dean McNameede...@chromium.org wrote: The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ 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: Chromium Linux 64-bit
On Thu, Aug 20, 2009 at 10:26 AM, Evan Martine...@chromium.org wrote: How does the v8 perf look like relative to 32-bit? I guess we ought to set up perf bots for startup/memory/etc. as well; I'd expect we improve on those metrics on our 64-bit buildbots due to more sharing with other apps on the system. I don't think we have the memory perfbot working yet, since it's blocked on http://code.google.com/p/chromium/issues/detail?id=9653. I agree it'd be nice to see how the perf dashboard compares between 32/64bit. On Thu, Aug 20, 2009 at 8:44 AM, Dean McNameede...@chromium.org wrote: The v8 team did some amazing work this quarter building a working 64-bit port. After a handful of changes on the Chromium side, I've had Chromium Linux building on 64-bit for the last few weeks. I believe mmoss or tony is going to get a buildbot running, and working on packaging. You can follow the build instructions at: http://code.google.com/p/chromium/wiki/LinuxChromium64 It also looks like FTA has updated his daily builds so that the 64-bit packages are true 64-bit: https://launchpad.net/~chromium-daily/+archive/ppa Enjoy them big pointers, -- dean --~--~-~--~~~---~--~~ 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: about gtest's main in chromium
printing_unittests depends on gtestmain.lib. See src/printing/printing.gyp. On Wed, Jun 24, 2009 at 12:46 AM, Jickae Davisjick...@gmail.com wrote: yep, for base_unittests, that's true. But what I want to know is how chromium uses GTest. An important problem is how it runs all the GTest projects. Take the simplest GTest project printing_unittests as an example, I know it's run via GTest's main in run_all_unittests.cc. But I don't know how it invokes the main. I checked the project properties of printing_unittests, and didn't find a link to gtestmain.lib as I always do while writing GTest tests. 2009/6/23 Adam Langley a...@chromium.org On Mon, Jun 22, 2009 at 7:55 PM, Jickae Davisjick...@gmail.com wrote: But I find something weird in the chromiun's GTest projects, they neither write a main nor link a gtest_main.lib. How do they start GTest? Well, you can always set a breakpoint at main and see where you end up. For base_unittests, it's base/run_all_unittests.cc for example. 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] git isn't sync'ing latest svn revisions for me
sorry to evanerg for the remail, my @google.com one bounced Hi, I dunno what's up, but git isn't sync'ing to the latest svn revisions for me: (21:37:35) willchan: any git experts around? (21:37:35) mdengfeng left the room (quit: Read error: 104 (Connection reset by peer)). (21:38:21) willchan: my git repo isn't syncing the latest svn revisions, gives me an error like (21:38:32) willchan: Index mismatch: ab650084ec5d9d308af33d7417442925d645a149 != 9951dd9bfdc1b0cecbad98604aaf9f3f28de27cc (21:38:59) markybob: heh, true, those are != :P (21:39:12) willchan: :) (21:39:24) dave_levin: willchan: I would delete that branch. (21:39:40) willchan: dave_levin: i created a new branch that had the same prob :( (21:39:42) dave_levin: then recreated it (21:39:45) dave_levin: oh (21:39:47) dave_levin: bummer (21:42:26) shenki: pulling the latest changes wfm (21:45:52) willchan: for some reason it seems i can only sync up to r18549 (21:46:48) shenki: that's not the latest commit? (21:46:54) willchan: no (21:46:57) shenki: oh (21:47:01) willchan: it's 6 hours ago (21:47:08) shenki: i assumed it was, as that's the latest im getting = willc...@panda:/usr/local/google/chromium4/src$ git checkout -b new_test origin Branch new_test set up to track remote branch refs/remotes/origin/trunk. Switched to a new branch new_test willc...@panda:/usr/local/google/chromium4/src$ git pull Already up-to-date. willc...@panda:/usr/local/google/chromium4/src$ git log -n5 commit 5aa424b09d8ee966947e69e82244550e40e4c787 Author: t...@chromium.org t...@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98 Date: Tue Jun 16 22:44:58 2009 + Add a small untility for checking to see if the X server is alive. This will be used by the buildbots after Xvfb is executated to make sure that Xvfb is alive. Review URL: http://codereview.chromium.org/126165 git-svn-id: svn://svn.chromium.org/chrome/trunk/s...@18549 0039d316-1c4b-4281-b951-d872f2087c98 ... willc...@panda:/usr/local/google/chromium4/src$ git svn fetch Index mismatch: ab650084ec5d9d308af33d7417442925d645a149 != 9951dd9bfdc1b0cecbad98604aaf9f3f28de27cc rereading 5aa424b09d8ee966947e69e82244550e40e4c787 A chrome/test/data/media/player.html A chrome/test/data/media/bear.mp4 A chrome/browser/media_uitest.cc Checksum mismatch: trunk/src/chrome/chrome.gyp c5184bb887fa26a89e4cd1894e6a9c96a866c020 expected: 0e4f507ffaca2f5c5070acfbc5cf2495 got: ad54c53174d56906eb5391091924f3dc === Can some git ninja help me out? Thanks :) --~--~-~--~~~---~--~~ 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] green flashes in page content
On Tue, May 19, 2009 at 5:12 PM, James Hawkins jhawk...@chromium.org wrote: On Tue, May 19, 2009 at 5:07 PM, Evan Stade est...@chromium.org wrote: Are we sure we need this functionality? I understand the intention of seeing when we're not drawing fast enough, but I'm seeing the green background all the time (on a fast machine), which leads me to believe that the debugging aid is a red herring. Yea, you should see it all the time. We'll never be able to fix that. But how much of it you see is a good measure of jank. If enough people hate it, we can remove it (and only enable when we care to look at jank). We should leave page load/rendering time to measurements from the tests. This should be something that a developer working on jankiness could enable himself. It's rather distracting to the developers who don't need to look into jankiness, but do need to run debug builds regularly. I personally like seeing the green background, since I do like seeing how much jank there is. It doesn't bother me at all. That said, I can see how it'd annoy some people. If most people dislike it, then I think we should just make it the same as the release behavior (use a white background), but I think it'd be nice to have a command line flag or a preference or something so I can run with a green or whatever background to aid in debugging jankiness. -- James Hawkins --~--~-~--~~~---~--~~ 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: Unit tests and anonymous namespaces.
2009/3/6 Scott Hess sh...@chromium.org:
I just wanted to make sure I understood your proposal.
Right now, test classes want to be in the anonymous namespace so that
unit test files do not have to coordinate with each other in the
naming of test classes. With your proposal, the thing which is
exposed outside of the anonymous namespace (MyClassPeer) is based on a
thing already known to be unique (MyClass), so coordinate is not an
issue unless you have multiple unit test files testing the same class.
There are still just as many items exposed outside of the anonymous
namespace, but they are named in a way which prevents collisions.
Is that about right?
Mostly right. It's fewer things exposed outside of the anonymous
namespace, since previously you needed each TEST/TEST_F class to exist
outside the anonymous namespace in order for you to FRIEND_TEST it.
In this way, you only have one Peer per class you're testing. I don't
know enough about Chrome yet, but if there were some very commonly
used classes, then it might make sense to put the Peer class in a
header file for multiple tests to share. My gut instinct is this use
case doesn't happen enough in Chrome to make it worthwhile, but I have
no clue. It made more sense in the Google code base for various
reasons.
Also, I'm a big fan of testing via the public interface methods as
much as possible. Hopefully we don't need to friend most classes in
order to tell them well.
Thanks,
scott
On Tue, Mar 3, 2009 at 4:49 PM, William Chan (陈智昌)
willc...@chromium.org wrote:
My old team never really used FRIEND_TEST. We found it ugly that our
production code depended on test code. We typically used friended
Peer classes defined in the unittest file, but not in the anonymous
namespace. These are simple shims that provide access to the private
section. It also saves on having to FRIEND_TEST each individual test
as you add them. It looks like almost every time FRIEND_TEST is used,
it's used for multiple tests, not just a single one. I'm not sure how
much of a problem chrome has with build dependencies leading to
rebuilds, but it was very annoying in google projects to add a
FRIEND_TEST to a widely used .h file, thus forcing everyone to
rebuild, even though you're only adding a new test.
On Tue, Mar 3, 2009 at 4:30 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Mar 3, 2009 at 3:55 PM, Scott Hess sh...@chromium.org wrote:
On the Mac, code like this:
namespace {
class MyTest : public testing::Test {
};
} // namespace
TEST_F(MyTest, ATest) {
}
generates errors like this:
warning: 'MyTest_ATest_Test' has a field
'MyTest_ATest_Test::anonymous' whose type uses the anonymous
namespace
warning: 'MyTest_ATest_Test' has a base 'unnamed::MyTest' whose type
uses the anonymous namespace
Removing the namespace fixes it, which is poor because we seem to want
to move towards more anonymous namespace use. Putting the test case
inside the namespace also fixes it, but is incompatible with
FRIEND_TEST(). This seems to be a gcc 4.2 addition, per:
http://gcc.gnu.org/gcc-4.2/changes.html
Members of the anonymous namespace are now local to a particular
translation unit, along with any other declarations which use them,
though they are still treated as having external linkage for language
semantics.
At this point, I'm sort of at the bleeding edge of my knowledge. For
FRIEND_TEST() cases, it seems like the anonymous namespace needs to
go, but elsewhere it can be changed to enclose the entire file. Does
that seem reasonable for now?
-scott
Assuming that you really need to use TEST_F, then it would be unfortunate to
lose the anonymous namespace. The anonymous namespace has allowed us to
have short names for helper classes used by tests without fear of colliding
with other short names used by other tests. (We have had those kinds of
conflicts in the past.)
We don't use FRIEND_TEST that much. Maybe we can just use #ifdef UNIT_TEST
to expose class APIs to unit tests?
-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: Unit tests and anonymous namespaces.
My old team never really used FRIEND_TEST. We found it ugly that our
production code depended on test code. We typically used friended
Peer classes defined in the unittest file, but not in the anonymous
namespace. These are simple shims that provide access to the private
section. It also saves on having to FRIEND_TEST each individual test
as you add them. It looks like almost every time FRIEND_TEST is used,
it's used for multiple tests, not just a single one. I'm not sure how
much of a problem chrome has with build dependencies leading to
rebuilds, but it was very annoying in google projects to add a
FRIEND_TEST to a widely used .h file, thus forcing everyone to
rebuild, even though you're only adding a new test.
On Tue, Mar 3, 2009 at 4:30 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Mar 3, 2009 at 3:55 PM, Scott Hess sh...@chromium.org wrote:
On the Mac, code like this:
namespace {
class MyTest : public testing::Test {
};
} // namespace
TEST_F(MyTest, ATest) {
}
generates errors like this:
warning: ‘MyTest_ATest_Test’ has a field
‘MyTest_ATest_Test::anonymous’ whose type uses the anonymous
namespace
warning: ‘MyTest_ATest_Test’ has a base ‘unnamed::MyTest’ whose type
uses the anonymous namespace
Removing the namespace fixes it, which is poor because we seem to want
to move towards more anonymous namespace use. Putting the test case
inside the namespace also fixes it, but is incompatible with
FRIEND_TEST(). This seems to be a gcc 4.2 addition, per:
http://gcc.gnu.org/gcc-4.2/changes.html
Members of the anonymous namespace are now local to a particular
translation unit, along with any other declarations which use them,
though they are still treated as having external linkage for language
semantics.
At this point, I'm sort of at the bleeding edge of my knowledge. For
FRIEND_TEST() cases, it seems like the anonymous namespace needs to
go, but elsewhere it can be changed to enclose the entire file. Does
that seem reasonable for now?
-scott
Assuming that you really need to use TEST_F, then it would be unfortunate to
lose the anonymous namespace. The anonymous namespace has allowed us to
have short names for helper classes used by tests without fear of colliding
with other short names used by other tests. (We have had those kinds of
conflicts in the past.)
We don't use FRIEND_TEST that much. Maybe we can just use #ifdef UNIT_TEST
to expose class APIs to unit tests?
-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 async IO
2009/2/26 Dean McNamee de...@chromium.org: Hey Will, I'd suggest as a first step improving the WorkerPool. It should be pretty easy, I don't think it will hurt us to do something where we fire off threads on demand, but then keep them around and reuse them. Might need some timer to periodically destroy idle threads when we get too many, etc. That's a pretty self contained change and would be a good first review. After that it will make more sense to implement the network file code to post tasks to the worker pool, and just do blocking IO there. That sounds reasonable to me. Also, do you have some page cycler numbers now and some oprofile data? I'd like to see the hot spots and where we are blocking on file access. This will be great data for comparison to the async implementation and make sure that we did indeed address all of the places we were concerned about. Nope, I don't know if it runs yet. I think Darin told me that there was some bug on linux or mac or both where it fails to run. I'm not sure. I agree the data is useful. I'll see if I can get any numbers. Thanks -- dean 2009/2/26 Craig Schlenter craig.schlen...@gmail.com: On Wed, Feb 25, 2009 at 11:21 PM, Adam Langley a...@chromium.org wrote: On Wed, Feb 25, 2009 at 1:13 PM, William Chan (陈智昌) willc...@chromium.org wrote: I talked to Darin and he told me that this needs work since it's impacting the page cycler times, so I figured I'd pick it up. You have a TODO there saying to figure out how to best do async IO. Did you ever figure this out? I talked to Darin briefly and decided that the simplest thing to do for now is simply to post tasks to the global WorkerPool. The global WorkerPool linux implementation looks pretty silly and needs work, but it's probably good enough for the page cycler. How does this approach sound to you? It's not clear if you were considering using POSIX async IO on Linux or not. Just in case you were: don't. It mostly doesn't work. LWN has a nice article on the future of async IO on linux here btw. http://lwn.net/Articles/316806/ Unfortunately that's not that useful currently. --Craig --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] linux async IO
Hey Dean, I talked to Darin and he told me that this needs work since it's impacting the page cycler times, so I figured I'd pick it up. You have a TODO there saying to figure out how to best do async IO. Did you ever figure this out? I talked to Darin briefly and decided that the simplest thing to do for now is simply to post tasks to the global WorkerPool. The global WorkerPool linux implementation looks pretty silly and needs work, but it's probably good enough for the page cycler. How does this approach sound to 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] Re: linux async IO
Woops, newbie mistake, sent from my google.com addr the first time. 2009/2/25 William Chan (陈智昌) willc...@google.com: Sorry for not being clear. Yep, you're correct, I'm not planning use POSIX async IO. Just planning to execute the sync IO on the WorkerPool. On Wed, Feb 25, 2009 at 1:21 PM, Adam Langley a...@chromium.org wrote: On Wed, Feb 25, 2009 at 1:13 PM, William Chan (陈智昌) willc...@chromium.org wrote: I talked to Darin and he told me that this needs work since it's impacting the page cycler times, so I figured I'd pick it up. You have a TODO there saying to figure out how to best do async IO. Did you ever figure this out? I talked to Darin briefly and decided that the simplest thing to do for now is simply to post tasks to the global WorkerPool. The global WorkerPool linux implementation looks pretty silly and needs work, but it's probably good enough for the page cycler. How does this approach sound to you? It's not clear if you were considering using POSIX async IO on Linux or not. Just in case you were: don't. It mostly doesn't work. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
