Re: Initdb problem on debian mips cobalt: Bus error

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(at)sss(dot)pgh(dot)pa(dot)us>
> To: Glyn Astill <glynastill(at)yahoo(dot)co(dot)uk>
> Cc: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>; pgsql-general(at)postgresql(dot)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(at)yahoo(dot)co(dot)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(at)yahoo(dot)co(dot)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

Glyn Astill <glynastill(at)yahoo(dot)co(dot)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

> 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

Glyn Astill <glynastill(at)yahoo(dot)co(dot)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

>
> 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

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(at)yahoo(dot)co(dot)uk> wrote:

> From: Glyn Astill <glynastill(at)yahoo(dot)co(dot)uk>
> Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error
> To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Cc: "Stefan Kaltenbrunner" <stefan(at)kaltenbrunner(dot)cc>, pgsql-general(at)postgresql(dot)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(at)postgresql(dot)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(at)yahoo(dot)co(dot)uk> wrote:

> From: Glyn Astill <glynastill(at)yahoo(dot)co(dot)uk>
> Subject: Re: [GENERAL] Initdb problem on debian mips cobalt: Bus error
> To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Cc: "Stefan Kaltenbrunner" <stefan(at)kaltenbrunner(dot)cc>, pgsql-general(at)postgresql(dot)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(at)postgresql(dot)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(at)yahoo(dot)co(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)sss(dot)pgh(dot)pa(dot)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. Hopefully at 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(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)kaltenbrunner(dot)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(at)yahoo(dot)co(dot)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(at)yahoo(dot)co(dot)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't it though?) is there another way to get a more up to date toolchain?

Here's what I'm running ont he qube;

glyn(at)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=release mipsel-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=release x86_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(at)yahoo(dot)co(dot)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't it 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 too but 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