[jitsi-dev] Call Thread Leak


#1

I have noticed what I believe is a thread leak in the SIP call logic.
When a call is made 10 or so threads are created for it. Then when the
SIP server initiates the direct connection between the clients an
additional 6 threads are created.

I am building and debugging the current nightly release with Netbeans on
Windows.

Thanks

Michael


#2

Hey Michael,

I have noticed what I believe is a thread leak in the SIP call logic.

When a call is made 10 or so threads are created for it. Then when the SIP
server initiates the direct connection between the clients an additional 6
threads are created.

And because you are mentioning a leak, I assume all these threads persist
after the call has ended. Is this correct or did I miss something?

Emil

--sent from my mobile

I am building and debugging the current nightly release with Netbeans on

Windows.

···

On Apr 14, 2012 1:35 AM, <jmichael.carter@l-3com.com> wrote:

Thanks

Michael


#3

Sorry I hit send before I proofed.

It looks like 2 or 3 threads of the 12 created for the call terminated
when the call ends. What I have not been able to determine is if this
is because of running within Netbeans debug environment or the way
Windows is implementing threads. I have not performed enough testing to
track down the cause and am looking to see if anyone can confirm my
observation.

Michael

···

From: Emil Ivov [mailto:emcho@jitsi.org]

Sent: Friday, April 13, 2012 6:49 PM
To: dev@jitsi.java.net
Subject: [jitsi-dev] Re: Call Thread Leak

Hey Michael,

On Apr 14, 2012 1:35 AM, <jmichael.carter@l-3com.com> wrote:

I have noticed what I believe is a thread leak in the SIP call logic.

When a call is made 10 or so threads are created for it. Then when the
SIP server initiates the direct connection between the clients an
additional 6 threads are created.

And because you are mentioning a leak, I assume all these threads
persist after the call has ended. Is this correct or did I miss
something?

Emil

--sent from my mobile

I am building and debugging the current nightly release with Netbeans

on Windows.

Thanks

Michael


#4

I did some testing about this. I'm running openSUSE 12.1 64 bit, I haven't used Eclipse or Netbeans and I can see some leak, so IMHO the problem is not the environment. Here are the results:
Just started Jitsi:
65 threads, 271 MB memory
Call 1 started:
93 threads, 544 MB memory
Call 1 closed:
69 threads (very) slowly decreasing to 66, 545 MB memory
Call 2 started:
94 threads, 564 MB memory
Call 2 closed:
70 threads (very) slowly decreasing to 68, 564 MB memory
Call 3 started:
96 threads, 563 MB memory
Call 3 closed:
71 threads (very) slowly decreasing to 70, 563 MB memory
Every call was made to echo@iptel.org, so no zrtp or similar.

I found another interesting thing: making a search, canceling it, making the same search, canceling it, etc. results in 4-6 MB of additional used memory (which is not freed) for every action.

I hope these tests could be useful.

Cheers,

Daniel Z.

···

Il 14/04/2012 03:24, jmichael.carter@L-3com.com ha scritto:

Sorry I hit send before I proofed.

It looks like 2 or 3 threads of the 12 created for the call terminated when the call ends. What I have not been able to determine is if this is because of running within Netbeans debug environment or the way Windows is implementing threads. I have not performed enough testing to track down the cause and am looking to see if anyone can confirm my observation.

Michael

*From:*Emil Ivov [mailto:emcho@jitsi.org]
*Sent:* Friday, April 13, 2012 6:49 PM
*To:* dev@jitsi.java.net
*Subject:* [jitsi-dev] Re: Call Thread Leak

Hey Michael,

On Apr 14, 2012 1:35 AM, <jmichael.carter@l-3com.com > <mailto:jmichael.carter@l-3com.com>> wrote:
>
> I have noticed what I believe is a thread leak in the SIP call logic. When a call is made 10 or so threads are created for it. Then when the SIP server initiates the direct connection between the clients an additional 6 threads are created.

And because you are mentioning a leak, I assume all these threads persist after the call has ended. Is this correct or did I miss something?

