Boost logo

Boost Users :

Subject: Re: [Boost-users] [Interprocess] How to prevent collision of mapping addresses with DLL Loading on Windows?
From: pheres (ph3res_at_[hidden])
Date: 2009-12-14 09:41:45


Eric J. Holtman wrote:
> It's not 100% reliable (because at some point, you're going to
> have to VirtualFree the slice so the shared memory lib
> can use it), but it's better than most alternatives.
Yes, I VirtualFree exactly one statement before initializing the IPC.

> If *you're* writing the code that uses the shared memory
> block, I would *strongly* encourage you to attempt to
> re-write it so that you don't need to have it loaded into the
> same address location in all processes.
I have a tree like structure in the shared memory using pointers
(which have to be valid inside every process, therefore the need for fixed
base address) as connection elements. The structure is fairly big and
queried
right often. If I use offsets instead pointers and convert that to
pointers using the
difference in the base addresses I get about 1/10th of the original
performance.

> (like, where I'm writing a lib, and using their lib, but I
> didn't write "main").
You could call VirtualAlloc() inside DllMain() of your lib as a workaround.

I found one other possibility to get some code (which could alloc and
therefore reserve the memory) executed possibly before any run time linking
occurs: Creating a thread local storage callback. But it involves some PE
format editor tools and probably manual work. Seems to hacky for anything
but creating malware.

I can't believe that Windows does not offer a way to solve this problem
more elegantly, e.g. through setting some option somewhere which states
like "if you load any DLL, do it, but do not relocate it between 0x...
and 0x...".
MS should know that the described problem could happen, but I'm unable
to find something in their docs.

Best Regards
Joerg


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net