Two probable basing issues causing fork failures: (1) cygreadline7.dll has ASLR enabled, (2) default base address conflicts with ASLR-relocated/system DLLs

Corinna Vinschen
Mon Apr 23 15:03:00 GMT 2012

On Apr 23 08:54, Eric Blake wrote:
> On 04/23/2012 08:51 AM, Corinna Vinschen wrote:
> >> If having Windows randomly rebase cygreadline7.dll in a child process via
> >> ASLR is not a problem, I'd simply be interested to know why.  I thought
> >> *any* Cygwin DLL relocating itself would cause fork to fail.
> > 
> > Yes, it is a problem in the first place if DLLs have the dynamicbase
> > flag set, because, obviously, it undermines what rebaseall is doing.
> > It's not a problem if the new address it gets rebased to doesn't collide
> > with any other used DLL since ASLR on Windows only shuffles ASLR-enabled
> > DLL addresses when a DLL is loaded by an application for the first time.
> > Afterwards, it will use the new address for that DLL until reboot.
> > So, yes, we should make sure that the ASLR flag is not used for Cygwin
> > DLLs.
> > 
> > Eric, could you create a new package which avoids setting the
> > dynamicbase flag for cygreadline and cyghistory?
> At the time I created the current cygreadline package, cygwin didn't
> have quite as good support for running rebaseall; since things have
> improved on that front, I will see about getting a new release of the
> readline package this week that disables the ASLR hack I had added way
> back when.



Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list