search

irundaia / sbt-sassify

sbt-web plugin for Sass files
Apache License 2.0
68 stars 17 forks source link

Segfaulting on Mac OS X with Homebrew installed libsass 3.4.4 #21

Open schmitch opened 7 years ago

schmitch commented 7 years ago

Actually it looks like that sbt-sassify tries to load a libsass installed via homebrew which will result in segfaults when libsass v3.4.4 will be installed:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000014c5a5656, pid=3532, tid=0x0000000000006f03
#
# JRE version: Java(TM) SE Runtime Environment (8.0_131-b11) (build 1.8.0_131-b11)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.131-b11 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C  [libsass.dylib+0xe2656]  sass_option_get_include_path+0x10
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.

Memory Mapping is:

Register to memory mapping:

RAX=0x0000000000000000 is an unknown value
RBX=0x0000700012ef0708 is pointing into the stack for thread: 0x00007fbd6c016000
RCX=0x00000005c00029a0 is an oop
java.lang.String 
 - klass: 'java/lang/String'
RDX=0x0000000000000000 is an unknown value
RSP=0x0000700012eefcf0 is pointing into the stack for thread: 0x00007fbd6c016000
RBP=0x0000700012eefcf0 is pointing into the stack for thread: 0x00007fbd6c016000
RSI=0x0000000119d531f3 is at entry_point+307 in (nmethod*)0x0000000119d52e50
RDI=0x00007fbd717848e0 is an unknown value
R8 =0x000000075ff3f828 is an oop
java.lang.StringCoding$StringEncoder 
 - klass: 'java/lang/StringCoding$StringEncoder'
R9 =0x000000010000001c is an unknown value
R10=0x0000700012eefc50 is pointing into the stack for thread: 0x00007fbd6c016000
R11=0x000000014c5a5646: sass_option_get_include_path+0 in /usr/local/lib/libsass.dylib at 0x000000014c4c3000
R12=0x0000000000000001 is an unknown value
R13=0x0000000000000001 is an unknown value
R14=0x00000001173ce654: ffi_call+0x3f4 in /private/var/folders/7l/71g7frnd4zv1q4pzspdwwd2c0000gn/T/jna--690384987/jna3674340442953001969.tmp at 0x00000001173c1000
R15=0x71d1e21ed6c20052 is an unknown value

Reverting to 3.4.3 or uninstalling it fixes the issue.

It took me a while to figure it out that it will use the libsass that is loaded via homebrew.

Well I think we should actually add something to the readme that either libasss needs to be uninstalled or that the version should align with the tested versions.

irundaia commented 7 years ago

Urgh... I wasn't expecting the JVM to prefer the platform library over the bundled one. Do you perhaps know of a way that I can tell jna to only load the library located in the JAR? In my opinion it should not matter whether someone has libsass installed himself.

schmitch commented 7 years ago

(I wasn't expecting it, too I tought about 1000 other things, but never about the homebrew library..). hm... I'm not sure but I doubt there is no possible way to actually handle that. Actually I think when specifiying the library with the name: public static final SassLibrary INSTANCE = (SassLibrary)Native.loadLibrary(SassLibrary.JNA_LIBRARY_NAME, SassLibrary.class);

instead of a path, it will try to use the system library that might be in memory, but I'm not 100% sure about that I'm not really a big JNA user. (and I'm also not sure if there is a way to explicity use a library path?!)