After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 706584 - GESVideoTestSource produces race condition in recent Windows threading
GESVideoTestSource produces race condition in recent Windows threading
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-editing-services
git master
Other Windows
: Normal critical
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 711107 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-08-22 13:41 UTC by Lubosz Sarnecki
Modified: 2015-09-23 17:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Minimal c example where the crash occurs (788 bytes, text/plain)
2013-08-22 13:41 UTC, Lubosz Sarnecki
  Details
GDB backtrace in glib (1.52 KB, application/octet-stream)
2013-08-22 13:45 UTC, Lubosz Sarnecki
  Details
GST_DEBUG=ges*:5 log (60.58 KB, application/octet-stream)
2013-08-22 13:45 UTC, Lubosz Sarnecki
  Details
GST_DEBUG=4 log (233.90 KB, application/octet-stream)
2013-08-22 13:46 UTC, Lubosz Sarnecki
  Details
Log with the crash and GST_DEBUG=5 (578.81 KB, application/x-compressed)
2013-08-22 14:33 UTC, Lubosz Sarnecki
  Details
Log without the crash because of GST_DEBUG=5 (1.30 MB, application/x-compressed)
2013-08-22 14:34 UTC, Lubosz Sarnecki
  Details
Better stack trace with Dr. MinGW (21.57 KB, text/plain)
2013-10-24 03:57 UTC, Lubosz Sarnecki
  Details
gnonlin patch that fixes the crash (607 bytes, patch)
2013-10-24 22:43 UTC, Lubosz Sarnecki
none Details | Review

Description Lubosz Sarnecki 2013-08-22 13:41:56 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.
Comment 1 Lubosz Sarnecki 2013-08-22 13:45:10 UTC
Created attachment 252744 [details]
GDB backtrace in glib
Comment 2 Lubosz Sarnecki 2013-08-22 13:45:42 UTC
Created attachment 252745 [details]
GST_DEBUG=ges*:5 log
Comment 3 Lubosz Sarnecki 2013-08-22 13:46:08 UTC
Created attachment 252746 [details]
GST_DEBUG=4 log
Comment 4 Lubosz Sarnecki 2013-08-22 14:33:57 UTC
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.
Comment 5 Lubosz Sarnecki 2013-08-22 14:34:37 UTC
Created attachment 252761 [details]
Log without the crash because of GST_DEBUG=5
Comment 6 Lubosz Sarnecki 2013-10-24 03:57:03 UTC
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.
Comment 7 Lubosz Sarnecki 2013-10-24 04:56:54 UTC
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.
Comment 8 Lubosz Sarnecki 2013-10-24 22:43:07 UTC
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;
Comment 9 Lubosz Sarnecki 2013-10-25 03:43:26 UTC
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.
Comment 10 Sebastian Dröge (slomo) 2013-11-04 17:23:45 UTC
*** Bug 711107 has been marked as a duplicate of this bug. ***
Comment 11 Sebastian Dröge (slomo) 2013-11-04 17:24:10 UTC
The patch was reported to work in bug #711107
Comment 12 Lubosz Sarnecki 2013-12-01 15:46:02 UTC
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.
Comment 13 Thibault Saunier 2014-10-27 08:25:56 UTC
Does that still happen?
Comment 14 Thibault Saunier 2015-09-23 17:05:21 UTC
No answer and afaik it works now, Closing