Hi Carlos,

On 07/03/2012 04:02:07 PM Tue, Carlos Franke wrote:
All I can suggest for now is to build with --disable-threads. In a threaded 
build, certain use-cases currently lead to deadlocks like yours and Paweł's. 
We're working on it--sorry for the inconvenience.

Okay, no rush and thank you for your efforts—but whoa, --disable-threads leads 
to a segmentation fault on program start! Program output (stripped of empty 
lines)
[ snipped ]

This is a long shot: one difference between the way Balsa starts up in an 
unthreaded build versus a threaded build is that it does not explicitly call 
g_type_init. That call has supposedly been redundant for a long time, currently 
because both gtk_init_with_args and gtk_application_run call it. And even if 
the GType system isn't initialized, it's supposed to complain. But perhaps all 
that gets somehow circumvented...

Anyway, attached is a patch that moves that (redundant) call from 
thread-specific code to unconditionally compiled code. Could you check to see 
if it helps?

Like I wrote, it's a long shot...

Best,

Peter
diff --git a/src/main.c b/src/main.c
index cf773a4..490fba3 100644
--- a/src/main.c
+++ b/src/main.c
@@ -262,8 +262,6 @@ pthread_mutex_t checking_mail_lock = PTHREAD_MUTEX_INITIALIZER;
 static void
 threads_init(void)
 {
-    g_type_init();
-
     libbalsa_threads_init();
     gdk_threads_init();
 
@@ -675,6 +673,8 @@ real_main(int argc, char *argv[])
     setlocale(LC_ALL, "");
 #endif
 
+    g_type_init();
+
 #ifdef BALSA_USE_THREADS
     /* initiate thread mutexs, variables */
     threads_init();

Attachment: pgphGIjtFbA4y.pgp
Description: PGP signature

_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list

Reply via email to