GitLab

[Re-land of Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107921
with supressions for induced (and planned) leaks) 
PLUS
Removed one line of defensive coding where I set(NULL)
the TLS slote at thread teardown. We're seeing
strange failures on the base unittests, and they
may be related to this.
]

Be extra carful about handling races in access to status_.
This will avoid generating a delta between a null time
and a real time, when status is changing in/around
the run of a task. This won't help with the benign
race for checking status_, but it may help with unit
test tsan complaints.

Leak data aggressively, rather than cleaning up, to
prevent any chance of a data access race between
tracked object testing (which need a near-virgin
global state, and hence must start by cleaning it up), and
other tests, which may have lingering threaded actions, 
that still access some previously created task tracking
data.

Provide more options for flags to enable/disable
tracking. These options might become useful
if we changed the default to not do tracking.

Allow for HTML generation even if the tracking has
changed to being disabled. This is especially useful
for looking at the tracked instances that were
monitored after turning tracking on by default, but
before the command line deactiated tracking.

tbr=rtenneti
bug=102327
Review URL: http://codereview.chromium.org/8425010

TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/8430003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107960 0039d316-1c4b-4281-b951-d872f2087c98

Repair busted tree.

TBR=rtenneti
Review URL: http://codereview.chromium.org/8425013

TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/8430002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107959 0039d316-1c4b-4281-b951-d872f2087c98

Mac base_unittests is still flaky....

Pthread is still sometimes crashing Mac on shutdown.

I'm suspicious that my handlers are tickling it.
This removes a DCHECK(), which checked status in
TLS during the teardown.

TBR=rtenneti
Review URL: http://codereview.chromium.org/8424013

TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/8431003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107958 0039d316-1c4b-4281-b951-d872f2087c98

This browser test tickles the webkit bug described in crbug.com/75604 .
The bug is very hard to repliably reproduce in a layout test, so my plan is
to land this browser_test, update webkit to fix the bug, and update this
test as we garden past the fix.

BUG=75604

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

TBR=gavinp@chromium.org
Review URL: http://codereview.chromium.org/8427003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107957 0039d316-1c4b-4281-b951-d872f2087c98

X.509 serial numbers should be a positive numbers according to the spec.
However, certificates have been issued with negative serial numbers. Negative
serial numbers are indicated with a most-significant bit of one. Positive
numbers which would have a MSB of 1 have a zero byte prepended to avoid the
ambiguity.

Previously we removing leading zero bytes because we were only matching against
a blacklist of serial numbers, none of which were negative.

This change moves the handling of serial numbers to the place where they are
used, rather than where they are parsed.

BUG=none
TEST=none


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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107956 0039d316-1c4b-4281-b951-d872f2087c98

BUG=95573
TEST=no change

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107954 0039d316-1c4b-4281-b951-d872f2087c98

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107952 0039d316-1c4b-4281-b951-d872f2087c98

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107951 0039d316-1c4b-4281-b951-d872f2087c98

BUG=none
TEST=manual: ./build/gyp_chromium with GYP_GENERATOR=ninja shouldn't complain about invalid type 'settings'.


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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107950 0039d316-1c4b-4281-b951-d872f2087c98

This browser test tickles the webkit bug described in crbug.com/75604 .
The bug is very hard to repliably reproduce in a layout test, so my plan is
to land this browser_test, update webkit to fix the bug, and update this
test as we garden past the fix.

BUG=75604

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107949 0039d316-1c4b-4281-b951-d872f2087c98

The framework's grown to the point that 32-bit dump_syms no longer has enough
memory to do its job. It is failing with messages like:

dump_syms(12345) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
dump_syms(12345) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
dump_syms(12345) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
terminate called after throwing an instance of 'St9bad_alloc'
  what():  std::bad_alloc

Moving to 64-bit gives it more space to work with. 64-bit dump_syms is able to
dump 32-bit files.

BUG=102361
TEST=Breakpad-enabled official release builds
Review URL: http://codereview.chromium.org/8409009

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107947 0039d316-1c4b-4281-b951-d872f2087c98

BUG=101718
TEST=

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107946 0039d316-1c4b-4281-b951-d872f2087c98

Note: This was a TODO for aa@.

R=sky@chromium.org

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107945 0039d316-1c4b-4281-b951-d872f2087c98

Mac base_unittests is still flaky....

Pthread is still sometimes crashing Mac on shutdown.

I'm suspicious that my handlers are tickling it.
This removes a DCHECK(), which checked status in
TLS during the teardown.

TBR=rtenneti
Review URL: http://codereview.chromium.org/8424013

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107944 0039d316-1c4b-4281-b951-d872f2087c98

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107943 0039d316-1c4b-4281-b951-d872f2087c98

I may be able to do better... but I wanted to  get
the tree greened up.

TBR=rtenneti
Review URL: http://codereview.chromium.org/8426006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107942 0039d316-1c4b-4281-b951-d872f2087c98

TBR=foo
Review URL: http://codereview.chromium.org/8424011

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107941 0039d316-1c4b-4281-b951-d872f2087c98

Repair busted tree.

TBR=rtenneti
Review URL: http://codereview.chromium.org/8425013

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107940 0039d316-1c4b-4281-b951-d872f2087c98

[Re-land of Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107921
with supressions for induced (and planned) leaks) 
PLUS
Removed one line of defensive coding where I set(NULL)
the TLS slote at thread teardown. We're seeing
strange failures on the base unittests, and they
may be related to this.
]

Be extra carful about handling races in access to status_.
This will avoid generating a delta between a null time
and a real time, when status is changing in/around
the run of a task. This won't help with the benign
race for checking status_, but it may help with unit
test tsan complaints.

Leak data aggressively, rather than cleaning up, to
prevent any chance of a data access race between
tracked object testing (which need a near-virgin
global state, and hence must start by cleaning it up), and
other tests, which may have lingering threaded actions, 
that still access some previously created task tracking
data.

Provide more options for flags to enable/disable
tracking. These options might become useful
if we changed the default to not do tracking.

Allow for HTML generation even if the tracking has
changed to being disabled. This is especially useful
for looking at the tracked instances that were
monitored after turning tracking on by default, but
before the command line deactiated tracking.

tbr=rtenneti
bug=102327
Review URL: http://codereview.chromium.org/8425010

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107939 0039d316-1c4b-4281-b951-d872f2087c98

Sorry, I forgot disabling SSLClientSocketTest.ConnectClientAuthCertRequested in my previous changes. (When I logged into the bot and run SSLClientSocketTest there, all other tests finished without crashes.)

TBR=stuartmorgan
BUT=102330
TEST=make the "Windows Tests (tsan)" bot green.
Review URL: http://codereview.chromium.org/8414056

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107937 0039d316-1c4b-4281-b951-d872f2087c98

TEST=Removes a DCHECK that we would hit on machines without a mic.
BUG=none
Review URL: http://codereview.chromium.org/8335005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107936 0039d316-1c4b-4281-b951-d872f2087c98

BUG=101718
TEST=manual


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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107935 0039d316-1c4b-4281-b951-d872f2087c98

BUG=45605
TEST=Tested it with Google Japanese Input method on Win7


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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107934 0039d316-1c4b-4281-b951-d872f2087c98

BUG=none
TEST=none
Review URL: http://codereview.chromium.org/8341107

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107933 0039d316-1c4b-4281-b951-d872f2087c98

This change suppresses an OOB read (which may be caused by the lack of symbols as written in <http://crbug.com/44341#c24>) and disables another SSLClientSocketTest on the "Windows Tests (tsan)" bot.

TBR=stuartmorgan
BUG=44341,102330
TEST=make the memory bots greener.
Review URL: http://codereview.chromium.org/8424009

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107932 0039d316-1c4b-4281-b951-d872f2087c98

[Re-land of Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107921
with supressions for induced (and planned) leaks) ]

Be extra carful about handling races in access to status_.
This will avoid generating a delta between a null time
and a real time, when status is changing in/around
the run of a task. This won't help with the benign
race for checking status_, but it may help with unit
test tsan complaints.

Leak data aggressively, rather than cleaning up, to
prevent any chance of a data access race between
tracked object testing (which need a near-virgin
global state, and hence must start by cleaning it up), and
other tests, which may have lingering threaded actions, 
that still access some previously created task tracking
data.

Provide more options for flags to enable/disable
tracking. These options might become useful
if we changed the default to not do tracking.

Allow for HTML generation even if the tracking has
changed to being disabled. This is especially useful
for looking at the tracked instances that were
monitored after turning tracking on by default, but
before the command line deactiated tracking.

tbr=rtenneti
bug=102327
Review URL: http://codereview.chromium.org/8414053

TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/8422004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107931 0039d316-1c4b-4281-b951-d872f2087c98

[Re-land of Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107921
with supressions for induced (and planned) leaks) ]

Be extra carful about handling races in access to status_.
This will avoid generating a delta between a null time
and a real time, when status is changing in/around
the run of a task. This won't help with the benign
race for checking status_, but it may help with unit
test tsan complaints.

Leak data aggressively, rather than cleaning up, to
prevent any chance of a data access race between
tracked object testing (which need a near-virgin
global state, and hence must start by cleaning it up), and
other tests, which may have lingering threaded actions, 
that still access some previously created task tracking
data.

Provide more options for flags to enable/disable
tracking. These options might become useful
if we changed the default to not do tracking.

Allow for HTML generation even if the tracking has
changed to being disabled. This is especially useful
for looking at the tracked instances that were
monitored after turning tracking on by default, but
before the command line deactiated tracking.

tbr=rtenneti
bug=102327
Review URL: http://codereview.chromium.org/8414053

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107928 0039d316-1c4b-4281-b951-d872f2087c98

BUG=102023

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107927 0039d316-1c4b-4281-b951-d872f2087c98

This refactors and improves a bunch of views accessibility
code on Windows and has the result of enabling NVDA to
announce the text selection in the omnibox.

The AutocompleteAccessibility class is removed; its
functionality is rolled into NativeViewAccessibilityWin.

NativeViewAccessibilityWin adds IAccessible2 and
IAccessibleText interfaces, allowing it to directly expose
the caret and selection to compatible assistive technology.
In addition, this gives each accessible object an unique id.

Finally, the reference from a View to its
NativeViewAccessibilityWin is changed from a scoped_refptr
to a ScopedComPtr, because another process may still have a
reference to the accessible COM object when the View is
deleted.

BUG=53380
TEST=Manually test the omnibox with NVDA on Windows. It should announce text that's selected, including autocompletions.
Review URL: http://codereview.chromium.org/8391010

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107924 0039d316-1c4b-4281-b951-d872f2087c98

This change just disables the SSLClientSocketTest.ConnectExpired, which has been failing somehow since Build 102330.

TBR=timurrrr,glider,thestig
BUG=102330
TEST=make the "Windows Tests (tsan)" bot green.
Review URL: http://codereview.chromium.org/8422003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107923 0039d316-1c4b-4281-b951-d872f2087c98

