Re: [PHP-DEV] Req #51295: busyTimeout method for SQLite3
Hi Mark, I agree but I'm not the maintainer for PDO_SQLITE, I just happen to know it somewhat and thought it can be useful to you as reference. I am CCing Wez Furlong who I believe is the lead for it. May the source be with you, Best regards, Jess Portnoy Mark Karpeles wrote: Hi, I checked around PDO (which I don't use at all, but the source is usually a good documentation). The timeout can be changed for SQLite and SQLite3 PDO drivers with: $pdo-setAttribute(PDO::ATTR_TIMEOUT, value_in_seconds) I see that PDO::ATTR_TIMEOUT is not documented on http://php.net/manual/en/pdo.setattribute.php - it might be a good idea to fix this :) Mark Le dimanche 14 mars 2010 à 09:57 +0200, Jess Portnoy a écrit : Hello Mark, Note that while indeed sqlite3_busy_timeout() is not extended by the SQLite3 and PDO_SQLITE extensions, it is called internally in ext/pdo_sqlite/sqlite_driver.c. I think it is a good idea to extend it but also, that if you do, it should probably also be done for PDO_SQLITE as it may be useful there as well. May the source be with you, Best regards, Jess Portnoy Mark Karpeles wrote: Hello, I've been encountering a problem with SELECT queries and SQLite3 as load was growing on my system. From times to times I was getting this error: Warning: SQLite3Stmt::execute(): Unable to execute statement: database is locked After searching on google I saw I should call sqlite3_busy_timeout() and found out that there was no way to call it from the SQLite3 extension (which is new to PHP 5.3.x). Here's a patch that will add this method to the SQLite3 class: http://bugs.php.net/51295 https://ookoo.org/svn/snip/php_5_3-sqlite3-busytimeout-method.patch Any comment welcome. Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Req #51295: busyTimeout method for SQLite3
Hello Mark, Note that while indeed sqlite3_busy_timeout() is not extended by the SQLite3 and PDO_SQLITE extensions, it is called internally in ext/pdo_sqlite/sqlite_driver.c. I think it is a good idea to extend it but also, that if you do, it should probably also be done for PDO_SQLITE as it may be useful there as well. May the source be with you, Best regards, Jess Portnoy Mark Karpeles wrote: Hello, I've been encountering a problem with SELECT queries and SQLite3 as load was growing on my system. From times to times I was getting this error: Warning: SQLite3Stmt::execute(): Unable to execute statement: database is locked After searching on google I saw I should call sqlite3_busy_timeout() and found out that there was no way to call it from the SQLite3 extension (which is new to PHP 5.3.x). Here's a patch that will add this method to the SQLite3 class: http://bugs.php.net/51295 https://ookoo.org/svn/snip/php_5_3-sqlite3-busytimeout-method.patch Any comment welcome. Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] multi-jobs run-tests.php
Hello all, While on the subject of run-tests.php, any plans for it to support web server SAPIs and not just CLI/CGI? I've looked at http://qa.php.net/projects.php and saw no such bullet but I thought asking anyhow won't hurt. Thanks, May the source be with you, Best regards, Jess Portnoy Raphael Geissert wrote: Hi Pierre, Pierre Joye wrote: There is an on-going work on run-test (which began as part of last year GSoC). I would begin there instead of working on the current run-test.php. Parallel testing is part of the new features as well, in a portable way (like not only where pcntl is available). Ah, I see, great. From a quick look at the code it looks like it also uses pcntl. Is there any plan to switch to that other implementation? No work has been done in something like the threads extension, has there? Cheers, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Crash when sending SIGHUP to the Apache parent process when IMagick is loaded
Hello all, I have IMagick 2.2.2 [latest stable in PECL] loaded with PHP 5.3.1. When sending SIGHUP, Apache defuncts, the BT is as follows: (gdb) bt #0 0x7f069935b384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x7f0699356bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x7f06993564fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x7f06903df7b3 in LockSemaphoreInfo (semaphore_info=0xfa9130) at magick/semaphore.c:373 #4 0x7f06903a5160 in DestroyModuleList () at magick/module.c:135 #5 0x7f06903a1d79 in DestroyMagickList () at magick/magick.c:140 #6 0x7f06903a1dff in MagickCoreTerminus () at magick/magick.c:1238 #7 0x7f069037caf7 in DefaultFatalErrorHandler (magick_unused_severity=value optimized out, reason=0xfa9430 unable to initialize module loader `Inappropriate ioctl for device', description=0x0) at magick/exception.c:305 #8 0x7f069037d0c6 in CatchException (exception=0x7fff61e2ff80) at magick/exception.c:218 #9 0x7f06903a46c0 in GetModuleInfo (tag=value optimized out, exception=0xfa8de0) at magick/module.c:793 #10 0x7f06903a1232 in GetMagickInfo (name=0x0, exception=0xfa8de0) at magick/magick.c:800 #11 0x7f06903a14d0 in MagickCoreGenesis (path=0x0, establish_signal_handlers=MagickFalse) at magick/magick.c:1201 #12 0x7f06905a9736 in MagickWandGenesis () at wand/magick-wand.c:987 #13 0x7f069072bf56 in zm_startup_imagick () from /usr/local/zend/lib/php_extensions/imagick.so #14 0x7f069322f8ec in zend_startup_module_ex (module=0x12b0310) at /php-5.3.1/Zend/zend_API.c:1613 #15 0x7f0693238475 in zend_hash_apply (ht=0x7f0693734ce0, apply_func=0x7f069322f800 zend_startup_module_ex) at /php-5.3.1/Zend/zend_hash.c:673 #16 0x7f06932322fa in zend_startup_modules () at /php-5.3.1/Zend/zend_API.c:1662 #17 0x7f06931dcce4 in php_module_startup (sf=value optimized out, additional_modules=0x7f06936fc4a0, num_additional_modules=1) at /php-5.3.1/main/main.c:2018 #18 0x7f06932b2c45 in php_apache2_startup (sapi_module=0xfa9130) at /php-5.3.1/sapi/apache2handler/sapi_apache2.c:328 #19 0x7f06932b36e6 in php_apache_server_startup (pconf=0xae6168, plog=value optimized out, ptemp=value optimized out, s=0xaec968) at /php-5.3.1/sapi/apache2handler/sapi_apache2.c:437 #20 0x00438cf4 in ap_run_post_config () #21 0x00425bbc in main () It appears to me as though IMagick's MSHUTDOWN fails to do proper cleanup and thus, the crash occurs in the next startup but this does not occur with PHP 5_2 [tested 5.2.12] or PHP 5.3.0 and is also resolved in 5.3.2RC1 which is good. Can anyone refer me to the revision that solves this issue? I am asking because I would very much like to backport it to 5.3.1. Thanks in advance, -- May the source be with you, Best regards, Jess Portnoy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Crash when sending SIGHUP to the Apache parent process when IMagick is loaded
Found the issue. I've applied a local patchset which included this revision: http://svn.php.net/viewvc/?view=revisionrevision=291488 Which fixes: #50261 (Crash When Calling Parent Constructor with call_user_func()) However, it also included a small mistake commit, later reverted in revision 291491. Thanks anyway, May the source be with you, Best regards, Jess Portnoy Jess Portnoy wrote: Hello all, I have IMagick 2.2.2 [latest stable in PECL] loaded with PHP 5.3.1. When sending SIGHUP, Apache defuncts, the BT is as follows: (gdb) bt #0 0x7f069935b384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x7f0699356bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x7f06993564fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x7f06903df7b3 in LockSemaphoreInfo (semaphore_info=0xfa9130) at magick/semaphore.c:373 #4 0x7f06903a5160 in DestroyModuleList () at magick/module.c:135 #5 0x7f06903a1d79 in DestroyMagickList () at magick/magick.c:140 #6 0x7f06903a1dff in MagickCoreTerminus () at magick/magick.c:1238 #7 0x7f069037caf7 in DefaultFatalErrorHandler (magick_unused_severity=value optimized out, reason=0xfa9430 unable to initialize module loader `Inappropriate ioctl for device', description=0x0) at magick/exception.c:305 #8 0x7f069037d0c6 in CatchException (exception=0x7fff61e2ff80) at magick/exception.c:218 #9 0x7f06903a46c0 in GetModuleInfo (tag=value optimized out, exception=0xfa8de0) at magick/module.c:793 #10 0x7f06903a1232 in GetMagickInfo (name=0x0, exception=0xfa8de0) at magick/magick.c:800 #11 0x7f06903a14d0 in MagickCoreGenesis (path=0x0, establish_signal_handlers=MagickFalse) at magick/magick.c:1201 #12 0x7f06905a9736 in MagickWandGenesis () at wand/magick-wand.c:987 #13 0x7f069072bf56 in zm_startup_imagick () from /usr/local/zend/lib/php_extensions/imagick.so #14 0x7f069322f8ec in zend_startup_module_ex (module=0x12b0310) at /php-5.3.1/Zend/zend_API.c:1613 #15 0x7f0693238475 in zend_hash_apply (ht=0x7f0693734ce0, apply_func=0x7f069322f800 zend_startup_module_ex) at /php-5.3.1/Zend/zend_hash.c:673 #16 0x7f06932322fa in zend_startup_modules () at /php-5.3.1/Zend/zend_API.c:1662 #17 0x7f06931dcce4 in php_module_startup (sf=value optimized out, additional_modules=0x7f06936fc4a0, num_additional_modules=1) at /php-5.3.1/main/main.c:2018 #18 0x7f06932b2c45 in php_apache2_startup (sapi_module=0xfa9130) at /php-5.3.1/sapi/apache2handler/sapi_apache2.c:328 #19 0x7f06932b36e6 in php_apache_server_startup (pconf=0xae6168, plog=value optimized out, ptemp=value optimized out, s=0xaec968) at /php-5.3.1/sapi/apache2handler/sapi_apache2.c:437 #20 0x00438cf4 in ap_run_post_config () #21 0x00425bbc in main () It appears to me as though IMagick's MSHUTDOWN fails to do proper cleanup and thus, the crash occurs in the next startup but this does not occur with PHP 5_2 [tested 5.2.12] or PHP 5.3.0 and is also resolved in 5.3.2RC1 which is good. Can anyone refer me to the revision that solves this issue? I am asking because I would very much like to backport it to 5.3.1. Thanks in advance, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] http://bugs.php.net DB seems to be down
Hello all, I can get to the system's index page just fine but any bug lookup results in: The data center is offline. This might be a feature, and not a bug, but probably not. It was probably reported already but in case it was not, thought I'd drop you a line. Thanks, -- May the source be with you, Best regards, Jess Portnoy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] newbie: my extension not getting compiled/included in Php-5.3.1 (RH linux)
Hello, Please attach your config.m4 file which will help understand what's wrong. You should also try to compare yours with an existing one, maybe the problem will become apparent simply by comparison. May the source be with you, Best regards, Jess Portnoy Sanjeev Kumar wrote: I am new to Php-dev and trying to add an extension to Php I downloaded php-5.3.1 src on RedHatLinux4 . After adding my extension, the configure/make doesn't build my extension and include in Php. commands that I ran after unzipping the php5.3.1 src: cd ext ./ext_skel --extname=pdo-mydbext enabled in pdo-mydbext/config.m4 cd .. ./buildconf --force ./configure --enable-pdo-mydbext make My issue: No objects are compiled for my pdo-mydbext. In fact, seeing the output of ./configure on screen, I can see that my ext didn't called in extensions list. .. whether to enable pdo-myext ... didn't get displayed by ./configure make didn't build myext. What do I need to add my extension(to be compiled, and so on..) thanks, -sanjeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] AM_PROG_LEX needed in Zend/configure.in
Hello all, When attempting to build only the libZend.a by executing: #cd /Zend Zend# ./buildconf One gets this message [redundant output was truncated]: Makefile.am: Lex source seen but `LEX' is undefined Makefile.am: The usual way to define `LEX' is to add `AM_PROG_LEX' Makefile.am: to `configure.in' and run `aclocal' and `autoconf' again. buildconf: keeping configure Adding AM_PROG_LEX solves this problem. Compiling only the archive can be useful for various things so I think this should be made operational, especially since I don't see any down side to it. Attaching a patch. Thanks, -- May the source be with you, Best regards, Jess Portnoy --- php-5.3.2RC1/Zend/configure.in.orig 2009-04-02 16:34:05.0 +0300 +++ php-5.3.2RC1/Zend/configure.in 2009-04-02 16:33:51.0 +0300 @@ -24,6 +24,7 @@ LIBZEND_DLSYM_CHECK AM_PROG_LIBTOOL +AM_PROG_LEX if test $enable_debug != yes; then AM_SET_LIBTOOL_VARIABLE([--silent]) fi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mysqli PHPTs call my_mysqli_connect() which does not exist
Hello all, In the 5_3 branch and also in 5.3.1, some MySQLi PHPTs call my_mysqli_connect() which is not defined. Is this a mistakingly committed change? Seems like they should call mysqli_connect(). See also: http://gcov.php.net/viewer.php?version=PHP_5_3func=testsfile=ext%2Fmysqli%2Ftests%2Fmysqli_insert_packet_overflow.phpt Thanks, -- May the source be with you, Best regards, Jess Portnoy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli PHPTs call my_mysqli_connect() which does not exist
Hi Michael, Thanks, now I see it. Sorry, did not look hard enough. May the source be with you, Best regards, Jess Portnoy Michael Maclean wrote: Jess Portnoy wrote: In the 5_3 branch and also in 5.3.1, some MySQLi PHPTs call my_mysqli_connect() which is not defined. Is this a mistakingly committed change? Seems like they should call mysqli_connect(). It's defined in connect.inc as a wrapper. See http://php-og.mgdm.net/opengrok/xref/PHP_5_3/ext/mysqli/tests/connect.inc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Attempt to include ext/mysqlnd/mysqlnd_portability.h when building MySQLi against libmysql
Hello all,
My configure command is as follows:
./configure --disable-xml --disable-dom --disable-libxml
--disable-simplexml --without-pear --disable-xmlreader
--disable-xmlwriter --without-iconv
I then archive the result and use it to build various PHP extensions,
among which MySQLi.
Since I did not configure with mysqlnd, I do not have ext/mysqlnd copied
onto $PHP_PREFIX/include/php/ext, causing this following code to fail
compilation:
#include ext/mysqlnd/mysqlnd_portability.h
Attached is a suggested patch for php-5.3.1/ext/mysqli/mysqli.c and
php-5.3.1/ext/mysqli/mysqli_api.c, basically:
+#ifdef MYSQLI_USE_MYSQLND
#include ext/mysqlnd/mysqlnd_portability.h
+#endif
Thanks in advance,
--
May the source be with you,
Best regards,
Jess Portnoy
--- php-5.3.1/ext/mysqli/mysqli.c 2009-10-14 15:51:25.0 +0200
+++ php-5.3.1/ext/mysqli/mysqli.c.mod 2010-01-11 18:04:57.0 +0200
@@ -32,7 +32,9 @@
#include ext/standard/php_string.h
#include php_mysqli_structs.h
#include zend_exceptions.h
+#ifdef MYSQLI_USE_MYSQLND
#include ext/mysqlnd/mysqlnd_portability.h
+#endif
ZEND_DECLARE_MODULE_GLOBALS(mysqli)
static PHP_GINIT_FUNCTION(mysqli);
--- php-5.3.1/ext/mysqli/mysqli_api.c 2009-10-14 15:51:25.0 +0200
+++ php-5.3.1/ext/mysqli/mysqli_api.c.mod 2010-01-11 18:25:23.0 +0200
@@ -31,7 +31,9 @@
#include php_globals.h
#include ext/standard/info.h
#include php_mysqli_structs.h
+#ifdef MYSQLI_USE_MYSQLND
#include ext/mysqlnd/mysqlnd_portability.h
+#endif
/* {{{ proto mixed mysqli_affected_rows(object link)
Get number of affected rows in previous MySQL operation */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Attempt to include ext/mysqlnd/mysqlnd_portability.h when building MySQLi against libmysql
Just to clarify, this applies only to the 5_3 branch. May the source be with you, Best regards, Jess Portnoy Jess Portnoy wrote: Hello all, My configure command is as follows: ./configure --disable-xml --disable-dom --disable-libxml --disable-simplexml --without-pear --disable-xmlreader --disable-xmlwriter --without-iconv I then archive the result and use it to build various PHP extensions, among which MySQLi. Since I did not configure with mysqlnd, I do not have ext/mysqlnd copied onto $PHP_PREFIX/include/php/ext, causing this following code to fail compilation: #include ext/mysqlnd/mysqlnd_portability.h Attached is a suggested patch for php-5.3.1/ext/mysqli/mysqli.c and php-5.3.1/ext/mysqli/mysqli_api.c, basically: +#ifdef MYSQLI_USE_MYSQLND #include ext/mysqlnd/mysqlnd_portability.h +#endif Thanks in advance, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Attempt to include ext/mysqlnd/mysqlnd_portability.h when building MySQLi against libmysql
Hi Andrey,
Yes, it compiled just fine with my patch.
Even loaded :)
May the source be with you,
Best regards,
Jess Portnoy
Andrey Hristov wrote:
Hi Jess,
does it compile after that, because I guess it doesn't. We use some
macros from that header file to be able to handle bit types correctly
in mysqli, when libmysql is used.
#if MYSQL_VERSION_ID 50002
if (mysql_fetch_field_direct(result, i)-type == MYSQL_TYPE_BIT) {
my_ulonglong llval;
char tmp[22];
switch (field_len[i]) {
case 8:llval = (my_ulonglong) bit_uint8korr(row[i]);break;
case 7:llval = (my_ulonglong) bit_uint7korr(row[i]);break;
case 6:llval = (my_ulonglong) bit_uint6korr(row[i]);break;
case 5:llval = (my_ulonglong) bit_uint5korr(row[i]);break;
case 4:llval = (my_ulonglong) bit_uint4korr(row[i]);break;
case 3:llval = (my_ulonglong) bit_uint3korr(row[i]);break;
case 2:llval = (my_ulonglong) bit_uint2korr(row[i]);break;
case 1:llval = (my_ulonglong) uint1korr(row[i]);break;
}
#endif
Best,
Andrey
Jess Portnoy wrote:
Hello all,
My configure command is as follows:
./configure --disable-xml --disable-dom --disable-libxml
--disable-simplexml --without-pear --disable-xmlreader
--disable-xmlwriter --without-iconv
I then archive the result and use it to build various PHP extensions,
among which MySQLi.
Since I did not configure with mysqlnd, I do not have ext/mysqlnd
copied onto $PHP_PREFIX/include/php/ext, causing this following code
to fail compilation:
#include ext/mysqlnd/mysqlnd_portability.h
Attached is a suggested patch for php-5.3.1/ext/mysqli/mysqli.c and
php-5.3.1/ext/mysqli/mysqli_api.c, basically:
+#ifdef MYSQLI_USE_MYSQLND
#include ext/mysqlnd/mysqlnd_portability.h
+#endif
Thanks in advance,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Attempt to include ext/mysqlnd/mysqlnd_portability.h when building MySQLi against libmysql
Reason is MYSQL_VERSION_ID is defined here:
ext/mysqlnd/mysqlnd_libmysql_compat.h:#define
MYSQL_VERSION_ID MYSQLND_VERSION_ID
And then, included here:
ext/mysqli/mysqli_mysqlnd.h:#include ext/mysqlnd/mysqlnd_libmysql_compat.h
Same is done with MySQL and PDO_MYSQL.
May the source be with you,
Best regards,
Jess Portnoy
Jess Portnoy wrote:
Hi Andrey,
Yes, it compiled just fine with my patch.
Even loaded :)
May the source be with you,
Best regards,
Jess Portnoy
Andrey Hristov wrote:
Hi Jess,
does it compile after that, because I guess it doesn't. We use some
macros from that header file to be able to handle bit types correctly
in mysqli, when libmysql is used.
#if MYSQL_VERSION_ID 50002
if (mysql_fetch_field_direct(result, i)-type == MYSQL_TYPE_BIT) {
my_ulonglong llval;
char tmp[22];
switch (field_len[i]) {
case 8:llval = (my_ulonglong) bit_uint8korr(row[i]);break;
case 7:llval = (my_ulonglong) bit_uint7korr(row[i]);break;
case 6:llval = (my_ulonglong) bit_uint6korr(row[i]);break;
case 5:llval = (my_ulonglong) bit_uint5korr(row[i]);break;
case 4:llval = (my_ulonglong) bit_uint4korr(row[i]);break;
case 3:llval = (my_ulonglong) bit_uint3korr(row[i]);break;
case 2:llval = (my_ulonglong) bit_uint2korr(row[i]);break;
case 1:llval = (my_ulonglong) uint1korr(row[i]);break;
}
#endif
Best,
Andrey
Jess Portnoy wrote:
Hello all,
My configure command is as follows:
./configure --disable-xml --disable-dom --disable-libxml
--disable-simplexml --without-pear --disable-xmlreader
--disable-xmlwriter --without-iconv
I then archive the result and use it to build various PHP
extensions, among which MySQLi.
Since I did not configure with mysqlnd, I do not have ext/mysqlnd
copied onto $PHP_PREFIX/include/php/ext, causing this following code
to fail compilation:
#include ext/mysqlnd/mysqlnd_portability.h
Attached is a suggested patch for php-5.3.1/ext/mysqli/mysqli.c and
php-5.3.1/ext/mysqli/mysqli_api.c, basically:
+#ifdef MYSQLI_USE_MYSQLND
#include ext/mysqlnd/mysqlnd_portability.h
+#endif
Thanks in advance,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Attempt to include ext/mysqlnd/mysqlnd_portability.h when building MySQLi against libmysql
Hi Andrey,
I understand. If the the bit_ macros are specific to mysqlnd then
perhaps their usage should also be protected by an #ifdef
MYSQLI_USE_MYSQLND?
May the source be with you,
Best regards,
Jess Portnoy
Andrey Hristov wrote:
Jess Portnoy wrote:
Reason is MYSQL_VERSION_ID is defined here:
ext/mysqlnd/mysqlnd_libmysql_compat.h:#define
MYSQL_VERSION_ID MYSQLND_VERSION_ID
And then, included here:
ext/mysqli/mysqli_mysqlnd.h:#include
ext/mysqlnd/mysqlnd_libmysql_compat.h
Same is done with MySQL and PDO_MYSQL.
May the source be with you,
Best regards,
Jess Portnoy
MYSQL_VERSION_ID is also defined by libmysql/MySQL server. Only if you
use pre-5.0 libmysql headers this should not compile. the bit_
macros are specific to mysqlnd, not exposed by libmysql.
Andrey
Jess Portnoy wrote:
Hi Andrey,
Yes, it compiled just fine with my patch.
Even loaded :)
May the source be with you,
Best regards,
Jess Portnoy
Andrey Hristov wrote:
Hi Jess,
does it compile after that, because I guess it doesn't. We use some
macros from that header file to be able to handle bit types
correctly in mysqli, when libmysql is used.
#if MYSQL_VERSION_ID 50002
if (mysql_fetch_field_direct(result, i)-type ==
MYSQL_TYPE_BIT) {
my_ulonglong llval;
char tmp[22];
switch (field_len[i]) {
case 8:llval = (my_ulonglong) bit_uint8korr(row[i]);break;
case 7:llval = (my_ulonglong) bit_uint7korr(row[i]);break;
case 6:llval = (my_ulonglong) bit_uint6korr(row[i]);break;
case 5:llval = (my_ulonglong) bit_uint5korr(row[i]);break;
case 4:llval = (my_ulonglong) bit_uint4korr(row[i]);break;
case 3:llval = (my_ulonglong) bit_uint3korr(row[i]);break;
case 2:llval = (my_ulonglong) bit_uint2korr(row[i]);break;
case 1:llval = (my_ulonglong) uint1korr(row[i]);break;
}
#endif
Best,
Andrey
Jess Portnoy wrote:
Hello all,
My configure command is as follows:
./configure --disable-xml --disable-dom --disable-libxml
--disable-simplexml --without-pear --disable-xmlreader
--disable-xmlwriter --without-iconv
I then archive the result and use it to build various PHP
extensions, among which MySQLi.
Since I did not configure with mysqlnd, I do not have ext/mysqlnd
copied onto $PHP_PREFIX/include/php/ext, causing this following
code to fail compilation:
#include ext/mysqlnd/mysqlnd_portability.h
Attached is a suggested patch for php-5.3.1/ext/mysqli/mysqli.c
and php-5.3.1/ext/mysqli/mysqli_api.c, basically:
+#ifdef MYSQLI_USE_MYSQLND
#include ext/mysqlnd/mysqlnd_portability.h
+#endif
Thanks in advance,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Attempt to include ext/mysqlnd/mysqlnd_portability.h when building MySQLi against libmysql
I see but assuming mysqlnd is copied, I can still see a problem, in the
configure script:
echo #define $php_def_have_what 1 ext/mysqlnd/php_mysqlnd_config.h
When running my configure:
./configure --disable-xml --disable-dom --disable-libxml
--disable-simplexml --without-pear --disable-xmlreader
--disable-xmlwriter --without-iconv
ext/mysqlnd/php_mysqlnd_config.h is not created and
ext/mysqlnd/mysqlnd_portability.h attempts to include that and hence,
even if the mysqlnd dir is copied to $PHP_PREFIX/include/php/ext
regardless of your configure argument, there will still be a problem
with this auto generated header.
May the source be with you,
Best regards,
Jess Portnoy
Andrey Hristov wrote:
Jess Portnoy wrote:
Hi Andrey,
I understand. If the the bit_ macros are specific to mysqlnd then
perhaps their usage should also be protected by an #ifdef
MYSQLI_USE_MYSQLND?
by specific I mean that mysqlnd introduces them but they are valid for
everyone who wants to be able to decode BIT columns sent from the
server. Without these macros BIT fields are useless in the client,
can't be decoded.
Johannes did some change in a recent commit, but I am not sure if all
of mysqlnd's headers are installed at make install. This should be the
case or no extension that relies on mysqlnd will be able to compile as
a module (with phpize).
May the source be with you,
Best regards,
Jess Portnoy
Best,
Andrey
Andrey Hristov wrote:
Jess Portnoy wrote:
Reason is MYSQL_VERSION_ID is defined here:
ext/mysqlnd/mysqlnd_libmysql_compat.h:#define
MYSQL_VERSION_ID MYSQLND_VERSION_ID
And then, included here:
ext/mysqli/mysqli_mysqlnd.h:#include
ext/mysqlnd/mysqlnd_libmysql_compat.h
Same is done with MySQL and PDO_MYSQL.
May the source be with you,
Best regards,
Jess Portnoy
MYSQL_VERSION_ID is also defined by libmysql/MySQL server. Only if
you use pre-5.0 libmysql headers this should not compile. the
bit_ macros are specific to mysqlnd, not exposed by libmysql.
Andrey
Jess Portnoy wrote:
Hi Andrey,
Yes, it compiled just fine with my patch.
Even loaded :)
May the source be with you,
Best regards,
Jess Portnoy
Andrey Hristov wrote:
Hi Jess,
does it compile after that, because I guess it doesn't. We use
some macros from that header file to be able to handle bit types
correctly in mysqli, when libmysql is used.
#if MYSQL_VERSION_ID 50002
if (mysql_fetch_field_direct(result, i)-type ==
MYSQL_TYPE_BIT) {
my_ulonglong llval;
char tmp[22];
switch (field_len[i]) {
case 8:llval = (my_ulonglong)
bit_uint8korr(row[i]);break;
case 7:llval = (my_ulonglong)
bit_uint7korr(row[i]);break;
case 6:llval = (my_ulonglong)
bit_uint6korr(row[i]);break;
case 5:llval = (my_ulonglong)
bit_uint5korr(row[i]);break;
case 4:llval = (my_ulonglong)
bit_uint4korr(row[i]);break;
case 3:llval = (my_ulonglong)
bit_uint3korr(row[i]);break;
case 2:llval = (my_ulonglong)
bit_uint2korr(row[i]);break;
case 1:llval = (my_ulonglong) uint1korr(row[i]);break;
}
#endif
Best,
Andrey
Jess Portnoy wrote:
Hello all,
My configure command is as follows:
./configure --disable-xml --disable-dom --disable-libxml
--disable-simplexml --without-pear --disable-xmlreader
--disable-xmlwriter --without-iconv
I then archive the result and use it to build various PHP
extensions, among which MySQLi.
Since I did not configure with mysqlnd, I do not have
ext/mysqlnd copied onto $PHP_PREFIX/include/php/ext, causing
this following code to fail compilation:
#include ext/mysqlnd/mysqlnd_portability.h
Attached is a suggested patch for php-5.3.1/ext/mysqli/mysqli.c
and php-5.3.1/ext/mysqli/mysqli_api.c, basically:
+#ifdef MYSQLI_USE_MYSQLND
#include ext/mysqlnd/mysqlnd_portability.h
+#endif
Thanks in advance,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Attempt to include ext/mysqlnd/mysqlnd_portability.h when building MySQLi against libmysql
Hi Andrey, Sounds good to me. Would you like me to test and submit a patch or will you? May the source be with you, Best regards, Jess Portnoy Andrey Hristov wrote: Hi Jess, Jess Portnoy wrote: I see but assuming mysqlnd is copied, I can still see a problem, in the configure script: echo #define $php_def_have_what 1 ext/mysqlnd/php_mysqlnd_config.h When running my configure: ./configure --disable-xml --disable-dom --disable-libxml --disable-simplexml --without-pear --disable-xmlreader --disable-xmlwriter --without-iconv ext/mysqlnd/php_mysqlnd_config.h is not created and ext/mysqlnd/mysqlnd_portability.h attempts to include that and hence, even if the mysqlnd dir is copied to $PHP_PREFIX/include/php/ext regardless of your configure argument, there will still be a problem with this auto generated header. May the source be with you, Best regards, Jess Portnoy Possible solution is to copy the macros from mysqlnd_portability.h to mysqli and use ifndef to define them, if mysqlnd_portability.h is not available. Hopefully the code will compile without the need to typedef types as the macros use C99 types (uintXX_t) which should be available mostly anywhere. Best, Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about where to put the gtk.ini file for php(5)-gtk?
Hello,
There is an ENV var called PHP_INI_SCAN_DIR, when exported, it can
override the default scandir set during compilation. You can set this in
an RC file sourced by apachectl. From you description I can tell you're
packaging an RPM for it so, as I'm sure you're aware, you need to think
of the best way to accomplish this as an RPM cannot just run wild and
has to consider fitting in the general scheme of things and that may
make it somewhat difficult :)
About GTK, what exactly happens? It should not crash the PHP module but
I admit I never tried and am not familiar with the problem.
In my personal opinion, if the extension cannot load under some SAPI, it
should be disabled. That is, PHP_MINIT should include a check of SAPI
and return FAILURE in the event the current SAPI cannot be operated under.
Another extension I guess should do that is PCNTL, known not to work
well in web server context.
May the source be with you,
Best regards,
Jess Portnoy
Joop Boonen wrote:
All,
I have a question. I'm building the php(5)-gtk package. But when I put the
gtk.ini in /etc/php5/conf.d which is the --with-config-file-scan-dir.
php programs like cacti that are accessed via apache don't run any more.
As it also want to start up gtk but it fails because it doesn't have a
display. Which is logical and also wanted.
As the gtk.ini file should only be in cli (and not apache etc), I'm
wondering how this issue could be best handled?
Is there a way to put two directories in --with-config-file-scan-dir like
--with-config-file-scan-dir=%{php_sysconf}/conf.d
%{php_sysconf}/$sapi/conf.d
Regards,
Joop.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about where to put the gtk.ini file for php(5)-gtk?
Just another small comment about PHP_INI_SCAN_DIR, it was introduced in
5.2.7, I assume you're packaging the current stable but just to be on
the safe side I thought I'd mention it :)
May the source be with you,
Best regards,
Jess Portnoy
Jess Portnoy wrote:
Hello,
There is an ENV var called PHP_INI_SCAN_DIR, when exported, it can
override the default scandir set during compilation. You can set this
in an RC file sourced by apachectl. From you description I can tell
you're packaging an RPM for it so, as I'm sure you're aware, you need
to think of the best way to accomplish this as an RPM cannot just run
wild and has to consider fitting in the general scheme of things and
that may make it somewhat difficult :)
About GTK, what exactly happens? It should not crash the PHP module
but I admit I never tried and am not familiar with the problem.
In my personal opinion, if the extension cannot load under some SAPI,
it should be disabled. That is, PHP_MINIT should include a check of
SAPI and return FAILURE in the event the current SAPI cannot be
operated under.
Another extension I guess should do that is PCNTL, known not to work
well in web server context.
May the source be with you,
Best regards,
Jess Portnoy
Joop Boonen wrote:
All,
I have a question. I'm building the php(5)-gtk package. But when I
put the
gtk.ini in /etc/php5/conf.d which is the --with-config-file-scan-dir.
php programs like cacti that are accessed via apache don't run any more.
As it also want to start up gtk but it fails because it doesn't have a
display. Which is logical and also wanted.
As the gtk.ini file should only be in cli (and not apache etc), I'm
wondering how this issue could be best handled?
Is there a way to put two directories in --with-config-file-scan-dir
like
--with-config-file-scan-dir=%{php_sysconf}/conf.d
%{php_sysconf}/$sapi/conf.d
Regards,
Joop.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #48843
Hi Andre, I'm not 100% sure, but I believe this is related: http://bugs.php.net/bug.php?id=50251 May the source be with you, Best regards, Jess Portnoy Andre Hübner wrote: Hello, sorry, but i can not leave comments to Bugs with status Bogus: http://bugs.php.net/bug.php?id=48843 Is this Bug really fixed/complete discovered ? In 5.3.1 my logfile is still flooded with deprecated Messages. PHP-Settings are log_errors = OFF error_reporting = E_ALL ~E_NOTICE ~E_DEPRECATED timezone is also set which was in relation to duplicate reports: date.timezone = Europe/Berlin how to solve this if it is really not a bug? Thanks, Andre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #48843
Sure, NP. Happy patching. May the source be with you, Best regards, Jess Portnoy Andre Hübner wrote: Hello, I'm not 100% sure, but I believe this is related: http://bugs.php.net/bug.php?id=50251 ohh yes, did not found this report by previously searches :/ Thanks, could use this patch... Andre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php-5.2.12 and pecl install: Seg. fault
Hello, One thing that immediately comes to mind is the old OpenSSL version [0.9.7]. Doesn't SLES9 offer OpenSSL 0.9.8 of any version? Is 0.9.7 as high as it gets in their official repos? If so, I'd compile the latest OpenSSL on my own [0.9.8l] and try, also, what is the OpenSSL version on the SLES10SP2? The attached trace is not really useful as there are no debug symbols, if you want to go that road they will be necessary. May the source be with you, Best regards, Jess Portnoy Karl Pflästerer wrote: Hi, I wanted to install php-5.2.12 on a 32-Bit SLES9 SP4. I had no problems with the 64-Bit SLES10SP2 but with the 32-Bit I can't use pecl. Whenever I try to install a library I only get a seg. fault. I tried also php-5.2.11 and there is also the same problem. php-5.2.9 works. pecl install pdflib expands to: /usr/local/php-5.2.12/bin/php -C -n -q -d include_path=/usr/local/php-5.2.12/lib/php -d output_buffering=1 -d variables_order=EGPCS -d safe_mode=0 -d register_argc_argv=On /usr/local/php-5.2.12/lib/php/peclcmd.php install pdflib If I run that with gdb I see: (gdb) run Starting program: /usr/local/php-5.2.12/bin/php -C -n -q -d include_path=/usr/local/php-5.2.12/lib/php -d output_buffering=1 -d variables_order=EGPCS -d safe_mode=0 -d register_argc_argv=On /usr/local/php-5.2.12/lib/php/peclcmd.php install pdflib [Thread debugging using libthread_db enabled] [New Thread 1080940768 (LWP 32645)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1080940768 (LWP 32645)] 0x402fb9f4 in SSL_SESSION_hash () from /usr/lib/libssl.so.0.9.7 (gdb) bt #0 0x402fb9f4 in SSL_SESSION_hash () from /usr/lib/libssl.so.0.9.7 #1 0x402fba3b in SSL_SESSION_hash_LHASH_HASH () from /usr/lib/libssl.so.0.9.7 #2 0x40016a6c in d2i_X509 () from /lib/ld-linux.so.2 #3 0x403fceac in __JCR_LIST__ () from /usr/lib/libcrypto.so.0.9.7 #4 0x403d171d in getrn () from /usr/lib/libcrypto.so.0.9.7 #5 0x in ?? () (gdb) And there I'm lost. How can I debug further what the problem might be. On another server (also SLES9SP4 32-bit Linux) I see: (gdb) run Starting program: /usr/local/php-5.2.12/bin/php -C -n -q -d include_path=/usr/local/php-5.2.12/lib/php -d output_buffering=1 -d variables_order=EGPCS -d safe_mode=0 -d register_argc_argv=On /usr/local/php-5.2.12/lib/php/peclcmd.php install pdflib [Thread debugging using libthread_db enabled] [New Thread 1082827648 (LWP 25177)] *** glibc detected *** double free or corruption (out): 0x4083f088 *** *** glibc detected *** double free or corruption (out): 0x4083f090 *** Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1082827648 (LWP 25177)] 0x4053e498 in ASN1_STRING_free () from /usr/lib/libcrypto.so.0.9.7 (gdb) bt #0 0x4053e498 in ASN1_STRING_free () from /usr/lib/libcrypto.so.0.9.7 #1 0x4083f05e in main_arena () from /lib/tls/libc.so.6 #2 0x4053b565 in ASN1_primitive_free () from /usr/lib/libcrypto.so.0.9.7 #3 0x08068afb in ?? () #4 0x405d3eac in __JCR_LIST__ () from /usr/lib/libcrypto.so.0.9.7 #5 0xf0604082 in ?? () #6 0x405d3eac in __JCR_LIST__ () from /usr/lib/libcrypto.so.0.9.7 #7 0x405cefe8 in X509_seq_tt () from /usr/lib/libcrypto.so.0.9.7 #8 0x4053b61b in asn1_item_combine_free () from /usr/lib/libcrypto.so.0.9.7 #9 0x405cf72c in ASN1_OCTET_STRING_it () from /usr/lib/libcrypto.so.0.9.7 #10 0x405bd330 in gdImageCreateFromPngCtx () at gd_png.c:124 #11 0x in ?? () KP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php-5.2.12 and pecl install: Seg. fault
Hello, See here: http://distrowatch.com/table.php?distribution=suse This is very useful when trying to determining what distro has what of what version. May the source be with you, Best regards, Jess Portnoy Karl Pflästerer wrote: Jess Portnoy j...@zend.com writes: Hello, One thing that immediately comes to mind is the old OpenSSL version [0.9.7]. Doesn't SLES9 offer OpenSSL 0.9.8 of any version? Is 0.9.7 as high as it gets in their official repos? If so, I'd compile the latest OpenSSL on my own [0.9.8l] and try, also, what is the OpenSSL version on the SLES10SP2? The attached trace is not really useful as there are no debug symbols, if you want to go that road they will be necessary. Unfortunately if I see it right 0.9.7 is the newest version for openssl in SLES9. SLES10 has 0.9.8 and there everything works. I'll try it with compiling openssl but I would avoid it if I could. The maintenance for these systems (4 machines) won't be easier then :-( download, compile, test It works with openssl 0.9.8l, thanks. KP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php-5.2.12 and pecl install: Seg. fault
Hi Pierre, I may be wrong but as far as I can see, SSL is being used by PEAR, at least, potentially, I am not that well versed in its code but I ran: # grep -i ssl /usr/local/zend/share/pear/* -r --color And it does seem to return relevant results. Again, I admit I did not review throughly. May the source be with you, Best regards, Jess Portnoy Pierre Joye wrote: hi, I'm 99.99% sure that there are some libraries or extension mess. Please double check your extension directory and be sure that you are not loading old extensions or random libraries. Cheers, On Tue, Dec 22, 2009 at 4:27 PM, Karl Pflästerer k...@rl.pflaesterer.de wrote: Pierre Joye pierre@gmail.com writes: The pecl channel install does not use SSL and there is no signing involved, so the pecl install pdflib cmd won't use ssl. On your other Hi, that was the exact backtrace I got, when I ran pecl install pdflib. Something must call use ssl there, how would I otherwise get such a backtrace? script, gd crashes, are you opening an image from a https URL? If not, it means that your setup is broken (mixing lib/headers/x86/x64 versions?). I'll check that. I also wondered about the gd crash, since I didn't open an image; I just called `pecl install pdflib'. As I wrote in another message; for the first machine installing openssl from source helped; for the second (and third, fourth and fifth :-) ) I'll see. But as I wrote: php-5.2.9 worked; I tested 5.2.11 there I also had the segfault. I didn't install php-5.2.10 so I don't know if the change was from 5.2.9 to .10 or .11 KP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Using a stream function into another module
Hi, stream_array_to_fd_set() is defined in ext/standard/streamsfuncs.c, not the header. But I see the actual complaint is on ext/sockets/sockets.c:877: undefined reference to `stream_array_to_fd_set'... What exactly did you do? May the source be with you, Best regards, Jess Portnoy Samuel ROZE wrote: Nobody can help me ? Is there someone who can just give me some astuces ? Regards, Samuel ROZE. 2009/11/27 Samuel ROZE samuel.r...@gmail.com: Hello, I want to use two stream functions (stream_array_to_fd_set and stream_array_from_fd_set) in a module (/etc/modulename/modulename.c). To use them, i included the streamsfuncs.h file, with: #include ext/standard/streamsfuncs.h The problem is that when I want to compile, i've these errors: /home/samuel/Développement/workspaces/C-Cpp/PHP_5_3/ext/sockets/sockets.c:877: undefined reference to `stream_array_to_fd_set' /home/samuel/Développement/workspaces/C-Cpp/PHP_5_3/ext/sockets/sockets.c:884: undefined reference to `stream_array_to_fd_set' /home/samuel/Développement/workspaces/C-Cpp/PHP_5_3/ext/sockets/sockets.c:891: undefined reference to `stream_array_to_fd_set' /home/samuel/Développement/workspaces/C-Cpp/PHP_5_3/ext/sockets/sockets.c:936: undefined reference to `stream_array_emulate_read_fd_set' /home/samuel/Développement/workspaces/C-Cpp/PHP_5_3/ext/sockets/sockets.c:957: undefined reference to `stream_array_from_fd_set' /home/samuel/Développement/workspaces/C-Cpp/PHP_5_3/ext/sockets/sockets.c:958: undefined reference to `stream_array_from_fd_set' /home/samuel/Développement/workspaces/C-Cpp/PHP_5_3/ext/sockets/sockets.c:959: undefined reference to `stream_array_from_fd_set' How can I do to use them into my module ? Regards, Samuel ROZE. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php id string
Hello, Have you considered cases such as universal MAC/Darwin builds? The universal build method [used only by Apple but still, many PHP developers do run MAC] means you have several archs bundled together in the same binary, and, a binary built 2 ways [i386 and PPC or i386 and x86_64 or even 4 ways for that matter] can work on any of these archs. How do you suggest to handle that? May the source be with you, Best regards, Jess Portnoy jvlad wrote: Hi all, Starting with version 5.3 php checks id string when it loads the extensions to match its own one and it also shows this string in PHP Extension Build line of phpinfo(). That's great. This line contains api#, threadsafe, and compiler. So it's almost all important thigs to check and make sure that a particular module is binary-compatible with php core. All things, except just one, the CPU. It's known that Windows runs on many CPUs, Solaris runs fine under sparc, sparc64, x86, and x86_64. Needless to mention linux and *bsd systems (I guess they are running on everything). Why not to add what phpinfo() shows in Architecture, to the id string? Are there any reasons not to do this? -jvlad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php id string
And, though I'm sure everyone on the list is capable of finding this URL on their own, a short explanation: http://en.wikipedia.org/wiki/Universal_binary May the source be with you, Best regards, Jess Portnoy Jess Portnoy wrote: Hello, Have you considered cases such as universal MAC/Darwin builds? The universal build method [used only by Apple but still, many PHP developers do run MAC] means you have several archs bundled together in the same binary, and, a binary built 2 ways [i386 and PPC or i386 and x86_64 or even 4 ways for that matter] can work on any of these archs. How do you suggest to handle that? May the source be with you, Best regards, Jess Portnoy jvlad wrote: Hi all, Starting with version 5.3 php checks id string when it loads the extensions to match its own one and it also shows this string in PHP Extension Build line of phpinfo(). That's great. This line contains api#, threadsafe, and compiler. So it's almost all important thigs to check and make sure that a particular module is binary-compatible with php core. All things, except just one, the CPU. It's known that Windows runs on many CPUs, Solaris runs fine under sparc, sparc64, x86, and x86_64. Needless to mention linux and *bsd systems (I guess they are running on everything). Why not to add what phpinfo() shows in Architecture, to the id string? Are there any reasons not to do this? -jvlad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php id string
Perhaps it would be wise to display both the build arch and the current arch on which its running? I used the Darwin/MAC universal build example before but even on Windows and *nix as well when you think about it, one can run a 32bit binary on a 64bit OS, usually provided the stack below [Apache, etc] is also 32 bit. So, unlike the PHP_COMPILER_ID check, which makes sense as the various VCs are declared as not quite compatible, I think in the case of different archs this would be a mistake, just displaying the gathered arch info I can see no harm in though... May the source be with you, Best regards, Jess Portnoy Pierre Joye wrote: hi, This info is available in phpinfo on windows and I would like to add it in the php -v output as well. I'm not sure how we can safely rely on this info on other platforms but that's definitively something we should try to do. Cheers, On Sun, Nov 29, 2009 at 11:29 AM, jvlad d...@yandex.ru wrote: Hi all, Starting with version 5.3 php checks id string when it loads the extensions to match its own one and it also shows this string in PHP Extension Build line of phpinfo(). That's great. This line contains api#, threadsafe, and compiler. So it's almost all important thigs to check and make sure that a particular module is binary-compatible with php core. All things, except just one, the CPU. It's known that Windows runs on many CPUs, Solaris runs fine under sparc, sparc64, x86, and x86_64. Needless to mention linux and *bsd systems (I guess they are running on everything). Why not to add what phpinfo() shows in Architecture, to the id string? Are there any reasons not to do this? -jvlad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php id string
Apple ships their MAC OS with GCC that is capable of building universal binaries. Most MAC users expect packages to be built universal. Trust me, I also hate it but its true... If what you want is just to ensure the extensions are built for the same architecture as the PHP core, this I can understand, I'm just saying you need to take multiple archs bundled together under consideration. Also, I don't know if deciding for the dynamic loader if something can be loaded is so wise, if it can great, if not, it will yell at you anyhow.. May the source be with you, Best regards, Jess Portnoy jvlad wrote: Jess Portnoy j...@zend.com wrote in message news:4b1266e0.7010...@zend.com... Perhaps it would be wise to display both the build arch and the current arch on which its running? I used the Darwin/MAC universal build example before but even on Windows and *nix as well when you think about it, one can run a 32bit binary on a 64bit OS, usually provided the stack below [Apache, etc] is also 32 bit. So, unlike the PHP_COMPILER_ID check, which makes sense as the various VCs are declared as not quite compatible, I think in the case of different archs this would be a mistake, just displaying the gathered arch info I can see no harm in though... May the source be with you, Best regards, Jess Portnoy Pierre Joye wrote: hi, This info is available in phpinfo on windows and I would like to add it in the php -v output as well. I'm not sure how we can safely rely on this info on other platforms but that's definitively something we should try to do. Cheers, On Sun, Nov 29, 2009 at 11:29 AM, jvlad d...@yandex.ru wrote: Hi all, Starting with version 5.3 php checks id string when it loads the extensions to match its own one and it also shows this string in PHP Extension Build line of phpinfo(). That's great. This line contains api#, threadsafe, and compiler. So it's almost all important thigs to check and make sure that a particular module is binary-compatible with php core. All things, except just one, the CPU. It's known that Windows runs on many CPUs, Solaris runs fine under sparc, sparc64, x86, and x86_64. Needless to mention linux and *bsd systems (I guess they are running on everything). Why not to add what phpinfo() shows in Architecture, to the id string? Are there any reasons not to do this? -jvlad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Jess, Current platform plays no role. If it can't run a particular php build, there is nothing to care of. What I do care of is ABA which depends on the compile-time arch and nothing else. It's my understanding that id-string is a part of the technology to make sure that extensions are compatible with core. -jvlad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php id string
BTW, Macports also support building PHP in universal mode. May the source be with you, Best regards, Jess Portnoy Jess Portnoy wrote: Apple ships their MAC OS with GCC that is capable of building universal binaries. Most MAC users expect packages to be built universal. Trust me, I also hate it but its true... If what you want is just to ensure the extensions are built for the same architecture as the PHP core, this I can understand, I'm just saying you need to take multiple archs bundled together under consideration. Also, I don't know if deciding for the dynamic loader if something can be loaded is so wise, if it can great, if not, it will yell at you anyhow.. May the source be with you, Best regards, Jess Portnoy jvlad wrote: Jess Portnoy j...@zend.com wrote in message news:4b1266e0.7010...@zend.com... Perhaps it would be wise to display both the build arch and the current arch on which its running? I used the Darwin/MAC universal build example before but even on Windows and *nix as well when you think about it, one can run a 32bit binary on a 64bit OS, usually provided the stack below [Apache, etc] is also 32 bit. So, unlike the PHP_COMPILER_ID check, which makes sense as the various VCs are declared as not quite compatible, I think in the case of different archs this would be a mistake, just displaying the gathered arch info I can see no harm in though... May the source be with you, Best regards, Jess Portnoy Pierre Joye wrote: hi, This info is available in phpinfo on windows and I would like to add it in the php -v output as well. I'm not sure how we can safely rely on this info on other platforms but that's definitively something we should try to do. Cheers, On Sun, Nov 29, 2009 at 11:29 AM, jvlad d...@yandex.ru wrote: Hi all, Starting with version 5.3 php checks id string when it loads the extensions to match its own one and it also shows this string in PHP Extension Build line of phpinfo(). That's great. This line contains api#, threadsafe, and compiler. So it's almost all important thigs to check and make sure that a particular module is binary-compatible with php core. All things, except just one, the CPU. It's known that Windows runs on many CPUs, Solaris runs fine under sparc, sparc64, x86, and x86_64. Needless to mention linux and *bsd systems (I guess they are running on everything). Why not to add what phpinfo() shows in Architecture, to the id string? Are there any reasons not to do this? -jvlad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Jess, Current platform plays no role. If it can't run a particular php build, there is nothing to care of. What I do care of is ABA which depends on the compile-time arch and nothing else. It's my understanding that id-string is a part of the technology to make sure that extensions are compatible with core. -jvlad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] potential null dereference in ext/ftp/ftp.c
Hello, clang is indeed a great tool but since it does a lot more than just static analysis. For those cases where one wants source code analysis, especially security oriented, I'd recommend flawfinder [http://www.dwheeler.com/flawfinder]. This is a very good tool and it exists in the official repos for Debian, Ubuntu and FC [and probably many others but these I checked]. It can operate on both C and C++ source files [less relevant for the PHP engine but good to know, right?]. I ran it against the PHP 5.2.11 sources and am now sorting through results, patching suggestions may follow :) May the source be with you, Best regards, Jess Portnoy Michael Maclean wrote: Hi, Gwynne pointed me at the clang static analyser earlier on today, and so I've run it against current PHP_5_3. In the course of messing with it, it noticed a potential null dereference in ext/ftp - I've attached a one-liner to fix it. Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] potential null dereference in ext/ftp/ftp.c
Hey, The thing I like a lot about clang is that it can be used as a drop-in substitute for GCC so you can actual call clang or clang++ instead of executing gcc/g++, see here: http://clang.llvm.org/get_started.html The results you published certainly look interesting :) May the source be with you, Best regards, Jess Portnoy Michael Maclean wrote: Hi, Jess Portnoy wrote: clang is indeed a great tool but since it does a lot more than just static analysis. Yeah, it looked like an interesting thing and so I decided to play with it. Incidentally, I discovered later that clang appears to compile PHP 5.3 pretty much flawlessly just now (at least for my particular set of configure options). The scan-build analyser thing I used ran the code through clang before forwarding it on to gcc for the actual compilation. For those cases where one wants source code analysis, especially security oriented, I'd recommend flawfinder [http://www.dwheeler.com/flawfinder]. I'll have a look. Thanks for the tip. I ran it against the PHP 5.2.11 sources and am now sorting through results, patching suggestions may follow :) Heh. If anyone wants to see the output from scan-build that I got, it's at http://mgdm.net/~michael/php-5.3-clang/ along with the notes.txt that I'm filling in as I go along. Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] potential null dereference in ext/ftp/ftp.c
Hello, I agree that it [potentially] many false positives and the is even addressed in the homepage. While this is common to most static analyzers to some extent and requires going through each find with care while mumbling again with this crap.., I still think it has some value. One person's opinion. May the source be with you, Best regards, Jess Portnoy Rasmus Lerdorf wrote: Jess Portnoy wrote: Hello, clang is indeed a great tool but since it does a lot more than just static analysis. For those cases where one wants source code analysis, especially security oriented, I'd recommend flawfinder [http://www.dwheeler.com/flawfinder]. I find that flawfinder is way too simplistic. It just does a grep for certain strings and spews a canned warning. For example: basic_functions.c:137: [4] (buffer) sprintf: Does not check for buffer overflows. Use snprintf or vsnprintf. basic_functions.c:2778: [4] (buffer) sprintf: Does not check for buffer overflows. Use snprintf or vsnprintf. basic_functions.c:2779: [4] (format) printf: If format strings can be influenced by an attacker, they can be exploited. Use a constant for the format specification. Now, that sounds very scary, until you look at those source code lines: 137: #undef sprintf 2778: PHP_NAMED_FE(sprintf, PHP_FN(user_sprintf), arginfo_sprintf) 2779: PHP_NAMED_FE(printf,PHP_FN(user_printf),arginfo_printf) It is so littered with false positives like this that I don't find it useful. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
