Bug 21286 - Win64 assertion abort, condition `tls_offset < 64' not met
Summary: Win64 assertion abort, condition `tls_offset < 64' not met
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: JIT ()
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2014-07-13 05:32 UTC by Filip Lundgren
Modified: 2014-07-14 15:43 UTC (History)
3 users (show)

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

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:
Status:
RESOLVED FIXED

Description Filip Lundgren 2014-07-13 05:32:56 UTC
I get a fatal assertion upon JIT compiling .cs files with the CSharpCodeProvider. This works fine in a 32-bit executable, but fails in x64. Let me know if you guys need more information, I can reproduce this very easily and consistently.

This occurs under the current 'mono/mono' master branch.

Assertion message:

0x000000004741da30 "* Assertion at ..\\mono\\mini\\mini-amd64.c:3641, condition `tls_offset < 64' not met\n"

Call stack:
 	CryMono.dll!HandleSignalAbort(int error) Line 199	C++
 	msvcr110.dll!raise(int signum) Line 586	C
 	msvcr110.dll!abort() Line 82	C
 	monosgen-2.0.dll!monoeg_g_logv(const char * log_domain, GLogLevelFlags log_level, const char * format, char * args) Line 177	C
 	monosgen-2.0.dll!monoeg_assertion_message(const char * format, ...) Line 199	C
>	monosgen-2.0.dll!mono_amd64_emit_tls_get(unsigned char * code, int dreg, int tls_offset) Line 3642	C
 	monosgen-2.0.dll!mono_arch_output_basic_block(MonoCompile * cfg, MonoBasicBlock * bb) Line 5593	C
 	monosgen-2.0.dll!mono_codegen(MonoCompile * cfg) Line 4116	C
 	monosgen-2.0.dll!mini_method_compile(_MonoMethod * method, unsigned int opts, _MonoDomain * domain, JitFlags flags, int parts) Line 5706	C
 	monosgen-2.0.dll!mono_jit_compile_method_inner(_MonoMethod * method, _MonoDomain * target_domain, int opt, _MonoException * * jit_ex) Line 6018	C
 	monosgen-2.0.dll!mono_jit_compile_method_with_opt(_MonoMethod * method, unsigned int opt, _MonoException * * ex) Line 6295	C
 	monosgen-2.0.dll!mono_jit_compile_method(_MonoMethod * method) Line 6332	C
 	monosgen-2.0.dll!common_call_trampoline(__int64 * regs, unsigned char * code, _MonoMethod * m, unsigned char * tramp, MonoVTable * vt, void * * vtable_slot, int need_rgctx_tramp) Line 597	C
 	monosgen-2.0.dll!mono_magic_trampoline(__int64 * regs, unsigned char * code, void * arg, unsigned char * tramp) Line 718	C
Comment 1 Zoltan Varga 2014-07-13 11:01:26 UTC
Could you try  mono master (b921dc0cef3926818ddd1862d119d6fe0403daad) ?
Comment 2 Filip Lundgren 2014-07-13 12:00:00 UTC
That actually gets me further, but still a similar result:

 	CryMono.dll!HandleSignalAbort(int error) Line 199	C++
 	msvcr110.dll!raise(int signum) Line 586	C
 	msvcr110.dll!abort() Line 82	C
 	monosgen-2.0.dll!monoeg_g_logv(const char * log_domain, GLogLevelFlags log_level, const char * format, char * args) Line 177	C
 	monosgen-2.0.dll!monoeg_assertion_message(const char * format, ...) Line 199	C
>	monosgen-2.0.dll!mono_method_to_ir(MonoCompile * cfg, _MonoMethod * method, MonoBasicBlock * start_bblock, MonoBasicBlock * end_bblock, MonoInst * return_var, _GList * dont_inline, MonoInst * * inline_args, unsigned int inline_offset, int is_virtual_call) Line 11520	C
 	monosgen-2.0.dll!mini_method_compile(_MonoMethod * method, unsigned int opts, _MonoDomain * domain, JitFlags flags, int parts) Line 5277	C
 	monosgen-2.0.dll!mono_jit_compile_method_inner(_MonoMethod * method, _MonoDomain * target_domain, int opt, _MonoException * * jit_ex) Line 6021	C
 	monosgen-2.0.dll!mono_jit_compile_method_with_opt(_MonoMethod * method, unsigned int opt, _MonoException * * ex) Line 6298	C
 	monosgen-2.0.dll!mono_jit_compile_method(_MonoMethod * method) Line 6335	C
 	monosgen-2.0.dll!common_call_trampoline(__int64 * regs, unsigned char * code, _MonoMethod * m, unsigned char * tramp, MonoVTable * vt, void * * vtable_slot, int need_rgctx_tramp) Line 586	C
 	monosgen-2.0.dll!mono_magic_trampoline(__int64 * regs, unsigned char * code, void * arg, unsigned char * tramp) Line 707	C
Comment 3 Zoltan Varga 2014-07-13 12:58:10 UTC
If this is an embedded app, as a workaround, try loading/initializing the runtime as soon as possible after startup, so mono's thread-local variables get assigned small offsets, thus avoiding this assert.
Comment 4 Filip Lundgren 2014-07-13 13:55:41 UTC
Unfortunately isn't an option for us, as we're embedding into the CRYENGINE Engine as a Service program, where that early initialization isn't available.
Comment 5 Zoltan Varga 2014-07-14 15:43:35 UTC
Fixed in mono master 49d68ea47cec285f82fdf6a17f472f8adbe72bfc.