intermittent fatal erros

[gregtillbrook]

Hi, Ive been getting the following errors intermittently when building sass;

node(14524,0x1017bb000) malloc: *** mmap(size=1152921504876556288) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
terminate called throwing an exceptionAbort trap: 6

Not very helpful - but with some help from a issue I raised in node-sass I was able to get the following stack trace;

0 0x00007fff8a32dce2 in pthread_kill ()
1 0x00007fff8bcf57d2 in pthread_kill ()
2 0x00007fff8bce6a7a in abort ()
3 0x00007fff9141e7bc in abort_message ()
4 0x00007fff9141bfcf in default_terminate ()
5 0x00007fff8885b1cd in _objc_terminate ()
6 0x00007fff9141c001 in safe_handler_caller ()
7 0x00007fff9141c05c in std::terminate ()
8 0x00007fff9141d152 in __cxa_throw ()
9 0x00007fff848e8255 in std::throw_length_error ()
10 0x00007fff8490e84e in std::string::_Rep::_S_create ()
11 0x00007fff849102fa in std::string::_S_construct ()
12 0x00007fff849104a8 in std::basic_string, std::allocator >::basic_string ()
13 0x000000010172c0f8 in Sass::Token::to_string () at :68
14 0x000000010172c0f8 in Sass::Node::to_string (this=0x7fff8bd0f711, inside_of=Sass::Node::none) at ../libsass/node_emitters.cpp:68
15 0x000000010172f5d1 in std::string::data () at ../libsass/node_emitters.cpp:390
16 0x000000010172f5d1 in std::string::_M_data () at /usr/include/c++/4.2.1/bits/basic_string.h:2413
17 0x000000010172f5d1 in std::operator<< , std::allocator > () at /usr/include/c++/4.2.1/bits/basic_string.h:1542
18 0x000000010172f5d1 in Sass::Node::emit_nested_css (this=0x102844e88, buf=@0x1017ba708, depth=1, at_toplevel=false, in_media_query=true) at ../libsass/node_emitters.cpp:390
19 0x000000010172fa13 in std::operator<< std::char_traits () at /usr/include/c++/4.2.1/ostream:427
20 0x000000010172fa13 in Sass::Node::emit_nested_css (this=0x10300bf28, buf=@0x1017ba708, depth=, at_toplevel=, in_media_query=false) at ../libsass/node_emitters.cpp:428
21 0x000000010172f4df in Sass::Node::emit_nested_css (this=0x1017bac58, buf=@0x1017ba708, depth=0, at_toplevel=true, in_media_query=false) at ../libsass/node_emitters.cpp:379
22 0x0000000101709787 in std::basic_stringstream, std::allocator >::str () at /usr/include/c++/4.2.1/sstream:133
23 0x0000000101709787 in Sass::Document::emit_css (this=, style=) at ../libsass/document.cpp:141
24 0x0000000101733581 in std::string::_M_rep () at ../libsass/sass_interface.cpp:51
25 0x0000000101733581 in std::string::_M_data () at /usr/include/c++/4.2.1/bits/basic_string.h:605
26 0x0000000101733581 in std::string::size () at /usr/include/c++/4.2.1/bits/basic_string.h:287
27 0x0000000101733581 in process_document (doc=@0x1017bac20, style=0) at ../libsass/sass_interface.cpp:52
28 0x0000000101733157 in sass_compile (c_ctx=0x102800140) at ../libsass/sass_interface.cpp:65
29 0x00000001000462a8 in etp_proc ()
30 0x00007fff8bcf38bf in _pthread_start ()
31 0x00007fff8bcf6b75 in thread_start ()

Does that provide enough info to be of help?

Im running on a Mac - OS X 10.7.5
Im auto building sass with 'grunt watch' using -> grunt-sass which wraps -> node-sass which wraps -> libsass

[craigbarnes]

Does grunt-sass or node-sass use threads? The backtrace starts and ends with pthread calls but it's not clear where they're coming from. Also, in your node-sass issue you said it happens "roughly once in every 10 runs". That sounds consistent with a race condition to me.

What does thread apply all backtrace give you?

[akhleung]

