Re: [Evolution-hackers] improved rfc2047 decode patch

[Jeffrey Stedfast <fejj novell com>]

Thanks for the info, I'll have a closer look when I get back from
holiday. My guess is that "Conditional jumps" can safely be ignored as
they are probably due to some code optimization hack inside memchr() but
the others I'm not sure about.

I've committed a possible fix for them (only bug I could think of at
first glance) which checks that inbuf is >= 8 bytes since that is the
minimum size of an rfc2047 encoded-word token, less than that and it's
not an enc-word for sure.

Either way, my fix is a nice sanity check to have anyway.

Jeff


On Thu, 2007-12-27 at 21:52 +0100, Philip Van Hoof wrote:
> These warnings might be unimportant. But fyi
> 
> ==32055== 
> ==32055== Thread 3:
> ==32055== Conditional jump or move depends on uninitialised value(s)
> ==32055==    at 0x4023BC7: memchr (mc_replace_strmem.c:354)
> ==32055==    by 0x5054F8D: rfc2047_decode_word (camel-mime-utils.c:1060)
> ==32055==    by 0x5057FA9: header_decode_mailbox (camel-mime-utils.c:2602)
> ==32055==    by 0x50583AD: header_decode_address (camel-mime-utils.c:2727)
> ==32055==    by 0x50589FB: camel_header_address_decode (camel-mime-utils.c:2997)
> ==32055==    by 0x5043A26: internet_decode (camel-internet-address.c:91)
> ==32055==    by 0x5039789: camel_address_decode (camel-address.c:129)
> ==32055==    by 0x504E71A: process_header (camel-mime-message.c:708)
> ==32055==    by 0x504E851: add_header (camel-mime-message.c:745)
> ==32055==    by 0x504585C: camel_medium_add_header (camel-medium.c:145)
> ==32055==    by 0x50533FB: construct_from_parser (camel-mime-part.c:963)
> ==32055==    by 0x504E317: construct_from_parser (camel-mime-message.c:597)
> ==32055== 
> ==32055== Conditional jump or move depends on uninitialised value(s)
> ==32055==    at 0x4023BD5: memchr (mc_replace_strmem.c:354)
> ==32055==    by 0x5054F8D: rfc2047_decode_word (camel-mime-utils.c:1060)
> ==32055==    by 0x5057FA9: header_decode_mailbox (camel-mime-utils.c:2602)
> ==32055==    by 0x50583AD: header_decode_address (camel-mime-utils.c:2727)
> ==32055==    by 0x50589FB: camel_header_address_decode (camel-mime-utils.c:2997)
> ==32055==    by 0x5043A26: internet_decode (camel-internet-address.c:91)
> ==32055==    by 0x5039789: camel_address_decode (camel-address.c:129)
> ==32055==    by 0x504E71A: process_header (camel-mime-message.c:708)
> ==32055==    by 0x504E851: add_header (camel-mime-message.c:745)
> ==32055==    by 0x504585C: camel_medium_add_header (camel-medium.c:145)
> ==32055==    by 0x50533FB: construct_from_parser (camel-mime-part.c:963)
> ==32055==    by 0x504E317: construct_from_parser (camel-mime-message.c:597)
> ==32055== 
> ==32055== Invalid read of size 1
> ==32055==    at 0x4023BD3: memchr (mc_replace_strmem.c:354)
> ==32055==    by 0x5054F8D: rfc2047_decode_word (camel-mime-utils.c:1060)
> ==32055==    by 0x5057FA9: header_decode_mailbox (camel-mime-utils.c:2602)
> ==32055==    by 0x50583AD: header_decode_address (camel-mime-utils.c:2727)
> ==32055==    by 0x50589FB: camel_header_address_decode (camel-mime-utils.c:2997)
> ==32055==    by 0x5043A26: internet_decode (camel-internet-address.c:91)
> ==32055==    by 0x5039789: camel_address_decode (camel-address.c:129)
> ==32055==    by 0x504E71A: process_header (camel-mime-message.c:708)
> ==32055==    by 0x504E851: add_header (camel-mime-message.c:745)
> ==32055==    by 0x504585C: camel_medium_add_header (camel-medium.c:145)
> ==32055==    by 0x50533FB: construct_from_parser (camel-mime-part.c:963)
> ==32055==    by 0x504E317: construct_from_parser (camel-mime-message.c:597)
> ==32055==  Address 0x89ced8c is 0 bytes after a block of size 4 alloc'd
> ==32055==    at 0x4022AB8: malloc (vg_replace_malloc.c:207)
> ==32055==    by 0x4022BFC: realloc (vg_replace_malloc.c:429)
> ==32055==    by 0x4A649BA: g_realloc (in /usr/lib/libglib-2.0.so.0.1400.1)
> ==32055==    by 0x4A7DC7B: (within /usr/lib/libglib-2.0.so.0.1400.1)
> ==32055==    by 0x4A7ECDC: g_string_sized_new (in /usr/lib/libglib-2.0.so.0.1400.1)
> ==32055==    by 0x4A7ED24: g_string_new (in /usr/lib/libglib-2.0.so.0.1400.1)
> ==32055==    by 0x5057BC7: header_decode_mailbox (camel-mime-utils.c:2480)
> ==32055==    by 0x50583AD: header_decode_address (camel-mime-utils.c:2727)
> ==32055==    by 0x50589FB: camel_header_address_decode (camel-mime-utils.c:2997)
> ==32055==    by 0x5043A26: internet_decode (camel-internet-address.c:91)
> ==32055==    by 0x5039789: camel_address_decode (camel-address.c:129)
> ==32055==    by 0x504E71A: process_header (camel-mime-message.c:708)
> ==32055== 
> ==32055== Invalid read of size 1
> ==32055==    at 0x5054F9D: rfc2047_decode_word (camel-mime-utils.c:1060)
> ==32055==    by 0x5057FA9: header_decode_mailbox (camel-mime-utils.c:2602)
> ==32055==    by 0x50583AD: header_decode_address (camel-mime-utils.c:2727)
> ==32055==    by 0x50589FB: camel_header_address_decode (camel-mime-utils.c:2997)
> ==32055==    by 0x5043A26: internet_decode (camel-internet-address.c:91)
> ==32055==    by 0x5039789: camel_address_decode (camel-address.c:129)
> ==32055==    by 0x504E71A: process_header (camel-mime-message.c:708)
> ==32055==    by 0x504E851: add_header (camel-mime-message.c:745)
> ==32055==    by 0x504585C: camel_medium_add_header (camel-medium.c:145)
> ==32055==    by 0x50533FB: construct_from_parser (camel-mime-part.c:963)
> ==32055==    by 0x504E317: construct_from_parser (camel-mime-message.c:597)
> ==32055==    by 0x50534DA: camel_mime_part_construct_from_parser (camel-mime-part.c:995)
> 
> 
> 
> On Thu, 2007-12-27 at 08:25 -0500, Jeffrey Stedfast wrote:
> > On Thu, 2007-12-27 at 08:46 +0800, jacky wrote:
> > > --- Jeffrey Stedfast <fejj novell com>wrote:
> > > 
> > > > 
> > > > On Thu, 2007-12-27 at 00:20 +0800, jacky wrote:
> > > > > It seem that your patch don't support this kind of
> > > > > encoded string:
> > > > >
> > > >
> > > =?gb2312?b?<any-encoded-text?==?gb2312?b?<any-encoded-text?=
> > > > > Two encoded-words are not separated by any
> > > > character.
> > > > 
> > > > Are you sure? I wrote the code to be able to handle
> > > > this case and I just
> > > > tested it again (noticed that I didn't have a test
> > > > case like this in my
> > > > test suite so added one) and it works fine.
> > > > 
> > > > Do you have an example subject/whatever header for
> > > > me to test against?
> > > > 
> > > 
> > > I make my conclusion too hastiness. Yes, your patch
> > > support this kind of email,
> > 
> > ok ;-)
> > 
> > >  but it didn't support the
> > > email that break a single multi-byte character across
> > > multiple encoded-word tokens, and when it decode the
> > > header that break a encoded-word token across two
> > > lines, there is no result display on evolution, for
> > > example, the Subject is empty.
> > 
> > ok, just fixed this in svn. I had tested a broken UTF-8 header earlier
> > and so didn't see a slight bug in my code.
> > 
> > > I'll use Camle with your patch to check all email on
> > > my mbox  and use gmime to decode all email header to
> > > find out it's capacity.
> > 
> > 
> > Ok, awesome.
> > 
> > Jeff
> > 
> > _______________________________________________
> > Evolution-hackers mailing list
> > Evolution-hackers gnome org
> > http://mail.gnome.org/mailman/listinfo/evolution-hackers