Hi, Am 05.09.2009 03:11, schrieb Rick Dicaire: > On Fri, Sep 4, 2009 at 9:06 PM, Benny Baumann<[email protected]> wrote: > >> You missed doing the bt command after the segfault which would have >> > OOPS my apologies... > No problem ;-) > (gdb) file /usr/local/bin/php > Reading symbols from /usr/local/bin/php...done. > (gdb) run missing_rrd.php > Starting program: /usr/local/bin/php missing_rrd.php > [Thread debugging using libthread_db enabled] > [New Thread 0xb78128d0 (LWP 17634)] > PHP Warning: Module 'rrdtool' already loaded in Unknown on line 0 > Did you check your php.ini (and other parsed config files of PHP which are parsed) that there's only (exactly) one with a line extension=rrdtool.so ??? > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb78128d0 (LWP 17634)] > 0xb785a41b in ____strtol_l_internal () from /lib/libc.so.6 > (gdb) bt > #0 0xb785a41b in ____strtol_l_internal () from /lib/libc.so.6 > #1 0xb785a180 in strtol () from /lib/libc.so.6 > #2 0xb7756443 in rrd_create (argc=17, argv=0x8c206e4) at > /usr/include/stdlib.h:291 > #3 0xb77977ee in zif_rrd_create (ht=3, return_value=0x8c1fff8, > return_value_ptr=0x0, this_ptr=0x0, > return_value_used=1) at /usr/local/include/php/ext/rrdtool/rrdtool.c:499 > hmmm, that more or less confirms my guess that this is not a crash of the RRDtool extension directly (or at least not initially), but more or less some internal error in librrd.
Could you run the same command as your script performs on the command line? i.e. # rrdtool create missing.rrd --step 86400 --start 1231022640 "DS:missing:GAUGE:172800:U:U" "DS:msie:GAUGE:172800:U:U" "DS:none:GAUGE:172800:U:U" "RRA:AVERAGE:0.5:1:360" "RRA:AVERAGE:0.5:7:360" "RRA:AVERAGE:0.5:30:360" "RRA:AVERAGE:0.5:360:360" "RRA:MAX:0.5:1:360" "RRA:MAX:0.5:7:360" "RRA:MAX:0.5:30:360" "RRA:MAX:0.5:360:360" I wonder if this crashes too ... Some other commands that might help pin down the issue (just type them after the segfault occured): frame //Show the current stack frame and variables; include e.g. #1 to show a specific one) info args //More detailled information on variables of the current stack frame; maybe combine with print) return //Leave the current stack frame and return into the nex tupper (calling) function print argc print argv[0] //After print follows a C-style expression) the frame command should give some variable names that are available here One question is: Are the strings passed correctly in frame #2 and (what string is passed to #1 when the crash occurs. If you want a bit more comfortable debugging environment you might try the graphical debugger DDD which uses GDB as a backend, but visualizes the information a bit better. Regards, BenBE.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
