Do not zero-initialize RawPtr.

Do not zero-initialize RawPtr.

RawPtr is a transition type that will be removed and replace with a
normal pointer. Normal pointers are not default initialized and therefore
RawPtr shouldn't be either. Instead, we introduce a zap value in debug
mode to make it easier to find uninitialized RawPtrs during the transition.

R=erik.corry@gmail.com, oilpan-reviews@chromium.org, tkent@chromium.org, zerny@chromium.org

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=169922

[Erik Corry, 2014-03-24 09:18:46]

lgtm

[tkent, 2014-03-24 09:27:05]

lgtm

https://codereview.chromium.org/209433004/diff/1/Source/wtf/RawPtr.h
File Source/wtf/RawPtr.h (right):

https://codereview.chromium.org/209433004/diff/1/Source/wtf/RawPtr.h#newcode124
Source/wtf/RawPtr.h:124: static const uintptr_t rawPtrZapValue = 0x3a3a3a3a;
nit: I prefer an odd number.

[wibling-chromium, 2014-03-24 09:36:21]

lgtm

[Mads Ager (chromium), 2014-03-24 10:09:14]

Thanks guys. Before I can land this I need to update quite a bit of code. The
problematic cases are things like:

{
    RefPtrWillBeRawPtr<A> a;
    // do stuff that might and might not set a.
    if (a)
        a->doStuff();
}

We will need to update these places for the end result anyway because this will
need an explicit initialization at the end.

I'll prepare a separate change list for these updates.

[zerny-chromium, 2014-03-24 10:12:38]

lgtm

[tkent, 2014-03-24 10:57:29]

can we remove this constructor?

[Mads Ager (chromium), 2014-03-24 11:07:42]

I think that will be hard. We will want RefPtrWillBeRawPtr in collections
which require a default constructor.


On Mon, Mar 24, 2014 at 11:57 AM, <tkent@chromium.org> wrote:

> can we remove this constructor?
>
>
> https://codereview.chromium.org/209433004/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[Mads Ager (chromium), 2014-03-24 11:09:13]

Those should be Members of course, so maybe it would be simpler to just
remove it to make sure that we never do it wrong. It will require
initialization of all RawPtrs in the system. Not sure if we want to require
that.


On Mon, Mar 24, 2014 at 12:07 PM, Mads Sig Ager <ager@chromium.org> wrote:

> I think that will be hard. We will want RefPtrWillBeRawPtr in collections
> which require a default constructor.
>
>
> On Mon, Mar 24, 2014 at 11:57 AM, <tkent@chromium.org> wrote:
>
>> can we remove this constructor?
>>
>>
>> https://codereview.chromium.org/209433004/
>>
>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[haraken, 2014-03-24 11:15:09]

> Those should be Members of course, so maybe it would be simpler to just
> remove it to make sure that we never do it wrong. It will require
> initialization of all RawPtrs in the system. Not sure if we want to require
> that.

What's a situation where we don't want to require initialization of RawPtrs?

[Mads Ager (chromium), 2014-03-24 11:20:34]

{
    A* a;
    if (condition)
        a = something;
    else
        a = somethingElse;
}

I would be happy to have the initialization here though. It might require a
bit of work to get there. I'll look into it. I also thing we have stuff
like:

RefPtrWillBeRawPtr<A> array[kSize];

at this point. That requires changing as well because array is then used
with the assumption that the values are 0.


On Mon, Mar 24, 2014 at 12:15 PM, <haraken@chromium.org> wrote:

> Those should be Members of course, so maybe it would be simpler to just
>> remove it to make sure that we never do it wrong. It will require
>> initialization of all RawPtrs in the system. Not sure if we want to
>> require
>> that.
>>
>
> What's a situation where we don't want to require initialization of
> RawPtrs?
>
>
> https://codereview.chromium.org/209433004/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[Mads Ager (chromium), 2014-03-24 11:23:27]

Bindings macros is another place that uses these.

type var;
{
   ExcpetionThingie scope;
   var = (value);
}



On Mon, Mar 24, 2014 at 12:20 PM, Mads Sig Ager <ager@chromium.org> wrote:

> {
>     A* a;
>     if (condition)
>         a = something;
>     else
>         a = somethingElse;
> }
>
> I would be happy to have the initialization here though. It might require
> a bit of work to get there. I'll look into it. I also thing we have stuff
> like:
>
> RefPtrWillBeRawPtr<A> array[kSize];
>
> at this point. That requires changing as well because array is then used
> with the assumption that the values are 0.
>
>
> On Mon, Mar 24, 2014 at 12:15 PM, <haraken@chromium.org> wrote:
>
>>  Those should be Members of course, so maybe it would be simpler to just
>>> remove it to make sure that we never do it wrong. It will require
>>> initialization of all RawPtrs in the system. Not sure if we want to
>>> require
>>> that.
>>>
>>
>> What's a situation where we don't want to require initialization of
>> RawPtrs?
>>
>>
>> https://codereview.chromium.org/209433004/
>>
>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[haraken, 2014-03-24 11:23:47]

