Mail Archives: cygwin/2003/01/01/18:33:11
Robert Collins wrote:
> On Wed, 2003-01-01 at 11:45, Charles Wilson wrote:
>
>
>
>>[...but I can't reproduce the fault on linux. Even if I link in
>>dlmalloc. Bleah. ElectricFence on linux couldn't find anything
>>suspicious either.]
>
>
> You might try valgrind. valgrind is *good*.
Oh dear. What're all you guys doing on the list today? It's a holiday
gosh darn it. Anyway, I see a lot of replies in this thread which I
haven't yet read, but here's what I've learned on my own...
1) valgrind hasn't been ported to cygwin AFAIK. But it was fairly easy
to compile efence, given that helpful folks had previously posted
patches to the list. I've updated them to Bruce's 2.2.2 release, and
will publish them soon. (However, I don't want to take on yet another
package, so...)
2) There's a very good reason why the bug shows up on cygwin, but not
linux. The actual fault occurs in newlib, in the
vsprintf -> vfprintf -> _vfprintf_r -> cvt [vfprintf.c line 1181]
callstack. But it's basically a straightforward buffer overrun in
g_strdup_vprintf():
First, create a buffer of the appropriate length:
buffer = g_new (gchar, g_printf_string_upper_bound (format, args1));
And then format the data into that buffer.
vsprintf (buffer, format, args2);
But the buffer isn't long enough, so the actual problem is *probably*
somewhere in the g_printf_string_upper_bound() routine, that computes
the appropriate length.
I really think that "vsnprintf" should be used here, just on general
principle -- and it IS available on cygwin. But still, glib's
*string_upper_bound function *ought* to be able to accurately compute
the buffer size, and obviously is not.
I haven't stepped thru or investigated in detail, but I will...
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -