Bug #45735 [Nab]: preg_match fails with Segmentation Fault on capturing subpattern
Edit report at https://bugs.php.net/bug.php?id=45735&edit=1 ID: 45735 Updated by: ras...@php.net Reported by:johnston dot joshua at gmail dot com Summary:preg_match fails with Segmentation Fault on capturing subpattern Status: Not a bug Type: Bug Package:PCRE related Operating System: * PHP Version:5.2CVS, 5.3CVS, 6CVS (2008-08-06) Block user comment: N Private report: N New Comment: The problem here is that there is no way to detect run-away regular expressions here without huge performance and memory penalties. Yes, we could build PCRE in a way that it wouldn't segfault and we could crank up the default backtrack limit to something huge, but it would slow every regex call down by a lot. If PCRE provided a way to handle this in a more graceful manner without the performance hit we would of course use it. Previous Comments: [2013-04-12 18:51:07] johnston dot joshua at gmail dot com I agree that something needs to be done about this bug on the php side that doesn't involve custom compiling pcre. In my case way back in '08, I found that the solution was misuse of capturing subpatterns. I was using () for grouping even though I did not need to match subpatterns. In reality I should have been using (:?) which solved my issue. [2013-04-12 18:40:49] josh dot adell at gmail dot com Just hit this bug today as well. It would be nice if PHP handled this more gracefully by triggering an error or warning instead of segfaulting. [2013-04-11 16:35:34] michael at writhem dot com why is this status not a bug? [2011-12-23 13:09:46] vojtech dot kurka at gmail dot com We have hit this bug today on 5.3.8, just sending 70KB variable as an input to preg_match_all(). Please fix this, it took us quite a lot of time to find the root cause. This should never cause a segfault. If the preg_match_all() function would throw a standard PHP error/warning, we would find the problem immeadiately. Debugging such problems is just a waste of time, this bugreport is more than 3 years old. [2011-12-15 14:42:35] josiecki at silvercube dot pl Why is this bug status set to "Bogus"? Seems to be unsolved since over three years, and I haven't found a single PHP installation that would not be vulnerable to this, including quite new 5.3.8 installation... 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 https://bugs.php.net/bug.php?id=45735 -- Edit this bug report at https://bugs.php.net/bug.php?id=45735&edit=1
[PHP-BUG] Bug #64641 [NEW]: imagefilledpolygon doesn't draw horizontal line
From: temposeb at free dot fr
Operating system: Win XP Pro SP3
PHP version: 5.3.24
Package: GD related
Bug Type: Bug
Bug description:imagefilledpolygon doesn't draw horizontal line
Description:
At worst imagefilledpolygon( ) doesn't render at all object composed
exclusively
of horizontal lines. No problem with vertical/diagonal lines or
imagepolygon( ).
Test script:
---
$image = imagecreatetruecolor(640, 480) ;
// Vertical line, drawn
$points = array(100, 100, 100, 200, 100, 300) ;
imagefilledpolygon($image, $points, 3, 0x00) ;
// Horizontal line, not drawn
$points = array(300, 200, 400, 200, 500, 200) ;
imagefilledpolygon($image, $points, 3, 0x00) ;
header('Content-Type: image/png') ;
imagepng($image) ;
Expected result:
Two objects rendered : 1 vertical line, 1 horizontal line.
Actual result:
--
One object rendered : 1 vertical line.
--
Edit bug report at https://bugs.php.net/bug.php?id=64641&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64641&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64641&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64641&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64641&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64641&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64641&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64641&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64641&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64641&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64641&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64641&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64641&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64641&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64641&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64641&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64641&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64641&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64641&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64641&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64641&r=mysqlcfg
Bug #45735 [Com]: preg_match fails with Segmentation Fault on capturing subpattern
Edit report at https://bugs.php.net/bug.php?id=45735&edit=1
ID: 45735
Comment by: johnston dot joshua at gmail dot com
Reported by:johnston dot joshua at gmail dot com
Summary:preg_match fails with Segmentation Fault on
capturing subpattern
Status: Not a bug
Type: Bug
Package:PCRE related
Operating System: *
PHP Version:5.2CVS, 5.3CVS, 6CVS (2008-08-06)
Block user comment: N
Private report: N
New Comment:
I agree that something needs to be done about this bug on the php side that
doesn't involve custom compiling pcre.
In my case way back in '08, I found that the solution was misuse of capturing
subpatterns. I was using () for grouping even though I did not need to match
subpatterns. In reality I should have been using (:?) which solved my issue.
Previous Comments:
[2013-04-12 18:40:49] josh dot adell at gmail dot com
Just hit this bug today as well. It would be nice if PHP handled this more
gracefully by triggering an error or warning instead of segfaulting.
[2013-04-11 16:35:34] michael at writhem dot com
why is this status not a bug?
[2011-12-23 13:09:46] vojtech dot kurka at gmail dot com
We have hit this bug today on 5.3.8, just sending 70KB variable as an input to
preg_match_all().
Please fix this, it took us quite a lot of time to find the root cause. This
should never cause a segfault. If the preg_match_all() function would throw a
standard PHP error/warning, we would find the problem immeadiately. Debugging
such problems is just a waste of time, this bugreport is more than 3 years old.
[2011-12-15 14:42:35] josiecki at silvercube dot pl
Why is this bug status set to "Bogus"? Seems to be unsolved since over three
years, and I haven't found a single PHP installation that would not be
vulnerable to this, including quite new 5.3.8 installation...
[2008-08-07 13:44:55] johnston dot joshua at gmail dot com
Just for my own personal knowledge, is it the capturing pattern the part that
causes the recursion?
If I remove the () part of the pattern I can keep adding 0's to the below code
I can trigger a php memory error but no seg fault.
jjohnston:~$ php -r 'preg_match("/http:\/\/.+\.ru/i",
str_repeat("http://google.ru";, 200));
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
https://bugs.php.net/bug.php?id=45735
--
Edit this bug report at https://bugs.php.net/bug.php?id=45735&edit=1
Bug #45735 [Com]: preg_match fails with Segmentation Fault on capturing subpattern
Edit report at https://bugs.php.net/bug.php?id=45735&edit=1
ID: 45735
Comment by: josh dot adell at gmail dot com
Reported by:johnston dot joshua at gmail dot com
Summary:preg_match fails with Segmentation Fault on
capturing subpattern
Status: Not a bug
Type: Bug
Package:PCRE related
Operating System: *
PHP Version:5.2CVS, 5.3CVS, 6CVS (2008-08-06)
Block user comment: N
Private report: N
New Comment:
Just hit this bug today as well. It would be nice if PHP handled this more
gracefully by triggering an error or warning instead of segfaulting.
Previous Comments:
[2013-04-11 16:35:34] michael at writhem dot com
why is this status not a bug?
[2011-12-23 13:09:46] vojtech dot kurka at gmail dot com
We have hit this bug today on 5.3.8, just sending 70KB variable as an input to
preg_match_all().
Please fix this, it took us quite a lot of time to find the root cause. This
should never cause a segfault. If the preg_match_all() function would throw a
standard PHP error/warning, we would find the problem immeadiately. Debugging
such problems is just a waste of time, this bugreport is more than 3 years old.
[2011-12-15 14:42:35] josiecki at silvercube dot pl
Why is this bug status set to "Bogus"? Seems to be unsolved since over three
years, and I haven't found a single PHP installation that would not be
vulnerable to this, including quite new 5.3.8 installation...
[2008-08-07 13:44:55] johnston dot joshua at gmail dot com
Just for my own personal knowledge, is it the capturing pattern the part that
causes the recursion?
If I remove the () part of the pattern I can keep adding 0's to the below code
I can trigger a php memory error but no seg fault.
jjohnston:~$ php -r 'preg_match("/http:\/\/.+\.ru/i",
str_repeat("http://google.ru";, 200));
[2008-08-07 11:27:29] lbarn...@php.net
I seen that PCRE has a NO_RECURSE flag to avoid the recursion in
match() (described in pcre_exec.c).
Defining NO_RECURSE at compile time avoids this problem :)
diff -u -r1.38.2.3.2.10.2.3 config0.m4
--- ext/pcre/config0.m4 2 Jun 2008 14:12:20 -
1.38.2.3.2.10.2.3
+++ ext/pcre/config0.m4 7 Aug 2008 11:25:39 -
@@ -59,7 +59,7 @@
pcrelib/pcre_ord2utf8.c
pcrelib/pcre_refcount.c pcrelib/pcre_study.c \
pcrelib/pcre_tables.c
pcrelib/pcre_try_flipped.c pcrelib/pcre_valid_utf8.c \
pcrelib/pcre_version.c
pcrelib/pcre_xclass.c"
-PHP_NEW_EXTENSION(pcre, $pcrelib_sources php_pcre.c, no,,-
+PHP_NEW_EXTENSION(pcre, $pcrelib_sources php_pcre.c, no,,-
PHP_ADD_BUILD_DIR($ext_builddir/pcrelib)
PHP_INSTALL_HEADERS([ext/pcre], [php_pcre.h pcrelib/])
AC_DEFINE(HAVE_BUNDLED_PCRE, 1, [ ])
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
https://bugs.php.net/bug.php?id=45735
--
Edit this bug report at https://bugs.php.net/bug.php?id=45735&edit=1
Bug #64637 [Opn]: redefine NULL
Edit report at https://bugs.php.net/bug.php?id=64637&edit=1
ID: 64637
User updated by:rstoll at tutteli dot ch
Reported by:rstoll at tutteli dot ch
Summary:redefine NULL
Status: Open
Type: Bug
Package:*Languages/Translation
Operating System: windows
PHP Version:5.4.7
Block user comment: N
Private report: N
New Comment:
strange that you do not have the same problem. However, a notice should already
be shown for the first usage of define.
Previous Comments:
[2013-04-12 16:57:14] anon at anon dot anon
Tested on PHP 5.3.5 on Windows and I just get NULL as output all four times,
and then the notice. Seems normal.
[2013-04-12 11:21:28] rstoll at tutteli dot ch
Maybe the bug only exists on windows.
I got the error for 5.4.7 and 5.3.5
[2013-04-12 04:14:04] larue...@php.net
http://3v4l.org/8knru
I didn't see a "hello world" outputted
[2013-04-11 23:23:28] rstoll at tutteli dot ch
Description:
It is possible to redefine NULL (however, not null). No one probably does that
but it should not be possible. Maybe there are more of this kind of errors.
Test script:
---
var_dump(null); // null
var_dump(NULL); // null
define("NULL","hello world");
var_dump(null); // null
var_dump(NULL); // hello world
define("null","hello world"); //Notice: Constant null already defined
--
Edit this bug report at https://bugs.php.net/bug.php?id=64637&edit=1
Bug #64637 [Com]: redefine NULL
Edit report at https://bugs.php.net/bug.php?id=64637&edit=1
ID: 64637
Comment by: anon at anon dot anon
Reported by:rstoll at tutteli dot ch
Summary:redefine NULL
Status: Open
Type: Bug
Package:*Languages/Translation
Operating System: windows
PHP Version:5.4.7
Block user comment: N
Private report: N
New Comment:
Tested on PHP 5.3.5 on Windows and I just get NULL as output all four times,
and then the notice. Seems normal.
Previous Comments:
[2013-04-12 11:21:28] rstoll at tutteli dot ch
Maybe the bug only exists on windows.
I got the error for 5.4.7 and 5.3.5
[2013-04-12 04:14:04] larue...@php.net
http://3v4l.org/8knru
I didn't see a "hello world" outputted
[2013-04-11 23:23:28] rstoll at tutteli dot ch
Description:
It is possible to redefine NULL (however, not null). No one probably does that
but it should not be possible. Maybe there are more of this kind of errors.
Test script:
---
var_dump(null); // null
var_dump(NULL); // null
define("NULL","hello world");
var_dump(null); // null
var_dump(NULL); // hello world
define("null","hello world"); //Notice: Constant null already defined
--
Edit this bug report at https://bugs.php.net/bug.php?id=64637&edit=1
Bug #64633 [Asn]: microtime regression - resolution reduced to 64 ticks per second
Edit report at https://bugs.php.net/bug.php?id=64633&edit=1
ID: 64633
User updated by:phpbugs at musiclogistics dot net
Reported by:phpbugs at musiclogistics dot net
Summary:microtime regression - resolution reduced to 64
ticks per second
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Windows 7
PHP Version:5.4.14
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
@a...@php.net: You are right: While usleep() only works in 1/64 second
increments on my machine (640 loops of "usleep(1)" take about 10 seconds), this
is not related to PHP 5.4.14. It's the same on 5.4.13 and probably a limitation
of Windows' multitasking.
Previous Comments:
[2013-04-12 11:29:36] paj...@php.net
We should use performance counters instead, which brings a much higher
precision
at less cost.
[2013-04-12 11:25:47] a...@php.net
This is a tradeoff one has to make, precision vs. accuracy. That's very
depending on the hardware. While on one system using the performance timer it
would work as expected, on another it's still more accurate time with a very
variable precision. That's where you could see in your snippet currentTimeMs()
- $startTimeMs < 0. That is much more weird than possibly having a worse
resolution, say currentTimeMs() - $startTimeMs == 0.
Heres' an interesting reading about this
http://blogs.msdn.com/b/oldnewthing/archive/2005/09/02/459952.aspx . The goal
of the latest fix is to remove the random results. Also this will work in most
cases as normally a script doesn't consist on just two subsequent microtime
calls. Starting with win8 there is a much better API, but it of course doesn't
help here. I'm not sure it should be touched, will look how to improve it
without getting to the old erroneous behaviour. Maybe reimplement the
performance timer part and make an ini option to let user decide if the
performance timer should be used. As we really cannot foresee every hardware
bugs.
Btw. usleep() isn't affected by that, it uses the waitable timer which has a
better resolution.
[2013-04-11 16:52:09] phpbugs at musiclogistics dot net
Description:
Probably caused by recent patch for bug #64370:
Since v 5.4.14 microtime() only moves forward in 15,6 ms (1/64 sec) increments
on Win7. Same for CLI and Apache 2.2 SAPI.
Build: VC9 x86 Thread Safe (2013-Apr-10 22:55:28) from windows.php.net.
Behaviour normal after downgrade to 5.4.13.
This also breaks usleep() (only sleeping for multiples of 15,6 ms now) and
uniqid() (returning the same value for 15,6 ms with $more_entropy = false).
Test script:
---
for ($startTimeMs = currentTimeMs(), $i = 0; $i < 1; $i++) {
//usleep(1);
echo (currentTimeMs() - $startTimeMs) . ' ';
}
function currentTimeMs() {
return round(microtime(true) * 100);
}
Expected result:
[what PHP 5.4.13 prints on the same machine:]
13 28 35 41 48 54 61 67 74 80 86 92 99 105 112 118 124 131 137 143 149 155 162
168 174 181 187 193 200 206 212 218 224 [...and so on]
Actual result:
--
0 0 0 0 0 0 0 0 0 [many more zeroes] 15600 15600 15600 15600 [...] 31200 31200
31200 31200 31200 [...] 46800 46800 46800 46800 46800 [...and so on]
--
Edit this bug report at https://bugs.php.net/bug.php?id=64633&edit=1
Bug #64636 [Fbk->Opn]: Segfault in scan from parse_date.c
Edit report at https://bugs.php.net/bug.php?id=64636&edit=1
ID: 64636
User updated by:shakaran at gmail dot com
Reported by:shakaran at gmail dot com
Summary:Segfault in scan from parse_date.c
-Status: Feedback
+Status: Open
Type: Bug
Package:Apache2 related
Operating System: Centos 5.9
PHP Version:5.3.24
Block user comment: N
Private report: N
New Comment:
I cannot provide a code example of this bug, because it is a production server
with hundred of shared users and I don't know what exact php code and moment
trigger the bug.
Also I am afraid that it is a cPanel PHP bug since that lines in parse_date.c
don't follow the stacktrace.
Sorry for the noise here, I learn the leason with cPanel PHP, next time I will
check first for a cPanel PHP bug and try to report in his support (but I am
afraid that the bug will be ignored by months). Thanks
Previous Comments:
[2013-04-12 13:15:20] johan...@php.net
Also please make sure this is not cpanel related (see also bug #64635)
[2013-04-12 04:15:04] larue...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2013-04-11 20:39:59] shakaran at gmail dot com
Another more different in this stacktrace:
(gdb) where
#0 0x2b657d1ed073 in scan (s=0x17560ea0 "imap_header", len=, errors=0x17560ea0, tzdb=0xd,
tz_get_wrapper=0x7fffcff08628) at /home/cpeasyapache/src/php-
5.3.23/ext/date/lib/parse_date.c:8374
#1 timelib_strtotime (s=0x17560ea0 "imap_header", len=,
errors=0x17560ea0, tzdb=0xd, tz_get_wrapper=0x7fffcff08628)
at /home/cpeasyapache/src/php-5.3.23/ext/date/lib/parse_date.c:24730
#2 0x in ?? ()
(gdb) thread apply all bt full
Thread 1 (Thread 0x2b657d0cdb40 (LWP 2470)):
#0 0x2b657d1ed073 in scan (s=0x17560ea0 "imap_header", len=, errors=0x17560ea0, tzdb=0xd,
tz_get_wrapper=0x7fffcff08628) at /home/cpeasyapache/src/php-
5.3.23/ext/date/lib/parse_date.c:8374
yych =
yyaccept = 0
cursor =
str = 0x17560ea0 "imap_header"
ptr = 0x17556590 ""
yybm = "\000\000\000\000\000\000\000\000\000d", '\000' ,
"d\000\000\000\000\000\000\000\000\000\000\200@\240`\000\002\002\002\002\002\002
\002\002\002\002\000\000\000\000\000\000\000", '\b' ,
"\000\000\000\000\000\000\030\030\030X\030\030\030X\030\030\030\030\030X\030\030
\030XXX\030\030\030\030\030\030", '\000'
#1 timelib_strtotime (s=0x17560ea0 "imap_header", len=,
errors=0x17560ea0, tzdb=0xd, tz_get_wrapper=0x7fffcff08628)
at /home/cpeasyapache/src/php-5.3.23/ext/date/lib/parse_date.c:24730
in = {fd = 0, lim = 0x0, str = 0x17560ea0 "imap_header", ptr =
0x51615639 ,
cur = 0xd , tok = 0x2b657da43e1c
"dns_get_record", pos = 0x2b657dde8320 "", line = 2099173936, len = 11109,
errors = 0x30ed950031, time = 0x7fffcff08510, tzdb = 0x0}
e =
#2 0x in ?? ()
No symbol table info available.
[2013-04-11 20:36:52] shakaran at gmail dot com
Description:
I am using cPanel with cpeasyapache and php 5.3.23.
I get a apache core file when parse_date.c: is used in scan.
I start gdb in the core file showing this:
# gdb /usr/local/apache/bin/httpd core.5886
GNU gdb (GDB) CentOS (7.0.1-45.el5.centos)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
Bug #64636 [Fbk]: Segfault in scan from parse_date.c
Edit report at https://bugs.php.net/bug.php?id=64636&edit=1
ID: 64636
Updated by: johan...@php.net
Reported by:shakaran at gmail dot com
Summary:Segfault in scan from parse_date.c
Status: Feedback
Type: Bug
Package:Apache2 related
Operating System: Centos 5.9
PHP Version:5.3.24
Block user comment: N
Private report: N
New Comment:
Also please make sure this is not cpanel related (see also bug #64635)
Previous Comments:
[2013-04-12 04:15:04] larue...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2013-04-11 20:39:59] shakaran at gmail dot com
Another more different in this stacktrace:
(gdb) where
#0 0x2b657d1ed073 in scan (s=0x17560ea0 "imap_header", len=, errors=0x17560ea0, tzdb=0xd,
tz_get_wrapper=0x7fffcff08628) at /home/cpeasyapache/src/php-
5.3.23/ext/date/lib/parse_date.c:8374
#1 timelib_strtotime (s=0x17560ea0 "imap_header", len=,
errors=0x17560ea0, tzdb=0xd, tz_get_wrapper=0x7fffcff08628)
at /home/cpeasyapache/src/php-5.3.23/ext/date/lib/parse_date.c:24730
#2 0x in ?? ()
(gdb) thread apply all bt full
Thread 1 (Thread 0x2b657d0cdb40 (LWP 2470)):
#0 0x2b657d1ed073 in scan (s=0x17560ea0 "imap_header", len=, errors=0x17560ea0, tzdb=0xd,
tz_get_wrapper=0x7fffcff08628) at /home/cpeasyapache/src/php-
5.3.23/ext/date/lib/parse_date.c:8374
yych =
yyaccept = 0
cursor =
str = 0x17560ea0 "imap_header"
ptr = 0x17556590 ""
yybm = "\000\000\000\000\000\000\000\000\000d", '\000' ,
"d\000\000\000\000\000\000\000\000\000\000\200@\240`\000\002\002\002\002\002\002
\002\002\002\002\000\000\000\000\000\000\000", '\b' ,
"\000\000\000\000\000\000\030\030\030X\030\030\030X\030\030\030\030\030X\030\030
\030XXX\030\030\030\030\030\030", '\000'
#1 timelib_strtotime (s=0x17560ea0 "imap_header", len=,
errors=0x17560ea0, tzdb=0xd, tz_get_wrapper=0x7fffcff08628)
at /home/cpeasyapache/src/php-5.3.23/ext/date/lib/parse_date.c:24730
in = {fd = 0, lim = 0x0, str = 0x17560ea0 "imap_header", ptr =
0x51615639 ,
cur = 0xd , tok = 0x2b657da43e1c
"dns_get_record", pos = 0x2b657dde8320 "", line = 2099173936, len = 11109,
errors = 0x30ed950031, time = 0x7fffcff08510, tzdb = 0x0}
e =
#2 0x in ?? ()
No symbol table info available.
[2013-04-11 20:36:52] shakaran at gmail dot com
Description:
I am using cPanel with cpeasyapache and php 5.3.23.
I get a apache core file when parse_date.c: is used in scan.
I start gdb in the core file showing this:
# gdb /usr/local/apache/bin/httpd core.5886
GNU gdb (GDB) CentOS (7.0.1-45.el5.centos)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
Req #54178 [Com]: make a better intl Locale::acceptFromHttp
Edit report at https://bugs.php.net/bug.php?id=54178&edit=1 ID: 54178 Comment by: millenium dot maestro at gmx dot de Reported by:giorgio dot liscio at email dot it Summary:make a better intl Locale::acceptFromHttp Status: Open Type: Feature/Change Request Package:I18N and L10N related PHP Version:5.3.5 Block user comment: N Private report: N New Comment: I agree! What kind of black magic does php use to detect the best supported language of my application? eg: Accept-Language:de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4 and now the application supports the locales "it-IT" and "en", but the result of Locale::acceptFromHttp is "de-DE". I'm pretty sure nobody will use a implementation with such useless results. weird enough the icu lib is supporting this behavior! see @ http://icu- project.org/apiref/icu4c/uloc_8h.html#aced06018568333e1906ae104ab62757a Previous Comments: [2011-03-07 09:14:49] giorgio dot liscio at email dot it Description: hi, would be nice to have some like this in the lib http://www.thefutureoftheweb.com/blog/use-accept-language-header the current implementation of Locale::acceptFromHttp is not useful at all thank you -- Edit this bug report at https://bugs.php.net/bug.php?id=54178&edit=1
Bug #64633 [Ver->Asn]: microtime regression - resolution reduced to 64 ticks per second
Edit report at https://bugs.php.net/bug.php?id=64633&edit=1
ID: 64633
Updated by: paj...@php.net
Reported by:phpbugs at musiclogistics dot net
Summary:microtime regression - resolution reduced to 64
ticks per second
-Status: Verified
+Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Windows 7
PHP Version:5.4.14
-Assigned To:
+Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
We should use performance counters instead, which brings a much higher
precision
at less cost.
Previous Comments:
[2013-04-12 11:25:47] a...@php.net
This is a tradeoff one has to make, precision vs. accuracy. That's very
depending on the hardware. While on one system using the performance timer it
would work as expected, on another it's still more accurate time with a very
variable precision. That's where you could see in your snippet currentTimeMs()
- $startTimeMs < 0. That is much more weird than possibly having a worse
resolution, say currentTimeMs() - $startTimeMs == 0.
Heres' an interesting reading about this
http://blogs.msdn.com/b/oldnewthing/archive/2005/09/02/459952.aspx . The goal
of the latest fix is to remove the random results. Also this will work in most
cases as normally a script doesn't consist on just two subsequent microtime
calls. Starting with win8 there is a much better API, but it of course doesn't
help here. I'm not sure it should be touched, will look how to improve it
without getting to the old erroneous behaviour. Maybe reimplement the
performance timer part and make an ini option to let user decide if the
performance timer should be used. As we really cannot foresee every hardware
bugs.
Btw. usleep() isn't affected by that, it uses the waitable timer which has a
better resolution.
[2013-04-11 16:52:09] phpbugs at musiclogistics dot net
Description:
Probably caused by recent patch for bug #64370:
Since v 5.4.14 microtime() only moves forward in 15,6 ms (1/64 sec) increments
on Win7. Same for CLI and Apache 2.2 SAPI.
Build: VC9 x86 Thread Safe (2013-Apr-10 22:55:28) from windows.php.net.
Behaviour normal after downgrade to 5.4.13.
This also breaks usleep() (only sleeping for multiples of 15,6 ms now) and
uniqid() (returning the same value for 15,6 ms with $more_entropy = false).
Test script:
---
for ($startTimeMs = currentTimeMs(), $i = 0; $i < 1; $i++) {
//usleep(1);
echo (currentTimeMs() - $startTimeMs) . ' ';
}
function currentTimeMs() {
return round(microtime(true) * 100);
}
Expected result:
[what PHP 5.4.13 prints on the same machine:]
13 28 35 41 48 54 61 67 74 80 86 92 99 105 112 118 124 131 137 143 149 155 162
168 174 181 187 193 200 206 212 218 224 [...and so on]
Actual result:
--
0 0 0 0 0 0 0 0 0 [many more zeroes] 15600 15600 15600 15600 [...] 31200 31200
31200 31200 31200 [...] 46800 46800 46800 46800 46800 [...and so on]
--
Edit this bug report at https://bugs.php.net/bug.php?id=64633&edit=1
Bug #64633 [Opn->Ver]: microtime regression - resolution reduced to 64 ticks per second
Edit report at https://bugs.php.net/bug.php?id=64633&edit=1
ID: 64633
Updated by: a...@php.net
Reported by:phpbugs at musiclogistics dot net
Summary:microtime regression - resolution reduced to 64
ticks per second
-Status: Open
+Status: Verified
Type: Bug
Package:Date/time related
Operating System: Windows 7
PHP Version:5.4.14
Block user comment: N
Private report: N
New Comment:
This is a tradeoff one has to make, precision vs. accuracy. That's very
depending on the hardware. While on one system using the performance timer it
would work as expected, on another it's still more accurate time with a very
variable precision. That's where you could see in your snippet currentTimeMs()
- $startTimeMs < 0. That is much more weird than possibly having a worse
resolution, say currentTimeMs() - $startTimeMs == 0.
Heres' an interesting reading about this
http://blogs.msdn.com/b/oldnewthing/archive/2005/09/02/459952.aspx . The goal
of the latest fix is to remove the random results. Also this will work in most
cases as normally a script doesn't consist on just two subsequent microtime
calls. Starting with win8 there is a much better API, but it of course doesn't
help here. I'm not sure it should be touched, will look how to improve it
without getting to the old erroneous behaviour. Maybe reimplement the
performance timer part and make an ini option to let user decide if the
performance timer should be used. As we really cannot foresee every hardware
bugs.
Btw. usleep() isn't affected by that, it uses the waitable timer which has a
better resolution.
Previous Comments:
[2013-04-11 16:52:09] phpbugs at musiclogistics dot net
Description:
Probably caused by recent patch for bug #64370:
Since v 5.4.14 microtime() only moves forward in 15,6 ms (1/64 sec) increments
on Win7. Same for CLI and Apache 2.2 SAPI.
Build: VC9 x86 Thread Safe (2013-Apr-10 22:55:28) from windows.php.net.
Behaviour normal after downgrade to 5.4.13.
This also breaks usleep() (only sleeping for multiples of 15,6 ms now) and
uniqid() (returning the same value for 15,6 ms with $more_entropy = false).
Test script:
---
for ($startTimeMs = currentTimeMs(), $i = 0; $i < 1; $i++) {
//usleep(1);
echo (currentTimeMs() - $startTimeMs) . ' ';
}
function currentTimeMs() {
return round(microtime(true) * 100);
}
Expected result:
[what PHP 5.4.13 prints on the same machine:]
13 28 35 41 48 54 61 67 74 80 86 92 99 105 112 118 124 131 137 143 149 155 162
168 174 181 187 193 200 206 212 218 224 [...and so on]
Actual result:
--
0 0 0 0 0 0 0 0 0 [many more zeroes] 15600 15600 15600 15600 [...] 31200 31200
31200 31200 31200 [...] 46800 46800 46800 46800 46800 [...and so on]
--
Edit this bug report at https://bugs.php.net/bug.php?id=64633&edit=1
Bug #64637 [Fbk->Opn]: redefine NULL
Edit report at https://bugs.php.net/bug.php?id=64637&edit=1
ID: 64637
User updated by:rstoll at tutteli dot ch
Reported by:rstoll at tutteli dot ch
Summary:redefine NULL
-Status: Feedback
+Status: Open
Type: Bug
Package:*Languages/Translation
-Operating System:
+Operating System: windows
-PHP Version:5.4.14
+PHP Version:5.4.7
Block user comment: N
Private report: N
New Comment:
Maybe the bug only exists on windows.
I got the error for 5.4.7 and 5.3.5
Previous Comments:
[2013-04-12 04:14:04] larue...@php.net
http://3v4l.org/8knru
I didn't see a "hello world" outputted
[2013-04-11 23:23:28] rstoll at tutteli dot ch
Description:
It is possible to redefine NULL (however, not null). No one probably does that
but it should not be possible. Maybe there are more of this kind of errors.
Test script:
---
var_dump(null); // null
var_dump(NULL); // null
define("NULL","hello world");
var_dump(null); // null
var_dump(NULL); // hello world
define("null","hello world"); //Notice: Constant null already defined
--
Edit this bug report at https://bugs.php.net/bug.php?id=64637&edit=1
[PHP-BUG] Bug #64640 [NEW]: PDO can't get output parameter value
From: shllove at hotmail dot com Operating system: winxp sp3 PHP version: 5.4.14 Package: PDO related Bug Type: Bug Bug description:PDO can't get output parameter value Description: --- >From manual page: http://www.php.net/pdostatement.bindparam#refsect1-pdostatement.bindparam-description --- Test script: --- $sql = "call `SP_Test`(?)"; $stmt = $this->db->prepare($sql); $stmt->bindParam(1, $cnt, PDO::PARAM_INPUT_OUTPUT | PDO::PARAM_INT , 11); $stmt->execute(); $rt = $stmt->fetchAll(); echo "cnt: $cnt"; $stmt->closeCursor(); echo "cnt: $cnt"; sp: CREATE PROCEDURE `SP_Test`( out resultCount int ) BEGIN set resultCount=10; END; Expected result: cnt: 10 Actual result: -- Uncaught exception 'PDOException' with message 'SQLSTATE[42000]: Syntax error or access violation: 1414 OUT or INOUT argument 1 for routine octpod.SP_Test is not a variable or NEW pseudo-variable in BEFORE trigger' -- Edit bug report at https://bugs.php.net/bug.php?id=64640&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64640&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64640&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64640&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64640&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64640&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64640&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64640&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64640&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64640&r=support Expected behavior: https://bugs.php.net/fix.php?id=64640&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64640&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64640&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64640&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64640&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64640&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64640&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64640&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64640&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64640&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64640&r=mysqlcfg
