[rrd-developers] rrdtool: *** glibc detected *** free(): invalid pointer: 0x08056450 ***

[Sebastian Harl]

Hi,

(Please keep 451852-forwarded at bugs.debian.org Cc'ed in replies to this E-mail)

I finally had the time to take a look at this bug report. Sorry for the
long delay.

On Sun, Nov 18, 2007 at 10:49:21PM +0100, Matej Kosik wrote:
> when I perform the following command
> 
> rrdtool graph /tmp/plot_1195420761938267.png --width 479 --height 71 --start 1195257600 --end 1195344000 -i -y 1:1 -l 0 -u 1 DEF:mystate=node_0.rrd:state:AVERAGE LINE2:mystate#FF0000
> 
> I get an error:
> 
> *** glibc detected *** free(): invalid pointer: 0x08056450 ***
> 
> and no graph is generated. The node_0.rrd file was created as follows:
> 
> 	rrdtool create /usr/local/src/nms/nms/priv/rrd/node_0.rrd -s 60000 DS:state:GAUGE:60:U:U RRA:AVERAGE:0.5:1:604800

I can reproduce a segfault with the upcoming 1.3 release but it's not an
invalid call to free(). Here's the backtrace I get:

#0  0x0fe972d0 in memcpy () from /lib/libc.so.6
#1  0x0ffc725c in rrd_read (rrd_file=0x1005a4e0, buf=0x1005a4e8, count=8)
    at rrd_open.c:465
#2  0x0ffbc18c in rrd_fetch_fn (filename=0x1001a1e8 "foo.rrd", 
    cf_idx=CF_AVERAGE, start=0x1001a818, end=0x1001a81c, step=0xbf8bf644, 
    ds_cnt=0x1001a830, ds_namv=0x1001a838, data=0x1001a83c) at rrd_fetch.c:416
#3  0x0ff9faa0 in data_fetch (im=0xbf8bf7c0) at rrd_graph.c:827
#4  0x0ffa9754 in graph_paint (im=0xbf8bf7c0) at rrd_graph.c:2957
#5  0x0ffad6e4 in rrd_graph_v (argc=4, argv=0xbf8c2688) at rrd_graph.c:3646
#6  0x0ffad0c8 in rrd_graph (argc=4, argv=0xbf8c2688, prdata=0xbf8c232c, 
    xsize=0xbf8c2330, ysize=0xbf8c2334, stream=0x0, ymin=0xbf8c2338, 
    ymax=0xbf8c2340) at rrd_graph.c:3535
#7  0x10004768 in HandleInputLine (argc=5, argv=0xbf8c2684, out=0xff7f4a0)
    at rrd_tool.c:791
#8  0x10003534 in main (argc=5, argv=0xbf8c2684) at rrd_tool.c:492

Line 465 of rrd_open.c says:

  buf = memcpy(buf, rrd_file->file_start + rrd_file->pos, _cnt);

The buffer is passed from rrd_fetch_fn() in rrd_fetch.c. In line 330 of
that file, the buffer is allocated using:

  malloc(*ds_cnt * rows * sizeof(rrd_value_t))

Later (starting at line 375) a for-loop is used to sequentially read
from the RRD file into the buffer:

  for (i = start_offset;
       i < (signed) rrd.rra_def[chosen_rra].row_cnt - end_offset; i++)

Unfortunately, I did not have the time to take a closer look at how the
size passed to malloc() and the number of loop iterations are related to
one another. Note that during some iterations more than a single
rrd_value_t is read into the buffer.

This bug only appears if the step size of the RRD file is greater than
3550. In that case, start_offset (the initial value of the control
variable 'i' of that loop) is a fairly large negative number. The
following is the relevant debugging output for size = 3551:

  Entered rrd_fetch_fn() searching for the best match
  Looking for: start 1213086635 end 1213173035 step   216
  Considering: start 3360493238 end 1213170742 step  3551 best full match so far
  We found:    start 1213085518 end 1213174293 step  3551 rows  26
  rra_start 3360496789, rra_end 1213170742, start_off -604733, end_off -1
  First Seek: rra_base 556 rra_pointer 548981

start_offset is calculated in line 348:

  start_offset = (long) (*start + *step - rra_start_time) / (long) *step;

I suspect that we're getting some kind of overflow here. Tobi do you have any
ideas about that?

Cheers,
Sebastian

-- 
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

-------------- 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/20080611/ce839034/attachment.bin