[sldev] Community QA process

[Carlo Wood]

On Fri, Apr 24, 2009 at 12:17:10PM -0400, Jason Giglio wrote:
> GDB Backtrace on an *unstripped* binary, along with a little about what
> you were doing when it happened, is probably enough info to fix 80% of
> the bugs.

I disagree. Most crashes happen in third party libraries.
The crashes that last (that aren't already fixed) never happen in
the location where the problem is.

Problems might involve memory corruption (using freed objects,
overflows), hardware specific or hard to reproduce external
environment involvement (ie, someone using a bad internet
connection; or a specific type of videocard), race conditions
or other threading related issues, etc. None of those will
be easy to fix with a backtrace.

I've been collecting backtraces from my own crashes just to
see if they happen in the same place (and in fact, most of
my current crashes happen clearly at the moment that a media
url is changed).

So here isn't example (not reported, by me, before):

When the media url is changed as a result of a teleport,
entering a parcel or maybe by a script (didn't run into it
yet when I did it manually), the viewer crashes with a
backtrace like the following:

#0  0x0000000000000000 in ?? ()
#1  0x00007f1a83962941 in g_object_notify () from /usr/lib/libgobject-2.0.so.0
#2  0x00007f1a605b9538 in ?? () from /usr/lib/gstreamer-0.10/libgstplaybin.so
#3  0x00007f1a7f5edc98 in gst_marshal_BOOLEAN__POINTER (closure=0x57d7bf0, return_value=0x46a4abe0, n_param_values=<value optimized out>, param_values=0x46a4ac50,
    invocation_hint=<value optimized out>, marshal_data=0x7f1a605b9370) at gstmarshal.c:584
#4  0x00007f1a8395c11d in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#5  0x00007f1a8396fd0d in ?? () from /usr/lib/libgobject-2.0.so.0
#6  0x00007f1a7f5b1628 in gst_pad_emit_have_data_signal (pad=<value optimized out>, obj=0x4945f00) at gstpad.c:3830
#7  0x00007f1a7f5b1ee5 in gst_pad_push_event (pad=0x57b5da0, event=0x4945f00) at gstpad.c:4476
#8  0x00007f1a7f5b1a18 in gst_pad_send_event (pad=0x49f3d30, event=0x4945f00) at gstpad.c:4634
#9  0x00007f1a7f5b2038 in gst_pad_push_event (pad=0x590acf0, event=0x4945f00) at gstpad.c:4490
#10 0x00007f1a52cdc316 in ?? () from /usr/lib/gstreamer-0.10/libgstffmpeg.so
#11 0x00007f1a7f5b1a18 in gst_pad_send_event (pad=0x590ab80, event=0x4945f00) at gstpad.c:4634
#12 0x00007f1a7f5b2038 in gst_pad_push_event (pad=0x590aa10, event=0x4945f00) at gstpad.c:4490
#13 0x00007f1a60179b79 in gst_queue_loop (pad=<value optimized out>) at gstqueue.c:1093
#14 0x00007f1a7f5d56d6 in gst_task_func (task=0x5738030, tclass=<value optimized out>) at gsttask.c:192
#15 0x00007f1a836ef387 in ?? () from /usr/lib/libglib-2.0.so.0
#16 0x00007f1a836eddf4 in ?? () from /usr/lib/libglib-2.0.so.0
#17 0x00007f1a824c8fc7 in start_thread () from /lib/libpthread.so.0
#18 0x00007f1a7d7845ad in clone () from /lib/libc.so.6

Now, if you think the 0x0000000000000000 at the top is significant,
here is another:

#0  0x00007f2623ae2513 in ?? () from /usr/lib/libgobject-2.0.so.0
#1  0x00007f2623ae4045 in g_object_set_valist () from /usr/lib/libgobject-2.0.so.0
#2  0x00007f2623ae4324 in g_object_set () from /usr/lib/libgobject-2.0.so.0
#3  0x00007f2600748090 in ?? () from /usr/lib/gstreamer-0.10/libgstplaybin.so
#4  0x00007f2600748469 in ?? () from /usr/lib/gstreamer-0.10/libgstplaybin.so
#5  0x00007f2600749a20 in ?? () from /usr/lib/gstreamer-0.10/libgstplaybin.so
#6  0x00007f2623adf11d in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#7  0x00007f2623af2d0d in ?? () from /usr/lib/libgobject-2.0.so.0
#8  0x00007f2623af41d8 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#9  0x00007f2623af46d3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#10 0x00007f2623adf11d in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#12 0x00007f2623af41d8 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#13 0x00007f2623af46d3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#14 0x00007f25f584f7e3 in ?? () from /usr/lib/gstreamer-0.10/libgstqtdemux.so
#15 0x00007f25f5850fbf in ?? () from /usr/lib/gstreamer-0.10/libgstqtdemux.so
#16 0x00007f261f7378e6 in gst_pad_chain_unchecked (pad=0x12b468a0, buffer=0x7f25cd58e6c0) at gstpad.c:3890
#17 0x00007f261f738bc3 in gst_pad_push (pad=0xd99a730, buffer=0x7f25cd58e6c0) at gstpad.c:4057
#18 0x00007f25fbdf10ff in gst_type_find_element_chain (pad=0xd99acf0, buffer=0x7f25cd58e6c0) at gsttypefindelement.c:623
#19 0x00007f261f7378e6 in gst_pad_chain_unchecked (pad=0xd99acf0, buffer=0x7f25cd58e6c0) at gstpad.c:3890
#20 0x00007f261f738bc3 in gst_pad_push (pad=0x12b763e0, buffer=0x7f25cd58e6c0) at gstpad.c:4057
#21 0x00007f261f7378e6 in gst_pad_chain_unchecked (pad=0x10ebdd80, buffer=0x7f25cd58e6c0) at gstpad.c:3890
#22 0x00007f261f738bc3 in gst_pad_push (pad=0x12b46170, buffer=0x7f25cd58e6c0) at gstpad.c:4057
#23 0x00007f2600f88431 in gst_base_src_loop (pad=0x12b46170) at gstbasesrc.c:2275
#24 0x00007f261f7586d6 in gst_task_func (task=0xbb38960, tclass=<value optimized out>) at gsttask.c:192
#25 0x00007f2623872387 in ?? () from /usr/lib/libglib-2.0.so.0
#26 0x00007f2623870df4 in ?? () from /usr/lib/libglib-2.0.so.0
#27 0x00007f262264bfc7 in start_thread () from /lib/libpthread.so.0
#28 0x00007f261d9075ad in clone () from /lib/libc.so.6

Now you might think this is easy to fix if you look at the source code
of the lines mentioned.. but I doubt that because this only happens
sometimes - not every time.

Although I'm running the viewer always in gdb, I didn't yet get
to it to install *all* libraries involved in a debugable way :p
I'm pretty sure 99.999% of the users will have libraries installed
that give equal or less information.

-- 
Carlo Wood <carlo at alinoe.com>