Crystal: LLVM LexicalScopes build exception when building with --release flag

[fridgerator]

I was able to build fine in OSX, however Ubuntu 16.04 is failing with this error:

remote: crystal: /var/cache/omnibus/src/llvm/llvm-3.8.1.src/lib/CodeGen/LexicalScopes.cpp:160: llvm::LexicalScope* llvm::LexicalScopes::getOrCreateRegularScope(const llvm::DILocalScope*): Assertioncast(Scope)->describes(MF->getFunction())' failed.`

Originally reported by @crisward here

Replicated by @hak8or and @matiasgarciaisaia. @matiasgarciaisaia mentioned that building with --no-debug works as a temporary workaround.

[crisward]

Has anyone tried build with --release on llvm 3.8.1 on mac? Mac ships with llvm 4.0, so this could be an llvm version issue.

[straight-shoota]

quote from @matiasgarciaisaia

It's really weird to see that /var/cache/omnibus/... there, given that the Crystal package doesn't install that.

It's really weird. That /var/cache/omnibus directory doesn't even exist on my machine and should never be created.

[konovod]

I have similar (but maybe not identical) problem:

crystal: /var/cache/omnibus/src/llvm/llvm-3.8.1.src/include/llvm/IR/DataLayout.h:513: uint64_t llvm::DataLayout::getTypeSizeInBits(llvm::Type*) const: Assertion `Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"' failed.
/usr/bin/crystal: line 102:  6027 Aborted                 (core dumped) "$INSTALL_DIR/embedded/bin/crystal" "$@"

https://travis-ci.org/konovod/linalg/builds/253769479
Maybe offtopic (and i still haven't found minimal example for reporting), but it also has /var/cache/omnibus and also appeared after 0.23.1 so i think worth mentioning.

[crisward]

I also don't have /var/cache/omnibus/ and get that error. Also this is very easy to reproduce.

# on Ubuntu 14.04
sudo apt-get install crystal
echo 'p "hello world"' > test.cr
crystal build test.cr --release

crystal: /var/cache/omnibus/src/llvm/llvm-3.8.1.src/lib/CodeGen/LexicalScopes.cpp:160: llvm::LexicalScope* llvm::LexicalScopes::getOrCreateRegularScope(const llvm::DILocalScope*): Assertion `cast<DISubprogram>(Scope)->describes(MF->getFunction())' failed.
/usr/bin/crystal: line 102: 16249 Aborted                 "$INSTALL_DIR/embedded/bin/crystal" "$@"

[RX14]

I don't find it confusing at all. It's telling you the location in the source file where the runtime assertion failed, doesn't mean the source file has to be there on the PC where it runs, because it's a compiled library. It's exactly the same as __FILE__ in crystal.

[straight-shoota]

@konovod This runs without --release, so it seems to be a different thing, still might as well be related. Perhaps it's an issue with liblapacke?
Does this error also appear on local builds? And is it present in 0.23.0 or the inofficial release of 0.23.1 (#4647)?

[straight-shoota]

@RX14 Ok, makes sense. I didn't expect LLVM to have such detailed internal debug info in a released binary^^

@crisward Even smaller example would be crystal eval --release 'p "hello world'

[RX14]

It appears to me that LLVM was manually compiled by the omnibus, instead of using a prebuilt version. By the appearance of assertion errors, it's probably not a release build either. It's likely a release build would simply not have these runtime checks.

[konovod]

Does this error also appear on local builds?

Still haven't managed to get it on local build. If assertions in llvm are present, perhaps this problem is unrelated.

[crisward]

Also

• crystal eval --release 'p "hello world"' --no-debug works
• crystal eval --release 'p "hello world"' fails

[crisward]

Not sure if this is relevant but the old llvm setup used to configure disable-assertions

https://github.com/crystal-lang/omnibus-crystal/commit/57e0ebcf5a04bdd205c85ae5ba125d659e8de2ca#diff-004ad5a5c6f368464daff6c7cbde83a5L26

[crisward]

Looks like setting CMAKE_BUILD_TYPE to debug makes it enable assertions otherwise it's in disabled. So probably not that then.

[RX14]

@crisward confusingly, I think that's the wrong branch: https://github.com/crystal-lang/omnibus-crystal/blob/current/config/software/llvm.rb

Still has assertions disabled, even though it's not a release build.

[crisward]

That version doesn't appear to have CMAKE_BUILD_TYPE set at all, though the docs don't indicate the default setting. Perhaps setting it to MinSizeRel would do the trick?

[ysbaddaden]

@RX14 you can compile LLVM in release mode yet keep assertions. It's a little slower, but still a good idea, as it will catch understandable errors, that would otherwise lead to segfaults that are hard to understand.

[ysbaddaden]

Which happened to me before. I couldn't understand an LLVM segfault, which was catched quickly by asterite which had assertions turned on.

[straight-shoota]

So, any idea what the failing assertion is telling us? :)

