the part of the code giving trouble is pretty sure to cause a segfault for all calls to rrd_update on platforms where time_t is NOT 64bit ... which is still pretty common I guess ...
I will publish 1.3.7 as soon as I get some more feedback that the patch actually fixes the problem others have seen. cheers tobi Today kevin brintnall wrote: > On Wed, Apr 01, 2009 at 11:01:24AM -0800, Mr. James W. Laferriere wrote: > > Hello Kevin , > > Hi James, forgive my late reply.. I am out on holiday. > > > There are two places in the make process that that file is compiled or > > built , They're in the attached file , make-rrdtool-1_3_6.rrd_update_c.log > > . > > I also have a full make log capture if you ever need that . > > These do look good.. -g and no -O. However, based on the backtrace it > does look like the call to write_RRA_row() is still being optimized out. > > Does your build environment contain any other things that would turn on > optimization? i.e. $CFLAGS in the environment or in the default make > settings? > > Send me the full log off-list. > > > > It will be very helpful to see the ds_idx value; I suspect it's this > > > pointer de-reference that's causing the SIGSEGV, because all the other > > > pointers look correct: rrd->ds_def[ds_idx].ds_nam > > > > See attached , rrdtool-segfault-20090401.log . > > Your debug commands: > > (gdb) p rrd->stat_head->ds_cnt > No symbol "rrd" in current context. > (gdb) p rrd->stat_head > No symbol "rrd" in current context. > (gdb) p rrd->ds_def[ds_idx].ds_nam > No symbol "rrd" in current context. > (gdb) exit > Undefined command: "exit". Try "help". > > ...are not useful since they are in the wrong stack frame. You need to > use "(gdb) select 4" to examine this frame. It would be helpful if you > could retry. > > #4 0xb7cc1193 in write_to_rras (rrd=0xbff20944, rrd_file=0x897b658, > rra_step_cnt=<value optimized out>, rra_begin=2760, > current_time=1238611056, skip_update=0x89cdfb0, > pcdp_summary=0xbff209a0) at rrd_update.c:1944 > > Also, see Tobi's recent patch. This is the same part of code that is > giving you trouble. > > https://lists.oetiker.ch/pipermail/rrd-developers/2009-April/003074.html > > What are sizeof(time_t) and sizeof(long long) on your platform? > > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch [email protected] ++41 62 775 9902 / sb: -9900 _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
