[jitsi-dev] Video preview issue with Jitsi


#1

Hi all,

I have recently come accross with a possible memory leak on Jitsi,
which seemed very important. Its an issue about video streaming with
the client. I found out that some threads, which are created whilst
video preview is open in the Options->Video section, seem to be hung
up even if the video preview is stopped by closing the window or
changing to another tab in the Options menu. Each time I try to open
video preview tab in the options menu, new threads are created and
they never get destroyed until the client is totally shutdown by the
end user.

I tried to debug the problem through Eclipse IDE and saw that video
preview is triggered by some device capture code on Java side, and
with JNI, directshow interface for the Windows OS is accessed. I am
not so familiar with native side but what I can say is that, threads
are not destroyed after device capture code successfully calls doStop
and doDisconnect methods which access to directshow code on native
side.

Sebastien,

It seems that you are the author of the mentioned code in Java side
(DSCaptureDevice). Do you have an opinion on this? Is there a way to
detach those threads after we are done with video capturing?

I guess this is a major issue if the OS got overwhelmed with growing
number of directshow threads.

BTW, I ran the client on Windows XP SP3 machine and I used a Microsoft
Live Cam for video capturing.

Thanks&Regards
Sercan Sadi


#2

Thank you for the report! Could you please be more specific and tell
us whether these are Java or native threads? Which tool shows them to
you? Do you see their names (e.g. if these are Java threads and you
see them in a Java thread dump)? I'm asking because the video devices
on all platforms use base/super classes so the problem could possibly
be in them.

···

On Wed, Mar 30, 2011 at 9:10 PM, Sercan Sadi <sercan.sadi@gmail.com> wrote:

I found out that some threads, which are created whilst
video preview is open in the Options->Video section, seem to be hung
up even if the video preview is stopped by closing the window or
changing to another tab in the Options menu. Each time I try to open
video preview tab in the options menu, new threads are created and
they never get destroyed until the client is totally shutdown by the
end user.


#3

Hi Lyubomir,

I guess its a Java daemon thread triggered by the JMF packages. I
added a screenshot which shows the thread number 22 is created when
starting video preview. I used the debugging interface of the Eclipse
IDE (version 3.6 Helios). But I can have any further logs you request
from me. I try to suspend the problematic threads to see the linecodes
or any other valuable info for tracking, but it wont help, suspended
thread does not show anything unlike the other java threads in the
list.

···

On Wed, Mar 30, 2011 at 9:19 PM, Lyubomir Marinov <lubo@jitsi.org> wrote:

On Wed, Mar 30, 2011 at 9:10 PM, Sercan Sadi <sercan.sadi@gmail.com> wrote:

I found out that some threads, which are created whilst
video preview is open in the Options->Video section, seem to be hung
up even if the video preview is stopped by closing the window or
changing to another tab in the Options menu. Each time I try to open
video preview tab in the options menu, new threads are created and
they never get destroyed until the client is totally shutdown by the
end user.

Thank you for the report! Could you please be more specific and tell
us whether these are Java or native threads? Which tool shows them to
you? Do you see their names (e.g. if these are Java threads and you
see them in a Java thread dump)? I'm asking because the video devices
on all platforms use base/super classes so the problem could possibly
be in them.


#4

Thank you very much for the fast response! Instead of Eclipse IDE,
please use jstack.exe (which is part of the Java Development Kit) to
dump the stacks of the running threads and send them to us as well so
that we can look at them together.

···

On Wed, Mar 30, 2011 at 9:43 PM, Sercan Sadi <sercan.sadi@gmail.com> wrote:

But I can have any further logs you request
from me. I try to suspend the problematic threads to see the linecodes
or any other valuable info for tracking, but it wont help, suspended
thread does not show anything unlike the other java threads in the
list.


#5

I collected the logs with jstack. I ran the problem scenario, I
displayed video preview for two times and total of 6 threads are
created (3 threads plus for each time I display video preview). They
are numbered from 22 to 27 and unfortunately, theydo not have any
explanatory thread dump info

jstackOutput.txt (13.5 KB)

···

On Wed, Mar 30, 2011 at 9:50 PM, Lyubomir Marinov <lubo@jitsi.org> wrote:

On Wed, Mar 30, 2011 at 9:43 PM, Sercan Sadi <sercan.sadi@gmail.com> wrote:

But I can have any further logs you request
from me. I try to suspend the problematic threads to see the linecodes
or any other valuable info for tracking, but it wont help, suspended
thread does not show anything unlike the other java threads in the
list.

Thank you very much for the fast response! Instead of Eclipse IDE,
please use jstack.exe (which is part of the Java Development Kit) to
dump the stacks of the running threads and send them to us as well so
that we can look at them together.


#6

Great catch! These "triplets" are so not dying on my Windows too.


#7

Le 30/03/11 23:17, Lyubomir Marinov a �crit :

Great catch! These "triplets" are so not dying on my Windows too.

I am also able to reproduce this problem on Windows.

BTW it seems that it does not occurs on Mac OS X. The design of the JMF capture device is very similar between directshow (Windows) and QuickTime (Mac OS X). Maybe it could be something in JMF version for Windows ?

···

--
Seb


#8

Hi all,

The directshow native code use AttachCurrentThreadAsDaemon and does not call DetachCurrentThread after so the daemon thread stay.

We will test a little more to see if there are no problems and we will commit the new directshow DLL for 32-bit and 64-bit Windows version.

···

--
Seb

Le 31/03/11 09:29, Sebastien Vincent a �crit :

Le 30/03/11 23:17, Lyubomir Marinov a �crit :

Great catch! These "triplets" are so not dying on my Windows too.

I am also able to reproduce this problem on Windows.

BTW it seems that it does not occurs on Mac OS X. The design of the JMF capture device is very similar between directshow (Windows) and QuickTime (Mac OS X). Maybe it could be something in JMF version for Windows ?

--
Seb


#9

As far as my experience goes, AttachCurrentThreadAsDaemon does not
prevent the native thread from perishing. Is it not correct?

If the native thread calls back to you and you
AttachCurrentThreadAsDaemon when you enter the callback and
DetachCurrentThread when you exit the callback, there is a performance
downside that each time the callback is executed a new Java Thread
object has to be created. And in the case of capturing with a
callback, one may pretty much create such Java Thread objects in the
range of hundreds in a very short time.

···

On Thu, Mar 31, 2011 at 11:18 AM, Sebastien Vincent <seb@sip-communicator.org> wrote:

The directshow native code use AttachCurrentThreadAsDaemon and does not call
DetachCurrentThread after so the daemon thread stay.


#10

Le 31/03/11 10:25, Lyubomir Marinov a �crit :

The directshow native code use AttachCurrentThreadAsDaemon and does not call
DetachCurrentThread after so the daemon thread stay.

As far as my experience goes, AttachCurrentThreadAsDaemon does not
prevent the native thread from perishing. Is it not correct?

Maybe it is an internal directshow thread that never die. I will try to find some information about that.

If the native thread calls back to you and you
AttachCurrentThreadAsDaemon when you enter the callback and
DetachCurrentThread when you exit the callback, there is a performance
downside that each time the callback is executed a new Java Thread
object has to be created. And in the case of capturing with a
callback, one may pretty much create such Java Thread objects in the
range of hundreds in a very short time.

OK, I will modify code to just call DetachCurrentThread when the capture device stop.

···

On Thu, Mar 31, 2011 at 11:18 AM, Sebastien Vincent > <seb@sip-communicator.org> wrote:

--
Seb