Description of problem: PHP use of MySQL database via unixODBC and mysql-connector-odbc produces memory corruption and segmentation faults on roughly half of all database accesses. Representative error messages from the Apache error log: [Mon Mar 13 14:54:03 2006] [notice] child pid 28893 exit signal Segmentation fault (11) [Mon Mar 13 15:27:39 2006] [error] [client 172.16.81.27] PHP Warning: odbc_connect() [<a href='function.odbc-connect'>function.odbc-connect</a>]: SQL error: [unixODBC][MySQL][ODBC 3.51 Driver]Can't initialize character set latin1 (path: /usr/share/mysql/charsets/), SQL state S1T00 in SQLConnect in /var/www/html/bluemoose/qq.php on line 2 Character set 'latin1' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file This bug is (or is related to) the following MySQL bugs: http://bugs.mysql.com/bug.php?id=15248 http://bugs.mysql.com/bug.php?id=15547 Version-Release number of selected component (if applicable): mysql-connector-odbc-3.51.12-1.e14s1.1 unixODBC-2.2.11-6.e14s1.1 How reproducible: Very - usually after 2 or 3 repeated accesses of the attached PHP code Steps to Reproduce: - see attachment
Created attachment 126070 [details] PHP test case illustrating bug
May be related to bug #171064
I didn't have any luck reproducing the problem when running php directly on the test case (ie, "php bug.php"). Any suggestions?
BTW, I notice that bug #171064 relates to the much older MyODBC driver (libmyodbc.so rather than libmyodbc3.so). Might be worth double checking which driver version your ODBC configuration actually selects.
OK, I'm pretty well convinced that you are in fact seeing the same problem as is mentioned in the second mysql bug above (15547) --- the core dump is in the same place. And I can reproduce that one on my own machine. It looks to me like some kind of double-free error but I'm not having much luck narrowing it down more than that (it'd seem the MySQL guys have not found it either...) Currently rebuilding all this stuff on my old slow i386 machine so I can try valgrind.
Argh ... I suddenly see the problem. libmyodbc3.so is linking to libmysqlclient.so which is *not thread safe*. Why isn't it linking to libmysqlclient_r.so?
Double argh. I've been testing an incorrect configuration: multithread programs had better use libmyodbc3_r.so, not libmyodbc3.so. With the thread-safe library I'm not seeing the bogus free()s anymore. It still crashes though :-(
It seems that the correct fix to this is that myodbc_end() shouldn't be called during connection shutdown. That function only makes sense to call during total library shutdown (eg, DLL unload on Windows). Committed in 3.51.12-2.el4s1.1 and reported to upstream library author too.
Greg Nichols verified this bug.. Changing the status to verified.
This bug is long since dealt with, not sure why it was not closed.