minor TSRM issues

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:eetay@zend.com http://www.zend.com Come and visit the Zend Booth # 605 at Apachecon 2001, April 4-6, California. -----Original Message----- From: Joe Brown [mailto:joebrown@somewhere.com] Sent: Sunday, April 01, 2001 11:06 AM To: php-dev@lists.php.net 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: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net