From Hermann.Lauer at iwr.uni-heidelberg.de  Sat Apr  5 22:39:23 2008
From: Hermann.Lauer at iwr.uni-heidelberg.de (Hermann Lauer)
Date: Sat, 5 Apr 2008 22:39:23 +0200
Subject: [rrd-developers] Daylight saving time change issue with rrdtool
	fetch
In-Reply-To: <mailman.0.1207427606.16381.rrd-developers@lists.oetiker.ch>
References: <mailman.0.1207427606.16381.rrd-developers@lists.oetiker.ch>
Message-ID: <20080405203923.GB9973@lemon.iwr.uni-heidelberg.de>

Hello,

during daylight change last year I got a fault in a python application
with the rrdtool module returning a false error.
This can be easily demonstrated with the
commandline tool, too (tested under linux with 1.2.15, 1.2.23 and 1.3beta4):

$ export TZ=Europe/Berlin
$ rrdtool fetch sample.rrd -s 1193533140 -e 1193533200 AVERAGE
ERROR: start (1193536740) should be less than end (1193533200)
$ unset TZ
$ rrdtool fetch sample.rrd -s 1193533140 -e 1193533200 AVERAGE
<normal output suppressed>

After looking at the code in parsetime() in src/parsetime.c to me it looks like 
rrdtools time parser makes an for unix seconds superfluos double
conversion where that dst issue most probably originates from.

To circumvent the error someone could be tempted to use relative
times, but then the 
data returned is probably wrong.

Hope this helps cleaning up that issue - or are I'm somehow wrong ?

Greetings
  Hermann

-- 
Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres 
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
Email: Hermann.Lauer at iwr.uni-heidelberg.de


From mlb at decisionsoft.com  Thu Apr 10 14:00:44 2008
From: mlb at decisionsoft.com (Matthew Boyle)
Date: Thu, 10 Apr 2008 13:00:44 +0100
Subject: [rrd-developers] buffer overflow in global_ctx
Message-ID: <47FE016C.30904@decisionsoft.com>

lines 27 and 28 of rrd_not_thread_safe.c are the wrong way round.  as a 
result, global_ctx->rrd_error points to a 256 byte buffer, while 
global_ctx->len claims it's 4096 bytes.

this means a long enough error message can lead to a buffer overflow in 
rrd_set_error().

the attached patch (against the SVN snapshot) fixes this.

--matt


-- 
Matthew Boyle
Junior Systems Administrator
DecisionSoft Limited                        http://www.decisionsoft.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reorder.diff
Type: text/x-patch
Size: 368 bytes
Desc: not available
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20080410/b87de7cb/attachment.bin 

From tobi at oetiker.ch  Sat Apr 12 11:19:16 2008
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Sat, 12 Apr 2008 11:19:16 +0200 (CEST)
Subject: [rrd-developers] Daylight saving time change issue with rrdtool
 fetch
In-Reply-To: <20080405203923.GB9973@lemon.iwr.uni-heidelberg.de>
References: <mailman.0.1207427606.16381.rrd-developers@lists.oetiker.ch>
	<20080405203923.GB9973@lemon.iwr.uni-heidelberg.de>
Message-ID: <alpine.DEB.1.00.0804121116550.5272@sebohet.brgvxre.pu>

Hi Hermann,

I guess I should just not mess with DST so much ...

Index: parsetime.c
===================================================================
--- parsetime.c (revision 1286)
+++ parsetime.c (working copy)
@@ -915,7 +916,6 @@
       panic(e("unparsable trailing text: '...%s%s'", sc_token, sct));
     }

-    ptv->tm.tm_isdst = -1; /* for mktime to guess DST status */
     if( ptv->type == ABSOLUTE_TIME )
       if( mktime( &ptv->tm ) == -1 ) { /* normalize & check */
         /* can happen for "nonexistent" times, e.g. around 3am */

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten
http://it.oetiker.ch tobi at oetiker.ch ++41 62 213 9902


From tobi at oetiker.ch  Mon Apr 21 00:56:46 2008
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Mon, 21 Apr 2008 00:56:46 +0200 (CEST)
Subject: [rrd-developers] rrdtool 1.3 is drawing near (last feature is in)
Message-ID: <alpine.DEB.1.10.0804210047270.27488@sebohet.brgvxre.pu>

Developers,

Over the last few days I have integrated a heavily modified version
of Mark Plaksins patch into RRDtool 1.3dev. The result is a new
interface to the RRDtool graph function called 'graphv' or when
calling from C 'rrd_graph_v'. The new interface returns a lot of
meta-data about the graph in rrd_info style. This even includes the
graph itself when called with '' or '-' as the name of the graph.

The new call is supported on the RRDtool command line, Perl and ruby
bindings. Unfortunately I am not very familiar with writing python
bindings, so this is left as an exercise to an avid python hacker
(the current python bindings do NOT include proper rrd_info
bindings, but rather an independent reimplementation of the same
functionality).

The meta information returned contains additional information about
the graph. Most notably the location of the actual graph inside the
image.

Thanks Mark for getting me started on this!

With this addition I am down to fixing some bugs mentioned on the
rrd traq but we should go rc pretty soon.

cheers
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten
http://it.oetiker.ch tobi at oetiker.ch ++41 62 213 9902


From mlb at decisionsoft.com  Tue Apr 22 20:25:01 2008
From: mlb at decisionsoft.com (Matthew Boyle)
Date: Tue, 22 Apr 2008 19:25:01 +0100
Subject: [rrd-developers] patch for bug #148
Message-ID: <480E2D7D.2030607@decisionsoft.com>

rrd_open() returns either a pointer or NULL, but PyRRD_info() tests the 
return value against -1.  if there's a problem opening the file, the 
error handling code is skipped anyway, and it attempts to fclose() an 
invalid filehandle.  the fclose() is unnecessary anyway, because any 
opened files are already closed by rrd_open().

there's also a mismatch between the function definitions for rrd_open in 
src/rrd.h and bindings/python/rrd_extra.h.  so rrd_open() gets a bad 
pointer to the rrd_t struct.  when this parameter gets initialised, it 
results in the saved %ebp and %eip being overwritten with NULLs.  this 
is obviously a slight problem when PyRRD_info() tries to return.

the attached patch (against svn r1331) should fix both these issues.

cheers,

--matt


-- 
Matthew Boyle
Junior Systems Administrator
DecisionSoft Limited                        http://www.decisionsoft.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rrdtool-bug148.patch
Type: text/x-patch
Size: 1120 bytes
Desc: not available
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20080422/08f89eb6/attachment.bin 

From tobi at oetiker.ch  Tue Apr 22 23:42:57 2008
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Tue, 22 Apr 2008 23:42:57 +0200 (CEST)
Subject: [rrd-developers] patch for bug #148
In-Reply-To: <480E2D7D.2030607@decisionsoft.com>
References: <480E2D7D.2030607@decisionsoft.com>
Message-ID: <alpine.DEB.1.10.0804222340500.22149@wbuna.brgvxre.pu>

Hi Matthew,

thanks I have integrated the fix ... the deeper problem here though
is that thepython bindings do not support rrd_info proper which is
not good ... since there are now three important features in
rrdtool that use the rrd_info mechanism for passing data back ...
(rrd_update_v, rrd_graph_v, rrd_info) so if there are any
ablebodied python hackers out there, this might be a good thing to
throw into the mix before 1.3 goes live, which is pretty soon now
...
cheers
tobi

Today Matthew Boyle wrote:

> rrd_open() returns either a pointer or NULL, but PyRRD_info() tests the return
> value against -1.  if there's a problem opening the file, the error handling
> code is skipped anyway, and it attempts to fclose() an invalid filehandle.
> the fclose() is unnecessary anyway, because any opened files are already
> closed by rrd_open().
>
> there's also a mismatch between the function definitions for rrd_open in
> src/rrd.h and bindings/python/rrd_extra.h.  so rrd_open() gets a bad pointer
> to the rrd_t struct.  when this parameter gets initialised, it results in the
> saved %ebp and %eip being overwritten with NULLs.  this is obviously a slight
> problem when PyRRD_info() tries to return.
>
> the attached patch (against svn r1331) should fix both these issues.
>
> cheers,
>
> --matt
>
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten
http://it.oetiker.ch tobi at oetiker.ch ++41 62 213 9902


From happy at usg.edu  Wed Apr 30 17:42:59 2008
From: happy at usg.edu (Mark Plaksin)
Date: Wed, 30 Apr 2008 11:42:59 -0400
Subject: [rrd-developers] rrdtool 1.3 is drawing near (last feature is
	in)
References: <alpine.DEB.1.10.0804210047270.27488@sebohet.brgvxre.pu>
Message-ID: <wszlrb5oxo.fsf@stone.tss.usg.edu>

Tobias Oetiker <tobi at oetiker.ch> writes:

> Over the last few days I have integrated a heavily modified version
> of Mark Plaksins patch into RRDtool 1.3dev. The result is a new
> interface to the RRDtool graph function called 'graphv' or when
> calling from C 'rrd_graph_v'. The new interface returns a lot of
> meta-data about the graph in rrd_info style. This even includes the
> graph itself when called with '' or '-' as the name of the graph.

Does anybody have a quick fix for me?  On RHEL5 (and Debian unstable) I
get this error when I run "make":

cd . && /bin/sh /home/happy/rrdtool-trunk/missing --run aclocal-1.9 
 cd . && /bin/sh /home/happy/rrdtool-trunk/missing --run automake-1.9 --foreign 
cd . && /bin/sh /home/happy/rrdtool-trunk/missing --run autoconf
/bin/sh ./config.status --recheck
running CONFIG_SHELL=/bin/sh /bin/sh ./configure  --prefix=/usr/local/happy  --no-create --no-rec
ursion                                                                                          
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
./configure: line 2118: syntax error near unexpected token `0.35.0,no-xml'
./configure: line 2118: `IT_PROG_INTLTOOL(0.35.0,no-xml)'
make: *** [config.status] Error 2


From rrdtool at nospam.verplant.org  Wed Apr 30 18:47:34 2008
From: rrdtool at nospam.verplant.org (Florian Forster)
Date: Wed, 30 Apr 2008 18:47:34 +0200
Subject: [rrd-developers] rrdtool 1.3 is drawing near (last feature is
	in)
In-Reply-To: <wszlrb5oxo.fsf@stone.tss.usg.edu>
References: <alpine.DEB.1.10.0804210047270.27488@sebohet.brgvxre.pu>
	<wszlrb5oxo.fsf@stone.tss.usg.edu>
Message-ID: <20080430164734.GW14121@verplant.org>

Hi Mark,

On Wed, Apr 30, 2008 at 11:42:59AM -0400, Mark Plaksin wrote:
> Does anybody have a quick fix for me?  On RHEL5 (and Debian unstable)
> I get this error when I run "make":

> ./configure: line 2118: `IT_PROG_INTLTOOL(0.35.0,no-xml)'

yes, most likely you're missing `intltool'. Under Debian the required
stuff is in the `intltool' package. After installing it, run
`MakeMakefile' and then `configure' again.

I tripped over the same problem - twice. That's why I changed a check
for intltool to the MakeMakefile script - it was added to the SVN
repository with revision 1313.

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20080430/c00f100f/attachment.bin 

From happy at usg.edu  Wed Apr 30 19:26:52 2008
From: happy at usg.edu (Mark Plaksin)
Date: Wed, 30 Apr 2008 13:26:52 -0400
Subject: [rrd-developers] rrdtool 1.3 is drawing near (last feature is
	in)
References: <alpine.DEB.1.10.0804210047270.27488@sebohet.brgvxre.pu>
	<wszlrb5oxo.fsf@stone.tss.usg.edu>
	<20080430164734.GW14121@verplant.org>
Message-ID: <wsve1z5k4j.fsf@stone.tss.usg.edu>

Florian Forster <rrdtool at nospam.verplant.org> writes:

> Hi Mark,
>
> On Wed, Apr 30, 2008 at 11:42:59AM -0400, Mark Plaksin wrote:
>> Does anybody have a quick fix for me?  On RHEL5 (and Debian unstable)
>> I get this error when I run "make":
>
>> ./configure: line 2118: `IT_PROG_INTLTOOL(0.35.0,no-xml)'
>
> yes, most likely you're missing `intltool'. Under Debian the required
> stuff is in the `intltool' package. After installing it, run
> `MakeMakefile' and then `configure' again.

I already had intltool on the Debian box.  I installed it on the RHEL5
box and ran MakeMakefile but I still get:

kage_3:~/rrdtool-trunk $ ./MakeMakefile 
libtool --version = 1.5.22  (expecting 1.5.14 or later)
automake  --version = 1.9.6  (expecting 1.9.5 or later)
autoconf --version = 2.59  (expecting 2.59 or later)
intltoolize --version = 0.35.0  (expecting 0.35.0 or later)
./configure: line 2118: syntax error near unexpected token `0.35.0,no-xml'
./configure: line 2118: `IT_PROG_INTLTOOL(0.35.0,no-xml)'
make: *** [config.status] Error 2

I'm using revision 1332 of the repo which is the latest unless I'm
missing something.


From happy at usg.edu  Wed Apr 30 19:45:27 2008
From: happy at usg.edu (Mark Plaksin)
Date: Wed, 30 Apr 2008 13:45:27 -0400
Subject: [rrd-developers] rrdtool 1.3 is drawing near (last feature is
	in)
References: <alpine.DEB.1.10.0804210047270.27488@sebohet.brgvxre.pu>
	<wszlrb5oxo.fsf@stone.tss.usg.edu>
	<20080430164734.GW14121@verplant.org>
	<wsve1z5k4j.fsf@stone.tss.usg.edu>
Message-ID: <wsr6cn5j9k.fsf@stone.tss.usg.edu>

Mark Plaksin <happy at usg.edu> writes:

>> yes, most likely you're missing `intltool'. Under Debian the required
>> stuff is in the `intltool' package. After installing it, run
>> `MakeMakefile' and then `configure' again.
>
> I already had intltool on the Debian box.  I installed it on the RHEL5
> box and ran MakeMakefile but I still get:

Goodness.  I swear I already checked for libxml2-devel on the RHEL box
but obviously not.  I installed it and all is well.

I still don't understand the problem w/ Debian but it *is* unstable :)

Sorry for the noise!


From happy at usg.edu  Wed Apr 30 21:27:46 2008
From: happy at usg.edu (Mark Plaksin)
Date: Wed, 30 Apr 2008 15:27:46 -0400
Subject: [rrd-developers] rrdtool 1.3 is drawing near (last feature is
	in)
References: <alpine.DEB.1.10.0804210047270.27488@sebohet.brgvxre.pu>
Message-ID: <wszlrb3zyl.fsf@stone.tss.usg.edu>

Tobias Oetiker <tobi at oetiker.ch> writes:

> Developers,
>
> Over the last few days I have integrated a heavily modified version
> of Mark Plaksins patch into RRDtool 1.3dev. The result is a new
> interface to the RRDtool graph function called 'graphv' or when
> calling from C 'rrd_graph_v'. The new interface returns a lot of
> meta-data about the graph in rrd_info style. This even includes the
> graph itself when called with '' or '-' as the name of the graph.

It looks good!

Would you make --image-only print the image_height and image_width?  It
turns out that our app (which we'll post if people ever stop quitting
their jobs :) can survive without it but that's just luck.  Had we
wanted/needed to write it a different way we would have needed the
height and width with --image-only.

Thanks!