Strange segmentation fault trying to run postgresql on current

Hi,

I run a (relatively) current system on my new Cobalt Qube 2
(NetBSD  
xxx.xxx.org 4.99.16 NetBSD 4.99.16 (GENERIC) #0: Wed Mar 28
14:14:11  
PDT 2007  buildswb36:/home/builds/ab/HEAD/cobalt/200703280002Z-obj/ 
home/builds/ab/HEAD/src/sys/arch/cobalt/compile/GENERIC
cobalt)

I want to run PostgreSQL (current) on it, and I encounter a
problem  
that might be more MIPS related than specificaly Cobalt
related, but  
here it is:

the "postgres" exe seg faults early in main when
jumping to a  
subroutine. Here are some relevant info from a gdb session:

(gdb)
79              argv = save_ps_display_args(argc, argv);
(gdb) stepi
0x005ae3b0      79              argv =
save_ps_display_args(argc, argv);
(gdb)
0x005ae3b4      79              argv =
save_ps_display_args(argc, argv);
(gdb)
79              argv = save_ps_display_args(argc, argv);
(gdb)

Program received signal SIGSEGV, Segmentation fault.
main (argc=1, argv=0x7fffdcc4) at main.c:79
79              argv = save_ps_display_args(argc, argv);


Here is a disassembly of the concerned code:

0x005ae3a8 <main+72>:   lw      gp,16(sp)
0x005ae3ac <main+76>:   move    a1,s0
0x005ae3b0 <main+80>:   lw      t9,-20988(gp)
0x005ae3b4 <main+84>:   move    a0,s3
0x005ae3b8 <main+88>:   jalr    t9

Could some one help me with this ?

gp starts at 00882de0 when entering main, and t9 ends up
with 007578b0
Here is what I find in a disassembly of the postgres exe:

007578b0 <save_ps_display_args>:
   7578b0:       3c1c0013        lui     gp,0x13
   7578b4:       279cb530        addiu   gp,gp,-19152
   7578b8:       0399e021        addu    gp,gp,t9
   7578bc:       8f838110        lw      v1,-32496(gp)
   7578c0:       00a01021        move    v0,a1


I built some packages on the machine without problems (but
did not  
test extensively), like perl, bash, screen, tcl, python and
more. So  
the toolchain is not completely busted.
this is gcc (GCC) 4.1.2 20070110 prerelease (NetBSD nb1
20070110)
and GNU ld version 2.16.1

Regards,

Rémi Zara

On Apr 14, 2007, at 2:11 PM, Rémi Zara wrote:

> Hi,
>
> I run a (relatively) current system on my new Cobalt
Qube 2 (NetBSD  
> xxx.xxx.org 4.99.16 NetBSD 4.99.16 (GENERIC) #0: Wed
Mar 28  
> 14:14:11 PDT 2007  buildswb36:/home/builds/ab/HEAD/cobalt/ 
>
200703280002Z-obj/home/builds/ab/HEAD/src/sys/arch/cobalt/co
mpile/ 
> GENERIC cobalt)
>
> I want to run PostgreSQL (current) on it, and I
encounter a problem  
> that might be more MIPS related than specificaly Cobalt
related,  
> but here it is:

So, you're not running PostgreSQL out of pkgsrc huh?  And it
built ok  
I guess?  I've been trying to build databases/postgresql81
& ...82,   
on 3.99.20 from last summer but it fails because of GCC
trying to  
generate assembly that tries to jump too far.

Did you try building out of pkgsrc?

I've been meaning to update to a more recent current and see
if that  
solves my troubles, but haven't had time to schedule it...

Robert

Le 21 avr. 07 à 21:35, Robert P. Thille a écrit :

>
> So, you're not running PostgreSQL out of pkgsrc huh?

No, I'm not. I would like to setup a PostgreSQL buildfarm
client.

>   And it built ok I guess?

Yep. (But I had an issue linking initdb with libpq with the
ldap  
support).

> I've been trying to build databases/postgresql81 &
...82,  on  
> 3.99.20 from last summer but it fails because of GCC
trying to  
> generate assembly that tries to jump too far.
>
> Did you try building out of pkgsrc?

No. I will try that.

Regards,

Rémi Zara

Hi,

Still trying to figure why postgresql is crashing. (I've not
yet  
tried pkgsrc or another version than "current"
postgresql).

