Fix handling of BIT fields in mysqli, when libmysql is used
We need to use macros from mysqlnd to be able to read the
bit fields, as they are specially encoded. mysqlnd is always
there, 5.3+, so its macros can be used, even if mysqlnd is
not compiled as library of choice.
Moving test code around to get test failures down without testing less. Users of the MySQL Client Lib should always call stmt_bind_result after execute - not before.
Fixing test by calling it a known limit. We keept the test failing as a reminder to think about how to handle BIT(32) and up but none of us has an idea. Thinks work fine up to BIT(31) - the limitation should be documented.
Afix not included by the fix committed by Ulf.
pemalloc and then efree - too bad!
Sorry for committing in two passes, my big tree is already patched
with compressed.
Fix (by Andrey) and test for bug #49442 . Don't use efree() for memory allocated with malloc()... If a connection gets created by mysqli_init(), mysqlnd makes it 'persistent'. 'Persistent' means that mysqlnd uses malloc(). mysqlnd does use malloc() instead of ealloc() because it is unknown if the connection will become a true persistent connection in the sense of ext/mysqli. It is unknown if the user wants a persistent connection or not until the user calls mysqli_real_connect(). To avoid tricky conversions mysqlnd uses malloc(), which sets a private persistent flag in the mysqlnd structures. A precondition for the crash to happen was that the private persistent flag is set. The flag is also set when creating a real persistent connection (in the sense of ext/mysqli) and so the bug can happen with mysql_init()/mysqli_real_connect() and mysql_connect('p:<host>', ...). Therefore we test both cases. Note the (tricky?) difference between the implementation detail'mysqlnd private persistent flag = use malloc()' and persistent connections from a user perspective. Although mysqlnd will always set its private persistent flag and use malloc() for connections created with mysqli_init() it is still up to the user to decide in mysqli_real_connect() if the connection shall become a (true) persistent connection or not.
Fix and tests for bug #49511 . mysqlnd and the MySQL Client Library (libmysql) use different networking APIs. mysqlnd does use PHP streams whereas libmysql uses its own wrapper of the operating level network calls. PHP sets by default a read timeout of 60s for streams - php.ini, default_socket_timeout. This default applies to all streams that set no other timeout value. mysqlnd has not set any other value and therefore it connections of long running queries can have been cut off after default_socket_timeout seconds resulting in a 2006 - MySQL Server has gone away error message. The MySQL Client Library sets a default timeout of 365 * 24 * 3600 seconds (1year) and waits for other timeouts to happen, e.g. TCP/IP timeouts. mysqlnd now uses the same very long timeout. The value is configurable through a new php.ini setting: mysqlnd.net_read_timeout. mysqlnd.net_read_timeout gets used by any extension (ext/mysql, ext/mysqli, PDO_MySQL) that uses mysqlnd. mysqlnd tells PHP Streams to use mysqlnd.net_read_timeout. Please note that there may be subtle differences between MYSQL_OPT_READ_TIMEOUT from the MySQL Client Library and PHP Streams. E.g. MYSQL_OPT_READ_TIMEOUT is documented to work only for TCP/IP connections and, prior to MySQL 5.1.2, only for Windows. PHP streams may not have this limitation. Please check the streams documentation, if in doubt.
Fix for bug #49357 (MySQLi extension fails to recognize POINT (spatial) colums).
Do yourself a favour and use mysqlnd. mysqlnd has no isuses here.
If you insist on using the MySQL Client Library (libmysql) I strongly recommend to use mysqli_stmt_store_result() when fetching geometry data using prepared statements. When streaming data, which is the default for prepared statements, ext/mysqli will have to make a guess on the size of the result buffer it needs. The guess is based on a length reported by the MySQL CLient Library (libmysql). The MySQL Client Library reports 4GB (!) for a POINT - a conservative and safe guess. Consequently, ext/mysqli will try to allocate 4GB of RAM. The true (maximum) size of the column is not available before buffering the result on the client using mysqli_stmt_store_result(). If you call mysqli_stmt_store_result(), the result buffers will not get bigger than needed. However, store_result()/buffering is usually not what you want when you ask for prepared statements.
Stepping back to PHP 5.2.x and earlier logic of allocating even huge pieces of memory for large BLOB types to avoid data truncation. This fixes the test failure of 005.phpt when using MySQL Client
Library (libmysql). The test does pass with mysqlnd because mysqlnd does not have any issues here.
Fixing a crash which must have existed since PHP 5.0. At least the crash can be reproduced with PHP 5.0.6. The crash happens only when using the MySQL Client Library (libmysql) - it does not happen
when using mysqlnd.
projects / php / log