date:20170508

[v8-users] unable to locate module needed for external types:.dwo file not exist

2017-05-08 Thread Early

hi, I use lldb to debug v8.But when i use lldb `print` command to output 
some variable.there is always some errors come for me?
what's the reason for that?
(lldb) n
Process 27213 stopped
* thread #1, name = 'unittests', stop reason = step over
frame #0: 0x55fec318 
unittests`v8::internal::SourcePositionTableIterator::is_statement(this=0x7fffd5b8)
 
const at source-position-table.h:88
   85 }
   86 bool is_statement() const {
   87   DCHECK(!done());
-> 88   return current_.is_statement;
   89 }
   90 bool done() const { return index_ == kDone; }
   91   
(lldb) fr v
(const v8::internal::SourcePositionTableIterator *) this = 
0x7fffd5b8
(lldb) p current_
warning: (x86_64) /home/zhujianchen/work/v8/out.gn/x64.debug/unittests 
0x1386fcf6: DW_AT_specification(0x0005bb61) has no decl

warning: (x86_64) 
/home/zhujianchen/work/v8/out.gn/x64.debug/obj/v8_base/interpreter-irregexp.dwo 
0x000b: unable to locate module needed for external types: 
obj/v8_base/interpreter-irregexp.dwo
error: 'obj/v8_base/interpreter-irregexp.dwo' does not exist
Debugging will be degraded due to missing types. Rebuilding your project 
will regenerate the needed module files.
warning: (x86_64) 
/home/zhujianchen/work/v8/out.gn/x64.debug/obj/v8_base/regexp-macro-assembler-irregexp.dwo
 
0x000b: unable to locate module needed for external types: 
obj/v8_base/regexp-macro-assembler-irregexp.dwo
error: 'obj/v8_base/regexp-macro-assembler-irregexp.dwo' does not exist
Debugging will be degraded due to missing types. Rebuilding your project 
will regenerate the needed module files.
warning: (x86_64) 
/home/zhujianchen/work/v8/out.gn/x64.debug/obj/third_party/icu/icuuc/cwchar.dwo 
0x000b: unable to locate module needed for external types: 
obj/third_party/icu/icuuc/cwchar.dwo
error: 'obj/third_party/icu/icuuc/cwchar.dwo' does not exist
Debugging will be degraded due to missing types. Rebuilding your project 
will regenerate the needed module files.
warning: (x86_64) 
/home/zhujianchen/work/v8/out.gn/x64.debug/obj/third_party/icu/icuuc/ucnv_ct.dwo
 
0x000b: unable to locate module needed for external types: 
obj/third_party/icu/icuuc/ucnv_ct.dwo
error: 'obj/third_party/icu/icuuc/ucnv_ct.dwo' does not exist
Debugging will be degraded due to missing types. Rebuilding your project 
will regenerate the needed module files.
warning: (x86_64) 
/home/zhujianchen/work/v8/out.gn/x64.debug/obj/third_party/icu/icuuc/ucnv_lmb.dwo
 
0x000b: unable to locate module needed for external types: 
obj/third_party/icu/icuuc/ucnv_lmb.dwo
error: 'obj/third_party/icu/icuuc/ucnv_lmb.dwo' does not exist
Debugging will be degraded due to missing types. Rebuilding your project 
will regenerate the needed module files.
warning: (x86_64) 
/home/zhujianchen/work/v8/out.gn/x64.debug/obj/third_party/icu/icuuc/ucnv_u7.dwo
 
0x000b: unable to locate module needed for external types: 
obj/third_party/icu/icuuc/ucnv_u7.dwo
error: 'obj/third_party/icu/icuuc/ucnv_u7.dwo' does not exist
Debugging will be degraded due to missing types. Rebuilding your project 
will regenerate the needed module files.
warning: (x86_64) 
/home/zhujianchen/work/v8/out.gn/x64.debug/obj/third_party/icu/icuuc/ucnvhz.dwo 
0x000b: unable to locate module needed for external types: 
obj/third_party/icu/icuuc/ucnvhz.dwo
error: 'obj/third_party/icu/icuuc/ucnvhz.dwo' does not exist
Debugging will be degraded due to missing types. Rebuilding your project 
will regenerate the needed module files.
warning: (x86_64) 
/home/zhujianchen/work/v8/out.gn/x64.debug/obj/third_party/icu/icuuc/ucnvisci.dwo
 
0x000b: unable to locate module needed for external types: 
obj/third_party/icu/icuuc/ucnvisci.dwo
error: 'obj/third_party/icu/icuuc/ucnvisci.dwo' does not exist
Debugging will be degraded due to missing types. Rebuilding your project 
will regenerate the needed module files.
warning: (x86_64) 
/home/zhujianchen/work/v8/out.gn/x64.debug/obj/third_party/icu/icuuc/ucnvscsu.dwo
 
0x000b: unable to locate module needed for external types: 
obj/third_party/icu/icuuc/ucnvscsu.dwo
error: 'obj/third_party/icu/icuuc/ucnvscsu.dwo' does not exist
Debugging will be degraded due to missing types. Rebuilding your project 
will regenerate the needed module files.
warning: (x86_64) 
/home/zhujianchen/work/v8/out.gn/x64.debug/obj/third_party/icu/icuuc/wintz.dwo 
0x000b: unable to locate module needed for external types: 
obj/third_party/icu/icuuc/wintz.dwo
error: 'obj/third_party/icu/icuuc/wintz.dwo' does not exist
Debugging will be degraded due to missing types. Rebuilding your project 
will regenerate the needed module files.



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

Re: [v8-users] Cryptic out-of-memory error

2017-05-08 Thread Andre Cunha

@Michael Lippautz, I'll try adding a breakpoint if AllocateChunk returns 
NULL; hopefully, I'll get more information about the problem.

@Jakob Kummerow, yes, I'm calling Isolate::Dispose() in every isolate after 
using it. I'll also observe the VIRT column and see if it shows any 
abnormality.

Thank you!

On Monday, May 8, 2017 at 11:07:44 AM UTC-3, Jakob Kummerow wrote:
>
> My guess would be an address space leak (should show up in the "VIRT" 
> column of "top" on Linux). Are you calling "isolate->Dispose()" on any 
> isolate you're done with?
>
> On Mon, May 8, 2017 at 4:01 PM, Michael Lippautz  > wrote:
>
>> V8 usually fails there if it cannot allocate a 512KiB page from the 
>> operating system/
>>
>> You could try hooking in AllocateChunk [1] and see why it is returning 
>> NULL and trace back through the underlying calls. 
>>
>> Best, Michael
>>
>> [1]: 
>> https://cs.chromium.org/chromium/src/v8/src/heap/spaces.cc?q=AllocateChunk=package:chromium=739
>>
>> On Mon, May 8, 2017 at 3:27 PM Andre Cunha > > wrote:
>>
>>> Hello,
>>>
>>> I have embedded v8 into a project for the company I work for, and during 
>>> some stress tests, I've encountered a weird out-of-memory error. After 
>>> considerable investigation, I still have no idea of what might be going on, 
>>> so I'm reaching out to you in hope of some insight.
>>>
>>> So here is a summary of the scenario: in each test iteration, I create 
>>> an Isolate, run some short JS code fragments, and then destroy the isolate. 
>>> After the execution of each code fragment, I perform some variable 
>>> manipulations from my C++ code using V8's API, prior to running the next 
>>> fragment. I repeat thousands of such iterations over the same input (it's 
>>> valid), and I expect no memory leaks and no crashes. However, after about 3 
>>> hours, V8 crashes with an out-of-memory error of no apparent reason.
>>>
>>> I have run the code though valgrind and using address sanitizing, and no 
>>> memory leaks were detected. Additionally, I monitor memory consumption 
>>> throughout the test; the program's memory usage is stable, without any 
>>> peak, and when V8 crashes the system has a lot of available memory (more 
>>> than 5 Gib). I have used V8's API to get heap usage statistics after each 
>>> successful iteration; the values are always the same, and are shown below 
>>> (they are included in an attached file, typical_memory.txt):
>>>
>>> ScriptEngine::Run: finished running at 2017-05-05T13:20:34
>>>   used_heap_size   : 46.9189 Mib
>>>   total_heap_size  : 66.1562 Mib
>>>   Space 0
>>> name   : new_space
>>> size   : 8 Mib
>>> used_size  : 2.47314 Mib
>>> available_size : 5.39404 Mib
>>>   Space 1
>>> name   : old_space
>>> size   : 39.5625 Mib
>>> used_size  : 31.6393 Mib
>>> available_size : 5.51526 Mib
>>>   Space 2
>>> name   : code_space
>>> size   : 10.4375 Mib
>>> used_size  : 6.16919 Mib
>>> available_size : 0 B
>>>   Space 3
>>> name   : map_space
>>> size   : 8.15625 Mib
>>> used_size  : 6.63733 Mib
>>> available_size : 80 B
>>>   Space 4
>>> name   : large_object_space
>>> size   : 0 B
>>> used_size  : 0 B
>>> available_size : 11.1015 Gib
>>>
>>> When V8 crashes, it prints a heap summary, which I'm sending attached 
>>> (file heap_after_error.txt). I also save a core dump. Sometimes, the 
>>> system crashes during the creation of an Isolate; sometimes, during the 
>>> creation of a Context; typically, it crashes during snapshot 
>>> deserialization. However, the top of the stack is always the same, and it's 
>>> reproduced below (also included attached, file stacktrace.txt).
>>>
>>> #7  v8::internal::OS::Abort () at 
>>> ../../src/base/platform/platform-posix.cc:230
>>> #8  0x7ff15a2f922f in v8::Utils::ReportOOMFailure 
>>> (location=0x7ff15b20f62e "Committing semi space failed.", 
>>> is_heap_oom=false) at ../../src/api.cc:381
>>> #9  0x7ff15a2f918e in v8::internal::V8::FatalProcessOutOfMemory 
>>> (location=0x7ff15b20f62e "Committing semi space failed.", 
>>> is_heap_oom=false) at ../../src/api.cc:352
>>> #10 0x7ff15aa3fefc in v8::internal::Heap::EnsureFromSpaceIsCommitted 
>>> (this=0x7ff12c0bdde0) at ../../src/heap/heap.cc:1234
>>> #11 0x7ff15aa3ed34 in v8::internal::Heap::PerformGarbageCollection 
>>> (this=0x7ff12c0bdde0, collector=v8::internal::MARK_COMPACTOR,
>>> gc_callback_flags=v8::kNoGCCallbackFlags) at 
>>> ../../src/heap/heap.cc:1308
>>> #12 0x7ff15aa3e2ab in v8::internal::Heap::CollectGarbage 
>>> (this=0x7ff12c0bdde0, collector=v8::internal::MARK_COMPACTOR,
>>> gc_reason=v8::internal::GarbageCollectionReason::kDeserializer, 
>>> collector_reason=0x7ff15b20f07a "GC in old space requested",
>>>

[v8-users] v8 protocol not progressing after id:8

2017-05-08 Thread Harsha HS

Hi,
I am trying to use chrome protocol with chrom-devtools in front end.
I am not receiving any message from frontend after id:8

 message {"id":1,"method":"Runtime.enable"}
 message {"id":2,"method":"Debugger.enable"}
 message 
{"id":3,"method":"Debugger.setPauseOnExceptions","params":{"state":"none"}}
 message 
{"id":4,"method":"Debugger.setAsyncCallStackDepth","params":{"maxDepth":0}}
 message {"id":5,"method":"Profiler.enable"}
 message 
{"id":6,"method":"Profiler.setSamplingInterval","params":{"interval":100}}
 message 
{"id":7,"method":"Debugger.setBlackboxPatterns","params":{"patterns":[]}}
message {"id":8,"method":"Runtime.runIfWaitingForDebugger"}

For each of these messages, I am replying to frontend with {id:xx, 
result:{}}.

Code is at https://github.com/hsharsha/v8inspector

-Harsha

-- 
-- 
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] Cryptic out-of-memory error

2017-05-08 Thread Jakob Kummerow

My guess would be an address space leak (should show up in the "VIRT"
column of "top" on Linux). Are you calling "isolate->Dispose()" on any
isolate you're done with?

On Mon, May 8, 2017 at 4:01 PM, Michael Lippautz 
wrote:

> V8 usually fails there if it cannot allocate a 512KiB page from the
> operating system/
>
> You could try hooking in AllocateChunk [1] and see why it is returning
> NULL and trace back through the underlying calls.
>
> Best, Michael
>
> [1]: https://cs.chromium.org/chromium/src/v8/src/heap/
> spaces.cc?q=AllocateChunk=package:chromium=739
>
> On Mon, May 8, 2017 at 3:27 PM Andre Cunha 
> wrote:
>
>> Hello,
>>
>> I have embedded v8 into a project for the company I work for, and during
>> some stress tests, I've encountered a weird out-of-memory error. After
>> considerable investigation, I still have no idea of what might be going on,
>> so I'm reaching out to you in hope of some insight.
>>
>> So here is a summary of the scenario: in each test iteration, I create an
>> Isolate, run some short JS code fragments, and then destroy the isolate.
>> After the execution of each code fragment, I perform some variable
>> manipulations from my C++ code using V8's API, prior to running the next
>> fragment. I repeat thousands of such iterations over the same input (it's
>> valid), and I expect no memory leaks and no crashes. However, after about 3
>> hours, V8 crashes with an out-of-memory error of no apparent reason.
>>
>> I have run the code though valgrind and using address sanitizing, and no
>> memory leaks were detected. Additionally, I monitor memory consumption
>> throughout the test; the program's memory usage is stable, without any
>> peak, and when V8 crashes the system has a lot of available memory (more
>> than 5 Gib). I have used V8's API to get heap usage statistics after each
>> successful iteration; the values are always the same, and are shown below
>> (they are included in an attached file, typical_memory.txt):
>>
>> ScriptEngine::Run: finished running at 2017-05-05T13:20:34
>>   used_heap_size   : 46.9189 Mib
>>   total_heap_size  : 66.1562 Mib
>>   Space 0
>> name   : new_space
>> size   : 8 Mib
>> used_size  : 2.47314 Mib
>> available_size : 5.39404 Mib
>>   Space 1
>> name   : old_space
>> size   : 39.5625 Mib
>> used_size  : 31.6393 Mib
>> available_size : 5.51526 Mib
>>   Space 2
>> name   : code_space
>> size   : 10.4375 Mib
>> used_size  : 6.16919 Mib
>> available_size : 0 B
>>   Space 3
>> name   : map_space
>> size   : 8.15625 Mib
>> used_size  : 6.63733 Mib
>> available_size : 80 B
>>   Space 4
>> name   : large_object_space
>> size   : 0 B
>> used_size  : 0 B
>> available_size : 11.1015 Gib
>>
>> When V8 crashes, it prints a heap summary, which I'm sending attached
>> (file heap_after_error.txt). I also save a core dump. Sometimes, the
>> system crashes during the creation of an Isolate; sometimes, during the
>> creation of a Context; typically, it crashes during snapshot
>> deserialization. However, the top of the stack is always the same, and it's
>> reproduced below (also included attached, file stacktrace.txt).
>>
>> #7  v8::internal::OS::Abort () at ../../src/base/platform/
>> platform-posix.cc:230
>> #8  0x7ff15a2f922f in v8::Utils::ReportOOMFailure
>> (location=0x7ff15b20f62e "Committing semi space failed.",
>> is_heap_oom=false) at ../../src/api.cc:381
>> #9  0x7ff15a2f918e in v8::internal::V8::FatalProcessOutOfMemory
>> (location=0x7ff15b20f62e "Committing semi space failed.",
>> is_heap_oom=false) at ../../src/api.cc:352
>> #10 0x7ff15aa3fefc in v8::internal::Heap::EnsureFromSpaceIsCommitted
>> (this=0x7ff12c0bdde0) at ../../src/heap/heap.cc:1234
>> #11 0x7ff15aa3ed34 in v8::internal::Heap::PerformGarbageCollection
>> (this=0x7ff12c0bdde0, collector=v8::internal::MARK_COMPACTOR,
>> gc_callback_flags=v8::kNoGCCallbackFlags) at
>> ../../src/heap/heap.cc:1308
>> #12 0x7ff15aa3e2ab in v8::internal::Heap::CollectGarbage
>> (this=0x7ff12c0bdde0, collector=v8::internal::MARK_COMPACTOR,
>> gc_reason=v8::internal::GarbageCollectionReason::kDeserializer,
>> collector_reason=0x7ff15b20f07a "GC in old space requested",
>> gc_callback_flags=v8::kNoGCCallbackFlags) at
>> ../../src/heap/heap.cc:1002
>> #13 0x7ff15a33cdee in v8::internal::Heap::CollectGarbage
>> (this=0x7ff12c0bdde0, space=v8::internal::OLD_SPACE,
>> gc_reason=v8::internal::GarbageCollectionReason::kDeserializer,
>> callbackFlags=v8::kNoGCCallbackFlags) at ../../src/heap/heap-inl.h:681
>> #14 0x7ff15aa3d069 in v8::internal::Heap::CollectAllGarbage
>> (this=0x7ff12c0bdde0, flags=2,
>>

Re: [v8-users] Cryptic out-of-memory error

2017-05-08 Thread Michael Lippautz

V8 usually fails there if it cannot allocate a 512KiB page from the
operating system/

You could try hooking in AllocateChunk [1] and see why it is returning NULL
and trace back through the underlying calls.

Best, Michael

[1]:
https://cs.chromium.org/chromium/src/v8/src/heap/spaces.cc?q=AllocateChunk=package:chromium=739

On Mon, May 8, 2017 at 3:27 PM Andre Cunha  wrote:

> Hello,
>
> I have embedded v8 into a project for the company I work for, and during
> some stress tests, I've encountered a weird out-of-memory error. After
> considerable investigation, I still have no idea of what might be going on,
> so I'm reaching out to you in hope of some insight.
>
> So here is a summary of the scenario: in each test iteration, I create an
> Isolate, run some short JS code fragments, and then destroy the isolate.
> After the execution of each code fragment, I perform some variable
> manipulations from my C++ code using V8's API, prior to running the next
> fragment. I repeat thousands of such iterations over the same input (it's
> valid), and I expect no memory leaks and no crashes. However, after about 3
> hours, V8 crashes with an out-of-memory error of no apparent reason.
>
> I have run the code though valgrind and using address sanitizing, and no
> memory leaks were detected. Additionally, I monitor memory consumption
> throughout the test; the program's memory usage is stable, without any
> peak, and when V8 crashes the system has a lot of available memory (more
> than 5 Gib). I have used V8's API to get heap usage statistics after each
> successful iteration; the values are always the same, and are shown below
> (they are included in an attached file, typical_memory.txt):
>
> ScriptEngine::Run: finished running at 2017-05-05T13:20:34
>   used_heap_size   : 46.9189 Mib
>   total_heap_size  : 66.1562 Mib
>   Space 0
> name   : new_space
> size   : 8 Mib
> used_size  : 2.47314 Mib
> available_size : 5.39404 Mib
>   Space 1
> name   : old_space
> size   : 39.5625 Mib
> used_size  : 31.6393 Mib
> available_size : 5.51526 Mib
>   Space 2
> name   : code_space
> size   : 10.4375 Mib
> used_size  : 6.16919 Mib
> available_size : 0 B
>   Space 3
> name   : map_space
> size   : 8.15625 Mib
> used_size  : 6.63733 Mib
> available_size : 80 B
>   Space 4
> name   : large_object_space
> size   : 0 B
> used_size  : 0 B
> available_size : 11.1015 Gib
>
> When V8 crashes, it prints a heap summary, which I'm sending attached
> (file heap_after_error.txt). I also save a core dump. Sometimes, the
> system crashes during the creation of an Isolate; sometimes, during the
> creation of a Context; typically, it crashes during snapshot
> deserialization. However, the top of the stack is always the same, and it's
> reproduced below (also included attached, file stacktrace.txt).
>
> #7  v8::internal::OS::Abort () at
> ../../src/base/platform/platform-posix.cc:230
> #8  0x7ff15a2f922f in v8::Utils::ReportOOMFailure
> (location=0x7ff15b20f62e "Committing semi space failed.",
> is_heap_oom=false) at ../../src/api.cc:381
> #9  0x7ff15a2f918e in v8::internal::V8::FatalProcessOutOfMemory
> (location=0x7ff15b20f62e "Committing semi space failed.",
> is_heap_oom=false) at ../../src/api.cc:352
> #10 0x7ff15aa3fefc in v8::internal::Heap::EnsureFromSpaceIsCommitted
> (this=0x7ff12c0bdde0) at ../../src/heap/heap.cc:1234
> #11 0x7ff15aa3ed34 in v8::internal::Heap::PerformGarbageCollection
> (this=0x7ff12c0bdde0, collector=v8::internal::MARK_COMPACTOR,
> gc_callback_flags=v8::kNoGCCallbackFlags) at
> ../../src/heap/heap.cc:1308
> #12 0x7ff15aa3e2ab in v8::internal::Heap::CollectGarbage
> (this=0x7ff12c0bdde0, collector=v8::internal::MARK_COMPACTOR,
> gc_reason=v8::internal::GarbageCollectionReason::kDeserializer,
> collector_reason=0x7ff15b20f07a "GC in old space requested",
> gc_callback_flags=v8::kNoGCCallbackFlags) at
> ../../src/heap/heap.cc:1002
> #13 0x7ff15a33cdee in v8::internal::Heap::CollectGarbage
> (this=0x7ff12c0bdde0, space=v8::internal::OLD_SPACE,
> gc_reason=v8::internal::GarbageCollectionReason::kDeserializer,
> callbackFlags=v8::kNoGCCallbackFlags) at ../../src/heap/heap-inl.h:681
> #14 0x7ff15aa3d069 in v8::internal::Heap::CollectAllGarbage
> (this=0x7ff12c0bdde0, flags=2,
> gc_reason=v8::internal::GarbageCollectionReason::kDeserializer,
> gc_callback_flags=v8::kNoGCCallbackFlags) at ../../src/heap/heap.cc:848
> #15 0x7ff15aa3fe84 in v8::internal::Heap::ReserveSpace
> (this=0x7ff12c0bdde0, reservations=0x7ff148fe6078, maps=0x7ff148fe60f8) at
> ../../src/heap/heap.cc:1215
>
> In the heap summary that gets printed, I have noted some apparent
> discrepancies with the typical data I get

[v8-users] Cryptic out-of-memory error

2017-05-08 Thread Andre Cunha

Hello,

I have embedded v8 into a project for the company I work for, and during 
some stress tests, I've encountered a weird out-of-memory error. After 
considerable investigation, I still have no idea of what might be going on, 
so I'm reaching out to you in hope of some insight.

So here is a summary of the scenario: in each test iteration, I create an 
Isolate, run some short JS code fragments, and then destroy the isolate. 
After the execution of each code fragment, I perform some variable 
manipulations from my C++ code using V8's API, prior to running the next 
fragment. I repeat thousands of such iterations over the same input (it's 
valid), and I expect no memory leaks and no crashes. However, after about 3 
hours, V8 crashes with an out-of-memory error of no apparent reason.

I have run the code though valgrind and using address sanitizing, and no 
memory leaks were detected. Additionally, I monitor memory consumption 
throughout the test; the program's memory usage is stable, without any 
peak, and when V8 crashes the system has a lot of available memory (more 
than 5 Gib). I have used V8's API to get heap usage statistics after each 
successful iteration; the values are always the same, and are shown below 
(they are included in an attached file, typical_memory.txt):

ScriptEngine::Run: finished running at 2017-05-05T13:20:34
  used_heap_size   : 46.9189 Mib
  total_heap_size  : 66.1562 Mib
  Space 0
name   : new_space
size   : 8 Mib
used_size  : 2.47314 Mib
available_size : 5.39404 Mib
  Space 1
name   : old_space
size   : 39.5625 Mib
used_size  : 31.6393 Mib
available_size : 5.51526 Mib
  Space 2
name   : code_space
size   : 10.4375 Mib
used_size  : 6.16919 Mib
available_size : 0 B
  Space 3
name   : map_space
size   : 8.15625 Mib
used_size  : 6.63733 Mib
available_size : 80 B
  Space 4
name   : large_object_space
size   : 0 B
used_size  : 0 B
available_size : 11.1015 Gib

When V8 crashes, it prints a heap summary, which I'm sending attached (file 
heap_after_error.txt). I also save a core dump. Sometimes, the system 
crashes during the creation of an Isolate; sometimes, during the creation 
of a Context; typically, it crashes during snapshot deserialization. 
However, the top of the stack is always the same, and it's reproduced below 
(also included attached, file stacktrace.txt).

#7  v8::internal::OS::Abort () at 
../../src/base/platform/platform-posix.cc:230
#8  0x7ff15a2f922f in v8::Utils::ReportOOMFailure 
(location=0x7ff15b20f62e "Committing semi space failed.", 
is_heap_oom=false) at ../../src/api.cc:381
#9  0x7ff15a2f918e in v8::internal::V8::FatalProcessOutOfMemory 
(location=0x7ff15b20f62e "Committing semi space failed.", 
is_heap_oom=false) at ../../src/api.cc:352
#10 0x7ff15aa3fefc in v8::internal::Heap::EnsureFromSpaceIsCommitted 
(this=0x7ff12c0bdde0) at ../../src/heap/heap.cc:1234
#11 0x7ff15aa3ed34 in v8::internal::Heap::PerformGarbageCollection 
(this=0x7ff12c0bdde0, collector=v8::internal::MARK_COMPACTOR,
gc_callback_flags=v8::kNoGCCallbackFlags) at ../../src/heap/heap.cc:1308
#12 0x7ff15aa3e2ab in v8::internal::Heap::CollectGarbage 
(this=0x7ff12c0bdde0, collector=v8::internal::MARK_COMPACTOR,
gc_reason=v8::internal::GarbageCollectionReason::kDeserializer, 
collector_reason=0x7ff15b20f07a "GC in old space requested",
gc_callback_flags=v8::kNoGCCallbackFlags) at ../../src/heap/heap.cc:1002
#13 0x7ff15a33cdee in v8::internal::Heap::CollectGarbage 
(this=0x7ff12c0bdde0, space=v8::internal::OLD_SPACE,
gc_reason=v8::internal::GarbageCollectionReason::kDeserializer, 
callbackFlags=v8::kNoGCCallbackFlags) at ../../src/heap/heap-inl.h:681
#14 0x7ff15aa3d069 in v8::internal::Heap::CollectAllGarbage 
(this=0x7ff12c0bdde0, flags=2,
gc_reason=v8::internal::GarbageCollectionReason::kDeserializer, 
gc_callback_flags=v8::kNoGCCallbackFlags) at ../../src/heap/heap.cc:848
#15 0x7ff15aa3fe84 in v8::internal::Heap::ReserveSpace 
(this=0x7ff12c0bdde0, reservations=0x7ff148fe6078, maps=0x7ff148fe60f8) at 
../../src/heap/heap.cc:1215

In the heap summary that gets printed, I have noted some apparent 
discrepancies with the typical data I get from the API (shown above): for 
example, the summary says the size of the old space is 4067328 bytes (= 
3.88 Mib), not the typical 39.56 Mib I get from the API.

I have dived into V8 garbage collection, but still couldn't make sense of 
the error message ("Committing semi space failed"). So, I'd like to know 
under which circumstances this error can happen, and how it's possible that 
it only happens occasionally, given that each test iteration is identical 
to the others and there is no detectable memory leaks.

If you need more

[v8-users] unable to locate module needed for external types:.dwo file not exist

Re: [v8-users] Cryptic out-of-memory error

[v8-users] v8 protocol not progressing after id:8

Re: [v8-users] Cryptic out-of-memory error

Re: [v8-users] Cryptic out-of-memory error

[v8-users] Cryptic out-of-memory error

6 matches

Site Navigation

Mail list logo

Footer information