|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22403 PHP crashes when executing a sql procedure without parameters
Submitted: 2003-02-24 15:38 UTC Modified: 2004-03-01 10:50 UTC
Avg. Score:4.5 ± 0.9
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: cesararnold at yahoo dot com dot br Assigned: thekid (profile)
Status: Not a bug Package: Sybase-ct (ctlib) related
PHP Version: 4CVS, 5CVS OS: *
Private report: No CVE-ID: None
 [2003-02-24 15:38 UTC] cesararnold at yahoo dot com dot br

we are using PHP 4.3.2 (latest STABLE version) and found a possible bug when trying to execute a sql command (a procedure). the procedure needs 1 (one) argument and does not accept null values when is called. 
On our case, the variable $varID was infortunatelly = NULL. after ran the code we got two strange behaviors:

1) using pear object
$cmd_sql = "exec procedure_name " . $varID;

if (DB::isError($query_proc = $db_conn->query($cmd_sql))) 
	// get the native backend error    
	// and the last query    
the system crashes and stops the web server! restarting the web server, evething restarts to work. 

2) using native functions
like @sybase_query( $cmd_sql, $db_conn );

the system crashes but does NOT stop the web server.

for both cases php gives the message:
"PHP has encountered an Access Violation at 01E436B9"

I know that this can be fixed just sending a non-null value to the procedure, but PHP could not crash, on my single oppinion.

Is there some fix to this case?
Thanks a lot.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-02-25 15:34 UTC]
What crashes in particular PHP or Sybase? Given the nature of your error I could see how the query would fail, which could trigger a crash in sybase if this particular condition is not handled. However, if that is the case there is nothing PHP could do to prevent such a thing from happening.
 [2003-02-26 07:22 UTC] cesararnold at yahoo dot com dot br
Hi, thanks for your reply.

sybase did not stop. If I ran the query with null parameter (as mentioned) directly into the database, nothing wrong happens. Also, using differente interfaces to run that query using null, everything goes well. the db returns a error message saying that that the query does not accept null values and returns, something like:

Server Message:  Number  201, Severity  16
Procedure 'procedure_name', Line 0:
Procedure procedure_name expects parameter @ID, which was not supplied. 
(return status = -6)

So, the problem, on my oppinion, is not on the db. 
Could it be on php or on the native dll, on this case : php_sybase_ct.dll, when receiving the error message from the database ?

I hope this can help.
Thanks again.
 [2003-03-25 17:56 UTC]
Could not reproduce here:
  $db= sybase_connect('sybase', 'username', '******');
  $q= sybase_query('exec csc_getAddressByCId '.$argv[1]);
  var_dump($q, sybase_fetch_assoc($q));

### Testing with empty parameter:

thekid@thekid:~ > php sybase_segfault.php ''
PHP Warning:  sybase_query() []: Sybase:  Server message:  Procedure csc_getAddressByCId expects parameter @cid, which was not supplied.
 (severity 16, procedure csc_getAddressByCId) in /usr/home/thekid/sybase_segfault.php on line 3

Warning: sybase_query() []: Sybase:  Server message:  Procedure csc_getAddressByCId expects parameter @cid, which was not supplied.
 (severity 16, procedure csc_getAddressByCId) in /usr/home/thekid/sybase_segfault.php on line 3
PHP Warning:  sybase_fetch_assoc(): supplied argument is not a valid Sybase result resource in /usr/home/thekid/sybase_segfault.php on line 4

Warning: sybase_fetch_assoc(): supplied argument is not a valid Sybase result resource in /usr/home/thekid/sybase_segfault.php on line 4

### Testing with parameter, but sp returning failure: 

thekid@thekid:~ > php sybase_segfault.php 182
resource(5) of type (sybase-ct result)

### Testing with parameter and sp returning data:

