#17572 [Fbk->Csd]: Calling odbc_tables crashes

ID: 17572 Updated by: kalowsky@php.net Reported By: jma@jma.se -Status: Feedback +Status: Closed Bug Type: ODBC related Operating System: W2K, FP2 PHP Version: 4.2.1 New Comment: Fixed in CVS. This is a two part problem. One was the ODBC module shutdown was not cleaning up the results before the connections were shutdown. The second is, in none of these scripts did anyone properly shutdown their ODBC connections. paulr pointed out online that if you added odbc_close() to the end of the 2 line sample, the problem went away. Anyways the fix is CVS head, try a -latest snapshot (not STABLE) dated sometime after this post. Previous Comments: ------------------------------------------------------------------------ [2002-08-12 22:26:49] kalowsky@php.net Okay I did some research on this, and it seems to be a legit bug on Windows when using the JET engine only. Have any of you updated to the latest JET service pack to see if this happens for you? ------------------------------------------------------------------------ [2002-07-23 11:32:55] kalowsky@php.net should be marked as open, as there is now new feedback. ------------------------------------------------------------------------ [2002-07-20 15:02:15] olivierS.dagenaisP@canadaA.comM I'm getting the same problem, however I am running WinME and I can reproduce the same problem with an even shorter example: (I never free my results - it's done for you, right?) <?php $DB = odbc_connect ( "moo", "", "" ); $Cursor = odbc_tables ( $DB ); ?> Running this script from the command-line or from PWS (as CGI) both get php.exe to crash. If I start extracting rows using odbc_fetch_into, I can go through a good deal of the cursor (getting correct results - but not all of them) until it dies the same way. Reproduced the crash on 4.2.1 (official download), 4.2.2-dev (STABLE, dated July 19th at snaps.php.net), 4.3.0-dev (also dated July 19th at snaps.php.net). If it makes a difference, I'm using an Access System data source on the same machine. This doesn't crash on a RedHat 7.3 machine, running PHP 4.1.2 and accessing a PostgreSQL 7.2.1 database. (not sure about the ODBC driver, though - probably from standard RedHat install) Last minute comment: Also reproduced the crash on a machine running Win98SE and the same 4.3.0-dev snapshot, also with Access System DSN: PHP caused an invalid page fault in module <unknown> at 00de:1f8fdffc. Registers: EAX=00d70094 CS=0167 EIP=1f8fdffc EFLGS=00010202 EBX=00d70314 SS=016f ESP=0063f8b8 EBP=0063f8d8 ECX=00d703c0 DS=016f ESI=00d703c0 FS=6d77 EDX=01173b00 ES=016f EDI=00000001 GS=0000 Bytes at CS:EIP: Stack dump: 1f7d7a57 00000003 0065c59c 82d50000 01173e4c 01174378 00000000 00000000 012af09c 1f7d7866 00d703c0 00000001 00000010 007604e0 01173e4c 10084f11 HTH, - Oli ------------------------------------------------------------------------ [2002-06-24 16:39:46] kalowsky@php.net The crash comes from your use of odbc_free_result. If you notice you call it twice, both times trying to free the $th value. You can't really clear out the result while still trying to read it ;) Adding some simple printf debug statements shows this. Can you please try this change and report back if it works or not? Needless to say, this leads to an interesting problem which says that this shouldn't really happen (there should be some checks on this). So it looks like some sort of modifications will be needed to make checks for this. Hope to see them for 4.3, but don't hold your breath very long... I'm in the process of moving and promise nothing. The simplified version also suffers the same problem (the odbc_free_result while using it). ------------------------------------------------------------------------ [2002-06-14 15:01:14] grangeway@hotmail.com A shorter version of this crash is : $ms = odbc_connect("moo", "", ""); $th = odbc_tables ($ms); while (odbc_fetch_row($th)) { odbc_free_result($th); } ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/17572 -- Edit this bug report at http://bugs.php.net/?id=17572&edit=1