Emil

--sent from my mobile

> I am building and debugging the current nightly release with Netbeans on Windows.
>
> Thanks
>
> Michael


#5

I did some testing about this. I'm running openSUSE 12.1 64 bit, I haven't used Eclipse or Netbeans and I can see some leak, so IMHO the problem is not the environment. Here are the results:
Just started Jitsi:
65 threads, 271 MB memory
Call 1 started:
93 threads, 544 MB memory
Call 1 closed:
69 threads (very) slowly decreasing to 66, 545 MB memory
Call 2 started:
94 threads, 564 MB memory
Call 2 closed:
70 threads (very) slowly decreasing to 68, 564 MB memory
Call 3 started:
96 threads, 563 MB memory
Call 3 closed:
71 threads (very) slowly decreasing to 70, 563 MB memory
Every call was made to echo@iptel.org, so no zrtp or similar.

I found another interesting thing: making a search, canceling it, making the same search, canceling it, etc. results in 4-6 MB of additional used memory (which is not freed) for every action.

I hope these tests could be useful.

Cheers,

Daniel Z.

···

Il 14/04/2012 03:24, jmichael.carter@L-3com.com ha scritto:

Sorry I hit send before I proofed.

It looks like 2 or 3 threads of the 12 created for the call terminated when the call ends. What I have not been able to determine is if this is because of running within Netbeans debug environment or the way Windows is implementing threads. I have not performed enough testing to track down the cause and am looking to see if anyone can confirm my observation.

Michael

*From:*Emil Ivov [mailto:emcho@jitsi.org]
*Sent:* Friday, April 13, 2012 6:49 PM
*To:* dev@jitsi.java.net
*Subject:* [jitsi-dev] Re: Call Thread Leak

Hey Michael,

On Apr 14, 2012 1:35 AM, <jmichael.carter@l-3com.com > <mailto:jmichael.carter@l-3com.com>> wrote:
>
> I have noticed what I believe is a thread leak in the SIP call logic. When a call is made 10 or so threads are created for it. Then when the SIP server initiates the direct connection between the clients an additional 6 threads are created.

And because you are mentioning a leak, I assume all these threads persist after the call has ended. Is this correct or did I miss something?

Emil

--sent from my mobile

> I am building and debugging the current nightly release with Netbeans on Windows.
>
> Thanks
>
> Michael


#6

This appears to be aggravated by timing. While testing with variable
induced latency of packets I have seen a different number of threads
left on a call. Strangely it is less threads left with a higher SIP
packet latency. So I speculate that there is a problem with thread
critical section control.

Thanks,

Michael

···

From: Daniel Zucchetto [mailto:dzmail90-voip@yahoo.it]

Sent: Saturday, April 14, 2012 3:31 PM
To: dev@jitsi.java.net
Subject: [jitsi-dev] Re: Call Thread Leak

I did some testing about this. I'm running openSUSE 12.1 64 bit, I
haven't used Eclipse or Netbeans and I can see some leak, so IMHO the
problem is not the environment. Here are the results:
Just started Jitsi:
65 threads, 271 MB memory
Call 1 started:
93 threads, 544 MB memory
Call 1 closed:
69 threads (very) slowly decreasing to 66, 545 MB memory
Call 2 started:
94 threads, 564 MB memory
Call 2 closed:
70 threads (very) slowly decreasing to 68, 564 MB memory
Call 3 started:
96 threads, 563 MB memory
Call 3 closed:
71 threads (very) slowly decreasing to 70, 563 MB memory
Every call was made to echo@iptel.org, so no zrtp or similar.

I found another interesting thing: making a search, canceling it, making
the same search, canceling it, etc. results in 4-6 MB of additional used
memory (which is not freed) for every action.

I hope these tests could be useful.

Cheers,

Daniel Z.

Il 14/04/2012 03:24, jmichael.carter@L-3com.com ha scritto:

Sorry I hit send before I proofed.

