#26906 [NEW]: strlen returns values for non string types

[scottmacvicar at ntlworld dot com]

From: scottmacvicar at ntlworld dot com
Operating system: All
PHP version:  4CVS-2004-01-14 (stable)
PHP Bug Type: Scripting Engine problem
Bug description:  strlen returns values for non string types

Description:

strlen will return a value for boolean types as well as a consitent value
of 5 for an array.

Reproduce code:
---


Expected result:

string foo = int(3)
bool true = int(-1)
bool false = int(-1)
array('foo', 'bar') = int(-1)

Actual result:
--
string foo = int(3)
bool true = int(1)
bool false = int(0)
array('foo', 'bar') = int(5)

-- 
Edit bug report at http://bugs.php.net/?id=26906&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=26906&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=26906&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=26906&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=26906&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26906&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=26906&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=26906&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26906&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=26906&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26906&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26906&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=26906&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26906&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=26906&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=26906&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26906&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26906&r=float

#26906 [Opn]: strlen returns values for non string types

[scottmacvicar at ntlworld dot com]

 ID:   26906
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: All
 PHP Version:  4CVS-2004-01-14 (stable)
 New Comment:

Patch

diff -u zend_builtin_functions.c zend_builtin_functions.c.patched
--- zend_builtin_functions.c2003-08-28 18:06:52.0 +0100
+++ zend_builtin_functions.c.patched2004-01-14 17:46:02.0
+
@@ -260,6 +260,16 @@
if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &str) ==
FAILURE) {
ZEND_WRONG_PARAM_COUNT();
}
+   switch((*str)->type) {
+   case IS_LONG:
+   case IS_DOUBLE:
+   case IS_STRING:
+   break;
+   default:
+   zend_error(E_WARNING, "Variable passed to
strlen() is not a string or number");
+   RETURN_LONG(-1);
+   break;
+   }
convert_to_string_ex(str);
RETVAL_LONG((*str)->value.str.len);
 }


Previous Comments:


[2004-01-14 13:24:49] scottmacvicar at ntlworld dot com

Description:

strlen will return a value for boolean types as well as a consitent
value of 5 for an array.

Reproduce code:
---


Expected result:

string foo = int(3)
bool true = int(-1)
bool false = int(-1)
array('foo', 'bar') = int(-1)

Actual result:
--
string foo = int(3)
bool true = int(1)
bool false = int(0)
array('foo', 'bar') = int(5)





-- 
Edit this bug report at http://bugs.php.net/?id=26906&edit=1

#26906 [Bgs]: strlen returns values for non string types

[scottmacvicar at ntlworld dot com]

 ID:   26906
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: All
 PHP Version:  4CVS-2004-01-14 (stable)
 New Comment:

Indeed PHP is a typeless language and the convert_to_string_ex(str);
attempts to convert an invalid value to a string.

A similar change to this was made in PHP 5 regarding array_merge which
would cause a Warning if a non array type was used as a parameter and I
feel that a likewise change would be of benefit.


Previous Comments:


[2004-01-14 13:52:08] [EMAIL PROTECTED]

As PHP is a typeless language, this behaviour is expected. Please take
a look at this extended version of your script:

var_dump((string)'foo', strlen('foo')); // 3
var_dump((string)true, strlen(true)); // 1
var_dump((string)false, strlen(false)); // 0
var_dump((string)array('foo', 'bar'), strlen(array('foo', 'bar'))); //
5


----------------

[2004-01-14 13:25:53] scottmacvicar at ntlworld dot com

Patch

diff -u zend_builtin_functions.c zend_builtin_functions.c.patched
--- zend_builtin_functions.c2003-08-28 18:06:52.0 +0100
+++ zend_builtin_functions.c.patched2004-01-14 17:46:02.0
+
@@ -260,6 +260,16 @@
if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &str) ==
FAILURE) {
ZEND_WRONG_PARAM_COUNT();
}
+   switch((*str)->type) {
+   case IS_LONG:
+   case IS_DOUBLE:
+   case IS_STRING:
+   break;
+   default:
+   zend_error(E_WARNING, "Variable passed to
strlen() is not a string or number");
+   RETURN_LONG(-1);
+   break;
+   }
convert_to_string_ex(str);
RETVAL_LONG((*str)->value.str.len);
 }

----------------

[2004-01-14 13:24:49] scottmacvicar at ntlworld dot com

Description:

strlen will return a value for boolean types as well as a consitent
value of 5 for an array.

Reproduce code:
---


Expected result:

string foo = int(3)
bool true = int(-1)
bool false = int(-1)
array('foo', 'bar') = int(-1)

Actual result:
--
string foo = int(3)
bool true = int(1)
bool false = int(0)
array('foo', 'bar') = int(5)





-- 
Edit this bug report at http://bugs.php.net/?id=26906&edit=1

#26653 [Com]: open_basedir bug

[scottmacvicar at ntlworld dot com]

 ID:   26653
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  eddyleo777 at hotmail dot com
 Status:   Verified
 Bug Type: *Directory/Filesystem functions
 Operating System: Win32
 PHP Version:  4CVS, 5CVS
 New Comment:

When the value in php.ini has no trailing slash or a slash which
differs from the value of PHP_DIR_SEPARATOR the condition on line 135
against the path fails, causing the function not to add the trailing
slash to the resolved_basedir value.

I also noticed that if the condition was to work it would only append /
to the resolved_basedir / resolved_name when it should in fact append
PHP_DIR_SEPARATOR.

Patch
---
diff -u fopen_wrappers.c fopen_wrappers.c.patched
--- fopen_wrappers.c2004-02-09 22:47:35.0 +
+++ fopen_wrappers.c.patched2004-02-09 22:49:14.0 +
@@ -132,15 +132,15 @@
if ((expand_filepath(path, resolved_name TSRMLS_CC) != NULL) &&
(expand_filepath(local_open_basedir, resolved_basedir TSRMLS_CC) !=
NULL)) {
/* Handler for basedirs that end with a / */
resolved_basedir_len = strlen(resolved_basedir);
-   if (basedir[strlen(basedir)-1] == PHP_DIR_SEPARATOR &&
resolved_basedir[resolved_basedir_len -1] != PHP_DIR_SEPARATOR) {
-   resolved_basedir[resolved_basedir_len] = '/';
+   if (resolved_basedir[resolved_basedir_len -1] !=
PHP_DIR_SEPARATOR) {
+   resolved_basedir[resolved_basedir_len] =
PHP_DIR_SEPARATOR;
resolved_basedir[++resolved_basedir_len] =
'\0';
}
 
if (path[strlen(path)-1] == PHP_DIR_SEPARATOR) {
resolved_name_len = strlen(resolved_name);
if (resolved_name[resolved_name_len - 1] !=
PHP_DIR_SEPARATOR) {
-   resolved_name[resolved_name_len] =
'/';
+   resolved_name[resolved_name_len] =
PHP_DIR_SEPARATOR;
resolved_name[++resolved_name_len] =
'\0';
}
}


Previous Comments:


[2003-12-17 12:12:44] eddyleo777 at hotmail dot com

Description:

test.php


php.ini
open_basedir = "c:\apache\user\" ;work
open_basedir = "c:/apache/user" ;it does not work
open_basedir = "c:/apache/user/" ;it does not work


Reproduce code:
---
php4-200312171430/main/fopen_wrappers.c on line 133

/* Handler for basedirs that end with a / */
if (basedir[strlen(basedir)-1] == PHP_DIR_SEPARATOR) {
  resolved_basedir_len = strlen(resolved_basedir);
  resolved_basedir[resolved_basedir_len] = '/';
  resolved_basedir[++resolved_basedir_len] = '\0';
} else {
  resolved_basedir_len = strlen(resolved_basedir);  
}

if (path[strlen(path)-1] == PHP_DIR_SEPARATOR) {
  resolved_name_len = strlen(resolved_name);
  resolved_name[resolved_name_len] = '/';
  resolved_name[++resolved_name_len] = '\0';
}


Expected result:

the introduced solution not work.
interpret this possible solution please.

php4-200312171430/main/fopen_wrappers.c on line 133

/* Handler for basedirs that end with a / */
if (???is_dir???(resolved_basedir)) {
  resolved_basedir_len = strlen(resolved_basedir);
  resolved_basedir[resolved_basedir_len] =PHP_DIR_SEPARATOR;
  resolved_basedir[++resolved_basedir_len] = '\0';
} else {
  resolved_basedir_len = strlen(resolved_basedir);
}

if (???is_dir???(resolved_name)) {
  resolved_name_len = strlen(resolved_name);
  resolved_name[resolved_name_len] = PHP_DIR_SEPARATOR;
  resolved_name[++resolved_name_len] = '\0';
}







-- 
Edit this bug report at http://bugs.php.net/?id=26653&edit=1

#26862 [Com]: ob_flush() doesn't output last two chars

[scottmacvicar at ntlworld dot com]

 ID:   26862
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  nunoplopes at sapo dot pt
 Status:   Verified
 Bug Type: Output Control
 Operating System: *
 PHP Version:  4CVS, 5CVS
 New Comment:

I think i've tracked this one down to the URL parser, it happens when
the argument do_flush is set to false for url_adapt_ext
(url_scanner_ex.c line 837) this is because it only expects to do the
re-write at the final flush.

I modified what was passed in to accept the final flush or a flush
halfway through the script execution.

Patch
---
diff -u url_scanner_ex.c url_scanner_ex.c.patched
--- url_scanner_ex.c2004-02-10 01:29:05.0 +
+++ url_scanner_ex.c.patched2004-02-10 01:30:51.0 +
@@ -918,7 +918,8 @@
size_t len;
 
 if (BG(url_adapt_state_ex).url_app.len != 0) {
-*handled_output = url_adapt_ext(output, output_len, &len,
(zend_bool) (mode&PHP_OUTPUT_HANDLER_END ? 1 : 0) TSRMLS_CC);
+*handled_output = url_adapt_ext(output, output_len, &len,
(zend_bool) ((mode & PHP_OUTPUT_HANDLER_CONT) || (mode 
+& PHP_OUTPUT_HANDLER_END) ? 1 : 0) TSRMLS_CC);
if (sizeof(uint) < sizeof(size_t)) {
if (len > UINT_MAX)
len = UINT_MAX;


Previous Comments:


[2004-01-22 10:48:57] nunoplopes at sapo dot pt

I've checked the sources and if you changed the implementation of
ob_flush everything works:

use this:
php_end_ob_buffer(1, 0 TSRMLS_CC);
instead of:
php_end_ob_buffer(1, 1 TSRMLS_CC);

So, the error is in just_flush in php_end_ob_buffer().



[2004-01-10 11:42:24] nunoplopes at sapo dot pt

Description:

When using the given code, ob_flush() doesn't output all the buffer.
When using ob_get_flush() it works as expected.

Reproduce code:
---
link';

ob_flush();

output_reset_rewrite_vars();
echo 'link';
?>

Expected result:

linklink

Actual result:
--
linklink





-- 
Edit this bug report at http://bugs.php.net/?id=26862&edit=1

#23467 [Com]: Showing incorrect Time Zone

[scottmacvicar at ntlworld dot com]

 ID:   23467
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  John at JGSystems dot net
 Status:   Verified
 Bug Type: Date/time related
 Operating System: win32
 PHP Version:  4CVS, 5CVS
 New Comment:

tname[0] is replaced with tzname[0] if it exists, the same should be
done with tname[1] but it doesn't need set to ??? like tname[0] since
the default value is BST set in the tname declaration.

I've tested this patch on windows and will try to test on linux.

Patch
---
diff -u datetime.c datetime.c.patched
--- datetime.c  2004-02-10 12:30:17.0 +
+++ datetime.c.patched  2004-02-10 12:32:12.0 +
@@ -324,6 +324,10 @@
} else {
tname[0] = "???";
}
+
+   if (tzname[1] != NULL) {
+   tname[1] = tzname[1];
+   }
 #endif
}


Previous Comments:


[2003-11-04 21:18:38] danielc at analysisandsolutions dot com

Um, sorry if I'm cluttering the list...  This bug is half a year old so
I'm wondering if/when it's going to get fixed.

Y'all probably know what's going on, but allow me to clarify what I've
learned about this bug, perhaps it will help someone.

date('T') doesn't work under Windows during Daylight times and there's
no notation of this in the manual.  I'll put a user comment in there.

Here's a test script:

";
putenv('TZ=EST5EDT');
echo 'EST5EDT:   dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');

echo "\n";
putenv('TZ=PST8PDT');
echo 'PST8PDT:   dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');

echo "\n";
putenv('TZ=GMT0BST');
echo 'GMT0BST:   dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');

echo "\n";
putenv('TZ=MST-3MDT');
echo 'MST-3MDT:  dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');

echo "\n";
putenv('TZ=GMT');
echo 'GMT:   dT='.date('T') . ' dO='.date('O') . '
sZ='.strftime('%Z');
?>


OUTPUT DURING EASTERN DAYLIGHT TIME
---
Local: dT=BST dO=-0400 sZ=Eastern Daylight Time
EST5EDT:   dT=BST dO=-0400 sZ=EDT
PST8PDT:   dT=BST dO=-0700 sZ=PDT
GMT0BST:   dT=BST dO=+0100 sZ=BST
MST-3MDT:  dT=BST dO=+0400 sZ=MDT
GMT:   dT=GMT dO=+ sZ=GMT

OUTPUT DURING EASTERN STANDARD TIME
---
Local: dT=Eastern Standard Time dO=-0500 sZ=Eastern Standard Time
EST5EDT:   dT=EST dO=-0500 sZ=EST
PST8PDT:   dT=PST dO=-0800 sZ=PST
GMT0BST:   dT=GMT dO=+ sZ=GMT
MST-3MDT:  dT=MST dO=+0300 sZ=MST
GMT:   dT=GMT dO=+ sZ=GMT



[2003-08-26 22:59:32] [EMAIL PROTECTED]

This is general win32 problem. No need to post anymore comments here,
we know about it.




[2003-08-20 20:35:39] John at JGSystems dot net

Here ya go:
Commands:
echo date("r"),"\n";
echo date("I"),"\n";  // uppercase "i"
echo date("T"),"\n";

Result:
Wed, 20 Aug 2003 19:33:34 -0600
1
BST

This what you wanted? (I hope)



[2003-05-03 12:14:00] John at JGSystems dot net

Running PHP with BadBlue on Two machines.  One Win2K Pro, the other XP
SPK1.  Also on a Linux Apache production machine.

"T" Option to the date function appears to display incorrectly.  Shows
Mountain Standard Time all the time.  It is now Daylight Savings Time
here in Montana.

Script:

