FW: getting a crash during initdb

Started by Merlin Moncureover 21 years ago11 messages
#1Merlin Moncure
merlin.moncure@rcsonline.com

[sorry for the repost...lists down? Problem may or may not be on win32
version only]
The catalog number was updated, so it was time to run initdb.

Sometime over the weekend (or since the last initdb I ran, about a
week), the source was updated which caused an AV & CRASH during
initdb...specifically during pg_depend step. Also, after initdb fails,
the files are removed but the folders are not, causing subsequent
attempts to initdb not to work...is this the expected hehavior?

Here is the log:

H:\>initdb
The files belonging to this database system will be owned by user
"Merlin.Moncure".
This user must also own the server process.

The database cluster will be initialized with locale C.

fixing permissions on existing directory c:/postgres/data ... ok
creating directory c:/postgres/data/global ... ok
creating directory c:/postgres/data/pg_xlog ... ok
creating directory c:/postgres/data/pg_clog ... ok
creating directory c:/postgres/data/base ... ok
creating directory c:/postgres/data/base/1 ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 1000
creating configuration files ... ok
creating template1 database in c:/postgres/data/base/1 ... ok
initializing pg_shadow ... ok
enabling unlimited row size for system tables ... ok
initializing pg_depend [CRASH]... initdb: child process was terminated
by signal 5
initdb: failed
initdb: removing contents of data directory "c:/postgres/data"
Deleted file - c:\postgres\data\pg_hba.conf
[...]

Merlin

