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

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: "could not reattach to shared memory" on buildfarm member dory
Дата
Msg-id CAEepm=2Fzs4yEcAzVM5FLo7QihrZ99+zVYpdn_2Jym2Qc7G_KQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: "could not reattach to shared memory" on buildfarm member dory  (Noah Misch <noah@leadboat.com>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: "could not reattach to shared memory" on buildfarm member dory
Следующее
От: Tom Lane
Дата:
Сообщение: Re: "could not reattach to shared memory" on buildfarm member dory