summaryrefslogtreecommitdiffstats
path: root/base
Commit message (Collapse)AuthorAgeFilesLines
* Help make base compile under NaClabarth@chromium.org2010-12-011-0/+15
| | | | | | | | | | | | This file requires a few tweaks to run under Native Client. For example, there isn't a NaCl API to determine whether the process is being debugged and int3 isn't a valid NaCl instruction. Original patch by Eric Seidel. Review URL: http://codereview.chromium.org/5423002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67827 0039d316-1c4b-4281-b951-d872f2087c98
* Help make base compile in NaCl.abarth@chromium.org2010-12-011-0/+6
| | | | | | | | | | Turns out intptr_t isn't 64 bits wide in 64-bit NaCl. This class assumes that Atomic64 is actually 64 bits wide, so we need to use the int64_t type instead. Original patch by Eric Seidel. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67826 0039d316-1c4b-4281-b951-d872f2087c98
* windows: remove PathService::Get() that uses wstringsevan@chromium.org2010-11-302-17/+0
| | | | | | | | | | This just required fixing the remaining callers. BUG=24672 Review URL: http://codereview.chromium.org/5356008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67783 0039d316-1c4b-4281-b951-d872f2087c98
* net: Remove typedef net::URLRequest URLRequest;tfarina@chromium.org2010-11-301-5/+5
| | | | | | | | | BUG=64263 TEST=compiled locally, trybots Review URL: http://codereview.chromium.org/5384002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67762 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 67662 - FBTF: Remove unneeded headers from base/ (part 10)thestig@chromium.org2010-11-301-0/+1
| | | | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/5139006 TBR=thestig@chromium.org Review URL: http://codereview.chromium.org/5270010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67674 0039d316-1c4b-4281-b951-d872f2087c98
* FBTF: Remove unneeded headers from base/ (part 10)thestig@chromium.org2010-11-301-1/+0
| | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/5139006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67662 0039d316-1c4b-4281-b951-d872f2087c98
* Some additions to support symlinks better on platforms that support them.gspencer@chromium.org2010-11-307-11/+78
| | | | | | | | | BUG=none TEST=Ran new unit test, passed trybots. Review URL: http://codereview.chromium.org/5349007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67631 0039d316-1c4b-4281-b951-d872f2087c98
* Moved the calls to the MessageLoop destruction observers to after the ↵sanjeevr@chromium.org2010-11-302-4/+68
| | | | | | | | | | | | pending tasks are deleted. BUG=None TEST=Unit-test provided, tests should pass and all hell should not break loose. Review URL: http://codereview.chromium.org/5318003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67623 0039d316-1c4b-4281-b951-d872f2087c98
* Remove a pair of overly aggressive DCHECKsjar@chromium.org2010-11-291-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consistency checks (to detect memory corruption) were disabled for non-standard derived forms of histograms (some cache stats were using histograms a bit differently). When I added a virtual function to allow such derived classes to override the checking code, I forgot I had some inline DCHECKs as well. The method for getting the total_count was still DCHECKing the consistency, and there was another consistency assertion made when gathering data for upload to UMA. Both of these DCHECKs, which were not overridden, were removed. They were there to assure my code was working, and to detect memory smashers (or broken DRAM) more quickly... but are too hard to cleanly override (for the one histogram that does not support this facility). BUG=61281 BUG=64268 r=jam Review URL: http://codereview.chromium.org/5365004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67608 0039d316-1c4b-4281-b951-d872f2087c98
* Make base's fork of ICU macros use its internal version for one case that wasbrettw@chromium.org2010-11-291-1/+1
| | | | | | | | | | forgotten before. TEST=it compiles BUG=none Review URL: http://codereview.chromium.org/5270009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67601 0039d316-1c4b-4281-b951-d872f2087c98
* Add a unit test for CommandLine that makes sure that GetProgram will not ↵tommi@chromium.org2010-11-291-0/+19
| | | | | | | | | | | return a quoted string and that (on Windows) the program part of a command line string will always be quoted. BUG=none TEST=Run the ProgramQuotes test. Should be no visible changes. Review URL: http://codereview.chromium.org/4949004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67583 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "base: wait for children to terminate."agl@chromium.org2010-11-291-55/+43
| | | | | | | This reverts commit r67562, it caused some test failures which I need to look at. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67573 0039d316-1c4b-4281-b951-d872f2087c98
* base: wait for children to terminate.agl@chromium.org2010-11-291-43/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | I screwed up and assumed that you can't race the kernel. But it turns out that it's possible to obverse a child in the process of dying. The kernel will close the child's file descriptors before waitpid knows that the child is dead. Rather than rewrite everything (in an area of the code which has had lots of issues in the past), I'm opting to do a blocking wait for the child to die. The code higher up already copes with waitpid() failing, but we'll miss some crashes if it does. With this patch, we'll wait up to 250ms for the termination information on a child. We are, no doubt, blocking a latency sensitive thread with this. However, the race window in the kernel is small, so doesn't really block for > a millisecond or so. We do have to consider the case where a buggy child closes its file descriptor without dying. In that case, we'll block for the full 250ms but that indicates a serious bug in the child. BUG=63531 TEST=nagivating to about:gpucrash on linux and checking the we know that the child crashed. http://codereview.chromium.org/5377001/ git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67572 0039d316-1c4b-4281-b951-d872f2087c98
* Make ScopedTempDir::Delete return a bool so that its functionality can be ↵tommi@chromium.org2010-11-293-6/+37
| | | | | | | | | | | tested. TEST=Run the new unit test: ScopedTempDir.LockedTempDir BUG=none Review URL: http://codereview.chromium.org/5340004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67551 0039d316-1c4b-4281-b951-d872f2087c98
* Check if the frame belongs to the browser tree associated with the BHO ↵siggi@chromium.org2010-11-251-0/+5
| | | | | | | | | | | | | | | | | before commiting to creating and binding handlers. Also, replace CComPtr with ScopedPtrHandler. Committing for motek@google.com, original review at http://codereview.chromium.org/5311003/. TEST=unittests in change. BUG=3205224 BUG=3166440 Review URL: http://codereview.chromium.org/5360003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67415 0039d316-1c4b-4281-b951-d872f2087c98
* Make sure third_party/dmg_fp/dtoa.cc is compiled threadsafe.siggi@chromium.org2010-11-252-1/+41
| | | | | | | | | BUG=64353 TEST=none Review URL: http://codereview.chromium.org/5321008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67414 0039d316-1c4b-4281-b951-d872f2087c98
* Fixed warning on empty --v switch (this time for reals)akalin@chromium.org2010-11-251-5/+6
| | | | | | | | | BUG=None TEST=Manual Review URL: http://codereview.chromium.org/5364001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67360 0039d316-1c4b-4281-b951-d872f2087c98
* This is another try to commit OOM priority management.gspencer@chromium.org2010-11-241-1/+1
| | | | | | | | | | | | | This changes nothing, except that I now initialize memory_used in oom_priority_manager.cc to placate the incorrect gcc warning about it being used when uninitialized. The original review is here: http://codereview.chromium.org/4498001/ BUG=none TEST=Passed chromeos try-bot, built both debug and release locally. Review URL: http://codereview.chromium.org/5328003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67342 0039d316-1c4b-4281-b951-d872f2087c98
* Initial conversion of download unit test to browser test with enhancedrdsmith@google.com2010-11-242-0/+66
| | | | | | | | | | | download completion detection (DownloadsObserver). BUG=None TEST=browser_tests --gtest_filter=DownloadTest.DownloadMimeType Review URL: http://codereview.chromium.org/4658001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67279 0039d316-1c4b-4281-b951-d872f2087c98
* Cleanup AdjustStringForLocaleDirection() to modify input parameter in place.jeremy@chromium.org2010-11-242-32/+17
| | | | | | | | | | | As described in the bug, the current behavior is confusing and bug-prone. BUG=47194 TEST=Check that there are no visible regressions in RTL and LTR language UIs on Linux & Windows. Review URL: http://codereview.chromium.org/5154009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67237 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 67201 - Revert 67191 - chrome_paths: refactor and sanitize cache ↵viettrungluu@chromium.org2010-11-246-21/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | directory handling [Checking to see if this build failures on Windows.] [[Nope. Failure was a flake.]] Previously we had a bunch of logic in profile_impl.cc that computed where the cache directory lives. This change relocates it to chrome_paths.cc. Some background on cache directories. There are two possible places to store cache files: 1) in the user data directory 2) in an OS-specific user cache directory On Windows, we always pick (1). On Mac and Linux, we currently use (2) in some circumstances. This patch changes both Mac and Linux to have the same behavior with respect to (2). The Mac/Linux shared behavior is that if the profile directory is in the standard location for profiles, we put the cache files into a matching directory name in the standard system cache directory (e.g. on Linux if you're using ~/.config/google-chrome, your cache ends up in ~/.cache/google-chrome; on Mac, the directories are ~/Library/Application Support versus ~/Library/Caches). If your user data directory is not in the standard location, we use behavior (1). The semantic changes of this patch should be: - On Mac, previously we checked whether the (2) directory had some particular subdirectories already when picking which one to use. This was removed; which directory is used is solely a question of whether the profile directory is in the standard location. I think the previous behavior was unpredictable. - On Linux, previously we only used behavior (2) if you hadn't changed your user-data-directory at all. Now, to match Mac, as long as your user-data-dir is in the standard place, you use the system cache dir. So e.g. using ~/.config/foobar puts your cache in ~/.cache/foobar. - On Linux, previously the default cache would end up as directories under ~/.cache/google-chrome/; now it ends up as directories under ~/.cache/google-chrome/Default/. (In all instances above, on Linux we continue to obey $XDG_CACHE_HOME.) BUG=59824 TEST=New test ChromePaths.UserCacheDir Review URL: http://codereview.chromium.org/5123004 TBR=evan@chromium.org Review URL: http://codereview.chromium.org/5344003 TBR=viettrungluu@chromium.org git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67202 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 67191 - chrome_paths: refactor and sanitize cache directory handlingviettrungluu@chromium.org2010-11-246-9/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Checking to see if this build failures on Windows.] Previously we had a bunch of logic in profile_impl.cc that computed where the cache directory lives. This change relocates it to chrome_paths.cc. Some background on cache directories. There are two possible places to store cache files: 1) in the user data directory 2) in an OS-specific user cache directory On Windows, we always pick (1). On Mac and Linux, we currently use (2) in some circumstances. This patch changes both Mac and Linux to have the same behavior with respect to (2). The Mac/Linux shared behavior is that if the profile directory is in the standard location for profiles, we put the cache files into a matching directory name in the standard system cache directory (e.g. on Linux if you're using ~/.config/google-chrome, your cache ends up in ~/.cache/google-chrome; on Mac, the directories are ~/Library/Application Support versus ~/Library/Caches). If your user data directory is not in the standard location, we use behavior (1). The semantic changes of this patch should be: - On Mac, previously we checked whether the (2) directory had some particular subdirectories already when picking which one to use. This was removed; which directory is used is solely a question of whether the profile directory is in the standard location. I think the previous behavior was unpredictable. - On Linux, previously we only used behavior (2) if you hadn't changed your user-data-directory at all. Now, to match Mac, as long as your user-data-dir is in the standard place, you use the system cache dir. So e.g. using ~/.config/foobar puts your cache in ~/.cache/foobar. - On Linux, previously the default cache would end up as directories under ~/.cache/google-chrome/; now it ends up as directories under ~/.cache/google-chrome/Default/. (In all instances above, on Linux we continue to obey $XDG_CACHE_HOME.) BUG=59824 TEST=New test ChromePaths.UserCacheDir Review URL: http://codereview.chromium.org/5123004 TBR=evan@chromium.org Review URL: http://codereview.chromium.org/5344003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67201 0039d316-1c4b-4281-b951-d872f2087c98
* chrome_paths: refactor and sanitize cache directory handlingevan@chromium.org2010-11-246-21/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we had a bunch of logic in profile_impl.cc that computed where the cache directory lives. This change relocates it to chrome_paths.cc. Some background on cache directories. There are two possible places to store cache files: 1) in the user data directory 2) in an OS-specific user cache directory On Windows, we always pick (1). On Mac and Linux, we currently use (2) in some circumstances. This patch changes both Mac and Linux to have the same behavior with respect to (2). The Mac/Linux shared behavior is that if the profile directory is in the standard location for profiles, we put the cache files into a matching directory name in the standard system cache directory (e.g. on Linux if you're using ~/.config/google-chrome, your cache ends up in ~/.cache/google-chrome; on Mac, the directories are ~/Library/Application Support versus ~/Library/Caches). If your user data directory is not in the standard location, we use behavior (1). The semantic changes of this patch should be: - On Mac, previously we checked whether the (2) directory had some particular subdirectories already when picking which one to use. This was removed; which directory is used is solely a question of whether the profile directory is in the standard location. I think the previous behavior was unpredictable. - On Linux, previously we only used behavior (2) if you hadn't changed your user-data-directory at all. Now, to match Mac, as long as your user-data-dir is in the standard place, you use the system cache dir. So e.g. using ~/.config/foobar puts your cache in ~/.cache/foobar. - On Linux, previously the default cache would end up as directories under ~/.cache/google-chrome/; now it ends up as directories under ~/.cache/google-chrome/Default/. (In all instances above, on Linux we continue to obey $XDG_CACHE_HOME.) BUG=59824 TEST=New test ChromePaths.UserCacheDir Review URL: http://codereview.chromium.org/5123004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67191 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 67175 - This change implements OOM priority management for ChromeOSviettrungluu@chromium.org2010-11-231-1/+1
| | | | | | | | | | | | | | | | (Build failure, probably debug/release warning difference.) This adds periodic OOM score adjustment, based on the last access time of the tab, whether or not it is pinned, and (of course) how much memory it is using. BUG=http://crosbug.com/8990 TEST=Ran some ui_tests, ran on device. Review URL: http://codereview.chromium.org/4498001 TBR=gspencer@chromium.org Review URL: http://codereview.chromium.org/5284003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67183 0039d316-1c4b-4281-b951-d872f2087c98
* Stop using Hard Coded copies of GUID strings in RGS files.mad@google.com2010-11-232-0/+90
| | | | | | | | | BUG=0 TEST=Make sure everything works after unregistration and re-registration. Review URL: http://codereview.chromium.org/5113005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67180 0039d316-1c4b-4281-b951-d872f2087c98
* This change implements OOM priority management for ChromeOSgspencer@chromium.org2010-11-231-1/+1
| | | | | | | | | | | This adds periodic OOM score adjustment, based on the last access time of the tab, whether or not it is pinned, and (of course) how much memory it is using. BUG=http://crosbug.com/8990 TEST=Ran some ui_tests, ran on device. Review URL: http://codereview.chromium.org/4498001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67175 0039d316-1c4b-4281-b951-d872f2087c98
* Fix shutdown crash in CertVerifier by using a MessageLoopProxy.willchan@chromium.org2010-11-232-1/+7
| | | | | | | | | | | The CertVerifier is not getting Cancel()'d because something which owns it is getting leaked, most likely a URLRequestJob. Therefore, we can end up accessing a deleted MessageLoop on shutdown. MessageLoopProxy prevents accessing a deleted MessageLoop on shutdown, instead it just deletes the task, which isn't great, but it's better than crashing. We should fix the root cause eventually, which is a leak of the URLRequestJob. BUG=42275,chromium-os:8179 TEST=none Review URL: http://codereview.chromium.org/5347001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67172 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "chrome_paths: refactor and sanitize cache directory handling"evan@chromium.org2010-11-236-7/+25
| | | | | | This reverts commit r67160, test failures. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67171 0039d316-1c4b-4281-b951-d872f2087c98
* chrome_paths: refactor and sanitize cache directory handlingevan@chromium.org2010-11-236-25/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we had a bunch of logic in profile_impl.cc that computed where the cache directory lives. This change relocates it to chrome_paths.cc. Some background on cache directories. There are two possible places to store cache files: 1) in the user data directory 2) in an OS-specific user cache directory On Windows, we always pick (1). On Mac and Linux, we currently use (2) in some circumstances. This patch changes both Mac and Linux to have the same behavior with respect to (2). The Mac/Linux shared behavior is that if the profile directory is in the standard location for profiles, we put the cache files into a matching directory name in the standard system cache directory (e.g. on Linux if you're using ~/.config/google-chrome, your cache ends up in ~/.cache/google-chrome; on Mac, the directories are ~/Library/Application Support versus ~/Library/Caches). If your user data directory is not in the standard location, we use behavior (1). The semantic changes of this patch should be: - On Mac, previously we checked whether the (2) directory had some particular subdirectories already when picking which one to use. This was removed; which directory is used is solely a question of whether the profile directory is in the standard location. I think the previous behavior was unpredictable. - On Linux, previously we only used behavior (2) if you hadn't changed your user-data-directory at all. Now, to match Mac, as long as your user-data-dir is in the standard place, you use the system cache dir. So e.g. using ~/.config/foobar puts your cache in ~/.cache/foobar. - On Linux, previously the default cache would end up as directories under ~/.cache/google-chrome/; now it ends up as directories under ~/.cache/google-chrome/Default/. (In all instances above, on Linux we continue to obey $XDG_CACHE_HOME.) BUG=59824 TEST=New test ChromePaths.UserCacheDir Review URL: http://codereview.chromium.org/5123004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67160 0039d316-1c4b-4281-b951-d872f2087c98
* Fixed logging so that vmodule works correctly againakalin@chromium.org2010-11-233-9/+5
| | | | | | | | | | | | | | Removed extraneous check in LogMessage destructor; all the checks are now done before LogMessage is created. Removed useless warning if --vmodule is used but --v is not. BUG=None TEST=Manual Review URL: http://codereview.chromium.org/5329001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67131 0039d316-1c4b-4281-b951-d872f2087c98
* Add infrastructure enabling tests of installer upgrade scenarios.grt@chromium.org2010-11-231-3/+3
| | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/5236002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67099 0039d316-1c4b-4281-b951-d872f2087c98
* Implements openssl session cachingjoth@chromium.org2010-11-231-0/+2
| | | | | | | | | | | Also fixes up the ssl socket handling of the OpenSSL error stack, and resolves a few TODOs. BUG=None TEST=opening https: pages with vlog=3 enabled and expected the log Review URL: http://codereview.chromium.org/5100010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67087 0039d316-1c4b-4281-b951-d872f2087c98
* Dynamic refresh for the silent extension install policygfeher@chromium.org2010-11-233-0/+43
| | | | | | | | | | | Re-run ExternalPolicyExtensionProvider::VisitRegisteredExtension each time the policy-controlled preference prefs::kExtensionInstallForceList is changed. This will install new policy-controlled extensions. Those that are removed from the policy will only be uninstalled at next startup. BUG=63179 TEST=ExtensionManagementTest.ExternalPolicyRefresh Review URL: http://codereview.chromium.org/5120003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67078 0039d316-1c4b-4281-b951-d872f2087c98
* Reconstructing 67000.bradnelson@google.com2010-11-231-1/+1
| | | | | | | | | | | | | | (python24 -> python26). Regression in nacl fixed, new DEPS change. BUG=None TEST=NOne Review URL: http://codereview.chromium.org/5310001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67057 0039d316-1c4b-4281-b951-d872f2087c98
* Revert previous commit which was by accidentjabdelmalek@google.com2010-11-231-0/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67052 0039d316-1c4b-4281-b951-d872f2087c98
* Fix compile error on Linuxjabdelmalek@google.com2010-11-231-1/+0
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67051 0039d316-1c4b-4281-b951-d872f2087c98
* Make DeleteKey support GetLastError.tommi@chromium.org2010-11-231-1/+6
| | | | | | | | | | | | | | | | | | | | | | | When SHDeleteKey returns, the last error value hasn't been set. With this change, it's possible to have checks like: if (!key.DeleteKey(...) && GetLastError() != ERROR_NOT_FOUND) { HandleErrorCase(); return false; } return true; As it stands, the last error value will always be ERROR_SUCCESS, which is not all that useful. In fact there is code in the installer that attempts to do this, but doesn't currently work correctly (also because it's checking for the wrong GLE value, but I'm fixing that in a separate change). BUG=none TEST=Should have no side effects. Review URL: http://codereview.chromium.org/5182009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67049 0039d316-1c4b-4281-b951-d872f2087c98
* [Mac] Log registers with stackdump in debug crashes.shess@chromium.org2010-11-221-7/+51
| | | | | | | | | | | Expand |StackDumpSignalHandler()| to log register contents and part of the stack. BUG=60426 TEST=Bug's crashes get registers logged. Review URL: http://codereview.chromium.org/5243002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67012 0039d316-1c4b-4281-b951-d872f2087c98
* Switch to using kInvalidThreadId instead of 0.willchan@chromium.org2010-11-221-2/+2
| | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/5266001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67011 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 67000.bradnelson@google.com2010-11-221-1/+1
| | | | | | | | | | BUG=None TEST=None TBR=nsylvain Review URL: http://codereview.chromium.org/5272001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67004 0039d316-1c4b-4281-b951-d872f2087c98
* Switching chrome to use python26 in place of python24.bradnelson@google.com2010-11-221-1/+1
| | | | | | | | | BUG=None TEST=None Review URL: http://codereview.chromium.org/5121009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67000 0039d316-1c4b-4281-b951-d872f2087c98
* Fix ThreadChecker to use Locks and not use scoped_ptr.willchan@chromium.org2010-11-214-17/+26
| | | | | | | | | | | | | | | It needs to synchronize its checks, since in order to assert correctly, it needs to make sure the thread id is synchronized on all threads. It doesn't need scoped_ptr. It was trying to use NULL to catch invalid thread ids. 0 is already assumed to be invalid (see base::Thread's use). Eliminating scoped_ptr fixes a valgrind/heapcheck issue where they don't follow LazyInstance objects' member pointers. So they think the ThreadChecker's member variable is leaked, even though the global object still has a pointer to it. Removing the scoped_ptr.h caused a bunch of other lame files to fail to compile. I had to fix those places. #include what you use please :( TBR=levin (I want to green the memory bots) BUG=none TEST=none Review URL: http://codereview.chromium.org/5180006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66915 0039d316-1c4b-4281-b951-d872f2087c98
* Leak NSS to prevent shutdown crashes.willchan@chromium.org2010-11-211-59/+74
| | | | | | | | | | | NSS can be used by non-joinable threads (worker threads). These can access it after ~AtExitManager has already triggered the NSS shutdown code, so we can crash on shutdown. Therefore we leak NSS. BUG=61585 TEST=existing Review URL: http://codereview.chromium.org/5240001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66904 0039d316-1c4b-4281-b951-d872f2087c98
* FBTF: Remove unneeded headers from base/ (part 9)thestig@chromium.org2010-11-209-10/+5
| | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/5091005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66873 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes a crash in the Windows media player plugin caused when the Real player ↵ananta@chromium.org2010-11-192-3/+29
| | | | | | | | | | | | | | | | | | | | | | | recorder plugin is installed on the machine. This plugin intercepts LoadLibrary calls issued by chrome.dll and wraps NPAPI calls provided the actual plugin dll, in this case media player. This is to provide the Download this video functionality. Crash occurs probably due to an interacton with Real player and media player. Fix is to load the plugin dynamically via the exported kernel32 function LoadLibrary instead of invoking it via the LoadLibrary import from chrome.dll. This would bypass the recorder plugin. Fixes bug http://code.google.com/p/chromium/issues/detail?id=63552 Bug=63552 Test=Install real player and media player on the machine and navigate to the url mentioned in the bug. It should not crash Review URL: http://codereview.chromium.org/5190005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66839 0039d316-1c4b-4281-b951-d872f2087c98
* Reland 66791 (change was innocent)willchan@chromium.org2010-11-198-41/+180
| | | | | | | | | | | | | | | | | | | Revert 66719 - Reland r65996. Disallows Singletons on non-joinable thread. Test breakages caused by this change have been fixed here or in other changelists. BUG=61753 TEST=none Review URL: http://codereview.chromium.org/5024003 TBR=willchan@chromium.org Review URL: http://codereview.chromium.org/5206005 TBR=willchan@chromium.org Review URL: http://codereview.chromium.org/5242002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66808 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 66719 - Reland r65996. Disallows Singletons on non-joinable thread.willchan@chromium.org2010-11-198-180/+41
| | | | | | | | | | | | | | Test breakages caused by this change have been fixed here or in other changelists. BUG=61753 TEST=none Review URL: http://codereview.chromium.org/5024003 TBR=willchan@chromium.org Review URL: http://codereview.chromium.org/5206005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66791 0039d316-1c4b-4281-b951-d872f2087c98
* Fix openssl build to work with AllowSingleton changesjoth@chromium.org2010-11-191-3/+16
| | | | | | | | | BUG=61585 TEST=net & base unit tests; start & quit browser Review URL: http://codereview.chromium.org/5102006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66772 0039d316-1c4b-4281-b951-d872f2087c98
* Follow up comments on SymmetricKey::Import docsjoth@chromium.org2010-11-191-4/+4
| | | | | | | | | BUG=None TEST=None Review URL: http://codereview.chromium.org/5223001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66765 0039d316-1c4b-4281-b951-d872f2087c98
* Reland r65996. Disallows Singletons on non-joinable thread.willchan@chromium.org2010-11-198-41/+180
| | | | | | | | | | | Test breakages caused by this change have been fixed here or in other changelists. BUG=61753 TEST=none Review URL: http://codereview.chromium.org/5024003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66719 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-08 07:51:14 +0000