[PHP-DEV] Bug #15350: Apache crashes when using PHP's magical __sleep() function
From: [EMAIL PROTECTED]
Operating system: Win 2k
PHP version: 4.1.0
PHP Bug Type: Reproducible crash
Bug description: Apache crashes when using PHP's magical __sleep() function
Using latest Apache V 1.3.22
Apache chrashes whith this code:
?php
class A {
function A() {}
function __sleep() {return;}
}
$a = new A();
$stream = serialize($a);
?
A also tested __wakeup() and that works OK.
--
Edit bug report at: http://bugs.php.net/?id=15350edit=1
Fixed in CVS: http://bugs.php.net/fix.php?id=15350r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=15350r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15350r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15350r=oldversion
Not for support: http://bugs.php.net/fix.php?id=15350r=support
Not wrong behavior: http://bugs.php.net/fix.php?id=15350r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15350r=notenoughinfo
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #15092 Updated: xml_parse() fails if XML-data contains entity like nbsp; or copy; ...
ID: 15092
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: XML related
Operating System: Win 2k (all I gues)
PHP Version: 4.1.0
New Comment:
After some more testes I found that the only literal entities that work
are: amp;, lt; gt; and quot;.
*ALL* others (like nbsp; copy; a.s.o.) cause an
XML_ERROR_UNDEFINED_ENTITY error.
The best work around to this problem, is to tranlate the entities
found in the XML source to theire numeric equivalent E.g. nbsp; to
#160; / copy; to #169; a.s.o.
Following function will do the job:
/**
* Translate literal entities to their numeric equivalents and vice
versa.
*
* PHP's XML parser (in V 4.1.0) has problems with entities! The only
one's that are recognized
* are amp;, lt; gt; and quot;. *ALL* others (like nbsp; copy;
a.s.o.) cause an
* XML_ERROR_UNDEFINED_ENTITY error. I reported this as bug at
http://bugs.php.net/bug.php?id=15092
* The work around is to translate the entities found in the XML
source to their numeric equivalent
* E.g. nbsp; to #160; / copy; to #169; a.s.o.
*
* NOTE: Entities amp;, lt; gt; and quot; are left 'as is'
*
* @author Sam Blum [EMAIL PROTECTED]
* @param string $xmlSource The XML string
* @param bool $reverse (default=FALSE) Translate numeric entities
to literal entities.
* @return The XML string with translatet entities.
*/
function _translateLiteral2NumericEntities($xmlSource, $reverse =
FALSE) {
static $literal2NumericEntity;
if (empty($literal2NumericEntity)) {
$transTbl = get_html_translation_table(HTML_ENTITIES);
foreach ($transTbl as $char = $entity) {
if (strpos('', $char) !== FALSE) continue;
$literal2NumericEntity[$entity] = '#'.ord($char).';';
}
}
if ($reverse) {
return strtr($xmlSource, array_flip($literal2NumericEntity));
} else {
return strtr($xmlSource, $literal2NumericEntity);
}
}
Previous Comments:
[2002-01-17 21:03:07] [EMAIL PROTECTED]
PHP XML-parser has problems with the full iso8859-1 char set when
trying to use entity names. E.g. the parser will fail with undefined
entity if the XML data you parse contains nbsp; or copy; a.s.o.
(there many more).
Some entities do work, like lt; gt; amp; as well as the alternative
notation unsing the ISO-code number: like non-breaking space ===
#160;
For a full iso8859-1 list and it's entities see:
http://www.ramsch.org/martin/uni/fmi-hp/iso8859-1.html
Here's the test script you can use to check the error :
?php
$xmlString[0] = AAA#160;/AAA;
$xmlString[1] = AAAnbsp;/AAA;
function startElement($xml_parser, $name, $attrs) {}
function endElement($xml_parser, $name) {}
function characterData($xml_parser, $text) {echo Handling character
data: '.htmlspecialchars($text).'br;}
$xml_parser = xml_parser_create();
xml_set_element_handler($xml_parser, startElement, endElement);
xml_set_character_data_handler($xml_parser, characterData);
// Parse the XML data.
if (!xml_parse($xml_parser, $xmlString[1], TRUE)) {
echo XML error in given {$source} on line .
xml_get_current_line_number($xml_parser) .
' column ' . xml_get_current_column_number($xml_parser) .
'. Reason:' .
xml_error_string(xml_get_error_code($xml_parser));
}
?
Edit this bug report at http://bugs.php.net/?id=15092edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #15092: xml_parse() fails if XML-data contains entity like nbsp; or copy; ...
From: [EMAIL PROTECTED]
Operating system: Win 2k (all I gues)
PHP version: 4.1.0
PHP Bug Type: XML related
Bug description: xml_parse() fails if XML-data contains entity like nbsp; or copy;
...
PHP XML-parser has problems with the full iso8859-1 char set when trying to
use entity names. E.g. the parser will fail with undefined entity if the
XML data you parse contains nbsp; or copy; a.s.o. (there many more).
Some entities do work, like lt; gt; amp; as well as the alternative
notation unsing the ISO-code number: like non-breaking space === #160;
For a full iso8859-1 list and it's entities see:
http://www.ramsch.org/martin/uni/fmi-hp/iso8859-1.html
Here's the test script you can use to check the error :
?php
$xmlString[0] = AAA#160;/AAA;
$xmlString[1] = AAAnbsp;/AAA;
function startElement($xml_parser, $name, $attrs) {}
function endElement($xml_parser, $name) {}
function characterData($xml_parser, $text) {echo Handling character
data: '.htmlspecialchars($text).'br;}
$xml_parser = xml_parser_create();
xml_set_element_handler($xml_parser, startElement, endElement);
xml_set_character_data_handler($xml_parser, characterData);
// Parse the XML data.
if (!xml_parse($xml_parser, $xmlString[1], TRUE)) {
echo XML error in given {$source} on line .
xml_get_current_line_number($xml_parser) .
' column ' . xml_get_current_column_number($xml_parser) .
'. Reason:' . xml_error_string(xml_get_error_code($xml_parser));
}
?
--
Edit bug report at: http://bugs.php.net/?id=15092edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14798 Updated: session.gc_maxlifetime does not work (Reopen Bug ID #3793)
ID: 14798 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Session related Operating System: Win 2k PHP Version: 4.1.0 Previous Comments: [2002-01-08 06:22:40] [EMAIL PROTECTED] Any windows users can confirm this? What you mean by *any*? At least 3 users working with WIN 2k (Me, [EMAIL PROTECTED], [EMAIL PROTECTED]) 2 of them using FAT32. (See bug report #3793) BTW, gc_maxlifetime is in sec. and *explained* explicitly in php.ini IIRC. I read tfm! Read line 2 of my report above: session.gc_maxlifetime *documented* as a lifetime measured in seconds ... OK,OK if you say it's secs I'll believe you. I can't verify it because of the current bug. They're indications that the doc could have been wrong (Read my report above) [2002-01-06 20:14:03] [EMAIL PROTECTED] Any windows users can confirm this? BTW, gc_maxlifetime is in sec. and *explained* explicitly in php.ini IIRC. [2002-01-02 08:37:15] [EMAIL PROTECTED] Befor going into the bug-report an importent question: session.gc_maxlifetime documented as a lifetime messured in *seconds* with default = 1440 1440s = 24min. hmm 24min ?? Expectiong the gc_maxlifetime to be rather long 24 min. seams a short time AND 24 relates more to 24h! So is it realy *seconds* ?! --- The Bug: As reported in Bug ID #3793 (from [EMAIL PROTECTED]) following still happens (taken from [EMAIL PROTECTED], 2000-12-07 and veryfied by [EMAIL PROTECTED], 2001-11-25): 1) session.gc_maxlifetime does not work - I set this to 60 sec, but I can read values from the session even when time expired. (I start the session and then I wait more than 60 sec before calling other script) 2) When I set session.gc_probability = 100 in php.ini, ALL other session files are deleted (only one session can be used at the time - if 2 clients are connected to server, the second client deletes session of the first client, etc.). . My Comment: To (1): This may be intended when using cookies! Because if session.cookie_lifetime is =0 (until browser is restarted) finding a valid SID in the cookie may prevent the gc from destroying the session data. (The doc leves this open). To (2): For testing I've set session.gc_probability = 50 but the effect is the same. As soon as the gc runs, all other session-files are deleted. gc_maxlifetime has no influance. [EMAIL PROTECTED] wrote that it may have to do with 'atime' and I would think so too. I would consider to use 'mtime' (maybe as fallback). Even the PHP-manual makes restriktions to 'atime': Some Unix filesystems can be mounted with atime updates disabled to increase the performance. [Session] session.gc_probability = 100 session.gc_maxlifetime = 60 session.save_handler = files session.save_path = c:\tmp\ session.use_cookies = 1 session.name = PHPSESSID session.auto_start = 0 session.cookie_lifetime = 0 session.cookie_path = / session.cookie_domain = session.serialize_handler = php session.referer_check = session.entropy_length = 0 session.entropy_file = ;session.entropy_length = 16 ;session.entropy_file = /dev/urandom session.cache_limiter = nocache session.cache_expire = 180 session.use_trans_sid = 1 Edit this bug report at http://bugs.php.net/?id=14798edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14798 Updated: session.gc_maxlifetime does not work (Reopen Bug ID #3793)
ID: 14798 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Win 2k PHP Version: 4.1.0 New Comment: I'm using FAT32 and mtime is working fine! I use mtime in 2 PHP objects I've wrote (a cache system and a extention to PHP's session handling) and mtime is fine! Again: [EMAIL PROTECTED] and I suspect the bug in *atime*!!! NOTE: Fat32 on Win has following effect as described by [EMAIL PROTECTED] under the user comment of fileatime() http://www.php.net/manual/en/function.fileatime.php: Windows *does* track file access times, however it seems (that FAT32) only keep track of the date a file was last accessed, ignoring the actual time, so if you try to pull the fileatime() for a file in Windows, you will get 00:00:00. You can verify this by right-clicking on any file in Windows explorer and viewing the properties of the file. If atime is beeing uses then this would explain way all session data is looked as garbage after 00:24. There must be a fallback *without* the use of atime because Some Unix filesystems can be mounted with atime updates disabled to increase the performance. and because of the Win FAT32 problem. Since you are using W2K, could you use NTFS, if not? I can't and don't want to switch to NTFS for several reasons: a) Even if it would work, you can't go and tell ppl to go and change the filesystem! b) I have a dual boot system and depend on the FAT32. Previous Comments: [2002-01-11 18:43:50] [EMAIL PROTECTED] Clarify: It sounds like problem is in filesystem used. Are you sure your FAT FS supports mtime? i.e. modified time? If you created the partition with old FAT FS. mtime is not supported and it will not work. Since you are using W2K, could you use NTFS, if not? BTW, I don't use W2K now, but files save handler worked for me with PHP 4.0.x. [2002-01-08 06:22:40] [EMAIL PROTECTED] Any windows users can confirm this? What you mean by *any*? At least 3 users working with WIN 2k (Me, [EMAIL PROTECTED], [EMAIL PROTECTED]) 2 of them using FAT32. (See bug report #3793) BTW, gc_maxlifetime is in sec. and *explained* explicitly in php.ini IIRC. I read tfm! Read line 2 of my report above: session.gc_maxlifetime *documented* as a lifetime measured in seconds ... OK,OK if you say it's secs I'll believe you. I can't verify it because of the current bug. They're indications that the doc could have been wrong (Read my report above) [2002-01-06 20:14:03] [EMAIL PROTECTED] Any windows users can confirm this? BTW, gc_maxlifetime is in sec. and *explained* explicitly in php.ini IIRC. [2002-01-02 08:37:15] [EMAIL PROTECTED] Befor going into the bug-report an importent question: session.gc_maxlifetime documented as a lifetime messured in *seconds* with default = 1440 1440s = 24min. hmm 24min ?? Expectiong the gc_maxlifetime to be rather long 24 min. seams a short time AND 24 relates more to 24h! So is it realy *seconds* ?! --- The Bug: As reported in Bug ID #3793 (from [EMAIL PROTECTED]) following still happens (taken from [EMAIL PROTECTED], 2000-12-07 and veryfied by [EMAIL PROTECTED], 2001-11-25): 1) session.gc_maxlifetime does not work - I set this to 60 sec, but I can read values from the session even when time expired. (I start the session and then I wait more than 60 sec before calling other script) 2) When I set session.gc_probability = 100 in php.ini, ALL other session files are deleted (only one session can be used at the time - if 2 clients are connected to server, the second client deletes session of the first client, etc.). . My Comment: To (1): This may be intended when using cookies! Because if session.cookie_lifetime is =0 (until browser is restarted) finding a valid SID in the cookie may prevent the gc from destroying the session data. (The doc leves this open). To (2): For testing I've set session.gc_probability = 50 but the effect is the same. As soon as the gc runs, all other session-files are deleted. gc_maxlifetime has no influance. [EMAIL PROTECTED] wrote that it may have to do with 'atime' and I would think so too. I would consider to use 'mtime' (maybe as fallback). Even the PHP-manual makes restriktions to 'atime': Some Unix filesystems can be mounted with atime updates disabled to increase the performance. [Session] session.gc_probability = 100 session.gc_maxlifetime = 60 session.save_handler = files session.save_path = c:\tmp\ session.use_cookies = 1 session.name = PHPSESSID session.auto_start = 0 session.cookie_lifetime = 0 session.cookie_path = / session.cookie_domain =
[PHP-DEV] Bug #14798 Updated: session.gc_maxlifetime does not work (Reopen Bug ID #3793)
ID: 14798 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Session related Operating System: Win 2k PHP Version: 4.1.0 New Comment: OK, as I thought: The test (see top entry) works on Win with NTFS. What I did: a) I set session.gc_probability = 100 b) I mad a little FAT32 partition on F: and a NTFS partition G: The bug *only appears* when using FAT32: session.save_path = F:\tmp Session works fine when using NTFS: session.save_path = G:\tmp So it MUST be a *atime* related problem. Previous Comments: [2002-01-13 16:22:13] [EMAIL PROTECTED] Ok, I'll assume your FAT FS supports mtime. However, I still have to ask you if it work with NTFS. I don't use Windows now . If there is a problem, I think problem is in TSRM code ;) [2002-01-13 16:01:19] [EMAIL PROTECTED] I'm using FAT32 and mtime is working fine! I use mtime in 2 PHP objects I've wrote (a cache system and a extention to PHP's session handling) and mtime is fine! Again: [EMAIL PROTECTED] and I suspect the bug in *atime*!!! NOTE: Fat32 on Win has following effect as described by [EMAIL PROTECTED] under the user comment of fileatime() http://www.php.net/manual/en/function.fileatime.php: Windows *does* track file access times, however it seems (that FAT32) only keep track of the date a file was last accessed, ignoring the actual time, so if you try to pull the fileatime() for a file in Windows, you will get 00:00:00. You can verify this by right-clicking on any file in Windows explorer and viewing the properties of the file. If atime is beeing uses then this would explain way all session data is looked as garbage after 00:24. There must be a fallback *without* the use of atime because Some Unix filesystems can be mounted with atime updates disabled to increase the performance. and because of the Win FAT32 problem. Since you are using W2K, could you use NTFS, if not? I can't and don't want to switch to NTFS for several reasons: a) Even if it would work, you can't go and tell ppl to go and change the filesystem! b) I have a dual boot system and depend on the FAT32. [2002-01-11 18:43:50] [EMAIL PROTECTED] Clarify: It sounds like problem is in filesystem used. Are you sure your FAT FS supports mtime? i.e. modified time? If you created the partition with old FAT FS. mtime is not supported and it will not work. Since you are using W2K, could you use NTFS, if not? BTW, I don't use W2K now, but files save handler worked for me with PHP 4.0.x. [2002-01-08 06:22:40] [EMAIL PROTECTED] Any windows users can confirm this? What you mean by *any*? At least 3 users working with WIN 2k (Me, [EMAIL PROTECTED], [EMAIL PROTECTED]) 2 of them using FAT32. (See bug report #3793) BTW, gc_maxlifetime is in sec. and *explained* explicitly in php.ini IIRC. I read tfm! Read line 2 of my report above: session.gc_maxlifetime *documented* as a lifetime measured in seconds ... OK,OK if you say it's secs I'll believe you. I can't verify it because of the current bug. They're indications that the doc could have been wrong (Read my report above) [2002-01-06 20:14:03] [EMAIL PROTECTED] Any windows users can confirm this? BTW, gc_maxlifetime is in sec. and *explained* explicitly in php.ini IIRC. 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/?id=14798 Edit this bug report at http://bugs.php.net/?id=14798edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14785 Updated: cannot save data with session_register() in functions
ID: 14785
Comment by: [EMAIL PROTECTED]
Old Reported By: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: Debian Linux
PHP Version: 4.1.0
New Comment:
This is not a Bug. All variables that you plan to register must be
global!
Reason:
The PHP-function session_register() only 'remember' the *names* of the
variables (not the content) it must save when the script terminates.
The session vars are read at script end. This happens outside of any
function or methode and therefor only global vars that have been set
have a value; all others are unset.
Previous Comments:
[2002-01-01 01:18:46] [EMAIL PROTECTED]
session_register() doesnt seem to save anything in functions, eg.
session_start();
function bob() {
$var = somethinghere;
session_register(var);
}
bob();
echo session_encode();
the above only registers the var name, not the data in it.
if it helps theres a way around it, all you gota do is make the $var
global so instead of having $var have $GLOBALS['var'] and it works
fine.
might be little bug, but it stuffed me up 4 nights in a row.
oh and the way i compiled php was just with apt-get install php4 in
debian, (newbie here)
Edit this bug report at http://bugs.php.net/?id=14785edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14798 Updated: session.gc_maxlifetime does not work (Reopen Bug ID #3793)
ID: 14798 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Win 2k PHP Version: 4.1.0 New Comment: Any windows users can confirm this? What you mean by *any*? At least 3 users working with WIN 2k (Me, [EMAIL PROTECTED], [EMAIL PROTECTED]) 2 of them using FAT32. (See bug report #3793) BTW, gc_maxlifetime is in sec. and *explained* explicitly in php.ini IIRC. I read tfm! Read line 2 of my report above: session.gc_maxlifetime *documented* as a lifetime measured in seconds ... OK,OK if you say it's secs I'll believe you. I can't verify it because of the current bug. They're indications that the doc could have been wrong (Read my report above) Previous Comments: [2002-01-06 20:14:03] [EMAIL PROTECTED] Any windows users can confirm this? BTW, gc_maxlifetime is in sec. and *explained* explicitly in php.ini IIRC. [2002-01-02 08:37:15] [EMAIL PROTECTED] Befor going into the bug-report an importent question: session.gc_maxlifetime documented as a lifetime messured in *seconds* with default = 1440 1440s = 24min. hmm 24min ?? Expectiong the gc_maxlifetime to be rather long 24 min. seams a short time AND 24 relates more to 24h! So is it realy *seconds* ?! --- The Bug: As reported in Bug ID #3793 (from [EMAIL PROTECTED]) following still happens (taken from [EMAIL PROTECTED], 2000-12-07 and veryfied by [EMAIL PROTECTED], 2001-11-25): 1) session.gc_maxlifetime does not work - I set this to 60 sec, but I can read values from the session even when time expired. (I start the session and then I wait more than 60 sec before calling other script) 2) When I set session.gc_probability = 100 in php.ini, ALL other session files are deleted (only one session can be used at the time - if 2 clients are connected to server, the second client deletes session of the first client, etc.). . My Comment: To (1): This may be intended when using cookies! Because if session.cookie_lifetime is =0 (until browser is restarted) finding a valid SID in the cookie may prevent the gc from destroying the session data. (The doc leves this open). To (2): For testing I've set session.gc_probability = 50 but the effect is the same. As soon as the gc runs, all other session-files are deleted. gc_maxlifetime has no influance. [EMAIL PROTECTED] wrote that it may have to do with 'atime' and I would think so too. I would consider to use 'mtime' (maybe as fallback). Even the PHP-manual makes restriktions to 'atime': Some Unix filesystems can be mounted with atime updates disabled to increase the performance. [Session] session.gc_probability = 100 session.gc_maxlifetime = 60 session.save_handler = files session.save_path = c:\tmp\ session.use_cookies = 1 session.name = PHPSESSID session.auto_start = 0 session.cookie_lifetime = 0 session.cookie_path = / session.cookie_domain = session.serialize_handler = php session.referer_check = session.entropy_length = 0 session.entropy_file = ;session.entropy_length = 16 ;session.entropy_file = /dev/urandom session.cache_limiter = nocache session.cache_expire = 180 session.use_trans_sid = 1 Edit this bug report at http://bugs.php.net/?id=14798edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14798: session.gc_maxlifetime does not work (Reopen Bug ID #3793)
From: [EMAIL PROTECTED] Operating system: Win 2k PHP version: 4.1.0 PHP Bug Type: Session related Bug description: session.gc_maxlifetime does not work (Reopen Bug ID #3793) Befor going into the bug-report an importent question: session.gc_maxlifetime documented as a lifetime messured in *seconds* with default = 1440 1440s = 24min. hmm 24min ?? Expectiong the gc_maxlifetime to be rather long 24 min. seams a short time AND 24 relates more to 24h! So is it realy *seconds* ?! --- The Bug: As reported in Bug ID #3793 (from [EMAIL PROTECTED]) following still happens (taken from [EMAIL PROTECTED], 2000-12-07 and veryfied by [EMAIL PROTECTED], 2001-11-25): 1) session.gc_maxlifetime does not work - I set this to 60 sec, but I can read values from the session even when time expired. (I start the session and then I wait more than 60 sec before calling other script) 2) When I set session.gc_probability = 100 in php.ini, ALL other session files are deleted (only one session can be used at the time - if 2 clients are connected to server, the second client deletes session of the first client, etc.). . My Comment: To (1): This may be intended when using cookies! Because if session.cookie_lifetime is =0 (until browser is restarted) finding a valid SID in the cookie may prevent the gc from destroying the session data. (The doc leves this open). To (2): For testing I've set session.gc_probability = 50 but the effect is the same. As soon as the gc runs, all other session-files are deleted. gc_maxlifetime has no influance. [EMAIL PROTECTED] wrote that it may have to do with 'atime' and I would think so too. I would consider to use 'mtime' (maybe as fallback). Even the PHP-manual makes restriktions to 'atime': Some Unix filesystems can be mounted with atime updates disabled to increase the performance. [Session] session.gc_probability = 100 session.gc_maxlifetime = 60 session.save_handler = files session.save_path = c:\tmp\ session.use_cookies = 1 session.name = PHPSESSID session.auto_start = 0 session.cookie_lifetime = 0 session.cookie_path = / session.cookie_domain = session.serialize_handler = php session.referer_check = session.entropy_length = 0 session.entropy_file = ;session.entropy_length = 16 ;session.entropy_file = /dev/urandom session.cache_limiter = nocache session.cache_expire = 180 session.use_trans_sid = 1 -- Edit bug report at: http://bugs.php.net/?id=14798edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14479: ini_get('memory_limit') returns empty string (Not FALSE or so)
From: [EMAIL PROTECTED]
Operating system: W2k
PHP version: 4.1.0
PHP Bug Type: Feature/Change Request
Bug description: ini_get('memory_limit') returns empty string (Not FALSE or so)
ini_get('memory_limit') returns empty string (Not FALSE or so).
I understand that it may not be possable to set 'memory_limit' but at least
it should be possable to read it.
I would like to use it, to set a buffer size in % to the available
memory.
Also
ini_get('any value that is not in php.ini')
returns an empty string too. I would have expected FALSE.
--
Edit bug report at: http://bugs.php.net/?id=14479edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14479 Updated: ini_get('memory_limit') returns empty string (Not FALSE or so)
ID: 14479
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Assigned
Status: Open
Bug Type: Feature/Change Request
Operating System: W2k
PHP Version: 4.1.0
Old Assigned To: derick
Assigned To:
New Comment:
I'v managed to get the value with
get_cfg_var('memory_limit')
So it is more a documentation issu. :o)
I'v added a User Contributed Notes to ini_get()
Previous Comments:
[2001-12-13 05:14:08] [EMAIL PROTECTED]
checking this out
[2001-12-13 05:07:15] [EMAIL PROTECTED]
ini_get('memory_limit') returns empty string (Not FALSE or so).
I understand that it may not be possable to set 'memory_limit' but at least it should
be possable to read it.
I would like to use it, to set a buffer size in % to the available memory.
Also
ini_get('any value that is not in php.ini')
returns an empty string too. I would have expected FALSE.
Edit this bug report at http://bugs.php.net/?id=14479edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14454: Is_enum() is not part of PHP4.1.0, as noted in the chang list.
From: [EMAIL PROTECTED] Operating system: W2k PHP version: 4.1.0 PHP Bug Type: Feature/Change Request Bug description: Is_enum() is not part of PHP4.1.0, as noted in the chang list. In the change list you wrote: - Added support for single dimensional SafeArrays and Enumerations. Added an is_enum() function to check if a component implements an enumeration. (Alan, Harald) BUT calling is_enum() results in a Fatal error: Call to undefined function: is_enum() ALSO not part of the docu. Was it droped? -- Edit bug report at: http://bugs.php.net/?id=14454edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14454 Updated: Is_enum() is not part of PHP4.1.0, as noted in the change list.
ID: 14454 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Summary: Is_enum() is not part of PHP4.1.0, as noted in the chang list. Status: Open Bug Type: Feature/Change Request Operating System: W2k PHP Version: 4.1.0 New Comment: . Previous Comments: [2001-12-12 09:04:44] [EMAIL PROTECTED] In the change list you wrote: - Added support for single dimensional SafeArrays and Enumerations. Added an is_enum() function to check if a component implements an enumeration. (Alan, Harald) BUT calling is_enum() results in a Fatal error: Call to undefined function: is_enum() ALSO not part of the docu. Was it droped? Edit this bug report at http://bugs.php.net/?id=14454edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10555 Updated: .htaccess config setting cause sudden loss of PHP-include path or apache crash
ID: 10555
User Update by: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Configuration Issues
Description: .htaccess config setting cause sudden loss of PHP-include path or apache
crash
Problem has disappeared with the new version of php 4.0.5
Previous Comments:
---
[2001-04-29 13:55:16] [EMAIL PROTECTED]
ERROR:
==
A *VERY* tricky error only showning up under load.
A simple reproduceable sample is below and a guess of reason.
Error will show up if you use Apache (V3.1.19) and try to set the PHP include_path as
config setting in the .htaccess file (instead of using the php-ini file) as described
in chapter 3 of the PHP documentation.
E.g. content of the .htaccess:
php_value include_path c:varwwwphp
Setup as described above and refresh the sample below quickly few times and you'll see
the effect:
- Either the apache server will crash
OR
- A PHP Fatal error: Failed opening required 'empty.php' (include_path=' KÞ') in ...
on line 2
will display suddenly in one of the frames instead of OK. The content of
include_path is then random or an empty string.
REASON GUESS:
Either a PHP or Apache problem. When reading the .htaccess file it seams to cause a
pointer error. As this effect comes up under load, I guess it's a file pointer- or
cashing- problem.
WORK AROUND:
Don't use .htaccess for PHP config settings under windows.
SAMPLE:
===
2 Files empty.php and bug.php
A) empty.php: An empty PHP file that must be lying in the include_path (e.g.
c:varwwwphp).
B) bug.php: The code is at the end of this repport. Put it somewhere accessable by the
server and browse it. On success you should see 4x4 frames displaying OK. The error
case is described above.
?
require_once('empty.php');
$thisFile = $PHP_SELF;
if (!isSet($input)) $input=0;
if ($input2) {
$input++;
?
!-- frames --
frameset rows=50%,* cols=50%,*
frame src=? echo $thisFile; ??input=? echo $input; ?
frame src=? echo $thisFile; ??input=? echo $input; ?
frame src=? echo $thisFile; ??input=? echo $input; ?
frame src=? echo $thisFile; ??input=? echo $input; ?
/frameset
?
} else {
echo OK;
}
?
---
Full Bug description available at: http://bugs.php.net/?id=10555
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10555: .htaccess config setting cause sudden loss of PHP-include path or apache crash
From: [EMAIL PROTECTED]
Operating system: Windows NT 4.0 and 2000
PHP version: 4.0.4pl1
PHP Bug Type: *Configuration Issues
Bug description: .htaccess config setting cause sudden loss of PHP-include path or
apache crash
ERROR:
==
A *VERY* tricky error only showning up under load.
A simple reproduceable sample is below and a guess of reason.
Error will show up if you use Apache (V3.1.19) and try to set the PHP include_path as
config setting in the .htaccess file (instead of using the php-ini file) as described
in chapter 3 of the PHP documentation.
E.g. content of the .htaccess:
php_value include_path c:\var\www\php
Setup as described above and refresh the sample below quickly few times and you'll see
the effect:
- Either the apache server will crash
OR
- A PHP Fatal error: Failed opening required 'empty.php' (include_path=' KÞ') in ...
on line 2
will display suddenly in one of the frames instead of OK. The content of
include_path is then random or an empty string.
REASON GUESS:
Either a PHP or Apache problem. When reading the .htaccess file it seams to cause a
pointer error. As this effect comes up under load, I guess it's a file pointer- or
cashing- problem.
WORK AROUND:
Don't use .htaccess for PHP config settings under windows.
SAMPLE:
===
2 Files empty.php and bug.php
A) empty.php: An empty PHP file that must be lying in the include_path (e.g.
c:\var\www\php).
B) bug.php: The code is at the end of this repport. Put it somewhere accessable by the
server and browse it. On success you should see 4x4 frames displaying OK. The error
case is described above.
?
require_once('empty.php');
$thisFile = $PHP_SELF;
if (!isSet($input)) $input=0;
if ($input2) {
$input++;
?
!-- frames --
frameset rows=50%,* cols=50%,*
frame src=? echo $thisFile; ??input=? echo $input; ?
frame src=? echo $thisFile; ??input=? echo $input; ?
frame src=? echo $thisFile; ??input=? echo $input; ?
frame src=? echo $thisFile; ??input=? echo $input; ?
/frameset
?
} else {
echo OK;
}
?
--
Edit Bug report at: http://bugs.php.net/?id=10555edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
