Skip to content
Snippets Groups Projects
  1. Oct 20, 2010
  2. Oct 14, 2010
  3. Aug 03, 2010
  4. Jul 30, 2010
  5. Jul 02, 2010
  6. Jun 07, 2010
  7. Mar 14, 2010
  8. Mar 09, 2010
  9. Dec 11, 2009
  10. 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
  11. Nov 09, 2009
  12. 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
  13. Oct 31, 2009
  14. Oct 15, 2009
  15. Oct 14, 2009
  16. Oct 11, 2009
  17. Oct 06, 2009
  18. 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
  19. Sep 10, 2009
  20. May 29, 2009
  21. May 28, 2009
  22. May 27, 2009
  23. Mar 12, 2009
  24. Mar 11, 2009
  25. Mar 05, 2009
  26. Dec 31, 2008
  27. Dec 30, 2008
  28. Dec 16, 2008
  29. Dec 04, 2008
  30. Nov 22, 2008
  31. 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
  32. 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
  33. Aug 24, 2008
  34. Aug 09, 2008
  35. Jul 27, 2008
Loading