On 6/21/2011 4:06 AM, Corinna Vinschen wrote: > Btw., did anybody experiment with setting the ASLR flag for DLLs? > Chuck's description sounds as if this really might help to reduce > collision problems at fork time. If so, the ASLR flag should > become default for DLLs.
(1) I thought the end result of those experiments was that it really didn't help, and sometimes hurt...especially as Reini wrote last december: http://cygwin.com/ml/cygwin/2010-12/msg00091.html >> I'm trying now to turn off ASLR: peflags -d0 for all perl dll's. > Yes. Adding a -d0 solved so far the problems on Win7 for me. More recently on the mingw list: http://lists-archives.org/mingw-users/19902-msys-perl-regression.html >> I thought we (on cygwin) had pretty much come to the conclusion that >> chasing after ASLR and peflags -d0 [ed: that is, turning ASLR *off*] >> was a red herring? Well, I guess >> it's not too hard to patch the Makefile to run peflags on miniperl... > > Not really. I tested recently perls on Windows 7 with peflags -d1 [ed: that is, with ASLR turned on] > and > came to the conclusion that in perl forking a perl which load dll's > (XS) we get random problems. (2) Most of the problems lately seem to occur with 64bit OS's. I think your idea of rebasing into high memory on those systems is something good to try -- but in that case, ASLR will not apply anyway: a global bitmap called _MiImageBitMap is used to represent the address space from 0x50000000 to 0x78000000. The bitmap is 0x2800 bits in length with each bit representing 64KB of memory. With regards to #1, we had a long thread a few years ago, where we investigated an issue where DLLs would allocate memory 'right next to' their own .text segment -- but this extra memory doesn't show up in the "next_dll_image_base = my_dll_image_base + my_dll_image_size" calculation. Hence, boom. We "solved" the problem by explicitly increasing the rebaseall offset to 0x20000, and fixing one other issue related to allocating a large buffer for a filename in the PEB or something: http://cygwin.com/ml/cygwin/2009-06/msg00266.html (*) One statement in that thread: http://cygwin.com/ml/cygwin/2009-06/msg00226.html > In that sense, ASLR would be a disimprovement over what we can do with > rebase, because we can apply a larger quantization (e.g. > DefaultOffset=0x20000). referred the fact that ASLR will *always* compute the next image base based on a 64k quantization size, and can't be 'tweaked' to make room for allocations in the first dll, that happen after the "next" dll is loaded and ASLRed. ===== so, the upshot is, I'm not sure if ASLR really is a silver bullet, since Reini's experiments in late 2010 are certainly after the buffer-size changes from June 2009. I'd love to be wrong... -- Chuck (*) This series of patches, I believe 2009-06-06 Corinna Vinschen <> * dll_init.cc (dll_list::alloc): Allocate memory using a section object. Explain why. Drop call to GetSystemInfo, rather call getpagesize to get allocation granularity. Only align to allocation granularity under WOW64. Use roundup2 to align. (dll_list::detach): Call NtUnmapViewOfSection instead of VirtualFree. 2009-06-06 Corinna Vinschen <> * mmap.cc: Use NtUnmapViewOfSection instead of UnmapViewOfFile throughout for symmetry. (fhandler_dev_mem::munmap): Use correct process handle in call to NtUnmapViewOfSection. 2009-06-06 Corinna Vinschen <> * dll_init.h (struct dll): Set size of name element to ANYSIZE_ARRAY. * dll_init.cc: Fix formatting. (dll_list::alloc): Only allocate as much memory for struct dll as necessary for given DLL name. (dll_list::load_after_fork): Only read a single page of parent memory. Only read more if namelen indicates that it's necessary.
