Обсуждение: 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!
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