[PHP-BUG] Bug #65749 [NEW]: getimagesize not returning channels for png and bmp
From: nettum at gmail dot com Operating system: PHP version: Irrelevant Package: GetImageSize related Bug Type: Bug Bug description:getimagesize not returning channels for png and bmp Description: getimagesize does not contain 'channel' in the returning array when you run getimagesize on a PNG or BMP image. The documentation (http://php.net/manual/en/function.getimagesize.php) specifies that it will always return an array with 7 elements. This does not seem to be the case. Se script output below. Test script: --- ?php $file_jpg = test.jpg; $file_png = tux.png; $info_jpg = getimagesize($file_jpg); $info_png = getimagesize($file_png); echo \nJPG:; print_r($info_jpg); echo \nPNG:; print_r($info_png); ? Expected result: JPG:Array ( [0] = 463 [1] = 399 [2] = 2 [3] = width=463 height=399 [bits] = 8 [channels] = 3 [mime] = image/jpeg ) PNG:Array ( [0] = 400 [1] = 479 [2] = 3 [3] = width=400 height=479 [bits] = 8 [channels] = 4 [mime] = image/png ) Actual result: -- JPG:Array ( [0] = 463 [1] = 399 [2] = 2 [3] = width=463 height=399 [bits] = 8 [channels] = 3 [mime] = image/jpeg ) PNG:Array ( [0] = 400 [1] = 479 [2] = 3 [3] = width=400 height=479 [bits] = 8 [mime] = image/png ) -- Edit bug report at https://bugs.php.net/bug.php?id=65749edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65749r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65749r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65749r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65749r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65749r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65749r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65749r=needscript Try newer version: https://bugs.php.net/fix.php?id=65749r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65749r=support Expected behavior: https://bugs.php.net/fix.php?id=65749r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65749r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65749r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65749r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65749r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65749r=dst IIS Stability: https://bugs.php.net/fix.php?id=65749r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65749r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65749r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65749r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65749r=mysqlcfg
Bug #65687 [Fbk-Asn]: oci_connect() fails with segmentation fault signal
Edit report at https://bugs.php.net/bug.php?id=65687edit=1 ID: 65687 User updated by:grig-siren at rambler dot ru Reported by:grig-siren at rambler dot ru Summary:oci_connect() fails with segmentation fault signal -Status: Feedback +Status: Assigned Type: Bug Package:Oracle related Operating System: Linux PHP Version:Irrelevant Assigned To:sixd Block user comment: N Private report: N New Comment: Bug report #58477 looks like something similar. But I use PHP 5.3.3. The following is from my phpinfo() result: OCI8 Supportenabled Version 1.4.5 Revision$Revision: 305257 $ Oracle Instant Client Version 10.2 Previous Comments: [2013-09-23 15:17:45] s...@php.net What would be most useful is version numbers of PHP OCI8, the Oracle client libraries and the Oracle database. I thought this crash was fixed long ago. See bugs like https://bugs.php.net/bug.php?id=58477 and https://bugs.php.net/bug.php?id=59896 [2013-09-18 06:21:43] grig-siren at rambler dot ru Sorry, but I can't do so. To do so I need DBA access rights to Oracle to restore user's password life time and make this password expired. But I don't have such rights. But I'm sure the problem is located inside oci_connect() call and execution. To locate it I have put debugging trigger_error() calls in my script in different places. And when I put trigger_error() call just before call to oci_connect() and another just after it - then I have got 'before' print in '/var/log/httpd/error_log' and fauilure message just after it. BTW, when I tried to connect to the same database with another tools (such as SQLDeveloper or SQL*Plus), I have got message ORA-2800x (sorry, I don't remember the last digit). I think, oci_connect() receives the same message, but don't expect it, and that's the reason of failure. [2013-09-17 21:47:56] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2013-09-17 10:15:34] grig-siren at rambler dot ru Description: I have tried to connect to Oracle database after user's password has expired. And result was: failure of PHP with message child pid ... exit signal Segmentation fault(11) in '/var/log/httpd/error_log' file. Then I asked Oracle DBA to modify user's profile and set password life time to unlimited - and after that all my scripts again work correctly. As I understand, the reason of such situation is warning message about password expiration issued by database during connection process. I think, this message is a big surprise for function oci_connect(). -- Edit this bug report at https://bugs.php.net/bug.php?id=65687edit=1
[PHP-BUG] Req #65750 [NEW]: Enabling factory constructors
From: thomas dot sahlin at invented dot se
Operating system:
PHP version: Irrelevant
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:Enabling factory constructors
Description:
It would be nice to be able to create factory constructors (like Dart
offers).
This could be achieved by allowing __construct to return an arbitrary
object of
the same class or a descendant thereof.
No return statement would then mean return $this; as it is today.
Sure, one can use a static factory method, but it's not as elegant and
cannot
simply be added to existing code without modifying all places where objects
are
instantiated.
Test script:
---
class MyClass
{
public function __construct($id)
{
if (isset(self::$cache[$id]))
return self::$cache[$id];
// Do expensive setup
self::$cache[$id] = $this;
}
private static $cache = array();
}
--
Edit bug report at https://bugs.php.net/bug.php?id=65750edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65750r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65750r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65750r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65750r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65750r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65750r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65750r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65750r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65750r=support
Expected behavior: https://bugs.php.net/fix.php?id=65750r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65750r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65750r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65750r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65750r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65750r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65750r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65750r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65750r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65750r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65750r=mysqlcfg
[PHP-BUG] Bug #65751 [NEW]: isset() and empty() hides illegal offset warning
From: anton dot polonskiy at gmail dot com Operating system: Ubuntu 13.04 PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:isset() and empty() hides illegal offset warning Description: Manual says: As of PHP 5.4 string offsets have to either be integers or integer-like strings, otherwise a warning will be thrown. Previously an offset like foo was silently cast to 0. That warning will suppressed by wrapping variable in isset() or empty(); http://3v4l.org/MEldp Test script: --- ?php $a = 'foo'; var_dump($a['bar']); // warning var_dump(empty($a['bar'])); // no warning var_dump(isset($a['bar'])); // no warning -- Edit bug report at https://bugs.php.net/bug.php?id=65751edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65751r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65751r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65751r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65751r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65751r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65751r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65751r=needscript Try newer version: https://bugs.php.net/fix.php?id=65751r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65751r=support Expected behavior: https://bugs.php.net/fix.php?id=65751r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65751r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65751r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65751r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65751r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65751r=dst IIS Stability: https://bugs.php.net/fix.php?id=65751r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65751r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65751r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65751r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65751r=mysqlcfg
Bug #65705 [Fbk-Csd]: simplexml_load_string does not honor error_reporting settting
Edit report at https://bugs.php.net/bug.php?id=65705edit=1
ID: 65705
User updated by:oskar dot mothander at gmail dot com
Reported by:oskar dot mothander at gmail dot com
Summary:simplexml_load_string does not honor error_reporting
settting
-Status: Feedback
+Status: Closed
Type: Bug
Package:SimpleXML related
Operating System: Windows 7 (64)
PHP Version:5.4.19
Block user comment: N
Private report: N
New Comment:
My misstake I think
Previous Comments:
[2013-09-22 22:47:33] ahar...@php.net
I can't reproduce this: setting display_errors to false or removing E_WARNING
from error_reporting() quiets the warnings as expected for me.
Do you have any extensions loaded that may interfere with error reporting, such
as xdebug or scream? (You can check this via phpinfo().) If not, does this
still
occur on a current version of PHP (ie 5.4.20 or 5.5.4)?
[2013-09-19 08:34:46] oskar dot mothander at gmail dot com
Description:
Calling simplexml_load_string() on invalid xml will output Warnings even though
you've been a good developer and turned these OFF on live environment.
Using libxml_use_internal_errors(true); fixes the problem but shouldn't be
nessesary.
This caused my site to display Warnings live.
Affected versions:
PHP 5.4.3 (not in the list above?)
PHP 5.3.8 (VC9 X86 32bit thread safe) + PEAR
Test script:
---
ini_set(display_errors, false);
simplexml_load_string('apa');
// Will still output Warnings even though they are off.
Expected result:
Empty result
Actual result:
--
Warning: simplexml_load_string() [function.simplexml-load-string]: Entity: line
1:
parser error : Premature end of data in tag apa line 1 on line 2
Warning: simplexml_load_string() [function.simplexml-load-string]: apa on
line 2
Warning: simplexml_load_string() [function.simplexml-load-string]: ^ on line 2
--
Edit this bug report at https://bugs.php.net/bug.php?id=65705edit=1
Bug #65002 [Com]: 0x00002aaaae9f6654 in gc_remove_zval_from_buffer () from /etc/httpd/modules/lib
Edit report at https://bugs.php.net/bug.php?id=65002edit=1 ID: 65002 Comment by: mheijkoop at gmail dot com Reported by:manas dot panda at tcubes dot com Summary:0x2e9f6654 in gc_remove_zval_from_buffer () from /etc/httpd/modules/lib Status: Feedback Type: Bug Package:Apache related Operating System: CentOS release 5.8 (Final) PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Same problem here on 5.3.10, on Ubuntu. Stacktrace: https://gist.github.com/anonymous/c09d8e491e9e0a454065 PHP 5.3.10-1ubuntu3.8 with Suhosin-Patch (cli) (built: Sep 4 2013 20:00:51) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans I can add that the exact same code that segfaults on the apache2 SAPI does run perfectly fine in CLI on the same machine. On a different machine, running the same PHP version, the problem does NOT occur: PHP 5.3.10-1ubuntu3.8 with Suhosin-Patch (cli) (built: Sep 4 2013 20:05:42) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans The machine on which the problem occurs has PHP compiled as 64-bits, the machine on which it does not is 32-bits. The code in question is doing a lot of __call and __callStatic, including a couple of methods that return references. That might be a clue as to what the underlying problem may be. Sadly, as of yet unable to create a minimal example to reproduce this bug. Previous Comments: [2013-06-10 11:07:42] larue...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2013-06-10 11:05:11] manas dot panda at tcubes dot com I have tried disabling zend.enable_gc. But it did not help. Reverted back zend.enable_gc = 0 [2013-06-10 10:54:16] manas dot panda at tcubes dot com Description: [root@spmgnm50 conf]# gdb /usr/sbin/httpd GNU gdb (GDB) CentOS (7.0.1-45.el5.centos) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/sbin/httpd...(no debugging symbols found)...done. (gdb) r -DONE_PROCESS Starting program: /usr/sbin/httpd -DONE_PROCESS warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2ad1e000 [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x2e9f6654 in gc_remove_zval_from_buffer () from /etc/httpd/modules/libphp5.so (gdb) where #0 0x2e9f6654 in gc_remove_zval_from_buffer () from /etc/httpd/modules/libphp5.so #1 0x2e9cd039 in _zval_ptr_dtor () from /etc/httpd/modules/libphp5.so #2 0x2e9e6838 in zend_hash_destroy () from /etc/httpd/modules/libphp5.so #3 0x2e9f83c9 in zend_object_std_dtor () from /etc/httpd/modules/libphp5.so #4 0x2e9f83e9 in zend_objects_free_object_storage () from /etc/httpd/modules/libphp5.so #5 0x2e9fc0c5 in zend_objects_store_del_ref_by_handle_ex () from /etc/httpd/modules/libphp5.so #6 0x2e9fc103 in zend_objects_store_del_ref () from /etc/httpd/modules/libphp5.so #7 0x2e9cd028 in _zval_ptr_dtor () from /etc/httpd/modules/libphp5.so #8 0x2e9e6838 in zend_hash_destroy () from /etc/httpd/modules/libphp5.so #9 0x2e9f83c9 in zend_object_std_dtor () from /etc/httpd/modules/libphp5.so #10 0x2e9f83e9 in zend_objects_free_object_storage () from /etc/httpd/modules/libphp5.so #11 0x2e9fc4a6 in zend_objects_store_free_object_storage () from /etc/httpd/modules/libphp5.so #12 0x2e9cd2e7 in ?? () from /etc/httpd/modules/libphp5.so #13 0x2e9d9b12 in ?? () from /etc/httpd/modules/libphp5.so #14 0x2e98644e in php_request_shutdown () from
Req #63105 [Com]: Default transanction isolation level in PHP for Firebird in php.ini
Edit report at https://bugs.php.net/bug.php?id=63105edit=1 ID: 63105 Comment by: slavb18 at gmail dot com Reported by:mar...@php.net Summary:Default transanction isolation level in PHP for Firebird in php.ini Status: Assigned Type: Feature/Change Request Package:InterBase related Operating System: All PHP Version:Irrelevant Assigned To:mariuz Block user comment: N Private report: N New Comment: examples: $pdo-setAttribute(PDO::ATTR_READONLY, FALSE); // read-write transaction (Default) $pdo-setAttribute(PDO::ATTR_READONLY, TRUE); // readonly transaction $pdo-setAttribute(PDO::ATTR_TIMEOUT, 0); // no_wait $pdo-setAttribute(PDO::ATTR_TIMEOUT, -1); // wait $pdo-setAttribute(PDO::ATTR_TIMEOUT, 4); // wait timeout 4 seconds $pdo-setAttribute(PDO::FB_TRANS_ISOLATION_LEVEL, PDO::FB_TRANS_COMMITTED); //read committed (default) ... etc FB_TRANS_COMMITTED_NO_REC_VERSION, FB_TRANS_CONCURRENCY, FB_TRANS_CONCURRENCY Previous Comments: [2012-09-18 07:52:40] mar...@php.net Discussion on firebird php list http://tech.groups.yahoo.com/group/firebird-php/message/3758 [2012-09-18 07:18:47] mar...@php.net Description: If you start a new transaction (or if one is started internally, where you cannot change the isolation level) where you donât explicitly specify isolation level the IBASE_DEFAULT is used. But this is IBASE_WRITE|IBASE_CONCURRENCY|IBASE_WAIT. This is read-write wait transaction in concurrency mode. This mode is most restrictive, nothing close to read committed. And to make it worse, thereâs no way to change this default value in runtime. You can only do it recompiling sources, nothing to be viable in most cases. http://blog.cincura.net/233007-default-transanction-isolation-level-in-php-for- firebird/ -- Edit this bug report at https://bugs.php.net/bug.php?id=63105edit=1