php print "This page was last modified:".date("l - F d, Y \\a\\t
g:i A T.", getlastmod())

Under my Apache servers PHP displays correctly.  I use this for the
getlastmod() document function.  Here is a copy/paste from the same
page on two different servers.

Linux Apache (Production Machine):

This page was last modified:
Friday - April 25, 2003 at 11:30 AM MDT.

Windows 2K/XP:

This page was last modified:
Friday - April 25, 2003 at 11:30 AM Mountain Standard Time. 

This also happens with a simple date printout:

php print "This page was last modified:".date("l - F d, Y \\a\\t
g:i A T.")

Saturday - May 03, 2003 at 11:09 AM Mountain Standard Time.

Hope this helps.




-- 
Edit this bug report at http://bugs.php.net/?id=23467&edit=1

#23220 [Com]: fgets() causes warning while reading data via SSL channel (HTTPS)

[scottmacvicar at ntlworld dot com]

 ID:   23220
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  storozhilov at mail dot ru
 Status:   Assigned
 Bug Type: Filesystem function related
 Operating System: *
 PHP Version:  4CVS
 Assigned To:  wez
 New Comment:

Found the cause of this now.



Its Microsoft's we can do what we want attituide in regards to IIS.



An EOF occured but the SSL "close_notify" message hasn't been sent.



I'll write a patch and post it tomorrow hopefully.


Previous Comments:


[2004-02-16 17:00:49] aaron_hawryluk at shaw dot ca

This also seems to cause a problem with file_get_contents which I am
using to retrieve transaction data.  Test case is:

https://any.secure.server";);

?>

returns:

Warning: file_get_contents(): SSL: fatal protocol error in
/usr/local/www/data-dist/navdev/test.php on line 2



...plus whatever data the secure server provides.



[2004-02-12 16:15:31] wtatam at premierit dot com

If you apply the patch shown in this script it works perfectly



Why has this not been commited into the main branch for both php 4 and
5 ?



[2004-02-04 18:48:37] douga at accessdata dot com

I am seeing the same error. It appears to be generated after the
following loop has completed. More specifically, the Warning message is
emitted just after the loop terminates.



while( !feof($handle) )

{

   echo "Looping to read in all of the reply.";

   $reply .= fgets($handle);

}



PHP 4.3.4 compiled with --with-openssl



What other information would be helpful?



[2004-01-27 12:58:26] admin at jazzfanz dot com

I'm sorry but I can't really tell based on this thread if there was
ever a version of PHP where this problem was corrected.  Is there a
version?



I'm on 4.3.3 currently under IPlanet.



Is there a workaround without using cURL?



[2004-01-12 06:42:19] [EMAIL PROTECTED]

Keep it assigned to the only person who can fix it..





The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/23220

-- 
Edit this bug report at http://bugs.php.net/?id=23220&edit=1

#23220 [Com]: fgets() causes warning while reading data via SSL channel (HTTPS)

[scottmacvicar at ntlworld dot com]

 ID:   23220
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  storozhilov at mail dot ru
 Status:   Assigned
 Bug Type: Filesystem function related
 Operating System: *
 PHP Version:  4CVS
 Assigned To:  wez
 New Comment:

Since this indeed an error but it will happen anytime you make an HTTPS
request to IIS i think the error should be changed to E_NOTICE and the
error message updated to what it actually does.



Patch

---

diff -u network.c network.c.patched

--- network.c   2004-02-17 01:20:49.0 +

+++ network.c.patched   2004-02-17 01:22:23.0 +

@@ -870,8 +870,8 @@

case SSL_ERROR_SYSCALL:

if (ERR_peek_error() == 0) {

if (nr_bytes == 0) {

-   php_error_docref(NULL
TSRMLS_CC, E_WARNING,

-   "SSL: fatal
protocol error");

+   php_error_docref(NULL
TSRMLS_CC, E_NOTICE,

+   "SSL: EOF
occurred in violation of protocol");

stream->eof = 1;

retry = 0;

} else {


Previous Comments:


[2004-02-16 19:58:27] scottmacvicar at ntlworld dot com

Found the cause of this now.



Its Microsoft's we can do what we want attituide in regards to IIS.



An EOF occured but the SSL "close_notify" message hasn't been sent.



I'll write a patch and post it tomorrow hopefully.



[2004-02-16 17:00:49] aaron_hawryluk at shaw dot ca

This also seems to cause a problem with file_get_contents which I am
using to retrieve transaction data.  Test case is:

https://any.secure.server";);

?>

returns:

Warning: file_get_contents(): SSL: fatal protocol error in
/usr/local/www/data-dist/navdev/test.php on line 2



...plus whatever data the secure server provides.



[2004-02-12 16:15:31] wtatam at premierit dot com

If you apply the patch shown in this script it works perfectly



Why has this not been commited into the main branch for both php 4 and
5 ?



[2004-02-04 18:48:37] douga at accessdata dot com

I am seeing the same error. It appears to be generated after the
following loop has completed. More specifically, the Warning message is
emitted just after the loop terminates.



while( !feof($handle) )

{

   echo "Looping to read in all of the reply.";

   $reply .= fgets($handle);

}



PHP 4.3.4 compiled with --with-openssl



What other information would be helpful?



[2004-01-27 12:58:26] admin at jazzfanz dot com

I'm sorry but I can't really tell based on this thread if there was
ever a version of PHP where this problem was corrected.  Is there a
version?



I'm on 4.3.3 currently under IPlanet.



Is there a workaround without using cURL?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/23220

-- 
Edit this bug report at http://bugs.php.net/?id=23220&edit=1

#26238 [Com]: flush() doesn't work with output_buffering = 4096

[scottmacvicar at ntlworld dot com]

 ID:   26238
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  spam at vrana dot cz
 Status:   Verified
 Bug Type: Output Control
 Operating System: *
 PHP Version:  4CVS, 5CVS
 New Comment:

Setting output_buffering to a value causes it to create an ouput buffer
on startup using the default output handler. You can see this using
print_r(ob_get_status()); within the script.



ob_flush() should be used in this case rather than flush() since the
latter only calls the backends flush method. So i believe this bug is
bogus, though it could be a documentation problem.


Previous Comments:


[2004-02-18 17:19:31] [EMAIL PROTECTED]

Here's nice and short reproduce script:



# php -d'output_buffering=2' -r 'while(1) {echo "."; flush(); sleep(1);
}'







[2003-11-17 13:14:20] scottm at spamcop dot net

Confirmed.



If you set output_buffering = 3 then it will flush them in groups of
three.



Running RH9, Apache 1.3.29 and PHP 4.3.4



[2003-11-13 08:40:59] spam at vrana dot cz

Description:

I have set output_buffering = 4096 and flush(), ob_implicit_flush(),
ob_flush() and similar functions doesn't work. This is reproducible in
PHP Apache module, in PHP-CLI and also on Linux.

Reproduce code:
---
while (true) {

echo ".";

flush();

sleep(1);

}



Expected result:

. (1 second) . (1 second) ...

Actual result:
--
nothing (for output_buffering seconds)





-- 
Edit this bug report at http://bugs.php.net/?id=26238&edit=1

#27327 [Com]: Problem with 2004-03-28 (summer time conversion)

[scottmacvicar at ntlworld dot com]

 ID:   27327
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  timo at reflection-metal dot de
 Status:   Open
 Bug Type: Date/time related
 Operating System: Suse, RedHat, WinXP, W2K
 PHP Version:  4.3.4
 New Comment:

Can't confirm this under RH9 and Windows XP using PHP 4.3.5RC3. There
was a few timezone bug fixes could you try a snapshot from
http://snaps.php.net



What timezone was your server running in? I was running them in GMT.


Previous Comments:


[2004-02-21 12:14:46] timo at reflection-metal dot de

Hi Sniper,

thanks for your advice... But shouldn't the daylight saving return 1
instead of 2 hours difference?



[2004-02-20 04:16:57] [EMAIL PROTECTED]

We are happy to tell you that you just discovered Daylight Savings
Time. For more information see:
http://webexhibits.org/daylightsaving/b.html
Instead of using mktime/date consider using gmmktime and gmdate which
do
not suffer from DST.





[2004-02-20 03:41:56] timo at reflection-metal dot de

Just found out that this bug is a problem with summer time conversion.
You could check out e.g. 2003-03-30...

In addition:

If you subtract 1 minute from '2004-03-28 03:00:00' it results in
'2004-03-28 03:59:00'



[2004-02-20 02:53:44] timo at reflection-metal dot de

Description:

The mktime function gives strange results when adding something that
results between '2004-03-28 01:00:00' and '2004-03-28 01:01:00'.

Reproduce code:
---
$STTDate = strToTime('2004-03-28 00:30:00');



$StrangeDate = date('Y-m-d H:i:s',
mktime(date('H',$STTDate),date('i',$STTDate)+30,0,date('m',$STTDate),date('d',$STTDate),date('Y',$STTDate)));



Expected result:

2004-03-28 01:00:00

Actual result:
--
2004-03-28 03:00:00





-- 
Edit this bug report at http://bugs.php.net/?id=27327&edit=1

#26863 [Com]: fgets hangs on some urls

[scottmacvicar at ntlworld dot com]

 ID:   26863
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  jim at bluedojo dot com
 Status:   Assigned
 Bug Type: *Directory/Filesystem functions
 Operating System: *
 PHP Version:  4CVS, 5CVS
 Assigned To:  wez
 New Comment:

If you have a server which is under extreme load and is taking around
30 seconds to respond, results similar to a DoS attack. It appears that
the stream doesn't have a timeout so it simply finishes when
max_execution_time is reached.


Previous Comments:


[2004-01-14 18:04:09] jim at bluedojo dot com

I will try to answer the question the best I can.



I have written a spider in php that can index millions of pages.  Every
once in a while it will encounter a page that will not load up (which I
thought was due to fgets).  When I type this url in the location bar of
a browser, the page seems like it will load forever and nothing will
show up.



When I set stream_set_timeout($fd, 6) then once would expect that $fd
will time out in 6 seconds and exit the loop.  I believe that feof
would detect that the stream would time out:





if ($fd = @fopen($url,'rb')){

   stream_set_timeout($fd, 6);

   $html = '';

   while (!feof($fd)) {

  $html .= trim(fgets($fd));

   }

   fclose($fd);

}



To answer wez's question, I had to find a url that didn't work (that
took forever to load) in order to test that feof would exit due to the
timing out of the stream ($fd).



The url that I was using wasn't working for about one day.  Then it
started to load normally in a browser a day later so I couldn't use it
anymore as a test case for this problem.



Making the stream time out is important for my application because it
needs to move on to the next url or else it will loop forever.



Hope that helps.



[2004-01-12 22:08:56] jim at bluedojo dot com

I think removing feof() solved the problem.  I don't get any infinite
stalls anymore.  Thanks.



[2004-01-10 19:48:26] [EMAIL PROTECTED]

So the URL needs to return a failure code in order

to trigger the problem?

Please as specific as you can about it to help us figure

out whats happening.



[2004-01-10 18:06:17] jim at bluedojo dot com

The url is now working now so I cannot use it as a test case (it needs
to return false).  I will see if I can find a new url to test it with
the new code.



[2004-01-10 17:35:18] [EMAIL PROTECTED]

I suspect the problem to be with feof() rather than fgets().



try this:



do {

   $line = fgets($fp);

   if ($line === false)

  break;

   $html .= trim($line);

} while(true);





The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/26863

-- 
Edit this bug report at http://bugs.php.net/?id=26863&edit=1

#23071 [NEW]: when trying to use the T flag in date it will crash if DST is in operation

[scottmacvicar at ntlworld dot com]

From: scottmacvicar at ntlworld dot com
Operating system: Windows XP
PHP version:  4.3.2RC1
PHP Bug Type: Reproducible crash
Bug description:  when trying to use the T flag in date it will crash if DST is in 
operation

on windows this will crash Apache 2.0.45 using PHP built from this morning.
tname[1] value is BST but tname[0] value is GMT Standard Time.



patch is as follows

--- datetime.c  Sun Feb  9 17:11:00 2003
+++ datetime.c.patched  Sun Apr  6 10:41:52 2003
@@ -540,7 +540,11 @@
 #if HAVE_TM_ZONE
strcat(Z_STRVAL_P(return_value),
ta->tm_zone);
 #elif HAVE_TZNAME
-   strcat(Z_STRVAL_P(return_value),
tname[0]);
+   if (ta->tm_isdst > 0 ) {
+   strcat(Z_STRVAL_P(return_value),
tname[1]);
+   } else {
+   strcat(Z_STRVAL_P(return_value),
tname[0]);
+   }
 #endif
break;
case 'B':   /* Swatch Beat a.k.a. Internet
Time */
-- 
Edit bug report at http://bugs.php.net/?id=23071&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=23071&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=23071&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=23071&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=23071&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=23071&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=23071&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=23071&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=23071&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=23071&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=23071&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=23071&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=23071&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=23071&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=23071&r=gnused

#25701 [NEW]: Calling flush from within an output buffer prevents headers from being sent

[scottmacvicar at ntlworld dot com]

From: scottmacvicar at ntlworld dot com
Operating system: Windows XP SP1
PHP version:  4CVS-2003-09-30 (stable)
PHP Bug Type: Apache2 related
Bug description:  Calling flush from within an output buffer prevents headers from 
being sent

Description:

Calling flush in Apache and Apache 2 produce different results.

Within Apache after calling flush you can still send headers as the output
buffer prevents it from actually being flushed.

Within Apache 2 after calling flush you can no longer send headers even
though headers_sent still returns false.


Reproduce code:
---


Expected result:

test

Actual result:
--
binary data

-- 
Edit bug report at http://bugs.php.net/?id=25701&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25701&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25701&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25701&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25701&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25701&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25701&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25701&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25701&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25701&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25701&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25701&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25701&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25701&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=25701&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25701&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25701&r=float

#25701 [Fbk->Opn]: Calling flush from within an output buffer prevents headers from being sent

[scottmacvicar at ntlworld dot com]

 ID:   25701
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: Windows XP SP1
 PHP Version:  4CVS-2003-09-30 (stable)
 New Comment:

PHP Version 4.3.4RC2-dev

Same result as mentioned above.


Previous Comments:


[2003-09-30 10:19:14] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip



[2003-09-30 09:56:26] scottmacvicar at ntlworld dot com

Description:

Calling flush in Apache and Apache 2 produce different results.

Within Apache after calling flush you can still send headers as the
output buffer prevents it from actually being flushed.

Within Apache 2 after calling flush you can no longer send headers even
though headers_sent still returns false.


Reproduce code:
---


Expected result:

test

Actual result:
--
binary data





-- 
Edit this bug report at http://bugs.php.net/?id=25701&edit=1

#25701 [Bgs]: Calling flush from within an output buffer prevents headers from being sent

[scottmacvicar at ntlworld dot com]

 ID:   25701
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
 Status:   Bogus
 Bug Type: Apache2 related
 Operating System: *
 PHP Version:  4CVS
 New Comment:

Shouldn't headers_sent() return true then?


Previous Comments:


[2003-09-30 18:47:05] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Unlike Apache 1, when Apache 2 recieves a directive to flush it does so
right away sending any pending headers in the process. Since the
headers & text were already sent it cannot send the header indicating
the data that follows in gziped. Due to the missing header you get a
whole bunch of binary data.



[2003-09-30 09:56:26] scottmacvicar at ntlworld dot com

Description:

Calling flush in Apache and Apache 2 produce different results.

Within Apache after calling flush you can still send headers as the
output buffer prevents it from actually being flushed.

Within Apache 2 after calling flush you can no longer send headers even
though headers_sent still returns false.


Reproduce code:
---


Expected result:

test

Actual result:
--
binary data





-- 
Edit this bug report at http://bugs.php.net/?id=25701&edit=1

#25701 [Bgs->Opn]: Calling flush from within an output buffer prevents headers from being sent

[scottmacvicar at ntlworld dot com]

 ID:   25701
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
-Status:   Bogus
+Status:   Open
 Bug Type: Apache2 related
 Operating System: *
 PHP Version:  4CVS
 New Comment:

';
}

echo $newtext;

?>

Based on what you've said above then you shouldn't see 'in here' within
Apache 2.


Previous Comments:


[2003-09-30 19:22:16] scottmacvicar at ntlworld dot com

Shouldn't headers_sent() return true then?



[2003-09-30 18:47:05] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Unlike Apache 1, when Apache 2 recieves a directive to flush it does so
right away sending any pending headers in the process. Since the
headers & text were already sent it cannot send the header indicating
the data that follows in gziped. Due to the missing header you get a
whole bunch of binary data.

----

[2003-09-30 09:56:26] scottmacvicar at ntlworld dot com

Description:

Calling flush in Apache and Apache 2 produce different results.

Within Apache after calling flush you can still send headers as the
output buffer prevents it from actually being flushed.

Within Apache 2 after calling flush you can no longer send headers even
though headers_sent still returns false.


Reproduce code:
---


Expected result:

test

Actual result:
--
binary data





-- 
Edit this bug report at http://bugs.php.net/?id=25701&edit=1

#25717 [Com]: stack over flow

[scottmacvicar at ntlworld dot com]

 ID:   25717
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  net_del at freemail dot ru
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Win32
 PHP Version:  4CVS-2003-10-01 (stable)
 New Comment:

Your sending PHP into an infinite loop.

simplier example is





This report is bogus.


Previous Comments:


[2003-10-01 12:42:47] net_del at freemail dot ru

Description:

This code over flow the apache!

Reproduce code:
---
eval($apache_fuck);
echo("


");

Expected result:

;)while (true) but no error ;P

Actual result:
--
Apache.exe errored





-- 
Edit this bug report at http://bugs.php.net/?id=25717&edit=1

#27424 [NEW]: flush sets SG(headers_sent) to true preventing sapi_send_headers from running

[scottmacvicar at ntlworld dot com]

From: scottmacvicar at ntlworld dot com
Operating system: All
PHP version:  4CVS-2004-02-27 (stable)
PHP Bug Type: Apache2 related
Bug description:  flush sets SG(headers_sent) to true preventing sapi_send_headers 
from running

Description:

If you have zlib.output_compression = On in php.ini and echo some content
then flush under apache 2 then you'll get some binary data due to the lack
of headers.



I've had a look at the code and when you call flush() under Apache 2 it
has



SG(headers_sent) = 1;

sapi_apache2.c line 265



During php_request_shutdown() sapi_send_headers is called to add
appropriate gzip headers.



Within sapi_send_headers there is a check to see if headers have already
been sent. SAPI.c line 701.



I've read previous bug reports on flush and Apache 2 in particular, bug
#25701. Ilia mentions that Apache 2 and Apache 1 behave differently, on
flush Apache 2 sends any pending headers but in this case the gzip headers
haven't been added yet.



I can see two ways to handle this,

Disable zlib.output_compression if flush is called

or

Make flush do nothing if zlib.output_compression is enabled


-- 
Edit bug report at http://bugs.php.net/?id=27424&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27424&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27424&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27424&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27424&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27424&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27424&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27424&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27424&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27424&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27424&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27424&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27424&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27424&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27424&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27424&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27424&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27424&r=float

#22127 [Com]: bogus http response when force-cgi-redirect safety mechanism triggered

[scottmacvicar at ntlworld dot com]

 ID:   22127
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  zlo at canada dot com
 Status:   Verified
 Bug Type: CGI related
 Operating System: *
 PHP Version:  4CVS, 5CVS
 New Comment:

403 is probably the most appropriate response code.

Though 400 Bad Request could be another possibility.



http://www.w3.org/Protocols/HTTP/HTRESP.html



patch

---

diff -u cgi_main.c cgi_main.c.patched

--- cgi_main.c  2004-02-28 14:53:31.0 +

+++ cgi_main.c.patched  2004-02-28 14:54:16.0 +

@@ -1106,6 +1106,7 @@

in case some server does something
different than above */

&& (!redirect_status_env ||
!getenv(redirect_status_env))

) {

+   SG(sapi_headers).http_response_code = 403;

PUTS("Security Alert! The PHP CGI cannot
be accessed directly.\n\n\

 This PHP CGI binary was compiled with force-cgi-redirect enabled. 
This\n\

 means that a page will only be served up if the REDIRECT_STATUS CGI
variable is\n\


Previous Comments:


[2003-08-08 06:16:21] [EMAIL PROTECTED]

Still a problem with both PHP4/PHP5.





[2003-03-30 15:45:43] zlo at canada dot com

using the latest build:

# HEAD http://mysite/cgi-bin/php/pi.php

500 Bad response code: 'HTTP/1.1 0'



[2003-03-30 06:44:32] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2003-02-08 14:46:41] zlo at canada dot com

When php is used in cgi mode with force-cgi-redirect enabled, and the
safety mechanism is triggered, PHP produces a bogus http response
line:

HTTP/1.1 0

this is invalid and browsers fail to display the output.

it happens for PHP 4.3.0 and a fresh PHP 4.3.1-dev snapshot under both
Windows and Linux.

AFAIK 0 is not a valid response code, and unless one uses a
non-compliant browser or accesses the page through a raw telnet
session, the warning page cannot be seen.

it would be desirable for PHP to produce a meaningful response code,
such as 200, 403 or 500.

for example:



GET /cgi-bin/php/pi.php HTTP/1.1

HOST: mysite



HTTP/1.1 0

Date: Sat, 08 Feb 2003 20:32:46 GMT

Server: Apache/1.3.27 (Unix) PHP/4.3.0

Transfer-Encoding: chunked

Content-Type: text/html; charset=windows-1251



283

Security Alert! The PHP CGI cannot be accessed directly.



This PHP CGI binary was compiled with force-cgi-redirect enabled. 
This

means that a page will only be served up if the REDIRECT_STATUS CGI
variable is

set, e.g. via an Apache Action directive.

For more information as to why this behaviour exists, see the
http://php.net/security.cgi-bin";>manual page for CGI
security.

For more information about changing this behaviour or re-enabling
this webserver,

consult the installation file that came with this distribution, or
visit

http://php.net/install.windows";>the manual page.



0






-- 
Edit this bug report at http://bugs.php.net/?id=22127&edit=1

#27501 [Com]: not possible to load extensions without "zend_list_find" entry point error

[scottmacvicar at ntlworld dot com]

 ID:   27501
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  pseudonym1972 at hotmail dot com
 Status:   Open
 Bug Type: Zend Engine 2 problem
 Operating System: XP pro IIS 5
 PHP Version:  4.3.4
 New Comment:

Are you sure php_gd.dll exists? as far as i'm aware it should be
php_gd2.dll


Previous Comments:


[2004-03-04 19:06:08] pseudonym1972 at hotmail dot com

Description:

The sad story..

I downloaded and installed php from the windows installer.  Then I
added the extensions directory one gets when they download the php zip
package.

The php.ini file was modified to use the extensions directory like so,
extension_dir = "C:\PHP\extensions"

Finally I attempt to get php to use one.

extension=php_gd.dll



I am reading that there are issues like this around, and that most of
them are related to a bad install usually by mixing binary versions.

This is a fresh install. I have done nothing but installed php and seen
it echo "hello" on a test page.

Reproduce code:
---
I attempt to view the modules by command line, c:\php/php -m

Expected result:

PHP 4.3.4 (cli) (built: Nov  2 2003 23:47:34)

Copyright (c) 1997-2003 The PHP Group

Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies



Actual result:
--
an error message pops up saying 

"The procedure entry point zend_list_find could not be located in the
dynamic link library php4ts.dll." The php_gd.dll isn't loaded.





-- 
Edit this bug report at http://bugs.php.net/?id=27501&edit=1

#27509 [Com]: fsockopen() failed with "Addr family not supported by protocol" error

[scottmacvicar at ntlworld dot com]

 ID:   27509
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  scott at abcoa dot com
 Status:   Open
 Bug Type: Sockets related
 Operating System: AIX 4.3.3
 PHP Version:  4.3.4
 New Comment:

Should be tcp:// not tcp:\\ since \ is an escape character and will end
up being evaluated to tcp:\



How about a local IP do they work?


Previous Comments:


[2004-03-05 17:59:13] scott at abcoa dot com

Description:

I had no trouble with the fsockopen() until I upgraded to PHP 4.3.4. 
My last working version was 4.2.3 before the upgrade.  It sure look
like a fsockopen() issue.  Enclosed below is the source code that
produce the same error result with both the Apache/Browser and the
Shell Environment.  I tried variety of URL Address and still get the
same result, like www.google.com, www.cnn.com, www.php.net, etc... 
Been trying different ways with the scripts, machine and network and
yet get the same result.  I tried with and without the "tcp:\\" and
still get the same result.  (One more thing, could error 66 meant 6
with an one digit, not two??)

Reproduce code:
---


Expected result:

Should expect to see an successful connection to www.google.com

Actual result:
--
Warning: fsockopen() [http://www.php.net/function.fsockopen]:
php_hostconnect: connect failed in <> on line
5



Warning: fsockopen() [http://www.php.net/function.fsockopen]: unable to
connect to www.google.com:80 in <> on line 5





66



Addr family not supported by protocol







-- 
Edit this bug report at http://bugs.php.net/?id=27509&edit=1

#27490 [Com]: system function produces garbage with zlib.output_copmression

[scottmacvicar at ntlworld dot com]

 ID:   27490
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  mortoray at ecircle-ag dot com
 Status:   Feedback
 Bug Type: Zlib Related
 Operating System: Windows NT 5.0 build 219
 PHP Version:  4.3.4
 New Comment:

Duplicate of http://bugs.php.net/bug.php?id=27424



In the case of apache2 sapi_flush sends any pending headers and
prevents any further headers being sent unlike Apache 1.



Call to sapi_flush is within php_Exec on line 247 in
ext/standard/exec.c


Previous Comments:


[2004-03-05 18:52:01] [EMAIL PROTECTED]

Does it work if you set the header yourself with:

header('Content-Encoding: gzip');



?



regards,

Derick



[2004-03-04 04:11:45] mortoray at ecircle-ag dot com

Description:

Using the zlib.output_compression=On and the function system() produces
garbage output to the browser.  Specifically, it does a gzip encoding
but omits the "Content-Encoding: gzip" header.



Using "passthru" instead of "system" works as intended.



Turning off compression and using "system" works as intended.

Reproduce code:
---


Expected result:

Either system() should somehow turn off the zlib compression or its
output should be compressed properly and the proper headers should be
set.



--TCP Flow with passthru()--

GET /dir.php HTTP/1.0

Host: qatest.ecircle.de:8080

Accept: text/*, image/jpeg, image/png, image/*, */*

Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5

Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity

Accept-Language: en

User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux; en_US, en)



HTTP/1.1 200 OK

Date: Thu, 04 Mar 2004 09:12:41 GMT

Server: Apache/2.0.45 (Win32) PHP/4.3.4

X-Powered-By: PHP/4.3.4

Content-Encoding: gzip

Vary: Accept-Encoding

Connection: close

Content-Type: text/html; charset=ISO-8859-1



...S=O.0..+.?...X.J.-..dAbb`...kk5q...e..sm.

m"q.{.C.5c...1,!..b

}.MYb.p{..Ks.x_x.25..!..5..I.5..._..?.."a\.B|..ji...Iw..*i.[yE..

.-.~N.W.'.Xmy).7V.n.,sE.yer.I||...c..4...?f...Y.gWh!..h.);?.v...O.:H.A1...U6.^..6..z...d..g...5..nz.M.XWaM..o%...>..7

..5.cy6.K.aB..f..p.

..`...

...



Actual result:
--
--TCP Flow with system()--



GET /dir.php HTTP/1.0

Host: qatest.ecircle.de:8080

Accept: text/*, image/jpeg, image/png, image/*, */*

Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5

Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity

Accept-Language: en

Cache-control: no-cache

Pragma: no-cache

User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux; en_US, en)



HTTP/1.1 200 OK

Date: Thu, 04 Mar 2004 09:13:45 GMT

Server: Apache/2.0.45 (Win32) PHP/4.3.4

X-Powered-By: PHP/4.3.4

Connection: close

Content-Type: text/html; charset=ISO-8859-1



...S.n.0..#..{..X.J.\*..CO\...E..B"un.c...Ma..hA.x.+.r.nUO..2.!..U..F...".'.o...h.$...:.9.L..u`q...$.

@.Pxp.sW..3.*|...*B...t.)H..,S.vK..*.J..A.gYn..T.$L.=...8..Q.I{..7X.]A..)M,..g3<.=^_0.uZZ..^.#..M..L.wPL).N.V.!;..Al!o.(Q)k3.O.u.5..
..i.OM.$N.q.K4  >[EMAIL PROTECTED]|{...P.0...>..6...
%.78n.~..C

...





-- 
Edit this bug report at http://bugs.php.net/?id=27490&edit=1

#27513 [Com]: strrpos() using the offset

[scottmacvicar at ntlworld dot com]

 ID:   27513
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  asterisk at email dot it
 Status:   Open
 Bug Type: Strings related
 Operating System: windows xp
 PHP Version:  4.3.4
 New Comment:

http://www.php.net/strrpos



Quote from that page

---

Note: As of PHP 5.0.0 offset may be specified to begin searching an
arbitrary number of characters into the string. Negative values will
stop searching at an arbitrary point prior to the end of the string. 

---



Your using PHP4 hence the error


Previous Comments:


[2004-03-06 12:10:31] asterisk at email dot it

Description:

when is used 3rd parameter, the offset, the function produce a warning
and don't return nothing

Reproduce code:
---


Expected result:

1

Actual result:
--
Warning: Wrong parameter count for strrpos() in C:\WWW\strrpos.php on
line 4





-- 
Edit this bug report at http://bugs.php.net/?id=27513&edit=1

#27490 [Com]: system function produces garbage with zlib.output_copmression

[scottmacvicar at ntlworld dot com]

 ID:   27490
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  mortoray at ecircle-ag dot com
 Status:   Feedback
 Bug Type: Zlib Related
 Operating System: Windows NT 5.0 build 219
 PHP Version:  4.3.4
 New Comment:

http://bugs.php.net/bug.php?id=27424 has been fixed and i tested the
reproduce code which is now working as expected.


Previous Comments:


[2004-03-05 20:37:01] scottmacvicar at ntlworld dot com

Duplicate of http://bugs.php.net/bug.php?id=27424



In the case of apache2 sapi_flush sends any pending headers and
prevents any further headers being sent unlike Apache 1.



Call to sapi_flush is within php_Exec on line 247 in
ext/standard/exec.c



[2004-03-05 18:52:01] [EMAIL PROTECTED]

Does it work if you set the header yourself with:

header('Content-Encoding: gzip');



?



regards,

Derick



[2004-03-04 04:11:45] mortoray at ecircle-ag dot com

Description:

Using the zlib.output_compression=On and the function system() produces
garbage output to the browser.  Specifically, it does a gzip encoding
but omits the "Content-Encoding: gzip" header.



Using "passthru" instead of "system" works as intended.



Turning off compression and using "system" works as intended.

Reproduce code:
---


Expected result:

Either system() should somehow turn off the zlib compression or its
output should be compressed properly and the proper headers should be
set.



--TCP Flow with passthru()--

GET /dir.php HTTP/1.0

Host: qatest.ecircle.de:8080

Accept: text/*, image/jpeg, image/png, image/*, */*

Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5

Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity

Accept-Language: en

User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux; en_US, en)



HTTP/1.1 200 OK

Date: Thu, 04 Mar 2004 09:12:41 GMT

Server: Apache/2.0.45 (Win32) PHP/4.3.4

X-Powered-By: PHP/4.3.4

Content-Encoding: gzip

Vary: Accept-Encoding

Connection: close

Content-Type: text/html; charset=ISO-8859-1



...S=O.0..+.?...X.J.-..dAbb`...kk5q...e..sm.

m"q.{.C.5c...1,!..b

}.MYb.p{..Ks.x_x.25..!..5..I.5..._..?.."a\.B|..ji...Iw..*i.[yE..

.-.~N.W.'.Xmy).7V.n.,sE.yer.I||...c..4...?f...Y.gWh!..h.);?.v...O.:H.A1...U6.^..6..z...d..g...5..nz.M.XWaM..o%...>..7

..5.cy6.K.aB..f..p.

..`...

...



Actual result:
--
--TCP Flow with system()--



GET /dir.php HTTP/1.0

Host: qatest.ecircle.de:8080

Accept: text/*, image/jpeg, image/png, image/*, */*

Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5

Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity

Accept-Language: en

Cache-control: no-cache

Pragma: no-cache

User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux; en_US, en)



HTTP/1.1 200 OK

Date: Thu, 04 Mar 2004 09:13:45 GMT

Server: Apache/2.0.45 (Win32) PHP/4.3.4

X-Powered-By: PHP/4.3.4

Connection: close

Content-Type: text/html; charset=ISO-8859-1



...S.n.0..#..{..X.J.\*..CO\...E..B"un.c...Ma..hA.x.+.r.nUO..2.!..U..F...".'.o...h.$...:.9.L..u`q...$.

@.Pxp.sW..3.*|...*B...t.)H..,S.vK..*.J..A.gYn..T.$L.=...8..Q.I{..7X.]A..)M,..g3<.=^_0.uZZ..^.#..M..L.wPL).N.V.!;..Al!o.(Q)k3.O.u.5..
..i.OM.$N.q.K4  >[EMAIL PROTECTED]|{...P.0...>..6...
%.78n.~..C

...





-- 
Edit this bug report at http://bugs.php.net/?id=27490&edit=1

#27533 [NEW]: gmmktime can return wrong value on the night that DST comes into affect

[scottmacvicar at ntlworld dot com]

From: scottmacvicar at ntlworld dot com
Operating system: *
PHP version:  4CVS-2004-03-08 (stable)
PHP Bug Type: Date/time related
Bug description:  gmmktime can return wrong value on the night that DST comes into 
affect

Description:

This bug seems to have different affect on Windows and Linux.



Windows

--

System has to be running GMT and Automatically adjust clock for daylight
savings time checked.



You'll notice that the 27th appears twice. The second occurence of the
27th is Sat Mar 27 23:00:00 2004.

--



Redhat 9.0

--

The timestamp for linux on the 28th is Sun Mar 28 02:00:00 2004



/etc/sysconfig/clock

ZONE="Europe/London"

UTC=true

ARC=false

--

So Windows lost an hour and linux gained 2 hours.



Patch

--- datetime.c  2004-03-09 02:19:32.0 +

+++ datetime.c.patched  2004-03-09 02:20:48.0 +

@@ -192,8 +192,8 @@

/* fall-through */ 

case 1: /* hour */

val = (*arguments[0])->value.lval; 

-   if (val < 1) { 

-   chgsecs += (1-val) * 60*60; val = 1; 

+   if (val < 2) { 

+   chgsecs += (2-val) * 60*60; val = 2; 

} 

ta->tm_hour = val; 

/* fall-through */ 



Changing the time to

02:01:01 seems to correct this issue and the windows machine stops eating
an hour and not setting tm_idst to 1 and i have no idea whats going on
with the linux machine.

Reproduce code:
---


Expected result:

1080259200 - 26

1080345600 - 27

1080432000 - 28

1080518400 - 29

Actual result:
--
Windows

---

1080259200 - 26

1080345600 - 27

1080428400 - 27

1080518400 - 29



Linux

---

1080259200 - 26

1080345600 - 27

1080439200 - 28

1080518400 - 29

-- 
Edit bug report at http://bugs.php.net/?id=27533&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27533&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27533&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27533&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27533&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27533&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27533&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27533&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27533&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27533&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27533&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27533&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27533&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27533&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27533&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27533&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27533&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27533&r=float

#25701 [Csd]: Calling flush from within an output buffer prevents headers from being sent

[scottmacvicar at ntlworld dot com]

 ID:   25701
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
 Status:   Closed
 Bug Type: Apache2 related
 Operating System: *
 PHP Version:  4CVS
 Assigned To:  iliaa
 New Comment:

This isn't a place to post problems with PHP applications. This should
be taken up with the authors of the script.


Previous Comments:


[2004-04-21 20:21:57] j_gambarron at hotmail dot com

copermine isn't fuction in my php nuke 7.2

www.absocios.es.kz



[2004-04-19 13:07:43] webmaster at line-of-fire dot de

Hi,
I have a problem with the Gallery...

If i want to upload a picture, i became a error:

Warning: is_dir() [function.is-dir]: Stat failed for
modules/coppermine/albums/userpics/10002 (errno=13 - Permission denied)
in
/home/www/htdocs/nstudios.de/php/html/modules/coppermine/db_input.php
on line 236

Warning: mkdir(modules/coppermine/albums/userpics/10002)
[function.mkdir]: Permission denied in
/home/www/htdocs/nstudios.de/php/html/modules/coppermine/db_input.php
on line 237

Warning: is_dir() [function.is-dir]: Stat failed for
modules/coppermine/albums/userpics/10002 (errno=13 - Permission denied)
in
/home/www/htdocs/nstudios.de/php/html/modules/coppermine/db_input.php
on line 238

...
AND


Verzeichnis modules/coppermine/albums/userpics/10002 konnte nicht
angelegt werden! 

Datei:
/home/www/htdocs/nstudios.de/php/html/modules/coppermine/db_input.php -
Zeile: 238




I hope someone coud help me.

LoF



[2004-01-05 03:15:35] brion at pobox dot com

While this seems to be fixed when using --with-apxs2, 
the bug still occurs in 4.3.4 using --with-apxs2filter.

headers_sent() returns false, no warning or error 
message occurs when trying to use header(), just the 
headers silently vanish.



[2003-10-01 23:22:07] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.





[2003-10-01 10:30:57] scottmacvicar at ntlworld dot com

';
}

echo $newtext;

?>

Based on what you've said above then you shouldn't see 'in here' within
Apache 2.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/25701

-- 
Edit this bug report at http://bugs.php.net/?id=25701&edit=1

#28375 [NEW]: getimagesize only checks global gif header

[scottmacvicar at ntlworld dot com]

From: scottmacvicar at ntlworld dot com
Operating system: *
PHP version:  4CVS-2004-05-12 (stable)
PHP Bug Type: GetImageSize related
Bug description:  getimagesize only checks global gif header

Description:

A getimagesize can return a wrong value if corruption or intentional
editing has changed the values held in the global header for the gif.

It is possible to find the correct value by scanning through each frame
and looking at the local image descriptor values for width and height and
returning the largest value.

Both Mozilla and IE do this as standard and ignore the global height and
width.

If anyone wants a sample gif I can email them it.


-- 
Edit bug report at http://bugs.php.net/?id=28375&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28375&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28375&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28375&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28375&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28375&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28375&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28375&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28375&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28375&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28375&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28375&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28375&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28375&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28375&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28375&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28375&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28375&r=float

#28281 [Com]: strftime prints incorret month, when directed to print only month

[scottmacvicar at ntlworld dot com]

 ID:   28281
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  info at alt dot lt
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: debian woody (latest stable upd)
 PHP Version:  4.3.6
 New Comment:

The last day of any given month can be expressed as the "0" day of the
next month, not the -1 day. Hence why 0 is producing the last day of
November.

This is in the mktime documentation.


Previous Comments:


[2004-05-05 11:57:34] info at alt dot lt

Description:


strftime prints incorret (decreased by one) month, when directed to
print only month.

Reproduce code:
---
";
$dat1=strftime("%Y  %B  %d  ",mktime(0,0,0,$month,$day,$year));
echo $dat1,"";
?>

Expected result:

Result is self explaining:

November
2004 December 15 








-- 
Edit this bug report at http://bugs.php.net/?id=28281&edit=1

#28263 [Com]: PNG image generation causes Segmentation Fault

[scottmacvicar at ntlworld dot com]

 ID:   28263
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  Rich dot West at wesmo dot com
 Status:   Open
 Bug Type: GD related
 Operating System: Fedora Core 1
 PHP Version:  4.3.6
 New Comment:

I had the same problem using the latest releases of libpng and had to
go back to an older version. It would happen for any png image.

Was using Red Hat Enterprise


Previous Comments:


[2004-05-06 16:54:14] Rich dot West at wesmo dot com

Any PNG image will do it.

I woul attach it, but there's no interface here to attach the images
that I tested with.



[2004-05-06 14:40:31] [EMAIL PROTECTED]

Please provide the source image. 



[2004-05-03 19:22:22] Rich dot West at wesmo dot com

Description:

After upgrading from PHP 4.3.3 to 4.3.5, and then again to 4.3.6, I
discovered that image generation calls to create PNG files were
producing zero length images.

I dug through it further by testing with the CLI version of PHP, and it
appears that if a PNG image is being created, the process with
segfault.

I was able to compile PHP 4.3.3 on this machine using the configure
options below, and, after running the test script through php, it would
properly output a PNG file.

Using the same configure options for PHP 4.3.5 and PHP 4.3.6, the
operation segfaults (and creates a core file) when creating a PNG file.
 It works just fine when creating a JPEG file.

I can consistently get things to work for PHP 4.3.3 and I can
consistently get it to NOT work for PHP 4.3.5 and PHP 4.3.6...

Oh, and, yes, my GD and libpng10/libpng libraries are linked
properly..

>From phpinfo():
'./configure' '--host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu'
'--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--cache-file=../config.cache'
'--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d'
'--enable-force-cgi-redirect' '--disable-debug' '--enable-pic'
'--disable-rpath' '--enable-inline-optimization' '--with-bz2'
'--with-db4=/usr' '--with-curl' '--with-exec-dir=/usr/bin'
'--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd'
'--enable-gd-native-ttf' '--with-gdbm' '--with-gettext'
'--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr'
'--with-openssl' '--with-png' '--with-pspell' '--with-regex=system'
'--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr'
'--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared'
'--with-pcre=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath'
'--enable-exif' '--enable-ftp' '--enable-magic-quotes'
'--enable-safe-mode' '--enable-sockets' '--enable-sysvsem'
'--enable-sysvshm' '--enable-discard-path' '--enable-track-vars'
'--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8'
'--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl'
'--with-kerberos' '--with-ldap=shared' '--with-pdflib'
'--with-mysql=shared,/usr' '--with-pgsql=shared'
'--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack'
'--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath'
'--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio'
'--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans'
'--enable-mbregex' '--with-apxs2=/usr/sbin/apxs'

Reproduce code:
---
 

Expected result:

Result should have been a PNG image.

Actual result:
--
#0  0x2009 in ?? ()
#1  0x00f1d850 in png_create_struct_2 () from /usr/lib/libpdf.so.1
#2  0x00997dcd in png_create_info_struct () from
/usr/lib/libpng12.so.0
#3  0x080c1b72 in gdImageCreateFromPngCtx ()
#4  0x080c1a61 in gdImageCreateFromPng ()
#5  0x080af917 in zif_imagecreatefromstring ()
#6  0x080afbea in zif_imagecreatefrompng ()
#7  0x0a11aa34 in ?? ()






-- 
Edit this bug report at http://bugs.php.net/?id=28263&edit=1

#28460 [Com]: zlib_output_compression On keepalive connections linger

[scottmacvicar at ntlworld dot com]

 ID:   28460
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  pixl at 7pt dot net
 Status:   Open
 Bug Type: Zlib Related
 Operating System: Linux, Redhat,  2.4.21-9.0.3.ELs
 PHP Version:  4.3.6
 New Comment:

Does the same problem occur with apache 1?


Previous Comments:


[2004-05-20 21:09:45] pixl at 7pt dot net

Description:

PHP 4.3.6
Apache 2 (prefork)

When using zlib_output_compression = On, with vBulletin Version 3.0.0
Internet Explorer and Mozilla Firefox does not show that the page has
completed loading, until the keepalive timer expires (15 seconds in my
config). Doing test with ethereal I see this.

with apachebench it works correcly
ab -n 2 -k -H "Accept-Encoding: gzip"
http://forums.anabolicreview.com/
after the html is pulled the client sends a [FIN] packet and the server
terminates the connection.

with Mozilla FireFox .8, the client pulls the page and images in about
.2 seconds, then sits in globe spinning mode (little animation goes in
the corner) for 15 seconds. At 15 seconds the server sends a [FIN-ACK]
packet the connection is closed and the client is no longer connected.

Internet Explorer 6 does exactly the same as mozilla.

This only occurs with zlib_output_compression =on, with
zlib_output_compression = off OR the obgzhandler settings on this does
not occur.

Most of the problem I have is a human one, users see that the animation
in there browser is still going for 15 seconds and make complaints that
the message board is going slow even when the page has loaded in under
a second.

I have currenly turned zlib-compression off, and enabled gzip
compression in vbulletins settings (im assuming using ob_gzhandler in
the php) and compression is working fine, I've just read in enough
documentation that zlib_output_compression is the recommended way to
run php.

If you need certian detailed information please ask, I'll reneable zilb
on the server and reproduce the problem.

Thank You, Peter

apache2 configuration
CFLAGS="-O2 -mcpu=pentium4 -march=pentium4"; export CFLAGS
"./configure" \
"--prefix=/usr/local/apache" \
"--enable-shared=max" \
"$@"

php 4.3.6 configuration

'./configure' '--with-apxs2=/usr/local/httpd/bin/apxs'
'--with-config-file-path=/usr/local/httpd' '--disable-debug'
'--disable-ipv6' '--disable-display-source' '--disable-cgi'
'--with-zlib' '--with-gettext' '--with-bz2' '--with-gd'
'--enable-gd-native-ttf' '--enable-memory-limit' '--enable-sysvshm'
'--enable-sysvsem' '--enable-sysvmsg' '--enable-shared'
'--with-freetype-dir=/usr' '--with-mysql=/usr' '--with-tiff-dir=/usr'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' 








-- 
Edit this bug report at http://bugs.php.net/?id=28460&edit=1

#29725 [Com]: variable $HTTP_SERVER_VARS['PHP_SELF'] does not exist or it's clear

[scottmacvicar at ntlworld dot com]

 ID:   29725
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  mex at localnet dot sk
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Windows XP SP1a
 PHP Version:  5.0.1
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a list
of more appropriate places to ask for help using PHP, please visit
http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Check your php.ini and make sure you register the old-style 
vars, this was a change made for PHP 5.
 
register_long_arrays = On


Previous Comments:


[2004-08-18 00:53:39] mex at localnet dot sk

Description:

variable $HTTP_SERVER_VARS['PHP_SELF'] does not exist or it's clear

Reproduce code:
---
on windows xp sp1a I get clear page:



on freebsd 5.2-cvs i get right reply



Expected result:

variable may be filled with relative path to actual script

Actual result:
--
variable is clear (or null?)





-- 
Edit this bug report at http://bugs.php.net/?id=29725&edit=1

#28639 [Com]: imageCreateFromGif infinite loop. max processor

[scottmacvicar at ntlworld dot com]

 ID:   28639
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  jim at bluedojo dot com
 Status:   Verified
 Bug Type: GD related
 Operating System: Windows XP
 PHP Version:  4.3.7
 New Comment:

Problem is in GetDataBlock_ it doesn't even return -1 so constantly
loops within the end code handling part of LWZReadByte_

while ((count = GetDataBlock(fd, buf)) > 0)
is the loop in question in libgd/gd_gif_in.c

I dont have enough time to see whats wrong with that function but its
there its looping.


Previous Comments:


[2004-06-15 12:45:03] iridium at beyondunreal dot com

I have reproduced this bug using

php -r
"imagecreatefromgif('http://members.tripod.com/~TyroneZero/drstrangelove.gif');"

on both windows xp in PHP 5.0.0rc2
and linux with 4.3.6
(both command line).

The above command causes it to hang. Tracing through the code using a
debugger it does look a lot like an infinate loop, though it could just
be a really long one.

I believe the infinate loop starts at line 155 in gd_gif_in.c at 

for (;;) {

- I think it may just not be reaching an exit condition.

I may investigate more later.

Very strangely, if I download the gif and run the same command without
going to the site at runtime, there is no such problem.

Irid.



[2004-06-14 14:02:11] [EMAIL PROTECTED]

It seems this is Windows specific issue caused most probably by
php_gd2.dll.



[2004-06-06 20:04:26] jim at bluedojo dot com

Yes, the images are corrupt.  I believe that is why the function
imageCreateFromGif() is going into an infinite loop.  I need to have
the function just exit and not loop infinitely.

When I run the php page from the command line it goes into an infinite
loop.  When I load the php page from an Apache web server, it causes
Apache to stall infinitely.  My processor maxes out and I have to go to
the Windows Task Menu to cancel the process.

I am running the following:

Windows XP
Apache/1.3.28
PHP/4.3.7 
GD library is turned on in php.ini

Any help would be greatful.  Thanks.



[2004-06-06 18:32:07] [EMAIL PROTECTED]

The 2 gif images you've offered are corrupt, and I cannot 
replicate the cpu usage you are reporting.  



[2004-06-05 20:00:26] jim at bluedojo dot com

This picture also causes processor to max out:

http://www.geocities.com/Tokyo/Palace/5677/riiya1.gif



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/28639

-- 
Edit this bug report at http://bugs.php.net/?id=28639&edit=1

#28875 [Com]: Wrong regex crashes server

[scottmacvicar at ntlworld dot com]

 ID:   28875
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  amoljak at cox dot net
 Status:   Feedback
 Bug Type: PCRE related
 Operating System: Windows 2000 Server
 PHP Version:  4.3.8-dev
 New Comment:

[EMAIL PROTECTED] scott]# php -v
PHP 4.3.8-dev (cli) (built: Jul  6 2004 17:26:46)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

[EMAIL PROTECTED] scott]# uname -a
Linux devbox 2.4.20-31.9 #1 Tue Apr 13 18:04:23 EDT 2004 i686 athlon
i386 GNU/Linux

