[evolution-patches] Re: [Evolution-hackers] g_mutex, e_mutex and pthread_mutex in camel?!

[Philip Van Hoof <spam pvanhoof be>]

On Mon, 2006-03-13 at 12:54 +0100, Philip Van Hoof wrote:
> Is there a reason why g_mutex, e_mutex and pthread_mutex are used in a
> mixed may on libcamel?

This patch replaces that pthread_mutex. But it looks like there's
something wrong with the write_to_stream function pointer ...

In my debugger, at the write_to_stream function, the "stream" instance
doesn't look like a CamelStream.
 
Whereas in camel_data_wrapper_write_to_stream it does. This is perhaps
my GDB acting strange, but it looks like that is causing the
segmentation fault described below.

Also funny is the address of "stream" in the backtrace. It changes?!

That shouldn't happen if I follow the code ... strange.

0x8067c58 vs. 0x8067a38 -- So the ptr is decreased a few bytes?

> Anyway, I'm getting this segmentation fault on the
> CAMEL_DATA_WRAPPER_UNLOCK call in camel-data-wrapper.c 
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1226287424 (LWP 16199)]
> 0x00001098 in ?? ()
> (gdb) bt
> #0  0x00001098 in ?? ()
> #1  0x00000012 in ?? ()
> #2  0x00000f40 in ?? ()
> #3  0xb7a3d653 in write_to_stream (data_wrapper=0x8067aa8,
> stream=0x8067c58) at camel-data-wrapper.c:149
> #4  0xb7a3d6d7 in camel_data_wrapper_write_to_stream
> (data_wrapper=0x8067aa8, stream=0x8067a38) at camel-data-wrapper.c:175
> 
-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be

Index: camel-data-wrapper.c
===================================================================
RCS file: /cvs/gnome/evolution-data-server/camel/camel-data-wrapper.c,v
retrieving revision 1.68
diff -u -r1.68 camel-data-wrapper.c
--- camel-data-wrapper.c	31 Aug 2005 04:21:56 -0000	1.68
+++ camel-data-wrapper.c	13 Mar 2006 12:41:27 -0000
@@ -73,7 +73,8 @@
 	CamelDataWrapper *camel_data_wrapper = CAMEL_DATA_WRAPPER (object);
 	
 	camel_data_wrapper->priv = g_malloc (sizeof (struct _CamelDataWrapperPrivate));
-	pthread_mutex_init (&camel_data_wrapper->priv->stream_lock, NULL);
+	
+	camel_data_wrapper->priv->stream_lock = g_mutex_new ();
 	
 	camel_data_wrapper->mime_type = camel_content_type_new ("application", "octet-stream");
 	camel_data_wrapper->encoding = CAMEL_TRANSFER_ENCODING_DEFAULT;
@@ -143,9 +144,8 @@
 		CAMEL_DATA_WRAPPER_UNLOCK (data_wrapper, stream_lock);
 		return -1;
 	}
-	
 	ret = camel_stream_write_to_stream (data_wrapper->stream, stream);
-	
+
 	CAMEL_DATA_WRAPPER_UNLOCK (data_wrapper, stream_lock);
 	
 	return ret;
Index: camel-private.h
===================================================================
RCS file: /cvs/gnome/evolution-data-server/camel/camel-private.h,v
retrieving revision 1.37
diff -u -r1.37 camel-private.h
--- camel-private.h	8 Dec 2005 08:59:32 -0000	1.37
+++ camel-private.h	13 Mar 2006 12:41:27 -0000
@@ -142,11 +142,11 @@
 
 
 struct _CamelDataWrapperPrivate {
-	pthread_mutex_t stream_lock;
+	GMutex *stream_lock;
 };
 
-#define CAMEL_DATA_WRAPPER_LOCK(dw, l)   (pthread_mutex_lock(&((CamelDataWrapper *)dw)->priv->l))
-#define CAMEL_DATA_WRAPPER_UNLOCK(dw, l) (pthread_mutex_unlock(&((CamelDataWrapper *)dw)->priv->l))
+#define CAMEL_DATA_WRAPPER_LOCK(dw, l)   (g_mutex_lock (((CamelDataWrapper *)dw)->priv->l))
+#define CAMEL_DATA_WRAPPER_UNLOCK(dw, l) (g_mutex_unlock (((CamelDataWrapper *)dw)->priv->l))
 
 
 /* most of this stuff really is private, but the lock can be used by subordinate classes */