Adding to the list of unsucessful things:

• Compiling pthreads with GC-inline, GCE-inline, or GCE-static instead of GC-static prior to building libvpx and FFMPEG

from ffmpeg-windows-build-helpers.

is there an ffmpeg command line that fails with it?

On Thu, Feb 19, 2015 at 2:21 AM, Fabian Wickborn [email protected]
wrote:

The issue I am going to describe occurs both with the Zeranoe builds as
well as with code compiled with this script in a Debian machine for Windows
32. I also described the problem in the Zeranoe FFMPEG forum
http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=15&t=2344. Since then,
I investigated further

I am using libavcodec to encode a WebM file which works fine when using
only a single thread for libvpx, but crashes when setting the thread_count
of the encoder to a value higher than 1.

I modified doc/examples/muxing.c to reproduce the error (cleaned to
compile with MSVC2010, hardcoding the webm destination and set encoder
threads to 4): crash_example.cpp
https://github.com/fawick/ffmpeg-windows-build-helpers/blob/master/crash_example.cpp.
The call to compile it is (from a Visual Studio command prompt)

cl -I"c:\ffmpeg\include" crash_example.cpp /link /OPT:NOREF /OUT:crash_example.exe /LIBPATH:c:\ffmpeg\bin c:\ffmpeg\bin\avdevice.lib c:\ffmpeg\bin\avformat.lib c:\ffmpeg\bin\avutil.lib c:\ffmpeg\bin\avcodec.lib c:\ffmpeg\bin\avfilter.lib c:\ffmpeg\bin\swscale.lib c:\ffmpeg\bin\swresample.lib

However, f the same code file is compiled with mingw-w64 on Windows, it
works:

g++ crash_example.cpp -I/c/ffmpeg/include -L/c/ffmpeg/bin -lavformat -lavcodec -lavutil -lswscale -lswresample -o crash_example.exed

I added a lot of printf statements to ffmpeg and libvpx sourcecode and
found the root of the crash to a race condition, crashing in the following
loop (from libvpx-v1.3.0/vp8/encoder/encodeframes.c, lines 468 to 475)

while (mb_col > (*last_row_current_mb_col - nsync))
{
x86_pause_hint();
thread_sleep(0);
}

So it looks like the mingw-w64-built libraries that have pthreads
statically compiled in clash with the MSVC compiler/linker/runtime. I do
not know any way around this. What I have tried so far (unsuccessfully):

• enabling winpthreads instead of wiwhen compiling mingw-w64 on Debian
  with the Zeranoe script (3.6.6-preview).
• using the pthreads-win32 of the cross-compile-ffmpeg script
• using the latest libvpx from the git repo instead of 1.3.0
• recompiling my software with the define PTW32_STATIC_LIB

—
Reply to this email directly or view it on GitHub
#64.

from ffmpeg-windows-build-helpers.

No, not in my case at least. Normally, as the ffmpeg.exe is built with the cross compilation script (and thus by GCC) it should not be affected. I believe, the problem only occurs when linking against the livav* shared libraries from MSVC-compiled code.

MSVC2010 does not support the C99 standard and I did not go through the hassle to port it to C98. However, I reckon, that for a ffmpeg command line executable built with MSVC 2010 from ffmpeg*.c that is linked against libav*.dll which were built with MinGW-W64, the following command line will reproduce the error:

ffmpeg.exe somearbitraryvideo.mp4 -threads 4 test.webm

I cannot test whether the same would be true for later versions of the MSVC compiler.

EDIT: typos

from ffmpeg-windows-build-helpers.

if you build it all using MSVC does it blow up?

On Thu, Feb 19, 2015 at 7:15 AM, Fabian Wickborn [email protected]
wrote:

No, not in my case at least. Normally, as the ffmpeg.exe is built with the
cross compilation script (and thus by GCC) it should not be affected. I
beliebe, the problem only occurs when linking against the livav* shared
libraries from MSVC-compiled code.

MSVC2010 does not support the C99 standard and I did not go through the
hassle to port it to C98. However, I reckon, that for a ffmpeg command line
executable built with MSVC 2010 from ffmpeg_.c that is linked against
libav_.dll which were built with MinGW-W64, the following command line
will reproduce the error:

fmpeg.exe somearbitraryvideo.mp4 -threads 4 test.webm

I cannot test whether the same would be true for later versions of the
MSVC compiler.

—
Reply to this email directly or view it on GitHub
#64 (comment)
.

from ffmpeg-windows-build-helpers.

I cannot build ffmpeg w/ MSVC 2010 so I cannot answer that question, I'm afraid.

from ffmpeg-windows-build-helpers.

unfortunately it [and the conversion to C99] might be your only way
out...maybe [?] what's a gdb backtrace of a failing instance?

On Thu, Feb 19, 2015 at 12:49 PM, Fabian Wickborn [email protected]
wrote:

I cannot build ffmpeg w/ MSVC 2010 so I cannot answer that question, I'm
afraid.

—
Reply to this email directly or view it on GitHub
#64 (comment)
.

from ffmpeg-windows-build-helpers.

Not much, as the libav* are built without debug symbols. I'll try to enable debugging symbols tomorrow in the cross compilation. Is there a dedicated switch for that in your script or do I need to set it for all of pthread, lib[vpx|ogg|vorbis] and ffmpeg individually?

from ffmpeg-windows-build-helpers.

gdb was unable to get anything useful from the crash. However, CDB gave the following output:

   0  Id: 1888.1294 Suspend: 1 Teb: 7efdb000 Unfrozen
ChildEBP RetAddr  
WARNING: Stack unwind information not available. Following frames may be wrong.
00000000 00000000 avcodec_56!avpriv_split_xiph_headers+0x8cbd0

#  1  Id: 1888.980 Suspend: 1 Teb: 7efd8000 Unfrozen
ChildEBP RetAddr  
WARNING: Stack unwind information not available. Following frames may be wrong.
02a6f878 772ea181 avcodec_56!avpriv_split_xiph_headers+0x8c77a
02a6f954 5133477d ntdll32!LdrpInitializeThread+0x1f5
02a6f974 512d8cb3 avcodec_56!avpriv_split_xiph_headers+0x70bcd
02a6f984 5133ecd3 avcodec_56!avpriv_split_xiph_headers+0x15103
02a6f9a4 512dd3ab avcodec_56!avpriv_split_xiph_headers+0x7b123
02a6f9d0 77380806 avcodec_56!avpriv_split_xiph_headers+0x197fb
02a6fa00 02a6fa70 ntdll32!RtlpValidateHeap+0x20
02a6fa44 7733ac29 0x2a6fa70
77381794 90909090 ntdll32!RtlpFreeHeap+0x5d
773817a0 ccb0ffdc 0x90909090
773817a4 e8000000 0xccb0ffdc
773817a8 fff50ad0 0xe8000000
773817ac 909090c3 0xfff50ad0
773817b0 106a9090 0x909090c3
773817b4 2dd0d868 0x106a9090
773817b8 c722e877 0x2dd0d868
773817bc 758bfff5 0xc722e877
773817c0 08758908 0x758bfff5
773817c4 00e745c6 0x8758908
773817c8 00e645c6 0xe745c6
773817cc 004446f7 0xe645c6
773817d0 74010000 0x4446f7
773817d4 1875ff17 0x74010000
773817d8 ff1475ff 0x1875ff17
773817dc 75ff1075 0xff1475ff
773817e0 49e8560c 0x75ff1075
773817e4 e9ffffce 0x49e8560c
773817e8 00000000 0xe9ffffce

   2  Id: 1888.185c Suspend: 1 Teb: 7efd5000 Unfrozen
ChildEBP RetAddr  
WARNING: Stack unwind information not available. Following frames may be wrong.
02b8fa28 75daa53a avcodec_56!avpriv_split_xiph_headers+0x7d733
02b8fa3c 75db1287 msvcrt!_getptd_noexit+0x62
02b8fa74 75db1328 msvcrt!_endthreadex+0x44
02b8fa7c 7663338a msvcrt!_endthreadex+0xce
02b8fa88 772e9f72 kernel32!BaseThreadInitThunk+0xe
02b8fac8 772e9f45 ntdll32!__RtlUserThreadStart+0x70
02b8fae0 00000000 ntdll32!_RtlUserThreadStart+0x1b

   3  Id: 1888.8c4 Suspend: 1 Teb: 7efad000 Unfrozen
ChildEBP RetAddr  
02d7fc40 74de3bd5 ntdll32!NtDelayExecution+0x15
02d7fca8 74de44a5 KERNELBASE!SleepEx+0x65
02d7fcb8 513412f0 KERNELBASE!Sleep+0xf
WARNING: Stack unwind information not available. Following frames may be wrong.
02d7fd44 75daa53a avcodec_56!avpriv_split_xiph_headers+0x7d740
02d7fd58 75db1287 msvcrt!_getptd_noexit+0x62
02d7fd90 75db1328 msvcrt!_endthreadex+0x44
02d7fd98 7663338a msvcrt!_endthreadex+0xce
02d7fda4 772e9f72 kernel32!BaseThreadInitThunk+0xe
02d7fde4 772e9f45 ntdll32!__RtlUserThreadStart+0x70
02d7fdfc 00000000 ntdll32!_RtlUserThreadStart+0x1b

   4  Id: 1888.180c Suspend: 1 Teb: 7efaa000 Unfrozen
ChildEBP RetAddr  
02eafa3c 74de14ab ntdll32!NtWaitForSingleObject+0x15
02eafaa8 76631194 KERNELBASE!WaitForSingleObjectEx+0x98
02eafac0 76631148 kernel32!WaitForSingleObjectExImplementation+0x75
02eafad4 51341083 kernel32!WaitForSingleObject+0x12
WARNING: Stack unwind information not available. Following frames may be wrong.
02eafb2c 75db1328 avcodec_56!avpriv_split_xiph_headers+0x7d4d3
02eafb34 7663338a msvcrt!_endthreadex+0xce
02eafb40 772e9f72 kernel32!BaseThreadInitThunk+0xe
02eafb80 772e9f45 ntdll32!__RtlUserThreadStart+0x70
02eafb98 00000000 ntdll32!_RtlUserThreadStart+0x1b

from ffmpeg-windows-build-helpers.

are you using any codecs from xiph? http://xiph.org/
did you use gdb with ffmpeg_g.exe?

On Fri, Feb 20, 2015 at 4:21 AM, Fabian Wickborn [email protected]
wrote:

gdb was unable to get anything useful from the crash. However, CDB gave
the following output:

0 Id: 1888.1294 Suspend: 1 Teb: 7efdb000 Unfrozen
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
00000000 00000000 avcodec_56!avpriv_split_xiph_headers+0x8cbd0

1 Id: 1888.980 Suspend: 1 Teb: 7efd8000 Unfrozen

ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
02a6f878 772ea181 avcodec_56!avpriv_split_xiph_headers+0x8c77a
02a6f954 5133477d ntdll32!LdrpInitializeThread+0x1f5
02a6f974 512d8cb3 avcodec_56!avpriv_split_xiph_headers+0x70bcd
02a6f984 5133ecd3 avcodec_56!avpriv_split_xiph_headers+0x15103
02a6f9a4 512dd3ab avcodec_56!avpriv_split_xiph_headers+0x7b123
02a6f9d0 77380806 avcodec_56!avpriv_split_xiph_headers+0x197fb
02a6fa00 02a6fa70 ntdll32!RtlpValidateHeap+0x20
02a6fa44 7733ac29 0x2a6fa70
77381794 90909090 ntdll32!RtlpFreeHeap+0x5d
773817a0 ccb0ffdc 0x90909090
773817a4 e8000000 0xccb0ffdc
773817a8 fff50ad0 0xe8000000
773817ac 909090c3 0xfff50ad0
773817b0 106a9090 0x909090c3
773817b4 2dd0d868 0x106a9090
773817b8 c722e877 0x2dd0d868
773817bc 758bfff5 0xc722e877
773817c0 08758908 0x758bfff5
773817c4 00e745c6 0x8758908
773817c8 00e645c6 0xe745c6
773817cc 004446f7 0xe645c6
773817d0 74010000 0x4446f7
773817d4 1875ff17 0x74010000
773817d8 ff1475ff 0x1875ff17
773817dc 75ff1075 0xff1475ff
773817e0 49e8560c 0x75ff1075
773817e4 e9ffffce 0x49e8560c
773817e8 00000000 0xe9ffffce

2 Id: 1888.185c Suspend: 1 Teb: 7efd5000 Unfrozen
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
02b8fa28 75daa53a avcodec_56!avpriv_split_xiph_headers+0x7d733
02b8fa3c 75db1287 msvcrt!_getptd_noexit+0x62
02b8fa74 75db1328 msvcrt!_endthreadex+0x44
02b8fa7c 7663338a msvcrt!_endthreadex+0xce
02b8fa88 772e9f72 kernel32!BaseThreadInitThunk+0xe
02b8fac8 772e9f45 ntdll32!__RtlUserThreadStart+0x70
02b8fae0 00000000 ntdll32!_RtlUserThreadStart+0x1b

3 Id: 1888.8c4 Suspend: 1 Teb: 7efad000 Unfrozen
ChildEBP RetAddr
02d7fc40 74de3bd5 ntdll32!NtDelayExecution+0x15
02d7fca8 74de44a5 KERNELBASE!SleepEx+0x65
02d7fcb8 513412f0 KERNELBASE!Sleep+0xf
WARNING: Stack unwind information not available. Following frames may be wrong.
02d7fd44 75daa53a avcodec_56!avpriv_split_xiph_headers+0x7d740
02d7fd58 75db1287 msvcrt!_getptd_noexit+0x62
02d7fd90 75db1328 msvcrt!_endthreadex+0x44
02d7fd98 7663338a msvcrt!_endthreadex+0xce
02d7fda4 772e9f72 kernel32!BaseThreadInitThunk+0xe
02d7fde4 772e9f45 ntdll32!__RtlUserThreadStart+0x70
02d7fdfc 00000000 ntdll32!_RtlUserThreadStart+0x1b

4 Id: 1888.180c Suspend: 1 Teb: 7efaa000 Unfrozen
ChildEBP RetAddr
02eafa3c 74de14ab ntdll32!NtWaitForSingleObject+0x15
02eafaa8 76631194 KERNELBASE!WaitForSingleObjectEx+0x98
02eafac0 76631148 kernel32!WaitForSingleObjectExImplementation+0x75
02eafad4 51341083 kernel32!WaitForSingleObject+0x12
WARNING: Stack unwind information not available. Following frames may be wrong.
02eafb2c 75db1328 avcodec_56!avpriv_split_xiph_headers+0x7d4d3
02eafb34 7663338a msvcrt!_endthreadex+0xce
02eafb40 772e9f72 kernel32!BaseThreadInitThunk+0xe
02eafb80 772e9f45 ntdll32!__RtlUserThreadStart+0x70
02eafb98 00000000 ntdll32!_RtlUserThreadStart+0x1b

—
Reply to this email directly or view it on GitHub
#64 (comment)
.

from ffmpeg-windows-build-helpers.

closing no feedback [?] feel free to reopen it here...

from ffmpeg-windows-build-helpers.