#0  0x4207491d in _int_free () from /lib/tls/libc.so.6
#1  0x42073908 in free () from /lib/tls/libc.so.6
#2  0x080bac88 in php_pcre_compile (pattern=0x82e8fa4
"(^|[^a-zA-Z0-9-])([Nn]on[-s?
[]]]degrees?[Ss]tudents?)([^a-zA-Z0-9-]|$)", 
options=4, errorptr=0xbfffc264, erroroffset=0xbfffc268,
tables=0x82e8160 "")
at /usr/local/src/php-4.3.8-dev/ext/pcre/pcrelib/pcre.c:5088
#3  0x080c1270 in pcre_get_compiled_regex (
regex=0x82e04cc "/(^|[^a-zA-Z0-9-])([Nn]on[-s?
[]]]degrees?[Ss]tudents?)([^a-zA-Z0-9-]|$)/es", extra=0xbfffc358, 
preg_options=0xbfffc35c) at
/usr/local/src/php-4.3.8-dev/ext/pcre/php_pcre.c:257
#4  0x080c1513 in php_pcre_match (ht=137265364, return_value=0x82e8114,
this_ptr=0x0, return_value_used=0, global=0)
at /usr/local/src/php-4.3.8-dev/ext/pcre/php_pcre.c:391
#5  0x080c1e59 in zif_preg_match (ht=4, return_value=0x82e8114,
this_ptr=0x0, return_value_used=0)
at /usr/local/src/php-4.3.8-dev/ext/pcre/php_pcre.c:594
#6  0x0816d836 in execute (op_array=0x82e3f14) at
/usr/local/src/php-4.3.8-dev/Zend/zend_execute.c:1635
#7  0x08160ef9 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/php-4.3.8-dev/Zend/zend.c:891
#8  0x0813ae67 in php_execute_script (primary_file=0xbfffe9d0) at
/usr/local/src/php-4.3.8-dev/main/main.c:1731
#9  0x081724c7 in main (argc=2, argv=0xbfffea54) at
/usr/local/src/php-4.3.8-dev/sapi/cli/php_cli.c:822
#10 0x42015704 in __libc_start_main () from /lib/tls/libc.so.6