It looks like 2 or 3 threads of the 12 created for the call terminated
when the call ends. What I have not been able to determine is if this
is because of running within Netbeans debug environment or the way
Windows is implementing threads. I have not performed enough testing to
track down the cause and am looking to see if anyone can confirm my
observation.

Michael

From: Emil Ivov [mailto:emcho@jitsi.org]

Sent: Friday, April 13, 2012 6:49 PM
To: dev@jitsi.java.net
Subject: [jitsi-dev] Re: Call Thread Leak

Hey Michael,

On Apr 14, 2012 1:35 AM, <jmichael.carter@l-3com.com> wrote:

I have noticed what I believe is a thread leak in the SIP call logic.

When a call is made 10 or so threads are created for it. Then when the
SIP server initiates the direct connection between the clients an
additional 6 threads are created.

And because you are mentioning a leak, I assume all these threads
persist after the call has ended. Is this correct or did I miss
something?

Emil

--sent from my mobile

I am building and debugging the current nightly release with Netbeans

on Windows.

Thanks

Michael


#7

Hey Michael,

We appreciate you looking into this since we don't currently have the
time. Could you please also log an issue so that we don't forget about it?

Thanks,
Emil

···

On 20.04.12 21:59, jmichael.carter@L-3com.com wrote:

This appears to be aggravated by timing. While testing with variable
induced latency of packets I have seen a different number of threads
left on a call. Strangely it is less threads left with a higher SIP
packet latency. So I speculate that there is a problem with thread
critical section control.

Thanks,

Michael

*From:*Daniel Zucchetto [mailto:dzmail90-voip@yahoo.it]
*Sent:* Saturday, April 14, 2012 3:31 PM
*To:* dev@jitsi.java.net
*Subject:* [jitsi-dev] Re: Call Thread Leak

I did some testing about this. I'm running openSUSE 12.1 64 bit, I
haven't used Eclipse or Netbeans and I can see some leak, so IMHO the
problem is not the environment. Here are the results:
Just started Jitsi:
65 threads, 271 MB memory
Call 1 started:
93 threads, 544 MB memory
Call 1 closed:
69 threads (very) slowly decreasing to 66, 545 MB memory
Call 2 started:
94 threads, 564 MB memory
Call 2 closed:
70 threads (very) slowly decreasing to 68, 564 MB memory
Call 3 started:
96 threads, 563 MB memory
Call 3 closed:
71 threads (very) slowly decreasing to 70, 563 MB memory
Every call was made to echo@iptel.org <mailto:echo@iptel.org>, so no
zrtp or similar.

I found another interesting thing: making a search, canceling it, making
the same search, canceling it, etc. results in 4-6 MB of additional used
memory (which is not freed) for every action.

I hope these tests could be useful.

Cheers,

Daniel Z.

Il 14/04/2012 03:24, jmichael.carter@L-3com.com > <mailto:jmichael.carter@L-3com.com> ha scritto:

Sorry I hit send before I proofed.

It looks like 2 or 3 threads of the 12 created for the call terminated
when the call ends. What I have not been able to determine is if this
is because of running within Netbeans debug environment or the way
Windows is implementing threads. I have not performed enough testing to
track down the cause and am looking to see if anyone can confirm my
observation.

Michael

*From:*Emil Ivov [mailto:emcho@jitsi.org]
*Sent:* Friday, April 13, 2012 6:49 PM
*To:* dev@jitsi.java.net <mailto:dev@jitsi.java.net>
*Subject:* [jitsi-dev] Re: Call Thread Leak

Hey Michael,

On Apr 14, 2012 1:35 AM, <jmichael.carter@l-3com.com > <mailto:jmichael.carter@l-3com.com>> wrote:

I have noticed what I believe is a thread leak in the SIP call logic.

When a call is made 10 or so threads are created for it. Then when the
SIP server initiates the direct connection between the clients an
additional 6 threads are created.

And because you are mentioning a leak, I assume all these threads
persist after the call has ended. Is this correct or did I miss something?

Emil

--sent from my mobile

I am building and debugging the current nightly release with Netbeans

on Windows.

Thanks

Michael