Opened 13 years ago
Closed 12 years ago
#1231 closed defect (worksforme)
ffplay access violation on win64
Reported by: | ronag | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | unspecified | Keywords: | win64 |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
win64 static build (http://ffmpeg.zeranoe.com/builds/, 2012-04-16) ffplay crashes on win64 with some files, I added two samples in (ftp://upload.ffmpeg.org/incoming/intermittent_win64_ffplay_crash).
I do not have this problem with win32 static build ffplay.
Change History (13)
comment:1 by , 13 years ago
Component: | avformat → undetermined |
---|---|
Keywords: | win64 added |
comment:2 by , 13 years ago
Crash with ffmpeg -i input -f null as well.
I'll try to get debug win64 binaries to run it with. With the regular binaries gdb complains that ffmpeg.exe is "not in executable format".
comment:3 by , 13 years ago
Works fine with 32 bit ffmpeg/ffplay, and both 32 bit and 64 bit avconv/avplay.
comment:4 by , 13 years ago
I've tried to reproduce it in VS2010 using the ffmpeg libraries where I can get the w64 build to crash with the following. Not sure if it is the same with the ffmpeg/ffplay executables.
while(true) { AVFormatContext* ic = nullptr; avformat_open_input(&ic, "M:\\t.mp4", nullptr, nullptr); avformat_find_stream_info(ic, nullptr); <-- Access violation reading location 0xffffffffffffffff. avformat_close_input(&ic); Sleep(1000); }
Which crashes. It is interesting that it crashes on vmovaps, since I just recently upgraded to a Sandy Bridge cpu with AVX instructions.
avcodec-54.dll!000000006a5b7ef0() <-- Access violation reading location 0xffffffffffffffff. [Frames below may be incorrect and/or missing, no symbols loaded for avcodec-54.dll] avcodec-54.dll!000000006a5b8035() avcodec-54.dll!000000006a5b8e95() avcodec-54.dll!000000006a5b8ed5() avcodec-54.dll!000000006a5b8f15() avcodec-54.dll!000000006a5b8f55() avcodec-54.dll!000000006a5badf6() avcodec-54.dll!000000006b381fa0()
000000006A5B7EF0 vmovaps ymm2,ymmword ptr [rcx+40h] <-- Access violation reading location 0xffffffffffffffff. 000000006A5B7EF5 vmovaps ymm3,ymmword ptr [rcx+60h] 000000006A5B7EFA vsubps ymm7,ymm2,ymm3 000000006A5B7EFE vaddps ymm2,ymm2,ymm3 000000006A5B7F02 vxorps ymm7,ymm7,ymmword ptr [6ADEA300h] 000000006A5B7F0A vshufps ymm3,ymm2,ymm7,0BEh 000000006A5B7F0F vshufps ymm2,ymm2,ymm7,44h 000000006A5B7F14 vsubps ymm7,ymm2,ymm3 000000006A5B7F18 vaddps ymm2,ymm2,ymm3 000000006A5B7F1C vshufps ymm3,ymm2,ymm7,0DDh 000000006A5B7F21 vshufps ymm2,ymm2,ymm7,88h
comment:5 by , 13 years ago
Did you use a gdb version that is able to debug win64 binaries?
Please recompile FFmpeg with debug symbols enabled.
follow-up: 7 comment:6 by , 13 years ago
I use gdb which is included in the mingw installation found here, http://sourceforge.net/projects/mingw-w64/.
I cannot compile ffmpeg, a virtual linux dist does not fit on my ssd drive. I'm trying to get debug binaries through other means.
follow-up: 8 comment:7 by , 13 years ago
Replying to ronag:
I use gdb which is included in the mingw installation found here, http://sourceforge.net/projects/mingw-w64/.
I cannot compile ffmpeg
FFmpeg compilation should work out-of-the-box with mingw, do you see any problems?
comment:8 by , 13 years ago
FFmpeg compilation should work out-of-the-box with mingw, do you see any problems?
The problem is that I'm on Windows, and don't know how to compile ffmpeg.
comment:10 by , 13 years ago
I tested zeranoe fce30d8 64-bit Static and both ffmpeg and ffplay work fine for the given samples, I cannot test on AVX though.
comment:11 by , 12 years ago
Summary: | ffplay access violation → ffplay access violation on win64 |
---|
comment:12 by , 12 years ago
tested on mingw64 + wine with AVX, no crash (only ffmpeg tested, no SDL for mingw installed)
comment:13 by , 12 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
I tested on Windows 7 with AVX hardware and current Zeranoe static build: No crash
Both samples show no problems with valgrind here.
Is the crash also reproducible with ffmpeg -i input -f null - ?
Please add gdb output as explained on http://ffmpeg.org/bugreports.html (gdb works fine on Windows64), please understand that it is unlikely a crash without backtrace gets fixed.