php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #12 odbc_execute() causes application error
Submitted: 1998-01-26 19:31 UTC Modified: 1998-02-04 09:20 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: walton at nordicdms dot com Assigned:
Status: Closed Package: ODBC related
PHP Version: 3.0 Latest CVS OS: WinNT 4.0
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: walton at nordicdms dot com
New email:
PHP Version: OS:

 

 [1998-01-26 19:31 UTC] walton at nordicdms dot com
[Reposted with updates for 3.0b4-dev behavior]

I've been experimenting with odbc_prepare() and odbc_execute()
to try to figure out how to use them, and have succeeded only
in generating application errors when calling odbc_execute().
I don't know for sure that I'm using them right, but they
should at least complain and exit gracefully, not crash in
such an ugly way.

Here's my code:

  $result = odbc_prepare($conn,"{call sp_asp_dmsGetArtist (?)}");
  $parm[0] = 303;
  $result = odbc_execute($result, $parm);

If I comment out odbc_execute(), the code completes nicely,
but leaving it in causes a crash.  According to SQLTrace, 
the query *is* getting sent to the server, which implies 
that the crash occurs after the SQLExecute() at line 626 
of unified_odbc.c (3.0b3-dev).

If I change (?) -> (?, ?) in the first line and insert
  $parm[1] = 0;
after the second line, I get the same results.

However, if I change (?) -> (?, ?) and leave $parm[1] unset,
PHP still crashes, but the query is never sent to the server.
In this case, PHP should catch the mismatch in parameters 
at line 599 and return immediately, which explains why
SQLExecute() isn't called.  Unfortunately, that doesn't 
explain why PHP still crashes.

**** Update for 3.0b4-dev ****

Using
  $result = odbc_prepare($conn,"{call sp_asp_dmsGetArtist (?, ?)}");
while leaving out
  $parm[1] = 0;
no longer causes a crash.  It now properly returns with:
  Warning:  Not enough parameters (1 should be 2) given

In the cases that still cause a crash, the last output from
PHP is:
  <br>
  <b>Warning:</b>
which implies that PHP is dieing inside of php3_error()?!

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [1998-02-04 09:20 UTC] kara
No more crashing with b4,
but odbc_cursor() doesn't return a name in this environment.
I'm unable to reproduce this behaviour. (Different OS/Drivermanager/Driver)
 [2017-10-05 20:24 UTC] willfitch@php.net
Automatic comment on behalf of willfitch
Revision: http://git.php.net/?p=pecl/numbers/bitset.git;a=commit;h=4f4534ac09862d802b4e985bad18c87a276fb4f8
Log: Fix #12
 [2024-01-23 07:27 UTC] git@php.net
Automatic comment on behalf of remicollet
Revision: https://github.com/php/pecl-system-dio/commit/e04039866a71d3087fcddb0ce686ef22edbd3d1d
Log: Fix #12 memory leak in dio_read
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 14:01:28 2024 UTC