'Could not attach to shared memory' bug in Windows

I've just had a case of the 'could not reattach to shared memory'
problem, and I thought I'd pass on my findings in case it helps.

I found that it was trying to access shared memory at 0x1610000

I used Process Explorer to have a look at the DLLs used by existing
copies of Postgres to see if I could get any clues from those

I found that one DLL (SystemState.dll FWIW - part of PicoBackup) was
loading at different base addresses - eg 0x1550000 or 0x15B0000 in the
different instances of Postgres. This was because whoever had compiled
that DLL had set the image base to 0x400000 which is guaranteed to
clash, so Windows was having to relocate it every time. The relocated
base address was NOT identical in the different instances of Postgres -
don't ask me why.
I guess at some point it was being relocated to 0x15F0000 or similar, so
it would extend into 0x1610000, but those instances of postgres were
dying so I couldn't see those.

(I have some screenshots if anyone wants them)

Notably, things like LIBEAY32.DLL which are used by Postgres are also
relocated to different addresses (all the OpenSLL DLLs seem to be
compiled with base addresses at 0x10000000 or 0x1C000000) - eg I've
looked here, and in one instance LIBEAY32.DLL is at 0xBE0000, in another
instance it's at 0x230000

I'm not really sure what Postgres can do about this, other than to allow
a moveable shared memory location - but I've seen from previous messages
that that's basically not going to be possible - but that's the 'proper'
solution.

If Postgres controls the loading of the OpenSSL DLLs (using LoadModule
rather than 'static' dynamic linking)  then it can load the OpenSSL DLLs
after getting the right shared memory area, but that won't solve the
problem for DLLs which inject themselves into the application.

Maybe it could allocate a large temporary chunk of shared memory and
then allocate the real chunk above that, then free the temporary chunk.
That would hopefully put the real shared memory well above the space
where Windows will put relocated DLLs - Windows seems to store relocated
DLLs at the bottom of memory, working upwards.

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows