Horton

Re: "could not reattach to shared memory" on buildfarm member dory

Stephen Frost <sfrost@snowman.net>

View thread View on postgr.es
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Noah Misch <noah@leadboat.com>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-04-28T13:59:23Z
Lists: 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

Commits

  1. Avoid "could not reattach" by providing space for concurrent allocation.

  2. Assert that pgwin32_signal_initialize() has been called early enough.

  3. Remove investigative code for can't-reattach-to-shared-memory errors.

  4. Does it help to wait before reattaching?

  5. Map and unmap the shared memory block before risking VirtualFree.

  6. Further effort at preventing memory map dump from affecting the results.

  7. Remove Windows module-list-dumping code.

  8. Dump full memory maps around failing Windows reattach code.

  9. Get still more info about Windows can't-reattach-to-shared-memory errors.

  10. Get more info about Windows can't-reattach-to-shared-memory errors.

  11. Try to get some info about Windows can't-reattach-to-shared-memory errors.