Skip to content
Snippets Groups Projects
Select Git revision
10 results
Search by author
  • Any Author
  • Alexandros Frantzis alf
  • AngeloGioacchino Del Regno AngeloGioacchino Del Regno kholk11
  • Ariel D'Alessandro Ariel D'Alessandro adalessandro
  • Daniel Stone Daniel Stone daniels
  • Louis-Alexis Eyraud Louis-Alexis Eyraud laeyraud
  • Martyn Welch Martyn Welch martyn
  • Nícolas F. R. A. Prado Nícolas F. R. A. Prado nfraprado
  • Robert Mader Robert Mader rmader
  • Sjoerd Simons Sjoerd Simons sjoerd
  • Youko Omori youko
10 authors
  1. Oct 20, 2010
  3. Oct 14, 2010
  5. Aug 03, 2010
  7. Jul 30, 2010
  9. Jul 02, 2010
  11. Jun 07, 2010
  13. Mar 14, 2010
  15. Mar 09, 2010
  17. Dec 11, 2009
  19. Nov 25, 2009
    • jar@chromium.org's avatar
      Fix typo in recursion detection logic · 7ee2fe8a
      jar@chromium.org authored 
      When releasing the lock, I incorrectly set the thread owner for the lock
to the current thread, rather than resetting it to zero.  The result is that
some number of stacks were not being recorded into the stack map (because
the recursion blocking logic aborted the attempt to gather the lock).

If I ever do a recursive acquisition (i.e., my logic is faulty), then
an assertion will fire in the Acquire() for the lock.  This in turn
guarantees that when I Release() the lock, it was not a (windows
allowed) recursive acquisition of the lock, and hence the
thread owning the lock should indeed be zeroed.

r=mbelshe
Review URL: http://codereview.chromium.org/443009

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33140 0039d316-1c4b-4281-b951-d872f2087c98
      7ee2fe8a
  21. Nov 09, 2009
  23. Nov 06, 2009
    • jar@chromium.org's avatar
      Support running memory watch under vista, plus other tweaks · 0c685451
      jar@chromium.org authored 
      This version of memory_watcher can run under Vista, even though the
recursive calls that it handles are appearing often enough that there
is a performance penalty.  With this landed, it may be possible for other
folks to run the tool, and I can work on improving its performance.

This CL also resolves the problem with hanging processes.  Although
memory reporting can only be done once, and it leaves a pile of memory
"hanging around," the browser can be cleanly exited.

Tweaks include outputing the aggregate stacks such that the largest
stacks appear at the start of the output file.

This version avoids ongoing aggregation of stats in favor of only
doing the aggregation at dump-time.  This probably enhances performance
at run-time, although it is hidden (on Vista) by the recursive calling.
This also simplifies the tracking code a fair amount.

There is some evidence that a small number of duplicate calls are being
made to "track" the same memory region, without an intervening free (i.e.,
call to "untrack").  The code to better diagnose this is currently in
place, but ifdef'ed, as it is only useful under a debugger.  Exercise
of this code (turning a stack-frame list into a human readable stack
trace string) currently causes some corruption shortly after it triggers,
so I can't leave it on full time.


r=mbelshe
Review URL: http://codereview.chromium.org/366031

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31299 0039d316-1c4b-4281-b951-d872f2087c98
      0c685451
  25. Oct 31, 2009
  27. Oct 15, 2009
  29. Oct 14, 2009
  31. Oct 11, 2009
  33. Oct 06, 2009
  35. Sep 15, 2009
    • yaar@chromium.org's avatar
      Force inclusion of build/common.gypi for all chromium gyp files. · 21642abd
      yaar@chromium.org authored 
      Why: Simpler build code. If everybody includes it, it should be included automatically.
Why now: The webkit chromium builds need it be specified, since can't default to build/common.gypi.

What was done:
1. build/common.gypi's contents were moved to a new file build/gyp_chromium.gypi
2. tools/gyp/gyp_chromium was moved to build/gyp_chromium and made to automatically include build/gyp_chromium.gypi.
3. lots of gyp files were fixed to not refer to build/common.gypi any more.
4. o3d which also builds independently of chrome, was fixed to have a gyp_o3d that includes gyp_chromium.gypi too.
5. build/common.gypi was left empty, because there are some external projects that still refer to it.

Things that are left to do after this patch is in:
1. The following external files (in other repositories) need to stop include common.gypi
  ./third_party/hunspell/hunspell.gyp
  ./third_party/icu/icu.gyp
  ./v8/tools/gyp/v8.gyp
2. Once nobody refers to common.gypi anymore, delete common.gypi
   -or-
   Delete gyp_chromium.gypi and move its content back to common.gypi

Tested on mac, win and linux. On win, got a few unit tests errors on chrome bookmarks, which should not be related. I'm running again with clobber to verify.

Review URL: http://codereview.chromium.org/206006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26302 0039d316-1c4b-4281-b951-d872f2087c98
      21642abd
  37. Sep 10, 2009
  39. May 29, 2009
  41. May 28, 2009
  43. May 27, 2009
  45. Mar 12, 2009
  47. Mar 11, 2009
  49. Mar 05, 2009
  51. Dec 31, 2008
  53. Dec 30, 2008
  55. Dec 16, 2008
  57. Dec 04, 2008
  59. Nov 22, 2008
  61. Sep 25, 2008
    • maruel@google.com's avatar
      Wow, it's been a while since we cleaned EOL. · de8d2667
      maruel@google.com authored 
      Ran dos2unix on *.cc, *.h, *.py and SCons*.*
Ran for /R /D %a in (*.*) do @if exist %a\.svn\. svn pset svn:eol-style LF %a\*.cc
Ran for /R /D %a in (*.*) do @if exist %a\.svn\. svn pset svn:eol-style LF %a\*.h
Ran for /R /D %a in (*.*) do @if exist %a\.svn\. svn pset svn:eol-style LF %a\*.py
Ran for /R /D %a in (*.*) do @if exist %a\.svn\. svn pset svn:eol-style LF %a\SCons*.*



git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2611 0039d316-1c4b-4281-b951-d872f2087c98
      de8d2667
  63. Sep 14, 2008
    • maruel@google.com's avatar
      Provide necessary constructors in StackAllocator and PrivateHookAllocator to... · 1456372b
      maruel@google.com authored 
      Provide necessary constructors in StackAllocator and PrivateHookAllocator to permit release mode building in VC++2008 SP1. The current allocators do not conform with the C++ spec for allocators, and unlike previous versions, VC++2008 requires conformant allocators.

The reason that the allocators are not conformant is that any allocator, say, template<typename T> struct Alloc; must have a constructor of the following form:
template<typename U> Alloc(const Alloc<U>& other)
to allow construction of an Alloc<T> from an Alloc<U>.  The constructors cannot be explicit, because they're (essentially) copy constructors, and so are not called explicitly.

StackAllocator has no converting copy constructor at all, and PrivateHookAllocator's is declared explicit, preventing it from being usable.

Without the StackAllocator constructor, StackVectors fail (due to the std::vector member, base\stack_container.h(216)).

Patch by Peter Bright <drpizza@quiscalusmexicanus.org>.


git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2175 0039d316-1c4b-4281-b951-d872f2087c98
      1456372b
  65. Aug 24, 2008
  67. Aug 09, 2008
  69. Jul 27, 2008