#41744 [Fbk->Opn]: about try...catch...
ID: 41744
User updated by: edwardhey at 163 dot com
Reported By: edwardhey at 163 dot com
-Status: Feedback
+Status: Open
Bug Type: Unknown/Other Function
Operating System: freebsd
PHP Version: 5.2.3
New Comment:
yes,i have
about this:
Zend Extension 220060519
My phpinfo information:
http://www.phpoo.cn/tan/iProber.php?act=phpinfo
thanks a lot!
Previous Comments:
[2007-06-20 07:01:21] [EMAIL PROTECTED]
Do you have any extensions loaded, particularly "Zend" extensions?
[2007-06-20 00:42:30] edwardhey at 163 dot com
Description:
hi~!
when i use 'try' to catch the 'exception',the server throw me the
Fatal error.
php: php5.2.1/fastcgi
server: apache2.2.3
Reproduce code:
---
getMessage(), "\n";
}
echo 'Hello World';
?>
Expected result:
Fatal error: Uncaught exception 'Exception' with message 'Always throw
this error' in /www/phpoo.cn/htdocs/test.php:4 Stack trace: #0 {main}
thrown in /www/phpoo.cn/htdocs/test.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=41744&edit=1
#41744 [Fbk->Opn]: about try...catch...
ID: 41744
User updated by: edwardhey at 163 dot com
Reported By: edwardhey at 163 dot com
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: freebsd
PHP Version: 5.2.1
New Comment:
i will keep trying and upgrade my php, thanks a lot!
Previous Comments:
[2007-06-20 10:03:40] [EMAIL PROTECTED]
And why do you report bugs in old releases? The latest is 5.2.3..you
have 5.2.1!
[2007-06-20 10:02:40] [EMAIL PROTECTED]
First you need to disable all 3rd party extensions, like any Zend
extensions.
[2007-06-20 07:20:47] edwardhey at 163 dot com
yes,i have
about this:
Zend Extension 220060519
My phpinfo information:
http://www.phpoo.cn/tan/iProber.php?act=phpinfo
thanks a lot!
[2007-06-20 07:01:21] [EMAIL PROTECTED]
Do you have any extensions loaded, particularly "Zend" extensions?
[2007-06-20 00:42:30] edwardhey at 163 dot com
Description:
hi~!
when i use 'try' to catch the 'exception',the server throw me the
Fatal error.
php: php5.2.1/fastcgi
server: apache2.2.3
Reproduce code:
---
getMessage(), "\n";
}
echo 'Hello World';
?>
Expected result:
Fatal error: Uncaught exception 'Exception' with message 'Always throw
this error' in /www/phpoo.cn/htdocs/test.php:4 Stack trace: #0 {main}
thrown in /www/phpoo.cn/htdocs/test.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=41744&edit=1
#41751 [Opn]: touch() works incorrectly in Windows.
ID: 41751
User updated by: aeolianmeson at blitzeclipse dot com
Reported By: aeolianmeson at blitzeclipse dot com
Status: Open
Bug Type: *General Issues
Operating System: Windows XP SP2
PHP Version: 5.2.3
New Comment:
Plus, this only happens with Windows.
Dustin
Previous Comments:
[2007-06-20 22:27:45] aeolianmeson at blitzeclipse dot com
It's just easier to see when I use (0). I was using normal timestamps
before.
[2007-06-20 22:26:26] [EMAIL PROTECTED]
Actually I think it's just the thing that you pass '0' to touch() as
2nd parameter..
[2007-06-20 21:58:56] aeolianmeson at blitzeclipse dot com
1182376591
1182376591
ctime doesn't appear to be afflicted.
Dustin Oprea
[2007-06-20 21:53:45] [EMAIL PROTECTED]
What does this output for you:
[2007-06-20 21:28:11] aeolianmeson at blitzeclipse dot com
Description:
Touch appears to always apply a timestamp that is exactly one-hour
earlier then the given timestamp, in Windows. It appears to work fine in
PHP 5.0.4 and 4.1.2 in Linux.
Reproduce code:
---
touch('b', 0);
var_dump(stat('b'));
Expected result:
array(26) {
[0]=>
int(2)
[1]=>
int(0)
[2]=>
int(33206)
[3]=>
int(1)
[4]=>
int(0)
[5]=>
int(0)
[6]=>
int(2)
[7]=>
int(0)
[8]=>
int(-3600)
[9]=>
int(-3600)
[10]=>
int(1182374129)
[11]=>
int(-1)
[12]=>
int(-1)
["dev"]=>
int(2)
["ino"]=>
int(0)
["mode"]=>
int(33206)
["nlink"]=>
int(1)
["uid"]=>
int(0)
["gid"]=>
int(0)
["rdev"]=>
int(2)
["size"]=>
int(0)
["atime"]=>
int(0)
["mtime"]=>
int(0)
["ctime"]=>
int(1182374129)
["blksize"]=>
int(-1)
["blocks"]=>
int(-1)
}
Actual result:
--
// mtime and ctime are -3600.
array(26) {
[0]=>
int(2)
[1]=>
int(0)
[2]=>
int(33206)
[3]=>
int(1)
[4]=>
int(0)
[5]=>
int(0)
[6]=>
int(2)
[7]=>
int(0)
[8]=>
int(-3600)
[9]=>
int(-3600)
[10]=>
int(1182374129)
[11]=>
int(-1)
[12]=>
int(-1)
["dev"]=>
int(2)
["ino"]=>
int(0)
["mode"]=>
int(33206)
["nlink"]=>
int(1)
["uid"]=>
int(0)
["gid"]=>
int(0)
["rdev"]=>
int(2)
["size"]=>
int(0)
["atime"]=>
int(-3600)
["mtime"]=>
int(-3600)
["ctime"]=>
int(1182374129)
["blksize"]=>
int(-1)
["blocks"]=>
int(-1)
}
--
Edit this bug report at http://bugs.php.net/?id=41751&edit=1
#41751 [Fbk->Opn]: touch() works incorrectly in Windows.
ID: 41751
User updated by: aeolianmeson at blitzeclipse dot com
Reported By: aeolianmeson at blitzeclipse dot com
-Status: Feedback
+Status: Open
Bug Type: *General Issues
Operating System: Windows XP SP2
PHP Version: 5.2.3
New Comment:
It's just easier to see when I use (0). I was using normal timestamps
before.
Previous Comments:
[2007-06-20 22:26:26] [EMAIL PROTECTED]
Actually I think it's just the thing that you pass '0' to touch() as
2nd parameter..
[2007-06-20 21:58:56] aeolianmeson at blitzeclipse dot com
1182376591
1182376591
ctime doesn't appear to be afflicted.
Dustin Oprea
[2007-06-20 21:53:45] [EMAIL PROTECTED]
What does this output for you:
[2007-06-20 21:28:11] aeolianmeson at blitzeclipse dot com
Description:
Touch appears to always apply a timestamp that is exactly one-hour
earlier then the given timestamp, in Windows. It appears to work fine in
PHP 5.0.4 and 4.1.2 in Linux.
Reproduce code:
---
touch('b', 0);
var_dump(stat('b'));
Expected result:
array(26) {
[0]=>
int(2)
[1]=>
int(0)
[2]=>
int(33206)
[3]=>
int(1)
[4]=>
int(0)
[5]=>
int(0)
[6]=>
int(2)
[7]=>
int(0)
[8]=>
int(-3600)
[9]=>
int(-3600)
[10]=>
int(1182374129)
[11]=>
int(-1)
[12]=>
int(-1)
["dev"]=>
int(2)
["ino"]=>
int(0)
["mode"]=>
int(33206)
["nlink"]=>
int(1)
["uid"]=>
int(0)
["gid"]=>
int(0)
["rdev"]=>
int(2)
["size"]=>
int(0)
["atime"]=>
int(0)
["mtime"]=>
int(0)
["ctime"]=>
int(1182374129)
["blksize"]=>
int(-1)
["blocks"]=>
int(-1)
}
Actual result:
--
// mtime and ctime are -3600.
array(26) {
[0]=>
int(2)
[1]=>
int(0)
[2]=>
int(33206)
[3]=>
int(1)
[4]=>
int(0)
[5]=>
int(0)
[6]=>
int(2)
[7]=>
int(0)
[8]=>
int(-3600)
[9]=>
int(-3600)
[10]=>
int(1182374129)
[11]=>
int(-1)
[12]=>
int(-1)
["dev"]=>
int(2)
["ino"]=>
int(0)
["mode"]=>
int(33206)
["nlink"]=>
int(1)
["uid"]=>
int(0)
["gid"]=>
int(0)
["rdev"]=>
int(2)
["size"]=>
int(0)
["atime"]=>
int(-3600)
["mtime"]=>
int(-3600)
["ctime"]=>
int(1182374129)
["blksize"]=>
int(-1)
["blocks"]=>
int(-1)
}
--
Edit this bug report at http://bugs.php.net/?id=41751&edit=1
#41751 [Opn->Fbk]: touch() works incorrectly in Windows.
ID: 41751
Updated by: [EMAIL PROTECTED]
Reported By: aeolianmeson at blitzeclipse dot com
-Status: Open
+Status: Feedback
Bug Type: *General Issues
Operating System: Windows XP SP2
PHP Version: 5.2.3
New Comment:
Actually I think it's just the thing that you pass '0' to touch() as
2nd parameter..
Previous Comments:
[2007-06-20 21:58:56] aeolianmeson at blitzeclipse dot com
1182376591
1182376591
ctime doesn't appear to be afflicted.
Dustin Oprea
[2007-06-20 21:53:45] [EMAIL PROTECTED]
What does this output for you:
[2007-06-20 21:28:11] aeolianmeson at blitzeclipse dot com
Description:
Touch appears to always apply a timestamp that is exactly one-hour
earlier then the given timestamp, in Windows. It appears to work fine in
PHP 5.0.4 and 4.1.2 in Linux.
Reproduce code:
---
touch('b', 0);
var_dump(stat('b'));
Expected result:
array(26) {
[0]=>
int(2)
[1]=>
int(0)
[2]=>
int(33206)
[3]=>
int(1)
[4]=>
int(0)
[5]=>
int(0)
[6]=>
int(2)
[7]=>
int(0)
[8]=>
int(-3600)
[9]=>
int(-3600)
[10]=>
int(1182374129)
[11]=>
int(-1)
[12]=>
int(-1)
["dev"]=>
int(2)
["ino"]=>
int(0)
["mode"]=>
int(33206)
["nlink"]=>
int(1)
["uid"]=>
int(0)
["gid"]=>
int(0)
["rdev"]=>
int(2)
["size"]=>
int(0)
["atime"]=>
int(0)
["mtime"]=>
int(0)
["ctime"]=>
int(1182374129)
["blksize"]=>
int(-1)
["blocks"]=>
int(-1)
}
Actual result:
--
// mtime and ctime are -3600.
array(26) {
[0]=>
int(2)
[1]=>
int(0)
[2]=>
int(33206)
[3]=>
int(1)
[4]=>
int(0)
[5]=>
int(0)
[6]=>
int(2)
[7]=>
int(0)
[8]=>
int(-3600)
[9]=>
int(-3600)
[10]=>
int(1182374129)
[11]=>
int(-1)
[12]=>
int(-1)
["dev"]=>
int(2)
["ino"]=>
int(0)
["mode"]=>
int(33206)
["nlink"]=>
int(1)
["uid"]=>
int(0)
["gid"]=>
int(0)
["rdev"]=>
int(2)
["size"]=>
int(0)
["atime"]=>
int(-3600)
["mtime"]=>
int(-3600)
["ctime"]=>
int(1182374129)
["blksize"]=>
int(-1)
["blocks"]=>
int(-1)
}
--
Edit this bug report at http://bugs.php.net/?id=41751&edit=1
#41751 [Fbk->Opn]: touch() works incorrectly in Windows.
ID: 41751
User updated by: aeolianmeson at blitzeclipse dot com
Reported By: aeolianmeson at blitzeclipse dot com
-Status: Feedback
+Status: Open
Bug Type: *General Issues
Operating System: Windows XP SP2
PHP Version: 5.2.3
New Comment:
1182376591
1182376591
ctime doesn't appear to be afflicted.
Dustin Oprea
Previous Comments:
[2007-06-20 21:53:45] [EMAIL PROTECTED]
What does this output for you:
[2007-06-20 21:28:11] aeolianmeson at blitzeclipse dot com
Description:
Touch appears to always apply a timestamp that is exactly one-hour
earlier then the given timestamp, in Windows. It appears to work fine in
PHP 5.0.4 and 4.1.2 in Linux.
Reproduce code:
---
touch('b', 0);
var_dump(stat('b'));
Expected result:
array(26) {
[0]=>
int(2)
[1]=>
int(0)
[2]=>
int(33206)
[3]=>
int(1)
[4]=>
int(0)
[5]=>
int(0)
[6]=>
int(2)
[7]=>
int(0)
[8]=>
int(-3600)
[9]=>
int(-3600)
[10]=>
int(1182374129)
[11]=>
int(-1)
[12]=>
int(-1)
["dev"]=>
int(2)
["ino"]=>
int(0)
["mode"]=>
int(33206)
["nlink"]=>
int(1)
["uid"]=>
int(0)
["gid"]=>
int(0)
["rdev"]=>
int(2)
["size"]=>
int(0)
["atime"]=>
int(0)
["mtime"]=>
int(0)
["ctime"]=>
int(1182374129)
["blksize"]=>
int(-1)
["blocks"]=>
int(-1)
}
Actual result:
--
// mtime and ctime are -3600.
array(26) {
[0]=>
int(2)
[1]=>
int(0)
[2]=>
int(33206)
[3]=>
int(1)
[4]=>
int(0)
[5]=>
int(0)
[6]=>
int(2)
[7]=>
int(0)
[8]=>
int(-3600)
[9]=>
int(-3600)
[10]=>
int(1182374129)
[11]=>
int(-1)
[12]=>
int(-1)
["dev"]=>
int(2)
["ino"]=>
int(0)
["mode"]=>
int(33206)
["nlink"]=>
int(1)
["uid"]=>
int(0)
["gid"]=>
int(0)
["rdev"]=>
int(2)
["size"]=>
int(0)
["atime"]=>
int(-3600)
["mtime"]=>
int(-3600)
["ctime"]=>
int(1182374129)
["blksize"]=>
int(-1)
["blocks"]=>
int(-1)
}
--
Edit this bug report at http://bugs.php.net/?id=41751&edit=1
#41751 [Opn->Fbk]: touch() works incorrectly in Windows.
ID: 41751
Updated by: [EMAIL PROTECTED]
Reported By: aeolianmeson at blitzeclipse dot com
-Status: Open
+Status: Feedback
Bug Type: *General Issues
Operating System: Windows XP SP2
PHP Version: 5.2.3
New Comment:
What does this output for you:
Previous Comments:
[2007-06-20 21:28:11] aeolianmeson at blitzeclipse dot com
Description:
Touch appears to always apply a timestamp that is exactly one-hour
earlier then the given timestamp, in Windows. It appears to work fine in
PHP 5.0.4 and 4.1.2 in Linux.
Reproduce code:
---
touch('b', 0);
var_dump(stat('b'));
Expected result:
array(26) {
[0]=>
int(2)
[1]=>
int(0)
[2]=>
int(33206)
[3]=>
int(1)
[4]=>
int(0)
[5]=>
int(0)
[6]=>
int(2)
[7]=>
int(0)
[8]=>
int(-3600)
[9]=>
int(-3600)
[10]=>
int(1182374129)
[11]=>
int(-1)
[12]=>
int(-1)
["dev"]=>
int(2)
["ino"]=>
int(0)
["mode"]=>
int(33206)
["nlink"]=>
int(1)
["uid"]=>
int(0)
["gid"]=>
int(0)
["rdev"]=>
int(2)
["size"]=>
int(0)
["atime"]=>
int(0)
["mtime"]=>
int(0)
["ctime"]=>
int(1182374129)
["blksize"]=>
int(-1)
["blocks"]=>
int(-1)
}
Actual result:
--
// mtime and ctime are -3600.
array(26) {
[0]=>
int(2)
[1]=>
int(0)
[2]=>
int(33206)
[3]=>
int(1)
[4]=>
int(0)
[5]=>
int(0)
[6]=>
int(2)
[7]=>
int(0)
[8]=>
int(-3600)
[9]=>
int(-3600)
[10]=>
int(1182374129)
[11]=>
int(-1)
[12]=>
int(-1)
["dev"]=>
int(2)
["ino"]=>
int(0)
["mode"]=>
int(33206)
["nlink"]=>
int(1)
["uid"]=>
int(0)
["gid"]=>
int(0)
["rdev"]=>
int(2)
["size"]=>
int(0)
["atime"]=>
int(-3600)
["mtime"]=>
int(-3600)
["ctime"]=>
int(1182374129)
["blksize"]=>
int(-1)
["blocks"]=>
int(-1)
}
--
Edit this bug report at http://bugs.php.net/?id=41751&edit=1
#41749 [Opn->Bgs]: Reproducible segfault in PCRE lib
ID: 41749 Updated by: [EMAIL PROTECTED] Reported By: joe at emomentum dot co dot uk -Status: Open +Status: Bogus Bug Type: PCRE related Operating System: Debian Etch (Debian 4.0 Stable) PHP Version: 5.2.0 New Comment: We don't use the pcre_dfa_exec() function. There's something wrong going there. Still this is not a PHP bug. libpcre 6.7 is really old and you should consider upgrading to libpcre 7.2. BTW, I couldn't reproduce the problem, albeith with a newer libpcre version. Previous Comments: [2007-06-20 21:06:58] judas dot iscariote at gmail dot com your code produces stack overflow in the PCRE library and there is nothing almost nothing that PHP can do to avoid that. [2007-06-20 14:40:11] joe at emomentum dot co dot uk Description: Couldn't see this anywhere else (similar but not close enough). Located an apparent bug in the PCRE library, although this might be relating to the way PHP calls the library (I'll post this to the PCRE list as well). Reproducable if slightly random crash occurs when using regex's with certain hex strings on longish (and random) strings. Weirdly, the length of the string directly relates to the chance of a segfault, and the segfault only occurs with certain ranges of hex strings (specifically, ONLY over x7A and ONLY with text strings of exactly 4843 bytes or longer). Note that using the regex /^([\x00-\x7A])*$/ causes a segfault, whereas /^([\x00-\x71])*$/ or /^([\x00-\x79])*$/ does not. Running on Debian Etch 64bit (amd64) with latest stable PHP and libpcre3_6.7-1_amd64 installed. Regards, Joe Harris Senior Developer eMomentum Limited Reproduce code: --- Expected result: int(0) (false, never going to match a-z random string) Actual result: -- Segmentation fault (core dumped) - when running in gdb: This GDB was configured as "x86_64-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run test.php Starting program: /usr/bin/php test.php (no debugging symbols found) [snip - lots of these] (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 47782002024432 (LWP 11134)] (no debugging symbols found) [snip - lots of these] (no debugging symbols found) testing a string of 4846 bytes in length Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47782002024432 (LWP 11134)] 0x2b751be871a8 in pcre_dfa_exec () from /usr/lib/libpcre.so.3 -- Edit this bug report at http://bugs.php.net/?id=41749&edit=1
#41751 [NEW]: touch() works incorrectly in Windows.
From: aeolianmeson at blitzeclipse dot com
Operating system: Windows XP SP2
PHP version: 5.2.3
PHP Bug Type: *General Issues
Bug description: touch() works incorrectly in Windows.
Description:
Touch appears to always apply a timestamp that is exactly one-hour earlier
then the given timestamp, in Windows. It appears to work fine in PHP 5.0.4
and 4.1.2 in Linux.
Reproduce code:
---
touch('b', 0);
var_dump(stat('b'));
Expected result:
array(26) {
[0]=>
int(2)
[1]=>
int(0)
[2]=>
int(33206)
[3]=>
int(1)
[4]=>
int(0)
[5]=>
int(0)
[6]=>
int(2)
[7]=>
int(0)
[8]=>
int(-3600)
[9]=>
int(-3600)
[10]=>
int(1182374129)
[11]=>
int(-1)
[12]=>
int(-1)
["dev"]=>
int(2)
["ino"]=>
int(0)
["mode"]=>
int(33206)
["nlink"]=>
int(1)
["uid"]=>
int(0)
["gid"]=>
int(0)
["rdev"]=>
int(2)
["size"]=>
int(0)
["atime"]=>
int(0)
["mtime"]=>
int(0)
["ctime"]=>
int(1182374129)
["blksize"]=>
int(-1)
["blocks"]=>
int(-1)
}
Actual result:
--
// mtime and ctime are -3600.
array(26) {
[0]=>
int(2)
[1]=>
int(0)
[2]=>
int(33206)
[3]=>
int(1)
[4]=>
int(0)
[5]=>
int(0)
[6]=>
int(2)
[7]=>
int(0)
[8]=>
int(-3600)
[9]=>
int(-3600)
[10]=>
int(1182374129)
[11]=>
int(-1)
[12]=>
int(-1)
["dev"]=>
int(2)
["ino"]=>
int(0)
["mode"]=>
int(33206)
["nlink"]=>
int(1)
["uid"]=>
int(0)
["gid"]=>
int(0)
["rdev"]=>
int(2)
["size"]=>
int(0)
["atime"]=>
int(-3600)
["mtime"]=>
int(-3600)
["ctime"]=>
int(1182374129)
["blksize"]=>
int(-1)
["blocks"]=>
int(-1)
}
--
Edit bug report at http://bugs.php.net/?id=41751&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41751&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41751&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41751&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41751&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41751&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41751&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41751&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41751&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41751&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41751&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41751&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41751&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41751&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41751&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41751&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41751&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41751&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41751&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41751&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41751&r=mysqlcfg
#41749 [Com]: Reproducible segfault in PCRE lib
ID: 41749 Comment by: judas dot iscariote at gmail dot com Reported By: joe at emomentum dot co dot uk Status: Open Bug Type: PCRE related Operating System: Debian Etch (Debian 4.0 Stable) PHP Version: 5.2.0 New Comment: your code produces stack overflow in the PCRE library and there is nothing almost nothing that PHP can do to avoid that. Previous Comments: [2007-06-20 14:40:11] joe at emomentum dot co dot uk Description: Couldn't see this anywhere else (similar but not close enough). Located an apparent bug in the PCRE library, although this might be relating to the way PHP calls the library (I'll post this to the PCRE list as well). Reproducable if slightly random crash occurs when using regex's with certain hex strings on longish (and random) strings. Weirdly, the length of the string directly relates to the chance of a segfault, and the segfault only occurs with certain ranges of hex strings (specifically, ONLY over x7A and ONLY with text strings of exactly 4843 bytes or longer). Note that using the regex /^([\x00-\x7A])*$/ causes a segfault, whereas /^([\x00-\x71])*$/ or /^([\x00-\x79])*$/ does not. Running on Debian Etch 64bit (amd64) with latest stable PHP and libpcre3_6.7-1_amd64 installed. Regards, Joe Harris Senior Developer eMomentum Limited Reproduce code: --- Expected result: int(0) (false, never going to match a-z random string) Actual result: -- Segmentation fault (core dumped) - when running in gdb: This GDB was configured as "x86_64-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run test.php Starting program: /usr/bin/php test.php (no debugging symbols found) [snip - lots of these] (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 47782002024432 (LWP 11134)] (no debugging symbols found) [snip - lots of these] (no debugging symbols found) testing a string of 4846 bytes in length Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47782002024432 (LWP 11134)] 0x2b751be871a8 in pcre_dfa_exec () from /usr/lib/libpcre.so.3 -- Edit this bug report at http://bugs.php.net/?id=41749&edit=1
#41732 [Opn]: Bare LFs in SMTP
ID: 41732
User updated by: as at as dot hu
Reported By: as at as dot hu
Status: Open
Bug Type: Mail related
Operating System: Windows 2003
PHP Version: 4.4.7
New Comment:
It's a real bug. :-)
because when I use the mail function, the mail bounced from some
server. It is bug.
Please try sending mail to this address:
ashutest(at)vipmail.hu
This server is not Windows server, and MUST sending mail to this server
with CrLf.
Please read http://www.faqs.org/rfcs/rfc822.html
But, oK.
How to set up correctly php on windows?
In my php.ini I cannot see settings for CRLF:
[mail function]
; For Win32 only.
SMTP = mail.xxx.hu
smtp_port = 25
; For Win32 only.
sendmail_from = return(at)xxx.hu
; For Unix only. You may supply arguments as well (default: "sendmail
-t -i").
;sendmail_path =
When I use Wordpress, the mails not sendig for some host. Same in
phpNuke, etc... So I think, it's a bug in php mail sending function.
Previous Comments:
[2007-06-20 12:30:35] bas at tobin dot nl
Hi,
This is not a bug of PHP.
E-Mail being transferred between mail servers needs CrLf (\r\n) as EOL
separator. The catch however is how PHP sends the mail to your outbound
mail server. On windows you always need to separate mail headers and end
of lines with CrLf as this is the standard windows EOL separator. On
Linux this depends on the mail injector of your Mail Server. For
instance qmail expects the EOL separator to be the same as the standard
linux separator Lf(\n) and when sending the message outbound converts
all these Lf's to CrLf. If you feed this script with CrLf you will send
E-Mail messages having extra white lines.
If your PHP script does not send the message to a typical local mail
injector but to a normal inbound mail port it will have to follow RFC's
and CrLf will be needed again.
So depending on your setup you either need to send CrLf or Lf between
lines.
[2007-06-18 20:32:03] as at as dot hu
Description:
On Windows 2003, default smtp server.
When I use the mail function, some target e-mail system say:
195.56.151.XX, OutboundConnectionResponse, 2007. 06. 18., 22:06:43,
SMTPSVC1, AS, -, 312, 0, 47, 0, 0, -, -, 451 See
http://pobox.com/~djb/docs/smtplf.html.,
Reproduce code:
---
$subject = "Elveszett jelszó";
$headers = "From: ".$mail_pswd_from."\nX-FW-MailID:s6s06s9s80";
$row=mysql_fetch_array($result);
$to = $row['usr_email'];
$body = "Tisztelt ".$row[usr_lastname]." ".$row[usr_firstname]."!\nAz
Ön jelszava: ".$row[usr_pswd]."\n\nÜdvözlettel,\nA S";
mail($to,$subject,$body,$headers);
Expected result:
The email bounce to the sender from some hosts. (like citromail.hu,
vipmail.hu) with this error message:
http://pobox.com/~djb/docs/smtplf.html
Actual result:
--
When I replace all newline to CRLF, the mail went away without
problem:
$subject = "Elveszett jelszó";
$headers = "From: ".$mail_pswd_from."\nX-FW-MailID:s6s06s9s80";
$row=mysql_fetch_array($result);
$to = $row['usr_email'];
$body = "Tisztelt ".$row[usr_lastname]." ".$row[usr_firstname]."!\nAz
Ön jelszava: ".$row[usr_pswd]."\n\nÜdvözlettel,\nA S";
$body = str_replace("\r\n","\n",$body);
$body = str_replace("\r","\n",$body);
$body = str_replace("\n","\r\n",$body);
mail($to,$subject,$body,$headers);
--
Edit this bug report at http://bugs.php.net/?id=41732&edit=1
#41497 [Opn->Bgs]: php.ini not loaded
ID: 41497 Updated by: [EMAIL PROTECTED] Reported By: dbjh at gmx dot net -Status: Open +Status: Bogus Bug Type: PHP options/info functions Operating System: RHEL 4 PHP Version: 5.2.2 New Comment: Not any PHP bug then. Previous Comments: [2007-06-18 13:53:07] dbjh at gmx dot net You were right about SELinux. When I set it to permissive there's no problem. [2007-05-25 23:15:31] [EMAIL PROTECTED] Just tested latest 5.2 snapshot on a rhel4 machine and it worked just fine using exactly same ini config options as you pasted here. Are you sure this isn't some SELinux issue? Do you get any errors in /var/log/messages ?? Can you reproduce this with CLI ? [2007-05-25 23:05:52] [EMAIL PROTECTED] 1) My reply was perfectly appropriate, you did not mention what configure line you had used nor that it worked in 5.2.0. 2) What exactly is said in phpinfo() output about what php.ini is loaded when you have it in /etc ? [2007-05-25 19:30:45] dbjh at gmx dot net Last message before I start looking at source code. On both Fedora Core 4 and Red Hat Enterprise Linux (4 & 5) I used the configure options '--with-config-file-path=/etc' and '--with-config-file-scan-dir=/etc/php.d'. [2007-05-25 19:18:14] dbjh at gmx dot net I should add that PHP 5.2.0 worked without problems on Fedora Core 4. I just compiled PHP 5.2.2 on Fedora Core 4 and there the problem doesn't show up. 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/41497 -- Edit this bug report at http://bugs.php.net/?id=41497&edit=1
#41568 [Bgs->Asn]: PHP 5.2.3 php_mysql.dll and libmysql.dll not working?
ID: 41568 Updated by: [EMAIL PROTECTED] Reported By: Sephiroth dot PZC at gmail dot com -Status: Bogus +Status: Assigned Bug Type: MySQL related Operating System: Windows XP PHP Version: 5.2.3 -Assigned To: +Assigned To: Andrey Previous Comments: [2007-06-12 11:53:20] [EMAIL PROTECTED] I'm not seeing this problem at all on any of my installs. PHP 5.2.3 using the MSI installer ( updated from 5.2.2 ) MySQL 5.0.41 using the MSI installer ( installed before PHP 5.2.3 ) phpinfo() reports using MySQL client API version 5.0.37 ( which is the version bundled with PHP 5.2.3 ). I think the problem is with the libmysql.dll from MySQL 5.0.41 being loaded instead of the one packaged with PHP. [2007-06-09 22:42:54] [EMAIL PROTECTED] If this isn't the case then please re-open this report. [2007-06-07 13:29:34] [EMAIL PROTECTED] The libmysql.dll from 5.0.41 can't be loaded dynamically due to a bug in MySQL more detail is available at http://bugs.mysql.com/bug.php?id=28358 If you're not using 5.0.41 or a 5.1 beta then you've most likely got other libmysql.dll files on your system somewhere that need removed. [2007-06-07 13:16:50] Seth at nospam dot com Forgot to write that PDO MySQL driver is not working neighter [2007-06-07 13:13:57] Seth at nospam dot com Got same bug under XP and Apache 2.2 Unfortunetly downgrade dosen't work 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/41568 -- Edit this bug report at http://bugs.php.net/?id=41568&edit=1
#41748 [Opn]: exif_read_data returns corrupted GPS data
ID: 41748
Updated by: [EMAIL PROTECTED]
Reported By: frederic dot maziere1 at neuf dot fr
Status: Open
-Bug Type: PHP-GTK related
+Bug Type: EXIF related
Operating System: W2000 and WXP
PHP Version: 4.4.7
New Comment:
Moved bug to right category
Previous Comments:
[2007-06-20 12:37:57] frederic dot maziere1 at neuf dot fr
Description:
While it works on many files exif_read_data returns corrupted GPS data
on others.
exif_read_data returns bad latitude and longitude values for the
following file :
http://trekmaniac3.free.fr/Canaries2006/images/thumb/IMG_3801.jpg
FYI, xnview, robogeo (and others) are able to read and return correct
GPS data from that file. The expected values are :
latitude=27°38'26.39"
longitude=17°58'49.93"
When analyzing the data returns by exif_read_data, it looks like
there's a 3 value shift in the array of the rational values returned.
This problem occurs in every php version I tried : 4.3.10 or 5.2.0
Reproduce code:
---
$exif=exif_read_data('IMG_3801.jpg');
foreach ($exif as $key => $section) {
print_r($section);
foreach ($section as $name => $val) {
echo "$key.$name: $val\n";
}
}
Expected result:
GPSLatitude.0: 452984832/16777216
GPSLatitude.1: 637534208/16777216
GPSLatitude.2: 442812995/16777216
GPSLongitude.0:285212672/16777216
GPSLongitude.1:973078528/16777216
GPSLongitude.2:837753660/16777216
...
Actual result:
--
GPS tags returned :
GPSLatitude.0: 542065991/808334710
GPSLatitude.1: 3224110/452984832
GPSLatitude.2: 16777216/637534208
GPSLongitude.0: 16777216/442812995
GPSLongitude.1: 16777216/285212672
GPSLongitude.2: 16777216/973078528
GPSTimeStamp.0: 16777216/837753660
GPSTimeStamp.1: 16777216/9
GPSTimeStamp.2: 1/49
--
Edit this bug report at http://bugs.php.net/?id=41748&edit=1
#41350 [Asn]: Error in my_thread_global_end()
ID: 41350 Updated by: [EMAIL PROTECTED] Reported By: graham at directhostinguk dot com Status: Assigned Bug Type: MySQL related Operating System: Windows 2003 PHP Version: 5.2.2 Assigned To: georg New Comment: Is everyone running a CGI implementation or ISAPI? Previous Comments: [2007-06-19 16:26:42] chris at crgs dot co dot uk Re short_open_tag option I have tested on my server with short_open_tag set to both 'on' and 'off' and get this problem whatever happens with PHP 5.2.3. The error occurs even with this page: [2007-06-18 19:33:57] curthenderson at hotmail dot com I have found that this error will come up if you are using short php opening tags http://bugs.mysql.com/bug.php?id=25621 for mysql bug report on same prob [2007-06-12 16:31:54] chris at crgs dot co dot uk Still a problem on PHP 5.2.3 under Windows Server 2003 / IIS 6 / MySQL 5.0.41. Can be fixed by copying libmysql.dll from PHP 5.2.1. Seems as if neither side wants to take ownership of the bug. MySQL people seem to say it's a PHP issue (see http://bugs.mysql.com/bug.php?id=25621), but not much seems to be happening here. Can someone please fix this bug before the next release of PHP? [2007-05-31 08:15:58] louis at steelbytes dot com repro on win2k3. reverting libmysql.dll to 5.2.1 fixes it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/41350 -- Edit this bug report at http://bugs.php.net/?id=41350&edit=1
#41744 [Opn->Fbk]: about try...catch...
ID: 41744
Updated by: [EMAIL PROTECTED]
Reported By: edwardhey at 163 dot com
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: freebsd
PHP Version: 5.2.1
Previous Comments:
[2007-06-20 10:03:40] [EMAIL PROTECTED]
And why do you report bugs in old releases? The latest is 5.2.3..you
have 5.2.1!
[2007-06-20 10:02:40] [EMAIL PROTECTED]
First you need to disable all 3rd party extensions, like any Zend
extensions.
[2007-06-20 07:20:47] edwardhey at 163 dot com
yes,i have
about this:
Zend Extension 220060519
My phpinfo information:
http://www.phpoo.cn/tan/iProber.php?act=phpinfo
thanks a lot!
[2007-06-20 07:01:21] [EMAIL PROTECTED]
Do you have any extensions loaded, particularly "Zend" extensions?
[2007-06-20 00:42:30] edwardhey at 163 dot com
Description:
hi~!
when i use 'try' to catch the 'exception',the server throw me the
Fatal error.
php: php5.2.1/fastcgi
server: apache2.2.3
Reproduce code:
---
getMessage(), "\n";
}
echo 'Hello World';
?>
Expected result:
Fatal error: Uncaught exception 'Exception' with message 'Always throw
this error' in /www/phpoo.cn/htdocs/test.php:4 Stack trace: #0 {main}
thrown in /www/phpoo.cn/htdocs/test.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=41744&edit=1
#41749 [Opn]: Reproducible segfault in PCRE lib
ID: 41749 User updated by: joe at emomentum dot co dot uk -Summary: eproducible segfault in PCRE lib Reported By: joe at emomentum dot co dot uk Status: Open Bug Type: Reproducible crash Operating System: Debian Etch (Debian 4.0 Stable) PHP Version: 5.2.0 New Comment: ... seems I can't edit that, ignore :) Previous Comments: [2007-06-20 14:45:46] joe at emomentum dot co dot uk fixed typo. [2007-06-20 14:40:11] joe at emomentum dot co dot uk Description: Couldn't see this anywhere else (similar but not close enough). Located an apparent bug in the PCRE library, although this might be relating to the way PHP calls the library (I'll post this to the PCRE list as well). Reproducable if slightly random crash occurs when using regex's with certain hex strings on longish (and random) strings. Weirdly, the length of the string directly relates to the chance of a segfault, and the segfault only occurs with certain ranges of hex strings (specifically, ONLY over x7A and ONLY with text strings of exactly 4843 bytes or longer). Note that using the regex /^([\x00-\x7A])*$/ causes a segfault, whereas /^([\x00-\x71])*$/ or /^([\x00-\x79])*$/ does not. Running on Debian Etch 64bit (amd64) with latest stable PHP and libpcre3_6.7-1_amd64 installed. Regards, Joe Harris Senior Developer eMomentum Limited Reproduce code: --- Expected result: int(0) (false, never going to match a-z random string) Actual result: -- Segmentation fault (core dumped) - when running in gdb: This GDB was configured as "x86_64-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run test.php Starting program: /usr/bin/php test.php (no debugging symbols found) [snip - lots of these] (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 47782002024432 (LWP 11134)] (no debugging symbols found) [snip - lots of these] (no debugging symbols found) testing a string of 4846 bytes in length Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47782002024432 (LWP 11134)] 0x2b751be871a8 in pcre_dfa_exec () from /usr/lib/libpcre.so.3 -- Edit this bug report at http://bugs.php.net/?id=41749&edit=1
#41749 [Opn]: eproducible segfault in PCRE lib
ID: 41749 User updated by: joe at emomentum dot co dot uk -Summary: reproducable segfault in PCRE lib Reported By: joe at emomentum dot co dot uk Status: Open Bug Type: Reproducible crash Operating System: Debian Etch (Debian 4.0 Stable) -PHP Version: 5.2.3 +PHP Version: 5.2.0 New Comment: fixed typo. Previous Comments: [2007-06-20 14:40:11] joe at emomentum dot co dot uk Description: Couldn't see this anywhere else (similar but not close enough). Located an apparent bug in the PCRE library, although this might be relating to the way PHP calls the library (I'll post this to the PCRE list as well). Reproducable if slightly random crash occurs when using regex's with certain hex strings on longish (and random) strings. Weirdly, the length of the string directly relates to the chance of a segfault, and the segfault only occurs with certain ranges of hex strings (specifically, ONLY over x7A and ONLY with text strings of exactly 4843 bytes or longer). Note that using the regex /^([\x00-\x7A])*$/ causes a segfault, whereas /^([\x00-\x71])*$/ or /^([\x00-\x79])*$/ does not. Running on Debian Etch 64bit (amd64) with latest stable PHP and libpcre3_6.7-1_amd64 installed. Regards, Joe Harris Senior Developer eMomentum Limited Reproduce code: --- Expected result: int(0) (false, never going to match a-z random string) Actual result: -- Segmentation fault (core dumped) - when running in gdb: This GDB was configured as "x86_64-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run test.php Starting program: /usr/bin/php test.php (no debugging symbols found) [snip - lots of these] (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 47782002024432 (LWP 11134)] (no debugging symbols found) [snip - lots of these] (no debugging symbols found) testing a string of 4846 bytes in length Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47782002024432 (LWP 11134)] 0x2b751be871a8 in pcre_dfa_exec () from /usr/lib/libpcre.so.3 -- Edit this bug report at http://bugs.php.net/?id=41749&edit=1
#41749 [NEW]: reproducable segfault in PCRE lib
From: joe at emomentum dot co dot uk Operating system: Debian Etch (Debian 4.0 Stable) PHP version: 5.2.3 PHP Bug Type: Reproducible crash Bug description: reproducable segfault in PCRE lib Description: Couldn't see this anywhere else (similar but not close enough). Located an apparent bug in the PCRE library, although this might be relating to the way PHP calls the library (I'll post this to the PCRE list as well). Reproducable if slightly random crash occurs when using regex's with certain hex strings on longish (and random) strings. Weirdly, the length of the string directly relates to the chance of a segfault, and the segfault only occurs with certain ranges of hex strings (specifically, ONLY over x7A and ONLY with text strings of exactly 4843 bytes or longer). Note that using the regex /^([\x00-\x7A])*$/ causes a segfault, whereas /^([\x00-\x71])*$/ or /^([\x00-\x79])*$/ does not. Running on Debian Etch 64bit (amd64) with latest stable PHP and libpcre3_6.7-1_amd64 installed. Regards, Joe Harris Senior Developer eMomentum Limited Reproduce code: --- Expected result: int(0) (false, never going to match a-z random string) Actual result: -- Segmentation fault (core dumped) - when running in gdb: This GDB was configured as "x86_64-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run test.php Starting program: /usr/bin/php test.php (no debugging symbols found) [snip - lots of these] (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 47782002024432 (LWP 11134)] (no debugging symbols found) [snip - lots of these] (no debugging symbols found) testing a string of 4846 bytes in length Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47782002024432 (LWP 11134)] 0x2b751be871a8 in pcre_dfa_exec () from /usr/lib/libpcre.so.3 -- Edit bug report at http://bugs.php.net/?id=41749&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41749&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41749&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41749&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41749&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41749&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41749&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41749&r=needscript Try newer version:http://bugs.php.net/fix.php?id=41749&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41749&r=support Expected behavior:http://bugs.php.net/fix.php?id=41749&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41749&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41749&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41749&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41749&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41749&r=dst IIS Stability:http://bugs.php.net/fix.php?id=41749&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41749&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41749&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41749&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41749&r=mysqlcfg
#37898 [Com]: strip_tags selectively strips allowed_tags
ID: 37898
Comment by: vorandrew+php at gmail dot com
Reported By: admin at rcczone dot com
Status: No Feedback
Bug Type: Strings related
Operating System: Linux / Apache
PHP Version: 4.4.2
New Comment:
Linux IGMAPPSERV 2.6.18-4-686 #1 SMP Mon Mar 26 17:17:36 UTC 2007 i686
GNU/Linux
Packages
==
ii libapache2-mod-php5 5.2.0-8+etch4
server-side, HTML-embedded scripting languag
ii php-pear 5.2.0-8+etch4
PEAR - PHP Extension and Application Reposit
ii php5 5.2.0-8+etch4
server-side, HTML-embedded scripting languag
ii php5-cli 5.2.0-8+etch4
command-line interpreter for the php5 script
ii php5-common 5.2.0-8+etch4
Common files for packages built from the php
ii php5-dev 5.2.0-8+etch4
Files for PHP5 module development
ii php5-gd 5.2.0-8+etch4
GD module for php5
ii php5-imagick 0.9.11+1-4.1
ImageMagick module for php5
ii php5-mysql5.2.0-8+etch4
MySQL module for php5
ii php5-sqlite 5.2.0-8+etch4
SQLite module for php5
ii phpmyadmin2.9.1.1-3
Administrate MySQL over the WWW
Previous Comments:
[2007-06-20 14:10:11] vorandrew+php at gmail dot com
Code:
=
'));
var_dump($text);
?>
Result:
=
string(218) "Cliquez "TELECHARGEZ MAINTENANT" pour commencer
l'instalation du logiciel de Casino Las Vegas
Cliquez à nouveau sur "Ouvrir (Run)" (ou
"Ouvrir- Open")."
string(103) "Cliquez "TELECHARGEZ MAINTENANT" pour commencer
l'instalation du logiciel de Casino Las Vegas"
[2006-07-30 01:00:01] 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-07-22 12:15:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-06-23 02:53:09] admin at rcczone dot com
Description:
For some reason beyond my knowledge, the strip_tags function is
selectively stripping allowed_tags. I have tested it against three
relatively similar strings (all tags) and it passing on only one
out of the three. The string and xhtml tags themselves are perfectly
valid, and I have no clue why strip_tags is behaving in such a way.
Reproduce code:
---
echo strip_tags('http://www.picturetrail.com/photoFlick/l_bookhorizontal.swf";
name="photoFlick"
FlashVars="img1=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756363.jpg&img2=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756370.jpg&img3=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756373.jpg&img4=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756375.jpg&img5=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756377.jpg&img6=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756379.jpg&img7=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756381.jpg&img8=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756384.jpg&img9=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756386.jpg&img10=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756388.jpg&img11=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756391.jpg&img12=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756394.jpg&img13=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/!
139756395.jpg&img14=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756397.jpg";
loop="false" menu="false" quality="high" bgcolor="..ff" width="600"
height="410" align="middle" allowScriptAccess="never"
type="application/x-shockwave-flash"
pluginspage="http://www.macromedia.com/go/getflashplayer";>','');
Expected result:
http://www.picturetrail.com/photoFlick/l_bookhorizontal.swf";
name="photoFlick"
FlashVars="img1=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756363.jpg&img2=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756370.jpg&img3=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756373.jpg&img4=http://pic20.picturetrail.com:80/VOL1204/4617287/98090
#37898 [Com]: strip_tags selectively strips allowed_tags
ID: 37898
Comment by: vorandrew+php at gmail dot com
Reported By: admin at rcczone dot com
Status: No Feedback
Bug Type: Strings related
Operating System: Linux / Apache
PHP Version: 4.4.2
New Comment:
Code:
=
'));
var_dump($text);
?>
Result:
=
string(218) "Cliquez "TELECHARGEZ MAINTENANT" pour commencer
l'instalation du logiciel de Casino Las Vegas
Cliquez à nouveau sur "Ouvrir (Run)" (ou
"Ouvrir- Open")."
string(103) "Cliquez "TELECHARGEZ MAINTENANT" pour commencer
l'instalation du logiciel de Casino Las Vegas"
Previous Comments:
[2006-07-30 01:00:01] 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-07-22 12:15:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-06-23 02:53:09] admin at rcczone dot com
Description:
For some reason beyond my knowledge, the strip_tags function is
selectively stripping allowed_tags. I have tested it against three
relatively similar strings (all tags) and it passing on only one
out of the three. The string and xhtml tags themselves are perfectly
valid, and I have no clue why strip_tags is behaving in such a way.
Reproduce code:
---
echo strip_tags('http://www.picturetrail.com/photoFlick/l_bookhorizontal.swf";
name="photoFlick"
FlashVars="img1=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756363.jpg&img2=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756370.jpg&img3=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756373.jpg&img4=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756375.jpg&img5=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756377.jpg&img6=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756379.jpg&img7=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756381.jpg&img8=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756384.jpg&img9=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756386.jpg&img10=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756388.jpg&img11=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756391.jpg&img12=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756394.jpg&img13=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/!
139756395.jpg&img14=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756397.jpg";
loop="false" menu="false" quality="high" bgcolor="..ff" width="600"
height="410" align="middle" allowScriptAccess="never"
type="application/x-shockwave-flash"
pluginspage="http://www.macromedia.com/go/getflashplayer";>','');
Expected result:
http://www.picturetrail.com/photoFlick/l_bookhorizontal.swf";
name="photoFlick"
FlashVars="img1=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756363.jpg&img2=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756370.jpg&img3=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756373.jpg&img4=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756375.jpg&img5=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756377.jpg&img6=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756379.jpg&img7=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756381.jpg&img8=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756384.jpg&img9=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756386.jpg&img10=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756388.jpg&img11=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756391.jpg&img12=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756394.jpg&img13=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/!
139756395.jpg&img14=http://pic20.picturetrail.com:80/VOL1204/4617287/9809076/139756397.jpg";
loop="false" menu="false" quality="high" bgcolor="..ff" width="600"
height="410" align="middle" allowScriptAccess="never"
type="application/x-shockwave-flash"
pluginspage="http://www.macromedia.com/go/getflashplayer";>
Actual result:
--
--
Edit this bug report at http://bugs.php.net/?id=37898&edit=1
#41485 [NoF->Opn]: segmentation fault parsing wrong xsl file
ID: 41485 User updated by: andyjunkie at tiscali dot it Reported By: andyjunkie at tiscali dot it -Status: No Feedback +Status: Open Bug Type: Reproducible crash Operating System: linux debian PHP Version: 5.2.2 New Comment: No crash from command line. Crashes with: Debian 2.6.18-4-686 Apache/2.2.3 (Debian) PHP/5.2.0-8+etch4 libxml2 2.6.27 libxslt 1.1.19 Previous Comments: [2007-06-16 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-08 01:12:54] [EMAIL PROTECTED] Works for me on Linux Fedora 6. [2007-06-01 15:00:52] [EMAIL PROTECTED] You might want to try using xsltproc command line to see if it crashes there as well (indicating not a PHP issue). Also, try upgrading your libxml2 and libxslt libraries. It's working fine on linux with libxml2-2.6.23 and libxslt-1.1.15 [2007-06-01 14:33:15] andyjunkie at tiscali dot it http://www.w3.org/1999/XSL/Transform";> '; $xsltProcessor = new XSLTProcessor(); $xslDom = new DOMDocument(); $xslDom->loadXML($xsl); $xsltProcessor->importStyleSheet($xslDom); ?> [2007-06-01 14:27:54] andyjunkie at tiscali dot it Here is the script: load(dirname(__FILE__).'/test.xsl'); $xsltProcessor->importStyleSheet($xslDom); // SEG FAULT ?> This is the content of "test.xsl", note that tag is not closed http://www.w3.org/1999/XSL/Transform";> 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/41485 -- Edit this bug report at http://bugs.php.net/?id=41485&edit=1
#41732 [Com]: Bare LFs in SMTP
ID: 41732
Comment by: bas at tobin dot nl
Reported By: as at as dot hu
Status: Open
Bug Type: Mail related
Operating System: Windows 2003
PHP Version: 4.4.7
New Comment:
Hi,
This is not a bug of PHP.
E-Mail being transferred between mail servers needs CrLf (\r\n) as EOL
separator. The catch however is how PHP sends the mail to your outbound
mail server. On windows you always need to separate mail headers and end
of lines with CrLf as this is the standard windows EOL separator. On
Linux this depends on the mail injector of your Mail Server. For
instance qmail expects the EOL separator to be the same as the standard
linux separator Lf(\n) and when sending the message outbound converts
all these Lf's to CrLf. If you feed this script with CrLf you will send
E-Mail messages having extra white lines.
If your PHP script does not send the message to a typical local mail
injector but to a normal inbound mail port it will have to follow RFC's
and CrLf will be needed again.
So depending on your setup you either need to send CrLf or Lf between
lines.
Previous Comments:
[2007-06-18 20:32:03] as at as dot hu
Description:
On Windows 2003, default smtp server.
When I use the mail function, some target e-mail system say:
195.56.151.XX, OutboundConnectionResponse, 2007. 06. 18., 22:06:43,
SMTPSVC1, AS, -, 312, 0, 47, 0, 0, -, -, 451 See
http://pobox.com/~djb/docs/smtplf.html.,
Reproduce code:
---
$subject = "Elveszett jelszó";
$headers = "From: ".$mail_pswd_from."\nX-FW-MailID:s6s06s9s80";
$row=mysql_fetch_array($result);
$to = $row['usr_email'];
$body = "Tisztelt ".$row[usr_lastname]." ".$row[usr_firstname]."!\nAz
Ön jelszava: ".$row[usr_pswd]."\n\nÜdvözlettel,\nA S";
mail($to,$subject,$body,$headers);
Expected result:
The email bounce to the sender from some hosts. (like citromail.hu,
vipmail.hu) with this error message:
http://pobox.com/~djb/docs/smtplf.html
Actual result:
--
When I replace all newline to CRLF, the mail went away without
problem:
$subject = "Elveszett jelszó";
$headers = "From: ".$mail_pswd_from."\nX-FW-MailID:s6s06s9s80";
$row=mysql_fetch_array($result);
$to = $row['usr_email'];
$body = "Tisztelt ".$row[usr_lastname]." ".$row[usr_firstname]."!\nAz
Ön jelszava: ".$row[usr_pswd]."\n\nÜdvözlettel,\nA S";
$body = str_replace("\r\n","\n",$body);
$body = str_replace("\r","\n",$body);
$body = str_replace("\n","\r\n",$body);
mail($to,$subject,$body,$headers);
--
Edit this bug report at http://bugs.php.net/?id=41732&edit=1
#34647 [Com]: mssql.timeout has no affect
ID: 34647
Comment by: jochem dot blok at fasterforward dot nl
Reported By: j dot geusebroek at intellit dot nl
Status: No Feedback
Bug Type: MSSQL related
Operating System: Suse 9.3
PHP Version: 5.0.5
Assigned To: fmk
New Comment:
I also have this problem with PHP 5.2.0.
mssql.timeout is set to Local Value 60 and Master Value 60. Php doesn't
time out. I have a query which run over 60 seconds.
Previous Comments:
[2007-06-15 11:36:39] sarstrom at gmail dot com
I'm sorry, but setting the timeouts in php.ini doesn't help either.
phpinfo() confirms that the limit is set to 1 second, but it waits an
infinite amount of time for the query to finish!
Deliberatly making a self-join-query will lock up one php-thread
forever, after all threads are locked up, the webserver won't answer any
further requests.
/hps
[2007-06-14 16:47:33] [EMAIL PROTECTED]
The two time out parameters is used during request startup and it will
not have any effect to change the value at runtime.
I'll look at a way to move these to the connect/query functions, but
until then you should specify these in your php.ini file.
[2007-06-13 11:30:52] sarstrom at gmail dot com
I can still reproduce this problem as of 2007-06-13.
I've tried with PHP 5.2.1 and 5.2.3, And FreeTDS is at 0.64
on a FreeBSD 6.1 install.
This code always waits the 20 seconds and tells me that everything went
according to plan
$dbLink = mssql_connect('sqldmz','sosuser','123456');
ini_set('mssql.timeout','1');
$query = "WAITFOR DELAY '000:00:20' SELECT TOP 1 * FROM
tbl_serviceorder";
$res = mssql_query($query,$dbLink);
if(!$res) {
echo 'No, error, warning, timeout!';
}
else {
$row = mssql_fetch_assoc($res);
echo 'Everything is OK: '.$row['OrderNumber'];
}
/hps
[2005-11-14 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".
[2005-11-06 23:19:58] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
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/34647
--
Edit this bug report at http://bugs.php.net/?id=34647&edit=1
#41744 [Fbk->Opn]: about try...catch...
ID: 41744
User updated by: edwardhey at 163 dot com
Reported By: edwardhey at 163 dot com
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: freebsd
PHP Version: 5.2.1
New Comment:
ok~ i will try, thanks a lot! and i will update my php!
Previous Comments:
[2007-06-20 10:03:40] [EMAIL PROTECTED]
And why do you report bugs in old releases? The latest is 5.2.3..you
have 5.2.1!
[2007-06-20 10:02:40] [EMAIL PROTECTED]
First you need to disable all 3rd party extensions, like any Zend
extensions.
[2007-06-20 07:20:47] edwardhey at 163 dot com
yes,i have
about this:
Zend Extension 220060519
My phpinfo information:
http://www.phpoo.cn/tan/iProber.php?act=phpinfo
thanks a lot!
[2007-06-20 07:01:21] [EMAIL PROTECTED]
Do you have any extensions loaded, particularly "Zend" extensions?
[2007-06-20 00:42:30] edwardhey at 163 dot com
Description:
hi~!
when i use 'try' to catch the 'exception',the server throw me the
Fatal error.
php: php5.2.1/fastcgi
server: apache2.2.3
Reproduce code:
---
getMessage(), "\n";
}
echo 'Hello World';
?>
Expected result:
Fatal error: Uncaught exception 'Exception' with message 'Always throw
this error' in /www/phpoo.cn/htdocs/test.php:4 Stack trace: #0 {main}
thrown in /www/phpoo.cn/htdocs/test.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=41744&edit=1
#41744 [Fbk]: about try...catch...
ID: 41744
Updated by: [EMAIL PROTECTED]
Reported By: edwardhey at 163 dot com
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: freebsd
-PHP Version: 5.2.3
+PHP Version: 5.2.1
New Comment:
And why do you report bugs in old releases? The latest is 5.2.3..you
have 5.2.1!
Previous Comments:
[2007-06-20 10:02:40] [EMAIL PROTECTED]
First you need to disable all 3rd party extensions, like any Zend
extensions.
[2007-06-20 07:20:47] edwardhey at 163 dot com
yes,i have
about this:
Zend Extension 220060519
My phpinfo information:
http://www.phpoo.cn/tan/iProber.php?act=phpinfo
thanks a lot!
[2007-06-20 07:01:21] [EMAIL PROTECTED]
Do you have any extensions loaded, particularly "Zend" extensions?
[2007-06-20 00:42:30] edwardhey at 163 dot com
Description:
hi~!
when i use 'try' to catch the 'exception',the server throw me the
Fatal error.
php: php5.2.1/fastcgi
server: apache2.2.3
Reproduce code:
---
getMessage(), "\n";
}
echo 'Hello World';
?>
Expected result:
Fatal error: Uncaught exception 'Exception' with message 'Always throw
this error' in /www/phpoo.cn/htdocs/test.php:4 Stack trace: #0 {main}
thrown in /www/phpoo.cn/htdocs/test.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=41744&edit=1
#41744 [Opn->Fbk]: about try...catch...
ID: 41744
Updated by: [EMAIL PROTECTED]
Reported By: edwardhey at 163 dot com
-Status: Open
+Status: Feedback
-Bug Type: Unknown/Other Function
+Bug Type: Scripting Engine problem
Operating System: freebsd
PHP Version: 5.2.3
New Comment:
First you need to disable all 3rd party extensions, like any Zend
extensions.
Previous Comments:
[2007-06-20 07:20:47] edwardhey at 163 dot com
yes,i have
about this:
Zend Extension 220060519
My phpinfo information:
http://www.phpoo.cn/tan/iProber.php?act=phpinfo
thanks a lot!
[2007-06-20 07:01:21] [EMAIL PROTECTED]
Do you have any extensions loaded, particularly "Zend" extensions?
[2007-06-20 00:42:30] edwardhey at 163 dot com
Description:
hi~!
when i use 'try' to catch the 'exception',the server throw me the
Fatal error.
php: php5.2.1/fastcgi
server: apache2.2.3
Reproduce code:
---
getMessage(), "\n";
}
echo 'Hello World';
?>
Expected result:
Fatal error: Uncaught exception 'Exception' with message 'Always throw
this error' in /www/phpoo.cn/htdocs/test.php:4 Stack trace: #0 {main}
thrown in /www/phpoo.cn/htdocs/test.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=41744&edit=1
#41740 [Opn->Fbk]: XML Declaration Error
ID: 41740 Updated by: [EMAIL PROTECTED] Reported By: dgrimes at scvl dot com -Status: Open +Status: Feedback Bug Type: *XML functions Operating System: Compaq Tru64 PHP Version: 5.2.3 New Comment: Try updating libxml2. I cant reproduce this (testing with 2.6.26 and higher). Previous Comments: [2007-06-19 17:49:12] dgrimes at scvl dot com Description: I'm getting the following error: XML error: XML declaration not finished at line 1 Here is the xml code: Tove Jani Reminder Don't forget me this weekend! However, if I remove line one completely the code works but I can't have any reference to . Reproduce code: --- I took this code from the php.net xml examples. Everyghing works OK in php4 but not php5. Here is the test program: Expected result: NOTE TO FROM HEADING BODY This was run with the above code without the line. Actual result: -- XML error: XML declaration not finished at line 1 Run with the same code with the line. -- Edit this bug report at http://bugs.php.net/?id=41740&edit=1
#41747 [Opn->Bgs]: Performance Issue with Array Removals
ID: 41747
Updated by: [EMAIL PROTECTED]
Reported By: martinmrozster at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Performance problem
Operating System: Linux 2.6
PHP Version: 5.2.3
New Comment:
.
Previous Comments:
[2007-06-20 09:08:37] martinmrozster at gmail dot com
Description:
FOR THE LOVE OF GOD AND ALL THAT IS HOLY
I can't believe your insane stupidity. You are telling me that the
only way of REMOVING AN OBJECT FROM AN ARRAY IS TO USE YOUR OWN CODE?!
WHO IN THEIR RIGHT MIND WRITES A _HIGH_LEVEL LANGUAGE AND
EXCLUDES THE MOST BASIC ARRAY FUNCTIONALITY?! WHERE IN GODS NAME DO
YOU GET THE IDEA THAT YOU ARE EVEN ALLOWED TO LIVE?!?!?!
I HAVE SPENT THE LAST HOUR FINDING OUT THAT unset() DOES NOT UPDATE
THE INICES IN AN ARRAY THAT YOU REMOVE AN OBJECT FROM - I MEAN JESUS
FUCKING CHRIST I THIS IS SO FAR BEYOND INSANE THAT YOU SHOULD BE SHOT
IN THE FACE AND LEFT TO DIE A HORRIBLE PAINFUL DEATH.
Lets calm down for a second and just think to ourselves
Objective-C NSArray: [obj removeObjectAtIndex:] [arr removeObject]
[arr removeObjectsInRange] AND MORE
.NET: array.removeAt(), array.remove(), array.removeRange, and
FRIENDS.
Ruby: array.remove, array.remove_at
JavaScript: array.splice(index, howMany)
CoreFoundation: CFArrayRemove()
PERL: splice
PHP: INSERT FUNCTION HERE, LIKE, OH I DUNNO, MINE:
function array_remove(&$array, $key) {
$newArray = array();
foreach($array as $dumbassFuckingKey=>$value) {
if($dumbassFuckingKey != $key) {
$newArray[] = $value;
}
}
$array = $newArray;
}
Reproduce code:
---
function array_remove(&$array, $key) {
$newArray = array();
foreach($array as $dumbassFuckingKey=>$value) {
if($dumbassFuckingKey != $key) {
$newArray[] = $value;
}
}
$array = $newArray;
}
Expected result:
Well, I EXPECTED YOU TO PROVIDE ME A FUCKING FUNCTION TO REMOVE A VALUE
FROM A GOD DAMNED ARRAY.
Actual result:
--
YOU DIDNT.
--
Edit this bug report at http://bugs.php.net/?id=41747&edit=1
#41747 [NEW]: Performance Issue with Array Removals
From: martinmrozster at gmail dot com
Operating system: Linux 2.6
PHP version: 5.2.3
PHP Bug Type: Performance problem
Bug description: Performance Issue with Array Removals
Description:
FOR THE LOVE OF GOD AND ALL THAT IS HOLY
I can't believe your insane stupidity. You are telling me that the
only way of REMOVING AN OBJECT FROM AN ARRAY IS TO USE YOUR OWN CODE?!
WHO IN THEIR RIGHT MIND WRITES A _HIGH_LEVEL LANGUAGE AND
EXCLUDES THE MOST BASIC ARRAY FUNCTIONALITY?! WHERE IN GODS NAME DO
YOU GET THE IDEA THAT YOU ARE EVEN ALLOWED TO LIVE?!?!?!
I HAVE SPENT THE LAST HOUR FINDING OUT THAT unset() DOES NOT UPDATE
THE INICES IN AN ARRAY THAT YOU REMOVE AN OBJECT FROM - I MEAN JESUS
FUCKING CHRIST I THIS IS SO FAR BEYOND INSANE THAT YOU SHOULD BE SHOT
IN THE FACE AND LEFT TO DIE A HORRIBLE PAINFUL DEATH.
Lets calm down for a second and just think to ourselves
Objective-C NSArray: [obj removeObjectAtIndex:] [arr removeObject]
[arr removeObjectsInRange] AND MORE
.NET: array.removeAt(), array.remove(), array.removeRange, and
FRIENDS.
Ruby: array.remove, array.remove_at
JavaScript: array.splice(index, howMany)
CoreFoundation: CFArrayRemove()
PERL: splice
PHP: INSERT FUNCTION HERE, LIKE, OH I DUNNO, MINE:
function array_remove(&$array, $key) {
$newArray = array();
foreach($array as $dumbassFuckingKey=>$value) {
if($dumbassFuckingKey != $key) {
$newArray[] = $value;
}
}
$array = $newArray;
}
Reproduce code:
---
function array_remove(&$array, $key) {
$newArray = array();
foreach($array as $dumbassFuckingKey=>$value) {
if($dumbassFuckingKey != $key) {
$newArray[] = $value;
}
}
$array = $newArray;
}
Expected result:
Well, I EXPECTED YOU TO PROVIDE ME A FUCKING FUNCTION TO REMOVE A VALUE
FROM A GOD DAMNED ARRAY.
Actual result:
--
YOU DIDNT.
--
Edit bug report at http://bugs.php.net/?id=41747&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41747&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41747&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41747&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41747&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41747&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41747&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41747&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41747&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41747&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41747&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41747&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41747&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41747&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41747&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41747&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41747&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41747&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41747&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41747&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41747&r=mysqlcfg
#41746 [NEW]: post_max_size and upload_max_filesize capped to 32-bit
From: bio at blarg dot ru Operating system: Linux PHP version: 5.2.3 PHP Bug Type: *Configuration Issues Bug description: post_max_size and upload_max_filesize capped to 32-bit Description: Setting post_max_size and/or upload_max_filesize to something more than 2 Gigabytes brokes file uploads completely, $_FILES always empty. -- Edit bug report at http://bugs.php.net/?id=41746&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41746&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41746&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41746&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41746&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41746&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41746&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41746&r=needscript Try newer version:http://bugs.php.net/fix.php?id=41746&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41746&r=support Expected behavior:http://bugs.php.net/fix.php?id=41746&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41746&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41746&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41746&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41746&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41746&r=dst IIS Stability:http://bugs.php.net/fix.php?id=41746&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41746&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41746&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41746&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41746&r=mysqlcfg
#41744 [Opn->Fbk]: about try...catch...
ID: 41744
Updated by: [EMAIL PROTECTED]
Reported By: edwardhey at 163 dot com
-Status: Open
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: freebsd
PHP Version: 5.2.3
New Comment:
Do you have any extensions loaded, particularly "Zend" extensions?
Previous Comments:
[2007-06-20 00:42:30] edwardhey at 163 dot com
Description:
hi~!
when i use 'try' to catch the 'exception',the server throw me the
Fatal error.
php: php5.2.1/fastcgi
server: apache2.2.3
Reproduce code:
---
getMessage(), "\n";
}
echo 'Hello World';
?>
Expected result:
Fatal error: Uncaught exception 'Exception' with message 'Always throw
this error' in /www/phpoo.cn/htdocs/test.php:4 Stack trace: #0 {main}
thrown in /www/phpoo.cn/htdocs/test.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=41744&edit=1
