v0.12.0 segmentation fault in new Buffer(string, encoding)

[zaro]

I have a simple C++ extension that worked fine on 0.10.X, and with the release of 0.12 I ported it to the new C++ addon interface. It works but it would quite often SEGV with the following stacktrace:

    Reading symbols from /home/zaro/.nvm/versions/v0.12.0/bin/node...done.
    [New LWP 29316]
    [New LWP 29317]
    [New LWP 29318]
    [New LWP 29319]
    [New LWP 29320]
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib64/libthread_db.so.1".
    Core was generated by `node test/test_strip.js'.
    Program terminated with signal SIGSEGV, Segmentation fault.
    #0  0x0000000000a2761c in void v8::internal::String::WriteToFlat<unsigned short>(v8::internal::String*, unsigned short*, int, int) ()
    (gdb) bt
    #0  0x0000000000a2761c in void v8::internal::String::WriteToFlat<unsigned short>(v8::internal::String*, unsigned short*, int, int) ()
    #1  0x00000000007973d6 in v8::String::Write(unsigned short*, int, int, int) const ()
    #2  0x0000000000be5896 in node::StringBytes::Write(v8::Isolate*, char*, unsigned long, v8::Handle<v8::Value>, node::encoding, int*) ()
    #3  0x0000000000bc03d2 in void node::Buffer::StringWrite<(node::encoding)3>(v8::FunctionCallbackInfo<v8::Value> const&) ()
    #4  0x00000000007a7498 in v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) ()
    #5  0x00000000007c7327 in v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) ()
    #6  0x0000128347d0740e in ?? ()

Initially I though I am messing up some memory in the C++ code, but after quite a lot of fiddling I managed to reproduce it with plain JS, and the problem seems to appear when Buffer is created from string with 'utf16-le' encoding( may occur with other encodings also, I used only this one).

Here are the two relevant files : https://gist.github.com/zaro/788a8fee8244d4ffc6f9 , also as zip here : https://foggly.net/public.php?service=files&t=79384320ca5afe8808f4d23163d565d3 .

Steps to reproduce:
1.unzip
2.

$ node -v
v0.12.0
$ node test/test_strip.js 
<a href="#"> linky link </a>
Segmentation fault (core dumped)

My node is installed trough nvm on Fedora 21.

I couldn't manage to reproduce the bug on a node with debug symbols, also by just adding comments or console.log() statements in both index.js and test_strip.js the bug disappears most of the time. For example if I comment everything below line 25 in index.js ( as it is irrelevant ) it is not triggered anymore.

[CGavrila]

I have tried this on Ubuntu 12.04 and I don't get a segmentation fault, but I do get a lot more output and a FAIL! at the end. Am I doing something wrong or is this just working for me? Is the FAIL! message supposed to be there? (didn't have time to check the source to see exactly what it's trying to do)

I am using node v0.12.0, downloaded through nvm as well.

What I get is:

cristian@blueberry:~/test_strip/test$ node test_strip.js 
<a href="#"> linky link </a>
sdfsd





sdfsd
sdfsd
<a href="#"> linky link </a>
'<a href="#"> linky link </a>' : '  linky link  ' ? '  linky link  ' == '<a href="#"> linky link </a>' -> 'false'
FAIL!

...and then the process just exists. Note that I get the exact same thing with v0.10.36.

[zaro]

Yes, FAIL is normal as this is not the full test, and since it is supposed to SEGV the actual result of the script is not important.

Incidentally I tried running this with iojs, and it didn't fail. Then I re-installed node 0.12.0 , and it is not failing again. So I am thinking is it possible that somehow nvm installed me an broken node the first time ...

[trevnorris]

@zaro Thanks for reporting. Please ping back if you manage to reproduce the issue again.

[zaro]

ok, I tried reproducing it on OS X, Fedora 20, and Fedora 21 VM and I couldn't. And given the fact that it occurs with 50% chance on my laptop, makes me think there is something wrong with my laptop.

[carlin-psvl]

Zaro, I can actually very reliably get this segfault to happen when using your htmlstrip-native module. In my case it happens if I rapidly attempt to strip the string "uyjkosyhdzsthopmg\n" alone or concatenated multiple times, though I am sure the exact content isn't relevant. My stack trace is roughly the same:

PID 24136 received SIGSEGV for address: 0x0
/home/user/repos/code/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x11f6)[0x7fcac9a251f6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfc90)[0x7fcacb248c90]
node(_ZN2v88internal6String11WriteToFlatItEEvPS1_PT_ii+0x28c)[0xa3efbc]
node(_ZNK2v86String5WriteEPtiii+0xd6)[0x79f096]
node(_ZN4node11StringBytes5WriteEPN2v87IsolateEPcmNS1_6HandleINS1_5ValueEEENS_8encodingEPi+0x3b6)[0xc0ce26]
node(_ZN4node6Buffer11StringWriteILNS_8encodingE3EEEvRKN2v820FunctionCallbackInfoINS3_5ValueEEE+0x2b2)[0xbe62e2]

This is Node 0.12.0 on x86_64 Kubuntu 14.10, if that's relevant.

[zaro]

@carlin-psvl can you provide somehow a file with a test. I will try to reproduce it again.
My testcase was very unstable, just adding comment to the JS file, or delete irrelevant lines, and the crash disappears. Also I notices it had nothng to do with the native(C++) module, as even with no calls to the C++ functions the problem persisted.