Stack memory issue with gstreamer

[Haakon Sporsheim]

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?

Regarding your output from /proc/$pid/maps file:
It shows you that your current mapped memory for your main thread has
virtual address be845000-be866000 which would be 33x 4k pages.
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?

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.
You wrote about 5 threads:
 - main thread running GMainLoop or qt main loop (or what ever it is
called)?
 - pulseaudio thread (could there be a bug here?)
 - 2x gstthreads (these I suspect will be joined and respawned on every
set_state NULL and then PLAYING)
 - glib thread (?, or is this the GMainLoop where GstBus messages are
processed? Then this might be joined and respawned as well)

Haakon


On Thu, May 1, 2014 at 10:26 PM, jbvulai <jb.vu.lai at gmail.com> wrote:

> Hi Haakon,
>
> 1. I don't have a definite value for how many bytes are leaking each
> iteration, but from what i could tell the stack grows a bit less than 1kb
> each iteration. This is according to the massif graphs. Each iteration has
> either 3-4 file source changes.
>
> 2. This is nice command, unfortunatly it did not yield and clues as it
> didnt
> show any value.
> be845000-be866000 rwxp 00000000 00:00 0          [stack]
>
>
> We've also suspected about the start and join of threads, but did not where
> to start where to check for this.  A thread spawning app would be a good
> idea, but I don't undertstand why this would leak in the stack.
>
> Regards,
>
> J.B.
>
>
>
>
> --
> View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/Stack-memory-issue-with-gstreamer-tp4666681p4666701.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140501/b1e4f29a/attachment.html>