Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3E10C29B.2010709@ece.gatech.edu> Date: Mon, 30 Dec 2002 17:03:07 -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: cygwin AT cygwin DOT com Subject: Heads up: *possible* bug in cygwin References: <3E05BD05 DOT 5090408 AT ece DOT gatech DOT edu> <3E0DDE19 DOT 1060903 AT ece DOT gatech DOT edu> <3E10A7AE DOT 20405 AT ece DOT gatech DOT edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Charles Wilson wrote: > Then, configure, make. It passes all tests but one, and I *think* that > one is actually a bug in cygwin's malloc routine. But I am NOT sure > about that. > > test results: > ================================== > > string-test: FAIL > dies in this test: > > g_string_sprintf (string2, "%s|%0100d|%s|%s|%0*d|%*.*f|%100.100f", > "this pete guy sure is a wuss, like he's the number ", > 1, > " wuss. everyone agrees.\n", > string1->str, > 10, 666, 15, 15, 666.666666666, 666.666666666); > > death occurs in > g_string_printf > g_string_append_printf_internal > g_strdup_vprintf > g_new (gchar, g_printf_string_upper_bound(format,args1)) > where second arg evaulates to 10324 > g_new is #defined as > #define g_new(struct_type, n_structs) \ > ((struct_type *) g_malloc (((gsize) sizeof (struct_type)) * ((gsize) (n_structs)))) > so this call is ACTUALLY > (char *) g_malloc ( (sizeof (char)) * 10324 ) > > in g_malloc, we die at this line: > mem = glib_mem_vtable.malloc ( nbytes ) > where nbytes is 10324 > glib_mem_vtable.malloc = 0x10063b20 > death is a SIGSEGV, and it must occur in malloc, and it corrupts the stack. > > Haven't investigated this further, because you need a debuggable kernel and I > don't have time to build one right now. A little more evidence -- but still not a *real* analysis. I just tried to build pkgconfig-0.14.0. Both pkgconfig-0.14.0 and 0.12.0 include their own private copy of glib-1.2.8, and the version included in eack pkgconfig dist are the same, except for autotool updates. In pkgconfig-0.12.0, I HAD passed the glib-1.2.8 string-test back when I built it (I saved the make check output from May 1, 2002). In pkgconfig-0.14.0, I failed it: 136 [main] string-test 1304 handle_exceptions: Error while dumping state (probably corrupted stack) Signal 11 FAIL: string-test As an added test, I rebuilt 0.12.0 today, and it TOO failed the string-test. Now, there are a number of things on my system that have changed between May 1, 2002 and now, including cygwin1.dll gcc (2.95.3 --> 3.2-3) binutils so it's not a slam dunk that cygwin's malloc is the problem. main g_string_sprintf g_string_sprintfa_int ------------------- | unlike glib-2.0.7, the following call succeeds. 1.2.8 fails | in realloc() with the new cygwin/gcc/binutils, while 2.0.7 failed | in malloc(). |g_strdup_vprintf | buffer = g_new(gchar, g_printf_string_upper_bound(format, args1)); | g_printf_string_upper_bound() evaluates to 30423 | again, g_new() is #defined as g_malloc with typecasting, so | buffer = (char *) g_malloc(30423) | this actually succeeds ------------------- g_string_append(string, buffer) g_string_maybe_expand g_realloc() dies in: p = (gpointer) realloc(mem, size) where mem is a char* that points to a chunk of previously alloc'ed memory 4 bytes long, and size is 32768. dies with SIGSEGV. If somebody with a debuggable cygwin kernel could look into this, I'd appreciate it. I'll try to follow up on my own, but it takes FOREVER to do a 'cvs update' on the cygwin source tree over a 28.8k modem... One needn't use the giant glib-2.0.7 tarball, or even the added overhead of pkgconfig, to demonstrate the problem. Nor is the problem related to calling the glib functions inside a dll -- because pkgconfig builds and uses glib statically. The problem even appears (given current binutils, gcc, and cygwin) in the plain glib-1.2.8 dist from ftp://ftp.gtk.org/pub/gtk/v1.2/glib-1.2.8.tar.gz without any special re-autotoolization. Just apply this patch, do 'CFLAGS=-g ./configure' and make. Then gdb on tests/string-test.exe. --- glib-1.2.8-orig/gstrfuncs.c Mon Apr 17 11:05:16 2000 +++ glib-1.2.8/gstrfuncs.c Wed May 1 21:09:56 2002 @@ -671,7 +671,7 @@ char *msg; #ifdef HAVE_STRSIGNAL - extern char *strsignal (int sig); + extern const char *strsignal (int sig); return strsignal (signum); #elif NO_SYS_SIGLIST switch (signum) --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/