On 2014/03/24 11:20:34, Mads Ager (chromium) wrote:
> {
>     A* a;
>     if (condition)
>         a = something;
>     else
>         a = somethingElse;
> }
> 
> I would be happy to have the initialization here though. It might require a
> bit of work to get there. I'll look into it.

Thanks, that sounds nicer!

[haraken, 2014-03-24 11:25:10]

> Bindings macros is another place that uses these.
> 
> type var;
> {
>    ExcpetionThingie scope;
>    var = (value);
> }

Yeah, but we just need to change it to 'type var = nullptr', right?

[haraken, 2014-03-24 11:26:16]

On 2014/03/24 11:25:10, haraken wrote:
> > Bindings macros is another place that uses these.
> > 
> > type var;
> > {
> >    ExcpetionThingie scope;
> >    var = (value);
> > }
> 
> Yeah, but we just need to change it to 'type var = nullptr', right?

My question is whether forcing the rule will bloat compile errors people don't
want to see or not.

[Mads Ager (chromium), 2014-03-24 11:32:39]

Let me keep digging. I'll let you know what I find. :)


On Mon, Mar 24, 2014 at 12:26 PM, <haraken@chromium.org> wrote:

> On 2014/03/24 11:25:10, haraken wrote:
>
>> > Bindings macros is another place that uses these.
>> >
>> > type var;
>> > {
>> >    ExcpetionThingie scope;
>> >    var = (value);
>> > }
>>
>
>  Yeah, but we just need to change it to 'type var = nullptr', right?
>>
>
> My question is whether forcing the rule will bloat compile errors people
> don't
> want to see or not.
>
>
> https://codereview.chromium.org/209433004/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[Mads Ager (chromium), 2014-03-24 13:40:21]

Updated all usages of RefPtrWillBeRawPtr.

I'm not getting rid of the default constructor in this patch set. The
V8_TRYCATCH_VOID macro is used with a lot of different types and introducing a
new macro and sorting through the usages can be done separately if we think it
is worth it.

[haraken, 2014-03-24 13:52:54]

I think you need to rebase with Ian's CL that changed RefPtrWillBeRawPtrs in
stack-allocated objects with RefPtrWillBeMembers :)

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSCalcu...
File Source/core/css/CSSCalculationValue.cpp (right):

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSCalcu...
Source/core/css/CSSCalculationValue.cpp:560: DISALLOW_ALLOCATION(); // Is only
ever stack allocated.

Can this be STACK_ALLOCATED() ?

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSCalcu...
Source/core/css/CSSCalculationValue.cpp:562:
RefPtrWillBeRawPtr<CSSCalcExpressionNode> value = nullptr;

Then this could be a RefPtrWillBeMember.

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSCompu...
File Source/core/css/CSSComputedStyleDeclaration.cpp (right):

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSCompu...
Source/core/css/CSSComputedStyleDeclaration.cpp:1199:
RefPtrWillBeRawPtr<CSSPrimitiveValue> spread = useSpread ?
zoomAdjustedPixelValue(shadow.spread(), style) :
PassRefPtrWillBeRawPtr<CSSPrimitiveValue>(nullptr);

PassRefPtrWillBeRawPtr<CSSPrimitiveValue>(nullptr) => nullptr ?

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSCompu...
Source/core/css/CSSComputedStyleDeclaration.cpp:1200:
RefPtrWillBeRawPtr<CSSPrimitiveValue> shadowStyle = shadow.style() == Normal ?
PassRefPtrWillBeRawPtr<CSSPrimitiveValue>(nullptr) :
cssValuePool().createIdentifierValue(CSSValueInset);

PassRefPtrWillBeRawPtr<CSSPrimitiveValue>(nullptr) => nullptr ?

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSPrimi...
File Source/core/css/CSSPrimitiveValue.cpp (right):

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSPrimi...
Source/core/css/CSSPrimitiveValue.cpp:406: 

Unnecessary edit.

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/parser/C...
File Source/core/css/parser/CSSPropertyParser.cpp (right):

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/parser/C...
Source/core/css/parser/CSSPropertyParser.cpp:5351:
RefPtrWillBeRawPtr<CSSPrimitiveValue> color = nullptr;

These could be RefPtrWillBeMembers, since the object is stack-allocated.

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/parser/C...
Source/core/css/parser/CSSPropertyParser.cpp:5662: RefPtrWillBeRawPtr<CSSValue>
m_repeat = nullptr;

Ditto.

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/parser/C...
Source/core/css/parser/CSSPropertyParser.cpp:5864:
RefPtrWillBeRawPtr<CSSPrimitiveValue> m_left = nullptr;

Ditto.

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/parser/C...
Source/core/css/parser/CSSPropertyParser.cpp:5981:
RefPtrWillBeRawPtr<CSSPrimitiveValue> m_left = nullptr;

Ditto.

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/parser/C...
File Source/core/css/parser/CSSPropertyParser.h (right):

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/parser/C...
Source/core/css/parser/CSSPropertyParser.h:385: RefPtrWillBeRawPtr<CSSCalcValue>
m_parsedCalculation = nullptr;

This object is stack-allocated. This could be a RefPtrWillBeMember.

https://codereview.chromium.org/209433004/diff/20001/Source/core/page/EventHa...
File Source/core/page/EventHandler.cpp (right):

https://codereview.chromium.org/209433004/diff/20001/Source/core/page/EventHa...
Source/core/page/EventHandler.cpp:3593: struct {

Won't this be stack-allocated as well?

https://codereview.chromium.org/209433004/diff/20001/Source/core/xml/XPathPar...
File Source/core/xml/XPathParser.h (right):

https://codereview.chromium.org/209433004/diff/20001/Source/core/xml/XPathPar...
Source/core/xml/XPathParser.h:68: DISALLOW_ALLOCATION();

This should be changed to STACK_ALLOCATED.

https://codereview.chromium.org/209433004/diff/20001/Source/core/xml/XPathPar...
Source/core/xml/XPathParser.h:125: RefPtrWillBeRawPtr<XPathNSResolver>
m_resolver = nullptr;

Then use RefPtrWillBeMember.

https://codereview.chromium.org/209433004/diff/20001/Source/modules/speech/Sp...
File Source/modules/speech/SpeechRecognitionEvent.h (right):

https://codereview.chromium.org/209433004/diff/20001/Source/modules/speech/Sp...
Source/modules/speech/SpeechRecognitionEvent.h:41: DISALLOW_ALLOCATION();

Remove this, since EventInit is already marked as STACK_ALLOCATED.

https://codereview.chromium.org/209433004/diff/20001/Source/modules/speech/Sp...
Source/modules/speech/SpeechRecognitionEvent.h:46:
RefPtrWillBeRawPtr<SpeechRecognitionResultList> results = nullptr;

RefPtrWillBeMember.

[zerny-chromium, 2014-03-24 14:07:51]

Ditto to Haraken's stack-allocated remarks and otherwise lgtm

[Mads Ager (chromium), 2014-03-24 14:27:30]

Thanks. I'll merge with Ian's changes. I updated this to not have the RawPtr
members in stack allocated objects. :)

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSCalcu...
File Source/core/css/CSSCalculationValue.cpp (right):

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSCalcu...
Source/core/css/CSSCalculationValue.cpp:560: DISALLOW_ALLOCATION(); // Is only
ever stack allocated.
On 2014/03/24 13:52:54, haraken wrote:
> 
> Can this be STACK_ALLOCATED() ?

If the comments are true both this and CSSCalcExpressionNodeParser can be stack
allocated. Thanks!

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSCalcu...
Source/core/css/CSSCalculationValue.cpp:562:
RefPtrWillBeRawPtr<CSSCalcExpressionNode> value = nullptr;
On 2014/03/24 13:52:54, haraken wrote:
> 
> Then this could be a RefPtrWillBeMember.

Done.

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSCompu...
File Source/core/css/CSSComputedStyleDeclaration.cpp (right):

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSCompu...
Source/core/css/CSSComputedStyleDeclaration.cpp:1199:
RefPtrWillBeRawPtr<CSSPrimitiveValue> spread = useSpread ?
zoomAdjustedPixelValue(shadow.spread(), style) :
PassRefPtrWillBeRawPtr<CSSPrimitiveValue>(nullptr);
On 2014/03/24 13:52:54, haraken wrote:
> 
> PassRefPtrWillBeRawPtr<CSSPrimitiveValue>(nullptr) => nullptr ?

