Re: [v8-users] Re: Disabling All Of The Optimizations

[Jochen Eisinger]

sorry, no idea.

On Mon, Sep 26, 2016 at 9:01 AM PhistucK  wrote:

> Yes, but I could not provide a reproduction case. :(
> At least not without approvals from managers, I guess.
>
> Do you happen to know when the next stable patch release is planned (that
> includes the change)? I had to instruct the test teams to use
> --js-flags="--no-crankshaft" for now, which is not ideal...
>
>
> ☆*PhistucK*
>
> On Mon, Sep 26, 2016 at 9:42 AM, Jochen Eisinger 
> wrote:
>
> Thanks for tracking this down. In general, if you're willing / able to
> provide a repro case, we're happy to investigate suchs bugs ourselves, so
> you don't have to go through the trouble of bisecting this..
>
> On Sun, Sep 25, 2016 at 6:06 PM PhistucK  wrote:
>
> After bisecting, the bug started at -
> https://chromium.googlesource.com/v8/v8/+log/c93d868f..d83c3f0e
> The bug stopped at -
> https://chromium.googlesource.com/v8/v8/+log/f9a47d47..a255aa83
>
> This leaves me with
> https://chromium.googlesource.com/v8/v8/+/4dab7b5a1d6722002d47d0be2481cb65602a2451,
> which resolves a for-in optimization (Turbofan) bug
>  and
> already merged to the 5.3 branch (but is not released to stable yet :().
>
> Though, I wonder, why did it not always occur? jQuery.isPlainObject is a
> very hot function (at least in the code with which I am dealing here). Is
> it possible that it is not always optimized?
> (Also, that weird foo.hasOwnProperty(bar) === true versus 
> Object.keys(foo).indexOf(bar)
> === -1 contradiction...)
>
> Hopefully, another stable patch will be released soon, as it may affect
> many jQuery versions, since that was the way to check whether an object is
> a plain object until some time ago.
>
> I apologize to everyone, as I experienced the bug when it started but
> dismissed it as a temporary canary issue that would resolve itself. Stupid
> me. I hope I learned my lesson (probably not, though :( - I would have
> reported it if it did not require days of investigations).
>
>
> ☆*PhistucK*
>
> On Sat, Sep 24, 2016 at 1:45 PM, PhistucK  wrote:
>
> Thank you! Unfortunately, for everyone, it is getting clearer and clearer
> that this is an optimization issue. The issue does not reproduce with the
> --no-crankshaft flag.
>
> The code is calling something like -
> jQuery.extend(/* deepCopy */ true, {string: 'something'}, {string,
> 'something', instance: someConstructedInstance})
> (Where someConstructedInstance is a an instance of an object based on an
> enhanced Backbone View Model, so it is not a plain object)
> And sometimes (it used to occasionally appear, it now appears most often
> than not), jQuery.isPlainObject returns true for the value of instance.
> That jQuery function finishes with the following statements
> 
>  -
> var key;
> for ( key in obj ) {}
>
> return key === undefined || core_hasOwn.call( obj, key );
> From my debugging, it sometimes fails the key === undefined
> 
> check (if I add more logging code, it returns true - that does not make
> sense) and it sometimes fails the core_hasOwn.call( obj, key )
> 
> check (which returns true for a key that is not an own property). When
> this happen, Object.keys(obj).indexOf(key) returns -1. I verified that
> the key is indeed not an own property.
> (I am using jQuery 1.9.1 and cannot update it, but the code has basically
> gone through simplification, not real bug fixes)
>
> I think it may have started since Chrome 52, I am not sure. It evidently
> possibly became much, much worse in Chrome 53 (Windows 7, Intel Core i5, 32
> bit).
>
> I should report it, but I cannot disclose the code (it is a
> several-megabyte package that includes - and uses in that stack - several
> libraries like Knockout, Backbone, Underscore and more). Can someone
> suggest how I can diagnose and debug this further (without a native code
> debugger) in order to help you understand the exact issue (without showing
> code :()?
>
>
> ☆*PhistucK*
> On Tuesday, September 20, 2016 at 3:54:19 PM UTC+3, Michael Hablich wrote:
>
> --no-crankshaft should do the trick. The name is misleading, it will also
> disable TurboFan.
>
>
> On Tuesday, September 20, 2016 at 1:51:51 PM UTC+2, PhistucK wrote:
>
> I have an issue where the code suddenly (since Chrome 53) gets caught up
> in a cyclic recursion until it exceeds the stack size limit.
>
> Since the code is the same, I want to try and rule out engine optimization
> issues. Is there a V8 flag for disabling all of the optimizations?
>
>
> ☆*PhistucK*
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> 

Re: [v8-users] Re: Disabling All Of The Optimizations

[PhistucK]

Yes, but I could not provide a reproduction case. :(
At least not without approvals from managers, I guess.

Do you happen to know when the next stable patch release is planned (that
includes the change)? I had to instruct the test teams to use
--js-flags="--no-crankshaft" for now, which is not ideal...


☆*PhistucK*

On Mon, Sep 26, 2016 at 9:42 AM, Jochen Eisinger 
wrote:

> Thanks for tracking this down. In general, if you're willing / able to
> provide a repro case, we're happy to investigate suchs bugs ourselves, so
> you don't have to go through the trouble of bisecting this..
>
> On Sun, Sep 25, 2016 at 6:06 PM PhistucK  wrote:
>
>> After bisecting, the bug started at -
>> https://chromium.googlesource.com/v8/v8/+log/c93d868f..d83c3f0e
>> The bug stopped at -
>> https://chromium.googlesource.com/v8/v8/+log/f9a47d47..a255aa83
>>
>> This leaves me with https://chromium.googlesource.com/v8/v8/+/
>> 4dab7b5a1d6722002d47d0be2481cb65602a2451, which resolves a for-in
>> optimization (Turbofan) bug
>>  and
>> already merged to the 5.3 branch (but is not released to stable yet :().
>>
>> Though, I wonder, why did it not always occur? jQuery.isPlainObject is a
>> very hot function (at least in the code with which I am dealing here). Is
>> it possible that it is not always optimized?
>> (Also, that weird foo.hasOwnProperty(bar) === true versus 
>> Object.keys(foo).indexOf(bar)
>> === -1 contradiction...)
>>
>> Hopefully, another stable patch will be released soon, as it may affect
>> many jQuery versions, since that was the way to check whether an object is
>> a plain object until some time ago.
>>
>> I apologize to everyone, as I experienced the bug when it started but
>> dismissed it as a temporary canary issue that would resolve itself. Stupid
>> me. I hope I learned my lesson (probably not, though :( - I would have
>> reported it if it did not require days of investigations).
>>
>>
>> ☆*PhistucK*
>>
>> On Sat, Sep 24, 2016 at 1:45 PM, PhistucK  wrote:
>>
>>> Thank you! Unfortunately, for everyone, it is getting clearer and
>>> clearer that this is an optimization issue. The issue does not reproduce
>>> with the --no-crankshaft flag.
>>>
>>> The code is calling something like -
>>> jQuery.extend(/* deepCopy */ true, {string: 'something'}, {string,
>>> 'something', instance: someConstructedInstance})
>>> (Where someConstructedInstance is a an instance of an object based on an
>>> enhanced Backbone View Model, so it is not a plain object)
>>> And sometimes (it used to occasionally appear, it now appears most often
>>> than not), jQuery.isPlainObject returns true for the value of instance.
>>> That jQuery function finishes with the following statements
>>> 
>>>  -
>>> var key;
>>> for ( key in obj ) {}
>>>
>>> return key === undefined || core_hasOwn.call( obj, key );
>>> From my debugging, it sometimes fails the key === undefined
>>> 
>>> check (if I add more logging code, it returns true - that does not make
>>> sense) and it sometimes fails the core_hasOwn.call( obj, key )
>>> 
>>> check (which returns true for a key that is not an own property). When
>>> this happen, Object.keys(obj).indexOf(key) returns -1. I verified that
>>> the key is indeed not an own property.
>>> (I am using jQuery 1.9.1 and cannot update it, but the code has
>>> basically gone through simplification, not real bug fixes)
>>>
>>> I think it may have started since Chrome 52, I am not sure. It evidently
>>> possibly became much, much worse in Chrome 53 (Windows 7, Intel Core i5, 32
>>> bit).
>>>
>>> I should report it, but I cannot disclose the code (it is a
>>> several-megabyte package that includes - and uses in that stack - several
>>> libraries like Knockout, Backbone, Underscore and more). Can someone
>>> suggest how I can diagnose and debug this further (without a native code
>>> debugger) in order to help you understand the exact issue (without showing
>>> code :()?
>>>
>>>
>>> ☆*PhistucK*
>>> On Tuesday, September 20, 2016 at 3:54:19 PM UTC+3, Michael Hablich
>>> wrote:
>>>
 --no-crankshaft should do the trick. The name is misleading, it will
 also disable TurboFan.


 On Tuesday, September 20, 2016 at 1:51:51 PM UTC+2, PhistucK wrote:
>
> I have an issue where the code suddenly (since Chrome 53) gets caught
> up in a cyclic recursion until it exceeds the stack size limit.
>
> Since the code is the same, I want to try and rule out engine
> optimization issues. Is there a V8 flag for disabling all of the
> optimizations?
>
>
> ☆*PhistucK*
>
 --
>>> --

Re: [v8-users] Re: Disabling All Of The Optimizations

[Jochen Eisinger]

Thanks for tracking this down. In general, if you're willing / able to
provide a repro case, we're happy to investigate suchs bugs ourselves, so
you don't have to go through the trouble of bisecting this..

On Sun, Sep 25, 2016 at 6:06 PM PhistucK  wrote:

> After bisecting, the bug started at -
> https://chromium.googlesource.com/v8/v8/+log/c93d868f..d83c3f0e
> The bug stopped at -
> https://chromium.googlesource.com/v8/v8/+log/f9a47d47..a255aa83
>
> This leaves me with
> https://chromium.googlesource.com/v8/v8/+/4dab7b5a1d6722002d47d0be2481cb65602a2451,
> which resolves a for-in optimization (Turbofan) bug
>  and
> already merged to the 5.3 branch (but is not released to stable yet :().
>
> Though, I wonder, why did it not always occur? jQuery.isPlainObject is a
> very hot function (at least in the code with which I am dealing here). Is
> it possible that it is not always optimized?
> (Also, that weird foo.hasOwnProperty(bar) === true versus 
> Object.keys(foo).indexOf(bar)
> === -1 contradiction...)
>
> Hopefully, another stable patch will be released soon, as it may affect
> many jQuery versions, since that was the way to check whether an object is
> a plain object until some time ago.
>
> I apologize to everyone, as I experienced the bug when it started but
> dismissed it as a temporary canary issue that would resolve itself. Stupid
> me. I hope I learned my lesson (probably not, though :( - I would have
> reported it if it did not require days of investigations).
>
>
> ☆*PhistucK*
>
> On Sat, Sep 24, 2016 at 1:45 PM, PhistucK  wrote:
>
> Thank you! Unfortunately, for everyone, it is getting clearer and clearer
> that this is an optimization issue. The issue does not reproduce with the
> --no-crankshaft flag.
>
> The code is calling something like -
> jQuery.extend(/* deepCopy */ true, {string: 'something'}, {string,
> 'something', instance: someConstructedInstance})
> (Where someConstructedInstance is a an instance of an object based on an
> enhanced Backbone View Model, so it is not a plain object)
> And sometimes (it used to occasionally appear, it now appears most often
> than not), jQuery.isPlainObject returns true for the value of instance.
> That jQuery function finishes with the following statements
> 
>  -
> var key;
> for ( key in obj ) {}
>
> return key === undefined || core_hasOwn.call( obj, key );
> From my debugging, it sometimes fails the key === undefined
> 
> check (if I add more logging code, it returns true - that does not make
> sense) and it sometimes fails the core_hasOwn.call( obj, key )
> 
> check (which returns true for a key that is not an own property). When
> this happen, Object.keys(obj).indexOf(key) returns -1. I verified that
> the key is indeed not an own property.
> (I am using jQuery 1.9.1 and cannot update it, but the code has basically
> gone through simplification, not real bug fixes)
>
> I think it may have started since Chrome 52, I am not sure. It evidently
> possibly became much, much worse in Chrome 53 (Windows 7, Intel Core i5, 32
> bit).
>
> I should report it, but I cannot disclose the code (it is a
> several-megabyte package that includes - and uses in that stack - several
> libraries like Knockout, Backbone, Underscore and more). Can someone
> suggest how I can diagnose and debug this further (without a native code
> debugger) in order to help you understand the exact issue (without showing
> code :()?
>
>
> ☆*PhistucK*
> On Tuesday, September 20, 2016 at 3:54:19 PM UTC+3, Michael Hablich wrote:
>
> --no-crankshaft should do the trick. The name is misleading, it will also
> disable TurboFan.
>
>
> On Tuesday, September 20, 2016 at 1:51:51 PM UTC+2, PhistucK wrote:
>
> I have an issue where the code suddenly (since Chrome 53) gets caught up
> in a cyclic recursion until it exceeds the stack size limit.
>
> Since the code is the same, I want to try and rule out engine optimization
> issues. Is there a V8 flag for disabling all of the optimizations?
>
>
> ☆*PhistucK*
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
>
> You received this message because you are subscribed to a topic in the
> Google Groups "v8-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/v8-users/V3J9CwEv468/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> v8-users+unsubscr...@googlegroups.com.
>
>
> For more options, visit https://groups.google.com/d/optout.
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> 

Re: [v8-users] Re: Disabling All Of The Optimizations

[PhistucK]

After bisecting, the bug started at -
https://chromium.googlesource.com/v8/v8/+log/c93d868f..d83c3f0e
The bug stopped at -
https://chromium.googlesource.com/v8/v8/+log/f9a47d47..a255aa83

This leaves me with
https://chromium.googlesource.com/v8/v8/+/4dab7b5a1d6722002d47d0be2481cb65602a2451,
which resolves a for-in optimization (Turbofan) bug
 and already
merged to the 5.3 branch (but is not released to stable yet :().

Though, I wonder, why did it not always occur? jQuery.isPlainObject is a
very hot function (at least in the code with which I am dealing here). Is
it possible that it is not always optimized?
(Also, that weird foo.hasOwnProperty(bar) === true versus
Object.keys(foo).indexOf(bar)
=== -1 contradiction...)

Hopefully, another stable patch will be released soon, as it may affect
many jQuery versions, since that was the way to check whether an object is
a plain object until some time ago.

I apologize to everyone, as I experienced the bug when it started but
dismissed it as a temporary canary issue that would resolve itself. Stupid
me. I hope I learned my lesson (probably not, though :( - I would have
reported it if it did not require days of investigations).


☆*PhistucK*

On Sat, Sep 24, 2016 at 1:45 PM, PhistucK  wrote:

> Thank you! Unfortunately, for everyone, it is getting clearer and clearer
> that this is an optimization issue. The issue does not reproduce with the
> --no-crankshaft flag.
>
> The code is calling something like -
> jQuery.extend(/* deepCopy */ true, {string: 'something'}, {string,
> 'something', instance: someConstructedInstance})
> (Where someConstructedInstance is a an instance of an object based on an
> enhanced Backbone View Model, so it is not a plain object)
> And sometimes (it used to occasionally appear, it now appears most often
> than not), jQuery.isPlainObject returns true for the value of instance.
> That jQuery function finishes with the following statements
> 
>  -
> var key;
> for ( key in obj ) {}
>
> return key === undefined || core_hasOwn.call( obj, key );
> From my debugging, it sometimes fails the key === undefined
> 
> check (if I add more logging code, it returns true - that does not make
> sense) and it sometimes fails the core_hasOwn.call( obj, key )
> 
> check (which returns true for a key that is not an own property). When
> this happen, Object.keys(obj).indexOf(key) returns -1. I verified that
> the key is indeed not an own property.
> (I am using jQuery 1.9.1 and cannot update it, but the code has basically
> gone through simplification, not real bug fixes)
>
> I think it may have started since Chrome 52, I am not sure. It evidently
> possibly became much, much worse in Chrome 53 (Windows 7, Intel Core i5, 32
> bit).
>
> I should report it, but I cannot disclose the code (it is a
> several-megabyte package that includes - and uses in that stack - several
> libraries like Knockout, Backbone, Underscore and more). Can someone
> suggest how I can diagnose and debug this further (without a native code
> debugger) in order to help you understand the exact issue (without showing
> code :()?
>
>
> ☆*PhistucK*
> On Tuesday, September 20, 2016 at 3:54:19 PM UTC+3, Michael Hablich wrote:
>
>> --no-crankshaft should do the trick. The name is misleading, it will also
>> disable TurboFan.
>>
>>
>> On Tuesday, September 20, 2016 at 1:51:51 PM UTC+2, PhistucK wrote:
>>>
>>> I have an issue where the code suddenly (since Chrome 53) gets caught up
>>> in a cyclic recursion until it exceeds the stack size limit.
>>>
>>> Since the code is the same, I want to try and rule out engine
>>> optimization issues. Is there a V8 flag for disabling all of the
>>> optimizations?
>>>
>>>
>>> ☆*PhistucK*
>>>
>> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "v8-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/v8-users/V3J9CwEv468/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.