Re: [sqlsmith] crashes in RestoreSnapshot on hot standby
От | Thomas Munro |
---|---|
Тема | Re: [sqlsmith] crashes in RestoreSnapshot on hot standby |
Дата | |
Msg-id | CAEepm=1Xft6DYXmR7Z2qQoRweCUJ8r6_eUMnQaM1c0SCXVGprg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [sqlsmith] crashes in RestoreSnapshot on hot standby (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [sqlsmith] crashes in RestoreSnapshot on hot standby
|
Список | pgsql-hackers |
On Fri, Jul 1, 2016 at 2:17 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Fri, Jul 1, 2016 at 6:26 AM, Andreas Seltenreich <seltenreich@gmx.de> wrote: >> #1 0x0000000000822032 in RestoreSnapshot (start_address=start_address@entry=0x7f2701d5a110 <error: Cannot access memoryat 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
Вложения
В списке pgsql-hackers по дате отправления: