On Fri, Jul 1, 2016 at 2:17 PM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Fri, Jul 1, 2016 at 6:26 AM, Andreas Seltenreich <seltenre...@gmx.de> 
> wrote:
>> #1  0x0000000000822032 in RestoreSnapshot 
>> (start_address=start_address@entry=0x7f2701d5a110 <error: Cannot access 
>> memory at address 0x7f2701d5a110>) at snapmgr.c:2020
>         memcpy(snapshot->subxip, serialized_xids + serialized_snapshot->xcnt,
>                serialized_snapshot->subxcnt * sizeof(TransactionId));
> So this is choking here? Is one of those pointers NULL?

Theory 1:
If serialized_snapshot->xcnt == 0, then snapshot->xip never gets
initialized to a non-NULL value.  Then if serialized_snapshot->subxcnt
> 0, we set snapshot->subxip = snapshot->xip +
serialized_snapshot->xcnt (so that's NULL too).  Then in line the line
you show we call memcpy(snapshot->subxip, ...).  The fix might be
something like the attached.

Theory 2:
The DSM segment was deleted underneath us.  We can see that it was not
mapped by the time GDB dumped that (start_address is not accessible).

Theory 3:
Somehow the xcnt or xsubcnt was wrong or the serialized snapshot was
truncated, and we read past the end of the DSM, who knows...

Thomas Munro

Attachment: fix-subxip.patch
Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to