Horton

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

Heath Lord <heath.lord@crunchydata.com>

View thread View on postgr.es
From: Heath Lord <heath.lord@crunchydata.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>, Thomas Munro <thomas.munro@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-04-30T19:25:39Z
Lists: pgsql-hackers 
On Mon, Apr 30, 2018 at 2:34 PM, Stephen Frost <sfrost@snowman.net> wrote:

> Greetings,
>
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > [ Thanks to Stephen for cranking up a continuous build loop on dory ]
>
> That was actually Heath, who is also trying to work this issue and has
> an idea about something else which might help (and some more information
> about what's happening in the event log).  Adding him to the thread so
> he can (easily) reply with what he's found.
>
> Heath..?
>
> Thanks!
>
> Stephen
>

   So what I noticed after adding the '--force' flag was that in the Event
Viewer logs there was an Error in the System log stating that "The
application-specific permission settings do not grant Local Activation
permission for the COM Server application" for the Runtime Broker.  So
around 2:00 pm today I went and changed the ownership of the registry
values to Administrators so I could add the user we are running the builds
under to the list of members that have access to it.  However right after I
made that change the build was actually broken for me so I am just now
turning the builds back on to run constantly to verify if this has
any effect on the issue of not being able to reattach to the shared
memory.  I am hoping that this makes things more stable, however I am not
confident that these are related.
  The change that I attempted prior to this, which was done last Wednesday,
was to remove the vctip.exe program from being used as this was causing
issues for us as well.  This was causing an Event ID 1530 error that stated
that "The application this is listed in the event details is leaving the
registry handle open" and Windows was helpfully closing any registry values
for that user profile, and I thought that possibly when doing so it was
cleaning up the memory that was allocated prior.  However this did not
change anything for us after making that change.
   Any ideas or changes that we could do to help debug or verify would be
helpful.  We have considered changing it to run everything as SYSTEM but if
possible we would like to avoid this for security reasons.  Thank you in
advance and I appreciate all the help.

-Heath

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.