I've rebuilt with CFLAGS=-O0, and it still crash early in
main, but  
not exactly at the same place (a little earlier).

Here are some relevant info:

Program received signal SIGSEGV, Segmentation fault.
0x006bb26c in main (argc=1, argv=0x7fffdccc) at main.c:61

here is the instruction:

0x006bb26c <main+92>:   sw      v1,0(v0)

registers:

(gdb) info registers
           zero       at       v0       v1       a0       a1
       
a2       a3
R0   00000000 00000000 00af83cf 00b3f030 00b3f039 7fffddf5
00000000  
7fffddec
             t0       t1       t2       t3       t4       t5
       
t6       t7
R8   7fffddf4 00000000 00000008 00000000 8000001f ffffffe0
7fffdd30  
009d6340
             s0       s1       s2       s3       s4       s5
       
s6       s7
R16  7fffdd78 7fffdcc8 00000001 7fffdccc 00af8358 7fffeff0
7dfb2f90  
7dfa3000
             t8       t9       k0       k1       gp       sp
       
s8       ra
R24  0000083d 7d9d4528 00000000 00000000 00afb160 7fffdc68
7fffdc68  
006bb25c
             sr       lo       hi      bad    cause      
pc
       0000ff13 0009f79c 000000b4 006bb268 00000024
006bb26c
            fsr      fir
       007e92c0 00000000

So if I understand correctly, it tries to store 00b3f030 at
address  
00af83cf

So SIGSEGV would me that that address is not mapped or
accessible ? but
pmap gives:

(...)
00af8000-00af8fff       4k 00000000 rw-p- (rwx) 1/0/0 00:00 
     0  
-   [ anon ]
(...)

So this address seems to be mapped and writable ?

What am I missing.

What should I try to debug this ?

Regards,

Rémi Zara

On 4/26/07, Rémi Zara <remi.zarafree.fr> wrote:
> So this address seems to be mapped and writable ?
>
> What am I missing.
>
> What should I try to debug this ?

I think Postgresql hasn't worked on mips in
"forever". I think it
doesn't work on Linux either, but I haven't checked for some
years
now.

I got the same problems and just gave up. I suppose doing a
compile
with -g might be useful or something, but I'm kinda out of
my league
even commenting on that.

Andy

Le 26 avr. 07 à 23:09, Andy Ruhl a écrit :

> On 4/26/07, Rémi Zara <remi.zarafree.fr> wrote:
>> So this address seems to be mapped and writable ?
>>
>> What am I missing.
>>
>> What should I try to debug this ?
>
> I think Postgresql hasn't worked on mips in
"forever". I think it
> doesn't work on Linux either, but I haven't checked for
some years
> now.

Well it works on debian 3.. See http://www.pgbuil
dfarm.org/cgi-bin/ 
show_status.pl?member=lionfish

hostname = mastercube
uname -m = mips
uname -r = 2.4.27-r5k-cobalt
uname -s = Linux
uname -v = #1 Thu Dec 7 18:22:50 UTC 2006

This seems to be a machine quite similar to my Qube2.


> I got the same problems and just gave up. I suppose
doing a compile
> with -g might be useful or something,

already done.

Regards,

Rémi Zara

It is not the mapping that is the problem but alignment. It
is trying to 
store word (32 bits) at the address that is aligned on 1
byte (cf).
I don't know much about how netbsd translates mips
exceptions to signals 
but I think from your register dump the problem is
alignment.

Regards,
Alex


Rémi Zara wrote:
> Hi,
> 
> Still trying to figure why postgresql is crashing.
(I've not yet tried 
> pkgsrc or another version than "current"
postgresql).
> 
> I've rebuilt with CFLAGS=-O0, and it still crash early
in main, but not 
> exactly at the same place (a little earlier).
> 
> Here are some relevant info:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x006bb26c in main (argc=1, argv=0x7fffdccc) at
main.c:61
> 
> here is the instruction:
> 
> 0x006bb26c <main+92>:   sw      v1,0(v0)
> 
> registers:
> 
> (gdb) info registers
>           zero       at       v0       v1       a0     
 a1       
> a2       a3
> R0   00000000 00000000 00af83cf 00b3f030 00b3f039
7fffddf5 00000000 
> 7fffddec
>             t0       t1       t2       t3       t4     
 t5       
> t6       t7
> R8   7fffddf4 00000000 00000008 00000000 8000001f
ffffffe0 7fffdd30 
> 009d6340
>             s0       s1       s2       s3       s4     
 s5       
> s6       s7
> R16  7fffdd78 7fffdcc8 00000001 7fffdccc 00af8358
7fffeff0 7dfb2f90 
> 7dfa3000
>             t8       t9       k0       k1       gp     
 sp       
> s8       ra
> R24  0000083d 7d9d4528 00000000 00000000 00afb160
7fffdc68 7fffdc68 
> 006bb25c
>             sr       lo       hi      bad    cause     
 pc
>       0000ff13 0009f79c 000000b4 006bb268 00000024
006bb26c
>            fsr      fir
>       007e92c0 00000000
> 
> So if I understand correctly, it tries to store
00b3f030 at address 
> 00af83cf
> 
> So SIGSEGV would me that that address is not mapped or
accessible ? but
> pmap gives:
> 
> (...)
> 00af8000-00af8fff       4k 00000000 rw-p- (rwx) 1/0/0
00:00       0 -   
> [ anon ]
> (...)
> 
> So this address seems to be mapped and writable ?
> 
> What am I missing.
> 
> What should I try to debug this ?
> 
> Regards,
> 
> Rémi Zara

If you could correlate place of error with the source code
you could get 
more information. From the dump you provided it is in
main+92 offset. 
You can try looking at line information and see which line
corresponds 
to this offset. Try objdump and see if you can figure out
where exactly 
in source code this happens.

Regards,
Alex


Rémi Zara wrote:
> 
> Le 26 avr. 07 à 23:12, Alex Pelts a écrit :
> 
>> It is not the mapping that is the problem but
alignment. It is trying 
>> to store word (32 bits) at the address that is
aligned on 1 byte (cf).
>> I don't know much about how netbsd translates mips
exceptions to 
>> signals but I think from your register dump the
problem is alignment.
> 
> Interesting !
> So maybe some option is lacking for GCC ? it seems to
build ok on debian 
> 3.1 with gcc version 3.3.5 (Debian 1:3.3.5-13) (see 
> http://www.pgbuildfarm.org/cgi-bin/show_status.
pl?member=lionfish)
> without any option. Any idea ?
> 
> I'm using
> 
> bash-3.2# gcc -v
> Using built-in specs.
> Target: mipsel--netbsd
> Configured with:
/usr/src/tools/gcc/../../gnu/dist/gcc4/configure 
> --enable-long-long --disable-multilib --enable-threads
--disable-symvers 
> --build=x86_64-unknown-netbsd4.99.12
--host=mipsel--netbsd 
> --target=mipsel--netbsd
> Thread model: posix
> gcc version 4.1.2 20070110 prerelease (NetBSD nb1
20070110)
> 
> 
> Regards,
> 
> Rémi Zara
> 
>> Regards,
>> Alex
> 
> 

Le 26 avr. 07 à 23:12, Alex Pelts a écrit :

> It is not the mapping that is the problem but
alignment. It is  
> trying to store word (32 bits) at the address that is
aligned on 1  
> byte (cf).
> I don't know much about how netbsd translates mips
exceptions to  
> signals but I think from your register dump the problem
is alignment.

Interesting !
So maybe some option is lacking for GCC ? it seems to build
ok on  
debian 3.1 with gcc version 3.3.5 (Debian 1:3.3.5-13) (see
http:// 
www.pgbuildfarm.org/cgi-bin/show_status.pl?member=lionfish)
without any option. Any idea ?

I'm using

bash-3.2# gcc -v
Using built-in specs.
Target: mipsel--netbsd
Configured with:
/usr/src/tools/gcc/../../gnu/dist/gcc4/configure -- 
enable-long-long --disable-multilib --enable-threads
--disable- 
symvers --build=x86_64-unknown-netbsd4.99.12
--host=mipsel--netbsd -- 
target=mipsel--netbsd
Thread model: posix
gcc version 4.1.2 20070110 prerelease (NetBSD nb1 20070110)


Regards,

Rémi Zara

> Regards,
> Alex

On 4/27/07, Byron Servies <Byron.Serviessun.com> wrote:
> My prehistoric 1.6.2 Qube running postgresql 7.3.4 has
worked dandy for
> many years.  I've never gotten around to upgrading,
though, so I can't
> say about anything more recent than ... well, half a
decade ago.

I started with 2.0 on the Qube (I think), but I never got
postgres to
compile out of pkgsrc.

Hmm.

Andy