BUG #8782: Segmentation Fault during initialization
The following bug has been logged on the website:
Bug reference: 8782
Logged by: Luke Campbell
Email address: lcampbell@asascience.com
PostgreSQL version: 9.3.1
Operating system: Centos 6.5
Description:
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:
#0 0x000000000085b246 in palloc (size=1024) at mcxt.c:647
647 CurrentMemoryContext->isReset = false;
(gdb) bt
#0 0x000000000085b246 in palloc (size=1024) at mcxt.c:647
#1 0x0000000000625750 in initStringInfo (str=0x7fff1c878c10) at
stringinfo.c:50
#2 0x0000000000837d5b in expand_fmt_string (fmt=0x9c51b0 "could not change
directory to \"%s\": %s", edata=0xc9d680) at elog.c:2886
#3 0x0000000000834e00 in elog_finish (elevel=15, fmt=0x9c51b0 "could not
change directory to \"%s\": %s") at elog.c:1288
#4 0x0000000000875796 in resolve_symlinks (path=0x7fff1c87a2e0
"/opt/postgresql-9.3.1/bin/postgres") at exec.c:293
#5 0x000000000087527f in find_my_exec (argv0=0x1989a60
"/opt/postgresql-9.3.1/bin/postgres", retpath=0x7fff1c87a2e0
"/opt/postgresql-9.3.1/bin/postgres") at exec.c:144
#6 0x0000000000875b1c in set_pglocale_pgservice (argv0=0x1989a60
"/opt/postgresql-9.3.1/bin/postgres", app=0x959448 "postgres-9.3") at
exec.c:561
#7 0x0000000000636a56 in main (argc=3, argv=0x1989a30) at main.c:
The server was compiled with:
$ CFLAGS=-ggdb PYTHON=/usr/local/bin/python ./configure --enable-debug
--prefix=/opt/postgresql-9.3.1 --enable-thread-safety --with-gssapi
--with-openssl --with-libxml --with-libxslt --with-python
No errors during make or make install
Additional assessments, speculation and developer commentary can be found
at:
https://gist.github.com/lukecampbell/8363139
For more information or environment information please contact me at
lcampbell@asascience.com
Thanks!
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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:
/messages/by-id/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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers