From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: OK, so culicidae is *still* broken |
Date: | 2017-04-15 21:30:18 |
Message-ID: | 20170415213017.co7gkjlbcy44zlmw@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-04-15 17:24:54 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2017-04-15 17:09:38 -0400, Tom Lane wrote:
> >> Why doesn't Windows' ability to map the segment into the new process
> >> before it executes take care of that?
>
> > Because of ASLR of the main executable (i.e. something like PIE).
>
> Not following. Are you saying that the main executable gets mapped into
> the process address space immediately, but shared libraries are not?
Without PIE/ASLR we can somewhat rely on pgwin32_ReserveSharedMemoryRegion
to find the space that PGSharedMemoryCreate allocated still unoccupied.
If the main binary also uses ASLR, not just libraries/stack/other
mappings, that's not guaranteed to be the case.
But this probably needs somebody with actual windows expertise
commenting.
> I wonder whether we could work around that by just destroying the created
> process and trying again if we get a collision. It'd be a tad
> inefficient, but hopefully collisions wouldn't happen often enough to be a
> big problem.
That might work, although it's obviously not pretty. We could also just
default to some out-of-the-way address for MapViewOfFileEx, that might
also work.
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-04-15 21:30:21 | Re: OK, so culicidae is *still* broken |
Previous Message | Tom Lane | 2017-04-15 21:24:54 | Re: OK, so culicidae is *still* broken |