Re: [gmime-devel] crash in g_mime_iconv_strndup

[John Feuerstein <john feurix com>]

On Sat, 12 Nov 2011 22:28:26 -0500, Jeffrey Stedfast wrote:
> On 11/12/2011 11:23 AM, John Feuerstein wrote:
> >Program received signal SIGSEGV, Segmentation fault.
> >
> >(gdb) bt 3
> >#0  0x00007ffff5aee52a in memset () from /lib/libc.so.6
> >#1  0x00007ffff7957e89 in g_mime_iconv_strndup (cd=0x798730,
> >     str=0x7fffd81e8b10 "Änderungen an der Artikel-Detailseite", n=38) at gmime-iconv-utils.c:161
> >#2  0x00007ffff7957f30 in g_mime_iconv_strdup (cd=0x798730,
> >     str=0x7fffd81e8b10 "Änderungen an der Artikel-Detailseite") at gmime-iconv-utils.c:199
> >(More stack frames follow...)
> >
> >(gdb) info locals
> >inleft = 0
> >outleft = 140736817703276
> >converted = 134665270
> >out = 0x7fffd806a910 ""
> >outbuf = 0x0
> >inbuf = 0x7fffd81e8b36 ""
> >outlen = 92
> >errnosav = 32767
> 
> inleft looks reasonable
> 
> outleft looks ... wrong. is this the snapshot of the locals just
> before memset is called?

See backtrace above, it's the snapshot right after memset() was called
and produced the SIGSEGV, i.e. gmime-iconv-utils.c line 161:

> >gmime-iconv-utils.c:161 is:
> >
> >     /* nul-terminate the string */
> >     memset (outbuf, 0, 4);
> >

> converted looks way too large, I wouldn't expect a value larger than
> 38 (I'm not sure what counts as "irreversible conversion", but I
> think it reasonable that it wouldn't be larger than the number of
> bytes in the input). I guess, in the end, it likely doesn't matter
> what the value is since it's not being used.
> 
> I would expect 'out' to contain a copy (more-or-less) of the input
> string, not be ""
> 
> As you noted, outbuf shouldn't be null.
> 
> inbuf looks correct (and seems to compute correctly based on the
> address of the input string)
> 
> outlen is definitely correct
> 
> we can ignore errnosav as it shouldn't have been used.

Ok, so we can say that these values don't make sense at the time where
memset() is called:

outleft = 140736817703276
converted = 134665270
out = 0x7fffd806a910 ""
outbuf = 0x0

Looking at the code again, I'm not sure what lead to this. The function
is entered with sane values:

str = 0x7fffd81e8b10 "Änderungen an der Artikel-Detailseite"
n = 38

Therefore:

outlen = n * 2 + 16 = 92

The g_malloc and g_realloc would have aborted the program on failure.

I suspect this situation is a result of some unhandled behaviour of
iconv(3). If it helps, squeeze is shipping glibc-2.11.

> what values do the locals have just before the iconv flush is called?

I'm unable to provide this as it seems impossible to reproduce
(heisenbug?), not with the dbmail testsuite nor with the gmime
testsuite and the string in question.

I'm now trying on a higher level with:

(gdb) set $buggy = "Änderungen an der Artikel-Detailseite"
(gdb) b g_mime_iconv_strndup if (n == 38 && strcmp($buggy, str) == 0)
Breakpoint 2 at 0x7ffff7957d05: file gmime-iconv-utils.c, line 105.
(gdb) i b
Num     Type           Disp Enb Address            What
2       breakpoint     keep y   0x00007ffff7957d05 in g_mime_iconv_strndup at gmime-iconv-utils.c:105
        stop only if (n == 38 && strcmp($buggy, str) == 0)
(gdb) c
Continuing.

... and the resync of the mailbox is still in progress ...

Another idea (I'm not really familiar with how iconv works): Perhaps the
problem is related to an unclean state of "cd" (the conversion
descriptor) when entering the loop. Any ideas how to debug that are
welcome.

Thanks,
John