-
Notifications
You must be signed in to change notification settings - Fork 790
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Segfault #633
Comments
Looks like this could be the same issue sass/sassc-rails#122 |
I got the same error after upgrading to 4.0.0 but it is inconsistent. The consistent bug was stylesheet variables set in one sheet were not recognized:
After running Going back to 'sprockets', '3.7.2' fixed the problem. My setup when the error occurred ruby 2.6.4 |
We only see the segfault with |
Can confirm the segfault with |
I had a similar segmentation fault issue caused by |
Downgrading |
Removing this line from Rails.application.config.assets.precompile += %w(manifest.js) |
This does not resolve the problem for us, we followed the upgrade guide when upgrading which states to switch to using a manifest file https://github.com/rails/sprockets/blob/master/UPGRADING.md#manifestjs so never attempted to run it with |
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:
Sadly the only useful instance variable seems to be 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 Lastly, given css is a subset of scss, would it be a bad idea to import all css as scss/sass, expecially if |
After adding (and downgrading at same time) |
I just downgraded to 3.7.2 and it fixed things. I noticed before the memory dump the last line in the trace was coffee_script.rb. What else can we provide to help trace this? |
I also have this issue when using with sassc_rails. I need to access a variable that is defined in scss by a gem. Setting |
I've been able to repro this reliably on OSX. With sprockets 4.0.0, delete the Please let me know if you need any additional information. |
can confirm Segfault seeing on Rails 5.2.4.3 with Sprocket 4.0.2 ruby version 2.6.5. like the post said. i was running rspec with render_option |
I've experienced this issue with different rails projects with Docker on Linux, not on MacOS. For me, upgrading to sassc 2.4.0 solved the issue. |
Downgrading spockets to 3.7.2 also worked for me. |
Downgrading spockets to 3.7.2 also worked for me too. |
There's basically nothing I can do without an example app. I'll need an example app that reproduces the behavior (https://www.codetriage.com/example_app). Otherwise i'll need to close the issue. |
Might be related to #581 which has a PR |
Chiming in to say that this is an issue for me as well, using Ruby 2.6.6 and Rails 5.0.7. I'm on the latest version of Sprockets and sassc. I'm still getting segfaults when trying to run tests locally, even with the recommended fix to disable concurrent asset compilation. Also my Linux kernel is 5.4.72-microsoft-standard-WSL2. Piping back in to say that this may also prevent us from upgrading to the heroku-20 stack on Heroku, as that also uses Ubuntu 20.04, which appears to use Linux kernel version 5.4+ as the default. As for an example app, I can offer EBWiki - if you clone the repo and run |
For what it's worth, we needed to set Rails.application.config.assets.configure do |env|
env.export_concurrent = false
end I'm not sure what the difference is, but setting it in a one-liner did not make a difference. # THIS DOES NOT WORK
Rails.application.config.assets.export_concurrent = false |
Yes, I want to confirm that nesting that setting did in fact resolve the issue with segfaults. I'm honestly not sure why. |
Various suggestions to downgrade sprockets to fix a segfault crash: sass/sassc-ruby#207 sass/sassc-rails#122 rails/sprockets#633 We'll see if that fixes it for us. Refs: #2872
Various suggestions to downgrade sprockets to fix a segfault crash: sass/sassc-ruby#207 sass/sassc-rails#122 rails/sprockets#633 We'll see if that fixes it for us. Refs: #2872
@schneems you can find an example app here https://github.com/mvz/example-app-sprockets-crash (crafted by @mvz). |
Using Sassc and Sprockets seems somewhat prone to segmentation faults which seems to be a common issue with Sprockets 4. As per rails/sprockets#633 and sass/sassc-ruby#207, switching concurrent asset generation seems to resolve the problem. The unproven theory is that this reflects that Sprockets 4 uses threads which causes problems for sassc. A consequence of this is that asset pre-compilation may be slower than it could be.
Using Sassc and Sprockets seems somewhat prone to segmentation faults which seems to be a common issue with Sprockets 4. As per rails/sprockets#633 and sass/sassc-ruby#207, switching concurrent asset generation seems to resolve the problem. The unproven theory is that this reflects that Sprockets 4 uses threads which causes problems for sassc. A consequence of this is that asset pre-compilation may be slower than it could be.
Using Sassc and Sprockets seems somewhat prone to segmentation faults which seems to be a common issue with Sprockets 4. As per rails/sprockets#633 and sass/sassc-ruby#207, switching concurrent asset generation seems to resolve the problem. The unproven theory is that this reflects that Sprockets 4 uses threads which causes problems for sassc. A consequence of this is that asset pre-compilation may be slower than it could be.
Using Sassc and Sprockets seems somewhat prone to segmentation faults which seems to be a common issue with Sprockets 4. As per rails/sprockets#633 and sass/sassc-ruby#207, switching concurrent asset generation seems to resolve the problem. The unproven theory is that this reflects that Sprockets 4 uses threads which causes problems for sassc. A consequence of this is that asset pre-compilation may be slower than it could be.
Using Sassc and Sprockets seems somewhat prone to segmentation faults which seems to be a common issue with Sprockets 4. As per rails/sprockets#633 and sass/sassc-ruby#207, switching concurrent asset generation seems to resolve the problem. The unproven theory is that this reflects that Sprockets 4 uses threads which causes problems for sassc. A consequence of this is that asset pre-compilation may be slower than it could be.
I know this is old but came across this error today. The way I got it fixed was upgrading Sprockets to 4.2.1 as suggested here My setup:
|
I received a Segfault after upgrading to sprockets 4.0. I haven't gotten the error again, but I wanted to post it anyway. I'm not sure if this is the best spot for this, or if it needs to go under the
sassc
gem.System configuration
The text was updated successfully, but these errors were encountered: