[rrd-developers] [rrd-users] rrdtool php extension

[Benny Baumann]

Hi,

Am 05.09.2009 03:11, schrieb Rick Dicaire:
> On Fri, Sep 4, 2009 at 9:06 PM, Benny Baumann<BenBE at geshi.org> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20090905/49bc0e54/attachment.pgp