Re: any suggestions to detect memory corruption

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alex <zhihui(dot)fan1213(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: any suggestions to detect memory corruption
Date: 2019-05-09 13:30:12
Message-ID: 2051.1557408612@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alex <zhihui(dot)fan1213(at)gmail(dot)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.
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-09 13:41:16 Re: Fuzzy thinking in is_publishable_class
Previous Message Karl O. Pinc 2019-05-09 13:27:53 Re: Patch to document base64 encoding