Re: any suggestions to detect memory corruption
От | Alex |
---|---|
Тема | Re: any suggestions to detect memory corruption |
Дата | |
Msg-id | CAKU4AWofge-TygReXWM5RH0c5SXBBqWX9FhJBcqZpeqzCOvVyA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: any suggestions to detect memory corruption (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, May 9, 2019 at 9:30 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alex <zhihui.fan1213@gmail.com> writes:
> Someone add some code during backend init which used palloc. but at that
> time, the CurrentMemoryContext is PostmasterContext. at the end of
> backend initialization, the PostmasterContext is deleted, then the error
> happens. the reason why it happens randomly is before the palloc, there
> are some other if clause which may skip the palloc.
> I still can't explain why PostmasterContext may have impact "index info"
> MemoryContext sometime, but now I just can't reproduce it (before the
> fix, it may happen in 30% cases).
Well, once the context is deleted, that memory is available for reuse.
Everything will seem fine until it *is* reused, and then boom!
The error would have been a lot more obvious if you'd enabled
MEMORY_CONTEXT_CHECKING, which would overwrite freed data with garbage.
Thanks! I didn't know this before and " once the context is deleted, that memory is available for reuse.
Everything will seem fine until it *is* reused". I have enabled enable-cassert now. That is normally turned on in --enable-cassert builds. Anybody who's been
hacking Postgres for more than a week does backend code development in
--enable-cassert mode as a matter of course; it turns on a *lot* of
helpful cross-checks.
regards, tom lane
В списке pgsql-hackers по дате отправления: