Bug 32907 - Accessing fields of `Random` object from IL code leads to mono crash.
Summary: Accessing fields of `Random` object from IL code leads to mono crash.
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: JIT (show other bugs)
Version: 4.0.0
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2015-08-10 08:47 UTC by mholenko
Modified: 2015-08-14 18:36 UTC (History)
4 users (show)

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


Attachments
Code reproducing the crash condition (1.90 KB, text/x-csharp)
2015-08-10 08:47 UTC, mholenko
Details

Description mholenko 2015-08-10 08:47:01 UTC
Overview:
    Accessing fields of `Random` object from IL code leads to mono crash.

    Mono crashes when trying to create a delegate that modifies `SeedArray` field. The delegate
    does not have to be called at all.

    What is even more interesting, it is enough to *add code* calling `Random` class constructor
    to avoid the problem. This code does *not* have to be *executed* at all.

Steps to reproduce:
    As the case is a bit complicated, I attach code with the smallest example I could prepare:

    (1) Compile the code and run it.
    (2) Modify the code by commenting out line 20 (i.e., line calling `ThisIsNotExecuted` method).
    (3) Compile the code and run it again.

Actual results:
    In the first case the code works as expected - application prints three lines and exits.
    In the second case mono crashes.

Expected results:
    In both cases application should print three lines and exit.

Buld Date & Platform:
    Mono JIT compiler version 4.3.0 (master/23453f3 sob, 11 lip 2015, 12:22:57 CEST) on Linux 3.17.1 (Debian)

    The same binary (without recompilation) works well on Windows .NET [Microsoft .NET Framework, version 4.0.30319.34209].

Additional information:
    I couldn't reproduce the problem under debugger - it happens only when the binary is executed directly.
Comment 1 mholenko 2015-08-10 08:47:43 UTC
Created attachment 12426 [details]
Code reproducing the crash condition
Comment 2 Zoltan Varga 2015-08-11 22:45:25 UTC
I can't reproduce this with mono master.
Comment 3 mholenko 2015-08-12 03:47:12 UTC
I have just tested it on a fresh virtual machine with Ubuntu 14.04 LTS (trusty) and yesterday's mono:

Mono JIT compiler version 4.3.0 (master/6fc86ee wto, 11 sie 2015, 15:19:56 CEST)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           __thread
	SIGSEGV:       altstack
	Notifications: epoll
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	LLVM:          supported, not enabled.
	GC:            sgen

and got a crash with following stacktrace:

antmicro@antmicro-Standard-PC-i440FX-PIIX-1996:~/Downloads$ ./Program.exe 
Before delegate creation
Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.Delegate.CreateDelegate_internal (System.Type,object,System.Reflection.MethodInfo,bool) <0xffffffff>
  at System.Delegate.CreateDelegate (System.Type,object,System.Reflection.MethodInfo,bool,bool) <0x00708>
  at System.Delegate.CreateDelegate (System.Type,System.Reflection.MethodInfo,bool) <0x00025>
  at System.Delegate.CreateDelegate (System.Type,System.Reflection.MethodInfo) <0x00016>
  at System.Reflection.Emit.DynamicMethod.CreateDelegate (System.Type) <0x0004c>
  at Test.MainClass.Main (string[]) <0x006bb>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

	/usr/bin/cli() [0x4a20b8]
	/usr/bin/cli() [0x4f6dde]
	/usr/bin/cli() [0x422d22]
	/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7f5d01a7d340]
	/usr/bin/cli() [0x441a24]
	/usr/bin/cli() [0x500ea2]
	/usr/bin/cli() [0x5022bf]
	/usr/bin/cli() [0x421dcc]
	/usr/bin/cli() [0x42244b]
	/usr/bin/cli() [0x539f30]
	[0x41897574]

Debug info from gdb:

warning: File "/usr/bin/mono-sgen-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
	add-auto-load-safe-path /usr/bin/mono-sgen-gdb.py
