Created attachment 2967 [details]
application that causes runtime to fault with --llvm
I did a build off of LLVM and mono heads yesterday for ubuntu 12.04, compiled for 64bit support. The program (a very small winforms UI) runs properly on this build without --llvm and fails with a core dump with llvm. The output does not show a stack, however, I investigated the core and it shows 2 anonymous stack frames (most likely JIT code).
I've included the executable and required environment. untar and do ". run" directly in the untarred directory. This app wants to connect to a server, so if it runs successfully you will see:
INFO [2012-11-19 08:37:33.774]: connecting to execution & data services
WARN [2012-11-19 08:37:34.794]: exec: failed to connect to executor, will retry in 5 secs
You can kill the app at that point, as will not be able to connect, nevertheless, has demonstrated that is running correctly.
When run with --llvm, you should see:
INFO [2012-11-19 08:39:02.709]: connecting to execution & data services
Segmentation fault (core dumped)
So, it looks like we are geenrating incorrect code with LLVM ...
Also note that this occurs before the UI is initialized. I do some initialization and connection to services before starting up the UI. So this should not be winforms related (which I know is not well supported).
Thanks for the report. I couldn't reproduce the exact problem, but fixed something which could have caused it in:
Could you try that patch ?
Thanks, I'm pulling the latest and will let you know how it goes ...
Unfortunately I experience the same problem. I did a complete rebuild of LLVM and mono from git (and also verified that your changes were in place).
It is possible that the result varies depending on the # of cores made available (since this is threaded). I am running this on a VM with 1 core enabled and also tried with 2 cores enabled).
Does the example work for you?
I can't run winforms on my machine due to some configuration problems, so I just get an exception about libgdiplus not found. Does the testcase run for you without winforms ?
Let me reduce this application to remove the winforms. I'll post a new application in a day or two. Thanks.
Ok, well the problem is not related to winforms or threads. mono / LLVM is generating bad code for a trivial program. Reduced everything down. Find the source code and exe enclosed. Note that the program is nonsensical, as is an isolated bit from a larger app.
The program runs without error with:
And fails with a runtime fault:
mono --llvm bin/Debug/Bad.exe
Find in the new attachment.
Created attachment 3001 [details]
Simple program that fails with LLVM JIT
I can reproduce that.
Hopefully fixed by
Thanks for the testcase.
Zoltan, I got the latest LLVM and mono from the HEAD, but ran into the following compilation problem:
.libs/mini-llvm.o: In function `dlsym_cb':
/home/jshore/Srcs/mono/mono/mini/mini-llvm.c:4761: undefined reference to `mono_arch_create_llvm_native_thunk'
/usr/bin/ld: .libs/libmono-llvm.so.0.0.0: hidden symbol `mono_arch_create_llvm_native_thunk' isn't defined
I see that there is code for this in tramp-amd64.c, however, there is something about the build process such that this function is not visible or not included in the .la?
I used the following configuration:
./autogen.sh --prefix=/opt/mono-3.0 --enable-llvm=yes --enable-loadedllvm
and on the llvm config:
./configure --prefix=/opt/mono-3.0 --enable-optimized --enable-targets="x86 x86_64"
Should be fixed by 6ff01ffc70ec5f0d9887752c2c9264fab667c89c.
Thanks. That did fix the issue. Looking at the code changes, I guess the problem was a long jump outside of relative 32bit addr space requiring a thunk to alias into local space (?). Interesting stuff. Thanks.
Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on GitHub
to continue tracking issues. Bugzilla will remain available for
reference in read-only mode. We will continue to work on open Bugzilla
bugs, copy them to the new locations as needed for follow-up, and add
the new items under Related Links.
Create a new report for Bug 8502 on Developer
Community or GitHub if you have new information to add and do not yet see a matching
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
Our sincere thanks to everyone who has contributed on this bug tracker
over the years. Thanks also for your understanding as we make these
adjustments and improvements for the future.