thekid@thekid:~ > php sybase_segfault.php 1861822
resource(5) of type (sybase-ct result)
array(1) {
  string(16) ""

Does this only happen within Apache or does this occur on cli scripts, too?

 [2003-03-28 14:54 UTC] cesararnold at yahoo dot com dot br
first of all, thanks for your tests...

I'm sorry but I forgot to say that it's happening on IIS 5.0, not on Apache.

Thanks again.
 [2003-04-12 10:27 UTC]
Can you show me the output of this script:

/* Test script for
 * SQL needed
 * ==========
 * use tempdb
 * go
 * create proc test (@param int)
 * as
 * begin
 *   select @param
 *   select @param + 1
 *   return @param
 * end
 * go

  header('Content-type: text/plain');
  function sybase_message($msgnumber, $severity, $state, $line, $text) {
      "*** Caught Sybase Server Message #%d [Severity %d, state %d] at line %d\n    '%s'\n",
  function sybase_exec() {
    echo str_repeat('-', 72)."\n";
    $args= func_get_args();
    $query= array_shift($args);
    foreach ($args as $arg) {
      $query.= ' '.((NULL === $arg) ? 'NULL' : $arg);
    printf(">>> Query: %s\n", $query);
    $h= sybase_query($query);
    printf("<<< Return: %s\n", var_export(is_resource($h), 1));
    if (!$h) return;
    while ($data= sybase_fetch_assoc($h)) {
  sybase_connect('...', '...', '...');		// FILL IN PLEASE:)
    "PHP Version: %s\n".
    "OS         : %s\n".
    "SAPI       : %s\n". 
    "Sybase     : %s\n",
    array_shift(sybase_fetch_row(sybase_query('select @@version')))

  sybase_exec('exec tempdb..test');
  sybase_exec('exec tempdb..test', NULL);
  sybase_exec('exec tempdb..test', 1);
  sybase_exec('exec tempdb..test', 'foo');
  printf("\n===> Done\n");

 [2003-04-14 20:55 UTC] cesararnold at yahoo dot com dot br
Bingo !
The output is below:

PHP Version: 4.3.2-dev
OS         : Windows NT SAO-IRINEU 5.0 build 2195
SAPI       : isapi
Sybase     : Adaptive Server Enterprise/11.9.2/1075/P/Linux Intel/Linux 2.2.5 i586/OPT/Mon Jul 12 09:51:46 1999
>>> Query: exec tempdb..test
*** Caught Sybase Server Message #201 [Severity 16, state 2] at
line 0
    'Procedure test expects parameter @param, which was not supplied.'
PHP has encountered an Access Violation at 01EB36C9

At this point the PHP stopped and IIS too, exactly as we have posted.
It was necessary to stop and restart the www service manually.

Thanks again for your great help.
 [2003-04-18 20:37 UTC]
Have been able to reproduce with sybase libraries. As these are not available on FreeBSD, I use FreeTDS, which does not produce a status result in this situation ("return status = -6") but rather issues a "CS_CMD_FAIL" instantly. I know where the problem is (php_sybase_finish_results), fixing it is not trivial though (I've already given it a first shot but gave up after the supposed fix caused a segfault in another place:)). I'll do my best and see if I can include the fix in 4.3.2.
 [2003-06-02 14:58 UTC] cesararnold at yahoo dot com dot br
we still waiting for the fix.

Sometimes we must restart the web server and this is causing some problems to the users and mainly for our customers. What to say to the customers when web server stops sometimes regarding a php error ?

I got more info if can help.
The problem happens not only when the procedure receives null parameters for non null arguments.
If, in a procedure code, for example, I create a temporary table and it have fields that does not accept null values and, when inserting rows with null values into non null fields, the same problem happens. PHP stops the web server. Sybase just returns error (-6) advising that the field does not accept null values ...

We know that this is a error on the logics of the procedure and can be fixed by the programmer, fixing the code and recompiling the procedure and so on.

We know that you are doing the best, but on my single oppinion, it's a problem to be fixed urgently.

Are there any news about this bug fix ?
Thanks again.
 [2004-01-18 12:01 UTC]
Please try out the patch available at

This should fix it.
 [2004-01-19 07:34 UTC] cesararnold at yahoo dot com dot br
I?m sorry.
I?m not a php developer and wouldn?t get access to php "c" code.

Is there a patch available on ?
 [2004-01-23 21:38 UTC]
Please try using this CVS snapshot:
For Windows:

 [2004-01-28 12:15 UTC] cesararnold at yahoo dot com dot br

It seems to be working now, but not for all cases. Instead of a php crash and the web server stopped, a "HTTP 500 - Internal server error" 
page appears and "The page cannot be displayed". That's fine. But if I put a "echo " command before the query like the following example, the php crashes. If the "echo" is removed, the "HTTP 500 ..." error appears.

line 098) echo "Testing ...";
line 099) 
line 101) // select data
line 102) $cmd_sql = "exec sp_procedure";
line 103)
line 104) if (DB::isError($query = $db_conn->query($cmd_sql))) 
line 105) {    
line 106)     // get the native backend error    
line 107)     // and the last query    
line 108)     exit($query->getMessage());
line 109) }

I have two more questions to do about the last update:
- on the last stable version downloaded exists a new folder called "ext", that seems to be similat to "extensions". Now we have 2 folders on php directory, with similar dlls. Is that correct ?
- why it does not execute the "exit" command at line 108, because (in my oppinion) a error is occuring at the sql command ? is that error code returned or not ?

It seems that you are almost arriving to solve the case.
Anything alse we can do to help, please advise.
Thanks for all your help.
 [2004-01-29 07:48 UTC] cesararnold at yahoo dot com dot br
I didn't see that you sent php5 instead php4.

Anyway, after restore a backup from original version before install php5 and update it to the same error happens, as reported yesterday.

Including a "echo" command before run the query, it shows:
Testing ...PHP has encountered an Access Violation at 01E736C9

Removing the "echo" the "HTTP 500 ..." page is shown.

Step by step we can arrive at the destination.
 [2004-01-29 10:58 UTC] cesararnold at yahoo dot com dot br
maybe there was a mistake after update to
After copy the new files over the php root directory, stop and restart the server the same error occured, as reported to you.
But, after restart the hole server to make sure the installation was sucessfully, some php dlls were not loaded, indicating that maybe the update wasn't well done.
So, this is the reason of the error, and the latest version wasn't fully applied.

The original php version was restored, the web server stopped and the latest version applied. When the server is started some dlls does not start, like php_exif.dll, php_gd.dll, ... showing a message that it cannot be loaded.

I didn't copy the php.ini-recommeded over php.ini. I'm analysing what changes I need to do on our php.ini to put it like recommended and add our particular settings. Done  php.ini, I'll try to restart the web server and check if the dlls can be loaded.

Can you please confirm if there are new setting on php.ini-recommneded that will affect the way as php works regarding this bug ?

 [2004-01-29 16:53 UTC]
DO NOT mix different PHP versions with each other.
And I didn't ask you to try PHP 5, I asked to try the latest _STABLE_ snapshot, which is still PHP 4.

You're now trying to load wrong extensions from incompatible PHP version..please ask further support questions elsewhere.

 [2004-01-30 07:30 UTC] cesararnold at yahoo dot com dot br
Thanks, this recommendation is obvious.

I think that the question isn't find who is doing mistakes, and say "I'm right and YOU are not". I hope we are trying to solve a bug, and sometimes people do mistakes.

If you have time to check, I received a message asking to try latest snapshot talking about php5, and I did not see that it was from php5. It was my fault. Anyway, we did a backup and nothing was lost.

Now we are running the original version and we'll update over that. As soon as we update it, we'll keep you posted.
Is that fine to you ?

My question is: are there setting on php.ini-recommended that are necessary to the latest version or not ?

 [2004-03-01 10:50 UTC] cesararnold at yahoo dot com dot br
Congratulations to PHP Development Team !

The bug was well fixed. Sorry for any inconveniences caused during the time to solve the question.

Many thanks to "thekid", "sniper", Timm and everybody who's working and helping people to use php.
We hope you continue doing efforts to improve the language, as we can see frequently.
Good job !
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Fri Dec 01 12:01:26 2023 UTC