[konovod]

googling text of error shows some links:
https://github.com/rust-lang/rust/issues/17677 -> https://github.com/rust-lang/rust/issues/17201 ->

The bad stuff happens when a function with debuginfo is inlined at a call-site that has no associated debuginfo.

http://clang-developers.42468.n3.nabble.com/clang-compilation-error-on-adding-debug-flag-td4050831.html

LLVM will not crash immediately if you bypass this particular assertion, it will just generate bogus debug info somewhere.

[RX14]

@ysbaddaden I'm sure you can, but i'm not sure how that're relevant to this error: the omnibus repo shows that LLVM appears to be compiled in debug mode with assertions turned off. Which makes getting assertion errors more weird. Perhaps the latest commit of the omnibus doesn't exactly represent the state of the distributed package.

[RX14]

Interestingly, i've been noticing lots of bogus debug info in release builds, perhaps this is the cause and somehow we've never had assertions turned on before.

[bararchy]

So, right now I can't install latest Crystal in Arch Linux because of this bug crashing the compiler build in release mode, any fixes or tips to "baypass" this ?

[RX14]

@bararchy This has been limited to the omnibus compiler, and the crystal package in arch community is up to date. Are you using crenv perhaps?

[bararchy]

Nope, building crystal-git from AUR, which show me the same issue, I can post output also if needed

[bararchy]

