Segmentation fault on "RAILS_ENV=production assets:precompile"

[icr4]

/home/icra/.gem/ruby/2.5.0/gems/sassc-2.0.1/lib/sassc/engine.rb:42: [BUG] Segmentation fault at 0x0000000000000000 ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux-gnu]

-- Control frame information ----------------------------------------------- c:0065 p:---- s:0385 e:000384 CFUNC :compile_data_context c:0064 p:0298 s:0380 e:000379 METHOD /home/icra/.gem/ruby/2.5.0/gems/sassc-2.0.1/lib/sassc/engine.rb:42

--- EDIT ---- Excluding CSS files one by one i discovered the problem is my "style.css", but it has no errors, and the stacktrace is not appointing it so i can understand the error. The CSS compiles well on another project using same version of sass-c. I tried creating a new rails app and it still crashes.

[bolandrm]

Hi, could you make style.css available so that someone might try to reproduce and fix the issue?

[ahorek]

Hi, I have the same problem.

test.css

/*
 *= require_self
*/

div {
    background: image-url('arrow.gif');
}

but if I put that into an .scss file it works fine, that could be a workaround for you.

[icr4]

Hi, I have the same problem.

test.css

/*
 *= require_self
*/

div {
    background: image-url('arrow.gif');
}

but if I put that into an .scss file it works fine, that could be a workaround for you.

They already are .scss, i solved switching back to 'sass-rails' temporarily hoping the problem will get fixed soon.

[halo]

I encounter this with the follwoing .sass file (not.scss)

@font-face
  // If i comment out the following line, there is no segfault
  src: asset-url('some_custom_font.woff') format('woff')

It reminds me of this issue that caused a segfault whenever a pipeline helper was called.

• sprockets 4.0.0.beta9
• rails 6.0.0.rc1
• Ruby 2.6.1
• sassc 2.0.1
• sassc-rails 2.1.2

EDIT This appeared after a bundle update, so I tried to find the culprit by upgrading the mentioned gems one by one. After I did that, the segfault now disappeared. Weird. But I'm happy now ;)

EDIT2 I still have this problem, but intermittently. The problem disappears when I make modifications to SASS in another file, at some other place in the stylesheet assembly. If I make more changes, the problem is back. If I change something, it's gone again. I have not been able to reproduce it reliably though.

[ozgg]

I have this problem too, and it's hard to reproduce it. It happens unexpectedly with different projects and disappears, when I update any file used (just add blank line to any scss file, for example). And it doesn't appear again even after I remove that blank line.

[jkwuc89]

I am getting this segmentation fault consistently within the Rails project I am working on. It results from running: `NODE_ENV=production RAILS_ENV=production bundle exec dotenv 'bin/rails assets:precompile'. The dump/stack trace is attached.

I am using:

• Ruby 2.5.5
• Rails 6.0.0
• macOS Catalina
• Xcode 11 with command line tools installed

sassc_crash_stack_trace.txt

[kernow]

I'm seeing the same issue when precompiling assets on deployment.

• sprockets 4.0.0
• rails 5.2.3
• Ruby 2.5.5
• sassc 2.2.1
• sassc-rails 2.1.2

I only saw this issue after upgrading from sprockets 3.7.2 to 4.0.0. Revert back to sprockets 3.7.2 and the issue goes away.

[adesurirey]

Same issue running RAILS_ENV=production bundle exec rake assets:precompile with Travis CI.

• rails 6.0.1
• sprockets 4.0.0
• Ruby 2.6.5
• sassc 2.2.1
• sassc-rails 2.1.2

[martinezcoder]

I had the same issue upgrading to sass-rails 6.0.0 and finally I fixed it using sprockets 4.

• ruby 2.6.5
• rails 6.0.1
• sass-rails 6.0.0
• sprockets 4.0.0

There is something that is told indirectly in the sprockets upgrading readme:

# In your Rails configuration, prior to Sprockets 4
config.assets.precompile += ["marketing.css"]

This kind of configuration is necessary only if you are using a prior version of Sprockets 4. The upgrading documentation is not warning about the need to remove those kind of lines, but at least in my case, removing them and adding that dependencies in the manifest.js file has fixed the issue.

This post was very useful to understand the changes between versions.

[epipheus]

I've tried with with every permutation I can think of sassc and sass-rails with no love. using manifest.js already. works in dev, no clue why not in production. Attached the vomit from the crash.

precompile.out.txt

[epipheus]

Also, just a note, this was all working on rails 6.0.1 with manifests and gemified assets so I'm sure they aren't the cause, which really make this perplexing for me. sassc I think is the only thing that changed. For some stupid reason I removed the version from my Gemfile. Looking through git for where it went wrong.

[epipheus]

Not getting a useful error msg and instead getting a segfault can be quite annoying. Is anyone from sassc-rails going to actually comment? OP filed in May, it's almost Dec. Is there anything you need from us to shed more light? How can we get help?

[ozgg]

@epipheus I think the problem is that nobody can reliably reproduce this error, so comments from the team won't help either. The only information everyone has is: sometimes it unexpectedly crashes and the next consequent time it works.

[epipheus]

Can I ask this? what's the difference between doing rails assets:precompile in dev vs prod mode? Why would the outcome be different in those environments? Maybe if we understand that we can sort it out.

[ozgg]

I get crashes for both development and production environments. The only difference is that dev crashes until I change any scss file, but for prod it crashes only once.

[epipheus]

hmm. i haven't flipped around to it working yet for me in production. Dev, no problem, as all. Even precompiles in dev without a hitch. which is super odd. OK, can I ask this, before we used sassc there are a pure ruby one right? took forever, but it existed I thought. How can we revert to that one? We should at least be able to fully trace right?

[epipheus]

I read somewhere there used to be a problem with concurrency for precompilation, the workaround of disabling concurrency didn't work for me and besides it's supposedly rolled into previous versions. I also went through and started taking out asset url helpers from my assets instead using scss variable and referencing from /assets. have asset references working in dev with that but still no precompilation love. I basically can't push needed changes to production because the deploy fails at asset compilation, which sucks. Anyone have any ideas?

[martinezcoder]

@epipheus

• What version of sprockets are you using? I guess you are using sprockets version 4

• Did you remove the lines using Rails.application.config.assets.precompile += [...] in your config/initializers/assets.rb?

• Are you adding your JS and CSS to app/assets/config/manifest.js following this guide?

If after doing all this is still not working, you can force your project to use sprockets version 3.7.2 and it should work.

[epipheus]

Yes, using 4.0.0 and I moved to manifest.js when I upgraded to rails 6.0.1. I will try sprockets 3.7.2. Manifests work in sprockets 3?

[epipheus]

Tried 3.7.2 and it partially precompiled, most progress yet, but still crashed; do you know if there is a combination of sprockets with sprockets-rails and sassc and sassc-rails version voodoo that works in particular?

[epipheus]

I don't know if this is helpful, but I can tell you how I tracked down my problem. Maybe it will help you, because I'm my case it was a ridiculous needle in the haystack. I used gemified assets on my large projects so it was particularly hard to track down especially since other projects used the same pack of assets. I went old-school and forked sassc-ruby and printed debug messages before the offending line.

Looking at my own segfault and others’, the offending line is almost always this line in the sassc-ruby engine

I went old-school and printed a few debug messages before the offending line

status = Native.compile_data_context(data_context)

As for instance variable, in my case:

• filename is almost always empty
• context and data_context, native_options all hold FFI pointers with the same address
• options almost always just has {style: :compressed} in it

Sadly the only useful instance variable seems to be template which holds the contents of the asset (css or scsss). Luckily enough for me it was a vendor css file with it’s name at the top. I went to that file exactly to see what was wrong and turns out that the file name was blah.css but it was edited to have asset_url helpers in it. Literally just renaming the file to blah.scss meant all of my assets compiled. And not just for sprockets 3.7.2 but for 4.0.0 as well.

I don’t have much experience binding C and Ruby but seems to me that we need to wrap sassc-ruby’s line:

status = Native.compile_data_context(data_context)

with something that can fail gracefully (?).

Also why aren’t file names non-empty/present? That would help people tremendously to have a mode like rails assets:precompile --verbose that simply prints the current asset being processed so we have a place to look for issues.

Lastly, given css is a subset of scss, would it be a bad idea to import all css as scss/sass, expecially if config.assets.css_compressor = :sass ?

[martinezcoder]

You went much deeply with the error than me... AFAIK, although the segmentation fault occurs in sassc-rails, I suspect that the problem starts earlier in sprockets and some kind of corner case of incompatibility with this sassc. If you see the file you shared ( precompile.out.txt ) before starting with sassc it was on sprockets-4.0.0/lib/sprockets/sass_compressor.rb:30 and sprockets-4.0.0/lib/sprockets/processor_utils.rb:84.

I am sorry to not having a technical explanation about the problem, but I could fix the problem with two different ways:

• Using a previous version of sprockets. In my case it worked fine with 3.7.2 or
• Removing all the Rails.application.config.assets.precompile += [...] and doing the work in the manifest.js. The problem in our code was that we had one Rails.application.config.assets.precompile += [...] that was not inserted in the manifest.js. So we removed the Rails.application.config.assets.precompile += [...] and inserted this JS in the manifest. And it worked for us.

For us, both options worked, so we decided to go with the second one because it was using sprockets 4.

But the easiest way to fix this issue is to downgrade to sprockets 3.7.2.

[epipheus]

Ahh, well I guess my segfault location changed. downgrading to 3.7.2 partially worked for me but it crash at like 42 of the sassc-ruby engine, which seems to also be the location of the OP's (@icra-zz) segfault as well.

/home/icra/.gem/ruby/2.5.0/gems/sassc-2.0.1/lib/sassc/engine.rb:42: [BUG] Segmentation fault at 0x0000000000000000 ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux-gnu] -- Control frame information ----------------------------------------------- c:0065 p:---- s:0385 e:000384 CFUNC :compile_data_context > c:0064 p:0298 s:0380 e:000379 METHOD /home/icra/.gem/ruby/2.5.0/gems/sassc-2.0.1/lib/sassc/engine.rb:42

I think my point here is that there probably is a way to eliminate a fair percentage of these with simply a message stating which asset we're on in the process when it fails. There are probably only a few choke points, with compilation likely being the major one. Is there not a way to try a ffi C function?

And btw, finding this needle in the haystack meant being able to use the latest version of all the component without a hitch. And I moderately stressed precompilation to see if it would appear again, it hasn't. It might not be sprocket's fault at all; it's possible, perhaps it's the joints and not the meat, so to speak.

I would bet, many of the segfaults die at line 42. of those that fall there a large percent probably could be completely eliminated by importing css as scss (certainly eliminates having helpers blow things up). I don't know about you guys but my large apps have a ton of assets. finding that needle is a real pain without basic information.

[ozgg]

I think it's not directly connected with the contents of assets. If I'll find time, I'll try to reproduce this with almost empty scss like body { font-size: 16px; }. In the very beginning of this thread there is an example with a very simple file.

[epipheus]

thanks.

[epipheus]

No wait dude, this is exactly what I described.

• Failure at sassc line 42 not sassc-rails

• the tiny code sample uses an asset url helper image-url which is not OK for css but is OK for scss

• instead of a graceful message it segfaults.

This is exactly what's I've just described. Changing it to scss is what makes it ok. I love to blame sprockets too, but I just don't think it is.

Hi, I have the same problem. test.css

/*
 *= require_self
*/

div {
    background: image-url('arrow.gif');
}

but if I put that into an .scss file it works fine, that could be a workaround for you.

They already are .scss, i solved switching back to 'sass-rails' temporarily hoping the problem will get fixed soon.

[epipheus]

literally if you import all css as scss which should work because it's a subset, this will disappear. hence the lack of a segfault when you rename it.

[ozgg]

Hmm. But I use only scss as extension and still get segfaults. And the only difference for me between production and development is production fails once and works the next time and development fails again and again until I change any scss-file (I usually just add whitespace).

[ozgg]

Or you mean that renaming them to css is the current solution?

[drusepth]

Here's another segfault log in case it's helpful in finding common denominators and tracing the problem here. Here's the full app in case you want to look up any other gems/etc, and this is the point in time when I first started seeing segfaults.

Seeing frequent-but-intermittent segfaults when precompiling assets in local and production after upgrading from Rails 5.2 to 6.0.

rails 6.0.2 sprockets 4.0.0 Ruby 2.6.3 sassc 2.2.1 sassc-rails 2.1.2

Edit: Downgrading to sprockets 3.7.2 seems to have avoided any future segfaults, but it would be nice to not have to be locked to an older version.