Bugzilla – Bug 8502
Core dumped with 3.0.x (HEAD) with llvm, does not fail when using mono JIT
Last modified: 2012-11-23 11:21:33 EST
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
/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
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.