[rrd-developers] Seg fault with r1094

[Bernhard Fischer]

On Fri, Jun 01, 2007 at 11:03:40AM -0500, Matthew Chambers wrote:
>> I had a short glance at the alleged segfault and cannot reproduce it
>> with a pristine checkout built with -O0 -g3 -ggdb3 on the PPC box and
>> running that 32bit binary on the PPC64 box.
>> 
>> If this turns out to be a problem at higher optimization-levels, i
>> suggest you talk to the redhat guys about this, fwiw. I've been bitten
>> by redhat compilers miscompiling for loops on a so called advanced
>> server lately even on i386, so the possibility that redhat's ppc
>> compiler does stuff differently than one would expect is something i
>> would not exactly be surprised about..
>
>Bernhard,
>
>I am thoroughly confused now.  I think the shared libraries are conspiring
>against me.
>
>On the PPC box:
>After running: make clean distclean
>I've been running: ./configure --prefix=/frogstar/usr/ppc; make; make
>install
>This is of course on the trunk source.  And it appears to work and install
>things to the right places.  The file dates in /frogstar/usr/ppc/bin and
>/frogstar/usr/ppc/lib get updated to the compile time:
>
>$ find /frogstar/usr/ppc/bin -name "*rrd*" | xargs ls -l
> 55175 Jun  1 10:46 /frogstar/usr/ppc/bin/rrdcgi
> 14180 Jun  1 10:46 /frogstar/usr/ppc/bin/rrdtool
>157083 Jun  1 10:46 /frogstar/usr/ppc/bin/rrdupdate
>
>$ find /frogstar/usr/ppc/lib -name "*rrd*" | xargs ls -l
>889996 Jun  1 10:46 /frogstar/usr/ppc/lib/librrd.a
>   832 Jun  1 10:46 /frogstar/usr/ppc/lib/librrd.la
>    16 Jun  1 10:46 /frogstar/usr/ppc/lib/librrd.so -> librrd.so.2.0.11
>    16 Jun  1 10:46 /frogstar/usr/ppc/lib/librrd.so.2 -> librrd.so.2.0.11
>640946 May 29 16:19 /frogstar/usr/ppc/lib/librrd.so.2.0.10
>649101 Jun  1 10:46 /frogstar/usr/ppc/lib/librrd.so.2.0.11
>892026 Jun  1 10:46 /frogstar/usr/ppc/lib/librrd_th.a
>   863 Jun  1 10:46 /frogstar/usr/ppc/lib/librrd_th.la
>    19 Jun  1 10:46 /frogstar/usr/ppc/lib/librrd_th.so ->
>librrd_th.so.2.0.11
>    19 Jun  1 10:46 /frogstar/usr/ppc/lib/librrd_th.so.2 ->
>librrd_th.so.2.0.11
>650481 Jun  1 10:46 /frogstar/usr/ppc/lib/librrd_th.so.2.0.11
>642350 May 29 16:19 /frogstar/usr/ppc/lib/librrd_th.so.2.0.8
>
>
>On the PPC64 box:
>I have an RPM install of 1.2.23 in my path:
>$ which rrdtool
>/usr/bin/rrdtool
>
>When I manually run the absolute path to the trunk version:
>$ /frogstar/usr/ppc/bin/rrdtool
>RRDtool 1.2.99907052400  Copyright 1997-2007 by Tobias Oetiker
><tobi at oetiker.ch>
>               Compiled Jun  1 2007 10:44:15
>
>When I run the version you built:
>$ /home/aldot/rrdtool-ppc32
>RRDtool 1.2.99907052400  Copyright 1997-2007 by Tobias Oetiker
><tobi at oetiker.ch>
>               Compiled Jun  1 2007 02:19:57
>
>When I run your version with an RRD info:
>$ /home/aldot/rrdtool-ppc32 info
>/var/lib/ganglia/rrds/__SummaryInfo__/cpu_user.rrd 
>filename = "/var/lib/ganglia/rrds/__SummaryInfo__/cpu_user.rrd"
>rrd_version = "0003"
>step = 15
>last_update = 1180713507
>...
>
>I.e. it works fine.

I've linked librrd statically for that "rrdtool-ppc32" binary (look at
ldd and the binary size, compared to a purely dynamically linked
version).
As i already sent you in private, the one box looks quite suspicious,
given that it's RPM database seems to be corrupted, i.e. i wouldn't be
convincend anymore that updates work like you'd expect. In general, a
box with a broken RPM databse is doomed, in my experience.

In my POV trunk is fine on PPC with 32bit (I've even did some cursory
checks on an ia64 box to see if there are any unexpected problems on
64bit setups, and all is well) and any other arch for that matter.

Check you setup..
HTH,