[PHP-DEV] Patches for 4_3 COM Memory Leaks
The recent fixes to the COM extension (for the 4_3 branch) have helped
with a lot of the memory leaking that was occuring. Working with
the latest snapshot I've done some additional work to clean up the
few remaining leaks I am seeing in my COM calls. I believe that the
two patches below eliminate all the overloaded COM memory leaks in
the 4_3 branch.
1) In php_COM_call_function_handler() the constructor block is:
if (zend_llist_count(property_reference-elements_list)==1
!strcmp(Z_STRVAL(function_name-element), com)) {
/* constructor */
PHP_FN(com_load)(INTERNAL_FUNCTION_PARAM_PASSTHRU);
*object = *return_value;
pval_copy_constructor(object);
pval_destructor(function_name-element);
return;
}
After tracing the memory leaks that PHP reports when executing $xml =
new COM('MSXML.DOMDocument'); I believe that the issue is the
replacing of *object with *return_value. The original allocated memory
of *object is now lost (and PHP reports it as a leak in the debug
version). I added a zval_dtor(object); just before replacing the
value of *object and the memory leaks are cleared up.
2) At the bottom of do_COM_propput() is this line:
efree(new_value); // FREE_VARIANT does a VariantClear() which is not
desired here !
Back in September (around the release of 4.2.3) I asked about why this
change was made as it causes the value that is being put to never be
released (as referenced in PHP Weekly Summaries #101 and #103). If I
revert this to FREE_VARIANT() (along with the first patch) it
eliminates all the memory leaks I am seeing with the overload COM
running under the ISAPI.
I have done initial testing of the COM usage in my PHP code with both
these patches and haven't seen any problems. I haven't had any luck
getting a response from the authors of the code areas in question.
Is there someone else who can consider these patches (in particular why
the FREE_VARIANT was changed to an efree)?
Michael Sisolak
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [BUGFIX 21089/21328] MSSQL not returning values of SP output parameters in 4.3.0
This issue has now been fixed in CVS by Frank Kromann. Michael Sisolak [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [BUGFIX 21089/21328] MSSQL not returning values of SP output parameters in 4.3.0
A bug was introduced into mssql_execute with version 1.89 of
php_mssql.c (as reported in the bug database as bugs #21089 and #21328)
which is included in the 4_3 branch. While this patch allowed a SQL
Server stored procedure to return multiple record sets, it prevented it
from ever returning the values of any output parameters. The call to
_mssql_get_sp_result was put inside an else clause that was never
called as long as the stored procedure executed correctly.
The attached patch is one solution: it resets the value of
retval_results to indicate all results have been read and breaks the
else back out into its own if clause. I'm not sure if this is really
needed - we may be able to just call _mssql_get_sp_result where this
patch adds the reset of the retval_results value.
Michael Sisolak
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--- php_mssql.orig.cWed Jan 08 16:24:07 2003
+++ php_mssql.c Wed Jan 08 16:24:58 2003
@@ -2078,8 +2078,11 @@
result-num_rows = _mssql_fetch_batch(mssql_ptr, result,
retvalue TSRMLS_CC);
result-statement = statement;
}
+
+ retval_results=dbresults(mssql_ptr-link);
}
- else if (retval_results==NO_MORE_RESULTS) {
+
+ if (retval_results==NO_MORE_RESULTS) {
_mssql_get_sp_result(mssql_ptr, statement TSRMLS_CC);
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [BUGFIX 21089/21328] MSSQL not returning values of SP output parameters in 4.3.0
The attached patch is one solution: it resets the value of retval_results to indicate all results have been read and breaks the else back out into its own if clause. I'm not sure if this is really needed - we may be able to just call _mssql_get_sp_result where this patch adds the reset of the retval_results value. My patch isn't quite correct. It sets the output parameters only as long as there are zero or one record sets returned - two or more and the parameters are not set. If we just always call _mssql_get_sp_result then this problem will be avoided, but might that cause some other issue? Michael Sisolak [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [BUGFIX 21089/21328] MSSQL not returning values of SP output parameters in 4.3.0
My patch isn't quite correct. It sets the output parameters only as long as there are zero or one record sets returned - two or more and the parameters are not set. If we just always call _mssql_get_sp_result then this problem will be avoided, but might that cause some other issue? I've played with this some more. You can't get the output parameters for the stored procedure call until after all the result sets have been read (a limit of the SQL Server DB-Library). The mssql_next_result() function is already set to do this, but you need to call it an extra time (i.e., if you have two result sets you have to call it once to get the second result set and then a second time to get the output parameters set). We definatley need to document this. I propose that my earlier patch is applied as it restored the BC that was broken in 4.3.0. In 4.2.3 the output parameters were always set after the call to mssql_execute(), but in 4.3.0 you now always have to call mssql_next_result() at least once. As a result any calls to mssql_execute() with output parameters in pre-4.3.0 code break when run under 4.3.0. With my patch if you have a stored procedure that returns one or no result sets the output parameters are returned just as they used to be. If you are returning multiple result sets (a new feature in 4.3.0) then you need to call mssql_next_result() an extra time to get the output parameters set correctly. Since that is a new feature there are no BC issues (just a need for a documention warning). Michael Sisolak [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fwd: Re: [BUGFIX 21089/21328] MSSQL not returning values of SP output parameters in 4.3.0
I propose that my earlier patch is applied as it restored the BC that
was broken in 4.3.0. In 4.2.3 the output parameters were always set
after the call to mssql_execute(), but in 4.3.0 you now always have
to
call mssql_next_result() at least once. As a result any calls to
mssql_execute() with output parameters in pre-4.3.0 code break when
run
under 4.3.0. With my patch if you have a stored procedure that
returns
one or no result sets the output parameters are returned just as they
used to be. If you are returning multiple result sets (a new feature
in 4.3.0) then you need to call mssql_next_result() an extra time to
get the output parameters set correctly. Since that is a new feature
there are no BC issues (just a need for a documention warning).
Okay, I've really _got_ to stop responding to myself multiple times.
People may begin to wonder...
It turns out there was an issue with my first patch attempt as it left
the state of the database result set pointer incorrect if there were
multiple record sets. The attached patch fixes this by always trying
to get the output parameters without first testing if there is another
result set that will block the request. Nothing bad happens if there
is, and if there isn't the output parameters are correctly set. I
couldn't find a way to peak ahead to see if there was another result
set so that I could skip this, but it doesn't seem to do any harm.
This patch now makes mssql_execute() work for output parameters from a
stored procedure with zero and one result sets just as it did in 4.2.3,
and for 2+ result sets requires calls to mssql_next_result().
Michael Sisolak
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--- php_mssql.orig.cWed Jan 08 16:24:07 2003
+++ php_mssql.c Thu Jan 09 00:26:43 2003
@@ -2053,12 +2053,10 @@
RETURN_FALSE;
}
- /* The following is just like mssql_query, fetch all rows from the server into
-* the row buffer. We add here the RETVAL and OUTPUT parameters stuff
+ /* The following is just like mssql_query, fetch all rows from the first
+result
+* set into the row buffer.
*/
result=NULL;
- /* if multiple recordsets in a stored procedure were supported, we would
- use a while (retval_results!=NO_MORE_RESULTS) instead an if */
if (retval_results==SUCCEED) {
if ( (retvalue=(dbnextrow(mssql_ptr-link)))!=NO_MORE_ROWS ) {
num_fields = dbnumcols(mssql_ptr-link);
@@ -2079,9 +2077,11 @@
result-statement = statement;
}
}
- else if (retval_results==NO_MORE_RESULTS) {
- _mssql_get_sp_result(mssql_ptr, statement TSRMLS_CC);
- }
+
+ /* Try to get output parameters. Won't work if there are more record sets
+* in the batch until they are all retrieved with mssql_next_result().
+*/
+ _mssql_get_sp_result(mssql_ptr, statement TSRMLS_CC);
if (result==NULL) {
RETURN_TRUE;/* no recordset returned ...*/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] What headers/libs does Win32 Snaps build use?
As I was looking into my build of Win32 failing becuase it tried to link to a non-existant zlib.lib (the win32build.zip version is called zlibstat.lib), it occured to me that everything does build fine on the snapshot machine. All the extensions build also (like gd or openssl) that require external libraries and headers that are not included in win32build.zip. I also am curious about the versions of libraries which are linked as most of win32build.zip is from 1998 (such as the older version of ZLib with the double free error). What headers and libraries are in the include paths for the Win32 snapshot builds? Are they (or could they be made) available as a collection for those that want to build the entire Win32 package? Michael Sisolak [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Win32 Build Quirks
Zeev Suraski wrote: It's zlib. I'm not sure why people relied on users having zlib installed as a part of their standard libraries under Windows, but it's not a reasonable assumption... checkout zlib, build it (under both Release and Debug), delete *.lib and *.dll from your PHP output directory, and relink. I configured the zlib project to work properly with PHP. Zeev, The current win32build tools has a zlibstat.lib in the lib directory. If I copy that to also be called zlib.lib then the release 4.3.0 build correctly. Should we be linking to zlibstat.lib instead of zlib.lib or updating win32build to include whatever zlib.lib it should link to? I would imagine that most Win32 builds will now fail (unless they happen to have a zlib.lib in their library path). Michael Sisolak [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Multiple MSSQL Crashes in 4.3.0RC2
Frank Kromann has investigated these issues and has made fixes in the
CVS version of ext/mssql.
Michael
--- Michael Sisolak [EMAIL PROTECTED] wrote:
Testing my existing SQL Server based sites with 4.3.0RC2 resulted in
many memory access violations and crashes. I believe that I have
tracked these down to two different changes made to the MSSQL
extension
since 4.2.3:
1) In version 1.82 of php_mssql.c there were 6 mallocs that were
changed from emalloc(res_length + 1); to emalloc(res_length);. I
believe, however, that the code that uses those memory blocks in at
least four of the cases required that extra space. This is the code
as
it is now for two of the changes in 4.3.0RC2:
res_buf = (unsigned char *) emalloc(res_length);
bin = ((DBBINARY *)dbdata(mssql_ptr-link, offset));
memcpy(res_buf, bin, res_length);
res_buf[res_length] = '\0';
It's the setting of res_buf[res_length] illegal, as that would be
beyond the bounds of emalloc(res_length)? Also this code (appearing
in
two of the changes):
res_length = 19;
res_buf = (unsigned char *) emalloc(res_length);
sprintf(res_buf, %d-%02d-%02d %02d:%02d:%02d , . . .
Since the length of the character string is going to be 19
characters,
isn't the sprintf going to write an ASCIIZ ending beyond the size of
res_buf?
Does the way emalloc() works take care of these problems? Adding the
+ 1 back to these four emalloc() calls stopped one set of crashes.
2) In version 1.83 of php_mssql.c the mssql_query() function was
altered from:
if ((num_fields = dbnumcols(mssql_ptr-link)) = 0) {
RETURN_TRUE;
}
to:
if ((num_fields = dbnumcols(mssql_ptr-link)) = 0
!dbdataready(mssql_ptr-link)) {
RETURN_TRUE;
}
The CVS comment indicates that this change was for fixing the
mssql_query to handle multiple results correct if the first result
does
not return any data. If I now call mssql_query() with a query that
doesn't return any values (like a SQL-T EXEC call), however, PHP will
crash (removing the new dbdataready() check eliminates the crash).
Michael Sisolak
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Multiple MSSQL Crashes in 4.3.0RC2
Testing my existing SQL Server based sites with 4.3.0RC2 resulted in
many memory access violations and crashes. I believe that I have
tracked these down to two different changes made to the MSSQL extension
since 4.2.3:
1) In version 1.82 of php_mssql.c there were 6 mallocs that were
changed from emalloc(res_length + 1); to emalloc(res_length);. I
believe, however, that the code that uses those memory blocks in at
least four of the cases required that extra space. This is the code as
it is now for two of the changes in 4.3.0RC2:
res_buf = (unsigned char *) emalloc(res_length);
bin = ((DBBINARY *)dbdata(mssql_ptr-link, offset));
memcpy(res_buf, bin, res_length);
res_buf[res_length] = '\0';
It's the setting of res_buf[res_length] illegal, as that would be
beyond the bounds of emalloc(res_length)? Also this code (appearing in
two of the changes):
res_length = 19;
res_buf = (unsigned char *) emalloc(res_length);
sprintf(res_buf, %d-%02d-%02d %02d:%02d:%02d , . . .
Since the length of the character string is going to be 19 characters,
isn't the sprintf going to write an ASCIIZ ending beyond the size of
res_buf?
Does the way emalloc() works take care of these problems? Adding the
+ 1 back to these four emalloc() calls stopped one set of crashes.
2) In version 1.83 of php_mssql.c the mssql_query() function was
altered from:
if ((num_fields = dbnumcols(mssql_ptr-link)) = 0) {
RETURN_TRUE;
}
to:
if ((num_fields = dbnumcols(mssql_ptr-link)) = 0
!dbdataready(mssql_ptr-link)) {
RETURN_TRUE;
}
The CVS comment indicates that this change was for fixing the
mssql_query to handle multiple results correct if the first result does
not return any data. If I now call mssql_query() with a query that
doesn't return any values (like a SQL-T EXEC call), however, PHP will
crash (removing the new dbdataready() check eliminates the crash).
Michael Sisolak
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] +3 for Win32 CoInitalize/CoUninitialize Call Move, Please Apply
We got +3 on applying this but missed it for 4.3.0 RC2. Will someone
with the correct karma please apply it to the 4.3.0 tree?
Michael
--- Michael Sisolak [EMAIL PROTECTED] wrote:
Date: Mon, 25 Nov 2002 10:32:13 -0800 (PST)
From: Michael Sisolak [EMAIL PROTECTED]
Subject: [PATCH 4.3.0] Win32 CoInitalize/CoUninitialize Call Move
To: [EMAIL PROTECTED]
While stess testing the recent threading fixes under the ISAPI module
I
was seeing a lot of instability in IIS after the testing finished.
While the PHP pages would continue to load, no ASP pages would
anymore.
I have tracked this down to the placement of the Win32
CoInitialize()
and CoUninitialize() calls. In the current 4.3.0 release candidate
CoInitialize() and CoUninitialize() are only called once per thread
(from the basic_globals_ctor/_dtor in basic_functions.c). According
to
Microsoft, however, at
http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/devs0hm5.asp:
COM initialization, from CoInitialize or CoInitializeEx, affects the
thread in which it's called. For this reason, you cannot initialize
COM
unless you uninitialize it before returning from your callback
function. [ . . .] CoInitialize and CoUninitialize need to be called
in
order. If one is called twice in a row, by different ISAPIs on the
same
thread, your users may see error 270.
This is exactly the error I am seeing: if I load an ASP page in a
thread that has processed PHP pages I get the 270 error (reported as
Error -2147417842 (0x8001010e)). I moved the CoInitilize call to
PHP_RINIT_FUNCTION(basic) and CoUninitialize to
PHP_RSHUTDOWN_FUNCTION(basic) and reran my stress testing. After
100,000 PHP page loads IIS now remains stable and able to process
both
ASP and PHP pages.
I ran this by Zeev and he suggested that some kind of just-in-time
COM
initialization, but I'm not going to have the time to get to this
full
solution until later. In the meantime for 4.3.0 I request that the
attached patch is applied that moves the CoInitialize or
CoInitializeEx
calls to be per-request. This is the last little fix that all the
multi-threading bug fixing to make the ISAPI rock solid in 4.3.0
requires. I've done a lot of testing and feel very confident about
including this patch.
Michael Sisolak
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--- basic_functions.c.orig Fri Nov 08 10:49:32 2002
+++ basic_functions.c Mon Nov 25 13:25:09 2002
@@ -959,10 +959,6 @@
memset(BG(url_adapt_state), 0, sizeof(BG(url_adapt_state)));
memset(BG(url_adapt_state_ex), 0, sizeof(BG(url_adapt_state_ex)));
-#ifdef PHP_WIN32
- CoInitialize(NULL);
-#endif
-
BG(incomplete_class) = php_create_incomplete_class(TSRMLS_C);
}
@@ -973,9 +969,6 @@
if (BG(sm_allowed_env_vars)) {
free(BG(sm_allowed_env_vars));
}
-#ifdef PHP_WIN32
- CoUninitialize();
-#endif
}
@@ -1102,6 +1095,10 @@
PHP_RINIT_FUNCTION(basic)
{
+#ifdef PHP_WIN32
+ CoInitialize(NULL);
+#endif
+
memset(BG(strtok_table), 0, 256);
BG(strtok_string) = NULL;
BG(strtok_zval) = NULL;
@@ -1182,6 +1179,10 @@
if (BG(mmap_file)) {
munmap(BG(mmap_file), BG(mmap_len));
}
+#endif
+
+#ifdef PHP_WIN32
+ CoUninitialize();
#endif
return SUCCESS;
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH 4.3.0] Win32 CoInitalize/CoUninitialize Call Move
While stess testing the recent threading fixes under the ISAPI module I
was seeing a lot of instability in IIS after the testing finished.
While the PHP pages would continue to load, no ASP pages would anymore.
I have tracked this down to the placement of the Win32 CoInitialize()
and CoUninitialize() calls. In the current 4.3.0 release candidate
CoInitialize() and CoUninitialize() are only called once per thread
(from the basic_globals_ctor/_dtor in basic_functions.c). According to
Microsoft, however, at
http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/devs0hm5.asp:
COM initialization, from CoInitialize or CoInitializeEx, affects the
thread in which it's called. For this reason, you cannot initialize COM
unless you uninitialize it before returning from your callback
function. [ . . .] CoInitialize and CoUninitialize need to be called in
order. If one is called twice in a row, by different ISAPIs on the same
thread, your users may see error 270.
This is exactly the error I am seeing: if I load an ASP page in a
thread that has processed PHP pages I get the 270 error (reported as
Error -2147417842 (0x8001010e)). I moved the CoInitilize call to
PHP_RINIT_FUNCTION(basic) and CoUninitialize to
PHP_RSHUTDOWN_FUNCTION(basic) and reran my stress testing. After
100,000 PHP page loads IIS now remains stable and able to process both
ASP and PHP pages.
I ran this by Zeev and he suggested that some kind of just-in-time COM
initialization, but I'm not going to have the time to get to this full
solution until later. In the meantime for 4.3.0 I request that the
attached patch is applied that moves the CoInitialize or CoInitializeEx
calls to be per-request. This is the last little fix that all the
multi-threading bug fixing to make the ISAPI rock solid in 4.3.0
requires. I've done a lot of testing and feel very confident about
including this patch.
Michael Sisolak
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail Plus Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--- basic_functions.c.orig Fri Nov 08 10:49:32 2002
+++ basic_functions.c Mon Nov 25 13:25:09 2002
@@ -959,10 +959,6 @@
memset(BG(url_adapt_state), 0, sizeof(BG(url_adapt_state)));
memset(BG(url_adapt_state_ex), 0, sizeof(BG(url_adapt_state_ex)));
-#ifdef PHP_WIN32
- CoInitialize(NULL);
-#endif
-
BG(incomplete_class) = php_create_incomplete_class(TSRMLS_C);
}
@@ -973,9 +969,6 @@
if (BG(sm_allowed_env_vars)) {
free(BG(sm_allowed_env_vars));
}
-#ifdef PHP_WIN32
- CoUninitialize();
-#endif
}
@@ -1102,6 +1095,10 @@
PHP_RINIT_FUNCTION(basic)
{
+#ifdef PHP_WIN32
+ CoInitialize(NULL);
+#endif
+
memset(BG(strtok_table), 0, 256);
BG(strtok_string) = NULL;
BG(strtok_zval) = NULL;
@@ -1182,6 +1179,10 @@
if (BG(mmap_file)) {
munmap(BG(mmap_file), BG(mmap_len));
}
+#endif
+
+#ifdef PHP_WIN32
+ CoUninitialize();
#endif
return SUCCESS;
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Adding mail() Parameter to Set Return Path
Several months ago the imap_sendmail.c routines were merged into the standard Win32 sendmail.c code. One of the results of this was that the TSendMail function gained a parameter to specifically set the mail header return path. The imap_mail() function can use this parameter, but the standard mail() function cannot (it is always set to NULL). Based on the number of comments on the mail() manual pages about issues that occur when the return path is always the sendmail_from ini value, it appears that it would be useful to add an additional optional parameter to mail() to set the return path. The only downside I see to this is that the value would only work for the internal Win32 sendmail code and not the standard Unix calls to sendmail. Any thoughts on this? Michael Sisolak [EMAIL PROTECTED] __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Leak Memory Overrun in 4.3.0pre2
I'm seeing a memory overrun under PHP 4.3.0pre2 (debug) running under
Windows 2000 ISAPI. Using these two scripts:
test.php
html
head
link rel=stylesheet href=stylesheet.php type=text/css
/head
body
span class=textstyled!/span
/body
/html
stylesheet.php
--
?php
// only reload this version of the stylesheet ever hour
header(Cache-Control: max-age=3600);
?
.text {
font-size: 12px;
color: red;
font-family: Arial, Helvetica, Verdana, sans-serif
}
If in a browser window I refresh this page repeatedly within about ten
seconds I get an access violation and this debug output:
---
C:\Work\php-source\php-4.3.0pre2\ext\bcmath\libbcmath\src\init.c(72) :
Freeing 0x01B85050 (1 bytes), script=c:\inetpub\wwwroot\test.php
Last leak repeated 2 times
C:\Work\php-source\php-4.3.0pre2\ext\bcmath\libbcmath\src\init.c(57) :
Freeing 0x01B84FF8 (29 bytes), script=c:\inetpub\wwwroot\test.php
Last leak repeated 2 times
---
c:\work\php-source\php-4.3.0pre2\zend\zend_ptr_stack.c(77) : Block
0x01B80650 status:
Beginning:
Overrun (magic=0x01B80178, expected=0x7312F8DC)
End:
Unknown
---
c:\work\php-source\php-4.3.0pre2\zend\zend_hash.c(534) : ht=0x018f3484
is already destroyed
c:\work\php-source\php-4.3.0pre2\zend\zend_hash.c(660) : ht=0x018f3548
is already destroyed
---
c:\work\php-source\php-4.3.0pre2\zend\zend_ptr_stack.c(77) : Block
0x01B00650 status:
Beginning:
Overrun (magic=0x01B00178, expected=0x7312F8DC)
End:
Unknown
---
c:\work\php-source\php-4.3.0pre2\zend\zend_hash.c(534) : ht=0x01894df4
is already destroyed
c:\work\php-source\php-4.3.0pre2\zend\zend_hash.c(660) : ht=0x01894eb8
is already destroyed
---
Any tips on how to track down what's going on here?
Michael Sisolak
[EMAIL PROTECTED]
__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Leak Memory Overrun in 4.3.0pre2
I'm seeing a memory overrun under PHP 4.3.0pre2 (debug) running under Windows 2000 ISAPI. [ . . . ] --- C:\Work\php-source\php-4.3.0pre2\ext\bcmath\libbcmath\src\init.c(72): Freeing 0x01B85050 (1 bytes), script=c:\inetpub\wwwroot\test.php Last leak repeated 2 times C:\Work\php-source\php-4.3.0pre2\ext\bcmath\libbcmath\src\init.c(57): Freeing 0x01B84FF8 (29 bytes), script=c:\inetpub\wwwroot\test.php Last leak repeated 2 times Based on seeing these leaks I disabled BCMath and recompiled PHP. Without BCMath active I do not have any of the memory overruns that I reported in my previous message. Looking in the CVS logs for php4/ext/bcmath/bcmath.c I believe there may be an issue with the changes introduced in version 1.37 (by Andi, who is CCed also). This patch moved the allocation and freeing of the static BC numbers _zero_, _one_, and _two_ to a per-request basis instead of at module initilzation and shutdown. It looks like the storage locations for those values are global externs, however, which multiple threads are now allocating and deallocating at the same time. Is there somewhere that I'm not understanding in the code that would keep multiple threads from smashing each other here? Michael Sisolak [EMAIL PROTECTED] __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 4.3.0pre1 Win32 Build Error
A Win32 build of 4.3.0pre1 fails with this error: Compiling... zend.c c:\work\php-source\php-4.3.0pre1\zend\zend.c(163) : error C2065: 'tsrm_ls' : undeclared identifier Michael Sisolak [EMAIL PROTECTED] __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Additional 4.3.0pre1 Win32 Build Errors
My Win32 build of 4.3.0pre1 also fails with these two errors: glob.c c:\work\php-source\php-4.3.0pre1\win32\glob.c(506) : warning C4090: 'function' : different 'const' qualifiers c:\work\php-source\php-4.3.0pre1\win32\glob.c(506) : warning C4028: formal parameter 1 different from declaration c:\work\php-source\php-4.3.0pre1\win32\glob.c(506) : warning C4090: 'function' : different 'const' qualifiers c:\work\php-source\php-4.3.0pre1\win32\glob.c(506) : warning C4028: formal parameter 2 different from declaration c:\work\php-source\php-4.3.0pre1\win32\glob.c(506) : warning C4024: 'qsort' : different types for formal and actual parameter 4 formatted_print.c c:\work\php-source\php-4.3.0pre1\ext\standard\formatted_print.c(287) : error C2065: 'tsrm_ls' : undeclared identifier Michael Sisolak [EMAIL PROTECTED] __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] COM Memory Leak in 4.2.3 RCs Not Addressed
The leak that was referred to in the Zend PHP Weekly Summary last week: BUG: COM leak in 4.2.3 RC 1 Michael Sisolak let the list know that the COM extension is leaking memory in the 4.2.3 Release Candidate. He ahs pointed out a fix which will be included for the final version. was not addressed before release. The released version of 4.2.3 has the same memory leak issue when property values are set on a COM object that was reported about RC1 and RC2. This leak does not occur in version 4.2.2. I've opened a new bug report (#19342) on this: There appears to be a memory leak when setting a property value of a COM object in 4.2.3. Running under ISAPI if this script is repeated memory usage continues to grow: $adodb = new COM(ADODB.Connection); $adodb-ConnectionString = str_repeat(this is a text string!, 1000); Looking through the patches that have been applied, I believe that this is caused when COM.c went from 1.78 to 1.79 (which was then back-ported to 4.2.3). In this patch at the end of do_COM_propput(), this: FREE_VARIANT(new_value); became this: efree(new_value); // FREE_VARIANT does a VariantClear() which is not desired here ! If I reverse this patch I no longer see the leak and the code still appears to be working correctly. What was the purpose of this change? Does doing the FREE_VARIANT version cause some other issue? Michael Sisolak [EMAIL PROTECTED] __ Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost http://dir.remember.yahoo.com/tribute -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ISAPI Crash Debugging Notes
Andi,
After spending some more time looking at the Zend2 code it appears that
it does still have the same issue that I'm seeing in Zend1 (first ISAPI
thread gets the global compiler_globals as it's own personal copy). I
can't get the same debug output as I was able to for Zend1, but I am
seeing similar error messages (mostly about classes being already
defined that aren't).
I've continued to dig around in the Zend1 code and still believe that
the first thread is using the globals as it's own copy. In one of the
earlier messages you said that this shouldn't be happening. In
zend_startup() the startup thread's copy of compiler_global is set to
be the GLOBAL_*_TABLES version:
compiler_globals = ts_resource(compiler_globals_id);
executor_globals = ts_resource(executor_globals_id);
tsrm_ls = ts_resource_ex(0, NULL);
compiler_globals_dtor(compiler_globals, tsrm_ls);
compiler_globals-function_table = GLOBAL_FUNCTION_TABLE;
compiler_globals-class_table = GLOBAL_CLASS_TABLE;
compiler_globals-auto_globals = GLOBAL_AUTO_GLOBALS_TABLE;
I can't find anything in the code that runs after this that would reset
this thread's compiler_globals to be it's own local copy again. Can
you explain where you think this should be happening so I can try to
track it in my setup? Maybe this is somehow ISAPI specific.
As a follow-up test I created a version of 4.2.3RC1 with a new external
function in zend.c:
void zend_startup_done()
{
#ifdef ZTS
zend_compiler_globals *compiler_globals;
zend_executor_globals *executor_globals;
TSRMLS_FETCH();
compiler_globals = ts_resource(compiler_globals_id);
compiler_globals_ctor(compiler_globals, tsrm_ls);
executor_globals = ts_resource(executor_globals_id);
executor_globals_ctor(executor_globals, tsrm_ls);
#endif
}
This function will create a new compiler_globals and executor_globals
for the current thread and reinitilize them with the constructors. I
then added a call to this function as the last step of the ISAPI's
DLL_PROCESS_ATTACH code. I've tested and it appears to fix the
problems I was having with using the ISAPI module just as my version
that spun off a new thread for the initialization did.
Michael
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Any chance you can setup and Engine 2 build and see if this problem
persists?
Andi
At 06:42 AM 8/27/2002 -0700, Michael Sisolak wrote:
--- Zeev Suraski [EMAIL PROTECTED] wrote:
At 09:53 27/08/2002, Michael Sisolak wrote:
i've been doing some debugging of the crashes when running
php
under
the isapi sapi. is anybody else currently looking at this?
if
you
are let's talk - here are my notes so far.
first off, can you try using
http://www.php.net/~zeev/php-4.2.3rc1.tar.gz
and see if you experience the same problems? i've made some
thread-safety related fixes there, even though none should
lead
to a hard crash...
zeev,
i believe that i may have tracked down a major isapi filter
thread-safety hole. if i understand what zend_startup() is
doing
correctly, it assumes that the thread that it runs under will
not
also
be used to serve http requests.
No, the startup thread can be used as a regular HTTP thread,
nothing
in the
code should prevent that.
The globals code in the startup sequence is very tricky, but it
should work.
This is a sample of the debug output that I'm seeing (this is PHP
4.2.1
running under Windows 2000 Professional, single CPU):
[1948] the startup thread is 1956
[1948] GLOBAL_FUNCTION_TABLE is 4226120
[1948] in HttpExtensionProc thread 1956, CG(function_table) is
4226120
[1948] in HttpExtensionProc thread 1520, CG(function_table) is
18834536
[1948] in HttpExtensionProc thread 920, CG(function_table) is
18838912
[1948] in HttpExtensionProc thread 1956, CG(function_table) is
4226120
[1948] in HttpExtensionProc thread 1256, CG(function_table) is
19250808
[1948] in HttpExtensionProc thread 920, CG(function_table) is
18838912
[1948] in HttpExtensionProc thread 1956, CG(function_table) is
4226120
Notice that the initial thread (1956) appears to continue to use
GLOBAL_FUNCTION_TABLE as it's own CG(function_table). I'm reporting
the GLOBAL_FUNCTION_TABLE value from within zend_startup() - is
there
some point later in the code that makes it okay that this is the
same
value that I get for a CG(function_table) later?
__
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ISAPI Crash Debugging Notes
Andi, I download the alpha2 version of the php-4.3.0-dev-zend2 release. Unfortunatley out-of-the-box I got an Invalid access to memory location. error returned when I try to view I page. I was able to track it down to something with the browscap processing - something in ini_parse() is causing a memory access violation, but I get lost in all the lex code trying to figure out exactly what is going on. I disabled my browscap entry and was able to continue with the testing. It does appear that the issue I'm seeing with the first thread getting the GLOBAL_FUNCTION_TABLE as it's own local copy is fixed in Zend2: [1340] the startup thread is 1996 [1340] copying the GLOBAL_FUNCTION_TABLE from 20933432 [1340] in HttpExtensionProc thread 1996, CG(function table) is 21138360 [1340] copying the GLOBAL_FUNCTION_TABLE from 20933432 [1340] in HttpExtensionProc thread 532, CG(function table) is 22055840 [1340] in HttpExtensionProc thread 1996, CG(function table) is 21138360 The initial thread does now get it's own copy of the GLOBAL_FUNCTION_TABLE. Since it will be a while before Zend2 is production quality do you think it would be possible to port what makes this work in Zend2 back to 4.2.x? The changes in zend.c seem fairly straight forward, but there may be interactions with other changes I'm not seeing. Michael Sisolak [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ISAPI Crash Debugging Notes
I've been doing some debugging of the crashes when running PHP under
the ISAPI sapi. Is anybody else currently looking at this? If you
are let's talk - here are my notes so far.
First off, can you try using
http://www.php.net/~zeev/php-4.2.3RC1.tar.gz
and see if you experience the same problems? I've made some
thread-safety related fixes there, even though none should lead
to a hard crash...
Zeev,
I believe that I may have tracked down a major ISAPI filter
thread-safety hole. If I understand what zend_startup() is doing
correctly, it assumes that the thread that it runs under will not also
be used to serve HTTP requests. I base that on the #ifdef ZTS
section in the middle that takes the compiler_globals that has been
allocated for that thread, destorys it, and replaces it with pointers
to the GLOBAL_FUNCTION_TABLE and GLOBAL_CLASS_TABLE instead. I believe
that the compiler_globals for this thread must thus be the parent of
all the child threads that the web server will create (and
compiler_globals_ctor() appears to bear that out).
Under an ISAPI application, however, the thread that starts the DLL is
also used as the first thread to serve HTTP requests through
HttpExtensionProc. As PHP currently behaves, this initial thread will
use the global compiler_globals as it's own personal copy (as that is
the state that zend_startup() left the thread in). If another thread
starts as this thread is processing, it copies the
GLOBAL_FUNCTION/CLASS_TABLE assuming they are thread safe, but in
reality they contain the local values of the first HTTP processing
thread. The local functions and classes of the first thread leak into
the second and then it's all downhill from there.
I believe that the solution to this problem is to start a new thread
for zend_startup() when it is called to initialize the ISAPI module.
This way the globals have their own private thread and the initial
thread can be safely initialized as a child of those global values.
I've thrown together a quick hack to demonstrate this - it's not the
best threaded code ever, but it has allowed me to test out my ideas.
Since creating and destroying threads in DllMain is quite tricky, I've
moved all the startup and shutdown code into the ISAPI
GetExtensionVersion and TerminateExtension functions to make things
easier. On startup GetExtensionVersion starts a new thread with
php_isapi_startup_global_thread(). This thread calls the module-wide
startup functions and then enters a loop waiting for ISAPI termination.
When IIS calls TerminateExtension this thread is signaled to fall into
the module termination code.
I have never been able to get the ISAPI module to stay up for more than
a few minutes when I tested previously, but I've been hammering on this
code for the last hour and so far it has been rock solid. Please take
a look at what I've done here and see if it makes sense. I'm trying
not to get my hopes up, but what I see so far looks very encouraging.
Michael Sisolak
[EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
__
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
--- php-4.2.1/sapi/isapi/php4isapi.def.orig Tue Aug 27 02:36:14 2002
+++ php-4.2.1/sapi/isapi/php4isapi.def Tue Aug 27 02:36:20 2002
@@ -3,3 +3,4 @@
GetFilterVersion
HttpExtensionProc
GetExtensionVersion
+TerminateExtension
--- php-4.2.1/sapi/isapi/php4isapi.c.orig Thu Apr 18 18:52:20 2002
+++ php-4.2.1/sapi/isapi/php4isapi.cTue Aug 27 01:54:51 2002
@@ -63,6 +63,9 @@
static zend_bool bFilterLoaded=0;
static zend_bool bTerminateThreadsOnError=0;
+static HANDLE pGlobalThread;
+static zend_bool bGlobalThreadReady=0;
+
static char *isapi_special_server_variable_names[] = {
ALL_HTTP,
HTTPS,
@@ -682,6 +685,32 @@
}
+void php_isapi_startup_global_thread(void *unused)
+{
+ /* start the global thread (TSRM and global values) */
+#ifdef WITH_ZEUS
+ tsrm_startup(128, 1, TSRM_ERROR_LEVEL_CORE, TSRM.log);
+#else
+ tsrm_startup(128, 1, TSRM_ERROR_LEVEL_CORE, C:\\TSRM.log);
+#endif
+ sapi_startup(isapi_sapi_module);
+ if (isapi_sapi_module.startup) {
+ isapi_sapi_module.startup(sapi_module);
+ }
+
+ /* signal that we're ready to begin processing requests and wait for
+termination */
+ bGlobalThreadReady = 1;
+ while (bGlobalThreadReady)
+ Sleep(1000);
+
+ /* shutdown the global thread (signaled from TerminateExtension) */
+ if (isapi_sapi_module.shutdown) {
+ isapi_sapi_module.shutdown(sapi_module);
+ }
+ tsrm_shutdown();
+}
+
+
BOOL WINAPI GetExtensionVersion(HSE_VERSION_INFO *pVer)
{
pVer-dwExtensionVersion = HSE_VERSION;
@@ -690,10 +719,27 @@
#else
lstrcpyn(pVer-lpszExtensionDesc
Re: [PHP-DEV] ISAPI Crash Debugging Notes
--- Zeev Suraski [EMAIL PROTECTED] wrote: At 09:53 27/08/2002, Michael Sisolak wrote: i've been doing some debugging of the crashes when running php under the isapi sapi. is anybody else currently looking at this? if you are let's talk - here are my notes so far. first off, can you try using http://www.php.net/~zeev/php-4.2.3rc1.tar.gz and see if you experience the same problems? i've made some thread-safety related fixes there, even though none should lead to a hard crash... zeev, i believe that i may have tracked down a major isapi filter thread-safety hole. if i understand what zend_startup() is doing correctly, it assumes that the thread that it runs under will not also be used to serve http requests. No, the startup thread can be used as a regular HTTP thread, nothing in the code should prevent that. The globals code in the startup sequence is very tricky, but it should work. This is a sample of the debug output that I'm seeing (this is PHP 4.2.1 running under Windows 2000 Professional, single CPU): [1948] the startup thread is 1956 [1948] GLOBAL_FUNCTION_TABLE is 4226120 [1948] in HttpExtensionProc thread 1956, CG(function_table) is 4226120 [1948] in HttpExtensionProc thread 1520, CG(function_table) is 18834536 [1948] in HttpExtensionProc thread 920, CG(function_table) is 18838912 [1948] in HttpExtensionProc thread 1956, CG(function_table) is 4226120 [1948] in HttpExtensionProc thread 1256, CG(function_table) is 19250808 [1948] in HttpExtensionProc thread 920, CG(function_table) is 18838912 [1948] in HttpExtensionProc thread 1956, CG(function_table) is 4226120 Notice that the initial thread (1956) appears to continue to use GLOBAL_FUNCTION_TABLE as it's own CG(function_table). I'm reporting the GLOBAL_FUNCTION_TABLE value from within zend_startup() - is there some point later in the code that makes it okay that this is the same value that I get for a CG(function_table) later? Either way - starting threads from an ISAPI filter/extension is completely forbidden (or at least strongly discouraged) so even if there is some bug in there, starting our own thread is not an option. I don't believe that this is true. In this sample on MSDN: http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q197728 their code for GetExtensionVersion calls AfxBeginThread. Also in this document: http://msdn.microsoft.com/library/en-us/vccore/html/vcconatlserverandcom.asp point 1 recommends Create your own thread in GetExtensionVersion on which you can initialize COM... Can you give me the data I mentioned in the previous letter? This is PHP 4.2.1 running under Windows 2000 Professional (SP3) on a single CPU system. I can't really send the code as I'm currently testing with a large application that I have been running under CGI. I'll see if I can come up with a simpler example that causes the crash, but the debug output above would be the same either way. Please let me know if there is anything else I can provide to help in tracking this down. Michael Sisolak [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] COM Memory Leak in 4.2.3RC1
There appears to be a memory leak when setting a property value of a COM object in 4.2.3RC1. Running under ISAPI if this script is repeated memory usage continues to grow: $adodb = new COM(ADODB.Connection); $adodb-ConnectionString = str_repeat(this is a text string!, 1000); Looking through the patches that have been applied, I believe that this is caused when COM.c went from 1.78 to 1.79 (which was then back-ported to 4.2.3). In this patch at the end of do_COM_propput(), this: FREE_VARIANT(new_value); became this: efree(new_value); // FREE_VARIANT does a VariantClear() which is not desired here ! If I reverse this patch I no longer see the leak and the code still appears to be working correctly. What was the purpose of this change? Michael Sisolak [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ISAPI Crash Debugging Notes
I've been doing some debugging of the crashes when running PHP under the ISAPI sapi. Is anybody else currently looking at this? If you are let's talk - here are my notes so far. I can make my install of PHP (4.2.1, a debug build) throw an exception on the first load after an IISReset 90% of the time. My code is a PHP page that loads another PHP page as the stylesheet - so I end up with two PHP page loads running at the same time. The exception is thrown in the php_request_shutdown call at the end of the HttpExtensionProc. I'm working on tracking down where the exception is coming from, but one thing I've noticed so far is that the first thread that gets to the shutdown_memory_manager call (inside php_request_shutdown) reports a lot of leaks. I find this to be quite odd, and am beginning to wonder if it is mis-reporting the memory of the second thread as if they were leaks of the first. It's just a hunch so far - I haven't been able to come up with any evidence, and my understanding of the thread-safe memory managment is quite shallow. Having done some more work I believe that the exception I'm getting is coming from inside the zend_hash_reverse_apply call in shutdown_executor. The one to clear the function_table completes correctly, but then the class_table one fails (my main PHP file does include a series of classes). Michael Sisolak [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Thread safety failure in EG(function_table)?
I believe that I can reproduce a thread safety failure in init_executor (as called from the ISAPI sapi). I have a PHP script page that loads the stylesheet as a PHP page - thus causing two almost simultaneous page loads. I assume that if in init_executor() directly after EG(function_table) = CG(function_table); I dump out any non-internal functions in the function_table I shouldn't find any (as no script page has been loaded yet in that thread). That's how it works when my main page loads, but when the second page load happens the functions from the first page show up in the function_table for the second! Once one of the threads releases it's local functions, the other still believes they are valid and tries to release them also creating quite a mess. Is there any legitimate way this could happen? I'm pretty much at the end of my ability to debug much deeper into the Zend Engine code and still be able to understand what's going on, but this looks really odd to me. Michael Sisolak [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Thread safety failure in EG(function_table)?
I believe that I can reproduce a thread safety failure in init_executor (as called from the ISAPI sapi). I have a PHP script page that loads the stylesheet as a PHP page - thus causing two almost simultaneous page loads. I assume that if in init_executor() directly after EG(function_table) = CG(function_table); I dump out any non-internal functions in the function_table I shouldn't find any (as no script page has been loaded yet in that thread). That's how it works when my main page loads, but when the second page load happens the functions from the first page show up in the function_table for the second! Once one of the threads releases it's local functions, the other still believes they are valid and tries to release them also creating quite a mess. I believe I have tracked this down to an issue in the threading model of ISAPI applications vs. what the thread safe PHP is expecting. I've followed up in the thread ISAPI Crash Debugging Notes. Michael Sisolak [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Requests for 4.2.3
I believe that the following three patches should be included in 4.2.3: - etc/com/conversion.c, version 1.46 to fix bug #14353 (http://cvs.php.net/co.php/php4/ext/com/conversion.c?r=1.46Horde=0c024469e11792fde7be2067c89cfa6d) - main/sapi.c, version 1.130 to fix bug #16458 (http://cvs.php.net/co.php/php4/main/SAPI.c?r=1.130Horde=0c024469e11792fde7be2067c89cfa6d) - ext/standard/head.c, version 1.56 to fix bug #16626(http://cvs.php.net/co.php/php4/ext/standard/head.c?r=1.56Horde=bf567e33a9e655539c840bf2453f8cfb) My understanding of the CVS versions is that all of these files include only bug fixes since their 4.2.1 version. Michael Sisolak [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Bug #14407: Win32 SendMail function doesn't use From: in SMTP MAIL FROM command
Diff against current HEAD for patch for bug #14407. This allows the
return path to automatically be set to the from address for Win32
sendmail.
Michael Sisolak
[EMAIL PROTECTED]
__
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
--- sendmail.c Tue May 14 10:07:40 2002
+++ sendmail.c.new Tue May 14 10:22:13 2002
@@ -125,11 +125,26 @@
strcpy(MailHost, host);
}
- if (INI_STR(sendmail_from)){
- RPath = estrdup(INI_STR(sendmail_from));
+ /* use from address as return path (if specified in headers) */
+ if (headers strstr(headers, From:)) {
+ char *pos;
+ pos = strstr(headers, From:) + 5;
+ while (pos (*pos == ' '))
+ pos++;
+
+ if (pos strlen(pos)) {
+ RPath = estrdup(pos);
+ RPath[strcspn(RPath, \r\n)] = '\x0';
+ }
+ }
+
+ if (!RPath) {
+ if (INI_STR(sendmail_from)) {
+ RPath = estrdup(INI_STR(sendmail_from));
} else {
*error = W32_SM_SENDMAIL_FROM_NOT_SET;
return FAILURE;
+ }
}
/* attempt to connect with mail host */
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Suggested fix for #16458: header() does not replace headers but always produces duplicates
Bug #16458 reports that the header() command does not correctly use the
replace parameter (i.e., a header of the same name should be replaced
if this parameter is true). The problem is that the standard
sapi_add_header_ex function assumes that the sapi being used with deal
with any header replacements. For Apache that works fine as the Apache
sapi correctly used the replace parameter. The IIS sapi, however,
defaults to the standard funtionality in sapi_add_header_ex (as does
the CGI). The default handler just calls zend_llist_add_element to add
the header to the header list thus appending even if replace was
requested.
Attached is a suggested patch that first removes the header from the
list if it already exists if we are in replace mode. This works for
the Win32 IIS and CGI builds, but I don't have a way to test any
possible interaction this might have with the other sapi modules (or
under GCC).
Michael Sisolak
[EMAIL PROTECTED]
__
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
--- sapi.c Tue May 14 16:11:31 2002
+++ sapi.c.new Tue May 14 16:29:23 2002
@@ -385,6 +385,11 @@
return code;
}
+static int sapi_find_matching_header(void *element1, void *element2)
+{
+ return strnicmp(((sapi_header_struct*)element1)-header, (char*)element2,
+strlen((char*)element2)) == 0;
+}
+
/* This function expects a *duplicated* string, that was previously emalloc()'d.
* Pointers sent to this functions will be automatically freed by the framework.
*/
@@ -551,6 +556,19 @@
zend_llist_clean(SG(sapi_headers).headers);
}
if (retval SAPI_HEADER_ADD) {
+ /* in replace mode first remove the header if it already exists in the
+headers llist */
+ if (replace) {
+ colon_offset = strchr(header_line, ':');
+ if (colon_offset) {
+ char sav;
+ colon_offset++;
+ sav = *colon_offset;
+ *colon_offset = 0;
+ zend_llist_del_element(SG(sapi_headers).headers,
+header_line, (int(*)(void*, void*))sapi_find_matching_header);
+ *colon_offset = sav;
+ }
+ }
+
zend_llist_add_element(SG(sapi_headers).headers, (void *)
sapi_header);
}
if (free_header) {
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Quick CVS Request for 4.2.1RC1
If someone with CVS access would make the quick patches to the COM extension described in these two bug reports for 4.2.1RC1 it would really clean up all the Win32 codepage stuff: #16767 - 4.2.0 broke setting the codepage when you don't also set a remote server #14353 - can't set CP_UTF8 codepage (I doubt this has ever worked) Thanks. __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 4.2.0 SID set login reversed, SID broken
The logic in 4.2.0 to decide when to set the SID constant (which should
be only when the cookie hasn't been set) is reversed. In
ext\session\session.c on line 933:
/* define SID always, if the client did not send a cookie */
if (send_cookie) {
smart_str var = {0};
smart_str_appends(var, PS(session_name));
smart_str_appendc(var, '=');
smart_str_appends(var, PS(id));
smart_str_0(var);
REGISTER_STRING_CONSTANT(SID, var.c, 0);
} else {
REGISTER_STRING_CONSTANT(SID, empty_string, 0);
}
The if statement should be if !send_cookie. The 4.2.0 release sets
the SID when it shouldn't, and doesn't set it when it's needed. :-(
Michael
__
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
