[Mono-dev] Memory leaks and segfaults

[Thorsten Schuett]

Hi,

I sent a mail to this list in September regarding a memory leak on IA64. Back 
then the problem wasn't solved, but the machine had enough memory to survive. 
This week the problem became worse. mono segfaults!

VS 2005 Beta:
The simulation runs fine and the memory consumption reported by the task 
managers oscillates between 30 and 450MB.

IA64 mono 1.1.9.2:
The consumed memory goes up to 2.2GB and then mono segfaults. The core dump 
isn't really helpfull:
(gdb) bt
#0  0x0000000000000000 in ?? ()

IA32 mono 1.1.9.2:
The consumed memory goes up to ~1GB and then mono segfaults. The core dump 
contained more information this time: The backtrace had 150k lines. Therefore 
I post only a small subset ;-)

#0  0x080e1cf1 in TlsGetValue (idx=1) at threads.c:813
#1  0x080c0b59 in mono_domain_get () at domain.c:835
#2  0x081259b1 in mono_handle_exception (ctx=0xbf800110, obj=0x8239fc0,
    original_ip=0x8089131, test_only=0) at mini-exceptions.c:552
#3  0x0806f0b5 in throw_exception (eax=136287784, ecx=1074812116,
    edx=136191176, ebx=136552384, esi=68, edi=80, ebp=3212837284,
    exc=0x8239fc0, eip=134779185, esp=3212837256, rethrow=134779185)
    at exceptions-x86.c:273
#4  0x40016555 in ?? ()
#5  0x0809b17c in mono_gc_out_of_memory (size=68) at gc.c:115
#6  0x080ede10 in GC_generic_malloc (lb=68, k=0) at malloc.c:227
#7  0x080ede84 in GC_malloc_atomic (lb=68) at malloc.c:262
#8  0x080888f5 in mono_string_new_size (domain=0x81d5f00, len=27)
    at object.c:2189
#9  0x08088860 in mono_string_new_utf16 (domain=0x81d5f00, text=0x40c63818,
    len=27) at object.c:2662
#10 0x080889dd in mono_string_new (domain=0x81d5f00,
    text=0x40c637f0 "System.OutOfMemoryException") at object.c:2748
#11 0x08090202 in ves_icall_System_MonoType_getFullName (object=0x81def30,
    full_name=1, assembly_qualified=0) at icall.c:4110
[snip]
#144410 0x40a6c583 in ?? ()
#144411 0x40a6acc3 in ?? ()
#144412 0x40a6abd3 in ?? ()
#144413 0x08116c7c in mono_jit_runtime_invoke (method=0x824d2a8, obj=0x0,
    params=0xbfffdb88, exc=0x0) at mini.c:9649
#144414 0x08087170 in mono_runtime_invoke (method=0x824d2a8, obj=0x0,
    params=0xbfffdb88, exc=<incomplete type>) at object.c:1311
#144415 0x08087d87 in mono_runtime_exec_main (method=0x824d2a8,
    args=<incomplete type>, exc=<incomplete type>) at object.c:2011
#144416 0x08087a96 in mono_runtime_run_main (method=0x824d2a8, argc=0,
    argv=0xbfffdcfc, exc=<incomplete type>) at object.c:1869
#144417 0x0805c0e5 in main_thread_handler (user_data=0xbfffdc70)
    at driver.c:529
#144418 0x0805cbd3 in mono_main (argc=1, argv=0xbfffdcf4) at driver.c:936
#144419 0x42015704 in __libc_start_main () from /lib/tls/libc.so.6

Paolo told me last time to use GC_PRINT_STATS=1 to get more information on the 
garbage collector. The ia32 complains about not having enough memory right 
before dying:
[snip]
Failed to expand heap by 65536 bytes
Failed to expand heap by 8388608 bytes
Failed to expand heap by 65536 bytes
Failed to expand heap by 8388608 bytes
Failed to expand heap by 65536 bytes
Failed to expand heap by 8388608 bytes
Failed to expand heap by 65536 bytes
Failed to expand heap by 8388608 bytes
Failed to expand heap by 65536 bytes
Failed to expand heap by 8388608 bytes
Failed to expand heap by 65536 bytes

Last GC run of the IA32:
Increasing heap size by 8388608 after 197974536 allocated bytes
Increasing heap size by 8388608 after 203201984 allocated bytes
Initiating full world-stop collection 54 after 208438112 allocd bytes
--> Marking for collection 54 after 208438112 allocd bytes + 71334048 wasted 
bytes
Collection 53 finished ---> heapsize = 834928640 bytes
World-stopped marking took 50 msecs
Complete collection took 90 msecs

The last GC run on the IA64 provided the following information:
Initiating full world-stop collection 74 after 654382464 allocd bytes
--> Marking for collection 74 after 654382464 allocd bytes + 97226080 wasted 
bytes
Collection 73 finished ---> heapsize = 2256044032 bytes
World-stopped marking took 82 msecs
Complete collection took 196 msecs

The ia32 and the ia64 die at different points! I could "cope" with the memory 
leak on the ia64, but the segfault is a serious problem for me. Any ideas? If 
you need more information feel free to ask.

Thanks in advance,
	Thorsten