Bug 8502 - Core dumped with 3.0.x (HEAD) with llvm, does not fail when using mono JIT
Summary: Core dumped with 3.0.x (HEAD) with llvm, does not fail when using mono JIT
Alias: None
Product: Runtime
Classification: Mono
Component: JIT ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2012-11-19 08:43 UTC by Jonathan Shore
Modified: 2012-11-23 11:21 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

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

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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.

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.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

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

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 UTC
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 UTC
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 ?
Comment 3 Jonathan Shore 2012-11-22 09:51:53 UTC
Thanks, I'm pulling the latest and will let you know how it goes ...
Comment 4 Jonathan Shore 2012-11-22 11:09:57 UTC
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 UTC
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 UTC
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 UTC
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 UTC
Created attachment 3001 [details]
Simple program that fails with LLVM JIT
Comment 9 Zoltan Varga 2012-11-22 21:59:43 UTC
I can reproduce that.
Comment 10 Zoltan Varga 2012-11-23 04:02:07 UTC
Hopefully fixed by 
Thanks for the testcase.
Comment 11 Jonathan Shore 2012-11-23 09:37:38 UTC
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 UTC
Should be fixed by 6ff01ffc70ec5f0d9887752c2c9264fab667c89c.
Comment 13 Jonathan Shore 2012-11-23 11:10:50 UTC
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 UTC