Req #64475 [Com]: Update the version of internal SQLite lib in windows builds
Edit report at https://bugs.php.net/bug.php?id=64475edit=1 ID: 64475 Comment by: pawlaktomek at gmail dot com Reported by:alejosimon at gmail dot com Summary:Update the version of internal SQLite lib in windows builds Status: Open Type: Feature/Change Request Package:PDO related Operating System: Windows 7 PHP Version:5.5.0alpha5 Block user comment: N Private report: N New Comment: Please also update SQLite in all currently supported branches of PHP (e.g. 5.3 and 5.4). This is important to me, because SQLite 3.3.15+ far more effectively handles IN operator in WHERE clause, than it was in previous releases. Consequently change of SQLite engine version from 3.7.7.1 to 3.3.15 causes queries in my application running 3-5 times faster. Previous Comments: [2013-03-21 12:16:50] alejosimon at gmail dot com Description: You can update the version of sqlite in this new version of PHP? ...because in unix systems use a global scope sqlite lib... but in windows systems depend only of the internal version from the php build, and still is 3.7.7.1 from php 5.4/5 ... and php 5.5 should come with the new sqlite version, you think? :-) ... or remember the pdo_sqlite_external.dll ? this was a good solution but died! :-( Thanks! Test script: --- ?php $pdo = new PDO( 'sqlite::memory:' ) ; $res = $pdo-query( 'SELECT sqlite_version()' ) ; print_r( $res-fetchColumn() ) ; ? Expected result: 3.7.16 Actual result: -- 3.7.7.1 -- Edit this bug report at https://bugs.php.net/bug.php?id=64475edit=1
Req #64475 [Opn]: Update the version of internal SQLite lib in windows builds
Edit report at https://bugs.php.net/bug.php?id=64475edit=1 ID: 64475 Updated by: paj...@php.net Reported by:alejosimon at gmail dot com Summary:Update the version of internal SQLite lib in windows builds Status: Open Type: Feature/Change Request Package:PDO related -Operating System: Windows 7 +Operating System: PHP Version:5.5.0alpha5 Block user comment: N Private report: N New Comment: It has nothing to do with windows, sqlite is bundled in php sources and windows uses it for the sqlite related extension. Previous Comments: [2013-05-02 07:08:44] pawlaktomek at gmail dot com Please also update SQLite in all currently supported branches of PHP (e.g. 5.3 and 5.4). This is important to me, because SQLite 3.3.15+ far more effectively handles IN operator in WHERE clause, than it was in previous releases. Consequently change of SQLite engine version from 3.7.7.1 to 3.3.15 causes queries in my application running 3-5 times faster. [2013-03-21 12:16:50] alejosimon at gmail dot com Description: You can update the version of sqlite in this new version of PHP? ...because in unix systems use a global scope sqlite lib... but in windows systems depend only of the internal version from the php build, and still is 3.7.7.1 from php 5.4/5 ... and php 5.5 should come with the new sqlite version, you think? :-) ... or remember the pdo_sqlite_external.dll ? this was a good solution but died! :-( Thanks! Test script: --- ?php $pdo = new PDO( 'sqlite::memory:' ) ; $res = $pdo-query( 'SELECT sqlite_version()' ) ; print_r( $res-fetchColumn() ) ; ? Expected result: 3.7.16 Actual result: -- 3.7.7.1 -- Edit this bug report at https://bugs.php.net/bug.php?id=64475edit=1
[PHP-BUG] Bug #64755 [NEW]: Only variables should be passed by reference
From: eth at ethaniel dot com Operating system: Debian 7.0 PHP version: 5.4.14 Package: Scripting Engine problem Bug Type: Bug Bug description:Only variables should be passed by reference Description: I get a PHP Strict Standards: Only variables should be passed by reference in error where there should be none. Test script: --- echo array_pop(array_keys(array(erwre))); Expected result: Result: 0. Actual result: -- The script returns the result (0), but also a PHP Strict Standards: Only variables should be passed by reference in in my error log. -- Edit bug report at https://bugs.php.net/bug.php?id=64755edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64755r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64755r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64755r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64755r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64755r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64755r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64755r=needscript Try newer version: https://bugs.php.net/fix.php?id=64755r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64755r=support Expected behavior: https://bugs.php.net/fix.php?id=64755r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64755r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64755r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64755r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64755r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64755r=dst IIS Stability: https://bugs.php.net/fix.php?id=64755r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64755r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64755r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64755r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64755r=mysqlcfg
Bug #64755 [Opn-Nab]: Only variables should be passed by reference
Edit report at https://bugs.php.net/bug.php?id=64755edit=1 ID: 64755 Updated by: paj...@php.net Reported by:eth at ethaniel dot com Summary:Only variables should be passed by reference -Status: Open +Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: Debian 7.0 PHP Version:5.4.14 Block user comment: N Private report: N New Comment: See www.php.net/array_pop. Using: array_pop(array_keys($a)); array_keys($a) is an expression while array_pop expects a variable. ($k = array_keys($a);...). Previous Comments: [2013-05-02 08:03:55] eth at ethaniel dot com Description: I get a PHP Strict Standards: Only variables should be passed by reference in error where there should be none. Test script: --- echo array_pop(array_keys(array(erwre))); Expected result: Result: 0. Actual result: -- The script returns the result (0), but also a PHP Strict Standards: Only variables should be passed by reference in in my error log. -- Edit this bug report at https://bugs.php.net/bug.php?id=64755edit=1
[PHP-BUG] Req #64756 [NEW]: Add constructor parameter or update docs
From: luke dot brown28 at gmail dot com
Operating system: Windows Server 2008
PHP version: 5.3.24
Package: SPL related
Bug Type: Feature/Change Request
Bug description:Add constructor parameter or update docs
Description:
---
From manual page: http://www.php.net/arrayobject.construct#refsect1-
arrayobject.construct-examples
---
Currently when constructing an ArrayObject it isn't possible to specify
whether
or not you would like recursion to take place, thus traversing the array
structure and creating ArrayObject instances in multi-dimensional arrays.
Whilst I appreciate that this is standard behavior, being given the option
when
constructing would be very useful as you wouldn't then be required to
extend the
class for what is quite a common use-case. I appreciate it's easy to extend
the
class and code in the recursion, but I feel a param on construct would be
equally as useful (perhaps even as part of the bitwise flags).
Failing this, the documentation should at the very least be updated to
include
an example of instantiating the class with a multi-dimensional array to
show
that any arrays within the one passed to the constructor will not be
converted
by ArrayObject.
Test script:
---
$array = array('one' = 1, 'fruit' = array('lemon' = 'bitter', 'orange'
= 'sweet'));
$obj = new ArrayObject($array);
$obj-fuit-orange; // null
$obj-fuit['orange'] // 'sweet'
--
Edit bug report at https://bugs.php.net/bug.php?id=64756edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64756r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64756r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64756r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64756r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64756r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64756r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64756r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64756r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64756r=support
Expected behavior: https://bugs.php.net/fix.php?id=64756r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64756r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64756r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64756r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64756r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64756r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64756r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64756r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64756r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64756r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64756r=mysqlcfg
[PHP-BUG] Bug #64760 [NEW]: var_export() does not use full precision for floating-point numbers
From: cf0hay at gmail dot com
Operating system: Linux 64bit (PHP 64bit too)
PHP version: 5.4.14
Package: Variables related
Bug Type: Bug
Bug description:var_export() does not use full precision for floating-point
numbers
Description:
var_export() truncates floating-point precision. serialize() does not have
the same problem.
Test script:
---
?php
$a = microtime(true);
echo error of serialize(): ;
var_export($a - unserialize(serialize($a))); //This returns 0.
echo \n;
echo error of var_export(): ;
eval('$b = '.var_export($a,true).';');
var_export($a - $b); //Almost never 0.
echo \n;
Expected result:
Exporting a floating-point value should generate enough digits to prevent
precision loss. The script above should always return 0 on the second case.
Actual result:
--
The difference between the original floating point value and the one
exported differs. The error is about 15 magnitude lower than the magnitude
of the value itself.
--
Edit bug report at https://bugs.php.net/bug.php?id=64760edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64760r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64760r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64760r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64760r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64760r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64760r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64760r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64760r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64760r=support
Expected behavior: https://bugs.php.net/fix.php?id=64760r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64760r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64760r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64760r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64760r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64760r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64760r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64760r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64760r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64760r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64760r=mysqlcfg
Req #64475 [Opn]: Update the version of internal SQLite lib in windows builds
Edit report at https://bugs.php.net/bug.php?id=64475edit=1 ID: 64475 User updated by:alejosimon at gmail dot com Reported by:alejosimon at gmail dot com Summary:Update the version of internal SQLite lib in windows builds Status: Open Type: Feature/Change Request Package:PDO related PHP Version:5.5.0alpha5 Block user comment: N Private report: N New Comment: Hi Pierre, I think that I already clarified, but I repeat again... I am only user-programer of PHP and not a win-builder versions, then I can not change and compile PHP every time under change the PHP version number, so you should update sqlite from sources before compiling... and I like many others who only use PHP and just download only the binaries for use, I was clear?! ;-) Sorry but my english isn't buggy. So Windows is not like Unix ... and does not use external sqlite lib, so we depend on the version that comes inside of the binaries. Please I hope you can update it, who clearly appropriate. Thanks.! Previous Comments: [2013-05-02 07:22:50] paj...@php.net It has nothing to do with windows, sqlite is bundled in php sources and windows uses it for the sqlite related extension. [2013-05-02 07:08:44] pawlaktomek at gmail dot com Please also update SQLite in all currently supported branches of PHP (e.g. 5.3 and 5.4). This is important to me, because SQLite 3.3.15+ far more effectively handles IN operator in WHERE clause, than it was in previous releases. Consequently change of SQLite engine version from 3.7.7.1 to 3.3.15 causes queries in my application running 3-5 times faster. [2013-03-21 12:16:50] alejosimon at gmail dot com Description: You can update the version of sqlite in this new version of PHP? ...because in unix systems use a global scope sqlite lib... but in windows systems depend only of the internal version from the php build, and still is 3.7.7.1 from php 5.4/5 ... and php 5.5 should come with the new sqlite version, you think? :-) ... or remember the pdo_sqlite_external.dll ? this was a good solution but died! :-( Thanks! Test script: --- ?php $pdo = new PDO( 'sqlite::memory:' ) ; $res = $pdo-query( 'SELECT sqlite_version()' ) ; print_r( $res-fetchColumn() ) ; ? Expected result: 3.7.16 Actual result: -- 3.7.7.1 -- Edit this bug report at https://bugs.php.net/bug.php?id=64475edit=1
[PHP-BUG] Bug #64761 [NEW]: rebinding of closures doesn't work when they are declared in a static method
From: netmosfera at gmail dot com
Operating system: any
PHP version: 5.5.0beta4
Package: *General Issues
Bug Type: Bug
Bug description:rebinding of closures doesn't work when they are declared in a
static method
Description:
?
class Test
{
public $clos;
public $bobo = 22;
static function blah(){
return new static(function(){ echo $this-bobo; });
}
function __construct(\Closure $c)
{
$this-clos = $c-bindTo($this, $this);
}
}
// perfectly fine when closure is declared in global space
$a = new Test(function(){ echo $this-bobo; });
$clos = $a-clos;
$clos();
// binding doesn't work when closure is declared in a static method
$a = Test::blah();
$clos = $a-clos;
$clos();
// results in: Warning: Cannot bind an instance to a static closure
--
Edit bug report at https://bugs.php.net/bug.php?id=64761edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64761r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64761r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64761r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64761r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64761r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64761r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64761r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64761r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64761r=support
Expected behavior: https://bugs.php.net/fix.php?id=64761r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64761r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64761r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64761r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64761r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64761r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64761r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64761r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64761r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64761r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64761r=mysqlcfg
Req #64475 [Opn]: Update the version of internal SQLite lib in windows builds
Edit report at https://bugs.php.net/bug.php?id=64475edit=1 ID: 64475 Updated by: paj...@php.net Reported by:alejosimon at gmail dot com Summary:Update the version of internal SQLite lib in windows builds Status: Open Type: Feature/Change Request Package:PDO related PHP Version:5.5.0alpha5 Block user comment: N Private report: N New Comment: Distributions sometimes use system library, sometimes not. But php.net's sources bundled Sqlite and it is not Sqlite specific. See: https://github.com/php/php-src/tree/master/ext/sqlite3/libsqlite The day we will have the newer version there, windows will have it automatically as well. Previous Comments: [2013-05-02 12:18:09] alejosimon at gmail dot com Hi Pierre, I think that I already clarified, but I repeat again... I am only user-programer of PHP and not a win-builder versions, then I can not change and compile PHP every time under change the PHP version number, so you should update sqlite from sources before compiling... and I like many others who only use PHP and just download only the binaries for use, I was clear?! ;-) Sorry but my english isn't buggy. So Windows is not like Unix ... and does not use external sqlite lib, so we depend on the version that comes inside of the binaries. Please I hope you can update it, who clearly appropriate. Thanks.! [2013-05-02 07:22:50] paj...@php.net It has nothing to do with windows, sqlite is bundled in php sources and windows uses it for the sqlite related extension. [2013-05-02 07:08:44] pawlaktomek at gmail dot com Please also update SQLite in all currently supported branches of PHP (e.g. 5.3 and 5.4). This is important to me, because SQLite 3.3.15+ far more effectively handles IN operator in WHERE clause, than it was in previous releases. Consequently change of SQLite engine version from 3.7.7.1 to 3.3.15 causes queries in my application running 3-5 times faster. [2013-03-21 12:16:50] alejosimon at gmail dot com Description: You can update the version of sqlite in this new version of PHP? ...because in unix systems use a global scope sqlite lib... but in windows systems depend only of the internal version from the php build, and still is 3.7.7.1 from php 5.4/5 ... and php 5.5 should come with the new sqlite version, you think? :-) ... or remember the pdo_sqlite_external.dll ? this was a good solution but died! :-( Thanks! Test script: --- ?php $pdo = new PDO( 'sqlite::memory:' ) ; $res = $pdo-query( 'SELECT sqlite_version()' ) ; print_r( $res-fetchColumn() ) ; ? Expected result: 3.7.16 Actual result: -- 3.7.7.1 -- Edit this bug report at https://bugs.php.net/bug.php?id=64475edit=1
Bug #64722 [Com]: PDO extension causes zend_mm_heap corrupted
Edit report at https://bugs.php.net/bug.php?id=64722edit=1
ID: 64722
Comment by: tj dot botha at plista dot com
Reported by:tj dot botha at plista dot com
Summary:PDO extension causes zend_mm_heap corrupted
Status: Feedback
Type: Bug
Package:PDO related
Operating System: Ubuntu Server 12.10
PHP Version:master-Git-2013-04-26 (Git)
Block user comment: N
Private report: N
New Comment:
Hey guys - I have run various tests - using valgrind I did not find anything.
I have debugged the code, and I have narrowed down the problem.
It is not a race condition, the problem is dangling pointers are getting freed:
below is still okay:
//php_source/ext/pdo/pdo_dbh.c
static void pdo_dbh_free_storage(pdo_dbh_t *dbh TSRMLS_DC)
{
...
zend_object_std_dtor(dbh-std TSRMLS_CC);
dbh-std.properties = NULL;
...
}
The problem arrives here in zend_object_std_dtor, in
php_source/Zend/zend_objects.c
The situation can be recreated when a zend_object has properties AND a
properties_table
Look at the code below:
In my case, the below function gets called TWICE:
ZEND_API void zend_object_std_dtor(zend_object *object TSRMLS_DC)
{
if (object-guards) {
zend_hash_destroy(object-guards);
FREE_HASHTABLE(object-guards);
}
if (object-properties) {
zend_hash_destroy(object-properties);
FREE_HASHTABLE(object-properties);
if (object-properties_table) {
efree(object-properties_table);
}
} else if (object-properties_table) {
int i;
for (i = 0; i object-ce-default_properties_count; i++) {
if (object-properties_table[i]) {
zval_ptr_dtor(object-properties_table[i]);
}
}
efree(object-properties_table);
}
}
The important bits are:
...
if (object-properties)
{
...
if (object-properties_table) {
efree(object_properties_table); //this creates dangling
pointers 0x5a5a5a5a5a5a5a5a
//Now, object-properties_table[0, 1, 2, ... n] are all
dangling pointers
}
...
} else if (object-properties_table)
{
...
//now the second time this function gets called, at some point during the
zval_ptr_dtor call on object-
properties_table[i], a function tries to decrease the ref val on the dangling
pointer, and this causes SIGSEGV 11
(zend_mm_heap corrupted)
...
}
I do not know what the correct behavior should be.
I have tried removing the else if and then setting the properties_table to
NULL after de-allocation and forcing de-
allocation of both, however different modifications to the code have lead to
different problems and I do not seem to
find a 100% correct solution. The solution I had in mind to work perfect lead
to for example:
/home/tj/php-5.4.14/Zend/zend_API.c(1127) : Freeing 0x7FFFE89B6418 (16 bytes),
script=/.../index.php
=== Total 1 memory leaks detected ===
I do not know if the function should indeed be called twice, or whether the
object should only contain properties or
properties_table and not both, and why the properties_table does not get set to
NULL after being de-allocated, as
well as the other properties_table[] pointers.
In either way - it turns out that this situation is created because we are
extending the PDO class in PHP, and adding
custom properties and methods.
I will still investigate further - but I will really appreciate some advice /
help!
Previous Comments:
[2013-05-01 13:05:43] larue...@php.net
if you can reproduce it in a 100% chance, please run it with valgrind, let's
see
what valgrind says about this..
thanks
[2013-04-30 16:16:29] tj dot botha at plista dot com
Ok - I just recompiled apache with prefork (It was supposed to be the default,
instead it defaulted to event) - and recompiled PHP, and it is no longer
multithreaded - and the problem persists:
Apache information now:
Server version: Apache/2.4.4 (Unix)
Server built: Apr 30 2013 17:41:49
Server's Module Magic Number: 20120211:11
Server loaded: APR 1.4.6, APR-UTIL 1.5.2
Compiled using: APR 1.4.6, APR-UTIL 1.5.2
Architecture: 64-bit
Server MPM: prefork
threaded: no
forked: yes (variable process count)
Server compiled with
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=256
-D HTTPD_ROOT=/usr/local/apache2
-D SUEXEC_BIN=/usr/local/apache2/bin/suexec
-D DEFAULT_PIDLOG=logs/httpd.pid
-D
Bug #64722 [Com]: PDO extension causes zend_mm_heap corrupted
Edit report at https://bugs.php.net/bug.php?id=64722edit=1
ID: 64722
Comment by: tj dot botha at plista dot com
Reported by:tj dot botha at plista dot com
Summary:PDO extension causes zend_mm_heap corrupted
Status: Feedback
Type: Bug
Package:PDO related
Operating System: Ubuntu Server 12.10
PHP Version:master-Git-2013-04-26 (Git)
Block user comment: N
Private report: N
New Comment:
In my mind, the correct function should look like this (without knowing the
exact context in which it runs)
//source_code/Zend/zend_objects.c:
ZEND_API void zend_object_std_dtor(zend_object *object TSRMLS_DC)
{
if (object-guards) {
zend_hash_destroy(object-guards);
FREE_HASHTABLE(object-guards);
}
if (object-properties) {
zend_hash_destroy(object-properties);
FREE_HASHTABLE(object-properties);
}
if (object-properties_table) {
int i;
for (i = 0; i object-ce-default_properties_count; i++) {
if (object-properties_table[i]) {
zval_ptr_dtor(object-properties_table[i]);
object-properties_table[i] = NULL;
}
}
efree(object-properties_table);
object-properties_table = NULL;
}
}
However, this appears in my apache logs, only when running in debug mode:
[Thu May 02 16:41:28.476657 2013] [auth_digest:notice] [pid 23396] AH01757:
generating secret for digest authentication ...
[Thu May 02 16:41:29.052276 2013] [ssl:warn] [pid 23396] AH01873: Init: Session
Cache is not configured [hint: SSLSessionCache]
[Thu May 02 16:41:29.052747 2013] [lbmethod_heartbeat:notice] [pid 23396]
AH02282: No slotmem from mod_heartmonitor
[Thu May 02 16:41:29.141345 2013] [core:warn] [pid 23396] AH00098: pid file
/usr/local/apache2/logs/httpd.pid overwritten -- Unclean shutdown of previous
Apache run?
[Thu May 2 16:41:35 2013] Script: '/.../index.php'
/home/tj/php-5.4.14/Zend/zend_API.c(1127) : Freeing 0x7FFFE89B6050 (16 bytes),
script=/usr/local/apache2/htdocs/www/plista/www.2.3.2/app/webroot/index.php
=== Total 1 memory leaks detected ===
But the project loads without problems.
Previous Comments:
[2013-05-02 13:51:47] tj dot botha at plista dot com
Hey guys - I have run various tests - using valgrind I did not find anything.
I have debugged the code, and I have narrowed down the problem.
It is not a race condition, the problem is dangling pointers are getting freed:
below is still okay:
//php_source/ext/pdo/pdo_dbh.c
static void pdo_dbh_free_storage(pdo_dbh_t *dbh TSRMLS_DC)
{
...
zend_object_std_dtor(dbh-std TSRMLS_CC);
dbh-std.properties = NULL;
...
}
The problem arrives here in zend_object_std_dtor, in
php_source/Zend/zend_objects.c
The situation can be recreated when a zend_object has properties AND a
properties_table
Look at the code below:
In my case, the below function gets called TWICE:
ZEND_API void zend_object_std_dtor(zend_object *object TSRMLS_DC)
{
if (object-guards) {
zend_hash_destroy(object-guards);
FREE_HASHTABLE(object-guards);
}
if (object-properties) {
zend_hash_destroy(object-properties);
FREE_HASHTABLE(object-properties);
if (object-properties_table) {
efree(object-properties_table);
}
} else if (object-properties_table) {
int i;
for (i = 0; i object-ce-default_properties_count; i++) {
if (object-properties_table[i]) {
zval_ptr_dtor(object-properties_table[i]);
}
}
efree(object-properties_table);
}
}
The important bits are:
...
if (object-properties)
{
...
if (object-properties_table) {
efree(object_properties_table); //this creates dangling
pointers 0x5a5a5a5a5a5a5a5a
//Now, object-properties_table[0, 1, 2, ... n] are all
dangling pointers
}
...
} else if (object-properties_table)
{
...
//now the second time this function gets called, at some point during the
zval_ptr_dtor call on object-
properties_table[i], a function tries to decrease the ref val on the dangling
pointer, and this causes SIGSEGV 11
(zend_mm_heap corrupted)
...
}
I do not know what the correct behavior should be.
I have tried removing the else if and then setting the properties_table to
NULL after de-allocation and forcing de-
allocation of both, however different modifications to the code have lead to
different problems and I do not seem to
find a 100% correct solution. The
Bug #55348 [Com]: SoapServer (typemap related) Error calling from_xml callback
Edit report at https://bugs.php.net/bug.php?id=55348edit=1 ID: 55348 Comment by: sprotte at visionconnect dot de Reported by:sprotte at visionconnect dot de Summary:SoapServer (typemap related) Error calling from_xml callback Status: Open Type: Bug Package:SOAP related Operating System: openSUSE 11.4 PHP Version:5.3.7RC4 Block user comment: N Private report: N New Comment: Any news to this? Like Chris said, this is also happening when xdebug is NOT installed. The problem still exists in PHP 5.3.24. Previous Comments: [2012-02-12 18:20:08] chris at cmbuckley dot co dot uk Regardless of the Xdebug comment, the error is still present without Xdebug; if the from_xml callback generates an error more than once during server handling, the error message Error calling from_xml callback is shown instead of the actual fault. [2011-08-23 12:26:15] der...@php.net There is an incompatibility with Xdebug and the SOAP extension, due to the way that the SOAP extension also overloads php_error_cb. In order to properly fix this, the error_cb overloading needs to be changed. I don't however know, exactly how. See also: http://bugs.xdebug.org/view.php?id=609 http://bugs.xdebug.org/view.php?id=705 [2011-08-23 11:19:45] chris at cmbuckley dot co dot uk Additional: Fatal only happens in conjunction with Xdebug (see https://bugs.php.net/bug.php?id=50547). [2011-08-22 19:48:28] chris at cmbuckley dot co dot uk Description: Reduced to smaller test script. Test script: http://starsquare.co.uk/code/php/bugs/55348.phps Expected result: ... SOAP-ENV:Fault faultcodeSOAP-ENV:Server/faultcode faultstringConversion Fault/faultstring /SOAP-ENV:Fault ... Actual result: -- Fatal error: SOAP-ERROR: Encoding: Error calling from_xml callback [2011-08-02 15:14:41] sprotte at visionconnect dot de Description: Throwing a SoapFault exception inside the from_xml callback function (when using the typemap feature with SoapServer) does not work as expected in some cases. I have created a small client/server application with one working example (type date) and one not working example (type myType). In case of the date type the SoapFault exception is transformed into a matching SOAP-Response. The original message is available on the client side. In case of the myType type the thrown SoapFault exception is completely ignored and the SOAP-Response contains another error message. Test script: --- http://www.visionconnect.de/php_bugreports/soapserver_to_xml.tar.gz Expected result: Faultcode: 0001 Faultstring: Invalid date: 2011-15-15 Faultcode: 0002 Faultstring: Invalid type: foobar Actual result: -- Faultcode: 0001 Faultstring: Invalid date: 2011-15-15 Faultcode: SOAP-ENV:Server Faultstring: SOAP-ERROR: Encoding: Error calling from_xml callback -- Edit this bug report at https://bugs.php.net/bug.php?id=55348edit=1
Bug #64722 [Com]: PDO extension causes zend_mm_heap corrupted
Edit report at https://bugs.php.net/bug.php?id=64722edit=1
ID: 64722
Comment by: tj dot botha at plista dot com
Reported by:tj dot botha at plista dot com
Summary:PDO extension causes zend_mm_heap corrupted
Status: Feedback
Type: Bug
Package:PDO related
Operating System: Ubuntu Server 12.10
PHP Version:master-Git-2013-04-26 (Git)
Block user comment: N
Private report: N
New Comment:
Even more correct:
ZEND_API void zend_object_std_dtor(zend_object *object TSRMLS_DC)
{
if (object-guards) {
zend_hash_destroy(object-guards);
FREE_HASHTABLE(object-guards);
object-guards = NULL;
}
if (object-properties) {
zend_hash_destroy(object-properties);
FREE_HASHTABLE(object-properties);
object-properties = NULL;
}
if (object-properties_table) {
int i;
for (i = 0; i object-ce-default_properties_count; i++) {
if (object-properties_table[i]) {
zval_ptr_dtor(object-properties_table[i]);
object-properties_table[i] = NULL;
}
}
efree(object-properties_table);
object-properties_table = NULL;
}
}
Previous Comments:
[2013-05-02 14:42:26] tj dot botha at plista dot com
In my mind, the correct function should look like this (without knowing the
exact context in which it runs)
//source_code/Zend/zend_objects.c:
ZEND_API void zend_object_std_dtor(zend_object *object TSRMLS_DC)
{
if (object-guards) {
zend_hash_destroy(object-guards);
FREE_HASHTABLE(object-guards);
}
if (object-properties) {
zend_hash_destroy(object-properties);
FREE_HASHTABLE(object-properties);
}
if (object-properties_table) {
int i;
for (i = 0; i object-ce-default_properties_count; i++) {
if (object-properties_table[i]) {
zval_ptr_dtor(object-properties_table[i]);
object-properties_table[i] = NULL;
}
}
efree(object-properties_table);
object-properties_table = NULL;
}
}
However, this appears in my apache logs, only when running in debug mode:
[Thu May 02 16:41:28.476657 2013] [auth_digest:notice] [pid 23396] AH01757:
generating secret for digest authentication ...
[Thu May 02 16:41:29.052276 2013] [ssl:warn] [pid 23396] AH01873: Init: Session
Cache is not configured [hint: SSLSessionCache]
[Thu May 02 16:41:29.052747 2013] [lbmethod_heartbeat:notice] [pid 23396]
AH02282: No slotmem from mod_heartmonitor
[Thu May 02 16:41:29.141345 2013] [core:warn] [pid 23396] AH00098: pid file
/usr/local/apache2/logs/httpd.pid overwritten -- Unclean shutdown of previous
Apache run?
[Thu May 2 16:41:35 2013] Script: '/.../index.php'
/home/tj/php-5.4.14/Zend/zend_API.c(1127) : Freeing 0x7FFFE89B6050 (16 bytes),
script=/usr/local/apache2/htdocs/www/plista/www.2.3.2/app/webroot/index.php
=== Total 1 memory leaks detected ===
But the project loads without problems.
[2013-05-02 13:51:47] tj dot botha at plista dot com
Hey guys - I have run various tests - using valgrind I did not find anything.
I have debugged the code, and I have narrowed down the problem.
It is not a race condition, the problem is dangling pointers are getting freed:
below is still okay:
//php_source/ext/pdo/pdo_dbh.c
static void pdo_dbh_free_storage(pdo_dbh_t *dbh TSRMLS_DC)
{
...
zend_object_std_dtor(dbh-std TSRMLS_CC);
dbh-std.properties = NULL;
...
}
The problem arrives here in zend_object_std_dtor, in
php_source/Zend/zend_objects.c
The situation can be recreated when a zend_object has properties AND a
properties_table
Look at the code below:
In my case, the below function gets called TWICE:
ZEND_API void zend_object_std_dtor(zend_object *object TSRMLS_DC)
{
if (object-guards) {
zend_hash_destroy(object-guards);
FREE_HASHTABLE(object-guards);
}
if (object-properties) {
zend_hash_destroy(object-properties);
FREE_HASHTABLE(object-properties);
if (object-properties_table) {
efree(object-properties_table);
}
} else if (object-properties_table) {
int i;
for (i = 0; i object-ce-default_properties_count; i++) {
if (object-properties_table[i]) {
[PHP-BUG] Bug #64763 [NEW]: unbuffered queries connection problems are not handled by mysqlnd
From: ihanick at gmail dot com
Operating system: CentOS release 6.4
PHP version: master-Git-2013-05-02 (snap)
Package: MySQL related
Bug Type: Bug
Bug description:unbuffered queries connection problems are not handled by
mysqlnd
Description:
Partially finished unbuffered query for mysql doesn't return any errors.
The problem persists for all current versions of mysqlnd but everything
find with
old libmysqlclient code for all mysql extensions: mysql, mysqli,
pdo-mysql.
If I have 100k rows in query and connection dropped at 50k point, there is
no
simple way to see this error in application and handle the problem.
Test script:
---
1) create a big table to have several seconds for select * from table
execution time
2) run php script
3) kill connection from php to mysql or kill mysqld
?php
error_reporting(E_ALL);
$link = mysql_connect('localhost', 'root', '');
mysql_select_db('test') or die('Could not select database');
// Performing SQL query
$query = 'SELECT * FROM x;';
$result = mysql_unbuffered_query($query) or die('Query failed: ' .
mysql_error());
while ($line = mysql_fetch_array($result, MYSQL_ASSOC)) {
}
echo mysql_error($link) . PHP_EOL;
Expected result:
Warning about connection problems and
mysql_error should return Query failed: MySQL server has gone away
Everything works correctly for old (non-mysqlnd) extension.
Actual result:
--
getting warning:
Warning: Empty row packet body in /root/php5-trunk/test.php on line 10
But empty result for mysql_error($link)
--
Edit bug report at https://bugs.php.net/bug.php?id=64763edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64763r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64763r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64763r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64763r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64763r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64763r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64763r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64763r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64763r=support
Expected behavior: https://bugs.php.net/fix.php?id=64763r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64763r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64763r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64763r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64763r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64763r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64763r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64763r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64763r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64763r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64763r=mysqlcfg
[PHP-BUG] Req #64764 [NEW]: add support for FPM init.d script
From: lior dot k at zend dot com Operating system: PHP version: 5.4.14 Package: FPM related Bug Type: Feature/Change Request Bug description:add support for FPM init.d script Description: The attached patch adds that status option to init.d.php-fpm.in file. -- Edit bug report at https://bugs.php.net/bug.php?id=64764edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64764r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64764r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64764r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64764r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64764r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64764r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64764r=needscript Try newer version: https://bugs.php.net/fix.php?id=64764r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64764r=support Expected behavior: https://bugs.php.net/fix.php?id=64764r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64764r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64764r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64764r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64764r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64764r=dst IIS Stability: https://bugs.php.net/fix.php?id=64764r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64764r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64764r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64764r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64764r=mysqlcfg
[PHP-BUG] Bug #64765 [NEW]: Some IPv6 addresses get interpreted wrong
From: gmcgraw at udel dot edu
Operating system: Linux
PHP version: 5.4.14
Package: SNMP related
Bug Type: Bug
Bug description:Some IPv6 addresses get interpreted wrong
Description:
PHP sends the following string to Net-SNMP to parse as an address:
udp6:fc00::23:250:56ff:fe82:3177
Net-SNMP understands the final part of the IP address to be a port number,
since
it has no hexadecimal characters in it. There was an earlier bug filed and
fixed in PHP 5.4 that involved IPv6 but that fix only partially addressed
the
issue (bug #42918). It made PHP correctly parse IPv6 address but it didn't
ensure that PHP sent Net-SNMP a form of address that it will always
correctly
interpret.
My patch causes square brackets to always surround the IPv6 address, so
that
Net-SNMP cannot possibly interpret the last part of the Ipv6 address as a
port
number. The port number will be placed outside the square brackets. Here
is an
example of how it will now send the IPV6 address to Net-SNMP:
udp6:[fc00::23:250:56ff:fe82:3177]
Or if there is a custom port number 1234:
udp6:[fc00::23:250:56ff:fe82:3177]:1234
Net-SNMP will correctly parse that and use the default SNMP port number
(161) if
none is specified or the provided port number otherwise.
I have reproduced this in 5.4.1 and 5.4.14.
Test script:
---
$s=new SNMP(SNMP::VERSION_2C, '[fc00::23:250:56ff:fe82:3177]', 'public');
print_r($s-get('.1.3.6.1.2.1.1.1.0'));
Expected result:
STRING: Linux mykernel12345 #5 SMP Fri Jun 1 19:44:50 GMT 2012 x86_64
Actual result:
--
Warning: SNMP::get(): No response from udp6:fc00::23:250:56ff:fe82:3177 in
php
shell code on line 1
--
Edit bug report at https://bugs.php.net/bug.php?id=64765edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64765r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64765r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64765r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64765r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64765r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64765r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64765r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64765r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64765r=support
Expected behavior: https://bugs.php.net/fix.php?id=64765r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64765r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64765r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64765r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64765r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64765r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64765r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64765r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64765r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64765r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64765r=mysqlcfg
[PHP-BUG] Bug #64767 [NEW]: DateInterval::format Inconsistant
From: brent dot hansen at gmail dot com
Operating system: All
PHP version: Irrelevant
Package: Date/time related
Bug Type: Bug
Bug description:DateInterval::format Inconsistant
Description:
DateInterval::format() does not follow standard like DateTime Date. Need
to use
new format. What used to be H:i:s for formatting now needs H:I:S
Test script:
---
$interval = new DateInterval('P2Y4DT6H8M');
echo $interval-format(%Y-%m-%d %H:%i:%s);
Expected result:
02-00-04 06:08:00
Actual result:
--
02-0-4 06:8:0
--
Edit bug report at https://bugs.php.net/bug.php?id=64767edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64767r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64767r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64767r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64767r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64767r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64767r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64767r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64767r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64767r=support
Expected behavior: https://bugs.php.net/fix.php?id=64767r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64767r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64767r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64767r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64767r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64767r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64767r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64767r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64767r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64767r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64767r=mysqlcfg
Bug #63812 [Com]: PDO Triggers Warning(s) Regardless of Error Handling Strategy
Edit report at https://bugs.php.net/bug.php?id=63812edit=1
ID: 63812
Comment by: fog at yandex dot ru
Reported by:sergey at shymko dot net
Summary:PDO Triggers Warning(s) Regardless of Error Handling
Strategy
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.3.19
Block user comment: N
Private report: N
New Comment:
There is another similar problem, sometimes connection fails with message:
Warning: PDO::__construct(): MySQL server has gone away in [...file_path...] on
line N
It happens despiting that PDO::ATTR_ERRMODE is set to PDO::ERRMODE_EXCEPTION
Previous Comments:
[2012-12-20 05:34:45] sergey at shymko dot net
Relates to https://bugs.php.net/bug.php?id=63546
[2012-12-20 05:25:22] sergey at shymko dot net
Description:
PDO triggers warning(s) regardless of the chosen error handling strategy
http://php.net/manual/en/pdo.error-handling.php
Environment:
- mysql Ver 14.14 Distrib 5.5.22, for Linux (x86_64) using EditLine wrapper
Test script:
---
?php
$adapter = new PDO('mysql:host=localhost;db_name=test', 'root', '');
$adapter-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
assert($adapter-getAttribute(PDO::ATTR_ERRMODE) === PDO::ERRMODE_EXCEPTION);
$waitTimeout = 1;
$adapter-exec(SET @@session.wait_timeout = {$waitTimeout});
$statement = $adapter-query('SELECT @@session.wait_timeout');
assert($statement-fetchColumn() == $waitTimeout);
/**
* Ensure 'MySQL server has gone away' conditions are met
*/
sleep($waitTimeout + 1);
$adapter-query('SELECT 1');
Expected result:
- PDOException with message 'SQLSTATE[HY000]: General error: 2006 MySQL server
has gone away'
- No warnings (because of the chosen PDO error handling strategy)
Actual result:
--
1. When connection type is TCP/IP:
1. Warning: PDO::query() [pdo.query]: MySQL server has gone away
2. Warning: PDO::query() [pdo.query]: Error reading result set's header
1'. When connection type is Unix socket:
1. Warning: Error while sending QUERY packet. PID=18586
2. PDOException with message 'SQLSTATE[HY000]: General error: 2006 MySQL server
has gone away'
--
Edit this bug report at https://bugs.php.net/bug.php?id=63812edit=1
