[marcuscom-devel] cvs commit: ports/x11/gnome-shell/files patch-js_ui_extensionSystem.js
Gustau Pérez i Querol
gustau.perez at gmail.com
Thu Jun 28 12:27:06 EDT 2012
> The bug was just fixed upstream. The problem was not in how the mutex
> unlock code was written, but rather how it was called in one module
> within gio. The lock was being unlocked from a different thread.
> FreeBSD doesn't allow this. Linux wouldn't either if an error check
> mutex was used.
> We will incorporate the fix, and these problems should go away.
Thanks for the heads up.
However I fear the patch would only fix the tls-interaction test.
The patch addresses the mutex unlock problem. However gjs still crashes
because of clutter trying to unlock a mutex.
Taking a bt from gjs I see this:
#0 0x00000008035d5e1c in thr_kill () from /lib/libc.so.7
#1 0x000000080368485b in abort () from /lib/libc.so.7
#2 0x0000000801d716ae in g_thread_abort (status=Could not find the
frame base for "g_thread_abort".
) at gthread-posix.c:76
#3 0x0000000801d71855 in g_mutex_unlock (mutex=0x805723de8)
#4 0x000000080548b3c6 in clutter_main ()
#5 0x0000000801ac2c98 in ffi_call_unix64 () from /usr/local/lib/libffi.so.5
#6 0x0000000801ac2b3f in ffi_call (cif=0x80bb50418,
fn=0x80548b330 <clutter_main>, rvalue=0x7fffffffd050,
avalue=0x7fffffffcd70) at src/x86/ffi64.c:484
#7 0x000000080083def0 in gjs_callback_trampoline_new ()
#8 0x000000080083e802 in gjs_invoke_c_function_uncached ()
#9 0x0000000802824fc6 in js::Invoke () from /usr/local/lib/libmozjs185.so.1
#10 0x00000008028072dc in js::Interpret () from
#11 0x0000000802824958 in js::RunScript () from
#12 0x00000008028265d4 in js::Execute () from
#13 0x00000008027919d4 in EvaluateUCScriptForPrincipalsCommon ()
#14 0x0000000802791a77 in JS_EvaluateUCScriptForPrincipals ()
---Type <return> to continue, or q <return> to quit---
#15 0x0000000802791b02 in JS_EvaluateUCScript ()
#16 0x000000080082c5be in gjs_context_eval () from
#17 0x0000000000401039 in main ()
According to this, clutter seems to unlock a mutex owned by another
the thread, triggering the problem again. Compiling clutter would
provide more info. I'll try to dig deeper.
More information about the marcuscom-devel