#50675 [NEW]: SoapClient can't handle object references correctly.
From: margaritisz dot oresztesz at dotroll dot hu Operating system: Linux PHP version: 5.2.12 PHP Bug Type: SOAP related Bug description: SoapClient can't handle object references correctly. Description: When sending the same object multiple times in a SOAP call, SoapClient replaces the object with a href='..' object reference. However the client generates the request envelope with an incorrect parameter name, so the server does not get the referenced object. Reproduce code: --- Sources of a simple server and client could be found at the following URL: http://charlie.extra.hu/php-soap/soap.tar.gz If I run client.php, it gets back an object filled with null parameters. It should recieve the first object sent to the server. If I change the reference's parameter name to 'secondUser', the SOAP response includes the correct object. Expected result: Expected the following soap envelope to be sent: 1 user Actual result: -- Got this request: 1 user -- Edit bug report at http://bugs.php.net/?id=50675&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50675&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50675&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50675&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50675&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50675&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50675&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50675&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50675&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50675&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50675&r=support Expected behavior: http://bugs.php.net/fix.php?id=50675&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50675&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50675&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50675&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50675&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50675&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50675&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50675&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50675&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50675&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50675&r=mysqlcfg
#50676 [NEW]: rename across Volumes throws warning "Operation not permitted"
From: andreas at heigl dot org Operating system: Mac OS X 10.6 PHP version: 5.3.1 PHP Bug Type: Filesystem function related Bug description: rename across Volumes throws warning "Operation not permitted" Description: When renaming files acros Volumes a warning is triggered that the "Operation is not permitted. The operation is executed though. Reproduce code: --- - Create two images and mount them (Image1, Image2). - Disable the 'Ignore Owner'-Feature on both of them and set permissions so the WebServer can access the files. - Add a file to one of the mounted volumes (touch /Volumes/Image1/testfile) ini_set ( 'error_reporting', E_ALL ); ini_set ( 'display_errors', true ); rename ( '/Volumes/Image1/testfile', '/Volumes/Image2/testfile' ); Expected result: The file /Volumes/Image1/testfile has been copied to /Volumes/Image2/testfile ad the original file has been removed. No error should be triggered Actual result: -- The file /Volumes/Image1/testfile has been copied to /Volumes/Image2/testfile ad the original file has been removed. Additionally the following error is triggered: rename(/Volumes/Image1/testfile,/Volumes/Image2/testfile): Operation not permitted in renametest.php on line n -- Edit bug report at http://bugs.php.net/?id=50676&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50676&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50676&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50676&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50676&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50676&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50676&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50676&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50676&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50676&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50676&r=support Expected behavior: http://bugs.php.net/fix.php?id=50676&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50676&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50676&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50676&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50676&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50676&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50676&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50676&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50676&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50676&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50676&r=mysqlcfg
#50660 [Opn->Csd]: exif_read_data fails on a given image while giving no errors with other tools
ID: 50660
Updated by: il...@php.net
Reported By: skinny dot bravo at gmail dot com
-Status: Open
+Status: Closed
Bug Type: EXIF related
Operating System: Linux
PHP Version: 5.2.12
New Comment:
If it works with php5.2-201001041530 it means that the issue has been
resolved.
Previous Comments:
[2010-01-04 17:55:52] skinny dot bravo at gmail dot com
Description:
PHP fails reading GPS data from a given set of photos from Samsung
SGH-
i900. The images are said to come from the camera without any edits.
Ex:
http://o1.imgsrc.ru/v/vahmurka/3/16095163cDU.jpg
http://o1.imgsrc.ru/v/vahmurka/1/16095161rno.jpg
exiftool 8.00 has no problem reading this file. php5.2-201001041530
produces
the same result.
Reproduce code:
---
# php -r 'var_dump(read_exif_data("16095163cDU.jpg",NULL,TRUE));'
Expected result:
...
["SectionsFound"]=>
string(35) "ANY_TAG, IFD0, THUMBNAIL, EXIF, GPS"
...
["GPS"]=>
array(8) {
["GPSVersion"]=>
string(4) ""
["GPSLatitudeRef"]=>
string(1) "N"
["GPSLatitude"]=>
array(3) {
[0]=>
string(4) "43/1"
[1]=>
string(4) "16/1"
[2]=>
string(11) "75363/1"
}
["GPSLongitudeRef"]=>
string(1) "E"
["GPSLongitude"]=>
array(3) {
[0]=>
string(4) "77/1"
[1]=>
string(4) "21/1"
[2]=>
string(11) "140249/2629"
}
["GPSAltitudeRef"]=>
string(1) ""
["GPSAltitude"]=>
string(6) "1603/1"
["GPSMapDatum"]=>
string(6) "WGS-84"
}
these results are taken after fixing image with exiftool:
# exiftool -all= -tagsfromfile @ -all:all -unsafe 16095163cDU.jpg
Actual result:
--
Warning: read_exif_data(16095163cDU.jpg): Illegal IFD offset in
Command line code on line 1
array(4) {
["FILE"]=>
array(6) {
["FileName"]=>
string(15) "16095163cDU.jpg"
["FileDateTime"]=>
int(1259257839)
["FileSize"]=>
int(938692)
["FileType"]=>
int(2)
["MimeType"]=>
string(10) "image/jpeg"
["SectionsFound"]=>
string(19) "ANY_TAG, IFD0, EXIF"
}
--
Edit this bug report at http://bugs.php.net/?id=50660&edit=1
#50660 [Csd]: exif_read_data fails on a given image while giving no errors with other tools
ID: 50660
User updated by: skinny dot bravo at gmail dot com
Reported By: skinny dot bravo at gmail dot com
Status: Closed
Bug Type: EXIF related
Operating System: Linux
PHP Version: 5.2.12
New Comment:
Sorry,
- php5.2-201001041530 produces the same result
+ php5.2-201001041530 produces the same result as 5.2.12 below
Previous Comments:
[2010-01-06 12:42:40] il...@php.net
If it works with php5.2-201001041530 it means that the issue has been
resolved.
[2010-01-04 17:55:52] skinny dot bravo at gmail dot com
Description:
PHP fails reading GPS data from a given set of photos from Samsung
SGH-
i900. The images are said to come from the camera without any edits.
Ex:
http://o1.imgsrc.ru/v/vahmurka/3/16095163cDU.jpg
http://o1.imgsrc.ru/v/vahmurka/1/16095161rno.jpg
exiftool 8.00 has no problem reading this file. php5.2-201001041530
produces
the same result.
Reproduce code:
---
# php -r 'var_dump(read_exif_data("16095163cDU.jpg",NULL,TRUE));'
Expected result:
...
["SectionsFound"]=>
string(35) "ANY_TAG, IFD0, THUMBNAIL, EXIF, GPS"
...
["GPS"]=>
array(8) {
["GPSVersion"]=>
string(4) ""
["GPSLatitudeRef"]=>
string(1) "N"
["GPSLatitude"]=>
array(3) {
[0]=>
string(4) "43/1"
[1]=>
string(4) "16/1"
[2]=>
string(11) "75363/1"
}
["GPSLongitudeRef"]=>
string(1) "E"
["GPSLongitude"]=>
array(3) {
[0]=>
string(4) "77/1"
[1]=>
string(4) "21/1"
[2]=>
string(11) "140249/2629"
}
["GPSAltitudeRef"]=>
string(1) ""
["GPSAltitude"]=>
string(6) "1603/1"
["GPSMapDatum"]=>
string(6) "WGS-84"
}
these results are taken after fixing image with exiftool:
# exiftool -all= -tagsfromfile @ -all:all -unsafe 16095163cDU.jpg
Actual result:
--
Warning: read_exif_data(16095163cDU.jpg): Illegal IFD offset in
Command line code on line 1
array(4) {
["FILE"]=>
array(6) {
["FileName"]=>
string(15) "16095163cDU.jpg"
["FileDateTime"]=>
int(1259257839)
["FileSize"]=>
int(938692)
["FileType"]=>
int(2)
["MimeType"]=>
string(10) "image/jpeg"
["SectionsFound"]=>
string(19) "ANY_TAG, IFD0, EXIF"
}
--
Edit this bug report at http://bugs.php.net/?id=50660&edit=1
#50657 [Ana->Csd]: copy() with an empty (zero-byte) HTTP source succeeds but returns false
ID: 50657
Updated by: il...@php.net
Reported By: php at lorddeath dot net
-Status: Analyzed
+Status: Closed
Bug Type: Filesystem function related
Operating System: Win32/Linux
PHP Version: 5.3SVN-2010-01-04 (snap)
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2010-01-06 12:54:54] s...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=293175
Log: Fixed bug #50657 (copy() with an empty (zero-byte) HTTP source
succeeds but returns false).
[2010-01-04 22:07:08] j...@php.net
_php_stream_copy_to_stream_ex() contains the problem, it assumes read
length of 0 to be an error..
[2010-01-04 21:57:30] j...@php.net
Nevermind, the auto-link-thing in this crappy bug tracker messed the
url. :)
[2010-01-04 21:56:47] j...@php.net
Was the file always returning 404 ?
[2010-01-04 15:51:34] php at lorddeath dot net
Description:
The copy() function returns false (but otherwise succeeds in copying
the
file) when the source file is accessed via a HTTP stream, but is empty
(zero bytes). Other, non-HTTP, stream types might also be affected,
but
local files are definitely *NOT* affected.
I have successfully reproduced this bug with PHP 5.2.9 on Linux, and
5.2.5, 5.2.12, 5.3.0, 5.3.1 and 5.3.3-dev (2010-Jan-04 15:00:00) on
Windows.
(I will keep the empty.txt URL in the reproduce code accessible for a
while.)
Reproduce code:
---
$r = copy("http://lspace.sihnon.net/pub/empty.txt";, "temp");
var_dump($r);
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=50657&edit=1
#50661 [Asn->Csd]: DOMDocument::loadXML does not allow UTF-16
ID: 50661 Updated by: rricha...@php.net Reported By: geoffers+phpbugs at gmail dot com -Status: Assigned +Status: Closed Bug Type: DOM XML related Operating System: Mac OS 10.5.8 PHP Version: 5.3SVN-2010-01-04 (SVN) Assigned To: rrichards New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-01-06 13:13:18] s...@php.net Automatic comment from SVN on behalf of rrichards Revision: http://svn.php.net/viewvc/?view=revision&revision=293176 Log: fix bug #50661 (DOMDocument::loadXML does not allow UTF-16) add test [2010-01-04 23:16:49] rricha...@php.net Assign to self [2010-01-04 20:58:36] geoffers+phpbugs at gmail dot com Description: DOMDocument::loadXML() does not support UTF-16 encoded XML. This breaks the XML spec which says, "All XML processors MUST accept the UTF-8 and UTF-16 encodings of Unicode". As such, DOMDocument::loadXML() is not a conformant XML processor. XMLReader supports this fine, which suggests something is wrong in the use of the libxml2 API. Reproduce code: --- loadXML($data); echo $dom->saveXML(); Expected result: Actual result: -- PHP Warning: DOMDocument::loadXML(): Start tag expected, '<' not found in Entity, line: 1 in /Users/gsnedders/Desktop/foo.php on line 5 Warning: DOMDocument::loadXML(): Start tag expected, '<' not found in Entity, line: 1 in /Users/gsnedders/Desktop/foo.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=50661&edit=1
#50677 [NEW]: gdImageFill still fails due to bug #46318
From: christian at elmerot dot se Operating system: Debian Etch, Lenny PHP version: 5.3.1 PHP Bug Type: GD related Bug description: gdImageFill still fails due to bug #46318 Description: PHP bug #46318 and attached patch still affects PHP 5.3.1 so please do reopen this bug as the attached patch fixes the issue. If you are bitten by this bug then the only remedy, besides rebuilding PHP using this patch, is to restart the server, fixing the issue for a while. While #46318 may be a duplicate of libGD #177 it is in no way fixed in either libGD or PHP as the error is still in both sources. -- Edit bug report at http://bugs.php.net/?id=50677&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50677&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50677&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50677&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50677&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50677&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50677&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50677&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50677&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50677&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50677&r=support Expected behavior: http://bugs.php.net/fix.php?id=50677&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50677&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50677&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50677&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50677&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50677&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50677&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50677&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50677&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50677&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50677&r=mysqlcfg
#50677 [Opn->Bgs]: gdImageFill still fails due to bug #46318
ID: 50677 Updated by: paj...@php.net Reported By: christian at elmerot dot se -Status: Open +Status: Bogus Bug Type: GD related Operating System: Debian Etch, Lenny PHP Version: 5.3.1 New Comment: This patch has not been applied. However I do not have a way to reproduce this bug. Please note that the other bug was closed to avoid double locations for a discussion. Please use bugs.libgd.org to discuss it (the bug is still open there). Duplicate > bogus. Previous Comments: [2010-01-06 15:32:14] christian at elmerot dot se Description: PHP bug #46318 and attached patch still affects PHP 5.3.1 so please do reopen this bug as the attached patch fixes the issue. If you are bitten by this bug then the only remedy, besides rebuilding PHP using this patch, is to restart the server, fixing the issue for a while. While #46318 may be a duplicate of libGD #177 it is in no way fixed in either libGD or PHP as the error is still in both sources. -- Edit this bug report at http://bugs.php.net/?id=50677&edit=1
#50660 [Csd]: exif_read_data fails on a given image while giving no errors with other tools
ID: 50660
Updated by: srina...@php.net
Reported By: skinny dot bravo at gmail dot com
Status: Closed
Bug Type: EXIF related
Operating System: Linux
PHP Version: 5.2.12
New Comment:
not sure, why you closed this bug when it is reproduced with the latest
snapshot as well ?
Previous Comments:
[2010-01-06 12:49:45] skinny dot bravo at gmail dot com
Sorry,
- php5.2-201001041530 produces the same result
+ php5.2-201001041530 produces the same result as 5.2.12 below
[2010-01-06 12:42:40] il...@php.net
If it works with php5.2-201001041530 it means that the issue has been
resolved.
[2010-01-04 17:55:52] skinny dot bravo at gmail dot com
Description:
PHP fails reading GPS data from a given set of photos from Samsung
SGH-
i900. The images are said to come from the camera without any edits.
Ex:
http://o1.imgsrc.ru/v/vahmurka/3/16095163cDU.jpg
http://o1.imgsrc.ru/v/vahmurka/1/16095161rno.jpg
exiftool 8.00 has no problem reading this file. php5.2-201001041530
produces
the same result.
Reproduce code:
---
# php -r 'var_dump(read_exif_data("16095163cDU.jpg",NULL,TRUE));'
Expected result:
...
["SectionsFound"]=>
string(35) "ANY_TAG, IFD0, THUMBNAIL, EXIF, GPS"
...
["GPS"]=>
array(8) {
["GPSVersion"]=>
string(4) ""
["GPSLatitudeRef"]=>
string(1) "N"
["GPSLatitude"]=>
array(3) {
[0]=>
string(4) "43/1"
[1]=>
string(4) "16/1"
[2]=>
string(11) "75363/1"
}
["GPSLongitudeRef"]=>
string(1) "E"
["GPSLongitude"]=>
array(3) {
[0]=>
string(4) "77/1"
[1]=>
string(4) "21/1"
[2]=>
string(11) "140249/2629"
}
["GPSAltitudeRef"]=>
string(1) ""
["GPSAltitude"]=>
string(6) "1603/1"
["GPSMapDatum"]=>
string(6) "WGS-84"
}
these results are taken after fixing image with exiftool:
# exiftool -all= -tagsfromfile @ -all:all -unsafe 16095163cDU.jpg
Actual result:
--
Warning: read_exif_data(16095163cDU.jpg): Illegal IFD offset in
Command line code on line 1
array(4) {
["FILE"]=>
array(6) {
["FileName"]=>
string(15) "16095163cDU.jpg"
["FileDateTime"]=>
int(1259257839)
["FileSize"]=>
int(938692)
["FileType"]=>
int(2)
["MimeType"]=>
string(10) "image/jpeg"
["SectionsFound"]=>
string(19) "ANY_TAG, IFD0, EXIF"
}
--
Edit this bug report at http://bugs.php.net/?id=50660&edit=1
#50678 [NEW]: files extracted by ZipArchive class lost their original modified time
From: sunchaojun at gmail dot com
Operating system: windows
PHP version: 5.2.12
PHP Bug Type: Zip Related
Bug description: files extracted by ZipArchive class lost their original
modified time
Description:
After I extract a zip file via ZipArchive class in my php codes, I found
that the creation time, modified time and lastaccess time of the files
extracted have been set to the time at that it was being extracted.
Reproduce code:
---
---
>From manual page: class.ziparchive
---
$zip = new ZipArchive();
if ($zip->open('test.zip')) {
zip->extractTo
zip.close()
}
Expected result:
A extracted files has the same creation time, modified time and lastaccess
time with its oringinal copy.
Actual result:
--
The creation time, modified time and lastaccess time of a extracted file
has been reset when extracting.
--
Edit bug report at http://bugs.php.net/?id=50678&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50678&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50678&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50678&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50678&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50678&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50678&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50678&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50678&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50678&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50678&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50678&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50678&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50678&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50678&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50678&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50678&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50678&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50678&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50678&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50678&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50678&r=mysqlcfg
#50679 [NEW]: range fails on some float values
From: kauffj at gmail dot com Operating system: Ubuntu 9.10 PHP version: 5.3.1 PHP Bug Type: Unknown/Other Function Bug description: range fails on some float values Description: The range function works on some float values but not others. Reproduce code: --- WORKS: print_r(range(0.3, 0.4, 0.1)); FAILS: print_r(range(5.5, 5.6, 0.1)); WORKS: print_r(range(5.5, 5.7, 0.1)); Expected result: Array ( [0] => 0.3 [1] => 0.4 ) Array ( [0] => 5.5 [1] => 5.6 ) Array ( [0] => 5.5 [1] => 5.6 [2] => 5.7 ) Actual result: -- Array ( [0] => 0.3 [1] => 0.4 ) PHP Warning: range(): step exceeds the specified range Array ( [0] => 5.5 [1] => 5.6 [2] => 5.7 ) -- Edit bug report at http://bugs.php.net/?id=50679&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50679&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50679&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50679&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50679&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50679&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50679&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50679&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50679&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50679&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50679&r=support Expected behavior: http://bugs.php.net/fix.php?id=50679&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50679&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50679&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50679&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50679&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50679&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50679&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50679&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50679&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50679&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50679&r=mysqlcfg
#49081 [Asn]: [PATCH] DateTime::diff() mistake if start in January and interval > 28 days
ID: 49081
Updated by: dani...@php.net
Reported By: nate at frickenate dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3.0
Assigned To: derick
New Comment:
Hmm... Isn't the whole days_next_month functionality in
do_range_limit_days_relative() unnecessary?
Previous Comments:
[2010-01-06 01:04:18] dani...@php.net
A better test file:
http://www.analysisandsolutions.com/php/bug49081v2.phpt
The scenarios it covers are more relevant and thorough, plus it
improves the context, making it easier see what the test is doing.
[2010-01-05 22:11:57] dani...@php.net
This bug continues to exist in 5.3.2RC2.
DateTime::diff() / date_diff() chokes on dates starting in January if
the interval is greater than 28 days (during non-leap years).
It is happening because of a bug in do_range_limit_days_relative() in
ext/date/lib/tm2unixtime.c. At the end of the function if *d >
days_next_month, the code subtracts the days and adds a month. So when
the starting month is January, the days_next_month is 28 or 29,
mistakenly triggering the month/day swapping behavior.
Patch:
http://www.analysisandsolutions.com/php/bug49081.diff
Test:
http://www.analysisandsolutions.com/php/bug49081.phpt
[2009-12-16 05:44:52] peter dot schleif at gmx dot de
More simple code to reproduce error:
diff($d2);
print_r($d);
?>
Expected:
-
[m] => 0
[d] => 30
Actual:
---
[m] => 1
[d] => 2
[2009-07-27 22:55:24] nate at frickenate dot com
Description:
DateTime::diff calculates diffs incorrectly.
As an example, the diff of 2009-01-01 and 2009-03-31 *should be* "2
months, 30 days". 2009-01-01 + 2 months = 2009-03-01, + 30 days =
2009-03-31. Taking 2009-01-01 and using DateTime::add() to add 'P2M30D'
does indeed result in 2009-03-31. This is correct.
However, running the diff() of 2009-01-01 and 2009-03-31 returns "3
months, 2 days". add()ing 2009-01-01 + 'P3M2D' returns 2009-04-03
instead of 2009-03-31 (as it should, since the diff that told us to add
3M2D was incorrect).
Reproduce code:
---
add(new DateInterval('P2M30D'))); // correct period
var_dump($jan_1->add(new DateInterval('P3M2D'))); // incorrect period
// END EXAMPLE CODE - following is just extra fluff
// here's the replacement function I am currently
// using to calculate the correct diff until the
// built-in method is patched and functional
function date_diff2 ($t1, $t2) {
if (! preg_match('/^\d+\z/', $t1) && ($t1 = strtotime($t1)) ===
false)
return false;
if (! preg_match('/^\d+\z/', $t2) && ($t2 = strtotime($t2)) ===
false)
return false;
if ($t1 > $t2)
list($t1, $t2) = array($t2, $t1);
$diffs = array(
'years' => 0, 'months' => 0, 'days' => 0,
'hours' => 0, 'minutes' => 0, 'seconds' => 0,
);
foreach (array_keys($diffs) as $interval) {
while ($t2 >= ($t3 = strtotime("+1 ${interval}", $t1))) {
$t1 = $t3;
++$diffs[$interval];
}
}
return $diffs;
}
?>
Expected result:
object(DateInterval)#3 (8) {
["y"]=>
int(0)
["m"]=>
int(2)
["d"]=>
int(30)
["h"]=>
int(0)
["i"]=>
int(0)
["s"]=>
int(0)
["invert"]=>
int(0)
["days"]=>
int(89)
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-03-31 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-07-03 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
Actual result:
--
object(DateInterval)#3 (8) {
["y"]=>
int(0)
["m"]=>
int(3)
["d"]=>
int(2)
["h"]=>
int(0)
["i"]=>
int(0)
["s"]=>
int(0)
["invert"]=>
int(0)
["days"]=>
int(89)
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-03-31 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-07-03 00:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(16) "America/Montreal"
}
--
Edit this bug report at http://bugs.php.net/?id=49081&edit=1
#50660 [Csd->Opn]: exif_read_data fails on a given image while giving no errors with other tools
ID: 50660
User updated by: skinny dot bravo at gmail dot com
Reported By: skinny dot bravo at gmail dot com
-Status: Closed
+Status: Open
Bug Type: EXIF related
Operating System: Linux
PHP Version: 5.2.12
New Comment:
New to this bug report system. Reopened. Sorry again.
Previous Comments:
[2010-01-06 15:43:23] srina...@php.net
not sure, why you closed this bug when it is reproduced with the latest
snapshot as well ?
[2010-01-06 12:49:45] skinny dot bravo at gmail dot com
Sorry,
- php5.2-201001041530 produces the same result
+ php5.2-201001041530 produces the same result as 5.2.12 below
[2010-01-06 12:42:40] il...@php.net
If it works with php5.2-201001041530 it means that the issue has been
resolved.
[2010-01-04 17:55:52] skinny dot bravo at gmail dot com
Description:
PHP fails reading GPS data from a given set of photos from Samsung
SGH-
i900. The images are said to come from the camera without any edits.
Ex:
http://o1.imgsrc.ru/v/vahmurka/3/16095163cDU.jpg
http://o1.imgsrc.ru/v/vahmurka/1/16095161rno.jpg
exiftool 8.00 has no problem reading this file. php5.2-201001041530
produces
the same result.
Reproduce code:
---
# php -r 'var_dump(read_exif_data("16095163cDU.jpg",NULL,TRUE));'
Expected result:
...
["SectionsFound"]=>
string(35) "ANY_TAG, IFD0, THUMBNAIL, EXIF, GPS"
...
["GPS"]=>
array(8) {
["GPSVersion"]=>
string(4) ""
["GPSLatitudeRef"]=>
string(1) "N"
["GPSLatitude"]=>
array(3) {
[0]=>
string(4) "43/1"
[1]=>
string(4) "16/1"
[2]=>
string(11) "75363/1"
}
["GPSLongitudeRef"]=>
string(1) "E"
["GPSLongitude"]=>
array(3) {
[0]=>
string(4) "77/1"
[1]=>
string(4) "21/1"
[2]=>
string(11) "140249/2629"
}
["GPSAltitudeRef"]=>
string(1) ""
["GPSAltitude"]=>
string(6) "1603/1"
["GPSMapDatum"]=>
string(6) "WGS-84"
}
these results are taken after fixing image with exiftool:
# exiftool -all= -tagsfromfile @ -all:all -unsafe 16095163cDU.jpg
Actual result:
--
Warning: read_exif_data(16095163cDU.jpg): Illegal IFD offset in
Command line code on line 1
array(4) {
["FILE"]=>
array(6) {
["FileName"]=>
string(15) "16095163cDU.jpg"
["FileDateTime"]=>
int(1259257839)
["FileSize"]=>
int(938692)
["FileType"]=>
int(2)
["MimeType"]=>
string(10) "image/jpeg"
["SectionsFound"]=>
string(19) "ANY_TAG, IFD0, EXIF"
}
--
Edit this bug report at http://bugs.php.net/?id=50660&edit=1
#50680 [NEW]: "eight" -> "eighth"
From: danielc at analysisandsolutions dot com Operating system: PHP version: 5.3SVN-2010-01-06 (SVN) PHP Bug Type: Date/time related Bug description: "eight" -> "eighth" Description: In ext/date/lib/parse_date.re, reltextnumber and timelib_reltext_lookup contain ordinal numbers, but when it comes to 8th, it mistakenly uses "eight", rather than "eighth". Guess it now needs to contain both to provide backwards compatibility. -- Edit bug report at http://bugs.php.net/?id=50680&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50680&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50680&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50680&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50680&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50680&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50680&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50680&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50680&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50680&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50680&r=support Expected behavior: http://bugs.php.net/fix.php?id=50680&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50680&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50680&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50680&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50680&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50680&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50680&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50680&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50680&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50680&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50680&r=mysqlcfg
#44994 [Com]: exec() produces zombie processes on Windows, hangs Apache
ID: 44994
Comment by: patrick dot bueker at triangle-solutions dot de
Reported By: dbarrett at vistaprint dot com
Status: No Feedback
Bug Type: Program Execution
Operating System: win32 only - 2003 Server, 64-bit
PHP Version: 5.2.6
Assigned To: garretts
New Comment:
I once had the problem too. I had the feeling that it has something to
do with threadsafe or non-threadsafe versions of PHP. I still have the
problem on some installations, others work.
Previous Comments:
[2009-09-01 18:42:09] garre...@php.net
I'm trying to come up with a reproducible test case for this bug.
If anyone has a complete test scenario for this please post it. I
simply can't replicate the effects here.
G
[2009-08-27 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".
[2009-08-19 19:06:40] garre...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-08-19 17:26:55] garre...@php.net
I've seen this happen in other languages too.
This happens when the pipe between the parent and child fills up, and
cmd.exe ends up blocking and creates a race condition. (Windows script
host languages trip up on this quickly)
in popen_ex() ( in tsrm_win32.c) the pipe is creates with a 2k buffer:
if (!str_len || !CreatePipe(&in, &out, &security, 2048L)) {
this should probably be significantly larger. I'd certainly go with at
least 16k or 32k. (hey, it's only memory :D)
as well, the elimination of the unrequired cmd.exe as the immediate
child process would eliminate the possibility that *it's* buffer gets
overwhelmed too. (which solves bug #43327, and I've passed a patch to
Pierre for that.)
[2009-06-08 16:40:15] alex at bartl dot net
Reproducable with PHP 5.2.9-1 on Windows2003 Server with Apache2.2
Workaround with calling session_write_close() before calling exec()
confirmed working
NOT reproducable with PHP 5.2.1 on Windows 2000 Server with IIS5
anyway, seems to be a duplicate of Bug#44942
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/44994
--
Edit this bug report at http://bugs.php.net/?id=44994&edit=1
#50661 [Csd]: DOMDocument::loadXML does not allow UTF-16
ID: 50661 User updated by: geoffers+phpbugs at gmail dot com Reported By: geoffers+phpbugs at gmail dot com Status: Closed Bug Type: DOM XML related Operating System: Mac OS 10.5.8 PHP Version: 5.3SVN-2010-01-04 (SVN) Assigned To: rrichards New Comment: Null-terminated strings and UTF-16 fun. :) Thanks for fixing it! Previous Comments: [2010-01-06 13:16:36] rricha...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2010-01-06 13:13:18] s...@php.net Automatic comment from SVN on behalf of rrichards Revision: http://svn.php.net/viewvc/?view=revision&revision=293176 Log: fix bug #50661 (DOMDocument::loadXML does not allow UTF-16) add test [2010-01-04 23:16:49] rricha...@php.net Assign to self [2010-01-04 20:58:36] geoffers+phpbugs at gmail dot com Description: DOMDocument::loadXML() does not support UTF-16 encoded XML. This breaks the XML spec which says, "All XML processors MUST accept the UTF-8 and UTF-16 encodings of Unicode". As such, DOMDocument::loadXML() is not a conformant XML processor. XMLReader supports this fine, which suggests something is wrong in the use of the libxml2 API. Reproduce code: --- loadXML($data); echo $dom->saveXML(); Expected result: Actual result: -- PHP Warning: DOMDocument::loadXML(): Start tag expected, '<' not found in Entity, line: 1 in /Users/gsnedders/Desktop/foo.php on line 5 Warning: DOMDocument::loadXML(): Start tag expected, '<' not found in Entity, line: 1 in /Users/gsnedders/Desktop/foo.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=50661&edit=1
#49560 [Asn->Csd]: OCI_RETURN_LOBS causes php_shutdown to take very long
ID: 49560
Updated by: s...@php.net
Reported By: j dot henge-ernst at interexa dot de
-Status: Assigned
+Status: Closed
Bug Type: OCI8 related
Operating System: linux
PHP Version: 5.2.10
Assigned To: sixd
New Comment:
-
A fix has been merged to PHP 5.3.3 and a request for it to be merged to
5.3.2 has been made to the Release Manager.
The fix will be in PECL OCI8 1.4.1+
Previous Comments:
[2010-01-06 18:58:16] s...@php.net
Automatic comment from SVN on behalf of sixd
Revision: http://svn.php.net/viewvc/?view=revision&revision=293180
Log: Fixed bug #49560 (oci8: using LOBs causes slow PHP shutdown)
- Improved descriptor refcounting to remove unneeded items sooner
- Replaced n^2 list traversal during descriptor list destruction
[2009-09-15 15:37:24] j dot henge-ernst at interexa dot de
Using oracle 11 instant client with Oracle 11.0.7 database
yes end of the php process. After the php script on the command line
has finished the gdb shows something like the following in the
backtrace:
0x7f5e231da5b0 in php_oci_descriptor_delete_from_hash
(data=0x7f35610, id=0xbb8ebe8)
at /home/hernst/src/php-5.3.0/ext/oci8/oci8.c:1497
1497if (descriptor && desc_id && descriptor->id ==
*desc_id) {
(gdb) where
#0 0x7f5e231da5b0 in php_oci_descriptor_delete_from_hash
(data=0x7f35610, id=0xbb8ebe8)
at /home/hernst/src/php-5.3.0/ext/oci8/oci8.c:1497
#1 0x007503c5 in zend_hash_apply_with_argument (ht=0xf3e670,
apply_func=0x7f5e231da57d ,
argument=0xbb8ebe8)
at /home/hernst/src/php-5.3.0/Zend/zend_hash.c:697
#2 0x7f5e231e5c9c in php_oci_lob_free (descriptor=0xbb8ebe8) at
/home/hernst/src/php-5.3.0/ext/oci8/oci8_lob.c:672
#3 0x7f5e231da3c4 in php_oci_descriptor_list_dtor
(entry=0xbb8e5d8) at /home/hernst/src/php-5.3.0/ext/oci8/oci8.c:1386
#4 0x0075276a in list_entry_destructor (ptr=0xbb8e5d8) at
/home/hernst/src/php-5.3.0/Zend/zend_list.c:184
#5 0x00750163 in zend_hash_apply_deleter (ht=0xd680f0,
p=0xbb8ec30) at /home/hernst/src/php-5.3.0/Zend/zend_hash.c:611
#6 0x00750255 in zend_hash_graceful_reverse_destroy
(ht=0xd680f0) at /home/hernst/src/php-5.3.0/Zend/zend_hash.c:646
#7 0x007528ba in zend_destroy_rsrc_list (ht=0xd680f0) at
/home/hernst/src/php-5.3.0/Zend/zend_list.c:240
#8 0x00740e21 in zend_deactivate () at
/home/hernst/src/php-5.3.0/Zend/zend.c:896
#9 0x006d812d in php_request_shutdown (dummy=0x0) at
/home/hernst/src/php-5.3.0/main/main.c:1576
#10 0x0081e11e in main (argc=3, argv=0x7fff9852fb98) at
/home/hernst/src/php-5.3.0/sapi/cli/php_cli.c:1369
(gdb) up
#1 0x007503c5 in zend_hash_apply_with_argument (ht=0xf3e670,
apply_func=0x7f5e231da57d ,
argument=0xbb8ebe8)
at /home/hernst/src/php-5.3.0/Zend/zend_hash.c:697
(gdb) print ht->nTableSize
$1 = 262144
I run the script from commandline with
time php script.php 10
When the php script has outputed the last thing the php process takes
very long till it finaly returns to the command line.
Guess it's more like a oci_free_lob-count issue you mentoined. Is there
a newer version to try?
[2009-09-15 15:17:04] s...@php.net
What version Oracle client and database?
By shutdown do you mean end-of-web-request, or shutdown of the PHP
process?
It might be a symptom of a LOB ref count issue we've recently
uncovered, or it might just be Oracle having to clean up.
[2009-09-15 12:20:06] j dot henge-ernst at interexa dot de
Description:
If you read a lot of clobs/blob via oci_fetch_array($stmt,
OCI_RETURN_NULLS+OCI_ASSOC+OCI_RETURN_LOBS) it causes php_shutdown to
take a very long time.
Depending on the rows you read via oci_fetch_array the php_shutdown
takes longer and longer. Examples:
10.000 rows read with one lob column 0.1 seconds
20.000 rows read with one lob column2 seconds
30.000 rows read with one lob column8 seconds
40.000 rows read with one lob column 28 seconds
50.000 rows read with one lob column 60 seconds
100.000 rows read with one lob column 1800 seconds
This also happens if you skip the OCI_RETURN_LOBS and you don't use
->free on the returned lob-object.
Tested with oci8 extension form php 5.2.10 and php 5.3.0
Reproduce code:
---
$conn = oci_connect($user, $user, $db);
$tcst = oci_parse($conn, 'CREATE TABLE TESTTABLE ( PK NUMBER NOT NULL,
TB BLOB , CONSTRAINT TABLE1_PK PRIMARY KEY ( PK) ENABLE)');
oci_execute($tcst);
oci_free_statement($tcst);
for ($i = 1; $i <= 1; ++$i) {
$stmt = oci_parse($conn, "insert into testtable (PK, TB)
values(:PK, :TB)");
oci_bind_by_name($stmt, ':PK', $i, -1);
#50681 [NEW]: array of objects: copying passes reference instead of copy
From: israel at toxinworks dot com
Operating system: RedHat EL5
PHP version: 5.2.12
PHP Bug Type: Class/Object related
Bug description: array of objects: copying passes reference instead of copy
Description:
PHP 5 does not copy object from array[ndx] to a new array entry, instead
it seems to pass a reference to the original.
Reproduce code:
---
function fetchData()
{
// return array of objects
}
$arr = fetchData();
$newNdx = count($arr);
$arr[$newNdx] = $arr[0]; // create copy of first object
$arr[$newNdx]->description = 'Change description';
Expected result:
The result is that $arr[0]->description will also have changed when we
modified $arr[$newNdx]->description, therefor not copying, but more like
creating a reference to the original.
This happens only in PHP 5, not 4.
--
Edit bug report at http://bugs.php.net/?id=50681&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50681&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50681&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50681&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50681&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50681&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50681&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50681&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50681&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50681&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50681&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50681&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50681&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50681&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50681&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50681&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50681&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50681&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50681&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50681&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50681&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50681&r=mysqlcfg
#46565 [Asn->WFx]: oci_fetch_all() returns ORA-01002
ID: 46565
Updated by: s...@php.net
Reported By: james_blond at hipernet dot brda dot net
-Status: Assigned
+Status: Wont fix
Bug Type: OCI8 related
Operating System: *
PHP Version: 5.2.6
Assigned To: sixd
New Comment:
I'm closing this because there are no plans to break existing
oci_fetch_all() behaviour.
Previous Comments:
[2009-02-11 20:19:32] s...@php.net
Until array functionality is introduced, make sure that
oci8.default_prefetch is set high in such cases.
[2008-11-20 02:16:52] s...@php.net
The use case was for a report generator, typically handling 10K rows,
and sometimes up to 80K. Batching would improve performance.
[2008-11-19 00:18:49] s...@php.net
The oci_fetch_all() function was designed to cancel a query after
being called once. The behavior you see is expected.
However it sounds like a possible enhancement.
[2008-11-13 13:00:26] james_blond at hipernet dot brda dot net
Description:
function oci_fetch_all on second use return error ORA-01002: fetch out
of sequence.
Reproduce code:
---
$dbstr = "(DESCRIPTION = (ADDRESS = PROTOCOL = TCP (HOST = host)(PORT =
1521))(CONNECT_DATA = (SID = sid)))";
$c = oci_connect("user","pass",$dbstr,"UTF8");
$SQL = "SELECT * FROM table "; // table have more then 100 rec
$s = oci_parse($c,$SQL);
oci_execute($s,OCI_COMMIT_ON_SUCCESS);
oci_fetch_all($s,$Row,0,10, OCI_NUM);
print_r($Row);
oci_fetch_all($s,$Row,10,10, OCI_NUM);// here return error ORA-01002
print_r($Row);
Expected result:
printed array $Row
Actual result:
--
array $Row is printed only on first time
on second $Row is empty , oci_fetch_all -> return error ORA-01002:
fetch out of sequence.
--
Edit this bug report at http://bugs.php.net/?id=46565&edit=1
#49803 [Asn->Fbk]: OCI statement cache causes ORA-01007
ID: 49803 Updated by: s...@php.net Reported By: stronk7 at moodle dot org -Status: Assigned +Status: Feedback Bug Type: OCI8 related Operating System: MacOS X (any) PHP Version: 5.2.11 Assigned To: sixd New Comment: What's the testcase? Previous Comments: [2009-10-07 16:29:46] stronk7 at moodle dot org Description: Under certain circumstances (multiple DDL creation) OCI client statement cache causes ORA-01007: variable not in select list error in simple queries against those tables. Only disabling the cache ( oci8.statement_cache_size = 0 in php.ini, from default 20) alleviates the problem. Running with cache disabled has a big impact in oci performance. It should be some explicit way to clean the cache from php oci or the driver itself should be "clever enough" to clean it when DDL statements are executed. Reproduce code: --- http://tracker.moodle.org/secure/attachment/18556/testing_oci_stmt_cache_pureoci.php Expected result: TESTING MOODLE 2.0 OCI DRIVER WITH oci8.statement_cache_size = 0 (from php.ini) Created table unit_table (id, course, name). Ok Selected 0 records from table. Ok Dropped table unit_table (id, course, name). Ok Created table unit_table (id, course). Ok Selected 0 records from table. Ok Dropped table unit_table (id, course). Ok Actual result: -- TESTING MOODLE 2.0 OCI DRIVER WITH oci8.statement_cache_size = 20 (from php.ini) Created table unit_table (id, course, name). Ok Selected 0 records from table. Ok Dropped table unit_table (id, course, name). Ok Created table unit_table (id, course). Ok Error selecting records from table!! ORA-01007: variable not in select list Dropped table unit_table (id, course). Ok -- Edit this bug report at http://bugs.php.net/?id=49803&edit=1
#49803 [Fbk]: OCI statement cache causes ORA-01007
ID: 49803 Updated by: s...@php.net Reported By: stronk7 at moodle dot org Status: Feedback Bug Type: OCI8 related Operating System: MacOS X (any) PHP Version: 5.2.11 Assigned To: sixd New Comment: Doh. I've got it. Previous Comments: [2010-01-06 19:40:49] s...@php.net What's the testcase? [2009-10-07 16:29:46] stronk7 at moodle dot org Description: Under certain circumstances (multiple DDL creation) OCI client statement cache causes ORA-01007: variable not in select list error in simple queries against those tables. Only disabling the cache ( oci8.statement_cache_size = 0 in php.ini, from default 20) alleviates the problem. Running with cache disabled has a big impact in oci performance. It should be some explicit way to clean the cache from php oci or the driver itself should be "clever enough" to clean it when DDL statements are executed. Reproduce code: --- http://tracker.moodle.org/secure/attachment/18556/testing_oci_stmt_cache_pureoci.php Expected result: TESTING MOODLE 2.0 OCI DRIVER WITH oci8.statement_cache_size = 0 (from php.ini) Created table unit_table (id, course, name). Ok Selected 0 records from table. Ok Dropped table unit_table (id, course, name). Ok Created table unit_table (id, course). Ok Selected 0 records from table. Ok Dropped table unit_table (id, course). Ok Actual result: -- TESTING MOODLE 2.0 OCI DRIVER WITH oci8.statement_cache_size = 20 (from php.ini) Created table unit_table (id, course, name). Ok Selected 0 records from table. Ok Dropped table unit_table (id, course, name). Ok Created table unit_table (id, course). Ok Error selecting records from table!! ORA-01007: variable not in select list Dropped table unit_table (id, course). Ok -- Edit this bug report at http://bugs.php.net/?id=49803&edit=1
#49803 [Fbk->Opn]: OCI statement cache causes ORA-01007
ID: 49803 Updated by: s...@php.net Reported By: stronk7 at moodle dot org -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: MacOS X (any) PHP Version: 5.2.11 Assigned To: sixd Previous Comments: [2010-01-06 19:42:18] s...@php.net Doh. I've got it. [2010-01-06 19:40:49] s...@php.net What's the testcase? [2009-10-07 16:29:46] stronk7 at moodle dot org Description: Under certain circumstances (multiple DDL creation) OCI client statement cache causes ORA-01007: variable not in select list error in simple queries against those tables. Only disabling the cache ( oci8.statement_cache_size = 0 in php.ini, from default 20) alleviates the problem. Running with cache disabled has a big impact in oci performance. It should be some explicit way to clean the cache from php oci or the driver itself should be "clever enough" to clean it when DDL statements are executed. Reproduce code: --- http://tracker.moodle.org/secure/attachment/18556/testing_oci_stmt_cache_pureoci.php Expected result: TESTING MOODLE 2.0 OCI DRIVER WITH oci8.statement_cache_size = 0 (from php.ini) Created table unit_table (id, course, name). Ok Selected 0 records from table. Ok Dropped table unit_table (id, course, name). Ok Created table unit_table (id, course). Ok Selected 0 records from table. Ok Dropped table unit_table (id, course). Ok Actual result: -- TESTING MOODLE 2.0 OCI DRIVER WITH oci8.statement_cache_size = 20 (from php.ini) Created table unit_table (id, course, name). Ok Selected 0 records from table. Ok Dropped table unit_table (id, course, name). Ok Created table unit_table (id, course). Ok Error selecting records from table!! ORA-01007: variable not in select list Dropped table unit_table (id, course). Ok -- Edit this bug report at http://bugs.php.net/?id=49803&edit=1
#50681 [Opn->Bgs]: array of objects: copying passes reference instead of copy
ID: 50681
Updated by: j...@php.net
Reported By: israel at toxinworks dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: RedHat EL5
PHP Version: 5.2.12
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2010-01-06 19:15:15] israel at toxinworks dot com
Description:
PHP 5 does not copy object from array[ndx] to a new array entry,
instead it seems to pass a reference to the original.
Reproduce code:
---
function fetchData()
{
// return array of objects
}
$arr = fetchData();
$newNdx = count($arr);
$arr[$newNdx] = $arr[0]; // create copy of first object
$arr[$newNdx]->description = 'Change description';
Expected result:
The result is that $arr[0]->description will also have changed when we
modified $arr[$newNdx]->description, therefor not copying, but more like
creating a reference to the original.
This happens only in PHP 5, not 4.
--
Edit this bug report at http://bugs.php.net/?id=50681&edit=1
#50682 [NEW]: strtotime producing incorrect result
From: keefeg at gmail dot com
Operating system: FreeBSD 6.2
PHP version: 5.2.12
PHP Bug Type: Date/time related
Bug description: strtotime producing incorrect result
Description:
strtotime does not handle the "last month" parameter correctly all the
time.
Reproduce code:
---
---
>From manual page: function.strtotime#Description
---
$ny = strtotime("31 December 2009");
echo "this month: " . date('Ym', strtotime("now", $ny)) . "\n";
echo "last month: " . date('Ym', strtotime("last month", $ny)) . "\n";
Expected result:
I would like it to produce this result:
this month: 200912
last month: 200911
Actual result:
--
It prints this result:
this month: 200912
last month: 200912
--
Edit bug report at http://bugs.php.net/?id=50682&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50682&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50682&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50682&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50682&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50682&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50682&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50682&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50682&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50682&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50682&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50682&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50682&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50682&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50682&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50682&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50682&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50682&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50682&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50682&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50682&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50682&r=mysqlcfg
#50679 [Opn->Bgs]: range fails on some float values
ID: 50679 Updated by: j...@php.net Reported By: kauffj at gmail dot com -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Ubuntu 9.10 PHP Version: 5.3.1 New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is, read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. Previous Comments: [2010-01-06 16:07:12] kauffj at gmail dot com Description: The range function works on some float values but not others. Reproduce code: --- WORKS: print_r(range(0.3, 0.4, 0.1)); FAILS: print_r(range(5.5, 5.6, 0.1)); WORKS: print_r(range(5.5, 5.7, 0.1)); Expected result: Array ( [0] => 0.3 [1] => 0.4 ) Array ( [0] => 5.5 [1] => 5.6 ) Array ( [0] => 5.5 [1] => 5.6 [2] => 5.7 ) Actual result: -- Array ( [0] => 0.3 [1] => 0.4 ) PHP Warning: range(): step exceeds the specified range Array ( [0] => 5.5 [1] => 5.6 [2] => 5.7 ) -- Edit this bug report at http://bugs.php.net/?id=50679&edit=1
#50682 [Opn->Bgs]: strtotime producing incorrect result
ID: 50682
Updated by: ras...@php.net
Reported By: keefeg at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: FreeBSD 6.2
PHP Version: 5.2.12
New Comment:
That's because you are asking for the same day last month which doesn't
exist since November doesn't have 31 days. November 31 gets normalized
to Dec 1. If you are using last/next make sure you feed it a recurring
starting point. Like the 1st of the sequence, in this case the 1st of
the month.
Previous Comments:
[2010-01-06 20:28:57] keefeg at gmail dot com
Description:
strtotime does not handle the "last month" parameter correctly all the
time.
Reproduce code:
---
---
>From manual page: function.strtotime#Description
---
$ny = strtotime("31 December 2009");
echo "this month: " . date('Ym', strtotime("now", $ny)) . "\n";
echo "last month: " . date('Ym', strtotime("last month", $ny)) . "\n";
Expected result:
I would like it to produce this result:
this month: 200912
last month: 200911
Actual result:
--
It prints this result:
this month: 200912
last month: 200912
--
Edit this bug report at http://bugs.php.net/?id=50682&edit=1
#50682 [Bgs]: strtotime producing incorrect result
ID: 50682
User updated by: keefeg at gmail dot com
Reported By: keefeg at gmail dot com
Status: Bogus
Bug Type: Date/time related
Operating System: FreeBSD 6.2
PHP Version: 5.2.12
New Comment:
I understand your explanation, but the results still seem incorrect.
Under reasonable circumstances even programmers shouldn't have to
consider "last month" to be equal to "this month."
In the context of "last month", it should first decrement the month,
and then if that particular day (31st of November) does not exist, it
should then decrement the day until it reaches a valid day (30th of
November).
The way it is now breaks programs in a non-obvious way. I use that
code to daily make a list of archive files to "keep" (now, -1 month, -2
month, -3 month) and on the 31st of December it ended up deleting the
november file because it thought "-1 month" was December.
I'll work around using the 1st of the month, but it at least merits a
warning in the documentation.
Thanks for PHP, it's incredibly useful!
Previous Comments:
[2010-01-06 20:53:58] ras...@php.net
That's because you are asking for the same day last month which doesn't
exist since November doesn't have 31 days. November 31 gets normalized
to Dec 1. If you are using last/next make sure you feed it a recurring
starting point. Like the 1st of the sequence, in this case the 1st of
the month.
[2010-01-06 20:28:57] keefeg at gmail dot com
Description:
strtotime does not handle the "last month" parameter correctly all the
time.
Reproduce code:
---
---
>From manual page: function.strtotime#Description
---
$ny = strtotime("31 December 2009");
echo "this month: " . date('Ym', strtotime("now", $ny)) . "\n";
echo "last month: " . date('Ym', strtotime("last month", $ny)) . "\n";
Expected result:
I would like it to produce this result:
this month: 200912
last month: 200911
Actual result:
--
It prints this result:
this month: 200912
last month: 200912
--
Edit this bug report at http://bugs.php.net/?id=50682&edit=1
#50682 [Bgs]: strtotime producing incorrect result
ID: 50682
Updated by: ras...@php.net
Reported By: keefeg at gmail dot com
Status: Bogus
Bug Type: Date/time related
Operating System: FreeBSD 6.2
PHP Version: 5.2.12
New Comment:
This isn't something we made up. We are simply following the GNU
strtotime convention as it is implemented by your command line date
utility and many others as well. It is described here:
http://www.gnu.org/software/tar/manual/html_node/Relative-items-in-
date-strings.html#SEC120
Note the second last paragraph that talks about the fuzz in units.
Whether this should have been done this way or not is debatable, but it
is a consistent convention and we don't want to stray from that.
Previous Comments:
[2010-01-07 01:37:43] keefeg at gmail dot com
I understand your explanation, but the results still seem incorrect.
Under reasonable circumstances even programmers shouldn't have to
consider "last month" to be equal to "this month."
In the context of "last month", it should first decrement the month,
and then if that particular day (31st of November) does not exist, it
should then decrement the day until it reaches a valid day (30th of
November).
The way it is now breaks programs in a non-obvious way. I use that
code to daily make a list of archive files to "keep" (now, -1 month, -2
month, -3 month) and on the 31st of December it ended up deleting the
november file because it thought "-1 month" was December.
I'll work around using the 1st of the month, but it at least merits a
warning in the documentation.
Thanks for PHP, it's incredibly useful!
[2010-01-06 20:53:58] ras...@php.net
That's because you are asking for the same day last month which doesn't
exist since November doesn't have 31 days. November 31 gets normalized
to Dec 1. If you are using last/next make sure you feed it a recurring
starting point. Like the 1st of the sequence, in this case the 1st of
the month.
[2010-01-06 20:28:57] keefeg at gmail dot com
Description:
strtotime does not handle the "last month" parameter correctly all the
time.
Reproduce code:
---
---
>From manual page: function.strtotime#Description
---
$ny = strtotime("31 December 2009");
echo "this month: " . date('Ym', strtotime("now", $ny)) . "\n";
echo "last month: " . date('Ym', strtotime("last month", $ny)) . "\n";
Expected result:
I would like it to produce this result:
this month: 200912
last month: 200911
Actual result:
--
It prints this result:
this month: 200912
last month: 200912
--
Edit this bug report at http://bugs.php.net/?id=50682&edit=1
#35368 [Com]: PDO query does not work properly with serialize
ID: 35368 Comment by: uggabc at yahoo dot cn Reported By: lists at cyberlot dot net Status: Suspended Bug Type: PDO related Operating System: * PHP Version: 6CVS, 5CVS Assigned To: wez New Comment: It was my pleasure to visit your Website. I am also very Website you enjoy the article.And I also have http://www.emu-boots.net/";>emu boots he feeling that it was really a pity that we didn¡¯ t meet each other earlier. Because the kindness and warmth in your Website can make me completely relaxed and happy. I hope that you will visit my blog too Previous Comments: [2005-11-27 22:11:06] w...@php.net We managed to reproduce the problem; it's a problem with the query rewriter when it maps :name to ?. If the string is embedded in the SQL using single quotes, but has double quotes backslashed, the string it too tricky for the parser to follow, and it ends up transforming parts of the serialized string that it shouldn't. There are three possible workarounds for this issue, in order of preference: - Don't embed serialized data into the query string; use bound parameters (that's what they're there for). In future versions of PDO, prepared statements may be cacheable in persistent connections, leading to a performance gain. - Use PDO::quote() to correctly quote the string - Use PDO::exec() to fire off this UPDATE/INSERT statement; it uses an alternate API that doesn't need to handle parameters. [2005-11-25 16:40:35] tony2...@php.net This is fixed in CVS, get a fresh snapshot and try again. [2005-11-25 16:32:07] lists at cyberlot dot net To try and narrow this down and be able to play with the code more I recompiled PHP 5.1 without pdo support then compiled seperate modules however I could not get pdo_mysql to compile. I phpized ./configure and make and get the following error checking for MySQL support for PDO... yes, shared checking for mysql_config... /usr/bin/mysql_config checking for mysql_query... no configure: error: mysql_query missing!? Might be related? So I forced a install of pdo_mysql RC2 The bug goes away, Same exact script but everything is working... So its either a diffrence between pdo_mysql RC2 or some wierd issue with shared vs compiled in. I hope that helps somehow? [2005-11-25 15:14:33] lists at cyberlot dot net What OS are you testing on? All I have are Centos/Redhat based boxes to test on. Also if this helps I always download directly from MySQL I never use the DIST included rpms. [2005-11-25 15:11:22] lists at cyberlot dot net Run this on another box, MySQL 4.1.12 and php 5.1.0RC4 same results 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/35368 -- Edit this bug report at http://bugs.php.net/?id=35368&edit=1
#35368 [Com]: PDO query does not work properly with serialize
ID: 35368 Comment by: uggabc at yahoo dot cn Reported By: lists at cyberlot dot net Status: Suspended Bug Type: PDO related Operating System: * PHP Version: 6CVS, 5CVS Assigned To: wez New Comment: It was my pleasure to visit your Website. I am also very Website you enjoy the article.And I also have [url=http://www.emu-boots.net/]emu boots[/url] he feeling that it was really a pity that we didn¡¯ t meet each other earlier. Because the kindness and warmth in your Website can make me completely relaxed and happy. I hope that you will visit my blog too Previous Comments: [2010-01-07 06:48:39] uggabc at yahoo dot cn It was my pleasure to visit your Website. I am also very Website you enjoy the article.And I also have http://www.emu-boots.net/";>emu boots he feeling that it was really a pity that we didn¡¯ t meet each other earlier. Because the kindness and warmth in your Website can make me completely relaxed and happy. I hope that you will visit my blog too [2005-11-27 22:11:06] w...@php.net We managed to reproduce the problem; it's a problem with the query rewriter when it maps :name to ?. If the string is embedded in the SQL using single quotes, but has double quotes backslashed, the string it too tricky for the parser to follow, and it ends up transforming parts of the serialized string that it shouldn't. There are three possible workarounds for this issue, in order of preference: - Don't embed serialized data into the query string; use bound parameters (that's what they're there for). In future versions of PDO, prepared statements may be cacheable in persistent connections, leading to a performance gain. - Use PDO::quote() to correctly quote the string - Use PDO::exec() to fire off this UPDATE/INSERT statement; it uses an alternate API that doesn't need to handle parameters. [2005-11-25 16:40:35] tony2...@php.net This is fixed in CVS, get a fresh snapshot and try again. [2005-11-25 16:32:07] lists at cyberlot dot net To try and narrow this down and be able to play with the code more I recompiled PHP 5.1 without pdo support then compiled seperate modules however I could not get pdo_mysql to compile. I phpized ./configure and make and get the following error checking for MySQL support for PDO... yes, shared checking for mysql_config... /usr/bin/mysql_config checking for mysql_query... no configure: error: mysql_query missing!? Might be related? So I forced a install of pdo_mysql RC2 The bug goes away, Same exact script but everything is working... So its either a diffrence between pdo_mysql RC2 or some wierd issue with shared vs compiled in. I hope that helps somehow? [2005-11-25 15:14:33] lists at cyberlot dot net What OS are you testing on? All I have are Centos/Redhat based boxes to test on. Also if this helps I always download directly from MySQL I never use the DIST included rpms. 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/35368 -- Edit this bug report at http://bugs.php.net/?id=35368&edit=1
#35368 [Com]: PDO query does not work properly with serialize
ID: 35368 Comment by: uggabc at yahoo dot cn Reported By: lists at cyberlot dot net Status: Suspended Bug Type: PDO related Operating System: * PHP Version: 6CVS, 5CVS Assigned To: wez New Comment: It was my pleasure to visit your Website. I am also very Website you enjoy the article.And I also have http://www.emu-boots.net/ emu boots he feeling that it was really a pity that we didn ¡¯ t meet each other earlier. Because the kindness and warmth in your Website can make me completely relaxed and happy. I hope that you will visit my blog too to see if you can have the same feeling. Previous Comments: [2010-01-07 06:50:39] uggabc at yahoo dot cn It was my pleasure to visit your Website. I am also very Website you enjoy the article.And I also have [url=http://www.emu-boots.net/]emu boots[/url] he feeling that it was really a pity that we didn¡¯ t meet each other earlier. Because the kindness and warmth in your Website can make me completely relaxed and happy. I hope that you will visit my blog too [2010-01-07 06:48:39] uggabc at yahoo dot cn It was my pleasure to visit your Website. I am also very Website you enjoy the article.And I also have http://www.emu-boots.net/";>emu boots he feeling that it was really a pity that we didn¡¯ t meet each other earlier. Because the kindness and warmth in your Website can make me completely relaxed and happy. I hope that you will visit my blog too [2005-11-27 22:11:06] w...@php.net We managed to reproduce the problem; it's a problem with the query rewriter when it maps :name to ?. If the string is embedded in the SQL using single quotes, but has double quotes backslashed, the string it too tricky for the parser to follow, and it ends up transforming parts of the serialized string that it shouldn't. There are three possible workarounds for this issue, in order of preference: - Don't embed serialized data into the query string; use bound parameters (that's what they're there for). In future versions of PDO, prepared statements may be cacheable in persistent connections, leading to a performance gain. - Use PDO::quote() to correctly quote the string - Use PDO::exec() to fire off this UPDATE/INSERT statement; it uses an alternate API that doesn't need to handle parameters. [2005-11-25 16:40:35] tony2...@php.net This is fixed in CVS, get a fresh snapshot and try again. [2005-11-25 16:32:07] lists at cyberlot dot net To try and narrow this down and be able to play with the code more I recompiled PHP 5.1 without pdo support then compiled seperate modules however I could not get pdo_mysql to compile. I phpized ./configure and make and get the following error checking for MySQL support for PDO... yes, shared checking for mysql_config... /usr/bin/mysql_config checking for mysql_query... no configure: error: mysql_query missing!? Might be related? So I forced a install of pdo_mysql RC2 The bug goes away, Same exact script but everything is working... So its either a diffrence between pdo_mysql RC2 or some wierd issue with shared vs compiled in. I hope that helps somehow? 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/35368 -- Edit this bug report at http://bugs.php.net/?id=35368&edit=1
