GNOME Bugzilla – Bug 706584
GESVideoTestSource produces race condition in recent Windows threading
Last modified: 2015-09-23 17:05:21 UTC
Created attachment 252741 [details] Minimal c example where the crash occurs GES crashes in gthread-win32.c shortly after the main loop is started. The crash only occurs when following conditions are met: * The timeline is committed ges_timeline_commit (timeline); * An asset is added to the layer, so the demo actually plays something ges_layer_add_asset (layer, src_asset, 0, 0, GST_SECOND, GES_TRACK_TYPE_UNKNOWN); * The state is set to playing and the main loop is started gst_element_set_state (GST_ELEMENT (pipeline), GST_STATE_PLAYING); g_main_loop_run (mainloop); The crash also occurs in the basic test, but in no other test. This is interesting. Isn't the commit used in the other tests? Using current git master branches of gstreamer, plugins, libav, gnonlin and ges.
Created attachment 252744 [details] GDB backtrace in glib
Created attachment 252745 [details] GST_DEBUG=ges*:5 log
Created attachment 252746 [details] GST_DEBUG=4 log
Created attachment 252760 [details] Log with the crash and GST_DEBUG=5 When GST_DEBUG=5 is used, the crash only occurs sometimes (~1/4 times) and the directx sink is opened correctly and the video is played with sound. I append the GST_DEBUG=5 logs for both events.
Created attachment 252761 [details] Log without the crash because of GST_DEBUG=5
Created attachment 257984 [details] Better stack trace with Dr. MinGW I was able to get a better stacktrace with Dr. MinGW, a debugger for MinGW. It involves gstbasesrc, gstpad, gstobject and gstbasetransform.
The problem does not occur when ges_track_commit is not executed. In there it does not occur when following line is executed: g_signal_emit_by_name (track->priv->composition, "commit", TRUE, &ret); So the segaulft is caused by gnlcomposition's gnl_composition_commit_func and not GES.
Created attachment 258063 [details] [review] gnonlin patch that fixes the crash The crash does not occur when the stop duration is not updated in the GnlComposition. Rendering of the of my test takes ~1.38s without the stop update. With the value updated it takes only ~0.50s and crashes in 1/5 times. Commenting out gnlcomposition.c(2050) in update_start_stop_duration prevents the later crash: cobj->stop = obj->stop;
The stack trace I was able to achieve with the dll method of Dr. MinGW c:\Users\bmonkey\cerbero\dist\windows_x86\bin\ges-minimal.exe caused an Unknown [0xC0000264] Exception at location 7784334F in module C:\Windows\SysWOW64\ntdll.dll. Registers: eax=074a506c ebx=074a4fb0 ecx=00000000 edx=00471f28 esi=fffffffe edi=00000000 eip=7784334f esp=0b4cfd98 ebp=0b4cfd98 iopl=0 nv up ei pl zr na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 AddrPC Params 7784334F 074A506C 0A1C8F20 0B4CFE28 ntdll.dll!RtlUlonglongByteSwap 68631900 074A506C 074A4FB0 0B4CFE28 libglib-2.0-0.dll!g_mutex_unlock [c:\Users\bmonkey\cerbero\sources\windows_x86\glib-2.38.1\glib/gthread-win32.c @ 152] 6B5E7011 074A4FB8 00000050 0B4CFE28 libgstbase-1.0-0.dll!gst_base_src_loop [c:\Users\bmonkey\cerbero\sources\windows_x86\gstreamer-git-None\libs\gst\base/gstbasesrc.c @ 2819] 63A4A741 0A1BC1F8 00000000 00000008 libgobject-2.0-0.dll!g_object_unref [c:\Users\bmonkey\cerbero\sources\windows_x86\glib-2.38.1\gobject/gobject.c @ 3105] 68631AA6 0A1B67E8 0741D5C8 0A1B67E8 libglib-2.0-0.dll!g_rec_mutex_lock [c:\Users\bmonkey\cerbero\sources\windows_x86\glib-2.38.1\glib/gthread-win32.c @ 206] 614AC9E8 0A1CA0D8 00425058 00000000 libgstreamer-1.0-0.dll!gst_task_func [c:\Users\bmonkey\cerbero\sources\windows_x86\gstreamer-git-None\gst/gsttask.c @ 293] 68616BD7 0B4CFF94 755233AA 072E2180 libglib-2.0-0.dll!g_thread_pool_thread_proxy [c:\Users\bmonkey\cerbero\sources\windows_x86\glib-2.38.1\glib/gthreadpool.c @ 310] 74F31328 072E2180 0B4CFFD4 777F9F72 msvcrt.dll!_endthreadex 755233AA 072E2180 75C9E2D7 00000000 kernel32.dll!BaseThreadInitThunk 777F9F72 74F312E5 072E2180 00000000 ntdll.dll!RtlInitializeExceptionChain 777F9F45 74F312E5 072E2180 00000000 ntdll.dll!RtlInitializeExceptionChain I also noticed following output during the configuration of glib checking for platform-dependent source... gwin32.lo checking whether to compile timeloop... no checking if building for some Win32 platform... yes checking for thread implementation... win32 configure: WARNING: I can't find the MACRO to enable thread safety on your platform (normally it's _REENTRANT). I'll not use any flag on compilation now, but then your programs might not work. Please provide information on how it is done on your system. checking thread related cflags... checking thread related libraries... checking for localtime_r... no checking for gmtime_r... (cached) no configure: WARNING: the 'g_get_(user_name|real_name|home_dir|tmp_dir)' functions will not be MT-safe during their first call because there is no working 'getpwuid_r' on your system. configure: WARNING: the 'g_date_set_time' function will not be MT-safe because there is no 'localtime_r' on your system.
*** Bug 711107 has been marked as a duplicate of this bug. ***
The patch was reported to work in bug #711107
The crash occurs only on recent ntdll.dll versions (I like how there is 2 times dll in this filename). It does not occur on unpatched Windows 7. On Windows 8.1 it does not crash but freeze. I rebuild everything with recent GStreamer 1.2.1 on Windows 8.1 with 64bit MinGW and it is gone. Only the VideoTestSrc seems to produce it (so the example from this bug still produces it), but other things seem to work better.
Does that still happen?
No answer and afaik it works now, Closing