Обсуждение: initdb segfaulting.
============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================
Your name : Rudolf Lippan
Your email address : rlippan@remotelinux.com
System Configuration
---------------------
Architecture (example: Intel Pentium) : PII-400x4
Operating System (example: Linux 2.0.26 ELF) : 2.4.19-gentoo-r9
PostgreSQL version (example: PostgreSQL-7.3): PostgreSQL-7.3
Compiler used (example: gcc 2.95.2) : gcc 2.95.3
Please enter a FULL description of your problem:
------------------------------------------------
initdb (postmaster) segfaults. It seems that if I don't set the system's
timezone, postmaster does a li'le fandango on core. Pg 7.2.3 work fine.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------
postgres@war PGDATA $ date
Sat Dec 14 02:12:00 Local time zone must be set--see zic manual page 2002
And run initdb. Here is output from both runs of initdb:
postgres@war PGDATA $ ../pgsql7.3/bin/initdb
The files belonging to this database system will be owned by user
"postgres".
This user must also own the server process.
The database cluster will be initialized with locale C.
creating directory /usr/local/PGDATA/pgsql7.3... ok
creating directory /usr/local/PGDATA/pgsql7.3/base... ok
creating directory /usr/local/PGDATA/pgsql7.3/global... ok
creating directory /usr/local/PGDATA/pgsql7.3/pg_xlog... ok
creating directory /usr/local/PGDATA/pgsql7.3/pg_clog... ok
creating template1 database in /usr/local/PGDATA/pgsql7.3/base/1...
../pgsql7.3/bin/initdb: line 582: 9491 Segmentation fault
"$PGPATH"/postgres -boot -x1 $PGSQL_OPT $BACKEND_TALK_ARG template1
initdb failed.
Removing /usr/local/PGDATA/pgsql7.3.
==============
postgres@war PGDATA $ TZ=EST ../pgsql7.3/bin/initdb
The files belonging to this database system will be owned by user
"postgres".
This user must also own the server process.
The database cluster will be initialized with locale C.
creating directory /usr/local/PGDATA/pgsql7.3... ok
creating directory /usr/local/PGDATA/pgsql7.3/base... ok
creating directory /usr/local/PGDATA/pgsql7.3/global... ok
creating directory /usr/local/PGDATA/pgsql7.3/pg_xlog... ok
creating directory /usr/local/PGDATA/pgsql7.3/pg_clog... ok
creating template1 database in /usr/local/PGDATA/pgsql7.3/base/1... ok
creating configuration files... ok
initializing pg_shadow... ok
enabling unlimited row size for system tables... ok
initializing pg_depend... ok
creating system views... ok
loading pg_description... ok
creating conversions... ok
setting privileges on built-in objects... ok
vacuuming database template1... ok
copying template1 to template0... ok
Success. You can now start the database server using:
../pgsql7.3/bin/postmaster -D /usr/local/PGDATA/pgsql7.3
or
../pgsql7.3/bin/pg_ctl -D /usr/local/PGDATA/pgsql7.3 -l logfile start
If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------
Rudy Lippan <rlippan@remotelinux.com> writes:
> postgres@war PGDATA $ date
> Sat Dec 14 02:12:00 Local time zone must be set--see zic manual page 2002
You've got a moderately broken platform there, IMHO. Everyone else in
the world defaults to GMT behavior if no recognizable timezone is set.
But if you can provide a stack trace showing just where the backend is
choking, we could try to defend against this.
regards, tom lane
On Wed, 11 Dec 2002, Tom Lane wrote: > Rudy Lippan <rlippan@remotelinux.com> writes: > > postgres@war PGDATA $ date > > Sat Dec 14 02:12:00 Local time zone must be set--see zic manual page 2002 > > You've got a moderately broken platform there, IMHO. Everyone else in > the world defaults to GMT behavior if no recognizable timezone is set. I don't know about that. I just screwed up the time zone when setting up the system, and keep forgetting to fix it -- it acts as if it is set to GMT; however, the timezone name indicates that you have not configured the timezone on your system. I submitted the bug because I thought it might be indicative of a larger problem. IMO segfault == bug. And there is that tendency for bugs to live together. > But if you can provide a stack trace showing just where the backend is > choking, we could try to defend against this. > #0 0x0811bac8 in AtEOXact_Buffers (isCommit=1 '\001') at bufmgr.c:914 914 if (PrivateRefCount[i] != 0) (gdb) bt #0 0x0811bac8 in AtEOXact_Buffers (isCommit=1 '\001') at bufmgr.c:914 #1 0x08087980 in CommitTransaction () at xact.c:1018 #2 0x08087c52 in CommitTransactionCommand (forceCommit=1) at xact.c:1304 #3 0x0808cf04 in do_end () at bootparse.y:66 #4 0x0808d231 in Int_yyparse () at bootparse.y:143 #5 0x0808ef68 in BootstrapMain (argc=7, argv=0x823dbe4) at bootstrap.c:445 #6 0x080e94a1 in main (argc=8, argv=0xbffffcd4) at main.c:218 #7 0x401c2671 in __libc_start_main () from /lib/libc.so.6 (gdb) print i $1 = 59320 (gdb) print NBuffers $2 = 762602867 ================= Update: Just thought to play with this a bit more and: TZ="AAAAAAAAAAAAAAAAAAAAAAAAAA" ../pgsql7.3/bin/initdb <-- segfault TZ="AAAAAAAAAAAAAAAAAAAAAAAAA" ../pgsql7.3/bin/initdb <-- initdb failed TZ="AAAAAAAAAAAAAAAAAAAAAAAA" ../pgsql7.3/bin/initdb <-- works. Looks like a simple buffer overrun. -r
Rudy Lippan <rlippan@remotelinux.com> writes:
> Just thought to play with this a bit more and:
> TZ="AAAAAAAAAAAAAAAAAAAAAAAAAA" ../pgsql7.3/bin/initdb <-- segfault
> TZ="AAAAAAAAAAAAAAAAAAAAAAAAA" ../pgsql7.3/bin/initdb <-- initdb failed
> TZ="AAAAAAAAAAAAAAAAAAAAAAAA" ../pgsql7.3/bin/initdb <-- works.
> Looks like a simple buffer overrun.
Yeah, I think so. I cannot replicate a problem here, but that may just
be a matter of how the linker chose to lay out static variables in my
build. Please apply the attached patch against 7.3 and see if it fixes
things for you.
regards, tom lane
*** src/backend/utils/adt/nabstime.c.orig Mon Nov 11 19:39:36 2002
--- src/backend/utils/adt/nabstime.c Thu Dec 12 14:17:04 2002
***************
*** 130,143 ****
* XXX FreeBSD man pages indicate that this should work - thomas
* 1998-12-12
*/
! strcpy(CTZName, tm->tm_zone);
#elif defined(HAVE_INT_TIMEZONE)
tm = localtime(&now);
CDayLight = tm->tm_isdst;
CTimeZone = ((tm->tm_isdst > 0) ? (TIMEZONE_GLOBAL - 3600) : TIMEZONE_GLOBAL);
! strcpy(CTZName, tzname[tm->tm_isdst]);
#else /* neither HAVE_TM_ZONE nor
* HAVE_INT_TIMEZONE */
CTimeZone = tb.timezone * 60;
--- 130,143 ----
* XXX FreeBSD man pages indicate that this should work - thomas
* 1998-12-12
*/
! StrNCpy(CTZName, tm->tm_zone, MAXTZLEN+1);
#elif defined(HAVE_INT_TIMEZONE)
tm = localtime(&now);
CDayLight = tm->tm_isdst;
CTimeZone = ((tm->tm_isdst > 0) ? (TIMEZONE_GLOBAL - 3600) : TIMEZONE_GLOBAL);
! StrNCpy(CTZName, tzname[tm->tm_isdst], MAXTZLEN+1);
#else /* neither HAVE_TM_ZONE nor
* HAVE_INT_TIMEZONE */
CTimeZone = tb.timezone * 60;
***************
*** 212,225 ****
* XXX FreeBSD man pages indicate that this should work - thomas
* 1998-12-12
*/
! strcpy(CTZName, tm->tm_zone);
#elif defined(HAVE_INT_TIMEZONE)
tm = localtime(&now);
CDayLight = tm->tm_isdst;
CTimeZone = ((tm->tm_isdst > 0) ? (TIMEZONE_GLOBAL - 3600) : TIMEZONE_GLOBAL);
! strcpy(CTZName, tzname[tm->tm_isdst]);
#else /* neither HAVE_TM_ZONE nor
* HAVE_INT_TIMEZONE */
CTimeZone = tb.timezone * 60;
--- 212,225 ----
* XXX FreeBSD man pages indicate that this should work - thomas
* 1998-12-12
*/
! StrNCpy(CTZName, tm->tm_zone, MAXTZLEN+1);
#elif defined(HAVE_INT_TIMEZONE)
tm = localtime(&now);
CDayLight = tm->tm_isdst;
CTimeZone = ((tm->tm_isdst > 0) ? (TIMEZONE_GLOBAL - 3600) : TIMEZONE_GLOBAL);
! StrNCpy(CTZName, tzname[tm->tm_isdst], MAXTZLEN+1);
#else /* neither HAVE_TM_ZONE nor
* HAVE_INT_TIMEZONE */
CTimeZone = tb.timezone * 60;