Bug#797227: segfault - gst_memory_unmap, libgstreamer

[Sebastian Dröge]

Hi,

On Mo, 2015-08-31 at 18:05 +0100, jnqnfe wrote:
> 
> > Interesting... that doesn't make any sense unless something 
> > corrupted the stack :) Can you also run in valgrind with --track
> > -origins=yes and provide the log?
> 
> Sure. Just fyi, because loading iceweasel after a crash results in a
> state where it asks whether or not to try to restore my tabs, I
> reverted back to gst v1.5.90, allowing me to get a clean restore then
> shutdown of iceweasel, then I installed the older version again and 
> ran valgrind. I am not actually familiar with valgrind at all 
> currently, if this is loading iceweasel in a VM environment, is it 
> actually loading my iceweasel profile? If not, then is there any use 
> to this?

It is running the application like it would be running without
valgrind, so it should use your profile. But it runs in some kind of VM
to catch invalid memory accesses and things like that, so will be very
slow.

With this log it doesn't look like you got iceweasel to crash. Was it
just not possible to crash it?

I also forgot to mention that you should set G_SLICE=always-malloc in
the environment before running valgrind. So basically you would do

  G_SLICE=always-malloc valgrind --track-origins=yes iceweasel

and then go to the vimeo website where stuff was crashing and try to
make it crash :)


What is interesting in your log so far is that there are lots of
invalid memory accesses around GTK. I'm not surprised at all if there
are random crashes with all that code poking at random memory areas it
shouldn't :)
These invalid memory accesses seem to be iceweasel's fault, either in
the JavaScript engine or elsewhere.

> Do you think there is anything in the fact that we have gst-base
> libraries @ version 1.4.5-2 (built 110 days ago!) interacting with 
> gst -bad libraries @ version 1.4.5-2+b2 (built 3 days ago) in this
> troublesome stack trace. We're going through a major transition to 
> GCC5 right now (as I'm sure you know very well), which involves ABI
> breakages. Could there perhaps be a ABI breakage issue between these
> two libraries, considering one has been recently rebuilt, but not the
> other??

The gcc 5 transition might've broken something related to iceweasel,
which is written in C++ and depends a lot on C++ libraries. Which then
might result in the invalid memory accesses mentioned above.

But GStreamer and dependencies in use here are plain C, so are
unaffected by that transition. Same for GTK.

I think there are problems somewhere in iceweasel in the way it is
using GTK, which is independent of the gcc 5 transition. And which
might or might not be the reason for the crash.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-gstreamer-maintainers/attachments/20150901/5ddda5a8/attachment.sig>