I attached a full trace off the the program running, can anyone check it out
for me?
2011/3/5 Chris Vine ch...@cvine.freeserve.co.uk
On Sat, 5 Mar 2011 11:58:23 +0800
Wei-Ning Huang aitjc...@gmail.com wrote:
[snip]
From what I can see, the program is stuck because the main thread
locked a
On Sun, 6 Mar 2011 10:57:24 +0800
Wei-Ning Huang aitjc...@gmail.com wrote:
Thanks Chris. I tried to remove any function call in the
compile_thread, i.e:
// Thread function
// It is signaled to wake up for every 1 second
gpointer motion_compile_thread(gpointer data) {
...
while (TRUE) {
On Sun, 6 Mar 2011 16:03:43 +
Chris Vine ch...@cvine.freeserve.co.uk wrote:
On Sun, 6 Mar 2011 10:57:24 +0800
Wei-Ning Huang aitjc...@gmail.com wrote:
[snip]
I'm starting to think it's the bug of gtk+, or perhaps the
kernel?
btw, I'm using Arch Linux with Kernel 2.6.37(autogroup
Hi Chris,
Thanks for your great help!!!
I finally find out why the deadlock always occurs after 5 minutes.
My applications has a function the autosave the document every X minute,
and I use the g_timeout_add_seconds with callback to handle it. However
the callback contains a line 'while
On Sat, 5 Mar 2011 11:58:23 +0800
Wei-Ning Huang aitjc...@gmail.com wrote:
[snip]
From what I can see, the program is stuck because the main thread
locked a mutex in #3.
But from the backtrace, the mutex seems to be locked by
gtk_main_loop_run() which is something I can't control,
and somehow
Thanks Chris. I tried to remove any function call in the compile_thread,
i.e:
// Thread function
// It is signaled to wake up for every 1 second
gpointer motion_compile_thread(gpointer data) {
...
while (TRUE) {
if (!g_mutex_trylock(cp_mutex)) continue;
g_cond_wait(compile_cv,