Previous Comments:


[2004-07-06 15:58:08] [EMAIL PROTECTED]

What's the difference in the 3rd server to the 2 others..?
And are you aware that PCRE has certain limitations what it can handle
and what not?




[2004-06-22 18:06:38] amoljak at cox dot net

Ok.. It crashes on two servers

And on the third machine it gives the following warning:
Warning: Compilation failed: internal error: code overflow at offset 72
in C:\work\servers\Apache2\htdocs\test\PHP\crashtest.php on line 7

(line 7 is the preg_match thing)
But it does not crash. The php.ini options are the same.

Thanks,
Amol



[2004-06-22 01:24:34] amoljak at cox dot net

I tried PHP 4.3.8-dev and it is not crashing. So I am closing the bug.
I will reopen if it occures on the machine I initially tried.

Thanks



[2004-06-22 00:45:31] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2004-06-21 22:58:29] amoljak at cox dot net

Description:

Note the extra ] in the regex. Try to load this page three times and it
will crash the third time.

Reproduce code:
---
";

?>


Expected result:

This is from end user's code and I don't know what he expected. But he
was able to crash the server... thats bad.






-- 
Edit this bug report at http://bugs.php.net/?id=28875&edit=1

#40545 [NEW]: zend_strtod.c threading issue

[scottmacvicar at ntlworld dot com]

From: scottmacvicar at ntlworld dot com
Operating system: RHEL 4
PHP version:  5.2.1
PHP Bug Type: Reproducible crash
Bug description:  zend_strtod.c threading issue

Description:

Recently upgraded to PHP 5.2.1 from PHP 5.1.6 and we started to see a
series of crashes every few hundred thousand requests, couldn't isolate
this to a specific section of code so I think its a concurrency problem.

I managed to catch a core file from the past few and in each case the
backtrace revealed that the problem is zend_strod. This is just an excerpt
the rest of the backtrace are just apache internals.

Thread 27 (process 14353):
#0  0x008b07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
No symbol table info available.
#1  0x0013bc46 in kill () from /lib/tls/libc.so.6
No symbol table info available.
#2  0x0807e90d in sig_coredump (sig=14332) at mpm_common.c:1170
No locals.
#3  
No symbol table info available.
#4  Balloc (k=1953067823) at /www/src/php-5.2.1/Zend/zend_strtod.c:460
x = Variable "x" is not available. 

We're seeing this problem on both of our web servers, I can recompile one
of the boxes in debug mode if that would help.

The only change I can see of recent was a reimplementation of the code to
a BSD license.


-- 
Edit bug report at http://bugs.php.net/?id=40545&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=40545&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=40545&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=40545&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40545&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=40545&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=40545&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40545&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40545&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=40545&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40545&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=40545&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=40545&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40545&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=40545&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40545&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40545&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=40545&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=40545&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=40545&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40545&r=mysqlcfg

#40545 [Fbk->Opn]: zend_strtod.c threading issue

[scottmacvicar at ntlworld dot com]

 ID:   40545
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: RHEL 4
 PHP Version:  5.2.1
 New Comment:

I've been unable to track it down specifically, its happening across a
larger number of scripts, the only thing I can see in common between
them all is a large number of unserialize calls during the script
startup.

I've compiled PHP into debug mode now and I'll leave it running
overnight to try and obtain a more detailed backtrace.


Previous Comments:


[2007-02-19 18:14:06] [EMAIL PROTECTED]

We still need to know how to reproduce it, otherwise it's hardly a
"**Reproducible** crash".

----

[2007-02-19 17:53:51] scottmacvicar at ntlworld dot com

Description:

