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

Christopher Faylor
Mon Apr 23 18:15:00 GMT 2012

On Mon, Apr 23, 2012 at 05:58:23PM +0200, Corinna Vinschen wrote:
>On Apr 23 11:44, Christopher Faylor wrote:
>> On Mon, Apr 23, 2012 at 04:51:06PM +0200, Corinna Vinschen wrote:
>> >On Apr 23 14:23, James Johnston wrote:
>> >> Perhaps I did not make it clear enough, but these issues still exist as far
>> >> as I can tell.  I have clean Windows 7 and Windows XP virtual machines, and
>> >> a clean install of Cygwin that was updated at the time I sent my original
>> >> message.  Both issues I described still exist.  This is why I wrote the
>> >> message.  If the issues weren't existing on an up-to-date Cygwin
>> >> installation, I would not write to this mailing list and waste anyone's time
>> >> - I am usually not that dumb! 
>> >> 
>> >> Just this morning, I turned on my Cygwin installation in the Windows 7 VM.
>> >> This time, cygreadline7.dll decided to relocate to 0x70030000 - different
>> >> from the original location I mentioned in my original e-mail.  This DLL is
>> >> not locating itself in a stable location.  And there are still system DLLs
>> >> located very close to the Cygwin DLLs.
>> >> 
>> >> 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.
>> Is this something that rebase could turn off when it touches a DLL?
>In theory that's the job of peflags, not of rebase.

Sure, peflags should be able to unset/set it but it doesn't seem to ever
make sense for a dll that rebase has touched so...

>But probably we can safely assume that the Cygwin distro DLLs should
>not have set the dynamicbase flag and the rebaseall script could call
>rebase with an extra flag which automatically removes the dynamicbase
>flag from all rebased DLLs.

I don't see a real need for an extra rebase flag, unless it is turn off
the "remove dynamicbase behavior" but it's no big deal.


Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list