Mail Archives: cygwin/2009/11/05/04:56:57
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
- Raw text -