Jochen,
That turns out to be really fun exercise, and the result is quite promising.
Thanks!
On Monday, January 25, 2016 at 11:44:44 PM UTC-8, Jochen Eisinger wrote:
>
> in theory, doing isolate->Exit(); isolate->Dispose(); should be enough to
> discard the isolate. How to terminate the thread
in theory, doing isolate->Exit(); isolate->Dispose(); should be enough to
discard the isolate. How to terminate the thread depends on the threading
library you use. Note that you'll also have to free up all C++ memory
you've allocated, because exiting the Isolate won't invoke weak callbacks
etc..
Jochen,
I do mange to get the callback now, but other than gracefully shutting
down, I'm not sure how to tear down the isolate and the thread it lived on,
without affecting other isolates and threads. Is there any sample code or
unit test code to demonstrate that?
Thanks a lot in advance.
Ja
can you post a standalone repro case? Otherwise, setting a break point in
v8's internal fatal error handler and checking why it doesn't invoke yours
would be a possible way to debug this.
On Thu, Jan 21, 2016 at 11:59 PM Jane Chen wrote:
> Yes, I do get fatal errors like these from v8, but my fa
Yes, I do get fatal errors like these from v8, but my fatal error callback
is never invoked. I register my callback after I create the isolate like
this:
isolate->Enter();
isolate->SetFatalErrorHandler(logFatalError);
isolate->SetCaptureStackTraceForUncaughtExceptions(true,64,
v8::Sta
With this CL applied: https://codereview.chromium.org/1614763002
I get the following output:
$ ulimit -v 819200
$ out/x64.release/hello-world
<--- Last few GCs --->
3308 ms: Scavenge 188.2 (211.0) -> 188.2 (211.0) MB, 84.8 / 0 ms
[allocation failure].
3383 ms: Scavenge 188.2 (211.0) ->
I already have registered by FatalErrorCallback, but it never gets called
from an out of memory condition.
It would be interesting to get a test case to trigger FatalErrorCallback,
since my present handling of it is to gracefully shutdown and die.
On Friday, January 15, 2016 at 7:12:46 AM UTC
this is the git commit:
https://chromium.googlesource.com/v8/v8/+/8b8fb30e7f8915d0762402f0b6e5b16c820cab48
Have you considered setting a FatalErrorCallback and then tearing down the
entire isolate and the thread it lived on? That might be better than
crashing, although I'm not sure whether you won
Unfortunately, the following link is no longer valid:
https://code.google.com/p/v8/source/detail?r=20184
We just moved to 4.6.88. No more IgnoreOutOfMemoryException(), and I am
looking for a way to proactively detect low memory condition to terminate a
request before it completely runs out of
On Sun, Jan 18, 2015 at 5:59 AM, Jane Chen wrote:
> Just to close the loop, I found out that for each isolate that's created,
>
> isolate->Enter();
> v8::V8::IgnoreOutOfMemoryException();
> isolate->Exit();
>
> avoids the crash for the test case I have above. Not sure if it's safe to
> always do
On Sun, Jan 18, 2015 at 5:59 AM, Jane Chen wrote:
> Just to close the loop, I found out that for each isolate that's created,
>
> isolate->Enter();
> v8::V8::IgnoreOutOfMemoryException();
> isolate->Exit();
>
> avoids the crash for the test case I have above. Not sure if it's safe to
> always do
Just to close the loop, I found out that for each isolate that's created,
isolate->Enter();
v8::V8::IgnoreOutOfMemoryException();
isolate->Exit();
avoids the crash for the test case I have above. Not sure if it's safe to
always do so. Still need more testing for other stress situations.
If an
Here's the trace_gc log:
[13997] 258 ms: Scavenge 2.3 (39.2) -> 1.9 (39.2) MB, 8.4 ms
[Runtime::PerformGC].
[13997] 277 ms: Scavenge 2.7 (39.2) -> 2.5 (40.2) MB, 10.3 ms
[Runtime::PerformGC].
[13997] 786 ms: Mark-sweep 15.5 (52.2) -> 9.6 (48.5) MB, 186.1 ms (+
96.5 ms in 1 steps
So I found out that after the first malloc callback, it depends on how much
v8 can recollect through GC. In the test case shown above, gc fails to
free up anything and the 1GB of memory is all used. Then it aborts.
In other healthier cases, even if multiple GBs of memory is allocated, as
long
Ben,
Thanks. That actually worked for my test case. Except that my callback is
only called once with an apparent size of 1GB. So no need to tally.
That's my only chance to call TerminateExecution before it aborts.
At least that's what I saw on Linux with v3.24. Haven't tested it
extensive
On Thu, Jan 15, 2015 at 7:37 AM, Jane Chen wrote:
> I'm embedding v8 3.24 in my system. When running this query:
>
> a = []; for (;;) { a.push("hello"); }
>
> v8 logs out of memory error and aborts:
>
> #4 0x7f785148b731 in v8::internal::OS::DebugBreak() () from lib/libv8.so
> #5 0x7f7851
I'm embedding v8 3.24 in my system. When running this query:
a = []; for (;;) { a.push("hello"); }
v8 logs out of memory error and aborts:
#4 0x7f785148b731 in v8::internal::OS::DebugBreak() () from
lib/libv8.so
#5 0x7f785148bf3d in v8::internal::OS::Abort() () from lib/libv8.so
#6
17 matches
Mail list logo
