X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Thu, 5 Nov 2009 10:56:29 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: malloc overrides
Message-ID: <20091105095629.GK26344@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4AF29EC2 DOT 2050808 AT users DOT sourceforge DOT net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4AF29EC2.2050808@users.sourceforge.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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

On Nov  5 03:45, Yaakov S wrote:
> GraphViz uses iffe tests to determine system capabilities.  Two
> tests, however, hang and require manual intervention to kill them
> and continue.  These are the culprits:
> 
> ####### start code 1 #######
> 
> /* Are we stuck with standard malloc? */
> 
> extern void _exit (int);
> extern char* strdup (const char*);
> 
> char* malloc(unsigned n) {
>     _exit(0);
>     return 0;
> }
> 
> int main(void) {
>     strdup("yo");
>     _exit(1);
> }
> 
> ####### end code 1 #######
> 
> ####### start code 2 #######
> 
> /* Is alloca is based on malloc()? */
> 
> #include <alloca.h>
> 
> void* malloc(unsigned int size) {
>     exit(0);
>     return 0;
> }
> 
> int main(void) {
>     alloca(10);
>     return 1;
> }
> 
> ####### end code 1 #######
> 
> In both cases, the program hangs and needs to be forcefully killed
> through Windows' taskmgr.  On Linux, these run quickly and return 0
> and 1, respectively.
> 
> Is this a problem with the code, or is this a bug or limitation in Cygwin?

You can replace malloc with your own implementation, but it has to be a
*working* implementation.  Early in the per-process DLL initialization
there's a call to free(malloc(16)), which is used to figure out if
Cygwin's malloc has been overridden with an application-supplied version
of malloc.  Since your malloc calls exit, this goes down the gutter.  At
this early stage in initialization, Cygwin can't handle the exit call
correctly.

Unless we can implement a way to figure out if the application provides
malloc without actually calling malloc, the above testcases are bound to
fail.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple