[rrd-users] rrdtool 1.3.0 - memory eaten away by mmap.

[Raimund Berger]

Tobias Oetiker <tobi at oetiker.ch> writes:

> glad to hear it is cairo, so that question is what makes it go belly
> up ... maybe we can alter rrdtool NOT to stroke it in that
> particular way (and I thought by moving away from libart I got rid
> of these problems ... )
>
> can you rrdtool dump the offending file and send me that together
> with the fatal graph instruction (the shorter that graph call, the
> better).
>
> not re cairo, there have been a number of releases since edge came
> out, so maybe the bug is already fixed and can be backported to the
> debian cairo ...


Right, I can't seem to be able to reproduce the issue on - the more
recent - Debian testing (Lenny). On the other hand, I see no
mentioning of this on the Debian bug trackers, so the issue likely got
fixed "by accident".

The main purpose of me posting this is for reference anyway. Others
may run into this either, as Etch is by far not phased out yet, so it
might be good to know this could happen, considering it's pretty much
fatal behavior.

Also, in case somebody has a corresponding debugging environment
already set up, it may make sense to double check what parameter
values rrdtool feeds into cairo in this particular case, just to be
sure.

Anyway, here's the dump
http://www.2new.homepage.t-online.de/misc/dump.zip

and the command to reproduce that error on Debian Etch would be

 rrdtool graphv router-net-up.png \
  --start=end-24hours \
  --end=17.06.2008 \
  --height=300 \
  --upper-limit=52000 \
  --rigid \
  DEF:d=./dump.rrd:42:AVERAGE AREA:d#606060:ppp0

For reference, this is the cairo version that comes with Etch:
 $ dpkg -l libcairo2      
 ii  libcairo2  1.2.4-4.1+etch1  The Cairo 2D vector graphics library
and rrdtool would be version 1.3.0 .

If you try the above call on Etch, make sure to prepend an 'strace' so
you can see the mmap calls and interrupt (^C) soon enough. Else it
just silently mmap's your memory away.

Some notes on reproducing this issue

* neither of rigid/height/upperlimit can be ommitted or the call
  simply goes through; I tried other height values, and the issue also
  shows, but totally ommitting the option makes the call succeed

* the data is tx values from an adsl ppp link, and the rrd was
  initially created by munin; it exhibits a common "error" I didn't
  fix yet, i.e. defining the value as COUNTER; as the ppp link gets
  reset once every day (7am), that leads to those well known rrdtool
  wrap around fixups, i.e. pretty much insanely high values; maybe the
  issue is triggered also by those

* I tried to cut down the issue to some particular time interval, like
  one hour or so, in the hope it would even be one particular data
  value which caused the error; it didn't work though, for example I
  couldn't find a single 12 hour interval which reproduces the error
  (yet).

Hm, ok. Hope I didn't forget something. Sorry for the trouble.

Regards, R.