Re: LOG: munmap(0x7fff80000000) failed: Invalid argument

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Chris Richards <chris(at)infinite(dot)io>, pgsql-general(at)postgresql(dot)org
Subject: Re: LOG: munmap(0x7fff80000000) failed: Invalid argument
Date: 2016-10-11 00:45:40
Message-ID: 23429.1476146740@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2016-10-10 18:21:48 -0400, Tom Lane wrote:
>> Chris Richards <chris(at)infinite(dot)io> writes:
>>> LOG: munmap(0x7fff80000000) failed: Invalid argument

>> [ digs in code... ] One theory is that PGSharedMemoryDetach is getting
>> called more than once, but I'm not sure how that would happen. Can you
>> characterize where this happens more precisely? What nondefault settings
>> have you got in postgresql.conf?

> Hm. Could that be from the DSM code?

That particular error message spelling only appears in sysv_shmem.c,
so it's not directly DSM's fault.

The comments around PGSharedMemoryDetach strongly suggest that it ought
to be a no-op if called twice, which it originally was but fails to be
since the addition of the munmap call. So I'm *very* strongly tempted
to add "AnonymousShmem = NULL;" there and in IpcMemoryDetach. But
it's not evident why we've not seen this behavior many times already,
so I'd kind of like to find out what's different about Chris's use-case
before assuming that that will fix it.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Periko Support 2016-10-11 00:45:55 Re: [SPAM] psql 9.3 automatic recovery in progress
Previous Message Andres Freund 2016-10-11 00:32:09 Re: LOG: munmap(0x7fff80000000) failed: Invalid argument