[Being extra conservative an leaking tracking data got
the base_unittest heap_checkers too excited. I need 
a supresion to match what we already have in the 
browser runs to calm them... so I'll revert for now.]

Be extra carful about handling races in access to status_.
This will avoid generating a delta between a null time
and a real time, when status is changing in/around
the run of a task.  This won't help with the benign
race for checking status_, but it may help with unit
test tsan complaints.

Leak data aggressively, rather than cleaning up, to
prevent any chance of a data access race between
tracked object testing (which need a near-virgin
global state, and hence must start by cleaning it up), and
other tests, which may have lingering threaded actions, 
that still access some previously created task tracking
data.

Provide more options for flags to enable/disable
tracking.  These options might become useful
if we changed the default to not do tracking.

Allow for HTML generation even if the tracking has
changed to being disabled.  This is especially useful
for looking at the tracked instances that were
monitored after turning tracking on by default, but
before the command line deactiated tracking.

r=rtenneti
bug=102327
Review URL: http://codereview.chromium.org/8414050

TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/8414051

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107922 0039d316-1c4b-4281-b951-d872f2087c98

Be extra carful about handling races in access to status_.
This will avoid generating a delta between a null time
and a real time, when status is changing in/around
the run of a task.  This won't help with the benign
race for checking status_, but it may help with unit
test tsan complaints.

Leak data aggressively, rather than cleaning up, to
prevent any chance of a data access race between
tracked object testing (which need a near-virgin
global state, and hence must start by cleaning it up), and
other tests, which may have lingering threaded actions, 
that still access some previously created task tracking
data.

Provide more options for flags to enable/disable
tracking.  These options might become useful
if we changed the default to not do tracking.

Allow for HTML generation even if the tracking has
changed to being disabled.  This is especially useful
for looking at the tracked instances that were
monitored after turning tracking on by default, but
before the command line deactiated tracking.

r=rtenneti
bug=102327
Review URL: http://codereview.chromium.org/8414050

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107921 0039d316-1c4b-4281-b951-d872f2087c98

This change suppresses a memory error and TSAN races started since r107895 <http://crrev.com/107895>.

TBR=timurrrr,glider,thestig
BUG=102327
TEST=make the valgrind bots greener.
Review URL: http://codereview.chromium.org/8425003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107918 0039d316-1c4b-4281-b951-d872f2087c98

doing official Chrome builds.

TBR=1aforge
Review URL: http://codereview.chromium.org/8424004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107910 0039d316-1c4b-4281-b951-d872f2087c98

BUG=100898
R=pkasting@chromium.org

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107907 0039d316-1c4b-4281-b951-d872f2087c98

This is needed for the <keygen> regression test to work

The webkit bug (and associated discussion) is here:
https://bugs.webkit.org/show_bug.cgi?id=70617

BUG=chromium-os:21905
TEST=regression test now works without additional changes to appendForm()

Change-Id: I0fffb6a885a75ac7a0acecce06034d8cdeab6832


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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107906 0039d316-1c4b-4281-b951-d872f2087c98

Options: Fix to enable Edit button only when the current profile is selected. Prevents a profile from editing the avatar and profile name of another profile in the Personal Options page. These changes got overwritten due to revision 107894. Bringing them back.


BUG=87658
TEST=NONE


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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107901 0039d316-1c4b-4281-b951-d872f2087c98

BUG=none
TEST=none

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

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107900 0039d316-1c4b-4281-b951-d872f2087c98

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107897 0039d316-1c4b-4281-b951-d872f2087c98

This is a re-land of:
http://codereview.chromium.org/8391019/
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107793

Original landing had trouble with message_loop_x.h, due to header
include ordering.  I pulled out the structure that was really needed by
tracked_objects.h into a new file tracked_info.*.  This allows tracked_objects
to inlude this tracked_info, but not have to include the message_loop.h
totality.  I also removed a DCHECK that that was triggering on a test,
and added yet one more file (browser_main.cc) where I removed a #ifdef
for TRACKING_ALL_OBJECTS.  The changes were minor, and I'm hoping to get
clear perf runs with tihs landing, so I'm going to TBR it and reland
early in the morning.



Comments from original landing:

Support is now controlled by the flag:
--enable-tracking
and the default is always on. To turn it off, use:
--enable-tracking=0

All profiler code is compiled now in release and official
builds (in addition to debug, where it was already active),
but most entry points can be disabled (turned into no-ops) 
by a single const bool setting atop tracked_objects.cc (in 
case folks want to revert the perf-impact of this change).

Transition to faster Now() service on Windows for the 
profiler use only.
The TimeTicks::Now() function on Window uses locking
to get a 64 bit time value. This CL transitions 
times used for profiling to more directly use a
32 bit Time interface, which is actually what drives the
64 bit TimeTicks. By using the smaller value, we avoid 
the need for locks, or even atomic operations for the most
part in the tracking system. On linux, we just down-sample
the standard TimeTicks to 32 bits for consistency (clean
ability to snapshot asyncronously without atomics...
but I should verify that such is helpful to performance).

I've also put in yet more cleanup and refactoring.

tbr=rtenneti
bug=101856
Review URL: http://codereview.chromium.org/8414036

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107895 0039d316-1c4b-4281-b951-d872f2087c98