#2Andrew Dunstan
andrew@dunslane.net
In reply to: Merlin Moncure (#1)
Re: FW: getting a crash during initdb

Merlin Moncure wrote:

[sorry for the repost...lists down? Problem may or may not be on win32
version only]
The catalog number was updated, so it was time to run initdb.

Sometime over the weekend (or since the last initdb I ran, about a
week), the source was updated which caused an AV & CRASH during
initdb...specifically during pg_depend step. Also, after initdb fails,
the files are removed but the folders are not, causing subsequent
attempts to initdb not to work...is this the expected hehavior?

No. The code currently does this on Windows:

snprintf(buf, sizeof(buf), "%s /s /q \"%s\"",
rmtopdir ? "rmdir" : "del", path);
system(buf);

Originally I had a builtin routine (see
http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/bin/initdb/initdb.c?rev=1.1&content-type=text/x-cvsweb-markup
) but Bruce felt shelling out to rm/rmdir/del was easier. I guess this
needs tweaking a bit.

I have no idea what caused the pg_depend stuff to crash.

cheers

andrew

#3Merlin Moncure
merlin.moncure@rcsonline.com
In reply to: Andrew Dunstan (#2)
Re: FW: getting a crash during initdb

I have no idea what caused the pg_depend stuff to crash.

The AV is in postgres.exe following the first SQL call in
setup_depend(). The problem is not in initdb (it hasn't changed) but
something in the backend. Changing the SQL statement made no
difference: I'd venture a guess that postgres.exe crashes when *any*
statement is sent to it. About 20 files have changed since my last
initdb; I have a list. Forced initdb + initdb crash = nasty bug, even
if it's just the cvs version (specific only to windows?).

I'll check why the rmdir command is not working as expected.

Merlin

#4Alvaro Herrera
alvherre@dcc.uchile.cl
In reply to: Merlin Moncure (#3)
Re: FW: getting a crash during initdb

On Mon, Apr 26, 2004 at 11:37:37AM -0400, Merlin Moncure wrote:

I have no idea what caused the pg_depend stuff to crash.

The AV is in postgres.exe following the first SQL call in
setup_depend(). The problem is not in initdb (it hasn't changed) but
something in the backend. Changing the SQL statement made no
difference: I'd venture a guess that postgres.exe crashes when *any*
statement is sent to it. About 20 files have changed since my last
initdb; I have a list. Forced initdb + initdb crash = nasty bug, even
if it's just the cvs version (specific only to windows?).

I've initdb'd more than twenty times with CVS tip code, so it would seem
to be Windows-specific.

Are you sure you're using a clean build and a really current checkout?

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"El miedo atento y previsor es la madre de la seguridad" (E. Burke)

#5Merlin Moncure
merlin.moncure@rcsonline.com
In reply to: Alvaro Herrera (#4)
Re: FW: getting a crash during initdb

Alvaro Herrera wrote:

The AV is in postgres.exe following the first SQL call in
setup_depend(). The problem is not in initdb (it hasn't changed)

but

something in the backend. Changing the SQL statement made no
difference: I'd venture a guess that postgres.exe crashes when *any*
statement is sent to it. About 20 files have changed since my last
initdb; I have a list. Forced initdb + initdb crash = nasty bug,

even

if it's just the cvs version (specific only to windows?).

I've initdb'd more than twenty times with CVS tip code, so it would

seem

to be Windows-specific.

Thought as much. I posted to the win32 list but it hasn't shown up yet.

Are you sure you're using a clean build and a really current checkout?

Yes, 100%.
Merlin

#6Bruce Momjian
pgman@candle.pha.pa.us
In reply to: Merlin Moncure (#3)
Re: FW: getting a crash during initdb

Merlin Moncure wrote:

I have no idea what caused the pg_depend stuff to crash.

The AV is in postgres.exe following the first SQL call in
setup_depend(). The problem is not in initdb (it hasn't changed) but
something in the backend. Changing the SQL statement made no
difference: I'd venture a guess that postgres.exe crashes when *any*
statement is sent to it. About 20 files have changed since my last
initdb; I have a list. Forced initdb + initdb crash = nasty bug, even
if it's just the cvs version (specific only to windows?).

I'll check why the rmdir command is not working as expected.

I just poked around and couldn't figure out the cause. Initdb should
either remove the directory if it created it, or remove everything _in_
the directory if the directory already existed. I tried the rmdir/del
/s /q commands in a CMD window and it worked fine.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#7Merlin Moncure
merlin.moncure@rcsonline.com
In reply to: Bruce Momjian (#6)
Re: FW: getting a crash during initdb

I'll check why the rmdir command is not working as expected.

I just poked around and couldn't figure out the cause. Initdb should
either remove the directory if it created it, or remove everything

_in_

the directory if the directory already existed. I tried the rmdir/del
/s /q commands in a CMD window and it worked fine.

Problem is backslash issue :) initdb is issuing del /s /q
"c:/postgres/data".

Is there a library command to properly resolve slashes?

Merlin

#8Bruce Momjian
pgman@candle.pha.pa.us
In reply to: Merlin Moncure (#7)
Re: FW: getting a crash during initdb

Merlin Moncure wrote:

I'll check why the rmdir command is not working as expected.

I just poked around and couldn't figure out the cause. Initdb should
either remove the directory if it created it, or remove everything

_in_

the directory if the directory already existed. I tried the rmdir/del
/s /q commands in a CMD window and it worked fine.

Problem is backslash issue :) initdb is issuing del /s /q
"c:/postgres/data".

Is there a library command to properly resolve slashes?

Uh, I just testd this using CMD and it worked:

rmdir /s /q "C:/TMP/TMP"

The quotes are required, but are in the code:

snprintf(buf, sizeof(buf), "%s /s /q \"%s\"",
rmtopdir ? "rmdir" : "del", path);

However, I have no problem with pulling his rmdir C code back out of CVS
and implementing it. I think it might come in as part of tablespaces
anyway so I was just waiting to see how things shook out. If we do it,
it would go into /port along with copdir/dp for directories.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
#9Merlin Moncure
merlin.moncure@rcsonline.com
In reply to: Bruce Momjian (#8)
Re: FW: getting a crash during initdb

Bruce Momjian wrote:

Merlin Moncure wrote:

I'll check why the rmdir command is not working as expected.

I just poked around and couldn't figure out the cause. Initdb

should

either remove the directory if it created it, or remove everything

_in_

the directory if the directory already existed. I tried the

rmdir/del

/s /q commands in a CMD window and it worked fine.

Problem is backslash issue :) initdb is issuing del /s /q
"c:/postgres/data".

Is there a library command to properly resolve slashes?

Uh, I just testd this using CMD and it worked:

Yes, you are correct, I was jumping to conclusions. What's really
strange is now initdb is properly cleaning up the folders. I examined
my previous logs and apparently the value of rmtopdir parameter to
rmtree was wrong...
Note my previous initdb log said removing contents of ... (now says
removing ...)

Some more checking turns out it is all hooking on the return val of
check_data_dir...perhaps the condition was hooking if I had the folder
open in another window...so no worries there. Still having the problems
with initdb.

Merlin

#10Merlin Moncure
merlin.moncure@rcsonline.com
In reply to: Merlin Moncure (#9)
Re: FW: getting a crash during initdb

make clean appears to have fixed the initdb crash :)
sorry to bother... :)

Merlin

#11Bruce Momjian
pgman@candle.pha.pa.us
In reply to: Merlin Moncure (#10)
Re: FW: getting a crash during initdb

Merlin Moncure wrote:

make clean appears to have fixed the initdb crash :)
sorry to bother... :)

Are you sure you're using a clean build and a really current checkout?

Yes, 100%.

Care to update that percentage? :-)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073