[x264-devel] [BUG] segfault when second pass has more frames than the first

[Corey Hickey]

Jason Garrett-Glaser wrote:
> On Mon, Feb 15, 2010 at 12:22 AM, Corey Hickey <bugfood-ml at fatooh.org> wrote:
>> Hello,
>>
>> I ran into this segfault while I was trying to figure out another bug,
>> and thought I'd see if I could fix it. I know that second passes should
>> have the same number of frames as the first, but x264 appears to have
>> code to handle this already, and that code just isn't quite working.
> 
> Fixed in http://git.videolan.org/?p=x264.git;a=commit;h=bb0990813c7fb047a322c5d463cde5ae8e22c756

Many thanks. I still get a segfault with my test case, though--it's in a
different place now.

$ mencoder -demuxer rawvideo -rawvideo w=16:h=16 /dev/zero \
  -o /dev/null -ovc x264 -x264encopts pass=1:bitrate=200 -frames 1

$ mencoder -demuxer rawvideo -rawvideo w=16:h=16 /dev/zero \
  -o /dev/null -ovc x264 -x264encopts pass=2:bitrate=200 -frames 2

Program received signal SIGSEGV, Segmentation fault.
0x0000000000c5634b in x264_weight_cost_init_luma (h=0x1663510,
fenc=0x188b8d0, ref=0x187d130,
    dest=0x1852bb0 "") at encoder/slicetype.c:93
93          if( fenc->lowres_mvs[0][ref0_distance][0][0] != 0x7FFF )
(gdb) print ref0_distance
$14 = 1
(gdb) print fenc->lowres_mvs[0][ref0_distance]
$15 = (int16_t (*)[2]) 0x0

It would appear that these are only allocated if h->frames.b_have_lowres
at common/frame.c:136.

I've attached a more complete gdb log, in case it's useful.

Thanks again,
Corey
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gdb.log
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20100215/af8c2c14/attachment.asc>