Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

intermittent fatal erros #61

Closed
gregtillbrook opened this Issue Nov 9, 2012 · 8 comments

Comments

Projects
None yet
4 participants

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

Contributor

craigbarnes commented Nov 9, 2012

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 commented Nov 9, 2012

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

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 ()

Contributor

QuLogic commented Nov 24, 2012

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.

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

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?

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

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!

@anlutro anlutro pushed a commit to alprs/libsass that referenced this issue Feb 2, 2015

@hcatlin hcatlin Merge pull request #61 from lunelson/issue-185
Add test for nested media query logical combination
b7dd8c3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment