Bug #52792 [Bgs]: core dump
Edit report at http://bugs.php.net/bug.php?id=52792&edit=1 ID: 52792 Updated by: and...@php.net Reported by:ken73 dot chen at gmail dot com Summary:core dump Status: Bogus Type: Bug Package:Unknown/Other Function Operating System: FreeBSD 7.2 PHP Version:5.3.3 Block user comment: N New Comment: What version of memcached extension is it? I'm not sure what I can do at this point, because libxml + memcached works normally for me (and does for other people) and I don't have a FreeBSD machine to debug this on. Previous Comments: [2010-09-07 11:41:21] ken73 dot chen at gmail dot com I have done, but developers thinks the problem is on libxml2. developers http://pecl.php.net/bugs/bug.php?id=18509 [2010-09-07 11:33:21] paj...@php.net Report the issue to the memcached developers at PECL [2010-09-07 11:25:31] ken73 dot chen at gmail dot com Description: db4# php -m [PHP Modules] Core date ereg json libxml memcached pcre Reflection session SPL standard xml [Zend Modules] Segmentation fault (core dumped) The problem only occur when memcached extension is loaded. Actual result: -- db4# gdb /usr/local/bin/php php.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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 "amd64-marcel-freebsd"... Core was generated by `php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.4...done. Loaded symbols for /lib/libcrypt.so.4 Reading symbols from /usr/local/lib/libpcre.so.0...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/local/lib/libxml2.so.5...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /lib/libz.so.4...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x7b5647b0 in ?? () (gdb) bt #0 0x7b5647b0 in ?? () #1 0x7a74b7d5 in xmlFreeMutex () from /usr/local/lib/libxml2.so.5 #2 0x7a74b215 in xmlCleanupGlobals () from /usr/local/lib/libxml2.so.5 #3 0x7a6e3d3a in xmlCleanupParser () from /usr/local/lib/libxml2.so.5 #4 0x0045f338 in php_libxml_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/ext/libxml/libxml.c:583 #5 0x0045f823 in zm_shutdown_libxml (type=1, module_number=3) at /usr/ports/lang/php5/work/php-5.3.3/ext/libxml/libxml.c:655 #6 0x005c6b26 in module_destructor (module=0x7af61270) at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend_API.c:2098 #7 0x005ce1f4 in zend_hash_apply_deleter (ht=0x8b4460, p=0x7afbd4c0) at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend_hash.c:611 #8 0x005ce35a in zend_hash_graceful_reverse_destroy (ht=0x8b4460) at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend_hash.c:646 #9 0x005bc888 in zend_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/Zend/zend.c:759 #10 0x00548aad in php_module_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/main/main.c:2138 #11 0x006abff6 in main (argc=2, argv=0x7fffec68) at /usr/ports/lang/php5/work/php-5.3.3/sapi/cli/php_cli.c:1387 (gdb) frame 4 #4 0x0045f338 in php_libxml_shutdown () at /usr/ports/lang/php5/work/php-5.3.3/ext/libxml/libxml.c:583 583 xmlCleanupParser(); (gdb) -- Edit this bug report at http://bugs.php.net/bug.php?id=52792&edit=1
#48669 [Bgs]: PHP now includes GOTO
ID: 48669 Updated by: and...@php.net Reported By: iwannalive at hotmail dot com Status: Bogus Bug Type: Reproducible crash Operating System: All PHP Version: 5.3.0RC4 New Comment: goto hell; Previous Comments: [2009-06-23 23:56:29] der...@php.net 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 . [2009-06-23 23:46:57] iwannalive at hotmail dot com Description: PHP 5.3 includes goto. This is a problem. Seriously, PHP has made it this far without goto, why turn the language into a public menace? Reproduce code: --- Expected result: The world will end. Actual result: -- The world ended. -- Edit this bug report at http://bugs.php.net/?id=48669&edit=1
#48139 [Bgs]: MySQL Integration
ID: 48139 Updated by: and...@php.net Reported By: Beowulve at gmail dot com Status: Bogus Bug Type: MySQL related Operating System: Win XP Pro PHP Version: 5.3.0RC1 New Comment: I wanted to send you a unicorn and a rainbow by way of apology, but realized you wouldn't be able to sign for it since your head is stuck so far up inside your ass. Previous Comments: [2009-05-03 21:26:59] der...@php.net . [2009-05-03 21:23:48] Beowulve at gmail dot com Description: Yeah, I would firstly like to mention how absolutely pissed off at PHP I am. Your program must be the absolute worst programmed piece of software in all of the net. You compete with Bill Gates in that regard. Now that I have that off my chest, let me explain why your program sucks. I have spent over 12 hours researching, reinstalling, etc etc etc etc etc etc ETCETERA... All trying to get mysql into php. It won't load the goddamn dll. Nothing in Event Log. Nothing anywhere, regardless of errors=E_ALL, or "REPORT_STARTUP_ERRORS". I have fucking done it all. ITS IMPOSSIBLE TO INTEGRATE PHP WITH MYSQL. THIS IS BECAUSE YOUR PROGRAM SUCKS, AND YOU SHOULD ADD SOME GODDAMN ERROR REPORTING SO WE CAN AT LEAST FIGURE OUT WHAT THE FUCK YOUR___ PROGRAM IS DOING WRONG. FIX YOUR SHIT. just fucking fix it. Thanks. And fuck you sincerely, for making my life, and everyone else's life, an utter atrocity. I'm going to Cold Fusion 8; Fuck you. Expected result: Nothing. Your blasted PHP program doesn't even report error messages like it should. Actual result: -- Yay! PHP Works. Oh wait... no it doesn't. It isn't loading .dll's, and it isn't reporting why not - maybe this is because PHP sucks? yup, i think so. -- Edit this bug report at http://bugs.php.net/?id=48139&edit=1
#47370 [Csd->Bgs]: array_unique has backward compatibility problem, and SORT_REGULAR is confusing
ID: 47370
Updated by: and...@php.net
Reported By: for-bugs at hnw dot jp
-Status: Closed
+Status: Bogus
Bug Type: Arrays related
Operating System: any
PHP Version: 5.2.9RC1
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 slight BC breakage is negligible compared to the benefits of
getting it to work properly.
Previous Comments:
[2009-02-13 01:53:09] for-bugs at hnw dot jp
Thank you so much. The snapshot returns same result to PHP 5.2.8 with
reproduce code. Such as:
array(2) {
[0]=>
int(0)
[1]=>
string(0) ""
}
array(2) {
[0]=>
string(0) ""
[1]=>
string(1) "0"
}
[2009-02-12 18:58:34] moriyo...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-02-12 18:12:35] moriyo...@php.net
Verified with 5.2, 5.3, HEAD.
[2009-02-12 16:25:59] for-bugs at hnw dot jp
Sorry, reproduce code was incorrect. Correct code is below:
int(0)
}
array(2) {
[0]=>
string(0) ""
[1]=>
string(1) "0"
}
--
Edit this bug report at http://bugs.php.net/?id=47370&edit=1
#44336 [Csd]: preg_replace with /u (unicode/UTF-8) and many hits = very bad performance
ID: 44336
Updated by: and...@php.net
Reported By: frode at coretrek dot com
Status: Closed
Bug Type: PCRE related
Operating System: Debian GNU/Linux 4.0r3
PHP Version: 5.2.6RC1
Assigned To: nlopess
New Comment:
Fixed in PHP_5_2 now as well.
Previous Comments:
[2008-03-08 12:04:31] nlop...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
this went to the PHP 5.3 and 6 branches only and won't be ported to PHP
5.2.
[2008-03-07 08:23:54] frode at coretrek dot com
Thanks :)
Do you have any idea if there's a chance to get this fix into PHP-5.2.6
before release?
[2008-03-05 16:34:41] fel...@php.net
Nice work! :)
Assigned to maintainer.
[2008-03-05 15:46:27] frode at coretrek dot com
Here's the patch. If it doesn't come through cleanly, it's also
available at http://apollo.coretrek.com/~frode/phpbug-44336.patch.txt
--- php_pcre.c.orig 2008-03-05 16:37:09.0 +0100
+++ php_pcre.c 2008-03-05 16:38:18.0 +0100
@@ -599,20 +599,23 @@
match = NULL;
matched = 0;
PCRE_G(error_code) = PHP_PCRE_NO_ERROR;
do {
/* Execute the regular expression. */
count = pcre_exec(pce->re, extra, subject, subject_len,
start_offset,
exoptions|g_notempty,
offsets, size_offsets);
+ /* Prevent lengthy UTF8 check on subsequent pcre_exec() calls to
save time (See PHP bug 44336) */
+ exoptions |= PCRE_NO_UTF8_CHECK;
+
/* Check for too many substrings condition. */
if (count == 0) {
php_error_docref(NULL TSRMLS_CC, E_NOTICE, "Matched,
but too many
substrings");
count = size_offsets/3;
}
/* If something has matched */
if (count > 0) {
matched++;
match = subject + offsets[0];
@@ -1002,20 +1005,23 @@
match = NULL;
*result_len = 0;
start_offset = 0;
PCRE_G(error_code) = PHP_PCRE_NO_ERROR;
while (1) {
/* Execute the regular expression. */
count = pcre_exec(pce->re, extra, subject, subject_len,
start_offset,
exoptions|g_notempty,
offsets, size_offsets);
+ /* Prevent lengthy UTF8 check on subsequent pcre_exec() calls to
save time (See PHP bug 44336) */
+ exoptions |= PCRE_NO_UTF8_CHECK;
+
/* Check for too many substrings condition. */
if (count == 0) {
php_error_docref(NULL TSRMLS_CC,E_NOTICE, "Matched, but
too many
substrings");
count = size_offsets/3;
}
piece = subject + start_offset;
if (count > 0 && (limit == -1 || limit > 0)) {
if (replace_count) {
@@ -1439,20 +1445,23 @@
last_match = subject;
match = NULL;
PCRE_G(error_code) = PHP_PCRE_NO_ERROR;
/* Get next piece if no limit or limit not yet reached and something
matched*/
while ((limit_val == -1 || limit_val > 1)) {
count = pcre_exec(pce->re, extra, subject,
subject_len, start_offset,
exoptions|g_notempty,
offsets, size_offsets);
+ /* Prevent lengthy UTF8 check on subsequent pcre_exec() calls to
save time (See PHP bug 44336) */
+ exoptions |= PCRE_NO_UTF8_CHECK;
+
/* Check for too many substrings condition. */
if (count == 0) {
php_error_docref(NULL TSRMLS_CC,E_NOTICE, "Matched, but
too many
substrings");
count = size_offsets/3;
}
/* If something matched */
if (count > 0) {
match = subject + offsets[0];
[2008-03-05 15:44:49] frode at coretrek dot com
According to ext/pcre/pcrelib/doc/pcre.txt and
ext/pcre/pcrelib/ChangeLog there is a flag PCRE_NO_UTF8_CHECK which was
added in libpcre 4.5:
> 3. When matching a UTF-8 string, the test for a valid string at the
>s
#43559 [Opn]: array_merge_recursive() doesn't behave as expected with duplicate NULL values
ID: 43559
Updated by: [EMAIL PROTECTED]
Reported By: kraghuba at in dot ibm dot com
Status: Open
Bug Type: Arrays related
Operating System: Linux, windows
PHP Version: 5.2CVS-2007-12-11 (snap)
New Comment:
Looks fine to me.
Previous Comments:
[2008-01-17 21:35:13] [EMAIL PROTECTED]
Simple fix:
http://ecl.zoone.com.br/etc/patches/bug43559.patch
[2007-12-11 05:35:05] kraghuba at in dot ibm dot com
Description:
When two arrays having common key and value are passed as argument to
array_merge_recursive(), the function behaves in an unexpected way for
NULL values. It outputs an empty array instead of an array having two
elements, both being NULL. Whereas, the function behaves in an expected
way with values other than NULL. This behavior can be observed in the
testcase array_merge_recursive_variation9.phpt.
This behavior is observed in PHP5.3 and PHP6 as well.
I tried creating an array with two null values and it works:
output:
array(2) {
[0]=>
NULL
[1]=>
NULL
}
Reproduce code:
---
'string' );
$a2 = array( 'b' => 'string' );
$a3 = array( 'b' => NULL );
$a4 = array( 'b' => NULL );
var_dump( array_merge_recursive($a1, $a2) ); // expected output
var_dump( array_merge_recursive($a3, $a4) ); // unexpecteed output
?>
Expected result:
array(1) {
["b"]=>
array(2) {
[0]=>
string(6) "string"
[1]=>
string(6) "string"
}
}
array(1) {
["b"]=>
array(2) {
[0]=>
NULL
[1]=>
NULL
}
}
Actual result:
--
array(1) {
["b"]=>
array(2) {
[0]=>
string(6) "string"
[1]=>
string(6) "string"
}
}
array(1) {
["b"]=>
array(0) {
}
}
--
Edit this bug report at http://bugs.php.net/?id=43559&edit=1
#43649 [NEW]: Strange error message when performing a query
From: andrei dot vig at ecommerce dot com
Operating system: Debian GNU
PHP version: 5.2CVS-2007-12-21 (snap)
PHP Bug Type: PDO related
Bug description: Strange error message when performing a query
Description:
i am trying to run a few lines of code and i am getting the following
error. Can you please give me a hint here :
Error message :
Invalid datetime format: 7 ERROR: invalid input syntax for type timestamp:
"2007-12-21 07$1$2"' and error code 22007
Reproduce code:
---
Code :
$s_sql = "SELECT hd.hd_ticketid,
hdc.title AS category_title,
hds.title AS status_title,
hd.subject,
hd.datetimecreated,
extract(epoch from hd.datetimecreated) as
datetimecreated_timestamp,
CASE
WHEN hd.domain IS NOT NULL THEN hd.domain
WHEN hd.dom_domain IS NOT NULL THEN hd.dom_domain
ELSE 'General Inquiry'
END as target,
CASE
WHEN loginid_last_repl <> 56455 AND
(hd.hd_statusid = 3 OR hd.hd_statusid = 1) THEN 'Processing Ticket'
WHEN hd.hd_statusid = 2 THEN 'http://andrei-ixhead.ecommerce.com/index.php/cpanelhelpdesk.getFrmTicketModify/hd_ticketid/'
|| hd.hd_ticketid ||'''>Please Respond'
WHEN hd.hd_statusid = 4 THEN 'http://andrei-ixhead.ecommerce.com/index.php/cpanelhelpdesk.getFrmTicketModify/hd_ticketid/'
|| hd.hd_ticketid ||'''>Review Solution'
WHEN hd.hd_statusid = 5 THEN 'Ticket Closed'
WHEN loginid_last_repl = 56455 THEN (extract(epoch
from '2007-12-21 07:42:53'::timestamp) - extract(epoch from
coalesce(hd.datetimemodified_customer, hd.datetimecreated)))::varchar
END as time_passed,
CASE
WHEN loginid_last_repl <> 56455 AND
(hd.hd_statusid = 3 OR hd.hd_statusid = 1) THEN -4
WHEN hd.hd_statusid = 2 THEN -3
WHEN hd.hd_statusid = 4 THEN -2
WHEN hd.hd_statusid = 5 THEN -1
WHEN loginid_last_repl = 56455 THEN extract(epoch
from '2007-12-21 07:42:53'::timestamp) - extract(epoch from
coalesce(hd.datetimemodified_customer, hd.datetimecreated))
END as time_passed_timestamp,
customer_read,
CASE
WHEN datetimeconfirmed IS NULL THEN 'http://andrei-ixhead.ecommerce.com/index.php/cpanelhelpdesk.qryTicketVerify/hd_ticketid/'
|| hd.hd_ticketid ||'''>Verify'
ELSE 'Verified'
END as verify_link,
CASE
WHEN hd.hd_statusid = 5 THEN 'Closed'
ELSE 'Close'
END AS close_link,
CASE WHEN 4=hd.hd_statusid THEN hd.hd_ticketid ELSE
NULL END AS close_ticketid
FROMhd_ticket hd
INNER JOIN hd_ticket_category hdc
USING(hd_ticket_categoryid)
INNER JOIN hd_ticket_status hds USING(hd_statusid)
WHERE hd.customerid = 56204 AND hd.b_visible AND
hd.hd_statusid IN (1,2,3,4)GROUP BYhd.hd_ticketid,
hdc.title,
hds.title,
hd.subject,
hd.datetimecreated,
hd.domain,
hd.dom_domain,
hd.customer_read,
hd.hd_statusid,
hd.datetimemodified_emp,
hd.datetimemodified_customer,
hd.loginid_last_repl,
hd.datetimeconfirmed ORDER BY hd.hd_statusid = 2,
hd.hd_statusid = 4, hd.hd_ticketid DESC LIMIT 1 OFFSET 0";
$o_pdo->query($s_sql);
Expected result:
query works when i run it directly in psql
--
Edit bug report at http://bugs.php.net/?id=43649&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43649&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43649&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43649&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43649&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43649&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43649&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43649&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43649&
#41593 [Com]: FastCGI does not handle graceful reload/shutdown
ID: 41593 Comment by: andrei dot nigmatulin at gmail dot com Reported By: jonepet at dcvhost dot no Status: No Feedback Bug Type: CGI related Operating System: Linux PHP Version: 5.2.3 Assigned To: dmitry New Comment: Graceful reload/shutdown implemented in unofficial patch http://php-fpm.anight.org/. For now docs are in Russian, though. Previous Comments: [2007-06-21 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2007-06-13 19:25:56] severn-php at xephris dot net Re: mod_fcgid: I see... I guess I'll modify mod_fcgid myself for that setup. That doesn't explain the mod_fastcgi problems though. I thought it might be something with my setup so I rebuilt it from scratch... might have had some old crap left behind. I don't get 500 errors with PHP 5.2.3 + mod_fastcgi 2.4.2 + Apache 1.3.37 anymore, so it does look fixed in 5.2.3... but I get another strange problem: doing a graceful restart shortens the sleep time to zero. i.e. Going to this page then doing a graceful after 5 seconds would give "5" instead of the expected "30". php5.fcgi== #!/bin/sh export PHP_FCGI_CHILDREN=4 exec /opt/php5/bin/php-cgi $* For the record, PHP 4.4.7 dies with a 500 error, but that's not a big problem for us... Could the OP perhaps provide us some info on what versions of Apache and mod_fastcgi/mod_fcgid so we can try replicating it? [2007-06-13 17:40:12] [EMAIL PROTECTED] PHP/fastcgi catches SIGTERM and always does graceful shutdown, however mod_fcgid sends SIGTERM then waits for one second and sends SIGKILL if PHP process isn't exited. So this is not a PHP issue. [2007-06-12 19:31:57] severn-php at xephris dot net >From the looks of the changelog, Bug #36158 was fixed in 5.1.3 I just tried that with mod_fcgid 2.1 and Apache 2.2.4 on x64 Linux and it too "died". mod_fcgid sends SIGTERM to the PHP process which dies returning a blank page. I also tried it with mod_fastcgi 2.4.2 and Apache 1.3.37, that died with the 500 error. I've also tried PHP 5.1.6 and 5.2.3, same issue. So... it looks to me like the bug was never actually fixed... (not in 5.x at least). I get the same behaviour with 4.4.7 (blank screen with mod_fcgid, 500 error with mod_fastcgi) [2007-06-05 07:58:15] jonepet at dcvhost dot no As of the close/last comment of Bug #36158 it was working at that time. I don't know if it really did, or if there was any releases with this fix. I didn't meant "previous version" but "earlier version", in the original description, referring to the last comment of Bug #36158. 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/41593 -- Edit this bug report at http://bugs.php.net/?id=41593&edit=1
#42746 [Asn->Bgs]: '\u' char in single quotes gets interepreted.
ID: 42746
Updated by: [EMAIL PROTECTED]
Reported By: mahesh dot vemula at in dot ibm dot com
-Status: Assigned
+Status: Bogus
Bug Type: *Unicode Issues
Operating System: Linux, Windows XP
PHP Version: 6CVS-2007-09-24 (SNAP)
Assigned To: tony2001
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
This is by design.
See "Language Modifications" section in:
http://cvs.php.net/viewvc.cgi/php-src/README.UNICODE?revision=1.8
Previous Comments:
[2007-09-24 10:34:10] mahesh dot vemula at in dot ibm dot com
Description:
'\u' escape sequence char in single quotes('') is being interpreted by
PHP6.
Reproduce code:
---
Expected result:
unicode(1) "ሴ"
unicode(6) "\u1234"
Actual result:
--
unicode(1) "ሴ"
unicode(1) "ሴ"
--
Edit this bug report at http://bugs.php.net/?id=42746&edit=1
#40694 [Fbk]: __call() does not allow passing args by reference
ID: 40694
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type:Scripting Engine problem
PHP Version: 5CVS-2007-03-02 (CVS)
New Comment:
You're forcing a call-time reference. How is this going to help when
call-time reference stuff is deprecated?
Previous Comments:
[2007-08-31 12:13:24] [EMAIL PROTECTED]
test(&$v); //NB 2
var_dump($v);
?>
This code results in:
str
5
int(5)
So I believe this report can be closed.
[2007-03-02 17:51:47] [EMAIL PROTECTED]
Summary from IRC:
This should be fixable by selectively populating arg_info in
zend_std_get_method() with a structure that turns on the pass rest by
ref flag. That'll tell the macros in zend_vm_def.h to send the
arguments by reference. From there, you might need to modify
zend_std_call_user_call() a little bit where it's building the args
array... (Havn't looked close enough to be sure)
While addressing this, you should look at the return value as well,
again this should be a minor matter of checking the __call
implementation and flipping the return type in zend_std_get_method()...
[2007-03-02 17:27:59] [EMAIL PROTECTED]
Description:
__call() method does not allow specifying the arguments array by
reference. Essentially this means that there is no way to return
modified arguments when using overloading.
Reproduce code:
---
class Foo {
function __call($method, &$args)
{
print $args[0]."\n";
$args[0] = 5;
print $args[0]."\n";
return true;
}
}
$v = 'str';
$o = new Foo();
$o->test($v);
var_dump($v);
Expected result:
str
5
int(5)
Actual result:
--
str
5
string(3) "str"
--
Edit this bug report at http://bugs.php.net/?id=40694&edit=1
#41165 [Opn]: Segmentation fault in single script
ID: 41165 Updated by: [EMAIL PROTECTED] Reported By: JimmyPaterson at gmx dot de Status: Open Bug Type: Reproducible crash Operating System: Fedora Core 6 PHP Version: 5CVS-2007-04-22 (snap) New Comment: Can you simplify it to something less than 340 lines of code? Previous Comments: [2007-05-03 22:54:53] JimmyPaterson at gmx dot de Oh, sorry about that - this time I've uploaded it as a downloadable file on my own webspace: http://mhooo.mirrormoon.org/dload/template.bugged.class.inc.php (don't mind the .php extension, it won't execute but download instead). [2007-05-03 17:54:02] [EMAIL PROTECTED] I can't download the reproduction code from that link. [2007-04-23 18:54:55] JimmyPaterson at gmx dot de My code however does the same thing example 1662 on http://de2.php.net/manual/en/function.preg-replace-callback.php does. So is that an infinite recursion as well? Why is there an example to infinite recursion if the actual depth of recursion is limited (to whatever depth) and why is there no notice on that matter :?x thanks for helping, joreji [2007-04-23 16:22:58] [EMAIL PROTECTED] >Why is it expected to cause a stack overflow? Why infinite loop is expected to cause stack overflow? Because that's how stack works. >It is not infinite after all PCRE itself uses stack pretty hard. And it is infinite, yes. [2007-04-23 16:08:54] JimmyPaterson at gmx dot de Why is it expected to cause a stack overflow? It is not infinite after all - I could "expect" a stack overflow with a hundred of recursive calls to preg_match_callback, but not with only 4 - at least not with memory_limit being 128MB. 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/41165 -- Edit this bug report at http://bugs.php.net/?id=41165&edit=1
#41165 [Opn]: Segmentation fault in single script
ID: 41165
Updated by: [EMAIL PROTECTED]
Reported By: JimmyPaterson at gmx dot de
Status: Open
Bug Type: Reproducible crash
Operating System: Fedora Core 6
PHP Version: 5CVS-2007-04-22 (snap)
New Comment:
I can't download the reproduction code from that link.
Previous Comments:
[2007-04-23 18:54:55] JimmyPaterson at gmx dot de
My code however does the same thing example 1662 on
http://de2.php.net/manual/en/function.preg-replace-callback.php does. So
is that an infinite recursion as well? Why is there an example to
infinite recursion if the actual depth of recursion is limited (to
whatever depth) and why is there no notice on that matter :?x
thanks for helping,
joreji
[2007-04-23 16:22:58] [EMAIL PROTECTED]
>Why is it expected to cause a stack overflow?
Why infinite loop is expected to cause stack overflow?
Because that's how stack works.
>It is not infinite after all
PCRE itself uses stack pretty hard.
And it is infinite, yes.
[2007-04-23 16:08:54] JimmyPaterson at gmx dot de
Why is it expected to cause a stack overflow?
It is not infinite after all - I could "expect" a stack overflow with a
hundred of recursive calls to preg_match_callback, but not with only 4 -
at least not with memory_limit being 128MB.
[2007-04-23 10:26:44] [EMAIL PROTECTED]
Infinite recursion - preg_replace_callback -> callback ->
preg_replace_callback is expected to cause stack overflow.
[2007-04-22 17:00:03] JimmyPaterson at gmx dot de
Description:
Segmentation fault... and I have no idea why.
php.ini is the same as CVS snapshot php.ini-recommended with
output_buffering = On
instead of
output_buffering = 4096.
PHP Configure line:
./configure --with-pic --disable-rpath --without-pear --with-bz2
--with-curl --with-exec-dir=/usr/bin --enable-gd-native-ttf
--without-gdbm --with-gettext --with-gmp --with-iconv --with-openssl
--with-png --with-zlib --with-layout=GNU --enable-exif --enable-ftp
--enable-magic-quotes --enable-sockets --enable-sysvsem --enable-sysvshm
--enable-sysvmsg --enable-track-vars --enable-trans-sid --enable-yp
--enable-wddx --with-kerberos --enable-ucd-snmp-hack
--enable-memory-limit --enable-shmop --enable-calendar --enable-dbx
--enable-dio --with-mime-magic=/usr/share/file/magic --with-xml
--with-apxs2=/usr/sbin/apxs --with-mysql --with-gd
--prefix=/usr/local/php5 --enable-debug
Reproduce code:
---
Full code, stripped of any includes: http://rafb.net/p/tSDfY786.html
Expected result:
Header 1
Topic 11
Topic 12
Topic 13
Header 2
Topic 21
Topic 22
Topic 23
Actual result:
--
[EMAIL PROTECTED] system]# gdb /usr/sbin/httpd
GNU gdb Red Hat Linux (6.5-15.fc6rh)
Copyright (C) 2006 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-redhat-linux-gnu"...(no debugging
symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run -X
Starting program: /usr/sbin/httpd -X
(no debugging symbols found)
...
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1208940848 (LWP 11923)]
(no debugging symbols found)
...
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1208940848 (LWP 11923)]
(no debugging symbols found)
...
(no debugging symbols found)
[Sun Apr 22 18:51:10 2007] [warn] module php5_module is already loaded,
skipping
httpd: Could not reliably determine the server's fully qualified domain
name, using ::1 for ServerName
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208760624 (LWP 11884)]
0x0105fe9a in _zval_dtor (zvalue=0x5a5a5a5a,
__zend_filename=0x13ebe2c
"/usr/local/src/php5.2-200704221230/ext/pcre/php_pcre.c",
__zend_lineno=1328)
at /usr/local/src/php5.2-200704221230/Zend/zend_variables.h:32
32 if (zvalue->type <= IS_BOOL) {
(gdb) bt
#0 0x0105fe9a in _zval_dtor (zvalue=0x5a5a5a5a,
__zend_filename=0x13ebe2c
"/usr/local/src/php5.2-200704221230/ext/pcre/php_pcre.c",
__zend_lineno=1328)
at /usr/local/src/php5.2-200704221230/Zend/zend_variables.h:32
#1 0x010628b8 in preg_replace_impl (ht=5, return_value=0x81be6f08,
return_value_ptr=0x0, this_ptr=0x0,
return_value_used=1, is_callable_replace=1 '\001') at
/usr/local/src/php5.2-200704221230/ext/pcre/php_pcre.c:1328
#2 0x01062942 in zif_preg
#40871 [Asn->Bgs]: preg_replace returns blank when the text contains bad UTF-8
ID: 40871 Updated by: [EMAIL PROTECTED] Reported By: ismith at motorola dot com -Status: Assigned +Status: Bogus Bug Type: PCRE related Operating System: Windows Server 2003 SP1 PHP Version: 5.2.1 Assigned To: andrei 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 would really like to keep UTF-8 validation and escapement of bad sequences out of PCRE. Yes, it does return an error when it runs into a bad UTF-8 sequence, but that is all it can do. It does not return the location of the error. Yes, we could return the subject string if we see PCRE_BAD_UTF8_ERROR, but I do not believe it makes sense to do so, since there is still an error condition. It is very likely that you're passing the same bad UTF-8 string to other functions as well, so one could make an argument that this validation and escapement should be done everywhere, which unfortunately is not going to happen and which is why we have PHP 6 in the works. If you are working with UTF-8 strings, I suggest you validate them with your own function before passing them around to PHP extensions. Previous Comments: [2007-04-26 09:14:19] [EMAIL PROTECTED] Nuno, Andrei wake up. Is it worth/possible to do something about it or should I mark it as "won't fix"? [2007-03-22 23:03:41] [EMAIL PROTECTED] in PHP 6, PHP always passes well-formed utf-8 strings to pcre, because the strings are previously processed by ICU. In PHP 4/5, well.. It's hard to leave up to the user-land app to deal with these kind of complex things, but should we really interfere with string? I dunno.. but my point is that maintaing BC is more important at this time.. [2007-03-22 00:29:24] [EMAIL PROTECTED] Did you see this: http://us3.php.net/manual/en/function.preg-last-error.php The error is not getting lost. There's just not much we can do about it aside from returning it to the user. [2007-03-21 22:47:02] [EMAIL PROTECTED] Andrei, do you think there is something we can do about it? [2007-03-21 17:45:27] ismith at motorola dot com Further info: I emailed the PCRE maintainer, and he said that since PCRE doesn't do the replacement part, PCRE itself isn't dumping the text. Apparently when PCRE sees bad UTF8, it returns an error code (I believe PCRE_ERROR_BADUTF8). I think the text is getting lost by php_pcre_replace_impl. If pcre_exec returns PCRE_ERROR_NOMATCH, it saves all the unmatched text in the result; but if pcre_exec returns some other error code, it looks to me like it's dumping the result (which matches what I'm seeing). I don't see how PHP can do much else than what it's doing; without a match count back from pcre_exec, it can't process the replacements in any case. My feeling is that PCRE should not return an error code in this case, but work around the bad UTF-8 character, which would be more in keeping with the Unicode standard. I'll discuss this further with the PCRE folks. OTOH, maybe MediaWiki should do UTF-8 cleanup on the string before giving it to PHP. 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/40871 -- Edit this bug report at http://bugs.php.net/?id=40871&edit=1
#40871 [Asn]: preg_replace returns blank when the text contains bad UTF-8
ID: 40871 Updated by: [EMAIL PROTECTED] Reported By: ismith at motorola dot com Status: Assigned Bug Type: PCRE related Operating System: Windows Server 2003 SP1 PHP Version: 5.2.1 Assigned To: andrei New Comment: Did you see this: http://us3.php.net/manual/en/function.preg-last-error.php The error is not getting lost. There's just not much we can do about it aside from returning it to the user. Previous Comments: [2007-03-21 22:47:02] [EMAIL PROTECTED] Andrei, do you think there is something we can do about it? [2007-03-21 17:45:27] ismith at motorola dot com Further info: I emailed the PCRE maintainer, and he said that since PCRE doesn't do the replacement part, PCRE itself isn't dumping the text. Apparently when PCRE sees bad UTF8, it returns an error code (I believe PCRE_ERROR_BADUTF8). I think the text is getting lost by php_pcre_replace_impl. If pcre_exec returns PCRE_ERROR_NOMATCH, it saves all the unmatched text in the result; but if pcre_exec returns some other error code, it looks to me like it's dumping the result (which matches what I'm seeing). I don't see how PHP can do much else than what it's doing; without a match count back from pcre_exec, it can't process the replacements in any case. My feeling is that PCRE should not return an error code in this case, but work around the bad UTF-8 character, which would be more in keeping with the Unicode standard. I'll discuss this further with the PCRE folks. OTOH, maybe MediaWiki should do UTF-8 cleanup on the string before giving it to PHP. [2007-03-20 20:16:57] [EMAIL PROTECTED] >Where do I report this? How do I get it fixed? See http://pcre.org, further details I don't know myself. [2007-03-20 20:03:58] ismith at motorola dot com Tony, thanks for the response... but more info would be good. Where do I report this? How do I get it fixed? [2007-03-20 20:00:17] ismith at motorola dot com BTW, this bug surfaced in MediaWiki 1.9.3 on a private wiki, where it causes some pages with pasted-in Windows quotes to be displayed as blank. 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/40871 -- Edit this bug report at http://bugs.php.net/?id=40871&edit=1
#28793 [Asn->Csd]: php.ini settings should be able to read other php.ini settings
ID: 28793 Updated by: [EMAIL PROTECTED] Reported By: bero at arklinux dot org -Status: Assigned +Status: Closed Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.0.0RC3 Assigned To: andrei New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php It's already in PHP 5.1 and later. Previous Comments: [2004-06-15 16:36:29] [EMAIL PROTECTED] This is on our list for 5.1 already. Assigning this request to Andrei as he has a patch for it already. [2004-06-15 16:19:21] bero at arklinux dot org Description: This may not make a lot of sense at first look, but it makes perfect sense if you're using a CONFIG_FILE_SCAN_DIR and trying to install a number of 3rd party modules: php.ini settings should be able to reference other php.ini settings Example: [CONFIG_FILE_SCAN_DIR is set to /etc/php.d] /etc/php.ini has include_path=.;/usr/local/php-includes /etc/php.d/3rdpartymodule.ini has include_path=/opt/3rdpartymodule /etc/php.d/anothermodule.ini has include_path=/usr/local/anothermodule These are mutually exclusive --- to reduce the administrator workload of changing include_path for every 3rd party module (what CONFIG_FILE_SCAN_DIR was all about in the first place), it would be really nice if a 3rd party config file could just do include_path += /opt/3rdpartymodule or include_path = $include_path:/opt/3rdpartymodule -- Edit this bug report at http://bugs.php.net/?id=28793&edit=1
#38323 [Asn->Bgs]: Sections is not processed when parse_ini_file() which encoded in UTF-8 w/ BOM
ID: 38323 Updated by: [EMAIL PROTECTED] Reported By: zybersup at yahoo dot com -Status: Assigned +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows XP Professional PHP Version: 4.4.3 Assigned To: andrei 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 reason this happens is because BOM is immediately adjacent to the "[Section 1]" portion. PHP 4 does not support Unicode. Thus, the parser cannot parse that line properly and treats the entries in that section as being global. You can either fix this by putting a newline before [Section 1] or upgrading to PHP 6. Previous Comments: [2006-08-05 06:29:49] zybersup at yahoo dot com You can get the testing INI files from the same place of the testing script. http://theguru.co.th/zybersup/test_utf8.ini http://theguru.co.th/zybersup/test_utf8bom.ini http://theguru.co.th/zybersup/test_utf8ascii.ini [2006-08-04 19:49:33] [EMAIL PROTECTED] Please provide access to the exact .ini file that is problematic. I could not reproduce this on PHP 4 or 5. [2006-08-04 17:24:34] zybersup at yahoo dot com Script to reproduce the bug Unsatisfied Result === (Don't worry about the value, just check the difference of array structure) Array ( [Section1] => Array ( [Aval] => ทดสอบ ทดสอบ (Test Test) [Bval] => ไทย ) [Section2] => Array ( [Cval] => Bar [Dval] => Foo ) ) Array ( [Aval] => เธเธเธชเธญเธ� เธเธเธชเธญเธ� (Test Test) [Bval] => เน�เธเธข [Section2] => Array ( [Cval] => Bar [Dval] => Foo ) ) Array ( [Section1] => Array ( [Aval] => เธเธเธชเธญเธ� เธเธเธชเธญเธ� (Test Test) [Bval] => เน�เธเธข ) [Section2] => Array ( [Cval] => Bar [Dval] => Foo ) ) Try testing a demo at http://www.theguru.co.th/zybersup/test_parse_ini.php (May not keep there more than 2 months) [2006-08-04 07:55:08] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-08-04 02:20:24] zybersup at yahoo dot com Forgot to add more detail that... I have tested files encoded in ASCII, UTF-8 w/ BOM and UTF-8 w/o BOM on both PHP4 and PHP5 (5.0.5) Found no problem with ASCII and UTF-8 w/o BOM. Only UTF-8 w/ BOM has problem. Also I found no problem with PHP 5.0.5. So that this problem should not caused by my INI file, I guess ;). 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/38323 -- Edit this bug report at http://bugs.php.net/?id=38323&edit=1
#37902 [Asn->Csd]: include() and family do not use filesystem encoding
ID: 37902 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type:Unicode Engine related PHP Version: 6CVS-2006-06-23 (CVS) Assigned To: pollita New Comment: I think Sara has fixed this already. Previous Comments: [2006-06-23 15:58:56] [EMAIL PROTECTED] Description: It seems that fopen_for_include uses runtime encoding, not filesystem encoding. Reproduce code: --- php.ini --- unicode_semantics = on unicode.output_encoding = utf-8 unicode.runtime_encoding = iso-8859-1 unicode.script_encoding = utf-8 unicode.filesystem_encoding = utf-8 f.php - café.php (UTF-8 name) - Expected result: in café Actual result: -- Warning: include(caf?.php): failed to open stream: No such file or directory in /home/andrei/dev/php-src/f.php on line 1 Warning: include(): Failed opening 'caf?.php' for inclusion (include_path='.') in /home/andrei/dev/php-src/f.php on line 1 -- Edit this bug report at http://bugs.php.net/?id=37902&edit=1
#38323 [Opn]: Sections is not processed when parse_ini_file() which encoded in UTF-8 w/ BOM
ID: 38323 Updated by: [EMAIL PROTECTED] Reported By: zybersup at yahoo dot com Status: Open Bug Type: Unknown/Other Function Operating System: Windows XP Professional PHP Version: 4.4.3 New Comment: Please provide access to the exact .ini file that is problematic. I could not reproduce this on PHP 4 or 5. Previous Comments: [2006-08-04 17:24:34] zybersup at yahoo dot com Script to reproduce the bug Unsatisfied Result === (Don't worry about the value, just check the difference of array structure) Array ( [Section1] => Array ( [Aval] => ทดสอบ ทดสอบ (Test Test) [Bval] => ไทย ) [Section2] => Array ( [Cval] => Bar [Dval] => Foo ) ) Array ( [Aval] => เธเธเธชเธญเธ� เธเธเธชเธญเธ� (Test Test) [Bval] => เน�เธเธข [Section2] => Array ( [Cval] => Bar [Dval] => Foo ) ) Array ( [Section1] => Array ( [Aval] => เธเธเธชเธญเธ� เธเธเธชเธญเธ� (Test Test) [Bval] => เน�เธเธข ) [Section2] => Array ( [Cval] => Bar [Dval] => Foo ) ) Try testing a demo at http://www.theguru.co.th/zybersup/test_parse_ini.php (May not keep there more than 2 months) [2006-08-04 07:55:08] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2006-08-04 02:20:24] zybersup at yahoo dot com Forgot to add more detail that... I have tested files encoded in ASCII, UTF-8 w/ BOM and UTF-8 w/o BOM on both PHP4 and PHP5 (5.0.5) Found no problem with ASCII and UTF-8 w/o BOM. Only UTF-8 w/ BOM has problem. Also I found no problem with PHP 5.0.5. So that this problem should not caused by my INI file, I guess ;). [2006-08-04 02:15:57] zybersup at yahoo dot com Description: Call the function parse_ini_file() with INI file that written in UTF-8 with BOM. Set process_sections to TRUE. The result is an array of all value correctly parsed, but no section processed. (That means the result is not multi-dimentional array.) -- Edit this bug report at http://bugs.php.net/?id=38323&edit=1
#38105 [Asn->Csd]: Streams encoding doesn't seem to work
ID: 38105
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type:Unicode Engine related
PHP Version: 6CVS-2006-07-14 (CVS)
Assigned To: pollita
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2006-07-14 21:02:26] [EMAIL PROTECTED]
More problems:
$str = b"abcdef";
file_put_contents('str.txt', $str);
Result is (escaped):
<89><91><99><90><80><8C>
[2006-07-14 20:51:20] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2006-07-14 17:05:05] [EMAIL PROTECTED]
Description:
Streams encodings don't seem to work as advertised.
Reproduce code:
---
code
file_put_contents('abcdef', 'str.txt', FILE_TEXT);
php.ini
---
unicode.semantics = on
unicode.output_encoding = utf-8
unicode.runtime_encoding = iso-8859-1
unicode.script_encoding = utf-8
unicode.filesystem_encoding = utf-8
Expected result:
No stdout output and 6 chars in UTF-8 in str.txt.
Actual result:
--
Notice: file_put_contents(): 7 character unicode buffer downcoded for
binary stream runtime_encoding in /home/andrei/dev/php-src/q.php on
line 3
--
Edit this bug report at http://bugs.php.net/?id=38105&edit=1
#38105 [Csd->Asn]: Streams encoding doesn't seem to work
ID: 38105
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Assigned
Bug Type:Unicode Engine related
PHP Version: 6CVS-2006-07-14 (CVS)
Assigned To: pollita
Previous Comments:
[2006-07-14 21:02:26] [EMAIL PROTECTED]
More problems:
$str = b"abcdef";
file_put_contents('str.txt', $str);
Result is (escaped):
<89><91><99><90><80><8C>
[2006-07-14 20:51:20] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2006-07-14 17:05:05] [EMAIL PROTECTED]
Description:
Streams encodings don't seem to work as advertised.
Reproduce code:
---
code
file_put_contents('abcdef', 'str.txt', FILE_TEXT);
php.ini
---
unicode.semantics = on
unicode.output_encoding = utf-8
unicode.runtime_encoding = iso-8859-1
unicode.script_encoding = utf-8
unicode.filesystem_encoding = utf-8
Expected result:
No stdout output and 6 chars in UTF-8 in str.txt.
Actual result:
--
Notice: file_put_contents(): 7 character unicode buffer downcoded for
binary stream runtime_encoding in /home/andrei/dev/php-src/q.php on
line 3
--
Edit this bug report at http://bugs.php.net/?id=38105&edit=1
#38105 [Csd]: Streams encoding doesn't seem to work
ID: 38105
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type:Unicode Engine related
PHP Version: 6CVS-2006-07-14 (CVS)
Assigned To: pollita
New Comment:
More problems:
$str = b"abcdef";
file_put_contents('str.txt', $str);
Result is (escaped):
<89><91><99><90><80><8C>
Previous Comments:
[2006-07-14 20:51:20] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2006-07-14 17:05:05] [EMAIL PROTECTED]
Description:
Streams encodings don't seem to work as advertised.
Reproduce code:
---
code
file_put_contents('abcdef', 'str.txt', FILE_TEXT);
php.ini
---
unicode.semantics = on
unicode.output_encoding = utf-8
unicode.runtime_encoding = iso-8859-1
unicode.script_encoding = utf-8
unicode.filesystem_encoding = utf-8
Expected result:
No stdout output and 6 chars in UTF-8 in str.txt.
Actual result:
--
Notice: file_put_contents(): 7 character unicode buffer downcoded for
binary stream runtime_encoding in /home/andrei/dev/php-src/q.php on
line 3
--
Edit this bug report at http://bugs.php.net/?id=38105&edit=1
#37288 [Opn->Csd]: php-src/ext/unicode/unicode.c:22: php_property.h: No such file or directory
ID: 37288 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Linux PHP Version: 6CVS-2006-05-03 (CVS) Assigned To: andrei New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2006-05-03 05:52:46] [EMAIL PROTECTED] Description: This commit by andrei broke HEAD: modifiedandrei /php-src/ext/unicode/property.c 05/02/2006 23:49:16FALSE on empty string. modifiedandrei /php-src/ext/unicode/property.c 05/02/2006 23:39:15Implement C/POSIX migration functions. modifiedandrei /php-src/ext/unicode/unicode.c 05/02/2006 23:39:15Implement C/POSIX migration functions. Actual result: -- /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/pgsql/pgsql.c: In function `php_pgsql_convert': /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/pgsql/pgsql.c:4613: warning: passing arg 2 of `zend_hash_get_current_key_ex' from incompatible pointer type /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/pgsql/pgsql.c: In function `php_pgsql_insert': /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/pgsql/pgsql.c:5303: warning: passing arg 2 of `zend_hash_get_current_key_ex' from incompatible pointer type /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/pgsql/pgsql.c: In function `build_assignment_string': /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/pgsql/pgsql.c:5415: warning: passing arg 2 of `zend_hash_get_current_key_ex' from incompatible pointer type /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/standard/datetime.c: In function `zif_strptime': /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/standard/datetime.c:104: warning: assignment makes pointer from integer without a cast /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/standard/exec.c: In function `zif_shell_exec': /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/standard/exec.c:409: warning: passing arg 3 of `_php_stream_copy_to_mem_ex' from incompatible pointer type /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/standard/image.c: In function `php_handle_swc': /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/standard/image.c:214: warning: passing arg 3 of `_php_stream_copy_to_mem_ex' from incompatible pointer type /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/standard/string.c: In function `php_u_strtr': /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/standard/string.c:3583: warning: initialization from incompatible pointer type /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/standard/string.c: In function `php_u_similar_char': /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/standard/string.c:4058: warning: passing arg 1 of `php_similar_char' from incompatible pointer type /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/standard/string.c:4058: warning: passing arg 3 of `php_similar_char' from incompatible pointer type /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/standard/streamsfuncs.c: In function `zif_stream_get_contents': /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/standard/streamsfuncs.c:404: warning: passing arg 3 of `_php_stream_copy_to_mem_ex' from incompatible pointer type /opt/cruisecontrol/projects/PHP_HEAD/php-src/ext/unicode/unicode.c:22: php_property.h: No such file or directory make: *** [ext/unicode/unicode.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=37288&edit=1
#36975 [Opn->Asn]: natcasesort() causes array_pop() to misbehave
ID: 36975
Updated by: [EMAIL PROTECTED]
Reported By: ateixeira at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: Arrays related
Operating System: *
PHP Version: 5.1.2
-Assigned To:
+Assigned To: andrei
Previous Comments:
[2006-04-13 19:05:59] crescentfreshpot at yahoo dot com
sort re-indexes it's input. natcasesort/asort/arsort etc do not.
[2006-04-13 16:45:54] ateixeira at gmail dot com
At first I thought array_pop was the problem as well. However, I only
experienced this error when using 'natcasesort'. If I changed to using
'sort' instead, the error went away. In both natcasesort and sort, the
array's indices should be out of order due to the sorting, but
natcasesort is the only one to give me an error. It's strange, though,
since when I run your test, I also get an error, proving your array_pop
issue. So, that probably points to it being related to array_pop and
not natcasesort, but that still doesn't explain why 'sort' will work,
but not 'natcasesort'.
[2006-04-13 14:50:19] crescentfreshpot at yahoo dot com
This seems like an array_pop() bug to me.
This behaviour happens when array indices are 'out of order' and you
then use array_pop(). Any subsequent 'pushing' onto the end of the
array fails.
Using either the empty-square-bracket syntax or array_push() will both
fail. Square-bracket syntax issues the warning, array_push() does not.
Re: pushing new values onto the end of an array, the docs state: "the
maximum of the existing integer indices is taken, and the new key will
be that maximum value + 1"
It seems the engine cannot generate the next index after array_pop()
does it's thing.
Smaller reproduce code:
'foo', 0 => 'baz');
array_pop($list);
$list[] = 'bar'; // <- fails, issues warning
array_push($list, 'bar'); // <- fails, no warning
print_r($list);
?>
Expected Result
---
Array
(
[1] => foo
[2] => bar
[3] => bar
)
Actual Result
-
Warning: Cannot add element to the array as the next element is already
occupied in C:\Dev\webserver_root\t.php on line 5
Array
(
[1] => foo
)
[2006-04-04 21:06:37] ateixeira at gmail dot com
Description:
After using natcasesort, using the array_pop and array_push (or arr[] =
$value construct) in conjunction cause the following error (on
array_push):
Warning: Cannot add element to the array as the next element is
already occupied in x.php on Line xx
Also, the value doesn't get pushed onto the array.
Reproduce code:
---
$fileList = array('aa', 'aa', 'bb', 'bb', 'cc', 'cc');
$test = natcasesort($fileList);
if ($test) {
echo "natcasesort success!\n";
}
$val = array_pop($fileList);
$fileList[] = $val;
print_r($fileList);
Expected result:
natcasesort success!
Array
(
[0] => aa
[1] => aa
[2] => bb
[3] => bb
[4] => cc
[5] => cc
)
Actual result:
--
natcasesort success!
PHP Warning: Cannot add element to the array as the next element is
already occupied in /webroot/root/projects/RPMfe/j.php on line 10
Warning: Cannot add element to the array as the next element is already
occupied in /webroot/root/projects/RPMfe/j.php on line 10
Array
(
[0] => aa
[1] => aa
[3] => bb
[2] => bb
[5] => cc
)
--
Edit this bug report at http://bugs.php.net/?id=36975&edit=1
#37083 [Asn]: Frequent crashs in SOAP extension with new WSDL caching code in multithread WS
ID: 37083
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: SOAP related
Operating System: *
PHP Version: 5CVS-2006-04-14 (snap)
Assigned To: andrei
New Comment:
Does it crash in the client code or the server code? Can you provide a
short script that reproduces it on the webserver as well as a
backtrace?
Previous Comments:
[2006-04-15 11:59:30] [EMAIL PROTECTED]
The bug is not fixed completely. With another webservice it crashes
(one with an xsd:anyType value in one of the complex types):
[15/Apr/2006:13:55:20] catastrophe (24983): CORE3260: Server crash
detected (signal SIGSEGV) [15/Apr/2006:13:55:20] info (24983):
CORE3261: Crash occurred in NSAPI SAF php5_execute
[15/Apr/2006:13:55:20] info (24983): CORE3262: Crash occurred in
function get_conversion from module
/pangaea/webserver61/bin/libphp5.so
Code:
http://opteron.bremen.wdc-mare.org:8800/servlet/AXIS/Search?wsdl',array('encoding'=>'ISO-8859-1'
$search=new stdClass();
$search->queryString='argo';
$search->ranges[]=$r=new stdClass();
$r->field='maxDateTime';
$r->min='2003-04-01';
$search->index='all';
$res=$ws->search($search,$i*10,10);
}
?>
The problem is that this cannot be reproduced with CLI, this crashes
with SIGSEGV or SIGILL in the webserver only, so the above CLI script
works.
[2006-04-15 11:39:27] [EMAIL PROTECTED]
Works as CLI in patched snapshot:
[EMAIL PROTECTED]:~/install/php5.1-200604151030/sapi/cli$ ./php
~/test/test.php
Loop: 0
Loop: 1
Loop: 2
Loop: 3
Loop: 4
Loop: 5
Loop: 6
Loop: 7
Loop: 8
Loop: 9
Loop: 10
Loop: 11
Loop: 12
Loop: 13
Loop: 14
Loop: 15
Loop: 16
Loop: 17
Loop: 18
Loop: 19
...and in the webserver with WSDL caching enabled:
http://www.pangaea.de/PangaVista?query=grobe
You can apply this patch and close this bug.
I have only the following question:
Is it correct that no more /tmp/wsdl-* files are generated? There
should be some hint in php.ini, that the wsdl_cache_dir is not longer
needed. Or WHEN will it be used now (if not ZTS,...)?
Thanks for this patch, it is now really faster in this multithreaded
webserver where no longer the wsdl/wsdl-cache file needs to be
evaluated!
[2006-04-15 06:16:42] [EMAIL PROTECTED]
Could you try the following patch and make sure it works for you?
http://www.php.net/~andrei/soap_bug.diff
[2006-04-14 15:12:28] [EMAIL PROTECTED]
I have now compiled it again only with xml and soap modules linked
statically with --enable-debug, this time it coredumps even in the
first loop (there must be something completely broken, that the script
generates two different signals with/without debug). From the webserver
logs you see that master_to_xml is also in the error log (together with
other soap functions):
(gdb) run ~/test/test.php
Starting program: /pangaea/install/php5.1-200604131430/sapi/cli/php
~/test/test.php
Loop: 0
Program received signal SIGSEGV, Segmentation fault.
master_to_xml (encode=0x424b60, data=0x43fc28, style=1,
parent=0x429740)
at
/pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:363
363 data =
encode->to_xml_before(&encode->details, data);
(gdb) bt
#0 master_to_xml (encode=0x424b60, data=0x43fc28, style=1,
parent=0x429740)
at
/pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:363
#1 0x0011ca0c in model_to_xml_object (node=0x429740, model=0x43a8b0,
object=0x43fc28, style=1, strict=1)
at
/pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:1461
#2 0x0011cb5c in model_to_xml_object (node=0x429740, model=0x43a8e0,
object=0x428258, style=1, strict=1)
at
/pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:1542
#3 0x0011d300 in to_xml_object (type=0x439ef8, data=0x428258, style=1,
parent=0x423138)
at
/pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:1718
#4 0x0011fd60 in sdl_guess_convert_xml (enc=0x439ef8, data=0x428258,
style=1, parent=0x423138)
at
/pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:2981
#5 0x0011b7e4 in master_to_xml (encode=0x439ef8, data=0x428258,
style=1, parent=0x423138)
at
/pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:366
#6 0x0010d45c in serialize_zval (val=0x428258, param=0x42f430,
paramName=0x413718 "searchDescription", style=1,
parent=0x423138) at
/pangaea/install/php5.1-200604131430/ext/soap/soap.c:4167
#7 0x0010d60c in serialize_parameter (param=0x42f430,
param_val=0x428258, index=1, name=0x0, style=1,
parent=0x423138) at
/pangaea/install/php5.1-200604131430/ext/soap/soap.c:4140
#8 0x001
#37083 [Asn]: Frequent crashs in SOAP extension with new WSDL caching code in multithread WS
ID: 37083 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: SOAP related Operating System: * PHP Version: 5CVS-2006-04-14 (snap) Assigned To: andrei New Comment: Could you try the following patch and make sure it works for you? http://www.php.net/~andrei/soap_bug.diff Previous Comments: [2006-04-14 15:12:28] [EMAIL PROTECTED] I have now compiled it again only with xml and soap modules linked statically with --enable-debug, this time it coredumps even in the first loop (there must be something completely broken, that the script generates two different signals with/without debug). From the webserver logs you see that master_to_xml is also in the error log (together with other soap functions): (gdb) run ~/test/test.php Starting program: /pangaea/install/php5.1-200604131430/sapi/cli/php ~/test/test.php Loop: 0 Program received signal SIGSEGV, Segmentation fault. master_to_xml (encode=0x424b60, data=0x43fc28, style=1, parent=0x429740) at /pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:363 363 data = encode->to_xml_before(&encode->details, data); (gdb) bt #0 master_to_xml (encode=0x424b60, data=0x43fc28, style=1, parent=0x429740) at /pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:363 #1 0x0011ca0c in model_to_xml_object (node=0x429740, model=0x43a8b0, object=0x43fc28, style=1, strict=1) at /pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:1461 #2 0x0011cb5c in model_to_xml_object (node=0x429740, model=0x43a8e0, object=0x428258, style=1, strict=1) at /pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:1542 #3 0x0011d300 in to_xml_object (type=0x439ef8, data=0x428258, style=1, parent=0x423138) at /pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:1718 #4 0x0011fd60 in sdl_guess_convert_xml (enc=0x439ef8, data=0x428258, style=1, parent=0x423138) at /pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:2981 #5 0x0011b7e4 in master_to_xml (encode=0x439ef8, data=0x428258, style=1, parent=0x423138) at /pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:366 #6 0x0010d45c in serialize_zval (val=0x428258, param=0x42f430, paramName=0x413718 "searchDescription", style=1, parent=0x423138) at /pangaea/install/php5.1-200604131430/ext/soap/soap.c:4167 #7 0x0010d60c in serialize_parameter (param=0x42f430, param_val=0x428258, index=1, name=0x0, style=1, parent=0x423138) at /pangaea/install/php5.1-200604131430/ext/soap/soap.c:4140 #8 0x001124ac in serialize_function_call (this_ptr=0x427f60, function=0x415118, function_name=0x1 , uri=0x42f430 "", arguments=0x44059c, arg_count=5, version=1, soap_headers=0x0) at /pangaea/install/php5.1-200604131430/ext/soap/soap.c:3975 #9 0x001132ac in do_soap_call (this_ptr=0x427f60, function=0x440650 "advSearch", function_len=9, arg_count=5, real_args=0x440598, return_value=0x43fda0, location=0x43a6f0 "http://ws.pangaea.de/ws/services/PangaVista";, soap_action=0x0, call_uri=0x0, soap_headers=0x0, output_headers=0x0) at /pangaea/install/php5.1-200604131430/ext/soap/soap.c:2482 #10 0x00113ebc in zif_SoapClient___call (ht=2, return_value=0x43fda0, return_value_ptr=0x0, this_ptr=0x427f60, return_value_used=1) at /pangaea/install/php5.1-200604131430/ext/soap/soap.c:2696 #11 0x002023bc in zend_call_function (fci=0xffbfef98, fci_cache=0x363c00) at /pangaea/install/php5.1-200604131430/Zend/zend_execute_API.c:952 #12 0x002226dc in zend_call_method (object_pp=0xffbff0b0, obj_ce=0x3d0e38, fn_proxy=0x3d0f54, function_name=0x2ee3c8 "__call", function_name_len=6, retval_ptr_ptr=0xffbff04c, param_count=1515870810, arg1=0x440008, arg2=0x4403a0) at /pangaea/install/php5.1-200604131430/Zend/zend_interfaces.c:88 #13 0x0022904c in zend_std_call_user_call (ht=-4198224, return_value=0x43ff60, return_value_ptr=0x0, this_ptr=0x427f60, return_value_used=1) at /pangaea/install/php5.1-200604131430/Zend/zend_object_handlers.c:634 #14 0x0022e8fc in zend_do_fcall_common_helper_SPEC (execute_data=0xffbff388) at zend_vm_execute.h:200 #15 0x0022e0d0 in execute (op_array=0x422d08) at zend_vm_execute.h:92 #16 0x0020fef0 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /pangaea/install/php5.1-200604131430/Zend/zend.c:1109 #17 0x001cdb58 in php_execute_script (primary_file=0xffbffc28) ---Type to continue, or q to quit--- at /pangaea/install/php5.1-200604131430/main/main.c:1732 #18 0x0029100c in main (argc=2, argv=0xffbffcc4) at /pangaea/install/php5.1-200604131430/sapi/cli/php_cli.c:1092 (gdb) [2006-04-14 15:06:20] [EMAIL PROTECTED] Can definitely reproduce this. Valgrind trace follows: ==8798== In
#37002 [Asn->Opn]: Have to quote literals in INI when concatenating with vars
ID: 37002
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Open
Bug Type:Scripting Engine problem
PHP Version: 5.1.2
Assigned To: andrei
New Comment:
I don't know how to fix it. :)
Previous Comments:
[2006-04-06 21:22:05] [EMAIL PROTECTED]
Description:
>
> Another problem that I've hit is the following include path setting
does not
> work (ie. putting ${include_path} at the end)
>
> include_path = /home/y/share/pear:${include_path}
Yeah, a bit of a bug in the ini file parser. You can work around it
for
now by doing:
include_path = "/home/y/share/pear":${include_path}
--
Edit this bug report at http://bugs.php.net/?id=37002&edit=1
#33151 [Bgs->Asn]: [RFE] Implement a sane behavior when PCRE runs out of stack space
ID: 33151 Updated by: [EMAIL PROTECTED] Reported By: mikko dot rantalainen at peda dot net -Status: Bogus +Status: Assigned Bug Type: PCRE related Operating System: Linux PHP Version: 5.0.4 -Assigned To: +Assigned To: andrei Previous Comments: [2005-05-26 19:39:44] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Repeating will not make us fix any bugs any faster, quite the contrary. [2005-05-26 14:17:39] mikko dot rantalainen at peda dot net Description: PHP already has a number of bugs reported (http://bugs.php.net/search.php?search_for=crash+segmentation&boolean=0&limit=30&order_by=&direction=ASC&cmd=display&status=All&bug_type%5B%5D=PCRE+related) because of PCRE related crashes that are result of PCRE using heavy recursion with some patterns. Making always sure that both pattern and input string are always safe when using functions implemented with PCRE is really hard from PHP code because the most often hit limit is too small stack and PCRE is really the only part of the code that has knowledge to compute the stack usage. PHP already has it's own copy of PCRE and I'm requesting that that copy is modified so that PCRE is aware of stack usage and returns an error if computing the result would result in stack overflow and possible segmentation fault. If that is considered to be too much of work, PHP should at least put a hard limit on recursion as described in PCRE documentation: http://www.pcre.org/pcre.txt: "LIMITING PCRE RESOURCE USAGE ...a limit can be placed on the resources used by a single call to pcre_exec(). The limit can be changed at run time, as described in the pcreapi documentation..." Another way to workaround this problem is described by jorton at php.net in bug #28461: "One way PHP could mitigate the issue is to to set the match_limit field in the pcre_extra structure which puts a limit on the depth of the stack recursion." (I'm not sure if this is the actual implementation of above note?) Rationale: preg_* functions are often used for input validation just like in Perl. However, it cannot be safely used for that purpose because of all these bugs that result in stack overflows and/or segmentation faults. Increasing stack size cannot be as a workaround because stack usage seems to be exponential. (Resulting segmentation faults inside an Apache module are real pain in the ass to debug, too.) Reproduce code: --- Expected result: preg_match() should return true because the test string passes the test that it's composed of a's possibly followed by b's. Actual result: -- Crash. Isn't limited to PHP 5.x. I wouldn't expect 100KB of text to be too much because I've set my stack to 8192KB (more than 80x the size of the string to search) but I still get segmentation fault. Increase the counter "10" to reproduce the crash if you have huge stack. -- Edit this bug report at http://bugs.php.net/?id=33151&edit=1
#36983 [Bgs->Asn]: preg_match_all incorrect due to backtrack length limit?
ID: 36983 Updated by: [EMAIL PROTECTED] Reported By: crisp at tweakers dot net -Status: Bogus +Status: Assigned Bug Type: PCRE related Operating System: all PHP Version: 4.4.2 -Assigned To: +Assigned To: andrei Previous Comments: [2006-04-05 23:01:05] crisp at tweakers dot net Just a small update on this. PCRE is actually issuing an error; specifically PCRE_ERROR_MATCHLIMIT (-8) Apparently when PCRE goes into backtracking it will try any combination of the OR'ed subpattern resulting into over 10.000.000 calls to match(). Obviously there is no construction that first checks if (and where) a possible alternative defined as an OR can match within the part that is being backtracked. So this seems to be defined behaviour of PCRE (but it could use improvement if even a simple case like the one I constructed already triggers this behaviour), but my question now is why does PHP not raise a warning or error when PCRE exits with one? [2006-04-05 20:26:55] [EMAIL PROTECTED] >bogus' has a negative ring to it - at least it does for >me as a non-native English-speaking person. Well, it doesn't have a negative meaning for me, although I'm not a native speaker either =) [2006-04-05 20:22:19] crisp at tweakers dot net That last remark is taking my well-meant criticism to the extreme; surely you will know that that was not what I meant. 'bogus' has a negative ring to it - at least it does for me as a non-native English-speaking person. Anyway, let's leave it at that; I'll submit this to the PCRE developers. [2006-04-05 20:00:31] [EMAIL PROTECTED] "Bogus" doesn't mean "reporter is an idiot, the bug exists only in his imagination". "Bogus" quite often means "there were no issue we can fix, so we can't CLOSE it (i.e. FIX), we can only mark it as BOGUS (i.e. not PHP problem)". Status "CLOSED" means there was a bug in PHP itself and it was fixed. This is not the case. Nothing personal whatsoever. PCRE category exists for quite obvious reason: PHP functions in ext/pcre may be buggy, so you should be able to report problems in this category. Yes, we could of course add some more statuses like "not PHP problem", "RTFM", "floats have limited precision" or "please copy libmysql.dll to $PATH", but well.. does it make any sense? Not to me. [2006-04-05 19:52:12] crisp at tweakers dot net Not to be disrespectfull but honestly I feel a bit put off by the reply I'm getting here. When I personally put time in creating a valid and easy to follow testcase and submit it here, believing this is the right place to go (I found this bug using a PHP built-in function and it is PCRE related - why else do you have that category?) and by doing so helping in improving PHP, and all I'm getting is a 'this bug is bogus'-reply when it formally isn't. Maybe you should consider some more status codes like '3rd party related' or so - at least something that doesn't have such a negative sound and that actually reflects the status of the bugreport. And even when such an issue is 3rd party related I would think the PHP development team should at least feel some responsibility or show some concern about such issues. You probably have better contacts with these parties than I do and it is in your benefit too that such issues get resolved. Thank you in advance for making me think twice about submitting a bug the next time I encounter one; it'll probably save me some time... 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/36983 -- Edit this bug report at http://bugs.php.net/?id=36983&edit=1
#36241 [Opn]: explode() crashes
ID: 36241
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: Linux on PowerPC
PHP Version: 6CVS-2006-02-10 (CVS)
New Comment:
I cannot reproduce this on either x86 (BSD) or PPC (OSX).
Previous Comments:
[2006-03-03 18:10:18] [EMAIL PROTECTED]
I just did a fresh build of the current cvs on powerpc and i386. The
i386 works perfectly
[EMAIL PROTECTED]:/software/cvs/php-src$ /usr/local/php5-cvs/bin/php -r
'print_r(explode(",", "bal,blaj,alsdj"));'
Array
(
[0] => bal
[1] => blaj
[2] => alsdj
)
[EMAIL PROTECTED]:/software/cvs/php-src$
The powerpc version still crashes.
[2006-02-21 01:00:03] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2006-02-13 19:10:41] [EMAIL PROTECTED]
Is Linux on PPC the only platform where you're able to reproduce it?
[2006-02-10 09:53:02] [EMAIL PROTECTED]
I just updated my cvs working copy and the error has slightly changed
but is still there.
The following script causes the trouble:
It's not segm fault anymore but that doesn't make much of a
difference. zend_parse_parameters() just returns bogus.
Here is a gdb session:
[EMAIL PROTECTED]:/tmp$ gdb /usr/local/php5-cvs/bin/php
GNU gdb 6.4-debian
Copyright 2005 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 "powerpc-linux-gnu"...Using host
libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) break string.c:1099
Breakpoint 1 at 0x101fada4: file
/home/cvs/php/php-src/ext/standard/string.c, line 1099.
(gdb) run -f explode.php
Starting program: /home/local/php5-cvs/bin/php -f explode.php
warning: Lowest section in /usr/lib/libicudata.so.34 is .hash at
0094
[Thread debugging using libthread_db enabled]
[New Thread 805588960 (LWP 20645)]
[Switching to Thread 805588960 (LWP 20645)]
Breakpoint 1, zif_explode (ht=2, return_value=0x1069ca68,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1)
at /home/cvs/php/php-src/ext/standard/string.c:1099
1099if ( zend_parse_parameters(argc TSRMLS_CC, "TT|l",
&delim, &delim_len, &delim_type,
(gdb) next
1104if ( delim_len == 0 ) {
(gdb) print str
$1 = (void *) 0xb7
(gdb) print delim
$2 = (void *) 0x1040345c
(gdb) print str_len
$3 = 16
(gdb) print delim_len
$4 = 0
(gdb) print (char *) delim
$5 = 0x1040345c "/home/cvs/php/php-src/Zend/zend_vm_execute.h"
If continue the program I get a php error message because the delim
string is empty.
Uwe
[2006-02-01 11:15:33] [EMAIL PROTECTED]
Can't reproduce on i386 both in Unicode and regular modes.
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/36241
--
Edit this bug report at http://bugs.php.net/?id=36241&edit=1
#36234 [Asn->Opn]: segfault when testing property of an overloaded class in switch a statement
ID: 36234
Updated by: [EMAIL PROTECTED]
Reported By: matt dot flaherty at hildebrand dot co dot uk
-Status: Assigned
+Status: Open
Bug Type: Reproducible crash
Operating System: SUSE LINUX 10.0 (i586)
PHP Version: 4.4.2
Assigned To: andrei
New Comment:
I am not maintaining this anymore.
Previous Comments:
[2006-02-13 19:36:22] [EMAIL PROTECTED]
Andrei is the maintainer of this extension, not me...
[2006-02-13 15:53:49] matt dot flaherty at hildebrand dot co dot uk
Thank you for this. I'm aware that the OO implementation in PHP5 is
very different and I intend to use 5 for any serious OO development
from now on. However, there is a project I'm working on which requires
PHP 4 and needs a drop-in replacement for the PEAR DB libraries within
a third-party framework. As support for PHP 4 is still a going concern
I decided to raise this ticket. Since posting this bug report, I have
also encountered the same problem in PHP 4.3.11. Thank you again for
your response.
[2006-02-11 13:19:50] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-01-31 23:51:27] judas dot iscariote at gmail dot com
Program received signal SIGSEGV, Segmentation fault.
0x00417258 in overload_get_property
(property_reference=0x7fe61af8)
at /home/cristian/php-src/ext/overload/overload.c:363
363 if (Z_TYPE_P(overloaded_property) ==
OE_IS_OBJECT) {
(gdb) bt
#0 0x00417258 in overload_get_property
(property_reference=0x7fe61af8)
at /home/cristian/php-src/ext/overload/overload.c:363
#1 0x004e9c01 in get_overloaded_property (T=0x7fe61ae0) at
/home/cristian/php-src/Zend/zend_execute.c:970
#2 0x004e8327 in _get_zval_ptr (node=0x6a6bd0,
Ts=0x7fe614c0, should_free=0x649c10)
at /home/cristian/php-src/Zend/zend_execute.c:93
#3 0x004f2503 in zend_switch_free (opline=0x6a6ba8,
Ts=0x7fe614c0)
at /home/cristian/php-src/Zend/zend_execute.c:236
#4 0x004efe54 in execute (op_array=0x6978d0) at
/home/cristian/php-src/Zend/zend_execute.c:2053
#5 0x004d5cf5 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/cristian/php-src/Zend/zend.c:934
#6 0x00498774 in php_execute_script
(primary_file=0x7fe64750) at
/home/cristian/php-src/main/main.c:1753
#7 0x004f50eb in main (argc=2, argv=0x7fe648b8) at
/home/cristian/php-src/sapi/cli/php_cli.c:830
./sapi/cli/php -v
PHP 4.4.3-dev (cli) (built: Jan 31 2006 19:48:51) (DEBUG)
[2006-01-31 18:30:29] matt dot flaherty at hildebrand dot co dot uk
Almost forgot. PHP is configured in the standard way for this distro:
./configure --prefix=/usr --datadir=/usr/share/php
--mandir=/usr/share/man --bindir=/usr/bin --libdir=/usr/share
--includedir=/usr/include --sysconfdir=/etc --with-_lib=lib
--with-config-file-path=/etc --with-exec-dir=/usr/lib/php/bin
--disable-debug --enable-inline-optimization --enable-memory-limit
--enable-magic-quotes --enable-safe-mode --enable-sigchild
--disable-ctype --disable-session --without-mysql --disable-cli
--without-pear --with-openssl --with-apxs2=/usr/sbin/apxs2-prefork
i586-suse-linux
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/36234
--
Edit this bug report at http://bugs.php.net/?id=36234&edit=1
#34089 [NoF->Fbk]: Configure fails build test for libxml2
ID: 34089 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Feedback Bug Type: Compile Failure Operating System: Mac OS X 10.4.2 PHP Version: 6CVS-2005-10-07 Previous Comments: [2006-01-31 23:04:54] [EMAIL PROTECTED] OS X 10.4.2 - Build 8E90 PHP6 snapshot 200601311733 # ./configure --with-layout=PHP --prefix=/usr/local/php/6.0.0 --disable-all --with-icu-dir=/usr/local/icu # make # make install Using gcc v4.0.1 Test script: php-cli -dunicode_semantics=on -f test.php Result: unicode(3) "foo" Looks like the expected results to me. Can you run "otool -L" on the php library and share that here? [2006-01-14 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-12-30 00:59:11] [EMAIL PROTECTED] Do you actually have libicui18n.dylib.34 in /usr/local/...? [2005-11-30 17:30:28] [EMAIL PROTECTED] Tried that CVS snapshot with the following config line: ./configure --with-layout=PHP --prefix=/usr/local/php/6.0.0 --disable-all --with-icu-dir=/usr/local/icu It configures, makes, and make installs just fine. But it still says the library isn't loaded: ramsey:~ ramsey$ /usr/local/php/6.0.0/bin/php -v dyld: Library not loaded: libicui18n.dylib.34 Referenced from: /usr/local/php/6.0.0/bin/php Reason: image not found Trace/BPT trap [2005-10-07 21:38:20] [EMAIL PROTECTED] I've just updated my checkout and tried to rebuild it. I'm still getting the "Library not loaded" errors, though. I don't have access to another MacOSX machine. Is there someone else who can try to build this on their Mac to verify whether this issue can be reproduced? 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/34089 -- Edit this bug report at http://bugs.php.net/?id=34089&edit=1
#34089 [Opn]: Configure fails build test for libxml2
ID: 34089 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.4.2 PHP Version: 6CVS-2005-10-07 New Comment: Do you actually have libicui18n.dylib.34 in /usr/local/...? Previous Comments: [2005-11-30 17:30:28] [EMAIL PROTECTED] Tried that CVS snapshot with the following config line: ./configure --with-layout=PHP --prefix=/usr/local/php/6.0.0 --disable-all --with-icu-dir=/usr/local/icu It configures, makes, and make installs just fine. But it still says the library isn't loaded: ramsey:~ ramsey$ /usr/local/php/6.0.0/bin/php -v dyld: Library not loaded: libicui18n.dylib.34 Referenced from: /usr/local/php/6.0.0/bin/php Reason: image not found Trace/BPT trap [2005-11-30 00:52:49] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php6.0-latest.tar.gz For Windows: http://snaps.php.net/win32/php6.0-win32-latest.zip [2005-10-07 21:38:20] [EMAIL PROTECTED] I've just updated my checkout and tried to rebuild it. I'm still getting the "Library not loaded" errors, though. I don't have access to another MacOSX machine. Is there someone else who can try to build this on their Mac to verify whether this issue can be reproduced? [2005-09-16 12:31:41] [EMAIL PROTECTED] Can you reproduce this on some other Macosx machine? Can someone else reproduce this? [2005-09-15 23:20:58] [EMAIL PROTECTED] I grabbed the latest HEAD and I'm using the latest ICU (v3.4). With the following config line, everything configures, makes, and make installs just fine: ./configure --with-layout=PHP --prefix=/usr/local/php/6.0.0 --disable-all --with-icu-dir=/usr/local/icu However, I still receive an error: ramsey:~ ramsey$ /usr/local/php/6.0.0/bin/php -i dyld: Library not loaded: libicui18n.dylib.34 Referenced from: /usr/local/php/6.0.0/bin/php Reason: image not found Trace/BPT trap 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/34089 -- Edit this bug report at http://bugs.php.net/?id=34089&edit=1
#27908 [Ver]: xml default_handlers not being called when using libxml (works fine with expat)
ID: 27908
Updated by: [EMAIL PROTECTED]
Reported By: ahundiak at ingr dot com
Status: Verified
Bug Type: XML related
Operating System: *
PHP Version: 5CVS-2005-08-19
-Assigned To:
+Assigned To: rrichards
New Comment:
Rob, you grok libxml2 better than me, mind taking a look at this one?
Previous Comments:
[2005-03-24 18:33:49] [EMAIL PROTECTED]
See also bug #32441 for another example script.
[2005-03-24 18:31:56] [EMAIL PROTECTED]
You can always tell ext/xml to use external expat libraries
by using --with-libxml-dir configure option (it won't help of course if
you're using precompiled binaries)
[2005-03-18 16:22:03] werner at esmt dot org
..but what can i do, if i want to run my current php4
applications with php5 and other webs the new libxml2
stuff? its not really a solution, only a workaround ...
[2005-03-06 19:45:41] [EMAIL PROTECTED]
It is a bug in the compatibility layer used when ext/xml is build with
libxml2. It works fine with expat.
[2004-04-07 12:34:00] ahundiak at ingr dot com
Description:
As the test case shows, it does not appear that the default handler is
being called under PHP5RC1. The other handlers seem to work but the
default handler is required to get the document type line. PHP4.3.5
works. Using libxml2 2.6.5.
Reproduce code:
---
function x_default_handler($xp,$data)
{
echo "x_default_handler $data\n";
}
$xp = xml_parser_create();
xml_set_default_handler($xp,'x_default_handler');
xml_parse($xp,'',TRUE);
xml_parser_free($xp);
echo "Parse Test " . PHP_VERSION . " Done\n";
Expected result:
x_default_handler
x_default_handler
Parse Test 5.0.0RC1 Done
Actual result:
--
Parse Test 5.0.0RC1
--
Edit this bug report at http://bugs.php.net/?id=27908&edit=1
#33648 [Asn->Fbk]: Using --with-regex=system causes compile failure
ID: 33648
Updated by: [EMAIL PROTECTED]
Reported By: ergin at ergin dot dyndns dot org
-Status: Assigned
+Status: Feedback
Bug Type: Compile Failure
Operating System: *
PHP Version: 5CVS, 4CVS (2005-07-18)
Assigned To: andrei
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:
[2005-07-15 13:03:31] [EMAIL PROTECTED]
This is not fixed yet. I added the necessary configure checks
and now HAVE_REGEX_T_RE_MAGIC is defined if re_magic exists in regext_t
struct.
Andrei: Please check it out.
[2005-07-14 22:25:38] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2005-07-12 15:41:55] [EMAIL PROTECTED]
Assigned to Andrei, he broke it.
As to the problem: remove --with-regex=system from your configure line
and it will work fine.
[2005-07-12 08:56:25] ergin at ergin dot dyndns dot org
Here is my configure line...
- START -
%configure \
--prefix=%{_prefix} \
--with-config-file-path=%{_sysconfdir} \
--enable-force-cgi-redirect \
--disable-debug \
--enable-pic \
--disable-rpath \
--enable-inline-optimization \
--with-dom=shared \
--with-bz2 \
--with-db3 \
--with-exec-dir=%{_bindir} \
--with-freetype-dir=%{_prefix} \
--with-gd \
--with-gdbm \
--with-gettext \
--with-gmp \
--with-jpeg-dir=%{_prefix} \
--with-mm \
--with-openssl \
--with-png \
--with-regex=system \
--with-ttf \
--with-xml \
--with-expat-dir=%{_prefix} \
--with-zlib \
--with-layout=GNU \
--enable-bcmath \
--enable-debugger \
--enable-ftp \
--enable-magic-quotes \
--enable-safe-mode \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-discard-path \
--enable-mime-magic \
--enable-track-vars \
--enable-trans-sid \
--enable-yp \
--enable-wddx \
--without-oci8 \
--with-iconv --enable-mbstring --enable-mbregex \
--with-imap=shared,/usr/local/src/imap-2002e --with-imap-ssl
--with-kerberos=/usr/kerberos \
--with-ldap=shared \
--with-mysql=shared,/usr \
--with-pgsql=shared \
--with-curl=shared \
--with-mcrypt=shared \
--with-snmp=%{_prefix} \
--with-snmp=shared \
--enable-ucd-snmp-hack \
--with-unixODBC=shared \
--with-xmlrpc=shared \
--with-mhash=shared \
--enable-memory-limit \
--enable-bcmath \
--enable-shmop \
--enable-versioning \
--enable-sockets --enable-pcntl --enable-sigchild \
$*
END --
[2005-07-11 22:38:14] ergin at ergin dot dyndns dot org
Description:
Got following message when I tried to build RPMS for new PHP version
php-4.4.0 (OBS!!! couldn't choose it from drop menu - PHP version)
.
Actual result:
--
/usr/src/redhat/BUILD/php-4.4.0/ext/standard/reg.c: In fucntion
'_php_regcomp':
/usr/src/redhat/BUILD/php-4.4.0/ext/standard/reg.c:53 structure has no
member named 're_magic'
/usr/src/redhat/BUILD/php-4.4.0/ext/standard/reg.c:72 structure has no
member named 're_magic'
make *** [ext/standard/reg.lo] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.66063
--
Edit this bug report at http://bugs.php.net/?id=33648&edit=1
#33286 [Opn]: nested array_walk function broken
ID: 33286
Updated by: [EMAIL PROTECTED]
Reported By: pumuckel at metropolis dot de
Status: Open
Bug Type: Arrays related
Operating System: Linux
PHP Version: 5.0.4
New Comment:
Can you provide a patch against HEAD? It seems that there are more uses
of BG() global that your patch doesn't cover.
Previous Comments:
[2005-06-10 09:35:18] pumuckel at metropolis dot de
Here is the patch for using a local cache var instead of a global.
In nested loops using the global cache var only the innermost
array_walk function can effectively make use of the cache. All
outermost loops can't because cache always got cleared from innermost
and therefor functions have to be relocated.
With local cache var this is not needed and we will get better
performance with big nested arrays.
Patch:
diff -urw php-5.0.4/ext/standard/array.c
php-5.0.4.patched/ext/standard/array.c
--- php-5.0.4/ext/standard/array.c 2005-03-12 11:12:49.0
+0100
+++ php-5.0.4.patched/ext/standard/array.c 2005-06-10
09:25:15.0 +0200
@@ -1008,6 +1008,7 @@
uint string_key_len;
ulong num_key;
HashPosition pos;
+zend_fcall_info_cache array_walk_fci_cache =
empty_fcall_info_cache;
/* Set up known arguments */
args[1] = &key;
@@ -1051,7 +1052,7 @@
fci.no_separation = 0;
/* Call the userland function */
- if (zend_call_function(&fci,
&BG(array_walk_fci_cache) TSRMLS_CC) == SUCCESS) {
+ if (zend_call_function(&fci,
&array_walk_fci_cache TSRMLS_CC) == SUCCESS) {
if (retval_ptr) {
zval_ptr_dtor(&retval_ptr);
}
@@ -1094,7 +1095,6 @@
HashTable *target_hash;
argc = ZEND_NUM_ARGS();
- BG(array_walk_fci_cache) = empty_fcall_info_cache;
old_walk_func_name = BG(array_walk_func_name);
if (argc < 2 || argc > 3 ||
zend_get_parameters_ex(argc, &array,
&BG(array_walk_func_name), &userdata) == FAILURE) {
@@ -1131,7 +1131,6 @@
argc = ZEND_NUM_ARGS();
old_walk_func_name = BG(array_walk_func_name);
- BG(array_walk_fci_cache) = empty_fcall_info_cache;
if (argc < 2 || argc > 3 ||
zend_get_parameters_ex(argc, &array,
&BG(array_walk_func_name), &userdata) == FAILURE) {
diff -urw php-5.0.4/ext/standard/basic_functions.h
php-5.0.4.patched/ext/standard/basic_functions.h
--- php-5.0.4/ext/standard/basic_functions.h2004-03-27
01:50:39.0 +0100
+++ php-5.0.4.patched/ext/standard/basic_functions.h2005-06-10
09:24:46.0 +0200
@@ -154,7 +154,6 @@
ulong strtok_len;
char str_ebuf[40];
zval **array_walk_func_name;
- zend_fcall_info_cache array_walk_fci_cache;
zval **user_compare_func_name;
zend_fcall_info_cache user_compare_fci_cache;
zend_llist *user_tick_functions;
[2005-06-09 19:35:48] pumuckel at metropolis dot de
Description:
Nested array_walk calls don't work.
Reason: BG(array_walk_fci_cache) will not get re-initialized after
inner array_walk call.
Following patch will help - better solution would be a local
array_walk_fci_cache var inside the php_walk_array function:
diff -u php-5.0.4/ext/standard/array.c
php-5.0.4.patched/ext/standard/array.c
--- php-5.0.4/ext/standard/array.c 2005-03-12 11:12:49.0
+0100
+++ php-5.0.4.patched/ext/standard/array.c 2005-06-09
19:31:43.0 +0200
@@ -1079,6 +1079,8 @@
}
zend_hash_move_forward_ex(target_hash, &pos);
}
+
+BG(array_walk_fci_cache) = empty_fcall_info_cache;
return 0;
}
Reproduce code:
---
";
}
function test_func($item2, $key)
{
echo "test_func";
$arr = array(1, 2, 3, 4);
array_walk($arr, 'test_subfunc', 'extra_arg');
}
$x = array(5,6,7);
array_walk($x, 'test_func');
?>
Expected result:
test_func
test_subfunc
test_subfunc
test_subfunc
test_subfunc
test_func
test_subfunc
test_subfunc
test_subfunc
test_subfunc
test_func
test_subfunc
test_subfunc
test_subfunc
test_subfunc
Actual result:
--
test_func
test_subfunc
test_subfunc
test_subfunc
test_subfunc
Warning: Missing argument 3 for test_subfunc() in foo.php on line 3
test_subfunc
test_subfunc
--
Edit this bug report at http://bugs.php.net/?id=33286&edit=1
#32091 [Asn->Csd]: PCRE 5.0 ugprade request
ID: 32091 Updated by: [EMAIL PROTECTED] Reported By: ceefour at gauldong dot net -Status: Assigned +Status: Closed Bug Type: Feature/Change Request Operating System: All PHP Version: 5.0.3 Assigned To: andrei New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-02-24 09:20:25] [EMAIL PROTECTED] Can you have a look at this for PHP 5.1 Andrei? [2005-02-24 04:53:55] ceefour at gauldong dot net Description: PCRE 5.0 is already out and ripe for grabbing. The most important feature is IMHO the ability to match general category properties of Unicode/UTF-8 strings, which is *VERY* useful for internationalized sites. I hope this will be implemented as soon as possible. Even an updated extension will be much better if it's not contained in the next release of PHP. -- Edit this bug report at http://bugs.php.net/?id=32091&edit=1
#32952 [Bgs]: CLI Crash
ID: 32952 User updated by: perciun dot andrei at gmail dot com Reported By: perciun dot andrei at gmail dot com Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows XP SP2 PHP Version: 5.0.4 New Comment: I tested with php as cgi and it is chrashing the php process without reporting an syntax error. Previous Comments: [2005-05-05 11:28:24] [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 No crash here, just a syntax error. Read the docs about ternary operator. [2005-05-05 10:11:15] perciun dot andrei at gmail dot com Description: CLI crash with expression. Reproduce code: --- $last = ($last == $next? null); Expected result: Should be correct if statement. -- Edit this bug report at http://bugs.php.net/?id=32952&edit=1
#32952 [NEW]: CLI Crash
From: perciun dot andrei at gmail dot com Operating system: Windows XP SP2 PHP version: 5.0.4 PHP Bug Type: Reproducible crash Bug description: CLI Crash Description: CLI crash with expression. Reproduce code: --- $last = ($last == $next? null); Expected result: Should be correct if statement. -- Edit bug report at http://bugs.php.net/?id=32952&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32952&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32952&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32952&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32952&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32952&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32952&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32952&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32952&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32952&r=support Expected behavior: http://bugs.php.net/fix.php?id=32952&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32952&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32952&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32952&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32952&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32952&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32952&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32952&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32952&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32952&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32952&r=mysqlcfg
#32345 [Csd]: php_cli.c fails to compile after being updated to version 1.118
ID: 32345 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Compile Failure Operating System: windows XP PHP Version: 5CVS-2005-03-16 (dev) Assigned To: andrei New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Fixed TSRM issue. Previous Comments: [2005-03-17 08:31:46] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2005-03-16 23:47:08] [EMAIL PROTECTED] Description: When compiling PHP with VC++ 7.0 on windows XP, I recieve the following error: c:\work\PHP-5-1\sapi\cli\php_cli.c(414) : error C2065: 'tsrm_ls' : undeclared identifier c:\work\PHP-5-1\sapi\cli\php_cli.c(414) : warning C4022: 'php_dl' : pointer mismatch for actual parameter 4 NMAKE : fatal error U1077: '"cl.exe"' : return code '0x2' Stop. By replacing the file with version 1.117, all compiles well. Reproduce code: --- compile it yourself and you'll see Expected result: should compile ok Actual result: -- throws an error -- Edit this bug report at http://bugs.php.net/?id=32345&edit=1
#27811 [Fbk->Opn]: Segmentation fault when xml_parse() used
ID: 27811
User updated by: andrei at vinchi dot ru
Reported By: andrei at vinchi dot ru
-Status: Feedback
+Status: Open
Bug Type: *XML functions
Operating System: Red Hat 7.2, SlackWare 9.0
PHP Version: 4.3.5
New Comment:
Here they are:
Program received signal SIGSEGV, Segmentation fault.
normal_updatePosition (enc=0x815f760,
ptr=0x821d560 "ONTENT-DATA-175 CONTENT-DATA-176 CONTENT-DATA-177
CONTENT-DATA-178 CONTENT-DATA-179 CONTENT-DATA-180 CONTENT-DATA-181
CONTENT-DATA-182 CONTENT-DATA-183 CONTENT-DATA-184 CONTENT-DATA-185
CONTENT-DATA-1"...,
end=0x821b888
" DESCRIPTION-1 DESCRIPTION-2 DESCRIPTION-3 DESCRIPTION-4 DESCRIPTION-5 DESCRIPTION-6 DESCRIPTION-7 DESCRIPTION-8 DESCRIPTION-9 DESCRIPTION-10 DES"...,
pos=0x8214ff8)
at
/andrei/php/build/php4-STABLE-200404010630/ext/xml/expat/xmltok_impl.c:1747
1747switch (BYTE_TYPE(enc, ptr)) {
That's all. May be you need something else?
The CGI version (not only cgi, but apache module too) of PHP supplayed
with SlackWare 9.0 has this bug. It can be used for check.
Previous Comments:
[2004-04-01 03:16:25] [EMAIL PROTECTED]
Can you add the info of the crash (the few lines above the "bt"
command) too?
----
[2004-04-01 02:56:52] andrei at vinchi dot ru
This is back trace in gdb.
(gdb) bt
#0 normal_updatePosition (enc=0x815f760,
ptr=0x821d560 "ONTENT-DATA-175 CONTENT-DATA-176 CONTENT-DATA-177
CONTENT-DATA-178 CONTENT-DATA-179 CONTENT-DATA-180 CONTENT-DATA-181
CONTENT-DATA-182 CONTENT-DATA-183 CONTENT-DATA-184 CONTENT-DATA-185
CONTENT-DATA-1"...,
end=0x821b888
" DESCRIPTION-1 DESCRIPTION-2 DESCRIPTION-3 DESCRIPTION-4 DESCRIPTION-5 DESCRIPTION-6 DESCRIPTION-7 DESCRIPTION-8 DESCRIPTION-9 DESCRIPTION-10 DES"...,
pos=0x8214ff8)
at
/andrei/php/build/php4-STABLE-200404010630/ext/xml/expat/xmltok_impl.c:1747
#1 0x08109bd8 in php_XML_GetCurrentLineNumber (parser=0x8214e70)
at
/andrei/php/build/php4-STABLE-200404010630/ext/xml/expat/xmlparse.c:1571
#2 0x081082af in zif_xml_get_current_line_number (ht=1,
return_value=0x8213bcc, this_ptr=0x0, return_value_used=1)
at /andrei/php/build/php4-STABLE-200404010630/ext/xml/xml.c:1431
#3 0x0814f011 in execute (op_array=0x820ef04) at
/andrei/php/build/php4-STABLE-200404010630/Zend/zend_execute.c:1626
#4 0x0813ee56 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /andrei/php/build/php4-STABLE-200404010630/Zend/zend.c:889
#5 0x0811d1b2 in php_execute_script (primary_file=0xba80)
at /andrei/php/build/php4-STABLE-200404010630/main/main.c:1731
#6 0x081570a8 in main (argc=2, argv=0xbb24) at
/andrei/php/build/php4-STABLE-200404010630/sapi/cli/php_cli.c:822
#7 0x40318507 in __libc_start_main (main=0x8156934 , argc=2,
ubp_av=0xbb24, init=0x8066b4c <_init>,
fini=0x81575d0 <_fini>, rtld_fini=0x4000dc14 <_dl_fini>,
stack_end=0xbb1c) at ../sysdeps/generic/libc-start.c:129
(gdb) frame 3
#3 0x0814f011 in execute (op_array=0x820ef04) at
/andrei/php/build/php4-STABLE-200404010630/Zend/zend_execute.c:1626
1626
((zend_internal_function *)
EX(function_state).function)->handler(EX(opline)->extended_value,
EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr,
return_value_used TSRMLS_CC);
[2004-04-01 02:16:44] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Post that backtrace then if you have one...
----
[2004-04-01 01:52:02] andrei at vinchi dot ru
I've just tried latest PHP snapshot too and see that the problem still
present. In the gdb the same line 1747 of file
php4-STABLE-200404010630/ext/xml/expat/xmltok_impl.c produce crash.
[2004-03-31 14:09:04] [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
I've just tried latest PHP snapshot and I do not see a
crash. However I do see XML errors after entry #19
which appear like this: XML parse error on 121 in 905
The remainder of the comments for thi
#27811 [Fbk->Opn]: Segmentation fault when xml_parse() used
ID: 27811 User updated by: andrei at vinchi dot ru Reported By: andrei at vinchi dot ru -Status: Feedback +Status: Open Bug Type: *XML functions Operating System: Red Hat 7.2, SlackWare 9.0 PHP Version: 4.3.5 New Comment: This is back trace in gdb. (gdb) bt #0 normal_updatePosition (enc=0x815f760, ptr=0x821d560 "ONTENT-DATA-175 CONTENT-DATA-176 CONTENT-DATA-177 CONTENT-DATA-178 CONTENT-DATA-179 CONTENT-DATA-180 CONTENT-DATA-181 CONTENT-DATA-182 CONTENT-DATA-183 CONTENT-DATA-184 CONTENT-DATA-185 CONTENT-DATA-1"..., end=0x821b888 " DESCRIPTION-1 DESCRIPTION-2 DESCRIPTION-3 DESCRIPTION-4 DESCRIPTION-5 DESCRIPTION-6 DESCRIPTION-7 DESCRIPTION-8 DESCRIPTION-9 DESCRIPTION-10 DES"..., pos=0x8214ff8) at /andrei/php/build/php4-STABLE-200404010630/ext/xml/expat/xmltok_impl.c:1747 #1 0x08109bd8 in php_XML_GetCurrentLineNumber (parser=0x8214e70) at /andrei/php/build/php4-STABLE-200404010630/ext/xml/expat/xmlparse.c:1571 #2 0x081082af in zif_xml_get_current_line_number (ht=1, return_value=0x8213bcc, this_ptr=0x0, return_value_used=1) at /andrei/php/build/php4-STABLE-200404010630/ext/xml/xml.c:1431 #3 0x0814f011 in execute (op_array=0x820ef04) at /andrei/php/build/php4-STABLE-200404010630/Zend/zend_execute.c:1626 #4 0x0813ee56 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /andrei/php/build/php4-STABLE-200404010630/Zend/zend.c:889 #5 0x0811d1b2 in php_execute_script (primary_file=0xba80) at /andrei/php/build/php4-STABLE-200404010630/main/main.c:1731 #6 0x081570a8 in main (argc=2, argv=0xbb24) at /andrei/php/build/php4-STABLE-200404010630/sapi/cli/php_cli.c:822 #7 0x40318507 in __libc_start_main (main=0x8156934 , argc=2, ubp_av=0xbb24, init=0x8066b4c <_init>, fini=0x81575d0 <_fini>, rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbb1c) at ../sysdeps/generic/libc-start.c:129 (gdb) frame 3 #3 0x0814f011 in execute (op_array=0x820ef04) at /andrei/php/build/php4-STABLE-200404010630/Zend/zend_execute.c:1626 1626 ((zend_internal_function *) EX(function_state).function)->handler(EX(opline)->extended_value, EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC); Previous Comments: [2004-04-01 02:16:44] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Post that backtrace then if you have one... -------- [2004-04-01 01:52:02] andrei at vinchi dot ru I've just tried latest PHP snapshot too and see that the problem still present. In the gdb the same line 1747 of file php4-STABLE-200404010630/ext/xml/expat/xmltok_impl.c produce crash. [2004-03-31 14:09:04] [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 I've just tried latest PHP snapshot and I do not see a crash. However I do see XML errors after entry #19 which appear like this: XML parse error on 121 in 905 ---- [2004-03-31 14:04:55] andrei at vinchi dot ru Description: xml_parse() function is using in script that parse xml data containing some " " strings. At this string it report an error, but after script is die and Apache process crash with notice in error_log: "[notice] child pid 27456 exit signal Segmentation Fault (11)". Config line: ./configure --prefix=/opt/php --with-apache=/usr/src/apache_1.3.27rusPL30.16 --with-zlib --with-bz2 --enable-bcmath --enable-calendar --with-readline --enable-exif --enable-wddx --enable-dba --with-gdbm --with-dbase --with-system-regex --with-mod_charset --with-pgsql=/usr/local/PostgreSQL --with-mysql=/usr/local/MySQL --enable-safe-mode --enable-track-vars --enable-memory-limit --disable-short-tags --disable-display-source --with-gd --enable-gd-native-ttf --with-freetype-dir --with-jpeg-dir --with-png-dir --with-xpm-dir --with-debug gdb: Program received signal SIGSEGV, Segmentation fault. normal_updatePosition (enc=0x815edc0, ptr=0x821ca78 "ONTENT-DATA-175 CONTENT-DATA-176 CONTENT-DATA-177 CONTENT-DATA-178 CONTENT-DATA-179 CONTENT-DATA-180 CONTENT-DATA-181 CONTENT-DATA-182 CONTENT-DATA-183 CONTENT-DATA-184 CONTENT
#27811 [Fbk->Opn]: Segmentation fault when xml_parse() used
ID: 27811
User updated by: andrei at vinchi dot ru
Reported By: andrei at vinchi dot ru
-Status: Feedback
+Status: Open
Bug Type: *XML functions
Operating System: Red Hat 7.2, SlackWare 9.0
PHP Version: 4.3.5
New Comment:
I've just tried latest PHP snapshot too and see that the problem still
present. In the gdb the same line 1747 of file
php4-STABLE-200404010630/ext/xml/expat/xmltok_impl.c produce crash.
Previous Comments:
[2004-03-31 14:09:04] [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
I've just tried latest PHP snapshot and I do not see a
crash. However I do see XML errors after entry #19
which appear like this: XML parse error on 121 in 905
[2004-03-31 14:04:55] andrei at vinchi dot ru
Description:
xml_parse() function is using in script that parse xml data containing
some " " strings. At this string it report an error, but after
script is die and Apache process crash with notice in error_log:
"[notice] child pid 27456 exit signal Segmentation Fault (11)".
Config line: ./configure --prefix=/opt/php
--with-apache=/usr/src/apache_1.3.27rusPL30.16 --with-zlib --with-bz2
--enable-bcmath --enable-calendar --with-readline --enable-exif
--enable-wddx --enable-dba --with-gdbm --with-dbase --with-system-regex
--with-mod_charset --with-pgsql=/usr/local/PostgreSQL
--with-mysql=/usr/local/MySQL --enable-safe-mode --enable-track-vars
--enable-memory-limit --disable-short-tags --disable-display-source
--with-gd --enable-gd-native-ttf --with-freetype-dir --with-jpeg-dir
--with-png-dir --with-xpm-dir --with-debug
gdb:
Program received signal SIGSEGV, Segmentation fault.
normal_updatePosition (enc=0x815edc0,
ptr=0x821ca78 "ONTENT-DATA-175 CONTENT-DATA-176 CONTENT-DATA-177
CONTENT-DATA-178 CONTENT-DATA-179 CONTENT-DATA-180 CONTENT-DATA-181
CONTENT-DATA-182 CONTENT-DATA-183 CONTENT-DATA-184 CONTENT-DATA-185
CONTENT-DATA-1"...,
end=0x821ada0
" DESCRIPTION-1 DESCRIPTION-2 DESCRIPTION-3 DESCRIPTION-4 DESCRIPTION-5 DESCRIPTION-6 DESCRIPTION-7 DESCRIPTION-8 DESCRIPTION-9 DESCRIPTION-10 DES"...,
pos=0x82144f0)
at /andrei/php/build/php-4.3.5/ext/xml/expat/xmltok_impl.c:1747
1747switch (BYTE_TYPE(enc, ptr)) {
(gdb)
Reproduce code:
---
1. http://na.vinchi.ru/mkfaultdata.php.txt
This script must be used for creating "bad.dat" file. It contain xml
data for parsing by second script that produce crash.
2. http://na.vinchi.ru/xml-crash.php.txt
Expected result:
The script must output 50 lines like this: "Indexing:
news_view.php?id=1". Last number changed from 1 to 50.
Actual result:
--
Indexing: news_view.php?id=1
... cuted ...
Indexing: news_view.php?id=19
XML parse error on 121 in 298
After that script and process dies.
--
Edit this bug report at http://bugs.php.net/?id=27811&edit=1
#27811 [NEW]: Segmentation fault when xml_parse() used
From: andrei at vinchi dot ru
Operating system: Red Hat 7.2, SlackWare 9.0
PHP version: 4.3.5
PHP Bug Type: *XML functions
Bug description: Segmentation fault when xml_parse() used
Description:
xml_parse() function is using in script that parse xml data containing
some " " strings. At this string it report an error, but after script
is die and Apache process crash with notice in error_log: "[notice] child
pid 27456 exit signal Segmentation Fault (11)".
Config line: ./configure --prefix=/opt/php
--with-apache=/usr/src/apache_1.3.27rusPL30.16 --with-zlib --with-bz2
--enable-bcmath --enable-calendar --with-readline --enable-exif
--enable-wddx --enable-dba --with-gdbm --with-dbase --with-system-regex
--with-mod_charset --with-pgsql=/usr/local/PostgreSQL
--with-mysql=/usr/local/MySQL --enable-safe-mode --enable-track-vars
--enable-memory-limit --disable-short-tags --disable-display-source
--with-gd --enable-gd-native-ttf --with-freetype-dir --with-jpeg-dir
--with-png-dir --with-xpm-dir --with-debug
gdb:
Program received signal SIGSEGV, Segmentation fault.
normal_updatePosition (enc=0x815edc0,
ptr=0x821ca78 "ONTENT-DATA-175 CONTENT-DATA-176 CONTENT-DATA-177
CONTENT-DATA-178 CONTENT-DATA-179 CONTENT-DATA-180 CONTENT-DATA-181
CONTENT-DATA-182 CONTENT-DATA-183 CONTENT-DATA-184 CONTENT-DATA-185
CONTENT-DATA-1"...,
end=0x821ada0
" DESCRIPTION-1 DESCRIPTION-2 DESCRIPTION-3 DESCRIPTION-4 DESCRIPTION-5 DESCRIPTION-6 DESCRIPTION-7 DESCRIPTION-8 DESCRIPTION-9 DESCRIPTION-10 DES"...,
pos=0x82144f0)
at /andrei/php/build/php-4.3.5/ext/xml/expat/xmltok_impl.c:1747
1747switch (BYTE_TYPE(enc, ptr)) {
(gdb)
Reproduce code:
---
1. http://na.vinchi.ru/mkfaultdata.php.txt
This script must be used for creating "bad.dat" file. It contain xml data
for parsing by second script that produce crash.
2. http://na.vinchi.ru/xml-crash.php.txt
Expected result:
The script must output 50 lines like this: "Indexing: news_view.php?id=1".
Last number changed from 1 to 50.
Actual result:
--
Indexing: news_view.php?id=1
... cuted ...
Indexing: news_view.php?id=19
XML parse error on 121 in 298
After that script and process dies.
--
Edit bug report at http://bugs.php.net/?id=27811&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27811&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27811&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27811&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27811&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27811&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27811&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27811&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27811&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27811&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27811&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27811&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27811&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27811&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27811&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27811&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27811&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27811&r=float
#25124 [Ver]: overload() messes with array member variables
ID: 25124
Updated by: [EMAIL PROTECTED]
Reported By: ian at ardes dot com
Status: Verified
Bug Type: Class/Object related
Operating System: *
PHP Version: 4CVS-2004-02-11
New Comment:
Overloading of array indexes is not supported. This is expected
behavior.
Previous Comments:
[2003-08-18 02:34:02] ian at ardes dot com
Description:
Summary: When a class is overloaded with overload(),
array member variables go wrong.
If you overload a class, then access to declared array
member variables from within member functions (and
anywhere else I think) stops working correctly.
The very simple class in the code should not change
it's behaviour at all once it is overloaded. But it
does.
Reproduce code:
---
class Overloaded {
var $_my_array = array();
function Overloaded() {
$this->_my_array[1] = '1st element';
}
function __get($nm, &$val) {
return false;
}
function __set($nm, $val) {
return false;
}
}
$o1 = new Overloaded();
print ("before overload(): "); print_r($o1);
overload('Overloaded');
$o2 = new Overloaded();
print ("after overload(): "); print_r($o2);
Expected result:
before overload(): overloaded Object
(
[_my_array] => Array
(
[1] => 1st element
)
)
after overload(): overloaded Object
(
[_my_array] => Array
(
[1] => 1st element
)
)
Actual result:
--
before overload(): overloaded Object
(
[_my_array] => Array
(
[1] => 1st element
)
)
after overload(): overloaded Object
(
[_my_array] => 1st element
)
--
Edit this bug report at http://bugs.php.net/?id=25124&edit=1
#26854 [Opn->Bgs]: Using ! as a delimiter for regexps will not allow neg. lookahead assertions
ID: 26854
Updated by: [EMAIL PROTECTED]
Reported By: chris_se at gmx dot net
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: Linux
PHP Version: 4.3.4
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
Use a different delimiter instead. The library does not remove
backslashes before delimiters and PCRE doesn't know what to do with
(?\\!).
Previous Comments:
[2004-01-09 12:39:04] chris_se at gmx dot net
Description:
When I try to use ! as delimiter and use a negative lookahead assertion
which is normally started with (?!, (?! of course does not work,
because the ! will terminate the pattern (and PHP will of course
complain). But when I try to escape the exclamation mark like (?\!, an
error occurs.
I assume the \ is not removed in front of the ! after the pattern is
freed from its delimiters.
Reproduce code:
---
$res = preg_match ("!^(?\\!foo)[a-z]{3}$!", "bar");
Expected result:
$res contains true
Actual result:
--
Warning: Compilation failed: unrecognized character after (? at offset
3 in /home/christian/- on line 2
--
Edit this bug report at http://bugs.php.net/?id=26854&edit=1
#26219 [Bgs]: Segmentation fault using regexp in php versions later than 4.3.3RC1
ID: 26219
Updated by: [EMAIL PROTECTED]
Reported By: peter at normann dot com
Status: Bogus
Bug Type: Regexps related
Operating System: Linux kernel 2.5.74
PHP Version: 4.3.4
New Comment:
Could not reproduce with the latest PCRE library version 4.5.
Previous Comments:
[2003-11-12 13:00:37] [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.
I can verify the crash, however the crash is not the result of PHP code
but rather due to a bug in the pcre library. Please report this bug to
the maintainers of the pcre library.
[2003-11-12 11:24:19] peter at normann dot com
It's rather lengthy, but I have provided it at
http://www.normann.com/bug/buggy.txt
Also, the whole function can be found at
http://www.normann.com/bug/bug_code.txt
Thank you for taking your time...
[2003-11-12 11:00:03] [EMAIL PROTECTED]
Please provide sample of source text on which the regex operates.
[2003-11-12 09:46:00] peter at normann dot com
Description:
php crashes when using the preg_match function. Code included below.
Works in php4.3.3RC1 but any later version causes segmentation fault.
The code is part of a text filter.
$output contains text with plain text and html mixed. The idea is
anything between [html] and [/html] will go untouched by the filter.
I use dozens of other regular expressions, but preg_match is a sure
killer. I can easily reproduce this behavior.
Reproduce code:
---
while (preg_match('/\[html]((.|\s)+?)\[\/html]/', $output, $htmlshow))
$output = str_replace($htmlshow[0], str_replace('', '',
strtr($htmlshow[1],
array_flip(get_html_translation_table(HTML_ENTITIES, $output);
Actual result:
--
child pid x exit signal Segmentation fault (11)
--
Edit this bug report at http://bugs.php.net/?id=26219&edit=1
#23946 [Asn->Bgs]: [ep]reg_replace "z?$" with "a" in "xyz" yields "xyaa" instead of "xya"
ID: 23946
Updated by: [EMAIL PROTECTED]
Reported By: stuge-phpbugs at cdy dot org
-Status: Assigned
+Status: Bogus
Bug Type: *Regular Expressions
Operating System: Linux
PHP Version: 4.3.2
Assigned To: andrei
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 creator of PCRE and I agree: if this is what Perl does, then PHP
should do the same as to avoid confusion, because the current PCRE
support has been predicated on Perl compatibility.
Previous Comments:
[2003-06-07 04:45:07] [EMAIL PROTECTED]
Andrei, any opinions about the patches..?
[2003-06-06 21:09:17] stuge-phpbugs at cdy dot org
Ok. This patch works in that it gives me the expected results. I
modified it slightly to care less about bytes in the string and more
about the length variables, that way it's at least widechar-prepared.
Woo-hoo! :)
Currently running make test.. All reg tests PASS, I've also added a
test for this bug.
Here's the patch against current CVS:
---8<---
diff -ur php4.cvs/ext/pcre/php_pcre.c php4.new/ext/pcre/php_pcre.c
--- php4.cvs/ext/pcre/php_pcre.c2003-06-07 03:51:13.0
+0200
+++ php4.new/ext/pcre/php_pcre.c2003-06-07 03:52:02.0
+0200
@@ -797,7 +797,7 @@
*result_len = 0;
start_offset = 0;
- while (1) {
+ do {
/* Execute the regular expression. */
count = pcre_exec(re, extra, subject, subject_len,
start_offset,
exoptions|g_notempty,
offsets,
size_offsets);
@@ -933,7 +933,7 @@
/* Advance to the next piece. */
start_offset = offsets[1];
- }
+ } while(start_offset < subject_len);
efree(offsets);
diff -ur php4.cvs/ext/standard/reg.c php4.new/ext/standard/reg.c
--- php4.cvs/ext/standard/reg.c 2003-06-07 03:49:19.0 +0200
+++ php4.new/ext/standard/reg.c 2003-06-07 03:50:43.0 +0200
@@ -302,7 +302,7 @@
err = pos = 0;
buf[0] = '\0';
- while (!err) {
+ do {
err = regexec(&re, &string[pos], re.re_nsub+1, subs,
(pos ? REG_
NOTBOL : 0));
if (err && err != REG_NOMATCH) {
@@ -396,7 +396,7 @@
/* stick that last bit of string on our output
*/
strcat(buf, &string[pos]);
}
- }
+ } while(!err && pos < string_len);
/* don't want to leak memory .. */
efree(subs);
--->8---
And ext/standard/tests/reg/017.phpt:
---8<---
--TEST--
empty expression replaced extra time at end-of-string
--POST--
--GET--
--FILE--
--EXPECT--
xya
--->8---
I make no warranties whatsoever that this will not break things,
although I don't think it should. :)
[2003-06-06 20:34:53] stuge-phpbugs at cdy dot org
$ echo xyz|perl -e 'while() { $_=~ s/z?$/a/;print}'
xya
$ echo xyz|perl -e 'while() { $_=~ s/z?$/a/g;print}'
xyaa
a$ echo xyz|sed -e 's/z\?$/a/g'
xya
$ echo xyz|sed -e 's/z\?$/a/'
xya
perl and sed both behave the way I would expect.
[ep]reg_replace() don't. :)
A comment from php.net/manual/en/pcre.pattern.modifiers.php:
/g is default in PHP. You don't need to set it.
preg_replace() similarity with perl may not be desired, I only included
it because it showed the exact same behaviour while using a different
regex code base, indicating the same algorithm.
I believe Andrei's comment in 23903 is a bit quick, at least if this is
a dupe, which I would say it is.
Again, I believe the error to be that the regexp is "ran" one extra
time after all of the input string has already been matched and
processed inside [ep]reg_replace().
Because of this, any regexp that matches the empty string will cause
one extra replacement to occur at the end of the input string.
At least inside ereg_replace() the loop should just quit if the entire
string has been processed after the first iteration.
I'll try my patch and recomment.
[2003-06-03 12:59:57] [EMAIL PROTECTED]
Verified with 4.3.2 (and 4.3.1 and 4.2.3). Similar to #23903, but here
I see why you want to use [ep]reg_replace.
[2003-06-01 22:38:09] stuge-phpbugs at cdy dot org
Verified with 4.3.0 and 4.3.2rc2 but haven't tried 4.3.2. NEWS for
4.3.2 do not mention any *re
#23860 [Opn->Fbk]: published regexp not working: ^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{4,8}$
ID: 23860
Updated by: [EMAIL PROTECTED]
Reported By: jbarwick at sentienthealth dot com
-Status: Open
+Status: Feedback
Bug Type: PCRE related
Operating System: Linux GlibC 2.1
PHP Version: 4.3.1
New Comment:
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.
Please submit a short piece of code reproducing the issue.
Previous Comments:
[2003-05-28 12:30:08] jbarwick at sentienthealth dot com
Very interesting problem...this published regexp:
^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{4,8}$
was working with my PHP4.3.0 on Win32 platform
and on 4.3.0 on RedHat8.0 (all RH patches installed).
However, this regexp is NOT working on RedHat 9
with Apache 2.0. Any ideas why?
Gives REG_BADRPT messageSimple regexp's DO work.
This regexp compiles if you remove the ?'s (but of
course...will not do what I want it to!)...and of course
the string is:
$regexp="^(?=.*\\d)(?=.*[a-z])(?=.*[A-Z]).{4,8}\$";
taken directly from http://regexlib.com
BTW: libiconv 1.8 is installed. mbstring is loaded
and all encodings are set to UTF8...yes, ereg is not 8 bit safe...know
that...hope this ain't the problem.
4.3.1 was compiled with --with-regex=system...however, it appears to
use "bundled" regexp anyway. (tried with regex=php and
regex=system...both produce same results..ie. used bundled regexp
library).
this is NOT an Apache problemphp CGI version produces same
results...even though somewhere in the depths I read "php must be
compiled with the same regexp version as apache if php loaded as
module". I hear what this is saying, but I don't understand how to
determine this...and, like I said...CGI version produces same result.
Mayble I'll try --with-regexp=apache...see what happens...
If this is the same thing as Bug #1683...sorry...please combine with
that onebut...I'm not sure it's the same.
any response may be helpful...HLP!
--
Edit this bug report at http://bugs.php.net/?id=23860&edit=1
#23904 [Opn->Bgs]: PREG_SPLIT_NO_EMPTY causes ctl chars to not be excluded with [^a-zA-Z0-9] or \W
ID: 23904
Updated by: [EMAIL PROTECTED]
Reported By: jrose at lgb-inc dot com
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: Linux
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
Please read the function documentation. The third parameter is a
maximum number of pieces to be returned, not the flags. Try:
$parts = preg_split( '/\\W/', $string, -1, PREG_SPLIT_NO_EMPTY );
Previous Comments:
[2003-05-30 13:10:32] jrose at lgb-inc dot com
I slammed into this whilst converting Access data into MySQL.
I was attempting to break apart the following into words (* here
indicates that it fails to match /[\w,.-?]/):
|*|W|a|s|h|i|n|g|t|o|n|,|*|D|C|*|* // text
057617368696e67746f6e2c20444320200 // hex
I first tried splitting on any white space or commas:
preg_match( '/[\\s,]+/', $string, PREG_SPLIT_NO_EMPTY );
When this didn't work, I examined the hexadecimal values as above, and,
assuming that control characters weren't included in the \s group,
tried several things, including the very simple:
preg_match( '/\\W/', $string, PREG_SPLIT_NO_EMPTY );
Nothing worked, and ultimately I had to use preg_match_all() to split
the string up.
Example:
$string = chr(5) . 'Washington,' . chr(4) . 'DC' . chr(2);
$parts = preg_split( '/\\W/', $string, PREG_SPLIT_NO_EMPTY );
echo join('|', $parts);
--
Edit this bug report at http://bugs.php.net/?id=23904&edit=1
#23038 [Asn->Csd]: aggregate() leaks causing apache to segfault
ID: 23038
Updated by: [EMAIL PROTECTED]
Reported By: black at sunshine dot krneki dot org
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: linux debian
PHP Version: 4.3.2-RC
Assigned To: andrei
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-05-23 11:14:44] hewei at ied dot org dot cn
This short script can reproduce the aggregation bug I reported above.
class bar {
function doit()
{
print " Doing...\n";
}
}
class foo {
function foo()
{
print_r(aggregation_info($this));
aggregate($this, "bar");
}
function spawn()
{
return new foo();
}
}
$a = new foo();
$a->doit();
$b = $a->spawn();
$b->doit();
unset($a);
$c = $b->spawn();
$c->doit();
Besides 'unset($a)', '$a = new foo()' will also cause the same problem.
[2003-05-01 01:31:02] hewei at ied dot org dot cn
Similar problem happens to me. I either cannot reproduce the
situation because sometimes changing a irrelevant place will temporaily
wipe the problem away. But it will come back at an unexpected time.
The problem once caused Apache 2.0 crashing on Win32. But after some
irrelevant code restructuring, it now casues
error like this:
Fatal error: Call to undefined function: foo() in /path/bar.php on line
xxx
But foo() is surely an aggregated method. The strange but perhaps
useful point is that a print_r of aggregation_info() at the bug place
shows the function dose exists. Even I add the following codes the
error still exists:
if (!method_exists($this, "foo")) {
deaggregate($this, "CLASS_having_method_foo");
aggregate($this, "CLASS_having_method_foo");
}
This problem really stops me from doing any futher coding.
I tried ZendSafeGard, upgraded to the 4.3.2RC2, changed from Apache
module to CGI, and moved from Windows to Linux(RedHat 9.0). But none
seems to imporve the situation.
Since the problem is not easily reproduced outside my complex class
hierarchy, please instruct me of any other debug information I can
print out at the bug place. And because the PHP I'm using is
recompiled, I would even like to try do source codes debugging.
[2003-04-06 16:22:40] [EMAIL PROTECTED]
just letting you know that its been a week now with not a single crash
after removing aggregate - contact me when/if you want/need the db
dump and code dump to analyze this/test it.
[2003-04-03 19:45:12] [EMAIL PROTECTED]
.
[2003-04-03 15:38:50] [EMAIL PROTECTED]
according to http://snaps.php.net there is?
and yeah, i guess you could mark it as bogus, as far as "simple"
scripts go, i doubt i could ever reproduce this in a simple one.. even
the collection of code i use has about 170k just core files (and its
clean non bloated code if you believe it ;))..
the best i can do is give you a cvs snapshot of a week ago when the
bug was still occuring.. after i removed aggregate i havent had a
crash..
as for my debugging knowledge goes, its pretty much what i gathered
from this page, and you cant really expect me to master gdb and
valgrind without experience with any of them before.
if you want to give it a shot then by all means, im willing to give you
everything that is in my power to do so, a short example script
however, is not.
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=23038&edit=1
#23574 [Ver->Csd]: Wrong behaviour and crash of aggregate subsystem
ID: 23574
Updated by: [EMAIL PROTECTED]
Reported By: michael at gostev dot name
-Status: Verified
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: Linux RedHat 7.2
PHP Version: 4CVS-2003-05-10 (stable)
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-05-10 11:35:07] michael at gostev dot name
Here is sample script:
id=++$nCount;
return $n;
}
}
function makeBNode()
{
$b=new B();
return $b->newNode();
}
$bn1=makeBNode();
print_r( $bn1 );
$bn2=$bn1->newNode();
print_r( $bn2 );
unset($bn2); // Comment/uncomment this line to get interesting
result
$bn3=$bn1->newNode();
print_r($bn3);
print_r($bn3->newNode());
?>
produce following result:
[EMAIL PROTECTED] garb]# /usr/local/php_ss/bin/php aggregate.php
node Object
(
[id] => 1
)
node Object
(
[id] => 2
)
node Object
(
[id] => 3
)
node Object
(
[id] => 4
)
Segmentation fault (core dumped)
Here is information from gdb:
(gdb) where
#0 0x4013fc90 in chunk_free (ar_ptr=0x401f3620, p=0x81dac50) at
malloc.c:3231
#1 0x4013fbf4 in __libc_free (mem=0x81db430) at malloc.c:3154
#2 0x081171ac in shutdown_memory_manager (silent=0, clean_cache=0,
tsrm_ls=0x817d0c0)
at
/home/mike/Software/php4-STABLE-200305101330/Zend/zend_alloc.c:492
#3 0x080faa3e in php_request_shutdown (dummy=0x0) at
/home/mike/Software/php4-STABLE-200305101330/main/main.c:996
#4 0x08144680 in main (argc=2, argv=0xba64) at
/home/mike/Software/php4-STABLE-200305101330/sapi/cli/php_cli.c:843
#5 0x400db507 in __libc_start_main (main=0x8143884 , argc=2,
ubp_av=0xba64, init=0x80614b4 <_init>,
fini=0x8144b00 <_fini>, rtld_fini=0x4000dc14 <_dl_fini>,
stack_end=0xba5c) at ../sysdeps/generic/libc-start.c:129
One more issue. If comment line #34: unset($bn2);
We got following unexpected result:
[EMAIL PROTECTED] garb]# /usr/local/php_ss/bin/php aggregate.php
node Object
(
[id] => 1
)
node Object
(
[id] => 2
)
node Object
(
[id] => 3
)
Fatal error: Call to undefined function: newnode() in
/var/www/html/Kiss/garb/aggregate.php on line 38
Segmentation fault (core dumped)
Auxiliary information about system:
[EMAIL PROTECTED] garb]# /usr/local/php_ss/bin/php -r 'phpinfo();'
phpinfo()
PHP Version => 4.3.2-RC3-dev
System => Linux RAMM 2.4.20 #2 Sat Feb 1 17:42:27 MSK 2003 i686
Build Date => May 10 2003 19:00:42
Configure Command => './configure' '--prefix=/usr/local/php_ss'
'--with-apxs2=/usr/local/apache2/bin/apxs'
'--with-config-file-path=/etc'
Server API => Command Line Interface
Virtual Directory Support => enabled
Configuration File (php.ini) Path => /etc
PHP API => 20020918
PHP Extension => 20020429
Zend Extension => 20021010
Debug Build => no
Thread Safety => enabled
Registered PHP Streams => php, http, ftp
This program makes use of the Zend Scripting Language Engine:
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies
___
Configuration
PHP Core
Directive => Local Value => Master Value
allow_call_time_pass_reference => On => On
allow_url_fopen => On => On
always_populate_raw_post_data => Off => Off
arg_separator.input => & => &
arg_separator.output => & => &
asp_tags => Off => Off
auto_append_file => no value => no value
auto_prepend_file => no value => no value
browscap => no value => no value
default_charset => no value => no value
default_mimetype => text/html => text/html
define_syslog_variables => Off => Off
disable_classes => no value => no value
disable_functions => no value => no value
display_errors => On => On
display_startup_errors => Off => Off
doc_root => no value => no value
docref_ext => no value => no value
docref_root => no value => no value
enable_dl => On => On
error_append_string => no value => no value
error_log => no value => no value
error_prepend_string => no value => no value
error_reporting => no value => no value
expose_php => On => On
extension_dir =>
/usr/local/php_ss/lib/php/extensions/no-debug-zts-20020429 =>
/usr/local/php_ss/lib/php/extensions/no-debug-zts-20020429
file_uploads => On => On
gpc_order => GPC => GPC
highlight.bg => #FF => #FF
highlight.comment => #FF8000 => #FF8000
highlight.default => #BB => #BB
highlight.html => #00 => #00
highlight.keyword => #007700 => #007700
highlight.string => #DD => #DD
html_errors => Off => On
ignore_re
#20109 [Ctl->Ver]: iplanet 6 core dump w/NSAPI load
ID: 20109 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Verified Bug Type: iPlanet related Operating System: Solaris 9 PHP Version: 4.3.0-dev, php4-STABLE-20021116 Previous Comments: [2002-11-21 22:57:08] [EMAIL PROTECTED] Added 4.3.0-dev to version. [2002-11-16 13:09:18] [EMAIL PROTECTED] Updated to iPlanet-WebServer-Enterprise/6.0SP5 and tried php4-STABLE-200211161630. Same crash, no change. [16/Nov/2002:14:07:33] catastrophe (22765): Server crash detected (signal SIGBUS) [16/Nov/2002:14:07:33] info (22765): Crash occurred in NSAPI SAF php4_execute [16/Nov/2002:14:07:33] info (22765): Crash occurred in function php_register_variable_ex from module /usr/iplanet/servers/bin/libphp4.so [2002-11-02 14:11:14] [EMAIL PROTECTED] As much as I don't like nsapi, we can't have it not working for 4.3.0 release... since it has historically worked (sometimes). [2002-10-27 08:49:16] [EMAIL PROTECTED] Tried php4-200210262100, same crash, same backtrace. Crash: [27/Oct/2002:09:45:07] catastrophe (29972): Server crash detected (signal SIGBUS) [27/Oct/2002:09:45:07] info (29972): Crash occurred in NSAPI SAF php4_execute [27/Oct/2002:09:45:07] info (29972): Crash occurred in function php_register_variable_ex from module /usr/iplanet/servers/bin/libphp4.so [27/Oct/2002:09:45:12] failure (29957): Child process admin thread is shutting down Backtrace: #0 0xfe629ccc in php_register_variable_ex (var=0xfe6c05c0 "REQUEST_LINE", val=0xfda5f6b8, track_vars_array=0xfe6c05c0, tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/main/php_variables.c:176 #1 0xfe62988c in php_register_variable_safe (var=0xfe6c05c0 "REQUEST_LINE", strval=0xc722f0 "GET /phpinfo.php HTTP/1.1", str_len=25, track_vars_array=0x35a6d8, tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/main/php_variables.c:56 #2 0xfe6297a4 in php_register_variable (var=0xfe6c05c0 "REQUEST_LINE", strval=0xc722f0 "GET /phpinfo.php HTTP/1.1", track_vars_array=0x35a6d8, tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/main/php_variables.c:37 #3 0xfe678e10 in sapi_nsapi_register_server_variables ( track_vars_array=0x35a6d8, tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/sapi/nsapi/nsapi.c:290 #4 0xfe61e7b4 in php_hash_environment (tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/main/main.c:1220 #5 0xfe61d278 in php_request_startup (tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/main/main.c:857 #6 0xfe679590 in nsapi_module_main (request_context=0xc72d60, tsrm_ls=0x1792d8) at /home/cjs/work/php4-200210262100/sapi/nsapi/nsapi.c:460 #7 0xfe679768 in php4_execute (pb=0xc3f88, sn=0xc36a48, rq=0xc36a90) at /home/cjs/work/php4-200210262100/sapi/nsapi/nsapi.c:525 #8 0xff1d89b4 in __0FNfunc_exec_strP6KFuncStructP6GpblockP6HSessionP6HRequest () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #9 0xff1d9cf8 in INTobject_execute () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #10 0xff1dd8e8 in INTservact_service () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #11 0xff1dde84 in INTservact_handle_processed () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #12 0xff215c0c in __0fLHttpRequestUUnacceleratedRespondPCcTBPc () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #13 0xff2150c0 in __0fLHttpRequestNHandleRequestP6Gnetbuf () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #14 0xff213388 in __0fNDaemonSessionDrunv () from /usr/iplanet/servers/bin/https/lib/libns-httpd40.so #15 0xff163b80 in ThreadMain () from /usr/iplanet/servers/bin/https/lib/libnsprwrap.so #16 0xfede76a0 in _pt_root () from /usr/iplanet/servers/bin/https/lib/libnspr4.so [2002-10-26 17:01:52] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip I've just commited a patch to the CVS that may address the problem you are seeing. 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/20109 -- Edit this bug report at http://bugs.php.net/?id=20109&edit=1
#15209 [Ctl->Ver]: Under Apache, register_shutdown_function() broke between 4.0.x to 4.1.x
ID: 15209 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Verified Bug Type: Scripting Engine problem Operating System: RH Linux 7.2 PHP Version: 4.3.0-dev New Comment: Changing to 'Verified', since there is some disagreement on how this function should operate. Previous Comments: [2002-10-12 10:21:46] [EMAIL PROTECTED] Marking as critical since this worked at some point. And there was also posting by [EMAIL PROTECTED] with a possible fix on [EMAIL PROTECTED] [2002-10-04 07:44:12] [EMAIL PROTECTED] I grabbed a snapshot today (php4-200210040300). I jtate's script, and still got the erroneous (IMO) behavior. My connection to the server did not close until the shutdown function completed. Looking at the suspect section of sapi_apache.c, I do not see any changes. Not that I expected to see my patch verbatim, but I would expect something in that vicinity to change. [2002-10-02 10:33:06] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-02 09:35:00] [EMAIL PROTECTED] Is this really a dupe of 14251? Maybe they involve some of the same code, but these are really two different issues. 14251 involves the fact that the shutdown function code gets a different working directory. 15209 concerns whether the shutdown function runs before or after the HTTP connection is closed. [2002-10-01 06:04:16] [EMAIL PROTECTED] Dup of #14251 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/15209 -- Edit this bug report at http://bugs.php.net/?id=15209&edit=1
#19482 [Opn->Csd]: segfault on child process
ID: 19482 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: PCRE related Operating System: Redhat 7.3 PHP Version: 4.2.3,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: [2002-10-07 11:44:06] [EMAIL PROTECTED] I applied the patch to php4-200209191800 (the newest snapshot died with some other unrelated problem) and ran my normal tests. Looked like this fixed it! I went through 174 emails with IE and had no segfaults. Thanks for everyone's help in solving this problem and continue with the good work. [2002-10-07 11:16:59] [EMAIL PROTECTED] Please try this patch and report back: RCS file: /repository/php4/ext/pcre/php_pcre.c,v retrieving revision 1.128 diff -u -2 -b -w -B -r1.128 php_pcre.c --- ext/pcre/php_pcre.c 11 Sep 2002 14:41:25 - 1.128 +++ ext/pcre/php_pcre.c 7 Oct 2002 16:05:59 - @@ -67,4 +67,5 @@ #if HAVE_SETLOCALE if ((void*)pce->tables) pefree((void*)pce->tables, 1); + pefree(pce->locale, 1); #endif } @@ -303,5 +304,5 @@ new_entry.preg_options = poptions; #if HAVE_SETLOCALE - new_entry.locale = locale; + new_entry.locale = pestrdup(locale, 1); new_entry.tables = tables; #endif [2002-10-06 22:41:36] [EMAIL PROTECTED] I tried with the newest snapshot but I get the following backtrace (gdb) run -X -DSSL -f /usr/local/apache/conf/httpd.conf Starting program: /usr/local/apache/bin/httpd -X -DSSL -f /usr/local/apache/conf/httpd.conf Program received signal SIGSEGV, Segmentation fault. 0x403d2e94 in _efree (ptr=0x0) at /usr/local/software/php4-200210061800/Zend/zend_alloc.c:211 211 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size); (gdb) bt #0 0x403d2e94 in _efree (ptr=0x0) at /usr/local/software/php4-200210061800/Zend/zend_alloc.c:211 #1 0x403e5b8e in zend_hash_destroy (ht=0x82ea824) at /usr/local/software/php4-200210061800/Zend/zend_hash.c:550 #2 0x403e063a in _zval_dtor (zvalue=0x81802ec) at /usr/local/software/php4-200210061800/Zend/zend_variables.c:51 #3 0x403f1206 in execute (op_array=0x82d130c) at /usr/local/software/php4-200210061800/Zend/zend_execute.c:449 #4 0x403f411a in execute (op_array=0x82182e4) at /usr/local/software/php4-200210061800/Zend/zend_execute.c:1641 #5 0x403e1adc in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/software/php4-200210061800/Zend/zend.c:834 #6 0x403bbfed in php_execute_script (primary_file=0xb6d0) at /usr/local/software/php4-200210061800/main/main.c:1542 #7 0x403fb4b6 in apache_php_module_main (r=0x816c9e0, display_source_mode=0) at /usr/local/software/php4-200210061800/sapi/apache/sapi_apache.c:55 #8 0x403fbfd6 in send_php (r=0x816c9e0, display_source_mode=0, filename=0x0) at /usr/local/software/php4-200210061800/sapi/apache/mod_php4.c:564 #9 0x403fc02a in send_parsed_php (r=0x816c9e0) at /usr/local/software/php4-200210061800/sapi/apache/mod_php4.c:579 #10 0x0806bdcf in ap_invoke_handler () #11 0x08080e53 in process_request_internal () #12 0x08080eb4 in ap_process_request () ---Type to continue, or q to quit--- #13 0x08077df1 in child_main () #14 0x08077fc0 in make_child () #15 0x08078134 in startup_children () #16 0x080787ac in standalone_main () #17 0x0807902b in main () #18 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 [2002-10-06 19:08:49] [EMAIL PROTECTED] Note sure if this will be useful, but if i edit main/php_config.h (after running ./configure) and remove all LOCALE defines, here's a backtrace of the segfault: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 6702)] 0x403d6c67 in _zval_dtor (zvalue=0x82ad344, __zend_filename=0x40432520 "/tmp/php-debug/Zend/zend_execute_API.c", __zend_lineno=291) at /tmp/php-debug/Zend/zend_variables.c:43 43 CHECK_ZVAL_STRING_REL(zvalue); (gdb) bt #0 0x403d6c67 in _zval_dtor (zvalue=0x82ad344, __zend_filename=0x40432520 "/tmp/php-debug/Zend/zend_execute_API.c", __zend_lineno=291) at /tmp/php-debug/Zend/ze
#19482 [Opn]: segfault on child process
ID: 19482 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: PCRE related Operating System: Redhat 7.3 PHP Version: 4.2.3,4.3.0-dev New Comment: Please try this patch and report back: RCS file: /repository/php4/ext/pcre/php_pcre.c,v retrieving revision 1.128 diff -u -2 -b -w -B -r1.128 php_pcre.c --- ext/pcre/php_pcre.c 11 Sep 2002 14:41:25 - 1.128 +++ ext/pcre/php_pcre.c 7 Oct 2002 16:05:59 - @@ -67,4 +67,5 @@ #if HAVE_SETLOCALE if ((void*)pce->tables) pefree((void*)pce->tables, 1); + pefree(pce->locale, 1); #endif } @@ -303,5 +304,5 @@ new_entry.preg_options = poptions; #if HAVE_SETLOCALE - new_entry.locale = locale; + new_entry.locale = pestrdup(locale, 1); new_entry.tables = tables; #endif Previous Comments: [2002-10-06 22:41:36] [EMAIL PROTECTED] I tried with the newest snapshot but I get the following backtrace (gdb) run -X -DSSL -f /usr/local/apache/conf/httpd.conf Starting program: /usr/local/apache/bin/httpd -X -DSSL -f /usr/local/apache/conf/httpd.conf Program received signal SIGSEGV, Segmentation fault. 0x403d2e94 in _efree (ptr=0x0) at /usr/local/software/php4-200210061800/Zend/zend_alloc.c:211 211 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size); (gdb) bt #0 0x403d2e94 in _efree (ptr=0x0) at /usr/local/software/php4-200210061800/Zend/zend_alloc.c:211 #1 0x403e5b8e in zend_hash_destroy (ht=0x82ea824) at /usr/local/software/php4-200210061800/Zend/zend_hash.c:550 #2 0x403e063a in _zval_dtor (zvalue=0x81802ec) at /usr/local/software/php4-200210061800/Zend/zend_variables.c:51 #3 0x403f1206 in execute (op_array=0x82d130c) at /usr/local/software/php4-200210061800/Zend/zend_execute.c:449 #4 0x403f411a in execute (op_array=0x82182e4) at /usr/local/software/php4-200210061800/Zend/zend_execute.c:1641 #5 0x403e1adc in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/software/php4-200210061800/Zend/zend.c:834 #6 0x403bbfed in php_execute_script (primary_file=0xb6d0) at /usr/local/software/php4-200210061800/main/main.c:1542 #7 0x403fb4b6 in apache_php_module_main (r=0x816c9e0, display_source_mode=0) at /usr/local/software/php4-200210061800/sapi/apache/sapi_apache.c:55 #8 0x403fbfd6 in send_php (r=0x816c9e0, display_source_mode=0, filename=0x0) at /usr/local/software/php4-200210061800/sapi/apache/mod_php4.c:564 #9 0x403fc02a in send_parsed_php (r=0x816c9e0) at /usr/local/software/php4-200210061800/sapi/apache/mod_php4.c:579 #10 0x0806bdcf in ap_invoke_handler () #11 0x08080e53 in process_request_internal () #12 0x08080eb4 in ap_process_request () ---Type to continue, or q to quit--- #13 0x08077df1 in child_main () #14 0x08077fc0 in make_child () #15 0x08078134 in startup_children () #16 0x080787ac in standalone_main () #17 0x0807902b in main () #18 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 [2002-10-06 19:08:49] [EMAIL PROTECTED] Note sure if this will be useful, but if i edit main/php_config.h (after running ./configure) and remove all LOCALE defines, here's a backtrace of the segfault: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 6702)] 0x403d6c67 in _zval_dtor (zvalue=0x82ad344, __zend_filename=0x40432520 "/tmp/php-debug/Zend/zend_execute_API.c", __zend_lineno=291) at /tmp/php-debug/Zend/zend_variables.c:43 43 CHECK_ZVAL_STRING_REL(zvalue); (gdb) bt #0 0x403d6c67 in _zval_dtor (zvalue=0x82ad344, __zend_filename=0x40432520 "/tmp/php-debug/Zend/zend_execute_API.c", __zend_lineno=291) at /tmp/php-debug/Zend/zend_variables.c:43 #1 0x403cd471 in _zval_ptr_dtor (zval_ptr=0x40463b80, __zend_filename=0x40434300 "/tmp/php-debug/Zend/zend_execute_locks.h", __zend_lineno=26) at /tmp/php-debug/Zend/zend_execute_API.c:291 #2 0x403ee0b4 in zend_clean_garbage () at /tmp/php-debug/Zend/zend_execute_locks.h:26 #3 0x403e7bd5 in execute (op_array=0x82ae564) at /tmp/php-debug/Zend/zend_execute.c:1050 #4 0x403eab86 in execute (op_array=0x81e95c4) at /tmp/php-debug/Zend/zend_execute.c:1641 #5 0x403eab86 in execute (op_array=0x8241b2c) at /tmp/php-debug/Zend/zend_execute.c:1641 #6 0x403d8ad8 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /tmp/php-debug/Zend/zend.c:834 #7 0x403a2542 in php_execute_script (primary_file=0xb700) at /tmp/php-debug/main/main.c:1542 #8 0x403ef8c2 in apache_php_module_main (r=0x808cf18, display_source_mode=0) at /tmp/php-debug/sapi/apache/sapi_apache.c:55 #9 0x403f07bc in send_php (r=0x808cf18, display_source_mode=0, filename=0x808ebe0 "/var/www/modesmail/horde/imp/redirect.php")
#18556 [Ctl->Csd]: Setting locale to 'tr_TR' lowercases class names
ID: 18556
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Critical
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: Linux (RedHat 7.2)
PHP Version: 4.2.2,4.3.0-dev
Assigned To: hholzgra
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:
[2002-09-23 07:31:30] [EMAIL PROTECTED]
Verified with latest CVS head. The example script outputs:
Instantiating an infoBlob with a lowercase iFooInstantiating an
InfoBlob with an uppercase I
Fatal error: Cannot instantiate non-existent class: ýnfoblob in t.php
on line 18
t.php(18) : Fatal error - Cannot instantiate non-existent class:
ýnfoblob
[2002-08-28 21:12:13] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
Something related to this was fixed in CVS. (the #16865 which this one
was marked duplicate of is closed)
[2002-07-25 04:38:08] [EMAIL PROTECTED]
dup of #16865
[2002-07-25 03:57:43] [EMAIL PROTECTED]
known problem, see regression test case tests/lang/035.phpt
[2002-07-25 02:52:33] [EMAIL PROTECTED]
This bug is related to others submitted that refer to _constants_ being
affected by the locale change, but since this actually concerns a class
name, I wanted to submit it separately. Pardon the error if it turns
out to be one...
I'm internationalizing an app, which loads (include_once) a file called
'imc_Info.inc' containing two class definitions with their respective
constructors:
class Info
and
class InfoOracle
In the course of loading the index page, I call
new InfoOracle()
and perform a query. This works fine in English, Spanish, French, and
Greek. If I switch my app's locale to Turkish ('tr_TR'), however, I get
a error:
Cannot instantiate non-existent class: ?acle in /var/www/html
(Yes, that ? appears in my logs). After searching for bug reports
concerning Turkish, I noticed some closed/bogus reports that mentioned
_case_, so I did some poking around.
Although my class constructor clearly reads
function InfoOracle() {
blah blah blah
}
PHP fails to acknowledge it. The get_declared_classes() function DOES
return "info" and "infooracle" in its array though.
So I tried changing my call to
new infooracle(), simply lowercasing the whole name. That worked like a
charm, in Turkish. I noticed in one of the other bug reports that
Turkish contains no "I" in its character set, which _sort of_ explains
the problem, but it still strikes me as a bug. Shouldn't class names
remain unaffected by the current locale?
The following script demonstrates the problem. It generates the first
output, then throws an error attempting the second.
SCRIPT
foo = "Foo";
}
}
echo ('Instantiating an infoBlob with a lowercase i');
$foobar = new infoBlob();
echo ($foobar->foo);
echo ('Instantiating an InfoBlob with an uppercase I');
$foobar = new InfoBlob();
echo ($foobar->foo);
?>
--
Edit this bug report at http://bugs.php.net/?id=18556&edit=1
#17079 [Ctl->Ver]: setlocale changes the internal representation of floats
ID: 17079 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Verified Bug Type: *Languages/Translation Operating System: Red Hat Linux 7.1 PHP Version: 4.1.2 Assigned To: hholzgra Previous Comments: [2002-08-28 21:14:36] [EMAIL PROTECTED] one more locale bug.. [2002-05-23 10:44:35] [EMAIL PROTECTED] I didn't hear anything anymore, so I am just curious if this was picked up... Thanks, Jonathan [2002-05-08 04:14:04] [EMAIL PROTECTED] Hi somehow it has to do with converting 'numberic'-strings to floats as the script below shows: "; echo $rate1." * ".$amount1." = ".($rate1*$amount1); // second calculation with floats converted from strings echo "This should be correct as well:"; echo $rate2." * ".$amount2." = ".($rate2*$amount2); // set locale to Dutch to show misbehaviour // first calculation with floats setlocale (LC_ALL, 'nl_NL'); echo "This should still be correct:"; echo $rate1." * ".$amount1." = ".($rate1*$amount1); // second calculation with floats converted from strings echo "This should be wrong:"; echo $rate2." * ".$amount2." = ".($rate2*$amount2); ?> Hope this shows the 'bug' correctly! [2002-05-07 14:36:57] [EMAIL PROTECTED] This is dangerous indeed. We've had already reports about this (forgot #, or did it even only came up on php-dev@?). Though It may sound trivial, please provide a short self-contained script showing the (mis-)behaviour. Marking as critical for now. [2002-05-07 14:02:11] [EMAIL PROTECTED] If I set my locale to Dutch in my php-script that converts currencies for a Dutch site, I noticed that also the internal representation of floats change as well. In Europe an amount of tenthousand dollars is written as follows: $10.000,00 unlike the USA $10,000.00 So if I set the locale to "nl_NL" the internal representation of a float with a point to seperate the integer part from the decimals (for example: $amount = 68.123) is changed to a representation of a comma ','. I would like to see it changed because it messes up calculations and the different locale settings should (IMHO) apply only to output function and such. Thanks, Jonathan -- Edit this bug report at http://bugs.php.net/?id=17079&edit=1
#19324 [Ctl->Fbk]: show PHP source on client's browser
ID: 19324
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Critical
+Status: Feedback
Bug Type: Output Control
Operating System: Solaris8 x86
PHP Version: 4.2.3
Previous Comments:
[2002-09-25 22:59:00] [EMAIL PROTECTED]
apache 1.3.26
[2002-09-25 22:48:14] [EMAIL PROTECTED]
With which apache version it doesn't work?
[2002-09-25 21:29:57] [EMAIL PROTECTED]
I compiled php without any CFLAGS, showing source still
arisen .
My gcc version is 3.2 .
PS: but the situation doesn't arise on "APACHE 2.x + PHP" .
[2002-09-25 09:44:54] [EMAIL PROTECTED]
Could you try compiling PHP without using ANY predefined CFLAGS? ie.
only run the configure with your options.
[2002-09-25 03:56:02] [EMAIL PROTECTED]
When I use :
header('Location: xxx.php?a=123&b=456');
(1) use header() function
(2) the URL append GET string
then php file show the source on client's browser.
But after reload, the PHP just normal run.
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/19324
--
Edit this bug report at http://bugs.php.net/?id=19324&edit=1
#17616 [Bgs->Ver]: backslash characters handled oddly in preg_replace
ID: 17616
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Verified
Bug Type: PCRE related
Operating System: linux 2.4.14, pcre
PHP Version: 4.3.0-dev
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
In the first case the extension receives replacement string \\\ which
is basically \\, since last backslash doesn't quote anything. And in
the second case it's which is interpolated into \\.
Previous Comments:
[2002-09-25 09:33:23] [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
[2002-09-11 19:44:28] [EMAIL PROTECTED]
updated version.
[2002-06-05 18:17:27] [EMAIL PROTECTED]
Below are two calls to preg_replace() with different replacement
strings. For some reason, they both return the same string.
$s = "A backslash: \\ ";
$s1 = preg_replace("//", "\\", $s);
$s2 = preg_replace("//", "", $s);
echo "s : $s \n";
echo "s1: $s1 \n";
echo "s2: $s2 \n";
--
Output:
s : A backslash: \
s1: A backslash: \\
s2: A backslash: \\
--
My configuration:
'./configure' '--with-gnu-ld' '--with-apxs=/usr/local/apache/bin/apxs'
'--with-mysql=/usr/local/mysql'
--
Edit this bug report at http://bugs.php.net/?id=17616&edit=1
#17616 [Ver->Bgs]: backslash characters handled oddly in preg_replace
ID: 17616
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Verified
+Status: Bogus
Bug Type: PCRE related
Operating System: linux 2.4.14, pcre
PHP Version: 4.3.0-dev
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
Previous Comments:
[2002-09-11 19:44:28] [EMAIL PROTECTED]
updated version.
[2002-06-05 18:17:27] [EMAIL PROTECTED]
Below are two calls to preg_replace() with different replacement
strings. For some reason, they both return the same string.
$s = "A backslash: \\ ";
$s1 = preg_replace("//", "\\", $s);
$s2 = preg_replace("//", "", $s);
echo "s : $s \n";
echo "s1: $s1 \n";
echo "s2: $s2 \n";
--
Output:
s : A backslash: \
s1: A backslash: \\
s2: A backslash: \\
--
My configuration:
'./configure' '--with-gnu-ld' '--with-apxs=/usr/local/apache/bin/apxs'
'--with-mysql=/usr/local/mysql'
--
Edit this bug report at http://bugs.php.net/?id=17616&edit=1
#17570 [Asn->Opn]: Memory leak
ID: 17570 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Open Bug Type: Regexps related Operating System: Redhat Linux 7.2 PHP Version: 4.1.2 Assigned To: andrei 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: [2002-09-25 08:31:11] [EMAIL PROTECTED] Assigned to Andrei per his request. [2002-06-18 11:59:38] [EMAIL PROTECTED] I've tried the snapshot but situation is the same - the module leaks 32 bytes every init/shutdown cycle. [2002-06-17 19:02:37] [EMAIL PROTECTED] Please try with this snapshot: http://snaps.php.net/php4-latest.tar.gz [2002-06-03 06:15:34] [EMAIL PROTECTED] I've tried the latest CVS version and it seems the problem is still here. [2002-06-03 05:10:41] [EMAIL PROTECTED] Can you verify against HEAD if this problem is still there? 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/17570 -- Edit this bug report at http://bugs.php.net/?id=17570&edit=1
#14251 [Ctl->Ana]: register_shutdown_function bug
ID: 14251 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Analyzed Bug Type: Scripting Engine problem Operating System: Linux Mandrake 8.0 PHP Version: 4.1.0 Assigned To: zeev Previous Comments: [2002-09-19 21:07:31] [EMAIL PROTECTED] IIRC (!) this was some problem with the cwd funcs in TSRM. Can't remember now what exactly it was.. (it works in windows but not in *nix) [2002-09-19 11:08:13] [EMAIL PROTECTED] This isn't related to #11831. It has to do with the fact that by the time we're shutting down, we're no longer in the request context, but rather, in Apache's shutdown context. Apache is probably changing directory to / at this stage. I'm not sure why this is tagged as critical, I'm not sure whether this should be 'fixed'. My recommendation is to move it to 'Analyzed' status. [2002-09-03 18:35:56] [EMAIL PROTECTED] Another one related to #11831 [2002-08-05 16:48:02] [EMAIL PROTECTED] I have reproduced this too on PHP 4.2.2 and Linux RH 6.2. However it does not seem to occur in Windows. Workaround by putting getcwd() into a global variable before shutdown then using chdir() in the shutdown_function. [2001-11-27 12:48:47] [EMAIL PROTECTED] Reproduced. Seems like cwd changes to / always. 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/14251 -- Edit this bug report at http://bugs.php.net/?id=14251&edit=1
Bug #16825: Latest updates make compilation fail
From: [EMAIL PROTECTED] Operating system: RedHat 7.1 PHP version: 4.0CVS-2002-04-25 PHP Bug Type: DOM XML related Bug description: Latest updates make compilation fail After latest CVS update, compiling against installed libxml2-2.4.2 fails with the following: /projects/compile/php4/ext/domxml/php_domxml.c: In function `zif_domxml_doc_get_element_by_id': /projects/compile/php4/ext/domxml/php_domxml.c:2711: warning: passing arg 2 of `xmlHashScan' from incompatible pointer type -- Edit bug report at http://bugs.php.net/?id=16825&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16825&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16825&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16825&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16825&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16825&r=support Expected behavior: http://bugs.php.net/fix.php?id=16825&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16825&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16825&r=submittedtwice
Bug #14795 Updated: array_sum() modifies the specified array
ID: 14795 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Arrays related Operating System: Debian unstable PHP Version: 4.1.0 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-01-02 06:19:22] [EMAIL PROTECTED] the documentation claims this behavior was changed after 4.0.6, but it appears to behave the same in 4.1.0. (and i don't see a commit to ext/standard/array.c that indicates any such change to array_sum.) $a = array(1, 2, "foo"); print_r($a); echo array_sum($a); print_r($a); results in: Array ( [0] => 1 [1] => 2 [2] => foo ) 3Array ( [0] => 1 [1] => 2 [2] => 0 ) -- Edit this bug report at http://bugs.php.net/?id=14795&edit=1
Bug #14990 Updated: array_merge_recursive modifies inputted value
ID: 14990 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Arrays related Operating System: n/a PHP Version: 4.1.1 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-01-11 04:32:53] [EMAIL PROTECTED] With 3+ parameters, only the first parameter is left untouched. All others are affected, as demonstrated above with $b. [2002-01-11 04:02:21] [EMAIL PROTECTED] In Summary: -- array_merge_recursive() modifies the array entered as the second parameter if the merged arrays have at least one identical stringed key. It will affect all such duplicate keys, and modify the second parameter's array as demonstrated below. Example: -- '2 a', 'foo' => 'foo a','bar' => 'bar a'); $b = array(2 => '2 b', 'foo' => 'foo b','bar' => 'bar b'); $c['recursive'] = array_merge_recursive($a,$b); $c['a'] = $a; $c['b'] = $b; print_r($c); ?> Example output: --- Array ( [recursive] => Array ( [0] => 2 a [foo] => Array ( [0] => foo a [1] => foo b ) [bar] => Array ( [0] => bar a [1] => bar b ) [1] => 2 b ) [a] => Array ( [2] => 2 a [foo] => foo a [bar] => bar a ) [b] => Array ( [2] => 2 b [foo] => Array ( [0] => foo b ) [bar] => Array ( [0] => bar b ) ) ) Notes: Notice how in $b, keys 'foo' and 'bar' are now arrays when initially they were not. This behavior exists with all such duplicate stringed keys. array_merge_recursive() should not directly affect inputted values. This seems related to bug #14128. -- Edit this bug report at http://bugs.php.net/?id=14990&edit=1
Bug #14917 Updated: When using array_merge w/numbers & assoc array the numbers are changed to 0,1..
ID: 14917
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Arrays related
Operating System: BSD & Windows
PHP Version: 4.1.1
New Comment:
This happens because of the way PHP treats array keys that are quoted
numbers, that is, "7" is really an integer key 7 and those do get
renumbered by array_merge() as it's supposed to work this way.
Previous Comments:
[2002-03-22 17:00:08] [EMAIL PROTECTED]
Still a problem in 4.1.2
[2002-02-18 15:23:44] [EMAIL PROTECTED]
This is the work around I used:
function my_array_merge()
{
$DATA_ARRAY=func_get_args();
foreach ($DATA_ARRAY as $key=>$val)
{
foreach (testArray($DATA_ARRAY[$key]) as $key1=>$val1)
{$TEMP_ARRAY[$key1]=$DATA_ARRAY[$key][$key1];}
}
return $TEMP_ARRAY;
}
[2002-01-08 07:19:40] [EMAIL PROTECTED]
Reclassified.
[2002-01-07 16:01:29] [EMAIL PROTECTED]
When I try to use array_merge an array with an associative array the
array is renumbered starting at 0.
Problem on Win2k with 4.1.0 & 4.1.1
Problem on OpenBSD with 4.0.6
Here is a quick sample:
array(1=>"TEST",2=>"TEST",4=>"TEST"),"9"=>array(1=>"TEST",2=>"TEST",4=>"TEST")),array("A"=>array(1=>"TEST",2=>"TEST",4=>"TEST"),"B"=>array(1=>"TEST",2=>"TEST",4=>"TEST")));
foreach ($TEST as $key=>$val)
{print "$key";}
?>
Output:
0
1
A
B
--
Edit this bug report at http://bugs.php.net/?id=14917&edit=1
