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
[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:
Version-Release number of selected component (if applicable):
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
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.