Thread: Re: [BUGS] BUG #8782: Segmentation Fault during initialization

lcampbell@asascience.com writes:
> While attempting to initialize the server as a "postgres" user with:
> sudo -u postgres /opt/postgresql-9.3.1/bin/initdb /var/postgres
> A segmentation fault occurred.  Here's the stack trace from gdb:

This looks to be some variant of the problem discussed here:
http://www.postgresql.org/message-id/flat/20131003161139.GA28301@awork2.anarazel.de

namely that set_pglocale_pgservice calls code that assumes it can
report any failures via elog/ereport --- but the necessary infrastructure
for that hasn't been set up yet.  We didn't come to any consensus about
what to do in that thread, so let's try again.

Seems to me there are three feasible possibilities:

1. Rewrite/duplicate code to the point that set_pglocale_pgservice doesn't
depend on any code that assumes standard backend error handling.

2. Move the set_pglocale_pgservice() call to after we've done
MemoryContextInit().

3. Move the MemoryContextInit() call to before set_pglocale_pgservice().

Of these, I think #1 can be rejected: not only would it be ugly as sin,
but I can pretty much guarantee that somebody would break it again in
future.  It's too easy to call $random_function without thinking about
what the error handling consequences would be.

#2 is somewhat undesirable because there are multiple calls of
MemoryContextInit and thus we'd end up with multiple calls of
set_pglocale_pgservice.

#3 is not too nice either, because it would mean calling MemoryContextInit
in main.c which doesn't seem like a great place for it.  On the other
hand, there is a whole lot of rather random junk getting called from
main.c; who wants to bet that none of the rest of it can call elog(),
either now or in the future?

After a few moments' thought, I lean a bit towards #3, but it's a
weakly held position.  Anyone have other ideas?

One other point here is that I'm pretty sure MemoryContextInit itself
will try to elog() if it fails.  I don't know if it's worth trying
to unwind that circularity.  As long as we do it early enough, the
odds of failure should be about negligible --- certainly I don't
recall ever seeing a report of a crash there.

Possibly it'd be worth having some check in elog.c that ErrorContext has
been created, with a very simple "print some fixed text to stderr and die"
behavior if not.  That would at least be more useful than a bare crash.

Comments?
        regards, tom lane

On Fri, Jan 10, 2014 at 09:10:47PM -0500, Tom Lane wrote:
> 3. Move the MemoryContextInit() call to before set_pglocale_pgservice().

> #3 is not too nice either, because it would mean calling MemoryContextInit
> in main.c which doesn't seem like a great place for it.  On the other
> hand, there is a whole lot of rather random junk getting called from
> main.c; who wants to bet that none of the rest of it can call elog(),
> either now or in the future?
> 
> After a few moments' thought, I lean a bit towards #3, but it's a
> weakly held position.  Anyone have other ideas?

I, too, would pick #3.  Not much has reason to run before MemoryContextInit();
the only candidate that comes to mind is pgwin32_install_crashdump_handler().

> One other point here is that I'm pretty sure MemoryContextInit itself
> will try to elog() if it fails.  I don't know if it's worth trying
> to unwind that circularity.  As long as we do it early enough, the
> odds of failure should be about negligible --- certainly I don't
> recall ever seeing a report of a crash there.
> 
> Possibly it'd be worth having some check in elog.c that ErrorContext has
> been created, with a very simple "print some fixed text to stderr and die"
> behavior if not.  That would at least be more useful than a bare crash.

Not sure about what more to do here.

Thanks,
nm

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com