Re: "could not reattach to shared memory" on buildfarm member dory - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: "could not reattach to shared memory" on buildfarm member dory
Date
Msg-id 20180428135923.GO27724@tamriel.snowman.net
Whole thread Raw
In response to Re: "could not reattach to shared memory" on buildfarm member dory  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Tue, Apr 24, 2018 at 11:37:33AM +1200, Thomas Munro wrote:
> >> Maybe try asking what's mapped there with VirtualQueryEx() on failure?
>
> > +1.  An implementation of that:
> > https://www.postgresql.org/message-id/20170403065106.GA2624300%40tornado.leadboat.com
>
> Not seeing any other work happening here, I pushed a little bit of
> quick-hack investigation code.  This is based on noting that
> VirtualAllocEx is documented as rounding the allocation up to a page
> boundary (4K), but there's nothing specific about whether or how much
> CreateFileMapping or MapViewOfFileEx might round up.  The observed
> failures could be explained if those guys might eat more virtual
> address space for the same request size as VirtualAllocEx does.
> This is a stretch, for sure, but given the lack of any other theories
> we might as well check it.

Sounds good to me.  Just as an FYI, there are a couple folks taking a
look at the system and trying to figure out what's going on.  We've seen
an Event ID 1530 error in the Windows Event log associated with
vctip.exe which Visual Studio was running with the build, but only
sometimes.  When vctip.exe is being run and then finishes, it goes and
cleans things up which seems to be what's triggering the 1530 and that
appears to correllate with the failures, but hard to say if that's
really a smoking gun or is just coincidence.

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Toast issues with OldestXmin going backwards
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Clock with Adaptive Replacement