https://bugzilla.novell.com/show_bug.cgi?id=433100
User mmeeks@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=433100#c15
--- Comment #15 from Michael Meeks 2009-01-05 04:39:21 MST ---
Of course - it is -entirely- possible that this sort of crash is un-related;
the summaries & indexes have been created on a 32bit machine, and have been
transfered to a 64bit one and are being migrated on that - so perhaps there is
some 32/64bit un-clean-ness here that is clouding the picture.
Indeed - reading the code in message_info_load - it is pretty worrying to see:
static CamelMessageInfo *
message_info_load(CamelFolderSummary *s, FILE *in)
{
CamelMessageInfoBase *mi;
guint count;
..
if (camel_file_util_decode_uint32(in, &count) == -1)
where:
int
camel_file_util_decode_uint32 (FILE *in, guint32 *dest)
This is pretty much a disaster wrt. clean 64bit coding AFAICS - guint will be a
64bit quantity - only half of which is initialized; while - *dest will be
addressing only half of it [ surely ] ?
No idea how this appears to work most of the time ;-) but of course valgrind
can't easily catch such things on the stack.
I audited all of the other decode_uint32 calls - and they are all correct,
except for this one, please apply the following patch ASAP:
Index: camel/camel-folder-summary.c
===================================================================
--- camel/camel-folder-summary.c (revision 9789)
+++ camel/camel-folder-summary.c (working copy)
@@ -3081,7 +3081,7 @@
message_info_load(CamelFolderSummary *s, FILE *in)
{
CamelMessageInfoBase *mi;
- guint count;
+ guint32 count;
int i;
char *subject, *from, *to, *cc, *mlist, *uid;
Thanks.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.