Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interpreter Crash When Doing Fancy Reflection #13654

Closed
steveisok opened this issue Mar 25, 2019 · 0 comments · Fixed by #13708 or xamarin/xamarin-android#3041

Comments

@steveisok
Copy link
Contributor

@steveisok steveisok commented Mar 25, 2019

This impacts #12619 as it is the way events are auto wired in WebForms.

What's also interesting is that if I put an lldb breakpoint at sre.c line 4039 and try to print the local variables, it'll crash too.

Steps to Reproduce

  1. Copy this gist https://gist.github.com/steveisok/a04557c332dfaf6ba5415a6b426ec39d
  2. Compile it using csc
  3. Run it via mono --interpreter <exe_name>

Current Behavior

The process crashes when trying to invoke the delegate in the gist

Expected Behavior

The delegate should be invoke and work like it does w/o the interpreter

On which platforms did you notice this

[x] macOS
[x] Linux
[x] Windows

Version Used:

Mono JIT compiler version 6.1.0 (refsrc-webforms-switch/620f34c70e3 Wed Mar 20 06:58:47 EDT 2019)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           
	SIGSEGV:       altstack
	Notification:  kqueue
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	Interpreter:   yes
	LLVM:          supported, not enabled.
	Suspend:       hybrid
	GC:            sgen (concurrent by default)

Stacktrace

Here's the crash dump I got.

=================================================================
	Native Crash Reporting
=================================================================
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.
=================================================================
/proc/self/maps:
00400000-00877000 r-xp 00000000 08:01 1617510                            /opt/mono-webforms-switch/bin/mono-sgen
00a77000-00a7e000 r--p 00477000 08:01 1617510                            /opt/mono-webforms-switch/bin/mono-sgen
00a7e000-00a83000 rw-p 0047e000 08:01 1617510                            /opt/mono-webforms-switch/bin/mono-sgen
00a83000-00a9b000 rw-p 00000000 00:00 0 
01de1000-01f12000 rw-p 00000000 00:00 0                                  [heap]
41afa000-41b0a000 rwxp 00000000 00:00 0 
41b31000-41b41000 rwxp 00000000 00:00 0 
7f11fc000000-7f11fc021000 rw-p 00000000 00:00 0 
7f11fc021000-7f1200000000 ---p 00000000 00:00 0 
7f1200199000-7f12001a2000 ---p 00000000 00:00 0 
7f12001a2000-7f120039a000 rw-p 00000000 00:00 0 
7f120039a000-7f12007ff000 r--p 00000000 08:01 1619665                    /opt/mono-webforms-switch/lib/mono/4.5/mscorlib.dll
7f12007ff000-7f12017ff000 rw-p 00000000 00:00 0 
7f12017ff000-7f1201800000 ---p 00000000 00:00 0 
7f1201800000-7f1202400000 rw-p 00000000 00:00 0 
7f120250a000-7f12027e2000 r--p 00000000 08:01 3285870                    /usr/lib/locale/locale-archive
7f12027e2000-7f12029a2000 r-xp 00000000 08:01 1345923                    /lib/x86_64-linux-gnu/libc-2.23.so
7f12029a2000-7f1202ba2000 ---p 001c0000 08:01 1345923                    /lib/x86_64-linux-gnu/libc-2.23.so
7f1202ba2000-7f1202ba6000 r--p 001c0000 08:01 1345923                    /lib/x86_64-linux-gnu/libc-2.23.so
7f1202ba6000-7f1202ba8000 rw-p 001c4000 08:01 1345923                    /lib/x86_64-linux-gnu/libc-2.23.so
7f1202ba8000-7f1202bac000 rw-p 00000000 00:00 0 
7f1202bac000-7f1202bc2000 r-xp 00000000 08:01 1316074                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f1202bc2000-7f1202dc1000 ---p 00016000 08:01 1316074                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f1202dc1000-7f1202dc2000 rw-p 00015000 08:01 1316074                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f1202dc2000-7f1202dda000 r-xp 00000000 08:01 1345910                    /lib/x86_64-linux-gnu/libpthread-2.23.so

=================================================================
	Native stacktrace:
=================================================================
	0x51dca6 - /opt/mono-webforms-switch/bin/mono : (null)
	0x51dff1 - /opt/mono-webforms-switch/bin/mono : (null)
	0x4a9d11 - /opt/mono-webforms-switch/bin/mono : (null)
	0x516bf0 - /opt/mono-webforms-switch/bin/mono : (null)
	0x535b3d - /opt/mono-webforms-switch/bin/mono : (null)
	0x41afa7b0 - Unknown

=================================================================
	Telemetry Dumper:
=================================================================
Pkilling 0x7f1200399700 from 0x7f12038f9740
Entering thread summarizer pause from 0x7f12038f9740
Finished thread summarizer pause from 0x7f12038f9740.

Waiting for dumping threads to resume

=================================================================
	External Debugger Dump:
=================================================================
[New LWP 10196]
[New LWP 10197]
warning: File "/opt/mono-webforms-switch/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 /opt/mono-webforms-switch/bin/mono-sgen-gdb.py
line to your configuration file "/home/steveman/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/steveman/.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"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f1202dd2f7b in __waitpid (pid=pid@entry=10202, stat_loc=stat_loc@entry=0x7ffc3a137a94, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:29
29	../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
  Id   Target Id         Frame 
* 1    Thread 0x7f12038f9740 (LWP 10195) "mono" 0x00007f1202dd2f7b in __waitpid (pid=pid@entry=10202, stat_loc=stat_loc@entry=0x7ffc3a137a94, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:29
  2    Thread 0x7f1201fff700 (LWP 10196) "SGen worker" pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  3    Thread 0x7f1200399700 (LWP 10197) "Finalizer" 0x00007f1202dd1827 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0xa893a0 <finalizer_sem>) at ../sysdeps/unix/sysv/linux/futex-internal.h:205

Thread 3 (Thread 0x7f1200399700 (LWP 10197)):
#0  0x00007f1202dd1827 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0xa893a0 <finalizer_sem>) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem@entry=0xa893a0 <finalizer_sem>, abstime=0x0) at sem_waitcommon.c:111
#2  0x00007f1202dd18d4 in __new_sem_wait_slow (sem=0xa893a0 <finalizer_sem>, abstime=0x0) at sem_waitcommon.c:181
#3  0x00007f1202dd197a in __new_sem_wait (sem=sem@entry=0xa893a0 <finalizer_sem>) at sem_wait.c:29
#4  0x00000000006a6eff in mono_os_sem_wait (flags=MONO_SEM_FLAGS_ALERTABLE, sem=0xa893a0 <finalizer_sem>) at ../../mono/utils/mono-os-semaphore.h:203
#5  mono_coop_sem_wait (flags=MONO_SEM_FLAGS_ALERTABLE, sem=0xa893a0 <finalizer_sem>) at ../../mono/utils/mono-coop-semaphore.h:41
#6  finalizer_thread (unused=unused@entry=0x0) at gc.c:969
#7  0x0000000000659ba1 in start_wrapper_internal (stack_ptr=<optimized out>, start_info=0x0) at threads.c:1220
#8  start_wrapper (data=0x1e58d90) at threads.c:1293
#9  0x00007f1202dc96ba in start_thread (arg=0x7f1200399700) at pthread_create.c:333
#10 0x00007f12028e941d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 2 (Thread 0x7f1201fff700 (LWP 10196)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x000000000070515b in mono_os_cond_wait (mutex=0xa98180 <lock>, cond=0xa98140 <work_cond>) at ../../mono/utils/mono-os-mutex.h:177
#2  get_work (job=<synthetic pointer>, do_idle=<synthetic pointer>, work_context=<synthetic pointer>, worker_index=0) at sgen-thread-pool.c:165
#3  thread_func (data=<optimized out>) at sgen-thread-pool.c:196
#4  0x00007f1202dc96ba in start_thread (arg=0x7f1201fff700) at pthread_create.c:333
#5  0x00007f12028e941d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 1 (Thread 0x7f12038f9740 (LWP 10195)):
#0  0x00007f1202dd2f7b in __waitpid (pid=pid@entry=10202, stat_loc=stat_loc@entry=0x7ffc3a137a94, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:29
#1  0x000000000051dee8 in dump_native_stacktrace (ctx=ctx@entry=0x0, signal=0x74e5b5 "SIGSEGV") at mini-posix.c:1115
#2  0x000000000051dff1 in mono_dump_native_crash_info (signal=signal@entry=0x74e5b5 "SIGSEGV", ctx=ctx@entry=0x0, info=info@entry=0x0) at mini-posix.c:1157
#3  0x00000000004a9d11 in mono_handle_native_crash (signal=signal@entry=0x74e5b5 "SIGSEGV", ctx=ctx@entry=0x0, info=info@entry=0x0) at mini-exceptions.c:3336
#4  0x0000000000516bf0 in altstack_handle_and_restore (ctx=0x7ffc3a138870, obj=0x0, stack_ovf=0) at exceptions-amd64.c:870
#5  0x0000000000535b3d in interp_delegate_ctor (this_obj=..., target=..., addr=0x0, error=0x7f1202dd2f7b <__waitpid+107>) at interp/interp.c:1471
#6  0x0000000041afa7b0 in ?? ()
#7  0x00007ffc3a138a80 in ?? ()
#8  0x0000000001dec7b8 in ?? ()
#9  0x0000000001dec7c0 in ?? ()
#10 0x0000000001dec7b8 in ?? ()
#11 0x000000000046e4f0 in ?? () at jit-icalls.c:1521
#12 0x0000000000000001 in ?? ()
#13 0x00007ffc3a138890 in ?? ()
#14 0x000f6136d4cb5c7d in ?? ()
#15 0x00007ffc3a138ad0 in ?? ()
#16 0x0000000001dec7c0 in ?? ()
#17 0x0000000001dec7c0 in ?? ()
#18 0x0000000000000000 in ?? ()
Aborted (core dumped)

@marek-safar marek-safar added this to the 2019-02 (6.0.xx) milestone Mar 27, 2019
BrzVlad added a commit to BrzVlad/mono that referenced this issue Mar 28, 2019
This method returns a function pointer that can be called with a calli instruction. On interpreter we use a pointer to InterpMethod while on jit we use the native code address. Normally, GetFunctionPointer should return the InterpMethod pointer if called from interp or the native code address if called from jit. Since we don't have any information about the execution engine of the caller, we solve this by intrinsifying all these calls, that happen in the interpreter.

Passing such function pointers between jitted and interp code is probably still unreliable.

Fixes mono#13654
BrzVlad added a commit to BrzVlad/mono that referenced this issue Apr 2, 2019
This method returns a function pointer that can be called with a calli instruction. On interpreter we use a pointer to InterpMethod while on jit we use the native code address. Normally, GetFunctionPointer should return the InterpMethod pointer if called from interp or the native code address if called from jit. Since we don't have any information about the execution engine of the caller, we solve this by intrinsifying all these calls, that happen in the interpreter.

Passing such function pointers between jitted and interp code is probably still unreliable.

Fixes mono#13654
@lewurm lewurm closed this in #13708 Apr 4, 2019
lewurm added a commit that referenced this issue Apr 4, 2019
This method returns a function pointer that can be called with a calli instruction. On interpreter we use a pointer to InterpMethod while on jit we use the native code address. Normally, GetFunctionPointer should return the InterpMethod pointer if called from interp or the native code address if called from jit. Since we don't have any information about the execution engine of the caller, we solve this by intrinsifying all these calls, that happen in the interpreter.

Passing such function pointers between jitted and interp code is probably still unreliable.

Fixes #13654
BrzVlad added a commit to BrzVlad/mono that referenced this issue Apr 23, 2019
This method returns a function pointer that can be called with a calli instruction. On interpreter we use a pointer to InterpMethod while on jit we use the native code address. Normally, GetFunctionPointer should return the InterpMethod pointer if called from interp or the native code address if called from jit. Since we don't have any information about the execution engine of the caller, we solve this by intrinsifying all these calls, that happen in the interpreter.

Passing such function pointers between jitted and interp code is probably still unreliable.

Fixes mono#13654
BrzVlad added a commit to BrzVlad/mono that referenced this issue Apr 23, 2019
This method returns a function pointer that can be called with a calli instruction. On interpreter we use a pointer to InterpMethod while on jit we use the native code address. Normally, GetFunctionPointer should return the InterpMethod pointer if called from interp or the native code address if called from jit. Since we don't have any information about the execution engine of the caller, we solve this by intrinsifying all these calls, that happen in the interpreter.

Passing such function pointers between jitted and interp code is probably still unreliable.

Fixes mono#13654
marek-safar added a commit that referenced this issue Apr 24, 2019
This method returns a function pointer that can be called with a calli instruction. On interpreter we use a pointer to InterpMethod while on jit we use the native code address. Normally, GetFunctionPointer should return the InterpMethod pointer if called from interp or the native code address if called from jit. Since we don't have any information about the execution engine of the caller, we solve this by intrinsifying all these calls, that happen in the interpreter.

Passing such function pointers between jitted and interp code is probably still unreliable.

Fixes #13654
lewurm added a commit that referenced this issue Apr 26, 2019
This method returns a function pointer that can be called with a calli instruction. On interpreter we use a pointer to InterpMethod while on jit we use the native code address. Normally, GetFunctionPointer should return the InterpMethod pointer if called from interp or the native code address if called from jit. Since we don't have any information about the execution engine of the caller, we solve this by intrinsifying all these calls, that happen in the interpreter.

Passing such function pointers between jitted and interp code is probably still unreliable.

Fixes #13654
jonpryor added a commit to jonpryor/xamarin-android that referenced this issue Apr 29, 2019
Fixes: mono/mono#13654
Fixes: mono/mono#14079
Fixes: xamarin/xamarin-macios#5809

Context: https://github.com/xamarin/monodroid/runs/113546526
Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=2629299

Most importantly, we *hope* that mono/mono@0136ead will fix a
Xamarin.Android Designer integration bug which prevented
`libmonosgen-2.0.dll` from being loaded on Windows because
`libmonosgen-2.0.dll` was (1) referencing `libgcc_s_seh-1.dll`, and
(2) `libgcc_s_seh-1.dll` could not be found (it wasn't packaged).

Commit mono/mono@0136ead *should* remove the dependency on
`libgcc_s_seh-1.dll`, thus fixing the Designer tests on Windows.
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Apr 30, 2019
Fixes: mono/mono#13654
Fixes: mono/mono#14079
Fixes: xamarin/xamarin-macios#5809

Context: https://github.com/xamarin/monodroid/runs/113546526
Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=2629299

Most importantly, we *hope* that mono/mono@0136ead will fix a
Xamarin.Android Designer integration bug which prevented
`libmonosgen-2.0.dll` from being loaded on Windows because
`libmonosgen-2.0.dll` was (1) referencing `libgcc_s_seh-1.dll`, and
(2) `libgcc_s_seh-1.dll` could not be found (it wasn't packaged).

Commit mono/mono@0136ead *should* remove the dependency on
`libgcc_s_seh-1.dll`, thus fixing the Designer tests on Windows.
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Apr 30, 2019
Fixes: mono/mono#13654
Fixes: mono/mono#14079
Fixes: xamarin/xamarin-macios#5809

Context: https://github.com/xamarin/monodroid/runs/113546526
Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=2629299

Most importantly, we *hope* that mono/mono@0136ead will fix a
Xamarin.Android Designer integration bug which prevented
`libmonosgen-2.0.dll` from being loaded on Windows because
`libmonosgen-2.0.dll` was (1) referencing `libgcc_s_seh-1.dll`, and
(2) `libgcc_s_seh-1.dll` could not be found (it wasn't packaged).

Commit mono/mono@0136ead *should* remove the dependency on
`libgcc_s_seh-1.dll`, thus fixing the Designer tests on Windows.
alexanderkyte added a commit to alexanderkyte/mono that referenced this issue May 6, 2019
This method returns a function pointer that can be called with a calli instruction. On interpreter we use a pointer to InterpMethod while on jit we use the native code address. Normally, GetFunctionPointer should return the InterpMethod pointer if called from interp or the native code address if called from jit. Since we don't have any information about the execution engine of the caller, we solve this by intrinsifying all these calls, that happen in the interpreter.

Passing such function pointers between jitted and interp code is probably still unreliable.

Fixes mono#13654
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.