Re: CamelSeekableSubstream prob

On Mon, 2006-11-20 at 02:05 +0100, Philip Van Hoof wrote:
> On Mon, 2006-11-20 at 01:58 +0100, Philip Van Hoof wrote:
> > It looks like the seekable-substream type is being used to wrap steams
> > that are already seekable (like the memory stream).
> > 
> > If it does, it often upgrades the position member by adding (+=) the
> > amount of bytes that where written and read. If the underlying one also
> > does this (with the same integer), then the offset will be wrong.
> 
> Hmm, no. Forget about this patch. I still have the problem and the
> seekable position integer isn't the same as the parent's seekable
> position integer.
> 
> Searching some more ... (fearing it's an overflow problem that gets
> triggered more often on ARM)

I don't know why the parse_content is being called at that location. 

But it looks like it causes the start1, start2, end1 and end2 properties
to be incorrect (a negative extremely large value) on at least four
correct messages (that I can give you).

For example the message of James Livingston on Jun 02 2005 on the
rhythmbox-devel mailing list with the subject "Re: [Rhythmbox-devel]
Album covers" (but also many other signed ones) (which is the first
message on my IMAP server for a test folder of mine, hence why I tested
with this one).

On ARM this is the reason why a little later in the game at stream_seek
of camel-stream-mem.c the memset gets a huge value that will overwrite
the entire application's memory remainder (starting at stream_mem->
buffer->data) with 0's. In other words: lots of fun :) and very cool GDB
stack traces.

Note that camel_multipart_signed_get_content_stream also does this call
and might also have the same problem (but I haven't seen that one
causing troubles).

Anyway, commenting it out seems to work perfectly ...



-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog

_______________________________________________
Evolution-patches mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/evolution-patches

--- camel/camel-multipart-signed.c	2006-11-20 22:45:03.000000000 +0100
+++ /home/pvanhoof/repos/gnome/evolution-data-server/camel/camel-multipart-signed.c	2006-04-12 21:14:13.000000000 +0200
@@ -407,7 +407,7 @@
 	if ((mps->content || mps->contentraw) && mps->signature)
 		return 2;
 
-	if (mps->start1 == -1 /*&& parse_content(mps) == -1*/) {
+	if (mps->start1 == -1 && parse_content(mps) == -1) {
 		if (dw->stream == NULL)
 			return 0;
 		else