Bug 5004 - deadlock in loader.c
Summary: deadlock in loader.c
Alias: None
Product: Runtime
Classification: Mono
Component: Reflection ()
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2012-05-10 11:40 UTC by David Schmitt
Modified: 2012-11-30 15:16 UTC (History)
4 users (show)

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

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description David Schmitt 2012-05-10 11:40:00 UTC
* Debian squeeze
 * Mono JIT compiler version ((no/ca4d43f Thu May 10 01:28:40 CEST 2012) (self-compiled)
 * /var/lib/jenkins/mono/mono-2-10/bin/mono-sgen --gc=sgen /var/lib/jenkins/mono/mono-2-10/lib/mono/4.0/xsp4.exe --port 7007 --nonstop --verbose --applications [...]

When the application loads the first time it puts high load on JIT, reflection and assembly loader, triggering this deadlock in loader.c. No requests actually pull through.

Thread 3 (Thread 0x7fca3c653700 (LWP 5074)):
#0  0x00007fca41cb7c74 in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x00007fca41cb3194 in _L_lock_1024 () from /lib/libpthread.so.0
#2  0x00007fca41cb2ff7 in pthread_mutex_lock () from /lib/libpthread.so.0
#3  0x000000000051fbae in mono_loader_lock () at loader.c:2124
#4  0x00000000005a6729 in mono_class_setup_fields_locking (class=0x900e68) at class.c:1529
#5  0x00000000005a6d00 in mono_class_get_field_from_name_full (klass=0x900e68, name=0x80 <Address 0x80 out of bounds>, type=0x0) at class.c:6377
#6  0x000000000057e40e in ves_icall_System_Net_Sockets_Socket_SetSocketOption_internal (sock=7, level=65535, name=<value optimized out>, obj_val=0x7fca417d3240, byte_val=0x0, int_val=0, error=0x7fca3c65280c) at socket-io.c:2107
#7  0x0000000040bc6a0a in ?? ()
#8  0x00007fca3c65280c in ?? ()
#9  0x000000000000ffff in ?? ()
#10 0x0000000000000007 in ?? ()
#11 0x0000000001ce8600 in ?? ()
#12 0x000000000176d660 in ?? ()
#13 0x0000000000592f8a in new_slot (hash=0x7fca3c6527b0, key=0x80, value=0x7fca417d3240, replace=0) at mono-hash.c:87
#14 mono_g_hash_table_insert_replace (hash=0x7fca3c6527b0, key=0x80, value=0x7fca417d3240, replace=0) at mono-hash.c:451
#15 0x0000000040bcf97c in ?? ()
#16 0x00007fca3c65280c in ?? ()
#17 0x0000000000000007 in ?? ()
#18 0x00007fca3c65280c in ?? ()
#19 0x00000000005d0e03 in ioctlsocket (fd=1013262144, command=<value optimized out>, arg=0x7fca417d21a8) at sockets.c:1392
#20 0x0000000000580158 in ves_icall_System_Net_Sockets_Socket_Blocking_internal (sock=9440872, block=0, error=0x7fca417d3240) at socket-io.c:860
#21 0x00007fca417d21a8 in ?? ()
#22 0x00007fca41483098 in ?? ()

Thread 6 (Thread 0x7fca3ebbd700 (LWP 5064)):
#0  0x00007fca41cb7c74 in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x00007fca41cb3194 in _L_lock_1024 () from /lib/libpthread.so.0
#2  0x00007fca41cb2ff7 in pthread_mutex_lock () from /lib/libpthread.so.0
#3  0x000000000051fbae in mono_loader_lock () at loader.c:2124
#4  0x000000000056e483 in mono_find_jit_icall_by_addr (addr=0x460fa0) at icall.c:8178
#5  0x0000000000427cd1 in mono_emit_jit_icall (cfg=0x2171330, func=0x80, args=0x7fca3ebb9b40) at method-to-ir.c:2543
#6  0x0000000000450a91 in mono_method_to_ir (cfg=0x2171330, method=<value optimized out>, start_bblock=<value optimized out>, end_bblock=<value optimized out>, return_var=<value optimized out>, dont_inline=<value optimized out>,
    inline_args=0x0, inline_offset=0, is_virtual_call=0) at method-to-ir.c:8016
#7  0x000000000041c6b7 in mini_method_compile (method=<value optimized out>, opts=<value optimized out>, domain=<value optimized out>, run_cctors=<value optimized out>, compile_aot=<value optimized out>, parts=<value optimized out>)
    at mini.c:4498
#8  0x000000000041def9 in mono_jit_compile_method_inner (method="CustomInfo:GetActiveSection ()", opt=51472895, ex=0x7fca3ebb9e48) at mini.c:5204
#9  mono_jit_compile_method_with_opt (method="CustomInfo:GetActiveSection ()", opt=51472895, ex=0x7fca3ebb9e48) at mini.c:5435
#10 0x000000000041e78d in mono_jit_compile_method (method=Traceback (most recent call last):
  File "/var/lib/jenkins/mono/mono-2-10/bin/mono-sgen-gdb.py", line 153, in to_string
    class_name = stringify_class_name (klass ["name_space"].string (), klass ["name"].string ())
RuntimeError: Cannot access memory at address 0x100001412
) at mini.c:5460
#11 0x000000000049595b in common_call_trampoline (regs=<value optimized out>, code=0x41e79558 "HcE̅\300\017\205\065", m="CustomInfo:GetActiveSection ()", tramp=<value optimized out>, vt=0x0, vtable_slot=0x0, need_rgctx_tramp=0)
    at mini-trampolines.c:494
#12 0x00000000004963ad in mono_magic_trampoline (regs=0x900e68, code=0x80 <Address 0x80 out of bounds>, arg=0x7fca3ebb9b40, tramp=0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>) at mini-trampolines.c:596
#13 0x0000000041ff8186 in ?? ()
#14 0x0000000000000000 in ?? ()
Comment 1 Zoltan Varga 2012-05-10 18:34:45 UTC
There is no deadlock here, both threads are waiting for the same lock. Can you paste the stacktrace for all the other threads ?
Comment 2 Miguel de Icaza [MSFT] 2012-05-19 00:51:44 UTC
Flagging as needinfo, reopen when the extra data is in
Comment 3 Rodrigo Kumpera 2012-11-30 15:16:56 UTC
No response in 6 months. Closing.