Unfortunately, no. Both branches in a conditional must return the same type
(without conversions).

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSCompu...
Source/core/css/CSSComputedStyleDeclaration.cpp:1200:
RefPtrWillBeRawPtr<CSSPrimitiveValue> shadowStyle = shadow.style() == Normal ?
PassRefPtrWillBeRawPtr<CSSPrimitiveValue>(nullptr) :
cssValuePool().createIdentifierValue(CSSValueInset);
On 2014/03/24 13:52:54, haraken wrote:
> 
> PassRefPtrWillBeRawPtr<CSSPrimitiveValue>(nullptr) => nullptr ?

Ditto.

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSPrimi...
File Source/core/css/CSSPrimitiveValue.cpp (right):

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/CSSPrimi...
Source/core/css/CSSPrimitiveValue.cpp:406: 
On 2014/03/24 13:52:54, haraken wrote:
> 
> Unnecessary edit.

Removed.

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/parser/C...
File Source/core/css/parser/CSSPropertyParser.cpp (right):

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/parser/C...
Source/core/css/parser/CSSPropertyParser.cpp:5351:
RefPtrWillBeRawPtr<CSSPrimitiveValue> color = nullptr;
On 2014/03/24 13:52:54, haraken wrote:
> 
> These could be RefPtrWillBeMembers, since the object is stack-allocated.

Absolutely!

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/parser/C...
Source/core/css/parser/CSSPropertyParser.cpp:5662: RefPtrWillBeRawPtr<CSSValue>
m_repeat = nullptr;
On 2014/03/24 13:52:54, haraken wrote:
> 
> Ditto.

Yes, good catch. This is stack allocated as well.

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/parser/C...
Source/core/css/parser/CSSPropertyParser.cpp:5864:
RefPtrWillBeRawPtr<CSSPrimitiveValue> m_left = nullptr;
On 2014/03/24 13:52:54, haraken wrote:
> 
> Ditto.

Yes.

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/parser/C...
Source/core/css/parser/CSSPropertyParser.cpp:5981:
RefPtrWillBeRawPtr<CSSPrimitiveValue> m_left = nullptr;
On 2014/03/24 13:52:54, haraken wrote:
> 
> Ditto.

And yes. :)

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/parser/C...
File Source/core/css/parser/CSSPropertyParser.h (right):

https://codereview.chromium.org/209433004/diff/20001/Source/core/css/parser/C...
Source/core/css/parser/CSSPropertyParser.h:385: RefPtrWillBeRawPtr<CSSCalcValue>
m_parsedCalculation = nullptr;
On 2014/03/24 13:52:54, haraken wrote:
> 
> This object is stack-allocated. This could be a RefPtrWillBeMember.

Yes, thanks. Done and I will merge with Ian's change. :)

https://codereview.chromium.org/209433004/diff/20001/Source/core/page/EventHa...
File Source/core/page/EventHandler.cpp (right):

