Bug #63920 [Opn->Fbk]: imagejpeg
Edit report at https://bugs.php.net/bug.php?id=63920&edit=1 ID: 63920 Updated by: paj...@php.net Reported by:zebroid at list dot ru Summary:imagejpeg -Status: Open +Status: Feedback Type: Bug Package:GD related Operating System: debian 6.0 PHP Version:5.4.10 Block user comment: N Private report: N New Comment: 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. Previous Comments: [2013-01-06 17:04:03] zebroid at list dot ru Description: after update php 5.3->php 5.4 i have a problem with image thumbnails in vbulletin forum v 3.8.7 (last in the 3.x branch) after some investigations i find the problem. code imagejpeg($image, '', $quality); works fine in php 5.3 and output jpeg image to browser but in php 5.4 in only generate error: Warning: imagejpeg(): Filename cannot be empty in [path]/includes/class_image.php on line 1428 i read a documentation http://php.net/manual/en/function.imagejpeg.php and understand that now it should works maybe in more 'pedantic' way (imagejpeg($image, NULL, $quality)), but maybe for the Backward Compatible you make this function work in a old way? (NULL or '' in secord parameter to output jpeg) or, at least, mention about that on http://php.net/manual/en/migration54.incompatible.php vBulletin v3.x still rather popular and suppose that not only i may face this problem (and sorry for my russian-english) Test script: --- imagejpeg($image, '', $quality); <-work in php 5.3, dont work in php 5.4 -- Edit this bug report at https://bugs.php.net/bug.php?id=63920&edit=1
Bug #63882 [Ana]: zend_std_compare_objects crash on recursion
Edit report at https://bugs.php.net/bug.php?id=63882&edit=1 ID: 63882 Updated by: paj...@php.net Reported by:gynvael at coldwind dot pl Summary:zend_std_compare_objects crash on recursion Status: Analyzed Type: Bug Package:Reproducible crash Operating System: any PHP Version:5.4.10 -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N New Comment: hi Dmitry, Can you take a look at the patch please? btw, don't we have that already in place in the hash table for that? Wondering if we really need to add that for props as they are stored in the hash table anyway. Previous Comments: [2013-01-02 19:03:05] a...@php.net The stack overflow happens only with default class properties. Non default object properties are stored in the HashTable and it's protected against recursion. The solution I'm suggesting in the patch is simple but could be binary incompatible to the stuff in the outer world. I mean the stuff like pre compiled pecl extensions, as the zend_object size changes. May be that should only go into 5.5 Another solution were quite complex - compare_function could be extended with a recursion count argument, but that would need a lot of places to be touched. [2013-01-02 18:53:25] a...@php.net The following patch has been added/updated: Patch Name: 63882.patch Revision: 1357152805 URL: https://bugs.php.net/patch-display.php?bug=63882&patch=63882.patch&revision=1357152805 [2013-01-01 19:27:30] gynvael at coldwind dot pl Description: The standard PHP object compare handler (zend_std_compare_objects) together with the == operator (compare_function) have no limit on nesting levels nor any anti- recursion protection. The array comparing function in compare_function does have this protection. It would be good to add it to the object standard compare handler as well. Test script: --- x = $testobj1; $testobj2->x = $testobj2; $testobj1 == $testobj2; // Crash (stack exhaustion) Expected result: PHP Fatal error: Nesting level too deep - recursive dependency? in test.php on line 9 Actual result: -- segmentation fault (core dumped) -- Edit this bug report at https://bugs.php.net/bug.php?id=63882&edit=1
Bug #63925 [Csd->Nab]: $http_response_header unavailable in command line
Edit report at https://bugs.php.net/bug.php?id=63925&edit=1
ID: 63925
Updated by: ras...@php.net
Reported by:litesoftwares at gmail dot com
Summary:$http_response_header unavailable in command line
-Status: Closed
+Status: Not a bug
Type: Bug
Package:Variables related
Operating System: Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
Previous Comments:
[2013-01-07 05:29:08] litesoftwares at gmail dot com
Mistake report
[2013-01-07 05:23:23] litesoftwares at gmail dot com
Description:
The given test script does not work in command line mode.
---
>From manual page:
http://www.php.net/reserved.variables.httpresponseheader#refsect1-
reserved.variables.httpresponseheader-description
---
Test script:
---
function get_contents() {
file_get_contents("http://example.com";);
var_dump($http_response_header);
}
Expected result:
array(9) {
[0]=>
string(15) "HTTP/1.1 200 OK"
[1]=>
string(35) "Date: Sat, 12 Apr 2008 17:30:38 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(44) "Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT"
[4]=>
string(27) "ETag: "280100-1b6-80bfd280""
[5]=>
string(20) "Accept-Ranges: bytes"
[6]=>
string(19) "Content-Length: 438"
[7]=>
string(17) "Connection: close"
[8]=>
string(38) "Content-Type: text/html; charset=UTF-8"
}
Actual result:
--
NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=63925&edit=1
Bug #63925 [Opn->Csd]: $http_response_header unavailable in command line
Edit report at https://bugs.php.net/bug.php?id=63925&edit=1
ID: 63925
User updated by:litesoftwares at gmail dot com
Reported by:litesoftwares at gmail dot com
Summary:$http_response_header unavailable in command line
-Status: Open
+Status: Closed
Type: Bug
Package:Variables related
Operating System: Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Mistake report
Previous Comments:
[2013-01-07 05:23:23] litesoftwares at gmail dot com
Description:
The given test script does not work in command line mode.
---
>From manual page:
http://www.php.net/reserved.variables.httpresponseheader#refsect1-
reserved.variables.httpresponseheader-description
---
Test script:
---
function get_contents() {
file_get_contents("http://example.com";);
var_dump($http_response_header);
}
Expected result:
array(9) {
[0]=>
string(15) "HTTP/1.1 200 OK"
[1]=>
string(35) "Date: Sat, 12 Apr 2008 17:30:38 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(44) "Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT"
[4]=>
string(27) "ETag: "280100-1b6-80bfd280""
[5]=>
string(20) "Accept-Ranges: bytes"
[6]=>
string(19) "Content-Length: 438"
[7]=>
string(17) "Connection: close"
[8]=>
string(38) "Content-Type: text/html; charset=UTF-8"
}
Actual result:
--
NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=63925&edit=1
[PHP-BUG] Bug #63925 [NEW]: $http_response_header unavailable in command line
From: litesoftwares at gmail dot com
Operating system: Linux
PHP version: Irrelevant
Package: Variables related
Bug Type: Bug
Bug description:$http_response_header unavailable in command line
Description:
The given test script does not work in command line mode.
---
>From manual page:
http://www.php.net/reserved.variables.httpresponseheader#refsect1-
reserved.variables.httpresponseheader-description
---
Test script:
---
function get_contents() {
file_get_contents("http://example.com";);
var_dump($http_response_header);
}
Expected result:
array(9) {
[0]=>
string(15) "HTTP/1.1 200 OK"
[1]=>
string(35) "Date: Sat, 12 Apr 2008 17:30:38 GMT"
[2]=>
string(29) "Server: Apache/2.2.3 (CentOS)"
[3]=>
string(44) "Last-Modified: Tue, 15 Nov 2005 13:24:10 GMT"
[4]=>
string(27) "ETag: "280100-1b6-80bfd280""
[5]=>
string(20) "Accept-Ranges: bytes"
[6]=>
string(19) "Content-Length: 438"
[7]=>
string(17) "Connection: close"
[8]=>
string(38) "Content-Type: text/html; charset=UTF-8"
}
Actual result:
--
NULL
--
Edit bug report at https://bugs.php.net/bug.php?id=63925&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63925&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63925&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63925&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63925&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63925&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63925&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63925&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63925&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63925&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63925&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63925&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63925&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63925&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63925&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63925&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63925&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63925&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63925&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63925&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63925&r=mysqlcfg
Bug #63893 [Asn]: poor efficiency of strtr() using array with keys of very different length
Edit report at https://bugs.php.net/bug.php?id=63893&edit=1 ID: 63893 Updated by: cataphr...@php.net Reported by:scope at planetavent dot de Summary:poor efficiency of strtr() using array with keys of very different length Status: Assigned Type: Bug Package:Strings related Operating System: Windows Server 2008 / RHEL 6.3 PHP Version:5.4.10 Assigned To:cataphract Block user comment: N Private report: N New Comment: My patch so far: https://github.com/cataphract/php-src/compare/strtr Previous Comments: [2013-01-03 14:34:36] scope at planetavent dot de Description: As the documentation of strtr() points out, strtr "... will be the most efficient when all the keys have the same size". Using keys of very different lengths results in poor performance, even on very small inputs. If the str_repeat() for "m" in the test script is adjusted to 2 the resulting runtime increases to 45 seconds for strtr() while str_replace() does not increase notably. There are cases where the replacement array is built dynamically, so there might be little control over the keylengths. It's easy to expand the example such that strtr() takes several hours compared to just a few seconds using str_replace(). Test script: --- 'b', $long_from_x => 'y' ); $start = microtime( true ); $result_1 = strtr( $text, $replacements ); echo "strtr: " . number_format( microtime( true ) - $start, 4 ) . "\n"; $start = microtime( true ); $result_2 = str_replace( array_keys( $replacements ), array_values( $replacements ), $text ); echo "str_replace: " . number_format( microtime( true ) - $start, 4 ) . "\n"; echo $result_1 === $result_2 ? "results match!\n": "no match!\n"; Expected result: strtr: 0.0001 str_replace: 0.0001 results match! Actual result: -- strtr: 2.4203 str_replace: 0.0001 results match! -- Edit this bug report at https://bugs.php.net/bug.php?id=63893&edit=1
[PHP-BUG] Req #63924 [NEW]: Allow const definitions for traits
From: bitluni at bitluni dot net Operating system: PHP version: 5.4.10 Package: Class/Object related Bug Type: Feature/Change Request Bug description:Allow const definitions for traits Description: const definitions are currently not supported in traits. It would be very useful. -- Edit bug report at https://bugs.php.net/bug.php?id=63924&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63924&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63924&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63924&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63924&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63924&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63924&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63924&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63924&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63924&r=support Expected behavior: https://bugs.php.net/fix.php?id=63924&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63924&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63924&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63924&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63924&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63924&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63924&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63924&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63924&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63924&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63924&r=mysqlcfg
[PHP-BUG] Bug #63923 [NEW]: filter_var( $mail, FILTER_VALIDATE_EMAIL) crash Apache if $mail longer than 155
From: remi at minimal-beton dot com Operating system: Windows 7 PHP version: 5.3.20 Package: Reproducible crash Bug Type: Bug Bug description:filter_var( $mail, FILTER_VALIDATE_EMAIL) crash Apache if $mail longer than 155 Description: WHEN USING filter_var( $mail, FILTER_VALIDATE_EMAIL) It EVERY TIME crashes Apache IF $mail is longer than 155 characters - [Mon Dec 10 14:08:34 2012] [notice] Parent: Received shutdown signal -- Shutting down the server. [Mon Dec 10 14:08:34 2012] [notice] Child 4212: Exit event signaled. Child process is ending. [Mon Dec 10 14:08:35 2012] [notice] Child 4212: Released the start mutex [Mon Dec 10 14:08:36 2012] [notice] Child 4212: All worker threads have exited. [Mon Dec 10 14:08:36 2012] [notice] Child 4212: Child process is exiting [Mon Dec 10 14:08:36 2012] [notice] Parent: Child process exited successfully. [Mon Dec 10 14:08:36 2012] [notice] Apache/2.2.22 (Win64) PHP/5.3.13 configured -- resuming normal operations [Mon Dec 10 14:08:36 2012] [notice] Server built: May 13 2012 19:41:17 [Mon Dec 10 14:08:36 2012] [notice] Parent: Created child process 2096 [Mon Dec 10 14:08:36 2012] [notice] Child 2096: Child process is running [Mon Dec 10 14:08:36 2012] [notice] Child 2096: Acquired the start mutex. [Mon Dec 10 14:08:36 2012] [notice] Child 2096: Starting 64 worker threads. [Mon Dec 10 14:08:36 2012] [notice] Child 2096: Starting thread to listen on port 80. [Mon Dec 10 14:08:36 2012] [notice] Child 2096: Starting thread to listen on port 80. Test script: --- filter_var( "maiooumaidtotypo3mailtotypo3imailtotypo3mailtotypo3mailtotypo3mailtosmailtotypo3ppmailtotypo3mailtopdsdmarcheddefensedbrando...@.fr", FILTER_VALIDATE_EMAIL)); Expected result: function must return FALSE or TRUE Actual result: -- It EVERY TIME crashes Apache - [Mon Dec 10 14:08:34 2012] [notice] Parent: Received shutdown signal -- Shutting down the server. [Mon Dec 10 14:08:34 2012] [notice] Child 4212: Exit event signaled. Child process is ending. [Mon Dec 10 14:08:35 2012] [notice] Child 4212: Released the start mutex [Mon Dec 10 14:08:36 2012] [notice] Child 4212: All worker threads have exited. [Mon Dec 10 14:08:36 2012] [notice] Child 4212: Child process is exiting [Mon Dec 10 14:08:36 2012] [notice] Parent: Child process exited successfully. [Mon Dec 10 14:08:36 2012] [notice] Apache/2.2.22 (Win64) PHP/5.3.13 configured -- resuming normal operations [Mon Dec 10 14:08:36 2012] [notice] Server built: May 13 2012 19:41:17 [Mon Dec 10 14:08:36 2012] [notice] Parent: Created child process 2096 [Mon Dec 10 14:08:36 2012] [notice] Child 2096: Child process is running [Mon Dec 10 14:08:36 2012] [notice] Child 2096: Acquired the start mutex. [Mon Dec 10 14:08:36 2012] [notice] Child 2096: Starting 64 worker threads. [Mon Dec 10 14:08:36 2012] [notice] Child 2096: Starting thread to listen on port 80. [Mon Dec 10 14:08:36 2012] [notice] Child 2096: Starting thread to listen on port 80. -- Edit bug report at https://bugs.php.net/bug.php?id=63923&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63923&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63923&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63923&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63923&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63923&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63923&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63923&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63923&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63923&r=support Expected behavior: https://bugs.php.net/fix.php?id=63923&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63923&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63923&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63923&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63923&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63923&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63923&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63923&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63923&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63923&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63923&r=mysqlcfg
Bug #63921 [Opn]: sqlite3::bindvalue and relative PHP functions aren't using sqlite3_*_int64 API
Edit report at https://bugs.php.net/bug.php?id=63921&edit=1
ID: 63921
Updated by: google...@php.net
Reported by:google...@php.net
Summary:sqlite3::bindvalue and relative PHP functions aren't
using sqlite3_*_int64 API
Status: Open
Type: Bug
Package:SQLite related
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
I've sent a PR for this as well on master. I hope to get it merged into
5.3.NEXT,
5.4.NEXT, and 5.5.NEXT for consistency with the fix for bug #63916 as they are
both related to sqlite3 driver.
https://github.com/php/php-src/pull/254
Previous Comments:
[2013-01-06 17:24:52] google...@php.net
Description:
The sqlite3::bindvalue and relative PHP functions aren't using sqlite3_*_int64
API functions internally or checking for a 64 bit build to do so. As a result
using SQLITE3_INTEGER constants in calls to bindValue cause internal cast to 32
bit int. This is unexpected behavior and the API calls exist internally
sqlite3.
This is also related to bug #63916 which I also patched. I'm providing an
additional patch for ext/sqlite3 in relation for the same bug.
Test script:
---
$num = 14313234244; // notice this exceeds 32 bits
$conn = new sqlite3(':memory:');
$conn->query('CREATE TABLE users (id INTEGER NOT NULL, num INTEGER NOT NULL,
PRIMARY KEY(id))');
$stmt = $conn->prepare('insert into users (id, num) values (:id, :num)');
$stmt->bindValue(':id', 1, SQLITE3_INTEGER);
$stmt->bindValue(':num', $num, SQLITE3_INTEGER);
$stmt->execute();
$stmt = $conn->query('SELECT num FROM users');
$result = $stmt->fetchArray();
printf("Expected: %d Received: %d\n", $num, $result[0]);
Expected result:
Expected: 14313234244 Received: 14313234244
Actual result:
--
Expected: 14313234244 Received: 294714180
--
Edit this bug report at https://bugs.php.net/bug.php?id=63921&edit=1
[PHP-BUG] Bug #63922 [NEW]: stream_select on pipes returned by proc_open returns streams that are not ready
From: LastDragon at yandex dot ru
Operating system: Windows
PHP version: 5.4.10
Package: Streams related
Bug Type: Bug
Bug description:stream_select on pipes returned by proc_open returns streams
that are not ready
Description:
This is https://bugs.php.net/bug.php?id=44908 that is still exists... ~5
years :'(
> When using stream_select() on pipes returned by proc_open() in Windows,
input streams that are not ready are returned in the modified $read array.
Test script:
---
array("pipe", "r"), // stdin
1 => array("pipe", "w"), // stdout
2 => array("pipe", "w"), // stderr
);
$process = proc_open($cmd, $descriptors, $pipes);
if (is_resource($process)) {
$read= [$pipes[1], $pipes[2]];
$write = null;
$except = null;
$changed = stream_select($read, $write, $except, null);
var_dump($changed, $read, $write);
}
// stream_select.process.php
resource(5) of type (stream)
}
NULL
Actual result:
--
int(2)
array(2) {
[0]=>
resource(5) of type (stream)
[1]=>
resource(6) of type (stream)
}
NULL
--
Edit bug report at https://bugs.php.net/bug.php?id=63922&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63922&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63922&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63922&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63922&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63922&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63922&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63922&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63922&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63922&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63922&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63922&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63922&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63922&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63922&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63922&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63922&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63922&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63922&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63922&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63922&r=mysqlcfg
[PHP-BUG] Bug #63921 [NEW]: sqlite3::bindvalue and relative PHP functions aren't using sqlite3_*_int64 API
From: googleguy
Operating system:
PHP version: 5.4.10
Package: SQLite related
Bug Type: Bug
Bug description:sqlite3::bindvalue and relative PHP functions aren't using
sqlite3_*_int64 API
Description:
The sqlite3::bindvalue and relative PHP functions aren't using
sqlite3_*_int64
API functions internally or checking for a 64 bit build to do so. As a
result
using SQLITE3_INTEGER constants in calls to bindValue cause internal cast
to 32
bit int. This is unexpected behavior and the API calls exist internally
sqlite3.
This is also related to bug #63916 which I also patched. I'm providing an
additional patch for ext/sqlite3 in relation for the same bug.
Test script:
---
$num = 14313234244; // notice this exceeds 32 bits
$conn = new sqlite3(':memory:');
$conn->query('CREATE TABLE users (id INTEGER NOT NULL, num INTEGER NOT
NULL, PRIMARY KEY(id))');
$stmt = $conn->prepare('insert into users (id, num) values (:id, :num)');
$stmt->bindValue(':id', 1, SQLITE3_INTEGER);
$stmt->bindValue(':num', $num, SQLITE3_INTEGER);
$stmt->execute();
$stmt = $conn->query('SELECT num FROM users');
$result = $stmt->fetchArray();
printf("Expected: %d Received: %d\n", $num, $result[0]);
Expected result:
Expected: 14313234244 Received: 14313234244
Actual result:
--
Expected: 14313234244 Received: 294714180
--
Edit bug report at https://bugs.php.net/bug.php?id=63921&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63921&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63921&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63921&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63921&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63921&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63921&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63921&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63921&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63921&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63921&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63921&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63921&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63921&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63921&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63921&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63921&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63921&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63921&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63921&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63921&r=mysqlcfg
[PHP-BUG] Bug #63920 [NEW]: imagejpeg
From: zebroid at list dot ru Operating system: debian 6.0 PHP version: 5.4.10 Package: GD related Bug Type: Bug Bug description:imagejpeg Description: after update php 5.3->php 5.4 i have a problem with image thumbnails in vbulletin forum v 3.8.7 (last in the 3.x branch) after some investigations i find the problem. code imagejpeg($image, '', $quality); works fine in php 5.3 and output jpeg image to browser but in php 5.4 in only generate error: Warning: imagejpeg(): Filename cannot be empty in [path]/includes/class_image.php on line 1428 i read a documentation http://php.net/manual/en/function.imagejpeg.php and understand that now it should works maybe in more 'pedantic' way (imagejpeg($image, NULL, $quality)), but maybe for the Backward Compatible you make this function work in a old way? (NULL or '' in secord parameter to output jpeg) or, at least, mention about that on http://php.net/manual/en/migration54.incompatible.php vBulletin v3.x still rather popular and suppose that not only i may face this problem (and sorry for my russian-english) Test script: --- imagejpeg($image, '', $quality); <-work in php 5.3, dont work in php 5.4 -- Edit bug report at https://bugs.php.net/bug.php?id=63920&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63920&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63920&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63920&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63920&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63920&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63920&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63920&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63920&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63920&r=support Expected behavior: https://bugs.php.net/fix.php?id=63920&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63920&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63920&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63920&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63920&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63920&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63920&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63920&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63920&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63920&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63920&r=mysqlcfg
Bug #63615 [Asn]: DateTime::modify() ignores timezone
Edit report at https://bugs.php.net/bug.php?id=63615&edit=1
ID: 63615
Updated by: der...@php.net
Reported by:flavius dot as at gmail dot com
Summary:DateTime::modify() ignores timezone
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Linux x64
PHP Version:5.4.9
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
The original idea behind modify was to only add specific hours, minutes, days
etc. and not to *set* specific values such as timezones (or year, month, etc).
I am therefore leaning to saying to this patch: "this is not how things are
supposed to work".
Previous Comments:
[2012-11-26 21:42:36] flavius dot as at gmail dot com
Description:
DateTime::modify() ignores the timezone (when using the RFC 2822 format for
instance).
The right timestamp should be $t1 (from the example below).
Test script:
---
modify($str);
$t1 = $d1->getTimestamp();
$t2 = $d2->getTimestamp();
$tz1 = $d1->getTimezone()->getName();
$tz2 = $d2->getTimezone()->getName();
$f1 = $d1->format(DateTime::RFC2822);
$f2 = $d2->format(DateTime::RFC2822);
var_dump(compact('t1', 't2', 'tz1', 'tz2', 'f1', 'f2'));
/*
array(6) {
't1' =>
int(1334046476)
't2' =>
int(1334050076)
'tz1' =>
string(6) "+03:00"
'tz2' =>
string(13) "Europe/Vienna"
'f1' =>
string(31) "Tue, 10 Apr 2012 11:27:56 +0300"
'f2' =>
string(31) "Tue, 10 Apr 2012 11:27:56 +0200"
}
*/
Expected result:
$t1 == $t2
Actual result:
--
$t1 != $t2
--
Edit this bug report at https://bugs.php.net/bug.php?id=63615&edit=1
Bug->Req #40743 [ReO]: DateTime ignores the TimeZone object passed to the constructor
Edit report at https://bugs.php.net/bug.php?id=40743&edit=1
ID: 40743
Updated by: der...@php.net
Reported by:ddb at bitxtender dot de
Summary:DateTime ignores the TimeZone object passed to the
constructor
Status: Re-Opened
-Type: Bug
+Type: Feature/Change Request
Package:Date/time related
Operating System: Win XP
PHP Version:5.2.1
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
It's still not a bug, so changing it to a feature request. The "@" acts as a
timezone specifier and if there is one of those in the string to parse, then a
passed in timezone doesn't override this. This works the same as:
$a = new DateTime("2013-01-06 16:12 CEST", new DateTimeZone("Asia/Tokyo"));
var_dump( $a );
which shows:
class DateTime#1 (3) {
public $date =>
string(19) "2013-01-06 16:12:00"
public $timezone_type =>
int(2)
public $timezone =>
string(4) "CEST"
}
Previous Comments:
[2012-05-17 19:29:38] cataphr...@php.net
Still present in master.
getTimeZone()->getName());
object(DateTime)#1 (3) {
["date"]=>
string(19) "2012-05-17 19:29:15"
["timezone_type"]=>
int(1)
["timezone"]=>
string(6) "+00:00"
}
string(6) "+00:00"
[2012-02-09 02:28:58] kavi at postpro dot net
This bug is NOT fixed on 5.3.3 or trunk.
$ php
2005-08-15 15:52:01
[timezone_type] => 2
[timezone] => PDT
)
[2008-01-17 18:50:12] der...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2007-04-19 20:53:33] artur at jedlinski dot pl
It is ignoring the #2 parameter when you put the timezone info inside the #1.
It's *absolutely* unacceptable.
// Europe/Warsaw = GMT +0200
$dateSrc = '2007-04-19 12:50:00 GMT';
$dateTime = new DateTime($dateSrc, new DateTimeZone('Europe/Warsaw'));
echo $dateTime->format('H:i:s')."";
// RESULT: 12:50:00 (expected: 14:50:00)
$dateTime->setTimeZone(new DateTimeZone('Europe/Warsaw'));
echo $dateTime->format('H:i:s')."";
// RESULT: 14:50:00 (correct)
IMHO the most intuitive way is to create the date based on the #1, but displays
it using #2.
It's not only strange it ignores #2, but in fact it's strange that the internal
DateTime pointer is set to timezone provided in #1 at all. If the
date_default_timezone_set() was set to some TZ, it should create dates within
this timezone if one doesn't state otherwise (using #2). Of course the timezone
info from #1 should be used, but only to calculate the actual timestamp.
date_default_timezone_set('Europe/Warsaw');
$dateSrc = '2007-04-19 12:50:00 GMT';
$dateTime = new DateTime($dateSrc);
echo $dateTime->format('H:i:s')."";
// RESULT: 12:50:00 (expected: 14:50:00)
Currently, it's pretty complicated to translate dates from one timezone to
another - you have to use DateTime::setTimeZone(), when one line should do the
thing:
$dateTime = new DateTime($dateWithSrcTimeZone, $timeZoneToDisplay);
(or even without $timeZoneToDisplay if you want to use your current TZ).
[2007-04-11 14:45:46] der...@php.net
It's not totally ignored, but something fishy is going on. See the following
script + output:
format(DATE_RFC822 . " e T O"), "\n";
$dt = new DateTime('@' . time());
echo $dt->format(DATE_RFC822 . " e T O"), "\n";
$dt = new DateTime('@' . time(), new DateTimeZone('Europe/Berlin'));
echo $dt->format(DATE_RFC822 . " e T O"), "\n";
?>
Wed, 11 Apr 07 16:42:40 +0200 Europe/Oslo CEST +0200
Wed, 11 Apr 07 14:42:40 +0100 Europe/Oslo GMT+0100 +0100
Wed, 11 Apr 07 14:42:40 +0100 Europe/Berlin GMT+0100 +0100
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=40743
--
Edit this bug report at https://bugs.php.net/bug.php?id=40743&edit=1
Req #33445 [Asn->Opn]: strftime() arguments are system dependent
Edit report at https://bugs.php.net/bug.php?id=33445&edit=1
ID: 33445
Updated by: der...@php.net
Reported by:richard dot quadling at bandvulc dot co dot uk
Summary:strftime() arguments are system dependent
-Status: Assigned
+Status: Open
Type: Feature/Change Request
Package:Date/time related
Operating System: *
PHP Version:5.0.4
-Assigned To:derick
+Assigned To:
Block user comment: N
Private report: N
Previous Comments:
[2005-08-11 20:18:15] der...@php.net
The fix up of strftime() is not done though - please keep it assigned.
[2005-08-11 20:15:14] nlop...@php.net
Already implemented in PHP 5.1 as date('o').
[2005-06-23 13:32:10] der...@php.net
This will be re-implemented very soon, so stay tuned!
[2005-06-23 10:44:16] richard dot quadling at bandvulc dot co dot uk
Maybe a better solution would be to make the strftime and date functions the
same and to consolidate the code to remove the dependency on platform specific
libraries (e.g. the Windows strftime function does not support V,G or g).
Alternatively, amend the documentation to indicate which formats are supported
by which platform.
It does seem that both of these functions do the same job and could be
consilidated though.
Richard.
[2005-06-23 10:17:55] richard dot quadling at bandvulc dot co dot uk
Description:
This could also be a fix for a "Will Not Fix" bug #22711.
On Windows, the strftime() function does not support %V, %G or %g.
The date() function supports 'W' which deals with %V (if you get what I mean),
but when the week number is 52 or 53 and you are looking at a January date,
getting the correct year also would be useful.
I've included below a CVS diff datetime.c.
I don't know who to send it to.
date('V') emulates strftime('%G');
date('v') emulates strftime('%g');
I've also rewritten the date('W') code to combine with V and v.
Index: datetime.c
===
RCS file: /repository/php-src/ext/standard/datetime.c,v
retrieving revision 1.129
diff -u -r1.129 datetime.c
--- datetime.c 19 Jun 2005 22:15:26 - 1.129
+++ datetime.c 23 Jun 2005 08:00:48 -
@@ -288,7 +288,7 @@
pval **format, **timestamp;
time_t the_time;
struct tm *ta, tmbuf;
- int i, size = 0, length, h, beat, fd, wd, yd, wk;
+ int i, size = 0, length, h, beat, fd, wd, yd, wk, yr;
char tmp_buff[32];
#if !HAVE_TM_GMTOFF
long tzone;
@@ -382,6 +382,7 @@
size += 5;
break;
case 'Y': /* year, numeric, 4 digits */
+ case 'V': /* ISO-8601 year number of
year, numeric, 4 digits */
size += 4;
break;
case 'M': /* month, textual, 3 letters */
@@ -406,6 +407,7 @@
case 'S': /* standard english suffix for
the day of the month (e.g. 3rd, 2nd, etc) */
case 't': /* days in current month */
case 'W': /* ISO-8601 week number of
year, weeks starting on Monday */
+ case 'v': /* ISO-8601 year number of
year, numeric, 2 digits */
size += 2;
break;
case '\\':
@@ -641,27 +643,67 @@
strcat(Z_STRVAL_P(return_value), tmp_buff);
break;
case 'W': /* ISO-8601 week number of
year, weeks starting on Monday */
- wd = ta->tm_wday == 0 ? 6 : ta->tm_wday - 1; /*
weekday */
- yd = ta->tm_yday + 1;
/* days since January 1st */
-
- fd = (7 + wd - yd % 7+ 1) % 7;
/* weekday (1st January) */
-
- /* week is a last year week (52 or 53) */
- if ((yd <= 7 - fd) && fd > 3){
- wk = (fd == 4 || (fd == 5 &&
isleap((ta->tm_year + YEAR_BASE - 1 ? 53 : 52;
- }
- /* week is a next year week (1) */
- else if (isleap((ta->tm_year+YEAR_BASE)) + 365
- yd < 3 - wd){
Req #28016 [Asn->Opn]: is_resource() returns false for resources of type "Unknown"
Edit report at https://bugs.php.net/bug.php?id=28016&edit=1 ID: 28016 Updated by: der...@php.net Reported by:php at ter dot dk Summary:is_resource() returns false for resources of type "Unknown" -Status: Assigned +Status: Open Type: Feature/Change Request Package:*General Issues Operating System: * PHP Version:* -Assigned To:derick +Assigned To: Block user comment: N Private report: N Previous Comments: [2004-07-19 19:16:39] php at afdelingp dot dk I have created a patch for Piotr Pawlow's version of php_imlib 0.3, fixing this issue for imlib (though I think the PHP behavior is strange at best). http://www.afdelingp.dk/files/php-4.3.8-imlib-rsrc.diff Best regards, Morten K. Poulsen [2004-04-16 15:11:33] sni...@php.net Derick: I agree, just change gettype() too. And imlib / other extensions using the wrong way in registering resources should be fixed. The 'non-named' resource is meant for something else.. [2004-04-16 11:05:22] der...@php.net If the imlib extension gives it a proper name then it should work fine, so I think it's also a bug there. [2004-04-16 08:37:21] php at ter dot dk But will it solve the problem in my situation? After all, I do have a resource by hand, and would be pretty sad if other functions wouldn't recognize it as a resource. I do agree though that making gettype not return "resource" for a closed resource (since is_resource() already does that). I just don't like the idea that these functions might not recognize my resource at all. - Peter Brodersen [2004-04-16 03:15:17] der...@php.net No, the fix was correct. Close() in this case destroyed the resource data in the variable, so it's no longer a resource anymore. I think the correct thing to do here is to make gettype() not show "resource" either. 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=28016 -- Edit this bug report at https://bugs.php.net/bug.php?id=28016&edit=1
Req #31875 [Asn->Opn]: get_defined_functions() should not list disabled functions
Edit report at https://bugs.php.net/bug.php?id=31875&edit=1 ID: 31875 Updated by: der...@php.net Reported by:paul at quakenet dot org Summary:get_defined_functions() should not list disabled functions -Status: Assigned +Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: * PHP Version:* -Assigned To:derick +Assigned To: Block user comment: N Private report: N Previous Comments: [2005-02-07 21:44:07] s...@php.net Assigning to Derick (as he requested) [2005-02-07 21:36:30] paul at quakenet dot org Description: get_defined_functions() returns a list of defined functions. This includes functions that have been disabled through the use of disable_functions, and therefore function_exists() returns as not being defined. get_definited_functions should only return the list of functions that are defined (and enabled) for users to use. -- Edit this bug report at https://bugs.php.net/bug.php?id=31875&edit=1
Bug #63913 [Com]: Segfault on preg_replace with some weird conditions
Edit report at https://bugs.php.net/bug.php?id=63913&edit=1 ID: 63913 Comment by: s...@php.net Reported by:s...@php.net Summary:Segfault on preg_replace with some weird conditions Status: Feedback Type: Bug Package:*Regular Expressions Operating System: Windows 7 x64 PHP Version:5.5.0alpha2 Block user comment: N Private report: N New Comment: Regarding the stack limit, I don't think so for two reasons: 1) it works on 5.4, 2) if you look at the code I tried a very simple .* pattern and that seems to trigger a failure too. I tried to increase pcre stuff to 10million and it still fails. As I said I couldn't reduce it further, if I tweak the code too much it stops crashing, and I could not really pinpoint it to an exact line that makes it fail. All it does is preg_replace calls though so I guess that's it. Anyway here is the stack trace, not sure it's any help: Full Call Stack Function Arg 1 Arg 2 Arg 3 Arg 4 Source ntdll!NtRaiseException+12 0094efa4 0094eff4 c005 ntdll!KiUserExceptionDispatcher+29 0094efa4 0094eff4 c005 Exception Information PHP5TS!ZEND_DO_FCALL_COMMON_HELPER_SPEC+E7DIn php__PID__248__Date__01_06_2013__Time_04_57_23PM__236__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!zend_do_fcall_common_helper_SPEC+e7d in c:\Users\seld\Apps\Server\PHP\php\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x05f804c8 on thread 0 Previous Comments: [2013-01-06 10:15:54] paj...@php.net Can you provide a full BT please? Debug symbols must be loaded or the symbol path. Also I suspect the classic pcre stack limit crash issue here. Can you try to increase it using edit in and run the test again? If you could provide the simple pcre call, if it us actually a pcre crash. [2013-01-06 00:15:10] s...@php.net Description: The composer test suite segfaults on 5.5 as you can see on https://travis-ci.org/composer/composer/jobs/3971664 I tried investigating on my machine and could not get to the bottom of it, so here are my findings, I hope someone else can reproduce and will have more of a clue than I do. The weirdest thing is that *sometimes* depending on the code changes I make to runme.php (see https://gist.github.com/7f465d4109d667a73984) it actually runs through fine, but most of the time it crashes. Then a bit later if I try and do a similar change it crashes again, either it's an intermittent system issue or something's very wrong. Since it also segfaults on travis I would assume the latter. Note that tweaking the input to the preg_replace call (by removing bits and pieces of testcase.php) also tends to make it work sometimes. For example removing the "}" at line 15 makes it work for me. Test script: --- Run these commands: git clone https://gist.github.com/7f465d4109d667a73984.git reproduce cd reproduce/ php runme.php Expected result: With 5.4.8 VC9 TS I get the following: $ php runme.php string(8) "content:" string(103) "https://bugs.php.net/bug.php?id=63913&edit=1
Bug #55397 [Ana->Csd]: comparsion of incomplete DateTime causes SIGSEGV
Edit report at https://bugs.php.net/bug.php?id=55397&edit=1 ID: 55397 Updated by: der...@php.net Reported by:ladislav at marek dot su Summary:comparsion of incomplete DateTime causes SIGSEGV -Status: Analyzed +Status: Closed Type: Bug Package:Date/time related Operating System: Linux PHP Version:5.3.7RC4 Assigned To:derick Block user comment: N Private report: N New Comment: Automatic comment on behalf of git...@derickrethans.nl Revision: http://git.php.net/?p=php-src.git;a=commit;h=ff9c1b12ff9c9533367d0d6200eb39189ad0124c Log: Fixed bug #55397: Comparsion of incomplete DateTime causes SIGSEGV. Previous Comments: [2011-08-14 16:39:13] larue...@php.net As Derick's advice, I added a WARNING msg, but my english is poor, so the mes need to be tweaked into a good one. [2011-08-14 16:37:53] larue...@php.net The following patch has been added/updated: Patch Name: bug55397.phpt Revision: 1313339873 URL: https://bugs.php.net/patch-display.php?bug=55397&patch=bug55397.phpt&revision=1313339873 [2011-08-14 16:37:26] larue...@php.net The following patch has been added/updated: Patch Name: bug55397.diff Revision: 1313339846 URL: https://bugs.php.net/patch-display.php?bug=55397&patch=bug55397.diff&revision=1313339846 [2011-08-14 16:37:16] larue...@php.net The following patch has been added/updated: Patch Name: bug55397.diff Revision: 1313339836 URL: https://bugs.php.net/patch-display.php?bug=55397&patch=bug55397.diff&revision=1313339836 [2011-08-14 16:36:41] larue...@php.net The following patch has been added/updated: Patch Name: bug55397.diff Revision: 1313339801 URL: https://bugs.php.net/patch-display.php?bug=55397&patch=bug55397.diff&revision=1313339801 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=55397 -- Edit this bug report at https://bugs.php.net/bug.php?id=55397&edit=1
Req #52126 [Asn->Csd]: The mail.log added in PHP 5.3.0 has no timestamps.
Edit report at https://bugs.php.net/bug.php?id=52126&edit=1 ID: 52126 Updated by: lstro...@php.net Reported by:mark at msapiro dot net Summary:The mail.log added in PHP 5.3.0 has no timestamps. -Status: Assigned +Status: Closed Type: Feature/Change Request Package:Mail related Operating System: CentOS 5 PHP Version:5.3.2 Assigned To:kalle Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Fixed in 5.5 and master. Previous Comments: [2012-12-24 10:45:07] m...@php.net See https://github.com/php/php-src/pull/245 for a slightly alternative approach using the common date format in PHP. [2012-04-23 18:15:33] bakers at canbytel dot com Timestamps would be EXTREMELY useful for this function. I second the request for adding this functionality. [2010-06-19 17:03:24] mark at msapiro dot net Description: The entries in the PHP 5.3.0 and up mail.log have no timestamps. Timestamps would be incredibly useful for multiple reasons including meaningful logwatch reports. -- Edit this bug report at https://bugs.php.net/bug.php?id=52126&edit=1
Bug #63916 [Opn]: PDO::PARAM_INT casts to 32bit int internally even on 64bit builds in pdo_sqlite
Edit report at https://bugs.php.net/bug.php?id=63916&edit=1
ID: 63916
Updated by: google...@php.net
Reported by:google...@php.net
Summary:PDO::PARAM_INT casts to 32bit int internally even on
64bit builds in pdo_sqlite
Status: Open
Type: Bug
Package:PDO related
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
Because we're currently running 3 branches I've sent the PR for this to master
and I'm asking for it to be merged into 5.3.NEXT, 5.4.NEXT, and 5.5.NEXT
respectively to maintain consistency.
https://github.com/php/php-src/pull/253/
Previous Comments:
[2013-01-06 05:20:07] google...@php.net
Description:
Binding a PDO parameter with pdo_sqlite on 64bit builds with PDO::PARAM_INT
forces the param to be cast internally to an int. This means 64bit ints will be
cast down to 32bit ints internally even if PHP was compiled against a 64bit
arch.
Test script:
---
$num = 14313234244; // notice this exceeds 32 bits
$conn = new PDO('sqlite::memory:');
$conn->query('CREATE TABLE users (id INTEGER NOT NULL, num INTEGER NOT NULL,
PRIMARY KEY(id))');
$stmt = $conn->prepare('insert into users (id, num) values (:id, :num)');
$stmt->bindValue(':id', 1, PDO::PARAM_INT);
$stmt->bindValue(':num', $num, PDO::PARAM_INT);
$stmt->execute();
$stmt = $conn->query('SELECT num FROM users');
$result = $stmt->fetchAll(PDO::FETCH_COLUMN);
printf("Expected: %d Received: %d\n", $num, $result[0]);
Expected result:
// expected to output
Expected: 14313234244 Received: 14313234244
Actual result:
--
// instead we get output of
Expected: 14313234244 Received: 294714180
--
Edit this bug report at https://bugs.php.net/bug.php?id=63916&edit=1
Bug #63898 [Com]: json_encode sets string to null for invalid characters
Edit report at https://bugs.php.net/bug.php?id=63898&edit=1
ID: 63898
Comment by: Sjon at hortensius dot net
Reported by:sreed at ontraport dot com
Summary:json_encode sets string to null for invalid
characters
Status: Open
Type: Bug
Package:JSON related
Operating System: All
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
This actually worked fine in 5.3.14 but was broken in 5.3.14:
http://3v4l.org/Eouni#v5314
5.2.0 - 5.2.6 would truncate the character without notice but wouldn't produce
invalid json either
Previous Comments:
[2013-01-04 01:06:40] sreed at ontraport dot com
.
[2013-01-04 01:04:31] sreed at ontraport dot com
Description:
When you use json_encode with an invalid UTF-8 byte sequence in a string PHP
will
generate a warning (with display_errors set to off) and the function returns an
invalid json encoded string. The string with the invalid UTF-8 byte sequence is
replaced with null (for example: {null:""}). This is invalid json and can not
be
decoded with json_decode.
I would think the expected behavior should be that json_encode should never
returns an invalid json encoded string. It should either return false on
failure
as the documentation states or the invalid UTF-8 byte sequence should be
handled
in a way that does not corrupt the json string.
Test script:
---
$key = "Foo " . chr(163);
$array = array($key => "");
var_dump($array);
$json = json_encode($array);
echo $json."\n";
var_dump(json_decode($json));
Expected result:
I would expect the returned json string to be valid or for json_encode to
return
false.
Actual result:
--
array(1) {
["Foo �"]=>
string(0) ""
}
{null:""}
NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=63898&edit=1
[PHP-BUG] Bug #63917 [NEW]: SplObjectStorage: Iteration of all the objects is not possible after detach()
From: LastDragon at yandex dot ru
Operating system: all
PHP version: 5.4.10
Package: SPL related
Bug Type: Bug
Bug description:SplObjectStorage: Iteration of all the objects is not possible
after detach()
Description:
Iteration of all the objects is not possible after the detach method was
called.
Test script:
---
attach(new StdClass);
$s->attach(new StdClass);
$s->attach(new StdClass);
$s->attach(new StdClass);
var_dump($s->count());
foreach ($s as $v) {
var_dump($v);
$s->detach($v);
}
var_dump($s->count());
Expected result:
int(4)
object(stdClass)#2 (0) {
}
object(stdClass)#4 (0) {
}
object(stdClass)#5 (0) {
}
int(1)
Actual result:
--
int(4)
object(stdClass)#2 (0) {
}
object(stdClass)#3 (0) {
}
object(stdClass)#4 (0) {
}
object(stdClass)#5 (0) {
}
int(0)
--
Edit bug report at https://bugs.php.net/bug.php?id=63917&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63917&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63917&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63917&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63917&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63917&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63917&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63917&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63917&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63917&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63917&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63917&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63917&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63917&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63917&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63917&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63917&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63917&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63917&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63917&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63917&r=mysqlcfg
Req #63911 [Opn]: Ignore conflicting trait methods originationg from identical sub traits
Edit report at https://bugs.php.net/bug.php?id=63911&edit=1
ID: 63911
User updated by:bitluni at bitluni dot net
Reported by:bitluni at bitluni dot net
Summary:Ignore conflicting trait methods originationg from
identical sub traits
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: debian
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
@necktrox
I know there is 'insteadof' but see my example, there is just one function
implemented yet still I get collision error. The traits are just usable very
flat at the moment. If you have an hirachical stucture of traits like I do, you
have to do potentally exponetial count of 'insteadof's in the top level class
even there's not one dublicate function implemented.
Previous Comments:
[2013-01-06 02:36:02] necktrox at gmail dot com
# from http://php.net/manual/de/language.oop5.traits.php
trait A {
public function smallTalk() {
echo 'a';
}
public function bigTalk() {
echo 'A';
}
}
trait B {
public function smallTalk() {
echo 'b';
}
public function bigTalk() {
echo 'B';
}
}
class Talker {
use A, B {
B::smallTalk insteadof A;
A::bigTalk insteadof B;
}
}
[2013-01-05 18:39:11] bitluni at bitluni dot net
same issue for properties
[2013-01-05 18:27:56] bitluni at bitluni dot net
Description:
When extracting traits I would like to extract some general functions into sub
traits and 'use' them in the traits where needed.
But when I compose a class out of multiple traits with sub traits I have to do
obsolete statements regardless if the colliding methods originate from same sub
trait.
Just add a check if a method collides with itself
Test script:
---
trait A
{
public function a(){}
}
trait B
{
use A;
}
trait C
{
use A;
}
class D
{
use B, C;
}
Actual result:
--
Fatal error: Trait method a has not been applied, because there are collisions
with other trait methods on D in
--
Edit this bug report at https://bugs.php.net/bug.php?id=63911&edit=1
Bug #63913 [Opn->Fbk]: Segfault on preg_replace with some weird conditions
Edit report at https://bugs.php.net/bug.php?id=63913&edit=1 ID: 63913 Updated by: paj...@php.net Reported by:s...@php.net Summary:Segfault on preg_replace with some weird conditions -Status: Open +Status: Feedback Type: Bug Package:*Regular Expressions Operating System: Windows 7 x64 PHP Version:5.5.0alpha2 Block user comment: N Private report: N New Comment: Can you provide a full BT please? Debug symbols must be loaded or the symbol path. Also I suspect the classic pcre stack limit crash issue here. Can you try to increase it using edit in and run the test again? If you could provide the simple pcre call, if it us actually a pcre crash. Previous Comments: [2013-01-06 00:15:10] s...@php.net Description: The composer test suite segfaults on 5.5 as you can see on https://travis-ci.org/composer/composer/jobs/3971664 I tried investigating on my machine and could not get to the bottom of it, so here are my findings, I hope someone else can reproduce and will have more of a clue than I do. The weirdest thing is that *sometimes* depending on the code changes I make to runme.php (see https://gist.github.com/7f465d4109d667a73984) it actually runs through fine, but most of the time it crashes. Then a bit later if I try and do a similar change it crashes again, either it's an intermittent system issue or something's very wrong. Since it also segfaults on travis I would assume the latter. Note that tweaking the input to the preg_replace call (by removing bits and pieces of testcase.php) also tends to make it work sometimes. For example removing the "}" at line 15 makes it work for me. Test script: --- Run these commands: git clone https://gist.github.com/7f465d4109d667a73984.git reproduce cd reproduce/ php runme.php Expected result: With 5.4.8 VC9 TS I get the following: $ php runme.php string(8) "content:" string(103) "https://bugs.php.net/bug.php?id=63913&edit=1
Bug #52602 [Com]: fread is blocking even with the use of stream_select
Edit report at https://bugs.php.net/bug.php?id=52602&edit=1
ID: 52602
Comment by: gauthi...@php.net
Reported by:g at gsxm dot net
Summary:fread is blocking even with the use of stream_select
Status: Verified
Type: Bug
Package:Sockets related
Operating System: Gentoo x86_64
PHP Version:5.2.14
Assigned To:cataphract
Block user comment: N
Private report: N
New Comment:
As another workaround, you can use the same chunk size in your read calls as
the
PHP stream chunk size. Then there is never buffered data that has not been
consumed. In most cases the chunk size is 8192. In PHP 5.4 I think you can set
the
chunk size using stream_set_chunk_size().
This workaround allows you to continue using fread().
Previous Comments:
[2013-01-06 09:01:59] gauthi...@php.net
This problem affected me while writing a WebSocket server in PHP.
stream_select() returns streams ready for reading and fread() blocks when I try
to read them. What is the point of stream_select() if it behaves like this? How
are you supposed to write a blocking I/O loop?
My solution was to use stream_socket_recvfrom() and give up on implementing
SSL/TLS for my server (making me a bit sad inside).
Since stream_select() returns the stream ready for reading, I would expect
fread() to return the available bytes from the stream buffer in this case
rather
than blocking. See Bug 51056 for a long discussion on fread() behaviour with no
conclusion.
Can some conclusion be reached for PHP? Is there any actual evidence of people
writing their servers in a way where fixing fread() will break?
[2010-09-27 04:16:43] cataphr...@php.net
To sum up, the emulation behavior of stream_select is worse than useless:
* If using stream_socket_recvfrom(), the buffer will be bypassed anyway, so the
emulation behavior won't kick in.
* If using fread() and there's something in the buffer, it will return the
stream in the readfs set, which is documented "to see if characters become
available for reading (more precisely, to see if a read will not block [...])",
but a subsequent fread call will nevertheless eventually block when trying to
fill the buffer.
[2010-09-27 04:09:08] cataphr...@php.net
fread is not really adequate for this because of its buffering (see
stream_socket_recvfrom()).
Since you are specifying a length of 128 to fread, if you receive say, a 138
bytes long payload, the first call to fread will to read into the stream buffer
the whole data, but will only return 128 bytes. The stream buffer remains with
10 bytes, but the socket buffer will be empty. On the second call to fread, it
will try to read into the stream buffer again, but this time the socket buffer
is empty, so it will block until it can read another packet or until the
timeout.
This appears, however, to be the desired behavior (perhaps fread could just
return what it has in the buffer if it cannot read anything immediately, i.e.,
if it would otherwise block). So stream_select implements an emulation behavior
that says the stream is readable without calling select if the there's data in
the stream buffer. This is indeed odd, because the usual semantics of select
are that it a read on a socket returned in the readfs set will not block.
[2010-08-14 05:35:51] g at gsxm dot net
Not sure why I did not think of this before, but perhaps only the stream-*
functions works with stream_select
[2010-08-14 03:07:41] g at gsxm dot net
Description:
Using PHP CLI
Gentoo 64 bit box
PHP version 5.2.14
clean compile
Dual AMD Opteron 2212 CPU
Something is blocking in the code, it seems to be fread. I am sure this is not
the expected result.
I greatly simplified the sample I included.
I can just put the socket/stream in non-blocking mode, but I would much prefer
to use the code as I designed it.
I have considered just using the socket functions in php or just writing the
code in C.
Once in a great while it will resume after about thirty to sixty seconds. In
non-blocking mode I have no issues. This is a php cli script that connects to
another daemon running on the same machine, I am using this php script to parse
data to place in a sql database.
Test script:
---
$sock=@fsockopen("localhost","",$errno,$errstr,3);
if (!$sock)
{
echo "sock error".$crlf;
}
while(true)
{
$read=array($sock);
$write=NULL;
$except=NULL;
$status=@stream_select($read,$write,$except,1);
if ($status===false)
{
echo "select error".$crlf;
exit();
}
Bug #52602 [Com]: fread is blocking even with the use of stream_select
Edit report at https://bugs.php.net/bug.php?id=52602&edit=1
ID: 52602
Comment by: gauthi...@php.net
Reported by:g at gsxm dot net
Summary:fread is blocking even with the use of stream_select
Status: Verified
Type: Bug
Package:Sockets related
Operating System: Gentoo x86_64
PHP Version:5.2.14
Assigned To:cataphract
Block user comment: N
Private report: N
New Comment:
This problem affected me while writing a WebSocket server in PHP.
stream_select() returns streams ready for reading and fread() blocks when I try
to read them. What is the point of stream_select() if it behaves like this? How
are you supposed to write a blocking I/O loop?
My solution was to use stream_socket_recvfrom() and give up on implementing
SSL/TLS for my server (making me a bit sad inside).
Since stream_select() returns the stream ready for reading, I would expect
fread() to return the available bytes from the stream buffer in this case
rather
than blocking. See Bug 51056 for a long discussion on fread() behaviour with no
conclusion.
Can some conclusion be reached for PHP? Is there any actual evidence of people
writing their servers in a way where fixing fread() will break?
Previous Comments:
[2010-09-27 04:16:43] cataphr...@php.net
To sum up, the emulation behavior of stream_select is worse than useless:
* If using stream_socket_recvfrom(), the buffer will be bypassed anyway, so the
emulation behavior won't kick in.
* If using fread() and there's something in the buffer, it will return the
stream in the readfs set, which is documented "to see if characters become
available for reading (more precisely, to see if a read will not block [...])",
but a subsequent fread call will nevertheless eventually block when trying to
fill the buffer.
[2010-09-27 04:09:08] cataphr...@php.net
fread is not really adequate for this because of its buffering (see
stream_socket_recvfrom()).
Since you are specifying a length of 128 to fread, if you receive say, a 138
bytes long payload, the first call to fread will to read into the stream buffer
the whole data, but will only return 128 bytes. The stream buffer remains with
10 bytes, but the socket buffer will be empty. On the second call to fread, it
will try to read into the stream buffer again, but this time the socket buffer
is empty, so it will block until it can read another packet or until the
timeout.
This appears, however, to be the desired behavior (perhaps fread could just
return what it has in the buffer if it cannot read anything immediately, i.e.,
if it would otherwise block). So stream_select implements an emulation behavior
that says the stream is readable without calling select if the there's data in
the stream buffer. This is indeed odd, because the usual semantics of select
are that it a read on a socket returned in the readfs set will not block.
[2010-08-14 05:35:51] g at gsxm dot net
Not sure why I did not think of this before, but perhaps only the stream-*
functions works with stream_select
[2010-08-14 03:07:41] g at gsxm dot net
Description:
Using PHP CLI
Gentoo 64 bit box
PHP version 5.2.14
clean compile
Dual AMD Opteron 2212 CPU
Something is blocking in the code, it seems to be fread. I am sure this is not
the expected result.
I greatly simplified the sample I included.
I can just put the socket/stream in non-blocking mode, but I would much prefer
to use the code as I designed it.
I have considered just using the socket functions in php or just writing the
code in C.
Once in a great while it will resume after about thirty to sixty seconds. In
non-blocking mode I have no issues. This is a php cli script that connects to
another daemon running on the same machine, I am using this php script to parse
data to place in a sql database.
Test script:
---
$sock=@fsockopen("localhost","",$errno,$errstr,3);
if (!$sock)
{
echo "sock error".$crlf;
}
while(true)
{
$read=array($sock);
$write=NULL;
$except=NULL;
$status=@stream_select($read,$write,$except,1);
if ($status===false)
{
echo "select error".$crlf;
exit();
}
if ($status>0)
{
$data = @fread($sock,128);
echo $data;
$out .= $data;
}
usleep(1);
}
Expected result:
The loop should run for eternity as expected.
Actual result:
--
The loop is blocked, I am presuming by fread due to a failure of the expected
behavior of stream_select.
--
Edit this bug report
