Re: [gmime-devel] crash in g_mime_iconv_strndup

[Paul J Stevens <paul nfg nl>]

Jeff,


The circumstances under which John uncovered this, and the general
sanity of the gmime calls involved, suggested a thread-related issue.

Closer examination revealed that dbmail was not handling iconv_t
handlers in a thread-safe manner.

I think I've remedied this in the dbmail code, so please assume that's
where the bug lies.




On 13-11-11 16:18, John Feuerstein wrote:
> 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
> _______________________________________________
> gmime-devel-list mailing list
> gmime-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gmime-devel-list


-- 
________________________________________________________________
Paul J Stevens        pjstevns @ gmail, twitter, skype, linkedin

  * Premium Hosting Services and Web Application Consultancy *

           www.nfg.nl/info nfg nl/+31.85.877.99.97
________________________________________________________________