#24825 [WFx]: ?xml tag mistaken for ?php
ID: 24825 User updated by: drbezborodow at webpathways dot com Reported By: drbezborodow at webpathways dot com Status: Wont fix Bug Type: Feature/Change Request Operating System: UNIX PHP Version: 4.3.2 New Comment: Thank you very much for your response. I posted my bug report at phpbuilder.com and they basically laughed at me. I had to explain that I am a new user of PHP and havn't been around to see previous versions. Where may I find more specific information about this php_flag short_open_tags off, that you mentioned? - Damien Bezborodow Previous Comments: [2003-07-27 00:51:33] [EMAIL PROTECTED] I completely sympathize with what you're saying, however this is a behavior which is not (directly) going to change. Allow me to explain why. What's catching the '?xml' tag is actually the scan for the short_open_tag version of '?'. When this type of open tag was first created, you're absolutely right, not enough attention was paid to the world outside of PHP. In the designers defense, XML was a much smaller blip on the radar at the time, and creating XML documents from PHP sources was not a priority. It is precisely because of this ambiguity that the long open tag was devised. However, in the interest of maintaining compatability with preexisting scripts, the short open tag was neither removed, nor was it modified to require a space between it and instruction code. If your hosting provider allows you to modify php.ini options I'd recommend turning short_open_tags off. With apache this can even be done on a per-virtualserver/per-directory basis using: php_flag short_open_tags off If not, I'm afraid your only option until (if?) the short open tag is fully disabled (don't hold your breath) is to use the echo ?xml; hack you mentioned. Sorry I couldn't give you a better response, and thank you for using PHP. [2003-07-27 00:07:46] drbezborodow at webpathways dot com Description: I am not totally sure which version of PHP my web server is using, but I am positive that it is PHP4+. The web host's website is: www.echoechoplus.com Getting to the point, the PHP server mistakes this tag: ?xml version=1.0 encoding=iso-8859-1? for the opening and closing of ?php and ? The truth is that the designers overlooked (as is understandable in such a huge project) the fact that there are other technologies out there other than PHP. The server belives that ?xml is really ?php so it says, sorry, you have made an error. We can't show you this page. The fact is: if I said, I wan't apples, the server shouldn't say, sorry, you spelt oranges incorrectly, please try again! ;) A temporary workaround for this problem is VERY simple: ?php print ?xml version=\1.0\ encoding=\iso-8859-1\? ? Reproduce code: --- Create a file named whatever you like with the php extension (ie whatever.php). In this document, put these XHTML tags in line one, save it and then run the page on a PHP server: ?xml version=1.0 encoding=iso-8859-1? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en Expected result: The tag would have been as normal: ?xml version=1.0 encoding=iso-8859-1? The PHP Engine should have had nothing to do with this tag. It is an XML tag, but the server thought it was the beginning and end of a PHP script. IE: ?php /*content*/ ? Actual result: -- Parse error: parse error in /home/hbsast/harriscoaches.com.au/index.php on line 1 -- Edit this bug report at http://bugs.php.net/?id=24825edit=1
#24825 [WFx]: ?xml tag mistaken for ?php
ID: 24825 Updated by: [EMAIL PROTECTED] Reported By: drbezborodow at webpathways dot com Status: Wont fix Bug Type: Feature/Change Request Operating System: UNIX PHP Version: 4.3.2 New Comment: Have a look at the manual: http://www.php.net/configuration.changes Previous Comments: [2003-07-27 01:34:02] drbezborodow at webpathways dot com Thank you very much for your response. I posted my bug report at phpbuilder.com and they basically laughed at me. I had to explain that I am a new user of PHP and havn't been around to see previous versions. Where may I find more specific information about this php_flag short_open_tags off, that you mentioned? - Damien Bezborodow [2003-07-27 00:51:33] [EMAIL PROTECTED] I completely sympathize with what you're saying, however this is a behavior which is not (directly) going to change. Allow me to explain why. What's catching the '?xml' tag is actually the scan for the short_open_tag version of '?'. When this type of open tag was first created, you're absolutely right, not enough attention was paid to the world outside of PHP. In the designers defense, XML was a much smaller blip on the radar at the time, and creating XML documents from PHP sources was not a priority. It is precisely because of this ambiguity that the long open tag was devised. However, in the interest of maintaining compatability with preexisting scripts, the short open tag was neither removed, nor was it modified to require a space between it and instruction code. If your hosting provider allows you to modify php.ini options I'd recommend turning short_open_tags off. With apache this can even be done on a per-virtualserver/per-directory basis using: php_flag short_open_tags off If not, I'm afraid your only option until (if?) the short open tag is fully disabled (don't hold your breath) is to use the echo ?xml; hack you mentioned. Sorry I couldn't give you a better response, and thank you for using PHP. [2003-07-27 00:07:46] drbezborodow at webpathways dot com Description: I am not totally sure which version of PHP my web server is using, but I am positive that it is PHP4+. The web host's website is: www.echoechoplus.com Getting to the point, the PHP server mistakes this tag: ?xml version=1.0 encoding=iso-8859-1? for the opening and closing of ?php and ? The truth is that the designers overlooked (as is understandable in such a huge project) the fact that there are other technologies out there other than PHP. The server belives that ?xml is really ?php so it says, sorry, you have made an error. We can't show you this page. The fact is: if I said, I wan't apples, the server shouldn't say, sorry, you spelt oranges incorrectly, please try again! ;) A temporary workaround for this problem is VERY simple: ?php print ?xml version=\1.0\ encoding=\iso-8859-1\? ? Reproduce code: --- Create a file named whatever you like with the php extension (ie whatever.php). In this document, put these XHTML tags in line one, save it and then run the page on a PHP server: ?xml version=1.0 encoding=iso-8859-1? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en Expected result: The tag would have been as normal: ?xml version=1.0 encoding=iso-8859-1? The PHP Engine should have had nothing to do with this tag. It is an XML tag, but the server thought it was the beginning and end of a PHP script. IE: ?php /*content*/ ? Actual result: -- Parse error: parse error in /home/hbsast/harriscoaches.com.au/index.php on line 1 -- Edit this bug report at http://bugs.php.net/?id=24825edit=1
#24827 [NEW]: ob_gzhandler overrides Vary header
From: phpnet at shredzone dot de
Operating system: Linux
PHP version: 4.3.2
PHP Bug Type: Unknown/Other Function
Bug description: ob_gzhandler overrides Vary header
Description:
I am using ob_gzhandler to compress the page output. Now I need to add an
'accept-language' to the Vary header, because my page content depends on
the language settings of the browser.
Anyhow, it is impossible to change the Vary header when using
ob_gzhandler. It seems like ob_gzhandler is overriding an existing Vary
header just before returning the compressed content to the browser.
Expected behaviour: ob_gzhandler should check if a Vary header has already
been set. If so, it should only ADD an accept-encoding unless already
present, or should not change the Vary header at all.
Reproduce code:
---
?php
header(vary: accept-encoding,accept-language);
ob_start('ob_gzhandler');
print(htmlbodyfoo/body/html);
?
Expected result:
A HTTP header vary: accept-encoding,accept-language being returned.
Actual result:
--
A HTTP header Vary: Accept-Encoding (note the uppercase letters) will
always be returned.
--
Edit bug report at http://bugs.php.net/?id=24827edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24827r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24827r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=24827r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24827r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24827r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24827r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24827r=support
Expected behavior: http://bugs.php.net/fix.php?id=24827r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24827r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24827r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24827r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24827r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24827r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24827r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24827r=gnused
#24828 [NEW]: round() function doesn't round !
From: christophe dot bidaux at netcourrier dot com Operating system: Windows 98SE PHP version: 4CVS-2003-07-27 (stable) PHP Bug Type: Math related Bug description: round() function doesn't round ! Description: the round() function doesn't give me the results described in the documentation example. Reproduce code: --- // from the documentation example $foo = round( 3.4 ); // $foo == 3.0 var_dump($foo); $foo = round( 3.5 ); // $foo == 4.0 var_dump($foo); $foo = round( 3.6 ); // $foo == 4.0 var_dump($foo); Expected result: float(3) float(4) float(4) (PHP Version 4.3.3RC1 version) Actual result: -- float(3) float(3) float(3) (PHP Version 4.3.3RC2-dev (Jul 27 2003 10:11:04) version) -- Edit bug report at http://bugs.php.net/?id=24828edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24828r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24828r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24828r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24828r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24828r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24828r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24828r=support Expected behavior: http://bugs.php.net/fix.php?id=24828r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24828r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24828r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24828r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24828r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24828r=dst IIS Stability: http://bugs.php.net/fix.php?id=24828r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24828r=gnused
#24699 [Ver-Csd]: Memory Leak with per-class constants
ID: 24699
Updated by: [EMAIL PROTECTED]
Reported By: fujimura at wakhok dot ac dot jp
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2003-07-24 (dev)
New Comment:
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.
Previous Comments:
[2003-07-24 16:29:58] [EMAIL PROTECTED]
[EMAIL PROTECTED] /usr/src/php5 $ php -r 'class TEST { const FOO =
SEEK_CUR; }'
/usr/src/php5/Zend/zend_language_scanner.l() : Freeing 0x406842B0
(9 bytes), script=-
[EMAIL PROTECTED] /usr/src/php5 $ php -r 'class TEST { const FOO = 1; }'
[EMAIL PROTECTED] /usr/src/php5 $ php -r 'class TEST { const FOO =
PHP_VERSION; }'
/usr/src/php5/Zend/zend_language_scanner.l() : Freeing 0x406842B0
(12 bytes), script=-
/usr/src/php5/Zend/zend_constants.c(290) : Freeing 0x40684268 (12
bytes), script=-
/usr/src/php5/Zend/zend_variables.c(111) : Actual location (location
was relayed)
/usr/src/php5/Zend/zend_compile.c(2349) : Freeing 0x40684220 (16
bytes), script=-
[2003-07-17 23:17:54] fujimura at wakhok dot ac dot jp
Description:
The per-class constant causes memory leaks used with builtin
constants.
configure line:
./configure \
--with-apxs=/usr/local/apache/bin/apxs \
--disable-short-tags \
--enable-versioning \
--enable-bcmath \
--enable-dio \
--enable-mbstring \
--enable-mbregex \
--enable-wddx \
--enable-dom \
--with-iconv \
--with-xsl \
--with-openssl \
--with-zlib \
--with-bz2 \
--enable-debug
Reproduce code:
---
[EMAIL PROTECTED] php-src]$ php -r 'class TEST { const FOO = SEEK_CUR; }'
/home/user/php-src/Zend/zend_language_scanner.l() : Freeing
0x40435334 (9 bytes), script=-
/home/user/php-src/Zend/zend_compile.c(2405) : Freeing 0x404352F0 (16
bytes), script=-
--
Edit this bug report at http://bugs.php.net/?id=24699edit=1
#24286 [Ver]: using array from class as function name
ID: 24286
Updated by: [EMAIL PROTECTED]
Reported By: terjeto at stud dot ntnu dot no
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: RedHat 9.0
PHP Version: 5CVS-2003-06-22 (dev)
New Comment:
Why with $object-attribute()
$object-method_name() should be called and not
$object-attribute() and how the engine is supposed to tell that? Is
$foo-x() now meaning call method 'x' of object '$foo' or take
property 'x' of object '$foo' and call method with this name on object
'$foo'? My opinion is that it _always_ should mean the latter and
never the former.
Previous Comments:
[2003-07-10 07:57:44] tony2001 at phpclub dot net
I expect that using attribute of the object as method name it will work
as it's already working with PHP4.
That is:
$object-attribute = 'method_name';
and with
$object-attribute();
$object-method_name(); should be called.
Maybe I'm wrong, but in case of $object-obj_attribute-attribute(); we
have the same situation - we're calling
$object-obj_attribite-{method, which name contains
$object-obj_attribute-attribute }();
Am I wrong?
[2003-07-10 07:19:37] [EMAIL PROTECTED]
What is expected to be result of $test_obj-array_var[0][0][0](simple
test) call?
Which function or method of which object should be called? What with
$test_obj-foo-array_var[0][0][0](simple test) - should the calling
object be $test_obj and function name array_var[0][0][0] (should it be
global $array_var[0][0][0]? global $foo-array_var[0][0][0]? or
property foo-array_var[0][0][0] of $test_obj?) or the calling object
should be $test_obj-foo and array_var[0][0][0] should be the method
name?
[2003-07-10 06:25:06] tony2001 at phpclub dot net
There is no matter what Smarty version do you use.
PHP complains on this syntax:
?
class Test {
var $array_var = Array();
function test() {
$this-array_var[0][0][0] = test_method;
}
function test_method($echo_var) {
echo $echo_var;
}
}
$test_obj = new test;
$test_obj-array_var[0][0][0](simple test); //line 15
?
Fatal error: Method name must be a string in /www/index.php on line 15
Guys, please, fix this very annoying bug at least in beta2.
On 10 Jul 2003 this bug still exists in CVS.
[2003-07-09 08:09:13] bloso at mailbr dot com dot br
I've got the same error message:
Fatal error: Method name must be a string in
/var/www/htdocs/scorphus/phplab/countracker/tpl/templates_c/%%200/%%2001463753/index.html.php
on line 28
index.html.php line 28:
br?php echo $this-_plugins['function']['eval'][0](array('var' =
$this-_config[0]['vars']['credits']), $this) ; ?
PHP Version: 5.0.0b2-dev (php5-200307071930.tar.gz)
Configure Command: './configure' '--with-mysql' '--with-apxs'
System: Slackware 9 (2.4.20) and Debian 3.0 r1 (2.4.20)
Also unsing: Smarty 2.4.2
Hope it helps,
Pablo.
[2003-06-29 10:55:12] [EMAIL PROTECTED]
Works fine in php 4.3.3, so this appears to be a BC issue.
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/24286
--
Edit this bug report at http://bugs.php.net/?id=24286edit=1
#24477 [Ver-Fbk]: Problem returning new class by ref from function
ID: 24477
Updated by: [EMAIL PROTECTED]
Reported By: karl at karlaustin dot com
-Status: Verified
+Status: Feedback
Bug Type: Zend Engine 2 problem
Operating System: RH7.3
PHP Version: 5CVS-2003-07-03 (dev)
New Comment:
What is the meaning of returning result of new by reference?
Previous Comments:
[2003-07-09 04:12:56] jsemczyk at elv dot enic dot fr
I have the same error, it seems like it comes from a function that must
return a reference, but objects are already references.
this doesn't work, but worked before beta1, I tried PEAR before beta1
and it uses lots of this :
function myFunc()
{
return new MyClass();
}
This works fine :
function myFunc()
{
return new MyClass();
}
I don't understand why it comes from return (new Class()); cause it
doesn't work.
[2003-07-03 07:09:44] karl at karlaustin dot com
Well from the text of that item it would suggest that doing:
return new object();
is fine, but:
return (new object());
is not fine, that's how it would seem to me as an end user.
PEAR is ridled with returns like the one I list (Although IMHO it
should have only one return and assign return values to a variable then
return at the end, but that's another story).
[2003-07-03 06:17:54] [EMAIL PROTECTED]
Cause:
http://news.php.net/article.php?group=php.zend-engine.cvsarticle=1432
I wonder if we really should break BC here...
[2003-07-03 06:13:42] karl at karlaustin dot com
Description:
Fatal error: Only variables or references can be returned by reference
in /usr/local/php5/lib/php/DB/common.php on line 737
If seems that doing:
return new DB_result($this, $result);
in a function results in the above error, but:
$_tmp = new DB_result($this, $result);
return $_tmp;
Is fine.
--
Edit this bug report at http://bugs.php.net/?id=24477edit=1
#24550 [Ver-Csd]: tokenizing syntax highlighting crashes
ID: 24550
Updated by: [EMAIL PROTECTED]
Reported By: hos dot endre at axelero dot hu
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.0.0b2-dev
New Comment:
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.
Previous Comments:
[2003-07-09 06:47:16] [EMAIL PROTECTED]
[Switching to Thread 1024 (runnable)]
lex_scan (zendlval=0xb2b8) at
/usr/src/web/php/php5/Zend/zend_language_scanner.l:988
988 char *func_name = CG(active_op_array)-function_name;
(gdb) bt
#0 lex_scan (zendlval=0xb2b8) at
/usr/src/web/php/php5/Zend/zend_language_scanner.l:988
#1 0x813f070 in zend_highlight (syntax_highlighter_ini=0xb354) at
/usr/src/web/php/php5/Zend/zend_highlight.c:176
#2 0x81313db in highlight_string (str=0x40298ccc,
syntax_highlighter_ini=0xb354,
str_name=0x402992d4 Command line code(1) : highlighted code)
at /usr/src/web/php/php5/Zend/zend_language_scanner.l:461
#3 0x80c8094 in zif_highlight_string (ht=1, return_value=0x402992b4,
this_ptr=0x0, return_value_used=0)
at /usr/src/web/php/php5/ext/standard/basic_functions.c:2251
#4 0x816b63d in zend_do_fcall_common_helper (execute_data=0xb43c,
op_array=0x4029905c)
at /usr/src/web/php/php5/Zend/zend_execute.c:2664
#5 0x816bbc2 in zend_do_fcall_handler (execute_data=0xb43c,
op_array=0x4029905c)
at /usr/src/web/php/php5/Zend/zend_execute.c:2793
#6 0x815bc54 in execute (op_array=0x4029905c) at
/usr/src/web/php/php5/Zend/zend_execute.c:1266
#7 0x813ea61 in zend_eval_string (str=0xb7d7
highlight_string('?__METHOD__');, retval_ptr=0x0,
string_name=0x81ae354 Command line code) at
/usr/src/web/php/php5/Zend/zend_execute_API.c:803
#8 0x8175114 in main (argc=3, argv=0xb674) at
/usr/src/web/php/php5/sapi/cli/php_cli.c:1001
#9 0x401b19cb in __libc_start_main (main=0x8174378 main, argc=3,
argv=0xb674, init=0x80696a0 _init,
fini=0x8175724 _fini, rtld_fini=0x4000aea0 _dl_fini,
stack_end=0xb66c)
at ../sysdeps/generic/libc-start.c:92
(gdb)
[2003-07-08 17:13:14] hos dot endre at axelero dot hu
Description:
Tokenizer function (token_get_all) crashes and Apache is going down
immediately, when a newly introduced __METHOD__ constant have found in
the script. Workx good with __FUNCTION__ constant, now I'm gonna use
__FUNCTION__ in my script, but might be problem one day for others...
I guess the sample code wont crash before PHP5, because if I write
anything else instead of __METHOD__, parser assumes that it's ok!
Compiler handles this constant, so the scripts works well with
__METHOD__, but should be untokenizable for documentation generators.
Now I tried syntax highlighting: same result, as I expected.
By the way: in the sample code I use __METHOD__ out of a method,
originally the problem came up in a method's body.
Reproduce code:
---
// I hope you like this - the shortest crasher formula:
highlight_string('?__METHOD__');
Expected result:
I expect crash.
Actual result:
--
Doctor, what's on?
--
Edit this bug report at http://bugs.php.net/?id=24550edit=1
#24635 [Ver-Csd]: small block of code causes crash, possibly destructor related.
ID: 24635
Updated by: [EMAIL PROTECTED]
Reported By: eric at cosky dot com
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2003-07-13 (dev)
New Comment:
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.
Previous Comments:
[2003-07-13 18:20:27] [EMAIL PROTECTED]
Verified, backtrace as follows:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (runnable)]
_efree (ptr=0x6f697463) at /usr/src/web/php/php5/Zend/zend_alloc.c:257
257 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p-size);
(gdb) bt
#0 _efree (ptr=0x6f697463) at
/usr/src/web/php/php5/Zend/zend_alloc.c:257
#1 0x813e01b in _zval_ptr_dtor (zval_ptr=0x4029afc0) at
/usr/src/web/php/php5/Zend/zend_execute.h:67
#2 0x814b075 in zend_hash_clean (ht=0x4029adbc) at
/usr/src/web/php/php5/Zend/zend_hash.c:535
#3 0x816bb91 in zend_do_fcall_common_helper (execute_data=0xbfffd53c,
op_array=0x4029839c)
at /usr/src/web/php/php5/Zend/zend_execute.c:2673
#4 0x816bd80 in zend_do_fcall_by_name_handler
(execute_data=0xbfffd53c, op_array=0x4029839c)
at /usr/src/web/php/php5/Zend/zend_execute.c:2725
#5 0x815c2c4 in execute (op_array=0x4029839c) at
/usr/src/web/php/php5/Zend/zend_execute.c:1194
#6 0x8146b20 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/web/php/php5/Zend/zend.c:1017
#7 0x811b8d3 in php_execute_script (primary_file=0xb898) at
/usr/src/web/php/php5/main/main.c:1695
#8 0x8175503 in main (argc=2, argv=0xb904) at
/usr/src/web/php/php5/sapi/cgi/cgi_main.c:1560
#9 0x401b19cb in __libc_start_main (main=0x8174c80 main, argc=2,
argv=0xb904, init=0x806985c _init,
fini=0x8175c14 _fini, rtld_fini=0x4000aea0 _dl_fini,
stack_end=0xb8fc)
at ../sysdeps/generic/libc-start.c:92
[2003-07-13 12:53:28] eric at cosky dot com
Description:
The following block of code will crash the PHP I installed from
php5-win32-200307130630.zip (and previous versions).
I've read that I should be using 'new' to gain proper use of
destructors, but it seems reasonable to say that using 'new' shouldn't
cause a server crash. Perhaps a useful thing to do would be to have a
class that has a __destruct() function produce an error if created
without 'new'?
Reproduce code:
---
class SiteClass {
function __construct() { $this-page = new PageClass(); }
}
class PageClass {
function Display() {
$section = new SectionClass(PageClass::Display);
}
}
class SectionClass {
function __construct($comment) {
$this-Comment = $comment;
}
function __destruct() {
out($this-Comment); // this line doesn't crash PHP
out(\n!-- End Section: . $this-Comment . --); // this line
crashes PHP
}
}
function out($code) { return; }
$site = new SiteClass();
$site-page-Display();
Expected result:
Nothing.
Actual result:
--
System alert for PHP crashing.
--
Edit this bug report at http://bugs.php.net/?id=24635edit=1
#24536 [Opn-Csd]: cloning within a try-catch block
ID: 24536
Updated by: [EMAIL PROTECTED]
Reported By: andre at onestep dot nl
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: w2k
PHP Version: 5CVS-2003-07-08 (dev)
New Comment:
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.
Previous Comments:
[2003-07-08 07:54:28] andre at onestep dot nl
Description:
Cloning an object within a try-catch block generates a bad opcode in
throw list error.
Reproduce code:
---
class MyClass
{
public $foobar;
}
try
{
$a = new MyClass();
$b = $a-__clone();
}
catch(Exception $exception)
{
echo $exception-getMessage();
}
Expected result:
An empty page.
Actual result:
--
PHP Fatal error: Bad opcode in throw list in
C:\simon\production\www\test2.php on line 13
--
Edit this bug report at http://bugs.php.net/?id=24536edit=1
#24829 [NEW]: array_intersect_assoc compares keys AND values
From: niklas at zim dot goe dot net Operating system: Linux 2.4.20 PHP version: 4.3.1 PHP Bug Type: Arrays related Bug description: array_intersect_assoc compares keys AND values Description: The function array_intersect_assoc compares keys AND values. According to the documentation only the keys should be considered. The documentation says: Note that the keys are used in the comparison unlike in array_intersect(). If this is the volitional behavior you should point that out in the documentation (... that the keys are used too ...). Reproduce code: --- $array1 = array (a = green); $array2 = array (a = greenToo); print_r(array_intersect_assoc ($array1, $array2)); Expected result: Array( [a] = green ) Actual result: -- Array() -- Edit bug report at http://bugs.php.net/?id=24829edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24829r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24829r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24829r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24829r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24829r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24829r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24829r=support Expected behavior: http://bugs.php.net/fix.php?id=24829r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24829r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24829r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24829r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24829r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24829r=dst IIS Stability: http://bugs.php.net/fix.php?id=24829r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24829r=gnused
#24812 [Opn-Csd]: Calling exit() from a destructor breaks next executed script
ID: 24812
Updated by: [EMAIL PROTECTED]
Reported By: vma1 at abv dot bg
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Slackware Linux 9.0
PHP Version: 5CVS-2003-07-25 (dev)
New Comment:
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.
Previous Comments:
[2003-07-25 17:21:49] vma1 at abv dot bg
Description:
When a destructor runs and you call exit() from within it, this will
break the next executed PHP script with a Cannot redeclare...
message. The bug appears when the script is run on a web server, not
from the command line. I think that the HTTP request must be 1.1 not
1.0, because for me it appears only when HTTP request has keepalive
connection enabled. To reproduce the bug, place the following script on
a web server and run it from the web browser (in my case it was
Internet Explorer 6.0)
Reproduce code:
---
?
class someclass
{
public function __destruct ()
{
exit (Here we terminate);
}
}
header (Location: http://; . $_SERVER [SERVER_NAME] . $_SERVER
[SCRIPT_NAME]);
$obj = new someclass;
function evil ()
{
}
?
Expected result:
No output is expected. The HTTP request should loop in redirection
calls.
Actual result:
--
Fatal error: Cannot redeclare evil() (previously declared in :15) in
/usr/local/apache/site/htdocs/bug.php on line 15
--
Edit this bug report at http://bugs.php.net/?id=24812edit=1
#24659 [Ver-Fbk]: Crash due to some internal memory corruption (?)
ID: 24659 Updated by: [EMAIL PROTECTED] Reported By: fujimura at wakhok dot ac dot jp -Status: Verified +Status: Feedback Bug Type: Zend Engine 2 problem Operating System: Linux kernel-2.4.21 PHP Version: 5.0.0b2-dev New Comment: Could not make the second one (set_exception_handler) crash. Please check it still happens in current CVS. Previous Comments: [2003-07-18 00:36:26] [EMAIL PROTECTED] The second script crashes much earlier: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (runnable)] 0x40425fde in zend_hash_add_or_update (ht=0x80ded04, arKey=0x80ded24 \\sA@, nKeyLength=7, pData=0x0, nDataSize=4, pDest=0xbfffcd54, flag=1) at /usr/src/web/php/php5/Zend/zend_hash.c:238 238 INIT_DATA(ht, p, pData, nDataSize); (gdb) bt #0 0x40425fde in zend_hash_add_or_update (ht=0x80ded04, arKey=0x80ded24 \\sA@, nKeyLength=7, pData=0x0, nDataSize=4, pDest=0xbfffcd54, flag=1) at /usr/src/web/php/php5/Zend/zend_hash.c:238 #1 0x404271f4 in zend_hash_copy (target=0x80ded04, source=0x80de7e4, pCopyConstructor=0x4041fce4 zval_add_ref, tmp=0xbfffcda4, size=4) at /usr/src/web/php/php5/Zend/zend_hash.c:750 #2 0x4041fde6 in _zval_copy_ctor (zvalue=0x80f160c) at /usr/src/web/php/php5/Zend/zend_variables.c:124 #3 0x4042b068 in zif_set_exception_handler (ht=1, return_value=0x80f160c, this_ptr=0x0, return_value_used=0) at /usr/src/web/php/php5/Zend/zend_builtin_functions.c:1017 #4 0x40451d4f in zend_do_fcall_common_helper (execute_data=0xbfffcf5c, op_array=0x80ea62c) at /usr/src/web/php/php5/Zend/zend_execute.c:2634 #5 0x404523f4 in zend_do_fcall_handler (execute_data=0xbfffcf5c, op_array=0x80ea62c) at /usr/src/web/php/php5/Zend/zend_execute.c:2763 #6 0x4043a7ee in execute (op_array=0x80ea62c) at /usr/src/web/php/php5/Zend/zend_execute.c:1194 #7 0x4042190f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/web/php/php5/Zend/zend.c:1017 #8 0x403ef2c5 in php_execute_script (primary_file=0xb288) at /usr/src/web/php/php5/main/main.c:1695 #9 0x4045c07e in apache_php_module_main (r=0x81bf684, display_source_mode=0) at /usr/src/web/php/php5/sapi/apache/sapi_apache.c:54 #10 0x4045cd00 in send_php (r=0x81bf684, display_source_mode=0, filename=0x0) at /usr/src/web/php/php5/sapi/apache/mod_php5.c:621 #11 0x4045cd6a in send_parsed_php (r=0x81bf684) at /usr/src/web/php/php5/sapi/apache/mod_php5.c:636 #12 0x8054f09 in ap_invoke_handler () #13 0x806b0cf in process_request_internal () #14 0x806b13a in ap_process_request () #15 0x8061916 in child_main () #16 0x8061af5 in make_child () #17 0x8061c76 in startup_children () #18 0x806230d in standalone_main () #19 0x8062b9c in main () #20 0x4016c9cb in __libc_start_main (main=0x80627d8 main, argc=3, argv=0xb6b4, init=0x804ed2c _init, fini=0x8082e64 _fini, rtld_fini=0x4000aea0 _dl_fini, stack_end=0xb6ac) at ../sysdeps/generic/libc-start.c:92 [2003-07-18 00:34:39] [EMAIL PROTECTED] The first script (that xml thing) does this after some reloads: Warning: xml_set_default_handler(): supplied resource is not a valid XML Parser resource in /www/apache-1.3.27/htdocs/exep.php on line 13 Warning: xml_parser_free(): supplied resource is not a valid XML Parser resource in /www/apache-1.3.27/htdocs/exep.php on line 15 Warning: Unknown list entry type in request shutdown (135138372) in Unknown on line 0 Given enough requests, (ab -n 1000 http://localhost/bug24658_a.php), it crashes: [Switching to Thread 1024 (runnable)] 0x4042e1fd in zend_objects_destroy_object (object=0x80e907c, handle=1) at /usr/src/web/php/php5/Zend/zend_objects.c:36 36 zend_function *destructor = object-ce-destructor; (gdb) bt #0 0x4042e1fd in zend_objects_destroy_object (object=0x80e907c, handle=1) at /usr/src/web/php/php5/Zend/zend_objects.c:36 #1 0x40430855 in zend_objects_store_del_ref (zobject=0x80e0f9c) at /usr/src/web/php/php5/Zend/zend_objects_API.c:142 #2 0x4041fccc in _zval_dtor (zvalue=0x80e0f9c) at /usr/src/web/php/php5/Zend/zend_variables.c:61 #3 0x40417389 in _zval_ptr_dtor (zval_ptr=0x80ecff0) at /usr/src/web/php/php5/Zend/zend_execute_API.c:344 #4 0x40426be8 in zend_hash_destroy (ht=0x404a6990) at /usr/src/web/php/php5/Zend/zend_hash.c:509 #5 0x40416f55 in shutdown_executor () at /usr/src/web/php/php5/Zend/zend_execute_API.c:211 #6 0x40421257 in zend_deactivate () at /usr/src/web/php/php5/Zend/zend.c:795 #7 0x403ee8e6 in php_request_shutdown (dummy=0x0) at /usr/src/web/php/php5/main/main.c:1174 #8 0x4045c0d5 in apache_php_module_main (r=0x81bf684, display_source_mode=0) at /usr/src/web/php/php5/sapi/apache/sapi_apache.c:60 #9 0x4045cd00 in send_php (r=0x81bf684, display_source_mode=0, filename=0x0) at
#24829 [Opn-Bgs]: array_intersect_assoc compares keys AND values
ID: 24829 Updated by: [EMAIL PROTECTED] Reported By: niklas at zim dot goe dot net -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Linux 2.4.20 PHP Version: 4.3.1 New Comment: 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 The displayed behaviour is the correct one. Previous Comments: [2003-07-27 08:34:40] niklas at zim dot goe dot net Description: The function array_intersect_assoc compares keys AND values. According to the documentation only the keys should be considered. The documentation says: Note that the keys are used in the comparison unlike in array_intersect(). If this is the volitional behavior you should point that out in the documentation (... that the keys are used too ...). Reproduce code: --- $array1 = array (a = green); $array2 = array (a = greenToo); print_r(array_intersect_assoc ($array1, $array2)); Expected result: Array( [a] = green ) Actual result: -- Array() -- Edit this bug report at http://bugs.php.net/?id=24829edit=1
#24824 [Opn-Fbk]: dba_ routines with ndbm crash
ID: 24824 Updated by: [EMAIL PROTECTED] Reported By: php at johnlevine dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: BSD/OS 4.3.1 PHP Version: 4.3.2 New Comment: could you please provide the sample db, I am unabled to replicate the problem using a ndbm database that I have. Previous Comments: [2003-07-26 20:40:48] php at johnlevine dot com Description: This program prints Resource handle #5, and then crashes. It works OK in 4.2.2, crashes in a version of 4.3.0 I had lying around. It crashes in the Apache module, which is where I first noticed it. There also seems to be a change since 4.2 that it used to append .db to the file name but doesn't any more. It's compiled --with-mysql --with-apxs --with-ndbm (I know that ndbm is old and tired, but it's distributed with BSD/OS and I have a lot of existing ndbm files that I'm using.) Reproduce code: --- $a = dba_popen(test.db, r, ndbm); print handle is $a\n; // prints Resource #5 $k = dba_firstkey($a); print key is $k\n; // segfaults, see trace below Expected result: should print first key in db file Actual result: -- Segmentation violation: #0 0x481b5f1d in dbm_firstkey () from /shlib/libc.so.2 #1 0x806486f in dba_firstkey_ndbm (info=0x81bdf00, newlen=0x8046070) at /home/src/php-4.3.2/ext/dba/dba_ndbm.c:126 #2 0x8063a74 in zif_dba_firstkey (ht=1, return_value=0x81bc68c, this_ptr=0x0, return_value_used=1) at /home/src/php-4.3.2/ext/dba/dba.c:704 #3 0x8139bf3 in execute (op_array=0x81bb88c) at /home/src/php-4.3.2/Zend/zend_execute.c:1608 #4 0x812821e in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/src/php-4.3.2/Zend/zend.c:869 #5 0x8100275 in php_execute_script (primary_file=0x8047a94) at /home/src/php-4.3.2/main/main.c:1671 #6 0x814188e in main (argc=2, argv=0x8047afc) at /home/src/php-4.3.2/sapi/cli/php_cli.c:806 #7 0x8061843 in __start () -- Edit this bug report at http://bugs.php.net/?id=24824edit=1
#24805 [Bgs-Opn]: skip_long_header_sep routine break email
ID: 24805 User updated by: bobe at phpcodeur dot net Reported By: bobe at phpcodeur dot net -Status: Bogus +Status: Open Bug Type: Mail related Operating System: Linux PHP Version: 4.3.2 New Comment: The separator for long headers should be \r\n followed by either a space or a \t It is exactely what i do.. The bug tracker put the long subject of my previous example on 2 lines but it is a sequence \r\nSP This code also reproduces the bug : mail( '[EMAIL PROTECTED]', this is a long subject \r\n to test the mail function, 'This is the message', From: [EMAIL PROTECTED]: 1.0 ); Previous Comments: [2003-07-26 20:17:52] [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 The separator for long headers should be \r\n followed by either a space or a \t no other character such as \n or \r will be accepted. If you don't use tab or a space entire sequence will be converted to spaces. [2003-07-26 05:31:55] bobe at phpcodeur dot net The bug occurs for example with this code : mail( '[EMAIL PROTECTED]', =?iso-8859-1?Q?ceci_est_un_petit_test_pour_d=E9terminer_les_bugs_?=\r\n =?iso-8859-1?Q?existants_avec_la_classe_mail?=, 'This is the message', From: [EMAIL PROTECTED]: 1.0 ); result is : =?iso-8859-1?Q?existants_avec_la_classe_mail?= From: [EMAIL PROTECTED] MIME-Version: 1.0 This is the message. Maybe that the problem occurs with qmail because there are sequences \r\n instead of \n in long subject ? [2003-07-25 17:46:55] [EMAIL PROTECTED] Where is the bug occuring imap, or something else? Who does the message parsing? [2003-07-25 12:22:17] bobe at phpcodeur dot net Sorry for the bad translation :/ note that quoted-printable encoding plays no role in the problem [2003-07-25 12:14:44] bobe at phpcodeur dot net Description: Hello, The problem arises when we envoit an email with the subject encoded in quoted-printable and of type long header. skip_long_header_sep routine accept accepts only the separations \r\nLWS but on some systems, it doubles the line feed in the header: to test, send a long subject on a linux system Reproduce code: --- From - Fri Jul 25 18:53:24 2003 X-UIDL: 1059152088.14117.wsa-2037,S=4715 X-Mozilla-Status: 0001 X-Mozilla-Status2: Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: (qmail 14115 invoked by uid 99); 25 Jul 2003 16:54:48 - To: Undisclosed-recipients: ; Subject: =?iso-8859-1?Q?ceci_est_un_petit_test_pour_d=E9terminer_les_bugs_?= =?iso-8859-1?Q?existants_avec_la_classe_mail?= Date: Fri, 25 Jul 2003 18:54:48 +0200 From: test [EMAIL PROTECTED] X-Env: Linux - Apache PHP/4.3.2 MIME-Version: 1.0 Message-ID: [EMAIL PROTECTED] Content-Type: multipart/mixed; boundary=-=_Part0_6fEwBy2N74yqUJ0vNbQYrw0HBJrhLT-- This is a multi-part message in MIME format. Expected result: simply that subject of mail correctly display Actual result: -- the headers undo the long sybject aren't interpreted -- Edit this bug report at http://bugs.php.net/?id=24805edit=1
#24708 [Ver-Csd]: Calling restore_error_handler() in a destructor crashes things
ID: 24708
Updated by: [EMAIL PROTECTED]
Reported By: auroraeosrose at hotmail dot com
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.0.0b2-dev
New Comment:
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.
Previous Comments:
[2003-07-19 08:31:52] [EMAIL PROTECTED]
Backtrace (with CLI):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (runnable)]
0x81d30d1 in zend_objects_destroy_object (object=0x402a3230, handle=1)
at /usr/src/web/php/php5/Zend/zend_objects.c:44
44 if (destructor-op_array.fn_flags
(ZEND_ACC_PRIVATE|ZEND_ACC_PROTECTED)) {
(gdb) bt
#0 0x81d30d1 in zend_objects_destroy_object (object=0x402a3230,
handle=1)
at /usr/src/web/php/php5/Zend/zend_objects.c:44
#1 0x81d5a6f in zend_objects_store_del_ref (zobject=0x4029d3ac) at
/usr/src/web/php/php5/Zend/zend_objects_API.c:142
#2 0x81bf7e2 in _zval_dtor (zvalue=0x4029d3ac,
__zend_filename=0x822a640
/usr/src/web/php/php5/Zend/zend_execute_API.c, __zend_lineno=344)
at /usr/src/web/php/php5/Zend/zend_variables.c:61
#3 0x81b463d in _zval_ptr_dtor (zval_ptr=0x402a3784,
__zend_filename=0x822ae40
/usr/src/web/php/php5/Zend/zend_variables.c, __zend_lineno=165)
at /usr/src/web/php/php5/Zend/zend_execute_API.c:344
#4 0x81bfb24 in _zval_ptr_dtor_wrapper (zval_ptr=0x402a3784) at
/usr/src/web/php/php5/Zend/zend_variables.c:165
#5 0x81c8a9c in zend_hash_destroy (ht=0x402a36c0) at
/usr/src/web/php/php5/Zend/zend_hash.c:509
#6 0x81bf7a9 in _zval_dtor (zvalue=0x402a3640,
__zend_filename=0x822a640
/usr/src/web/php/php5/Zend/zend_execute_API.c, __zend_lineno=266)
at /usr/src/web/php/php5/Zend/zend_variables.c:52
#7 0x81b4346 in shutdown_executor () at
/usr/src/web/php/php5/Zend/zend_execute_API.c:266
#8 0x81c14b8 in zend_deactivate () at
/usr/src/web/php/php5/Zend/zend.c:795
#9 0x817b91b in php_request_shutdown (dummy=0x0) at
/usr/src/web/php/php5/main/main.c:1174
#10 0x81eecff in main (argc=2, argv=0xb694) at
/usr/src/web/php/php5/sapi/cli/php_cli.c:1018
#11 0x401b19cb in __libc_start_main (main=0x81eda64 main, argc=2,
argv=0xb694, init=0x806aefc _init,
fini=0x81ef644 _fini, rtld_fini=0x4000aea0 _dl_fini,
stack_end=0xb68c)
at ../sysdeps/generic/libc-start.c:92
[2003-07-18 14:54:05] auroraeosrose at hotmail dot com
Oh, btw, using $error = new Error(); makes no difference, the
script(and php, and apache) crash exactly the same way. Other
functions, echoes, etc. that I've tried work fine in the destructor.
[2003-07-18 14:26:49] auroraeosrose at hotmail dot com
Description:
Latest php snap of 5.0
Apache 2 filter
mb_string, gd, mssql, and mysql only dll's loaded
Error handler class - constructor calls set_error_handler and works
just fine, descructor calls restore_error_handler and the server
crashes nicely - not only the phpdll but all of apache as well in a
second message. I have some dump files if you need them, just leave a
message.
Reproduce code:
---
?php
class Error
{
function __construct()
{
set_error_handler(array($this, 'handler'));
}
function __destruct()
{
restore_error_handler();
}
function handler($no, $str, $file, $line, $ctx)
{
echo 'pre';
echo 'no : ' . $no . \n;
echo 'str : ' . $str . \n;
echo 'file : ' . $file . \n;
echo 'line : ' . $line . \n;
echo 'ctx : ';
print_r($ctx);
echo '/pre';
}
}
$error = new error();
echo $dog;
?
Expected result:
no : 8
str : Undefined variable: dog
file : /test.php
line : 29
ctx : Array
(
[GLOBALS] = Array
*RECURSION*
[_POST] = Array
(
)
[_GET] = Array
(
)
[_COOKIE] = Array
(
)
[_FILES] = Array
(
)
[error] = error Object
(
)
)
Actual result:
--
Comment out the restore_error_handler and it works jim dandy
--
Edit this bug report
#24824 [Fbk-Opn]: dba_ routines with ndbm crash
ID: 24824 User updated by: php at johnlevine dot com Reported By: php at johnlevine dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: BSD/OS 4.3.1 PHP Version: 4.3.2 New Comment: On my system, it crashes with any dbm file, even one with no entries. Previous Comments: [2003-07-27 10:10:42] [EMAIL PROTECTED] could you please provide the sample db, I am unabled to replicate the problem using a ndbm database that I have. [2003-07-26 20:40:48] php at johnlevine dot com Description: This program prints Resource handle #5, and then crashes. It works OK in 4.2.2, crashes in a version of 4.3.0 I had lying around. It crashes in the Apache module, which is where I first noticed it. There also seems to be a change since 4.2 that it used to append .db to the file name but doesn't any more. It's compiled --with-mysql --with-apxs --with-ndbm (I know that ndbm is old and tired, but it's distributed with BSD/OS and I have a lot of existing ndbm files that I'm using.) Reproduce code: --- $a = dba_popen(test.db, r, ndbm); print handle is $a\n; // prints Resource #5 $k = dba_firstkey($a); print key is $k\n; // segfaults, see trace below Expected result: should print first key in db file Actual result: -- Segmentation violation: #0 0x481b5f1d in dbm_firstkey () from /shlib/libc.so.2 #1 0x806486f in dba_firstkey_ndbm (info=0x81bdf00, newlen=0x8046070) at /home/src/php-4.3.2/ext/dba/dba_ndbm.c:126 #2 0x8063a74 in zif_dba_firstkey (ht=1, return_value=0x81bc68c, this_ptr=0x0, return_value_used=1) at /home/src/php-4.3.2/ext/dba/dba.c:704 #3 0x8139bf3 in execute (op_array=0x81bb88c) at /home/src/php-4.3.2/Zend/zend_execute.c:1608 #4 0x812821e in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/src/php-4.3.2/Zend/zend.c:869 #5 0x8100275 in php_execute_script (primary_file=0x8047a94) at /home/src/php-4.3.2/main/main.c:1671 #6 0x814188e in main (argc=2, argv=0x8047afc) at /home/src/php-4.3.2/sapi/cli/php_cli.c:806 #7 0x8061843 in __start () -- Edit this bug report at http://bugs.php.net/?id=24824edit=1
#24824 [Opn-Fbk]: dba_ routines with ndbm crash
ID: 24824 Updated by: [EMAIL PROTECTED] Reported By: php at johnlevine dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: BSD/OS 4.3.1 PHP Version: 4.3.2 New Comment: Please provide the outputs of the following two commands using CLI or CGI version of php: 1) php run-tests.php ext/dba 2) ldd php Previous Comments: [2003-07-27 11:22:26] php at johnlevine dot com On my system, it crashes with any dbm file, even one with no entries. [2003-07-27 10:10:42] [EMAIL PROTECTED] could you please provide the sample db, I am unabled to replicate the problem using a ndbm database that I have. [2003-07-26 20:40:48] php at johnlevine dot com Description: This program prints Resource handle #5, and then crashes. It works OK in 4.2.2, crashes in a version of 4.3.0 I had lying around. It crashes in the Apache module, which is where I first noticed it. There also seems to be a change since 4.2 that it used to append .db to the file name but doesn't any more. It's compiled --with-mysql --with-apxs --with-ndbm (I know that ndbm is old and tired, but it's distributed with BSD/OS and I have a lot of existing ndbm files that I'm using.) Reproduce code: --- $a = dba_popen(test.db, r, ndbm); print handle is $a\n; // prints Resource #5 $k = dba_firstkey($a); print key is $k\n; // segfaults, see trace below Expected result: should print first key in db file Actual result: -- Segmentation violation: #0 0x481b5f1d in dbm_firstkey () from /shlib/libc.so.2 #1 0x806486f in dba_firstkey_ndbm (info=0x81bdf00, newlen=0x8046070) at /home/src/php-4.3.2/ext/dba/dba_ndbm.c:126 #2 0x8063a74 in zif_dba_firstkey (ht=1, return_value=0x81bc68c, this_ptr=0x0, return_value_used=1) at /home/src/php-4.3.2/ext/dba/dba.c:704 #3 0x8139bf3 in execute (op_array=0x81bb88c) at /home/src/php-4.3.2/Zend/zend_execute.c:1608 #4 0x812821e in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/src/php-4.3.2/Zend/zend.c:869 #5 0x8100275 in php_execute_script (primary_file=0x8047a94) at /home/src/php-4.3.2/main/main.c:1671 #6 0x814188e in main (argc=2, argv=0x8047afc) at /home/src/php-4.3.2/sapi/cli/php_cli.c:806 #7 0x8061843 in __start () -- Edit this bug report at http://bugs.php.net/?id=24824edit=1
#24824 [Fbk-Opn]: dba_ routines with ndbm crash
ID: 24824 User updated by: php at johnlevine dot com Reported By: php at johnlevine dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: BSD/OS 4.3.1 PHP Version: 4.3.2 New Comment: tom:johnl:php-4.3.2$ TEST_PHP_EXECUTABLE=/usr/local/bin/php php run-tests.php ext/dba = CWD : /home/src/php-4.3.2 PHP : /usr/local/bin/php PHP_SAPI: cli PHP_VERSION : 4.3.2 ZEND_VERSION: 1.3.0 PHP_OS : BSD/OS INI actual : /usr/local/lib/php.ini More .INIs : Extra dirs : = Running selected tests. FAIL DBA File Creation Test [ext/dba/tests/dba001.phpt] FAIL DBA Insert/Fetch Test [ext/dba/tests/dba002.phpt] FAIL DBA Insert/Replace/Fetch Test [ext/dba/tests/dba003.phpt] FAIL DBA Multiple Insert/Fetch Test [ext/dba/tests/dba004.phpt] FAIL DBA FirstKey/NextKey Loop Test With 5 Items [ext/dba/tests/dba005.phpt] FAIL DBA FirstKey/NextKey with 2 deletes [ext/dba/tests/dba006.phpt] FAIL DBA Multiple File Creation Test [ext/dba/tests/dba007.phpt] FAIL DBA magic_quotes_runtime Test [ext/dba/tests/dba008.phpt] FAIL DBA dba_popen Test [ext/dba/tests/dba009.phpt] FAIL DBA CDB handler test [ext/dba/tests/dba_cdb.phpt] FAIL DBA CDB_MAKE handler test [ext/dba/tests/dba_cdb_make.phpt] PASS DBA CDB handler test (read only) [ext/dba/tests/dba_cdb_read.phpt] FAIL DBA DB2 handler test [ext/dba/tests/dba_db2.phpt] FAIL DBA DB3 handler test [ext/dba/tests/dba_db3.phpt] FAIL DBA DB4 handler test [ext/dba/tests/dba_db4.phpt] FAIL DBA DBM handler test [ext/dba/tests/dba_dbm.phpt] FAIL DBA FlatFile handler test [ext/dba/tests/dba_flatfile.phpt] FAIL DBA GDBM handler test [ext/dba/tests/dba_gdbm.phpt] FAIL DBA NDBM handler test [ext/dba/tests/dba_ndbm.phpt] tom:johnl:php-4.3.2$ ldd /usr/local/bin/php libm.so = /shlib/libm.so.0.0 (0x48171000) libdl.so = /shlib/libdl.so (0x48182000) libgcc.so.1 = /shlib/libgcc.so.1 (0x48185000) libc.so.2 = /shlib/libc.so.2 (0x48191000) Previous Comments: [2003-07-27 11:27:46] [EMAIL PROTECTED] Please provide the outputs of the following two commands using CLI or CGI version of php: 1) php run-tests.php ext/dba 2) ldd php [2003-07-27 11:22:26] php at johnlevine dot com On my system, it crashes with any dbm file, even one with no entries. [2003-07-27 10:10:42] [EMAIL PROTECTED] could you please provide the sample db, I am unabled to replicate the problem using a ndbm database that I have. [2003-07-26 20:40:48] php at johnlevine dot com Description: This program prints Resource handle #5, and then crashes. It works OK in 4.2.2, crashes in a version of 4.3.0 I had lying around. It crashes in the Apache module, which is where I first noticed it. There also seems to be a change since 4.2 that it used to append .db to the file name but doesn't any more. It's compiled --with-mysql --with-apxs --with-ndbm (I know that ndbm is old and tired, but it's distributed with BSD/OS and I have a lot of existing ndbm files that I'm using.) Reproduce code: --- $a = dba_popen(test.db, r, ndbm); print handle is $a\n; // prints Resource #5 $k = dba_firstkey($a); print key is $k\n; // segfaults, see trace below Expected result: should print first key in db file Actual result: -- Segmentation violation: #0 0x481b5f1d in dbm_firstkey () from /shlib/libc.so.2 #1 0x806486f in dba_firstkey_ndbm (info=0x81bdf00, newlen=0x8046070) at /home/src/php-4.3.2/ext/dba/dba_ndbm.c:126 #2 0x8063a74 in zif_dba_firstkey (ht=1, return_value=0x81bc68c, this_ptr=0x0, return_value_used=1) at /home/src/php-4.3.2/ext/dba/dba.c:704 #3 0x8139bf3 in execute (op_array=0x81bb88c) at /home/src/php-4.3.2/Zend/zend_execute.c:1608 #4 0x812821e in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/src/php-4.3.2/Zend/zend.c:869 #5 0x8100275 in php_execute_script (primary_file=0x8047a94) at /home/src/php-4.3.2/main/main.c:1671 #6 0x814188e in main (argc=2, argv=0x8047afc) at /home/src/php-4.3.2/sapi/cli/php_cli.c:806 #7 0x8061843 in __start () -- Edit this bug report at http://bugs.php.net/?id=24824edit=1
#24805 [Opn-NoF]: skip_long_header_sep routine break email
ID: 24805 Updated by: [EMAIL PROTECTED] Reported By: bobe at phpcodeur dot net -Status: Open +Status: No Feedback Bug Type: Mail related Operating System: Linux PHP Version: 4.3.2 New Comment: 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 It works perfectly on 4.3.3dev for me. Previous Comments: [2003-07-27 10:37:07] bobe at phpcodeur dot net The separator for long headers should be \r\n followed by either a space or a \t It is exactely what i do.. The bug tracker put the long subject of my previous example on 2 lines but it is a sequence \r\nSP This code also reproduces the bug : mail( '[EMAIL PROTECTED]', this is a long subject \r\n to test the mail function, 'This is the message', From: [EMAIL PROTECTED]: 1.0 ); [2003-07-26 20:17:52] [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 The separator for long headers should be \r\n followed by either a space or a \t no other character such as \n or \r will be accepted. If you don't use tab or a space entire sequence will be converted to spaces. [2003-07-26 05:31:55] bobe at phpcodeur dot net The bug occurs for example with this code : mail( '[EMAIL PROTECTED]', =?iso-8859-1?Q?ceci_est_un_petit_test_pour_d=E9terminer_les_bugs_?=\r\n =?iso-8859-1?Q?existants_avec_la_classe_mail?=, 'This is the message', From: [EMAIL PROTECTED]: 1.0 ); result is : =?iso-8859-1?Q?existants_avec_la_classe_mail?= From: [EMAIL PROTECTED] MIME-Version: 1.0 This is the message. Maybe that the problem occurs with qmail because there are sequences \r\n instead of \n in long subject ? [2003-07-25 17:46:55] [EMAIL PROTECTED] Where is the bug occuring imap, or something else? Who does the message parsing? [2003-07-25 12:22:17] bobe at phpcodeur dot net Sorry for the bad translation :/ note that quoted-printable encoding plays no role in the problem 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/24805 -- Edit this bug report at http://bugs.php.net/?id=24805edit=1
#24390 [Ver]: persistent resources destructors aren't called when ZTS is enabled.
ID: 24390 Updated by: [EMAIL PROTECTED] Reported By: vaclav dot pecuch at tiscali dot cz Status: Verified Bug Type: Scripting Engine problem Operating System: any (+ ZTS) -PHP Version: 4.3.3RC2-dev +PHP Version: 4.3.3RC2-dev 5.0.0b2 New Comment: Not only do the persistent resources destructors are not called, but the MSHUTDOWN is also not called resulting in quite a few memory leaks. Previous Comments: [2003-06-29 21:07:00] [EMAIL PROTECTED] This is not Windows specific, but ZTS issue. The persistant resource destructor is not called at all when ZTS is enabled. (tested using CLI compiled with ZTS enabled) Test sources found here (a bit cleaned up version): http://www.php.net/~jani/ext_tm.tar.gz Configure php: # ./configure --disable-all --disable-cgi --enable-tm --enable-experimental-zts Test results: --- Thread Safety = disabled resource(4) of type (TestModule Resource) TestModule (normal): resource non-persistent resource created (non-persistent) Running tm_resource_dtor() for resource non-persistent resource resource(4) of type (TestModule Persistent Resource) TestModule (persistent): resource persistent resource created (persistent): Running tm_presource_dtor() for resource persistent resource --- Thread Safety = enabled resource(4) of type (TestModule Resource) TestModule (normal): resource non-persistent resource created (non-persistent) Running tm_resource_dtor() for resource non-persistent resource resource(4) of type (TestModule Persistent Resource) TestModule (persistent): resource persistent resource created -- [2003-06-29 14:54:01] vaclav dot pecuch at tiscali dot cz Description: PHP 4.3.2 on Windows doesn't call persistent resource destructors on PHP process shutdown. I'm using persitent resources in my PHP module, i.e. in MINIT function I register destructors for my resources: mymod_rsc=zend_register_list_destructors_ex(mymod_commit_rsc, mymod_close_rsc, MYMOD_RSC_NAME, module_number); I add newly created resource to EG(persistent_list) by this code list_entry new_le; Z_TYPE(new_le) = mymod_rsc; new_le.ptr = malloced_rsc_data_buffer; zend_hash_update(EG(persistent_list), hashed_details, strlen(hashed_details)+1, (void *) new_le, sizeof(list_entry), NULL); Function mymod_commit_rsc is called at the end of the request while mymod_close_rsc is never called. I'm running PHP 4.3.2 with Apache 1.3.27 (PHP runs as Apache module) on Windows 2000. I'm loading PHP module through extension directive in PHP.INI. I've tested my module on Linux (RH 7.3, PHP 4.3.2 as Apache module with Apache 1.3.27) and it worked - mymod_close_rsc was called at the end of PHP process or more precisely at the end of Apache process. Reproduce code: --- The simplest example is there: http://home.tiscali.cz/vaclav.pecuch/phptestmodule.zip This is PHP module which registers its persistent resource in MINIT function, implements create_resource function and contains some logging (ugly but functional). Change path settings in makefile and logfile path and filename in C source before build. Expected result: Destruction of persistent resources at the end of PHP process. Actual result: -- Destructor isn't called on Windows, is called on Linux. -- Edit this bug report at http://bugs.php.net/?id=24390edit=1
#24805 [NoF-Fbk]: skip_long_header_sep routine break email
ID: 24805 Updated by: [EMAIL PROTECTED] Reported By: bobe at phpcodeur dot net -Status: No Feedback +Status: Feedback Bug Type: Mail related Operating System: Linux PHP Version: 4.3.2 Previous Comments: [2003-07-27 12:30:01] [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 It works perfectly on 4.3.3dev for me. [2003-07-27 10:37:07] bobe at phpcodeur dot net The separator for long headers should be \r\n followed by either a space or a \t It is exactely what i do.. The bug tracker put the long subject of my previous example on 2 lines but it is a sequence \r\nSP This code also reproduces the bug : mail( '[EMAIL PROTECTED]', this is a long subject \r\n to test the mail function, 'This is the message', From: [EMAIL PROTECTED]: 1.0 ); [2003-07-26 20:17:52] [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 The separator for long headers should be \r\n followed by either a space or a \t no other character such as \n or \r will be accepted. If you don't use tab or a space entire sequence will be converted to spaces. [2003-07-26 05:31:55] bobe at phpcodeur dot net The bug occurs for example with this code : mail( '[EMAIL PROTECTED]', =?iso-8859-1?Q?ceci_est_un_petit_test_pour_d=E9terminer_les_bugs_?=\r\n =?iso-8859-1?Q?existants_avec_la_classe_mail?=, 'This is the message', From: [EMAIL PROTECTED]: 1.0 ); result is : =?iso-8859-1?Q?existants_avec_la_classe_mail?= From: [EMAIL PROTECTED] MIME-Version: 1.0 This is the message. Maybe that the problem occurs with qmail because there are sequences \r\n instead of \n in long subject ? [2003-07-25 17:46:55] [EMAIL PROTECTED] Where is the bug occuring imap, or something else? Who does the message parsing? 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/24805 -- Edit this bug report at http://bugs.php.net/?id=24805edit=1
#24824 [Opn-Fbk]: dba_ routines with ndbm crash
ID: 24824 Updated by: [EMAIL PROTECTED] Reported By: php at johnlevine dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: BSD/OS 4.3.1 PHP Version: 4.3.2 -Assigned To: +Assigned To: helly New Comment: The result should be impossible with normal builds. Did you compile your own libc or something like that? Please execute: php -r 'echo print_r(dba_handlers());' You could also provide me with your config.log per email but stick to the list for the rest. Previous Comments: [2003-07-27 11:41:18] php at johnlevine dot com tom:johnl:php-4.3.2$ TEST_PHP_EXECUTABLE=/usr/local/bin/php php run-tests.php ext/dba = CWD : /home/src/php-4.3.2 PHP : /usr/local/bin/php PHP_SAPI: cli PHP_VERSION : 4.3.2 ZEND_VERSION: 1.3.0 PHP_OS : BSD/OS INI actual : /usr/local/lib/php.ini More .INIs : Extra dirs : = Running selected tests. FAIL DBA File Creation Test [ext/dba/tests/dba001.phpt] FAIL DBA Insert/Fetch Test [ext/dba/tests/dba002.phpt] FAIL DBA Insert/Replace/Fetch Test [ext/dba/tests/dba003.phpt] FAIL DBA Multiple Insert/Fetch Test [ext/dba/tests/dba004.phpt] FAIL DBA FirstKey/NextKey Loop Test With 5 Items [ext/dba/tests/dba005.phpt] FAIL DBA FirstKey/NextKey with 2 deletes [ext/dba/tests/dba006.phpt] FAIL DBA Multiple File Creation Test [ext/dba/tests/dba007.phpt] FAIL DBA magic_quotes_runtime Test [ext/dba/tests/dba008.phpt] FAIL DBA dba_popen Test [ext/dba/tests/dba009.phpt] FAIL DBA CDB handler test [ext/dba/tests/dba_cdb.phpt] FAIL DBA CDB_MAKE handler test [ext/dba/tests/dba_cdb_make.phpt] PASS DBA CDB handler test (read only) [ext/dba/tests/dba_cdb_read.phpt] FAIL DBA DB2 handler test [ext/dba/tests/dba_db2.phpt] FAIL DBA DB3 handler test [ext/dba/tests/dba_db3.phpt] FAIL DBA DB4 handler test [ext/dba/tests/dba_db4.phpt] FAIL DBA DBM handler test [ext/dba/tests/dba_dbm.phpt] FAIL DBA FlatFile handler test [ext/dba/tests/dba_flatfile.phpt] FAIL DBA GDBM handler test [ext/dba/tests/dba_gdbm.phpt] FAIL DBA NDBM handler test [ext/dba/tests/dba_ndbm.phpt] tom:johnl:php-4.3.2$ ldd /usr/local/bin/php libm.so = /shlib/libm.so.0.0 (0x48171000) libdl.so = /shlib/libdl.so (0x48182000) libgcc.so.1 = /shlib/libgcc.so.1 (0x48185000) libc.so.2 = /shlib/libc.so.2 (0x48191000) [2003-07-27 11:27:46] [EMAIL PROTECTED] Please provide the outputs of the following two commands using CLI or CGI version of php: 1) php run-tests.php ext/dba 2) ldd php [2003-07-27 11:22:26] php at johnlevine dot com On my system, it crashes with any dbm file, even one with no entries. [2003-07-27 10:10:42] [EMAIL PROTECTED] could you please provide the sample db, I am unabled to replicate the problem using a ndbm database that I have. [2003-07-26 20:40:48] php at johnlevine dot com Description: This program prints Resource handle #5, and then crashes. It works OK in 4.2.2, crashes in a version of 4.3.0 I had lying around. It crashes in the Apache module, which is where I first noticed it. There also seems to be a change since 4.2 that it used to append .db to the file name but doesn't any more. It's compiled --with-mysql --with-apxs --with-ndbm (I know that ndbm is old and tired, but it's distributed with BSD/OS and I have a lot of existing ndbm files that I'm using.) Reproduce code: --- $a = dba_popen(test.db, r, ndbm); print handle is $a\n; // prints Resource #5 $k = dba_firstkey($a); print key is $k\n; // segfaults, see trace below Expected result: should print first key in db file Actual result: -- Segmentation violation: #0 0x481b5f1d in dbm_firstkey () from /shlib/libc.so.2 #1 0x806486f in dba_firstkey_ndbm (info=0x81bdf00, newlen=0x8046070) at /home/src/php-4.3.2/ext/dba/dba_ndbm.c:126 #2 0x8063a74 in zif_dba_firstkey (ht=1, return_value=0x81bc68c, this_ptr=0x0, return_value_used=1) at /home/src/php-4.3.2/ext/dba/dba.c:704 #3 0x8139bf3 in execute (op_array=0x81bb88c) at /home/src/php-4.3.2/Zend/zend_execute.c:1608 #4 0x812821e in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/src/php-4.3.2/Zend/zend.c:869 #5 0x8100275 in php_execute_script (primary_file=0x8047a94) at /home/src/php-4.3.2/main/main.c:1671 #6 0x814188e in main (argc=2, argv=0x8047afc) at /home/src/php-4.3.2/sapi/cli/php_cli.c:806 #7 0x8061843 in
#24804 [Opn]: pg_lo_open() doesn't return a valid result ressource
ID: 24804
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: PostgreSQL related
Operating System: Win2000
PHP Version: 4.3.2
New Comment:
Please follow the instructions in ext/pgsql/tests/Readme and execute
the following command using either CLI or CGI version of PHP:
php run-tests.php ext/pgsql
Previous Comments:
[2003-07-25 12:05:17] [EMAIL PROTECTED]
Description:
pg_lo_open() doesn't return a result ressource in php 4.3.2 whereas the
same script runs properly with PHP 4.3.1
Reproduce code:
---
?php
include(lo_lib.php);
$sql = select * from bilder;
$res = pg_query($sql);
$rows = pg_numrows($res);
for ($i=0;$i$rows;$i++) {
$zeile = pg_fetch_array($res,$i);
echo 'Dateigroesse: '.$zeile[size];
pg_query(begin);
$handle = pg_lo_open($zeile[bild], r); echo 'brhandle =
'.$handle.'br';
if ($handle) {
$data = pg_loread($handle, 5);
$len = strlen($data);
echo ' | gelesen: '.$len.' Bytes';
}
pg_loclose($handle);
pg_exec(commit);
...
Expected result:
Dateigroesse: 6038
handle = Resource id #6
| gelesen: 6038 Bytes | geschrieben: 6038 Bytes
This is the result from PHP 4.3.1
Actual result:
--
Dateigroesse: 6038
handle =
Warning: pg_loclose(): supplied argument is not a valid PostgreSQL
large object resource in c:\apache\htdocs\lotest\bildtest.php on line
19
This is the result from PHP 4.3.2
--
Edit this bug report at http://bugs.php.net/?id=24804edit=1
#24827 [Opn-Csd]: ob_gzhandler overrides Vary header
ID: 24827
Updated by: [EMAIL PROTECTED]
Reported By: phpnet at shredzone dot de
-Status: Open
+Status: Closed
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 4.3.2
New Comment:
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.
Previous Comments:
[2003-07-27 06:09:27] phpnet at shredzone dot de
Description:
I am using ob_gzhandler to compress the page output. Now I need to add
an 'accept-language' to the Vary header, because my page content
depends on the language settings of the browser.
Anyhow, it is impossible to change the Vary header when using
ob_gzhandler. It seems like ob_gzhandler is overriding an existing Vary
header just before returning the compressed content to the browser.
Expected behaviour: ob_gzhandler should check if a Vary header has
already been set. If so, it should only ADD an accept-encoding unless
already present, or should not change the Vary header at all.
Reproduce code:
---
?php
header(vary: accept-encoding,accept-language);
ob_start('ob_gzhandler');
print(htmlbodyfoo/body/html);
?
Expected result:
A HTTP header vary: accept-encoding,accept-language being returned.
Actual result:
--
A HTTP header Vary: Accept-Encoding (note the uppercase letters) will
always be returned.
--
Edit this bug report at http://bugs.php.net/?id=24827edit=1
#24804 [Opn-Fbk]: pg_lo_open() doesn't return a valid result ressource
ID: 24804
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: PostgreSQL related
Operating System: Win2000
PHP Version: 4.3.2
Previous Comments:
[2003-07-27 12:36:36] [EMAIL PROTECTED]
Please follow the instructions in ext/pgsql/tests/Readme and execute
the following command using either CLI or CGI version of PHP:
php run-tests.php ext/pgsql
[2003-07-25 12:05:17] [EMAIL PROTECTED]
Description:
pg_lo_open() doesn't return a result ressource in php 4.3.2 whereas the
same script runs properly with PHP 4.3.1
Reproduce code:
---
?php
include(lo_lib.php);
$sql = select * from bilder;
$res = pg_query($sql);
$rows = pg_numrows($res);
for ($i=0;$i$rows;$i++) {
$zeile = pg_fetch_array($res,$i);
echo 'Dateigroesse: '.$zeile[size];
pg_query(begin);
$handle = pg_lo_open($zeile[bild], r); echo 'brhandle =
'.$handle.'br';
if ($handle) {
$data = pg_loread($handle, 5);
$len = strlen($data);
echo ' | gelesen: '.$len.' Bytes';
}
pg_loclose($handle);
pg_exec(commit);
...
Expected result:
Dateigroesse: 6038
handle = Resource id #6
| gelesen: 6038 Bytes | geschrieben: 6038 Bytes
This is the result from PHP 4.3.1
Actual result:
--
Dateigroesse: 6038
handle =
Warning: pg_loclose(): supplied argument is not a valid PostgreSQL
large object resource in c:\apache\htdocs\lotest\bildtest.php on line
19
This is the result from PHP 4.3.2
--
Edit this bug report at http://bugs.php.net/?id=24804edit=1
#24718 [Opn-Asn]: odbc_result_all crashes on some results
ID: 24718 Updated by: [EMAIL PROTECTED] Reported By: psychosos at gmx dot at -Status: Open +Status: Assigned Bug Type: ODBC related Operating System: Windows 2000 Professional PHP Version: 4.3.2 -Assigned To: +Assigned To: kalowsky Previous Comments: [2003-07-24 16:17:10] psychosos at gmx dot at Sorry about the delay. The database I am experiencing the problem with is an Microsoft Access Database I created with MS Access XP. The problematic table has the following schema: Table Kommentare ID long integer DEFAULT 0 NOT NULL Kommentar Memo NOT NULL Kommentator Text (50) Datum Date/Time (standard date) IP Text(15) (sorry about non-SQL conformity; I tried to transcribe the MS Access information) SELECT * FROM Kommentare crashes PHP. SELECT ID, Kommentator, Datum, IP FROM Kommentare works fine. SELECT Kommentar FROM Kommentare crashes PHP. SELECT TOP 200 Kommentar FROM Kommentare works fine as well. But SELECT Kommentar FROM Kommentare crashes PHP. If needed/helpful I might try to determine the exact number of records (bytes) which crashes PHP. Unfortunately I am not experienced debugging applications. If I can be of any further help I'd be glad to follow your instructions :-) Cheers, johannes [2003-07-19 17:30:10] [EMAIL PROTECTED] A sample schema would help tremendiously. Also what database? [2003-07-19 13:35:58] psychosos at gmx dot at Description: If I use odbc_result_all() with a result which has around 75 rows or more it crashes with an Application Error (The instruction at 0x1000ede5 referenced memory at 0x00ae. The memory could not be read. Unfortunately this only happens to me with one table and only if I retrieve longer fields (for example it only crashes when trying to retrieve a longer character field, not with my ID or a short string field) (I am sorry about this unexact bug report. If you can give me any hints how to be more helpful - please do so!) Reproduce code: --- ?php $connection = odbc_connect(Albumsliste,,); $result = odbc_exec($connection, SELECT * FROM Kommentare;); $count = odbc_result_all($result); echo \nResult count: $count\n; odbc_free_result($result); odbc_close($connection); ? Expected result: The code should output all the fields from the table named Kommentare. Actual result: -- PHP crashes with an Application Error (The instruction at 0x1000ede5 referenced memory at 0x00ae. The memory could not be read.) -- Edit this bug report at http://bugs.php.net/?id=24718edit=1
#24244 [Opn-Fbk]: odbc_errormsg() sometimes returns a bad string when no error occurs
ID: 24244
Updated by: [EMAIL PROTECTED]
Reported By: bl at btn dot de
-Status: Open
+Status: Feedback
Bug Type: ODBC related
Operating System: Red Hat Linux
PHP Version: 4.3.2
New Comment:
Actually I wanted to see the error id not the error message. So please
tell me what is the output of:
var_dump(odbc_error())
Previous Comments:
[2003-06-26 18:23:37] [EMAIL PROTECTED]
Do not add comments to your own report, use this link:
http://bugs.php.net/bug.php?id=24244edit=2
[2003-06-26 04:07:16] mb at btn dot de
Output of var_dump(odbc_errormsg()) as follows:
string(146)
31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:
string(122)
1:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:
These are only two examples. I had to reproduce the error in a small
script to generate these. That's why the variety is not that great like
in our production environment where we currently use a dirty
workaround.
[2003-06-18 10:24:52] [EMAIL PROTECTED]
What does var_dump(odbc_error()) return after a valid query?
[2003-06-18 06:54:21] bl at btn dot de
sorry ... one more thing ...
in my Actual Results section I forgot to remove the or's ...
So of course the or's are not part of the string which is returned by
odbc_errormsg() ...
[2003-06-18 06:50:30] bl at btn dot de
Description:
We use the IBMDB2 database on our systems. The following bug occured
while writing a class supposed to halt the code on database exceptions.
While checking for strlen(odbc_errormsg())==0 for aborting the routine
PHP sometimes (about once in four calls) returns Bad Strings (see
below).
Maybe the message is taken from an unallocated space on PHP's heap
?!?
It's not that much of a problem to come up with a workaround but PHP
shouldn't return random bits of the memory.
Reproduce code:
---
$link = odbc_connect(mydb, myusr,mypwd);
$sql = [INSERT FLAWLESS STATEMENT HERE];
odbc_exec($link,$sql)
if(strlen(odbc_errormsg())0) {
echo SQL-Error . odbc_errormsg();
}
odbc_close($link);
Expected result:
If $sql contains a valid statement odbc_errormsg() should return an
empty string (according to the PHP-Documentation)
Actual result:
--
Sometimes parts of the outstream, a URL, short binary data,
PHP-Variable names anything might happen ... as I mentioned above, the
data might be part of PHP's heap. Some Examples:
T_URI (?) or
(a variable name ?)
ze:12px; } .menue_common{ [... here it goes on for quite a while ...]
width: 140px; margin-bottom: 2p
(part of our stylesheet) or
ÿÿ or
(junk)
Àò or
(more junk)
aten_I or
(I have that somewhere earlier but I can't remember)
-urlencoded
(this shouldn't be an errormsg)
--
Edit this bug report at http://bugs.php.net/?id=24244edit=1
#24339 [Opn-Bgs]: Add*Filter PHP .. directives not work
ID: 24339 Updated by: [EMAIL PROTECTED] Reported By: eng at anrdaemon dot mtu-net dot ru -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Windows XP PHP Version: 4.3.2 New Comment: 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 The default apache2 interface is apache2handler which is not a filter. It's directives are pretty much the same as php's apache directives for apache 1. LoadModule php4_modulemodules/libphp4.so AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps Previous Comments: [2003-07-26 12:54:36] eng at anrdaemon dot mtu-net dot ru RTFM http://httpd.apache.org/docs-2.1/filter.html Key words: run-time configuration directives I can't use AddType in .htaccess files. [2003-06-25 18:05:18] [EMAIL PROTECTED] RTFM: http://www.php.net/manual/en/install.apache2.php [2003-06-25 16:41:35] eng at anrdaemon dot mtu-net dot ru Description: When I installing a 4.3.2 release version after 4.3.1, all of my pages sent to the users as stored - no PHP processing done at all. When I change configuration from AddInputFilter PHP .php AddOutputFilter PHP;INCLUDES .php to AddType application/x-httpd-php .php .php4 all pages works well, but this trick is NOT usable to me. 4.3.1 works well... 4.3.3RC1 works same as 4.3.2. -- Edit this bug report at http://bugs.php.net/?id=24339edit=1
#24810 [Opn-NoF]: sessions not overwritten properly
ID: 24810
Updated by: [EMAIL PROTECTED]
Reported By: dkaplan1 at uiuc dot edu
-Status: Open
+Status: No Feedback
Bug Type: Session related
Operating System: Solaris SunOS 5.9
PHP Version: 4.3.1
New Comment:
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
Previous Comments:
[2003-07-25 16:31:54] dkaplan1 at uiuc dot edu
Description:
Data that is newly written to the session hash is not getting stored
correctly. If I am storing two pieces of data (a string and a type of
view for example) in the session hash, the hash should only contain the
latest values of those two variables. Instead, as in the example
provided, the form randomly changes between the views, and the data
shown is not always the latest in the hash. Usually, it is from
previous submissions.
This seems to be a problem in IE and Netscape, but not in Mozilla.
Reproduce code:
---
?
session_cache_limiter('public');
session_start();
if (isset($_POST['submit'])) {
$_SESSION['data']=$_POST['data'];
} if (isset($_GET['form'])) {
$_SESSION['form']=$_GET['form'];
} if (!isset($_SESSION['form'])) {
$_SESSION['form']='basic';
} if ($_SESSION['form']=='basic') {
echo 'The value of the variable is '.$_SESSION['data'];
} if ($_SESSION['form']=='advanced') {
echo 'Here is a complete dump of the session hash ';
var_dump($_SESSION);
}
?brbr
a href=bug.php?form=basicBasic/abra
href=bug.php?form=advancedAdvanced/abr
form method=post action=bug.phpData: input type=text name=data
value=
input type=submit name=submit value=submit/form
Expected result:
When you type in a value, it should appear. When you switch views, the
data value should stay the same, only the view changes. When you enter
different data, only the data changes, the view stays the same.
Actual result:
--
View randomly changes and data is not always last entered.
--
Edit this bug report at http://bugs.php.net/?id=24810edit=1
#24828 [Opn-Asn]: round() function doesn't round !
ID: 24828 Updated by: [EMAIL PROTECTED] Reported By: christophe dot bidaux at netcourrier dot com -Status: Open +Status: Assigned Bug Type: Math related Operating System: Windows 98SE PHP Version: 4CVS-2003-07-27 (stable) -Assigned To: +Assigned To: edink Previous Comments: [2003-07-27 06:34:19] christophe dot bidaux at netcourrier dot com Description: the round() function doesn't give me the results described in the documentation example. Reproduce code: --- // from the documentation example $foo = round( 3.4 ); // $foo == 3.0 var_dump($foo); $foo = round( 3.5 ); // $foo == 4.0 var_dump($foo); $foo = round( 3.6 ); // $foo == 4.0 var_dump($foo); Expected result: float(3) float(4) float(4) (PHP Version 4.3.3RC1 version) Actual result: -- float(3) float(3) float(3) (PHP Version 4.3.3RC2-dev (Jul 27 2003 10:11:04) version) -- Edit this bug report at http://bugs.php.net/?id=24828edit=1
#24795 [Fbk-Bgs]: UNC Paths using IIS 5.0 and Win2k
ID: 24795
Updated by: [EMAIL PROTECTED]
Reported By: jf dot klug at canfer dot com
-Status: Feedback
+Status: Bogus
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.3.2
New Comment:
..
Previous Comments:
[2003-07-26 18:14:14] [EMAIL PROTECTED]
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.
Thank you for your interest in PHP.
You need to use something like this:
$dir = drive\\dir;
[2003-07-26 11:27:45] jf dot klug at canfer dot com
I've done //servername/sharedfolder and it doesn't work either. I'm
puzzled as to why it's not giving me any error at all. I checked the
php settings for error reporting, and they were set to show all errors,
so what gives?
[2003-07-24 11:44:37] [EMAIL PROTECTED]
You cannot do dir \\servername from the command prompt; you have to
use dir \\servername\sharename.
The same restrictions apply to PHP.
[2003-07-24 11:19:13] jf dot klug at canfer dot com
Description:
I'm trying to open a directory that is on a win2k network share. I've
read about UNC path problems, and they all claim to have been fixed in
4.0.6 or somthing like that, but i'm using 4.3.2 and it's still not
working. This code was ripped straight form the php documentation:
?php
$dir = /tmp/;
// Open a known directory, and proceed to read its contents
if (is_dir($dir)) {
if ($dh = opendir($dir)) {
while (($file = readdir($dh)) !== false) {
print filename: $file : filetype: . filetype($dir .
$file) . br;
}
closedir($dh);
}
}
?
Now when I make $dir equal to //shareddrive/ or shareddrive\\
nothing happens, no error or anything. Same thing happens if I map the
drive to a letter, like z:, it still does nothing. It doesn't list
the directory, nor does it give an error. The server has full rights to
connect with the shared folder, so it's not a permissions thing. It
also doesn't work when I use the UNC path for the webserver that this
script is running on, but it does work when I just list ./ so I think
it's just a problem with UNC paths. The server is running IIS 5.0 and
php 4.3.2. Yes there are other UNC path bug reports, but they've all
been dissmissed and stated that it's fixed in 4.0.6, but I'm using a
way later version then that and it's not fixed, so what gives?
Reproduce code:
---
?php
$dir = //fileserv/;
// Open a known directory, and proceed to read its contents
if (is_dir($dir)) {
if ($dh = opendir($dir)) {
while (($file = readdir($dh)) !== false) {
print filename: $file : filetype: . filetype($dir .
$file) . br;
}
closedir($dh);
}
}
?
Expected result:
Should list all files and folders in that directory.
Actual result:
--
A blank page. No error or nothing.
--
Edit this bug report at http://bugs.php.net/?id=24795edit=1
#24817 [Opn-WFx]: Suggestion on Function Handling functions
ID: 24817 Updated by: [EMAIL PROTECTED] Reported By: jimsonchang at yahoo dot com -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: XPbox PHP Version: 4.3.2 New Comment: And lose backwards compatibility? Yeah, right. Previous Comments: [2003-07-26 07:38:22] jimsonchang at yahoo dot com Description: i got a suggestion on Function Handling functions for better standardization and better php eg. call_user_func_array() can be changed to func_call_array() // since user might call internal function, not necessary user functions call_user_func() can be changed to func_call() // since user might call internal function also create_function() can be changed to func_create() func_get_arg() can be changed to func_arg() // no need the get word because we can't post or give func_get_args() can be changed to func_args() // like the above reason, because we can't post or give // and we already post/give in call_user_func() func_num_args() can be changed to func_args_num() // follow the above standard function_exists() can be changed to func_exists() get_defined_functions() can be changed to func_int_list() and func_usr_list() // since user no need to copy an array or unset to get the user or internal functions list register_shutdown_function() can be changed to func_reg_shutdown() register_tick_function() can be changed to func_tick_reg() unregister_tick_function() can be changed to func_tick_unreg() -- Edit this bug report at http://bugs.php.net/?id=24817edit=1
#24557 [WFx-Csd]: streams SIG_SEGVs
ID: 24557 Updated by: [EMAIL PROTECTED] Reported By: wmeler at wp-sa dot pl -Status: Wont fix +Status: Closed Bug Type: Network related Operating System: RH 7.3 PHP Version: 4CVS-2003-07-09 (stable) Assigned To: wez New Comment: 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. Previous Comments: [2003-07-11 04:48:45] [EMAIL PROTECTED] So, you patched your web server, you patched PHP and compiled it in the unsupported maintainer thread-safe mode and expect me to fix the segfault? :-) Maybe its better for you to ask questions on the internals list if you are developing your own SAPI. Not a bug in any of the supported PHP configurations, so we are not going to fix it. [2003-07-10 08:49:04] [EMAIL PROTECTED] Assigned to the father of streams. :) [2003-07-10 01:54:24] wmeler at wp-sa dot pl I enable ZTS, because I use threads. I have one IO thread and more PHP threads. As I said, it isn't pure thttpd and PHP. My web server has quite nice architecture - I have queues, processors, queue overflow control etc. About configure parameters - I use the same compilation on another web aplications and it is working well. Difference is that they don't use socket streams. They use oci8 and ldap without any problems. As far I know oracle ldap functions doesn't perform well and we use iplanet libraries with success. No problems with that. I can reduce config.nice by only few modules (ftp zlib gdbm gettext xml). Others are needed by my app. Anyway - don't you think that these STREAM_DEBUG messages are strange? [2003-07-09 18:07:40] [EMAIL PROTECTED] You should reduce the configure options to bare minimum, try with this configure line: # ./configure --with-thttpd=../thttpd --disable-all --enable-debug Why do you enable the ZTS anyway? Also, using --with-regex=system is not wise unless you REALLY know what you're doing. And Oracle has it's own ldap functions, it's known problem that those might conflict with other ldap libraries. Just point the --with-ldap to the same as you do with --with-oci8. [2003-07-09 04:55:39] wmeler at wp-sa dot pl PHP is taken from snaps.php.net : php4-STABLE-200307081130 './configure' \ '--with-thttpd=../thttpd' \ '--enable-experimental-zts' \ '--with-tsrm-pthreads' \ '--with-regex=system' \ '--with-mysql=/usr' \ '--with-oci8=/opt/oracle' \ '--with-ldap=/opt/iplanet' \ '--with-mhash' \ '--enable-ftp' \ '--with-zlib' \ '--with-gdbm' \ '--with-gettext' \ '--with-xml' \ '--enable-debug' \ $@ I've patched thttpd and PHP so it worked fine together in ZTS. I haven't touched streams. It worked until streams were introduced (4.3?). BTW are memory and fds freed if there is no msg in log like stream_free I think I won't be able to write short script which reproduct this error because it isn't on each request :(. 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/24557 -- Edit this bug report at http://bugs.php.net/?id=24557edit=1
#24829 [Bgs]: array_intersect_assoc compares keys AND values
ID: 24829 User updated by: niklas at zim dot goe dot net Reported By: niklas at zim dot goe dot net Status: Bogus Bug Type: Arrays related Operating System: Linux 2.4.20 PHP Version: 4.3.1 New Comment: Maybe you can point this out in the documentation. Previous Comments: [2003-07-27 10:03:43] [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 The displayed behaviour is the correct one. [2003-07-27 08:34:40] niklas at zim dot goe dot net Description: The function array_intersect_assoc compares keys AND values. According to the documentation only the keys should be considered. The documentation says: Note that the keys are used in the comparison unlike in array_intersect(). If this is the volitional behavior you should point that out in the documentation (... that the keys are used too ...). Reproduce code: --- $array1 = array (a = green); $array2 = array (a = greenToo); print_r(array_intersect_assoc ($array1, $array2)); Expected result: Array( [a] = green ) Actual result: -- Array() -- Edit this bug report at http://bugs.php.net/?id=24829edit=1
#21532 [Asn-Fbk]: incorrect warning
ID: 21532 Updated by: [EMAIL PROTECTED] Reported By: czuma at poland dot org -Status: Assigned +Status: Feedback Bug Type: *Directory/Filesystem functions Operating System: Solaris 8 PHP Version: 4.3.1 Assigned To: wez New Comment: 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 Previous Comments: [2003-03-22 14:20:35] czuma at poland dot org I have checked php4-STABLE-200303221630 (PHP/4.3.2-RC) Unfortunately, it doesn't work. I still see incorrect warning. [2003-03-18 11:47: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 [2003-03-01 12:07:47] czuma at poland dot org I have checked php4-STABLE-200303011230 Unfortunately it doesn't work. I still see incorrect warning: SAFE MODE Restriction in effect. The script whose uid is XXX is not allowed to access /www/user/data owned by uid 0 in /www/user/stale/table1a.php on line 3 Line 3: $my=opendir(/www/user/data/$dat); Probably: $dat=blabla/bleble.txt Directory blabla doesn't exist. I see correct and then incorrect warning. [2003-02-25 03:58:26] [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-25 01:42:35] rohan at cs dot rmit dot edu dot au Opps, lost part of the error... it is: Warning: filemtime() [function.filemtime]: SAFE MODE Restriction in effect. The script whose uid/gid is 1/31748 is not allowed to access /home/m/malsmith/.HTMLinfo/lastmodified owned by uid/gid 31748/103 in /home/m/malsmith/.HTMLinfo/software.php on line 3 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/21532 -- Edit this bug report at http://bugs.php.net/?id=21532edit=1
#24810 [NoF-Fbk]: sessions not overwritten properly
ID: 24810
Updated by: [EMAIL PROTECTED]
Reported By: dkaplan1 at uiuc dot edu
-Status: No Feedback
+Status: Feedback
Bug Type: Session related
Operating System: Solaris SunOS 5.9
PHP Version: 4.3.1
Previous Comments:
[2003-07-27 13:23:57] [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-07-25 16:31:54] dkaplan1 at uiuc dot edu
Description:
Data that is newly written to the session hash is not getting stored
correctly. If I am storing two pieces of data (a string and a type of
view for example) in the session hash, the hash should only contain the
latest values of those two variables. Instead, as in the example
provided, the form randomly changes between the views, and the data
shown is not always the latest in the hash. Usually, it is from
previous submissions.
This seems to be a problem in IE and Netscape, but not in Mozilla.
Reproduce code:
---
?
session_cache_limiter('public');
session_start();
if (isset($_POST['submit'])) {
$_SESSION['data']=$_POST['data'];
} if (isset($_GET['form'])) {
$_SESSION['form']=$_GET['form'];
} if (!isset($_SESSION['form'])) {
$_SESSION['form']='basic';
} if ($_SESSION['form']=='basic') {
echo 'The value of the variable is '.$_SESSION['data'];
} if ($_SESSION['form']=='advanced') {
echo 'Here is a complete dump of the session hash ';
var_dump($_SESSION);
}
?brbr
a href=bug.php?form=basicBasic/abra
href=bug.php?form=advancedAdvanced/abr
form method=post action=bug.phpData: input type=text name=data
value=
input type=submit name=submit value=submit/form
Expected result:
When you type in a value, it should appear. When you switch views, the
data value should stay the same, only the view changes. When you enter
different data, only the data changes, the view stays the same.
Actual result:
--
View randomly changes and data is not always last entered.
--
Edit this bug report at http://bugs.php.net/?id=24810edit=1
#24694 [Opn-Bgs]: File upload support does not populate $_FILES, $_POST
ID: 24694 Updated by: [EMAIL PROTECTED] Reported By: namejko at topiksolutions dot com -Status: Open +Status: Bogus Bug Type: HTTP related Operating System: Windows NT 5.1 build 2000 (XP) PHP Version: 4.3.3RC2-dev New Comment: Works fine here with Apache 1.3.28. Not PHP bug but some configuration issue within your server. Previous Comments: [2003-07-25 11:39:38] namejko at topiksolutions dot com variables_order: EGPCS gcp_order: GPC [2003-07-24 22:30:02] [EMAIL PROTECTED] s/gpc_order/variables_order [2003-07-24 21:11:17] [EMAIL PROTECTED] What is your gpc_order setting set to? [2003-07-22 12:24:37] namejko at topiksolutions dot com Apache/1.3.26 (Win32) mod_perl/1.25 mod_ssl/2.8.10 OpenSSL/0.9.6c DAV/1.0.3 Auth NuSphere/1.0.0 running... It's from PHPEd, by NuSphere. [2003-07-22 10:36:54] [EMAIL PROTECTED] Which webserver are you using? Apache? IIS? 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/24694 -- Edit this bug report at http://bugs.php.net/?id=24694edit=1
#24786 [Opn-Fbk]: xslt_set_encoding still not available
ID: 24786 Updated by: [EMAIL PROTECTED] Reported By: happycloud at undream dot com -Status: Open +Status: Feedback Bug Type: XSLT related Operating System: Linux 2.4 PHP Version: 4.3.3RC1 New Comment: Please give the information I requested. Previous Comments: [2003-07-26 00:16:31] happycloud at undream dot com If I use the -x option I get nothing. Batch xml? But sabcmd myxml myxsl gives correct output. As in sablotron's faq, I added different encodings to my xml and xsl. This is the only way I know to test. xsl: ?xml version=1.0? xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:output indent=no encoding=ISO-8859-1/ snip--- xm;: ?xml version=1.0 encoding=UTF-8? Not sure if this is the best way to test. I certainly get no errors. joshua myxml---snip--- [2003-07-25 17:09:07] [EMAIL PROTECTED] Can you please also make sure that you indeed compiled Sablotron with iconv support, i.e. try sabcmd -x your.xml your.xsl? I have been fighting with Sablotron and iconv on Solaris today (to no avail so far), and although I never had problems with that on Linux, it might give a hint to the problem's cause. [2003-07-24 06:26:07] [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 And if this fails with the snapshot, check the config.log for 'SablotSetEncoding' and any errors after that check. [2003-07-24 01:03:08] happycloud at undream dot com On a side note. I took a look at libsablot.a and I have: ... 1004 T SablotSetBaseForScheme 1420 T SablotSetEncoding 000 Does that mean that SablotSetEncoding function is indeed available and php is not detecting that? joshua [2003-07-24 00:57:35] happycloud at undream dot com Description: I have compiled sablot with iconv support which as I undertsand it, is the way to add encoding support? correction? I have also compiled php with sablot,expat, iconv (sometimes) to no avail. I still get a undefined function xslt_set_encoding. According to sablot, the way to use encoding directly is to specify it in the xml and xsl. I have done so and been able to get output from the sablot binary. Is there a sure way to tell that sablot does indeed have encoding support? I believe it does. I have tried 4.3.1, 4.3.2, snaps from 4.3x and 4.5 as of today and I get the same problem. After defining HAVE_SABLOT_SET_ENCODING in sablot.c, I can get it to work but I have seen this note on another bug : ---snip--- /* The user has to explicitly compile sablotron with sablotron encoding functions in order for SablotSetEncoding to be enabled. */ This means xslt_set_encoding() won't be available if your sablot installation hasn't got the SablotSetEncoding enabled snip--- Just how does one do that if sablot does not complain right now? joshua Expected result: -- Edit this bug report at http://bugs.php.net/?id=24786edit=1
#24824 [Fbk-Opn]: dba_ routines with ndbm crash
ID: 24824 User updated by: php at johnlevine dot com Reported By: php at johnlevine dot com -Status: Feedback +Status: Open Bug Type: DBM/DBA related Operating System: BSD/OS 4.3.1 PHP Version: 4.3.2 Assigned To: helly New Comment: All the system libraries are the standard ones. We may have an arcane difference between BSD/OS and other BSDs, assuming we know this works on other BSDs. I could try it on FreeBSD 4.8. tom:johnl:php-4.3.2$ php -r 'echo print_r(dba_handlers());' Array ( [0] = ndbm [1] = cdb [2] = cdb_make [3] = flatfile ) Previous Comments: [2003-07-27 12:33:35] [EMAIL PROTECTED] The result should be impossible with normal builds. Did you compile your own libc or something like that? Please execute: php -r 'echo print_r(dba_handlers());' You could also provide me with your config.log per email but stick to the list for the rest. [2003-07-27 11:41:18] php at johnlevine dot com tom:johnl:php-4.3.2$ TEST_PHP_EXECUTABLE=/usr/local/bin/php php run-tests.php ext/dba = CWD : /home/src/php-4.3.2 PHP : /usr/local/bin/php PHP_SAPI: cli PHP_VERSION : 4.3.2 ZEND_VERSION: 1.3.0 PHP_OS : BSD/OS INI actual : /usr/local/lib/php.ini More .INIs : Extra dirs : = Running selected tests. FAIL DBA File Creation Test [ext/dba/tests/dba001.phpt] FAIL DBA Insert/Fetch Test [ext/dba/tests/dba002.phpt] FAIL DBA Insert/Replace/Fetch Test [ext/dba/tests/dba003.phpt] FAIL DBA Multiple Insert/Fetch Test [ext/dba/tests/dba004.phpt] FAIL DBA FirstKey/NextKey Loop Test With 5 Items [ext/dba/tests/dba005.phpt] FAIL DBA FirstKey/NextKey with 2 deletes [ext/dba/tests/dba006.phpt] FAIL DBA Multiple File Creation Test [ext/dba/tests/dba007.phpt] FAIL DBA magic_quotes_runtime Test [ext/dba/tests/dba008.phpt] FAIL DBA dba_popen Test [ext/dba/tests/dba009.phpt] FAIL DBA CDB handler test [ext/dba/tests/dba_cdb.phpt] FAIL DBA CDB_MAKE handler test [ext/dba/tests/dba_cdb_make.phpt] PASS DBA CDB handler test (read only) [ext/dba/tests/dba_cdb_read.phpt] FAIL DBA DB2 handler test [ext/dba/tests/dba_db2.phpt] FAIL DBA DB3 handler test [ext/dba/tests/dba_db3.phpt] FAIL DBA DB4 handler test [ext/dba/tests/dba_db4.phpt] FAIL DBA DBM handler test [ext/dba/tests/dba_dbm.phpt] FAIL DBA FlatFile handler test [ext/dba/tests/dba_flatfile.phpt] FAIL DBA GDBM handler test [ext/dba/tests/dba_gdbm.phpt] FAIL DBA NDBM handler test [ext/dba/tests/dba_ndbm.phpt] tom:johnl:php-4.3.2$ ldd /usr/local/bin/php libm.so = /shlib/libm.so.0.0 (0x48171000) libdl.so = /shlib/libdl.so (0x48182000) libgcc.so.1 = /shlib/libgcc.so.1 (0x48185000) libc.so.2 = /shlib/libc.so.2 (0x48191000) [2003-07-27 11:27:46] [EMAIL PROTECTED] Please provide the outputs of the following two commands using CLI or CGI version of php: 1) php run-tests.php ext/dba 2) ldd php [2003-07-27 11:22:26] php at johnlevine dot com On my system, it crashes with any dbm file, even one with no entries. [2003-07-27 10:10:42] [EMAIL PROTECTED] could you please provide the sample db, I am unabled to replicate the problem using a ndbm database that I have. 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/24824 -- Edit this bug report at http://bugs.php.net/?id=24824edit=1
#24811 [Fbk-Bgs]: recursive data structures issue
ID: 24811 Updated by: [EMAIL PROTECTED] Reported By: xris at siliconmechanics dot com -Status: Feedback +Status: Bogus -Bug Type: Zend Engine 2 problem +Bug Type: Scripting Engine problem Operating System: redhat 7.3, 8 and 9 -PHP Version: Irrelevant +PHP Version: 4.2.2 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. 4.2.2 is to old. Previous Comments: [2003-07-26 00:58:39] [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 The version is never irrelevant in a crash bug.. And your assumption is wrong =) With PHP5-cvs: [107874] = b Object ( [a] = a Object *RECURSION* ) ) ) /opt/dev/php/php5/Zend/zend_hash.c(374) : Freeing 0x45660F20 (35 bytes), script=24811.php Last leak repeated 107874 times /opt/dev/php/php5/Zend/zend_hash.c(233) : Freeing 0x45660EC4 (37 bytes), script=24811.php Last leak repeated 107875 times /opt/dev/php/php5/Zend/zend_API.c(677) : Freeing 0x45660E70 (32 bytes), script=24811.php /opt/dev/php/php5/Zend/zend_hash.c(154) : Actual location (location was relayed) Last leak repeated 107875 times /opt/dev/php/php5/Zend/zend_execute.c(3037) : Freeing 0x45660E0C (44 bytes), script=24811.php /opt/dev/php/php5/Zend/zend_API.c(676) : Actual location (location was relayed) Last leak repeated 107875 times /opt/dev/php/php5/Zend/zend_objects.c(95) : Freeing 0x45660DC8 (12 bytes), script=24811.php Last leak repeated 107875 times /opt/dev/php/php5/Zend/zend_execute.c(3036) : Freeing 0x45660D84 (16 bytes), script=24811.php Last leak repeated 107875 times /opt/dev/php/php5/Zend/zend_hash.c(408) : Freeing 0x42F5103C (524288 bytes), script=24811.php /opt/dev/php/php5/Zend/zend_hash.c(154) : Actual location (location was relayed) /opt/dev/php/php5/Zend/zend_execute.c(793) : Freeing 0x42D6F4B8 (44 bytes), script=24811.php /opt/dev/php/php5/Zend/zend_variables.c(122) : Actual location (location was relayed) Last leak repeated 1 time 107K items in the array and it didn't die. PHP4-cvs: [4] = b Object ( [a] = a Object ( [items] = Array *RECURSION* ) ) ) ) /opt/dev/php/php4/Zend/zend_hash.c(406) : Freeing 0x091CB92C (35 bytes), script=24811.php Last leak repeated 4 times /opt/dev/php/php4/Zend/zend_hash.c(178) : Freeing 0x091CB884 (32 bytes), script=24811.php Last leak repeated 40001 times /opt/dev/php/php4/Zend/zend_API.c(594) : Freeing 0x091CB824 (44 bytes), script=24811.php /opt/dev/php/php4/Zend/zend_API.c(582) : Actual location (location was relayed) Last leak repeated 40001 times /opt/dev/php/php4/Zend/zend_execute.c(1975) : Freeing 0x091CB7E4 (12 bytes), script=24811.php Last leak repeated 40001 times /opt/dev/php/php4/Zend/zend_hash.c(262) : Freeing 0x091CB734 (37 bytes), script=24811.php Last leak repeated 40001 times /opt/dev/php/php4/Zend/zend_hash.c(440) : Freeing 0x4032D02C (262144 bytes), script=24811.php /opt/dev/php/php4/Zend/zend_execute.c(774) : Freeing 0x081F13AC (44 bytes), script=24811.php /opt/dev/php/php4/Zend/zend_variables.c(122) : Actual location (location was relayed) Last leak repeated 1 time 40k objects worked just fine, but somewhere around 50k it died. But there is no crash here. Just a couple of memleaks. [2003-07-25 16:43:15] xris at siliconmechanics dot com Description: Can't upgrade, production environment. Happens on 4.2.2 and earlier, and I'm forced to assume that it's still happening on more modern versions. Ran into this problem with a much more complicated piece of code. Basically, I have an array nested in an object. The array contains other objects that then reference the parent object ala circular linked-list. The provided example uses print_r to create an overflow, though my actual code the overflow happens elsewhere (I can't figure out where in my code the overflow is being generated, since I never actually traversed the list, as print_r does). I know that it's the same problem because both print_r and my code stabilize the instant I remove the recursive entry from the second object (luckily for me, it wasn't
#24820 [Opn-Bgs]: Configuration Problem
ID: 24820 Updated by: [EMAIL PROTECTED] Reported By: nagarajan2000 at hotmail dot com -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Windows 2000Professional PHP Version: 5.0.0b1 (beta1) 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. Thank you for your interest in PHP. And later betas will have this 'fixed'. Previous Comments: [2003-07-26 10:47:27] nagarajan2000 at hotmail dot com Description: Hi, Have installed PHP 5.0.b1 with Apache1.3.x. Getting the configuration error as others have in the report bugs area. Though i know that its not a bug and a configuration issue, the way you have told to fix that didn't helped me. I have changed php4_module to php5_module in the httpd.conf file. But still i get error. The exact error i get is: Syntax error on line 193 of c:/programfiles/apache group/apache/conf/httpd.conf cannot load c:/php/sapi/php4apache.dll into server: 126 The specified module could not be found: What should i do now to make php 5.0 working? Can anyone help? If so, please mail me to [EMAIL PROTECTED] Thanks. Expected result: Was expecting php 5.0 working fine. Actual result: -- Got error huh Syntax error on line 193 of c:/programfiles/apache group/apache/conf/httpd.conf cannot load c:/php/sapi/php4apache.dll into server: 126 The specified module could not be found: -- Edit this bug report at http://bugs.php.net/?id=24820edit=1
#24809 [Opn-WFx]: Packaging PHP Applications for Easy Distribution
ID: 24809 Updated by: [EMAIL PROTECTED] Reported By: lee at semel dot net -Status: Open +Status: Wont fix Bug Type:Feature/Change Request PHP Version: Irrelevant New Comment: We already have PEAR for this. (pear install) Previous Comments: [2003-07-25 16:28:46] lee at semel dot net Description: Since PHP is often used for distributing entire applications at once, it would be great to have a mechanism (similar to Java's WAR files) to make it easy to package, distribute, install, and configure them. I propose implementing a system for easily packaging PHP applications. A .PAR file (PHP ARchive) file is a zipfile containing the following: * All the images, includes, and php files that make up the PHP application. * a PHP.INI file configured specific to the application. PHP would ignore values from the master PHP.INI file and use the settings from the PHP.INI file inside the archive. * a WEB.XML (or WEB.INI) file defining default configuration parameters speicifc to the application. Configuration parameters should be able to be overridden by an external file, making them very easy to edit, and to provide an easy way to set up server-specific configurations when installing an application in multiple places. The application would be accessed through the browser at http://servername:port/nameofarchive/, or at another location specified by the administrator. Wioth this system, each application could have its own configuration, include path, and libraries, and installing an application becomes a matter of dropping the file into your document root. If your ISP doesn't let you change PHP.ini, simply installing the PAR file will set everything perfectly for you. No more having to worry if magic_quotes_gpc or register_globals is set correctly. No more having to worry if PEAR is installed. For more info on how Java does it: http://access1.sun.com/techarticles/simple.WAR.html -- Edit this bug report at http://bugs.php.net/?id=24809edit=1
#23038 [Asn-Ana]: PHP does not detect parent class inside child class' constructor
ID: 23038
Updated by: [EMAIL PROTECTED]
-Summary: aggregate() leaks causing apache to segfault
Reported By: black at sunshine dot krneki dot org
-Status: Assigned
+Status: Analyzed
Bug Type: Scripting Engine problem
Operating System: linux debian
PHP Version: 4.3.3RC2-dev
Assigned To: andrei
New Comment:
This problem has little to do with aggregation functions. This is a ZE
scripting language problem. This can be demonstrated by adding
var_dump(get_class($this)) inside the foo constructor. It'll always
print foo, the name of the class for the class the constructor is
for, not the 'real' class.
Previous Comments:
[2003-06-23 18:02:59] [EMAIL PROTECTED]
Andrei, can you take a look please..?
[2003-06-23 17:35:43] black at sunshine dot krneki dot org
Got Result:
Doing bar as foo ...
Array
(
[bar] = Array
(
[methods] = Array
(
[0] = doit
)
[properties] = Array
(
)
)
)
Doing bar as foo ...
i know the get_class() returns wrong classname on second hit, as it
returns 'foo' instead of 'foobar'.
Expected result should be:
Doing bar as foo ...
Doing bar as foobar ...
Clear enough for you, sniper, buddy? (sorry about this taunt)
[2003-06-23 17:25:27] [EMAIL PROTECTED]
Not enough info (as in: what was the expected result, etc..etc..)
[2003-06-21 09:17:30] hewei at ied dot org dot cn
The bug is not fixed. Run the following script either before or after
applying andrei's recent patch, one will reproduct the bug.
?php
class bar {
function doit()
{
print Doing bar as . get_class($this) . ...\n;
}
}
class foo {
function foo()
{
print_r(aggregation_info($this));
aggregate($this, bar);
}
}
class foobar extends foo {
}
$a = new foo();
$a-doit();
unset($a);
$b = new foobar();
$b-doit();
?
[2003-06-04 14:02:58] [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.
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/23038
--
Edit this bug report at http://bugs.php.net/?id=23038edit=1
#24066 [Fbk-NoF]: socket_read() in PHP_NORMAL_READ exits abnormally
ID: 24066
Updated by: [EMAIL PROTECTED]
Reported By: jason at superlink dot net
-Status: Feedback
+Status: No Feedback
Bug Type: Sockets related
Operating System: FreeBSD 4.8
PHP Version: 4.3.2
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
Previous Comments:
[2003-07-21 10:11:41] [EMAIL PROTECTED]
Can you try your example with var_dump($buffer) in your code?
socket_read returns boolean(FALSE) on an actual error, and empty string
when the connecting system has closed the connection. The connection
closed is not considered and error, and thus socket_last_error() is 0
(no error)
If you don't like this behaivior there is socket_recv, which returns
the length of the message returned(0 = connection close), and takes a
buf argument of the string, but it does not have the PHP_NORMAL_READ
capibility.
If this is the problem you should recode tests of socket_read like so
if (($buffer = socket_read($socket, 2048, xxx)) === FALSE) {
// Error has occured
} else if (empty($buffer)) {
// client disconnected
} else {
// do something with data
}
-Jason
[2003-06-06 21:50:20] jason at superlink dot net
Okay, a few things to add to my post...
I wanted to add that my initial assessment that binary_read did not
suffer from this issue is false.
In my inital test with binary read, I thought that simply watching the
socket download data was enough to validate if the issue was with
normal_read. There was one glaring diff between normal_read and
binary_read -- my software was only able to properly process input data
from normal_read. After a bit of tweaking, I made binary_read also
function and properly parse input. Once it was processing input, it too
had socket disconnects. Without processing input, it's simply reading
in data, with processing, it has to check data with a RDBMs, which
causes a slight delay between reads.
Perhaps this bit of info can help narrow down the problem.
Also, I wanted to add that I read the bug report about socket_read()
returning an infinate number of \n ...
(http://bugs.php.net/bug.php?id=21760), that bug is still present in
4.3.2. I had to write a shell script to watch for cpu use over 40% and
kill the process. It seems to happen around ~5% of the time.
[2003-06-06 14:36:06] jason at superlink dot net
I'm running a socket connection that needs NORMAL_READ mode enabled.
Here is a sample of the socket connection:
?php
while(1){
$r = array($socket);
if(socket_select($r, $w, $except = NULL, 0)) {
if($buffer = socket_read($socket, 2048,
PHP_NORMAL_READ)) {
$data=trim($buffer);
dostuff($data);// do something with the data.
} else {
// for some reason my socket connection FAILS a
lot.
die(ERROR: failed to read socket to
$remotehost);
}
} else {
sleep(1);
}
}
?
In the event of an error, I've been logging the error:
socket_strerror(socket_last_error())
The error for the last 5 attempts has returned:
uptime: 211 Unknown error: 0
uptime: 439 Unknown error: 0
uptime: 275 Unknown error: 0
uptime: 279 Unknown error: 0
uptime: 395 Unknown error: 0
The socket connection doesn't seem to want to stay alive for long. The
error message seems very unfriendly. I've tried the program in
binary mode (while my program doesn't function with binary mode on, it
can still download and read from the socket). In binary mode, the
problem does not occur.
I've tried NORMAL_READ with and without socket blocking, with the same
results (unexplained socket error).
this problem seems to have been happening in php 4.3.1 too.
Configure Command './configure' '--prefix=/usr/local'
'--with-apache=/home/jason/apache_1.3.27' '--enable-exif'
'--enable-track-vars' '--with-calendar=shared' '--enable-magic-quotes'
'--enable-trans-sid' '--enable-wddx' '--enable-sockets'
'--disable-debug' '--enable-gd-native-tt' '--with-zlib'
'--enable-inline-optimization' '--enable-memory-limit'
'--with-mysql=/usr/local'
--
Edit this bug report at http://bugs.php.net/?id=24066edit=1
#24736 [Fbk-NoF]: socket_set_timeout have no effect
ID: 24736 Updated by: [EMAIL PROTECTED] Reported By: sanry at now dot net dot cn -Status: Feedback +Status: No Feedback Bug Type: Network related Operating System: redhat8 redhat9 PHP Version: 4.3.3RC1 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. Previous Comments: [2003-07-21 08:55:28] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. [2003-07-21 08:36:25] sanry at now dot net dot cn Description: socket_set_timeout have no effect and after fsockopen fread or fgets can't get long stream ( yes much better than the the suck php4.3.2 , so disappint our website have so many bugs for upgrade to php4.3 serial) -- Edit this bug report at http://bugs.php.net/?id=24736edit=1
#24724 [Fbk-NoF]: Link failure with --disable-cgi --enable-cli
ID: 24724 Updated by: [EMAIL PROTECTED] Reported By: kyle at putnamcabinets dot com -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: Debian GNU/Linux (Sid) PHP Version: 4.3.3RC1 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. Previous Comments: [2003-07-20 05:38:33] [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-07-20 03:16:04] kyle at putnamcabinets dot com Description: Configured PHP with: ./configure --prefix=/usr --with-cli --with-regex=php --with-config-file-path=/etc/php/apache --disable-rpath --disable-debug --enable-memory-limit --with-layout=GNU --enable-calendar --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-trans-sid --enable-bcmath --with-bz2 --enable-ctype --with-iconv --enable-exif --enable-filepro --enable-ftp --with-gettext --enable-mbstring --with-pcre-regex=/usr --enable-shmop --enable-sockets --enable-wddx --disable-xml --with-expat-dir=/usr --enable-yp --with-zlib --with-pgsql=shared,/usr --with-kerberos=/usr --with-openssl=/usr --with-exec-dir=/usr/lib/php4/libexec --disable-static --with-curl=shared,/usr --with-dom=shared,/usr --with-dom-xslt=shared,/usr --with-dom-exslt=shared,/usr --with-zlib-dir=/usr --with-gd=shared --with-jpeg-dir=shared,/usr --with-xpm-dir=shared,/usr/X11R6 --with-png-dir=shared,/usr --with-freetype-dir=shared,/usr --with-imap=shared,/usr --with-imap-ssl --with-mcal=shared,/usr --with-mhash=shared,/usr --with-mcrypt=shared,/usr --with-mysql --with-unixODBC=shared,/usr --enable-xslt --with-xslt-sablot=shared,/usr --with-sybase-ct=shared,/usr --with-ttr=shared,/usr --with-t1lib=shared,/usr --with-dba=shared --with-flatfile --with-inifile --with-mime-magic --enable-mime-magic --with-xmlrpc --enable-mbstring=all --enable-mbstr-enc-trans --enable-dio --enable-gd-native-ttf --enable-dio --enable-bcmath --with-snmp=shared,/usr --with-aspell=shared,/usr --with-mssql=shared,/usr --with-ming=shared,/usr --enable-pcntl --with-readline=shared,/usr --enable-tokenizer --with-yaz=/usr/bin --disable-cgi (Okay, it's excessive... most import is --disable-cgi) Configure says it's using the cli SAPI... make compiles everything okay. But at the end make install fails with this: /bin/sh /usr/src/php-4.3.3RC1/libtool --silent --preserve-dup-deps --mode=link gcc -export-dynamic -g -O2 ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bcmath/bcmath.lo ext/bcmath/number.lo ext/bcmath/libbcmath/src/add.lo ext/bcmath/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src/neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/libbcmath/src/raisemod.lo ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/src/sub.lo ext/bcmath/libbcmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src/int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcmath/libbcmath/src/output.lo ext/bcmath/libbcmath/src/recmul.lo ext/bcmath/libbcmath/src/sqrt.lo ext/bcmath/libbcmath/src/zero.lo ext/bcmath/libbcmath/src/debug.lo ext/bcmath/libbcmath/src/doaddsub.lo ext/bcmath/libbcmath/src/nearzero.lo ext/bcmath/libbcmath/src/num2str.lo ext/bcmath/libbcmath/src/raise.lo ext/bcmath/libbcmath/src/rmzero.lo ext/bcmath/libbcmath/src/str2num.lo ext/bz2/bz2.lo ext/calendar/calendar.lo ext/calendar/dow.lo ext/calendar/french.lo ext/calendar/gregor.lo ext/calendar/jewish.lo ext/calendar/julian.lo ext/calendar/easter.lo ext/calendar/cal_unix.lo ext/ctype/ctype.lo ext/dba/dba.lo ext/dba/dba_cdb.lo ext/dba/dba_db2.lo ext/dba/dba_dbm.lo ext/dba/dba_gdbm.lo ext/dba/dba_ndbm.lo ext/dba/dba_db3.lo ext/dba/dba_db4.lo ext/dba/dba_flatfile.lo ext/dba/dba_inifile.lo ext/dba/libflatfile/flatfile.lo ext/dba/libinifile/inifile.lo ext/dio/dio.lo ext/exif/exif.lo ext/filepro/filepro.lo ext/ftp/php_ftp.lo ext/ftp/ftp.lo ext/gettext/gettext.lo ext/iconv/iconv.lo ext/mbstring/mbfilter_ja.lo ext/mbstring/mbfilter_cn.lo ext/mbstring/mbfilter_tw.lo ext/mbstring/mbfilter_kr.lo ext/mbstring/mbfilter_ru.lo ext/mbstring/mbfilter.lo ext/mbstring/mbstring.lo ext/mbstring/mbregex.lo ext/mbstring/php_mbregex.lo ext/mbstring/html_entities.lo ext/mbstring/php_unicode.lo ext/mime_magic/mime_magic.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo
#24534 [Fbk-NoF]: instability : iis is reseted automatically frequently
ID: 24534 Updated by: [EMAIL PROTECTED] Reported By: mstaiger at informatik dot uni-siegen dot de -Status: Feedback +Status: No Feedback Bug Type: IIS related Operating System: Win2k PHP Version: 4.3.2 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. Previous Comments: [2003-07-22 07:07:12] [EMAIL PROTECTED] If the problem is due to a memory shortfall try the following test. Make a simple php test script and then using ApacheBench or httpref try sending a large number of requests to it. Meanwhile monitor the memory usage to see if it continues to increase until eventually there is no memory avaliable. [2003-07-17 03:55:26] info at xboot dot de One of my customers has the same problem since upgrade from Php 4.1 to 4.32. The error occures 3 - 10 times a day. I've tried a lot: Installing Php on three different machines with a clean OS (and different Php versions 4.2), playing arround with IIS-settings, enable and disable Zend-Optimizer. But problem is still there. Now I use Windows 2003 Webserver Edition. IIS doesn't restart abnormal (because he now uses a seperate worker process), but in the Event-Viewer I found this (once again 3 - 10 times a day): A process serving application pool 'DefaultAppPool' terminated unexpectly. The process id was '...'. The process exit code was '0xc005'. When this error occures the following message is displayed on browser: Php has encountered an access violation at... When I reload the site everything works fine. [2003-07-17 02:31:27] mstaiger at informatik dot uni-siegen dot de So far the snapshot didn't help. IIS keeps resetting (1-2 times a day). BUT : I found out, that before it happens, the available System Memory goes rapidly down. Does this information help in any way? [2003-07-13 10:56:21] [EMAIL PROTECTED] And make sure you remove ALL existing PHP related dlls/binaries from your system before installing the new version. [2003-07-13 10:55:52] [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 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/24534 -- Edit this bug report at http://bugs.php.net/?id=24534edit=1
#24724 [NoF-Csd]: Link failure with --disable-cgi --enable-cli
ID: 24724 User updated by: kyle at putnamcabinets dot com Reported By: kyle at putnamcabinets dot com -Status: No Feedback +Status: Closed Bug Type: Compile Failure Operating System: Debian GNU/Linux (Sid) PHP Version: 4.3.3RC1 New Comment: CVS worked. Previous Comments: [2003-07-27 14:33:17] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2003-07-20 05:38:33] [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-07-20 03:16:04] kyle at putnamcabinets dot com Description: Configured PHP with: ./configure --prefix=/usr --with-cli --with-regex=php --with-config-file-path=/etc/php/apache --disable-rpath --disable-debug --enable-memory-limit --with-layout=GNU --enable-calendar --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-trans-sid --enable-bcmath --with-bz2 --enable-ctype --with-iconv --enable-exif --enable-filepro --enable-ftp --with-gettext --enable-mbstring --with-pcre-regex=/usr --enable-shmop --enable-sockets --enable-wddx --disable-xml --with-expat-dir=/usr --enable-yp --with-zlib --with-pgsql=shared,/usr --with-kerberos=/usr --with-openssl=/usr --with-exec-dir=/usr/lib/php4/libexec --disable-static --with-curl=shared,/usr --with-dom=shared,/usr --with-dom-xslt=shared,/usr --with-dom-exslt=shared,/usr --with-zlib-dir=/usr --with-gd=shared --with-jpeg-dir=shared,/usr --with-xpm-dir=shared,/usr/X11R6 --with-png-dir=shared,/usr --with-freetype-dir=shared,/usr --with-imap=shared,/usr --with-imap-ssl --with-mcal=shared,/usr --with-mhash=shared,/usr --with-mcrypt=shared,/usr --with-mysql --with-unixODBC=shared,/usr --enable-xslt --with-xslt-sablot=shared,/usr --with-sybase-ct=shared,/usr --with-ttr=shared,/usr --with-t1lib=shared,/usr --with-dba=shared --with-flatfile --with-inifile --with-mime-magic --enable-mime-magic --with-xmlrpc --enable-mbstring=all --enable-mbstr-enc-trans --enable-dio --enable-gd-native-ttf --enable-dio --enable-bcmath --with-snmp=shared,/usr --with-aspell=shared,/usr --with-mssql=shared,/usr --with-ming=shared,/usr --enable-pcntl --with-readline=shared,/usr --enable-tokenizer --with-yaz=/usr/bin --disable-cgi (Okay, it's excessive... most import is --disable-cgi) Configure says it's using the cli SAPI... make compiles everything okay. But at the end make install fails with this: /bin/sh /usr/src/php-4.3.3RC1/libtool --silent --preserve-dup-deps --mode=link gcc -export-dynamic -g -O2 ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bcmath/bcmath.lo ext/bcmath/number.lo ext/bcmath/libbcmath/src/add.lo ext/bcmath/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src/neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/libbcmath/src/raisemod.lo ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/src/sub.lo ext/bcmath/libbcmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src/int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcmath/libbcmath/src/output.lo ext/bcmath/libbcmath/src/recmul.lo ext/bcmath/libbcmath/src/sqrt.lo ext/bcmath/libbcmath/src/zero.lo ext/bcmath/libbcmath/src/debug.lo ext/bcmath/libbcmath/src/doaddsub.lo ext/bcmath/libbcmath/src/nearzero.lo ext/bcmath/libbcmath/src/num2str.lo ext/bcmath/libbcmath/src/raise.lo ext/bcmath/libbcmath/src/rmzero.lo ext/bcmath/libbcmath/src/str2num.lo ext/bz2/bz2.lo ext/calendar/calendar.lo ext/calendar/dow.lo ext/calendar/french.lo ext/calendar/gregor.lo ext/calendar/jewish.lo ext/calendar/julian.lo ext/calendar/easter.lo ext/calendar/cal_unix.lo ext/ctype/ctype.lo ext/dba/dba.lo ext/dba/dba_cdb.lo ext/dba/dba_db2.lo ext/dba/dba_dbm.lo ext/dba/dba_gdbm.lo ext/dba/dba_ndbm.lo ext/dba/dba_db3.lo ext/dba/dba_db4.lo ext/dba/dba_flatfile.lo ext/dba/dba_inifile.lo ext/dba/libflatfile/flatfile.lo ext/dba/libinifile/inifile.lo ext/dio/dio.lo ext/exif/exif.lo ext/filepro/filepro.lo ext/ftp/php_ftp.lo ext/ftp/ftp.lo ext/gettext/gettext.lo ext/iconv/iconv.lo ext/mbstring/mbfilter_ja.lo ext/mbstring/mbfilter_cn.lo ext/mbstring/mbfilter_tw.lo ext/mbstring/mbfilter_kr.lo ext/mbstring/mbfilter_ru.lo ext/mbstring/mbfilter.lo ext/mbstring/mbstring.lo ext/mbstring/mbregex.lo ext/mbstring/php_mbregex.lo ext/mbstring/html_entities.lo ext/mbstring/php_unicode.lo ext/mime_magic/mime_magic.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo
#24831 [NEW]: Memory Leak
From: cunha17 at uol dot com dot br
Operating system: Linux 2.4.20 (Redhat 9)
PHP version: 5.0.0b1 (beta1)
PHP Bug Type: Zend Engine 2 problem
Bug description: Memory Leak
Description:
This small OO script gives some memory leaks.
Reproduce code:
---
class ReleaseInfo
{
const NAME_LONG = PHPORB;
const NAME_SHORT= orb;
const VERSION_MAJOR = 0;
const VERSION_MINOR = 1;
const VERSION_MINOR_CHANGE = 0;
const VERSION = . VERSION_MAJOR . . .
VERSION_MINOR . . . VERSION_MINOR_CHANGE;
const SPEC_VERSION_MAJOR= 2;
const SPEC_VERSION_MINOR= 4;
const SPEC_VERSION_MINOR_CHANGE = 2;
const SPEC_VERSION = . SPEC_VERSION_MAJOR . . .
SPEC_VERSION_MINOR . . . SPEC_VERSION_MINOR_CHANGE;
const RELEASE = NAME_LONG . Version . VERSION;
const RELEASE_TAG = NAME_LONG . _ . VERSION_MAJOR .
_ . VERSION_MINOR . _ . VERSION_MINOR_CHANGE;
public static function main($args)
{
echo NAME_LONG . :;
echo \t . NAME_LONG . . VERSION;
echo \t . RELEASE_TAG;
echo \tCORBA/IIOP . SPEC_VERSION .
(http://www.omg.org/cgi-bin/doc?formal/01-02-01);
}
}
Expected result:
Nothing to the standard output and no memory leaks.
Actual result:
--
/usr/src/zend2/php5-200307262130/Zend/zend_operators.c(1087) : Freeing
0x4070AE7C (12 bytes), script=org/openorb/ReleaseInfo.php
Last leak repeated 13 times
Zend/zend_language_scanner.c(4497) : Freeing 0x4070AE40 (2 bytes),
script=org/openorb/ReleaseInfo.php
Last leak repeated 9 times
Zend/zend_language_scanner.c(4350) : Freeing 0x4070ADB8 (14 bytes),
script=org/openorb/ReleaseInfo.php
Last leak repeated 11 times
/usr/src/zend2/php5-200307262130/Zend/zend_compile.c(2524) : Freeing
0x4070AA80 (6 bytes), script=org/openorb/ReleaseInfo.php
/usr/src/zend2/php5-200307262130/Zend/zend_variables.c(111) : Actual
location (location was relayed)
Last leak repeated 2 times
--
Edit bug report at http://bugs.php.net/?id=24831edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24831r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24831r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=24831r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24831r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24831r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24831r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24831r=support
Expected behavior: http://bugs.php.net/fix.php?id=24831r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24831r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24831r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24831r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24831r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24831r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24831r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24831r=gnused
#24809 [Com]: Packaging PHP Applications for Easy Distribution
ID: 24809 Comment by: cunha17 at uol dot com dot br Reported By: lee at semel dot net Status: Wont fix Bug Type:Feature/Change Request PHP Version: Irrelevant New Comment: I don't think PEAR Install do what was proposed by Lee, IMHO. I think that the package won't have to be decompressed to be used and the PHP engine will use the files inside the package as they were decompressed on the filesystem. Correct me if I misunderstood something... Cristiano Duarte Previous Comments: [2003-07-27 14:19:03] [EMAIL PROTECTED] We already have PEAR for this. (pear install) [2003-07-25 16:28:46] lee at semel dot net Description: Since PHP is often used for distributing entire applications at once, it would be great to have a mechanism (similar to Java's WAR files) to make it easy to package, distribute, install, and configure them. I propose implementing a system for easily packaging PHP applications. A .PAR file (PHP ARchive) file is a zipfile containing the following: * All the images, includes, and php files that make up the PHP application. * a PHP.INI file configured specific to the application. PHP would ignore values from the master PHP.INI file and use the settings from the PHP.INI file inside the archive. * a WEB.XML (or WEB.INI) file defining default configuration parameters speicifc to the application. Configuration parameters should be able to be overridden by an external file, making them very easy to edit, and to provide an easy way to set up server-specific configurations when installing an application in multiple places. The application would be accessed through the browser at http://servername:port/nameofarchive/, or at another location specified by the administrator. Wioth this system, each application could have its own configuration, include path, and libraries, and installing an application becomes a matter of dropping the file into your document root. If your ISP doesn't let you change PHP.ini, simply installing the PAR file will set everything perfectly for you. No more having to worry if magic_quotes_gpc or register_globals is set correctly. No more having to worry if PEAR is installed. For more info on how Java does it: http://access1.sun.com/techarticles/simple.WAR.html -- Edit this bug report at http://bugs.php.net/?id=24809edit=1
#24801 [Opn-Csd]: xml_call_handler() causes segmentation fault
ID: 24801
Updated by: [EMAIL PROTECTED]
Reported By: fujimura at wakhok dot ac dot jp
-Status: Open
+Status: Closed
Bug Type: XML related
Operating System: Linux kernel-2.4.21
PHP Version: 5CVS-2003-07-25 (dev)
New Comment:
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.
Previous Comments:
[2003-07-25 03:51:18] fujimura at wakhok dot ac dot jp
Description:
ext/xml/xml.c:xml_call_handler() causes segmentation fault.
Reproduce code:
---
?php
function startElement() { }
$parser = xml_parser_create();
xml_set_element_handler($parser, startElement, endElement);
xml_parse($parser, ?xml version=\1.0\?root /, true) OR
die(xml_error_string(xml_get_error_code($parser)));
xml_parser_free($parser);
?
Actual result:
--
[EMAIL PROTECTED] public_html]$ gdb php
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-slackware-linux...
(gdb) run xml_parse.php
Starting program: /usr/local/bin/php xml_parse.php
Program received signal SIGSEGV, Segmentation fault.
0x081e7e4c in _zval_ptr_dtor (zval_ptr=0xbfffc97c,
__zend_filename=0x825e220 /home/fujimura/php-src/ext/xml/xml.c,
__zend_lineno=423)
at /home/fujimura/php-src/Zend/zend_execute_API.c:342
342 (*zval_ptr)-refcount--;
(gdb) bt
#0 0x081e7e4c in _zval_ptr_dtor (zval_ptr=0xbfffc97c,
__zend_filename=0x825e220 /home/fujimura/php-src/ext/xml/xml.c,
__zend_lineno=423)
at /home/fujimura/php-src/Zend/zend_execute_API.c:342
#1 0x081ab079 in xml_call_handler (parser=0x40436988,
handler=0x40436b7c, function_ptr=0x0, argc=2, argv=0xbfffc9b8)
at /home/fujimura/php-src/ext/xml/xml.c:423
#2 0x081abc7e in _xml_endElementHandler (userData=0x40436988,
name=0x830f550 root) at /home/fujimura/php-src/ext/xml/xml.c:753
#3 0x081ae851 in _end_element_handler (user=0x4042a0cc, name=0x830f410
root) at /home/fujimura/php-src/ext/xml/compat.c:128
#4 0x402443be in xmlParseExtParsedEnt () from /usr/lib/libxml2.so.2
#5 0x40244db1 in xmlParseChunk () from /usr/lib/libxml2.so.2
#6 0x081aedc0 in php_XML_Parse (parser=0x4042a0cc, data=0x40437200
?xml version=\1.0\?root /, data_len=29, is_final=1)
at /home/fujimura/php-src/ext/xml/compat.c:400
#7 0x081ad357 in zif_xml_parse (ht=3, return_value=0x40436c8c,
this_ptr=0x0, return_value_used=1) at
/home/fujimura/php-src/ext/xml/xml.c:1321
#8 0x08211156 in execute_internal (execute_data_ptr=0xbfffcdb0,
return_value_used=1) at
/home/fujimura/php-src/Zend/zend_execute.c:1143
#9 0x4074b276 in xdebug_execute_internal
(current_execute_data=0xbfffcdb0, return_value_used=1) at
/home/fujimura/xdebug-1.2.0/xdebug.c:782
#10 0x08215917 in zend_do_fcall_common_helper (execute_data=0xbfffcdb0,
op_array=0x40435714) at
/home/fujimura/php-src/Zend/zend_execute.c:2513
#11 0x08215feb in zend_do_fcall_handler (execute_data=0xbfffcdb0,
op_array=0x40435714) at
/home/fujimura/php-src/Zend/zend_execute.c:2642
#12 0x082112a8 in execute (op_array=0x40435714) at
/home/fujimura/php-src/Zend/zend_execute.c:1192
#13 0x4074afcc in xdebug_execute (op_array=0x40435714) at
/home/fujimura/xdebug-1.2.0/xdebug.c:750
#14 0x081f37d0 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/fujimura/php-src/Zend/zend.c:1017
#15 0x081b4af8 in php_execute_script (primary_file=0xb5f0) at
/home/fujimura/php-src/main/main.c:1568
#16 0x0821dec8 in main (argc=2, argv=0xb694) at
/home/fujimura/php-src/sapi/cli/php_cli.c:910
#17 0x4030bbb4 in __libc_start_main () from /lib/libc.so.6
--
Edit this bug report at http://bugs.php.net/?id=24801edit=1
#17414 [Com]: Segfaults on restart [apache2filter]
ID: 17414 Comment by: rich at rd dot gen dot nz Reported By: thom at planetarytramp dot net Status: No Feedback Bug Type: Apache2 related Operating System: Linux PHP Version: 4.3.0 New Comment: Applying the patch seems to fix the problem for me. I'm using Apache 2.0.47 (prefork), PHP 4.3.2 (compiled with imap, gettext), glibc 2.2.5 on Debian 3.0. Thanks! Previous Comments: [2003-07-22 09:02:27] timo dot teras at iki dot fi Seems to be actually a bug in glibc. I've made a patch that should workaround this problem. See: http://marc.theaimsgroup.com/?l=php-devm=105878953712765w=2 Maybe someone could verify that this works. [2003-07-15 08:17:21] timo dot teras at iki dot fi This bug is still present... Program received signal SIGSEGV, Segmentation fault. 0x405e8dc9 in sapi_initialize_empty_request (tsrm_ls=0x20) at /usr/src/php4-STABLE-200307151130/main/SAPI.c:424 424 SG(server_context) = NULL; (gdb) where #0 0x405e8dc9 in sapi_initialize_empty_request (tsrm_ls=0x20) at /usr/src/php4-STABLE-200307151130/main/SAPI.c:424 #1 0x405e3009 in php_module_startup (sf=0x40689b00, additional_modules=0x40689de0, num_additional_modules=1) at /usr/src/php4-STABLE-200307151130/main/main.c:1093 #2 0x406281b7 in php_apache2_startup (sapi_module=0x40689b00) at /usr/src/php4-STABLE-200307151130/sapi/apache2handler/sapi_apache2.c:297 #3 0x406282e3 in php_apache_server_startup (pconf=0x80aa9d0, plog=0x80e2ab0, ptemp=0x80e6ac0, s=0x40689b00) at /usr/src/php4-STABLE-200307151130/sapi/apache2handler/sapi_apache2.c:396 #4 0x08073618 in ap_run_post_config () #5 0x08077afa in main () #6 0x4035ea51 in __libc_start_main () from /lib/libc.so.6 #7 0x080603ad in _start () [2003-07-04 02:05:31] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2003-06-29 10:47:26] [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-05-19 10:03:59] thom at planetarytramp dot net Only difference in the backtrace when trying with apache2handler is the different SAPI directory: #0 0x403a6941 in sapi_initialize_empty_request (tsrm_ls=0x80f98f0) at /home/thom/php4-STABLE-200305190930/main/SAPI.c:434 434 SG(server_context) = NULL; (gdb) bt #0 0x403a6941 in sapi_initialize_empty_request (tsrm_ls=0x80f98f0) at /home/thom/php4-STABLE-200305190930/main/SAPI.c:434 #1 0x403a11b4 in php_module_startup (sf=0x4041cba0, additional_modules=0x4041ce80, num_additional_modules=1) at /home/thom/php4-STABLE-200305190930/main/main.c:1094 #2 0x403df187 in php_apache2_startup (sapi_module=0x4041cba0) at /home/thom/php4-STABLE-200305190930/sapi/apache2handler/sapi_apache2.c:290 #3 0x403df2b3 in php_apache_server_startup (pconf=0x80b90c8, plog=0x80f11a8, ptemp=0x80bb0d0, s=0x4041cba0) at /home/thom/php4-STABLE-200305190930/sapi/apache2handler/sapi_apache2.c:389 #4 0x0807e651 in ap_run_post_config (pconf=0x80b90c8, plog=0x80f11a8, ptemp=0x80bb0d0, s=0x80f5af0) at config.c:130 #5 0x08082e9c in main (argc=3, argv=0xb874) at main.c:640 (gdb) 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/17414 -- Edit this bug report at http://bugs.php.net/?id=17414edit=1
#24416 [Com]: Apache2 won't start with PHP5 beta
ID: 24416 Comment by: levi at levifig dot net Reported By: ldf13 at hotmail dot com Status: Bogus Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5CVS-2003-06-30 (dev) New Comment: I'm using Windows XP, Apache 2.0.47 and PHP 5.0.0b1 and i'm running everything without a problem! I changed the line to php5_module and i have all my 3 files (php4ts.dll, php4apache2.dll and php.ini) in my Apache's /bin directory. I load the module with a php5_module bin/php4apache2.dll. My Apache installation is under C:\Program Files\Apache Group\Apache2 and my PHP install is at (it doesn't matter as the needed files are under the Apache's installation directory) c:\php As a note, i do have all my dlls from php\dlls copied to c:\windows\system32... i don't believe it makes any difference to this subject, but i say it just in case! ;) Good Luck to y'all! : And gr33ts from Portugal! :X Previous Comments: [2003-07-13 01:44:54] es_anubis at cogeco dot ca Thanks. I was having the exact same problem. This is not our fault though, I think it was just a little thing which the PHP dev team did not notice. Do what the guy before my post said(aaron at gwmicro dot com), it works. [2003-07-03 14:36:13] aaron at gwmicro dot com nuno, Thanks for the info. What you noted still didn't work for me, but it did prompt me to keep trying. Finally, I had success. Here's what I had to do: copy x:/php/php4ts.dll to x:/php/sapi copy x:/php/dlls/iconv.dll to x:/php Plus the obligatory: LoadModule php5_module c:/php/sapi/php4apache2.dll AddType application/x-httpd-php .php A little frustrating that there appear so many different solutions in terms of where to copy what (unless we -- you, me, and a host of Google groupers -- keep mistyping things). But at least it works for now. Thanks for your help, Aaron [2003-07-02 12:54:49] nuno at dbforums dot com Sure Aaron, copy the files: php4ts.dll iconv.dll to c:/php/sapi/ Then simply add this to your httpd.conf file: LoadModule php5_module c:/php/sapi/php4apache2.dll AddType application/x-httpd-php .php Once that's all done, restart Apache. :) NET STOP APACHE2 NET START APACHE2 [2003-07-02 09:59:31] aaron at gwmicro dot com nuno, Would you care to enlighten the rest of us (me)? Aaron [2003-07-01 22:06:05] nuno at dbforums dot com Thankfully to strace (an amazing little tool BTW) and install.txt (duh), I finally managed to install PHP5 with Apache2.0.46. Therefore, I need to eat my words and I would like to take this opportunity to present my sincere apologies to the PHP Team. To sniper, a special thank you for his support. Best wishes, nuno :) 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/24416 -- Edit this bug report at http://bugs.php.net/?id=24416edit=1
#24809 [WFx]: Packaging PHP Applications for Easy Distribution Configuration
ID: 24809 User updated by: lee at semel dot net -Summary: Packaging PHP Applications for Easy Distribution Reported By: lee at semel dot net Status: Wont fix Bug Type:Feature/Change Request PHP Version: Irrelevant New Comment: Pear install isn't quite the same idea: 1) My suggestion is intended to overcome the problems of having a common PHP.INI file -- you can't configure one application separately from another 2) My suggestions is intended to be used for entire PHP applications themselves, not modules, libraries or groups of classes. 3) My suggestion is intended to separate the configuration of the application from the code of the application itself, and set up a standard way of doing this. On most applications today, configuration is nonstandard, usually involving manual edits to an include file, searches and replaces, manually creating, editing or moving files. Configuration is often mixed up with the code, so if you want to deploy your PHP app to both a development, test, and production environment, you have the potential for trouble. If this idea were implemented, installing or deploying a PHP application becomes very easy. Let's say you want to install myphpapp on your account. 1) Download the application (say myphpapp.par), stick it in your document root, and view http://mydomain/myphpapp/. It works, just as if the files were decompressed there. 2) To customize your configuration, edit a file myphpapp.ini or myphpapp.xml and put it in the same directory as the par file. PHP will know where to look for it. Here you can keep settings speciifc to this particular install: the database password, the color schemes, etc. 3) If you want to maintain a development and production version of the app, going live with a new version becomes as easy as copying one file from your development server to your live server. You can leave the configuration file there so each server can maintain a separate configuration, with its own database or debugging settings. 4) It would be possible to develop a web based tool to help you can download, configure and install your app through your browser! Some Java application servers (such as BEA Weblogic) do just that: You can upload a file containing a Java web application, configure it via your browser, and get it set up in about 2 minutes, with no manual editing of files. Unfortunately, Java has many other problems, which is why I prefer PHP. 5) If myphpapp.par wants register_globals, magic_quotes_gpc, and asp_tags, but someotherphpapp.par doesn't work with these settings, they can both live side by side, because each one's got a private PHP.INI file zipped up inside of it. 6) Making a PHP Archive file is easy - just use any standard zip program. All in all, I think this functionality would help make PHP applications easier to install, configure and manage. A standardized, easy way to do this may even hasten PHP's adoption within corporations, which are used to managing their Java web applications this way. Previous Comments: [2003-07-27 15:07:35] cunha17 at uol dot com dot br I don't think PEAR Install do what was proposed by Lee, IMHO. I think that the package won't have to be decompressed to be used and the PHP engine will use the files inside the package as they were decompressed on the filesystem. Correct me if I misunderstood something... Cristiano Duarte [2003-07-27 14:19:03] [EMAIL PROTECTED] We already have PEAR for this. (pear install) [2003-07-25 16:28:46] lee at semel dot net Description: Since PHP is often used for distributing entire applications at once, it would be great to have a mechanism (similar to Java's WAR files) to make it easy to package, distribute, install, and configure them. I propose implementing a system for easily packaging PHP applications. A .PAR file (PHP ARchive) file is a zipfile containing the following: * All the images, includes, and php files that make up the PHP application. * a PHP.INI file configured specific to the application. PHP would ignore values from the master PHP.INI file and use the settings from the PHP.INI file inside the archive. * a WEB.XML (or WEB.INI) file defining default configuration parameters speicifc to the application. Configuration parameters should be able to be overridden by an external file, making them very easy to edit, and to provide an easy way to set up server-specific configurations when installing an application in multiple places. The application would be accessed through the browser at http://servername:port/nameofarchive/, or at another location specified by the administrator. Wioth this system, each application could have its own configuration, include path, and
#24831 [Opn-Csd]: Memory Leak
ID: 24831
Updated by: [EMAIL PROTECTED]
Reported By: cunha17 at uol dot com dot br
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Linux 2.4.20 (Redhat 9)
PHP Version: 5.0.0b1 (beta1)
New Comment:
Latest CVS does not have those leaks.
Previous Comments:
[2003-07-27 14:57:31] cunha17 at uol dot com dot br
Description:
This small OO script gives some memory leaks.
Reproduce code:
---
class ReleaseInfo
{
const NAME_LONG = PHPORB;
const NAME_SHORT= orb;
const VERSION_MAJOR = 0;
const VERSION_MINOR = 1;
const VERSION_MINOR_CHANGE = 0;
const VERSION = . VERSION_MAJOR . . .
VERSION_MINOR . . . VERSION_MINOR_CHANGE;
const SPEC_VERSION_MAJOR= 2;
const SPEC_VERSION_MINOR= 4;
const SPEC_VERSION_MINOR_CHANGE = 2;
const SPEC_VERSION = . SPEC_VERSION_MAJOR . . .
SPEC_VERSION_MINOR . . . SPEC_VERSION_MINOR_CHANGE;
const RELEASE = NAME_LONG . Version .
VERSION;
const RELEASE_TAG = NAME_LONG . _ . VERSION_MAJOR .
_ . VERSION_MINOR . _ . VERSION_MINOR_CHANGE;
public static function main($args)
{
echo NAME_LONG . :;
echo \t . NAME_LONG . . VERSION;
echo \t . RELEASE_TAG;
echo \tCORBA/IIOP . SPEC_VERSION .
(http://www.omg.org/cgi-bin/doc?formal/01-02-01);
}
}
Expected result:
Nothing to the standard output and no memory leaks.
Actual result:
--
/usr/src/zend2/php5-200307262130/Zend/zend_operators.c(1087) : Freeing
0x4070AE7C (12 bytes), script=org/openorb/ReleaseInfo.php
Last leak repeated 13 times
Zend/zend_language_scanner.c(4497) : Freeing 0x4070AE40 (2 bytes),
script=org/openorb/ReleaseInfo.php
Last leak repeated 9 times
Zend/zend_language_scanner.c(4350) : Freeing 0x4070ADB8 (14 bytes),
script=org/openorb/ReleaseInfo.php
Last leak repeated 11 times
/usr/src/zend2/php5-200307262130/Zend/zend_compile.c(2524) : Freeing
0x4070AA80 (6 bytes), script=org/openorb/ReleaseInfo.php
/usr/src/zend2/php5-200307262130/Zend/zend_variables.c(111) : Actual
location (location was relayed)
Last leak repeated 2 times
--
Edit this bug report at http://bugs.php.net/?id=24831edit=1
#24817 [WFx]: Suggestion on Function Handling functions
ID: 24817 User updated by: jimsonchang at yahoo dot com Reported By: jimsonchang at yahoo dot com Status: Wont fix Bug Type: Feature/Change Request Operating System: XPbox PHP Version: 4.3.2 New Comment: ok, i mean maybe can implement double solutions(function's name) in php 4.3.3 and mention to users in changes list, while in the future version of php maybe 4.3.4, then only retrench the old functions name. first, we wish to make PHP a better programming language second, a change is a must. third, unless you tell me, u don't really care. fourth, if really like that, what da hell u are in php.net? u work for $M? there are 2 meanings inside your [quote] And lose backwards compatibility? Yeah, right. [/quote] i don't want to extend the meaning, but i think i got them. Previous Comments: [2003-07-27 13:44:26] [EMAIL PROTECTED] And lose backwards compatibility? Yeah, right. [2003-07-26 07:38:22] jimsonchang at yahoo dot com Description: i got a suggestion on Function Handling functions for better standardization and better php eg. call_user_func_array() can be changed to func_call_array() // since user might call internal function, not necessary user functions call_user_func() can be changed to func_call() // since user might call internal function also create_function() can be changed to func_create() func_get_arg() can be changed to func_arg() // no need the get word because we can't post or give func_get_args() can be changed to func_args() // like the above reason, because we can't post or give // and we already post/give in call_user_func() func_num_args() can be changed to func_args_num() // follow the above standard function_exists() can be changed to func_exists() get_defined_functions() can be changed to func_int_list() and func_usr_list() // since user no need to copy an array or unset to get the user or internal functions list register_shutdown_function() can be changed to func_reg_shutdown() register_tick_function() can be changed to func_tick_reg() unregister_tick_function() can be changed to func_tick_unreg() -- Edit this bug report at http://bugs.php.net/?id=24817edit=1
#24805 [Fbk-Opn]: skip_long_header_sep routine break email
ID: 24805 User updated by: bobe at phpcodeur dot net Reported By: bobe at phpcodeur dot net -Status: Feedback +Status: Open Bug Type: Mail related Operating System: Linux PHP Version: 4.3.2 New Comment: The problem does not appear under Windows, and I can't update php on the server where I test :/. But probably, the sequence \r\n provokes a problem with sendmail and/or qmail. It should be \n, not ? ( Skip_long_header_sep was not modifyed between php 4.3.2 and 4.3.3dev, and I see anybody that sequences \r\n are transformed \n before the sending in sendmail/qmail) Previous Comments: [2003-07-27 12:30:01] [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 It works perfectly on 4.3.3dev for me. [2003-07-27 10:37:07] bobe at phpcodeur dot net The separator for long headers should be \r\n followed by either a space or a \t It is exactely what i do.. The bug tracker put the long subject of my previous example on 2 lines but it is a sequence \r\nSP This code also reproduces the bug : mail( '[EMAIL PROTECTED]', this is a long subject \r\n to test the mail function, 'This is the message', From: [EMAIL PROTECTED]: 1.0 ); [2003-07-26 20:17:52] [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 The separator for long headers should be \r\n followed by either a space or a \t no other character such as \n or \r will be accepted. If you don't use tab or a space entire sequence will be converted to spaces. [2003-07-26 05:31:55] bobe at phpcodeur dot net The bug occurs for example with this code : mail( '[EMAIL PROTECTED]', =?iso-8859-1?Q?ceci_est_un_petit_test_pour_d=E9terminer_les_bugs_?=\r\n =?iso-8859-1?Q?existants_avec_la_classe_mail?=, 'This is the message', From: [EMAIL PROTECTED]: 1.0 ); result is : =?iso-8859-1?Q?existants_avec_la_classe_mail?= From: [EMAIL PROTECTED] MIME-Version: 1.0 This is the message. Maybe that the problem occurs with qmail because there are sequences \r\n instead of \n in long subject ? [2003-07-25 17:46:55] [EMAIL PROTECTED] Where is the bug occuring imap, or something else? Who does the message parsing? 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/24805 -- Edit this bug report at http://bugs.php.net/?id=24805edit=1
#19022 [Com]: PHP Warning: Failed to write session data (files)
ID: 19022 Comment by: alexbodn at 012 dot net dot il Reported By: phpbugs at mx4k dot com Status: No Feedback Bug Type: Session related Operating System: linux (rh7.3), apache 1.3.26 PHP Version: 4.2.2 New Comment: hello palls, i hope my workaround might help. i have experienced the same failure on a debian woody dev server with no load running a pentium 100 mhz with php 4.1.2. i had the problem on a page which was calling session_id() with no parameters. after reading this list, i have changed the first call to session_id() to: session_id(session_id(a)) and the problem dissapeared. i must mention that after the first time i found the problem, it didn't stop until this workaround. although i didn't examine php source, it might be that the solution for this case would be checking the number of parameters to session_id(). thank you very much for your work and contributions. alex Previous Comments: [2003-07-08 02:31:23] wieri420 at planet dot nl For the people not experiencing the failed to write session data error but those of you that do experience the 'random lose of session data' here a possible solution: Check if your script uses cookies AND sessions in one script. Comment all the 'setcookie' lines and all other cookie functions in your script and check if your problem still exists... It solved the problem (dissapearing sessions causing users to log out) for me. [2003-05-05 03:09:15] e dot aderhold at pro-seco dot de (/tmp/sess_7538b7739bdd44e2fb0e747f65af858d, O_RDWR) is this a problem ??? NO create a tmp folder in your SERVER ROOT like /var/www/tmp and it will work fine php.ini means not the / php means the WebServer Root [2003-04-22 09:02:12] php at rjs3 dot com Scratch my last post. The problem is back again. I'm having this issue with PHP 4.2.3 and apache 1.3.27 with SSL. I do have luck when restarting apache sometimes. I'm not 100% positive, but it often fixes itself after I restart my normal apache NOT my apache-ssl which is running my webmail site (horde) that breaks due to this bug. For the record, I also have 2 CPUs since that seems to be a common trend. The load is very low. [2003-04-21 19:25:04] skye at f4 dot ca I am also having this problem, FreeBSD 4.6.2 with Apache/1.3.27 (Unix) mod_throttle/3.1.2 mod_gzip/1.3.19.1a PHP/4.2.3 Using SquirrelMail 1.4.0 I get the usual: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0 My box has multiple CPUs. [2003-04-18 09:01:34] php at rjs3 dot com I have had this problem for a long time. Thanks to the individual that mentioned the /var/www/tmp directory. I did not change the permissions of the directory, I simply got rid of it and the problem went away. I used to have a /var/www/tmp from testing in the past. So I just deleted it and the problem is solved. PHP developers: Any reason why this would mess up PHP sessions? 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/19022 -- Edit this bug report at http://bugs.php.net/?id=19022edit=1
#19022 [Com]: PHP Warning: Failed to write session data (files)
ID: 19022 Comment by: alexbodn at 012 dot net dot il Reported By: phpbugs at mx4k dot com Status: No Feedback Bug Type: Session related Operating System: linux (rh7.3), apache 1.3.26 PHP Version: 4.2.2 New Comment: it's me again. i must mention that the problem occured to me on the index.php page, where i was calling session_id() after session_start(). (here is the place the id should be created for the first time). it didn't appear on pages that call session_id($_GET[$_SESSION[session_name()]]) before session_start(). thanks again, alex Previous Comments: [2003-07-27 20:40:41] alexbodn at 012 dot net dot il hello palls, i hope my workaround might help. i have experienced the same failure on a debian woody dev server with no load running a pentium 100 mhz with php 4.1.2. i had the problem on a page which was calling session_id() with no parameters. after reading this list, i have changed the first call to session_id() to: session_id(session_id(a)) and the problem dissapeared. i must mention that after the first time i found the problem, it didn't stop until this workaround. although i didn't examine php source, it might be that the solution for this case would be checking the number of parameters to session_id(). thank you very much for your work and contributions. alex [2003-07-08 02:31:23] wieri420 at planet dot nl For the people not experiencing the failed to write session data error but those of you that do experience the 'random lose of session data' here a possible solution: Check if your script uses cookies AND sessions in one script. Comment all the 'setcookie' lines and all other cookie functions in your script and check if your problem still exists... It solved the problem (dissapearing sessions causing users to log out) for me. [2003-05-05 03:09:15] e dot aderhold at pro-seco dot de (/tmp/sess_7538b7739bdd44e2fb0e747f65af858d, O_RDWR) is this a problem ??? NO create a tmp folder in your SERVER ROOT like /var/www/tmp and it will work fine php.ini means not the / php means the WebServer Root [2003-04-22 09:02:12] php at rjs3 dot com Scratch my last post. The problem is back again. I'm having this issue with PHP 4.2.3 and apache 1.3.27 with SSL. I do have luck when restarting apache sometimes. I'm not 100% positive, but it often fixes itself after I restart my normal apache NOT my apache-ssl which is running my webmail site (horde) that breaks due to this bug. For the record, I also have 2 CPUs since that seems to be a common trend. The load is very low. [2003-04-21 19:25:04] skye at f4 dot ca I am also having this problem, FreeBSD 4.6.2 with Apache/1.3.27 (Unix) mod_throttle/3.1.2 mod_gzip/1.3.19.1a PHP/4.2.3 Using SquirrelMail 1.4.0 I get the usual: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0 My box has multiple CPUs. 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/19022 -- Edit this bug report at http://bugs.php.net/?id=19022edit=1
#5094 [Com]: R_PPC_REL24 relocation out of range
ID: 5094 Comment by: clam at sluggy dot net Reported By: infos at e-blokos dot com Status: Closed Bug Type: Dynamic loading related Operating System: LinuxPPC PHP Version: 4.0.0 Release New Comment: i have this same problem under php4.3.2 and apache 2.0.47 this is occuring on a gentoo-ppc the error in my log: Syntax error on line 3 of /etc/apache2/conf/modules.d/70_mod_php.conf: Cannot load /etc/apache2/extramodules/libphp4.so into server:/etc/apache2/extramodules/libphp4.so: R_PPC_REL24 relocation at 0x0ccfafb0 for symbol `_get_element_by_id' out of range hope this helps --will Previous Comments: [2000-08-22 05:24:16] [EMAIL PROTECTED] Previous feedback: ok, thank you. i think that's the answer for my problem. I've forgotten the path ... User feedback: Really, i don't know, and i'm very too overbooked to recompile PHP and all other stuff like apache, etc... So if you want a speed answer, i suggest you try to send to [EMAIL PROTECTED] your emails, apparently recently there is a guy who 's have some prob with Php4. Hmm, this must be general concensus (to be overbooked. =) If some people have problems with php4 they should file a bug report here if they suspect it is a bug. Or ask from [EMAIL PROTECTED] I'm closing this one now. Please reopen if problem persists with newer versions and using --with-mysql=/path/to/mysql (when you have time to try it out) --Jani [2000-08-21 14:00:09] [EMAIL PROTECTED] What is your configure line used for php4? Try adding the path to the --with-mysql which points to the prefix with which mysql was installed with. --Jani [2000-08-20 03:57:44] [EMAIL PROTECTED] Does this problem still persist with more recent version of php (from CVS or http://snaps.php.net) ?? --Jani [2000-06-17 00:20:28] infos at e-blokos dot com php 4 compiles fine with apache 1.3.12 mod_ssl 2.6.4, mod_perl 1.24 in LINuXppc 2000 with apxs when i restart apache it makes thsi error R_PPC_REL24 relocation out of range any suggestions Thanks Franck Chionna -- Edit this bug report at http://bugs.php.net/?id=5094edit=1
#24805 [Opn-Bgs]: skip_long_header_sep routine break email
ID: 24805 Updated by: [EMAIL PROTECTED] Reported By: bobe at phpcodeur dot net -Status: Open +Status: Bogus Bug Type: Mail related Operating System: Linux PHP Version: 4.3.2 New Comment: 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 I am using qmail as well as sendmail and in both cases the code works fine. Previous Comments: [2003-07-27 19:30:37] bobe at phpcodeur dot net The problem does not appear under Windows, and I can't update php on the server where I test :/. But probably, the sequence \r\n provokes a problem with sendmail and/or qmail. It should be \n, not ? ( Skip_long_header_sep was not modifyed between php 4.3.2 and 4.3.3dev, and I see anybody that sequences \r\n are transformed \n before the sending in sendmail/qmail) [2003-07-27 12:30:01] [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 It works perfectly on 4.3.3dev for me. [2003-07-27 10:37:07] bobe at phpcodeur dot net The separator for long headers should be \r\n followed by either a space or a \t It is exactely what i do.. The bug tracker put the long subject of my previous example on 2 lines but it is a sequence \r\nSP This code also reproduces the bug : mail( '[EMAIL PROTECTED]', this is a long subject \r\n to test the mail function, 'This is the message', From: [EMAIL PROTECTED]: 1.0 ); [2003-07-26 20:17:52] [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 The separator for long headers should be \r\n followed by either a space or a \t no other character such as \n or \r will be accepted. If you don't use tab or a space entire sequence will be converted to spaces. [2003-07-26 05:31:55] bobe at phpcodeur dot net The bug occurs for example with this code : mail( '[EMAIL PROTECTED]', =?iso-8859-1?Q?ceci_est_un_petit_test_pour_d=E9terminer_les_bugs_?=\r\n =?iso-8859-1?Q?existants_avec_la_classe_mail?=, 'This is the message', From: [EMAIL PROTECTED]: 1.0 ); result is : =?iso-8859-1?Q?existants_avec_la_classe_mail?= From: [EMAIL PROTECTED] MIME-Version: 1.0 This is the message. Maybe that the problem occurs with qmail because there are sequences \r\n instead of \n in long subject ? 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/24805 -- Edit this bug report at http://bugs.php.net/?id=24805edit=1
#13142 [Ver-Csd]: strtotime() returns -1 for M d H:i:s Y format
ID: 13142 Updated by: [EMAIL PROTECTED] Reported By: jeannielu at hotmail dot com -Status: Verified +Status: Closed Bug Type: Date/time related Operating System: Linux PHP Version: 4.3.0-dev New Comment: 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. Previous Comments: [2003-04-19 16:49:43] fh at fuenf-freun dot de The problem is that the argument is ambigous. M d H:i:s Y could also be interpreted as M d Y:i:s Y. The latter case happens when PHP parses the string. Then a parse error occurs, because ':i:s' doesn't make any sense. Therefore, the function returns -1. In ext/standard/parsedate.y, the expression M d H:i:s Y is matched by 'tUNUMBER tMONTH tUNUMBER' (M d H) as well as 'tUNUMBER : tUNUMBER : tUNUMBER' (H:i:s). Unfortunately, I am not able to submit a patch as I know nothing about lex/yacc. Frederik [2003-04-07 14:40:20] jparneodo at yahoo dot fr Same problem on RedHat 7.2 with PHP 4.3.0 on CEST timezone returns -1 [2003-01-02 19:34:21] [EMAIL PROTECTED] Verified again with 4.3.0. [2002-10-11 09:13:55] godin dot gilles at ic dot gc dot ca I am using PHP 4.2.3 under Windows 2000 where date(D M d H:i:s T Y) produces... Fri Oct 11 09:52:47 Eastern Standard Time 2002 instead of... Fri Oct 11 09:52:47 EDT 2002 and, strtotime() of either format produced above returns -1 [2002-07-04 13:22:32] [EMAIL PROTECTED] Verified during the Bughunt 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/13142 -- Edit this bug report at http://bugs.php.net/?id=13142edit=1
#24718 [Asn]: odbc_result_all crashes on some results
ID: 24718 Updated by: [EMAIL PROTECTED] Reported By: psychosos at gmx dot at Status: Assigned Bug Type: ODBC related Operating System: Windows 2000 Professional PHP Version: 4.3.2 Assigned To: kalowsky New Comment: Well the start is that type TEXT isn't really supported by ODBC v2 (which is what PHP uses). If you can change to a type VARCHAR that would work much better (I can't remember if Access cares about this or not). But for further debugging information, if you can turn on SQLLogging (under your ODBC Administrator) create the connection, run one of the queries that crashes everything, and post the results here that would help. You might need/want to ensure the removal of the site specific information (i.e. login and password) before you post it here though. Previous Comments: [2003-07-24 16:17:10] psychosos at gmx dot at Sorry about the delay. The database I am experiencing the problem with is an Microsoft Access Database I created with MS Access XP. The problematic table has the following schema: Table Kommentare ID long integer DEFAULT 0 NOT NULL Kommentar Memo NOT NULL Kommentator Text (50) Datum Date/Time (standard date) IP Text(15) (sorry about non-SQL conformity; I tried to transcribe the MS Access information) SELECT * FROM Kommentare crashes PHP. SELECT ID, Kommentator, Datum, IP FROM Kommentare works fine. SELECT Kommentar FROM Kommentare crashes PHP. SELECT TOP 200 Kommentar FROM Kommentare works fine as well. But SELECT Kommentar FROM Kommentare crashes PHP. If needed/helpful I might try to determine the exact number of records (bytes) which crashes PHP. Unfortunately I am not experienced debugging applications. If I can be of any further help I'd be glad to follow your instructions :-) Cheers, johannes [2003-07-19 17:30:10] [EMAIL PROTECTED] A sample schema would help tremendiously. Also what database? [2003-07-19 13:35:58] psychosos at gmx dot at Description: If I use odbc_result_all() with a result which has around 75 rows or more it crashes with an Application Error (The instruction at 0x1000ede5 referenced memory at 0x00ae. The memory could not be read. Unfortunately this only happens to me with one table and only if I retrieve longer fields (for example it only crashes when trying to retrieve a longer character field, not with my ID or a short string field) (I am sorry about this unexact bug report. If you can give me any hints how to be more helpful - please do so!) Reproduce code: --- ?php $connection = odbc_connect(Albumsliste,,); $result = odbc_exec($connection, SELECT * FROM Kommentare;); $count = odbc_result_all($result); echo \nResult count: $count\n; odbc_free_result($result); odbc_close($connection); ? Expected result: The code should output all the fields from the table named Kommentare. Actual result: -- PHP crashes with an Application Error (The instruction at 0x1000ede5 referenced memory at 0x00ae. The memory could not be read.) -- Edit this bug report at http://bugs.php.net/?id=24718edit=1
#19022 [Com]: PHP Warning: Failed to write session data (files)
ID: 19022 Comment by: leiflists at tanukisoftware dot com Reported By: phpbugs at mx4k dot com Status: No Feedback Bug Type: Session related Operating System: linux (rh7.3), apache 1.3.26 PHP Version: 4.2.2 New Comment: I was getting this error 100% of the time on a Debian installation running PHP 4.1.2, with the following simple page: ? session_start(); phpinfo(); ? It turns out that my php.ini file contained the following setting: ; Handler used to store/retrieve data. ;session.save_handler = files session.save_handler = user Changing this to: ; Handler used to store/retrieve data. session.save_handler = files ;session.save_handler = user fixed the problem. Not a PHP expert, so this may be obvious. Cheers Previous Comments: [2003-07-27 21:01:38] alexbodn at 012 dot net dot il it's me again. i must mention that the problem occured to me on the index.php page, where i was calling session_id() after session_start(). (here is the place the id should be created for the first time). it didn't appear on pages that call session_id($_GET[$_SESSION[session_name()]]) before session_start(). thanks again, alex [2003-07-27 20:40:41] alexbodn at 012 dot net dot il hello palls, i hope my workaround might help. i have experienced the same failure on a debian woody dev server with no load running a pentium 100 mhz with php 4.1.2. i had the problem on a page which was calling session_id() with no parameters. after reading this list, i have changed the first call to session_id() to: session_id(session_id(a)) and the problem dissapeared. i must mention that after the first time i found the problem, it didn't stop until this workaround. although i didn't examine php source, it might be that the solution for this case would be checking the number of parameters to session_id(). thank you very much for your work and contributions. alex [2003-07-08 02:31:23] wieri420 at planet dot nl For the people not experiencing the failed to write session data error but those of you that do experience the 'random lose of session data' here a possible solution: Check if your script uses cookies AND sessions in one script. Comment all the 'setcookie' lines and all other cookie functions in your script and check if your problem still exists... It solved the problem (dissapearing sessions causing users to log out) for me. [2003-05-05 03:09:15] e dot aderhold at pro-seco dot de (/tmp/sess_7538b7739bdd44e2fb0e747f65af858d, O_RDWR) is this a problem ??? NO create a tmp folder in your SERVER ROOT like /var/www/tmp and it will work fine php.ini means not the / php means the WebServer Root [2003-04-22 09:02:12] php at rjs3 dot com Scratch my last post. The problem is back again. I'm having this issue with PHP 4.2.3 and apache 1.3.27 with SSL. I do have luck when restarting apache sometimes. I'm not 100% positive, but it often fixes itself after I restart my normal apache NOT my apache-ssl which is running my webmail site (horde) that breaks due to this bug. For the record, I also have 2 CPUs since that seems to be a common trend. The load is very low. 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/19022 -- Edit this bug report at http://bugs.php.net/?id=19022edit=1
#24834 [NEW]: Memory corruption bug in object destructor
From: vma1 at abv dot bg
Operating system: Slackware Linux 9.0
PHP version: 5CVS-2003-07-28 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description: Memory corruption bug in object destructor
Description:
The following script causes memory corruption when run from the command
line like:
php -f ./bug.php
There are variants of the script that show the bug when run from the web
browser, but these scripts are bigger.
Even small changes in the sample script hide the bug.
Notice that several bytes in the output string get overwritten.
Reproduce code:
---
?
class database
{
}
$a = new database;
$b = new database;
class broken
{
public function __construct ()
{
}
public function __destruct ()
{
$this-show (array (
aa,
aa,
aa,
, , , , , , , , , , , , ,
));
}
private function show ($values)
{
$values_string = ;
foreach ($values as $val) {
$values_string .= $val;
}
printf (%s\n, $values_string);
}
}
$brk = new broken ();
?
Expected result:
a
Actual result:
--
ëÿ¿aa
--
Edit bug report at http://bugs.php.net/?id=24834edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24834r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24834r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=24834r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24834r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24834r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24834r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24834r=support
Expected behavior: http://bugs.php.net/fix.php?id=24834r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24834r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24834r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24834r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24834r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24834r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24834r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24834r=gnused
