Created attachment 557153 [details] First set of stack traces Description of problem: For a little while now, starting I guess in the thunderbird 7 or 8 time frame, it seems that thunderbird leaks threads so that after a while it has hundreds of threads and other things start being unable to fork because the user's process limit has been reached. The leak can be observed even over a relatively short timespan of a few hours if you look closely and monitor the number of threads thunderbird has. Version-Release number of selected component (if applicable): thunderbird-9.0-4.fc16.x86_64 How reproducible: Every time. Steps to Reproduce: 1. Start thunderbird 2. Wait a week or so 3. Observe things starting to fail as they are unable to fork Actual results: Thunderbird will have hundreds of threads. Expected results: Thunderbird has a reasonable number of threads. Additional info: I'm attaching two "thread apply all bt full" traces taken from the same thunderbird instance some 16 hours apart. In the first it has 35 threads and in the second it has 68 threads.
Created attachment 557159 [details] Second set of stack traces
To be honest I've never run thunderbird longer than one day and we're not going ti fix it in some short time period. Btw, can you try the same with Firefox?
No I've never seen firefox do this, though I rarely run that for more than a week without having to restart due to it's memory foot print getting too large. Thunderbird on the other hand I would routinely run for weeks at a time, though it now usually runs out of threads after a couple of weeks. Right now thunderbird on this machine has been running for a week and has 378 threads while firefox has been running for three days and has 29 threads. On my machine at home thunderbird has been up for three days (because it ran out of threads and I had to kill it!) and it has 162 threads while firefox only has 29 threads (not sure when it was started).
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Still happens in F18 with thunderbird-17.0.2-1.fc18.x86_64
I've raised this upstream as https://bugzilla.mozilla.org/show_bug.cgi?id=833720
After further investigation I have discovered that disabling the lightning extension stops the thread leak, so it seems that lightning is actually responsible and I am going to transfer this bug to the thunderbird-lightning component. I have also done some comparisons of the collected stack traces, and it seems that all the leaked threads look like this: #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:165 #1 0x0000003916e23ab0 in PR_WaitCondVar (cvar=0x7f5d1d1b03c0, timeout=4294967295) at ../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:385 #2 0x0000003916e23db5 in PR_Wait (mon=0x7f5d24431c80, timeout=<optimized out>) at ../../../mozilla/nsprpub/pr/src/pthreads/ptsynch.c:582 #3 0x00007f5d36155b9d in Wait (interval=4294967295, this=0x7f5d244fa390) at ../../dist/include/mozilla/ReentrantMonitor.h:89 #4 Wait (interval=4294967295, this=<synthetic pointer>) at ../../dist/include/mozilla/ReentrantMonitor.h:192 #5 nsEventQueue::GetEvent (this=0x7f5d244fa390, mayWait=true, result=0x7f5d1d0fedf8) at /usr/src/debug/thunderbird-17.0.2/comm-release/mozilla/xpcom/threads/nsEventQueue.cpp:51 #6 0x00007f5d36156878 in nsThread::ProcessNextEvent (this=0x7f5d244fa340, mayWait=true, result=0x7f5d1d0fee3f) at /usr/src/debug/thunderbird-17.0.2/comm-release/mozilla/xpcom/threads/nsThread.cpp:605 #7 0x00007f5d3612c82b in NS_ProcessNextEvent_P (thread=<optimized out>, mayWait=true) at /usr/src/debug/thunderbird-17.0.2/comm-release/objdir/mozilla/xpcom/build/nsThreadUtils.cpp:220 #8 0x00007f5d36157080 in nsThread::ThreadFunc (arg=Python Exception <class 'gdb.error'> Attempt to dereference a generic pointer.: 0x7f5d244fa340) at /usr/src/debug/thunderbird-17.0.2/comm-release/mozilla/xpcom/threads/nsThread.cpp:257 #9 0x0000003916e28e23 in _pt_root (arg=Python Exception <class 'gdb.error'> Attempt to dereference a generic pointer.: 0x7f5d24867570) at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:156 #10 0x0000003909207d15 in start_thread (arg=Python Exception <class 'gdb.error'> Attempt to dereference a generic pointer.: 0x7f5d1d0ff700) at pthread_create.c:308 #11 0x0000003908af246d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114 Unfortunately that looks pretty generic to me and hence probably doesn't give much clue as to the cause of the leak.
Is there some information stored in any of the event objects that would give a clue as to who is responsible for them?
Reporter, please run thunderbird in debugger: http://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Running_application_in_debugger and after some time when you suspect that lot of threads leaked, switch to terminal and break program execution by Ctr-C and type command 'info thread'. This will print list of threads which currently exists. Please attach this output to this bug. You can also follow http://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Obtain_crash_stack_trace and attach 'crash_bt' file. The file will contain backtraces of all threads. Thanks.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.