Ticket #1212 (closed defect: fixed)
Invalid memory access with lead h263 and lowres
| Reported by: | ami_stuff | Owned by: | |
|---|---|---|---|
| Priority: | important | Component: | avcodec |
| Version: | git-master | Keywords: | lowres h263 |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | yes | |
| Analyzed by developer: | no |
Description
the crash happens after seeking a few times with the mouse
below log is from ffmpeg git-ed68fd4 (9 Apr 2012) - looks like enabling sdl outdev at the same time disables output to the console here (mingw)
(if it's libsdl's bug then maybe it's possible to workaround it somehow?)
$ gdb ffplay_g.exe
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from d:\mingw\msys\1.0\ffmpeg-head-6a052e6\ffplay_g.exe...done.
(gdb) r -vlowres 2 lead_h263.avi
Starting program: d:\mingw\msys\1.0\ffmpeg-head-6a052e6\ffplay_g.exe -vlowres 2
lead_h263.avi
[New Thread 4056.0xbe0]
[New Thread 4056.0xc0]
[New Thread 4056.0x648]
[New Thread 4056.0x7f4]
[New Thread 4056.0xa6c]
Program received signal SIGSEGV, Segmentation fault.
0x68128a6c in Color32DitherYV12Mod1X (colortab=0x44a4d48,
rgb_2_pix=0x398bf38,
lum=0x43f2bab '\020' <repeats 37 times>, "&\020+-\025#\"<\020\020! #4\032\06
0\035\061\f*+\023\005 \005 \a\037\017\n\006\n\024/5\026\022\064*\02
2\022\061+-\027\".\023#\032\034", '\020' <repeats 111 times>...,
cr=<optimized out>, cb=<optimized out>, out=0x44b7120 "", rows=120,
cols=180, mod=180) at ./src/video/SDL_yuv_sw.c:324
324 *row1++ = (rgb_2_pix[ L + cr_r ] |
(gdb) bt
#0 0x68128a6c in Color32DitherYV12Mod1X (colortab=0x44a4d48,
rgb_2_pix=0x398bf38,
lum=0x43f2bab '\020' <repeats 37 times>, "&\020+-\025#\"<\020\020! #4\032\06
0\035\061\f*+\023\005 \005 \a\037\017\n\006\n\024/5\026\022\064*\02
2\022\061+-\027\".\023#\032\034", '\020' <repeats 111 times>...,
cr=<optimized out>, cb=<optimized out>, out=0x44b7120 "", rows=120,
cols=180, mod=180) at ./src/video/SDL_yuv_sw.c:324
#1 0x68129f7c in SDL_DisplayYUV_SW (_this=0x3982338, overlay=0x3993b00,
src=0x22fd20, dst=0x22fd28) at ./src/video/SDL_yuv_sw.c:1263
#2 0x681283ec in SDL_DisplayYUVOverlay (overlay=0x3993b00, dstrect=0x22fe38)
at ./src/video/SDL_yuv.c:138
#3 0x00403530 in video_image_display (is=0x40e0040) at ffplay.c:728
#4 0x00a9cf68 in video_display (is=0x40e0040) at ffplay.c:987
#5 video_refresh (opaque=0x40e0040) at ffplay.c:1244
#6 event_loop (cur_stream=<optimized out>) at ffplay.c:2958
#7 main (argc=4, argv=0x3990df0) at ffplay.c:3241
Attachments
Change History
comment:3 Changed 13 months ago by ami_stuff
currently ffplay does not crash with -vlowres 2 anymore, but just exists without a crash (I didn't test, but it may be related to fix for ticket #38). -vlowres 3 still crashes randomly here while seeking, so maybe valgrid will show some invalid reads or something?
comment:4 Changed 13 months ago by ami_stuff
it looks like LEAD H263 text it not completly displayed with ffplay compared to original codec, I wonder if it may be the cause of crash with lowres
comment:6 Changed 13 months ago by cehoyos
- Status changed from new to open
- Reproduced by developer set
- Component changed from undetermined to avcodec
- Summary changed from ffplay: crash with lead h263 and lowres to Invalid memory access with lead h263 and lowres
- Priority changed from normal to important
- Version changed from unspecified to git-master
$ valgrind ffmpeg_g -lowres 2 -i lead_h263_ehc.avi -f null -
==8022== Memcheck, a memory error detector.
==8022== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==8022== Using LibVEX rev 1732, a library for dynamic binary translation.
==8022== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==8022== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==8022== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==8022== For more details, rerun with: -v
==8022==
ffmpeg version N-41239-g1bf22c3 Copyright (c) 2000-2012 the FFmpeg developers
built on Jun 2 2012 20:03:27 with gcc 4.3.2
configuration: --cc=/usr/local/gcc-4.3.2/bin/gcc --enable-gpl --enable-libopenjpeg --enable-libvorbis --enable-libspeex --enable-libmp3lame --enable-libtheora --extra-ldflags=-lm --enable-libvpx --enable-libxavs
libavutil 51. 56.100 / 51. 56.100
libavcodec 54. 23.100 / 54. 23.100
libavformat 54. 6.101 / 54. 6.101
libavdevice 54. 0.100 / 54. 0.100
libavfilter 2. 77.100 / 2. 77.100
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 15.100 / 0. 15.100
libpostproc 52. 0.100 / 52. 0.100
Input #0, avi, from 'lead_h263_ehc.avi':
Duration: 00:00:03.00, start: 0.000000, bitrate: 143 kb/s
Stream #0:0: Video: h263 (L263 / 0x3336324C), yuv420p, 180x120, 1 tbr, 1 tbn, 1 tbc
[buffer @ 0x46872c0] w:180 h:120 pixfmt:yuv420p tb:1/1 sar:0/1 sws_param:flags=2
[buffersink @ 0x4687ea0] No opaque field provided
Output #0, null, to 'pipe:':
Metadata:
encoder : Lavf54.6.101
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 180x120, q=2-31, 200 kb/s, 90k tbn, 1 tbc
Stream mapping:
Stream #0:0 -> #0:0 (h263 -> rawvideo)
Press [q] to stop, [?] for help
==8022== Invalid read of size 4
==8022== at 0x861D0DE: h263_h_loop_filter_mmx (dsputil_mmx.h:99)
==8022== Address 0x47E613E is 137,374 bytes inside a block of size 137,376 alloc'd
==8022== at 0x4021A50: memalign (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==8022== by 0x4021AAA: posix_memalign (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==8022== by 0x87F167F: av_mallocz (mem.c:95)
==8022==
==8022== Invalid write of size 4
==8022== at 0x861D272: h263_h_loop_filter_mmx (dsputil_mmx.c:747)
==8022== Address 0x47E613E is 137,374 bytes inside a block of size 137,376 alloc'd
==8022== at 0x4021A50: memalign (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==8022== by 0x4021AAA: posix_memalign (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==8022== by 0x87F167F: av_mallocz (mem.c:95)
==8022==
==8022== Invalid read of size 4
==8022== at 0x861D11B: h263_h_loop_filter_mmx (dsputil_mmx.h:99)
==8022== Address 0x47EAC60 is not stack'd, malloc'd or (recently) free'd
==8022==
==8022== Invalid write of size 4
==8022== at 0x861D281: h263_h_loop_filter_mmx (dsputil_mmx.c:747)
==8022== Address 0x47EAC60 is not stack'd, malloc'd or (recently) free'd
==8022==
==8022== Invalid read of size 4
==8022== at 0x861D118: h263_h_loop_filter_mmx (dsputil_mmx.h:99)
==8022== Address 0x47EAC1E is 19,038 bytes inside a block of size 19,040 alloc'd
==8022== at 0x4021A50: memalign (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==8022== by 0x4021AAA: posix_memalign (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==8022== by 0x87F15CF: av_malloc (mem.c:95)
==8022==
==8022== Invalid write of size 4
==8022== at 0x861D27D: h263_h_loop_filter_mmx (dsputil_mmx.c:747)
==8022== Address 0x47EAC1E is 19,038 bytes inside a block of size 19,040 alloc'd
==8022== at 0x4021A50: memalign (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==8022== by 0x4021AAA: posix_memalign (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==8022== by 0x87F15CF: av_malloc (mem.c:95)
Input stream #0:0 frame changed from size:180x120 fmt:yuv420p to size:180x60 fmt:yuv420p
[buffer @ 0x47f0f00] w:180 h:60 pixfmt:yuv420p tb:1/1 sar:12/11 sws_param:flags=2
[buffersink @ 0x47f1300] No opaque field provided
[scale @ 0x4737fc0] w:180 h:60 fmt:yuv420p sar:12/11 -> w:180 h:120 fmt:yuv420p sar:24/11 flags:0x4
[null @ 0x4677440] Encoder did not produce proper pts, making some up.
frame= 3 fps=0.0 q=0.0 Lsize= 0kB time=00:00:03.00 bitrate= 0.0kbits/s dup=1 drop=0
video:0kB audio:0kB global headers:0kB muxing overhead nan%
Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used)
==8022==
==8022== ERROR SUMMARY: 242 errors from 6 contexts (suppressed: 3 from 1)
==8022== malloc/free: in use at exit: 0 bytes in 0 blocks.
==8022== malloc/free: 1,758 allocs, 1,758 frees, 2,330,409 bytes allocated.
==8022== For counts of detected errors, rerun with: -v
==8022== All heap blocks were freed -- no leaks are possible.



