[Mono-dev] Memory leaks and segfaults

[Zoltan Varga]

                              Hi,

  It seems out-of-memory handling on ia64 seems to be broken. I will
try to fix it.

            Zoltan

On 10/12/05, Thorsten Schuett <schuett at zib.de> wrote:
> 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
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>