GNOME Bugzilla – Bug 117561
GTK programs crash when run with accessibility
Last modified: 2004-12-22 21:47:04 UTC
I have set GTK_MODULES to "gail:atk-bridge" and if I run a GTK program, e.g. gtk-demo it crashes gtk-demo GTK Accessibility Module initialized ** ERROR **: file linc-connection.c: line 523: assertion failed: (CNX_IS_LOCKED (0)) aborting... Abort (core dumped) It seems that a mutex is not reported locked when it should be. This program is a multithreaded program.
This seems to be caused by g_assert() calls which are in linc2 code in ORBit2 but where not in linc code.
Created attachment 18345 [details] [review] Proposed patch
Well - the real question is - how can it possibly be that the lock isn't held when the assert is fired. I guess the program is doing something sufficiently daft that the assert is intended to blow. The regression tests are multi-threaded programs, and they all pass, particularly in threaded mode. So - something odd is going on; what happens if you do: thread apply all backtrace and paste me the traces ?
The first oddness is that these programs are not multithreaded. libgthread is loaded only when the GTK modules are loaded and libthread is not loaded at all. It seems to be picking up the functions mutex_lock and mutex_trylock from libc. If using libc mutex_trylock returns 0 after mutex_lock is called. If using libthread mutex_lock returns a nonzero value after mutex_lock is called.
Bug 113020 looks like it may be a duplicate of this bug, but I'm not sure. Could someone check?
I do not believe that this is a dup[licate of 113020.
Well; this is most odd. Assuming then that it is the case where threads are not initialized yet that causes this grief; it would be interesting to see who/how the ORB was initialized - and indeed, why we don't see this in our regression tests at all [ very odd indeed (!) ]. Can you catch this in the debugger and dump: link_is_thread_safe check the value of the 'lock' pointer being passed in (presumably non NULL) ? Can you also assert that g_thread_supported() in the lock != NULL case ? and see if adding: "if (!g_thread_supported()) return TRUE;" helps the situation ? Another thing may be that we need to compile the gtk+-demo with -pthread or somesuch [ which would be a nasty pain ] - I'm not sure.
OK; this patch I'm guessing will make it work for you: Index: linc2/src/linc.c =================================================================== RCS file: /cvs/gnome/ORBit2/linc2/src/linc.c,v retrieving revision 1.45 diff -u -p -u -r1.45 linc.c --- linc2/src/linc.c 14 Jul 2003 15:03:44 -0000 1.45 +++ linc2/src/linc.c 29 Jul 2003 15:17:37 -0000 @@ -284,9 +284,14 @@ link_main_get_context (void) return link_context; } +/* + * This method is unreliable, and for use + * only for debugging. + */ gboolean link_mutex_is_locked (GMutex *lock) { +#ifdef __GLIBC__ gboolean result = TRUE; if (lock && g_mutex_trylock (lock)) { @@ -295,6 +300,18 @@ link_mutex_is_locked (GMutex *lock) } return result; +#else + /* + * On at least Solaris & BSD if we link our + * app without -lthread, and pull in ORBit2 + * with threading enabled, we get NOP pthread + * operations. This is fine mostly, but we get + * bogus return values from trylock which screws + * our debugging. + */ + d_printf ("hosed system is_lock-ing"); + return TRUE; +#endif } void it's in HEAD.