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 <[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
_______________________________________________
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
