Repository navigation
v6 has buffer issues on Fedora 24 #6272
Description
Activity
/cc @trevnorris
FWIW, I run x86_64 FC24 as well and
make testpasses for me. How much memory does your machine have and are their ulimits in effect?How much memory does your machine have
16 GB
are their ulimits in effect?
$ ulimit -a -t: cpu time (seconds) unlimited -f: file size (blocks) unlimited -d: data seg size (kbytes) unlimited -s: stack size (kbytes) 8192 -c: core file size (blocks) unlimited -m: resident set size (kbytes) unlimited -u: processes 62844 -n: file descriptors 4096 -l: locked-in-memory size (kbytes) 64 -v: address space (kbytes) unlimited -x: file locks unlimited -i: pending signals 62844 -q: bytes in POSIX msg queues 819200 -e: max nice 0 -r: max rt priority 0 -N 15: unlimitedBTW I don't need to compile it myself. It also fails with the latest RC.
That's not too different from my setup. What do the stack traces in gdb look like? What happens with a debug build? (
make -j8 -C out BUILDTYPE=Debug)#0 0x0000000000b850e8 in v8::internal::IncrementalMarking::ActivateIncrementalWriteBarrier() () #1 0x0000000000b85334 in v8::internal::IncrementalMarking::StartMarking() () #2 0x0000000000b855bf in v8::internal::IncrementalMarking::Start(char const*) () #3 0x0000000000b5b82b in v8::internal::ArrayBufferTracker::RegisterNew(v8::internal::JSArrayBuffer*) () #4 0x0000000000c52de3 in v8::internal::JSArrayBuffer::SetupAllocatingData(v8::internal::Handle<v8::internal::JSArrayBuffer>, v8::internal::Isolate*, unsigned long, bool, v8::internal::SharedFlag) () #5 0x00000000008d29fb in v8::internal::Builtin_ArrayBufferConstructor_ConstructStub(int, v8::internal::Object**, v8::internal::Isolate*) () #6 0x00002cfb9f10959b in ?? () #7 0x0000000000000000 in ?? ()It doesn't crash with a debug build.
Is the stack trace always the same? Maybe you can add some printf statements to
IncrementalMarking::ActivateIncrementalWriteBarrier()to find out exactly where in the function it's crashing?Just to be sure, it dies with a SIGSEGV, not e.g. a SIGILL? Did you check the disassembly and the registers at the crash site?
Does that mean
lop == nullptrright before the call toSetOldSpacePageFlags? Can you add a printf to check?Does that mean lop == nullptr right before the call to SetOldSpacePageFlags? Can you add a printf to check?
Yes
void IncrementalMarking::ActivateIncrementalWriteBarrier() { PrintF("ActivateIncrementalWriteBarrier\n"); ActivateIncrementalWriteBarrier(heap_->old_space()); ActivateIncrementalWriteBarrier(heap_->map_space()); ActivateIncrementalWriteBarrier(heap_->code_space()); ActivateIncrementalWriteBarrier(heap_->new_space()); LargePage* lop = heap_->lo_space()->first_page(); while (lop->is_valid()) { PrintF(lop->is_valid() ? "valid\n" : "not valid\n"); PrintF(lop == nullptr ? "null\n" : "not null\n"); SetOldSpacePageFlags(lop, true, is_compacting_); lop = lop->next_page(); } }
% ./node --trace-incremental-marking > var x = new buffer.SlowBuffer(buffer.kMaxLength) [IncrementalMarking] Start (external memory allocation limit reached.) [IncrementalMarking] Start marking ActivateIncrementalWriteBarrier valid null [1] 1515 segmentation fault (core dumped) ./node --trace-incremental-markingI think you're hitting undefined behavior in V8. The
lop->is_valid()method is essentially athis != nullptrcheck, which is undefined behavior according to the spec becausethisis never allowed to be null. I speculate the compiler optimizes away the check completely at-O2and higher.The reason you're seeing crashes and I don't is presumably because I haven't upgraded my copy of g++ yet. For the record, here is what I'm currently building with:
$ g++ -v Using built-in specs. COLLECT_GCC=/usr/bin/g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 5.3.1 20160406 (Red Hat 5.3.1-6) (GCC)Yeah I was also thinking about a difference of compilers. This is my version:
% g++ -v Using built-in specs. COLLECT_GCC=/usr/bin/g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.0.0/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 6.0.0 20160406 (Red Hat 6.0.0-0.20) (GCC)So is this a bug on V8's side ? With the following patch, all our tests pass again:
diff --git a/deps/v8/src/heap/incremental-marking.cc b/deps/v8/src/heap/incremental-marking.cc index ce6f6ee..ab61576 100644 --- a/deps/v8/src/heap/incremental-marking.cc +++ b/deps/v8/src/heap/incremental-marking.cc @@ -404,7 +404,7 @@ void IncrementalMarking::DeactivateIncrementalWriteBarrier() { DeactivateIncrementalWriteBarrierForSpace(heap_->new_space()); LargePage* lop = heap_->lo_space()->first_page(); - while (lop->is_valid()) { + while (lop != nullptr) { SetOldSpacePageFlags(lop, false, false); lop = lop->next_page(); } @@ -436,7 +436,7 @@ void IncrementalMarking::ActivateIncrementalWriteBarrier() { ActivateIncrementalWriteBarrier(heap_->new_space()); LargePage* lop = heap_->lo_space()->first_page(); - while (lop->is_valid()) { + while (lop != nullptr) { SetOldSpacePageFlags(lop, true, is_compacting_); lop = lop->next_page(); }
I think that explains it. I'd report it to V8.
18 remaining items
make testoutput:test/parallel/test-buffer-slow.jssegfaults atSlowBuffer(buffer.kMaxLength)test/parallel/test-fs-read-buffer-tostring-fail.jsatfs.read(fd, kStringMaxLength + 1, ...test/parallel/test-fs-readfile-tostring-fail.jssimilarly atfs.readFile(file, ...)Is there anything I can do to investigate this issue ?