PlayScript compiler tests using a variant of compiler-tester #8
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These have been already moved to mcs/play_tests/[as|play] and intregrated into the mono compiler-tester (make [astest|playtest|playscript]
* Moved Zynga tests to play_tests/[as|play] * Removed Zynga test dir * Add mcs/tools/playc-tester - This is a variant of tools/compiler-tester - Added -update-ref option to create intial xxx.exe.mdb.xml files for new tests - Added sub-directory support - Other misc. updates for testing .play/.as files * Add tools/compiler-tester and tools/playc-tester to mcs.master workspace * Play/AS tests conform Mono's naming, execution, testing ### Example: ./mcs/play_tests make astest ./as/test-debug-015.as... NOT TESTED ./as/test-debug-AllowDynamics.as... KNOWN ISSUE (Execution error) ./as/test-debug-DivideByZeroTest.as... KNOWN ISSUE (Compilation error) ./as/test-debug-UntypedVariableTest.as... KNOWN ISSUE (Compilation error) Done 40 test cases passed (93.02%) 1 test(s) ignored 3 known issue(s)
sushihangover
added a commit
that referenced
this pull request
Jul 17, 2015
PlayScript compiler tests using a variant of compiler-tester
sushihangover
pushed a commit
to sushihangover/playscript
that referenced
this pull request
Sep 3, 2015
Because the monitor thread was not marked as background thread, remove_and_abort_threads (threads.c:2807) would mark it as needed to be waited to shutdown the runtime, and wait_for_tids (threads.c:2652) would then wait indefinitely for it to finish. The issue was that the monitor was waiting on the semaphore monitor_sem, and thus would never exit. Thread 7 (Thread 0x1c13 of process 99776): #0 0x00007fff86590a56 in ?? () from /usr/lib/system/libsystem_kernel.dylib PlayScriptRedux#1 0x00000001003cc03a in mono_sem_wait (sem=0x1004f7f50, alertable=0) at mono-semaphore.c:103 PlayScriptRedux#2 0x00000001002cef41 in monitor_thread (unused=0x0) at threadpool.c:898 PlayScriptRedux#3 0x00000001002cb78f in start_wrapper_internal (data=0x10500abf0) at threads.c:657 PlayScriptRedux#4 0x00000001002cb4a1 in start_wrapper (data=0x10500abf0) at threads.c:704 PlayScriptRedux#5 0x00000001003d61d4 in inner_start_thread (arg=0x7fff5fbfe500) at mono-threads-posix.c:84 PlayScriptRedux#6 0x00007fff8e7c9899 in _pthread_body () from /usr/lib/system/libsystem_pthread.dylib PlayScriptRedux#7 0x00007fff8e7c972a in _pthread_start () from /usr/lib/system/libsystem_pthread.dylib PlayScriptRedux#8 0x00007fff8e7cdfc9 in thread_start () from /usr/lib/system/libsystem_pthread.dylib PlayScriptRedux#9 0x0000000000000000 in ?? () Thread 1 (Thread 0x1503 of process 99776): #0 0x00007fff86594716 in ?? () from /usr/lib/system/libsystem_kernel.dylib PlayScriptRedux#1 0x00007fff8e7cbc3b in _pthread_cond_wait () from /usr/lib/system/libsystem_pthread.dylib PlayScriptRedux#2 0x000000010039cfaa in _wapi_handle_timedwait_signal_handle (handle=0xa55, timeout=0x0, alertable=1, poll=0) at handles.c:1595 PlayScriptRedux#3 0x000000010039d03d in _wapi_handle_wait_signal_handle (handle=0xa55, alertable=1) at handles.c:1540 PlayScriptRedux#4 0x00000001003b7ba3 in WaitForSingleObjectEx (handle=0xa55, timeout=4294967295, alertable=1) at wait.c:194 PlayScriptRedux#5 0x00000001003b865d in WaitForMultipleObjectsEx (numobjects=1, handles=0x7fff5fbff1f8, waitall=1, timeout=4294967295, alertable=1) at wait.c:516 PlayScriptRedux#6 0x00000001002c75df in wait_for_tids (wait=0x7fff5fbff1f8, timeout=4294967295) at threads.c:2658 PlayScriptRedux#7 0x00000001002c70e5 in mono_thread_manage () at threads.c:2951 PlayScriptRedux#8 0x00000001000d551b in mono_main (argc=6, argv=0x7fff5fbff9e8) at driver.c:2021 PlayScriptRedux#9 0x0000000100001bd1 in mono_main_with_options (argc=6, argv=0x7fff5fbff9e8) at ./main.c:91 PlayScriptRedux#10 0x00000001000017d3 in main (argc=6, argv=0x7fff5fbff9e8) at ./main.c:122
sushihangover
pushed a commit
to sushihangover/playscript
that referenced
this pull request
Sep 3, 2015
…tempt) Because the monitor thread was not marked as background thread, remove_and_abort_threads (threads.c:2807) would mark it as needed to be waited to shutdown the runtime, and wait_for_tids (threads.c:2652) would then wait indefinitely for it to finish. The issue was that the monitor was waiting on the semaphore monitor_sem, and thus would never exit. Thread 7 (Thread 0x1c13 of process 99776): #0 0x00007fff86590a56 in ?? () from /usr/lib/system/libsystem_kernel.dylib PlayScriptRedux#1 0x00000001003cc03a in mono_sem_wait (sem=0x1004f7f50, alertable=0) at mono-semaphore.c:103 PlayScriptRedux#2 0x00000001002cef41 in monitor_thread (unused=0x0) at threadpool.c:898 PlayScriptRedux#3 0x00000001002cb78f in start_wrapper_internal (data=0x10500abf0) at threads.c:657 PlayScriptRedux#4 0x00000001002cb4a1 in start_wrapper (data=0x10500abf0) at threads.c:704 PlayScriptRedux#5 0x00000001003d61d4 in inner_start_thread (arg=0x7fff5fbfe500) at mono-threads-posix.c:84 PlayScriptRedux#6 0x00007fff8e7c9899 in _pthread_body () from /usr/lib/system/libsystem_pthread.dylib PlayScriptRedux#7 0x00007fff8e7c972a in _pthread_start () from /usr/lib/system/libsystem_pthread.dylib PlayScriptRedux#8 0x00007fff8e7cdfc9 in thread_start () from /usr/lib/system/libsystem_pthread.dylib PlayScriptRedux#9 0x0000000000000000 in ?? () Thread 1 (Thread 0x1503 of process 99776): #0 0x00007fff86594716 in ?? () from /usr/lib/system/libsystem_kernel.dylib PlayScriptRedux#1 0x00007fff8e7cbc3b in _pthread_cond_wait () from /usr/lib/system/libsystem_pthread.dylib PlayScriptRedux#2 0x000000010039cfaa in _wapi_handle_timedwait_signal_handle (handle=0xa55, timeout=0x0, alertable=1, poll=0) at handles.c:1595 PlayScriptRedux#3 0x000000010039d03d in _wapi_handle_wait_signal_handle (handle=0xa55, alertable=1) at handles.c:1540 PlayScriptRedux#4 0x00000001003b7ba3 in WaitForSingleObjectEx (handle=0xa55, timeout=4294967295, alertable=1) at wait.c:194 PlayScriptRedux#5 0x00000001003b865d in WaitForMultipleObjectsEx (numobjects=1, handles=0x7fff5fbff1f8, waitall=1, timeout=4294967295, alertable=1) at wait.c:516 PlayScriptRedux#6 0x00000001002c75df in wait_for_tids (wait=0x7fff5fbff1f8, timeout=4294967295) at threads.c:2658 PlayScriptRedux#7 0x00000001002c70e5 in mono_thread_manage () at threads.c:2951 PlayScriptRedux#8 0x00000001000d551b in mono_main (argc=6, argv=0x7fff5fbff9e8) at driver.c:2021 PlayScriptRedux#9 0x0000000100001bd1 in mono_main_with_options (argc=6, argv=0x7fff5fbff9e8) at ./main.c:91 PlayScriptRedux#10 0x00000001000017d3 in main (argc=6, argv=0x7fff5fbff9e8) at ./main.c:122 Thanks @akoeplinger for the help debugging
sushihangover
pushed a commit
that referenced
this pull request
Dec 9, 2015
We've seen that error for quite some time: > `* Assertion at ../../mono/utils/mono-os-mutex.h:71, condition `res != EINVAL' not met` It looks like there's a race between `finalizer_thread()` and `mono_gc_cleanup()` around `reference_queue_mutex`. The source of the problem is, `finalizer_thread` could end up being alive, although `mono_gc_cleanup()` made some effort to kill it and then destroys `reference_queue_mutex`, while the finalizer thread is still using it in `reference_queue_proccess_all()`. > $ MONO_GC_DEBUG=bridge=Bridge MONO_GC_PARAMS=minor=split MONO_ENV_OPTIONS=--gc=sgen MONO_PATH=/home/lewurm/monoperf/mono/mcs/class/lib/net_4_x ../../mono/mini/mono sgen-bridge-major-fragmentation.exe --optimize=all --debug > [...] > [12/08/2015 01:49:31] done > Shutting down finalizer thread timed out. > * Assertion at gc.c:867, condition `finalizer_thread_exited' not met > > Stacktrace: > > > Native stacktrace: > > > Debug info from gdb: > > [New LWP 7623] > [New LWP 7622] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". > 0x4043b5f4 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0 > Id Target Id Frame > 3 Thread 0x417ff430 (LWP 7622) "mono" 0x4043b5f4 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0 > 2 Thread 0x42573430 (LWP 7623) "Finalizer" 0x0021482a in finalizers_with_predicate (predicate=0x1fd121 <object_in_domain_predicate>, user_data=0x37a348, out_array=0x42572c70, out_size=64, hash_table=0x338f68 <major_finalizable_hash>) at sgen-fin-weak-hash.c:581 > * 1 Thread 0x406c4250 (LWP 7620) "mono" 0x4043b5f4 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0 > > Thread 3 (Thread 0x417ff430 (LWP 7622)): > #0 0x4043b5f4 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0 > #1 0x404371d8 in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0 > #2 0x00242266 in mono_os_cond_wait (cond=0x346e98 <work_cond>, mutex=0x346e80 <lock>) at ../../mono/utils/mono-os-mutex.h:105 > #3 0x00242c1a in thread_func (thread_data=0x0) at sgen-thread-pool.c:118 > #4 0x40433fbc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0 > #5 0x405a0b3c in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > Thread 2 (Thread 0x42573430 (LWP 7623)): > #0 0x0021482a in finalizers_with_predicate (predicate=0x1fd121 <object_in_domain_predicate>, user_data=0x37a348, out_array=0x42572c70, out_size=64, hash_table=0x338f68 <major_finalizable_hash>) at sgen-fin-weak-hash.c:581 > #1 0x00214894 in sgen_gather_finalizers_if (predicate=0x1fd121 <object_in_domain_predicate>, user_data=0x37a348, out_array=0x42572c70, out_size=64) at sgen-fin-weak-hash.c:622 > #2 0x001fd16a in mono_gc_finalizers_for_domain (domain=0x37a348, out_array=0x42572c70, out_size=64) at sgen-mono.c:546 > #3 0x001ca2a4 in finalize_domain_objects (req=0x47ba68) at gc.c:678 > #4 0x001ca3b6 in finalizer_thread (unused=0x0) at gc.c:730 > #5 0x001a1392 in start_wrapper_internal (data=0x3b1100) at threads.c:713 > #6 0x001a1430 in start_wrapper (data=0x3b1100) at threads.c:760 > #7 0x0027097a in inner_start_thread (arg=0xbed58de0) at mono-threads-posix.c:92 > #8 0x40433fbc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0 > #9 0x405a0b3c in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > Thread 1 (Thread 0x406c4250 (LWP 7620)): > #0 0x4043b5f4 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0 > #1 0x4043a396 in waitpid () from /lib/arm-linux-gnueabihf/libpthread.so.0 > #2 0x000d1b24 in mono_handle_native_sigsegv (signal=6, ctx=0xbed58a80, info=0xbed58a00) at mini-exceptions.c:2235 > #3 0x00112424 in sigabrt_signal_handler (_dummy=6, _info=0xbed58a00, context=0xbed58a80) at mini-posix.c:218 > #4 <signal handler called> > #5 0x405248e6 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 > #6 0x405330fe in raise () from /lib/arm-linux-gnueabihf/libc.so.6 > #7 0x40535956 in abort () from /lib/arm-linux-gnueabihf/libc.so.6 > #8 0x00277eaa in monoeg_log_default_handler (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, message=0x47bb28 "* Assertion at gc.c:867, condition `finalizer_thread_exited' not met\n", unused_data=0x0) at goutput.c:233 > #9 0x00277dca in monoeg_g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, format=0x3089b8 "* Assertion at %s:%d, condition `%s' not met\n", args=...) at goutput.c:113 > #10 0x00277e32 in monoeg_assertion_message (format=0x3089b8 "* Assertion at %s:%d, condition `%s' not met\n") at goutput.c:133 > #11 0x001ca786 in mono_gc_cleanup () at gc.c:867 > #12 0x001c1d24 in mono_runtime_cleanup (domain=0x37a348) at appdomain.c:356 > #13 0x0001dec0 in mini_cleanup (domain=0x37a348) at mini-runtime.c:3560 > #14 0x000a672c in mono_main (argc=5, argv=0x358098) at driver.c:2065 > #15 0x00017c4e in mono_main_with_options (argc=5, argv=0x358098) at main.c:20 > #16 0x00017c7e in main (argc=4, argv=0xbed591b4) at main.c:53 ================================================================= Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. =================================================================
sushihangover
pushed a commit
to sushihangover/playscript
that referenced
this pull request
Sep 2, 2016
We would previously observe the following crash: ``` ludovic-laptop :: ~/Xamarin/mono ‹16c07b5› » (cd tools/pedump && MONO_PATH=../../mcs/class/lib/net_4_x lldb -- ./pedump --verify metadata,code ../.././mono/tests/xdomain-threads.exe) (lldb) target create "./pedump" Current executable set to './pedump' (x86_64). (lldb) settings set -- target.run-args "--verify" "metadata,code" "../.././mono/tests/xdomain-threads.exe" (lldb) r Process 14407 launched: './pedump' (x86_64) mono_os_mutex_lock: pthread_mutex_lock failed with "Invalid argument" (22) Process 14407 stopped * thread PlayScriptRedux#1: tid = 0x27c9715, 0x00007fff93cfcf06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x00007fff93cfcf06 libsystem_kernel.dylib`__pthread_kill + 10 libsystem_kernel.dylib`__pthread_kill: -> 0x7fff93cfcf06 <+10>: jae 0x7fff93cfcf10 ; <+20> 0x7fff93cfcf08 <+12>: movq %rax, %rdi 0x7fff93cfcf0b <+15>: jmp 0x7fff93cf77cd ; cerror_nocancel 0x7fff93cfcf10 <+20>: retq (lldb) bt * thread PlayScriptRedux#1: tid = 0x27c9715, 0x00007fff93cfcf06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT * frame #0: 0x00007fff93cfcf06 libsystem_kernel.dylib`__pthread_kill + 10 frame PlayScriptRedux#1: 0x00007fff8b9b74ec libsystem_pthread.dylib`pthread_kill + 90 frame PlayScriptRedux#2: 0x00007fff908d56e7 libsystem_c.dylib`abort + 129 frame PlayScriptRedux#3: 0x000000010022da6a pedump`monoeg_log_default_handler(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, message="mono_os_mutex_lock: pthread_mutex_lock failed with \"Invalid argument\" (22)", unused_data=0x0000000000000000) + 202 at goutput.c:231 frame PlayScriptRedux#4: 0x000000010022d98d pedump`monoeg_g_logv(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, format="%s: pthread_mutex_lock failed with \"%s\" (%d)", args=0x00007fff5fbff4a0) + 109 at goutput.c:111 frame PlayScriptRedux#5: 0x000000010022dbd9 pedump`monoeg_g_log(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, format="%s: pthread_mutex_lock failed with \"%s\" (%d)") + 361 at goutput.c:121 frame PlayScriptRedux#6: 0x000000010022301e pedump`mono_os_mutex_lock(mutex=0x00000001002ec630) + 110 at mono-os-mutex.h:98 frame PlayScriptRedux#7: 0x0000000100223a66 pedump`mono_w32handle_new(type=MONO_W32HANDLE_PROCESS, handle_specific=0x00007fff5fbff540) + 246 at w32handle.c:440 frame PlayScriptRedux#8: 0x00000001001ef8bb pedump`_wapi_processes_init + 123 at processes.c:1149 frame PlayScriptRedux#9: 0x00000001001fbcc3 pedump`wapi_init + 19 at wapi.c:23 frame PlayScriptRedux#10: 0x0000000100116486 pedump`mono_init_internal(filename="pedump", exe_filename=0x0000000000000000, runtime_version="v4.0.30319") + 102 at domain.c:528 frame PlayScriptRedux#11: 0x0000000100117124 pedump`mono_init_version(domain_name="pedump", version="v4.0.30319") + 36 at domain.c:868 frame PlayScriptRedux#12: 0x0000000100001496 pedump`verify_image_file(fname="../.././mono/tests/xdomain-threads.exe") + 678 at pedump.c:466 frame PlayScriptRedux#13: 0x0000000100000f87 pedump`main(argc=4, argv=0x00007fff5fbff9a0) + 1095 at pedump.c:708 frame PlayScriptRedux#14: 0x00007fff93e655ad libdyld.dylib`start + 1 ``` That would be because the w32handle wouldn't be initialized before calling into `wapi_init` which allocates w32handle.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PlayScript compiler tests using a variant of compiler-tester
Example: