|Summary:||Fatal: Managed allocator missing for (mkbundle) in Mono 4.4.X|
|Product:||[Mono] Runtime||Reporter:||minxomat <squarecode>|
|Component:||General||Assignee:||Vlad Brezae <vlad.brezae>|
|Severity:||normal||CC:||alkpli, bjorn.samvik, kumpera, luis.aguilera, mono-bugs, mono-bugs+mono, mono-bugs+runtime, shrutis, vlad.brezae, webmaster|
|Target Milestone:||4.6.0 (C8)|
|Tags:||mkbundle, C8Beta1||Is this bug a regression?:||Yes|
|Last known good build:||4.2.4|
Description minxomat 2016-06-25 05:09:47 UTC
# The Error There's an error in mkbundle's compilation process that prevents compiled native code from running. Specifically, this is the error: Error: No managed allocator, but we need one for AOT. Are you using non-standard GC options? # What should have happened? Here's a complete compilation log for Mono 4.2.4, where everything works: https://travis-ci.org/turbo/src/builds/137594697 # What happened? This (contains a complete Stacktrace): https://travis-ci.org/turbo/src/builds/140176422 To reproduce, simply execute this command in an Ubuntu environment: wget -qO- git.io/ubuntu.sh|sh
Comment 1 Alexander Köplinger [MSFT] 2016-07-04 19:38:24 UTC
*** Bug 42058 has been marked as a duplicate of this bug. ***
Comment 2 Alexander Köplinger [MSFT] 2016-07-04 19:46:03 UTC
@kumpera: this seems to be a problem related to Mono embedding, since it affects edgejs as well (see https://github.com/mono/website/issues/199#issuecomment-230333018) which doesn't do mkbundle. Who would be the best one to take a look into this? I've assigned it to C8 for now, but I think this is worth C7SR2 milestone (for which there's no milestone yet).
Comment 3 Rodrigo Kumpera 2016-07-11 15:21:12 UTC
Hey Zoltan, Could you take a look at this one?
Comment 4 Zoltan Varga 2016-07-12 01:38:31 UTC
Does this affect 4.6 as well ?
Comment 5 Zoltan Varga 2016-07-12 01:46:18 UTC
Cannot reproduce this.
Comment 6 Alexander Köplinger [MSFT] 2016-07-12 09:27:27 UTC
@Zoltan did you try on Linux/Ubuntu? IIRC it doesn't show on OSX.
Comment 7 Vlad Brezae 2016-07-15 21:16:57 UTC
This is caused by having different TLS functionality between the normal mono and the embedded mono on systems where we use the __thread keyword. While on a normal mono we have MONO_THREAD_VAR_OFFSET defined on the embedding image we don't have it defined as of commit https://github.com/mono/mono/commit/daeb33c95b676d29624c98157214a64c95a7fe9c. The way this leads to asserting is the following. The normal mono (which has tls) aot-compiles corlib encoding allocations to MONO_WRAPPER_ALLOC plt calls. When the embedded mono tries to resolve the alloc wrapper, because it doesn't have MONO_THREAD_VAR_OFFSET defined, it fails to compile it therefore the assertion. This part could easily be fixed by resolving to the slow versions of the allocators instead, which don't require any tls. The problem is that there are methods in the corlib which have inlined tls code, which according to zoltan's commit, would not work anyway. We would either need to fix the tls definitions when mono comes as a library, or disable aot when mono comes as a library.
Comment 8 minxomat 2016-07-18 14:28:27 UTC
Additional info: I have an ARMv7h netbook running archlinux ARM. The system runs mono 4.6 (built from the git 4.6.0 branch). The bug does NOT apply there. On my x86_64 PCs running archlinux or some form of Debian, the error occurs with both 4.4.X and 4.6. (I didn't try 4.4.X on ARM)
Comment 9 Rodrigo Kumpera 2016-08-18 23:15:34 UTC
Fixed on master and mono 4.6.
Comment 10 Shruti 2016-09-07 10:42:56 UTC
@minxomat, Could you please share me your sample which would help me to replicate this issue or It would be great If you check this once at your end with latest Beta as this issue is fixed 20 days before.
Comment 11 Shruti 2016-09-12 13:02:06 UTC
We have executed regression test plan and did not experience this issue while executing regression and smoke test plan on OS X. Although we are waiting for the response of https://bugzilla.xamarin.com/show_bug.cgi?id=42169#c10 from last 1 week. So, today I am closing this issue. Please feel free to reopen this issue If you experience again. Thanks!!
Comment 12 Björn Samvik 2016-09-26 09:09:09 UTC
Hello I understand that this is is fixed on master but is there any workaround (in the bundling process or the program itself) to make the bundle work even when a version of mono without the fix is present in the system? Thanks
Comment 13 Vlad Brezae 2016-09-26 09:16:37 UTC
Hey. Disabling aot should be an easy workaround for the problem. You can achieve this by passing -O=-aot at mono initialization.
Comment 14 Björn Samvik 2016-09-27 13:27:21 UTC
Thank you, it works. Setting the following environment variable turns of aot when mono is bundled. MONO_BUNDLED_OPTIONS="-O=-aot"