This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 8502 - Core dumped with 3.0.x (HEAD) with llvm, does not fail when using mono JIT
: Core dumped with 3.0.x (HEAD) with llvm, does not fail when using mono JIT
Status: RESOLVED FIXED
Product: Runtime
Classification: Mono
Component: JIT
: unspecified
: PC Linux
: --- normal
: ---
Assigned To: Bugzilla
:
:
:
:
  Show dependency treegraph
 
Reported: 2012-11-19 08:43 EST by Jonathan Shore
Modified: 2012-11-23 11:21 EST (History)
3 users (show)

See Also:
Tags:
Test Case URL:
External Submit: ---


Attachments
application that causes runtime to fault with --llvm (1.43 MB, application/x-bzip2)
2012-11-19 08:43 EST, Jonathan Shore
Details
Simple program that fails with LLVM JIT (3.69 KB, application/x-bzip2)
2012-11-22 20:26 EST, Jonathan Shore
Details

Description Jonathan Shore 2012-11-19 08:43:36 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
Stacktrace:

Native stacktrace:

Segmentation fault (core dumped)

So, it looks like we are geenrating incorrect code with LLVM ...
Comment 1 Jonathan Shore 2012-11-19 08:49:23 EST
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).
Comment 2 Zoltan Varga 2012-11-22 09:04:57 EST
Thanks for the report. I couldn't reproduce the exact problem, but fixed
something which could have caused it in:
https://github.com/mono/mono/commit/9d0290d3fdcd6676ffbb5e4f64e34c04e77669cb
Could you try that patch ?
Comment 3 Jonathan Shore 2012-11-22 09:51:53 EST
Thanks, I'm pulling the latest and will let you know how it goes ...
Comment 4 Jonathan Shore 2012-11-22 11:09:57 EST
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?
Comment 5 Zoltan Varga 2012-11-22 11:52:11 EST
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 ?
Comment 6 Jonathan Shore 2012-11-22 12:46:03 EST
Let me reduce this application to remove the winforms.   I'll post a new
application in a day or two.  Thanks.
Comment 7 Jonathan Shore 2012-11-22 20:25:52 EST
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:

    mono  bin/Debug/Bad.exe

And fails with a runtime fault:

    mono  --llvm bin/Debug/Bad.exe

Find in the new attachment.
Comment 8 Jonathan Shore 2012-11-22 20:26:32 EST
Created attachment 3001 [details]
Simple program that fails with LLVM JIT
Comment 9 Zoltan Varga 2012-11-22 21:59:43 EST
I can reproduce that.
Comment 10 Zoltan Varga 2012-11-23 04:02:07 EST
Hopefully fixed by 
https://github.com/mono/mono/commit/81688d4189d955e49d77d0a945d3a60a9ee1c62e
Thanks for the testcase.
Comment 11 Jonathan Shore 2012-11-23 09:37:38 EST
Zoltan, I got the latest LLVM and mono from the HEAD, but ran into the
following compilation problem:

  CXXLD  libmono-llvm.la
.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"
Comment 12 Zoltan Varga 2012-11-23 09:51:50 EST
Should be fixed by 6ff01ffc70ec5f0d9887752c2c9264fab667c89c.
Comment 13 Jonathan Shore 2012-11-23 11:10:50 EST
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.
Comment 14 Zoltan Varga 2012-11-23 11:21:33 EST
-> FIXED.

Note You need to log in before you can comment on or make changes to this bug.