Using /usr/bin/llvm-config [version=4.0.1]
g++ -c -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt  -o src/llvm/ext/llvm_ext.o src/llvm/ext/llvm_ext.cc `/usr/bin/llvm-config --cxxflags`
cc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -fPIC  -D_FORTIFY_SOURCE=2  -c -o src/ext/sigfault.o src/ext/sigfault.c
ar -rcs src/ext/libcrystal.a src/ext/sigfault.o
./bin/crystal build --release  -o .build/crystal src/compiler/crystal.cr -D without_openssl -D without_zlib
crystal: /var/cache/omnibus/src/llvm/llvm-3.8.1.src/lib/CodeGen/LexicalScopes.cpp:160: llvm::LexicalScope* llvm::LexicalScopes::getOrCreateRegularScope(const llvm::DILocalScope*): Assertion `cast<DISubprogram>(Scope)->describes(MF->getFunction())' failed.
/tmp/yaourt-tmp-unshadow/aur-crystal-git/src/crystal-0.23.1-3/bin/crystal: line 102:  7853 Aborted                 (core dumped) "$INSTALL_DIR/embedded/bin/crystal" "$@"
make: *** [Makefile:117: .build/crystal] Error 134

[RX14]

@bararchy yes that package also uses the omnibus as it's bootstrap compiler

[megatux]

I tried again, after ElementaryOS updated the LLVM package from 3.8 to 4 but the issue still happen (w/crenv install). I don't know how the build works but the output still mention the llvm-3.8.x version.

[tosmi]

jm2c on this issue: i tried to build a newer version on freebsd and i used llvm 3.8 from ports. building 0.20.0 - 0.20.5 worked without problems but starting with 0.21.0 i got the assertion error. i had to recompile 0.20.5 with llvm 3.5.2, this fixed the issue for me. with llvm 3.5.2 i was able to compile crystal up to 0.23.1.

seems like as soon as you compile a version > 0.20.5 successful with llvm 3.8, the next build using this version will fail with the assertion error.

could run some more tests as freebsd comes with llvm 3.3/3.4/3.5/3.8/3.9 and 4.0 if required.

ah, and one final note: as far as i can see the --release flag was _not_ set.

[matiasgarciaisaia]

@RX14 @ysbaddaden the LLVM has been built using the current branch of omnibus-crystal. It may very well be that I've compiled it in debug mode instead of release.

Where is it that you see that _it appears to be compiled in debug mode with assertions turned off_? I can try re-building with the proper flags to see if this gets fixed.

[RX14]

@matiasgarciaisaia The cmake options leave CMAKE_BUILD_TYPE at it's default of Debug and set LLVM_ENABLE_ASSERTIONS=OFF.

[matiasgarciaisaia]

@RX14, @straight-shoota, everyone - here's a candidate re-build of 0.23.1, with the correct LLVM build settings: https://www.dropbox.com/sh/3m9xvwgt98w3dvi/AAAr3aM86c3ID3j5SwpMblJga?dl=0

Could you please try it and check if the issue is solved or not?

Thank you 👍

[straight-shoota]

@matiasgarciaisaia Looks good!
Seems like I rejoiced to early :/

[crisward]

I've tried this on ubuntu 14.04

crystal eval 'p "hello world"'
"hello world"

crystal eval --release --no-debug 'p "hello world"' 
"hello world"

crystal eval --release 'p "hello world"'
crystal: /var/cache/omnibus/src/llvm/llvm-3.8.1.src/lib/CodeGen/LexicalScopes.cpp:160: llvm::LexicalScope* llvm::LexicalScopes::getOrCreateRegularScope(const llvm::DILocalScope*): Assertion `cast<DISubprogram>(Scope)->describes(MF->getFunction())' failed.
/usr/bin/crystal: line 102:  7682 Aborted                 "$INSTALL_DIR/embedded/bin/crystal" "$@"

[ysbaddaden]

I guess we should hunt the issue that causes the LLVM assertion failure, and fix it?

[crisward]

Just googling the error brought these up - not sure if this helps

• http://lists.llvm.org/pipermail/llvm-bugs/2016-July/048519.html
• https://github.com/ldc-developers/ldc/issues/1032

[RX14]

