Your message dated Fri, 25 Apr 2014 20:27:30 +0200
with message-id <[email protected]>
and subject line Re: Bug#600844: rrdtool resize corrupts the original file
has caused the Debian Bug report #600844,
regarding rrdtool resize corrupts the original file
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
600844: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600844
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: rrdtool
Version: 1.3.1-4
Severity: important
Using "rrdtool restore" corrupts RRD files. According to its manual
page, rrdresize(1), the command is supposed to create a new file,
resize.rrd, and is not supposed to alter the original file in any way.
Unfortunately, the original file is altered and the newly created file
is unusable.
The following commands demonstrate the problems:
1 octo@huhu:/tmp $ rrdtool create -s 10 test.rrd DS:value:GAUGE:20:0:U
RRA:AVERAGE:0.5:1:360
2 octo@huhu:/tmp $ ls -l test.rrd
-rw-r--r-- 1 octo octo 3424 2010-10-20 14:42 test.rrd
3 octo@huhu:/tmp $ sha1sum test.rrd
915acef170e20588de560dfff907765aa99f7315 test.rrd
4 octo@huhu:/tmp $ rrdtool resize test.rrd 0 GROW 8280
5 octo@huhu:/tmp $ ls -l test.rrd resize.rrd
-rw------- 1 octo octo 69664 2010-10-20 14:42 resize.rrd
-rw-r--r-- 1 octo octo 3424 2010-10-20 14:42 test.rrd
6 octo@huhu:/tmp $ sha1sum test.rrd
5cbbfef92e0914141e763e0d1e47a5e11b83b620 test.rrd
7 octo@huhu:/tmp $ rrdtool info test.rrd | grep rows
rra[0].rows = 8640
8 octo@huhu:/tmp $ rrdtool info resize.rrd | grep rows
rra[0].rows = 8640
9 octo@huhu:/tmp $ rrdtool dump resize.rrd | grep '<v>' | grep -v NaN | wc -l
8280
10 octo@huhu:/tmp $ rrdtool dump test.rrd | grep '<v>' | grep -v NaN | wc -l
0
Command 1 creates a new RRD file which is not used outside of this
demonstration. Command 4 alters the first and only RRA to hold one day
of data rather than one hour. In contrast to the documented behavior the
original file is changed, as you can see by the changed SHA1 sum.
Command 7 shows that the original file is now reported as having 8640
rows, although the file size didn't change (commands 2 and 5). This
leads to problems when you try to fill the file with data:
octo@huhu:/tmp $ t=`date +%s`; for ((i=0; i < 100000; i++)); do rrdtool
update test.rrd $t:42; let t="$t+10"; done
[… a second or two pass, then …]
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
rrdtool: symbol lookup error: /usr/lib/librrd.so.4: undefined symbol: rrd_free
Segmentation fault
Segmentation fault
Segmentation fault
rrdtool: symbol lookup error: /usr/lib/librrd.so.4: undefined symbol: free,
version GLIBC_2.0
Segmentation fault
[…]
The segmentation faults don't appear right away, but after a short
moment. I'm assuming that filling the first 360 rows works as expected.
resize.rrd has a different problem: The newly created rows *should* be
filled with NaN, since there is no reasonable default value to fill them
with. Instead, those 8280 rows are filled with something else (0.0 to be
precise), see command 9.
I didn't have a chance to dive into the code to track down the problem
yet. It appears, however, that SVN revision 1726 introduces a fix that
might address this problem.
Regards,
—octo
[0] <http://oss.oetiker.ch/rrdtool-trac/changeset/1726/>
-- System Information:
Debian Release: 5.0.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=UTF-8) (ignored: LC_ALL set to
en_US.UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages rrdtool depends on:
ii libc6 2.7-18lenny4 GNU C Library: Shared libraries
ii libfontconfig1 2.6.0-3 generic font configuration library
ii libpixman-1-0 0.10.0-2 pixel-manipulation library for X a
ii libpng12-0 1.2.27-2+lenny4 PNG library - runtime
ii librrd4 1.3.1-4 Time-series data storage and displ
ii libx11-6 2:1.1.5-2 X11 client-side library
ii libxcb-render-util0 0.2.1+git1-1 utility libraries for X C Binding
ii libxcb-render0 1.1-1.2 X C Binding, render extension
ii libxcb1 1.1-1.2 X C Binding
ii libxrender1 1:0.9.4-2 X Rendering Extension client libra
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
rrdtool recommends no packages.
Versions of packages rrdtool suggests:
ii librrds-perl 1.3.1-4 Time-series data storage and displ
-- no debconf information
--- End Message ---
--- Begin Message ---
Source: rrdtool
Source-Version: 1.4.7-1
On Mon, Jan 23, 2012 at 12:08:30AM +0100, Christoph Biedl wrote:
> Florian Forster wrote...
>
> > Using "rrdtool restore" corrupts RRD files. According to its manual
> > page, rrdresize(1), the command is supposed to create a new file,
> > resize.rrd, and is not supposed to alter the original file in any way.
> > Unfortunately, the original file is altered and the newly created file
> > is unusable.
>
> Re-visiting that issue: I can reproduce this in Lenny (1.3.1-4).
> Appearently the data corruption and segmentations faults have been
> fixed in Squeeze (1.4.3-1), however ...
>
> > 4 octo@huhu:/tmp $ rrdtool resize test.rrd 0 GROW 8280
>
> ... that command creates an 'ERROR: attempting to write beyond end of
> file' message now. Upstream version 1.4.6 seems to have taken care of
> that, too.
Thanks for checking and verifying this! :-)
--
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/
Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
signature.asc
Description: Digital signature
--- End Message ---
