Hello there!
Here are two things that occurred to me while I played around with the TSRM
module (I am using 4.0.4pl1):
The first is: when compiling the TSRM without TSRM_DEBUG defined, but
compiling the PHP with -enable-debug option, the file zend_alloc.c uses the
function tsrm_error() but the function is not compiled in TSRM.c (#if'ed
out) and you get an undefined symbol error in linkage. Maybe the tsrm_error
function should be available even if TSRM_DEBUG is not defined.
The other thing in TSRM.c is this: The macro TSRM_ERROR is defined as either
"trsm_error" or as nothing. Here's the thing: when TSRM_ERROR is defined as
nothing, then:
TSRM_ERROR(something here, another here, etc, etc, etc );
is compiled as
(something here, another here, etc, etc, etc );
Which is a legal C statement, and it is compiled, but that is not quite what
one would hope for (i.e. an empty line), since all the parameters are still
eval'ed. The solution might be:
#ifdef TSRM_DEBUG
#define TSRM_ERROR(x) tsrm_error x
#else
#define TSRM_ERROR(x)
#endif
TSRM_ERROR((something here, another here, etc, etc, etc ));
Best Regards,
Eetay Natan,
R&D Manager
Zend Technologies
T: +972-3-6139665
mailto:[EMAIL PROTECTED]
http://www.zend.com
Come and visit the Zend Booth # 605 at Apachecon 2001, April 4-6,
California.
-----Original Message-----
From: Joe Brown [mailto:[EMAIL PROTECTED]]
Sent: Sunday, April 01, 2001 11:06 AM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] what kind of insect is this?
Had fun tracking this bugger down, now that I found it, I don't know what to
do with it. Maybe you can help me?
Summary: WinNT, Apache 1.3.19, fairly recent snap, php_oci8.dll (maybe
MySql also)
Resource not releasted after casting to an integer.
Don't know if this the the culprit to my Apache server on windows constantly
crashing, but suspect it may be playing a role in it.
<?php
$connection = OCIPLogon ("prn30","prn30","shmengie");
echo "<br>First round:<br>";
$statement=OCIParse ($connection, "select user from dual");
//$result_value=intval($statement); //CULPABLE.
echo var_dump($statement)."<br>Freed<br>";
@OCIFreeStatement($statement);
echo var_dump($statement)."<br>";
echo "<br>Second round:<br>";
$statement=OCIParse ($connection, "select user from dual");
$result_value=intval($statement); //CULPRIT
echo var_dump($statement)."<br>Freed<br>";
@OCIFreeStatement($statement);
echo var_dump($statement)."<br>";
?>
Outputs:
First round:
resource(2) of type (oci8 statement)
Freed
resource(2) of type (Unknown)
Second round:
resource(3) of type (oci8 statement)
Freed
resource(3) of type (oci8 statement)
In the second round, the resource is not freed.
Background info:
Thought it would be a good idea to use Manuel Lemos' Metabase. Works great
on Linux. That's where I developed this app, but now I need to migrate to a
Windows platform and it's crashing like crazy. Metabase's classes use an
intval($resource) as a place holder, in an array of statement_info so that
you can run mutiple queries. Metabase can keeps track of its queries this
way (for OCI at least).
The crashes experienced catestrophic, but threads aren't closing up shop
properly. Bug #9857 came about because a constant would be still be defined
the next page refresh. Haven't been able to reproduce this in a short code
segment w/out starting up metabase classes. After using Metabase on windows
however, all kinds of weirdness ensues. Apache performs illegal
instructions after every other refresh w/oci8 then.
-Joe "Shmengie"
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
