Fwd: [Bug 784193] Thunderbird leaks threads

[Orion Poplawski]

Any thoughts?


-------- Original Message --------
Subject: [Bug 784193] Thunderbird leaks threads
Date: Thu, 31 Jan 2013 10:10:04 +0000
From: bugz...@redhat.com
To: or...@cora.nwra.com

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=784193

Tom Hughes <t...@compton.nu> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |or...@cora.nwra.com
Component|thunderbird |thunderbird-lightning
Assignee|stra...@redhat.com |or...@cora.nwra.com

--- Comment #7 from Tom Hughes <t...@compton.nu> ---
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.

--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

[Stefan Sitter]

On 31.01.2013 16:37, Orion Poplawski wrote:
> Any thoughts?

From a quick search [1] in the latest Lightning 2.3 source code I think
there is only one place [2] that creates a thread in
calICSService::ParseICSAsync() via NS_NewThread().

How to tell if this thread is leaked?

[1] http://mxr.mozilla.org/comm-central/search?string=thread&find=/calendar/

[2]
http://mxr.mozilla.org/comm-central/source/calendar/base/src/calICSService.cpp#1264

[Orion Poplawski]

As noted in the bug, it seems most of the threads have to do with event
processing:

#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

I know nothing about this code, but perhaps threads can be created to process
events? Perhaps something is not setting them up properly? I wonder if there
is a way to see what created the event and event processor.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com

[Merike Sell]

I think (without knowledge of threading in calendar) it's very likely.

My tests in the hopes of finding out what has been causing me
intermittent crashes in random code parts for a while lead me to
https://bugzilla.mozilla.org/show_bug.cgi?id=833720#c5. I don't know yet
if this is actually related to my crashes (I've configured my network
calendars to update less often to find out) but it doesn't seem entirely
impossible that this many threads accumulating leads to crashing
elsewhere at some point...

Merike

[Mark Banner]

On 01/02/2013 16:11, Stefan Sitter wrote:
> On 31.01.2013 16:37, Orion Poplawski wrote:
>> Any thoughts?
>
> From a quick search [1] in the latest Lightning 2.3 source code I think
> there is only one place [2] that creates a thread in
> calICSService::ParseICSAsync() via NS_NewThread().
>
> How to tell if this thread is leaked?

If I understand threads correctly, then when it is no longer required,
Shutdown() must be called on the thread:

http://hg.mozilla.org/mozilla-central/annotate/847e28c7ba67/xpcom/threads/nsIThread.idl#l30

From what I can tell, the calendar code does this, for each call to
ParseICSAsync:

- Creates a worker (nsIRunnable) to parse the ics value
- Creates a new thread and dispatches the worker to it
- When the thread gets the go-ahead, it runs the the parser
- It them dispatches an event back to the main/original thread when it
has completed.

At no stage is Shutdown called, and a reference to the thread isn't kept
either.

There's two potential ways to fix this:

1) calICSService creates only one thread per application run, and
dispatches all ParseICSAsync requests to that thread. The thread then
can be shutdown once when the application shutdown.

2) calICSService continues creating multiple threads, but probably via
passing additional arguments/references, keeps track of when thread
completes and shuts them down appropriately.

The first option is probably slightly better than the second if there's
an acceptable trade-off that async ics requests are queued up if one is
still running when another comes in.

Mark.

p.s. if you agree this looks about right, please can someone file a bug
and stick this into it.

[Mark Banner]

On 04/02/2013 09:08, Mark Banner wrote:
> p.s. if you agree this looks about right, please can someone file a bug
> and stick this into it.

Just noticed we already had a bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=833720

Updated it with the comments.

Mark