Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 1.1.0-dp5
-
Fix Version/s: 1.1.0-dp5
-
Component/s: library
-
Security Level: Public
-
Labels:None
-
Environment:2.0.0 community edition (build-1723)
php 5.3.15 built with --enable-debug, --enable-maintainer-zts and --enable-gcov
-
Flagged:Release Note
Description
The getStats functionality (both OO and regular function) causes memory leak errors to be displayed when operating against a 2.0 beta server.
[Mon Oct 1 18:09:46 2012] Script: '/home/orion/couchbase/php-ext-couchbase/tests/new/phpt/ServerStats/Stats.php'
/home/orion/couchbase/php-ext-couchbase/couchbase.c(1310) : Freeing 0x094A5068 (20 bytes), script=/home/orion/couchbase/php-ext-couchbase/tests/new/phpt/ServerStats/Stats.php
Last leak repeated 2 times
[Mon Oct 1 18:09:46 2012] Script: '/home/orion/couchbase/php-ext-couchbase/tests/new/phpt/ServerStats/Stats.php'
/home/orion/couchbase/php-ext-couchbase/couchbase.c(1311) : Freeing 0x094A5154 (10 bytes), script=/home/orion/couchbase/php-ext-couchbase/tests/new/phpt/ServerStats/Stats.php
Last leak repeated 2 times
=== Total 6 memory leaks detected ===
(Memory locations and paths would, of course, vary from the above.)
The couchbase.c lines being referenced are:
1310 MAKE_STD_ZVAL(val);
1311 ZVAL_STRINGL(val, (char *)bytes, nbytes, 1);
within php_couchbase_stat_callback.
This only seems to occur when operating against a 2.0 beta Couchbase server. It does not occur when operating against a 1.8 server. In discussion in #libcouchbase, it was mentioned that this might be due to something like the server returning a zero-length data value (in the bytes variable, which is from resp->v.v0.bytes of lcb_server_stat_resp_t* resp).
Setting sev to minor at a guess, since the total memory leak here is on the order of 100 bytes for a few hundred stats values retrieved. I can't see that this would be severe unless a user was calling getStats() a huge number of times in a single script invocation; so it's probably mostly an annoyance.
[Mon Oct 1 18:09:46 2012] Script: '/home/orion/couchbase/php-ext-couchbase/tests/new/phpt/ServerStats/Stats.php'
/home/orion/couchbase/php-ext-couchbase/couchbase.c(1310) : Freeing 0x094A5068 (20 bytes), script=/home/orion/couchbase/php-ext-couchbase/tests/new/phpt/ServerStats/Stats.php
Last leak repeated 2 times
[Mon Oct 1 18:09:46 2012] Script: '/home/orion/couchbase/php-ext-couchbase/tests/new/phpt/ServerStats/Stats.php'
/home/orion/couchbase/php-ext-couchbase/couchbase.c(1311) : Freeing 0x094A5154 (10 bytes), script=/home/orion/couchbase/php-ext-couchbase/tests/new/phpt/ServerStats/Stats.php
Last leak repeated 2 times
=== Total 6 memory leaks detected ===
(Memory locations and paths would, of course, vary from the above.)
The couchbase.c lines being referenced are:
1310 MAKE_STD_ZVAL(val);
1311 ZVAL_STRINGL(val, (char *)bytes, nbytes, 1);
within php_couchbase_stat_callback.
This only seems to occur when operating against a 2.0 beta Couchbase server. It does not occur when operating against a 1.8 server. In discussion in #libcouchbase, it was mentioned that this might be due to something like the server returning a zero-length data value (in the bytes variable, which is from resp->v.v0.bytes of lcb_server_stat_resp_t* resp).
Setting sev to minor at a guess, since the total memory leak here is on the order of 100 bytes for a few hundred stats values retrieved. I can't see that this would be severe unless a user was calling getStats() a huge number of times in a single script invocation; so it's probably mostly an annoyance.