This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Process map and fork problems
- From: Achim Gratz <Stromeko at NexGo dot DE>
- To: cygwin at cygwin dot com
- Date: Wed, 20 Apr 2016 14:29:07 +0000 (UTC)
- Subject: Re: Process map and fork problems
- Authentication-results: sourceware.org; auth=none
- References: <loom dot 20160420T121651-786 at post dot gmane dot org> <20160420104633 dot GA26118 at calimero dot vinschen dot de> <loom dot 20160420T124825-644 at post dot gmane dot org> <20160420111431 dot GB13570 at calimero dot vinschen dot de> <loom dot 20160420T131743-463 at post dot gmane dot org> <20160420140625 dot GA25668 at calimero dot vinschen dot de>
Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> It can't fragment, it can only grow. The Unix heap management doesn't
> have the notion of multiple application heaps. There's only the sbrk
> call to raise or shrink the size of the heap.
Thanks for the confirmation. It looks like I am allowed to migrate the
machines to a 3GB VM, thus circumventing the heap collision with DLL.
Meanwhile I've looked at some problems that typically happen when loading
emacs-x11 and it turns out that this loads a number of Windows DLL related
to the display drivers and some others related to networking to low
addresses. The only way I see to get around that is to try to enable ASLR,
so what's the latest on doing that with Cygwin DLL? As far as I understand
we should then rebase from 0x50000000 down since the range above is used by
ASLR for any DLL that we still need top load to fixed addresses?
Regards,
Achim.
--
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