Horton

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

Thomas Munro <thomas.munro@enterprisedb.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Noah Misch <noah@leadboat.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Heath Lord <heath.lord@crunchydata.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-05-01T03:52:34Z
Lists: pgsql-hackers 
On Tue, May 1, 2018 at 2:59 PM, Noah Misch <noah@leadboat.com> wrote:
> Likely some privileged daemon is creating a thread in every new process.  (On
> Windows, it's not unusual for one process to create a thread in another
> process.)  We don't have good control over that.

Huh.  I was already amazed (as a non-Windows user) by the DSM code
that duplicates file handles into the postmaster process without its
cooperation, but starting threads is even more amazing.
Apparently debuggers do that.  Could this be running in some kind of
debugger-managed environment or build, perhaps as a result of some
core dump capturing mode or something?

https://msdn.microsoft.com/en-us/library/windows/desktop/dd405484(v=vs.85).aspx

Apparently another way to mess with another process's memory map is
via "Asynchronous Procedure Calls":

http://blogs.microsoft.co.il/pavely/2017/03/14/injecting-a-dll-without-a-remote-thread/

It looks like that mechanism could allow something either in our own
process (perhaps some timer-related thing that we might have set up
ourselves or might be set up by the system?) or another process to
queue actions for our own thread to run at certain points.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms681951(v=vs.85).aspx

-- 
Thomas Munro
http://www.enterprisedb.com

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.