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 http://www.enterprisedb.com
fix-subxip.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
