Re: [v8-users] JavaScript heap out of memory issue

[Abhishek Singh]

Hi Ben,

It turned out to be memory leak in my C++ wrapper on top of V8 - fixed it. 
Thanks for the suggestion around using v8::HeapProfiler::TakeHeapSnapshot().

> On 24-Sep-2016, at 00:08, Ben Noordhuis  wrote:
> 
> On Fri, Sep 23, 2016 at 12:54 PM, Abhishek Singh
>  wrote:
>> Hi,
>> 
>> I noticed a V8 crash with following message:
>> 
>> 
>> <--- Last few GCs --->
>> 
>>  251206 ms: Mark-sweep 1400.2 (1456.1) -> 1400.2 (1456.1) MB, 3688.5 / 0.0 
>> ms [allocation failure] [GC in old space requested].
>>  254854 ms: Mark-sweep 1400.2 (1456.1) -> 1400.2 (1456.1) MB, 3648.2 / 0.0 
>> ms [allocation failure] [GC in old space requested].
>>  258562 ms: Mark-sweep 1400.2 (1456.1) -> 1400.2 (1426.1) MB, 3707.6 / 0.0 
>> ms [last resort gc].
>>  262315 ms: Mark-sweep 1400.2 (1426.1) -> 1400.2 (1426.1) MB, 3752.6 / 0.0 
>> ms [last resort gc].
>> 
>> 
>> <--- JS stacktrace --->
>> 
>>  JS stack trace =
>> 
>> Security context: 0x3c20e87ca141 
>>1: OnHTTPGet [0x3c20e8704311 :~64] 
>> [pc=0x328074967a8e](this=0x94116b170d1 ,req=0x6ba99d91ed1 
>> ,res=0x6ba99d91f29 )
>> 
>>  Details 
>> 
>> [1]: OnHTTPGet [0x3c20e8704311 :~64] 
>> [pc=0x328074967a8e](this=0x94116b170d1 ,req=0x6ba99d91ed1 
>> > 
>> 
>> What the application does is - it executes JS function call when an end user 
>> fires a HTTP request and response object is written back to the end user. 
>> Call volume was around 10K HTTP requests/sec(JS code being executed is 
>> trivial) - snippet of it:
>> 
>> function OnHTTPGet(req, res) {
>>  res.body.msg = “Hello world”; // res is nested map exposed from C++ to JS 
>> world
>> }
>> 
>> ===
>> 
>> I tried simulating behaviour on a standalone environment and could replicate 
>> the problem, here is code to do that: 
>> https://gist.github.com/abhi-bit/505538ac45d4b11014c3681e3bb74a2b
>> 
>> What I noticed that my machine has probably 4GB of memory left but V8’s 
>> memory footprint was around 1.6GB before the crash. To summarise my 
>> questions:
>> 
>> Is 10K request/sec(JS function calls/sec) too much for GC to handle in this 
>> scenario? Any tunable to control this behaviour or am I doing wrong in 
>> standalone code?
> 
> Modulo bugs in the garbage collector the request rate shouldn't
> matter.  Your application can not allocate faster than the collector
> can reclaim because it will simply block your application until it
> catches up.  Not necessarily true for a truly concurrent GC but V8's
> is still stop-the-world when it has to be.
> 
> A more likely cause is that you have a memory leak somewhere.  Try
> making snapshots of the heap that you can inspect in Chrome DevTools;
> see HeapProfiler::TakeHeapSnapshot() in include/v8-profiler.h or
> https://github.com/bnoordhuis/node-heapdump for a more full-fledged
> example.
> 
>> Why V8 mem_size could only grow upto 1.6GB, even when system has 4GB of 
>> memory? I’ve seen similar problem in couchdb(map-reduce index based on top 
>> of V8) as well, where app V8 binding crashed when footprint when close to 
>> 1.6GB(but that with V8 3.23) - error dump looked like this:
> 
> The default limit is ~1.6 GB.  You can turn it up with
> --max_old_space_size or through
> Isolate::CreateParams::constraints::set_max_old_space_size().
> 
> -- 
> -- 
> 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.

-- 
-- 
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.

[v8-users] No libv8.a generated for either X64 or ARM64 build.

[Nonny Mouse]

I'm trying to build V8 for both X64 and ARM64 (by cross compiling).  Both 
builds seem to run and complete without errors, but libv8.a, libplatform.a, 
etc. are not generated for either build.  However, other static libraries 
are successfully built (e.g. libgmock.a).

Build machine is X64 running Mint 17.3 (i.e. Ubuntu 14.04LTS).  To be 
certain, I created a new v8 directory and downloaded and built everything 
again with the following:

 git clone 
https://chromium.googlesource.com/chromium/tools/depot_tools.git
 export (correct path, beginning with depot_tools)
 fetch v8;  cd v8
 build/linux/sysroot_scripts/install-sysroot.py --arch=arm64
 gclient sync
 
 then:

 gn gen out/a64 --args='is_debug=false symbol_level=0 
v8_use_external_startup_data=false v8_enable_i18n_support=false 
target_cpu="arm64"'
 ninja -C out/a64 | tee out/a64/build.log

(The only difference between the X64 and ARM64 builds was the target_cpu 
and out directory).

-- 
-- 
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.

Re: [v8-users] Re: Getting invalid (very high) line numbers from failed compile within v8::ScriptCompiler::CompileFunctionInContext

[Jochen Eisinger]

CompileFunctionInContext is equivalent to using with (context_extension) {
} around your function which is different from pretending it was inside
some other function.

As for the odd line numbers, can you provide a complete repro case?

On Sat, Sep 24, 2016 at 1:12 PM Zac Hansen  wrote:

> I'm a bit confused.   I put a proper TryCatch around the
> CompileFunctionInContext and print the results there and I get a much
> better error:
>
> 0
> myfile.js:74: SyntaxError: Unexpected identifier
> do_stuff: function(stuff){
>   
>
> because I'm missing a comma on the preceeding line.
>
> But what the heck was going on before?
>
>
> On Saturday, September 24, 2016 at 2:41:29 AM UTC-7, Zac Hansen wrote:
>
> I'm trying to take some user-provided code and pretend it's inside of a
> function, which is what I
> think v8::ScriptCompiler::CompileFunctionInContext is for.
>
> However, I have a syntax error in my javascript code, but when I get an
> error message:
>
> myfile.js:2079: Uncaught SyntaxError: Unexpected identifier
>
> there is no line 2079.  that specific file only has 372 lines and the
> actual failure is probably around line 85 or so.  If I look at my
> ScriptOrigin right before I start compiling, it all seems good with the
> right filename, line, and column offsets (1, 0 respectively).
>
> printf("%s\n", *v8::String::Utf8Value(script_origin.ResourceName()));
> printf("%d\n", script_origin.ResourceLineOffset()->Value());
> printf("%d\n", script_origin.ResourceColumnOffset()->Value());
>
>
> v8::ScriptCompiler::Source source(v8::String::NewFromUtf8(isolate, 
> module_source.c_str()), script_origin);
> v8::Local parameter_names[] = {
> v8::String::NewFromUtf8(isolate, "module"),
> v8::String::NewFromUtf8(isolate, "exports")
> };
> auto maybe_module_function =
> v8::ScriptCompiler::CompileFunctionInContext(context, , 2, 
> _names[0], 0, nullptr);
>
>
> Any ideas?
>
> --
> --
> 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.
>

-- 
-- 
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.

[v8-users] where to start on implementing chrome debug-ability for a embedded v8 application?

[Zac Hansen]

I want to be able to debug the code running in my program, and in a 
previous thread, I was informed that there is currently no way to do this 
with over the network.

Someone mentioned that this will be (re)added eventually, but when I asked 
for an estimate of a half-year that might happen, I got no response.

So, if i want to go about it myself, can I get some resources and maybe 
some hints as to how to start?


I see this page here:

https://developer.chrome.com/devtools/docs/debugger-protocol

and the "tip of tree" protocol page:

https://cs.chromium.org/#chromium/src/third_party/WebKit/Source/devtools/protocol.json=protocol.json=package:chromium=cs

but I was hoping maybe someone could tell me a minimum set of options I 
could implement that would give me a proof of concept, or maybe some 
general breakdown of what the fields in the json mean? 
 https://chromium.googlesource.com/v8/v8/+/master/src/inspector/js_protocol.json

Any help getting started down the right path would be awesome.   

Thank you.

--Zac

-- 
-- 
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.

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
>