FW: Re: [emacs_user@hotmail.com: ***MEMORY-ERROR***: emacs[5172]: GSlice: failed

Jan Djärv jan.h.d@swipnet.se
Fri Feb 23 17:44:00 GMT 2007


Larry Hall wrote:
> Jan DjÃrv wrote:
> 
>     Yes it does thanks for the explanation.  Cygwin has some mechanism that makes
>     it possible for a program to supply its own malloc/free and friends I think
>     (malloc_wrapper.cc).  Would it be hard to also handle memalign/valloc and
>     later posix_memalign in the same fashion?
> 
> 
> 
> It already handles memalign/valloc.

Are you talking about the released cygwin version?  It does not handle malloc
the same as memalign, I see in malloc_wrapper.c:

extern "C" void *
malloc (size_t size)
{
  void *res;
  export_malloc_called = 1;
  if (!use_internal_malloc)
    res = user_data->malloc (size);
  else
...

and

extern "C" void *
memalign (size_t alignment, size_t bytes)
{
  void *res;
  if (!use_internal_malloc)
    {
      set_errno (ENOSYS);
      res = NULL;
    }

> 
> 
>     Would I be correct in assuming that such an addition would make glib call the
>     Emacs versions?
> 
> 
> 
> I suppose.  But if Emacs is modular enough to provide its calls as a
> (import) library or object file, you can just list this on the link line
> after glib and get the same affect for Emacs/glib.  This may be easier
> for you.

That would have to come from someone that cares alot about Emacs + Gtk+ on
cygwin.  I'm just trying to find a simple solution, as it seems now, we will
disable Gtk+ on cygwin.

BTW, I tried to put to put the object file that contain malloc/memalign after
the Gtk+ libraries, and it didn't work.  Glib does not call the Emacs supplied
memalign in this case either.

	Jan D.


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



More information about the Cygwin mailing list