Recently upgraded to PHP 5.2.1 from PHP 5.1.6 and we started to see a
series of crashes every few hundred thousand requests, couldn't isolate
this to a specific section of code so I think its a concurrency
problem.

I managed to catch a core file from the past few and in each case the
backtrace revealed that the problem is zend_strod. This is just an
excerpt the rest of the backtrace are just apache internals.

Thread 27 (process 14353):
#0  0x008b07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
No symbol table info available.
#1  0x0013bc46 in kill () from /lib/tls/libc.so.6
No symbol table info available.
#2  0x0807e90d in sig_coredump (sig=14332) at mpm_common.c:1170
No locals.
#3  
No symbol table info available.
#4  Balloc (k=1953067823) at /www/src/php-5.2.1/Zend/zend_strtod.c:460
x = Variable "x" is not available. 

We're seeing this problem on both of our web servers, I can recompile
one of the boxes in debug mode if that would help.

The only change I can see of recent was a reimplementation of the code
to a BSD license.






-- 
Edit this bug report at http://bugs.php.net/?id=40545&edit=1

#40545 [Fbk->Opn]: zend_strtod.c threading issue

[scottmacvicar at ntlworld dot com]

 ID:   40545
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: RHEL 4
 PHP Version:  5.2.1
 New Comment:

The backtrace was too large to paste, the trace from the thread in
question is at.

http://public.vbulletin.com/bugs/php/bug40545-bt.txt

It does appear to be an unserialize call thats causing the crash.


Previous Comments:


[2007-02-19 18:24:38] [EMAIL PROTECTED]

Ok.



[2007-02-19 18:21:42] scottmacvicar at ntlworld dot com

I've been unable to track it down specifically, its happening across a
larger number of scripts, the only thing I can see in common between
them all is a large number of unserialize calls during the script
startup.

I've compiled PHP into debug mode now and I'll leave it running
overnight to try and obtain a more detailed backtrace.



[2007-02-19 18:14:06] [EMAIL PROTECTED]

We still need to know how to reproduce it, otherwise it's hardly a
"**Reproducible** crash".

----

[2007-02-19 17:53:51] scottmacvicar at ntlworld dot com

Description:

Recently upgraded to PHP 5.2.1 from PHP 5.1.6 and we started to see a
series of crashes every few hundred thousand requests, couldn't isolate
this to a specific section of code so I think its a concurrency
problem.

I managed to catch a core file from the past few and in each case the
backtrace revealed that the problem is zend_strod. This is just an
excerpt the rest of the backtrace are just apache internals.

Thread 27 (process 14353):
#0  0x008b07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
No symbol table info available.
#1  0x0013bc46 in kill () from /lib/tls/libc.so.6
No symbol table info available.
#2  0x0807e90d in sig_coredump (sig=14332) at mpm_common.c:1170
No locals.
#3  
No symbol table info available.
#4  Balloc (k=1953067823) at /www/src/php-5.2.1/Zend/zend_strtod.c:460
x = Variable "x" is not available. 

We're seeing this problem on both of our web servers, I can recompile
one of the boxes in debug mode if that would help.

The only change I can see of recent was a reimplementation of the code
to a BSD license.






-- 
Edit this bug report at http://bugs.php.net/?id=40545&edit=1

#40545 [Fbk->Opn]: zend_strtod.c threading issue

[scottmacvicar at ntlworld dot com]

 ID:   40545
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: RHEL 4
 PHP Version:  5.2.1
 New Comment:

Source of a simple script at
http://public.vbulletin.com/bugs/php/bug40545.phps

You can grab the text file from the same folder.

I then ran:
ab -c 30 -n 1 http://localhost/~scott/bug40545.php

Segfaults within a few hundred requests.

Apache 2.2.4 with keep alive disabled and PHP 5.2.1

It's a development box and not a production box so I can change more or
less anything if you need anything else tested.


Previous Comments:


[2007-02-19 19:20:54] [EMAIL PROTECTED]

That's ok, but how to reproduce it?



[2007-02-19 18:51:54] scottmacvicar at ntlworld dot com

The backtrace was too large to paste, the trace from the thread in
question is at.

http://public.vbulletin.com/bugs/php/bug40545-bt.txt

It does appear to be an unserialize call thats causing the crash.



[2007-02-19 18:24:38] [EMAIL PROTECTED]

Ok.



[2007-02-19 18:21:42] scottmacvicar at ntlworld dot com

I've been unable to track it down specifically, its happening across a
larger number of scripts, the only thing I can see in common between
them all is a large number of unserialize calls during the script
startup.

I've compiled PHP into debug mode now and I'll leave it running
overnight to try and obtain a more detailed backtrace.



[2007-02-19 18:14:06] [EMAIL PROTECTED]

We still need to know how to reproduce it, otherwise it's hardly a
"**Reproducible** crash".



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40545

-- 
Edit this bug report at http://bugs.php.net/?id=40545&edit=1

#40545 [Fbk->Opn]: zend_strtod.c threading issue

[scottmacvicar at ntlworld dot com]

 ID:   40545
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: RHEL 4
 PHP Version:  5.2.1
 New Comment:

As I said its in the same folder.

http://public.vbulletin.com/bugs/php/datastore.txt


Previous Comments:


[2007-02-19 20:24:33] [EMAIL PROTECTED]

'./datastore.txt' ?
Looks like you forgot to provide this file.



[2007-02-19 20:21:23] scottmacvicar at ntlworld dot com

Source of a simple script at
http://public.vbulletin.com/bugs/php/bug40545.phps

You can grab the text file from the same folder.

I then ran:
ab -c 30 -n 1 http://localhost/~scott/bug40545.php

Segfaults within a few hundred requests.

Apache 2.2.4 with keep alive disabled and PHP 5.2.1

It's a development box and not a production box so I can change more or
less anything if you need anything else tested.



[2007-02-19 19:20:54] [EMAIL PROTECTED]

That's ok, but how to reproduce it?



[2007-02-19 18:51:54] scottmacvicar at ntlworld dot com

The backtrace was too large to paste, the trace from the thread in
question is at.

http://public.vbulletin.com/bugs/php/bug40545-bt.txt

It does appear to be an unserialize call thats causing the crash.



[2007-02-19 18:24:38] [EMAIL PROTECTED]

Ok.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40545

-- 
Edit this bug report at http://bugs.php.net/?id=40545&edit=1

#40545 [Fbk->Opn]: zend_strtod.c threading issue

[scottmacvicar at ntlworld dot com]

 ID:   40545
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: RHEL 4
 PHP Version:  5.2.1
 New Comment:

That's correct, configure string for apache is the following:

./configure --with-included-apr --enable-so --enable-info
--enable-rewrite --enable-speling --enable-deflate --enable-ssl
--enable-mime-magic --with-mpm=worker


Previous Comments:


[2007-02-20 11:35:04] [EMAIL PROTECTED]

What kind of MPM are you using?
I assume it's worker?



[2007-02-19 20:29:27] scottmacvicar at ntlworld dot com

As I said its in the same folder.

http://public.vbulletin.com/bugs/php/datastore.txt



[2007-02-19 20:24:33] [EMAIL PROTECTED]

'./datastore.txt' ?
Looks like you forgot to provide this file.



[2007-02-19 20:21:23] scottmacvicar at ntlworld dot com

Source of a simple script at
http://public.vbulletin.com/bugs/php/bug40545.phps

You can grab the text file from the same folder.

I then ran:
ab -c 30 -n 1 http://localhost/~scott/bug40545.php

Segfaults within a few hundred requests.

Apache 2.2.4 with keep alive disabled and PHP 5.2.1

It's a development box and not a production box so I can change more or
less anything if you need anything else tested.



[2007-02-19 19:20:54] [EMAIL PROTECTED]

That's ok, but how to reproduce it?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40545

-- 
Edit this bug report at http://bugs.php.net/?id=40545&edit=1

#40545 [Csd]: zend_strtod.c threading issue

[scottmacvicar at ntlworld dot com]

 ID:   40545
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
 Status:   Closed
 Bug Type: Reproducible crash
 Operating System: RHEL 4
 PHP Version:  5.2.1
 New Comment:

Applied the patch to our production servers and I'll leave it running
overnight again and check tomorrow morning.

I have however seen another core dump in _zend_mm_alloc_int but I'll
hold back on reporting it for the moment.


Previous Comments:


[2007-02-20 12:02:15] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Ok, found and fixed.
Special thanks for the great reproduce case.



[2007-02-20 11:46:46] scottmacvicar at ntlworld dot com

That's correct, configure string for apache is the following:

./configure --with-included-apr --enable-so --enable-info
--enable-rewrite --enable-speling --enable-deflate --enable-ssl
--enable-mime-magic --with-mpm=worker



[2007-02-20 11:35:04] [EMAIL PROTECTED]

What kind of MPM are you using?
I assume it's worker?



[2007-02-19 20:29:27] scottmacvicar at ntlworld dot com

As I said its in the same folder.

http://public.vbulletin.com/bugs/php/datastore.txt



[2007-02-19 20:24:33] [EMAIL PROTECTED]

'./datastore.txt' ?
Looks like you forgot to provide this file.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40545

-- 
Edit this bug report at http://bugs.php.net/?id=40545&edit=1

#40578 [Opn]: Thread safety issue with imagettftext

[scottmacvicar at ntlworld dot com]

 ID:   40578
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
 Status:   Open
-Bug Type: GD related
+Bug Type: Reproducible crash
 Operating System: RHEL 4
 PHP Version:  5.2.1
 New Comment:

Should probably class this as a crash.


Previous Comments:


[2007-02-21 14:25:47] scottmacvicar at ntlworld dot com

Description:

There appears to be a race condition with the truetype font support of
GD. I can see mutexes in the code for the font cache so there must be a
code path that's missed.

Backtrace:
http://public.vbulletin.com/bugs/php/gd_thread_safety-bt.txt

Reproduce code:
http://public.vbulletin.com/bugs/php/gd_thread_safety.phps
http://public.vbulletin.com/bugs/php/HECK.TTF

Command: ab -c 30 -n 1
http://localhost/~scott/gd_thread_safety.php

Using Apache 2 with the Worker MPM.

Only patch applied to the build is a thread safety patch for
zend_strtod.c






-- 
Edit this bug report at http://bugs.php.net/?id=40578&edit=1

#40578 [Csd]: Thread safety issue with imagettftext

[scottmacvicar at ntlworld dot com]

 ID:   40578
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
 Status:   Closed
 Bug Type: GD related
 Operating System: RHEL 4
 PHP Version:  5.2.1
 Assigned To:  tony2001
 New Comment:

Any chance of having this backported to the PHP_4_4 branch? It's a
fairly minor patch to apply.


Previous Comments:


[2007-02-21 15:42:02] [EMAIL PROTECTED]

I reported the issue in GD too:

http://bugs.libgd.org/?do=details&task_id=48

Will be fixed in 2.0.35.

Thanks for your patch and nice reproduce case!



[2007-02-21 15:00:50] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

And again - very nice reproduce case & report, thanks.



[2007-02-21 14:40:19] scottmacvicar at ntlworld dot com

Should probably class this as a crash.



[2007-02-21 14:25:47] scottmacvicar at ntlworld dot com

Description:

There appears to be a race condition with the truetype font support of
GD. I can see mutexes in the code for the font cache so there must be a
code path that's missed.

Backtrace:
http://public.vbulletin.com/bugs/php/gd_thread_safety-bt.txt

Reproduce code:
http://public.vbulletin.com/bugs/php/gd_thread_safety.phps
http://public.vbulletin.com/bugs/php/HECK.TTF

Command: ab -c 30 -n 1
http://localhost/~scott/gd_thread_safety.php

Using Apache 2 with the Worker MPM.

Only patch applied to the build is a thread safety patch for
zend_strtod.c






-- 
Edit this bug report at http://bugs.php.net/?id=40578&edit=1

#40578 [Csd]: Thread safety issue with imagettftext

[scottmacvicar at ntlworld dot com]

 ID:   40578
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
 Status:   Closed
 Bug Type: GD related
 Operating System: RHEL 4
 PHP Version:  5.2.1
 Assigned To:  tony2001
 New Comment:

Has this potentially caused a regression?

I applied the patch that was checked in CVS this afternoon 
and  recompiled PHP.

Had another segfault in GD, here is the backtrace. 
Unfortunately it wasn't a debug build.

