[PATCH] Three patches for odbc module

php.internals

Dave Lawson

22 years ago
Hello, I discovered these problems during a project I'm working on. There are three separate patches involving different areas of the odbc module: php_odbc.c.patch1.txt ===================== Wherever an odbc_result is allocated, "emalloc" is used. This may cause random behavior in certain php_odbc methods if some odbc_result members are not initialized. I had a specific problem with the fetch_abs member of odbc_result. This member would contain garbage at random when calling odbc_gettypeinfo(). Since fetch_abs was non-zero, all of the odbc_fetch_xxx() functions would try to use SQLExtendedFetch(). The driver I'm using doesn't support this method so the method would appear to fail. The solution was to replace all odbc_result "emalloc" allocations with "ecalloc". php_odbc.c.patch2.txt ===================== There are resource leaks when using any of the following php_odbc functions: odbc_tables() odbc_columns() odbc_columnprivileges() odbc_foreignkeys() odbc_gettypeinfo() odbc_primarykeys() odbc_procedures() odbc_procedurecolumns() odbc_specialcolumns() odbc_statistics() odbc_tableprivileges() Each of these functions allocates a new odbc_result resource. When odbc_free_result() is called to free a resource from one of these functions, it tries to use the "id" member of the odbc_result struct to delete the resource from the global resource list. Since none of these functions initialize the "id" member, the delete silently fails and the resource stays allocated. After further investigation, there doesn't seem to be a real purpose to the "id" member. The only functions that initialize it are odbc_prepare() and odbc_exec(). Rather than using this member as the resource index to delete in odbc_free_result(), why not just use the value of the zval passed in to odbc_free_result()? This patch removes references to the "id" member in all affected functions. php_odbc.c.patch3.txt ===================== Reference counting for odbc_connection resources has issues. There are two problems: First, odbc_prepare() and odbc_exec() both add references to the connection (presumably for the the conn_ptr member of odbc_result). The code that should delete these references appears to be commented out in the _free_odbc_result() function (the odbc_result destructor). No other php_odbc functions add these references and they appear to be unnecessary. When an obdc_connection is freed via _close_odbc_conn() (the odbc_connection destructor), the function scans the resource list and deletes any existing odbc_result references associated with that connection. The second problem has to do with the fact the odbc_connections are cached. Please see the attached patch3-example.php file for an explanation of the problem and solution.