Bug #48225 [Com]: Microseconds output wrong in DateTime::format()
Edit report at https://bugs.php.net/bug.php?id=48225&edit=1
ID: 48225
Comment by: rewilliams at crystaltech dot com
Reported by:knut dot urdalen at gmail dot com
Summary:Microseconds output wrong in DateTime::format()
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: *
PHP Version:5.*, 6CVS (2009-05-09)
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
Still see it in 5.3.6 on OS X
Previous Comments:
[2011-01-23 16:20:32] jmdoren at ok dot cl
I have the same problem
my OS : Fedora release 14 (Laughlin)
my php Version: PHP 5.3.5 (cli) (built: Jan 22 2011 00:55:37)
in my php.ini date.timezone=America/Santiago
my script:
my results:
23-01-2011 8:34:18,00
23-01-2011 8:34:18,00
23-01-2011 8:34:19,00
23-01-2011 8:34:20,00
[2009-05-10 17:38:56] j...@php.net
See also bug #45554 and bug #47312
[2009-05-10 17:29:54] knut dot urdalen at gmail dot com
Description:
The date()-function allow a 'u' format character in the formatting field as of
PHP 5.2.2. The DateTime::format() function point to the same manual page for
the formatting as the date() function and since DateTime actually store
microseconds internally (as mentioned by Derick previously) I think it's a bug
that it's not output correctly.
Reproduce code:
---
format('Y-m-d H:i:s.u')."\n";
?>
Expected result:
The 'u' format character should output the microsecond that is internally
stored in the DateTime object upon creation.
Actual result:
--
The 'u' format character always resolve to 0.
--
Edit this bug report at https://bugs.php.net/bug.php?id=48225&edit=1
Bug #55660 [Fbk->Opn]: SplFixedArray::fromArray causing segmentation fault 11
Edit report at https://bugs.php.net/bug.php?id=55660&edit=1
ID: 55660
User updated by:rewilliams at crystaltech dot com
Reported by:rewilliams at crystaltech dot com
Summary:SplFixedArray::fromArray causing segmentation fault
11
-Status: Feedback
+Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Mac OS X 10.7.1
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Well, it doesn't seem to show itself under 5.3.8 on the Linux server, so maybe
this was fixed and I just missed the report. Since my original report, I've had
several similar cases that happened somewhat randomly under 5.3.6, so I'll just
keep an eye out and if I get something that's reproducible under the latest
version, I'll file another bug. In the mean time, you can close this bug.
Thanks for your time.
Previous Comments:
[2011-09-13 02:37:45] larue...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Hi, I still can not reproduce with your data.csv, could you try with the
5.3-trunk?
----
[2011-09-12 18:05:53] rewilliams at crystaltech dot com
laruence@: I just caught that you stated your test file had 1005 lines. I'm not
sure if you misread what I wrote or if you mistyped what you tested, but the
test file I used was 10005 lines - you're off by an order of magnitude.
I uploaded my file to Dropbox. You can grab it here:
<http://dl.dropbox.com/u/9434155/data.csv>
If you're able to grab it and attach it to the bug or make it available
someplace more permanent, that would be great.
------------
[2011-09-12 18:00:42] rewilliams at crystaltech dot com
FWIW, I just reproduced it on a Linux server running 5.3.4. I'm working on
getting
a backtrace, but I need to build a debug version of PHP first.
[2011-09-10 03:59:47] larue...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
I can not reproduce it with a test csv file(1005 line, 13 cloumns) with 5.3
trunk
--------------------
[2011-09-09 21:32:23] rewilliams at crystaltech dot com
Hmm, I don't see how to upload reproduction scripts. The script is below; I'll
leave the data
file to the tester. I created a simple CSV file that had 10,005 lines of 13
columns each, where
the value of every column is the alphabet. It included one trailing blank line
and used CRLF line
endings.
Here's the script:
setFlags(SplFileObject::SKIP_EMPTY |
SplFileObject::DROP_NEW_LINE |
SplFileObject::READ_CSV);
$return = array();
foreach ($fileObj as $oneLine) {
$return[] = new stdClass();
} //foreach
switch ($whichOption) {
case 1:
$return = array_slice($return, 0, );
$result = SplFixedArray::fromArray($return);
//we get here
return $result;
break;
case 2:
$return = array_slice($return, 0, 1);
$result = SplFixedArray::fromArray($return);
//we won't get here - get "Segmentation fault:
11"
return $result;
break;
} //switch
} //ImportData
} //NmsObj
//$dataSet1 = NmsObj::ImportData(1);
$dataSet1 = NmsObj::ImportData(2);
echo "Done!\n";
?>
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=55660
--
Edit this bug report at https://bugs.php.net/bug.php?id=55660&edit=1
Bug #55660 [Com]: SplFixedArray::fromArray causing segmentation fault 11
Edit report at https://bugs.php.net/bug.php?id=55660&edit=1
ID: 55660
Comment by: rewilliams at crystaltech dot com
Reported by:rewilliams at crystaltech dot com
Summary:SplFixedArray::fromArray causing segmentation fault
11
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Mac OS X 10.7.1
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
laruence@: I just caught that you stated your test file had 1005 lines. I'm not
sure if you misread what I wrote or if you mistyped what you tested, but the
test file I used was 10005 lines - you're off by an order of magnitude.
I uploaded my file to Dropbox. You can grab it here:
<http://dl.dropbox.com/u/9434155/data.csv>
If you're able to grab it and attach it to the bug or make it available
someplace more permanent, that would be great.
Previous Comments:
----
[2011-09-12 18:00:42] rewilliams at crystaltech dot com
FWIW, I just reproduced it on a Linux server running 5.3.4. I'm working on
getting
a backtrace, but I need to build a debug version of PHP first.
[2011-09-10 03:59:47] larue...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
I can not reproduce it with a test csv file(1005 line, 13 cloumns) with 5.3
trunk
------------
[2011-09-09 21:32:23] rewilliams at crystaltech dot com
Hmm, I don't see how to upload reproduction scripts. The script is below; I'll
leave the data
file to the tester. I created a simple CSV file that had 10,005 lines of 13
columns each, where
the value of every column is the alphabet. It included one trailing blank line
and used CRLF line
endings.
Here's the script:
setFlags(SplFileObject::SKIP_EMPTY |
SplFileObject::DROP_NEW_LINE |
SplFileObject::READ_CSV);
$return = array();
foreach ($fileObj as $oneLine) {
$return[] = new stdClass();
} //foreach
switch ($whichOption) {
case 1:
$return = array_slice($return, 0, );
$result = SplFixedArray::fromArray($return);
//we get here
return $result;
break;
case 2:
$return = array_slice($return, 0, 1);
$result = SplFixedArray::fromArray($return);
//we won't get here - get "Segmentation fault:
11"
return $result;
break;
} //switch
} //ImportData
} //NmsObj
//$dataSet1 = NmsObj::ImportData(1);
$dataSet1 = NmsObj::ImportData(2);
echo "Done!\n";
?>
--------------------
[2011-09-09 21:26:12] rewilliams at crystaltech dot com
Description:
I created a script that uses SplFileObject to iterate over a CSV file. As it
goes, it creates a new object with each line's data and adds the object to an
array. Running it with 10k or more lines crashes with a "Segmentation fault:
11"
error message, while anything up to 9,999 lines works well. Adjusting PHP's
memory limit had no effect.
I've attached a partial reduction to this bug. It seems like I really need the
elements of the SplFileObject and the class for each line, as skipping either
one of those (even when the resulting array is much larger than 10k items)
causes the failure to disappear. I'm not sure exactly what the trigger is,
however. My reduction includes a sample CSV file of just over 10k lines, and
though it still uses SplFileObject and a per-line object, the class for the
latter is just an stdClass, and the data from the file is essentially ignored.
The script has two lines near the bottom that are method calls to ImportData().
Comment out one or the other to see the script run successfully or to see it
fail. Option 1 works; option 2 fails.
Note that I tested this under 5.3.6, not the 5.3.8 that's indicated on the bug.
I do not have access to the latter.
Expected result:
-
Bug #55660 [Com]: SplFixedArray::fromArray causing segmentation fault 11
Edit report at https://bugs.php.net/bug.php?id=55660&edit=1
ID: 55660
Comment by: rewilliams at crystaltech dot com
Reported by:rewilliams at crystaltech dot com
Summary:SplFixedArray::fromArray causing segmentation fault
11
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Mac OS X 10.7.1
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
FWIW, I just reproduced it on a Linux server running 5.3.4. I'm working on
getting
a backtrace, but I need to build a debug version of PHP first.
Previous Comments:
[2011-09-10 03:59:47] larue...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
I can not reproduce it with a test csv file(1005 line, 13 cloumns) with 5.3
trunk
[2011-09-09 21:32:23] rewilliams at crystaltech dot com
Hmm, I don't see how to upload reproduction scripts. The script is below; I'll
leave the data
file to the tester. I created a simple CSV file that had 10,005 lines of 13
columns each, where
the value of every column is the alphabet. It included one trailing blank line
and used CRLF line
endings.
Here's the script:
setFlags(SplFileObject::SKIP_EMPTY |
SplFileObject::DROP_NEW_LINE |
SplFileObject::READ_CSV);
$return = array();
foreach ($fileObj as $oneLine) {
$return[] = new stdClass();
} //foreach
switch ($whichOption) {
case 1:
$return = array_slice($return, 0, );
$result = SplFixedArray::fromArray($return);
//we get here
return $result;
break;
case 2:
$return = array_slice($return, 0, 1);
$result = SplFixedArray::fromArray($return);
//we won't get here - get "Segmentation fault:
11"
return $result;
break;
} //switch
} //ImportData
} //NmsObj
//$dataSet1 = NmsObj::ImportData(1);
$dataSet1 = NmsObj::ImportData(2);
echo "Done!\n";
?>
--------------------
[2011-09-09 21:26:12] rewilliams at crystaltech dot com
Description:
I created a script that uses SplFileObject to iterate over a CSV file. As it
goes, it creates a new object with each line's data and adds the object to an
array. Running it with 10k or more lines crashes with a "Segmentation fault:
11"
error message, while anything up to 9,999 lines works well. Adjusting PHP's
memory limit had no effect.
I've attached a partial reduction to this bug. It seems like I really need the
elements of the SplFileObject and the class for each line, as skipping either
one of those (even when the resulting array is much larger than 10k items)
causes the failure to disappear. I'm not sure exactly what the trigger is,
however. My reduction includes a sample CSV file of just over 10k lines, and
though it still uses SplFileObject and a per-line object, the class for the
latter is just an stdClass, and the data from the file is essentially ignored.
The script has two lines near the bottom that are method calls to ImportData().
Comment out one or the other to see the script run successfully or to see it
fail. Option 1 works; option 2 fails.
Note that I tested this under 5.3.6, not the 5.3.8 that's indicated on the bug.
I do not have access to the latter.
Expected result:
I'd expect the script to run to completion in all cases, assuming there is
sufficient memory.
Actual result:
--
The script fails in the case of >= 1 items in the array being converted.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55660&edit=1
Bug #55660 [Opn]: SplFixedArray::fromArray causing segmentation fault 11
Edit report at https://bugs.php.net/bug.php?id=55660&edit=1
ID: 55660
User updated by:rewilliams at crystaltech dot com
Reported by:rewilliams at crystaltech dot com
Summary:SplFixedArray::fromArray causing segmentation fault
11
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Mac OS X 10.7.1
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Hmm, I don't see how to upload reproduction scripts. The script is below; I'll
leave the data
file to the tester. I created a simple CSV file that had 10,005 lines of 13
columns each, where
the value of every column is the alphabet. It included one trailing blank line
and used CRLF line
endings.
Here's the script:
setFlags(SplFileObject::SKIP_EMPTY |
SplFileObject::DROP_NEW_LINE |
SplFileObject::READ_CSV);
$return = array();
foreach ($fileObj as $oneLine) {
$return[] = new stdClass();
} //foreach
switch ($whichOption) {
case 1:
$return = array_slice($return, 0, );
$result = SplFixedArray::fromArray($return);
//we get here
return $result;
break;
case 2:
$return = array_slice($return, 0, 1);
$result = SplFixedArray::fromArray($return);
//we won't get here - get "Segmentation fault:
11"
return $result;
break;
} //switch
} //ImportData
} //NmsObj
//$dataSet1 = NmsObj::ImportData(1);
$dataSet1 = NmsObj::ImportData(2);
echo "Done!\n";
?>
Previous Comments:
--------
[2011-09-09 21:26:12] rewilliams at crystaltech dot com
Description:
I created a script that uses SplFileObject to iterate over a CSV file. As it
goes, it creates a new object with each line's data and adds the object to an
array. Running it with 10k or more lines crashes with a "Segmentation fault:
11"
error message, while anything up to 9,999 lines works well. Adjusting PHP's
memory limit had no effect.
I've attached a partial reduction to this bug. It seems like I really need the
elements of the SplFileObject and the class for each line, as skipping either
one of those (even when the resulting array is much larger than 10k items)
causes the failure to disappear. I'm not sure exactly what the trigger is,
however. My reduction includes a sample CSV file of just over 10k lines, and
though it still uses SplFileObject and a per-line object, the class for the
latter is just an stdClass, and the data from the file is essentially ignored.
The script has two lines near the bottom that are method calls to ImportData().
Comment out one or the other to see the script run successfully or to see it
fail. Option 1 works; option 2 fails.
Note that I tested this under 5.3.6, not the 5.3.8 that's indicated on the bug.
I do not have access to the latter.
Expected result:
I'd expect the script to run to completion in all cases, assuming there is
sufficient memory.
Actual result:
--
The script fails in the case of >= 1 items in the array being converted.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55660&edit=1
[PHP-BUG] Bug #55660 [NEW]: SplFixedArray::fromArray causing segmentation fault 11
From: Operating system: Mac OS X 10.7.1 PHP version: 5.3.8 Package: Reproducible crash Bug Type: Bug Bug description:SplFixedArray::fromArray causing segmentation fault 11 Description: I created a script that uses SplFileObject to iterate over a CSV file. As it goes, it creates a new object with each line's data and adds the object to an array. Running it with 10k or more lines crashes with a "Segmentation fault: 11" error message, while anything up to 9,999 lines works well. Adjusting PHP's memory limit had no effect. I've attached a partial reduction to this bug. It seems like I really need the elements of the SplFileObject and the class for each line, as skipping either one of those (even when the resulting array is much larger than 10k items) causes the failure to disappear. I'm not sure exactly what the trigger is, however. My reduction includes a sample CSV file of just over 10k lines, and though it still uses SplFileObject and a per-line object, the class for the latter is just an stdClass, and the data from the file is essentially ignored. The script has two lines near the bottom that are method calls to ImportData(). Comment out one or the other to see the script run successfully or to see it fail. Option 1 works; option 2 fails. Note that I tested this under 5.3.6, not the 5.3.8 that's indicated on the bug. I do not have access to the latter. Expected result: I'd expect the script to run to completion in all cases, assuming there is sufficient memory. Actual result: -- The script fails in the case of >= 1 items in the array being converted. -- Edit bug report at https://bugs.php.net/bug.php?id=55660&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55660&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55660&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55660&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55660&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55660&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55660&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55660&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55660&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55660&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55660&r=support Expected behavior: https://bugs.php.net/fix.php?id=55660&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55660&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55660&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55660&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55660&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55660&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55660&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55660&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55660&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55660&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55660&r=mysqlcfg
[PHP-BUG] Bug #52962 [NEW]: preg_replace should allow all special characters to be escaped
From:
Operating system: Mac OS X 10.6
PHP version: 5.3.3
Package: PCRE related
Bug Type: Bug
Bug description:preg_replace should allow all special characters to be escaped
Description:
One can use preg_quote() to prep a string for use as the search string with
preg_replace() and family. However,
attempting to pass a string escaped by preg_quote() into preg_replace() as
the
replacement string does not work
because all PCRE-special characters (such as '+') are escaped, but only '$'
and
'\' are unescaped by preg_replace().
IOW, this:
$result = preg_replace("/bar/", 'BAR\$\+', 'foo bar baz');
yields:
foo \BAR$\+ baz
preg_replace() should treat all escaped characters equally so that one can
simply call preg_quote() and be done with
it. As it is now, one must do something like this:
$safeReplacementString = str_replace(array('\\', '$'), array('',
'\\$'), $replacementString);
to avoid problems. Not is that an ugly solution, but I strongly suspect
that
most code out there doesn't do it.
Expected result:
The preg_replace() family of functions should accept any escaped PCRE
special
character sequence in the replacement text and treat it like the literal
equivalent. Thus, '\+' should be treated as the literal '+'.
Actual result:
--
Presently, the preg_replace() family of functions only accept escaped
sequences
for '\' and '$'. If other PCRE-special characters, such as '+' or '*', are
passed
into the replacement string, the escape sequences (e.g., '/+') are left
intact in
the output result.
--
Edit bug report at http://bugs.php.net/bug.php?id=52962&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52962&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52962&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52962&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52962&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52962&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52962&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52962&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52962&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52962&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52962&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52962&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52962&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52962&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52962&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52962&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52962&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52962&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52962&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52962&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52962&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52962&r=mysqlcfg