https://codereview.chromium.org/209433004/diff/20001/Source/core/page/EventHa...
Source/core/page/EventHandler.cpp:3593: struct {
On 2014/03/24 13:52:54, haraken wrote:
> 
> Won't this be stack-allocated as well?

Yes it will. I'm not sure what the plugin will say about this one, but using a
Member here and marking it STACK_ALLOCATED should be fine. Done.

https://codereview.chromium.org/209433004/diff/20001/Source/core/xml/XPathPar...
File Source/core/xml/XPathParser.h (right):

https://codereview.chromium.org/209433004/diff/20001/Source/core/xml/XPathPar...
Source/core/xml/XPathParser.h:68: DISALLOW_ALLOCATION();
On 2014/03/24 13:52:54, haraken wrote:
> 
> This should be changed to STACK_ALLOCATED.

Done.

https://codereview.chromium.org/209433004/diff/20001/Source/core/xml/XPathPar...
Source/core/xml/XPathParser.h:125: RefPtrWillBeRawPtr<XPathNSResolver>
m_resolver = nullptr;
On 2014/03/24 13:52:54, haraken wrote:
> 
> Then use RefPtrWillBeMember.

Yes, doen.

https://codereview.chromium.org/209433004/diff/20001/Source/modules/speech/Sp...
File Source/modules/speech/SpeechRecognitionEvent.h (right):

https://codereview.chromium.org/209433004/diff/20001/Source/modules/speech/Sp...
Source/modules/speech/SpeechRecognitionEvent.h:41: DISALLOW_ALLOCATION();
On 2014/03/24 13:52:54, haraken wrote:
> 
> Remove this, since EventInit is already marked as STACK_ALLOCATED.

Done.

https://codereview.chromium.org/209433004/diff/20001/Source/modules/speech/Sp...
Source/modules/speech/SpeechRecognitionEvent.h:46:
RefPtrWillBeRawPtr<SpeechRecognitionResultList> results = nullptr;
On 2014/03/24 13:52:54, haraken wrote:
> 
> RefPtrWillBeMember.

Done.

[Mads Ager (chromium), 2014-03-24 14:35:45]

And rebased on top of Ian's changes. PTAL

[haraken, 2014-03-24 14:39:06]

LGTM

https://codereview.chromium.org/209433004/diff/40001/Source/core/css/parser/C...
File Source/core/css/parser/CSSPropertyParser.cpp (right):

https://codereview.chromium.org/209433004/diff/40001/Source/core/css/parser/C...
Source/core/css/parser/CSSPropertyParser.cpp:5351:
RefPtrWillBeRawPtr<CSSPrimitiveValue> color = nullptr;

These should be RefPtrWillBeMembers.

[zerny-chromium, 2014-03-24 14:41:41]

lgtm

https://codereview.chromium.org/209433004/diff/40001/Source/core/css/parser/C...
File Source/core/css/parser/CSSPropertyParser.cpp (right):

https://codereview.chromium.org/209433004/diff/40001/Source/core/css/parser/C...
Source/core/css/parser/CSSPropertyParser.cpp:5351:
RefPtrWillBeRawPtr<CSSPrimitiveValue> color = nullptr;
On 2014/03/24 14:39:06, haraken wrote:
> 
> These should be RefPtrWillBeMembers.

QQ: where these not caught by the current plugin ToT?

[Mads Ager (chromium), 2014-03-24 14:43:16]

https://codereview.chromium.org/209433004/diff/40001/Source/core/css/parser/C...
File Source/core/css/parser/CSSPropertyParser.cpp (right):

https://codereview.chromium.org/209433004/diff/40001/Source/core/css/parser/C...
Source/core/css/parser/CSSPropertyParser.cpp:5351:
RefPtrWillBeRawPtr<CSSPrimitiveValue> color = nullptr;
On 2014/03/24 14:41:41, zerny-chromium wrote:
> On 2014/03/24 14:39:06, haraken wrote:
> > 
> > These should be RefPtrWillBeMembers.
> 
> QQ: where these not caught by the current plugin ToT?

Look at the rebased version. They are Members now. :)

[zerny-chromium, 2014-03-24 14:45:06]

https://codereview.chromium.org/209433004/diff/40001/Source/core/css/parser/C...
File Source/core/css/parser/CSSPropertyParser.cpp (right):

https://codereview.chromium.org/209433004/diff/40001/Source/core/css/parser/C...
Source/core/css/parser/CSSPropertyParser.cpp:5351:
RefPtrWillBeRawPtr<CSSPrimitiveValue> color = nullptr;
On 2014/03/24 14:43:16, Mads Ager (chromium) wrote:
> On 2014/03/24 14:41:41, zerny-chromium wrote:
> > On 2014/03/24 14:39:06, haraken wrote:
> > > 
> > > These should be RefPtrWillBeMembers.
> > 
> > QQ: where these not caught by the current plugin ToT?
> 
> Look at the rebased version. They are Members now. :)

Ah, good. I did my review on that and incorrectly assumed Haraken's comment was
on that too. Sorry for the noise :-)

[wibling-chromium, 2014-03-24 15:35:45]

lgtm

[Mads Ager (chromium), 2014-03-25 07:08:37]

The CQ bit was checked by ager@chromium.org

[commit-bot: I haz the power, 2014-03-25 07:08:47]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ager@chromium.org/209433004/60001

[commit-bot: I haz the power, 2014-03-25 07:11:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-25 07:11:07]

Try jobs failed on following builders:
  tryserver.blink on win_blink_compile_dbg

[Mads Ager (chromium), 2014-03-25 07:17:39]

The CQ bit was checked by ager@chromium.org

[commit-bot: I haz the power, 2014-03-25 07:17:46]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ager@chromium.org/209433004/60001

[commit-bot: I haz the power, 2014-03-25 07:20:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-25 07:20:20]

Try jobs failed on following builders:
  tryserver.blink on linux_blink_rel

[Mads Ager (chromium), 2014-03-25 07:39:40]

The CQ bit was checked by ager@chromium.org

[commit-bot: I haz the power, 2014-03-25 07:39:58]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ager@chromium.org/209433004/70001

[commit-bot: I haz the power, 2014-03-25 07:41:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-25 07:41:30]

Try jobs failed on following builders:
  tryserver.blink on mac_blink_rel

[Mads Ager (chromium), 2014-03-25 07:42:59]

The CQ bit was checked by ager@chromium.org

[commit-bot: I haz the power, 2014-03-25 07:43:05]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ager@chromium.org/209433004/70001

[commit-bot: I haz the power, 2014-03-25 08:46:08]

Change committed as 169922