Bug 772595

Summary: php-odbc double free with mysql-connector-odbc64
Product: Red Hat Enterprise Linux 5 Reporter: Karel Volný <kvolny>
Component: phpAssignee: Joe Orton <jorton>
Status: CLOSED NOTABUG QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.8CC: ddumas, jorton, tgl
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 772596 (view as bug list) Environment:
Last Closed: 2012-01-19 10:03:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 772596    

Description Karel Volný 2012-01-09 11:29:41 UTC 
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
Comment 1 Joe Orton 2012-01-09 16:56:04 UTC 
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?
Comment 2 Tom Lane 2012-01-09 17:14:29 UTC 
(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 ...
Comment 3 Tom Lane 2012-01-09 17:24:33 UTC 
(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.