Re: Address space clobbers during fork() (was Re: Extending /proc/*/maps)

[Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>]

On 21/04/2011 4:53 AM, Corinna Vinschen wrote:
> On Apr 19 14:16, Ryan Johnson wrote:
> > I actually hadn't noticed that thread stack before making the diff,
> > so at this point it's a toss-up which of the thread or locale.nls
> > got there first and messed up the other. Does Windows tend to map
> > files at the same address every time, or just executable images it
> > hopes to share as-is between processes? Without knowing that it's
> > hard to say what happened.
> I assume it will map the file to the same address if there's nothing
> else already in the way.  This should make virtual memory handling
> easier.  OTOH locale.nls is just a data file, so Win32 shouldn't care
> at all where it's located.
>
> > Regardless of file mapping behavior, though, I don't see right off
> > how to make this problem go away.
> Just an idea:  What if we map locale.nls to some fixed address ourselves
> before any NLS function is called?  Somewhere early in dll_crt0_1.
> If the file is already mapped, there should be no reason for the OS to
> map it again at some other address.
First, it looks like locale.nls has been a problem before: 
http://cygwin.com/ml/cygwin/2009-02/msg00488.html. In fact, locale.nls 
seems to have driven the creation of the peflags_all script (!)

Second, I don't know who maps locale.nls, but it happens *very* early in 
the life of the process, long before gdb can talk to it. Using windbg to 
break on module loads (sxe ld) and examining the list of mapped files 
(!address -f:FileMap) shows that locale.nls gets mapped before 
cygwin1.dll even loads. The load ordering is, AFAICT:

fork.exe
ntdll.dll
ntdll32.dll
wow64.dll
wow64win.dll
wow64cpu.dll
** four top sekrit things windbg reports as WOW64_IMAGE_SECTION and 
NOT_AN_IMAGE**
kernel32.dll
kernelbase.dll
*** somebody maps locale.nls without calling either MapViewOfFile[Ex] or 
NtMapViewOfSection***
*** console window opens for the process (might happen first, hard to 
say) ***
cygbar.dll

Third, it appears that MapViewOfFile[Ex] calls 
KERNELBASE!IsNLSDefinedString, which is probably why those functions 
aren't used to map in locale.nls. The only other function either one 
calls is NtMapViewOfSection, which I had already verified wasn't being 
called directly. Probably the syscall code was inlined, and I couldn't 
find a way right off to trap on all syscalls.

More debugging still ahead, I guess...

Ryan