Thread: Initdb problem on debian mips cobalt: Bus error
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 aroundto watch, that'd be painfull) and said "PostgreSQL compiled successfully and ready to install" or whatever, but whenI run make check, fails in initdb. Here is the message and the initdb log file contents showing "bus error" http://privatepaste.com/47jTTGw5XC I've configured it as I usually do "./configure --with-perl --with-python --with-tcl --with-openssl --with-pam --with-krb5". Of course running on a more obscure machine I don't expect too much to be honest, but does anyone have any ideas? Perhaps the kernel is missing support for something? Thanks Glyn __________________________________________________________ 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: > 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
stickaround to watch, that'd be painfull) and said "PostgreSQL compiled successfully and ready to install" or whatever,
butwhen 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: > From: Glyn Astill <glynastill@yahoo.co.uk> > Subject: [GENERAL] Initdb problem on debian mips cobalt: Bus error > To: pgsql-general@postgresql.org > Date: Friday, July 18, 2008, 10:26 AM > 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 >> the user ho execute the command initdb have owner to the directory where the cluster was create >> check the owner from the directory and permission > > I've configured it as I usually do "./configure > --with-perl --with-python --with-tcl --with-openssl > --with-pam --with-krb5". > > Of course running on a more obscure machine I don't > expect too much to be honest, but does anyone have any > ideas? > > Perhaps the kernel is missing support for something? > > Thanks > Glyn > > > > > __________________________________________________________ > 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 > > -- > Sent via pgsql-general mailing list > (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general
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&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&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 runningsarge, 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 tosee 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
thex86 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
mehere, 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
> 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'.
>
Ok, that helps a bit and the output now looks a little more useful:
Program terminated with signal 10, Bus error.
#0 InitializeGUCOptions () at guc.c:3133
3133 if (new_limit > 100)
(gdb) bt
#0 InitializeGUCOptions () at guc.c:3133
#1 0x004a1ec8 in AuxiliaryProcessMain (argc=4, argv=<value optimized out>)
at bootstrap.c:230
#2 0x005979a8 in main (argc=4, argv=<value optimized out>) at main.c:147
(gdb)
So, guc.c:3133 is doing something to try and set stack depth.... And I've no idea what I'm looking for unfortunately.
And, the instruction pointer info:
(gdb) x/i $pc
0x7572d0 <InitializeGUCOptions+648>:
beqz v0,0x75748c <InitializeGUCOptions+1092>
(gdb) x/32i $pc-32
0x7572b0 <InitializeGUCOptions+616>:
blez v0,0x7572d8 <InitializeGUCOptions+656>
0x7572b4 <InitializeGUCOptions+620>: move v1,v0
0x7572b8 <InitializeGUCOptions+624>: lui v0,0xfff8
0x7572bc <InitializeGUCOptions+628>: addu v0,v1,v0
0x7572c0 <InitializeGUCOptions+632>:
bltz v0,0x75753c <InitializeGUCOptions+1268>
0x7572c4 <InitializeGUCOptions+636>: nop
0x7572c8 <InitializeGUCOptions+640>: sra a2,v0,0xa
0x7572cc <InitializeGUCOptions+644>: slti v0,a2,101
0x7572d0 <InitializeGUCOptions+648>:
beqz v0,0x75748c <InitializeGUCOptions+1092>
0x7572d4 <InitializeGUCOptions+652>: slti v0,a2,2049
0x7572d8 <InitializeGUCOptions+656>: lw ra,84(sp)
0x7572dc <InitializeGUCOptions+660>: lw s8,80(sp)
0x7572e0 <InitializeGUCOptions+664>: lw s7,76(sp)
0x7572e4 <InitializeGUCOptions+668>: lw s6,72(sp)
0x7572e8 <InitializeGUCOptions+672>: lw s5,68(sp)
0x7572ec <InitializeGUCOptions+676>: lw s4,64(sp)
0x7572f0 <InitializeGUCOptions+680>: lw s3,60(sp)
0x7572f4 <InitializeGUCOptions+684>: lw s2,56(sp)
0x7572f8 <InitializeGUCOptions+688>: lw s1,52(sp)
0x7572fc <InitializeGUCOptions+692>: lw s0,48(sp)
---Type <return> to continue, or q <return> to quit---
0x757300 <InitializeGUCOptions+696>: jr ra
0x757304 <InitializeGUCOptions+700>: addiu sp,sp,88
0x757308 <InitializeGUCOptions+704>: lw t9,60(s0)
0x75730c <InitializeGUCOptions+708>: nop
0x757310 <InitializeGUCOptions+712>:
beqz t9,0x757330 <InitializeGUCOptions+744>
0x757314 <InitializeGUCOptions+716>: li a1,1
0x757318 <InitializeGUCOptions+720>: lw a0,48(s0)
0x75731c <InitializeGUCOptions+724>: jalr t9
0x757320 <InitializeGUCOptions+728>: move a2,zero
0x757324 <InitializeGUCOptions+732>: lw gp,24(sp)
0x757328 <InitializeGUCOptions+736>:
beqz v0,0x757454 <InitializeGUCOptions+1036>
0x75732c <InitializeGUCOptions+740>: addiu a0,s6,-8968
(gdb)
> though this is evidently getting confused by the overly
> long path,
> so you might still see the warning even after picking the
> right
> executable.
I thought the same, but was hoping it's just a display problem.
__________________________________________________________
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
> The only
> thought that
> comes to mind is that the branch is being attempted but
> there's garbage
> at InitializeGUCOptions+1092 ? Try "x/32i
> InitializeGUCOptions+1092"
>
> What ulimit settings are operative anyway? (ulimit -a
> might tell you)
>
(gdb) x/32i InitializeGUCOptions+1092
0x75748c <InitializeGUCOptions+1092>:
bnez v0,0x757498 <InitializeGUCOptions+1104>
0x757490 <InitializeGUCOptions+1096>: nop
0x757494 <InitializeGUCOptions+1100>: li a2,2048
0x757498 <InitializeGUCOptions+1104>: lw a1,-32720(gp)
0x75749c <InitializeGUCOptions+1108>: lw t9,-30852(gp)
0x7574a0 <InitializeGUCOptions+1112>: addiu s0,sp,32
0x7574a4 <InitializeGUCOptions+1116>: addiu a1,a1,-11352
0x7574a8 <InitializeGUCOptions+1120>: jalr t9
0x7574ac <InitializeGUCOptions+1124>: move a0,s0
0x7574b0 <InitializeGUCOptions+1128>: lw gp,24(sp)
0x7574b4 <InitializeGUCOptions+1132>: move a1,s0
0x7574b8 <InitializeGUCOptions+1136>: lw a0,-32720(gp)
0x7574bc <InitializeGUCOptions+1140>: lw t9,-13328(gp)
0x7574c0 <InitializeGUCOptions+1144>: addiu a0,a0,-6048
0x7574c4 <InitializeGUCOptions+1148>: li a2,1
0x7574c8 <InitializeGUCOptions+1152>: jalr t9
0x7574cc <InitializeGUCOptions+1156>: li a3,1
0x7574d0 <InitializeGUCOptions+1160>: lw gp,24(sp)
0x7574d4 <InitializeGUCOptions+1164>:
b 0x7572d8 <InitializeGUCOptions+656>
0x7574d8 <InitializeGUCOptions+1168>: nop
0x7574dc <InitializeGUCOptions+1172>: lw t9,-26816(gp)
---Type <return> to continue, or q <return> to quit---
0x7574e0 <InitializeGUCOptions+1176>: li a1,3042
0x7574e4 <InitializeGUCOptions+1180>: jalr t9
0x7574e8 <InitializeGUCOptions+1184>: addiu a2,s5,-9132
0x7574ec <InitializeGUCOptions+1188>: lw gp,24(sp)
0x7574f0 <InitializeGUCOptions+1192>: lwc1 $f0,48(s0)
0x7574f4 <InitializeGUCOptions+1196>: lw a1,-32720(gp)
0x7574f8 <InitializeGUCOptions+1200>: lwc1 $f1,52(s0)
0x7574fc <InitializeGUCOptions+1204>: lw a2,0(s0)
0x757500 <InitializeGUCOptions+1208>: lw t9,-27888(gp)
0x757504 <InitializeGUCOptions+1212>: swc1 $f0,16(sp)
0x757508 <InitializeGUCOptions+1216>: swc1 $f1,20(sp)
(gdb) q
deb:/usr/pgsql_src/postgresql-8.3.3/src/test/regress# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
max nice (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) unlimited
max rt priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
__________________________________________________________
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
>
> The stack size rlimit looks normal, which makes a crash in
> this spot
> look even less probable. I think maybe you are looking at
> a stale
> corefile that doesn't quite correspond to this postgres
> executable.
>
You are correct. I just checked and the core file was created on the 18th, that must be from the first attempt to run
makecheck. I just assumed that the next time I attempted to run make check it'd be overwriting it, and that's obviously
notthe case.
I'll try and get it to generate a fresh file.
__________________________________________________________
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:
>> What ulimit settings are operative anyway? (ulimit -a
>> might tell you)
> deb:/usr/pgsql_src/postgresql-8.3.3/src/test/regress# ulimit -a
> core file size (blocks, -c) 0
Hmm, are you sure the core actually corresponds to your failure?
Because this says you've got core dumps turned off.
> stack size (kbytes, -s) 8192
The stack size rlimit looks normal, which makes a crash in this spot
look even less probable. I think maybe you are looking at a stale
corefile that doesn't quite correspond to this postgres executable.
regards, tom lane
Glyn Astill <glynastill@yahoo.co.uk> writes:
> And, the instruction pointer info:
> (gdb) x/i $pc
> 0x7572d0 <InitializeGUCOptions+648>:
> beqz v0,0x75748c <InitializeGUCOptions+1092>
Huh. The pc could possibly be a bit off from reality in this type of
error, but none of the instructions immediately around it look like they
could be making a bogus memory access either. The only thought that
comes to mind is that the branch is being attempted but there's garbage
at InitializeGUCOptions+1092 ? Try "x/32i InitializeGUCOptions+1092"
What ulimit settings are operative anyway? (ulimit -a might tell you)
regards, tom lane
Hi chaps, I'm still trying to get postgres working on my qube2 with debian. I've downgraded it to sarge, and it's a little better,however now when compiling I get "functions.o: file not recognized: File truncated" http://privatepaste.com/3f1j0tI0ow Any ideas? --- On Tue, 22/7/08, Glyn Astill <glynastill@yahoo.co.uk> wrote: > From: Glyn Astill <glynastill@yahoo.co.uk> > Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error > To: "Tom Lane" <tgl@sss.pgh.pa.us> > Cc: "Stefan Kaltenbrunner" <stefan@kaltenbrunner.cc>, pgsql-general@postgresql.org > Date: Tuesday, 22 July, 2008, 7:35 PM > > > > The stack size rlimit looks normal, which makes a > crash in > > this spot > > look even less probable. I think maybe you are > looking at > > a stale > > corefile that doesn't quite correspond to this > postgres > > executable. > > > > You are correct. I just checked and the core file was > created on the 18th, that must be from the first attempt to > run make check. I just assumed that the next time I > attempted to run make check it'd be overwriting it, and > that's obviously not the case. > > I'll try and get it to generate a fresh file. > > > > __________________________________________________________ > 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 > > -- > Sent via pgsql-general mailing list > (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general __________________________________________________________ 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
Heres a backtrace on a fresh core file http://privatepaste.com/911BTjYrY1 Does this change get us any closer? --- On Tue, 22/7/08, Glyn Astill <glynastill@yahoo.co.uk> wrote: > From: Glyn Astill <glynastill@yahoo.co.uk> > Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error > To: "Tom Lane" <tgl@sss.pgh.pa.us> > Cc: "Stefan Kaltenbrunner" <stefan@kaltenbrunner.cc>, pgsql-general@postgresql.org > Date: Tuesday, 22 July, 2008, 7:35 PM > > > > The stack size rlimit looks normal, which makes a > crash in > > this spot > > look even less probable. I think maybe you are > looking at > > a stale > > corefile that doesn't quite correspond to this > postgres > > executable. > > > > You are correct. I just checked and the core file was > created on the 18th, that must be from the first attempt to > run make check. I just assumed that the next time I > attempted to run make check it'd be overwriting it, and > that's obviously not the case. > > I'll try and get it to generate a fresh file. > > > > __________________________________________________________ > 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 > > -- > Sent via pgsql-general mailing list > (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general __________________________________________________________ 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: > Heres a backtrace on a fresh core file > http://privatepaste.com/911BTjYrY1 > Does this change get us any closer? Not really ... there's no plausible reason to crash there, either. Just for entertainment's sake, try recompiling with -O0 instead of the default -O2. (Rather than trying to browbeat configure into doing this, I'd suggest manually adjusting CFLAGS in src/Makefile.global, then "make clean" and rebuild.) This has two purposes: if it's a compiler bug, that will likely make it go away; and if gdb is misleading us about exactly where the crash is, that should help it give a correct answer. regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > (Rather than trying to browbeat configure into doing this, I'd suggest > manually adjusting CFLAGS in src/Makefile.global, then "make clean" and > rebuild.) eh? either of these should work fine: ./configure --enable-debug CFLAGS=-O0 CFLAGS=-O0 ./configure --enable-debug And yes, you have to do make clean. I often forget that step :( -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> (Rather than trying to browbeat configure into doing this, I'd suggest
>> manually adjusting CFLAGS in src/Makefile.global, then "make clean" and
>> rebuild.)
> eh? either of these should work fine:
> ./configure --enable-debug CFLAGS=-O0
> CFLAGS=-O0 ./configure --enable-debug
The trouble with that approach is that it overrides *everything* that
configure would normally put into CFLAGS. I only want one thing
changing, please ... this is confusing enough already.
regards, tom lane
Gregory Stark wrote: > "Tom Lane" <tgl@sss.pgh.pa.us> writes: > > > (Rather than trying to browbeat configure into doing this, I'd suggest > > manually adjusting CFLAGS in src/Makefile.global, then "make clean" and > > rebuild.) > > eh? either of these should work fine: > > ./configure --enable-debug CFLAGS=-O0 > CFLAGS=-O0 ./configure --enable-debug > > And yes, you have to do make clean. I often forget that step :( I find it easier to create a src/Makefile.custom containing the following line: CFLAGS := $(patsubst -O2,-O0,$(CFLAGS)) When I'm done I just rename the file away to keep it around for next time. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
> > "Tom Lane" <tgl@sss.pgh.pa.us> writes:
> >
> > > (Rather than trying to browbeat configure into
> doing this, I'd suggest
> > > manually adjusting CFLAGS in src/Makefile.global,
> then "make clean" and
> > > rebuild.)
> >
> > eh? either of these should work fine:
> >
> > ./configure --enable-debug CFLAGS=-O0
> > CFLAGS=-O0 ./configure --enable-debug
> >
> > And yes, you have to do make clean. I often forget
> that step :(
>
> I find it easier to create a src/Makefile.custom containing
> the
> following line:
>
> CFLAGS := $(patsubst -O2,-O0,$(CFLAGS))
>
> When I'm done I just rename the file away to keep it
> around for next
> time.
I'm going to keep things simple and just do as Tom says by editing Makefile.global and we'll see what happens.
Hopefullyat the very lease it'll compile a little quicker with the optimization off.
__________________________________________________________
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
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Gregory Stark <stark@enterprisedb.com> writes: >> "Tom Lane" <tgl@sss.pgh.pa.us> writes: >>> (Rather than trying to browbeat configure into doing this, I'd suggest >>> manually adjusting CFLAGS in src/Makefile.global, then "make clean" and >>> rebuild.) > >> eh? either of these should work fine: >> ./configure --enable-debug CFLAGS=-O0 >> CFLAGS=-O0 ./configure --enable-debug > > The trouble with that approach is that it overrides *everything* that > configure would normally put into CFLAGS. I only want one thing > changing, please ... this is confusing enough already. Eh? $ ./configure ... configure: using CFLAGS=-O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels-fno-strict-aliasing -fwrapv configure: using CPPFLAGS= -D_GNU_SOURCE configure: using LDFLAGS= -Wl,--as-needed $ ./configure CFLAGS=-O0 ... configure: using CFLAGS=-O0 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels-fno-strict-aliasing -fwrapv configure: using CPPFLAGS= -D_GNU_SOURCE configure: using LDFLAGS= -Wl,--as-needed -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning
Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> The trouble with that approach is that it overrides *everything* that
>> configure would normally put into CFLAGS. I only want one thing
>> changing, please ... this is confusing enough already.
> Eh?
Sorry, memory failed me: what gets overridden is CFLAGS set by the
platform-specific template file. That's not a big problem on mainstream
platforms, but on some it will break your build.
regards, tom lane
http://privatepaste.com/cbY2S4JhtA Very little difference with the -O0 __________________________________________________________ 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: > http://privatepaste.com/cbY2S4JhtA > > Very little difference with the -O0 FWIW: there also seems to be a fairly indepth discussion on the cobalt related netbsd list from last year about a problem that looks very similiar (at least to you issue with etch): http://www.nabble.com/Strange-segmentation-fault-trying-to-run-postgresql-on-current-to9997129.html Stefan
[ cc'ing Remi to see if he remembers anything about how he got around this ] Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes: > FWIW: there also seems to be a fairly indepth discussion on the cobalt > related netbsd list from last year about a problem that looks very > similiar (at least to you issue with etch): > http://www.nabble.com/Strange-segmentation-fault-trying-to-run-postgresql-on-current-to9997129.html Hmm. I'm not sure it's the same problem, because what they were getting was SIGSEGV not SIGBUS. OTOH I would think the latter is a more correct errno for reporting an alignment trap, so maybe the NetBSD kernel has been fixed since then to report SIGBUS for this case. Anyway, it would be easy to verify this theory by looking at the instruction stream and registers in Glyn's dump, to see if it's trying to store at a non-aligned address. The conclusion of the thread seemed to be that it was a linker or assembler problem triggered by our use of SUBSYS.o files to aggregate all the backend .o files into a smaller number of files for the final link. If so the answer is either (a) update to a newer toolchain that might fix the problem, or (b) try our CVS HEAD which doesn't use the SUBSYS.o trick anymore. Mind you, I'd not especially recommend trying to run CVS HEAD for production purposes, but it would be real interesting at this point to see if you can compile it and run the regression tests with the toolchain you've got. regards, tom lane
> Mind you, I'd not especially recommend trying to run CVS HEAD for > production purposes, but it would be real interesting at this point > to see if you can compile it and run the regression tests with the > toolchain you've got. > I've no problem doing that, this machine is a toy not a production system. I've had little contact with CVS. Should I follow something at the following URL, or should I go elsewhere? http://wiki.postgresql.org/wiki/Working_with_CVS __________________________________________________________ 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
On 8/6/08, Glyn Astill <glynastill@yahoo.co.uk> wrote: > > Mind you, I'd not especially recommend trying to run CVS HEAD for > > production purposes, but it would be real interesting at this point > > to see if you can compile it and run the regression tests with the > > toolchain you've got. > > > > I've no problem doing that, this machine is a toy not a production system. > > I've had little contact with CVS. Should I follow something at the following URL, or should I go elsewhere? > > http://wiki.postgresql.org/wiki/Working_with_CVS > that is for setup your local copy of the repository, you should only need this: http://www.postgresql.org/docs/8.3/static/anoncvs.html -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Guayaquil - Ecuador Cel. (593) 87171157
> The conclusion of the thread seemed to be that it was a
> linker or
> assembler problem triggered by our use of SUBSYS.o files to
> aggregate
> all the backend .o files into a smaller number of files for
> the final
> link. If so the answer is either (a) update to a newer
> toolchain
> that might fix the problem, or (b) try our CVS HEAD which
> doesn't
> use the SUBSYS.o trick anymore. Mind you, I'd not
> especially recommend
> trying to run CVS HEAD for production purposes, but it
> would be real
> interesting at this point to see if you can compile it and
> run the
> regression tests with the toolchain you've got.
So tonight I've built CVS HEAD and rerun make check.
All 115 tests passed! It works :-)
__________________________________________________________
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:
>> The conclusion of the thread seemed to be that it was a linker or
>> assembler problem triggered by our use of SUBSYS.o files to aggregate
>> all the backend .o files into a smaller number of files for the final
>> link. If so the answer is either (a) update to a newer toolchain
>> that might fix the problem, or (b) try our CVS HEAD which doesn't use
>> the SUBSYS.o trick anymore.
> So tonight I've built CVS HEAD and rerun make check.
> All 115 tests passed! It works :-)
Okay, so it is indeed the linker's fault. Now try plan (a) --- can you
find a more up-to-date toolchain?
regards, tom lane
>
> Okay, so it is indeed the linker's fault. Now try plan
> (a) --- can you
> find a more up-to-date toolchain?
Well I've tried looking in apt, and the latest package is the version I've got, (the toolchain is more than just gcc
isn'tit though?) is there another way to get a more up to date toolchain?
Here's what I'm running ont he qube;
glyn@deb:~$ gcc -v
Using built-in specs.
Target: mipsel-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared--with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-libssp
--enable-checking=releasemipsel-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
And heres what I have on the servers at work;
Way5a:/pgsql/logs# gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared--with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--enable-checking=releasex86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Same version but different architectures.
__________________________________________________________
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:
>> Okay, so it is indeed the linker's fault. Now try plan
>> (a) --- can you
>> find a more up-to-date toolchain?
> Well I've tried looking in apt, and the latest package is the version I've got, (the toolchain is more than just gcc
isn'tit though?) is there another way to get a more up to date toolchain?
gcc wasn't the suspected candidate --- the netbsd guys thought it was
as or ld. On my Fedora machine those seem to be part of the binutils
package; dunno how Debian handles it.
regards, tom lane
> gcc wasn't the suspected candidate --- the netbsd guys
> thought it was
> as or ld. On my Fedora machine those seem to be part of
> the binutils
> package; dunno how Debian handles it.
>
Yeah, it appears to be the binutils package on debian too. I have the latest version from apt, I've checked backports
toobut the versions are the same.
__________________________________________________________
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