Initdb problem on debian mips cobalt: Bus error

Glyn Astill wrote:

Hi Chaps,

I'm attempting to run 8.3.3 on an old cobalt qube, with debian etch.
It appeared to compile ok (however I didn't stick around to watch,
that'd be painfull) and said "PostgreSQL compiled successfully and
ready to install" or whatever, but when I run make check, fails in
initdb.

Here is the message and the initdb log file contents showing "bus
error"

http://privatepaste.com/47jTTGw5XC

Looks like a problem trying to determine how much shared memory it can
allocate.

selecting default shared_buffers/max_fsm_pages ... sh: line 1: 22630 Bus
error (core dumped)
"/usr/pgsql_src/postgresql-8.3.3/src/test/regress/tmp_check/install/usr/local/pgsql/bin/postgres"
--boot -x0 -F -c max_connections=10 -c shared_buffers=4096 -c
max_fsm_pages=204800 <"/dev/null" >"/dev/null" 2>&1

Can you support 4096 shared-buffers on this? Afraid I don't know
anything about shared-mem handling on mips, but it might be that the
max-shared-memory detection got something wrong.

--
Richard Huxton
Archonet Ltd

I assume it's doing it correctly

deb:/home/glyn# cat /proc/sys/kernel/shmmax
33554432

That's right isn't it?

4096*8192= 33554432

----- Original Message ----

From: Richard Huxton <dev@archonet.com>
To: Glyn Astill <glynastill@yahoo.co.uk>
Cc: pgsql-general@postgresql.org
Sent: Friday, 18 July, 2008 11:48:39 AM
Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error

Glyn Astill wrote:

Hi Chaps,

I'm attempting to run 8.3.3 on an old cobalt qube, with debian etch.
It appeared to compile ok (however I didn't stick around to watch,
that'd be painfull) and said "PostgreSQL compiled successfully and
ready to install" or whatever, but when I run make check, fails in
initdb.

Here is the message and the initdb log file contents showing "bus
error"

http://privatepaste.com/47jTTGw5XC

Looks like a problem trying to determine how much shared memory it can
allocate.

selecting default shared_buffers/max_fsm_pages ... sh: line 1: 22630 Bus
error (core dumped)
"/usr/pgsql_src/postgresql-8.3.3/src/test/regress/tmp_check/install/usr/local/pgsql/bin/postgres"

--boot -x0 -F -c max_connections=10 -c shared_buffers=4096 -c
max_fsm_pages=204800 <"/dev/null" >"/dev/null" 2>&1

Can you support 4096 shared-buffers on this? Afraid I don't know
anything about shared-mem handling on mips, but it might be that the
max-shared-memory detection got something wrong.

--
Richard Huxton
Archonet Ltd

__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

Glyn Astill wrote:

I assume it's doing it correctly

deb:/home/glyn# cat /proc/sys/kernel/shmmax
33554432

That's right isn't it?

4096*8192= 33554432

Does shmall allow for any more? Other processes may be preventing you
from allocating all that. Of course, ideally you'd get an error message
regarding allocation rather than a bus error.

--
Richard Huxton
Archonet Ltd

Yes I think it does?

deb:/home/glyn# cat /proc/sys/kernel/shmall
2097152

deb:/home/glyn# getconf PAGE_SIZE
4096

----- Original Message ----

From: Richard Huxton <dev@archonet.com>
To: Glyn Astill <glynastill@yahoo.co.uk>
Cc: pgsql-general@postgresql.org
Sent: Friday, 18 July, 2008 12:36:30 PM
Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error

Glyn Astill wrote:

I assume it's doing it correctly

deb:/home/glyn# cat /proc/sys/kernel/shmmax
33554432

That's right isn't it?

4096*8192= 33554432

Does shmall allow for any more? Other processes may be preventing you
from allocating all that. Of course, ideally you'd get an error message
regarding allocation rather than a bus error.

--
Richard Huxton
Archonet Ltd

__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

Glyn Astill wrote:

Yes I think it does?

deb:/home/glyn# cat /proc/sys/kernel/shmall
2097152

deb:/home/glyn# getconf PAGE_SIZE
4096

Well, if it's using PAGE_SIZE then that's 8GB which sounds optimistic
for a qube. Presumably it represents some theoretical maximum.

Did a previous version of PG work on this box?

Actually, does Debian's package of PG (whatever version) work on this box?

--
Richard Huxton
Archonet Ltd

I thought similar, I assumed it was sort sort of generic maximum. The qube is very old so there's only 196Mb ram in it.

Nope, never tried postgres on this qube before. I've not tried debians package, it was 8.1 as I recall.

I'll give the package ago purely as a test unless anyone can see any other reasons for the errors?

I wanted to have 8.3.3 from source on it so I could poke around.

----- Original Message ----

From: Richard Huxton <dev@archonet.com>
To: Glyn Astill <glynastill@yahoo.co.uk>
Cc: pgsql-general@postgresql.org
Sent: Friday, 18 July, 2008 2:09:28 PM
Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error

Glyn Astill wrote:

Yes I think it does?

deb:/home/glyn# cat /proc/sys/kernel/shmall
2097152

deb:/home/glyn# getconf PAGE_SIZE
4096

Well, if it's using PAGE_SIZE then that's 8GB which sounds optimistic
for a qube. Presumably it represents some theoretical maximum.

Did a previous version of PG work on this box?

Actually, does Debian's package of PG (whatever version) work on this box?

--
Richard Huxton
Archonet Ltd

__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

Glyn Astill <glynastill@yahoo.co.uk> writes:

I'm attempting to run 8.3.3 on an old cobalt qube, with debian etch. It appeared to compile ok (however I didn't stick around to watch, that'd be painfull) and said "PostgreSQL compiled successfully and ready to install" or whatever, but when I run make check, fails in initdb.

Here is the message and the initdb log file contents showing "bus error"

Could we see a gdb stack trace from that core dump?

regards, tom lane

Could this be any less informative?

Core was generated by `/usr/pgsql_src/postgresql-8.3.3/src/test/regress/tmp_check/install/usr/local/pg'.
Program terminated with signal 10, Bus error.
#0 0x007572d0 in ?? ()

----- Original Message ----

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Glyn Astill <glynastill@yahoo.co.uk>
Cc: pgsql-general@postgresql.org
Sent: Friday, 18 July, 2008 4:01:23 PM
Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error

Glyn Astill writes:

I'm attempting to run 8.3.3 on an old cobalt qube, with debian etch. It

appeared to compile ok (however I didn't stick around to watch, that'd be
painfull) and said "PostgreSQL compiled successfully and ready to install" or
whatever, but when I run make check, fails in initdb.

Here is the message and the initdb log file contents showing "bus error"

Could we see a gdb stack trace from that core dump?

regards, tom lane

__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

Glyn Astill <glynastill@yahoo.co.uk> writes:

Could this be any less informative?
Core was generated by `/usr/pgsql_src/postgresql-8.3.3/src/test/regress/tmp_check/install/usr/local/pg'.
Program terminated with signal 10, Bus error.
#0 0x007572d0 in ?? ()

Probably not :-(. Did you build with --enable-debug?

regards, tom lane

No. Will recompile with debug info and post back when done.

----- Original Message ----

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Glyn Astill <glynastill@yahoo.co.uk>
Cc: pgsql-general@postgresql.org
Sent: Friday, 18 July, 2008 5:50:05 PM
Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error

Glyn Astill writes:

Could this be any less informative?
Core was generated by

`/usr/pgsql_src/postgresql-8.3.3/src/test/regress/tmp_check/install/usr/local/pg'.

Program terminated with signal 10, Bus error.
#0 0x007572d0 in ?? ()

Probably not :-(. Did you build with --enable-debug?

regards, tom lane

__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

Glyn Astill <glynastill@yahoo.co.uk> writes:

No. Will recompile with debug info and post back when done.

FWIW, the most likely issue here is the MIPS-specific assembly code in
src/include/storage/s_lock.h --- I'm not sure how many MIPS platforms
that's really been exercised on, but it may not work on yours. While
you're waiting for the rebuild you might try to find a MIPS guru to
show that code to.

regards, tom lane

--- On Fri, 7/18/08, Glyn Astill <glynastill@yahoo.co.uk> wrote:

Tom Lane wrote:

Glyn Astill <glynastill@yahoo.co.uk> writes:

No. Will recompile with debug info and post back when done.

FWIW, the most likely issue here is the MIPS-specific assembly code in
src/include/storage/s_lock.h --- I'm not sure how many MIPS platforms
that's really been exercised on, but it may not work on yours. While
you're waiting for the rebuild you might try to find a MIPS guru to
show that code to.

hmm well - lionfish (which is now offline due to a broken power supply)
is actually a cobalt cube too (and is running debian). So if we really
managed to break mipsel it must have happened in the last few months:

http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=lionfish&amp;br=HEAD

Stefan

From: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>

Tom Lane wrote:

Glyn Astill writes:

No. Will recompile with debug info and post back when done.

FWIW, the most likely issue here is the MIPS-specific assembly code in
src/include/storage/s_lock.h --- I'm not sure how many MIPS platforms
that's really been exercised on, but it may not work on yours. While
you're waiting for the rebuild you might try to find a MIPS guru to
show that code to.

hmm well - lionfish (which is now offline due to a broken power supply)
is actually a cobalt cube too (and is running debian). So if we really
managed to break mipsel it must have happened in the last few months:

http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=lionfish&amp;br=HEAD

Stefandumb here

Hmm, well I've still not ruled out the possibility that I've done something stupid yet. Also I see that lionfish is running sarge, and I'm running etch.

Once I get time to recompile I'll try and find out a little more.

Would the mips specific code behave differently on different oses? My other qube is running netbsd4, I'd be interested to see what goes off on that, however I'ts my live email/web/everything server and I didn't want to upset it.

__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

Glyn Astill <glynastill@yahoo.co.uk> writes:

Would the mips specific code behave differently on different oses?

I'm more worried about there being more than one type of MIPS CPU out
there. Do all qubes contain exactly the same sub-architecture?
The references to "mips2" in s_lock.h are attention-getting ...

regards, tom lane

I think so yes.

Qube/Raq2's have a RM5231 in them, whereas the Qube/Raq had a slowere RM5230 with less cache. Then the 3's moved on to the x86 platform.

A recompile with --enable-debug, then rerunning the make check gave me the same backtrace from gdb

----- Original Message ----

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Glyn Astill <glynastill@yahoo.co.uk>
Cc: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>; pgsql-general@postgresql.org
Sent: Saturday, 19 July, 2008 5:42:30 PM
Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error

Glyn Astill writes:

Would the mips specific code behave differently on different oses?

I'm more worried about there being more than one type of MIPS CPU out
there. Do all qubes contain exactly the same sub-architecture?
The references to "mips2" in s_lock.h are attention-getting ...

regards, tom lane

__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

Glyn Astill <glynastill@yahoo.co.uk> writes:

A recompile with --enable-debug, then rerunning the make check gave me the same backtrace from gdb

Did you actually give a "bt" command, or was that just the initial
output from gdb?

Another thing to try is looking around the current instruction pointer:

x/i $pc
x/32i $pc-32

regards, tom lane

Did you actually give a "bt" command, or was that
just the initial
output from gdb?

Yeah I used the bt command, which gave exactly the same output as the initial output. However you'll have to bear with me here, as I am new to gdb, so there is the possibility I'm just not doing things right at all.

Another thing to try is looking around the current
instruction pointer:

x/i $pc
x/32i $pc-32

I've just recompiled again after configuring with --enable-debug, and for completeness here's all the output from gdb:

# gdb /usr/pgsql_src/postgresql-8.3.3/src/test/regress/tmp_check/install/usr/local/pgsql/bin/initdb core
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "mipsel-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

warning: core file may not match specified executable file.
Core was generated by `/usr/pgsql_src/postgresql-8.3.3/src/test/regress/tmp_check/install/usr/local/pg'.
Program terminated with signal 10, Bus error.
#0 0x007572d0 in ?? ()
(gdb) bt
#0 0x007572d0 in ?? ()
warning: GDB can't find the start of the function at 0x7572d0.

GDB is unable to find the start of the function at 0x7572d0
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x7572d0 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
#1 0x007572d0 in ?? ()
warning: GDB can't find the start of the function at 0x7572d0.
Previous frame identical to this frame (corrupt stack?)
(gdb) set heuristic-fence-post 10000000
(gdb) bt
#0 0x007572d0 in ?? ()
warning: GDB can't find the start of the function at 0x7572d0.
#1 0x007572d0 in ?? ()
warning: GDB can't find the start of the function at 0x7572d0.
Previous frame identical to this frame (corrupt stack?)
(gdb) x/i $pc
0x7572d0: Cannot access memory at address 0x7572d0
(gdb) x/32i $pc
0x7572d0: Cannot access memory at address 0x7572d0
(gdb)

__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

Glyn Astill <glynastill@yahoo.co.uk> writes:

I've just recompiled again after configuring with --enable-debug, and for completeness here's all the output from gdb:

# gdb /usr/pgsql_src/postgresql-8.3.3/src/test/regress/tmp_check/install/usr/local/pgsql/bin/initdb core

Well, there's part of your problem: the program that is crashing is not
initdb. Specify the postgres executable, instead. Note the

warning: core file may not match specified executable file.
Core was generated by `/usr/pgsql_src/postgresql-8.3.3/src/test/regress/tmp_check/install/usr/local/pg'.

though this is evidently getting confused by the overly long path,
so you might still see the warning even after picking the right
executable.

regards, tom lane