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 since start of marking, biggest step 96.5 ms)
[StackGuard GC request] [GC in old space requested].
[13997] 2189 ms: Mark-sweep 45.1 (84.1) -> 29.3 (68.2) MB, 427.1 ms (+
276.9 ms in 1 steps since start of marking, biggest step 276.9 ms)
[StackGuard GC request] [GC in old space requested].
[13997] 6662 ms: Mark-sweep 149.1 (188.1) -> 95.8 (134.8) MB, 1441.6 ms
(+ 903.0 ms in 1 steps since start of marking, biggest step 903.0 ms)
[StackGuard GC request] [GC in old space requested].
[13997] 21462 ms: Mark-sweep 500.2 (539.3) -> 320.5 (359.5) MB, 4683.9
ms (+ 2996.5 ms in 1 steps since start of marking, biggest step 2996.5 ms)
[StackGuard GC request] [GC in old space requested].
[13997] 35887 ms: Scavenge 1038.9 (1077.9) -> 1038.9 (1077.9) MB, 1299.5
ms (+ 407.7 ms in 1 steps since last GC) [Runtime::PerformGC] [incremental
marking delaying mark-sweep].
[13997] 35913 ms: Scavenge 1038.9 (1077.9) -> 1038.9 (1077.9) MB, 1.9 ms
(+ 23.4 ms in 1 steps since last GC) [Runtime::PerformGC] [incremental
marking delaying mark-sweep].
#
# Fatal error in JS
# Allocation failed - process out of memory
#
On Thursday, January 15, 2015 at 2:06:27 PM UTC-8, Jane Chen wrote:
>
> 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 as GC is able to free up memory, it doesn't abort.
>
> Although I can register GC callbacks, the callback doesn't tell me how
> successful it is in freeing memory. --trace_gc does, but not through a
> callback. So at this point, I don't have a fix yet.
>
> On Thursday, January 15, 2015 at 12:34:05 PM UTC-8, Jane Chen wrote:
>>
>> 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
>> extensively though. If anyone knows of other scenarios, please share.
>>
>> Jane
>>
>> On Thursday, January 15, 2015 at 3:21:01 AM UTC-8, Ben Noordhuis wrote:
>>>
>>> On Thu, Jan 15, 2015 at 7:37 AM, Jane Chen <jxch...@gmail.com> 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 0x00007f785148b731 in v8::internal::OS::DebugBreak() () from
>>> lib/libv8.so
>>> > #5 0x00007f785148bf3d in v8::internal::OS::Abort() () from
>>> lib/libv8.so
>>> > #6 0x00007f7851109137 in v8::Utils::ReportApiFailure(char const*, char
>>> > const*) () from lib/libv8.so
>>> > #7 0x00007f785110bf5d in
>>> v8::internal::V8::FatalProcessOutOfMemory(char
>>> > const*, bool) () from lib/libv8.so
>>> > #8 0x00007f785118f46e in v8::internal::Invoke(bool,
>>> > v8::internal::Handle<v8::internal::JSFunction>,
>>> > v8::internal::Handle<v8::internal::Object>, int,
>>> > v8::internal::Handle<v8::internal::Object>*, bool*) () from
>>> lib/libv8.so
>>> > #9 0x00007f785118fd3f in
>>> > v8::internal::Execution::Call(v8::internal::Isolate*,
>>> > v8::internal::Handle<v8::internal::Object>,
>>> > v8::internal::Handle<v8::internal::Object>, int,
>>> > v8::internal::Handle<v8::internal::Object>*, bool*, bool) () from
>>> > lib/libv8.so
>>> > #10 0x00007f7851115a7e in v8::Script::Run() () from lib/libv8.so
>>> >
>>> > Ideally I would like to catch this and cancel the request causing the
>>> > out-of-memory error before v8 aborts. What's the best way to handle
>>> it?
>>> >
>>> > Thanks in advance.
>>>
>>> I don't think out of memory is a failure mode that V8 really supports;
>>> it will report an error in most cases but it won't be in a usable
>>> state afterwards.
>>>
>>> Maybe you can install a callback with
>>> Isolate::AddMemoryAllocationCallback(), keep a tally of allocated
>>> memory and kill the script before it exhausts all memory. I don't
>>> know if it's safe to call Isolate::TerminateExecution() from a memory
>>> callback but I imagine it is, it just sets a flag.
>>>
>>
--
--
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.
