[x264-devel] Yet another updated threaded slicetype patch (v14)

[Jason Garrett-Glaser]

On Tue, May 26, 2009 at 7:46 PM, Steven Walters <kemuri9 at gmail.com> wrote:
> OK, so i took a deeper crack at this a couple days ago when some time
> came around...
>
> the problem i was seeing that within
> encoder\lookahead.c - void x264_lookahead_thread( x264_t *h )
> upon entering the function h->rc is a valid non-null pointer.
> However, after entering and leaving the
> while ( h->lookahead->ifbuf.i_size == 0 && h->lookahead->b_exit_thread == 0 )
> branch, h->rc becomes NULL.
>
> as a small hack workaround, i tried storing h->rc into a local variable and
> set h->rc to the stored value before executing
> _x264_lookahead_slicetype_decide( h );
>
> it then successfully passed down h->rc to
> x264_ratecontrol_slice_type (h, ...)
>
> but it still seg faulted even with that.
>
> turning to valgrind at this point gets me the following output (on a
> debian box):
> ==13777== Thread 2:
> ==13777== Invalid read of size 4
> ==13777==    at 0x8095AFA: x264_ratecontrol_slice_type (ratecontrol.c:1012)
> ==13777==    by 0x8073414: x264_slicetype_decide (slicetype.c:608)
> ==13777==    by 0x8056CA3: (within /home/kemuri/projects/x264/x264test)
> ==13777==    by 0x809A86F: _x264_lookahead_slicetype_decide (lookahead.c:321)
> ==13777==    by 0x809AB5F: x264_lookahead_thread (lookahead.c:413)
> ==13777==    by 0x405023F: start_thread (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==13777==    by 0x412849D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so)
> ==13777==  Address 0xDC is not stack'd, malloc'd or (recently) free'd
> ==13777==
> ==13777== Process terminating with default action of signal 11 (SIGSEGV)
> ==13777==  Access not within mapped region at address 0xDC
> ==13777==    at 0x8095AFA: x264_ratecontrol_slice_type (ratecontrol.c:1012)
> ==13777==    by 0x8073414: x264_slicetype_decide (slicetype.c:608)
> ==13777==    by 0x8056CA3: (within /home/kemuri/projects/x264/x264test)
> ==13777==    by 0x809A86F: _x264_lookahead_slicetype_decide (lookahead.c:321)
> ==13777==    by 0x809AB5F: x264_lookahead_thread (lookahead.c:413)
> ==13777==    by 0x405023F: start_thread (in
> /lib/tls/i686/cmov/libpthread-2.3.6.so)
> ==13777==    by 0x412849D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so)
>
> so it does seem that the lookahead thread might need to allocate it's
> own ratecontrol_t
> what are the others' thought at this point?

As far as I can tell, the lookahead thread should never need to access
ratecontrol, ever, for any reason.  Any requirement that it do so is a
design flaw.

Dark Shikari