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:
pgpG2AMVEjEh7.pgp
Description: PGP signature