Re: Re: windows 8 RTM compatibility issue (could not reserve shared memory region for child)

From: Noah Misch <noah(at)leadboat(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Dave Vitek <dvitek(at)grammatech(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>, v-seishi(at)microsoft(dot)com
Subject: Re: Re: windows 8 RTM compatibility issue (could not reserve shared memory region for child)
Date: 2015-06-25 03:22:20
Message-ID: 20150625032220.GA603717@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Jun 24, 2015 at 04:03:53PM +0900, Michael Paquier wrote:
> On Wed, Jun 24, 2015 at 12:29 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > On Wed, Jun 24, 2015 at 10:06:00AM +0900, Michael Paquier wrote:
> >> > On Tue, Sep 04, 2012 at 11:45:47PM -0400, Dave Vitek wrote:
> >> >> LOG: could not reserve shared memory region (addr=0000000001410000) for child
> >> >> 0000000000000F8C: 487
> >> >> LOG: could not fork new process for connection: A blocking operation was
> >> >> interrupted by a call to WSACancelBlockingCall.
> >
> >> So, it happens that it is still possible to hit this issue on at least
> >> Win2k12 boxes (received some complaints about that) even if
> >> RandomizedBaseAddress is disabled in build, as per a result of the
> >> following thread:
> >> http://www.postgresql.org/message-id/BD0D89EC2438455C9DE0DC94D36912F4@maumau
> >
> > That report led to the RandomizedBaseAddress="FALSE" commit, so the report was
> > not based on such a build. If you have received complaints definitively
> > involving a RandomizedBaseAddress="FALSE" build, that is novel evidence. If
> > these complaints involved publicly-available binaries, which exact binaries
> > (download URL)? If not, what do you know about how the binaries were built?
>
> They are not publicly available, but the build is done using the
> community perl scripts with Visual 2008, with a slight difference
> though in the VC spec file, AdditionalOptions includes /DLL to tell
> the linker to build DLLs, but I don't think that it is much related to
> the failure except if I am missing a crucial piece of information
> regarding Visual.

Here are some of the things I would try, then:

- Reproduce it with postgresql.org official binaries.
- Run "dumpbin /headers" on postgres.exe and every dll it links at startup,
including dependencies. Compare to the corresponding data from
postgresql.org official binaries.
- Rebuild with VS2013 and see if the problem persists.
- Identify the allocation(s) overlapping the region needed for shared memory.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message hunkaverage 2015-06-25 06:07:20 BUG #13468: System hijacked by PostgreSQL user
Previous Message David G. Johnston 2015-06-25 00:49:25 Re: BUG #13465: multi update query use CTE, result & plan not equal, BUG?