[x264-devel] fyi: solaris dbx reporting Read from uninitialized

[Jason Garrett-Glaser]

On Sat, Jan 16, 2010 at 12:22 AM, Chris Brookes <cbrookes at gmail.com> wrote:
> While running x264 under dbx (see other thread), with runtime checking
> enabled it keeps finding rui problems, all of which are from the same
> line of code (so far). here's an example:
>
> Read from uninitialized (rui) on thread 1:
> Attempting to read 1 byte at address 0xe206d8e
>    which is 430 bytes into a heap block of size 2040 bytes at 0xe206be0
> This block was allocated from:
>        [1] x264_malloc() at line 771 in "common.c"
>        [2] x264_frame_new() at line 144 in "frame.c"
>        [3] x264_frame_pop_unused() at line 1001 in "frame.c"
>        [4] x264_encoder_encode() at line 2030 in "encoder.c"
>        [5] main() at line 1236 in "x264.c"
>
> t at 1 (l at 1) stopped in x264_slicetype_mb_cost at line 419 in file "slicetype.c"
>  419       frames[b]->lowres_inter_types[b-p0][p1-b][i_mb_xy>>2] &=
> ~(3<<((i_mb_xy&3)*2));
>
> I don't know that this is significant but thought I'd mention it anyway.

Not a problem.

It's a bitfield, so it stores 4 2-bit values in each 8-bit value.  So
if none of the values in a given 8-bit chunk are set yet, the
following occurs:

1) XX XX XX XX (all invalid)
2) AA XX XX XX (some invalid)
3) AA BB XX XX (some invalid)
4) AA BB CC XX (some invalid)
5) AA BB CC DD (none invalid)

1->2, 2->3, and 3->4 all consist of reading and writing to/from a
value that is not initialized, despite the fact that it's a perfectly
valid and reasonable operation that doesn't depend on uninitialized
data.  An overzealous runtime checker will whine.  Valgrind won't,
because it's smarter than that (and only complains about branches
based on uninitialized data, not the data itself).

Dark Shikari