Also, are you actually running LibSass, or just buiding it? (I've tried to make LibSass re-entrant.)

[gregtillbrook]

Hi again, sorry for slow reply, I was away the past few days.

I don't believe grunt-sass or node-sass use threads, they're both just very thin javascript wrappers around libsass. Ive not compiled LibSass either, all Im doing is using grunt-sass in my automated grunt build, this then includes node-sass which wraps a built libsass I believe (I'll double check that - havent poked around inside them too much yet).

Here's a new trace using 'thread apply all backtrace'.

Thread 3 (process 6593):
0 0x00007fff8aa99ce2 in __pthread_kill ()
1 0x00007fff859787d2 in pthread_kill ()
2 0x00007fff85969a7a in abort ()
3 0x00007fff83fa77bc in abort_message ()
4 0x00007fff83fa4fcf in default_terminate ()
5 0x00007fff8539a1cd in _objc_terminate ()
6 0x00007fff83fa5001 in safe_handler_caller ()
7 0x00007fff83fa505c in std::terminate ()
8 0x00007fff83fa6152 in __cxa_throw ()
9 0x00007fff87962255 in std::__throw_length_error ()
10 0x00007fff8798884e in std::string::_Rep::_S_create ()
11 0x00007fff8798a2fa in std::string::_S_construct<char const*> ()
12 0x00007fff8798a4a8 in std::basic_string<char, std::char_traits, std::allocator >::basic_string ()
13 0x0000000100f690f8 in Sass::Token::to_string () at :68
14 0x0000000100f690f8 in Sass::Node::to_string (this=0x7fff85992711, inside_of=Sass::Node::none) at ../libsass/node_emitters.cpp:68
15 0x0000000100f6c5d1 in std::string::data () at ../libsass/node_emitters.cpp:390
16 0x0000000100f6c5d1 in std::string::_M_data () at /usr/include/c++/4.2.1/bits/basic_string.h:2413
17 0x0000000100f6c5d1 in std::operator<< <char, std::char_traits, std::allocator > () at /usr/include/c++/4.2.1/bits/basic_string.h:1542
18 0x0000000100f6c5d1 in Sass::Node::emit_nested_css (this=0x100a5c088, buf=@0x100ff7708, depth=1, at_toplevel=false, in_media_query=true) at ../libsass/node_emitters.cpp:390
19 0x0000000100f6ca13 in std::operator<< std::char_traits () at /usr/include/c++/4.2.1/ostream:427
20 0x0000000100f6ca13 in Sass::Node::emit_nested_css (this=0x10101d528, buf=@0x100ff7708, depth=<value temporarily unavailable, due to optimizations>, at_toplevel=<value temporarily unavailable, due to optimizations>, in_media_query=false) at ../libsass/node_emitters.cpp:428
21 0x0000000100f6c4df in Sass::Node::emit_nested_css (this=0x100ff7c58, buf=@0x100ff7708, depth=0, at_toplevel=true, in_media_query=false) at ../libsass/node_emitters.cpp:379
22 0x0000000100f46787 in std::basic_stringstream<char, std::char_traits, std::allocator >::str () at /usr/include/c++/4.2.1/sstream:133
23 0x0000000100f46787 in Sass::Document::emit_css (this=<value temporarily unavailable, due to optimizations>, style=<value temporarily unavailable, due to optimizations>) at ../libsass/document.cpp:141
24 0x0000000100f70581 in std::string::_M_rep () at ../libsass/sass_interface.cpp:51
25 0x0000000100f70581 in std::string::_M_data () at /usr/include/c++/4.2.1/bits/basic_string.h:605
26 0x0000000100f70581 in std::string::size () at /usr/include/c++/4.2.1/bits/basic_string.h:287
27 0x0000000100f70581 in process_document (doc=@0x100ff7c20, style=0) at ../libsass/sass_interface.cpp:52
28 0x0000000100f70157 in sass_compile (c_ctx=0x100e00530) at ../libsass/sass_interface.cpp:65
29 0x00000001000462a8 in etp_proc ()
30 0x00007fff859768bf in _pthread_start ()
31 0x00007fff85979b75 in thread_start ()

Thread 2 (process 6593):
0 0x00007fff8aa986b6 in semaphore_wait_trap ()
1 0x000000010027484a in v8::internal::RuntimeProfiler::WaitForSomeIsolateToEnterJS ()
2 0x000000010027495a in v8::internal::RuntimeProfilerRateLimiter::SuspendIfNecessary ()
3 0x00000001002fb9bd in v8::internal::SamplerThread::Run ()
4 0x00000001002fb384 in v8::internal::ThreadEntry ()
5 0x00007fff859768bf in _pthread_start ()
6 0x00007fff85979b75 in thread_start ()

Thread 1 (process 6593):
0 0x00007fff8aa9a7e6 in kevent ()
1 0x000000010004c2a9 in kqueue_poll ()
2 0x0000000100043828 in uv__run ()
3 0x0000000100043763 in uv_run ()
4 0x00000001000090c3 in node::Start ()
5 0x0000000100001144 in start ()

[QuLogic]

Does grunt-sass or node-sass use threads? The backtrace starts and ends with pthread calls but it's not clear where they're coming from. Also, in your node-sass issue you said it happens "roughly once in every 10 runs". That sounds consistent with a race condition to me.

Note the output mmap(size=1152921504876556288), and that the pthread calls actually go down to a throw() in basic_string. It looks like Sass::Node::to_string is called on a Token with begin and end that are wildly incorrect. Now, whether that's due to a parsing issue or some thread corrupting things, I have no idea, but I thought I'd just point that out.

[akhleung]

@gregtillbrook Can you provide a copy of the Sass stylesheets that you're trying to compile? Then I can test them myself and try to reproduce the problem -- it could be that there's a null pointer dereference that I haven't caught.

[gregtillbrook]

I cant provide the exact same sass as technically my client owns it and its not mine to share. I'll make a generic sample that reproduces the same problem (bare with me though as this week is looking like a busy one..)

How would like me to send it to you? Email or just paste it here?

[akhleung]

A generic sample that reproduces the crash should be fine -- just post it here, if you can. Thanks!

[gregtillbrook]

Sorry about the lack of response. I did at the time try to create a simplified case but without success. Since then Ive moved project and then job so this issue is no longer affecting me - so i'll close this issue.

Thanks a lot for all your help!