Hide Forgot
Description of problem: Trying to connect to mysql database via odbc interface in php leads to an error on 64bit systems (seems reliably reproducible on x86_64 and ia64, ppc doesn't exhibit this): *** glibc detected *** php: double free or corruption (!prev): 0x60000000001dc8a0 *** Version-Release number of selected component (if applicable): php-odbc-5.1.6-27.el5_5.3.ia64 How reproducible: always? on x86_64, ia64 Steps to Reproduce: 1. run the test /CoreOS/mysql-connector-odbc64/Sanity/php-mysql-odbc Actual results: RUNNING /mnt/testarea/tests/mysql-connector-odbc64/Sanity/php-mysql-odbcphp(28678): unaligned access to 0x60000000001dc8e4, ip=0x200000000534fe70 php(28678): unaligned access to 0x60000000001dc914, ip=0x200000000534fe70 php(28678): unaligned access to 0x60000000001dc944, ip=0x200000000534fe70 php(28678): unaligned access to 0x60000000001dc974, ip=0x200000000534fe70 php(28678): unaligned access to 0x60000000001dc9a4, ip=0x200000000534fe70 *** glibc detected *** php: double free or corruption (!prev): 0x60000000001dc8a0 *** ======= Backtrace: ========= /lib/libc.so.6.1[0x20000000010b4280] /lib/libc.so.6.1(cfree-0x5413d0)[0x20000000010bcd60] php(_efree+0x1ffffffffed385f0)[0x4000000000336730] /usr/lib/php/modules/odbc.so[0x2000000004e56370] php(list_entry_destructor+0x1ffffffffed96b00)[0x4000000000391000] php(zend_hash_del_key_or_index+0x1ffffffffed915e0)[0x400000000038f730] php(_zend_list_delete+0x1ffffffffed934a0)[0x4000000000391600] /usr/lib/php/modules/odbc.so(zif_odbc_close+0x385b6d0)[0x2000000004e56990] php[0x40000000003e5790] php(execute+0x1ffffffffedc1100)[0x40000000003bb610] php(zend_execute_scripts+0x1ffffffffed74360)[0x40000000003724d0] php(php_execute_script+0x1ffffffffece2620)[0x40000000002e07a0] php(main+0x1ffffffffeecd500)[0x40000000004c7860] /lib/libc.so.6.1(__libc_start_main-0x5fe920)[0x2000000000fff870] php(_start+0x1ffffffffea49ea0)[0x4000000000048040] ======= Memory map: ======== 00000000-00004000 r--p 00000000 00:00 0 ... Expected results: (test passes without problems) Additional info: see beaker jobs https://beaker.engineering.redhat.com/recipes/373928#task4177262 https://beaker.engineering.redhat.com/recipes/373931#task4177277
Is this like bug 772293, where there ODBC configuration has been specifically configured to use the "wrong" drivers? Does unixODBC have a way to verify the loaded driver is using the correct ABI?
(In reply to comment #1) > Is this like bug 772293, where there ODBC configuration has been specifically > configured to use the "wrong" drivers? Sure looks like the same thing. > Does unixODBC have a way to verify the loaded driver is using the correct ABI? Not that I'm aware of :-(. If there were an ABI verification tool for ODBC, likely we'd not have this whole mess to begin with, because it would've noticed that 2.2.12 was misimplementing Microsoft's ABI spec ...
(In reply to comment #2) > > Does unixODBC have a way to verify the loaded driver is using the correct ABI? > > Not that I'm aware of :-(. Thinking about that some more ... the driver shlib should have a dependency on libodbc.so.1 or libodbc.so.2 depending on which ABI it was built against. This doesn't result in any runtime failure, because AFAIK the dynamic linker will happily pull in another copy of libodbc if what the application is using is the other one. But it seems like in principle we could add a check to unixODBC to see if the driver is linked against the proper version of libodbc. I have no idea exactly how to do that though, and am not sure if it'd be worth the trouble.