This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: emacs and large-address awareness under recent snapshots

On 8/8/2011 11:50 AM, Corinna Vinschen wrote:
On Aug 8 09:22, Ken Brown wrote:
I attached gdb to the running process and got some more information.
It turns out that this has nothing to do with X.  It's just that
starting emacs under X causes emacs to try to allocate memory, and
this makes the problem show up very quickly.

It looks to me like emacs gets stuck in morecore_nolock() and/or
_malloc_internal_nolock(), which are defined in src/gmalloc.c.
Apparently, emacs has a peculiar way of managing memory on Cygwin,
and this chokes on the changes to the heap start address as of
2011-07-21. I don't know enough programming to fix this.  If anyone
wants to try, the relevant source files to look at are gmalloc.c,
sheap.c, and unexcw.c.  The second and third are compiled only in
the Cygwin build, and the first also has some Cygwin-specific stuff.

Maybe I should take this to the emacs-devel list at some point, but
I'll wait a while to see if someone on this list can help.

I had a look into the sources you're mentioning above, but I don't see anything suspicious, apart from the fact that emacs uses some static buffer of 12 Megs as heap on Cygwin... sometimes. At least that's what sheap.c is about, afaics.

I'll build a debug version and try stepping through the functions I mentioned. Maybe I can figure out what's happening. I suspect that it does have something to do with the static heap.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]