|
View:
New views
11 Messages
—
Rating Filter:
Alert me
|
|
|
malloc overridesGraphViz 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? Yaakov -- 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 |
|
|
Re: malloc overridesOn 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 |
|
|
Re: malloc overridesOn 05/11/2009 03:56, Corinna Vinschen wrote:
> 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. Thanks for the explanation. So what are the correct answers to the questions the code is trying to answer? Yaakov -- 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 |
|
|
Re: malloc overridesOn Nov 5 04:04, Yaakov S wrote:
> On 05/11/2009 03:56, Corinna Vinschen wrote: > >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. > > Thanks for the explanation. So what are the correct answers to the > questions the code is trying to answer? Yes and no, in this order :) 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 |
|
|
Re: malloc overridesOn Nov 5 11:11, Corinna Vinschen wrote:
> On Nov 5 04:04, Yaakov S wrote: > > On 05/11/2009 03:56, Corinna Vinschen wrote: > > >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. > > > > Thanks for the explanation. So what are the correct answers to the > > questions the code is trying to answer? > > Yes and no, in this order :) Urgh, sorry, I wasn't paying enough attention to the style of the questions. Let's try again, please: Are we stuck with standard malloc? No Is alloca based on malloc()? No 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 |
|
|
Re: malloc overridesYaakov (Cygwin/X) wrote:
> ####### start code 1 ####### > > /* Are we stuck with standard malloc? */ > > extern void _exit (int); > extern char* strdup (const char*); static int are_we_stuck = 1; > > char* malloc(unsigned n) { are_we_stuck = 0; > return 0; > } > > int main(void) { > strdup("yo"); _exit (are_we_stuck); > } > > ####### end code 1 ####### FTFY. > ####### 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 ####### Left as an exercise for the reader. cheers, DaveK -- 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 |
|
|
Re: malloc overridesOn 05/11/2009 07:18, Dave Korn wrote:
>> extern void _exit (int); >> extern char* strdup (const char*); > > static int are_we_stuck = 1; >> >> char* malloc(unsigned n) { > are_we_stuck = 0; >> return 0; >> } >> >> int main(void) { >> strdup("yo"); > _exit (are_we_stuck); >> } > > FTFY. Funny, as I went to sleep last night I thought of just that solution. In practice, though, while it doesn't hang, it doesn't give the correct answer either. As Corinna said, the malloc override needs to be functional, in that it allocates memory which can then be free()d. So this isn't going to be quite so simple. :-( Yaakov -- 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 |
|
|
Re: malloc overrides2009/11/5 Yaakov (Cygwin/X):
>>> extern void _exit (int); >>> extern char* strdup (const char*); >> >> static int are_we_stuck = 1; >>> >>> char* malloc(unsigned n) { >> >> are_we_stuck = 0; >>> >>> return 0; >>> } >>> >>> int main(void) { >>> strdup("yo"); >> >> _exit (are_we_stuck); >>> >>> } >> >> FTFY. > > Funny, as I went to sleep last night I thought of just that solution. In > practice, though, while it doesn't hang, it doesn't give the correct answer > either. As Corinna said, the malloc override needs to be functional, in > that it allocates memory which can then be free()d. So this isn't going to > be quite so simple. :-( Does the memory actually need to be freed? The simplest implementation of malloc() simply advances a pointer into an array (taking alignment into account), and the simplest implementation of free() does nothing. Andy -- 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 |
|
|
Re: malloc overridesOn Nov 5 18:22, Andy Koppe wrote:
> 2009/11/5 Yaakov (Cygwin/X): > >>> extern void _exit (int); > >>> extern char* strdup (const char*); > >> > >> static int are_we_stuck = 1; > >>> > >>> char* malloc(unsigned n) { > >> > >> are_we_stuck = 0; > >>> > >>> return 0; > >>> } > >>> > >>> int main(void) { > >>> strdup("yo"); > >> > >> _exit (are_we_stuck); > >>> > >>> } > >> > >> FTFY. > > > > Funny, as I went to sleep last night I thought of just that solution. In > > practice, though, while it doesn't hang, it doesn't give the correct answer > > either. As Corinna said, the malloc override needs to be functional, in > > that it allocates memory which can then be free()d. So this isn't going to > > be quite so simple. :-( > > Does the memory actually need to be freed? Cygwin itself calls free, so the application implementation has to provide both. 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 |
|
|
Re: malloc overridesCorinna Vinschen wrote:
> On Nov 5 18:22, Andy Koppe wrote: >> 2009/11/5 Yaakov (Cygwin/X): >>>>> extern void _exit (int); >>>>> extern char* strdup (const char*); >>>> static int are_we_stuck = 1; >>>>> char* malloc(unsigned n) { >>>> are_we_stuck = 0; >>>>> return 0; >>>>> } >>>>> >>>>> int main(void) { >>>>> strdup("yo"); >>>> _exit (are_we_stuck); >>>>> } >>>> FTFY. >>> Funny, as I went to sleep last night I thought of just that solution. In >>> practice, though, while it doesn't hang, it doesn't give the correct answer >>> either. As Corinna said, the malloc override needs to be functional, in >>> that it allocates memory which can then be free()d. So this isn't going to >>> be quite so simple. :-( >> Does the memory actually need to be freed? > > Cygwin itself calls free, so the application implementation has to > provide both. So probably just adding a dummy free() implementation will do the job? cheers, DaveK -- 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 |
|
|
Re: malloc overridesOn 05/11/2009 13:02, Dave Korn wrote:
> So probably just adding a dummy free() implementation will do the job? Unfortunately not. Yaakov -- 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 |
| Free embeddable forum powered by Nabble | Forum Help |