php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #51300 SELECT * CRASH With LibMySQL > 5.0.51
Submitted: 2010-03-15 04:06 UTC Modified: 2010-03-15 20:40 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: tanguy dot pruvot at gmail dot com Assigned:
Status: Not a bug Package: PDO related
PHP Version: 5.2.13 OS: Windows 7
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2010-03-15 04:06 UTC] tanguy dot pruvot at gmail dot com 
Description:
------------
Since LibMySQL.dll 5.0.52 (and tested to 5.1.44)

I ve the found why pdo_mysql is crashing...

Here :
http://github.com/php/php-
src/blob/4f3e41e55dae1978487461d73805eaac8202aff8/ext/pdo_mysql/mysql_statement.
c#L429

The struct pdo_column_data must be 0x54 (84.) bytes sized... Actually it is 0x50 
(80.) bytes



You can fix binary dll by replacing (with hex editor : 83 C3 50 by 83 C3 54)



Test script:
---------------
<?php

$dbh = new PDO('mysql:host=127.0.0.1;port=3306;dbname=ubagestion_dev','root','');
echo "ok";
$dbh->exec('SET CHARACTER SET latin1');
echo "ok";
$stmt = $dbh->query("select ID_Utilisateur from utilisateurs");
echo "ok";
$stmt = $dbh->prepare("select * from utilisateurs");
echo "ok";

$results = $stmt->execute(); // CRASH HERE or on $dbh->query("SELECT * FROM ...")
echo "NOT CRASHED";

foreach ($results as $id){
echo $results['ID_Utilisateur'];
}


Actual result:
--------------
no trace, system crash (and apache too if apache2handler used)

Crash on second column name

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-03-15 04:08 UTC] tanguy dot pruvot at gmail dot com 
MySQL and MySQLi extensions are working, that only affects pdo_mysql extension...
 [2010-03-15 10:03 UTC] pajoye@php.net
-Status: Open +Status: Bogus
 [2010-03-15 10:03 UTC] pajoye@php.net 
We don't support external libmysql. They break the ABI, please be sur that the PHP directory (where the libmysql.dll and other php's released DLLs are present) is first in your PATH, for php.exe.
 [2010-03-15 10:09 UTC] tanguy dot pruvot at gmail dot com 
I'm sure, there is nothing in my PATH... i have posted the solution (working with 
all new versions....)
 [2010-03-15 10:13 UTC] tanguy dot pruvot at gmail dot com 
please make a check of column data length in pdo mysql startup... An error is 
better than a crash without log...
 [2010-03-15 10:14 UTC] tanguy dot pruvot at gmail dot com 
The Binary Fix is for php_pdo_mysql.dll ... not libmysql
 [2010-03-15 10:16 UTC] pajoye@php.net 
See the definition of ABI and explain it to the mysql developers: 

http://en.wikipedia.org/wiki/Application_binary_interface

That's not something we can or could test or change at runtime.
 [2010-03-15 10:23 UTC] pajoye@php.net 
Sorry but there is a misunderstanding.

We provide libmysql 5.0.x (don't remember which version exactly right now). PHP was compiled against this version, size of the struct and other elemenets were defined at compilation and linking time.

Further updates of the 5.0.x libraries should not change these sizs or it will break the binary compatibility and makes the applications behave badly (crashes being one of these effects).

Thanks for your understanding but there is no bug in php.
 [2010-03-15 10:33 UTC] tanguy dot pruvot at gmail dot com 
Sure i understand... but why 5.0.51 ? 5.0 community server has been replaced by 
5.1 since .... a lot of time

I hope my solution will be usefull to others like me who want same environnement 
for symfony in linux and windows... with a 5.0.52 to 90 or 5.1 MySQL Server

Detected and fixed the problem with OllyDbg... mysqli is not affected

Does all other PDO db use this same 0x50 byte-sized column structure ?
 [2010-03-15 10:36 UTC] pajoye@php.net 
You don't need libmysql 5.1 to communicate with a 5.1 server, libmysql 5.0 works just fine.

I would also suggest to move to 5.3 if you like a more recent mysql drivers (it uses a new driver not depending on libmysql). Symfony works fine with 5.3.
 [2010-03-15 10:55 UTC] tanguy dot pruvot at gmail dot com 
Yes... i will upgrade to 5.3... when all modules will be well tested on :)

I think Debian MySQL Package is locked to 5.0.51a for that too...

In fact i'm maintaining a wamp package, and PhpMyAdmin has a big Warning when 
Client API is not at the same version as the server...
 [2010-03-15 11:01 UTC] pajoye@php.net 
Which wamp package do you maintain? I'm about to contact the ones I know to give the VC9 version a boost, as well as improving our MSI to be sure that every wamp packagers can use it directly. Doing so will allow us to support them here (bugs.php.net) as well and brings us to the next step: one (signed) binary for all :)
 [2010-03-15 11:29 UTC] tanguy dot pruvot at gmail dot com 
EWS (Easy Web Server) which is French + English and contains another CGI 
(FastCGI) WDScript http://e.w.s.free.fr and http://tanguy.ath.cx/?q=/EWS250

This wamp package has the advantage to be executed as Service or Not :) that 
fixes mayne problem and helps component debugging

But all apache/php components are compiled with VC6 (i also compiled libmysql 
with it this night... to try to fix the bug)

And System PATH is not affected by EWS (which is not installed, just moveable)

I'm working on the next version of the pack... almost ready but with 2.5.13, not 
5.3.2
 [2010-03-15 11:33 UTC] pajoye@php.net 
Let me know once you will work on 5.3.x, that's the way to go on windows :)
 [2010-03-15 11:41 UTC] tanguy dot pruvot at gmail dot com 
Yes, i've read about that... PHP6...oops 5.3 ;) is optimized for Windows (and 
maybe the big machine WebPI) :p

But eaccelerator and xdebug had some problems with 5.3... so i wait and see...

Also, most of wamp package have migrated to 5.3... which has caused many 
problems...

My package is made for web dev purpose, at work... and its fine to have a wamp 
package compatible with "old" (1 year) php applications to upgrade them without 
the server on a production environment...
 [2010-03-15 11:44 UTC] pajoye@php.net 
xDebug works fine with 5.3, no idea about eaccalerator but APC works fine as well.

I don't see which problem 5.3 can cause to be honest. All apps I use work just fine with it.
 [2010-03-15 12:01 UTC] tanguy dot pruvot at gmail dot com 
i fixed sqlitemanager (1.2.0) sources .... and all the ereg(i/replace) 
functions.... and some other things herited from PHP 4 ;), dont remember...

I think 0.9.6 of eaccelerator is now ok (the rc version was not), the 0.9.6 works 
fine with 5.2.12 and 13 but need to be recompiled on every php minor version... 
this version is also smaller than before... some units were removed...
 [2010-03-15 12:06 UTC] pajoye@php.net 
Last but not least: Why do you compile it yourself? That should not be necessary.
 [2010-03-15 12:21 UTC] tanguy dot pruvot at gmail dot com 
like i said eaccelerator need to be recompiled on every php release... i htate 
to wait for a module to upgrade php...

xdebug doesnt have this problem... like my php4delphi module which is "working" 
since 5.2.0 ... and i've problem to upgrade it to the 7.2 (Delphi 2010) version 
which is less delphi-vcl dependant...

I want to make a php interface to my FastCGI WDScript .. To permit interface to 
the WLangage Native DB Drivers in a php script without json, to output PHP code 
or directly create php variables :)

I think i will make it with visual studio this time... i've now the knowledge 
and the tool suites to do that...
 [2010-03-15 12:30 UTC] pajoye@php.net 
Why do you compile PHP yourself is what I meant, it should be necessary and would make your users life easier if you do not.
 [2010-03-15 12:35 UTC] tanguy dot pruvot at gmail dot com 
Oh... I dont publish the self-compiled PHP version, i only use the source tree to 
compile the shared modules i need...
 [2010-03-15 20:40 UTC] tanguy dot pruvot at gmail dot com 
The new field of structure is :

  void *extension;

at the end of the record... That should not change anymore...

typedef struct st_mysql_field {
  char *name;                 /* Name of column */
  char *org_name;             /* Original column name, if an alias */
  char *table;                /* Table of column if column was a field */
  char *org_table;            /* Org table name, if table was an alias */
  char *db;                   /* Database for table */
  char *catalog;	      /* Catalog for table */
  char *def;                  /* Default value (set by mysql_list_fields) */
  unsigned long length;       /* Width of column (create length) */
  unsigned long max_length;   /* Max width for selected set */
  unsigned int name_length;
  unsigned int org_name_length;
  unsigned int table_length;
  unsigned int org_table_length;
  unsigned int db_length;
  unsigned int catalog_length;
  unsigned int def_length;
  unsigned int flags;         /* Div flags */
  unsigned int decimals;      /* Number of decimals in field */
  unsigned int charsetnr;     /* Character set */
  enum enum_field_types type; /* Type of field. See mysql_com.h for types */
  void *extension;
} MYSQL_FIELD;
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 26 21:01:29 2024 UTC