Thread 13 (process 27300):
#0  0x009457a2 in _dl_sysinfo_int80 () from /lib/ld-
linux.so.2
No symbol table info available.
#1  0x00985c46 in kill () from /lib/tls/libc.so.6
No symbol table info available.
#2  0x0807e646 in sig_coredump (sig=11) at mpm_common.c:1170
No locals.
#3  
No symbol table info available.
#4  0x009bf652 in malloc_consolidate () from /lib/tls/
libc.so.6
No symbol table info available.
#5  0x009bfd30 in _int_free () from /lib/tls/libc.so.6
No symbol table info available.
#6  0x009c033a in free () from /lib/tls/libc.so.6
---Type  to continue, or q  to quit---
No symbol table info available.
#7  0x003d5b8a in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#8  0x9e418dc0 in ?? ()
No symbol table info available.
#9  0x00431b2c in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#10 0xa6629868 in ?? ()
No symbol table info available.
#11 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#12 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#13 0x003d88e9 in FT_GlyphLoader_Reset () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#14 0x003d8948 in FT_GlyphLoader_Done () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#15 0x003dc1de in FT_Remove_Module () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#16 0x003dc72b in FT_Done_Library () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#17 0x003d5ee0 in FT_Done_FreeType () from /usr/lib/
libfreetype.so.6
No symbol table info available.
---Type  to continue, or q  to quit---
#18 0x00fa4518 in php_gd_gdFontCacheShutdown ()
at /www/src/php-5.2.1/ext/gd/libgd/gdft.c:724
No locals.
#19 0x00f8c7eb in zm_deactivate_gd (type=1, 
module_number=26, 
tsrm_ls=0x94aea70) at /www/src/php-5.2.1/ext/gd/gd.c:
1303
No locals.
#20 0x0113434a in module_registry_cleanup (module=0x8b5d1b0, 
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_API.c:1945
No locals.
#21 0x0113986c in zend_hash_apply (ht=0x14274e0, 
apply_func=0x1134328 , 
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_hash.c:673
result = 0
p = (Bucket *) 0x8b5d180
#22 0x0112fb33 in zend_deactivate_modules 
(tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend.c:839
__orig_bailout = (jmp_buf *) 0x0
__bailout = {{__jmpbuf = {144334232, 144334256, 
19764252, -1503487368, 
  -1503487568, 18021115}, __mask_was_saved = 0, 
__saved_mask = {__val = {
149310844, 10232833, 4294967294, 4294967295, 
149310844, 165552858, 0, 
0, 165552848, 165159443, 0, 0, 149809548, 0, 
11036764, 24, 56, 88, 0, 
11, 11536181, 144334232, 0, 2791479928, 17752220, 3, 
165552848, 
135009633, 2, 0, 165552808, 165552848
---Type  to continue, or q  to quit---
#23 0x010f19c5 in php_request_shutdown (dummy=0x0)
at /www/src/php-5.2.1/main/main.c:1293
__orig_bailout = Variable "__orig_bailout" is not 
available.

I can try a debug build but the segfaults are occuring less 
frequently now.


Previous Comments:


[2007-02-21 18:41:56] [EMAIL PROTECTED]

Also backported to 4_4.



[2007-02-21 18:24:27] scottmacvicar at ntlworld dot com

Any chance of having this backported to the PHP_4_4 branch? It's a
fairly minor patch to apply.



[2007-02-21 15:42:02] [EMAIL PROTECTED]

I reported the issue in GD too:

http://bugs.libgd.org/?do=details&task_id=48

Will be fixed in 2.0.35.

Thanks for your patch and nice reproduce case!



[2007-02-21 15:00:50] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

And again - very nice reproduce case & report, thanks.



[2007-02-21 14:40:19] scottmacvicar at ntlworld dot com

Should probably class this as a crash.



The remainder of the comments for this report are t

#40578 [Fbk->Opn]: Thread safety issue with imagettftext

[scottmacvicar at ntlworld dot com]

 ID:   40578
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
-Status:   Feedback
+Status:   Open
 Bug Type: GD related
 Operating System: RHEL 4
 PHP Version:  5.2.1
 Assigned To:  pajoye
 New Comment:

Applied now to one of our production boxes, When I'm back in 
the office tomorrow I'll see if I can spend a little time 
working out a test case to reproduce it.


Previous Comments:


[2007-02-22 00:57:19] [EMAIL PROTECTED]

It looks like something else.

Can you try:

http://pecl.php.net/~pierre/40568.txt





[2007-02-22 00:39:14] scottmacvicar at ntlworld dot com

Has this potentially caused a regression?

I applied the patch that was checked in CVS this afternoon 
and  recompiled PHP.

Had another segfault in GD, here is the backtrace. 
Unfortunately it wasn't a debug build.

Thread 13 (process 27300):
#0  0x009457a2 in _dl_sysinfo_int80 () from /lib/ld-
linux.so.2
No symbol table info available.
#1  0x00985c46 in kill () from /lib/tls/libc.so.6
No symbol table info available.
#2  0x0807e646 in sig_coredump (sig=11) at mpm_common.c:1170
No locals.
#3  
No symbol table info available.
#4  0x009bf652 in malloc_consolidate () from /lib/tls/
libc.so.6
No symbol table info available.
#5  0x009bfd30 in _int_free () from /lib/tls/libc.so.6
No symbol table info available.
#6  0x009c033a in free () from /lib/tls/libc.so.6
---Type  to continue, or q  to quit---
No symbol table info available.
#7  0x003d5b8a in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#8  0x9e418dc0 in ?? ()
No symbol table info available.
#9  0x00431b2c in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#10 0xa6629868 in ?? ()
No symbol table info available.
#11 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#12 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#13 0x003d88e9 in FT_GlyphLoader_Reset () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#14 0x003d8948 in FT_GlyphLoader_Done () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#15 0x003dc1de in FT_Remove_Module () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#16 0x003dc72b in FT_Done_Library () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#17 0x003d5ee0 in FT_Done_FreeType () from /usr/lib/
libfreetype.so.6
No symbol table info available.
---Type  to continue, or q  to quit---
#18 0x00fa4518 in php_gd_gdFontCacheShutdown ()
at /www/src/php-5.2.1/ext/gd/libgd/gdft.c:724
No locals.
#19 0x00f8c7eb in zm_deactivate_gd (type=1, 
module_number=26, 
tsrm_ls=0x94aea70) at /www/src/php-5.2.1/ext/gd/gd.c:
1303
No locals.
#20 0x0113434a in module_registry_cleanup (module=0x8b5d1b0, 
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_API.c:1945
No locals.
#21 0x0113986c in zend_hash_apply (ht=0x14274e0, 
apply_func=0x1134328 , 
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_hash.c:673
result = 0
p = (Bucket *) 0x8b5d180
#22 0x0112fb33 in zend_deactivate_modules 
(tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend.c:839
__orig_bailout = (jmp_buf *) 0x0
__bailout = {{__jmpbuf = {144334232, 144334256, 
19764252, -1503487368, 
  -1503487568, 18021115}, __mask_was_saved = 0, 
__saved_mask = {__val = {
149310844, 10232833, 4294967294, 4294967295, 
149310844, 165552858, 0, 
0, 165552848, 165159443, 0, 0, 149809548, 0, 
11036764, 24, 56, 88, 0, 
11, 11536181, 144334232, 0, 2791479928, 17752220, 3, 
165552848, 
135009633, 2, 0, 165552808, 165552848
---Type  to continue, or q  to quit---
#23 0x010f19c5 in php_request_shutdown (dummy=0x0)
at /www/src/php-5.2.1/main/main.c:1293
__orig_bailout = Variable "__orig_bailout" is not 
available.

I can try a debug build but the segfaults are occuring less 
frequently now.



[2007-02-21 18:41:56] [EMAIL PROTECTED]

Also backported to 4_4.

----

[2007-02-21 18:24:27] scottmacvicar at ntlworld dot com

Any chance of having this backported to the PHP_4_4 branch? It's a
fairly minor patch to apply.



[2007-02-21 15:42:02] [EMAIL PROTECTED]

I reported the issue in GD too:

http://bugs.libgd.org/?do=details&task_id=48

Will be fixed in 2.0.35.

Thanks for your patch and nice reproduce case!



The remainder of the comments for this report are too long. To view
the rest of the comments, please view

#40578 [NEW]: Thread safety issue with imagettftext

[scottmacvicar at ntlworld dot com]

From: scottmacvicar at ntlworld dot com
Operating system: RHEL 4
PHP version:  5.2.1
PHP Bug Type: GD related
Bug description:  Thread safety issue with imagettftext

Description:

There appears to be a race condition with the truetype font support of GD.
I can see mutexes in the code for the font cache so there must be a code
path that's missed.

Backtrace: http://public.vbulletin.com/bugs/php/gd_thread_safety-bt.txt

Reproduce code:
http://public.vbulletin.com/bugs/php/gd_thread_safety.phps
http://public.vbulletin.com/bugs/php/HECK.TTF

Command: ab -c 30 -n 1 http://localhost/~scott/gd_thread_safety.php

Using Apache 2 with the Worker MPM.

Only patch applied to the build is a thread safety patch for zend_strtod.c


-- 
Edit bug report at http://bugs.php.net/?id=40578&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=40578&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=40578&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=40578&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40578&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=40578&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=40578&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40578&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40578&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=40578&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40578&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=40578&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=40578&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40578&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=40578&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40578&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40578&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=40578&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=40578&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=40578&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40578&r=mysqlcfg

#40578 [Fbk->Opn]: Thread safety issue with imagettftext

[scottmacvicar at ntlworld dot com]

 ID:   40578
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
-Status:   Feedback
+Status:   Open
 Bug Type: GD related
 Operating System: RHEL 4
 PHP Version:  5.2.1
 Assigned To:  pajoye
 New Comment:

Been going for almost 24 hours now without any more crashes, 
the patch makes sense though. Since there was another race 
condition on shutdown if one thread is accessing the cache 
while another is trying to delete it.


Previous Comments:


[2007-02-22 01:48:56] scottmacvicar at ntlworld dot com

Applied now to one of our production boxes, When I'm back in 
the office tomorrow I'll see if I can spend a little time 
working out a test case to reproduce it.



[2007-02-22 00:57:19] [EMAIL PROTECTED]

It looks like something else.

Can you try:

http://pecl.php.net/~pierre/40568.txt





[2007-02-22 00:39:14] scottmacvicar at ntlworld dot com

Has this potentially caused a regression?

I applied the patch that was checked in CVS this afternoon 
and  recompiled PHP.

Had another segfault in GD, here is the backtrace. 
Unfortunately it wasn't a debug build.

Thread 13 (process 27300):
#0  0x009457a2 in _dl_sysinfo_int80 () from /lib/ld-
linux.so.2
No symbol table info available.
#1  0x00985c46 in kill () from /lib/tls/libc.so.6
No symbol table info available.
#2  0x0807e646 in sig_coredump (sig=11) at mpm_common.c:1170
No locals.
#3  
No symbol table info available.
#4  0x009bf652 in malloc_consolidate () from /lib/tls/
libc.so.6
No symbol table info available.
#5  0x009bfd30 in _int_free () from /lib/tls/libc.so.6
No symbol table info available.
#6  0x009c033a in free () from /lib/tls/libc.so.6
---Type  to continue, or q  to quit---
No symbol table info available.
#7  0x003d5b8a in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#8  0x9e418dc0 in ?? ()
No symbol table info available.
#9  0x00431b2c in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#10 0xa6629868 in ?? ()
No symbol table info available.
#11 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#12 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#13 0x003d88e9 in FT_GlyphLoader_Reset () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#14 0x003d8948 in FT_GlyphLoader_Done () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#15 0x003dc1de in FT_Remove_Module () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#16 0x003dc72b in FT_Done_Library () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#17 0x003d5ee0 in FT_Done_FreeType () from /usr/lib/
libfreetype.so.6
No symbol table info available.
---Type  to continue, or q  to quit---
#18 0x00fa4518 in php_gd_gdFontCacheShutdown ()
at /www/src/php-5.2.1/ext/gd/libgd/gdft.c:724
No locals.
#19 0x00f8c7eb in zm_deactivate_gd (type=1, 
module_number=26, 
tsrm_ls=0x94aea70) at /www/src/php-5.2.1/ext/gd/gd.c:
1303
No locals.
#20 0x0113434a in module_registry_cleanup (module=0x8b5d1b0, 
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_API.c:1945
No locals.
#21 0x0113986c in zend_hash_apply (ht=0x14274e0, 
apply_func=0x1134328 , 
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_hash.c:673
result = 0
p = (Bucket *) 0x8b5d180
#22 0x0112fb33 in zend_deactivate_modules 
(tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend.c:839
__orig_bailout = (jmp_buf *) 0x0
__bailout = {{__jmpbuf = {144334232, 144334256, 
19764252, -1503487368, 
  -1503487568, 18021115}, __mask_was_saved = 0, 
__saved_mask = {__val = {
149310844, 10232833, 4294967294, 4294967295, 
149310844, 165552858, 0, 
0, 165552848, 165159443, 0, 0, 149809548, 0, 
11036764, 24, 56, 88, 0, 
11, 11536181, 144334232, 0, 2791479928, 17752220, 3, 
165552848, 
135009633, 2, 0, 165552808, 165552848
---Type  to continue, or q  to quit---
#23 0x010f19c5 in php_request_shutdown (dummy=0x0)
at /www/src/php-5.2.1/main/main.c:1293
__orig_bailout = Variable "__orig_bailout" is not 
available.

I can try a debug build but the segfaults are occuring less 
frequently now.



[2007-02-21 18:41:56] [EMAIL PROTECTED]

Also backported to 4_4.

----

[2007-02-21 18:24:27] scottmacvicar at ntlworld dot com

Any chance of having this backported to the PHP_4_4 branch? It's a
fairly minor patch to apply.



The remainder of the comments for thi

#40578 [Csd]: Thread safety issue with imagettftext

[scottmacvicar at ntlworld dot com]

 ID:   40578
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
 Status:   Closed
 Bug Type: GD related
 Operating System: RHEL 4
 PHP Version:  5.2.1
 Assigned To:  pajoye
 New Comment:

Antony backported the initial fix to PHP_4_4, can this be 
backported too please.


Previous Comments:


[2007-02-23 01:04:17] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Fixed in 5.2 and HEAD.

Thanks for the tests



[2007-02-23 00:52:41] scottmacvicar at ntlworld dot com

Been going for almost 24 hours now without any more crashes, 
the patch makes sense though. Since there was another race 
condition on shutdown if one thread is accessing the cache 
while another is trying to delete it.



[2007-02-22 01:48:56] scottmacvicar at ntlworld dot com

Applied now to one of our production boxes, When I'm back in 
the office tomorrow I'll see if I can spend a little time 
working out a test case to reproduce it.



[2007-02-22 00:57:19] [EMAIL PROTECTED]

It looks like something else.

Can you try:

http://pecl.php.net/~pierre/40568.txt





[2007-02-22 00:39:14] scottmacvicar at ntlworld dot com

Has this potentially caused a regression?

I applied the patch that was checked in CVS this afternoon 
and  recompiled PHP.

Had another segfault in GD, here is the backtrace. 
Unfortunately it wasn't a debug build.

Thread 13 (process 27300):
#0  0x009457a2 in _dl_sysinfo_int80 () from /lib/ld-
linux.so.2
No symbol table info available.
#1  0x00985c46 in kill () from /lib/tls/libc.so.6
No symbol table info available.
#2  0x0807e646 in sig_coredump (sig=11) at mpm_common.c:1170
No locals.
#3  
No symbol table info available.
#4  0x009bf652 in malloc_consolidate () from /lib/tls/
libc.so.6
No symbol table info available.
#5  0x009bfd30 in _int_free () from /lib/tls/libc.so.6
No symbol table info available.
#6  0x009c033a in free () from /lib/tls/libc.so.6
---Type  to continue, or q  to quit---
No symbol table info available.
#7  0x003d5b8a in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#8  0x9e418dc0 in ?? ()
No symbol table info available.
#9  0x00431b2c in ?? () from /usr/lib/libfreetype.so.6
No symbol table info available.
#10 0xa6629868 in ?? ()
No symbol table info available.
#11 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#12 0x003d5fc0 in FT_Free () from /usr/lib/libfreetype.so.6
No symbol table info available.
#13 0x003d88e9 in FT_GlyphLoader_Reset () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#14 0x003d8948 in FT_GlyphLoader_Done () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#15 0x003dc1de in FT_Remove_Module () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#16 0x003dc72b in FT_Done_Library () from /usr/lib/
libfreetype.so.6
No symbol table info available.
#17 0x003d5ee0 in FT_Done_FreeType () from /usr/lib/
libfreetype.so.6
No symbol table info available.
---Type  to continue, or q  to quit---
#18 0x00fa4518 in php_gd_gdFontCacheShutdown ()
at /www/src/php-5.2.1/ext/gd/libgd/gdft.c:724
No locals.
#19 0x00f8c7eb in zm_deactivate_gd (type=1, 
module_number=26, 
tsrm_ls=0x94aea70) at /www/src/php-5.2.1/ext/gd/gd.c:
1303
No locals.
#20 0x0113434a in module_registry_cleanup (module=0x8b5d1b0, 
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_API.c:1945
No locals.
#21 0x0113986c in zend_hash_apply (ht=0x14274e0, 
apply_func=0x1134328 , 
tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend_hash.c:673
result = 0
p = (Bucket *) 0x8b5d180
#22 0x0112fb33 in zend_deactivate_modules 
(tsrm_ls=0x94aea70)
at /www/src/php-5.2.1/Zend/zend.c:839
__orig_bailout = (jmp_buf *) 0x0
__bailout = {{__jmpbuf = {144334232, 144334256, 
19764252, -1503487368, 
  -1503487568, 18021115}, __mask_was_saved = 0, 
__saved_mask = {__val = {
149310844, 10232833, 4294967294, 4294967295, 
149310844, 165552858, 0, 
0, 165552848, 165159443, 0, 0, 149809548, 0, 
11036764, 24, 56, 88, 0, 
11, 11536181, 144334232, 0, 2791479928, 17752220, 3, 
165552848, 
135009633, 2, 0, 165552808, 165552848
---Type  to continue, or q  to quit---
#23 0x010f19c5 in php_request_shutdown (dummy=0x0)
at /www/src/php-5.2.1/main/main.c:1293
__orig_bailout = Variable "__

#40719 [NEW]: Crash under load within memory manager

[scottmacvicar at ntlworld dot com]

From: scottmacvicar at ntlworld dot com
Operating system: RHEL 4
PHP version:  5.2.1
PHP Bug Type: Unknown/Other Function
Bug description:  Crash under load within memory manager

Description:

Under high load we appear to be experiencing a crash when allocating 
memory, I've been unable to track this down to a specific script and 
when we compile in debug mode the crash simply doesn't happen.

This has only happened in the 5.2 branch.

We're using the worker MPM for Apache 2 and a few patches from 5.2.2 
that we've backported to fix some thread safety issues.

Backtrace at the moment is as follows:

Thread 3 (process 12962):
#0  0x008b07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
No symbol table info available.
#1  0x008f0c46 in kill () from /lib/tls/libc.so.6
No symbol table info available.
#2  0x0807e90d in sig_coredump (sig=12936) at mpm_common.c:1170
No locals.
#3  
No symbol table info available.
#4  0x0092a652 in malloc_consolidate () from /lib/tls/libc.so.6
No symbol table info available.
#5  0x0092b643 in _int_malloc () from /lib/tls/libc.so.6
No symbol table info available.
#6  0x0092d401 in malloc () from /lib/tls/libc.so.6
No symbol table info available.
#7  0x011169cc in _zend_mm_alloc_int (heap=0xfff0, size=8192)
at /www/src/php-5.2.1/Zend/zend_alloc.c:1451
segment_size = 10420212
block_size = Variable "block_size" is not available.

I can't seem to pull out what scripts are running in what process at 
the time of execution from the logs, I may have to write a quick 
apache module to do this.

If nothing jumps out at anyone the just assign back to feedback and 
I'll try to do some more tracing to see if I can find a reproduce 
case.


-- 
Edit bug report at http://bugs.php.net/?id=40719&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=40719&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=40719&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=40719&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40719&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=40719&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=40719&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40719&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40719&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=40719&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40719&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=40719&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=40719&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40719&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=40719&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40719&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40719&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=40719&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=40719&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=40719&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40719&r=mysqlcfg

#38449 [Bgs->Opn]: Segfault when token_get_all is used

[scottmacvicar at ntlworld dot com]

 ID:   38449
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
-Status:   Bogus
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: FreeBSD 4.10-RELEASE-p5
 PHP Version:  4.4.3
 New Comment:

We've had another customer report regarding this issue on a completely
different server, same back trace but this time using PHP 4.4.2 and
4.11-RELEASE-p19

Is there anyway to produce more information that might help track this
down?

The configure line is:
'./configure' '--enable-versioning' '--enable-memory-limit'
'--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php'
'--disable-all' '--with-regex=php' '--disable-cli'
'--with-apxs=/usr/local/sbin/apxs' '--disable-ipv6'
'--prefix=/usr/local' 'i386-portbld-freebsd4.11'

tokenizer was built as a seperate module afterwards using the
php4-tokenizer port.


Previous Comments:


[2006-08-14 17:24:46] [EMAIL PROTECTED]

Please reopen when/if you can add more info.
Thank you.

----

[2006-08-14 15:44:50] scottmacvicar at ntlworld dot com

Can someone mark this awaiting feedback again.

----

[2006-08-14 15:44:03] scottmacvicar at ntlworld dot com

I edited the ports Makefile to add --enable-tokenizer and removed the
tokenizer as an extension and there was no crash.

I tried a similar setup on my debian box following the same procedure
with tokenizer as an extension and had no problem. I'm going to look a
little closer later on and see if I can identify what in particular is
causing this on the FreeBSD box.



[2006-08-14 12:05:55] [EMAIL PROTECTED]

Works just fine on Linux and FreeBSD 5.4-RELEASE.



[2006-08-14 11:37:00] scottmacvicar at ntlworld dot com

Description:

Customer reported this issue and we've tracked it down to a segfault
within token_get_all, we can't reproduce it on Linux or Windows but can
on FreeBSD.

php -v
PHP 4.4.3 (cli) (built: Aug 14 2006 04:34:25)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

Reproduce code:
---
');
var_dump($tokens);
?>

Expected result:

Some output

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x80d216d in _efree ()
(gdb) bt
#0  0x80d216d in _efree ()
#1  0x80de408 in _zval_dtor ()
#2  0x4861f8e6 in tokenize () from
/usr/local/lib/php/20020429/tokenizer.so
#3  0x48620041 in zif_token_get_all () from
/usr/local/lib/php/20020429/tokenizer.so
#4  0x80f14bb in execute ()
#5  0x80df699 in zend_execute_scripts ()
#6  0x80ba79f in php_execute_script ()
#7  0x80f8241 in main ()
#8  0x805cf86 in _start ()





-- 
Edit this bug report at http://bugs.php.net/?id=38449&edit=1

#39293 [Com]: no GET variables available if one of them is empty

[scottmacvicar at ntlworld dot com]

 ID:   39293
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  mcalpine at susysearch dot co dot za
 Status:   Feedback
 Bug Type: Unknown/Other Function
 Operating System: redhat
 PHP Version:  4.4.4
 New Comment:

This is a bug in suPHP that we see quite often with customers. 

Nothing to do with PHP itself.


Previous Comments:


[2006-10-29 00:00:10] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

Can't reproduce.



[2006-10-28 22:23:43] mcalpine at susysearch dot co dot za

Description:

if a url is sent with one or more of the query variable values empty,
eg: index.php?hello=yes&goodbye= , the whole $_GET global is emtpy and
the $_SERVER['REQUEST_URI'] is emtpy too. 

as soon as you send a value for all query variables, the GET and SERVER
variables have data.



Reproduce code:
---
just try var_dump($_GET)...
or echo  $_SERVER['REQUEST_URI'];

Expected result:

i would expect to see the url query variables...

Actual result:
--
described above.





-- 
Edit this bug report at http://bugs.php.net/?id=39293&edit=1

#38449 [NEW]: Segfault when token_get_all is used

[scottmacvicar at ntlworld dot com]

From: scottmacvicar at ntlworld dot com
Operating system: FreeBSD 4.10-RELEASE-p5
PHP version:  4.4.3
PHP Bug Type: Reproducible crash
Bug description:  Segfault when token_get_all is used

Description:

Customer reported this issue and we've tracked it down to a segfault
within token_get_all, we can't reproduce it on Linux or Windows but can on
FreeBSD.

php -v
PHP 4.4.3 (cli) (built: Aug 14 2006 04:34:25)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

Reproduce code:
---
');
var_dump($tokens);
?>

Expected result:

Some output

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x80d216d in _efree ()
(gdb) bt
#0  0x80d216d in _efree ()
#1  0x80de408 in _zval_dtor ()
#2  0x4861f8e6 in tokenize () from
/usr/local/lib/php/20020429/tokenizer.so
#3  0x48620041 in zif_token_get_all () from
/usr/local/lib/php/20020429/tokenizer.so
#4  0x80f14bb in execute ()
#5  0x80df699 in zend_execute_scripts ()
#6  0x80ba79f in php_execute_script ()
#7  0x80f8241 in main ()
#8  0x805cf86 in _start ()

-- 
Edit bug report at http://bugs.php.net/?id=38449&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=38449&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=38449&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=38449&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38449&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=38449&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=38449&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38449&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38449&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=38449&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38449&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=38449&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=38449&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38449&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=38449&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38449&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38449&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=38449&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=38449&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=38449&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38449&r=mysqlcfg

#38449 [Fbk->Csd]: Segfault when token_get_all is used

[scottmacvicar at ntlworld dot com]

 ID:   38449
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
-Status:   Feedback
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: FreeBSD 4.10-RELEASE-p5
 PHP Version:  4.4.3
 New Comment:

I edited the ports Makefile to add --enable-tokenizer and removed the
tokenizer as an extension and there was no crash.

I tried a similar setup on my debian box following the same procedure
with tokenizer as an extension and had no problem. I'm going to look a
little closer later on and see if I can identify what in particular is
causing this on the FreeBSD box.


Previous Comments:


[2006-08-14 12:05:55] [EMAIL PROTECTED]

Works just fine on Linux and FreeBSD 5.4-RELEASE.



[2006-08-14 11:37:00] scottmacvicar at ntlworld dot com

Description:

Customer reported this issue and we've tracked it down to a segfault
within token_get_all, we can't reproduce it on Linux or Windows but can
on FreeBSD.

php -v
PHP 4.4.3 (cli) (built: Aug 14 2006 04:34:25)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

Reproduce code:
---
');
var_dump($tokens);
?>

Expected result:

Some output

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x80d216d in _efree ()
(gdb) bt
#0  0x80d216d in _efree ()
#1  0x80de408 in _zval_dtor ()
#2  0x4861f8e6 in tokenize () from
/usr/local/lib/php/20020429/tokenizer.so
#3  0x48620041 in zif_token_get_all () from
/usr/local/lib/php/20020429/tokenizer.so
#4  0x80f14bb in execute ()
#5  0x80df699 in zend_execute_scripts ()
#6  0x80ba79f in php_execute_script ()
#7  0x80f8241 in main ()
#8  0x805cf86 in _start ()





-- 
Edit this bug report at http://bugs.php.net/?id=38449&edit=1

#38449 [Csd->Opn]: Segfault when token_get_all is used

[scottmacvicar at ntlworld dot com]

 ID:   38449
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
-Status:   Closed
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: FreeBSD 4.10-RELEASE-p5
 PHP Version:  4.4.3
 New Comment:

Can someone mark this awaiting feedback again.


Previous Comments:


[2006-08-14 15:44:03] scottmacvicar at ntlworld dot com

I edited the ports Makefile to add --enable-tokenizer and removed the
tokenizer as an extension and there was no crash.

I tried a similar setup on my debian box following the same procedure
with tokenizer as an extension and had no problem. I'm going to look a
little closer later on and see if I can identify what in particular is
causing this on the FreeBSD box.



[2006-08-14 12:05:55] [EMAIL PROTECTED]

Works just fine on Linux and FreeBSD 5.4-RELEASE.



[2006-08-14 11:37:00] scottmacvicar at ntlworld dot com

Description:

Customer reported this issue and we've tracked it down to a segfault
within token_get_all, we can't reproduce it on Linux or Windows but can
on FreeBSD.

php -v
PHP 4.4.3 (cli) (built: Aug 14 2006 04:34:25)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

Reproduce code:
---
');
var_dump($tokens);
?>

Expected result:

Some output

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x80d216d in _efree ()
(gdb) bt
#0  0x80d216d in _efree ()
#1  0x80de408 in _zval_dtor ()
#2  0x4861f8e6 in tokenize () from
/usr/local/lib/php/20020429/tokenizer.so
#3  0x48620041 in zif_token_get_all () from
/usr/local/lib/php/20020429/tokenizer.so
#4  0x80f14bb in execute ()
#5  0x80df699 in zend_execute_scripts ()
#6  0x80ba79f in php_execute_script ()
#7  0x80f8241 in main ()
#8  0x805cf86 in _start ()





-- 
Edit this bug report at http://bugs.php.net/?id=38449&edit=1

#40751 [Com]: Apache segmentation fault

[scottmacvicar at ntlworld dot com]

 ID:   40751
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  sti-pe2 at online dot no
 Status:   Feedback
 Bug Type: Session related
 Operating System: FreeBSD 5.3-RELEASE
 PHP Version:  4.4.6
 New Comment:

What other extensions do you load in php.ini an what order are they
loaded?

If you disable all apart from session do you still get the crash?


Previous Comments:


[2007-03-09 12:22:04] [EMAIL PROTECTED]

I'm still unable to reproduce it.



[2007-03-09 11:56:55] sti-pe2 at online dot no

Installed latest snapshot, but I still get the same error.



[2007-03-09 11:34:20] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2007-03-09 11:21:45] sti-pe2 at online dot no

No, my php.ini says
;open_basedir =



[2007-03-09 10:42:39] [EMAIL PROTECTED]

Do you have open_basedir set?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40751

-- 
Edit this bug report at http://bugs.php.net/?id=40751&edit=1

#40858 [NEW]: Thread safety issue in GD

[scottmacvicar at ntlworld dot com]

From: scottmacvicar at ntlworld dot com
Operating system: RHEL 4
PHP version:  5.2.1
PHP Bug Type: GD related
Bug description:  Thread safety issue in GD

Description:

Appears to be still several more thread safety issues in GD, I've not had
time to track these all down yet.

We're running gdft.c from CVS to fix a few identified issues already.
Looking at the code there still appears to be a race condition within the
code but it appears to be a pretty tight loop since its not happening as
often as before.

By looking at gdft.c it looks possible for a fontCache entry to exist
during a check, by the time it gets to obtaining the lock the fontCache has
been cleared or something similarly evil.

The backtrace we've got is:
http://public.vbulletin.com/bugs/php/gdcache-bt.txt

Patch for first issue to deal with the possibility that a cache entry is
null: http://public.vbulletin.com/bugs/php/gdcache-patch-1.txt

Potential patch for second issue to deal with gdCacheSetup thread safety:
http://public.vbulletin.com/bugs/php/gdcache-patch-2.txt


-- 
Edit bug report at http://bugs.php.net/?id=40858&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=40858&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=40858&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=40858&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40858&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=40858&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=40858&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40858&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40858&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=40858&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40858&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=40858&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=40858&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40858&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=40858&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40858&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40858&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=40858&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=40858&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=40858&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40858&r=mysqlcfg

#40858 [Asn]: Thread safety issue in GD

[scottmacvicar at ntlworld dot com]

 ID:   40858
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
 Status:   Assigned
 Bug Type: GD related
 Operating System: RHEL 4
 PHP Version:  5.2.1
 Assigned To:  pajoye
 New Comment:

I should have mentioned, the first patch deals with the segfault so it
errors out gracefully. We've got this running on production now.

The second patch is an attempt to deal with the race condition that's
still present, would probably be simplier to just to call
gdFontCacheSetup() again but I'm unsure what the behaviour is of setting
up a mutex thats already initialised and then locking it.


Previous Comments:


[2007-03-19 18:53:45] [EMAIL PROTECTED]

Assigned to the maintainer.



[2007-03-19 18:41:15] scottmacvicar at ntlworld dot com

Description:

Appears to be still several more thread safety issues in GD, I've not
had time to track these all down yet.

We're running gdft.c from CVS to fix a few identified issues already.
Looking at the code there still appears to be a race condition within
the code but it appears to be a pretty tight loop since its not
happening as often as before.

By looking at gdft.c it looks possible for a fontCache entry to exist
during a check, by the time it gets to obtaining the lock the fontCache
has been cleared or something similarly evil.

The backtrace we've got is:
http://public.vbulletin.com/bugs/php/gdcache-bt.txt

Patch for first issue to deal with the possibility that a cache entry
is null: http://public.vbulletin.com/bugs/php/gdcache-patch-1.txt

Potential patch for second issue to deal with gdCacheSetup thread
safety: http://public.vbulletin.com/bugs/php/gdcache-patch-2.txt






-- 
Edit this bug report at http://bugs.php.net/?id=40858&edit=1

#40858 [Asn]: Thread safety issue in GD

[scottmacvicar at ntlworld dot com]

 ID:   40858
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
 Status:   Assigned
 Bug Type: GD related
 Operating System: RHEL 4
 PHP Version:  5.2.1
 Assigned To:  pajoye
 New Comment:

Moving the code to PHP_MINIT fixes the problem for PHP but the
threading options of GD doesn't extend itself to this setup since the
function to create the mutex can be called more than once in a short
period of time.

This small race condition could be fixed by using pthread_once to
ensure the mutexes are allocated only once but I'm unsure of the Win32
equivalent.

I've got a patch that implements the PHP solution running on our boxes,
I can provide it if interested.


Previous Comments:


[2007-03-19 19:27:31] [EMAIL PROTECTED]

Did we not put it inside in the latest version of the last patch? I do
not have the code at hand but as far as I remember Nuno updated it. I
will check again tonight.



[2007-03-19 19:24:54] [EMAIL PROTECTED]

>The first problem looks weird. It defeats the whole purpose of the
mutex.
The !=NULL check is out of the mutex protected block.



[2007-03-19 19:22:00] [EMAIL PROTECTED]

Yes, we noticed the cacheSetup problem too. One solution is to
initialize it in MINIT and destroy it in MSHUTDOWN. I'm working on patch
to implement this solution.

The first problem looks weird. It defeats the whole purpose of the
mutex. I do not have the time now to test. I will give it a try later
this week.



[2007-03-19 19:13:02] scottmacvicar at ntlworld dot com

I should have mentioned, the first patch deals with the segfault so it
errors out gracefully. We've got this running on production now.

The second patch is an attempt to deal with the race condition that's
still present, would probably be simplier to just to call
gdFontCacheSetup() again but I'm unsure what the behaviour is of setting
up a mutex thats already initialised and then locking it.



[2007-03-19 18:53:45] [EMAIL PROTECTED]

Assigned to the maintainer.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40858

-- 
Edit this bug report at http://bugs.php.net/?id=40858&edit=1

#40858 [Fbk->Opn]: Thread safety issue in GD

[scottmacvicar at ntlworld dot com]

 ID:   40858
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
-Status:   Feedback
+Status:   Open
 Bug Type: GD related
 Operating System: RHEL 4
 PHP Version:  5.2.1
 Assigned To:  pajoye
 New Comment:

Patch is available at
http://public.vbulletin.com/bugs/php/gd-mutex-patch.txt

Quick explanation:
* The mutex is created at module startup and destroyed at module
shutdown courtesy of two new helper functions within the libGD code
base.
* The mutex is no longer destroyed at request shutdown.
* Locking is performed prior to checking fontCache to prevent the race
condition we're seeing.

This can't be merged back into libGD at the moment since it breaks
backwards compatibility by assuming a mutex has been allocated, the way
to fix this for pthread is fairly easy.

#define gdMutexDeclare(x) pthread_mutex_t x
#define gdMutexDeclare(x) pthread_mutex_t x
becomes
#define gdMutexDeclare(x) static pthread_mutex_t x =
PTHREAD_MUTEX_INITIALIZER
#define gdMutexSetup(x)

That would just leave the win32 implementation to deal with via
DLLMain, a quick patch to add that would only take a few minutes though
I don't have VC6 installed yet.


Previous Comments:


[2007-03-21 00:48:56] [EMAIL PROTECTED]

"Moving the code to PHP_MINIT fixes the problem for PHP but the
threading options of GD doesn't extend itself to this setup since the
function to create the mutex can be called more than once in a short
period of time."

Do you mean for libGD itself used a library in a random project? If
yes, a solution is very similar to this one. We have to do it at load
time (like DLLMain on windows). Many other libraries (and many related
to FT2, with ft2 cache or their own) rely on this solution. We can give
it a try, at least.

"I've got a patch that implements the PHP solution running on our
boxes, I can provide it if interested."

You can always post it, I still did not get the time to do it, so any
help is welcome.

--------

[2007-03-21 00:40:40] scottmacvicar at ntlworld dot com

Moving the code to PHP_MINIT fixes the problem for PHP but the
threading options of GD doesn't extend itself to this setup since the
function to create the mutex can be called more than once in a short
period of time.

This small race condition could be fixed by using pthread_once to
ensure the mutexes are allocated only once but I'm unsure of the Win32
equivalent.

I've got a patch that implements the PHP solution running on our boxes,
I can provide it if interested.



[2007-03-19 19:27:31] [EMAIL PROTECTED]

Did we not put it inside in the latest version of the last patch? I do
not have the code at hand but as far as I remember Nuno updated it. I
will check again tonight.



[2007-03-19 19:24:54] [EMAIL PROTECTED]

>The first problem looks weird. It defeats the whole purpose of the
mutex.
The !=NULL check is out of the mutex protected block.



[2007-03-19 19:22:00] [EMAIL PROTECTED]

Yes, we noticed the cacheSetup problem too. One solution is to
initialize it in MINIT and destroy it in MSHUTDOWN. I'm working on patch
to implement this solution.

The first problem looks weird. It defeats the whole purpose of the
mutex. I do not have the time now to test. I will give it a try later
this week.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40858

-- 
Edit this bug report at http://bugs.php.net/?id=40858&edit=1

#40858 [Asn]: Thread safety issue in GD

[scottmacvicar at ntlworld dot com]

 ID:   40858
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
 Status:   Assigned
 Bug Type: GD related
 Operating System: RHEL 4
 PHP Version:  5.2.1
 Assigned To:  pajoye
 New Comment:

I have some time to spare over the weekend and a copy of VC6 installed
now so I'll have a go at the win32 implementation.

Regarding the patch to the bundled GD library and the php wrapper, does
it look reasonable? We've been running it for the past 2 days now
without issue on a production server. I'd rather see something put into
5.2.2 and then fix libGD.


Previous Comments:


[2007-03-22 23:15:13] [EMAIL PROTECTED]

yep, having a statically declared mutex would fix the problems we are
having. I've a patch identical to yours
(http://mega.ist.utl.pt/~ncpl/libgd_mutexes.txt) for a while, but we are
still waiting for a win32 implementation to merge the patches (there is
another open bug report in the gd bugs db about a similar issue) to
definitely fix those nasty TS issues.



[2007-03-21 01:37:18] scottmacvicar at ntlworld dot com

Patch is available at
http://public.vbulletin.com/bugs/php/gd-mutex-patch.txt

Quick explanation:
* The mutex is created at module startup and destroyed at module
shutdown courtesy of two new helper functions within the libGD code
base.
* The mutex is no longer destroyed at request shutdown.
* Locking is performed prior to checking fontCache to prevent the race
condition we're seeing.

This can't be merged back into libGD at the moment since it breaks
backwards compatibility by assuming a mutex has been allocated, the way
to fix this for pthread is fairly easy.

#define gdMutexDeclare(x) pthread_mutex_t x
#define gdMutexDeclare(x) pthread_mutex_t x
becomes
#define gdMutexDeclare(x) static pthread_mutex_t x =
PTHREAD_MUTEX_INITIALIZER
#define gdMutexSetup(x)

That would just leave the win32 implementation to deal with via
DLLMain, a quick patch to add that would only take a few minutes though
I don't have VC6 installed yet.



[2007-03-21 00:48:56] [EMAIL PROTECTED]

"Moving the code to PHP_MINIT fixes the problem for PHP but the
threading options of GD doesn't extend itself to this setup since the
function to create the mutex can be called more than once in a short
period of time."

Do you mean for libGD itself used a library in a random project? If
yes, a solution is very similar to this one. We have to do it at load
time (like DLLMain on windows). Many other libraries (and many related
to FT2, with ft2 cache or their own) rely on this solution. We can give
it a try, at least.

"I've got a patch that implements the PHP solution running on our
boxes, I can provide it if interested."

You can always post it, I still did not get the time to do it, so any
help is welcome.

----------------

[2007-03-21 00:40:40] scottmacvicar at ntlworld dot com

Moving the code to PHP_MINIT fixes the problem for PHP but the
threading options of GD doesn't extend itself to this setup since the
function to create the mutex can be called more than once in a short
period of time.

This small race condition could be fixed by using pthread_once to
ensure the mutexes are allocated only once but I'm unsure of the Win32
equivalent.

I've got a patch that implements the PHP solution running on our boxes,
I can provide it if interested.



[2007-03-19 19:27:31] [EMAIL PROTECTED]

Did we not put it inside in the latest version of the last patch? I do
not have the code at hand but as far as I remember Nuno updated it. I
will check again tonight.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40858

-- 
Edit this bug report at http://bugs.php.net/?id=40858&edit=1

#40858 [Asn]: Thread safety issue in GD

[scottmacvicar at ntlworld dot com]

 ID:   40858
 User updated by:  scottmacvicar at ntlworld dot com
 Reported By:  scottmacvicar at ntlworld dot com
 Status:   Assigned
 Bug Type: GD related
 Operating System: RHEL 4
 PHP Version:  5.2.1
 Assigned To:  pajoye
 New Comment:

I don't have access to a Windows machine at the moment but the
following patch should fix the issues in libGD, I'll try and do a test
when I have access to the machine.

PHP 5.2 Patch: http://public.vbulletin.com/bugs/php/gd-mutex-patch.txt
libGD Patch:
http://public.vbulletin.com/bugs/php/libgd-mutex-patch.txt

Explanation:
* pthread now initialises the mutex only once
* win32 can set the mutex within DLLMain
* Race condition fix by locking prior to checking font cache

Problems not fixed:
* calling gdFontCacheSetup before obtaining a lock is going to cause
the race condition still, I know the ruby wrappers do this.
* Unusure about behaviour of using the non bundled GD library on
windows with PHP since DLLMain and gdFontCacheMutexSetup may setup the
critical section twice. Could make gdMutexSetup(x) a no-op for win32
too.


Previous Comments:


[2007-03-23 01:21:26] [EMAIL PROTECTED]

Hi Scott, Nuno,

"Regarding the patch to the bundled GD library and the php wrapper,
does it look reasonable? We've been running it for the past 2 days now
without issue on a production server. I'd rather see something put
into
5.2.2 "

Yes, the patch for php (and unix) looks good. I will apply it during
the weekend as well (or Nuno, you can do it if you have the time
before).

For the windows version, that's a good news, thanks to take the time to
work on it.

----

[2007-03-23 00:31:35] scottmacvicar at ntlworld dot com

I have some time to spare over the weekend and a copy of VC6 installed
now so I'll have a go at the win32 implementation.

Regarding the patch to the bundled GD library and the php wrapper, does
it look reasonable? We've been running it for the past 2 days now
without issue on a production server. I'd rather see something put into
5.2.2 and then fix libGD.



[2007-03-22 23:15:13] [EMAIL PROTECTED]

yep, having a statically declared mutex would fix the problems we are
having. I've a patch identical to yours
(http://mega.ist.utl.pt/~ncpl/libgd_mutexes.txt) for a while, but we are
still waiting for a win32 implementation to merge the patches (there is
another open bug report in the gd bugs db about a similar issue) to
definitely fix those nasty TS issues.

------------

[2007-03-21 01:37:18] scottmacvicar at ntlworld dot com

Patch is available at
http://public.vbulletin.com/bugs/php/gd-mutex-patch.txt

Quick explanation:
* The mutex is created at module startup and destroyed at module
shutdown courtesy of two new helper functions within the libGD code
base.
* The mutex is no longer destroyed at request shutdown.
* Locking is performed prior to checking fontCache to prevent the race
condition we're seeing.

This can't be merged back into libGD at the moment since it breaks
backwards compatibility by assuming a mutex has been allocated, the way
to fix this for pthread is fairly easy.

#define gdMutexDeclare(x) pthread_mutex_t x
#define gdMutexDeclare(x) pthread_mutex_t x
becomes
#define gdMutexDeclare(x) static pthread_mutex_t x =
PTHREAD_MUTEX_INITIALIZER
#define gdMutexSetup(x)

That would just leave the win32 implementation to deal with via
DLLMain, a quick patch to add that would only take a few minutes though
I don't have VC6 installed yet.



[2007-03-21 00:48:56] [EMAIL PROTECTED]

"Moving the code to PHP_MINIT fixes the problem for PHP but the
threading options of GD doesn't extend itself to this setup since the
function to create the mutex can be called more than once in a short
period of time."

Do you mean for libGD itself used a library in a random project? If
yes, a solution is very similar to this one. We have to do it at load
time (like DLLMain on windows). Many other libraries (and many related
to FT2, with ft2 cache or their own) rely on this solution. We can give
it a try, at least.

"I've got a patch that implements the PHP solution running on our
boxes, I can provide it if interested."

You can always post it, I still did not get the time to do it, so any
help is welcome.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40858

-- 
Edit this bug report at http://bugs.php.net/?id=40858&edit=1

#36867 [Com]: sqlite_escape_string on '' or null returns wrong value

[scottmacvicar at ntlworld dot com]

 ID:   36867
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  mpb dot mail at gmail dot com
 Status:   Open
 Bug Type: SQLite related
 Operating System: FreeBSD 4.x
 PHP Version:  4.4.2
 New Comment:

This was fixed in the PECL CVS there just happens to have been no
release since the bug was fixed.

Last release was 18th July 2004, the bug was fixed 27th July 2004.

If you compile a CVS copy it will work fine.

Perhaps Wez can make another release.


Previous Comments:


[2006-03-27 02:30:35] mpb dot mail at gmail dot com

Description:

sqlite_escape_string on '' (the empty string) or null returns the wrong
value.

I would guess that:

sqlite_escape_string ('') should return '',

and

sqlite_escape_string (null) should return null.

Additionally, you can see that what sqlite_escape_string actually does
return in these cases is a mangled version of the previous non-null
input string.

This bug appears to have been fixed in PHP5, but not yet in PHP4.
http://bugs.php.net/bug.php?id=29339
http://bugs.php.net/bug.php?id=29395

Reproduce code:
---



Expected result:

787878


done


Actual result:
--
787878
ac7878
ac7878
done






-- 
Edit this bug report at http://bugs.php.net/?id=36867&edit=1

#36943 [Com]: SCGI support

[scottmacvicar at ntlworld dot com]

 ID:   36943
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  webstorm at netcourrier dot com
 Status:   Feedback
 Bug Type: Feature/Change Request
 Operating System: Windows
 PHP Version:  5.1.2
 New Comment:

It's just another FastCGI type protocol but far easier to implement,
see http://python.ca/nas/scgi/protocol.txt for the spec.

Creating a SCGI API would be fairly straight forward.


Previous Comments:


[2006-04-01 20:05:20] [EMAIL PROTECTED]

PHP also supports FastCGI or it's not enough for Java web-server?



[2006-04-01 19:57:17] webstorm at netcourrier dot com

Description:

SCGI doesn't seems to be supported by PHP.

Running PHP as CGI is slow, and using PHP as Apache module is not an
option as I'm develloping a web server using Java.







-- 
Edit this bug report at http://bugs.php.net/?id=36943&edit=1

#36971 [Com]: unset() no longer works on $this in PHP5

[scottmacvicar at ntlworld dot com]

 ID:   36971
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  k at phpkoala dot com
 Status:   Open
 Bug Type: Class/Object related
 Operating System: Linux
 PHP Version:  5.1.2
 New Comment:

Destroying an object internally is an absurd concept, how can you
destroy something that is currently in the scope of execution?

The reason it works in PHP 4 and not in PHP 5 is that object types are
no longer mutable.


Previous Comments:


[2006-04-04 23:18:38] k at phpkoala dot com

Mike, I am serious or I would not have taken the time to post this bug
report.

The manual page for unset, over at
http://www.php.net/manual/en/function.unset.php, does not mention this
change in functionality. Like I said in my first message, this is
something that works in PHP4 but no longer works in PHP5.

If you can't believe I am serious, please point out why you think this
is a joke? How do you destroy a class instance internally in PHP5? And
if this is never going to happen, can't you say this in the manual,
along with an explanation?

If nothing else, the very fact that it worked in PHP4 and does not work
in PHP5 should merit a mention in the documentation. (Just Google for
this issue and you will see many pieces of software that have broken
because of this, when used on PHP5.)

Back to you, Mike.



[2006-04-04 19:33:07] [EMAIL PROTECTED]

I can't believe you're serious.



[2006-04-04 19:25:26] k at phpkoala dot com

Description:

In PHP4, calling unset($this) within a class worked fine, and destroyed
that class instance. This was a very useful way technique, one that I
and others have used many times.

In PHP5, it simply no longer works. There is no error message - not
even a strict - the instance is just unaffected.

PHP4 also offers another method - setting $this = NULL, but PHP5 gives
an error that $this cannot be reassigned.

I would like to see this functionality restored, or, an alternate
mechanism for destroying class instances internally should be pointed
out (and put into the manual), or, if for some unknown reason this
useful functionality is now declared by the PHP staff to be evil, the
reasons should be revealed and the appropriate details put into the
manual so that we know it know longer works in PHP5, and why.

I figure it's just a bug ;)

Reproduce code:
---
class test {
function f1() {
unset($this);
}
function f2() {
$this = NULL;
}
}

$obj = new test;
var_dump($obj);

$obj->f1();
var_dump($obj);

$obj->f2();
var_dump($obj);

unset($obj);
var_dump($obj);

Expected result:

object(test)(0) {
}
NULL
NULL
NULL

Note: if f1() worked, there would be no need to run f2(), because $obj
would have been unset. But, both methods should result in $obj being
NULL.

OR:

object(test)(0) {
}
object(test)(0) {
}
NULL
NULL

This would also be an acceptable result, because there is an alternate
method (f2()) that can be used. This is the result from the latest
version of PHP4.

Actual result:
--
>From PHP5:

Fatal error: Cannot re-assign $this in /home/test2.php on line 6

So, f2(), which sets $this to NULL, doesn't work. Commenting that out
produces:

object(test)#1 (0) {
}
object(test)#1 (0) {
}
NULL

So, neither of the methods f1() or f2() work.


>From the latest version of PHP4:

object(test)(0) {
}
object(test)(0) {
}
NULL
NULL

This is fine, as the desired effect can still be accomplished.


In earlier versions of PHP4, both f1() and f2() work fine.





-- 
Edit this bug report at http://bugs.php.net/?id=36971&edit=1

#37012 [Com]: ini_get('cgi.fix_pathinfo') broken

[scottmacvicar at ntlworld dot com]

 ID:   37012
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  ms419 at freezone dot co dot uk
 Status:   Feedback
 Bug Type: PHP options/info functions
 Operating System: Debian
 PHP Version:  4.4.2
 New Comment:

ini_get only works on items that have STD_PHP_INI_ entries,
unfortunately the cgi module does not have that entry so you can't use
ini_get.

The only other solution is get_cfg_var


test1 ~ # fgrep "cgi.fix_pathinfo" /etc/php/cgi-php5/php.ini
cgi.fix_pathinfo = 1

test1 ~ # php-cgi

X-Powered-By: PHP/5.1.2-gentoo
Content-type: text/html

string(0) ""

test1 gentoo-php-overlay # php-cgi

X-Powered-By: PHP/5.1.2-gentoo
Content-type: text/html

string(1) "1"



Previous Comments:


[2006-04-07 18:26:14] [EMAIL PROTECTED]

Make sure this particular PHP executable uses the same php.ini file.
Hint: `php -i | grep php.ini`



[2006-04-07 18:15:30] ms419 at freezone dot co dot uk

Description:

ini_get('cgi.fix_pathinfo') is broken

I can tell from my php.ini & from the behavior of PHP that
cgi.fix_pathinfo=1

However -


fis% /usr/lib/cgi-bin/php4

X-Powered-By: PHP/4.4.2-1+b1
Content-type: text/html

string(0) ""
fis% 


Thanks - Jack






-- 
Edit this bug report at http://bugs.php.net/?id=37012&edit=1

#37107 [Com]: mktime function

[scottmacvicar at ntlworld dot com]

 ID:   37107
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  eyglys at yahoo dot com dot br
 Status:   Open
 Bug Type: Date/time related
 Operating System: Linux
 PHP Version:  5.1.2
 New Comment:

Read http://www.php.net/manual/en/function.date.php

m prints the month number with leading 0, hence why H:m:s produces
10:01:40


Previous Comments:


[2006-04-17 16:01:06] eyglys at yahoo dot com dot br

Description:

mktime don't read a param minutes.

Reproduce code:
---


Expected result:

01/01/1970 10:30:40

Actual result:
--
01/01/1970 10:01:40





-- 
Edit this bug report at http://bugs.php.net/?id=37107&edit=1

#34409 [Com]: concatenating a "\n" to a single character string produces incorrect output

[scottmacvicar at ntlworld dot com]

 ID:   34409
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  dskiles at docfinity dot com
 Status:   Open
 Bug Type: Strings related
 Operating System: Windows XP sp2
 PHP Version:  5.0.5
 New Comment:

I can't reproduce this.

[EMAIL PROTECTED] www]# php -v
PHP 5.0.6-dev (cli) (built: Sep  5 2005 18:38:22)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.5, Copyright (c) 1998-2004 Zend Technologies
[EMAIL PROTECTED] www]# php bugtest.php
a
b
c
d


Previous Comments:


[2005-09-07 16:28:39] dskiles at docfinity dot com

I tried this with the latest CVS and got the same result.

Single character strings:


MultiCharacter strings:
aa
bb
cc
dd

Multiple Newlines:
a

b

c

d



[2005-09-07 16:17:35] [EMAIL PROTECTED]

Works just fine here.
Also, line endings on windows are \r\n, not \n. 



[2005-09-07 16:14:56] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

And can't you really come up with a shorter reproduce script?




[2005-09-07 15:50:30] dskiles at docfinity dot com

Description:

I've been running into a problem where a single character string will
turn into a '?' character when I attempt to concatenate it or
interpolate it with a single "\n" character.

If I use a multi-character string or multiple "\n" characters I don't
get '?' characters anymore.

I'm running this from the console.

Reproduce code:
---
factors = array();
$this->factorMaps = array();
$this->mode = $mode;
}

public function addFactorValues($factor, $values) {
if (!isset($this->factors[$factor])) {
$this->factors[$factor] = array();
}
$this->factors[$factor] = array_merge($this->factors[$factor],
$values);
//todo:  update the factormaps if any factors were added
}

public function getFactorValues($factor) {
return $this->factors[$factor];
}
}

?>

/

addFactorValues('test', array('a', 'b', 'c', 'd'));
foreach($enviro->getFactorValues('test') as $val) {
echo("$val\n");
}

?>

Expected result:

a
b
c
d

Actual result:
--






-- 
Edit this bug report at http://bugs.php.net/?id=34409&edit=1

#34409 [Com]: concatenating a "\n" to a single character string produces incorrect output

[scottmacvicar at ntlworld dot com]

 ID:   34409
 Comment by:   scottmacvicar at ntlworld dot com
 Reported By:  dskiles at docfinity dot com
 Status:   Open
 Bug Type: Strings related
 Operating System: Windows XP sp2
 PHP Version:  5.0.5
 New Comment:

Try this then, though i can't see why it woudl end up one character.
Are you sure your using the latest CVS version?

Check php -v

echo("$val" . PHP_EOL);


Previous Comments:


[2005-09-07 17:29:14] dskiles at docfinity dot com

I get this result back:

string(2) "a
"
string(3) "a
"

Does PHP not offer a universal "\n", like Python or Java?



[2005-09-07 17:24:50] [EMAIL PROTECTED]

Try this code:





[2005-09-07 17:21:04] dskiles at docfinity dot com

Scott,
I noticed that you were using a UNIX shell, so I fired up Cygwin and
tried the same thing on my box.

Cygwin:
a
b
c
d

Windows Shell:


--------

[2005-09-07 17:13:33] scottmacvicar at ntlworld dot com

I can't reproduce this.

[EMAIL PROTECTED] www]# php -v
PHP 5.0.6-dev (cli) (built: Sep  5 2005 18:38:22)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.5, Copyright (c) 1998-2004 Zend Technologies
[EMAIL PROTECTED] www]# php bugtest.php
a
b
c
d



[2005-09-07 16:28:39] dskiles at docfinity dot com

I tried this with the latest CVS and got the same result.

Single character strings:


MultiCharacter strings:
aa
bb
cc
dd

Multiple Newlines:
a

b

c

d



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/34409

-- 
Edit this bug report at http://bugs.php.net/?id=34409&edit=1