php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #17572 Calling odbc_tables crashes
Submitted: 2002-06-03 06:26 UTC Modified: 2002-08-13 19:49 UTC
Votes:2
Avg. Score:4.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:1 (50.0%)
From: jma at jma dot se Assigned:
Status: Closed Package: ODBC related
PHP Version: 4.2.1 OS: W2K, FP2
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: jma at jma dot se
New email:
PHP Version: OS:

 

 [2002-06-03 06:26 UTC] jma at jma dot se 
This script crashes after showing the first table.
This is consistant on several ODBC sources (tried Access, Foxpro and DB2).

This script worked with 4.0 versions.

<?php
$host = "";  // Enter your ODBC connection here
$uid = "";
$pwd = "";

       $ms = odbc_connect($host, $uid, $pwd);
       $th = odbc_tables ($ms);
       while (odbc_fetch_row($th))
           {
           if (odbc_result($th, "TABLE_TYPE") == "TABLE")
              {
              $table = odbc_result($th, "TABLE_NAME");
              printf("<H2>%s</H2>\n", $table);
              $fh = odbc_columns($ms);
              echo "<BLOCKQUOTE>\n";
              echo "<TABLE BORDER=0 CELLPADDING=10>\n";
              while (odbc_fetch_row($fh))
                    {
                    if (odbc_result($fh, "TABLE_NAME") == $table)
                       {
                       printf("<TR>");
                       printf("<TD>%s</TD>", odbc_result($fh, "TYPE_NAME"));
                       printf("<TD><B>%s</B></TD>", odbc_result($fh, "COLUMN_NAME"));

                       switch (odbc_result($fh, "DATA_TYPE"))
                              {
                              default:
                              }
                       printf("</TR>\n");
                       }
                    }

              echo "</TABLE>\n";
              echo "</BLOCKQUOTE>\n";
              odbc_free_result($th);
              }
           }

       odbc_free_result($th);
       odbc_close ($ms);
?>

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-06-03 06:29 UTC] derick@php.net 
Can you please try a non-stable snapshot from snaps.php.net/win32 and report back if it works?
Please do not forget to update your php4ts.dll.

Derick
 [2002-06-05 05:25 UTC] jma at jma dot se 
Tried the php4-win32-200206031400.zip build but the excat same thing happened :-(

/JMA
 [2002-06-12 17:58 UTC] mwilmes at avc dot edu 
I've tried this on two platforms W98 using Xitami, and W2K using iPlanet, but my bug is slightly different: My ODBC drivers don't load, error IM003.  But those ODBC drivers worked with Access and an Oracle frontend.  The W2K was a fresh install this morning with the ODBC drivers and PHP. This problem was resolved on BOTH platforms by retrograding to 4.2.0.
 [2002-06-14 15:01 UTC] grangeway at hotmail dot 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);
              }
 [2002-06-24 16:39 UTC] 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-07-20 15:02 UTC] olivierS dot dagenaisP at canadaA dot 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-07-23 11:32 UTC] kalowsky@php.net 
should be marked as open, as there is now new feedback.
 [2002-08-12 22:26 UTC] 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-08-13 19:49 UTC] kalowsky@php.net 
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.
 [2002-08-25 12:48 UTC] olivierS dot dagenaisP at canadaA dot comM 
According to http://www.php.net/manual/en/function.odbc-pconnect.php
"""
This function is much like odbc_connect(), except that the connection is not really closed when the script has finished.
"""

...which implies connections opened with odbc_connect are closed when the script is finished.

Also, http://www.php.net/manual/en/function.odbc-free-result.php says

"""
odbc_free_result() only needs to be called if you are worried about using too much memory while your script is running. All result memory will automatically be freed when the script is finished. But, if you are sure you are not going to need the result data anymore in a script, you may call odbc_free_result(), and the memory associated with result_id will be freed. 
"""

These are in contradiction with your statement "in none of these scripts did anyone properly shutdown their ODBC connections".  Is this a bug in PHP or the documentation?


In any case, I updated to MS Jet 4.0 SP6 on my WinME machine, added a odbc_close at the end of both the smallest repro case and one of my programs and I no longer see PHP crashing in either case.  I will try the CVS version soon to see if the documentation was right.. :)

Thanks for looking into this!
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Dec 13 04:00:01 2025 UTC