possible progress on XO-1 camera issues

[James Cameron]

As Tomeu also found, this backtrace frame is the most interesting:

#10 0xb67fae59 in gst_xvimagesink_xvimage_put (xvimagesink=0x8364160)
    at xvimagesink.c:864
        src = {x = 134867456, y = 140758336, w = -1259457208, h = 1}
        dst = {x = 137730309, y = 3, w = 0, h = 137691184}
        result = {x = 0, y = 0, w = 322, h = 241}
        draw_border = 322
        __PRETTY_FUNCTION__ = "gst_xvimagesink_xvimage_put"

The src.w value is in the same range as the Xlib function addresses;
-1259457208 is 0x4B11CAB8 and as can be seen from the call frame #9
the XSync function is at 0x4b0eccf7.  The other values seem
irrational.  This may be evidence that the stack has been corrupted
somewhere else, or the values not initialised.

Looking higher in the code, src.w, src.h, dst.w and dst.h are copied
from xvimagesink struct members.  That excludes initialisation of the
variables as a cause.  This may be evidence that these structures have
been corrupted somewhere else.

draw_border is set by the code to either TRUE or FALSE, so a value of
322 is unexpected.  It is also the same value for width.  Compiler
optimisation may cause a register to be used.

If the xvimagesink buffer is so corrupt as to generate those strange
values for src and dst, then when it is sent to XvPutImage the X error
is expected.

I've reviewed the upstream source, git repository
git://anongit.freedesktop.org/gstreamer/gst-plugins-base
but there have been no significant changes in that section of code.

On Fri, Dec 18, 2009 at 05:59:56PM +0000, Tomeu Vizoso wrote:
> Maybe you can set a breakpoint at gst_xvimagesink_xvimage_put and see
> from where come those invalid values?

I agree.

-- 
James Cameron
http://quozl.linux.org.au/