Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Message-ID: <3E137A39.9050204@ece.gatech.edu> Date: Wed, 01 Jan 2003 18:31:05 -0500 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Collins CC: cygwin@cygwin.com Subject: Re: Heads up: *possible* bug in cygwin References: <3E05BD05.5090408@ece.gatech.edu> <3E0DDE19.1060903@ece.gatech.edu> <3E10A7AE.20405@ece.gatech.edu> <3E10C29B.2010709@ece.gatech.edu> <3E111AAF.3090008@ece.gatech.edu> <20021231043913.GA26944@redhat.com> <3E11AD26.8050506@ece.gatech.edu> <20021231175349.GC6542@redhat.com> <3E123A28.8030705@ece.gatech.edu> <1041383123.6526.13.camel@lifelesswks> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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/