<div dir="ltr"><div><font face="arial, sans-serif">Just btw, are your application crashing due to a thread running out of stack or is your problem something else. If it is crashing due to stack overflow, does it run for longer if you increase default stack size on your system?</font></div>
<div><font face="arial, sans-serif"><br></font></div>Regarding your output from /proc/$pid/maps file:<div>It shows you that your current mapped memory for your main thread has virtual address <span style="font-family:arial,sans-serif;font-size:13px">be845000-be866000 which would be 33x 4k pages.</span></div>
<div><font face="arial, sans-serif">My linux kernel yields multiple lines, one for each stack/thread in the format <fromaddr>-<toaddr><perms> 00000000 00:00 0 [stack:<threadID>]. Its been like this since Linux 3.4. So if you are on an older kernel that's a probably why you only see one [stack]! You could have a look at /proc/$pid/tasks/$tid/maps for each thread of course. Well, anyway - does it change over time? Does it correlate to what gdb or massif is telling you?</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">What you want to figure out is which thread stack that increases! If non of the long running threads have increasing stacks, then I would start investigating deeper problems.</font></div>
<div><font face="arial, sans-serif">You wrote about 5 threads:</font></div><div><font face="arial, sans-serif"> - main thread running GMainLoop or qt main loop (or what ever it is called)?</font></div><div><font face="arial, sans-serif"> - pulseaudio thread (could there be a bug here?)</font></div>
<div><font face="arial, sans-serif"> - 2x gstthreads (these I suspect will be joined and respawned on every set_state NULL and then PLAYING)</font></div><div><font face="arial, sans-serif"> - glib thread (?, or is this the GMainLoop where GstBus messages are processed? Then this might be joined and respawned as well)</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><span style="font-family:arial,sans-serif">Haakon</span><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 1, 2014 at 10:26 PM, jbvulai <span dir="ltr"><<a href="mailto:jb.vu.lai@gmail.com" target="_blank">jb.vu.lai@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Haakon,<br>
<br>
1. I don't have a definite value for how many bytes are leaking each<br>
iteration, but from what i could tell the stack grows a bit less than 1kb<br>
each iteration. This is according to the massif graphs. Each iteration has<br>
either 3-4 file source changes.<br>
<br>
2. This is nice command, unfortunatly it did not yield and clues as it didnt<br>
show any value.<br>
be845000-be866000 rwxp 00000000 00:00 0          [stack]<br>
<br>
<br>
We've also suspected about the start and join of threads, but did not where<br>
to start where to check for this.  A thread spawning app would be a good<br>
idea, but I don't undertstand why this would leak in the stack.<br>
<br>
Regards,<br>
<br>
J.B.<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://gstreamer-devel.966125.n4.nabble.com/Stack-memory-issue-with-gstreamer-tp4666681p4666701.html" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/Stack-memory-issue-with-gstreamer-tp4666681p4666701.html</a><br>

<div class="HOEnZb"><div class="h5">Sent from the GStreamer-devel mailing list archive at Nabble.com.<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</div></div></blockquote></div><br></div>