Compiler segmentation fault

[kostya]

crystal eval '[1].bla'
crystal eval '[1] + 2'
crystal eval '"bla" + 1'

/usr/local/bin/crystal: line 6: 57378 Segmentation fault: 11 "$INSTALL_DIR/embedded/bin/crystal" "$@"
Crystal 0.5.7 [2568f87] (Fri Jan 2 23:29:49 UTC 2015)

hard to debug code because, on any typo segfault

[kostya]

hm, this is solved if i recompile crystal from sources (os x 10.9.1)

crystal --version 
Crystal 0.5.7 [2568f87] (Fri Jan  2 23:29:49 UTC 2015)

crystal eval '1 + :a'
/usr/local/bin/crystal: line 6: 61725 Segmentation fault: 11  "$INSTALL_DIR/embedded/bin/crystal" "$@"

./bin/crystal --version
Using compiled compiler at .build/crystal
Crystal 0.5.7 [88858cd] (четверг,  8 января 2015 г. 15:13:44 (UTC))

./bin/crystal eval '1 + :a'
Using compiled compiler at .build/crystal
Error in line 1: no overload matches 'Int32#+' with types Symbol
Overloads are:
 - Int32#+(other : Int8)
 - Int32#+(other : Int16)
 - Int32#+(other : Int32)
 - Int32#+(other : Int64)
 - Int32#+(other : UInt8)
 - Int32#+(other : UInt16)
 - Int32#+(other : UInt32)
 - Int32#+(other : UInt64)
 - Int32#+(other : Float32)
 - Int32#+(other : Float64)
 - Int32#+()

[asterite]

Yes, it's an issue that happens only on Mac osx. Apparently it's a bug in libunwind/llvm. If you build crystal 0.5.6 with optimizations the bug doesn't happen, but for some strange reason building 0.5.7 triggers the bug, so it's kind of hard to find a small code that reproduces the problem.

Julia has the same issue, timholy/IProfile.jl#14 (comment). They linked to a solution but we didn't have time to look into it.

As a workaround, like what you found, you can use a compiled compiler without optimizations.

[akaufmann]

Could this be related?

class Foo
  getter name

  def initialize(@name)
  end
end

def get(match)
  obj = nil

  if match
    obj = Foo.new("Foo")
  end

  obj
end

obj = get(true) # as Foo

# puts obj.name

# SEGV at `puts obj.name` if there is no `as Foo` at the end of `get(...)`

> crystal types segv.cr
> obj : Foo?

It seems to me that the question mark means that the type is not 100% clear at compile time (Nil or Foo)

Could this be the problem?

[asterite]

@akaufmann We believe the problem happens when the compiler tries to build the backtrace of an exception. In the case of a syntax error (I saw your previous comment but it somehow got deleted, maybe?) on the main file there is no backtrace so it works fine. When there is a semantic error a backtrace is built, and then it crashes. The backtrace I see (using the Console app) is:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libunwind.dylib                 0x00007fff9645d33b libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncodingRBPFrame(unsigned int, unsigned long long, libunwind::LocalAddressSpace&, libunwind::Registers_x86_64&) + 59
1   libunwind.dylib                 0x00007fff9645d2d1 libunwind::CompactUnwinder_x86_64<libunwind::LocalAddressSpace>::stepWithCompactEncoding(unsigned int, unsigned long long, libunwind::LocalAddressSpace&, libunwind::Registers_x86_64&) + 55
2   libunwind.dylib                 0x00007fff9645d269 libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::step() + 113
3   crystal                         0x000000010dc90422 *caller:Array(String) + 146

Now, this only happens on some builds, and in this case only in release mode. And it only happens on Mac, we never saw this error on linux.

If we see this thread you can see that the backtrace where they get the SEGV is the same, and it only happens on Mac. According to the last reply in that thread and the pointed solution, which points to a patch in libunwind, it does appear to be a bug in libunwind.

The thing is, it happens randomly. It didn't happen for 0.5.4. It did happen for 0.5.3, but we believe we weren't using a patch LLVM, and once we patched it (not for that bug, but for another one) it worked so we thought the problem was gone for good. We did check if it reappeared in 0.5.4, 0.5.5 and 0.5.6, and since it didn't, we (actually I :-P) forgot to check if it was broken in 0.5.7, but when I realized it the release was done.

I think we would need to include a patched version in our build system, manually applying the patch for libunwind, like what we do for LLVM.

As I'd like to think it, the good thing is that the bug is not on our side. But, the bad thing is that the bug is not on our side 😸

[akaufmann]

@asterite Thanks for your reply and your amazing work.

Yep, on Linux it shows me the exact error.

Ah man, this bug drives me nuts :-) Hard to find the real problem if you are just learning the language.

[asterite]

@kostya @akaufmann I just uploaded version 0.5.8. (luckily) It doesn't seem to have the bug this time. Could you try it?

Of course, I just released quickly so you (and we) don't get that ugly segfault, but I'll keep this issue open until we fix it by changing our build script.

[kostya]

fixed for me

[akaufmann]

Thanks Ary! Fixed for me too.