[Mono-list] Re: Garbage collection and memory usage

[Robert Jordan]

Georgi Moskov wrote:
> Hello again,
> 
>    Here is the output from the gdb macro:

This is still wrong. Try this:


set logging on
info threads
t a a mono_backtrace 100
quit

Then post the gdb.txt file, ideally compressed.

Robert

> 
> (gdb) mono_backtrace 15
> [Switching to Thread -1212431040 (LWP 2809)]
> #0  0xb7c966c6 in semop () from /lib/tls/libc.so.6
> #1  0xb7ef5bb7 in _wapi_shm_sem_lock () from /usr/lib/libmono.so.0
> #2  0xb7eeb567 in _wapi_handle_count_signalled_handles () from
> /usr/lib/libmono.so.0
> #3  0xb7ef9ca6 in SignalObjectAndWait () from /usr/lib/libmono.so.0
> #4  0xb7ef9ed2 in WaitForMultipleObjectsEx () from /usr/lib/libmono.so.0
> #5  0xb7eacb3b in mono_install_thread_callbacks () from /usr/lib/libmono.so.0
> #6  0xb7eace8a in mono_thread_manage () from /usr/lib/libmono.so.0
> #7  0xb7e320da in mono_main () from /usr/lib/libmono.so.0
> #8  0x0804857b in ?? ()
> #9  0x00000005 in ?? ()
> #10 0xbfeab0d4 in ?? ()
> #11 0xbfeab0a8 in ?? ()
> #12 0xb7bd2974 in __libc_start_main () from /lib/tls/libc.so.6
> #13 0xb7bd2974 in __libc_start_main () from /lib/tls/libc.so.6
> warning: Unable to restore previously selected frame.
> 
> #0  0xb7c966c6 in semop () from /lib/tls/libc.so.6
> (gdb)
> 
>    This time I limited the phisical memory of the machine from 192Mb
> to 96Mb, so the problem can show faster.
> 
> top:
> 
> top - 20:47:45 up 5 min,  1 user,  load average: 0.29, 0.46, 0.23
> Tasks:  65 total,   1 running,  64 sleeping,   0 stopped,   0 zombie
> Cpu(s):  1.0% us,  2.0% sy,  0.0% ni, 96.7% id,  0.0% wa,  0.3% hi,  0.0% si
> Mem:     93508k total,    91008k used,     2500k free,     1076k buffers
> Swap:    72252k total,    50408k used,    21844k free,    12932k cached
> 
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>  2809 www-data  15   0 86424  56m 6960 S  1.7 62.3   0:37.23 mono
> 
>    Since I am pretty sure that the problem has something to do with
> JIT compilation and memory, and the gdb trace from the macro doesn't
> look much different from the previous one, I surpose we could put up
> something similar to our application to reproduce the problem.
> 
> Regards,
> Georgi Moskov
> 
> On 4/7/06, Miguel de Icaza <miguel at ximian.com> wrote:
>> Hello,
>>
>>     Good news and bad news.   The good news is that it seems that the
>> bug is easy to trigger, which means we can do something about it.
>>
>>     The bad news is that the gdb stack trace you provided is only for
>> one thread, which is not the problematic one.
>>
>>     Please try the two gdb macros that we have in our site to get all
>> the information:
>>
>>         http://www.mono-project.com/Debugging
>>
>>      Alternatively, if you could share your application with us, and the
>> steps to reproduce it, we could do the work ourselves.
>>
>>      If your software is proprietary, we can sign an NDA to have someone
>> at Novell look at it.
>>
>> Miguel
>> _______________________________________________
>> Mono-list maillist  -  Mono-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-list
>>
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>