GNOME Bugzilla – Bug 749378
theoraenc: induces valgrind error downstream in oggmux when transcoding
Last modified: 2015-05-20 08:37:01 UTC
Running the validate.file.transcode.to_vorbis_and_theora_in_ogg.mp3_h264_0_mp4 scenario inside valgrind raise this error: ==23014== Use of uninitialised value of size 8 ==23014== at 0x93300C1: ogg_page_checksum_set (framing.c:307) ==23014== by 0x933041B: ogg_stream_flush_i (framing.c:515) ==23014== by 0x8F01CFB: gst_ogg_mux_process_best_pad (gstoggmux.c:1704) ==23014== by 0x8F01CFB: gst_ogg_mux_collected (gstoggmux.c:2042) ==23014== by 0x57DE876: gst_collect_pads_check_collected (gstcollectpads.c:1340) ==23014== by 0x57E0068: gst_collect_pads_chain (gstcollectpads.c:2193) ==23014== by 0x4C2B458: gst_validate_pad_monitor_chain_func (gst-validate-pad-monitor.c:2009) ==23014== by 0x5A6A503: gst_pad_chain_data_unchecked (gstpad.c:4038) ==23014== by 0x5A6A503: gst_pad_push_data (gstpad.c:4271) ==23014== by 0x8CB7F8E: gst_queue_push_one (gstqueue.c:1337) ==23014== by 0x8CB7F8E: gst_queue_loop (gstqueue.c:1484) ==23014== by 0x5A98EF0: gst_task_func (gsttask.c:331) ==23014== by 0x3EBB070D67: g_thread_pool_thread_proxy (gthreadpool.c:307) ==23014== by 0x3EBB0703D4: g_thread_proxy (gthread.c:764) ==23014== by 0x3EB8807529: start_thread (pthread_create.c:310) ==23014== by 0x3EB850022C: clone (clone.S:109) I've done some digging and it looks like one of the ogg->body[i] accessed in the ogg_page_checksum_set() function is not initialized. This body array is directly computed using the ogg_stream_state we pass to ogg_stream_flush() so this may be a bug in the way gst handles this memory. og->body=os->body_data+os->body_returned; Another option could be that the computed size of this array (using the header) is wrong.
For the record, this can also be reproduced with those scenarios: validate.file.transcode.to_vorbis_and_theora_in_ogg.raw_h264_0_mp4 validate.file.transcode.to_vorbis_and_theora_in_ogg.mp3_h264_0_mp4 validate.file.transcode.to_vorbis_and_theora_in_ogg.raw_h264_0_mp4
I've been looking at this one. It looks like one part in the middle of the page payload is uninitialized on a particular page after many have gone through. However, all data that gets pushed into the ogg_stream seems properly initialized. All data is copied by libogg, so it's not gst freeing prematurely. Still looking.
That was incorrect. The input data to oggmux actually had uninitialized data. This comes from upstream, in the packet data from libtheora. And this is in a test where libtheora throws lots of other valgrind warnings in th_encode_ycbcr_in, so they're probably related. In any case, the issue seems in libtheora, and not libogg/oggmux.
Duplicate of bug #749428 then I suppose?
Possibly... Though I remember seeing the ycbcr_in issues years ago and not the other ones. I guess it makes sense to dupe it now as the other is vaguely inclusive :) *** This bug has been marked as a duplicate of bug 749428 ***