line to your configuration file "/home/antmicro/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/antmicro/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
[New LWP 8812]
[New LWP 8811]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f5d01a7cee9 in __libc_waitpid (pid=pid@entry=8813, stat_loc=stat_loc@entry=0x7f5d025ad29c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40
40	../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
  Id   Target Id         Frame 
  3    Thread 0x7f5d007ff700 (LWP 8811) "cli" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  2    Thread 0x7f5d00e93700 (LWP 8812) "Finalizer" sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
* 1    Thread 0x7f5d025a57c0 (LWP 8809) "cli" 0x00007f5d01a7cee9 in __libc_waitpid (pid=pid@entry=8813, stat_loc=stat_loc@entry=0x7f5d025ad29c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40

Thread 3 (Thread 0x7f5d007ff700 (LWP 8811)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00000000005f833c in thread_func (thread_data=0x0) at sgen-thread-pool.c:118
#2  0x00007f5d01a75182 in start_thread (arg=0x7f5d007ff700) at pthread_create.c:312
#3  0x00007f5d017a230d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7f5d00e93700 (LWP 8812)):
#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
#1  0x000000000061b687 in mono_sem_wait (sem=sem@entry=0x94ac00 <finalizer_sem>, alertable=alertable@entry=1) at mono-semaphore.c:107
#2  0x00000000005a1576 in finalizer_thread (unused=<optimized out>) at gc.c:1096
#3  0x0000000000583fdb in start_wrapper_internal (data=<optimized out>) at threads.c:723
#4  start_wrapper (data=<optimized out>) at threads.c:770
#5  0x00000000006221a6 in inner_start_thread (arg=0x7fff4a99c4e0) at mono-threads-posix.c:97
#6  0x00007f5d01a75182 in start_thread (arg=0x7f5d00e93700) at pthread_create.c:312
#7  0x00007f5d017a230d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7f5d025a57c0 (LWP 8809)):
#0  0x00007f5d01a7cee9 in __libc_waitpid (pid=pid@entry=8813, stat_loc=stat_loc@entry=0x7f5d025ad29c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40
#1  0x00000000004a217e in mono_handle_native_sigsegv (signal=signal@entry=11, ctx=ctx@entry=0x7f5d025adc40, info=info@entry=0x7f5d025add70) at mini-exceptions.c:2246
#2  0x00000000004f6dde in mono_arch_handle_altstack_exception (sigctx=sigctx@entry=0x7f5d025adc40, siginfo=siginfo@entry=0x7f5d025add70, fault_addr=<optimized out>, stack_ovf=stack_ovf@entry=0) at exceptions-amd64.c:808
#3  0x0000000000422d22 in mono_sigsegv_signal_handler (_dummy=11, _info=0x7f5d025add70, context=0x7f5d025adc40) at mini-runtime.c:2454
#4  <signal handler called>
#5  0x0000000000441a24 in mono_method_to_ir (cfg=cfg@entry=0x2848fa0, method=method@entry=0x28406b0, start_bblock=<optimized out>, start_bblock@entry=0x0, end_bblock=<optimized out>, end_bblock@entry=0x0, return_var=return_var@entry=0x0, inline_args=inline_args@entry=0x0, inline_offset=inline_offset@entry=0, is_virtual_call=is_virtual_call@entry=0) at method-to-ir.c:10811
#6  0x0000000000500ea2 in mini_method_compile (method=method@entry=0x28406b0, opts=opts@entry=370239999, domain=domain@entry=0x26c0d40, flags=flags@entry=JIT_FLAG_RUN_CCTORS, parts=parts@entry=0, aot_method_index=aot_method_index@entry=-1) at mini.c:3502
#7  0x00000000005022bf in mono_jit_compile_method_inner (method=method@entry=0x28406b0, target_domain=target_domain@entry=0x26c0d40, opt=opt@entry=370239999, jit_ex=jit_ex@entry=0x7fff4a99c128) at mini.c:4100
#8  0x0000000000421dcc in mono_jit_compile_method_with_opt (method=method@entry=0x28406b0, opt=370239999, ex=ex@entry=0x7fff4a99c128) at mini-runtime.c:1887
#9  0x000000000042244b in mono_jit_compile_method (method=0x28406b0) at mini-runtime.c:1924
#10 0x0000000000539f30 in ves_icall_System_Delegate_CreateDelegate_internal (type=0x7f5d025087c0, target=0x0, info=<optimized out>, throwOnBindFailure=<optimized out>) at icall.c:5593
#11 0x0000000041897574 in ?? ()
#12 0x00007f5d025087c0 in ?? ()
#13 0x00007f5d0080cc98 in ?? ()
#14 0x00007f5d008007e8 in ?? ()
#15 0x0000000000000000 in ?? ()

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Aborted (core dumped)
Comment 4 Zoltan Varga 2015-08-12 23:11:34 UTC
Can't reproduce it on linux either.
Comment 5 Konrad Kruczyński 2015-08-13 03:12:34 UTC
I could reproduce it. What I did:
1. I downloaded the file from attachment.
2. I compiled it: mcs Program.cs
3. I ran it (mono Programs.exe) and it worked.
4. Then I edited it and removed line with ThisIsNotExecuted().
5. I compiled it again.
6. It did not work in a way described above.

Did you use Linux 64-bit and ran it without debugger?
Comment 6 Zoltan Varga 2015-08-14 18:36:31 UTC
Fixed in mono master 8ece42b8e839f00a643f2dc113b09e700173d1b6.

Notice (2018-05-21): bugzilla.xamarin.com will be switching to read-only mode on Thursday, 2018-05-25 22:00 UTC.

Please join us on Visual Studio Developer Community and GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs and copy them to the new locations as needed for follow-up. The See Also field on each Bugzilla bug will be updated with a link to its new location when applicable.

After Bugzilla is read-only, if you have new information to add for a bug that does not yet have a matching issue on Developer Community or GitHub, you can create a follow-up issue in the new location. Copy and paste the title and description from this bug, and then add your new details. You can get a pre-formatted version of the title and description here:

In special cases you might also want the comments:

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.

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