Heads up: *possible* bug in cygwin

Charles Wilson cwilson@ece.gatech.edu
Mon Dec 30 15:19:00 GMT 2002

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 <malloc>
> 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
   gcc (2.95.3 --> 3.2-3)
so it's not a slam dunk that cygwin's malloc is the problem.

| 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().
|  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)
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
without any special re-autotoolization.

Just apply this patch, do 'CFLAGS=-g ./configure' and make.  Then gdb on 

--- 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;

-  extern char *strsignal (int sig);
+  extern const char *strsignal (int sig);
    return strsignal (signum);
    switch (signum)


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/

More information about the Cygwin mailing list