[Libav-user] Possible infinite loop in libavcodec/h264.c
DSchere at skylinenet.net
DSchere at skylinenet.net
Mon Jan 21 14:15:11 CET 2013
Hello,
I am tracking down a memory leak in vlc where within a matter of seconds vlc consumes over 14G of memory, the problem is intermittent.
I think that the problem may be an infinite loop in libavcodec/h264.c at around line 1894 inside a while loop that allocates frames:
if(h0->current_slice == 0){
while(h->frame_num != h->prev_frame_num &&
h->frame_num != (h->prev_frame_num+1)%(1<<h->sps.log2_max_frame_num)){
Picture *prev = h->short_ref_count ? h->short_ref[0] : NULL;
av_log(h->s.avctx, AV_LOG_DEBUG, "Frame num gap %d %d\n", h->frame_num, h->prev_frame_num);
if (ff_h264_frame_start(h) < 0)
return -1;
h->prev_frame_num++;
h->prev_frame_num %= 1<<h->sps.log2_max_frame_num;
s->current_picture_ptr->frame_num= h->prev_frame_num;
ff_generate_sliding_window_mmcos(h);
ff_h264_execute_ref_pic_marking(h, h->mmco, h->mmco_index);
/* Error concealment: if a ref is missing, copy the previous ref in its place.
* FIXME: avoiding a memcpy would be nice, but ref handling makes many assumptions
* about there being no actual duplicates.
* FIXME: this doesn't copy padding for out-of-frame motion vectors. Given we're
* concealing a lost frame, this probably isn't noticable by comparison, but it should
* be fixed. */
if (h->short_ref_count) {
if (prev) {
av_image_copy(h->short_ref[0]->data, h->short_ref[0]->linesize,
(const uint8_t**)prev->data, prev->linesize,
s->avctx->pix_fmt, s->mb_width*16, s->mb_height*16);
h->short_ref[0]->poc = prev->poc+2;
}
h->short_ref[0]->frame_num = h->prev_frame_num;
}
}
What I did was created some diagnostic code which tracked the pointers from p_picture structures allocated from within VLC per thread. If the number of pictures allocated over one second exceeded a threshold (100 pictures) a flag was set that would raise an exception on the next allocation, this would in turn force a stack trace in gdb:
(gdb)
(gdb) where
#0 0x00007ffff69e9a75 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff69ed5c0 in *__GI_abort () at abort.c:92
#2 0x00007ffff69e2941 in *__GI___assert_fail (assertion=0x7ffff6286c50 "p->i_owner_tid != AllocTidTrap",
file=<value optimized out>, line=893, function=0x7ffff6286cf0 "onPictAlloc") at assert.c:81
#3 0x00007ffff6214f38 in onPictAlloc (p=0x7ffff0304a30) at video_output/vout_pictures.c:893
#4 0x00007ffff6215287 in picture_NewFromResource (p_fmt=0x10a87e8, p_resource=0x0) at video_output/vout_pictures.c:983
#5 0x00007ffff62152bc in picture_NewFromFormat (p_fmt=0x10a87e8) at video_output/vout_pictures.c:992
#6 0x00007ffff41ceb4b in video_new_buffer_decoder (p_dec=0x10a85d8) at video.c:101
#7 0x00007ffff61dcbb4 in decoder_NewPicture (p_decoder=0x10a85d8) at input/decoder.c:187
#8 0x00007fffe345e47c in ffmpeg_NewPictBuf (p_dec=0x10a85d8, p_context=0xc699c0) at video.c:185
#9 0x00007fffe345ff03 in ffmpeg_GetFrameBuf (p_context=0xc699c0, p_ff_pic=0xc38730) at video.c:972
#10 0x00007fffe2988bc2 in alloc_frame_buffer (s=0x1899a080, pic=0xc38730) at libavcodec/mpegvideo.c:230
#11 0x00007fffe2988dd4 in ff_alloc_picture (s=0x1899a080, pic=0xc38730, shared=0) at libavcodec/mpegvideo.c:272
#12 0x00007fffe298c6e1 in MPV_frame_start (s=0x1899a080, avctx=0xc699c0) at libavcodec/mpegvideo.c:962
#13 0x00007fffe2866167 in ff_h264_frame_start (h=0x1899a080) at libavcodec/h264.c:920
#14 0x00007fffe286a4eb in decode_slice_header (h=0x1899a080, h0=0x1899a080) at libavcodec/h264.c:1897
#15 0x00007fffe286ec48 in decode_nal_units (h=0x1899a080, buf=0x56492e0 "", buf_size=5227) at libavcodec/h264.c:2849
#16 0x00007fffe286f3d0 in decode_frame (avctx=0xc699c0, data=0x245c060, data_size=0x7ffff412db70, avpkt=0x7ffff412daf0)
at libavcodec/h264.c:3016
#17 0x00007fffe2a5741b in avcodec_decode_video2 (avctx=0xc699c0, picture=0x245c060, got_picture_ptr=0x7ffff412db70,
avpkt=0x7ffff412daf0) at libavcodec/utils.c:667
#18 0x00007fffe345f237 in DecodeVideo (p_dec=0x10a85d8, pp_block=0x7ffff412dbb8) at video.c:560
#19 0x00007ffff41d108d in transcode_video_process (p_stream=0xc1fec8, id=0xef0290, in=0x5649270, out=0x7ffff412dcf0) at video.c:622
#20 0x00007ffff41cc0a9 in Send (p_stream=0xc1fec8, id=0xef0290, p_buffer=0x5649270) at transcode.c:712
#21 0x00007ffff6265149 in sout_InputSendBuffer (p_input=0x155b9180, p_buffer=0x5649270) at stream_output/stream_output.c:283
#22 0x00007ffff61e0454 in DecoderPlaySout (p_dec=0xc65318, p_sout_block=0x5649270, b_telx=false) at input/decoder.c:1660
#23 0x00007ffff61e088e in DecoderProcessSout (p_dec=0xc65318, p_block=0x7ffff00042e0) at input/decoder.c:1784
#24 0x00007ffff61e0f78 in DecoderProcess (p_dec=0xc65318, p_block=0x7ffff00042e0) at input/decoder.c:1984
#25 0x00007ffff61de73c in DecoderThread (p_this=0xc65318) at input/decoder.c:892
#26 0x00007ffff6244a89 in thread_entry (data=0xeecc650) at misc/threads.c:58
#27 0x00007ffff7bc69ca in start_thread (arg=<value optimized out>) at pthread_create.c:300
#28 0x00007ffff6a9f16d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#29 0x0000000000000000 in ?? ()
The version of my Linux kernel does not support per thread memory statistics so this was the only way I could hunt down the leak.
Any suggestions on a work around? Since I am not familiar with the code I think the best thing I can do in the meantime is setup a counter inside this wile loop in h264.c and if the count exceeds over 100 exit with an error and have VLC stop and start the stream.
[cid:image001.jpg at 01CDF7AD.DC674250]
David Schere
Software Developer
508 - F McCormick Dr.
410.553.2600 x2040 (Office)
410.608.2618 (Cell)
"No Limits"
http://www.skylinenolimits.com<http://www.skylinenolimits.com/>
"Skyline Network Engineering, LLC is now Skyline Technology Solutions"
A member of the[cid:image002.jpg at 01CDF7AD.DC674250]
P Please don't print this e-mail unless you really need to!
CONFIDENTIALITY NOTICE: The information contained in this electronic message is confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this electronic message to the intended recipient, you are hereby notified that any dissemination or copying of this communication is strictly prohibited. If this message contains non-public personal information about any consumer or customer of the sender or intended recipient, you are further prohibited under penalty of law from using or disclosing the information to any third party by provisions of the federal Gramm-Leach-Bliley Act. If you have received this electronic message in error, please immediately notify us by telephone and return or destroy the original message to assure that it is not read, copied, or distributed by others.
________________________________
CONFIDENTIALITY NOTICE: The information contained in this electronic message is confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this electronic message to the intended recipient, you are hereby notified that any dissemination or copying of this communication is strictly prohibited. If this message contains non-public personal information about any consumer or customer of the sender or intended recipient, you are further prohibited under penalty of law from using or disclosing the information to any third party by provisions of the federal Gramm-Leach-Bliley Act. If you have received this electronic message in error, please immediately notify us by telephone and return or destroy the original message to assure that it is not read, copied, or distributed by others.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20130121/a50e04f7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2209 bytes
Desc: image001.jpg
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20130121/a50e04f7/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 2443 bytes
Desc: image002.jpg
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20130121/a50e04f7/attachment-0001.jpg>
More information about the Libav-user
mailing list