delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2002/12/30/23:20:57

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
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: <3E111AAF.3090008@ece.gatech.edu>
Date: Mon, 30 Dec 2002 23:18:55 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
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: Re: Heads up: *possible* bug in cygwin
References: <E18PoeB-0000fC-00 AT quimby DOT gnus DOT org> <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> <3E10C29B DOT 2010709 AT ece DOT gatech DOT edu>

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

Sigh.  Finally built a debuggable cygwin from current CVS.  Here's the 
stacktrace from the SIGSEGV.

#0  dlmalloc (bytes=60) at /usr/src/kernel/src/winsup/cygwin/malloc.cc:3516
#1  0x6104003b in dlrealloc (oldmem=0xa041d80, bytes=808464432) at 
/usr/src/kernel/src/winsup/cygwin/malloc.cc:4078
#2  0x610409f8 in realloc (p=0xa041d80, size=32768) at 
/usr/src/kernel/src/winsup/cygwin/malloc_wrapper.cc:146
#3  0x00405d40 in g_realloc (mem=0xa041d80, size=32768) at gmem.c:338
#4  0x00401d4a in g_string_maybe_expand (string=0xa100d4c, len=20223) at 
gstring.c:202
#5  0x0040225a in g_string_append (fstring=0xa100d4c, val=0xa042588 '0' 
<repeats 200 times>...) at gstring.c:297
#6  0x00402c7f in g_string_sprintfa_int (string=0xa100d4c, fmt=0x401330 
"%s|%0100d|%s|%s|%0*d|%*.*f|%10000.10000f", args=0x22fd38 "p\023@") at 
gstring.c:484
#7  0x00402cc4 in g_string_sprintf (string=0xa100d4c, fmt=0x401330 
"%s|%0100d|%s|%s|%0*d|%*.*f|%10000.10000f") at gstring.c:498
#8  0x004018be in main (argc=1, argv=0xa0411e0) at string-test.c:109
#9  0x61007888 in dll_crt0_1() () at 
/usr/src/kernel/src/winsup/cygwin/dcrt0.cc:781
#10 0x61007b6d in _dll_crt0 () at 
/usr/src/kernel/src/winsup/cygwin/dcrt0.cc:911
#11 0x0040d2b2 in cygwin_crt0 (f=0x4013be <main>) at 
/usr/src/kernel/src/winsup/cygwin/lib/cygwin_crt0.c:32
#12 0x0040103c in mainCRTStartup ()
#13 0x77e8d326 in _system_dlls__ ()

The problem seems to occur deep in the innards of Doug Lea's malloc (in 
the "mALLOc()" function -- although that's hard to see from the 
stacktrace above since cygwin itself was compiled with 
-fomit-frame-pointer).  There HAS been a change in this file (malloc.cc) 
since May 1, 2002...most significantly, on Sep 18 it was updated to 
version 2.7.2 from 2.7.1 -- but that wasn't much of a change.

Unfortunately, I'm not going to be able to look at this again until this 
weekend -- and the first thing I'll have to do is read the docs on Lea's 
site about how his malloc is *supposed* to work.  Talk about your black 
magic...

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


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019