GNOME Bugzilla – Bug 498995
gthumb gets it's locking wrong and crashes
Last modified: 2007-11-28 20:15:09 UTC
If you are running OpenSolaris you can set your environment to do locking error detection. If an error is detected, a message is written to stderr and the application is terminated with a core dump. Something like: $ export LIBTHREAD_ERROR_DETECTION=2 $ gthumb *** _THREAD_ERROR_DETECTION: lock usage error detected *** mutex_unlock(0x8143430): calling thread does not own the lock calling thread is 0xfea62a00 thread-id 1 the lock is unowned Abort (core dumped) $ pstack ./core core 'core' of 16545: gthumb-2.10.7/src/. ----------------- lwp# 1 / thread# 1 -------------------- feef3307 _lwp_kill (80474f0) + 7 feedd7c8 lock_error (81a1dc8, fef71c60, 0, 0) + 431 feee89a5 mutex_unlock_internal (81a1dc8, 0) + 245 feee8bab mutex_unlock (81a1dc8) + 1fb fec4e6e6 gdk_threads_impl_unlock (80479ac, fcfe9f78, 818c930, feffcb78, 1f10, 80af836) + 36 fe77a9b9 gtk_main (80478e4, feffa7d8, feffa7d8, 80478e4, 80479ac, 804791c) + a9 080af836 main (1, 8047928, 8047930) + 116 08074e6a _start (1, 8047a14, 0, 8047a66, 8047ae6, 8047af8) + 7a ----------------- lwp# 2 / thread# 2 -------------------- feeef61b __lwp_park (83e1800, 83cac10, 0) + b feee9736 cond_wait_queue (83e1800, 83cac10, 0, 0) + 41 feee9ac4 cond_wait_common (83e1800, 83cac10, 0) + 1e1 feee9c2c _cond_wait (83e1800, 83cac10) + 7b feee9c58 cond_wait (83e1800, 83cac10) + 24 feee9c92 pthread_cond_wait (83e1800, 83cac10) + 1e fedda9dd load_image_thread (83e1280) + 79 febb8da6 g_thread_create_proxy (83d7650) + 11a feeef382 _thr_setup (fa9f0a00) + 52 feeef5e0 _lwp_start (fa9f0a00, 0, 0, 0, 0, 0) ----------------- lwp# 3 / thread# 3 -------------------- feeef61b __lwp_park (83f6e60, 83fb150, 0) + b feee9736 cond_wait_queue (83f6e60, 83fb150, 0, 0) + 41 feee9ac4 cond_wait_common (83f6e60, 83fb150, 0) + 1e1 feee9c2c _cond_wait (83f6e60, 83fb150) + 7b feee9c58 cond_wait (83f6e60, 83fb150) + 24 feee9c92 pthread_cond_wait (83f6e60, 83fb150) + 1e fedda9dd load_image_thread (83fa4c0) + 79 febb8da6 g_thread_create_proxy (83f4410) + 11a feeef382 _thr_setup (fa9f1200) + 52 feeef5e0 _lwp_start (fa9f1200, 0, 0, 0, 0, 0) ----------------- lwp# 4 / thread# 4 -------------------- feeef61b __lwp_park (8441670, 81c5fb8, f61dde88) + b feee9736 cond_wait_queue (8441670, 81c5fb8, f61dde88, 0) + 41 feee9ac4 cond_wait_common (8441670, 81c5fb8, f61dde88) + 1e1 feee9cea _cond_timedwait (8441670, 81c5fb8, f61ddf08) + 4a feee9d79 cond_timedwait (8441670, 81c5fb8, f61ddf08) + 27 feee9db6 pthread_cond_timedwait (8441670, 81c5fb8, f61ddf08) + 21 fe20190e g_cond_timed_wait_posix_impl (8441670, 81c5fb8, f61ddf88) + 5a feb7977f g_async_queue_pop_intern_unlocked (81c5f98, 0, f61ddf88) + 8b feb79c56 g_async_queue_timed_pop_unlocked (81c5f98, f61ddf88) + 36 febba1f7 g_thread_pool_thread_proxy (81c68c0) + 8b febb8da6 g_thread_create_proxy (843aba8) + 11a feeef382 _thr_setup (fa9f1a00) + 52 feeef5e0 _lwp_start (fa9f1a00, 0, 0, 0, 0, 0) ----------------- lwp# 5 / thread# 5 -------------------- feeef61b __lwp_park (8441670, 81c5fb8, f60dde88) + b feee9736 cond_wait_queue (8441670, 81c5fb8, f60dde88, 0) + 41 feee9ac4 cond_wait_common (8441670, 81c5fb8, f60dde88) + 1e1 feee9cea _cond_timedwait (8441670, 81c5fb8, f60ddf08) + 4a feee9d79 cond_timedwait (8441670, 81c5fb8, f60ddf08) + 27 feee9db6 pthread_cond_timedwait (8441670, 81c5fb8, f60ddf08) + 21 fe20190e g_cond_timed_wait_posix_impl (8441670, 81c5fb8, f60ddf88) + 5a feb7977f g_async_queue_pop_intern_unlocked (81c5f98, 0, f60ddf88) + 8b feb79c56 g_async_queue_timed_pop_unlocked (81c5f98, f60ddf88) + 36 febba1f7 g_thread_pool_thread_proxy (81c68c0) + 8b febb8da6 g_thread_create_proxy (843b388) + 11a feeef382 _thr_setup (fa9f2200) + 52 feeef5e0 _lwp_start (fa9f2200, 0, 0, 0, 0, 0) ----------------- lwp# 7 / thread# 7 -------------------- feeef61b __lwp_park (84848c0, 8485e90, 0) + b feee9736 cond_wait_queue (84848c0, 8485e90, 0, 0) + 41 feee9ac4 cond_wait_common (84848c0, 8485e90, 0) + 1e1 feee9c2c _cond_wait (84848c0, 8485e90) + 7b feee9c58 cond_wait (84848c0, 8485e90) + 24 feee9c92 pthread_cond_wait (84848c0, 8485e90) + 1e fedda9dd load_image_thread (8463a70) + 79 febb8da6 g_thread_create_proxy (8468100) + 11a feeef382 _thr_setup (fa9f3200) + 52 feeef5e0 _lwp_start (fa9f3200, 0, 0, 0, 0, 0) ----------------- lwp# 8 / thread# 8 -------------------- feeef61b __lwp_park (8484d40, 8480fc0, 0) + b feee9736 cond_wait_queue (8484d40, 8480fc0, 0, 0) + 41 feee9ac4 cond_wait_common (8484d40, 8480fc0, 0) + 1e1 feee9c2c _cond_wait (8484d40, 8480fc0) + 7b feee9c58 cond_wait (8484d40, 8480fc0) + 24 feee9c92 pthread_cond_wait (8484d40, 8480fc0) + 1e fedda9dd load_image_thread (848df30) + 79 febb8da6 g_thread_create_proxy (8483388) + 11a feeef382 _thr_setup (fa9f3a00) + 52 feeef5e0 _lwp_start (fa9f3a00, 0, 0, 0, 0, 0) ----------------- lwp# 9 / thread# 9 -------------------- feeef61b __lwp_park (847e400, 8481180, 0) + b feee9736 cond_wait_queue (847e400, 8481180, 0, 0) + 41 feee9ac4 cond_wait_common (847e400, 8481180, 0) + 1e1 feee9c2c _cond_wait (847e400, 8481180) + 7b feee9c58 cond_wait (847e400, 8481180) + 24 feee9c92 pthread_cond_wait (847e400, 8481180) + 1e fedda9dd load_image_thread (848faa0) + 79 febb8da6 g_thread_create_proxy (8479af8) + 11a feeef382 _thr_setup (fa9f4200) + 52 feeef5e0 _lwp_start (fa9f4200, 0, 0, 0, 0, 0) Wrapping gtk_main() with calls to gdk_threads_enter() and gdk_threads_leave() resolves te problem
Created attachment 99486 [details] [review] Patch Attached patch wraps gtk_main() with calls to gdk_threads_enter() and gdk_threads_leave() which resolves this problem.
Just checking: what version of gthumb were you testing? Was it 2.10.4+? - Mike
I tested this with gthumb 2.10.7 :) cheers Matt
Patch applied to svn rev 2072. It should appear in 2.10.8. Thanks! - Mike