RESOLVED WORKSFORME136073
[GStreamer] crash after attempt to unlock mutex that was not locked
https://bugs.webkit.org/show_bug.cgi?id=136073
Summary [GStreamer] crash after attempt to unlock mutex that was not locked
Michael Catanzaro
Reported 2014-08-19 09:42:56 PDT
Loading http://www.vox.com/2014/8/19/6043409/a-local-public-defender-on-the-deeply-dysfunctional-ferguson-court always causes my web process to crash, after printing this warning: Attempt to unlock mutex that was not locked Here's a stack trace from a release build; I can post one from a debug build if you think that'd be helpful. #0 0x00007fa21c907c39 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 resultvar = 0 pid = 5602 selftid = 5647 #1 0x00007fa21c909348 in __GI_abort () at abort.c:89 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0x57288, sa_sigaction = 0x57288}, sa_mask = {__val = {140331614257200, 140331614268192, 140334287738662, 140333761429509, 0, 44, 140334240468288, 140331614257200, 140331614268192, 724000, 140334287765893, 44, 140334241384445, 140334244350464, 44, 0}}, sa_flags = 482920960, sa_restorer = 0x7fa21b5acdf0} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007fa21b528735 in g_mutex_unlock_slowpath (mutex=<optimized out>, prev=<optimized out>) at gthread-posix.c:1321 No locals. #3 0x00007fa21b5283ee in g_mutex_unlock (mutex=<optimized out>) at gthread-posix.c:1344 prev = <optimized out> #4 0x00007fa170b158bf in gst_hls_demux_change_playlist ( demux=demux@entry=0x7fa18004c030, max_bitrate=9343035) at gsthlsdemux.c:1673 previous_variant = 0x7fa18004eb00 current_variant = 0x7fa18004eb20 old_bandwidth = 357000 new_bandwidth = 724000 __FUNCTION__ = "gst_hls_demux_change_playlist" #5 0x00007fa170b198ad in gst_hls_demux_switch_playlist (demux=0x7fa18004c030) at gsthlsdemux.c:1755 bitrate = 11678794 #6 gst_hls_demux_stream_loop (demux=0x7fa18004c030) at gsthlsdemux.c:1249 end_of_playlist = 0 err = 0x0 __FUNCTION__ = "gst_hls_demux_stream_loop" #7 0x00007fa21825b346 in gst_task_func (task=0x80e710) at gsttask.c:317 lock = 0x7fa18004c210 tself = 0x7fa180049230 priv = 0x80e6c0 __PRETTY_FUNCTION__ = "gst_task_func" #8 0x00007fa21b50c0cc in g_thread_pool_thread_proxy (data=<optimized out>) at gthreadpool.c:307 task = 0x7fa178001fa0 pool = 0xc4e4b0 #9 0x00007fa21b50b745 in g_thread_proxy (data=0x7fa180049230) at gthread.c:764 thread = 0x7fa180049230 #10 0x00007fa21ac84f33 in start_thread (arg=0x7fa1a5ffb700) at pthread_create.c:309 __res = <optimized out> pd = 0x7fa1a5ffb700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140332251461376, -2793351388160340356, 0, 0, 140332251462080, 140332251461376, 2774021971184963196, 2772018513804643964}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> #11 0x00007fa21c9c6ded in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 No locals.
Attachments
Philippe Normand
Comment 1 2014-08-29 00:17:11 PDT
*** Bug 136074 has been marked as a duplicate of this bug. ***
Brendan Long
Comment 2 2014-08-29 10:52:45 PDT
Hm I don't get this in an Arch Linux VM either :\
Michael Catanzaro
Comment 3 2014-08-29 11:25:43 PDT
Arch would still be on glib 2.40. The strict mutex behavior is new in glib 2.42 (to be released late next month).
Philippe Normand
Comment 4 2014-11-18 08:46:19 PST
This trace is very similar to the one in Bug 138606. Shall we dupe one of these bugs?
Michael Catanzaro
Comment 5 2014-11-18 10:34:29 PST
Yeah it looks the same, though that makes me wonder if I was right to suspect glib 2.42 since if Andreas is using WebKit jhbuild, surely glib is much older.
Michael Catanzaro
Comment 6 2015-08-21 11:45:02 PDT
I do not see this anymore.
Note You need to log in before you can comment on or make changes to this bug.