ID: 48745 Updated by: and...@php.net Reported By: theta...@php.net -Status: Verified +Status: Closed Bug Type: MySQL related Operating System: * PHP Version: 5.3.0 Assigned To: mysql New Comment:
This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Uwe, the fix will appear in 5.3.1 Previous Comments: ------------------------------------------------------------------------ [2009-08-28 09:30:17] s...@php.net Automatic comment from SVN on behalf of andrey Revision: http://svn.php.net/viewvc/?view=revision&revision=287834 Log: Fix for bug#48745 mysqlnd: mysql_num_fields returns wrong column count for mysql_list_fields ------------------------------------------------------------------------ [2009-07-02 07:19:33] theta...@php.net Thanks! I understand the problem and that it is deprecated. The important thing is: it should *not* SIGSEGV. So the best idea would be to simply disable the whole function, if it is not working with mysqlnd and you are not willing to support it (something like: "deprecated functions work with libmysqlclient but not with mysqlnd". They should simply return false or throw an error or should removed at all). Because of the sigsegv it was hard to find out, where the error really occurred in this thousands of lines of foreign PHP code. But if Andrew is able to fix it, let's wait for it. > compile ext/mysql against libmysql (like ever since) and try > again in four weeks My problem was, that this does not work easily with PHP 32bit on Solaris x64 using /opt/csw libs (mysql_config only returns 64bit libs, includes strange not GCC compatible CFLAGS and so on). But this is another problem. It was also broken in 5.2 (but you were able to fix it), but with 5.3 it now produces hard compilation errors (and can only be fixed by replacing mysql_config with a "dummy" that returns correct CFLAGS and LIB paths). But Linux users can always compile against libmysql this. For Solaris users mysqlnd is the best for problem-less installation! The easiest workaround was to use mysqli in our case :) For me this bug is obsolete, I only want to keep it open because of the SIGSEGV. Uwe ------------------------------------------------------------------------ [2009-07-02 07:01:42] u...@php.net Thanks. As said, its fixable, I know the cause, I may know a hack to fix it but the call is deprecated. There are zillions of MySQL 4.0 users but we don't support MySQL 4.0 any more. There may be many list_fields users, but list_fields is deprecated. At some point you simply have to stop giving old, deprecated calls the highest priority. Apart from that, I don't want to hack with the packet decoders in the absence of Andrey if the workaround is as easy as: compile ext/mysql against libmysql (like ever since) and try again in four weeks. Ulf ------------------------------------------------------------------------ [2009-07-01 17:14:33] theta...@php.net As I noted before: This is not my code and there may be a lot of users installing software using the old mysql extension and also this function. For me the workaround was to enable the mysqli configuration option in Contenido. The only problem is, that it is not enabled per default in this CMS (although it says: PHP 5 only). Contenido uses a PHP-written database abstraction (from where I copied the functions in this bug report) and it was easy to exchange by the other one. It was also fixable by doing a dummy query "select * from table limit 1" and looking into the field descriptions for the result set (this is how the abstraction layer fr mysqli does it in Contenido). So many thanks for looking at it, I will post a note in the Contenido mailing list about this problem and the workaround. ------------------------------------------------------------------------ [2009-07-01 16:54:38] u...@php.net The trouble goes back to an over optimized COM_LIST_FIELDS communication package and a guess that mysqlnd makes. mysqlnd makes a guess on the number of fields that the deprecated API call mysql_list_fields() may return. The guess is never adjusted to the actual number of fields returned by the Server. As a result mysql_num_fields(), when invoked with a result set handle returned by mysql_list_fields(), may return a faulty number of fields. If a users tries to loop over all fields using the number of fields returned by mysql_num_fields() as a stop condition, he may try to access fields that don't exist. The out-of-bound access is not detected because the internal security check also gets the wrong number of fields reported. Workaround: - don't use deprecated functions, don't use mysql_list_fields().. (there is a reason why we want to deprecate COM_LIST_FIELDS!) - use libmysql until its fixed I don't want to play with the packet decoders and the protocol decoding in the absence of Andrey. I know roughly how to fix, but packet decoding is for Andrey. Andrey is on vacation until August. As its easy to work around, I think it can wait. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/48745 -- Edit this bug report at http://bugs.php.net/?id=48745&edit=1
