Hello again, Here is the output from the gdb macro:
(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 <[EMAIL PROTECTED]> 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@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > _______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list