[rrd-users] Oddities with rrdtool

Benny Baumann BenBE at geshi.org
Fri Jan 1 02:43:09 CET 2010


Hi,

Am 01.01.2010 01:55, schrieb Jean-Yves Avenard:
> Hi
>
> 2010/1/1 Benny Baumann <BenBE at geshi.org>:
>   
>> Looks like some random memory corruption or uninitialized memory. Could
>> you please provide a valgrind log of a run where graphing worked and one
>> where it didn't?
>>     
> I'm not familiar with valgrind ; I usually use Purify ...
> But I'll have a try next when I see the problem occuring next...
>
> Currently working, that's the output from valgrind:
> valgrind /usr/bin/rrdtool graph /tmp/powerjSwa9v -l 0 \
>   
>> -t 'USAGE - DAILY (hourly average) 1/1/2010' \
>> -x HOUR:1:HOUR:4:HOUR:2:0:%k  --slope-mode \
>> --step 3600 --start 1262304000 --end 1262390400 \
>> -w 480 -h 120 \
>> -W '(c) Jean-Yves Avenard 2009-2010. All rights reserved' COMMENT:'            ' \
>>     COMMENT:'Maximum    ' \
>>     COMMENT:'Average    ' \
>>     COMMENT:'Minimum    '  \
>>     COMMENT:'Total View\l' DEF:total=currentcost3.rrd:total:AVERAGE:start=1262304000:end=1262343599 \
>>      CDEF:totalw=total,3600,/ CDEF:ctotal=totalw,3600,* \
>>     VDEF:vtotalmax=ctotal,MAXIMUM \
>>     VDEF:vtotalavg=ctotal,AVERAGE \
>>     VDEF:vtotalmin=ctotal,MINIMUM \
>>     VDEF:vtotaltot=totalw,TOTAL AREA:ctotal#ff4500:'Total   ' \
>>     GPRINT:vtotalmax:'%6.1lf %sWh ' \
>>     GPRINT:vtotalavg:'%6.1lf %sWh ' \
>>     GPRINT:vtotalmin:'%6.1lf %sWh  ' \
>>     GPRINT:vtotaltot:'%7.2lf %sWh\l' DEF:ch1=currentcost3.rrd:ch1:AVERAGE:start=1262304000:end=1262343599 \
>>      CDEF:ch1w=ch1,3600,/ CDEF:cch1=ch1w,3600,* \
>>     VDEF:vch1max=cch1,MAXIMUM \
>>     VDEF:vch1avg=cch1,AVERAGE \
>>     VDEF:vch1min=cch1,MINIMUM \
>>     VDEF:vch1tot=ch1w,TOTAL AREA:cch1#add8e6:'Pool    ' \
>>     GPRINT:vch1max:'%6.1lf %sWh ' \
>>     GPRINT:vch1avg:'%6.1lf %sWh ' \
>>     GPRINT:vch1min:'%6.1lf %sWh  ' \
>>     GPRINT:vch1tot:'%7.2lf %sWh\l' DEF:ext=solarprod3.rrd:total:AVERAGE:start=1262304000:end=1262343599 \
>>      CDEF:extw=ext CDEF:cext=extw,3600,* \
>>     VDEF:vextmax=cext,MAXIMUM \
>>     VDEF:vextavg=cext,AVERAGE \
>>     VDEF:vextmin=cext,MINIMUM \
>>     VDEF:vexttot=extw,TOTAL AREA:cext#FFd700a0:'Solar   ' \
>>     GPRINT:vextmax:'%6.1lf %sWh ' \
>>     GPRINT:vextavg:'%6.1lf %sWh ' \
>>     GPRINT:vextmin:'%6.1lf %sWh  ' \
>>     GPRINT:vexttot:'%7.2lf %sWh\l' COMMENT:'-----------------------------------------------------------------\l' HRULE:0#999999 DEF:import=feedin30min3.rrd:in:AVERAGE:start=1262304000:end=1262343599 \
>>     CDEF:importw=import,1800,/ \
>>     CDEF:cimport=importw,3600,* \
>>     CDEF:cimport2=cimport,-1,* \
>>     VDEF:vimportmax=cimport,MAXIMUM \
>>     VDEF:vimportavg=cimport,AVERAGE \
>>     VDEF:vimportmin=cimport,MINIMUM \
>>     VDEF:vimporttot=importw,TOTAL AREA:cimport2#ff4500:'Import  ' \
>>     GPRINT:vimportmax:'%6.1lf %sWh ' \
>>     GPRINT:vimportavg:'%6.1lf %sWh ' \
>>     GPRINT:vimportmin:'%6.1lf %sWh  ' \
>>     GPRINT:vimporttot:'%7.2lf %sWh\l' DEF:export=feedin30min3.rrd:out:AVERAGE:start=1262304000:end=1262343599 \
>>     CDEF:exportw=export,1800,/ \
>>     CDEF:cexport=exportw,3600,* \
>>     CDEF:cexport2=cexport,-1,* \
>>     VDEF:vexportmax=cexport,MAXIMUM \
>>     VDEF:vexportavg=cexport,AVERAGE \
>>     VDEF:vexportmin=cexport,MINIMUM \
>>     VDEF:vexporttot=exportw,TOTAL AREA:cexport2#FFd700a0:'Export  ' \
>>     GPRINT:vexportmax:'%6.1lf %sWh ' \
>>     GPRINT:vexportavg:'%6.1lf %sWh ' \
>>     GPRINT:vexportmin:'%6.1lf %sWh  ' \
>>     GPRINT:vexporttot:'%7.2lf %sWh\l'
>>     
> ==10650== Memcheck, a memory error detector
> ==10650== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
> ==10650== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for
> copyright info
> ==10650== Command: /usr/bin/rrdtool graph /tmp/powerjSwa9v -l 0 -t
> USAGE\ -\ DAILY\ (hourly\ average)\ 1/1/2010 -x
> HOUR:1:HOUR:4:HOUR:2:0:%k --slope-mode --step 3600 --start 1262304000
> --end 1262390400 -w 480 -h 120 -W (c)\ Jean-Yves\ Avenard\ 2009-2010.\
> All\ rights\ reserved COMMENT:\ \ \ \ \ \ \ \ \ \ \ \
> COMMENT:Maximum\ \ \ \  COMMENT:Average\ \ \ \  COMMENT:Minimum\ \ \ \
>  COMMENT:Total\ View\\l
> DEF:total=currentcost3.rrd:total:AVERAGE:start=1262304000:end=1262343599
> CDEF:totalw=total,3600,/ CDEF:ctotal=totalw,3600,*
> VDEF:vtotalmax=ctotal,MAXIMUM VDEF:vtotalavg=ctotal,AVERAGE
> VDEF:vtotalmin=ctotal,MINIMUM VDEF:vtotaltot=totalw,TOTAL
> AREA:ctotal#ff4500:Total\ \ \  GPRINT:vtotalmax:%6.1lf\ %sWh\
> GPRINT:vtotalavg:%6.1lf\ %sWh\  GPRINT:vtotalmin:%6.1lf\ %sWh\ \
> GPRINT:vtotaltot:%7.2lf\ %sWh\\l
> DEF:ch1=currentcost3.rrd:ch1:AVERAGE:start=1262304000:end=1262343599
> CDEF:ch1w=ch1,3600,/ CDEF:cch1=ch1w,3600,* VDEF:vch1max=cch1,MAXIMUM
> VDEF:vch1avg=cch1,AVERAGE VDEF:vch1min=cch1,MINIMUM
> VDEF:vch1tot=ch1w,TOTAL AREA:cch1#add8e6:Pool\ \ \ \
> GPRINT:vch1max:%6.1lf\ %sWh\  GPRINT:vch1avg:%6.1lf\ %sWh\
> GPRINT:vch1min:%6.1lf\ %sWh\ \  GPRINT:vch1tot:%7.2lf\ %sWh\\l
> DEF:ext=solarprod3.rrd:total:AVERAGE:start=1262304000:end=1262343599
> CDEF:extw=ext CDEF:cext=extw,3600,* VDEF:vextmax=cext,MAXIMUM
> VDEF:vextavg=cext,AVERAGE VDEF:vextmin=cext,MINIMUM
> VDEF:vexttot=extw,TOTAL AREA:cext#FFd700a0:Solar\ \ \
> GPRINT:vextmax:%6.1lf\ %sWh\  GPRINT:vextavg:%6.1lf\ %sWh\
> GPRINT:vextmin:%6.1lf\ %sWh\ \  GPRINT:vexttot:%7.2lf\ %sWh\\l
> COMMENT:-----------------------------------------------------------------\\l
> HRULE:0#999999 DEF:import=feedin30min3.rrd:in:AVERAGE:start=1262304000:end=1262343599
> CDEF:importw=import,1800,/ CDEF:cimport=importw,3600,*
> CDEF:cimport2=cimport,-1,* VDEF:vimportmax=cimport,MAXIMUM
> VDEF:vimportavg=cimport,AVERAGE VDEF:vimportmin=cimport,MINIMUM
> VDEF:vimporttot=importw,TOTAL AREA:cimport2#ff4500:Import\ \
> GPRINT:vimportmax:%6.1lf\ %sWh\  GPRINT:vimportavg:%6.1lf\ %sWh\
> GPRINT:vimportmin:%6.1lf\ %sWh\ \  GPRINT:vimporttot:%7.2lf\ %sWh\\l
> DEF:export=feedin30min3.rrd:out:AVERAGE:start=1262304000:end=1262343599
> CDEF:exportw=export,1800,/ CDEF:cexport=exportw,3600,*
> CDEF:cexport2=cexport,-1,* VDEF:vexportmax=cexport,MAXIMUM
> VDEF:vexportavg=cexport,AVERAGE VDEF:vexportmin=cexport,MINIMUM
> VDEF:vexporttot=exportw,TOTAL AREA:cexport2#FFd700a0:Export\ \
> GPRINT:vexportmax:%6.1lf\ %sWh\  GPRINT:vexportavg:%6.1lf\ %sWh\
> GPRINT:vexportmin:%6.1lf\ %sWh\ \  GPRINT:vexporttot:%7.2lf\ %sWh\\l
> ==10650==
> ==10650== Invalid read of size 8
> ==10650==    at 0x4E37D56: data_proc (rrd_graph.c:1253)
> ==10650==    by 0x4E3FFD1: graph_paint (rrd_graph.c:3276)
> ==10650==    by 0x4E43308: rrd_graph_v (rrd_graph.c:3939)
> ==10650==    by 0x4E42D05: rrd_graph (rrd_graph.c:3820)
> ==10650==    by 0x402F78: HandleInputLine (rrd_tool.c:790)
> ==10650==    by 0x40377B: main (rrd_tool.c:511)
> ==10650==  Address 0x97966f8 is 0 bytes after a block of size 88 alloc'd
> ==10650==    at 0x4C25153: malloc (vg_replace_malloc.c:195)
> ==10650==    by 0x4E37686: data_calc (rrd_graph.c:1127)
> ==10650==    by 0x4E3FC97: graph_paint (rrd_graph.c:3232)
> ==10650==    by 0x4E43308: rrd_graph_v (rrd_graph.c:3939)
> ==10650==    by 0x4E42D05: rrd_graph (rrd_graph.c:3820)
> ==10650==    by 0x402F78: HandleInputLine (rrd_tool.c:790)
> ==10650==    by 0x40377B: main (rrd_tool.c:511)
> ==10650==
> 561x288
> ==10650==
> ==10650== HEAP SUMMARY:
> ==10650==     in use at exit: 376,314 bytes in 4,296 blocks
> ==10650==   total heap usage: 14,880 allocs, 10,584 frees, 9,257,593
> bytes allocated
> ==10650==
> ==10650== LEAK SUMMARY:
> ==10650==    definitely lost: 8,508 bytes in 14 blocks
> ==10650==    indirectly lost: 19,408 bytes in 609 blocks
> ==10650==      possibly lost: 229,291 bytes in 988 blocks
> ==10650==    still reachable: 119,107 bytes in 2,685 blocks
> ==10650==         suppressed: 0 bytes in 0 blocks
> ==10650== Rerun with --leak-check=full to see details of leaked memory
> ==10650==
> ==10650== For counts of detected and suppressed errors, rerun with: -v
> ==10650== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 7 from 7)
>
>   
Oops ;-) Seems my wild guess was totally right ;-)

==10650== Invalid read of size 8
==10650==    at 0x4E37D56: data_proc (rrd_graph.c:1253)
==10650==    by 0x4E3FFD1: graph_paint (rrd_graph.c:3276)
==10650==    by 0x4E43308: rrd_graph_v (rrd_graph.c:3939)
==10650==    by 0x4E42D05: rrd_graph (rrd_graph.c:3820)
==10650==    by 0x402F78: HandleInputLine (rrd_tool.c:790)
==10650==    by 0x40377B: main (rrd_tool.c:511)
==10650==  Address 0x97966f8 is 0 bytes after a block of size 88 alloc'd
==10650==    at 0x4C25153: malloc (vg_replace_malloc.c:195)
==10650==    by 0x4E37686: data_calc (rrd_graph.c:1127)
==10650==    by 0x4E3FC97: graph_paint (rrd_graph.c:3232)
==10650==    by 0x4E43308: rrd_graph_v (rrd_graph.c:3939)
==10650==    by 0x4E42D05: rrd_graph (rrd_graph.c:3820)
==10650==    by 0x402F78: HandleInputLine (rrd_tool.c:790)
==10650==    by 0x40377B: main (rrd_tool.c:511)
==10650==

If you are familiar with GDB debugging or one of its frontends (like
DDD) some more details could be useful. Set a breakpoint at that line
(in rrdgraph.c) and check the local context given.
>> Please install the library symbols for rrdtool and associated libraries
>> beforehand so valgrind finds them and reports proper locations in you dump.
>>     
> I compiled rrdtool on a Ubuntu 9.10 myself as the current ubuntu
> packages are broken (the python binding package is empty)
> So getting the debugging symbols isn't a problem
>   
Well, I try to stick with the prebuilt packages for most things, but
there are symbols for them usually called *-dev or *-dbg ;-)
>>> http://i45.tinypic.com/2mmhxj.png -> ok
>>> http://i45.tinypic.com/2llldn9.png -> ok
>>> http://i45.tinypic.com/2llldn9.jpg -> ok
>>> http://i50.tinypic.com/8vn3pk.png -> not ok
>>>
>>> I have another plot that is made of only 3 graphs.
>>> Sometimes any combination of 2 or 3 graph works ; but graphing one
>>> alone doesn't work ; getting those ? in the scale on the lest.
>>>       
>> hmmm, can't see the question marks you mentioned for the last of those
>> links. Could you please elaborate?
>>     
> Oops, my bad..
> Here is one
> http://i45.tinypic.com/1owv0g.png
>   
Really suspicious as the only thing that isn't shown is the graph;
although the legend at the bottom works just fine ...
> It happens about twice a day now. On all system logging similar data
> (power monitoring, one at home, one at work)
>   
>> hmmm, could you also check the used libraries for their version numbers.
>> If you have another computer where it works, could you provide version
>> numbers for it too? (Just to see if this is related to some externally
>> used librariy)
>>     
> It has the same behaviour on two completely different machines. That
> is from time to time, no graph is generated and the scale on the right
> contains '?'
>
> The two machines are :  one is running RRDTOOL 1.3.9 on a FreeBSD 64
> bits machine and the other is running RRDTOOL 1.4.2 on a Ubuntu 9.10
> (linux 2.6.31)
>
> So it couldn't be any different from one another, the FreeBSD box
> doesn't even use glibc
>   
hmmm, given the above valgrind log I'd eliminate external library
problems (for now).
> Thanks for your help
>
> Jean-Yves
>   
No problem,

BenBE.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-users/attachments/20100101/b2acf044/attachment-0001.pgp 


More information about the rrd-users mailing list