FATAL ERROR: v8::ArrayBuffer::Neuter Only externalized ArrayBuffers can be neutered

[ghost]

I keep getting this error "FATAL ERROR: v8::ArrayBuffer::Neuter Only externalized ArrayBuffers can be neutered" when I run "tns platform add ios" or "tns platform add android"

[svc76]

+1, i have tried npm i -g tns-ios to reinstall things but it still fails.

xcode version 7.1 (7B91b)
tns doctor reports no issues

[Trott]

@samb90 @charismsft What version of Node?

[Trott]

I'm able to reproduce this error with node 5.0.0 but reverting to node 4.2.1 fixes it.

Chances are you need to wait for https://github.com/NativeScript/nativescript-cl to be updated to work with node 5.0.0 but that's just a guess. I would recommend watching and/or commenting on NativeScript/nativescript-cli#1129.

[ghost]

I'm on Node 5.0.0. I'll try an older version of node and report back

[svc76]

how do i revert back to 4.2.1?

[unbornchikken]

We're having this error when compiling node-ffi on 5.0.0. Haven't found anything about this in the changelog. Is it an issue of node side, or should we (native module developers) change something in our codebase to work around this?

[bnoordhuis]

/cc @indutny - looks like 931118c is responsible.

[Trott]

@charismsft That depends on how you installed it in the first place. I would recommend opening an issue in https://github.com/nodejs/help/issues explaining what OS you are running and how you installed it.

[indutny]

@bnoordhuis patched 4.x version (with 931118c) works fine, however 5.x is broken.

The question is does everyone experiencing the problem here installed node from the website? If so - may I ask you to try building it from source and testing again?

[Trott]

@indutny:

• Current master (b7cc19c) still results in the error
• 931118c does not result in the error

[indutny]

@Trott is there an easy way to reproduce it?

[Trott]

I was doing something like this from the topmost dir in the repo clone:

$ export PATH=`pwd`:${PATH}
$ ./configure && make
...
$ npm uninstall -g nativescript
...
$ npm install -g nativescript --nodedir=`pwd`
...
$ tns platform

Running git bisect right now to try to identify the commit that causes the issue to show up.

[indutny]

Thanks.

[Trott]

I had to skip one commit because it did not build cleanly, but it's either d8011d1 or 7fb128d.

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
d8011d1683fe0d977de2bea1147f5213d4490c5a
7fb128d8dff0e690e2c31b3bc192c027932a4608
We cannot bisect more!

I guess it's not surprising that it would be triggered by a v8 upgrade.

[indutny]

Looking... I think I'm close to it.

[indutny]

Gosh:

 frame #0: 0x00000001007d4823 node`v8::internal::JSArrayBuffer::set_backing_store(this=0x00000c5a5b74e0e1, value=0x0000000102500000, mode=UPDATE_WRITE_BARRIER) + 35 at objects-inl.h:6464
    frame #1: 0x00000001007d4a97 node`v8::internal::JSTypedArray::MaterializeArrayBuffer(typed_array=Handle<v8::internal::JSTypedArray> @ 0x00000001059fe360) + 311 at objects.cc:15584
    frame #2: 0x00000001007d4cb3 node`v8::internal::JSTypedArray::GetBuffer(this=0x00000c5a5b74e121) + 163 at objects.cc:15611
    frame #3: 0x0000000100258e1d node`v8::ArrayBufferView::Buffer(this=0x00000001059fe880) + 333 at api.cc:6585
    frame #4: 0x0000000100af4ed1 node`node::Buffer::Data(obj=(val_ = 0x00000001059fe880)) + 113 at node_buffer.cc:192
    frame #5: 0x00000001049ce0f9 binding.node`(anonymous namespace)::WritePointer(info=0x00000001059fe4c8) + 468 at binding.cc:291
    frame #6: 0x00000001049cf158 binding.node`Nan::imp::FunctionCallbackWrapper(info=0x00000001059fe510) + 131 at nan_callbacks_12_inl.h:174
    frame #7: 0x000000010028766c node`v8::internal::FunctionCallbackArguments::Call(this=0x00000001059fe660, f=(binding.node`Nan::imp::FunctionCallbackWrapper(v8::FunctionCallbackInfo<v8::Value> const&) at nan_callbacks_12_inl.h:167))(v8::FunctionCallbackInfo<v8::Value> const&)) + 124 at arguments.cc:33
    frame #8: 0x00000001002d2c5c node`v8::internal::MaybeHandle<v8::internal::Object> v8::internal::HandleApiCallHelper<false>(isolate=0x0000000102804600, args=0x00000001059fe7d8)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>&) + 1452 at builtins.cc:1010
    frame #9: 0x00000001002ddb6b node`v8::internal::Builtin_Impl_HandleApiCall(args=v8::internal::(anonymous namespace)::HandleApiCallArgumentsType @ 0x00000001059fe7d8, isolate=0x0000000102804600)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>, v8::internal::Isolate*) + 139 at builtins.cc:1033
    frame #10: 0x00000001002d32a0 node`v8::internal::Builtin_HandleApiCall(args_length=5, args_object=0x00000001059fe898, isolate=0x0000000102804600) + 80 at builtins.cc:1029

[indutny]

Fix:

diff --git a/src/node_buffer.cc b/src/node_buffer.cc
index 7d428b2..f987c04 100644
--- a/src/node_buffer.cc
+++ b/src/node_buffer.cc
@@ -187,6 +187,8 @@ char* Data(Local<Value> val) {
 char* Data(Local<Object> obj) {
   CHECK(obj->IsUint8Array());
   Local<Uint8Array> ui = obj.As<Uint8Array>();
+  if (!ui->HasBuffer())
+    return nullptr;
   ArrayBuffer::Contents ab_c = ui->Buffer()->GetContents();
   return static_cast<char*>(ab_c.Data()) + ui->ByteOffset();
 }

@Trott mind giving it a try?

[indutny]

Will continue looking into it once I'll return back to computer.

[indutny]

Actually, I think this fix is correct. I'll write a test for it, should be easy thing.

[Trott]

@indutny That change fixes it for me.

[EverybodyKurts]

Hello all, I am experiencing this issue as well. Why was this issue closed?

[Trott]

It's closed because it has been fixed on the master branch.

However it has not been part of a release yet.

Look for it in version 5.1.0 which seems likely to come out this week.