It appears this is a problem with LLVM which is fixed in 4.0 (at the very least it's never appeared on archlinux).

[crisward]

The obvious solution would be to build agains v4.0, is there is a reason for not doing this? It seems to be available for ubuntu 14.

[ysbaddaden]

I've been compiling Crystal with LLVM 3.9 (from https://apt.llvm.org) for a long time and never hit this issue, either

That really looks like https://bugs.llvm.org/show_bug.cgi?id=28747 which got fixed in LLVM 3.9 apparently. Maybe omnibus should try LLVM 3.9.1? Or maybe 4.0.1 since 5.0.0 will be released soon.

[RX14]

git branch --contains 556fadaadab856d270ae7ecd38e24475e210d4f6 shows that the fix is only present in release_40, so if it works on 3.9 that's weird. Perhaps the fix was cherry-picked.

Looks like the fix was cherry-picked into LLVM 3.9 in 83c76e2427a852334afd0e9f709c4a5a4f6db01b.

[matiasgarciaisaia]

@ysbaddaden how confident you are this bug is caused by the one you linked?

I'll build Crystal with LLVM 4.0.1 and upload the packages here so we can test them 👍

[ysbaddaden]

I'd say something like 80%? The stacktrace and issue (broken debug) seem relevant, at least.

BTW: I'm incapable to reproduce the issue locally with LLVM 3.8 on Ubuntu Trusty, despite compiling and recompiling master with the llvm-3.8-dev package from Ubuntu repositories.

If you compile against LLVM 3.9+ you may enable the ARM target, too, while you're at it :-)

[totakaro]

If you compile against LLVM 3.9+ you may enable the ARM target, too, while you're at it :-)

ARM in releases page would be amazing :heart:

[RX14]

Now that #4872 and #4874 are merged, why don't we just scrap the current omnibus entirely and replace it with a statically compiled crystal omnibus. Should solve this issue at least.

[ysbaddaden]

Because of #4276: distributing a segfaulting compiler would be a bad experience ! Because of macOS, and other platforms could be added to omnibus.

[RX14]

@ysbaddaden It doesn't segfault for me. Must have been fixed somewhere along the line.

I know this because compiler errors (which are exceptions) work. Please try this out yourself though to verify.

[ysbaddaden]

A compiler linked statically against musl-libc won't segfault and appear to work... until it tries to unwind the stack. For example p caller will segfault.

[RX14]

@ysbaddaden yes but doesn't the compiler have to unwind the stack to raise compiler errors?

[matiasgarciaisaia]

Hi everyone!

I've been trying a couple of things, with not-very-good results.

I've started trying to build with LLVM 4.0.1, but it seems to require a GCC version newer than the ones our omnibus VMs have - so upgrading the VMs would mean we stop supporting Debian 7.

We _could_ change that VM to be an Ubuntu 14.04 to avoid loosing its support, but that'd mean building on Ubuntu instead of Debian - don't know what issues could come from that.

If you're thinking _let's just support latests OS versions_, recall what happened when we published 0.23.0 :P

I've then tried building with LLVM 3.9.1, which doesn't require upgrading gcc, but the resulting builds are hitting the same bugs (a inlinable function call in a function with debug info must have a !dbg location, actually, but I think it's the same thing):

vagrant@debian-7:~/kemal$ crystal build --release spec/all_spec.cr 
Module validation failed: inlinable function call in a function with debug info must have a !dbg location
  %4 = call i8* @__crystal_malloc(i32 ptrtoint (i1** getelementptr (i1*, i1** null, i32 1) to i32))

0x62b9fe: ??? at ??
0xdd2b90: ??? at ??
0xd485fe: ??? at ??
0x10a0ee5: ??? at ??
0x67c316: ??? at ??
0x65212c: main at ??
0x7fe259233ead: __libc_start_main at ??
0x62b209: ??? at ??

Error: you've found a bug in the Crystal compiler. Please open an issue, including source code that will allow us to reproduce the bug: https://github.com/crystal-lang/crystal/issues
vagrant@debian-7:~/kemal$ crystal build --release --no-debug spec/all_spec.cr 
vagrant@debian-7:~/kemal$ ./all_spec 
..........................................................................................

Finished in 7.51 milliseconds
90 examples, 0 failures, 0 errors, 0 pending

So _I think_ the bug we're hitting isn't solved by LLVM 3.9.1 - or I haven't built it correctly. This is how I've built LLVM3.9.1, and the resulting packages are published with the others (like this).

Regarding the statically linked compiler, I'm not sure it will solve every issue - for starter, it will be a Linux 64 bits only thing, isn't it?

[matiasgarciaisaia]

OK, I've just found that this seems to be a separate issue (#4600). I'm testing the same scenario with both LLVM 3.8.1 (the current release) and the new LLVM 3.9.1 and will confirm if this issue was fixed or not.

[matiasgarciaisaia]

Trying to build crystal build --release db/seed.cr in https://github.com/crystal-community/crystal-ann failed with the Lexical scope bug:

vagrant@debian-7:~/crystal-ann$ crystal build --release db/seed.cr 
crystal: /var/cache/omnibus/src/llvm/llvm-3.9.1.src/lib/CodeGen/LexicalScopes.cpp:159: llvm::LexicalScope* llvm::LexicalScopes::getOrCreateRegularScope(const llvm::DILocalScope*): Assertion `cast<DISubprogram>(Scope)->describes(MF->getFunction())' failed.
/usr/bin/crystal: line 102:  7482 Aborted                 "$INSTALL_DIR/embedded/bin/crystal" "$@"

@ysbaddaden @RX14 any ideas?

[opensas]

Great to know you are still trying to solve this one,
I just stumbled upon this issue and someone at gitter pointed me in the right direction.
In the meantime, have you considered document it somewhere in the documentation? perhaps a "known issues" section in the docs or when you explain the --release flag https://crystal-lang.org/docs/using_the_compiler/

[Xosmond]

I also can't build a project on ubuntu :(. Im getting the same error:
Assertioncast(Scope)->describes(MF->getFunction())' failed.`

[niltonvasques]

Using here with --no-debug option works for me.

      crystal build hello.cr --release --no-debug

[ekremkaraca]

Hey guys,

I had similar issue on Solus OS. With crenv tool, I was able to install 0.23.0, but not 0.23.1. Here is the error below:

➜  ~ crenv install 0.23.1
Resolving Crystal download URL by Remote Cache ... ok
Downloading Crystal binary tarball ...
https://github.com/crystal-lang/crystal/releases/download/0.23.1/crystal-0.23.1-3-linux-x86_64.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   625    0   625    0     0    625      0 --:--:-- --:--:-- --:--:--   693
100 18.9M  100 18.9M    0     0  2160k      0  0:00:09  0:00:09 --:--:-- 3232k
ok
Moving the Crystal directory ...ok
Checking if Shards already exists ... ng
Resolving Shards download URL ... ok
Downloading Shards tarball ...
https://github.com/crystal-lang/shards/archive/v0.7.1.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   127    0   127    0     0    127      0 --:--:-- --:--:-- --:--:--   151
100 29722  100 29722    0     0  29722      0  0:00:01  0:00:01 --:--:-- 29662
ok
Building Shards ... crystal: /var/cache/omnibus/src/llvm/llvm-3.8.1.src/lib/CodeGen/LexicalScopes.cpp:160: llvm::LexicalScope* llvm::LexicalScopes::getOrCreateRegularScope(const llvm::DILocalScope*): Assertion `cast<DISubprogram>(Scope)->describes(MF->getFunction())' failed.
/home/ekrem/.crenv/versions/0.23.1/bin/crystal: line 102:  3228 Aborted                 "$INSTALL_DIR/embedded/bin/crystal" "$@"

Retry building Shards ... crystal: /var/cache/omnibus/src/llvm/llvm-3.8.1.src/lib/CodeGen/LexicalScopes.cpp:160: llvm::LexicalScope* llvm::LexicalScopes::getOrCreateRegularScope(const llvm::DILocalScope*): Assertion `cast<DISubprogram>(Scope)->describes(MF->getFunction())' failed.
/home/ekrem/.crenv/versions/0.23.1/bin/crystal: line 102:  3268 Aborted                 "$INSTALL_DIR/embedded/bin/crystal" "$@"
shards build faild: /home/ekrem/.crenv/cache/0.23.1/shards-0.7.1 at /home/ekrem/.crenv/plugins/crystal-build/bin/../lib/CrystalBuild/Builder/Shards.pm line 33, <DATA> line 2.

[akzhan]

Just want to note that sample

bin/crystal eval --release 'p "hello world"'

raised assertion some days ago,

but now does OK and prints "hello world" (Crystal master branch built on LLVM 5.0).

So you allowed to build crystal by yourself from master branch, with LLVM 3.9 or above.

Or wait for new Crystal release.

[david50407]

Also happened on macOS 10.13 (LLVM 4.0.1) with nix packager: (Crystal 0.23.1-3)

Using /nix/store/4zn04v842al058ibl4rrk8xw83zi6v9c-llvm-4.0.1/bin/llvm-config [version=4.0.1]
clang++ -c  -o src/llvm/ext/llvm_ext.o src/llvm/ext/llvm_ext.cc `/nix/store/4zn04v842al058ibl4rrk8xw83zi6v9c-llvm-4.0.1/bin/llvm-config --cxxflags`
clang -fPIC    -c -o src/ext/sigfault.o src/ext/sigfault.c
ar -rcs src/ext/libcrystal.a src/ext/sigfault.o
./bin/crystal build --release  -o .build/crystal src/compiler/crystal.cr -D without_openssl -D without_zlib
[warn] kq_init: detected broken kqueue; not using.: Undefined error: 0
Assertion failed: (cast<DISubprogram>(Scope)->describes(MF->getFunction())), function getOrCreateRegularScope, file /var/cache/omnibus/src/llvm/llvm-3.8.1.src/lib/CodeGen/LexicalScopes.cpp, line 160.
/private/tmp/nix-build-crystal-0.23.1-3.drv-0/crystal-0.23.1/../crystal-0.23.1-3/bin/crystal: line 102:  1840 Abort trap: 6           "$INSTALL_DIR/embedded/bin/crystal" "$@"

[RX14]

This must be fixed before releasing 0.24.0.

We should not release a new omnibus knowing it's broken.

[asterite]

Do we know if this only happens when compiling the compiler with --release? Does it happen with other small programs that we can reproduce and fix?

[RX14]

Yes it happens with other small programs, and only with release mode.

[asterite]

Do we have one of those small programs? I'd like to reproduce it and try to fix it.

[lbguilherme]

@asterite I actually couldn't write a program where it doesn't happen.

[guilherme@note ~]$ echo "p 0" > /tmp/a.cr
[guilherme@note ~]$ crystal run --release /tmp/a.cr
crystal: /var/cache/omnibus/src/llvm/llvm-3.8.1.src/lib/CodeGen/LexicalScopes.cpp:160: llvm::LexicalScope* llvm::LexicalScopes::getOrCreateRegularScope(const llvm::DILocalScope*): Assertion `cast<DISubprogram>(Scope)->describes(MF->getFunction())' failed.
/opt/crystal/bin/crystal: line 102: 12515 Aborted                 (core dumped) "$INSTALL_DIR/embedded/bin/crystal" "$@"

[asterite]

@lbguilherme What if you use LLVM 4.0 or LLVM 5.0?

[asterite]

What I'm saying is, most of the previous comments suggest this is an LLVM bug that was fixed in 3.9. We should just make sure to use that LLVM version, or a later one, when doing the next release. There's nothing we can do in this repository to mitigate this problem.

[lbguilherme]

It works with LLVM 4.0.1.

[straight-shoota]

I've installed the pre-release debian package 0.24.0-2_amd64 on Ubunutu 14.05.5 LTS in Windows Subsystem for Linux.

$ crystal --version
vCrystal 0.23.0+313 [ea4187c] (2017-10-27)

LLVM: 3.9.1
Default target: x86_64-unknown-linux-gnu

Unfortunately, it seems the issue still persists with LLVM 3.9.1:

$ crystal eval 'puts "Hello World"' --release
crystal: /var/cache/omnibus/src/llvm/llvm-3.9.1.src/lib/CodeGen/LexicalScopes.cpp:159: llvm::LexicalScope* llvm::LexicalScopes::getOrCreateRegularScope(const llvm::DILocalScope*): Assertion `cast<DISubprogram>(Scope)->describes(MF->getFunction())' failed.
/usr/bin/crystal: line 102: 28893 Aborted                 (core dumped) "$INSTALL_DIR/embedded/bin/crystal" "$@"

Adding --no-debug, it compiles without error.

[RX14]

If this omnibus issue still isn't solved, i'm going to have another crack at my statically-compiled omnibus.

[RX14]

I have a new omnibus that I would like people to try and see if it fixes the --release issue for them: https://rx14.co.uk/crystal-0.24.0.tar.gz

You can build it yourself by running ./build.sh inside this repo with docker installed. A tar file will be placed in the build directory.

This package (correctly) only contains a statically compiled libgc. This means that you may have to install some new packages (libevent-dev, libpcre3-dev) to get it to compile. This is essentially the same as when compiling the compiler yourself, but without the requirement for llvm.

[crisward]

If it includes libgc, it could be good to compile it with

./configure --enable-munmap=3 

as per this thread.
https://github.com/crystal-lang/crystal/issues/3997#issuecomment-283765417

It allows it to return memory back to the OS after 3 GC cycles and works really well at allowing processes to return memory after high usage. The GC seems to slow down the frequency of it's cycles during high memory consumption, so 3 cycles isn't as often as you may think.

[ysbaddaden]

We shouldn't enable memory shrink by default: we'll (probably) have another GC in the future, and while growing memory is easy, shrinking is more complex and may not be available or even a goal to achieve.

[crisward]

Long running processes holding onto the memory they need at peak traffic seems wasteful. I'm not aware of any other languages doing this. Node, Go, even PHP return memory after a few minutes. I've been running Crystal with libgc compiled with this flag since that comment in march without any obvious ill effects.

Not using something because it may be difficult to replicate later on seems a little overly cautious and something that could be worked out if the need arises.

[ysbaddaden]

Sure. Implementing a GC with moving pointers to defragment memory isn't hard to implement. On free time. Without money support from Google.

If you need to give back memory then compile boehm-gc manually and be aware that this isn't to be expected by default. A custom GC likely won't have this feature to begin with. Don't give wrong expectations, otherwise implementing a GC for Crystal will never happen, because the mountain to climb will seem absurdly too high.

[RX14]

Per @ivmai

• unmapping+MPROTECT_VDB is not supported yet (so the client app won't be able to use incremental collection (except for Solaris and Windows target) if GC is compiled with unmapping)

This looks like a very good reason not to make this the default.

Still looking for feedback on how well my omnibus build works.

[straight-shoota]

As discussed in chat yesterday, Ubunutu 16.04.3 LTS works.

On Ubuntu 14.04.5 LTS on Windows Subsystem for Linux it throws a segmentation fault.
```Starting program: /mnt/c/Users/Johannes/crystal-0.24.0/lib/crystal/bin/crystal -v
warning: Error disabling address space randomization: Success

Program received signal SIGSEGV, Segmentation fault.
_start_c (sp=0x7fffe3b66370, dynv=)
at crt/../ldso/dlstart.c:139
139 in crt/../ldso/dlstart.c
```

[eregon]

This still happens in the latest available Crystal on Fedora, 0.23.1.

[stronny]

Please take a look at the debian package crystal_0.24.2-1_i386.deb from http://dist.crystal-lang.org/apt, I have the similar/same issue with it:

0:skuld:~/src/zorg$ cat test.cr puts "zorg"
0:skuld:~/src/zorg$ crystal test.cr --release --static crystal: /var/cache/omnibus/src/llvm/llvm-3.9.1.src/lib/CodeGen/LexicalScopes.cpp:159: llvm::LexicalScope* llvm::LexicalScopes::getOrCreateRegularScope(const llvm::DILocalScope*): Assertion `cast<DISubprogram>(Scope)->describes(MF->getFunction())' failed.
/usr/bin/crystal: line 102: 12249 Aborted                 "$INSTALL_DIR/embedded/bin/crystal" "$@"
134:skuld:~/src/zorg$ dpkg -l | grep cryst
ii  crystal                            0.24.2-1                       i386         The full stack of crystal
0:skuld:~/src/zorg$ cat /etc/debian_version
9.4
0:skuld:~/src/zorg$ crystal test.cr
zorg

[RX14]

@stronny crystal -v please, it seems you have an 0.24.2 package built with omnibus and llvm 3.9, which doesn't make sense.

[stronny]

0:skuld:~$ crystal -v
Crystal 0.24.2 [4f9ed8d] (2018-03-08)

LLVM: 3.9.1
Default target: i686-pc-linux-gnu

It does seem like that indeed, however I can't really judge how much sense does it make.

[ysbaddaden]

Doesn't the 32 bit version was still built with omnibus? The next release shall fix that, I believe.

[RX14]

ohh yeah, 32 bit x86, I forgot that exists

[bcardiff]

I've tested building crystal in a vagrant xenial 32 bits machine with llvm-4.0 as part of test-ecosystem and seems to work fine so far.