You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
sassc-ruby supports passing custom functions to libsass as ruby functions, for example it is used in sassc-rails to define url. Generally, this mechanism is memory-safe, but if custom function raises an exception that is not a subclass of StandardError, such as SystemStackError, segmentation fault happens.
Function wrapper catches only StandardError. If non-StandardError exception occurs, ffi gem ignores exception in FFI::Function's block and behaves like the function is returned nil.
Maybe this can be fixed by just catching all exceptions:
--- a/lib/sassc/functions_handler.rb 2024-07-01 17:12:43.522095555 +0300+++ b/lib/sassc/functions_handler.rb 2024-07-01 16:37:31.255145300 +0300@@ -25,7 +25,7 @@
function_arguments = arguments_from_native_list(native_argument_list)
result = functions_wrapper.send(custom_function, *function_arguments)
to_native_value(result)
- rescue StandardError => exception+ rescue Exception => exception
# This rescues any exceptions that occur either in value conversion
# or during the execution of a custom function.
error(exception.message)
It works for my case, catching "stack level too deep" and converting to sass compilation error, but I'm not sure if it's overall a good idea to catch non-StandardError exceptions and what consequences might it cause, especially when working near ffi boundaries. Maybe calling Kernel#abort in case of non-StandardError is a better idea.
The text was updated successfully, but these errors were encountered:
Maybe calling Kernel#abort in case of non-StandardError is a better idea.
Tried it, it does not abort ruby process immediately, it also causes ffi callback function to return with null pointer. So first, error message is printed and then segfault still happens.
I don't know a proper way to abort inside ffi callbacks, so maybe just rescuing all exceptions with the same handler that returns error value is okay.
kolen
linked a pull request
Jul 2, 2024
that will
close
this issue
sassc-ruby
supports passing custom functions tolibsass
as ruby functions, for example it is used insassc-rails
to defineurl
. Generally, this mechanism is memory-safe, but if custom function raises an exception that is not a subclass ofStandardError
, such asSystemStackError
, segmentation fault happens.This example causes segmentation fault by causing custom function to raise
SystemStackError
by infinite recursive call:Function wrapper catches only
StandardError
. If non-StandardError
exception occurs,ffi
gem ignores exception inFFI::Function
's block and behaves like the function is returnednil
.sassc-ruby/lib/sassc/functions_handler.rb
Lines 22 to 33 in 4fce2b6
libsass
requires return value from custom function to be a valid pointer toSass_Value
. This return value is then passed tosass_value_get_tag
, which tries to dereference null pointer.https://github.com/sass/libsass/blob/8d312a1c91bb7dd22883ebdfc829003f75a82396/src/eval.cpp#L1107-L1108
https://github.com/sass/libsass/blob/8d312a1c91bb7dd22883ebdfc829003f75a82396/src/sass_values.cpp#L16-L17
This might be cause of #133, #197, #207 (unsure).
Maybe this can be fixed by just catching all exceptions:
It works for my case, catching "stack level too deep" and converting to sass compilation error, but I'm not sure if it's overall a good idea to catch non-
StandardError
exceptions and what consequences might it cause, especially when working near ffi boundaries. Maybe callingKernel#abort
in case of non-StandardError
is a better idea.The text was updated successfully, but these errors were encountered: