Re: [HACKERS] OK, so culicidae is *still* broken - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [HACKERS] OK, so culicidae is *still* broken
Date
Msg-id CAA4eK1LzVhD2TzxRtG183z__=YzWwHtvUFJw4CAFdkyjR2SGRw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] OK, so culicidae is *still* broken  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, May 1, 2017 at 10:23 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Amit Kapila <amit.kapila16@gmail.com> writes:
>> Yeah, that's right.  Today, I have spent some time to analyze how and
>> where retry logic is required.  I think there are two places where we
>> need this retry logic, one is if we fail to reserve the memory
>> (pgwin32_ReserveSharedMemoryRegion) and second is if we fail to
>> reattach (PGSharedMemoryReAttach).
>
> I'm not following.  The point of the reserve operation is to ensure
> that the reattach will work.  What makes you think we need to add more
> code at that end?
>

We use VirtualAllocEx to allocate memory at a pre-defined address
(reserve operation) which can fail due to ASLR.  One recent example of
such a symptom is seen on pgsql-bugs [1], that failure is during
reserve operation and seems like something related to ASLR.  Another
point is the commit 7f3e17b4827b61ad84e0774e3e43da4c57c4487f (It
doesn't fail every time (which is explained by the Random part in
ASLR), but can fail with errors abut failing to reserve shared memory
region) also indicates that we can fail to reserve memory due to ASLR.


[1] - https://www.postgresql.org/message-id/14121.1485360296%40sss.pgh.pa.us

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] snapbuild woes
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] snapbuild woes