https://bugzilla.novell.com/show_bug.cgi?id=351991 Summary: Huge thread usage Product: openSUSE 10.3 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Critical Priority: P5 - None Component: Evolution AssignedTo: bnc-team-evolution@forge.provo.novell.com ReportedBy: lakhil@novell.com QAContact: lakhil@novell.com Found By: --- Upstream bug http://bugzilla.gnome.org/show_bug.cgi?id=503574 For me, often e-d-s appears to grow wrt. memory use over time, though very intermittently, until it turns into some vast giant of a process :-) Recently I had the beasty deadlock on me, and I was surprised to see: "Thread 195" in the gdb trace (attached). Is it possible that our memory usage problems, could be caused by a runaway / unrestrained thread-pool problem ? Almost all of the threads were at: Thread 190 (Thread 0xad3ffb90 (LWP 14900)): #0 0xffffe410 in __kernel_vsyscall () #1 0xb729d13e in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #2 0xb7298c0d in _L_mutex_lock_81 () from /lib/libpthread.so.0 #3 0xb7298553 in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0xb6e65622 in get_deltas (handle=0x87e9fc8) at e-cal-backend-groupwise.c:348 #5 0xb733f91f in g_thread_create_proxy (data=0xa6d2d00) at gthread.c:635 #6 0xb72970a5 in start_thread () from /lib/libpthread.so.0 #7 0xb721edfe in clone () from /lib/libc.so.6 Thread 189 (Thread 0xaaff7b90 (LWP 14927)): #0 0xffffe410 in __kernel_vsyscall () #1 0xb729d13e in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #2 0xb7298c0d in _L_mutex_lock_81 () from /lib/libpthread.so.0 #3 0xb7298553 in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0xb6e65622 in get_deltas (handle=0x806c338) at e-cal-backend-groupwise.c:348 #5 0xb733f91f in g_thread_create_proxy (data=0xae9a2a8) at gthread.c:635 #6 0xb72970a5 in start_thread () from /lib/libpthread.so.0 #7 0xb721edfe in clone () from /lib/libc.so.6 which looks odd: reading the code - there is apparently a *lot* of spawning of this thread going on - sometimes it's spawned after a 60second timeout too (why?). The logic here is unclear to me, but it seems that if get_deltas doesn't return inside a minute (the default) then we go on endlessly spawning these threads :-) - which is not cool: all of them blocking on the static 'connecting' mutex: ie. what we see. It seems clear that we shouldn't be launching duplicate threads to do the same work on a timeout here. The quick fix is to have a [ mutex protected ] list of threads already doing work here, and not dispatch duplicate threads. Of course - it's possible we also want some cancellation for very-long-running (failed) get_deltas threads too - not sure. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.