[Mono-dev] Array.Copy endian issue?
Hello, I’m chasing a bug while parsing the machine.config XML file, and I’ve narrowed it down to Array.Copy performing the wrong copy. Here’s an example: before copy 'descript' after copy ' edcsirt' The buffer is altered after its copied. This seems to happen only on newer versions of linux (3.4.6) on an armv5tel device. When running linux 2.6 I don’t see this. Any thoughts on what might be causing this? Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Array.Copy endian issue?
A little more details. If I remove the FastCopy call in Array.Copy I am unable to reproduce this. // if (FastCopy (sourceArray, sourceIndex, destinationArray, destinationIndex, length)) // return; Attached is a test case but it needs to be run on a ARM device with the same version of Linux. Happy to provide access to a box if needed. I’ll open a Xamarin bug too. Thanks! Bassam On Jan 29, 2014, at 3:53 PM, Bassam Tabbara bas...@symform.com wrote: Hello, I’m chasing a bug while parsing the machine.config XML file, and I’ve narrowed it down to Array.Copy performing the wrong copy. Here’s an example: before copy 'descript' after copy ' edcsirt' The buffer is altered after its copied. This seems to happen only on newer versions of linux (3.4.6) on an armv5tel device. When running linux 2.6 I don’t see this. Any thoughts on what might be causing this? Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Program.cs Description: Program.cs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Assert: condition `ret == 0' not met
I can confirm that the following commit builds fine: b71c0d6afc85ec1512d89692ca09dfc1692494cd I also just pulled that latest from master (with Zoltan’s fix) and it builds fine. Thanks for the quick turnaround! Bassam On Jan 14, 2014, at 8:04 AM, Andrés G. Aragoneses kno...@gmail.commailto:kno...@gmail.com wrote: Bassam, I bisected it and I think the culprit is in this commit: https://github.com/mono/mono/commit/a0afa38296b8a3b0382bf34ce777357d2553c0f0 Can you confirm my finding by trying to build the previous commit to this one? Thanks On 14/01/14 02:55, Andrés G. Aragoneses wrote: I confirm the problem, I also get it in Linux64bits On 14/01/14 00:33, Bassam Tabbara wrote: Yes. This is a clean build from mono/master. On Jan 13, 2014, at 3:07 PM, Rodrigo Kumpera kump...@gmail.com mailto:kump...@gmail.com wrote: Are you trying to build mono/master without any changes? That has not happen with our bots at xamarin. On Mon, Jan 13, 2014 at 4:47 PM, Bassam Tabbara bas...@symform.com mailto:bas...@symform.com wrote: Hello, I’m seeing the following exception while building MCS from the latest in master. This is on my mac (OSX 10.9). Any thoughts? System.Collections.Concurrent/BlockingCollection.cs(396,9): warning CS0219: The variable `index' is assigned but its value is never used System.Diagnostics/TraceImpl.cs(44,15): warning CS0649: Field `System.Diagnostics.TraceImplSettings.AutoFlush' is never assigned to, and will always have its default value `false' Compilation succeeded - 5 warning(s) * Assertion at gc.c:1216, condition `ret == 0' not met Stacktrace: at unknown 0x at (wrapper managed-to-native) System.Environment.Exit (int) 0x at Mono.CSharp.Driver.Main (string[]) 0x002b3 at (wrapper runtime-invoke) Module.runtime_invoke_int_object (object,intptr,intptr,intptr) 0x Native stacktrace: 0 mono0x000109261dfb mono_handle_native_sigsegv + 363 1 libsystem_platform.dylib0x7fff88bf05aa _sigtramp + 26 2 libsystem_c.dylib 0x7fff81b9ed8b __sprintf_chk + 153 3 libsystem_c.dylib 0x7fff81b7abba abort + 125 4 mono0x0001093eee11 monoeg_g_logv + 161 5 mono0x0001093eef4f monoeg_assertion_message + 143 6 mono0x000109365524 mono_gc_cleanup + 260 7 mono0x00010935bc1e mono_runtime_cleanup + 14 8 mono0x0001091d900c mini_cleanup + 956 9 mono0x0001092e6525 ves_icall_System_Environment_Exit + 37 10 ??? 0x0001119d2324 0x0 + 4590478116 11 mono0x0001091d88f5 mono_jit_runtime_invoke + 1653 12 mono0x00010936871b mono_runtime_invoke + 107 13 mono0x00010936e726 mono_runtime_exec_main + 374 14 mono0x0001092358d9 mono_main + 6121 15 mono0x0001091cc6ec main + 588 16 libdyld.dylib 0x7fff8d2195fd start + 1 17 ??? 0x001b 0x0 + 27 Debug info from gdb: Process 93570 stopped * thread #1: tid = 0x250792, 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP thread #2: tid = 0x2507a0, 0x7fff8da88e6a libsystem_kernel.dylib`__workq_kernreturn + 10 thread #3: tid = 0x2507a1, 0x7fff8da89662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager thread #4: tid = 0x2507a2, 0x7fff8da88e6a libsystem_kernel.dylib`__workq_kernreturn + 10 (lldb) * thread #1: tid = 0x250792, 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP frame #0: 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10 frame #1: 0x000109261ed4 mono`mono_handle_native_sigsegv(signal=unavailable, ctx=unavailable) + 580 at mini-exceptions.c:2299 frame #2: 0x7fff88bf05aa libsystem_platform.dylib`_sigtramp + 26 frame #3: 0x7fff8da88867 libsystem_kernel.dylib`__pthread_kill + 11 frame #4: 0x7fff81b9ed8b libsystem_c.dylib`__sprintf_chk + 153 frame #5: 0x7fff81b7abba libsystem_c.dylib`abort + 125 frame #6: 0x0001093eee11 mono`monoeg_g_logv(log_domain=unavailable, log_level=unavailable, format=unavailable, args=unavailable
[Mono-dev] Assert: condition `ret == 0' not met
Hello, I’m seeing the following exception while building MCS from the latest in master. This is on my mac (OSX 10.9). Any thoughts? System.Collections.Concurrent/BlockingCollection.cs(396,9): warning CS0219: The variable `index' is assigned but its value is never used System.Diagnostics/TraceImpl.cs(44,15): warning CS0649: Field `System.Diagnostics.TraceImplSettings.AutoFlush' is never assigned to, and will always have its default value `false' Compilation succeeded - 5 warning(s) * Assertion at gc.c:1216, condition `ret == 0' not met Stacktrace: at unknown 0x at (wrapper managed-to-native) System.Environment.Exit (int) 0x at Mono.CSharp.Driver.Main (string[]) 0x002b3 at (wrapper runtime-invoke) Module.runtime_invoke_int_object (object,intptr,intptr,intptr) 0x Native stacktrace: 0 mono0x000109261dfb mono_handle_native_sigsegv + 363 1 libsystem_platform.dylib0x7fff88bf05aa _sigtramp + 26 2 libsystem_c.dylib 0x7fff81b9ed8b __sprintf_chk + 153 3 libsystem_c.dylib 0x7fff81b7abba abort + 125 4 mono0x0001093eee11 monoeg_g_logv + 161 5 mono0x0001093eef4f monoeg_assertion_message + 143 6 mono0x000109365524 mono_gc_cleanup + 260 7 mono0x00010935bc1e mono_runtime_cleanup + 14 8 mono0x0001091d900c mini_cleanup + 956 9 mono0x0001092e6525 ves_icall_System_Environment_Exit + 37 10 ??? 0x0001119d2324 0x0 + 4590478116 11 mono0x0001091d88f5 mono_jit_runtime_invoke + 1653 12 mono0x00010936871b mono_runtime_invoke + 107 13 mono0x00010936e726 mono_runtime_exec_main + 374 14 mono0x0001092358d9 mono_main + 6121 15 mono0x0001091cc6ec main + 588 16 libdyld.dylib 0x7fff8d2195fd start + 1 17 ??? 0x001b 0x0 + 27 Debug info from gdb: Process 93570 stopped * thread #1: tid = 0x250792, 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP thread #2: tid = 0x2507a0, 0x7fff8da88e6a libsystem_kernel.dylib`__workq_kernreturn + 10 thread #3: tid = 0x2507a1, 0x7fff8da89662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager thread #4: tid = 0x2507a2, 0x7fff8da88e6a libsystem_kernel.dylib`__workq_kernreturn + 10 (lldb) * thread #1: tid = 0x250792, 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP frame #0: 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10 frame #1: 0x000109261ed4 mono`mono_handle_native_sigsegv(signal=unavailable, ctx=unavailable) + 580 at mini-exceptions.c:2299 frame #2: 0x7fff88bf05aa libsystem_platform.dylib`_sigtramp + 26 frame #3: 0x7fff8da88867 libsystem_kernel.dylib`__pthread_kill + 11 frame #4: 0x7fff81b9ed8b libsystem_c.dylib`__sprintf_chk + 153 frame #5: 0x7fff81b7abba libsystem_c.dylib`abort + 125 frame #6: 0x0001093eee11 mono`monoeg_g_logv(log_domain=unavailable, log_level=unavailable, format=unavailable, args=unavailable) + 161 at goutput.c:175 frame #7: 0x0001093eef4f mono`monoeg_assertion_message(format=unavailable) + 143 at goutput.c:195 frame #8: 0x000109365524 mono`mono_gc_cleanup + 260 at gc.c:1216 frame #9: 0x00010935bc1e mono`mono_runtime_cleanup(domain=unavailable) + 14 at appdomain.c:354 frame #10: 0x0001091d900c mono`mini_cleanup(domain=0x7fb070501350) + 956 at mini.c:7626 frame #11: 0x0001092e6525 mono`ves_icall_System_Environment_Exit(result=0) + 37 at icall.c:6517 frame #12: 0x0001119d2324 frame #13: 0x0001091d88f5 mono`mono_jit_runtime_invoke(method=unavailable, obj=0x, params=unavailable, exc=unavailable) + 1653 at mini.c:6654 frame #14: 0x00010936871b mono`mono_runtime_invoke(method=0x7fb0705025b0, obj=0x, params=0x7fff56a33d68, exc=0x) + 107 at object.c:2828 frame #15: 0x00010936e726 mono`mono_runtime_exec_main(method=0x7fb0705025b0, args=unavailable, exc=0x) + 374 at object.c:4053 frame #16: 0x0001092358d9 mono`mono_main [inlined] main_thread_handler + 6121 at driver.c:1066 frame #17: 0x0001092358a2 mono`mono_main(argc=24, argv=unavailable) + 6066 at driver.c:2014
Re: [Mono-dev] Assert: condition `ret == 0' not met
Yes. This is a clean build from mono/master. On Jan 13, 2014, at 3:07 PM, Rodrigo Kumpera kump...@gmail.commailto:kump...@gmail.com wrote: Are you trying to build mono/master without any changes? That has not happen with our bots at xamarin. On Mon, Jan 13, 2014 at 4:47 PM, Bassam Tabbara bas...@symform.commailto:bas...@symform.com wrote: Hello, I’m seeing the following exception while building MCS from the latest in master. This is on my mac (OSX 10.9). Any thoughts? System.Collections.Concurrent/BlockingCollection.cs(396,9): warning CS0219: The variable `index' is assigned but its value is never used System.Diagnostics/TraceImpl.cs(44,15): warning CS0649: Field `System.Diagnostics.TraceImplSettings.AutoFlush' is never assigned to, and will always have its default value `false' Compilation succeeded - 5 warning(s) * Assertion at gc.c:1216, condition `ret == 0' not met Stacktrace: at unknown 0x at (wrapper managed-to-native) System.Environment.Exit (int) 0x at Mono.CSharp.Driver.Main (string[]) 0x002b3 at (wrapper runtime-invoke) Module.runtime_invoke_int_object (object,intptr,intptr,intptr) 0x Native stacktrace: 0 mono0x000109261dfb mono_handle_native_sigsegv + 363 1 libsystem_platform.dylib0x7fff88bf05aa _sigtramp + 26 2 libsystem_c.dylib 0x7fff81b9ed8b __sprintf_chk + 153 3 libsystem_c.dylib 0x7fff81b7abba abort + 125 4 mono0x0001093eee11 monoeg_g_logv + 161 5 mono0x0001093eef4f monoeg_assertion_message + 143 6 mono0x000109365524 mono_gc_cleanup + 260 7 mono0x00010935bc1e mono_runtime_cleanup + 14 8 mono0x0001091d900c mini_cleanup + 956 9 mono0x0001092e6525 ves_icall_System_Environment_Exit + 37 10 ??? 0x0001119d2324 0x0 + 4590478116 11 mono0x0001091d88f5 mono_jit_runtime_invoke + 1653 12 mono0x00010936871b mono_runtime_invoke + 107 13 mono0x00010936e726 mono_runtime_exec_main + 374 14 mono0x0001092358d9 mono_main + 6121 15 mono0x0001091cc6ec main + 588 16 libdyld.dylib 0x7fff8d2195fd start + 1 17 ??? 0x001b 0x0 + 27 Debug info from gdb: Process 93570 stopped * thread #1: tid = 0x250792, 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP thread #2: tid = 0x2507a0, 0x7fff8da88e6a libsystem_kernel.dylib`__workq_kernreturn + 10 thread #3: tid = 0x2507a1, 0x7fff8da89662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager thread #4: tid = 0x2507a2, 0x7fff8da88e6a libsystem_kernel.dylib`__workq_kernreturn + 10 (lldb) * thread #1: tid = 0x250792, 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP frame #0: 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10 frame #1: 0x000109261ed4 mono`mono_handle_native_sigsegv(signal=unavailable, ctx=unavailable) + 580 at mini-exceptions.c:2299 frame #2: 0x7fff88bf05aa libsystem_platform.dylib`_sigtramp + 26 frame #3: 0x7fff8da88867 libsystem_kernel.dylib`__pthread_kill + 11 frame #4: 0x7fff81b9ed8b libsystem_c.dylib`__sprintf_chk + 153 frame #5: 0x7fff81b7abba libsystem_c.dylib`abort + 125 frame #6: 0x0001093eee11 mono`monoeg_g_logv(log_domain=unavailable, log_level=unavailable, format=unavailable, args=unavailable) + 161 at goutput.c:175 frame #7: 0x0001093eef4f mono`monoeg_assertion_message(format=unavailable) + 143 at goutput.c:195 frame #8: 0x000109365524 mono`mono_gc_cleanup + 260 at gc.c:1216 frame #9: 0x00010935bc1e mono`mono_runtime_cleanup(domain=unavailable) + 14 at appdomain.c:354 frame #10: 0x0001091d900c mono`mini_cleanup(domain=0x7fb070501350) + 956 at mini.c:7626 frame #11: 0x0001092e6525 mono`ves_icall_System_Environment_Exit(result=0) + 37 at icall.c:6517 frame #12: 0x0001119d2324 frame #13: 0x0001091d88f5 mono`mono_jit_runtime_invoke(method=unavailable, obj=0x, params=unavailable, exc=unavailable) + 1653 at mini.c:6654 frame #14: 0x00010936871b mono`mono_runtime_invoke(method=0x7fb0705025b0, obj=0x, params=0x7fff56a33d68, exc=0x) + 107 at object.c:2828 frame #15
[Mono-dev] Help w/ deadlock on shutdown
Hello, I’m seeing a deadlock on shutdown of latest mono form master when using our own native background thread. Here are backtraces: * thread #1: tid = 0xd83c3, 0x7fff91412716 libsystem_kernel.dylib`__psynch_cvwait + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP frame #0: 0x7fff91412716 libsystem_kernel.dylib`__psynch_cvwait + 10 frame #1: 0x7fff86b20c3b libsystem_pthread.dylib`_pthread_cond_wait + 727 frame #2: 0x00010919a892 mono`_wapi_handle_timedwait_signal_handle(handle=unavailable, timeout=unavailable, alertable=1, poll=unavailable) + 514 at handles.c:1588 frame #3: 0x0001091ab95b mono`WaitForMultipleObjectsEx(numobjects=7, handles=0x7fff56c6f2f0, waitall=1, timeout=4294967295, alertable=1) + 1419 at wait.c:668 frame #4: 0x000109112a2f mono`wait_for_tids(wait=0x7fff56c6f2f0, timeout=unavailable) + 47 at threads.c:2809 frame #5: 0x000109112626 mono`mono_thread_manage + 694 at threads.c:3095 frame #6: 0x000108ffc9fd mono`mono_main(argc=11, argv=unavailable) + 6301 at driver.c:2015 frame #7: 0x000108f92a0c mono`main [inlined] mono_main_with_options(argv=unavailable, argc=unavailable) + 549 at main.c:98 frame #8: 0x000108f927e7 mono`main(argc=unavailable, argv=unavailable) + 39 at main.c:133 frame #9: 0x7fff8d7875fd libdyld.dylib`start + 1 thread #2: tid = 0xd83c5, 0x7fff9140ea56 libsystem_kernel.dylib`semaphore_wait_trap + 10 frame #0: 0x7fff9140ea56 libsystem_kernel.dylib`semaphore_wait_trap + 10 frame #1: 0x0001091b8d38 mono`mono_sem_wait(sem=0x00010930ad78, alertable=unavailable) + 24 at mono-semaphore.c:121 frame #2: 0x000109136017 mono`finalizer_thread(unused=unavailable) + 103 at gc.c:1073 frame #3: 0x00010910d743 mono`start_wrapper [inlined] start_wrapper_internal + 456 at threads.c:609 frame #4: 0x00010910d57b mono`start_wrapper(data=unavailable) + 43 at threads.c:654 frame #5: 0x0001091acd50 mono`thread_start_routine(args=0x7f930981cbf8) + 144 at wthreads.c:294 frame #6: 0x0001091bdffa mono`inner_start_thread(arg=unavailable) + 58 at mono-threads-posix.c:49 frame #7: 0x7fff86b1e899 libsystem_pthread.dylib`_pthread_body + 138 frame #8: 0x7fff86b1e72a libsystem_pthread.dylib`_pthread_start + 137 frame #9: 0x7fff86b22fc9 libsystem_pthread.dylib`thread_start + 13 thread #3: tid = 0xd83c9, 0x7fff91413662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager frame #0: 0x7fff91413662 libsystem_kernel.dylib`kevent64 + 10 frame #1: 0x7fff8e0ac43d libdispatch.dylib`_dispatch_mgr_invoke + 239 frame #2: 0x7fff8e0ac152 libdispatch.dylib`_dispatch_mgr_thread + 52 thread #4: tid = 0xda1fc, 0x7fff9141364a libsystem_kernel.dylib`kevent + 10 frame #0: 0x7fff9141364a libsystem_kernel.dylib`kevent + 10 frame #1: 0x00010fa22712 libsymformutp.dylib`kq_dispatch(base=0x7f930b564890, tv=unavailable) + 706 at kqueue.c:301 frame #2: 0x00010fa17429 libsymformutp.dylib`event_base_loop(base=0x7f930b564890, flags=unavailable) + 873 at event.c:1826 frame #3: 0x00010f9fe657 libsymformutp.dylib`UTPEvents::Run(e=0x7f930b566180) + 23 at utp_event.cpp:81 frame #4: 0x7fff86b1e899 libsystem_pthread.dylib`_pthread_body + 138 frame #5: 0x7fff86b1e72a libsystem_pthread.dylib`_pthread_start + 137 frame #6: 0x7fff86b22fc9 libsystem_pthread.dylib`thread_start + 13 thread #4 is out native thread that will be shutdown when a managed SafeHandle is released. This thread is likely to have called managed code at some point. thread #1 seems to be waiting on all threads to exit including thread #4, but until finalization is complete on thread #2 this is not going to happen, and hence the deadlock. Does this seem likely? Why does mono runtime wait for threads to exit that it did not create? Should finalization happen before waiting for all threads to exit? Thanks in advance for the help. Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Help w/ deadlock on shutdown
Jonathan, thanks for the info. The native thread (#4) does not know about mono nor is it linked with the mono libraries, it would be hard to call mono_thread_detach from it. Is there a different solution to this? Out of curiosity why does mono not detach a thread once a managed call is complete from a native thread. On Dec 13, 2013, at 12:55 PM, Jonathan Chambers jonc...@gmail.commailto:jonc...@gmail.com wrote: If the native thread calls into managed code it is automatically 'attached' to the mono runtime and the gc for tracking. It does not automatically unattached upon return of the call into managed code. Then at shutdown the native thread is part of the list of threads that are expected to exit before the runtime can shut down properly. Try to call mono_thread_detach() in thread #4 before entering the wait for shutdown. - Jonathan On Fri, Dec 13, 2013 at 1:09 PM, Bassam Tabbara bas...@symform.commailto:bas...@symform.com wrote: Hello, I’m seeing a deadlock on shutdown of latest mono form master when using our own native background thread. Here are backtraces: * thread #1: tid = 0xd83c3, 0x7fff91412716 libsystem_kernel.dylib`__psynch_cvwait + 10, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP frame #0: 0x7fff91412716 libsystem_kernel.dylib`__psynch_cvwait + 10 frame #1: 0x7fff86b20c3b libsystem_pthread.dylib`_pthread_cond_wait + 727 frame #2: 0x00010919a892 mono`_wapi_handle_timedwait_signal_handle(handle=unavailable, timeout=unavailable, alertable=1, poll=unavailable) + 514 at handles.c:1588 frame #3: 0x0001091ab95b mono`WaitForMultipleObjectsEx(numobjects=7, handles=0x7fff56c6f2f0, waitall=1, timeout=4294967295, alertable=1) + 1419 at wait.c:668 frame #4: 0x000109112a2f mono`wait_for_tids(wait=0x7fff56c6f2f0, timeout=unavailable) + 47 at threads.c:2809 frame #5: 0x000109112626 mono`mono_thread_manage + 694 at threads.c:3095 frame #6: 0x000108ffc9fd mono`mono_main(argc=11, argv=unavailable) + 6301 at driver.c:2015 frame #7: 0x000108f92a0c mono`main [inlined] mono_main_with_options(argv=unavailable, argc=unavailable) + 549 at main.c:98 frame #8: 0x000108f927e7 mono`main(argc=unavailable, argv=unavailable) + 39 at main.c:133 frame #9: 0x7fff8d7875fd libdyld.dylib`start + 1 thread #2: tid = 0xd83c5, 0x7fff9140ea56 libsystem_kernel.dylib`semaphore_wait_trap + 10 frame #0: 0x7fff9140ea56 libsystem_kernel.dylib`semaphore_wait_trap + 10 frame #1: 0x0001091b8d38 mono`mono_sem_wait(sem=0x00010930ad78, alertable=unavailable) + 24 at mono-semaphore.c:121 frame #2: 0x000109136017 mono`finalizer_thread(unused=unavailable) + 103 at gc.c:1073 frame #3: 0x00010910d743 mono`start_wrapper [inlined] start_wrapper_internal + 456 at threads.c:609 frame #4: 0x00010910d57b mono`start_wrapper(data=unavailable) + 43 at threads.c:654 frame #5: 0x0001091acd50 mono`thread_start_routine(args=0x7f930981cbf8) + 144 at wthreads.c:294 frame #6: 0x0001091bdffa mono`inner_start_thread(arg=unavailable) + 58 at mono-threads-posix.c:49 frame #7: 0x7fff86b1e899 libsystem_pthread.dylib`_pthread_body + 138 frame #8: 0x7fff86b1e72a libsystem_pthread.dylib`_pthread_start + 137 frame #9: 0x7fff86b22fc9 libsystem_pthread.dylib`thread_start + 13 thread #3: tid = 0xd83c9, 0x7fff91413662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager frame #0: 0x7fff91413662 libsystem_kernel.dylib`kevent64 + 10 frame #1: 0x7fff8e0ac43d libdispatch.dylib`_dispatch_mgr_invoke + 239 frame #2: 0x7fff8e0ac152 libdispatch.dylib`_dispatch_mgr_thread + 52 thread #4: tid = 0xda1fc, 0x7fff9141364a libsystem_kernel.dylib`kevent + 10 frame #0: 0x7fff9141364a libsystem_kernel.dylib`kevent + 10 frame #1: 0x00010fa22712 libsymformutp.dylib`kq_dispatch(base=0x7f930b564890, tv=unavailable) + 706 at kqueue.c:301 frame #2: 0x00010fa17429 libsymformutp.dylib`event_base_loop(base=0x7f930b564890, flags=unavailable) + 873 at event.c:1826 frame #3: 0x00010f9fe657 libsymformutp.dylib`UTPEvents::Run(e=0x7f930b566180) + 23 at utp_event.cpp:81 frame #4: 0x7fff86b1e899 libsystem_pthread.dylib`_pthread_body + 138 frame #5: 0x7fff86b1e72a libsystem_pthread.dylib`_pthread_start + 137 frame #6: 0x7fff86b22fc9 libsystem_pthread.dylib`thread_start + 13 thread #4 is out native thread that will be shutdown when a managed SafeHandle is released. This thread is likely to have called managed code at some point. thread #1 seems to be waiting on all threads to exit including thread #4, but until finalization is complete on thread #2 this is not going to happen, and hence the deadlock. Does this seem likely? Why does mono runtime wait for threads to exit that it did not create? Should finalization happen before waiting
Re: [Mono-dev] Compiling for i586 Linux target on an i686 Linux machine
Chris, Try: ./configure --host=i585-unknown-linux-gnu Thanks! Bassam On Sep 16, 2013, at 2:49 PM, Chris Tacke cta...@opennetcf.commailto:cta...@opennetcf.com wrote: I need to get a 32-bit i586 build of the latest version of Mono to run on an embedded target. For a build machine I’m using Ubuntu 12 on 32-bit i686 VM. I have successfully pulled the Mono sources and built them using the default configuration, and the resulting Mono binaries work just fine ion an i686 machine. When I attempt to run on an i586 machine, I get an error that simply says “Illegal instruction” I assume that I need to cross-compile for i586, but I can’t find a --target setting that works I’ve tried a few things: ./configure --target=i586 ./configure --target=i586-linux ./configure --target=i586-linux-gcc And I always get an error along these lines (the target name changes with what I send in): Configure: error: Cross compiling is not supported for target i586-pc-linux-gcc Is there a known-good –target flag that I can send in to get a cross-compiled i586 output? -Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.commailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] _wapi_connect errors
Who is the appropriate contact for this one? Gonzalo? On Sep 11, 2013, at 5:19 PM, Bassam Tabbara bas...@symform.commailto:bas...@symform.com wrote: Hello, We're seeing these errors frequently as part of our application: _wapi_connect: error looking up socket handle 0x3fd _wapi_connect: error looking up socket handle 0x6db _wapi_connect: error looking up socket handle 0x25f _wapi_connect: error looking up socket handle 0x413 _wapi_connect: error looking up socket handle 0x314 _wapi_connect: error looking up socket handle 0x2d _wapi_connect: error looking up socket handle 0x395 _wapi_connect: error looking up socket handle 0x2b3 _wapi_connect: error looking up socket handle 0x1fb _wapi_connect: error looking up socket handle 0x2fd (error 10038) _wapi_connect: error looking up socket handle 0x2ab (error 10038) _wapi_connect: error looking up socket handle 0x27c _wapi_connect: error looking up socket handle 0x1de (error 10038) _wapi_connect: error looking up socket handle 0x2c4 (error 10038) _wapi_connect: error looking up socket handle 0x235 (error 10038) In code they are marked as warnings. These all look like race conditions where one thread closes a socket while another is trying to do some work on it. Should I be concerned about these? If not should these logs be silenced? Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.commailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] _wapi_connect errors
Hello, We're seeing these errors frequently as part of our application: _wapi_connect: error looking up socket handle 0x3fd _wapi_connect: error looking up socket handle 0x6db _wapi_connect: error looking up socket handle 0x25f _wapi_connect: error looking up socket handle 0x413 _wapi_connect: error looking up socket handle 0x314 _wapi_connect: error looking up socket handle 0x2d _wapi_connect: error looking up socket handle 0x395 _wapi_connect: error looking up socket handle 0x2b3 _wapi_connect: error looking up socket handle 0x1fb _wapi_connect: error looking up socket handle 0x2fd (error 10038) _wapi_connect: error looking up socket handle 0x2ab (error 10038) _wapi_connect: error looking up socket handle 0x27c _wapi_connect: error looking up socket handle 0x1de (error 10038) _wapi_connect: error looking up socket handle 0x2c4 (error 10038) _wapi_connect: error looking up socket handle 0x235 (error 10038) In code they are marked as warnings. These all look like race conditions where one thread closes a socket while another is trying to do some work on it. Should I be concerned about these? If not should these logs be silenced? Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SGEN support when cross compiling
Should it be a warning then? The runtime aborts after this error. The only workaround I've found so far is: https://github.com/symform/mono/commit/fe5c582a1a2d241f368c86081b3cb7ea53994f51 And sgen is running well now with a cross compiled mono. From: Rodrigo Kumpera kump...@gmail.commailto:kump...@gmail.com Date: Tuesday, August 27, 2013 8:58 AM To: Bassam Tabbara bas...@symform.commailto:bas...@symform.com Cc: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] SGEN support when cross compiling All this means is that the managed allocators won't be used. On Mon, Aug 26, 2013 at 8:07 PM, Bassam Tabbara bas...@symform.commailto:bas...@symform.com wrote: I tried that and I run into the following error when I run mono: sgen is not supported when using --with-tls=pthread Looking at the code here: https://github.com/mono/mono/blob/master/mono/metadata/sgen-gc.h#L990 Seems like pthread is only supported on darwin and windows. I'm cross compiling to linux with with-tls=pthread. From: Rodrigo Kumpera kump...@gmail.commailto:kump...@gmail.com Date: Monday, August 26, 2013 5:01 PM To: Bassam Tabbara bas...@symform.commailto:bas...@symform.com Cc: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] SGEN support when cross compiling Configure with --thread=pthread On Mon, Aug 26, 2013 at 7:36 PM, Bassam Tabbara bas...@symform.commailto:bas...@symform.com wrote: Thanks Rodrigo. Is there a trick then to bypass the __thread check during configuration? ./configure --host=armv5te-unknown-linux-gnueabi Fails with: configure: error: cannot run test program while cross compiling I worked around it with the following: https://github.com/symform/mono/commit/fe5c582a1a2d241f368c86081b3cb7ea53994f51 Do others not see this? From: Rodrigo Kumpera kump...@gmail.commailto:kump...@gmail.com Date: Monday, August 26, 2013 4:30 PM To: Bassam Tabbara bas...@symform.commailto:bas...@symform.com Cc: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] SGEN support when cross compiling sgen works fine on ARM and so does cross compiling to it. On Mon, Aug 26, 2013 at 6:19 PM, Bassam Tabbara bas...@symform.commailto:bas...@symform.com wrote: Hello, I'm working in mono master, and it looks like sgen is not support when cross compiling. Sgen requiren with-tls=__thread and during configuration a check is made if __thread is functioning and that fails with the following error when cross compiling: configure: error: cannot run test program while cross compiling [ I can work around this but disable the check during configuration, but I'm now wondering whether anyone is using sgen on ARM platforms? Are you cross compiling for those platforms? I must be missing something simple here. Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.commailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] SGEN support when cross compiling
Hello, I'm working in mono master, and it looks like sgen is not support when cross compiling. Sgen requiren with-tls=__thread and during configuration a check is made if __thread is functioning and that fails with the following error when cross compiling: configure: error: cannot run test program while cross compiling [ I can work around this but disable the check during configuration, but I'm now wondering whether anyone is using sgen on ARM platforms? Are you cross compiling for those platforms? I must be missing something simple here. Thanks! Bassam member:bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SGEN support when cross compiling
Thanks Rodrigo. Is there a trick then to bypass the __thread check during configuration? ./configure --host=armv5te-unknown-linux-gnueabi Fails with: configure: error: cannot run test program while cross compiling I worked around it with the following: https://github.com/symform/mono/commit/fe5c582a1a2d241f368c86081b3cb7ea53994f51 Do others not see this? From: Rodrigo Kumpera kump...@gmail.commailto:kump...@gmail.com Date: Monday, August 26, 2013 4:30 PM To: Bassam Tabbara bas...@symform.commailto:bas...@symform.com Cc: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] SGEN support when cross compiling sgen works fine on ARM and so does cross compiling to it. On Mon, Aug 26, 2013 at 6:19 PM, Bassam Tabbara bas...@symform.commailto:bas...@symform.com wrote: Hello, I'm working in mono master, and it looks like sgen is not support when cross compiling. Sgen requiren with-tls=__thread and during configuration a check is made if __thread is functioning and that fails with the following error when cross compiling: configure: error: cannot run test program while cross compiling [ I can work around this but disable the check during configuration, but I'm now wondering whether anyone is using sgen on ARM platforms? Are you cross compiling for those platforms? I must be missing something simple here. Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.commailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SGEN support when cross compiling
I tried that and I run into the following error when I run mono: sgen is not supported when using --with-tls=pthread Looking at the code here: https://github.com/mono/mono/blob/master/mono/metadata/sgen-gc.h#L990 Seems like pthread is only supported on darwin and windows. I'm cross compiling to linux with with-tls=pthread. From: Rodrigo Kumpera kump...@gmail.commailto:kump...@gmail.com Date: Monday, August 26, 2013 5:01 PM To: Bassam Tabbara bas...@symform.commailto:bas...@symform.com Cc: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] SGEN support when cross compiling Configure with --thread=pthread On Mon, Aug 26, 2013 at 7:36 PM, Bassam Tabbara bas...@symform.commailto:bas...@symform.com wrote: Thanks Rodrigo. Is there a trick then to bypass the __thread check during configuration? ./configure --host=armv5te-unknown-linux-gnueabi Fails with: configure: error: cannot run test program while cross compiling I worked around it with the following: https://github.com/symform/mono/commit/fe5c582a1a2d241f368c86081b3cb7ea53994f51 Do others not see this? From: Rodrigo Kumpera kump...@gmail.commailto:kump...@gmail.com Date: Monday, August 26, 2013 4:30 PM To: Bassam Tabbara bas...@symform.commailto:bas...@symform.com Cc: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] SGEN support when cross compiling sgen works fine on ARM and so does cross compiling to it. On Mon, Aug 26, 2013 at 6:19 PM, Bassam Tabbara bas...@symform.commailto:bas...@symform.com wrote: Hello, I'm working in mono master, and it looks like sgen is not support when cross compiling. Sgen requiren with-tls=__thread and during configuration a check is made if __thread is functioning and that fails with the following error when cross compiling: configure: error: cannot run test program while cross compiling [ I can work around this but disable the check during configuration, but I'm now wondering whether anyone is using sgen on ARM platforms? Are you cross compiling for those platforms? I must be missing something simple here. Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.commailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Assert in mini-arm.c
Here it is. Note that this run was compiled with BIND_ROOM set to 4 as you
recommended.
#2 0x00172c44 in arm_patch (code=0x407b05c8
\357\376\377\353\367\377\377\352\340A-\351\004\320M\342, target=0x5da1ebe0
\r\300\240\341\360_-\351(\320M\342$\311\377\353) at mini-arm.c:3530
(gdb) x/10i code
0x407b05c8: bl 0x407b018c
0x407b05cc: b 0x407b05b0
0x407b05d0: push{r5, r6, r7, r8, lr}
0x407b05d4: sub sp, sp, #4
0x407b05d8: mov r5, r0
0x407b05dc: mov r6, r1
0x407b05e0: mov r7, r2
0x407b05e4: orr r0, r5, r6
0x407b05e8: and r0, r0, #3
0x407b05ec: cmp r0, #0
(gdb) x/10i target
0x5da1ebe0: mov r12, sp
0x5da1ebe4: push{r4, r5, r6, r7, r8, r9, r10, r11, r12, lr}
0x5da1ebe8: sub sp, sp, #40 ; 0x28
0x5da1ebec: bl 0x5da11084
0x5da1ebf0: add r1, sp, #0
0x5da1ebf4: str r0, [r1, #4]
0x5da1ebf8: ldr r12, [r0]
0x5da1ebfc: str r12, [r1]
0x5da1ec00: str r1, [r0]
0x5da1ec04: str sp, [r1, #12]
Let me know if there is anything else I can provide.
From: Zoltan Varga var...@gmail.commailto:var...@gmail.com
Date: Tuesday, August 13, 2013 5:15 PM
To: Bassam Tabbara bas...@symform.commailto:bas...@symform.com
Cc: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com
mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Assert in mini-arm.c
I meant frame #2, i.e.
#2 0x00172ca8 in arm_patch
Zoltan
On Wed, Aug 14, 2013 at 2:14 AM, Zoltan Varga
var...@gmail.commailto:var...@gmail.com wrote:
Hi,
Can you see whats at 'code' and 'target' at frame #3, i.e.
x/10i code
x/10i target
Zoltan
On Wed, Aug 14, 2013 at 1:48 AM, Bassam Tabbara
bas...@symform.commailto:bas...@symform.com wrote:
Unfortunately that did not help. Still seeing the problem. I'm still working on
a test case but I'm not having much luck so far in getting an isolated repro.
I was able to get a debugger attached to the process right when handle_thunk
asserts, and there were 6 threads with the following call stack:
Thread 5 (Thread 0x558ff460 (LWP 9201)):
#0 handle_thunk (method=0x0, domain=0x4ce44e58, absolute=1, code=0x427f8f08
Q\364\377\353\367\377\377\352,
target=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353,
dyn_code_mp=0x0) at mini-arm.c:3373
#1 0x00172764 in arm_patch_general (method=0x0, domain=0x0, code=0x427f8f08
Q\364\377\353\367\377\377\352,
target=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353,
dyn_code_mp=0x0) at mini-arm.c:3425
#2 0x00172ca8 in arm_patch (code=0x427f8f08 Q\364\377\353\367\377\377\352,
target=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353) at
mini-arm.c:3536
#3 0x001830bc in mono_arch_patch_callsite (method_start=0x427f8e90
\r\300\240\341\360_-\351(\320M\342, code_ptr=0x427f8f0c \367\377\377\352,
addr=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353) at
tramp-arm.c:87
#4 0x0012c5c8 in common_call_trampoline (regs=0x558fd090, code=0x427f8f0c
\367\377\377\352, m=0x2a08a000, tramp=0x2e4bcd80 x\320\217U, vt=0x0,
vtable_slot=0x0,
need_rgctx_tramp=0) at mini-trampolines.c:673
#5 0x0012c67c in mono_magic_trampoline (regs=0x558fd090, code=0x427f8f0c
\367\377\377\352, arg=0x2a08a000, tramp=0x2e4bcd80 x\320\217U) at
mini-trampolines.c:690
#6 0x403f5060 in ?? ()
#7 0x403f5060 in ?? ()
All 6 threads where in a trampoline. The method in frame 4 was
mono_thread_interruption_checkpoint for all six threads.
Does this give you any more clues into what is going on?
This is blocking our upgrade to mono-3-0 unfortunately. Any help will be
greatly appreciated.
From: Zoltan Varga var...@gmail.commailto:var...@gmail.com
Date: Tuesday, August 13, 2013 3:20 AM
To: Bassam Tabbara bas...@symform.commailto:bas...@symform.com
Cc: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com
mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Assert in mini-arm.c
Hi,
This is a JIT problem, it will be hard to track down without a testcase. You
can try changing this line in mono/utils/mono-codeman.c:
#define BIND_ROOM 8
to
#define BIND_ROOM 4
It might fix the issue.
Zoltan
On Tue, Aug 13, 2013 at 7:44 AM, Bassam Tabbara
bas...@symform.commailto:bas...@symform.com wrote:
Folks,
Any insights into why the assert would trigger? Is this a resource exhaustion
issue, or is specific to certain code that is being JITed? I need someone to
point me in the right direction. I'm able to reproduce this but only in the
context of our application. This did not happen with the mono-2-10 branch.
Thanks!
Bassam
From: Bassam Tabbara bas...@symform.commailto:bas...@symform.com
Date: Friday, August 9, 2013 10:36 AM
To: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com
mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com
Subject: [Mono-dev
Re: [Mono-dev] Assert in mini-arm.c
I tried increasing MIN_PAGES in mono-codeman.c to 32 and still didn't help.
Is there another workaround that could help here?
From: Bassam Tabbara bas...@symform.commailto:bas...@symform.com
Date: Wednesday, August 14, 2013 12:26 AM
To: Zoltan Varga var...@gmail.commailto:var...@gmail.com
Cc: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com
mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Assert in mini-arm.c
Here it is. Note that this run was compiled with BIND_ROOM set to 4 as you
recommended.
#2 0x00172c44 in arm_patch (code=0x407b05c8
\357\376\377\353\367\377\377\352\340A-\351\004\320M\342, target=0x5da1ebe0
\r\300\240\341\360_-\351(\320M\342$\311\377\353) at mini-arm.c:3530
(gdb) x/10i code
0x407b05c8: bl 0x407b018c
0x407b05cc: b 0x407b05b0
0x407b05d0: push{r5, r6, r7, r8, lr}
0x407b05d4: sub sp, sp, #4
0x407b05d8: mov r5, r0
0x407b05dc: mov r6, r1
0x407b05e0: mov r7, r2
0x407b05e4: orr r0, r5, r6
0x407b05e8: and r0, r0, #3
0x407b05ec: cmp r0, #0
(gdb) x/10i target
0x5da1ebe0: mov r12, sp
0x5da1ebe4: push{r4, r5, r6, r7, r8, r9, r10, r11, r12, lr}
0x5da1ebe8: sub sp, sp, #40 ; 0x28
0x5da1ebec: bl 0x5da11084
0x5da1ebf0: add r1, sp, #0
0x5da1ebf4: str r0, [r1, #4]
0x5da1ebf8: ldr r12, [r0]
0x5da1ebfc: str r12, [r1]
0x5da1ec00: str r1, [r0]
0x5da1ec04: str sp, [r1, #12]
Let me know if there is anything else I can provide.
From: Zoltan Varga var...@gmail.commailto:var...@gmail.com
Date: Tuesday, August 13, 2013 5:15 PM
To: Bassam Tabbara bas...@symform.commailto:bas...@symform.com
Cc: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com
mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Assert in mini-arm.c
I meant frame #2, i.e.
#2 0x00172ca8 in arm_patch
Zoltan
On Wed, Aug 14, 2013 at 2:14 AM, Zoltan Varga
var...@gmail.commailto:var...@gmail.com wrote:
Hi,
Can you see whats at 'code' and 'target' at frame #3, i.e.
x/10i code
x/10i target
Zoltan
On Wed, Aug 14, 2013 at 1:48 AM, Bassam Tabbara
bas...@symform.commailto:bas...@symform.com wrote:
Unfortunately that did not help. Still seeing the problem. I'm still working on
a test case but I'm not having much luck so far in getting an isolated repro.
I was able to get a debugger attached to the process right when handle_thunk
asserts, and there were 6 threads with the following call stack:
Thread 5 (Thread 0x558ff460 (LWP 9201)):
#0 handle_thunk (method=0x0, domain=0x4ce44e58, absolute=1, code=0x427f8f08
Q\364\377\353\367\377\377\352,
target=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353,
dyn_code_mp=0x0) at mini-arm.c:3373
#1 0x00172764 in arm_patch_general (method=0x0, domain=0x0, code=0x427f8f08
Q\364\377\353\367\377\377\352,
target=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353,
dyn_code_mp=0x0) at mini-arm.c:3425
#2 0x00172ca8 in arm_patch (code=0x427f8f08 Q\364\377\353\367\377\377\352,
target=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353) at
mini-arm.c:3536
#3 0x001830bc in mono_arch_patch_callsite (method_start=0x427f8e90
\r\300\240\341\360_-\351(\320M\342, code_ptr=0x427f8f0c \367\377\377\352,
addr=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353) at
tramp-arm.c:87
#4 0x0012c5c8 in common_call_trampoline (regs=0x558fd090, code=0x427f8f0c
\367\377\377\352, m=0x2a08a000, tramp=0x2e4bcd80 x\320\217U, vt=0x0,
vtable_slot=0x0,
need_rgctx_tramp=0) at mini-trampolines.c:673
#5 0x0012c67c in mono_magic_trampoline (regs=0x558fd090, code=0x427f8f0c
\367\377\377\352, arg=0x2a08a000, tramp=0x2e4bcd80 x\320\217U) at
mini-trampolines.c:690
#6 0x403f5060 in ?? ()
#7 0x403f5060 in ?? ()
All 6 threads where in a trampoline. The method in frame 4 was
mono_thread_interruption_checkpoint for all six threads.
Does this give you any more clues into what is going on?
This is blocking our upgrade to mono-3-0 unfortunately. Any help will be
greatly appreciated.
From: Zoltan Varga var...@gmail.commailto:var...@gmail.com
Date: Tuesday, August 13, 2013 3:20 AM
To: Bassam Tabbara bas...@symform.commailto:bas...@symform.com
Cc: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com
mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Assert in mini-arm.c
Hi,
This is a JIT problem, it will be hard to track down without a testcase. You
can try changing this line in mono/utils/mono-codeman.c:
#define BIND_ROOM 8
to
#define BIND_ROOM 4
It might fix the issue.
Zoltan
On Tue, Aug 13, 2013 at 7:44 AM, Bassam Tabbara
bas...@symform.commailto:bas...@symform.com wrote:
Folks,
Any insights into why the assert would trigger? Is this a resource exhaustion
issue, or is specific
Re: [Mono-dev] Assert in mini-arm.c
Unfortunately that did not help. Still seeing the problem. I'm still working on a test case but I'm not having much luck so far in getting an isolated repro. I was able to get a debugger attached to the process right when handle_thunk asserts, and there were 6 threads with the following call stack: Thread 5 (Thread 0x558ff460 (LWP 9201)): #0 handle_thunk (method=0x0, domain=0x4ce44e58, absolute=1, code=0x427f8f08 Q\364\377\353\367\377\377\352, target=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353, dyn_code_mp=0x0) at mini-arm.c:3373 #1 0x00172764 in arm_patch_general (method=0x0, domain=0x0, code=0x427f8f08 Q\364\377\353\367\377\377\352, target=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353, dyn_code_mp=0x0) at mini-arm.c:3425 #2 0x00172ca8 in arm_patch (code=0x427f8f08 Q\364\377\353\367\377\377\352, target=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353) at mini-arm.c:3536 #3 0x001830bc in mono_arch_patch_callsite (method_start=0x427f8e90 \r\300\240\341\360_-\351(\320M\342, code_ptr=0x427f8f0c \367\377\377\352, addr=0x511f02a0 \r\300\240\341\360_-\351(\320M\342k\323\377\353) at tramp-arm.c:87 #4 0x0012c5c8 in common_call_trampoline (regs=0x558fd090, code=0x427f8f0c \367\377\377\352, m=0x2a08a000, tramp=0x2e4bcd80 x\320\217U, vt=0x0, vtable_slot=0x0, need_rgctx_tramp=0) at mini-trampolines.c:673 #5 0x0012c67c in mono_magic_trampoline (regs=0x558fd090, code=0x427f8f0c \367\377\377\352, arg=0x2a08a000, tramp=0x2e4bcd80 x\320\217U) at mini-trampolines.c:690 #6 0x403f5060 in ?? () #7 0x403f5060 in ?? () All 6 threads where in a trampoline. The method in frame 4 was mono_thread_interruption_checkpoint for all six threads. Does this give you any more clues into what is going on? This is blocking our upgrade to mono-3-0 unfortunately. Any help will be greatly appreciated. From: Zoltan Varga var...@gmail.commailto:var...@gmail.com Date: Tuesday, August 13, 2013 3:20 AM To: Bassam Tabbara bas...@symform.commailto:bas...@symform.com Cc: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Assert in mini-arm.c Hi, This is a JIT problem, it will be hard to track down without a testcase. You can try changing this line in mono/utils/mono-codeman.c: #define BIND_ROOM 8 to #define BIND_ROOM 4 It might fix the issue. Zoltan On Tue, Aug 13, 2013 at 7:44 AM, Bassam Tabbara bas...@symform.commailto:bas...@symform.com wrote: Folks, Any insights into why the assert would trigger? Is this a resource exhaustion issue, or is specific to certain code that is being JITed? I need someone to point me in the right direction. I'm able to reproduce this but only in the context of our application. This did not happen with the mono-2-10 branch. Thanks! Bassam From: Bassam Tabbara bas...@symform.commailto:bas...@symform.com Date: Friday, August 9, 2013 10:36 AM To: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com Subject: [Mono-dev] Assert in mini-arm.c Hello, I'm seeing the following assert on an armv5tel using latest from master: http://pastebin.com/raw.php?i=CLDXxiPy I'm trying to get an isolated repro but it proving to be elusive. In our full test runs we see this all the time. Any tips on how to debug this further? Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.commailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Assert in mini-arm.c
Folks, Any insights into why the assert would trigger? Is this a resource exhaustion issue, or is specific to certain code that is being JITed? I need someone to point me in the right direction. I'm able to reproduce this but only in the context of our application. This did not happen with the mono-2-10 branch. Thanks! Bassam From: Bassam Tabbara bas...@symform.commailto:bas...@symform.com Date: Friday, August 9, 2013 10:36 AM To: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com Subject: [Mono-dev] Assert in mini-arm.c Hello, I'm seeing the following assert on an armv5tel using latest from master: http://pastebin.com/raw.php?i=CLDXxiPy I'm trying to get an isolated repro but it proving to be elusive. In our full test runs we see this all the time. Any tips on how to debug this further? Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Assert in mini-arm.c
Hello, I'm seeing the following assert on an armv5tel using latest from master: http://pastebin.com/raw.php?i=CLDXxiPy I'm trying to get an isolated repro but it proving to be elusive. In our full test runs we see this all the time. Any tips on how to debug this further? Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Net.Http.Formatting and JSON.NET
Why does mono bundle JSON.NET into System.Net.Http.Formatting? This is quite different from how MSFT ships System.Net.Http.Formatting. Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Boehm GC reaching max_map_count
We are seeing the same issue. Mono is mapping a lot of memory: cat /proc/pid/maps | wc -l 21880 And it then reaches he max_map_count limit and dies: Program terminated with signal 6, Aborted. #0 0x7f69c02f51b5 in *__GI_raise (sig=value optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 in ../nptl/sysdeps/unix/sysv/linux/raise.c #0 0x7f69c02f51b5 in *__GI_raise (sig=value optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x7f69c02f7fc0 in *__GI_abort () at abort.c:92 #2 0x00493859 in mono_handle_native_sigsegv (signal=-1944970304, ctx=value optimized out) at mini-exceptions.c:2223 #3 signal handler called #4 0x7f69c02f51b5 in *__GI_raise (sig=value optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #5 0x7f69c02f7fc0 in *__GI_abort () at abort.c:92 #6 0x005f8171 in GC_abort (msg=0x6b4bb1 mmap(...PROT_NONE...) failed) at misc.c:1099 #7 0x005ea028 in GC_unmap (start=0x7f69956e6000 \350x\211\002, bytes=8192) at os_dep.c:2040 #8 0x005f9049 in GC_unmap_old () at allchblk.c:383 #9 0x005e73ce in GC_finish_collection () at alloc.c:776 #10 0x005e69ef in GC_try_to_collect_inner (stop_func=0x5e631c GC_never_stop_func) at alloc.c:393 #11 0x005e7ae8 in GC_collect_or_expand (needed_blocks=1, ignore_off_page=0) at alloc.c:1045 #12 0x005f6978 in GC_alloc_large (lw=260, k=0, flags=0) at malloc.c:60 #13 0x005f6d65 in GC_generic_malloc (lb=2080, k=0) at malloc.c:204 #14 0x005f6f4e in GC_malloc_atomic (lb=2080) at malloc.c:270 #15 0x005e81db in GC_local_malloc_atomic (bytes=2080) at pthread_support.c:380 mmap returns ENOMEM. We are going to increase the max_map_count limit, but http://www.novell.com/support/viewContent.do?externalId=7000830sliceId=1 warns against this (especially that it seems that 128 bytes are allocated in the kernel). For small mmaps like 4K or 8K that we see, this seems quite inefficient. Any help here appreciated. Thanks! Bassam -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of pablosantosl...@terra.es Sent: Tuesday, February 23, 2010 3:42 AM To: mono-devel-list@lists.ximian.com Cc: Dick Porter; Miguel de Icaza; Jesús Manuel González Subject: [Mono-dev] Boehm GC reaching max_map_count Hi there, We're experiencing problems with a server running on a 64bits box with plenty of RAM. After a few hours it crashed and the problem was that it was reaching the max_map_count limit. We raised it to two times the default (64k) but it also crashed. The problem is the following: normally the process has a number close to 100 or 200 mappings, but then, in less than a second, it grows beyond the limit and crashes. The process is not allocating memory (it stays stable although quite high) at this point, so we think it must be related to BoehmGC doing some collection or something. The process is heavily multithreaded. Mono is built with --with-large-heap and runs on a 64 bits box (where the pointer guessing issues with BoehmGC don't hit us so strongly as it happens on 32 bit systems). Well, anyone has any idea why this is happening? Thanks, pablo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Post-mortem debugging
Hello, I'm debugging a core file with gdb and I'm not able to find mono managed symbols: (gdb) where #0 0x7f93c9096ed5 in raise () from /lib/libc.so.6 #1 0x7f93c90983f3 in abort () from /lib/libc.so.6 #2 0x004933d0 in mono_handle_native_sigsegv (signal=-907561328, ctx=value optimized out) at mini-exceptions.c:2246 #3 0x004e6c9d in mono_arch_handle_altstack_exception (sigctx=0x7f93c9e7bc40, fault_addr=value optimized out, stack_ovf=0) at exceptions-amd64.c:957 #4 0x004176e4 in mono_sigsegv_signal_handler (_dummy=11, info=0x7f93c9e7bd70, context=0x7f93c9e7bc40) at mini.c:5882 #5 signal handler called #6 0x7f93c9d18cc0 in ?? () #7 0x413fb199 in ?? () #8 0x0025 in ?? () #9 0x7f93c9cb6a90 in ?? () #10 0x7f93c3cff150 in ?? () #11 0x in ?? () (gdb) p mono_pmip(0x7f93c9d18cc0) You can't do that without a process to debug. I looked at http://www.mono-project.com/Debugging and I can't tell if this is supposed to work on core dumps or not. How do you guys do it? What's your secret? Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Assertion at mini-arm.c:5559, condition `IS_LDR_PC (code_ptr [0])' not met
Hello, We are seeing the following on ARM devices. Running mono built from the 2-10 branch. Any ideas for where to start here? invalid code stream, instruction before IMT value is not a LDC in mono_arch_find_imt_method() (code 0x40be8868 value 0: 0xe1a06000 -1: 0xe591f028 -2: 0xe1a0e00f) * Assertion at mini-arm.c:5559, condition `IS_LDR_PC (code_ptr [0])' not met Stacktrace: at System.StringComparer.GetHashCode (object) 0x00067 at System.Collections.Hashtable.GetHash (object) 0x00033 at System.Collections.Hashtable.get_Item (object) 0x00057 at System.Collections.Specialized.NameObjectCollectionBase.FindFirstMatchedItem (string) 0x00033 at System.Collections.Specialized.NameObjectCollectionBase.BaseGet (string) 0x0001b at System.Configuration.PropertyInformationCollection.get_Item (string) 0x0001b at System.Configuration.ConfigurationElement.get_Item (string) 0x00033 at Foo.Bar.NodeSettings.get_ServerAddress () 0x0001f at Foo.Bar.Storage.ContributionHost.Start (System.Action) 0x000c7 at (wrapper remoting-invoke-with-check) Foo.Bar.Storage.ContributionHost.Start (System.Action) 0x at Symform.Storage.Node.Contribution.ContributionService.OnStart (string[]) 0x00113 at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object (object,intptr,intptr,intptr) 0x at System.Reflection.MonoMethod.Invoke (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) 0x00197 at System.Reflection.MethodBase.Invoke (object,object[]) 0x00047 at MonoServiceRunner.call (object,string,object[]) 0x00087 at MonoServiceRunner.MainLoop (System.ServiceProcess.ServiceBase[]) 0x005af at System.ServiceProcess.ServiceBase.Run (System.ServiceProcess.ServiceBase[]) 0x0004f at System.ServiceProcess.ServiceBase.Run (System.ServiceProcess.ServiceBase) 0x00047 at Symform.Storage.Node.Program.Main (string[]) 0x00383 at (wrapper runtime-invoke) Module.runtime_invoke_int_object (object,intptr,intptr,intptr) 0x at System.AppDomain.ExecuteAssemblyInternal (System.Reflection.Assembly,string[]) 0x0003b at System.AppDomain.ExecuteAssembly (string,System.Security.Policy.Evidence,string[]) 0x00033 at (wrapper remoting-invoke-with-check) System.AppDomain.ExecuteAssembly (string,System.Security.Policy.Evidence,string[]) 0x at MonoServiceRunner.StartService () 0x0040f at (wrapper runtime-invoke) Module.runtime_invoke_int__this__ (object,intptr,intptr,intptr) 0x at System.Runtime.Remoting.RemotingServices.InternalExecuteMessage (System.MarshalByRefObject,System.Runtime.Remoting.Messaging.IMethodCallMessage) 0x0022f at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage) 0x000e3 at System.Runtime.Remoting.Messaging.ServerObjectTerminatorSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage) 0x0008f at System.Runtime.Remoting.Lifetime.LeaseSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage) 0x0003b at System.Runtime.Remoting.ClientActivatedIdentity.SyncObjectProcessMessage (System.Runtime.Remoting.Messaging.IMessage) 0x00097 at System.Runtime.Remoting.Messaging.ServerContextTerminatorSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage) 0x001c3 at System.Runtime.Remoting.Contexts.CrossContextChannel.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage) 0x0010b at System.Runtime.Remoting.Channels.ChannelServices.SyncDispatchMessage (System.Runtime.Remoting.Messaging.IMessage) 0x0004f at System.AppDomain.ProcessMessageInDomain (byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage,byte[],System.Runtime.Remoting.Messaging.CADMethodReturnMessage) 0x00097 at (wrapper remoting-invoke-with-check) System.AppDomain.ProcessMessageInDomain (byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage,byte[],System.Runtime.Remoting.Messaging.CADMethodReturnMessage) 0x at System.Runtime.Remoting.Channels.CrossAppDomainSink.ProcessMessageInDomain (byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage) 0x0007b at (wrapper runtime-invoke) Module.runtime_invoke_CrossAppDomainSink/ProcessMessageRes_object_object (object,intptr,intptr,intptr) 0x at System.AppDomain.InvokeInDomainByID (int,System.Reflection.MethodInfo,object,object[]) 0x000a7 at System.Runtime.Remoting.Channels.CrossAppDomainSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage) 0x00127 at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke (System.Runtime.Remoting.Messaging.IMessage) 0x0040f at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (System.Runtime.Remoting.Proxies.RealProxy,System.Runtime.Remoting.Messaging.IMessage,System.Exception,object[]) 0x0042b at (wrapper runtime-invoke) Module.runtime_invoke_object_object_object_Exception_object[] (object,intptr,intptr,intptr) 0x at (wrapper
[Mono-dev] JIT'er bug?
Hello, We are seeing the following stack trace frequently on startup of our application. Seems to happen on both OSX and Linux. We build mono from the 2-10 branch. Any ideas? Stacktrace: at System.Collections.Generic.InternalStringComparer.GetHashCode (string) 0x0001d at System.Collections.Generic.Dictionary`2string, int.Add (string,int) 0x00029 at System.Security.Cryptography.Oid.GetName (string) 0x001a3 at System.Security.Cryptography.Oid..ctor (string) 0x0001f at System.Security.Cryptography.AsnEncodedData..ctor (string,byte[]) 0x00027 at System.Security.Cryptography.X509Certificates.X509ExtensionCollection..ctor (Mono.Security.X509.X509Certificate) 0x0018b at System.Security.Cryptography.X509Certificates.X509Certificate2.get_Extensions () 0x0003f at System.Security.Cryptography.X509Certificates.X509Certificate2Collection.Find (System.Security.Cryptography.X509Certificates.X509FindType,object,bool) 0x00b3f at System.Security.Cryptography.X509Certificates.X509Chain.FindParent (System.Security.Cryptography.X509Certificates.X509Certificate2) 0x0008b at System.Security.Cryptography.X509Certificates.X509Chain.BuildChainFrom (System.Security.Cryptography.X509Certificates.X509Certificate2) 0x00033 at System.Security.Cryptography.X509Certificates.X509Chain.Build (System.Security.Cryptography.X509Certificates.X509Certificate2) 0x00057 at System.Net.ServicePointManager/ChainValidationHelper.ValidateChain (Mono.Security.X509.X509CertificateCollection) 0x00267 at Mono.Security.Protocol.Tls.SslClientStream.OnRemoteCertificateValidation2 (Mono.Security.X509.X509CertificateCollection) 0x0001c at Mono.Security.Protocol.Tls.SslStreamBase.RaiseRemoteCertificateValidation2 (Mono.Security.X509.X509CertificateCollection) 0x00019 at Mono.Security.Protocol.Tls.SslClientStream.RaiseServerCertificateValidation2 (Mono.Security.X509.X509CertificateCollection) 0x00013 at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.validateCertificates (Mono.Security.X509.X509CertificateCollection) 0x000ac at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.ProcessAsTls1 () 0x000cf at Mono.Security.Protocol.Tls.Handshake.HandshakeMessage.Process () 0x0004d at (wrapper remoting-invoke-with-check) Mono.Security.Protocol.Tls.Handshake.HandshakeMessage.Process () 0x at Mono.Security.Protocol.Tls.ClientRecordProtocol.ProcessHandshakeMessage (Mono.Security.Protocol.Tls.TlsStream) 0x00087 at Mono.Security.Protocol.Tls.RecordProtocol.InternalReceiveRecordCallback (System.IAsyncResult) 0x00243 at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object (object,intptr,intptr,intptr) 0x Native stacktrace: 0 someapp 0x000d4ef6 mono_handle_native_sigsegv + 376 1 someapp 0xfc3c mono_sigsegv_signal_handler + 322 2 libsystem_c.dylib 0x9a0a059b _sigtramp + 43 3 ??? 0x 0x0 + 4294967295 4 libsystem_c.dylib 0x9a008f4b bsearch + 47 5 someapp 0x0014cd58 mono_class_interface_offset + 67 6 someapp 0x0014cdb2 mono_class_interface_offset_with_variance + 24 7 someapp 0x000d5d35 mono_convert_imt_slot_to_vtable_slot + 138 8 someapp 0x000d61a3 common_call_trampoline + 357 9 someapp 0x000d6e37 mono_vcall_trampoline + 388 10 ??? 0x00492c74 0x0 + 4795508 11 ??? 0x016f1dca 0x0 + 24059338 12 ??? 0x0262d7e4 0x0 + 40032228 13 ??? 0x0262d5f0 0x0 + 40031728 14 ??? 0x0262d598 0x0 + 40031640 15 ??? 0x0262d374 0x0 + 40031092 16 ??? 0x0262d1a8 0x0 + 40030632 17 ??? 0x0262c418 0x0 + 40027160 18 ??? 0x02628eb4 0x0 + 40013492 19 ??? 0x02628904 0x0 + 40012036 20 ??? 0x026281d0 0x0 + 40010192 21 ??? 0x026237f8 0x0 + 39991288 22 ??? 0x0262357d 0x0 + 39990653 23 ??? 0x0262355a 0x0 + 39990618 24 ??? 0x0262352c 0x0 + 39990572 25 ??? 0x02622e7d 0x0 + 39988861
Re: [Mono-dev] JIT'er bug?
Thanks Rodrigo. We will open a ticket with an isolated repro. From: Rodrigo Kumpera [mailto:kump...@gmail.com] Sent: Tuesday, December 20, 2011 5:10 PM To: Bassam Tabbara Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] JIT'er bug? It does look like a runtime error. Mind filing a bug report with a test case? On Tue, Dec 20, 2011 at 5:43 PM, Bassam Tabbara bas...@symform.commailto:bas...@symform.com wrote: Hello, We are seeing the following stack trace frequently on startup of our application. Seems to happen on both OSX and Linux. We build mono from the 2-10 branch. Any ideas? Stacktrace: at System.Collections.Generic.InternalStringComparer.GetHashCode (string) 0x0001d at System.Collections.Generic.Dictionary`2string, int.Add (string,int) 0x00029 at System.Security.Cryptography.Oid.GetName (string) 0x001a3 at System.Security.Cryptography.Oid..ctor (string) 0x0001f at System.Security.Cryptography.AsnEncodedData..ctor (string,byte[]) 0x00027 at System.Security.Cryptography.X509Certificates.X509ExtensionCollection..ctor (Mono.Security.X509.X509Certificate) 0x0018b at System.Security.Cryptography.X509Certificates.X509Certificate2.get_Extensions () 0x0003f at System.Security.Cryptography.X509Certificates.X509Certificate2Collection.Find (System.Security.Cryptography.X509Certificates.X509FindType,object,bool) 0x00b3f at System.Security.Cryptography.X509Certificates.X509Chain.FindParent (System.Security.Cryptography.X509Certificates.X509Certificate2) 0x0008b at System.Security.Cryptography.X509Certificates.X509Chain.BuildChainFrom (System.Security.Cryptography.X509Certificates.X509Certificate2) 0x00033 at System.Security.Cryptography.X509Certificates.X509Chain.Build (System.Security.Cryptography.X509Certificates.X509Certificate2) 0x00057 at System.Net.ServicePointManager/ChainValidationHelper.ValidateChain (Mono.Security.X509.X509CertificateCollection) 0x00267 at Mono.Security.Protocol.Tls.SslClientStream.OnRemoteCertificateValidation2 (Mono.Security.X509.X509CertificateCollection) 0x0001c at Mono.Security.Protocol.Tls.SslStreamBase.RaiseRemoteCertificateValidation2 (Mono.Security.X509.X509CertificateCollection) 0x00019 at Mono.Security.Protocol.Tls.SslClientStream.RaiseServerCertificateValidation2 (Mono.Security.X509.X509CertificateCollection) 0x00013 at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.validateCertificates (Mono.Security.X509.X509CertificateCollection) 0x000ac at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.ProcessAsTls1 () 0x000cf at Mono.Security.Protocol.Tls.Handshake.HandshakeMessage.Process () 0x0004d at (wrapper remoting-invoke-with-check) Mono.Security.Protocol.Tls.Handshake.HandshakeMessage.Process () 0x at Mono.Security.Protocol.Tls.ClientRecordProtocol.ProcessHandshakeMessage (Mono.Security.Protocol.Tls.TlsStream) 0x00087 at Mono.Security.Protocol.Tls.RecordProtocol.InternalReceiveRecordCallback (System.IAsyncResult) 0x00243 at (wrapper runtime-invoke) Module.runtime_invoke_void__this___object (object,intptr,intptr,intptr) 0x Native stacktrace: 0 someapp 0x000d4ef6 mono_handle_native_sigsegv + 376 1 someapp 0xfc3c mono_sigsegv_signal_handler + 322 2 libsystem_c.dylib 0x9a0a059b _sigtramp + 43 3 ??? 0x 0x0 + 4294967295 4 libsystem_c.dylib 0x9a008f4b bsearch + 47 5 someapp 0x0014cd58 mono_class_interface_offset + 67 6 someapp 0x0014cdb2 mono_class_interface_offset_with_variance + 24 7 someapp 0x000d5d35 mono_convert_imt_slot_to_vtable_slot + 138 8 someapp 0x000d61a3 common_call_trampoline + 357 9 someapp 0x000d6e37 mono_vcall_trampoline + 388 10 ??? 0x00492c74 0x0 + 4795508 11 ??? 0x016f1dca 0x0 + 24059338 12 ??? 0x0262d7e4 0x0 + 40032228 13 ??? 0x0262d5f0 0x0 + 40031728 14 ??? 0x0262d598 0x0 + 40031640 15 ??? 0x0262d374 0x0 + 40031092 16 ??? 0x0262d1a8 0x0 + 40030632 17 ??? 0x0262c418 0x0 + 40027160 18 ??? 0x02628eb4 0x0 + 40013492 19 ??? 0x02628904 0x0 + 40012036 20 ??? 0x026281d0 0x0 + 40010192
[Mono-dev] /dev/crypto and mono
Hello, Has anyone attempted to have mono use cryptodev modules in Linux (http://www.logix.cz/michal/devel/cryptodev/) instead of the managed implementations? What about on OSX? Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Exception on ASP.NET startup
Hello, We see the following exception every other day on our front end servers: System.ArgumentException: Key duplication when adding: sessionState at System.Collections.Hashtable.PutImpl (System.Object key, System.Object value, Boolean overwrite) [0x0] in filename unknown:0 at System.Collections.Hashtable.Add (System.Object key, System.Object value) [0x0] in filename unknown:0 at System.Collections.Specialized.NameObjectCollectionBase.BaseAdd (System.String name, System.Object value) [0x0] in filename unknown:0 at System.Collections.Specialized.NameObjectCollectionBase.BaseSet (System.String name, System.Object value) [0x0] in filename unknown:0 at System.Configuration.ConfigurationSectionCollection.get_Item (System.String name) [0x0] in filename unknown:0 at System.Configuration.Configuration.GetSection (System.String path) [0x0] in filename unknown:0 at System.Web.Configuration.WebConfigurationManager.GetSection (System.String sectionName, System.String path, System.Web.HttpContext context) [0x0] in filename unknown:0 at System.Web.Configuration.WebConfigurationManager.GetSection (System.String sectionName) [0x0] in filename unknown:0 at System.Web.SessionState.SessionStateModule.Init (System.Web.HttpApplication app) [0x0] in filename unknown:0 at System.Web.Configuration.HttpModulesSection.LoadModules (System.Web.HttpApplication app) [0x0] in filename unknown:0 at System.Web.HttpApplication.InitOnce (Boolean full_init) [0x0] in filename unknown:0 Seems like there is a race with ASP.NET startup on multi-core machines. We are running 2-10 bits. Anyone seen this before? Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Native stack trace in mono-2-10
Thanks Andres. We build out of the mono-2-10 branch directly (no tags). The part that is puzzling to me is why monoeg_g_hash_table_lookup calls mono_magic_trampoline (it doesn't). Also frame #12 looks very suspiciously close in value to the key parameter of monoeg_g_hash_table_lookup (they are 0x30 apart). #10 0x004977cd in mono_magic_trampoline (regs=0x600311, code=0x600311 __icall_wrapper_, arg=0x5f, tramp=0x8 Address 0x8 out of bounds) at mini-trampolines.c:590 #11 0x41d5116a in ?? () #12 0x7fe15cd65158 in ?? () #13 0x005e2d2b in monoeg_g_hash_table_lookup (hash=0x178c180, key=0x7fe15cd653e8) at ghashtable.c:280 #14 0x41ff0290 in ?? () #15 0x in ?? () Any pointers on how to proceed here would be appreciated. How do folks on the mono team debug stack corruption like this? Thanks! Bassam -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Andres G. Aragoneses Sent: Monday, September 12, 2011 9:57 AM To: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Native stack trace in mono-2-10 On 09/11/2011 09:42 AM, Bassam Tabbara wrote: Hello, We are seeing the following crash quite frequently on our test servers: #0 0x7fe188725165 in raise () from /lib/libc.so.6 #1 0x7fe188727f70 in abort () from /lib/libc.so.6 #2 0x00493298 in mono_handle_native_sigsegv (signal=2086645120, ctx=value optimized out) at mini-exceptions.c:2245 #3 0x004e6c8d in mono_arch_handle_altstack_exception (sigctx=0x7fe18390fac0, fault_addr=value optimized out, stack_ovf=0) at exceptions-amd64.c:956 #4 0x00417704 in mono_sigsegv_signal_handler (_dummy=11, info=0x7fe18390fbf0, context=0x7fe18390fac0) at mini.c:5881 #5 signal handler called #6 0x7fe1887fbc0b in ?? () from /lib/libc.so.6 #7 0x0041e751 in mono_jit_compile_method_with_opt (method=0x178c180, opt=51472895, ex=0x7fe15cd65040) at mini.c:5342 #8 0x0041eefe in mono_jit_compile_method (method=0x600311) at mini.c:5403 #9 0x00496eaf in common_call_trampoline (regs=0x7fe15cd652f0, code=0x41ff0290 \353, incomplete sequence \344, m=0x178c180, tramp=value optimized out, vt=0x0, vtable_slot=0x0, need_rgctx_tramp=0) at mini-trampolines.c:488 #10 0x004977cd in mono_magic_trampoline (regs=0x600311, code=0x600311 __icall_wrapper_, arg=0x5f, tramp=0x8 Address 0x8 out of bounds) at mini-trampolines.c:590 #11 0x41d5116a in ?? () #12 0x7fe15cd65158 in ?? () #13 0x005e2d2b in monoeg_g_hash_table_lookup (hash=0x178c180, key=0x7fe15cd653e8) at ghashtable.c:280 #14 0x41ff0290 in ?? () #15 0x in ?? () The servers is an x64 running Debian Linux 6. The back trace looks odd in that g_hash_table_lookup is calling a trampoline. Is this memory corruption? Any ideas on how to debug this? Have you read http://www.mono-project.com/Gdb ? Also, mono-2-10 is a branch, are you using the branch or particular tag/version? (I recall seeing a bug about trampolines and g_hash_tables being already fixed upstream a while ago.) Andres -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Native stack trace in mono-2-10
Hello, We are seeing the following crash quite frequently on our test servers: #0 0x7fe188725165 in raise () from /lib/libc.so.6 #1 0x7fe188727f70 in abort () from /lib/libc.so.6 #2 0x00493298 in mono_handle_native_sigsegv (signal=2086645120, ctx=value optimized out) at mini-exceptions.c:2245 #3 0x004e6c8d in mono_arch_handle_altstack_exception (sigctx=0x7fe18390fac0, fault_addr=value optimized out, stack_ovf=0) at exceptions-amd64.c:956 #4 0x00417704 in mono_sigsegv_signal_handler (_dummy=11, info=0x7fe18390fbf0, context=0x7fe18390fac0) at mini.c:5881 #5 signal handler called #6 0x7fe1887fbc0b in ?? () from /lib/libc.so.6 #7 0x0041e751 in mono_jit_compile_method_with_opt (method=0x178c180, opt=51472895, ex=0x7fe15cd65040) at mini.c:5342 #8 0x0041eefe in mono_jit_compile_method (method=0x600311) at mini.c:5403 #9 0x00496eaf in common_call_trampoline (regs=0x7fe15cd652f0, code=0x41ff0290 \353, incomplete sequence \344, m=0x178c180, tramp=value optimized out, vt=0x0, vtable_slot=0x0, need_rgctx_tramp=0) at mini-trampolines.c:488 #10 0x004977cd in mono_magic_trampoline (regs=0x600311, code=0x600311 __icall_wrapper_, arg=0x5f, tramp=0x8 Address 0x8 out of bounds) at mini-trampolines.c:590 #11 0x41d5116a in ?? () #12 0x7fe15cd65158 in ?? () #13 0x005e2d2b in monoeg_g_hash_table_lookup (hash=0x178c180, key=0x7fe15cd653e8) at ghashtable.c:280 #14 0x41ff0290 in ?? () #15 0x in ?? () The servers is an x64 running Debian Linux 6. The back trace looks odd in that g_hash_table_lookup is calling a trampoline. Is this memory corruption? Any ideas on how to debug this? Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Help with heap profilers
Any help with this would be appreciated? What tools are folks using to find leaks / fragmentation issues on mono? From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Bassam Tabbara Sent: Thursday, October 21, 2010 11:20 PM To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] Help with heap profilers I suspect I'm seeing a low grade leak with ASP.NET, and I'm having a hard time getting any of the heap profilers to run correctly. Which is the recommended heap profiler? I assume it's the logging profiler. I run it with the following options: --profile=logging:gc,as,output=/mnt/profile/frontend.$$.mprofile And it seems to hang my process frequently both while running and during shutdown. Also even when it does not hang, I'm unable to get mprof-decoder to parse its output, I see the following exception quite frequently: Unhandled Exception: System.OverflowException: Number overflow. at Mono.Profiler.BlockData.DecodeHeaderBlockCounterDelta (System.Byte[] header) [0x0] in filename unknown:0 at Mono.Profiler.SyncLogFileReader.ReadBlock () [0x0] in filename unknown:0 at Mono.Profiler.ConsoleDecoder.Main (System.String[] argv) [0x0] in filename unknown:0 Any help would be appreciated. I'm using mono built from mono-2-6 branch. Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Help with heap profilers
I suspect I'm seeing a low grade leak with ASP.NET, and I'm having a hard time getting any of the heap profilers to run correctly. Which is the recommended heap profiler? I assume it's the logging profiler. I run it with the following options: --profile=logging:gc,as,output=/mnt/profile/frontend.$$.mprofile And it seems to hang my process frequently both while running and during shutdown. Also even when it does not hang, I'm unable to get mprof-decoder to parse its output, I see the following exception quite frequently: Unhandled Exception: System.OverflowException: Number overflow. at Mono.Profiler.BlockData.DecodeHeaderBlockCounterDelta (System.Byte[] header) [0x0] in filename unknown:0 at Mono.Profiler.SyncLogFileReader.ReadBlock () [0x0] in filename unknown:0 at Mono.Profiler.ConsoleDecoder.Main (System.String[] argv) [0x0] in filename unknown:0 Any help would be appreciated. I'm using mono built from mono-2-6 branch. Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] Make mono on OSX relocatable
Attached is a patched that makes mono on OSX relocatable as with Linux, Windows and Solaris. It would be great if this can be committed to the mono-2-6 branch. Thanks! Bassam macos_relocate.patch Description: macos_relocate.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [Patch] Fix bug where HttpWebRequest.BeginResponse never completes
We are seeing a case where HttpWebRequest.BeginResponse never completes even through there is a response outstanding on the connection. We see this with mono 2.6.7. I've traces this down to the HttpWebRequest.SetResponseData method. Attached is a patch that fixes the problem. Thanks! Bassam HttpWebRequest.patch Description: HttpWebRequest.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Scripts to create the Mac OS X dmg packages
I'm looking for the scripts to generate the Mac OS X dmg packages that are on: http://www.go-mono.com/mono-downloads/download.html Are those available anywhere? Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] MVC 2 support
Hello, Which version of mono support MVC 2 ? Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Support for System.Net.ServicePoint.SetTcpKeepAlive
.NET FX 3.5 SP1 (and .NET 2.0 SP2) seems to have added a useful function to the System.Net.ServicePoint class - SetTcpKeepAlive. Which version of Mono would this be aligned to? Are there any plans to add similar support? Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Bug in System.Core LookupTKey,TElement
I'm running Mono 2.0-1 on Linux. The implementation of Lookup extension method
on IEnumerable does not seem to handle a case insensitive comparer correctly.
The code does the following:
public static LookupTKey, TElement ToLookupTSource, TKey, TElement (this
IEnumerableTSource source,
FuncTSource, TKey keySelector, FuncTSource, TElement
elementSelector, IEqualityComparerTKey comparer)
{
if (source == null || keySelector == null ||
elementSelector == null)
throw new ArgumentNullException ();
DictionaryTKey, ListTElement dictionary = new
DictionaryTKey, ListTElement (comparer ?? EqualityComparerTKey.Default);
foreach (TSource element in source) {
TKey key = keySelector (element);
if (key == null)
throw new ArgumentNullException ();
if (!dictionary.ContainsKey (key))
dictionary.Add (key, new ListTElement
());
dictionary [key].Add (elementSelector (element));
}
return new LookupTKey, TElement (dictionary);
}
The last line of the this method does not pass the comparer to the
LookupTKey,TElement class and hence all comparisons are done with the wrong
comparer.
Please let me know if you'd like me to test a patch.
Thanks!
Bassam
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Asynchronous sockets
From what I can see, Mono does not seem to use asynchronous sockets (even when using System.Net.Socket.Begin/End) on a Windows platform. Is this correct? Any plans to add this support? Thanks! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] eglib and cygwin
Hello, I'm unable to compile eglib in a cygwin/mingw environment. I've tried the following: cd eglib ./autogen.sh cp winconfig.h config.h [modified Makefile and src/Makefile to use -mno-cygwin -g options to gcc] make I get the following errors: make[2]: Entering directory `/usr/local/src/mono/mono/eglib/src' /bin/sh ../libtool --tag=CC --mode=compile gcc -mno-cygwin -g -DHAVE_CONFIG_H -I. -I.. -I. -I/usr/local/src/mono/deps/include -Wall -D_FORTIFY_SOURCE=2 -g O0 -D_GNU_SOURCE -MT libeglib_la-gfile.lo -MD -MP -MF .deps/libeglib_la-gfile.T o -c -o libeglib_la-gfile.lo `test -f 'gfile.c' || echo './'`gfile.c gcc -mno-cygwin -g -DHAVE_CONFIG_H -I. -I.. -I. -I/usr/local/src/mono/deps/inc ude -Wall -D_FORTIFY_SOURCE=2 -g -O0 -D_GNU_SOURCE -MT libeglib_la-gfile.lo -MD -MP -MF .deps/libeglib_la-gfile.Tpo -c gfile.c -DDLL_EXPORT -DPIC -o .libs/lib glib_la-gfile.o gfile.c:40:1: warning: S_ISREG redefined In file included from gfile.c:34: /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/include/sys/s tat h:72:1: warning: this is the location of the previous definition gfile.c:41:1: warning: S_ISDIR redefined /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/include/sys/s tat h:68:1: warning: this is the location of the previous definition Is there a recommended way to buld eglib in a cygwin/mingw environment? Thanks in advance! Bassam ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
