This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Heads up: *possible* bug in cygwin
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
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/