Bug #65948 [Wfx]: extension and PHP API version mismatch
Edit report at https://bugs.php.net/bug.php?id=65948edit=1 ID: 65948 Updated by: johan...@php.net Reported by:wzis at hotmail dot com Summary:extension and PHP API version mismatch Status: Wont fix Type: Bug Package:*General Issues Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: First: Please don't confuse ABI and API compatibility. API compatibility we have to a way larger degree. So many things just need a recompilation. ABI, binary compatibility is what we are talking about. Yes, operating system core APIs have quite some restrictions on ABI compatibility, this leads to some maintenance hell in some areas like use of special #defines to enable specific features or bug fixes or ... There the restrictions make sense - you can run only one libc on a host. With PHP this isn't the case. That said: We are aware of the fact that we might do better by having a stricter defined API and keeping that stable. For none of the active contributors (who are volunteers) this is not a big issue, though. If you want to help in that area this is welcome. Some basic thoughts are in these RFCs: https://wiki.php.net/rfc/php_native_interface https://wiki.php.net/rfc/remove_zend_api Previous Comments: [2013-10-24 00:16:35] wzis at hotmail dot com If glibc follows the PHP in way of doing API compatibility, it will be nightmare for 3rd party software developers. [2013-10-24 00:12:25] wzis at hotmail dot com But API should be very stable: one example is glibc: even though it has been many version releases, but so long you compile a program on a version of glibc, and only run that binary on system with that version of glibc or newer, the program can run successfully. [2013-10-23 23:12:09] johan...@php.net If you want to do experiments in that area you could do magic by creating your own get_module() function which detects the PHP version, but we change structures as we see need between releases. You are mentioning 5.1 versus 5.5 that's 8 years of development work with lots of improvements. We care a lot about binary compatibility between bug fix releases (x.y.z++) but not feature releases (x.y++.z) [2013-10-23 23:00:34] wzis at hotmail dot com If we only use very minimum PHP API functions and data structures, is there a way to achieve build once, run on multiple versions? [2013-10-23 22:56:13] wzis at hotmail dot com What do you mean by Please use #if #ifdef to make your module built with versions. I personally have module that works from PHP 4.3 through master, you should be able to do that. Do we still need to build the module for each version (x.y) or by using the #if #ifdef now we can build module on one version, use it on newer versions? Any example? 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=65948 -- Edit this bug report at https://bugs.php.net/bug.php?id=65948edit=1
Bug #65848 [Opn-Fbk]: output from php error
Edit report at https://bugs.php.net/bug.php?id=65848edit=1 ID: 65848 Updated by: johan...@php.net Reported by:wisans at gmail dot com Summary:output from php error -Status: Open +Status: Feedback Type: Bug Package:*General Issues Operating System: Linux 2.6.32-279.el6.x86_64 PHP Version:5.5.4 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 ?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. I do not understand to which error you are referring. Please provide a simple reproducible script and a clear error description. Previous Comments: [2013-10-07 04:06:44] wisans at gmail dot com Description: this error it happen random. i attach file you can see image output and some my source code in zip file. now i use ob_start to prevent this error i share file in https://www.dropbox.com/sh/3hckbmog2y1mtem/aM_6FkbqpC please help me -- Edit this bug report at https://bugs.php.net/bug.php?id=65848edit=1
Bug #65817 [Opn-Nab]: curl extension not visible after executing get_loaded_extensions()
Edit report at https://bugs.php.net/bug.php?id=65817edit=1 ID: 65817 Updated by: johan...@php.net Reported by:forsoap at gmail dot com Summary:curl extension not visible after executing get_loaded_extensions() -Status: Open +Status: Not a bug Type: Bug Package:cURL related Operating System: Windows 7 PHP Version:5.5.4 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Apparently apache can't load it. This might have different reasons. i.e. apache miht use a different php.ini or different PHP version. There might also be permission or other system level reasons. Check your logs etc. Previous Comments: [2013-10-02 18:06:50] forsoap at gmail dot com Description: In php.ini I uncommented string: extension=php_curl.dll When I run php -m, it shows in list curl, but when I try use get_loaded_extensions() in any php file it not in list. Also I am using php as an module in Apache 2.4 and problem can be reproduced if php loads as module in apache -- Edit this bug report at https://bugs.php.net/bug.php?id=65817edit=1
Bug #65675 [Opn-Fbk]: BingSiteAuth.xml
Edit report at https://bugs.php.net/bug.php?id=65675edit=1 ID: 65675 Updated by: johan...@php.net Reported by:mbiama at angosso dot com Summary:BingSiteAuth.xml -Status: Open +Status: Feedback Type: Bug Package:Output Control Operating System: webmaster bing PHP Version:master-Git-2013-09-15 (snap) Block user comment: N Private report: N New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Not sure what you want. PHP has no function string() and no predefined constant __CNAME__. the line with curl: is invalid from syntax. Please provide the exact reproduce code and your expected result. Previous Comments: [2013-09-15 14:50:34] mbiama at angosso dot com Description: Short script that reproduces the problem Test script: --- meta name=msvalidate.01 content=828E463BCD9081D94FAFA3E20CFE019F / html head meta name=msvalidate.01 content=828E463BCD9081D94FAFA3E20CFE019F / titleLes Diasporas Plurielles::[Dotted] - The Plural Diasporas here and in The World/title /head body p ?php include string(__CNAME__).'/541b04f323a031051553264d35181e65/verify.bing.com'; curl:'http://www.[dotted].com/BingSiteAuth.xml; ? /p /body /html Expected result: meta name=msvalidate.01 content=828E463BCD9081D94FAFA3E20CFE019F / html head meta name=msvalidate.01 content=828E463BCD9081D94FAFA3E20CFE019F / titleLes Diasporas Plurielles::[Dotted] - The Plural Diasporas here and in The World/title /head body ?php include string(__CNAME__).'/541b04f323a031051553264d35181e65/verify.bing.com'; curl:'http://www.[dotted].com/BingSiteAuth.xml; ? /body /html -- Edit this bug report at https://bugs.php.net/bug.php?id=65675edit=1
Bug #65647 [Opn-Fbk]: @list call behaves incorrectly and may cause Segmentation fault (11)
Edit report at https://bugs.php.net/bug.php?id=65647edit=1
ID: 65647
Updated by: johan...@php.net
Reported by:piotr dot m at shwrm dot com
Summary:@list call behaves incorrectly and may cause
Segmentation fault (11)
-Status: Open
+Status: Feedback
Type: Bug
Package:*General Issues
Operating System: Linux / Ubuntu 13.04
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
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.
The above has guidance on creating a backtrace, but please disable Zend
Optimizer and XDebug first.
Previous Comments:
[2013-09-10 10:43:53] piotr dot m at shwrm dot com
No, the problem does not seem to persit when run in CLI mode. The code behaves
exactly as it should.
Here's a var_dump(get_loaded_extensions()):
0 = string 'Core' (length=4)
1 = string 'date' (length=4)
2 = string 'ereg' (length=4)
3 = string 'libxml' (length=6)
4 = string 'openssl' (length=7)
5 = string 'pcre' (length=4)
6 = string 'zlib' (length=4)
7 = string 'bcmath' (length=6)
8 = string 'bz2' (length=3)
9 = string 'calendar' (length=8)
10 = string 'ctype' (length=5)
11 = string 'dba' (length=3)
12 = string 'dom' (length=3)
13 = string 'hash' (length=4)
14 = string 'fileinfo' (length=8)
15 = string 'filter' (length=6)
16 = string 'ftp' (length=3)
17 = string 'gettext' (length=7)
18 = string 'SPL' (length=3)
19 = string 'iconv' (length=5)
20 = string 'json' (length=4)
21 = string 'mbstring' (length=8)
22 = string 'session' (length=7)
23 = string 'standard' (length=8)
24 = string 'posix' (length=5)
25 = string 'Reflection' (length=10)
26 = string 'Phar' (length=4)
27 = string 'shmop' (length=5)
28 = string 'SimpleXML' (length=9)
29 = string 'soap' (length=4)
30 = string 'sockets' (length=7)
31 = string 'exif' (length=4)
32 = string 'sysvmsg' (length=7)
33 = string 'sysvsem' (length=7)
34 = string 'sysvshm' (length=7)
35 = string 'tokenizer' (length=9)
36 = string 'wddx' (length=4)
37 = string 'xml' (length=3)
38 = string 'xmlreader' (length=9)
39 = string 'xmlwriter' (length=9)
40 = string 'zip' (length=3)
41 = string 'apache2handler' (length=14)
42 = string 'PDO' (length=3)
43 = string 'curl' (length=4)
44 = string 'imap' (length=4)
45 = string 'memcached' (length=9)
46 = string 'pdo_pgsql' (length=9)
47 = string 'pgsql' (length=5)
48 = string 'readline' (length=8)
49 = string 'redis' (length=5)
50 = string 'mhash' (length=5)
51 = string 'Zend OPcache' (length=12)
52 = string 'xdebug' (length=6)
Unfortunately the coredump does not get created - any ideas on how i might
force the generation of one?
[2013-09-10 09:52:06] leight+bugs dot php at gmail dot com
Unable to reproduce with 5.5.3 or 5.6.0-dev on Debian 7 or OSX using PHP CLI
(unable to test with Apache at present).
Piotr do you get the same results using the CLI? What other modules do you have
loaded?
A backtrace of the coredump might also be useful.
[2013-09-10 09:21:08] piotr dot m at shwrm dot com
Description:
Call to @list on an array returned by function_get_args() will incorrectly fill
variables (only last one is filled) 80% of the time and will cause a
Segmentation fault (11) on the other 20%.
PHP 5.5.3 run on Apache 2.2.22
Test script:
---
function a() {
$opts = func_get_args();
@list($a, $b, $c) = $opts;
var_dump($a, $b, $c);
}
a('1','22', '333');
Expected result:
string '1' (length=1)
string '22' (length=2)
string '333' (length=3)
Actual result:
--
null
null
string '333' (length=3)
Or segfault:
[Tue Sep 10 10:57:46 2013] [notice] child pid 32315 exit signal Segmentation
fault (11), possible coredump in /etc/apache2
--
Edit this bug report at https://bugs.php.net/bug.php?id=65647edit=1
Bug #65648 [Opn-Nab]: Check date error
Edit report at https://bugs.php.net/bug.php?id=65648edit=1 ID: 65648 Updated by: johan...@php.net Reported by:manhchat dot it at gmail dot com Summary:Check date error -Status: Open +Status: Not a bug Type: Bug Package:Date/time related Operating System: Linux, Windown PHP Version:5.5.4RC1 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php A number prefixed by 0 is interpreted as octal. Please see http://php.net/integer Previous Comments: [2013-09-10 09:50:06] manhchat dot it at gmail dot com Description: function checkdate of PHP error: checkdate(009, 0023, 2013) will return true -- Edit this bug report at https://bugs.php.net/bug.php?id=65648edit=1
Bug #65643 [Opn-Nab]: Dynamically created methods cannot be called directly
Edit report at https://bugs.php.net/bug.php?id=65643edit=1
ID: 65643
Updated by: johan...@php.net
Reported by:yuri dot sulyma at gmail dot com
Summary:Dynamically created methods cannot be called
directly
-Status: Open
+Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: OS X 10.8.4
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is a limitation of PHP's type system. Functions/methods and variables
don't share a common namespace. Currently there is no plan to change this.
Previous Comments:
[2013-09-09 18:13:07] yuri dot sulyma at gmail dot com
Description:
Methods dynamically created by assigning a closure to a property of $this
cannot be called directly, but must instead by assigned to a variable first.
Test script:
---
class O {
public $f;
function __construct() {
$this-f = function() {
echo Dynamic method\n;
};
}
}
$o = new O();
$f = $o-f;
$f();
$o-f();
Expected result:
Dynamic method
Dynamic method
Actual result:
--
Dynamic method
Fatal error: Call to undefined method O::f()
--
Edit this bug report at https://bugs.php.net/bug.php?id=65643edit=1
Bug #65628 [Opn-Fbk]: pcntl_signal may produce segfault
Edit report at https://bugs.php.net/bug.php?id=65628edit=1 ID: 65628 Updated by: johan...@php.net Reported by:imprec at gmail dot com Summary:pcntl_signal may produce segfault -Status: Open +Status: Feedback Type: Bug Package:PCNTL related Operating System: OSX PHP Version:5.5.3 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 ?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. It is really hard to figure out what is causing this. Please try to reduce the code as much as possible (throw out other tests, run test code manually outside the test framework etc) Previous Comments: [2013-09-06 11:34:06] imprec at gmail dot com Description: Hello, In a unit test suite, when I call pcntl_signal, I got a segfault : Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00179788b729 0x0001003ec3b2 in zend_objects_store_del_ref () (gdb) #0 0x0001003ec3b2 in zend_objects_store_del_ref () No symbol table info available. #1 0x0001003b9c7e in _zval_ptr_dtor () No symbol table info available. #2 0x0001003e5cae in zend_closure_free_storage () No symbol table info available. #3 0x0001003ec554 in zend_objects_store_del_ref_by_handle_ex () No symbol table info available. #4 0x0001003ec396 in zend_objects_store_del_ref () No symbol table info available. #5 0x0001003b9c7e in _zval_ptr_dtor () No symbol table info available. #6 0x0001003d40b0 in _zend_hash_index_update_or_next_insert () No symbol table info available. #7 0x0001001c8bfe in zif_pcntl_signal () No symbol table info available. #8 0x0001003b9524 in dtrace_execute_internal () No symbol table info available. #9 0x00010043d0c2 in zend_do_fcall_common_helper_SPEC () No symbol table info available. #10 0x0001003ed10a in execute_ex () No symbol table info available. #11 0x0001003b9458 in dtrace_execute_ex () No symbol table info available. #12 0x00010043d036 in zend_do_fcall_common_helper_SPEC () No symbol table info available. #13 0x0001003ed10a in execute_ex () No symbol table info available. #14 0x0001003b9458 in dtrace_execute_ex () No symbol table info available. #15 0x00010043d036 in zend_do_fcall_common_helper_SPEC () No symbol table info available. #16 0x0001003ed10a in execute_ex () No symbol table info available. #17 0x0001003b9458 in dtrace_execute_ex () No symbol table info available. #18 0x0001003bb57a in zend_call_function () No symbol table info available. #19 0x000100212268 in zim_reflection_method_invokeArgs () No symbol table info available. #20 0x0001003b9524 in dtrace_execute_internal () No symbol table info available. #21 0x00010043d0c2 in zend_do_fcall_common_helper_SPEC () No symbol table info available. #22 0x0001003ed10a in execute_ex () No symbol table info available. #23 0x0001003b9458 in dtrace_execute_ex () No symbol table info available. #24 0x00010043d036 in zend_do_fcall_common_helper_SPEC () No symbol table info available. #25 0x0001003ed10a in execute_ex () No symbol table info available. #26 0x0001003b9458 in dtrace_execute_ex () No symbol table info available. #27 0x00010043d036 in zend_do_fcall_common_helper_SPEC () No symbol table info available. #28 0x0001003ed10a in execute_ex () No symbol table info available. #29 0x0001003b9458 in dtrace_execute_ex () No symbol table info available. #30 0x00010043d036 in zend_do_fcall_common_helper_SPEC () No symbol table info available. #31 0x0001003ed10a in execute_ex () No symbol table info available. #32 0x0001003b9458 in dtrace_execute_ex () No symbol table info available. #33 0x00010043d036 in zend_do_fcall_common_helper_SPEC () No symbol table info available. #34 0x0001003ed10a in execute_ex () No symbol table info available. #35 0x0001003b9458 in dtrace_execute_ex () No symbol table info available. #36 0x00010043d036 in zend_do_fcall_common_helper_SPEC () No symbol table info available. #37 0x0001003ed10a in execute_ex () No symbol table info available. #38 0x0001003b9458 in dtrace_execute_ex () No symbol table info available. #39 0x00010043d036 in zend_do_fcall_common_helper_SPEC () No symbol table info available. #40 0x0001003ed10a in execute_ex () No symbol table info available. #41 0x0001003b9458
Req #41856 [Opn]: support for anonymous classes
Edit report at https://bugs.php.net/bug.php?id=41856edit=1
ID: 41856
Updated by: johan...@php.net
Reported by:mbaynton at gmail dot com
Summary:support for anonymous classes
Status: Open
Type: Feature/Change Request
Package:*General Issues
PHP Version:5.2.3
Block user comment: N
Private report: N
New Comment:
My guess is that anonymous classes would have a good chance once a good
implementation comes by. This is not completely trivial as the class_entry has
to be stored in the class_table but has to be somewhat hidden and we might have
to find a way to hide the information in the oparray.
As all things in PHP this needs a volunteer to do it. All contributors have
sometime X to work on PHP and in time X can either discuss stuff, fix bugs or
implement features ... but with some guidance this might be a nice project for
a newcomer (I'd volunteer to give a hand to point in the right direction etc.,
while this guarantees acceptance in no way as that would need an RFC etc.)
until then we have to live with workarounds.
For the PageController interface example an (work-around) alternative is
$page_controller = [
'get' = function () {},
'post' = function () {}
};
Previous Comments:
[2013-09-02 21:42:36] zatacorothx at gmail dot com
Anonymous classes in Java are convenient when used with Interfaces. In PHP,
this
could help with MVC frameworks. Say all pages had a class that implemented
PageController:
[some_page.php]
$page_controller = new PageInterface() {
function doGet() {}
function doPost() {}
};
A current workaround would be using a factory or constructor to which you pass
required methods, and not using an interface. It works, but then you have to
deal with missing methods in application logic where you could otherwise just
handle an error.
[2013-07-22 15:32:27] pacerier at gmail dot com
+1
[2012-03-15 18:45:47] paj...@php.net
Not exactly the same but look at closure and traits support in 5.4.
[2012-03-15 18:35:55] david71rj at gmail dot com
+1
[2011-11-09 11:34:50] antoniocs at gmail dot com
Would be nice to have this in Php 5.4 (or a latter version)
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=41856
--
Edit this bug report at https://bugs.php.net/bug.php?id=41856edit=1
Bug #65587 [Fbk-Nab]: When PHP was upgraded from 5.2 to 5.4,then the bug will comes out
Edit report at https://bugs.php.net/bug.php?id=65587edit=1 ID: 65587 Updated by: johan...@php.net Reported by:xiche at adobe dot com Summary:When PHP was upgraded from 5.2 to 5.4,then the bug will comes out -Status: Feedback +Status: Not a bug Type: Bug Package:Strings related Operating System: Linux PHP Version:5.4.19 Block user comment: N Private report: N New Comment: In the old version an array was silently converted to a string Array which makes little sense. PHP no warns when this would happen. This is a bug in your code we're warning you about. Previous Comments: [2013-08-30 06:47:24] requi...@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-08-30 06:14:28] xiche at adobe dot com Description: --- From manual page: http://www.php.net/function.strstr#refsect1-function.strstr-description --- When PHP was upgraded from 5.2 to 5.4,then the warning message will comes out: PHP Warning: strstr() expects parameter 1 to be string, array given in - on line 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=65587edit=1
Bug #65596 [Wfx-Nab]: usleep prevents script timeout
Edit report at https://bugs.php.net/bug.php?id=65596edit=1
ID: 65596
Updated by: johan...@php.net
Reported by:ukrtelecom at gmail dot com
Summary:usleep prevents script timeout
-Status: Wont fix
+Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: Linux
PHP Version:5.4Git-2013-08-30 (snap)
Block user comment: N
Private report: N
New Comment:
What happens depends on the operating system, in general we tr tomeasure the
time spent on cpu, not the time elapsed.
On systems which have setitimer (Linux and other unixes) we use setitimer with
ITIMER_PROF, which, in my linux system's man page is documented as
ITIMER_PROFdecrements both when the process executes and when the
system is executing on behalf of the process.
During sleep nothing is being executed.
Previous Comments:
[2013-08-30 18:26:45] anon at anon dot anon
@ab Well of course it's solvable.
1. sleepTime = min(specifiedTime, timeLimit - scriptTime)
2. Do system call.
3. scriptTime += sleepTime
I don't understand why you track script time in such a bizarre fashion that it
somehow doesn't contribute to the time limit anyway.
[2013-08-30 18:00:25] a...@php.net
This is unsolvable in PHP, sleep is a system call so it will suspend the
execution
. It can be only interrupted by a signal which can't be thrown from PHP because
the execution is suspended :)
[2013-08-30 15:47:44] ukrtelecom at gmail dot com
Description:
Usleeped time does not count in total timeout time.
Commenting out line 11 usleep(10) in the test script results with expected
Fatal timeout in 2 seconds.
Enabling line 11 usleep(10) makes script exit by condition in 50 seconds.
Increasing waiting time to 100 seconds in line 2 results with timeout Fatal
error in 60-70 sec.
PHP 5.4.20-dev (cli) (built: Aug 30 2013 14:18:16)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
./configure --disable-libxml --disable-xml --disable-simplexml --disable-
xmlreader --disable-xmlwriter --disable-dom --without-pear
OS Ubuntu 12.04 LTS
Linux precise64 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
Test script:
---
?php
$wait = 50;
echo ini_get('max_execution_time');
set_time_limit(2);
$ts = time();
while(true) {
// usleep for 10 microseconds
usleep(10);
if ((time()- $ts) $wait) {
echo time() -$ts;
echo \n\nFailed! . ini_get('max_execution_time') . \n;
break;
}
}
Expected result:
0
Fatal error: Maximum execution time of 2 seconds exceeded in
/home/vagrant/t.php
on line 12
Actual result:
--
#with wait time 50 sec:
$ date; php t.php ; date
Fri Aug 30 15:40:54 UTC 2013
0
51
Failed! 2
Fri Aug 30 15:41:45 UTC 2013
#with wait time 100 sec:
$ date; php t.php ; date
Fri Aug 30 15:35:45 UTC 2013
0
Fatal error: Maximum execution time of 2 seconds exceeded in
/home/vagrant/t.php
on line 12
Fri Aug 30 15:36:40 UTC 2013
--
Edit this bug report at https://bugs.php.net/bug.php?id=65596edit=1
Bug #65583 [Opn-Nab]: PDO MySQL driver does not escape properly backslashes
Edit report at https://bugs.php.net/bug.php?id=65583edit=1
ID: 65583
Updated by: johan...@php.net
Reported by:kevin at les-tilleuls dot coop
Summary:PDO MySQL driver does not escape properly
backslashes
-Status: Open
+Status: Not a bug
Type: Bug
Package:PDO related
Operating System: Mac OS X
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Your issue is that for LIKE the \ is a special character. If you use
$stmt = $dbh-prepare('SELECT test FROM test WHERE test = :data');
all works. See also
http://dev.mysql.com/doc/refman/5.6/en/string-comparison-functions.html#operator_like
Previous Comments:
[2013-08-29 13:10:55] kevin at les-tilleuls dot coop
Description:
PDO MySQL driver does not escape backslashes in string.
The MySQL doc indicates that backslashes must be doubled to be escaped
http://dev.mysql.com/doc/refman/5.6/en/string-literals.html
The driver does not do that. See the script above.
Should this escaping be done by PDO or a higher layer like Doctrine DBAL?
Test script:
---
?php
define('DSN', 'mysql:dbname=testdb;host=127.0.0.1');
define('USER', 'root');
define('PASSWORD', '');
/* DATABASE STRUCTURE
CREATE TABLE `test` (
`test` varchar(255) NOT NULL,
PRIMARY KEY (`test`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
*/
$dbh = new PDO(DSN, USER, PASSWORD);
$data = '\\' . uniqid();
$stmt = $dbh-prepare('INSERT INTO test(test) VALUES(:data)');
$stmt-execute(array('data' = $data));
$stmt = $dbh-prepare('SELECT test FROM test WHERE test LIKE :data');
$stmt-execute(array('data' = $data));
var_dump($stmt-fetchColumn());
$stmt = $dbh-prepare('SELECT test FROM test WHERE test LIKE :data');
$stmt-execute(array('data' = str_replace('\\', '', $data)));
var_dump($stmt-fetchColumn());
Expected result:
string(14) \521f3f450f597
bool(false)
Actual result:
--
bool(false)
string(14) \521f3f450f597
--
Edit this bug report at https://bugs.php.net/bug.php?id=65583edit=1
Bug #65573 [Opn-Nab]: Parsing fails on simple one line echo
Edit report at https://bugs.php.net/bug.php?id=65573edit=1 ID: 65573 Updated by: johan...@php.net Reported by:phpnet at theodore dot phpexperts dot pro Summary:Parsing fails on simple one line echo -Status: Open +Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.4.19 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php hexdup shows you have some binary stuff (0a c2 a0 c2 a0) behind the opening tag. 3c 3f 70 68 70 0a c2 a0 c2 a0 20 65 63 68 6f 20 |?php. echo | Previous Comments: [2013-08-28 15:22:27] phpnet at theodore dot phpexperts dot pro The Attach file thing appears to have not worked. You can get the exact test case at http://www.phpexperts.pro/files/bad_php.txt [2013-08-28 15:16:25] phpnet at theodore dot phpexperts dot pro Description: PHP Parse error: syntax error, unexpected 'echo' (T_ECHO) in bad.php on line 2 I have attached the affected file. I can readily duplicate the issue across various PHP instances ranging from 5.2 to 5.4.19, nothing else was tested. Test script: --- ?php   echo This should work. But it doesn't!\n; Expected result: Output: This should work. But it doesn't! Actual result: -- PHP Parse error: syntax error, unexpected 'echo' (T_ECHO) in /home/tsmith/books/dimensional_shift/test.php on line 2 -- Edit this bug report at https://bugs.php.net/bug.php?id=65573edit=1
Req #61759 [Opn]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759edit=1
ID: 61759
Updated by: johan...@php.net
Reported by:ahar...@php.net
Summary:class_alias() should accept classes with leading
backslashes
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Irrelevant
PHP Version:master-Git-2012-04-18 (Git)
Block user comment: N
Private report: N
New Comment:
Technically we could, but it adds some inconsistency if one place allows this
but others not and that should be avoided.
Previous Comments:
[2013-08-27 09:46:53] jpa...@php.net
The following patch has been added/updated:
Patch Name: fix-class_alias
Revision: 1377596813
URL:
https://bugs.php.net/patch-display.php?bug=61759patch=fix-class_aliasrevision=1377596813
[2013-08-27 09:45:12] jpa...@php.net
Johannes: I agree, but we could start by patching this bug report right?
I got a patch here : https://github.com/jpauli/php-
src/compare/class_alias_registration_fix
[2013-08-26 18:32:26] johan...@php.net
Note: The bug report is too restrictive. A proper patch would have to work on
all places where classnames come from string context. This at first means
verifying that all places go via zend_lookup_class() and related functions, not
EG(class_table) / CG(class_table)
[2013-08-26 18:13:08] contact at jubianchi dot fr
I experienced the exact same issue on PHP 5.4.17 on OS X 10.9 (Mavericks DP6).
I wrote a simple test case, here it is :
Test script:
---
namespace jubianchi\Alias {
class A {}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'C'));
$reflector = new \ReflectionClass('C');
var_dump($reflector-getName());
var_dump(class_alias('\\jubianchi\\Alias\\A', '\\jubianchi\\Alias\\B'));
try {
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector-getName());
} catch(\Exception $e) {
var_dump(get_class($e) . ': ' . $e-getMessage());
}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'jubianchi\\Alias\\B'));
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector-getName());
}
Expected result:
bool(true)
string(17) jubianchi\Alias\A
bool(true)
string(17) jubianchi\Alias\A
bool(true)
string(17) jubianchi\Alias\A
Or:
bool(true)
string(17) jubianchi\Alias\A
bool(false)
string(60) ReflectionException: Class \jubianchi\Alias\B does not exist
bool(true)
string(17) jubianchi\Alias\A
Actual result:
bool(true)
string(1) A
bool(true)
string(17) jubianchi\Alias\A
bool(true)
string(60) ReflectionException: Class \jubianchi\Alias\B does not exist
bool(true)
string(17) jubianchi\Alias\A
As you can see, class_alias returns bool(true) as if everything went fine, so
we
expect the alias to be available but a reflection on the latter throws an
exception.
I think class_alias should be able to handle the leading backslashes or return
bool(false) if it can't.
[2012-04-18 06:11:21] ahar...@php.net
Description:
Aliasing namespaced classes currently expects that class names will be given in
the same form as the ZE uses internally; ie without a leading backslash. Since
that's inconsistent with the absolute form in PHP, it would be good if
class_alias() could also ignore a leading backslash.
Test script:
---
?php
namespace A;
class C { function foo() { echo 42\n; } }
namespace B;
class_alias('\A\C', '\B\C');
$c = new C;
$c-foo();
Expected result:
42
Actual result:
--
Fatal error: Class 'B\C' not found in /private/tmp/test.php on line 7
--
Edit this bug report at https://bugs.php.net/bug.php?id=61759edit=1
Bug #65562 [Opn]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562edit=1 ID: 65562 Updated by: johan...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg Status: Open Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Adam, well usually we won't need such an test function as usually we only accept things reproducable with core PHP a bug, so this report is no PHP bug. The primary purpose of the debug function here would be to allow verifying this issue was fixed (if rrh confirms this is the actual issue, I might have overseen some other issue). As I define this as not a PHP bug per se I agreee with Niki that we simply might not add an test to our test suite (currently this would be relevant only in an edge case for a commercial extension, due to the kind of error and PHP's gc also of low severity) but I wanted to discuss the requirements in case somebody picks this bug up. (and it's not one of, we already have leak() and two or so other debug only functions already) Anyways, the time spent on discussing this might have been more than needed to fixtest this, so I'll shut up unless anybody wants my review or I have some timemood while sitting on a machine with a PHP tree. ;-) Previous Comments: [2013-08-27 20:06:55] ahar...@php.net With my doc hat on, I'm personally not too concerned if we have a debug build only function â we can cross that bridge when we get to it, and I don't think anyone relies particularly heavily on the prototype extraction scripts anyway. With my php-src hat on, would it be better to consider adding a debug extension (say ext/debug) that wraps ZE functions where appropriate so we can start writing PHPT tests for them, rather than doing this as a one off? [2013-08-27 09:42:17] ni...@php.net @johannes: Does this really need a test? The change is rather obvious after all. Introducing debug-only functions for this seems like overkill. [2013-08-26 23:15:59] johan...@php.net A cleaner patch might pass the quiet argument to zend_parse_arg_impl, this would safe the allocation in there. This also seems to be limited to C and f modifiers which, in PHP itself, aren't used in combination with ZEND_PARSE_PARAMS_QUIET. So for adding a test we might need a deug-build-only functionin zend_builtin_functions.c. This might need coordination with docs and their function detection scripts. And sorry if I'm a bit harsh, but 99% of the internal API bugs we get are user errors and this bug was sparse on information. [2013-08-26 23:14:26] s...@php.net Waiting feedback on the patch [2013-08-26 23:07:33] rrh at newrelic dot com I will test the patch, and in the future come up with patches for your review. 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=65562 -- Edit this bug report at https://bugs.php.net/bug.php?id=65562edit=1
Bug #65556 [Opn-Nab]: Wrong error thrown
Edit report at https://bugs.php.net/bug.php?id=65556edit=1
ID: 65556
Updated by: johan...@php.net
Reported by:ante dot drnasin at wirecard dot com
Summary:Wrong error thrown
-Status: Open
+Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: Win7 Pro x64
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
The parser looks for something starting with a $ sign (to check for an
variable, property, array offset etc.) or some literal followed by :: in order
to check for static properties, it doesn't check whether the literal is a valid
class name at that stage and null is no conflicting parser token.
Previous Comments:
[2013-08-26 08:18:52] ante dot drnasin at wirecard dot com
Description:
Just a small issue.
When (ab)using return empty(null);
you get T_PAAMAYIM_NEKUDOTAYIM error (unexpected ) expecting ::) which is
not true...
is it per design or a bug?
Test script:
---
function test() {
return empty(null);
}
Expected result:
Null is not a valid value for empty
Actual result:
--
T_PAAMAYIM_NEKUDOTAYIM error
--
Edit this bug report at https://bugs.php.net/bug.php?id=65556edit=1
Bug #65557 [Ver]: Constants from Core are not defined with inline scripts
Edit report at https://bugs.php.net/bug.php?id=65557edit=1
ID: 65557
Updated by: johan...@php.net
Reported by:Laurent dot Lyaudet at gmail dot com
Summary:Constants from Core are not defined with inline
scripts
Status: Verified
Type: Bug
Package:CGI/CLI related
Operating System: Linux
PHP Version:5.4 and later
Block user comment: N
Private report: N
New Comment:
This is done by purpose: We can't easily provide STDIN as that's bound to the
script input and we either provide all three (STDIN, STDOUT, STERR) or none.
Maybe this can be improved to rebind STDIN (and then providing all three) after
the full script has been passed.
Maybe this trinity can be relaxed.
This requires some more analysis of the consequences.
Previous Comments:
[2013-08-26 09:09:30] yohg...@php.net
[yohgaki@dev PHP-5.5]$ echo '?php fwrite(STDERR, stderr\n); ' |
./sapi/cli/php
Warning: fwrite() expects parameter 1 to be resource, string given in - on line
1
[2013-08-26 09:06:21] Laurent dot Lyaudet at gmail dot com
Additionally I noted that
#echo '?php fwrite(STDERR, stderr\n); ?' test
#php test
works.
Is is somehow surprising since I would have thought that the only difference
between php test and php ?php fwrite(STDERR, stderr\n); ? was the input
stream for php code.
[2013-08-26 08:49:43] Laurent dot Lyaudet at gmail dot com
Description:
Hi,
I found a bug affecting PHP 5.3.3-7+squeeze15 and PHP 5.4.4-14+deb7u3 (cli)
(latest debian package for current stable).
The constant STDERR is not defined for inline scripts.
I mean it isn't defined when you type #php and then you type ?php
myscriptcontent ?, Ctrl+D.
But it works if you use php -r 'myscriptcontent'.
I join test script below.
I didn't tested it but I assume it is not specifically STDERR which is impacted.
It is probably the same for all Core constants.
Best regards,
Laurent Lyaudet
Test script:
---
php -r 'fwrite(STDERR, stderr\n);'
works but
root@wheezyDEVLaurent:~# php
?php
fwrite(STDERR, stderr\n);
?
doesn't.
Expected result:
stderr
Actual result:
--
PHP Notice: Use of undefined constant STDERR - assumed 'STDERR' in - on line 3
PHP Stack trace:
PHP 1. {main}() -:0
Notice: Use of undefined constant STDERR - assumed 'STDERR' in - on line 3
Call Stack:
10.9477 215280 1. {main}() -:0
PHP Warning: fwrite() expects parameter 1 to be resource, string given in - on
line 3
PHP Stack trace:
PHP 1. {main}() -:0
PHP 2. fwrite() -:3
Warning: fwrite() expects parameter 1 to be resource, string given in - on line
3
Call Stack:
10.9477 215280 1. {main}() -:0
10.9479 216048 2. fwrite() -:3
--
Edit this bug report at https://bugs.php.net/bug.php?id=65557edit=1
Req #61759 [Opn]: class_alias() should accept classes with leading backslashes
Edit report at https://bugs.php.net/bug.php?id=61759edit=1
ID: 61759
Updated by: johan...@php.net
Reported by:ahar...@php.net
Summary:class_alias() should accept classes with leading
backslashes
Status: Open
Type: Feature/Change Request
Package:Class/Object related
Operating System: Irrelevant
PHP Version:master-Git-2012-04-18 (Git)
Block user comment: N
Private report: N
New Comment:
Note: The bug report is too restrictive. A proper patch would have to work on
all places where classnames come from string context. This at first means
verifying that all places go via zend_lookup_class() and related functions, not
EG(class_table) / CG(class_table)
Previous Comments:
[2013-08-26 18:13:08] contact at jubianchi dot fr
I experienced the exact same issue on PHP 5.4.17 on OS X 10.9 (Mavericks DP6).
I wrote a simple test case, here it is :
Test script:
---
namespace jubianchi\Alias {
class A {}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'C'));
$reflector = new \ReflectionClass('C');
var_dump($reflector-getName());
var_dump(class_alias('\\jubianchi\\Alias\\A', '\\jubianchi\\Alias\\B'));
try {
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector-getName());
} catch(\Exception $e) {
var_dump(get_class($e) . ': ' . $e-getMessage());
}
var_dump(class_alias('\\jubianchi\\Alias\\A', 'jubianchi\\Alias\\B'));
$reflector = new \ReflectionClass('\\jubianchi\\Alias\\B');
var_dump($reflector-getName());
}
Expected result:
bool(true)
string(17) jubianchi\Alias\A
bool(true)
string(17) jubianchi\Alias\A
bool(true)
string(17) jubianchi\Alias\A
Or:
bool(true)
string(17) jubianchi\Alias\A
bool(false)
string(60) ReflectionException: Class \jubianchi\Alias\B does not exist
bool(true)
string(17) jubianchi\Alias\A
Actual result:
bool(true)
string(1) A
bool(true)
string(17) jubianchi\Alias\A
bool(true)
string(60) ReflectionException: Class \jubianchi\Alias\B does not exist
bool(true)
string(17) jubianchi\Alias\A
As you can see, class_alias returns bool(true) as if everything went fine, so
we
expect the alias to be available but a reflection on the latter throws an
exception.
I think class_alias should be able to handle the leading backslashes or return
bool(false) if it can't.
[2012-04-18 06:11:21] ahar...@php.net
Description:
Aliasing namespaced classes currently expects that class names will be given in
the same form as the ZE uses internally; ie without a leading backslash. Since
that's inconsistent with the absolute form in PHP, it would be good if
class_alias() could also ignore a leading backslash.
Test script:
---
?php
namespace A;
class C { function foo() { echo 42\n; } }
namespace B;
class_alias('\A\C', '\B\C');
$c = new C;
$c-foo();
Expected result:
42
Actual result:
--
Fatal error: Class 'B\C' not found in /private/tmp/test.php on line 7
--
Edit this bug report at https://bugs.php.net/bug.php?id=61759edit=1
Bug #65562 [Opn-Fbk]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562edit=1 ID: 65562 Updated by: johan...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg -Status: Open +Status: Feedback Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Please provide compilable code showing the issue. In general: We don't consider issues which can't be triggered by userspace code as bug but expect extension authors to provide patches to improve PHP. Previous Comments: [2013-08-26 20:23:12] rrh at newrelic dot com Description: Function zend_parse_arg leaks memory, as discovered when I ran valgrind with php test cases designed to exercise a module we wrote. zend_parse_arg calls zend_parse_arg_impl. Unfortunately, not all control flow paths to the return in zend_parse_arg call efree to free up the memory allocated by zend_parse_arg_impl to hold the error string. In my case, quiet != 0, so the lone efree (which has 2 additional guards) is not called. -- Edit this bug report at https://bugs.php.net/bug.php?id=65562edit=1
Bug #65562 [Fbk]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562edit=1 ID: 65562 Updated by: johan...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg Status: Feedback Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: https://github.com/johannes/php-src/commit/3bfe148c83d6c9b4134ac4fc5f6e0ae36f3f2c42 This might fix your issue. As you won't be telling whether this is our problem I can't properly test it. I'd welcome if you could test it and in future help providing patches. Previous Comments: [2013-08-26 22:55:31] yohg...@php.net It should be by using ext_skel shell script. It should be easy by using ext_skel shell script. [2013-08-26 22:54:27] yohg...@php.net If you are certain, please provide short and complete module code that leaks memory. (i.e. full module code that compiles as module) It should be by using ext_skel shell script. [2013-08-26 21:21:52] rrh at newrelic dot com I didn't provide code to show the issue because the issue is almost certainly independent of my module extension, and a quick inspection of the code looking at the control flow paths would show that efree isn't called on all paths leading to a return from the function. [2013-08-26 20:53:04] johan...@php.net Please provide compilable code showing the issue. In general: We don't consider issues which can't be triggered by userspace code as bug but expect extension authors to provide patches to improve PHP. [2013-08-26 20:23:12] rrh at newrelic dot com Description: Function zend_parse_arg leaks memory, as discovered when I ran valgrind with php test cases designed to exercise a module we wrote. zend_parse_arg calls zend_parse_arg_impl. Unfortunately, not all control flow paths to the return in zend_parse_arg call efree to free up the memory allocated by zend_parse_arg_impl to hold the error string. In my case, quiet != 0, so the lone efree (which has 2 additional guards) is not called. -- Edit this bug report at https://bugs.php.net/bug.php?id=65562edit=1
Bug #65562 [Fbk]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562edit=1 ID: 65562 Updated by: johan...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg Status: Feedback Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: meant to write your problem :-) Previous Comments: [2013-08-26 23:01:42] johan...@php.net https://github.com/johannes/php-src/commit/3bfe148c83d6c9b4134ac4fc5f6e0ae36f3f2c42 This might fix your issue. As you won't be telling whether this is our problem I can't properly test it. I'd welcome if you could test it and in future help providing patches. [2013-08-26 22:55:31] yohg...@php.net It should be by using ext_skel shell script. It should be easy by using ext_skel shell script. [2013-08-26 22:54:27] yohg...@php.net If you are certain, please provide short and complete module code that leaks memory. (i.e. full module code that compiles as module) It should be by using ext_skel shell script. [2013-08-26 21:21:52] rrh at newrelic dot com I didn't provide code to show the issue because the issue is almost certainly independent of my module extension, and a quick inspection of the code looking at the control flow paths would show that efree isn't called on all paths leading to a return from the function. [2013-08-26 20:53:04] johan...@php.net Please provide compilable code showing the issue. In general: We don't consider issues which can't be triggered by userspace code as bug but expect extension authors to provide patches to improve PHP. 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=65562 -- Edit this bug report at https://bugs.php.net/bug.php?id=65562edit=1
Bug #65562 [Fbk-Opn]: memory leak in zend_parse_arg
Edit report at https://bugs.php.net/bug.php?id=65562edit=1 ID: 65562 Updated by: johan...@php.net Reported by:rrh at newrelic dot com Summary:memory leak in zend_parse_arg -Status: Feedback +Status: Open Type: Bug Package:Performance problem Operating System: all PHP Version:5.5.3 Block user comment: N Private report: N New Comment: A cleaner patch might pass the quiet argument to zend_parse_arg_impl, this would safe the allocation in there. This also seems to be limited to C and f modifiers which, in PHP itself, aren't used in combination with ZEND_PARSE_PARAMS_QUIET. So for adding a test we might need a deug-build-only functionin zend_builtin_functions.c. This might need coordination with docs and their function detection scripts. And sorry if I'm a bit harsh, but 99% of the internal API bugs we get are user errors and this bug was sparse on information. Previous Comments: [2013-08-26 23:14:26] s...@php.net Waiting feedback on the patch [2013-08-26 23:07:33] rrh at newrelic dot com I will test the patch, and in the future come up with patches for your review. [2013-08-26 23:02:38] yohg...@php.net I suspect you have pointer issue. Valgrind does not handle ***(pointer to pointer to pointer) well. Check your hash handling code carefully, it may help. [2013-08-26 23:02:10] johan...@php.net meant to write your problem :-) [2013-08-26 23:01:42] johan...@php.net https://github.com/johannes/php-src/commit/3bfe148c83d6c9b4134ac4fc5f6e0ae36f3f2c42 This might fix your issue. As you won't be telling whether this is our problem I can't properly test it. I'd welcome if you could test it and in future help providing patches. 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=65562 -- Edit this bug report at https://bugs.php.net/bug.php?id=65562edit=1
Bug #65533 [Csd-Nab]: Unterminated #ifndef in Zend/zend_language_parser.(h|c)
Edit report at https://bugs.php.net/bug.php?id=65533edit=1 ID: 65533 Updated by: johan...@php.net Reported by:fk at florian-kaiser dot net Summary:Unterminated #ifndef in Zend/zend_language_parser.(h|c) -Status: Closed +Status: Not a bug Type: Bug Package:Compile Failure Operating System: Debian 7 PHP Version:5.4.19 Block user comment: N Private report: N Previous Comments: [2013-08-25 10:25:09] fk at florian-kaiser dot net I must confess I wasnt thorough enough. You are right, the #endif that closes the first #ifndef is at the very last line of zend_language_parser. For some reason, I had old zend_language_parser.(h|c) files from the previous debian package in the directory that did not get overwritten. So, I close this bug since it is not a PHP bug at all. Sorry for the the inconvenience my lazy research caused. [2013-08-23 21:16:03] ahar...@php.net Those are correct as they are â they're header include guards with matching #endif statements at the end of the files. (They're also generated files that don't exist in Git.) How are you compiling this, exactly (ie what commands, are there any additional files to do with the packaging, etc)? [2013-08-23 11:30:59] fk at florian-kaiser dot net Description: When trying to compile the just released version 5.4.19 we get the following errors on make: /tmp/php5.4-5.4.18/Zend/zend_language_parser.h:33:0: error: unterminated #ifndef [ ... ] /tmp/php5.4-5.4.18/Zend/zend_language_parser.y:66:0: error: unterminated #ifndef make[1]: *** [Zend/zend_language_parser.lo] Error 1 The errors itself only seem to turn up using the debian packacking mechanisms, not for simple ./configure make. Still, the code clearly suffers from 2 missing closing tags for #ifdef, so I guess its not nescessarily reproducable. I attached a patch that adds both missing endifs. Expected result: Compile finishes without error. Actual result: -- Compile stops and errors out. -- Edit this bug report at https://bugs.php.net/bug.php?id=65533edit=1
Bug #65542 [Opn-Nab]: zend_parse_parameters return string length == 0
Edit report at https://bugs.php.net/bug.php?id=65542edit=1 ID: 65542 Updated by: johan...@php.net Reported by:Azq2 at ya dot ru Summary:zend_parse_parameters return string length == 0 -Status: Open +Status: Not a bug Type: Bug Package:Unknown/Other Function PHP Version:5.5.3 Block user comment: N Private report: N New Comment: String lengths in PHP are int not uint. Still 0 would be an unlikely result, but string length handling works in a few hundred other functions flawlessly so it's likely a bug in your code. As this is no support forum please take this somewhere else. (The pecl-dev list might be a good place if you share a bit more code) Previous Comments: [2013-08-24 21:06:30] azq2 at ya dot ru But... password and db - is ok. [2013-08-24 21:05:08] Azq2 at ya dot ru char *addr, *user, *password, *db, *connect_id = NULL, *socket = NULL, *host = NULL; uint addr_length, user_length, password_length, db_length, connect_id_length = 0; [2013-08-24 21:04:09] fel...@php.net I mean what data type have you used for addr_length and user_length in your C code. [2013-08-24 21:02:17] azq2 at ya dot ru String. $db - connect(127.0.0.2, root, qwerty, test, 1); [2013-08-24 20:59:51] fel...@php.net What data type have you used for store the string length? 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=65542 -- Edit this bug report at https://bugs.php.net/bug.php?id=65542edit=1
Bug #65542 [Nab]: zend_parse_parameters return string length == 0
Edit report at https://bugs.php.net/bug.php?id=65542edit=1
ID: 65542
Updated by: johan...@php.net
Reported by:Azq2 at ya dot ru
Summary:zend_parse_parameters return string length == 0
Status: Not a bug
Type: Bug
Package:Unknown/Other Function
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
Given that zend_parse_parameters work in about 3000 places in PHP and tons of
other extensions it is unlikely that this is the cause of the issue. Have you
run a memory checker (valgrind etc.)?
Unless there is compilable code which proves this is a PHP issue this is Not a
Bug.
As said: For support writing PHP extensions please write the pecl-dev list
(pecl-dev at lists.php.net), but that also requires compilable code for useful
help.
Previous Comments:
[2013-08-24 22:31:38] azq2 at ya dot ru
But if use zval - length works
[2013-08-24 21:58:02] Azq2 at ya dot ru
NOT, ITS BUG.
CODE:
PHP_METHOD(Mysql, connect) {
bool return_state = true;
bool persistent = false;
char *addr, *user, *password, *db, *connect_id = NULL, *socket = NULL,
*host = NULL;
int addr_length=0, user_length, password_length, db_length,
connect_id_length = 0;
uint socket_length = 0, host_length = 0;
unsigned short port = 0;
unsigned long flags = 0;
zval *object = getThis();
php_mysql_object *obj = (php_mysql_object
*)zend_object_store_get_object(object TSRMLS_CC);
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, l|bl, addr,
addr_length, user, user_length, password, password_length, db,
db_length,
port, persistent, flags) != SUCCESS)
WRONG_PARAM_COUNT;
printf(addr(%d) = %s\n, addr_length, addr);
printf(user(%d) = %s\n, user_length, user);
printf(password(%d) = %s\n, password_length, password);
printf(db(%d) = %s\n, db_length, db);
php code:
$db - connect(127.0.0.2, root, qwerty, test, 1);
Returns:
addr(0) = 127.0.0.2
user(0) = root
password(6) = qwerty
db(4) = test
[2013-08-24 21:33:05] johan...@php.net
String lengths in PHP are int not uint.
Still 0 would be an unlikely result, but string length handling works in a few
hundred other functions flawlessly so it's likely a bug in your code. As this
is no support forum please take this somewhere else. (The pecl-dev list might
be a good place if you share a bit more code)
[2013-08-24 21:06:30] azq2 at ya dot ru
But... password and db - is ok.
[2013-08-24 21:05:08] Azq2 at ya dot ru
char *addr, *user, *password, *db, *connect_id = NULL, *socket = NULL, *host =
NULL;
uint addr_length, user_length, password_length, db_length, connect_id_length =
0;
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=65542
--
Edit this bug report at https://bugs.php.net/bug.php?id=65542edit=1
Bug #65497 [Opn-Fbk]: All tests are failing
Edit report at https://bugs.php.net/bug.php?id=65497edit=1 ID: 65497 Updated by: johan...@php.net Reported by:cmbecker69 at gmx dot de Summary:All tests are failing -Status: Open +Status: Feedback Type: Bug Package:*Compile Issues Operating System: Cygwin PHP Version:5.5.2 Block user comment: N Private report: N New Comment: So you most likely have another php.ini which is loaded which tries to load a shared extension which fails. the test system is supposed to verify PHP wors with all *valid* configurations. check the ini files the test runner mentions at the top of the output under INI actual and More .INIs Previous Comments: [2013-08-22 14:43:36] cmbecker69 at gmx dot de Indeed it is an issue related to the php.ini. When I remove it or disable it for single tests with -n, most tests succeed (I'll send a report about the failing tests to the qa-reports list). According to README.TESTING [Which php.ini is used] it shouldn't matter which php.ini is used. But both php.ini-production as well as php.ini-development cause all tests to fail (error while loading shared libraries). However, no errors are reported when running PHP with either of both php.ini files. [2013-08-22 08:22:04] yohg...@php.net You might have linked with incompatible library. ldd php or ldd libphp5.so too see what are linked. It may happen during build also. I recently helped a user who had build problem due to libtool installed under /usr/local. Explicitly using proper libtool solved the problem. Look for suspicious errors in build log, too. [2013-08-22 05:50:07] s...@php.net This looks like some environment problem. PHP does not load its own shared libs, so whatever is going wrong is going wrong either in the compiler or in the environment. If you're getting this message with tests but not when you run either -v or -i, the difference may be either php.ini or some environment vars. [2013-08-21 22:40:37] cmbecker69 at gmx dot de For most development I'm using normal Windows builds, but for some experiments I prefer the Unix toolchain, so Cygwin comes in handy (I could use a virtual machine, but it seems a bit heavyweight). I should have noted in the first place that the compiled PHP seems to run fine; at least I haven't noticed any issues yet (neither CLI nor CGI). basic/001.out: /home/cmb/php-5.5.2/sapi/cli/php.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory The other .out files have the same message (I've checked only a handful, however). [2013-08-21 21:57:46] johan...@php.net Cygwin is a complicated platform, any reason you're not using normal Windows or some normal Unix/linux? That aside: There shouldn't be any dll's or so's being built. Can you please check the created .out / .diff files from the tests to see whether the report any specific error? If they run at all PHP can't be totally broken as the test runner is using PHP, too. I guess it is some php.ini related error. 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=65497 -- Edit this bug report at https://bugs.php.net/bug.php?id=65497edit=1
Sec Bug-Bug #65495 [Opn-Nab]: no validation of session cookie values
Edit report at https://bugs.php.net/bug.php?id=65495edit=1
ID: 65495
Updated by: johan...@php.net
Reported by:cmanley at xs4all dot nl
Summary:no validation of session cookie values
-Status: Open
+Status: Not a bug
-Type: Security
+Type: Bug
Package:Session related
Operating System: linux
PHP Version:5.4.18
Block user comment: N
Private report: Y
New Comment:
It is the job of the handler to validate session IDs. the default file handler
uses this whitelist:
for (p = key; (c = *p); p++) {
/* valid characters are a..z,A..Z,0..9 */
if (!((c = 'a' c = 'z')
|| (c = 'A' c = 'Z')
|| (c = '0' c = '9')
|| c == ','
|| c == '-')) {
ret = FAILURE;
break;
}
}
See
http://lxr.php.net/xref/PHP_TRUNK/ext/session/session.c#php_session_valid_key
Previous Comments:
[2013-08-21 13:49:03] cmanley at xs4all dot nl
Description:
PHP doesn't validate the session id cookie name. Hackers can manipulate it's
value
and try to overwrite non-session files in sites where custom file based session
handlers are used.
I use database based handlers, so it doesn't apply to me, but I was surprised
to
see that PHP let the cookie in that I manipulated.
Test script:
---
This is debugging from my session handler showing the methods called and
arguments with my illegal cookie value
'../../../../../../../../var/www/site.com/htdocs/index.php'
SessionManagerPDO::_open('/var/lib/php5', 'PHPSESSID')
SessionManagerPDO::_read('../../../../../../../../var/www/site.com/htdocs/index.php')
(returns empty string because it finds no row)
SessionManagerPDO::_write('../../../../../../../../var/www/site.com/htdocs/index.php',
[0 bytes, md5=d41d8cd98f00b204e9800998ecf8427e])
(attempts to insert new row into database, but dies because session_id field is
too wide)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65495edit=1
Bug #65495 [Nab]: no validation of session cookie values
Edit report at https://bugs.php.net/bug.php?id=65495edit=1
ID: 65495
Updated by: johan...@php.net
Reported by:cmanley at xs4all dot nl
Summary:no validation of session cookie values
Status: Not a bug
Type: Bug
Package:Session related
Operating System: linux
PHP Version:5.4.18
Block user comment: N
Private report: N
New Comment:
It is an interoperability feature that the session functionality is open. You
can use a custom save-handler and serialization handler (like wddx) to share
session data with non-PHP systems. Enforcing stricter checks might limit this
interoperability, especially as a general check must be very restrictive.
An option might be to have the general check optional, but then we still have
to do double checking in the default handlers in order to be always secure.
Previous Comments:
[2013-08-21 14:22:59] cmanley at xs4all dot nl
Thanks.
Is it possible to add this to the PHP Validate filters?
That way a whole lot of PHP programmers (and noobs) won't have to reinvent the
validation wheel, if they perform any validating at all.
I'm busy making a stricter validation filter that also takes into account the
values of session.hash_function and session.hash_bits_per_character.
[2013-08-21 14:18:34] johan...@php.net
It is the job of the handler to validate session IDs. the default file handler
uses this whitelist:
for (p = key; (c = *p); p++) {
/* valid characters are a..z,A..Z,0..9 */
if (!((c = 'a' c = 'z')
|| (c = 'A' c = 'Z')
|| (c = '0' c = '9')
|| c == ','
|| c == '-')) {
ret = FAILURE;
break;
}
}
See
http://lxr.php.net/xref/PHP_TRUNK/ext/session/session.c#php_session_valid_key
[2013-08-21 13:49:03] cmanley at xs4all dot nl
Description:
PHP doesn't validate the session id cookie name. Hackers can manipulate it's
value
and try to overwrite non-session files in sites where custom file based session
handlers are used.
I use database based handlers, so it doesn't apply to me, but I was surprised
to
see that PHP let the cookie in that I manipulated.
Test script:
---
This is debugging from my session handler showing the methods called and
arguments with my illegal cookie value
'../../../../../../../../var/www/site.com/htdocs/index.php'
SessionManagerPDO::_open('/var/lib/php5', 'PHPSESSID')
SessionManagerPDO::_read('../../../../../../../../var/www/site.com/htdocs/index.php')
(returns empty string because it finds no row)
SessionManagerPDO::_write('../../../../../../../../var/www/site.com/htdocs/index.php',
[0 bytes, md5=d41d8cd98f00b204e9800998ecf8427e])
(attempts to insert new row into database, but dies because session_id field is
too wide)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65495edit=1
Bug #65497 [Opn-Fbk]: All tests are failing
Edit report at https://bugs.php.net/bug.php?id=65497edit=1 ID: 65497 Updated by: johan...@php.net Reported by:cmbecker69 at gmx dot de Summary:All tests are failing -Status: Open +Status: Feedback Type: Bug Package:Testing related Operating System: Cygwin PHP Version:5.5.2 Block user comment: N Private report: N New Comment: Cygwin is a complicated platform, any reason you're not using normal Windows or some normal Unix/linux? That aside: There shouldn't be any dll's or so's being built. Can you please check the created .out / .diff files from the tests to see whether the report any specific error? If they run at all PHP can't be totally broken as the test runner is using PHP, too. I guess it is some php.ini related error. Previous Comments: [2013-08-21 21:38:01] cmbecker69 at gmx dot de Description: After compiling PHP 5.5.2 on Cygwin[1] all tests of the accompanying test suite are failing. This might be related to the shared libraries, which don't seem to be properly build on Cygwin (.so instead of .dll.a, with a filesize of less than 1 KB). [1] $ uname -a CYGWIN_NT-5.1 RELIANT 1.7.18(0.263/5/3) 2013-04-19 10:39 i686 Cygwin Test script: --- ./configure --enable-opcache=no make make test Expected result: The tests succeed. Actual result: -- All tests fail. -- Edit this bug report at https://bugs.php.net/bug.php?id=65497edit=1
Bug #65485 [Opn-Nab]: Cast gives different values in one way or the other
Edit report at https://bugs.php.net/bug.php?id=65485edit=1 ID: 65485 Updated by: johan...@php.net Reported by:stephane at it-asia dot com Summary:Cast gives different values in one way or the other -Status: Open +Status: Not a bug Type: Bug Package:*General Issues Operating System: Windows 8 Mint Maya PHP Version:5.4.18 Block user comment: N Private report: N New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is, read this: http://www.floating-point-gui.de/ Thank you for your interest in PHP. Casting to string will be imprecise, then doing cast to int will be imprecise again. Two imprecisions increase the difference. Previous Comments: [2013-08-20 08:50:20] stephane at it-asia dot com Description: I have different value when I cast a double to int and when I cast to string before casting to int. I understand 39.48 is difficult to store in base 2. The problem is the cast algorythm is not the same if you cast a float to int or if you cast a float to string, This involves huges mistakes in accountancy software. Whatever the way you choose (float - int or float - string - int ) , you should have the same result at the end. Please define the right way to process data in that case. I have the same problem with almost every machines, Windows or Debian based. Thanks ! Test script: --- $d = 39.48 * 100; print(39.48 * 100 : ); var_dump ($d); $i = (int) $d; print(br /int: ); var_dump ($i); $s = (string) $d; print(br /string: ); var_dump ($s); $i = (int) $s; print(br /int: ); var_dump ($i); Expected result: same value if you cast double = int and if you cast double = string = int Actual result: -- 39.48 * 100 : double(3948) int: int(3947) string: string(4) 3948 int: int(3948) -- Edit this bug report at https://bugs.php.net/bug.php?id=65485edit=1
Bug #65362 [Opn-Nab]: strcmp null return missing from docs.
Edit report at https://bugs.php.net/bug.php?id=65362edit=1
ID: 65362
Updated by: johan...@php.net
Reported by:atli dot jonsson at ymail dot com
Summary:strcmp null return missing from docs.
-Status: Open
+Status: Not a bug
Type: Bug
Package:Scripting Engine problem
PHP Version:5.5.1
Block user comment: N
Private report: N
New Comment:
This is common PHP behavior and documented in a note here:
http://php.net/functions.internal
Previous Comments:
[2013-08-18 07:54:39] yohg...@php.net
Other functions such as strlen()/strncmp()/etc return null.
I'm not sure the best behavior, but E_NOTICE/E_WARNING for invalid parameters
are
preferred.
[2013-08-18 07:50:51] yohg...@php.net
I changed bug type since this is in Zend/zend_builtin_functions.c.
Shouldn't it raise error for arrays? Currently, it simply returned.
/* {{{ proto int strcmp(string str1, string str2)
Binary safe string comparison */
ZEND_FUNCTION(strcmp)
{
char *s1, *s2;
int s1_len, s2_len;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, ss, s1, s1_len,
s2, s2_len) == FAILURE) {
return;
}
RETURN_LONG(zend_binary_strcmp(s1, s1_len, s2, s2_len));
}
/* }}} */
[2013-07-30 23:36:30] atli dot jonsson at ymail dot com
Description:
strcmp, strncmp, strcasecmp and strncasecmp will all return NULL when either
string parameter is of a type that is invalid for string conversions, like
Arrays,
Objects and Resources.
However, the docs make no mention of this fact. (Aside from a comment.) As the
0
value returned for equal strings, and NULL returned for invalid comparisons,
are
equal when compared in a non-strict manner, this can lead to unexpected
behaviour.
There is a warning issued, but without clarification the above is still in no
way
obvious.
Test script:
---
?php
$arr = [];
$str = PHP is awesome!;
if (strcmp($arr, $str) == 0) {
echo Equal!; // Ends up here.
}
else {
echo Not equal!;
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=65362edit=1
Bug #65455 [Opn-Ana]: in Unknown on line 0
Edit report at https://bugs.php.net/bug.php?id=65455edit=1 ID: 65455 Updated by: johan...@php.net Reported by:spam2 at rhsoft dot net Summary:in Unknown on line 0 -Status: Open +Status: Analyzed Type: Bug Package:Scripting Engine problem PHP Version:5.4.17 Block user comment: N Private report: N New Comment: The error is triggered in shutdown when the user didn't clear errors by checking imap_errors(). http://lxr.php.net/xref/PHP_TRUNK/ext/imap/php_imap.c#1073 I think we could simply free the errors and be silent in this case. Users who care about errors can call imap_errors(). Previous Comments: [2013-08-15 11:25:29] spam2 at rhsoft dot net Description: $response = imap_fetch_overview($mbox, $range); Notice: Unknown: Sequence out of range (errflg=2) in Unknown on line 0 this is the same crap as https://bugs.php.net/bug.php?id=65359 and now do not tell me like in the othe rbugreport there is no script running and nobody knows file / line of the call -- Edit this bug report at https://bugs.php.net/bug.php?id=65455edit=1
Bug #65443 [Opn-Fbk]: class_exists with $autoload=true raising fatal error
Edit report at https://bugs.php.net/bug.php?id=65443edit=1
ID: 65443
Updated by: johan...@php.net
Reported by:pieczar92 at interia dot pl
Summary:class_exists with $autoload=true raising fatal error
-Status: Open
+Status: Feedback
Type: Bug
Package:PHP options/info functions
Operating System: Windows 8
PHP Version:5.4.17
Block user comment: N
Private report: N
Previous Comments:
[2013-08-13 19:48:53] requi...@php.net
Ticket renamed.
Test scripts need to be stand-alone and executable with a simple copy and paste
on our part. What you've posted requires a $gravatarURL and, to
reproduce your results, an autoloader.
You are using an autoloader, correct? Yours is deriving a filename and
immediately require or require_once-ing it. That is incorrect: it must
check if the file even exists first.
Make that change to your autoloader and use $autoload=true in your call to
class_exists(). If that does not fix the problem then please post a
COMPLETE test script that can be run by itself without using any undefined
variables or external autoloaders.
[2013-08-13 19:02:15] pieczar92 at interia dot pl
Description:
Welcome.
My report is related to the function:
bool class_exists (string $ class_name [, bool $ autoload = true])
Namely, I have noticed that if the result of the function returns false, the
script crashes mistake, because after all, the script tries to load a non-
existent class. Problem solved by changing the parameter $ autoload to false.
I believe that the $ autoload should be taken into account only if the result
of
the function will amount to true.
I'm sorry for syntax errors. My text was translated Google tools - translation.
Regards,
Kamil Piechaczek
Test script:
---
if( class_exists('finfo', false) ) {
$fInfo = new finfo(FILEINFO_MIME);
$gravatarImageMime = $fInfo-file($gravatarURL, FILEINFO_MIME_TYPE);
} else {
$gravatarImage = getimagesize($gravatarURL);
$gravatarImageMime = $gravatarImage['mime'];
}
Expected result:
Variable $gravatarImageMime should has type mime of file.
Actual result:
--
White screen (autoload can't find file)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65443edit=1
Bug #65445 [Opn-Fbk]: filesize() fails for files with high inode number
Edit report at https://bugs.php.net/bug.php?id=65445edit=1
ID: 65445
Updated by: johan...@php.net
Reported by:michal at michal dot waw dot pl
Summary:filesize() fails for files with high inode number
-Status: Open
+Status: Feedback
Type: Bug
Package:Filesystem function related
Operating System: Linux
PHP Version:5.5.1
Block user comment: N
Private report: N
New Comment:
Are you using a 32 or 64 it system?
Could you please run the following on command line to see whether the syscall
for stat succeeds or fails so we can narrow the search:
$ strace php -nr 'filesize(DSC_5196_fx-1553725666.JPG);'
The relevant output is towards the end something like
stat(DSC_5196_fx-1553725666.JPG, 0x7fff38d27f80) = -1 ENOENT (No such file or
directory)
write(1, \nWarning: filesize(): stat faile..., 96
or
stat(DSC_5196_fx-1553725666.JPG, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
thanks.
Previous Comments:
[2013-08-13 20:27:21] michal at michal dot waw dot pl
Description:
I have a file for which filesize() can't return value. stat result for this
file:
Original file:
File: 'DSC_5196_fx-1553725666.JPG'
Size: 1907383 Blocks: 3728 IO Block: 4096 regular file
Device: 803h/2051d Inode: 5905591363 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 51/http) Gid: ( 51/http)
Access: 2013-08-13 00:47:28.107477918 +0200
Modify: 2013-08-12 21:38:27.219913208 +0200
Change: 2013-08-13 00:47:08.931478654 +0200
Birth: -
I've made an exact copy, in same dir, same permissions:
Copy:
File: 'DSC_5196_fx-1553725666_X.JPG'
Size: 1907383 Blocks: 3728 IO Block: 4096 regular file
Device: 803h/2051d Inode: 144 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 51/http) Gid: ( 51/http)
Access: 2013-08-13 00:45:48.0 +0200
Modify: 2013-08-12 21:38:27.0 +0200
Change: 2013-08-13 00:47:28.199477914 +0200
Birth: -
filesize() works for this new file.
I can't find any other difference between these two files.
I checked that filesize() works for files with inode number less or equal to
4126207367and doesn't work for files with inode number equal or greater than
4358705632. I didn't find files with inode number in between but I'm still
looking.
To me it seems that filesize() has problem with inode number higher than 2^32.
Test script:
---
html
body
pre
?
$f1 =
'/home/services/httpd/html.galeria.michal.waw.pl/gallery/var/albums/988_Rok-2013/Sobota/DSC_5196_fx-1553725666.JPG';
$f2 =
'/home/services/httpd/html.galeria.michal.waw.pl/gallery/var/albums/988_Rok-2013/Sobota/DSC_5196_fx-1553725666_X.JPG';
print $f1.: .filesize($f1).\n;
print $f2.: .filesize($f2).\n;
?
/pre
/body
/html
Expected result:
I expected to see sizes of both files.
Actual result:
--
Warning: filesize(): stat failed for
/home/services/httpd/html.galeria.XXX/gallery/var/albums/988_Rok-2013/333_Rydzewo-04-06.08.2013/Sobota/DSC_5196_fx-1553725666.JPG
in /home/services/httpd/html.galeria.michal.waw.pl/gallery3-3.0.x/test.php on
line 13
/home/services/httpd/html.galeria.XXX/gallery/var/albums/988_Rok-2013/333_Rydzewo-04-06.08.2013/Sobota/DSC_5196_fx-1553725666.JPG:
/home/services/httpd/html.galeria.XXX/gallery/var/albums/988_Rok-2013/333_Rydzewo-04-06.08.2013/Sobota/DSC_5196_fx-1553725666_X.JPG:
1907383
--
Edit this bug report at https://bugs.php.net/bug.php?id=65445edit=1
Bug #65437 [Opn-Nab]: Cannot redeclare function alerts only when is used
Edit report at https://bugs.php.net/bug.php?id=65437edit=1
ID: 65437
Updated by: johan...@php.net
Reported by:joni2back at gmail dot com
Summary:Cannot redeclare function alerts only when is used
-Status: Open
+Status: Not a bug
Type: Bug
Package:Reproducible crash
Operating System: Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You can define functions conditionally in PHP:
?php
function a() {
function b() {}
}
var_dump(function_exists('b'));
a();
var_dump(function_exists('b'));
?
bool(false)
bool(true)
Previous Comments:
[2013-08-12 12:38:04] joni2back at gmail dot com
Description:
PHP throws fatal error only when the duplicate function is called.
Test script:
---
Fatal error:
function php()
{
function php()
{
}
}
php();
**
Nothing:
function php()
{
function php()
{
}
}
Expected result:
PHP should notify this problem (duplicate function) regardless the explicit
call
of the function
Actual result:
--
PHP does not notify if the duplicate function is not used
--
Edit this bug report at https://bugs.php.net/bug.php?id=65437edit=1
Bug #65359 [Asn]: Unknown: Skipping numeric key 1 in Unknown on line 0
Edit report at https://bugs.php.net/bug.php?id=65359edit=1 ID: 65359 Updated by: johan...@php.net Reported by:spam2 at rhsoft dot net Summary:Unknown: Skipping numeric key 1 in Unknown on line 0 Status: Assigned Type: Bug Package:Session related PHP Version:5.4.17 Assigned To:yohgaki Block user comment: N Private report: N New Comment: We don't have a reliable REQUEST_URI or such available. We only have the version in $_SERVER which might be changed by the user. In shutdown we also have no idea of what might have been the main script - a SAPI can execute multiple files in a row (as auto_[ap|pre]pend_file do), apache_filter is an example. A way to improve the error might be saving the place where a session is started, while that costs a tiny bit of memory and CPU. Previous Comments: [2013-08-10 21:02:33] spam2 at rhsoft dot net This is not feasible option. If PHP should detect invalid session data assignment, PHP should monitor every writes to variable WTF - nobody needs to monitor anything to know the script which is called - the design flaw is that this information well known as long the script is running is *thrown away* before the last possible event triggering an error and over years nobody spent a second to fix this Anyway, I may be able to add REQUEST_URI to the error. Do you want it? that is what i request all the time It can be retrieved via custom error handler, though. not a option in case of *600* vhosts Another feasible option for you is that define user error handler that ignores this error another option would be fix PHP's internal error handler that it shuts up in case it has nothing useful to say [2013-08-10 20:50:36] yohg...@php.net so again: we do not need a *incompatible* new session handler, we need proper error-reporting and in unknown is always a *major bug* and design flaw This is not feasible option. If PHP should detect invalid session data assignment, PHP should monitor every writes to variable, not only $_SESSION array, during execution only for register_globals limited serialize handler. There is no such API in PHP. If we made it, it slows down PHP and nobody is willing to do. (Technically, Zend engine provides handler for assignment. By using the API, anyone can make a module that detects invalid writes to $_SESSION) It seems current documentation does not state that users are not able to save numeric index session vars (and other special chars). However, older documents explicitly states numeric session vars are prohibited/unsupported. It's our document bug, but this is the way it supposed to work. Therefore, correct way of fixing this *major bug* and design flaw is introducing new serialize handler that is *not* bonded to register_globals. Anyway, I may be able to add REQUEST_URI to the error. Do you want it? It can be retrieved via custom error handler, though. Another feasible option for you is that define user error handler that ignores this error. Since we are not going to add new serialize handler to released branch, it would be most feasible option for you. Or write your own module that monitor assignments and raise error for invalid. [2013-08-10 10:53:36] spam2 at rhsoft dot net yes it is *saved* after script execution but that is no excuse not store the script path and throw it out in the error message so someone knows which of the some hundret thousands scripts on the server is triggering the error to debug whatever application so again: we do not need a *incompatible* new session handler, we need proper error-reporting and in unknown is always a *major bug* and design flaw [2013-08-10 10:45:47] yohg...@php.net Assigning numeric array index valid operation while it was not valid to have numeric variable names. That's the reason why old serializer do not allow to save such data. Session data is usually saved *after* scripts execution. My patch should be able to applied to PHP 5.4 cleanly. If you want it to be fixed seriously, apply my patch and use php_serialize. Beware that it won't work if you mix serializers on shared session data. [2013-08-10 10:34:43] spam2 at rhsoft dot net yeah, introduce new things and let the broken untouched broken is the way of PHP which leaded to all the troubles over the last 10 years - hence the real bug is that the info wich script was called is thrown away before the error_handler is raised and burry this problem with a new session_handler does not solve it *there must not* be any
Bug #65423 [Opn-Fbk]: Configure error with opcache and mcrypt
Edit report at https://bugs.php.net/bug.php?id=65423edit=1 ID: 65423 Updated by: johan...@php.net Reported by:vasilis at vatsos dot gr Summary:Configure error with opcache and mcrypt -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: CentOS release 6.2 (Final) PHP Version:5.5.1 Block user comment: N Private report: N New Comment: I can't reproduce locally. Please check your config.log file. Somewhere towards the end (above the lng list of variable declarations) there should be a some line with checking for known struct flock definition and then a small C program, the way it was compiled and a more verbose error message. Please provide this. Previous Comments: [2013-08-09 07:06:19] vasilis at vatsos dot gr Description: When you try to configure php with mcrypt, i get the Don't know how to define struct flock on this system. If i remove it, if finishes ok Test script: --- ./configure '--with-libdir=lib64' '--cache-file=../config.cache' '--prefix=/usr/local/php551' '--with-config-file-path=/usr/local/php551/etc' '--disable-debug' '--with-pic' '--disable-rpath' '--enable-fastcgi' '--with-bz2' '--with-curl' '--with-freetype-dir=/usr/local/php551' '--with-png-dir=/usr/local/php551' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr/local/php551' '--with-openssl' '--with-pspell' '--with-pcre-regex' '--with-zlib' '--enable-exif' '--enable-ftp' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-wddx' '--with-kerberos' '--with-unixODBC=/usr' '--enable-shmop' '--enable-calendar' '--without-sqlite3' '--with-libxml-dir=/usr/local/php551' '--enable-pcntl' '--with-imap' '--with-imap-ssl' '--enable-mbstring' '--enable-mbregex' '--with-gd' '--enable-bcmath' '--with-xmlrpc' '--with-ldap' '--with-ldap-sasl' '--with-mysql=/usr' '--with-mysqli' '--with-snmp' '--enable-soap' '--w ith-xsl' '--enable-xmlreader' '--enable-xmlwriter' '--enable-pdo' '--with-pdo-mysql' '--with-pdo-pgsql' '--with-pear=/usr/local/php551/pear' '--with-mcrypt' '--enable-intl' '--without-pdo-sqlite' '--with-config-file-scan-dir=/usr/local/php551/php.d' Expected result: To finish configure Actual result: -- checking for mmap() using MAP_ANON shared memory support... no checking for mmap() using /dev/zero shared memory support... no checking for mmap() using shm_open() shared memory support... no checking for mmap() using regular file shared memory support... no checking for known struct flock definition... configure: error: Don't know how to define struct flock on this system, set --enable-opcache=no -- Edit this bug report at https://bugs.php.net/bug.php?id=65423edit=1
Bug #65409 [Opn-Nab]: php.ini weird problem
Edit report at https://bugs.php.net/bug.php?id=65409edit=1 ID: 65409 Updated by: johan...@php.net Reported by:ionut_ionut_1987 at yahoo dot com Summary:php.ini weird problem -Status: Open +Status: Not a bug Type: Bug Package:*Configuration Issues Operating System: arch linux PHP Version:5.4.17 Block user comment: N Private report: N New Comment: You are trying to run php.ini like a php script, this won't work. See php -h for options and the docs etc. Previous Comments: [2013-08-07 08:16:29] ionut_ionut_1987 at yahoo dot com Description: On cli after the command sudo php /etc/php/php.ini the output: PHP Parse error: syntax error, unexpected 'and' (T_LOGICAL_AND) in /etc/php/php.ini on line 202 Parse error: syntax error, unexpected 'and' (T_LOGICAL_AND) in /etc/php/php.ini on line 202 Line 202 is just a comment -- Edit this bug report at https://bugs.php.net/bug.php?id=65409edit=1
Bug #65411 [Opn-Nab]: die() don't terminate the current script if mysqli::query use MYSQLI_USE_RESULT
Edit report at https://bugs.php.net/bug.php?id=65411edit=1
ID: 65411
Updated by: johan...@php.net
Reported by:tecdoc at ukr dot net
Summary:die() don't terminate the current script if
mysqli::query use MYSQLI_USE_RESULT
-Status: Open
+Status: Not a bug
Type: Bug
Package:MySQLi related
Operating System: Windows 7 32bit
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
After fixing the error and escaping the ' in the die call
die('why don\'t terminated script?');
the script works as expected. I don't now what effect you see as not
terminating
Previous Comments:
[2013-08-07 08:55:40] tecdoc at ukr dot net
Description:
Tested on PHP version is 5.4.16 and 5.3.13
die() don't terminate the current script when mysqli::query use
MYSQLI_USE_RESULT
---
From manual page: http://www.php.net/mysqli.query#refsect1-mysqli.query-seealso
---
Test script:
---
$mysqli = new mysqli('localhost', 'root', '', 'db1');
if (!$mysqli-set_charset(utf8))
die('Set Charset Error: ' . $mysqli-error);
// tab - it is a table that have more than 3 000 000 rows
$q = SELECT * FROM tab1;
// open query and try close all
$result = $mysqli-query($q, MYSQLI_USE_RESULT);
$result-free();
$mysqli-close();
die('why don't terminated script?');
// this end of script don't terminate also
$result = $mysqli-query($q, MYSQLI_USE_RESULT);
$result-free();
$thread = $mysqli-thread_id;
$mysqli-kill($thread);
$mysqli-close();
die('why don't terminated script?');
--
Edit this bug report at https://bugs.php.net/bug.php?id=65411edit=1
Bug #65411 [Nab]: die() don't terminate the current script if mysqli::query use MYSQLI_USE_RESULT
Edit report at https://bugs.php.net/bug.php?id=65411edit=1
ID: 65411
Updated by: johan...@php.net
Reported by:tecdoc at ukr dot net
Summary:die() don't terminate the current script if
mysqli::query use MYSQLI_USE_RESULT
Status: Not a bug
Type: Bug
Package:MySQLi related
Operating System: Windows 7 32bit
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Why do you request lots of data if you don't use it?
Previous Comments:
[2013-08-07 11:59:49] tecdoc at ukr dot net
because you do script on table with small count of rows
do you try did script when table have more than 3 000 000 rows?
[2013-08-07 10:04:14] johan...@php.net
After fixing the error and escaping the ' in the die call
die('why don\'t terminated script?');
the script works as expected. I don't now what effect you see as not
terminating
[2013-08-07 08:55:40] tecdoc at ukr dot net
Description:
Tested on PHP version is 5.4.16 and 5.3.13
die() don't terminate the current script when mysqli::query use
MYSQLI_USE_RESULT
---
From manual page: http://www.php.net/mysqli.query#refsect1-mysqli.query-seealso
---
Test script:
---
$mysqli = new mysqli('localhost', 'root', '', 'db1');
if (!$mysqli-set_charset(utf8))
die('Set Charset Error: ' . $mysqli-error);
// tab - it is a table that have more than 3 000 000 rows
$q = SELECT * FROM tab1;
// open query and try close all
$result = $mysqli-query($q, MYSQLI_USE_RESULT);
$result-free();
$mysqli-close();
die('why don't terminated script?');
// this end of script don't terminate also
$result = $mysqli-query($q, MYSQLI_USE_RESULT);
$result-free();
$thread = $mysqli-thread_id;
$mysqli-kill($thread);
$mysqli-close();
die('why don't terminated script?');
--
Edit this bug report at https://bugs.php.net/bug.php?id=65411edit=1
Bug #65404 [Opn-Nab]: OO with screen of death
Edit report at https://bugs.php.net/bug.php?id=65404edit=1
ID: 65404
Updated by: johan...@php.net
Reported by:info at djdb dot be
Summary:OO with screen of death
-Status: Open
+Status: Not a bug
Type: Bug
Package:Output Control
Operating System: win (irrelevant)
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Variables can be reassigned.
Previous Comments:
[2013-08-06 13:34:19] info at djdb dot be
Description:
file--1
$myobject = new object1();
class object1{
...
}
file--2
$myobject = new object2();
include(file--1)
class object2{
...
}
so the name of variable of instanties arr the same but no error message is write
so i was many time watching wat there was wrong (the file was to big to place
them here)
Test script:
---
file--1
$myobject = new object1();
class object1{
...
}
file--2
$myobject = new object2();
include(file--1)
class object2{
...
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=65404edit=1
Bug #65376 [Nab]: Unserialize function issue
Edit report at https://bugs.php.net/bug.php?id=65376edit=1 ID: 65376 Updated by: johan...@php.net Reported by:carlosV2 dot 0 at gmail dot com Summary:Unserialize function issue Status: Not a bug Type: Bug Package:*General Issues Operating System: Mac OS X PHP Version:Irrelevant Block user comment: N Private report: N New Comment: This is a feature we(at least on internal C level) use in different places on purpose. This feature won't be changed. Previous Comments: [2013-08-03 12:28:46] anon at anon dot anon @mike Did you just dismiss a feature request as Not a bug? Of course it's not a bug, it's a feature request. [2013-08-02 11:20:20] m...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. . [2013-08-02 08:27:35] carlosV2 dot 0 at gmail dot com Description: I think the unserialize method should have a final string length check. You can make objects disappear just running the code in the Test Script: This code outputs just the first object. This is something it can easily happend when you are working with sockets or data streams. Probably it is the developer's fault but actually to serialized objects together are not only one object. I think checking the string length at the end of the parser and rising a warning is enough to alert the developer that this things are happening. Test script: --- $o1 = new stdClass(); $o1-name = 'Object1'; $o2 = new stdClass(); $o2-name = 'Object2'; $objects = serialize($o1) . serialize($o2); print_r(unserialize($objects)); Expected result: A warning Actual result: -- Only the first object: stdClass Object ( [name] = Object1 ) -- Edit this bug report at https://bugs.php.net/bug.php?id=65376edit=1
Bug #65357 [Opn]: get_object_vars behavior changed unexpected after version upgrade from php 5.3
Edit report at https://bugs.php.net/bug.php?id=65357edit=1
ID: 65357
Updated by: johan...@php.net
Reported by:phpbugreport at darkaura dot de
Summary:get_object_vars behavior changed unexpected after
version upgrade from php 5.3
Status: Open
Type: Bug
Package:Reflection related
PHP Version:5.4.17
Block user comment: N
Private report: N
New Comment:
This is a effect of making $this available in closures. This example might be
added to the documentation.
Previous Comments:
[2013-07-30 09:43:21] phpbugreport at darkaura dot de
in the example the line should be:
return $analyse($this);
[2013-07-30 09:40:34] phpbugreport at darkaura dot de
Description:
---
From manual page: http://www.php.net/function.get-object-vars
---
get_object_vars exposes more than it should if you wrap it in a closure.
Not only $this but every variable pointing to the object the closure is in is
put
in a state where the prototected and private variables can be read.
Test script:
---
?php
class Example
{
public $publicSetting = 'public';
protected $protectedSetting = 'protected';
private $privateSetting = 'private';
public function showEverything()
{
return get_object_vars($this);
}
public function showMyPublicsOnly()
{
$analyse = function($object) {
return get_object_vars($object);
};
return $analyse($object);
}
}
$example = new Example();
Expected result:
$example-showMyPublicsOnly() //Outputs array('publicSetting' = 'public');
Actual result:
--
//PHP 5.3
$example-showMyPublicsOnly() //Outputs array('publicSetting' = 'public');
//PHP 5.4 and up
$example-showMyPublicsOnly() //Outputs array('publicSetting' = 'public',
'protectedSetting' = 'protected', 'privateSetting' = 'private');
This change is not mentioned on the manual page.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65357edit=1
Bug #65359 [Opn]: Unknown: Skipping numeric key 1 in Unknown on line 0
Edit report at https://bugs.php.net/bug.php?id=65359edit=1 ID: 65359 Updated by: johan...@php.net Reported by:spam2 at rhsoft dot net Summary:Unknown: Skipping numeric key 1 in Unknown on line 0 Status: Open Type: Bug -Package:Scripting Engine problem +Package:Session related PHP Version:5.4.17 Block user comment: N Private report: N New Comment: This error happens while encoding the session after request end, so there's no active script anymore. Not sure we can make it more verbose. Previous Comments: [2013-07-30 11:35:52] spam2 at rhsoft dot net Description: PHP Notice: Unknown: Skipping numeric key 1 in Unknown on line 0 it is ridiculous that PHP is thowing warnings and does not know at least the realpath of the executed script to choose one of the 600 possible involved vhosts -- Edit this bug report at https://bugs.php.net/bug.php?id=65359edit=1
Bug #65337 [Opn-Dup]: Segmentation Fault in _zend_mm_free_int using mysqlnd
Edit report at https://bugs.php.net/bug.php?id=65337edit=1
ID: 65337
Updated by: johan...@php.net
Reported by:pool at unimca dot com
Summary:Segmentation Fault in _zend_mm_free_int using
mysqlnd
-Status: Open
+Status: Duplicate
Type: Bug
Package:Reproducible crash
Operating System: Linux Debian Wheezy amd64
PHP Version:5.4.17
Block user comment: N
Private report: N
New Comment:
Already fixed in this commit:
https://github.com/php/php-src/commit/9fc38183b707341b6eddb8c196d0ea2b7c13d6a9
Previous Comments:
[2013-07-28 13:34:55] pool at unimca dot com
Error also occurs with integer key:
CREATE TABLE `testTable` (
`id` int auto_increment,
`content` varchar(30) NOT NULL,
PRIMARY KEY (`id`)
);
[2013-07-25 16:35:01] pool at unimca dot com
Description:
I get recurring (script to reproduce attached) segmentation faults. Both PHP
5.4.17 and 5.4.4.
When I query mySQL using:
- mysqli
- mysqlnd (native driver)
- prepared statements
- specific number o parameters
For me a number of parameters in the provided script of 1923-2033 produce the
error. A number below or above works fine. The numbers might vary from system
to system (I don't know). To take this into account, I made the script loop
with different numbers of parameters.
The Apache2 log reports: [notice] child pid 30414 exit signal Segmentation
fault (11)
I get the same error when using PDO and prepared statements (with real prepared
statements, ATTR_EMULATE_PREPARES = false).
I compiled PHP 5.4.17 myself (I'm not experienced in doing so). PHP 5.4.4 was
out of the box.
Both use mysqlnd in what seems to be the same version 5.0.10 ((?) according to
phpinfo()).
mySQL is out of the box wheezy: is Ver 14.14 Distrib 5.5.31, for
debian-linux-gnu (x86_64) using readline 6.2. Using InnoDB
Debian Wheezy is: 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux
Can anyone confirm that this is not specific to my machine/installation ?
Test script:
---
?php
/*
CREATE DATABASE testDatabase
CHARACTER SET utf8
DEFAULT CHARACTER SET utf8
COLLATE utf8_general_ci
DEFAULT COLLATE utf8_general_ci;
USE testDatabase;
SET NAMES 'utf8';
GRANT CREATE, ALTER, INDEX, DROP, CREATE TEMPORARY TABLES, SELECT, INSERT,
UPDATE, DELETE ON testDatabase.* TO 'testUser'@'localhost' IDENTIFIED BY
'testPassword';
GRANT CREATE, ALTER, INDEX, DROP, CREATE TEMPORARY TABLES, SELECT, INSERT,
UPDATE, DELETE ON testDatabase.* TO 'testUser'@'localhost.localdomain'
IDENTIFIED BY 'testPassword';
FLUSH PRIVILEGES;
CREATE TABLE `testTable` (
`testField` binary(16) NOT NULL,
`content` varchar(30) NOT NULL,
PRIMARY KEY (`testField`)
);
*/
for($j=2;$j65000;$j++)
{
$arBind = array();
$sBind = '';
for($i=0;$i$j;$i++) //$j = number parameters for prepared statement
{
$sBind .= 's';
$arBind[] = '';
}
echo 'brGoing to probe number of parameters: ' . count($arBind);
ob_flush(); //print it to browser right away, not required for script
flush();//print it to browser right away, not required for script
//Constructing the query
$query = 'SELECT * from testTable WHERE testField IN(unhex(?)';
$questionMarksMinus1 = count($arBind) - 1; //1 questionmark already set in query
for($i=1;$i=$questionMarksMinus1;$i++)
{
$query .= ',unhex(?)';
}
$query .= ')';
$mysqliConn= mysqli_connect('127.0.0.1', 'testUser', 'testPassword');
$mysqliConn-select_db('testDatabase');
$mysqliSTMT = $mysqliConn-stmt_init();
$mysqliSTMT-prepare($query);
array_unshift($arBind,$sBind); //add the type string to the beginning of the
array
$arBindRef = array(); //bind the parameters. bind_param expects references and
not values - making new reference array
foreach($arBind as $key = $value)
{
$arBindRef[] = $arBind[$key];
}
call_user_func_array(array($mysqliSTMT,'bind_param'),$arBindRef);
$mysqliSTMT-execute(); //here the problem occurs
}
echo 'brFINISHED';
?
Expected result:
No segementation fault
Actual result:
--
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
_zend_mm_free_int (heap=0x7f7a2473fa40, p=0x7f7a19cd5f38) at
/home/myUser/DebMaking/php-5.4.17/Zend/zend_alloc.c:2100
2100if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
(gdb) bt
#0 _zend_mm_free_int (heap=0x7f7a2473fa40, p=0x7f7a19cd5f38) at
/home/myUser/DebMaking/php-5.4.17/Zend/zend_alloc.c:2100
#1 0x7f7a1eb08afd in _mysqlnd_pefree (ptr=optimized out, persistent=0
'\000') at /home/myUser/DebMaking/php-5.4.17/ext/mysqlnd/mysqlnd_alloc.c:372
#2 0x7f7a1eb14cfa in mysqlnd_internal_free_result_contents
(result=0x7f7a19d479e8) at
Req #62169 [Wfx]: Use 'global' like a language structure
Edit report at https://bugs.php.net/bug.php?id=62169edit=1
ID: 62169
Updated by: johan...@php.net
Reported by:valentiny510 at yahoo dot es
Summary:Use 'global' like a language structure
Status: Wont fix
Type: Feature/Change Request
Package:*Programming Data Structures
Operating System: Windows XP
PHP Version:5.4.3
-Block user comment: No
+Block user comment: Yes
Private report: N
New Comment:
And we not about yours.
Previous Comments:
[2013-07-28 17:02:30] valentiny510 at yahoo dot es
Joost if you can explain the 'evil' difference between this 2 examples and also
tell me whitch is more 'hard to read' and why...
I will give you the Nobel prize por programming...
function test( ) {
return global $variable;
}
function test( ) {
global $variable;
return $variable;
}
and... nobody asked you about your 'solution' with scope identifier
global:: can be more evil yes.. but I do not care about your opinion, sorry
[2013-07-28 16:50:16] valentiny510 at yahoo dot es
Nikic you are really a php developer ?
Rasmus should choose better his team..
[2012-10-21 22:07:25] ni...@php.net
As already noted in this thread, using globals is highly discouraged and as
such it does not make sense to add any further functionality improving their
use.
Also (you say this yourself) you can use $GLOBALS. I don't understand why you
don't want to use it. Language features aren't added simply because someone
says Hey, I want to access globals in one expression, but I don't want to use
$GLOBALs, please add a feature that is fully equivalent but uses a different
syntax.
But even with the constraint of not using $GLOBALS you can easily build a
function that would do something equivalent:
function getGlobal($name) {
global $$name;
return $$name;
}
$foo = getGlobal('foo');
Marking this as Wontfix.
[2012-10-21 21:06:48] joost dot koehoorn at gmail dot com
My solution would be to introduce global as a scope identifier, so you could
use
it as:
global::$object = new stdClass;
global::$object-test = 'This is just a test';
function test()
{
return global::$object-test;
}
Although I do believe globals are evil and static class variables should be
used
at all times, this is a neat addition to avoid the very ugly and unclear global
keyword.
As it is now, you have to define a variable as global for it to resolve and act
on
the global variable. This makes code hard to read as it is not directly visible
that this is the case. The above syntax would solve this problem.
[2012-06-02 01:01:48] valentiny510 at yahoo dot es
Imagine I have unset the, ( $GLOBALS )..
To access a 'global' object into the function, first must be called trowght
global..
function test()
{
global $object;
return $object-some_method( );
}
I wonder if is posible to use (in the future :P) the 'global' like other
language structures.. Ex:
function test()
{
return( global $object-some_method( ) );
}
I know ... you will ask me why not use the namespaces, reflections, references,
traits, or whatever.. but .. its not the point ...
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=62169
--
Edit this bug report at https://bugs.php.net/bug.php?id=62169edit=1
Bug #65299 [Asn-Csd]: pdo mysql parsing errors
Edit report at https://bugs.php.net/bug.php?id=65299edit=1 ID: 65299 Updated by: johan...@php.net Reported by:php at on-e dot com Summary:pdo mysql parsing errors -Status: Assigned +Status: Closed Type: Bug Package:Compile Failure Operating System: Solaris 10 PHP Version:5.5.1 Assigned To:mysql Block user comment: N Private report: N New Comment: Fixed in revision 7b92a227. Note: It took me a while to figure out as you're most likely using a configure line which does something else than what you expect. I guess you are doing something like this: ./configure --with-mysqli --with-pdo-mysql=/path/to/bin/mysql_config This will compile mysqli using our mysqlnd library as base (http://php.net/mysqlnd) which is suggested and will, at the same time, build pdo_mysql using libmysql which is not suggested. I suggest using ./configure --with-mysqli --with-pdo-mysql which will use mysqlnd for both. Previous Comments: [2013-07-23 10:29:38] eugene at zhegan dot in Got this on a Solaris 11. [2013-07-19 21:44:03] johan...@php.net It is suggested to use mysqlnd, simply use --with-mysql --with-mysqli -with-pdo-mysql without specifying a path. This is still a bug though. [2013-07-19 20:32:39] php at on-e dot com Description: Mysql 5.1.65 /bin/bash /usr/local/src/php-5.5.1/libtool --silent --preserve-dup-deps -- mode=compile gcc -I/usr/local/src/php-5.5.1/ext -I -Iext/pdo_mysql/ - I/usr/local/src/php-5.5.1/ext/pdo_mysql/ -DPHP_ATOM_INC -I/usr/local/src/php- 5.5.1/include -I/usr/local/src/php-5.5.1/main -I/usr/local/src/php-5.5.1 - I/usr/local/src/php-5.5.1/ext/date/lib -I/usr/local/src/php-5.5.1/ext/ereg/regex -I/usr/local/include/libxml2 -I/usr/local/ssl/include -I/usr/local/include - I/usr/local/include/freetype2 -I/usr/local/src/php-5.5.1/ext/mbstring/oniguruma -I/usr/local/src/php-5.5.1/ext/mbstring/libmbfl -I/usr/local/src/php- 5.5.1/ext/mbstring/libmbfl/mbfl -I/usr/local/mysql/include/mysql - I/usr/local/src/php-5.5.1/ext/sqlite3/libsqlite -I/usr/local/src/php-5.5.1/TSRM -I/usr/local/src/php-5.5.1/Zend -D_POSIX_PTHREAD_SEMANTICS - D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/usr/local/include -g -O2 -DZTS -c /usr/local/src/php-5.5.1/ext/pdo_mysql/mysql_driver.c -o ext/pdo_mysql/mysql_driver.lo /usr/local/src/php-5.5.1/ext/pdo_mysql/mysql_driver.c:532:1: warning: MYSQL_UNIX_ADDR redefined In file included from /usr/local/mysql/include/mysql/mysql.h:74, from /usr/local/src/php- 5.5.1/ext/pdo_mysql/php_pdo_mysql_int.h:31, from /usr/local/src/php-5.5.1/ext/pdo_mysql/mysql_driver.c:33: /usr/local/mysql/include/mysql/mysql_version.h:19:1: warning: this is the location of the previous definition /usr/local/src/php-5.5.1/ext/pdo_mysql/mysql_driver.c: In function `pdo_mysql_handle_factory': /usr/local/src/php-5.5.1/ext/pdo_mysql/mysql_driver.c:717: error: `MYSQL_SERVER_PUBLIC_KEY' undeclared (first use in this function) /usr/local/src/php-5.5.1/ext/pdo_mysql/mysql_driver.c:717: error: (Each undeclared identifier is reported only once /usr/local/src/php-5.5.1/ext/pdo_mysql/mysql_driver.c:717: error: for each function it appears in.) make: *** [ext/pdo_mysql/mysql_driver.lo] Error 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=65299edit=1
Bug #65300 [Opn-Nab]: Memory leak when initializing objects
Edit report at https://bugs.php.net/bug.php?id=65300edit=1
ID: 65300
Updated by: johan...@php.net
Reported by:zlobnygrif at gmail dot com
Summary:Memory leak when initializing objects
-Status: Open
+Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: debian/ubuntu
PHP Version:5.4.17
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
When creating the class we prefill the properties. Thanks to copy-on-write we
(generally) don't have to copy these values when creating an instance of the
object. When reassigning them with the same value those default values will e
replaced. We don't compare the values.
Previous Comments:
[2013-07-20 06:14:03] zlobnygrif at gmail dot com
Description:
If I set object property run-time it uses more memory than equal default
property value.
Test script:
---
printf(PHP %s %s\n\n, PHP_VERSION, PHP_OS);
class Order {
public $id = '123';
public $number = '1234';
public $date = '12345';
}
$orders = [];
printf(Test1\nMem before: %.2f mb\n, memory_get_usage(true) / 1024 / 1024);
for ( $i = 0; ++$i 10; )
{
$order = new Order;
$orders[] = $order;
}
printf(Mem after: %.2f mb\n\n, memory_get_usage(true) / 1024 / 1024);
unset($orders, $i);
$orders = [];
printf(Test2\nMem before: %.2f mb\n, memory_get_usage(true) / 1024 / 1024);
for ( $i = 0; ++$i 10; )
{
$order = new Order;
$orders[] = $order;
}
printf(Mem after: %.2f mb\n\n, memory_get_usage(true) / 1024 / 1024);
unset($orders, $i);
$orders = [];
printf(Test3\nMem before: %.2f mb\n, memory_get_usage(true) / 1024 / 1024);
for ( $i = 0; ++$i 10; )
{
$order = new Order;
$order-id = '123';
$order-number = '12345';
$order-date = '123456';
$orders[] = $order;
}
printf(Mem after: %.2f mb\n\n, memory_get_usage(true) / 1024 / 1024);
unset($orders, $i);
printf(Mem after: %.2f mb\n\n, memory_get_usage(true) / 1024 / 1024);
Expected result:
no memory leaks
Actual result:
--
PHP 5.4.17-1~dotdeb.0 Linux
Test1
Mem before: 0.25 mb
Mem after: 16.25 mb
Test2
Mem before: 4.75 mb
Mem after: 16.25 mb
Test3
Mem before: 5.00 mb
Mem after: 24.25 mb
Mem after: 5.25 mb
--
Edit this bug report at https://bugs.php.net/bug.php?id=65300edit=1
Bug #65301 [Opn-Fbk]: Deleting sessions without taking into account the configuration
Edit report at https://bugs.php.net/bug.php?id=65301edit=1
ID: 65301
Updated by: johan...@php.net
Reported by:developer at cartman34 dot fr
Summary:Deleting sessions without taking into account the
configuration
-Status: Open
+Status: Feedback
Type: Bug
Package:Apache2 related
Operating System: Debian 7.1 (wheezy)
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
we can neither support debian builds nor old versions.
Previous Comments:
[2013-07-20 08:13:08] developer at cartman34 dot fr
Description:
I'am running a PHP5 5.4.4-14+deb7u3 with an apache2 2.2.22-13 and it suffered
of an issue with sessions, these ones are quickly deleted without taking into
account the php.ini configuration.
I recently updated my server from Squeeze to Wheezy and i come with a new
version of PHP, the version 5.4 and these bugs.
I got the new php.ini configuration that i updated for my own preferences.
Here is my php.ini session related configuration:
[Session]
session.save_handler = files
;session.save_path = /var/lib/php5
session.use_cookies = 1
;session.cookie_secure =
session.use_only_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 604800
session.cookie_path = /
session.cookie_domain =
session.cookie_httponly =
session.serialize_handler = php
session.gc_probability = 0
session.gc_divisor = 1000
session.gc_maxlifetime = 604800
session.bug_compat_42 = Off
session.bug_compat_warn = Off
session.referer_check =
;session.entropy_length = 32
;session.entropy_file = /dev/urandom
session.cache_limiter = nocache
session.cache_expire = 180
You see that PHP should not delete sessions due to the session.gc_probability=0
and even if it does, the session.gc_maxlifetime is for one week.
I checked the cookie, it is always right but the session file seems to
disappear after the default session.cookie_lifetime delay.
It is a debian stable server, so I can't upgrade PHP more than the current
stable release for debian. :-D
For my own usage, I will try to use a custom Session Handler.
Test script:
---
?php
session_start();
if( !isset($_SESSION['last_time']) ) {
echo 'Creating session.';
} else {
echo 'Delay since last update: '.($_SESSION['last_time']-time()).' seconds.';
}
$_SESSION['last_time'] = time();
// This is just a test script for bugs.php.net
Expected result:
Under one week reload, I expect displaying 'Delay since last update', not
'Creating session.'.
Actual result:
--
Displaying 'Creating session.' after less than 30 minutes.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65301edit=1
Bug #65299 [Opn-Asn]: pdo mysql parsing errors
Edit report at https://bugs.php.net/bug.php?id=65299edit=1 ID: 65299 Updated by: johan...@php.net Reported by:php at on-e dot com Summary:pdo mysql parsing errors -Status: Open +Status: Assigned Type: Bug Package:Compile Failure Operating System: Solaris 10 PHP Version:5.5.1 -Assigned To: +Assigned To:mysql Block user comment: N Private report: N New Comment: It is suggested to use mysqlnd, simply use --with-mysql --with-mysqli -with-pdo-mysql without specifying a path. This is still a bug though. Previous Comments: [2013-07-19 20:32:39] php at on-e dot com Description: Mysql 5.1.65 /bin/bash /usr/local/src/php-5.5.1/libtool --silent --preserve-dup-deps -- mode=compile gcc -I/usr/local/src/php-5.5.1/ext -I -Iext/pdo_mysql/ - I/usr/local/src/php-5.5.1/ext/pdo_mysql/ -DPHP_ATOM_INC -I/usr/local/src/php- 5.5.1/include -I/usr/local/src/php-5.5.1/main -I/usr/local/src/php-5.5.1 - I/usr/local/src/php-5.5.1/ext/date/lib -I/usr/local/src/php-5.5.1/ext/ereg/regex -I/usr/local/include/libxml2 -I/usr/local/ssl/include -I/usr/local/include - I/usr/local/include/freetype2 -I/usr/local/src/php-5.5.1/ext/mbstring/oniguruma -I/usr/local/src/php-5.5.1/ext/mbstring/libmbfl -I/usr/local/src/php- 5.5.1/ext/mbstring/libmbfl/mbfl -I/usr/local/mysql/include/mysql - I/usr/local/src/php-5.5.1/ext/sqlite3/libsqlite -I/usr/local/src/php-5.5.1/TSRM -I/usr/local/src/php-5.5.1/Zend -D_POSIX_PTHREAD_SEMANTICS - D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -I/usr/local/include -g -O2 -DZTS -c /usr/local/src/php-5.5.1/ext/pdo_mysql/mysql_driver.c -o ext/pdo_mysql/mysql_driver.lo /usr/local/src/php-5.5.1/ext/pdo_mysql/mysql_driver.c:532:1: warning: MYSQL_UNIX_ADDR redefined In file included from /usr/local/mysql/include/mysql/mysql.h:74, from /usr/local/src/php- 5.5.1/ext/pdo_mysql/php_pdo_mysql_int.h:31, from /usr/local/src/php-5.5.1/ext/pdo_mysql/mysql_driver.c:33: /usr/local/mysql/include/mysql/mysql_version.h:19:1: warning: this is the location of the previous definition /usr/local/src/php-5.5.1/ext/pdo_mysql/mysql_driver.c: In function `pdo_mysql_handle_factory': /usr/local/src/php-5.5.1/ext/pdo_mysql/mysql_driver.c:717: error: `MYSQL_SERVER_PUBLIC_KEY' undeclared (first use in this function) /usr/local/src/php-5.5.1/ext/pdo_mysql/mysql_driver.c:717: error: (Each undeclared identifier is reported only once /usr/local/src/php-5.5.1/ext/pdo_mysql/mysql_driver.c:717: error: for each function it appears in.) make: *** [ext/pdo_mysql/mysql_driver.lo] Error 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=65299edit=1
Bug #65284 [Opn-Nab]: Segmentation fault with the CLI
Edit report at https://bugs.php.net/bug.php?id=65284edit=1
ID: 65284
Updated by: johan...@php.net
Reported by:jhaagsma at gmail dot com
Summary:Segmentation fault with the CLI
-Status: Open
+Status: Not a bug
Type: Bug
Package:Reproducible crash
Operating System: Ubuntu
PHP Version:5.4.17
Block user comment: N
Private report: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
This must somehow depend on the build or something in the environment. Please
work with Ondrej on this. We'd need a stacktrace from vanilla PHP for doing
anything.
Previous Comments:
[2013-07-18 08:45:31] sjon at hortensius dot net
Obviously a vanilla 5.4.17 doesn't crash with this script (as can easily be
seen
at http://3v4l.org/gBq9U ); so the problem must be your environment; or the
patches that were applied.
I think you're best of contacting your distro-specific maintainer for this (I
noticed several debian patches which could cause this behaviour)
[2013-07-18 07:17:28] jhaagsma at gmail dot com
Description:
I was updating my machine VM's from 5.4.17RC1 to 5.4.17 and noticed a
problem,
it was segfaulting.
Using this test file on an upgraded machine and non-upgraded machine:
machine1:~$ php --version
PHP 5.4.17RC1 (cli) (built: Jun 22 2013 19:27:26)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
machine1:~$ php testphp
Running from CLI
machine2:~$ php --version
PHP 5.4.17-1~precise+1 (cli) (built: Jul 17 2013 18:14:06)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
machine2:~$ php testphp
Segmentation fault (core dumped)
This is on ubuntu using Ondrej's PPA for PHP 5.4, but he said he's not made any
debian/ubuntu specific changes since RC1.
Test script:
---
?php
if(defined('STDIN') )
echo(Running from CLI);
else
echo(Not Running from CLI);
?
Expected result:
Expected result was Running from CLI
Actual result:
--
Segmentation fault (core dumped)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65284edit=1
Bug #65223 [Opn-Nab]: $_SERVER, $_ENV, $_REQUEST variables missing in $GLOBALS
Edit report at https://bugs.php.net/bug.php?id=65223edit=1 ID: 65223 Updated by: johan...@php.net Reported by:truenrush at gmail dot com Summary:$_SERVER, $_ENV, $_REQUEST variables missing in $GLOBALS -Status: Open +Status: Not a bug Type: Bug Package:*General Issues Operating System: Debian PHP Version:5.4.17 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php super-globals (aka. auto globals) are not added to symbol tables by defaultfor performance reasons unless the parser sees need. i.e. ?php $_SERVER; print_r($GLOBALS); ? will list it. You can also control this using auto_gloals_jit in php.ini: http://www.php.net/manual/en/ini.core.php#ini.auto-globals-jit Previous Comments: [2013-07-09 11:20:19] truenrush at gmail dot com I also found that $_ENV and $_REQUEST vars are also missing in $GLOBALS. _SERVER variable appears in $GLOBALS when using php in cli mode, but with web server i can not find it in the $GLOBALS variable [2013-07-09 10:40:30] truenrush at gmail dot com Description: When i did a var_dump($GLOBALS) i was surprized, because _SERVER variable was missing here, but standalone _SERVER var was working fine. According to http://www.php.net/manual/en/reserved.variables.globals.php, $GLOBALS is an associative array containing references to all variables which are currently defined in the global scope of the script. _SERVER is defined in global space. But it does not appear in the $GLOBALS. I found nothing on php.net about such behaviour. Test script: --- var_dump($GLOBALS); Expected result: _SERVER key exists in $GLOBALS array. Actual result: -- _SERVER key does not exist in $GLOBALS array. -- Edit this bug report at https://bugs.php.net/bug.php?id=65223edit=1
Bug #65188 [Opn-Nab]: Undocumented change for open_basedir restrictions
Edit report at https://bugs.php.net/bug.php?id=65188edit=1 ID: 65188 Updated by: johan...@php.net Reported by:lennsen at chello dot at Summary:Undocumented change for open_basedir restrictions -Status: Open +Status: Not a bug Type: Bug Package:*Directory/Filesystem functions Operating System: Linux PHP Version:5.4.16 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This was a security discussion around CVE-2010-3436. I don't know if there is a public summary of the open_basedir minor flaw security thread from 28 Sep 2010. Previous Comments: [2013-07-03 00:44:25] lennsen at chello dot at Description: Between 5.3 and since 5.4 (also 5.5) there was a significant change for its reasons I am not aware of. If there is some directory e.g. /somedir having a script e.g. index.php then in 5.3 (and lower) it was possible to call this file by setting an apache document root there and if only read access was required, then one could call that vhost with /somedir/index.php without the need of having /somedir within open_basedir e.g. http://somedir.domain.com/index.php since 5.4 this is not possible any more, it returns an error with open_basedir restriction in effect and that the stream could not be opened I tested this with the very same systems (on 3 different ones), same configure options, same php.ini - the only difference was the PHP version, confirmed with 5.3 (working), 5.4.16, 5.5.0 (both not working) I guess that it might have something to do with the removal of safe_mode and its checks, perhaps the modifications for the core caused this change, but I can not tell for sure. As far as possible I adapted the following files from 5.3 to 5.4 by comparison and removing/adding lines to make them work as close as possible to 5.3 main/fopen_wrappers.c main/streams/streams.c main/fopen_wrappers.c main/streams/plain_wrapper.c ext/standard/php_fopen_wrapper.c ext/standard/basic_functions.c ext/standard/filestat.c ext/standard/file.c -- This is just a hint and might not mean anything, but after adapting these files (this was mostly possible until interface changes had to be made, causing gcc/make to abort) I did not see any change in behavior. The given error is No input file specified. (sapi fcgi is in use) and error_log gives the following errors: PHP Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 PHP Warning: Unknown: open_basedir restriction in effect. File(/somedir/index.php) is not within the allowed path(s): (/restricted_1/:/restricted_2/) in Unknown on line 0 This also might have to do something with the SAPI. The main reason behind this is: - I want to be able to use such a vhost, the php files should be -execute-only-, so opening and parsing index.php from within the browser should be possible - at the same time, due to the missing entry of /somepath in open_basedir, one must not be able to open /somepath/index.php with e.g. fopen, to see the file's contents (the plain PHP code) This worked very fine until 5.3. A solution or alternative to achieve these 2 requirements would be great since I can not stay with 5.3 forever. Please do not suggest code compiling with e.g. Zend Optimizer, RoundCube or similar. Individual changes in PHP's C source is an option if no generic solution is available. configuration: - open_basedir = /restricted_1/:/restricted_2/ - read/write access available for GID and UID - no SELinux - phpcgi and httpd are being executed with same GID and GID as the file Expected result: opening the resource, http://somedir.domain.com/index.php leads to opening parsing the file Actual result: -- fails to open resource, http://somedir.domain.com/index.php says 'No input file specified. ' error_log contains 2 errors: PHP Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 PHP Warning: Unknown: open_basedir restriction in effect. File(/somedir/index.php) is not within the allowed path(s): (/restricted_1/:/restricted_2/) in Unknown on line 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=65188edit=1
Bug #65168 [Opn-Nab]: segfault when __toString() returns $this
Edit report at https://bugs.php.net/bug.php?id=65168edit=1
ID: 65168
Updated by: johan...@php.net
Reported by:oliver at x10 dot pe
Summary:segfault when __toString() returns $this
-Status: Open
+Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Xubuntu 12.10 64bits
PHP Version:master-Git-2013-06-30 (Git)
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Infinite recursion can lead to stackoverflow and segfault.
Previous Comments:
[2013-06-30 16:53:11] oliver at x10 dot pe
laruence, yep I realized I described wrong the bug in the subject after sending
it .
[2013-06-30 16:46:37] larue...@php.net
oh, there was a mistake, that is, after we have stackless user function call
return $this should be same as return call_user_func(array($this,
__toString));
[2013-06-30 16:44:09] larue...@php.net
actually, this is not a returning problem,
return $this is same as return strval($this),
so, it's the same as return $this-__toString.
it's a stack overflow segfault
[2013-06-30 15:54:07] oliver at x10 dot pe
Description:
Hi,
Casting $this as string inside __toString() magic function makes php crash. It
seems it ran into an infinite loop.
Tested on PHP 5.5 and 5.4.11, even 5.3.6
Test script:
---
class base {
function __toString() {
return $this;
}
}
echo new base();
Expected result:
Exception thrown, or an error message.
Actual result:
--
Violación de segmento (`core' generado)
[Segmentation Fault ('core' dumped)]
--
Edit this bug report at https://bugs.php.net/bug.php?id=65168edit=1
Bug #65160 [Opn-Nab]: $this can be changed using reference
Edit report at https://bugs.php.net/bug.php?id=65160edit=1
ID: 65160
Updated by: johan...@php.net
Reported by:m dot adeelnawaz at ymail dot com
Summary:$this can be changed using reference
-Status: Open
+Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Windows 7 / Linux
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
We don't prevent people from purposely shooting in their own feet. The checks
we do are there during parsing stage in order to prevent obvious mistakes and
to warn people coming from PHP 4 (where reassigning $this was the only way in a
constructor to report errors)
We don't check further at runtime and won't do this as the only way would e to
check _every_ variable operation, which are costs in no relation to the benefit.
Previous Comments:
[2013-06-29 11:45:07] a...@php.net
On the other hand, overriding of $this is only possible on the stack, therefore
calling -test2() will have it back.
[2013-06-28 16:47:13] a...@php.net
looks like a real mess, namely here's a modified snippet
?php
class a{}
class b{
function test(){
$a = $this;
echo get_class($this).PHP_EOL;
echo get_class($a).PHP_EOL;
$a = new a();
echo get_class($this).PHP_EOL;
echo get_class($a).PHP_EOL;
}
function test2()
{
echo get_class($this).PHP_EOL;
}
function test3()
{
$a = $this;
$a = new a;
echo get_class($this).PHP_EOL;
echo get_class($a).PHP_EOL;
$this-test();
}
}
$b = new b();
$b-test();
$b-test2();
$b-test3();
$a = new a;
$a-test();
especially b:test3() - it reports both $a and $this having class 'a', but $this-
test() works after that. Whereby (new a)-test() will die on undefined method.
[2013-06-28 14:59:20] m dot adeelnawaz at ymail dot com
Actual result:
--
b
b
a
a
[2013-06-28 14:45:15] m dot adeelnawaz at ymail dot com
Description:
In an object method, $this must always be a reference to the caller object.
Now $this can not be re-assigned but re-assigning is not the only way to modify
$this. The code below demonstrates another way to set $this to something other
than the caller object.
This is what happens. $this is a reference (or copy of the identifier) to the
caller object. After doing this
$a = $this;
$a and $this are both pointing to the same reference to the object identifier.
So changing one of them (assigning them to something not by reference) will
change the reference for both of them.
After executing this line
$a = new a();
Both $a and $this start pointing to the reference of the identifier to the
newly created object. You can change $this's reference by setting $a (not by
reference) to any non-null variable or value.
Test script:
---
class a{}
class b{
function test(){
$a = $this;
echo get_class($this).'br/';
echo get_class($a).'br/';
$a = new a();
echo get_class($this).'br/';
echo get_class($a).'br/';
}
}
$b = new b();
$b-test();
Expected result:
One of the following should happen when I run the code above.
1. The code should produce a fatal error on line 3 ($a = $this;) saying that
referencing to $this is not allowed.
2. The code should allow me to create a reference to $this in $a but assigning
any non-null value to $a (not by reference) should produce a fatal error saying
that $a is a reference to $this so it should (first) be assigned by reference
to some variable / object other than current object.
3. The code should allow me to create a reference to $this in $a but then the
same rules should apply to $a as $this with one exception that $a can be
unset().
Actual result:
--
b
b
b
a
--
Edit this bug report at https://bugs.php.net/bug.php?id=65160edit=1
Bug #60646 [Fbk-Nab]: Recursive request with same session fails
Edit report at https://bugs.php.net/bug.php?id=60646edit=1 ID: 60646 Updated by: johan...@php.net Reported by:lgandras at gmail dot com Summary:Recursive request with same session fails -Status: Feedback +Status: Not a bug Type: Bug Package:Session related Operating System: Centos 5.4 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php When starting a session it is being locked to prevent concurrent access and loosing state. My suggestion is to use another mechanism to transfer the required data. If you really want parallel access you can use session_write_close() and lateron session-start() again. Previous Comments: [2013-06-27 21:26:45] ar...@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-27 21:26:27] ar...@php.net Er, clicked the wrong option.. [2013-06-27 21:25:39] ar...@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-03-19 10:55:07] cnam dot cdel at free dot fr I got the same problem with Lamp / PHP Version 5.3.3-7+squeeze14 [2012-05-05 21:33:21] scampbell525 at gmail dot com PHP version 5.3.10 This is not an issue on my localhost using WAMP, but when migrated to a LAMP stack on the web host, it becomes an issue. 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=60646 -- Edit this bug report at https://bugs.php.net/bug.php?id=60646edit=1
Bug #65011 [Asn-Opn]: ReflectionProperty::getDocComment() fails for multiple variable declarations
Edit report at https://bugs.php.net/bug.php?id=65011edit=1
ID: 65011
Updated by: johan...@php.net
Reported by:benjamin dot morel at gmail dot com
Summary:ReflectionProperty::getDocComment() fails for
multiple variable declarations
-Status: Assigned
+Status: Open
Type: Bug
Package:Reflection related
Operating System: CentOS 6.4
PHP Version:5.4.16
-Assigned To:johannes
+Assigned To:
Block user comment: N
Private report: N
New Comment:
i don't think it is the right thing to do. Let's extend through example:
class C {
/**
* foo
*/
public $foo,
/**
* bar
*/
$bar;
}
if we here take the doc comment from foo for both it becomes weird (ok, the
code is weird,
tion) taking bar we make the grammar more complex. I'd keep the current way.
Previous Comments:
[2013-06-24 00:14:29] fel...@php.net
Johannes, what is your opinion about this suggestion?
[2013-06-11 10:54:07] benjamin dot morel at gmail dot com
Description:
When multiple class properties are declared at once,
ReflectionProperty::getDocComment() only returns the doc comment for the first
one.
I believe that the doc comment applies to all of the properties if they're
declared together, so getDocComment() should return the same value for all of
them, not just the first one.
Test script:
---
class Foo {
/** @var string */
public $a, $b;
}
$class = new \ReflectionClass('Foo');
foreach ($class-getProperties() as $property) {
echo $property-getName() . ': ' . var_export($property-getDocComment(),
true) . PHP_EOL;
}
Expected result:
a: '/** @var string */'
b: '/** @var string */'
Actual result:
--
a: '/** @var string */'
b: false
--
Edit this bug report at https://bugs.php.net/bug.php?id=65011edit=1
Bug #46508 [Asn]: [PATCH]: getColumnMeta returns 'LONG','VAR_STRING','BLOB' as php native_type
Edit report at https://bugs.php.net/bug.php?id=46508edit=1 ID: 46508 Updated by: johan...@php.net Reported by:marques at displague dot com Summary:[PATCH]: getColumnMeta returns 'LONG','VAR_STRING','BLOB' as php native_type Status: Assigned Type: Bug Package:PDO related Operating System: * PHP Version:5.2.9 -Assigned To:mysql +Assigned To: Block user comment: N Private report: N New Comment: The complete topic is more complex and needs a more specific specification. I agree to the fact that long is no good choice. For the MySQL case mind that, if PDO is using emulation of prepared statements, which it does by default all data is returned as string, as that's the way it comes over the wire. when using native prepared statements the type used might change within a column (use a column with an integer type larger than PHP_INT_MAX, then values in PHP's integer/long range might be returned as PHP int/long (depends a bit on other factors, i.e. mysqlnd vs libmysql) else as string. So unless we define this for all drivers properly we (MySQL) will not change the behavior. Previous Comments: [2010-05-11 13:13:46] u...@php.net Whatever the docs say, what counts is EXPERIMENTAL = TENTATIVE = UNDEFINED. It is irrelevant how meaningful and sensible your suggestion is. If you want any changes to PDO, please write an RFC/discuss on internal/do whatever the current procedure is to get the EXPERIMENTAL removed. Specification via bug reports does not make much sense to me. You fix one and break another causing a bug report stating just the opposite and, for example, claiming you break backwards compatibility. The underlying issue is the lack of a clear definition. The issue is the EXPERIMENTAL. I do understand how annoying the answer is. But please respect that specification via bug reports is not a good approach and sometimes it is better to go a step back and do it right: fix PDO as such. Whoever wants, may play the patch-and-work-without-specs game. But I won't do it. Its an endless game leading nowhere: leaving bug open, unassigning mysql (at least as long as there is no clear specs). [2009-06-29 10:18:50] marques at displague dot com I stated in the bug report that the return values do not match up with the documentation. The docs state (pretty clearly): http://php.net/manual/en/pdostatement.getcolumnmeta.php: native_type The PHP native type used to represent the column value. driver:decl_typeThe SQL type used to represent the column value in the database. If the column in the result set is the result of a function, this value is not returned by PDOStatement::getColumnMeta(). pdo_typeThe type of this column as represented by the PDO::PARAM_* constants. The problems are that (per the docs) native_type is missed for some types (TINYINT) and that the native_type values currently returned should be in driver:decl_type, and PHP native types should be returned for native_type instead. [2009-06-29 09:42:27] uwendel at mysql dot com Why would I bother about a function that has no specification? Without a specification there is no definition of how things should go and there is no bug - by definition... Warning This function is EXPERIMENTAL. The behaviour of this function, its name, and surrounding documentation may change without notice in a future release of PHP. This function should be used at your own risk. , http://de.php.net/manual/en/pdostatement.getcolumnmeta.php There needs to be a proper PDO spec before one can decide about any bug report. IMHO the bug report should be closed as bogus. [2009-04-10 14:01:57] php at displague dot com This should probably be the topic of another bug, but TINYINT doesn't return a native_type (I'm guessing because TINY is used everywhere, but not TINYINT - maybe another constant is needed). mysql://user@host/db show columns from table like 'disable' \G; *** 1. row *** Field: disable Type: tinyint(4) Null: NO Key: Default: 0 Extra: 1 row in set (0.00 sec) getColumnMeta (php 5.2.9) returns: Array ( [flags] = Array ( [0] = not_null ) [table] = promo_item [name] = disable [len] = 4 [precision] = 0 [pdo_type] = 2 ) native_type is missing. Is there any chance this correction will make it into 5.2.x? [2008-11-07 16:24:52] fel...@php.net Hi Marques, good observation! I've updated the patch. ;)
Sec Bug-Bug #64993 [Opn]: [patch] PDO::query() memory leak and reference problem if error
Edit report at https://bugs.php.net/bug.php?id=64993edit=1
ID: 64993
Updated by: johan...@php.net
Reported by:rgagnon24 at gmail dot com
Summary:[patch] PDO::query() memory leak and reference
problem if error
Status: Open
-Type: Security
+Type: Bug
Package:PDO related
Operating System: Any
PHP Version:5.4.16
Block user comment: N
Private report: Y
New Comment:
This is no security issues. Users who want to hold a connection open can do
this without this bug, too.
Previous Comments:
[2013-06-08 08:30:13] rgagnon24 at gmail dot com
Have patch to upload, but it won't let me...
It is a small patch, so here is the diff inline:
===BEGIN=
--- ext/pdo/pdo_dbh.c.orig 2013-06-08 06:16:44.0 +
+++ ext/pdo/pdo_dbh.c 2013-06-08 07:00:54.0 +
@@ -1148,8 +1148,8 @@ static PHP_METHOD(PDO, query)
PDO_HANDLE_STMT_ERR();
} else {
PDO_HANDLE_DBH_ERR();
- zval_dtor(return_value);
}
+ zval_dtor(return_value);
RETURN_FALSE;
}
===END=
[2013-06-08 08:26:24] rgagnon24 at gmail dot com
Description:
If an error happens while executing PDO::query() causing FALSE to be returned,
or a PDOException to be thrown, the result is that a reference is held to the
PDO object and the database connection is not released until the script is
terminated.
This creates a memory leak in PHP, and an exhaustion of resources on the
Database Server being used, which could become a security issue.
This leak will not be noticible when running PHP as a web page, but is
painfully a problem when creating long-term CLI scripts that are always
running, connecting to a database, performing operations, closing, sleeping,
and repeating. Eventually all allowable connections to your database server
will be used up creating a denial of service problem, leading to other possible
security issues.
The sample code is short, but when combined with a monitoring of the network
connections to your database server, you will see that all connections remain
in ESTABLISHED state (via netstat -an) even though the $dbh value is set to
NULL on each iteration.
Because of the error in the PDO::query() call, setting $dbh to NULL does not
have the effect of releasing the connection because there is a held reference
to the object--namely the PDOStatement that is created internally within
PDO::query() but never returned to the calling program due to the error.
Note that persistent connection pooling is not the problem here as the test
script specifically instructs the code NOT to use persistent connections in
order to demonstrate the memory leak. To ensure this further, all persistent
settings in php.ini were set to completely disable connection persistence.
The bug is patched easily with the attached patch for the ext/pdo/pdo_dbh.c
file (1 line of code is moved).
The reason for moving the line in question is because during the error, the
created stmt object CANNOT be returned to the calling program. Thus, the
destructor of the stmt cannot go off, and the reference count to the dbh
object will never decrease to allow its destructor to do cleanup.
Furthermore, since the stmt object created prior to line 1125 of pdo_dbh.c has
a reference to the dbh added to it. A matching UNreference must be done if the
object is not going to be returned. Without the patch, the reference is only
removed following the PDO_HANDLE_DBH_ERR() macro, when it should be
de-referenced after EITHER PDO_HANDLE_DBH_ERR() OR PDO_HANDLE_STMT_ERR().
Since the stmt object is not returned during an error condition, the
zval_dtor() call is required. This will in turn allow the stmt to call
php_pdo_dbh_delref() thus letting the dbh object die when it is set to null.
Test script:
---
$options = array(
PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_PERSISTENT = false,
);
for($i = 0; $i 10; $i++) {
$dbh = new PDO(mysql:dbname=$dbname;host=$host, $user, $password,
$options);
$sql = SELECT 1 FROM table_that_does_not_exist LIMIT 1;
try {
$rs = $dbh-query($sql, PDO::FETCH_ASSOC);
$rs-closeCursor();
print Table exists\n;
} catch (Exception $e) {
print MSG: .$e-getMessage().\n;
}
sleep(3);
unset($rs);
$dbh = null;
}
while (1) {
print sleep\n;
sleep(10);
}
Expected result:
MSG: SQLSTATE[42S02]: Base table or view not found: 1146 Table
'DBNAME.table_that_does_not_exist' doesn't exist
...
repeat above 10 times
...
sleep
sleep
sleep
...
The above output will appear, but you must ALSO check netstat
Bug #64911 [Opn-Nab]: Looped forward_static_call causes segfault
Edit report at https://bugs.php.net/bug.php?id=64911edit=1 ID: 64911 Updated by: johan...@php.net Reported by:jutaky at ee dot oulu dot fi Summary:Looped forward_static_call causes segfault -Status: Open +Status: Not a bug Type: Bug Package:Reproducible crash Operating System: ArchLinux PHP Version:5.4.15 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Infinite recursion fills up the stack and causes an stackoverflow which the operating system handles by killing the process. We improved this with recent versions of PHP for regular function calls, currently we're not planning on doing this for indirect calls (all forms of call_user_func). Previous Comments: [2013-05-23 18:20:08] s...@php.net Does not seem to be a security issue. [2013-05-23 17:13:45] jutaky at ee dot oulu dot fi Description: Looped forward_static_call causes segfault on PHP 5.4.15, 5.5.0RC2 and on trunk (20130523). Configure for PHP 5.5.0RC2 and trunk: ./configure --enable-debug Worth noting: xdebug extension prevented crash and exited PHP cleanly. Backtrace is extremely long, here are ten first entries: #0 0x007896d1 in _zend_mm_alloc_int (heap=error reading variable: Cannot access memory at address 0x7f7fefe8, size=error reading variable: Cannot access memory at address 0x7f7fefe0, __zend_filename=error reading variable: Cannot access memory at address 0x7f7fefd8, __zend_lineno=error reading variable: Cannot access memory at address 0x7f7fefd4, __zend_orig_filename=error reading variable: Cannot access memory at address 0x7f7fefc8, __zend_orig_lineno=error reading variable: Cannot access memory at address 0x7f7fefd0) at removed/Zend/zend_alloc.c:1881 #1 0x0078b3f3 in _emalloc (size=4, __zend_filename=0xbd7e38 removed/Zend/zend_operators.c, __zend_lineno=1979, __zend_orig_filename=0x0, __zend_orig_lineno=0) at removed/Zend/zend_alloc.c:2429 #2 0x007bec56 in zend_str_tolower_dup (source=0x77e95ac0 foo::bar, length=3) at removed/Zend/zend_operators.c:1979 #3 0x007ce357 in zend_is_callable_check_class (name=0x77e95ac0 foo::bar, name_len=3, fcc=0x7f7ff720, strict_class=0x7f7ff168, error=0x7f7ff368) at removed/Zend/zend_API.c:2673 #4 0x007cea6e in zend_is_callable_check_func (check_flags=0, callable=0x75b4dbc8, fcc=0x7f7ff720, strict_class=0, error=0x7f7ff368) at removed/Zend/zend_API.c:2795 #5 0x007cfc75 in zend_is_callable_ex (callable=0x75b4dbc8, object_ptr=0x0, check_flags=0, callable_name=0x0, callable_name_len=0x7f7ff294, fcc=0x7f7ff720, error=0x7f7ff368) at removed/Zend/zend_API.c:3059 #6 0x007d0710 in zend_fcall_info_init (callable=0x75b4dbc8, check_flags=0, fci=0x7f7ff750, fcc=0x7f7ff720, callable_name=0x0, error=0x7f7ff368) at removed/Zend/zend_API.c:3235 #7 0x007c6d89 in zend_parse_arg_impl (arg_num=1, arg=0x75bab758, va=0x7f7ff610, spec=0x7f7ff540, error=0x7f7ff4e8, severity=0x7f7ff4e4) at removed/Zend/zend_API.c:632 #8 0x007c7061 in zend_parse_arg (arg_num=1, arg=0x75bab758, va=0x7f7ff610, spec=0x7f7ff540, quiet=0) at removed/Zend/zend_API.c:691 #9 0x007c787c in zend_parse_va_args (num_args=0, type_spec=0xbaabcb f*, va=0x7f7ff610, flags=0) at removed/Zend/zend_API.c:873 #10 0x007c7b4f in zend_parse_parameters (num_args=1, type_spec=0xbaabcb f*) at removed/Zend/zend_API.c:924 Test script: --- Example case: http://jutaky.com/fuzzing/loopz.html Expected result: Possibly looping until killed, reaching max_execution_time or other PHP set limit is reached? Actual result: -- Segmentation fault. -- Edit this bug report at https://bugs.php.net/bug.php?id=64911edit=1
Bug #64827 [Opn-Nab]: Segfault in zval_mark_grey (zend_gc.c)
Edit report at https://bugs.php.net/bug.php?id=64827edit=1 ID: 64827 Updated by: johan...@php.net Reported by:odou...@php.net Summary:Segfault in zval_mark_grey (zend_gc.c) -Status: Open +Status: Not a bug Type: Bug Package:*General Issues Operating System: Linux PHP Version:5.4.15 Block user comment: N Private report: N New Comment: Do not file bugs when you have Zend extensions (zend_extension=) loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache, APC, Xdebug and ionCube loader. These extensions often modify engine behavior which is not related to PHP itself. . Previous Comments: [2013-05-13 15:17:26] odou...@php.net Description: Bug cannot be reproduced easily, as it requires a Magento install with many products in it. Bug can be reproduced on PHP 5.4.15 and 5.3.25 It does not happen when using cgi mode (only on FastCGI). I assume memory management is not handled equally between these modes. Running a specific page on Magento, page is rendered correctly, but at the end a SIGSEGV happens on PHP process. Program received signal SIGSEGV, Segmentation fault. zval_mark_grey (pz=0x272afb8) at /usr/src/build/php-5.4.15/Zend/zend_gc.c:388 (if needed, you can check source code here : http://svn.php.net/viewvc/php/php- src/trunk/Zend/zend_gc.c?view=markup) Tell me how I can help debug this error, as I cannot provide a reproducible code. Expected result: result page complete with no error Actual result: -- result page complete + SIGSEGV of the process after, which leads to streange behaviour depending on server used (nginx hides the segfault, Apache concatenates a 500 error page if used with mod_fcgid). (gdb) bt #0 zval_mark_grey (pz=0x272afb8) at /usr/src/build/php- 5.4.15/Zend/zend_gc.c:388 #1 0x007fafe5 in zval_mark_grey (pz=0x272afb8) at /usr/src/build/php- 5.4.15/Zend/zend_gc.c:432 #2 0x007fbf05 in gc_mark_roots () at /usr/src/build/php- 5.4.15/Zend/zend_gc.c:501 #3 gc_collect_cycles () at /usr/src/build/php-5.4.15/Zend/zend_gc.c:795 #4 0x007fc290 in gc_zval_possible_root (zv=optimized out) at /usr/src/build/php-5.4.15/Zend/zend_gc.c:166 #5 0x007fe297 in zend_object_std_dtor (object=0x390ab38) at /usr/src/build/php-5.4.15/Zend/zend_objects.c:54 #6 0x007fe2c9 in zend_objects_free_object_storage (object=0x272afb8) at /usr/src/build/php- 5.4.15/Zend/zend_objects.c:137 #7 0x0080406b in zend_objects_store_del_ref_by_handle_ex (handle= optimized out, handlers=optimized out) at /usr/src/build/php-5.4.15/Zend/zend_objects_API.c:221 #8 0x00804093 in zend_objects_store_del_ref (zobject=0x390b088) at /usr/src/build/php- 5.4.15/Zend/zend_objects_API.c:173 #9 0x007ce03d in _zval_dtor (zvalue=optimized out) at /usr/src/build/php-5.4.15/Zend/zend_variables.h:35 #10 _zval_ptr_dtor (zval_ptr=0x39781f8) at /usr/src/build/php- 5.4.15/Zend/zend_execute_API.c:438 #11 0x007e9200 in zend_hash_destroy (ht=0x3978130) at /usr/src/build/php-5.4.15/Zend/zend_hash.c:560 #12 0x007db01d in _zval_dtor_func (zvalue=0x390acd0) at /usr/src/build/php-5.4.15/Zend/zend_variables.c:45 #13 0x007ce03d in _zval_dtor (zvalue=optimized out) at /usr/src/build/php-5.4.15/Zend/zend_variables.h:35 #14 _zval_ptr_dtor (zval_ptr=0x390d798) at /usr/src/build/php- 5.4.15/Zend/zend_execute_API.c:438 #15 0x007fe297 in zend_object_std_dtor (object=0x38e4fb8) at /usr/src/build/php-5.4.15/Zend/zend_objects.c:54 #16 0x007fe2c9 in zend_objects_free_object_storage (object=0x272afb8) at /usr/src/build/php- 5.4.15/Zend/zend_objects.c:137 #17 0x0080406b in zend_objects_store_del_ref_by_handle_ex (handle= optimized out, handlers=optimized out) at /usr/src/build/php-5.4.15/Zend/zend_objects_API.c:221 #18 0x00804093 in zend_objects_store_del_ref (zobject=0x3992400) at /usr/src/build/php- 5.4.15/Zend/zend_objects_API.c:173 #19 0x007ce03d in _zval_dtor (zvalue=optimized out) at /usr/src/build/php-5.4.15/Zend/zend_variables.h:35 #20 _zval_ptr_dtor (zval_ptr=0x39922f8) at /usr/src/build/php- 5.4.15/Zend/zend_execute_API.c:438 #21 0x007e9200 in zend_hash_destroy (ht=0x2533ab8) at /usr/src/build/php-5.4.15/Zend/zend_hash.c:560 #22 0x007db01d in _zval_dtor_func (zvalue=0x2528948) at /usr/src/build/php-5.4.15/Zend/zend_variables.c:45 #23 0x007ce03d in _zval_dtor (zvalue=optimized out) at /usr/src/build/php-5.4.15/Zend/zend_variables.h:35 #24 _zval_ptr_dtor (zval_ptr=0x2518c40) at /usr/src/build/php- 5.4.15/Zend/zend_execute_API.c:438 #25 0x007fe297 in zend_object_std_dtor (object=0x250cd28) at /usr/src/build/php-5.4.15/Zend/zend_objects.c:54 #26 0x007fe2c9 in zend_objects_free_object_storage (object=0x272afb8) at
Bug #64771 [Opn-Nab]: Error: require_once(): Unable to allocate memory for pool.
Edit report at https://bugs.php.net/bug.php?id=64771edit=1 ID: 64771 Updated by: johan...@php.net Reported by:tech at neodynamics dot com Summary:Error: require_ÂonceÂ(Â)Â: Unable to allocate memory for pool. -Status: Open +Status: Not a bug Type: Bug Package:Apache2 related Operating System: Linux PHP Version:5.3.24 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. This is not a matter of core PHP but APC configuration. Proalyyouneed more/larger shared memory segments for APC or shorter time to live or some filtering or ... see http://php.net/apc.configuration Previous Comments: [2013-05-03 11:25:46] tech at neodynamics dot com Description: I have a x-cart 4.4.2 Pro based store having the following configurations- Environment info- Component Status X-Cart version 4.4.2 X-Cart directory/var/www/html/mydomain.com/httpdocs PHP 5.3.10-1ubuntu3.5 GD 2.0 MySQL server5.1.45 MySQL client5.5.29 DB size 415.349Mb Web server Apache/2.2.22 (Ubuntu) Operation systemLinux Perl5.014002Details XML parser (expat) found X-Cart directory size Estimate the directory size HTTPS modules Net::SSLeay 1.42 libCURL 7.22.0 Active CURL executable curl 7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 OpenSSL executable OpenSSL 1.0.1 14 Mar 2012 I am facing the following problems and site become down. Test script: --- 1)/home.php raised Error: require_ÂonceÂ(Â)Â: Unable to allocate memory for pool. hellip; called at /var/www/html/mydomain.com/httpdocs/include/func/ func.core.php (70) in x_load called at /var/www/html/mydomain.com/httpdocs/init.php (61) in include_once called at /var/www/html/mydomain.com/httpdocs/preauth.php (69) in require called at /var/www/html/mydomain.com/httpdocs/auth.php (63) in require called at /var/www/html/mydomain.com/httpdocs/home.php (52) 2)/dispatcher.php raised Error: require_ÂonceÂ(Â)Â: Unable to allocate memory for pool. hellip; called at /var/www/html/mydomain.com/httpdocs/include/func/ func.core.php (70) in x_load called at /var/www/html/mydomain.com/httpdocs/init.php (61) in include_once called at /var/www/html/mydomain.com/httpdocs/preauth.php (69) in require called at /var/www/html/mydomain.com/httpdocs/dispatcher.php (50) 3)/adaptive.php raised Error: require_ÂonceÂ(Â)Â: Unable to allocate memory for pool. hellip; called at /var/www/html/mydomain.com/httpdocs/include/func/ func.core.php (70) in x_load called at /var/www/html/mydomain.com/httpdocs/init.php (61) in require called at /var/www/html/mydomain.com/httpdocs/adaptive.php (51) Expected result: My site frequently down and facing error. -- Edit this bug report at https://bugs.php.net/bug.php?id=64771edit=1
Bug #64763 [Opn-Asn]: unbuffered queries connection problems are not handled by mysqlnd
Edit report at https://bugs.php.net/bug.php?id=64763edit=1
ID: 64763
Updated by: johan...@php.net
Reported by:ihanick at gmail dot com
Summary:unbuffered queries connection problems are not
handled by mysqlnd
-Status: Open
+Status: Assigned
Type: Bug
Package:MySQL related
Operating System: CentOS release 6.4
PHP Version:master-Git-2013-05-02 (snap)
-Assigned To:
+Assigned To:mysql
Block user comment: N
Private report: N
Previous Comments:
[2013-05-02 17:31:51] ihanick at gmail dot com
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 this bug report at https://bugs.php.net/bug.php?id=64763edit=1
Bug #64741 [Opn-Nab]: Various ways to reassign this
Edit report at https://bugs.php.net/bug.php?id=64741edit=1
ID: 64741
Updated by: johan...@php.net
Reported by:php dot bugs at daverandom dot com
Summary:Various ways to reassign this
-Status: Open
+Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
we prevent from mistakes, we don't prevent people from shooting in their feed,
especially as such checks would slow down *all* variable access.
Previous Comments:
[2013-04-30 11:42:15] php dot bugs at daverandom dot com
Description:
The engine prevents userland code from directly reassigning $this with a
compile
time error, but it does not prevent a number of other mechanisms. The following
are all possible:
unset($this);
// ...
public function test()
{
${'th'.'is'} = 'foo';
}
// ...
public function test()
{
$foo = 'this';
$$foo = 'foo';
}
// ...
function ref($arg)
{
$arg = 'foo';
}
public function test()
{
ref($this);
}
Test script:
---
?php
function ref($arg)
{
$arg = 'foo';
}
class ThisReassignments
{
public function test1() { var_dump($this); ${'th'.'is'} = 'foo';
var_dump($this); }
public function test2() { var_dump($this); $foo = 'this'; $$foo =
'foo';; var_dump($this); }
public function test3() { var_dump($this); ref($this); var_dump($this);
}
}
(new ThisReassignments)-test1();
(new ThisReassignments)-test2();
(new ThisReassignments)-test3();
// NB: unset() causes a segmentation fault and doesn't *really* work, but
it should emit a meaningful error
Expected result:
Fatal error with a meaningful error message in all cases
Actual result:
--
object(ThisReassignments)#1 (0) {
}
string(3) foo
object(ThisReassignments)#1 (0) {
}
string(3) foo
object(ThisReassignments)#1 (0) {
}
string(3) foo
--
Edit this bug report at https://bugs.php.net/bug.php?id=64741edit=1
Bug #64718 [Opn-Csd]: mysqlnd redefines macros
Edit report at https://bugs.php.net/bug.php?id=64718edit=1 ID: 64718 Updated by: johan...@php.net Reported by:s...@php.net Summary:mysqlnd redefines macros -Status: Open +Status: Closed Type: Bug Package:MySQL related PHP Version:5.5.0beta4 -Assigned To: +Assigned To:johannes Block user comment: N Private report: N Previous Comments: [2013-04-25 19:19:26] s...@php.net Description: Compiling mysqnd gives: /home/cjones/Desktop/php-5.5.0beta4/ext/mysqlnd/mysqlnd_alloc.c:540:0: warning: SMART_STR_START_SIZE redefined [enabled by default] /home/cjones/Desktop/php-5.5.0beta4/ext/standard/php_smart_str.h:42:0: note: this is the location of the previous definition /home/cjones/Desktop/php-5.5.0beta4/ext/mysqlnd/mysqlnd_alloc.c:541:0: warning: SMART_STR_PREALLOC redefined [enabled by default] /home/cjones/Desktop/php-5.5.0beta4/ext/standard/php_smart_str.h:38:0: note: this is the location of the previous definition -- Edit this bug report at https://bugs.php.net/bug.php?id=64718edit=1
Bug #64742 [Opn-Nab]: float(1) casts to int as 0
Edit report at https://bugs.php.net/bug.php?id=64742edit=1 ID: 64742 Updated by: johan...@php.net Reported by:bondo dot the dot clown at gmail dot com Summary:float(1) casts to int as 0 -Status: Open +Status: Not a bug Type: Bug Package:Math related Operating System: linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is, read this: http://www.floating-point-gui.de/ Thank you for your interest in PHP. 8.95 - 7.95 is not exactly 1 (int) rounds down. $ php -d precision=99 -r 'echo 8.95 - 7.95;' 0.99911182158029987476766109466552734375 Previous Comments: [2013-04-30 14:37:11] bondo dot the dot clown at gmail dot com Description: code speaks for himself php --version PHP 5.4.6-1ubuntu1.2 (cli) (built: Mar 11 2013 14:57:54) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies with XCache v2.0.0, Copyright (c) 2005-2012, by mOo with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans Test script: --- echo (int)(8.95 - 7.95); Expected result: 1 Actual result: -- 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=64742edit=1
Bug #64722 [Fbk]: PDO extension causes zend_mm_heap corrupted
Edit report at https://bugs.php.net/bug.php?id=64722edit=1
ID: 64722
Updated by: johan...@php.net
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:
I can't reproduce this on my machine.
Apparently your PHP is not compiled in threaded mode (no tsrm_ls parameters in
the stacktrace) so I assume you're not in threaded mode, so no race conditions.
Can you share more details on your setup and code?
Previous Comments:
[2013-04-30 14:44:16] tj dot botha at plista dot com
I just want to emphasize - that commenting out the code not a solution - since
it
causes errors later down the line. Also, when stepping / breaking at problem
area through the code - the project starts loading in bits and pieces, no
segfaults occur. Only when left to run without breakpoints does it crash -
therefor this really does seem like a concurrency problem.
[2013-04-30 12:45:41] tj dot botha at plista dot com
This appears to be a race condition - so I am unable to reproduce. I am
however
able to make the problem go away by modifying pdo_dbh.c to the following:
static void pdo_dbh_free_storage(pdo_dbh_t *dbh TSRMLS_DC)
{
if (dbh-in_txn dbh-methods dbh-methods-rollback) {
dbh-methods-rollback(dbh TSRMLS_CC);
dbh-in_txn = 0;
}
if (dbh-is_persistent dbh-methods dbh-methods-
persistent_shutdown) {
dbh-methods-persistent_shutdown(dbh TSRMLS_CC);
}
//uncomment below to cause zend_mm_heap corrupted
//zend_object_std_dtor(dbh-std TSRMLS_CC);
//dbh-std.properties = NULL;
dbh_free(dbh TSRMLS_CC);
}
If I recompile this into PHP it works - however now there is most likely a
memory leak. I checked and this code is also new from PHP 5.3. So definitely
it is causing the fault.
Don't know what the real solution is though.
TJ
[2013-04-26 17:53:01] s...@php.net
Do you have a reproducible testcase?
[2013-04-26 14:48:58] tj dot botha at plista dot com
Description:
I have a project which uses MySQL PDO. I Compiled PHP versions 5.4.6, PHP
5.4.14 and PHP 5.6 (from current GIT repositoty - 26 April 2013).
I have various configuration options, but everytime I my configure command
includes --with-pdo-mysql=mysqlnd, I am unable to run my project.
The ONLY log file which shows any kind of information is Apache error.log:
zend_mm_heap corrupted
When I remove --with-pdo-mysql from configure, then my project works okay
(however all my PDO functions are of course missing) and I just get normal
expected PHP errors.
However. When I compile PHP version 5.3.24, it works. I can successfully
include --with-pdo-mysql=mysqlnd, and my project loads without problems.
Test script:
---
I do not have a test script - as I have no indication as to where the app fails
Actual result:
--
#0 0x008ee2c2 in zval_delref_p (pz=0x5a5a5a5a5a5a5a5a) at /home/tj/php-
latest/Zend/zend.h:409
#1 0x008ee51f in i_zval_ptr_dtor (zval_ptr=0x5a5a5a5a5a5a5a5a,
__zend_filename=0xe38408 /home/tj/php-latest/Zend/zend_objects.c,
__zend_lineno=54)
at /home/tj/php-latest/Zend/zend_execute.h:76
#2 0x008ef896 in _zval_ptr_dtor (zval_ptr=0x7f88d6068a20,
__zend_filename=0xe38408 /home/tj/php-latest/Zend/zend_objects.c,
__zend_lineno=54)
at /home/tj/php-latest/Zend/zend_execute_API.c:428
#3 0x009354de in zend_object_std_dtor (object=0x271b880) at
/home/tj/php-latest/Zend/zend_objects.c:54
#4 0x0068aad0 in pdo_dbh_free_storage (dbh=0x271b880) at /home/tj/php-
latest/ext/pdo/pdo_dbh.c:1576
#5 0x0093c9ad in zend_objects_store_del_ref_by_handle_ex (handle=140,
handlers=0x116c2e0 pdo_dbh_object_handlers)
at /home/tj/php-latest/Zend/zend_objects_API.c:221
#6 0x0093c6b3 in zend_objects_store_del_ref (zobject=0x7f88d60a4af8)
at
/home/tj/php-latest/Zend/zend_objects_API.c:173
#7 0x00901b6c in _zval_dtor_func (zvalue=0x7f88d60a4af8,
__zend_filename=0xe335f8 /home/tj/php-latest/Zend/zend_execute.h,
__zend_lineno=81)
at /home/tj/php-latest/Zend/zend_variables.c:54
#8 0x008ee4c1 in _zval_dtor (zvalue=0x7f88d60a4af8,
__zend_filename=0xe335f8 /home/tj/php-latest/Zend/zend_execute.h,
__zend_lineno=81)
at /home/tj/php-latest/Zend/zend_variables.h:35
#9 0x008ee58c in i_zval_ptr_dtor
Bug #64722 [Fbk]: PDO extension causes zend_mm_heap corrupted
Edit report at https://bugs.php.net/bug.php?id=64722edit=1
ID: 64722
Updated by: johan...@php.net
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:
so, the new backtrace has tsrm symbols, so what environment are you
using?8which web server,sapi, ...) Why threaded context?
And please try using helgrind (valgrind --tool=helgrind) with the server, this
should show details on race conditions.
Previous Comments:
[2013-04-30 15:07:35] tj dot botha at plista dot com
Also - some additional info which may help:
(gdb) frame 3
#3 0x7fffeb3e0056 in pdo_dbh_free_storage (dbh=0x7fffd00f56c0,
tsrm_ls=0x7fffd0017170) at /home/tj/php-5.4.14/ext/pdo/pdo_dbh.c:1577
1577zend_object_std_dtor(dbh-std TSRMLS_CC);
(gdb) print dbh-std
$1 = {ce = 0x7fffd6d3afc0, properties = 0x0, properties_table = 0x7fffd6d39378,
guards = 0x0}
(gdb)
and
for source_code/Zend/zend_objects.c:37 to 59:
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);
}
}
(gdb) print object-properties_table[0]
$2 = (zval *) 0x5a5a5a5a5a5a5a5a
(gdb) print object-properties_table[0]
$3 = (zval **) 0x7fffd6d39378
(gdb) print object-ce-default_properties_count
$4 = 2
(gdb) print i
$5 = 0
(gdb)
Not sure if this loop is thread safe:
for (i = 0; i object-ce-default_properties_count; i++) {
if (object-properties_table[i]) {
zval_ptr_dtor(object-properties_table[i]);
}
}
Thanks for your help!
[2013-04-30 15:01:07] tj dot botha at plista dot com
That is an old backtrace - here is the newest:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd8fe9700 (LWP 31920)]
0x7fffeb6a5722 in zval_delref_p (pz=0x5a5a5a5a5a5a5a5a) at /home/tj/php-
5.4.14/Zend/zend.h:395
395 return --pz-refcount__gc;
(gdb) backtrace
#0 0x7fffeb6a5722 in zval_delref_p (pz=0x5a5a5a5a5a5a5a5a) at /home/tj/php-
5.4.14/Zend/zend.h:395
#1 0x7fffeb6a7d06 in _zval_ptr_dtor (zval_ptr=0x7fffd6d39378,
__zend_filename=0x7fffebb88468 /home/tj/php-5.4.14/Zend/zend_objects.c,
__zend_lineno=54)
at /home/tj/php-5.4.14/Zend/zend_execute_API.c:432
#2 0x7fffeb6f258a in zend_object_std_dtor (object=0x7fffd00f56c0,
tsrm_ls=0x7fffd0017170) at /home/tj/php-5.4.14/Zend/zend_objects.c:54
#3 0x7fffeb3e0056 in pdo_dbh_free_storage (dbh=0x7fffd00f56c0,
tsrm_ls=0x7fffd0017170) at /home/tj/php-5.4.14/ext/pdo/pdo_dbh.c:1577
#4 0x7fffeb6fac18 in zend_objects_store_del_ref_by_handle_ex (handle=122,
handlers=0x7fffebeb8a20 pdo_dbh_object_handlers, tsrm_ls=0x7fffd0017170)
at /home/tj/php-5.4.14/Zend/zend_objects_API.c:221
#5 0x7fffeb6fa759 in zend_objects_store_del_ref (zobject=0x7fffd6d240e0,
tsrm_ls=0x7fffd0017170) at /home/tj/php-5.4.14/Zend/zend_objects_API.c:173
#6 0x7fffeb6baacd in _zval_dtor_func (zvalue=0x7fffd6d240e0,
__zend_filename=0x7fffebb83be8 /home/tj/php-5.4.14/Zend/zend_execute_API.c,
__zend_lineno=438)
at /home/tj/php-5.4.14/Zend/zend_variables.c:54
#7 0x7fffeb6a58c1 in _zval_dtor (zvalue=0x7fffd6d240e0,
__zend_filename=0x7fffebb83be8 /home/tj/php-5.4.14/Zend/zend_execute_API.c,
__zend_lineno=438)
at /home/tj/php-5.4.14/Zend/zend_variables.h:35
#8 0x7fffeb6a7da9 in _zval_ptr_dtor (zval_ptr=0x7fffd6bee268,
__zend_filename=0x7fffebb84cb0 /home/tj/php-5.4.14/Zend/zend_variables.c,
__zend_lineno=182)
at /home/tj/php-5.4.14/Zend/zend_execute_API.c:438
#9 0x7fffeb6baef5 in _zval_ptr_dtor_wrapper (zval_ptr=0x7fffd6bee268) at
/home/tj/php-5.4.14/Zend/zend_variables.c:182
#10 0x7fffeb6d3281 in zend_hash_destroy (ht=0x7fffd6d39768) at /home/tj/php-
5.4.14/Zend/zend_hash.c:560
#11 0x7fffeb6baa76 in
Bug #64726 [Opn-Asn]: Segfault when calling fetch_object on a use_result and DB pointer has closed
Edit report at https://bugs.php.net/bug.php?id=64726edit=1
ID: 64726
Updated by: johan...@php.net
Reported by:justin at eblah dot com
Summary:Segfault when calling fetch_object on a use_result
and DB pointer has closed
-Status: Open
+Status: Assigned
Type: Bug
Package:MySQLi related
Operating System: CentOS 5.9
PHP Version:5.4.14
-Assigned To:
+Assigned To:mysql
Block user comment: N
Private report: N
Previous Comments:
[2013-04-26 17:46:11] justin at eblah dot com
Reworded summary.
[2013-04-26 17:35:58] justin at eblah dot com
Description:
When using MYSQLI_USE_RESULT, then immediately closing the database, and then
attempting to fetch_object() the result will result in a segmentation fault.
PHP does not segfault if using fetch_array() or fetch_assoc().
Test script:
---
?php
$db = new mysqli(127.0.0.1, root, root, test);
$result = $db-query('SELECT 1', MYSQLI_USE_RESULT);
$db-close();
$result-fetch_object();
Expected result:
An exception or php fatal error that states the database was closed.
Actual result:
--
[root@devz user]# /usr/bin/php segfault.php
Warning: mysqli_result::fetch_object(): Error while reading a row in
segfault.php on line 15
Segmentation fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=64726edit=1
Bug #64719 [Opn-Nab]: simplexml not show farsi or arabic
Edit report at https://bugs.php.net/bug.php?id=64719edit=1 ID: 64719 Updated by: johan...@php.net Reported by:hooman6445 at gmail dot com Summary:simplexml not show farsi or arabic -Status: Open +Status: Not a bug Type: Bug Package:SimpleXML related PHP Version:5.4.14 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php ISO-8859-1 doesn't contain Ù and similar characters. Probably you have to set the file's encoding to utf-8. Previous Comments: [2013-04-26 09:04:31] hooman6445 at gmail dot com Description: --- From manual page: http://www.php.net/function.simplexml-load-file#refsect1- function.simplexml-load-file-examples --- Test script: --- ?php $xmlstring = XML ?xml version=1.0 encoding=ISO-8859-1? note toÙÙÙ Ù/to fromÙ Ù/from headingباگ/heading bodyاÛÙ ÙØ§Ø±Ø³Û Ûا Ø¹Ø±Ø¨Û Ø³Ø§Ù¾Ø±Øª ÙÙ ÛÚ©ÙÙ./body /note XML; $xml = simplexml_load_string($xmlstring); var_dump($xml); ? Expected result: object(SimpleXMLElement)[1] public 'to' = string 'ÙÙÙ Ù' (length=16) public 'from' = string 'Ù Ù' (length=8) public 'heading' = string 'باگ' (length=12) public 'body' = string 'اÛÙ ÙØ§Ø±Ø³Û Ûا Ø¹Ø±Ø¨Û Ø³Ø§Ù¾Ø±Øª ÙÙ ÛÚ©ÙÙ.' (length=106) Actual result: -- object(SimpleXMLElement)[1] public 'to' = string 'Ãâ¢Ãâ¡Ãâ¢ÃËÃâ¢Ãâ¦Ãâ¢Ãâ ' (length=16) public 'from' = string 'Ãâ¢Ãâ¦Ãâ¢Ãâ ' (length=8) public 'heading' = string 'ÃËèÃËçÚï' (length=12) public 'body' = string 'ÃËçÃâºÃÅÃâ¢Ãâ Ãâ¢ÃÂÃËçÃËñÃËóÃâºÃÅ ÃâºÃÅÃËç ÃËùÃËà ±ÃËèÃâºÃÅ ÃËóÃËçÃâ¢Ã¾ÃËñÃËê Ãâ¢Ãâ Ãâ¢Ãâ¦ÃâºÃÅÚéÃâ¢Ãâ Ãâ¢Ãâ¡.' (length=106) -- Edit this bug report at https://bugs.php.net/bug.php?id=64719edit=1
Bug #64689 [Opn-Nab]: _SERVER[SCRIPT_NAME] incorrectly evaluated
Edit report at https://bugs.php.net/bug.php?id=64689edit=1 ID: 64689 Updated by: johan...@php.net Reported by:admin at 3dr dot org Summary:_SERVER[SCRIPT_NAME] incorrectly evaluated -Status: Open +Status: Not a bug Type: Bug Package:FPM related Operating System: FreeBSD 9.1 PHP Version:5.3Git-2013-04-22 (Git) Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php $_SERVER variables are passed by the server, PHP doesn't touch it. Previous Comments: [2013-04-22 08:40:42] admin at 3dr dot org Description: I use mod_proxy_fcgi along with FPM: ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://172.16.0.11:1007/home/admin/domains/domenaadmina.fulo.inten.pl/public_htm l/$1 timeout=180 Using scripts like this: /glowna/index.php/aaa/bbb/ccc causes _SERVER[SCRIPT_NAME] to be wrongly evaluated. Instead of /glowna/index.php FPM returns /glowna/index.php/aaa/bbb/ccc which obviously also destroys _SERVER[PHP_SELF]. We've checked it with cgi.fix_pathinfo = 0 (no input file specified error) and cgi.fix_pathinfo = 1. proxy-fcgi-pathinfo = 1 doesn't help to. Expected result: _SERVER[REQUEST_URI] /glowna/index.php/aaa/bbb/ccc _SERVER[SCRIPT_NAME] /glowna/index.php _SERVER[PATH_INFO]/aaa/bbb/ccc _SERVER[ORIG_SCRIPT_FILENAME] /home/admin/domains/domenaadmina.fulo.inten.pl/public_html/glowna/index.php/aaa/bb b/ccc _SERVER[PATH_TRANSLATED] /home/admin/domains/domenaadmina.fulo.inten.pl/public_html/aaa/bbb/ccc _SERVER[PHP_SELF] /glowna/index.php/aaa/bbb/ccc Actual result: -- _SERVER[REQUEST_URI] /glowna/index.php/aaa/bbb/ccc _SERVER[SCRIPT_NAME] /glowna/index.php/aaa/bbb/ccc _SERVER[PATH_INFO]/aaa/bbb/ccc _SERVER[ORIG_SCRIPT_FILENAME] /home/admin/domains/domenaadmina.fulo.inten.pl/public_html/glowna/index.php/aaa/bb b/ccc _SERVER[PATH_TRANSLATED] /home/admin/domains/domenaadmina.fulo.inten.pl/public_html/aaa/bbb/ccc _SERVER[PHP_SELF] /glowna/index.php/aaa/bbb/ccc/aaa/bbb/ccc -- Edit this bug report at https://bugs.php.net/bug.php?id=64689edit=1
Bug #64682 [Opn-Nab]: failing to add 0.001 multiple times
Edit report at https://bugs.php.net/bug.php?id=64682edit=1
ID: 64682
Updated by: johan...@php.net
Reported by:easteregg at verfriemelt dot org
Summary:failing to add 0.001 multiple times
-Status: Open
+Status: Not a bug
Type: Bug
Package:Math related
Operating System: Linux and Windows
PHP Version:5.4.14
Block user comment: N
Private report: N
New Comment:
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about floats and what IEEE
754 is, read this:
http://www.floating-point-gui.de/
Thank you for your interest in PHP.
.
Previous Comments:
[2013-04-20 07:42:15] easteregg at verfriemelt dot org
Description:
Hi,
first some informations: vanilla php 5.4.14 without any changes from your
website, and a php 5.4.13 on a linux host.
C:\Users\Administratorphp -v
PHP 5.4.12 (cli) (built: Feb 19 2013 21:26:17)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
root@verfriemelt:~# php -v
PHP 5.4.13-1~dotdeb.1 (cli) (built: Mar 21 2013 08:29:56)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
i have a number like 8 and add 0.001 while this number reaches 11. i suspected
the numbers in between should look like 8.999 and 10.743 but instead i got some
like this:
8.98999
and i noticed a gap between some numbers.
eg:
8.09 + 0.001 equals 8.0909
i suspected a problem with my linux box and tested it with my windows
workstation, same result. so i guess its a php internal error.
this doest not occur, when i simple add 0.001 to 8.09 so i guess it has
something to do with the for()
Test script:
---
?php
for ($i = 8; $i 11; $i += 0.001) {
echo $i . \n;
}
Expected result:
[...]
8.08
8.081
8.082
8.083
8.084
8.085
8.086
8.087
8.088
8.089
8.09
8.091
8.092
8.093
8.094
8.095
8.096
8.097
8.098
8.099
8.1
[...]
Actual result:
--
8.08
8.081
8.082
8.083
8.084
8.085
8.086
[...]
8.087
8.088
8.089
8.09
8.09099
8.09199
8.09299
8.09399
8.09499
8.09599
8.09699
8.09799
8.09899
8.0
8.10099
[...]
--
Edit this bug report at https://bugs.php.net/bug.php?id=64682edit=1
Bug #64668 [Opn-Nab]: Casting from string containing exponential notation number to int
Edit report at https://bugs.php.net/bug.php?id=64668edit=1 ID: 64668 Updated by: johan...@php.net Reported by:biowep at gmail dot com Summary:Casting from string containing exponential notation number to int -Status: Open +Status: Not a bug Type: Bug Package:*Programming Data Structures Operating System: Windows 7 x64 SP1 PHP Version:5.4.14 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php the cast from string to int cuts the number of on the first non-digit (essentially using the system's atoi() function) this is expected behavior. Previous Comments: [2013-04-18 17:34:06] biowep at gmail dot com Description: When trying to cast a numeric string value in the exponential notation to int, the result doesn't match with the initial value. While the casting to float from string works well. Also casting to int from the same value stored in a float variable workes well. The function intval() has the same problem. Test script: --- ?php echo 1E2 . br /; echo (float)1E2 . br /; echo (int)1E2 . br /; echo intval(1E2) . br /; echo (float)1E2 . br /; echo (int)1E2 . br /;//problem echo intval(1E2) . br /;//problem ? Expected result: 100 100 100 100 100 100 100 Actual result: -- 100 100 100 100 100 1 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=64668edit=1
Bug #64636 [Fbk]: Segfault in scan from parse_date.c
Edit report at https://bugs.php.net/bug.php?id=64636edit=1
ID: 64636
Updated by: johan...@php.net
Reported by:shakaran at gmail dot com
Summary:Segfault in scan from parse_date.c
Status: Feedback
Type: Bug
Package:Apache2 related
Operating System: Centos 5.9
PHP Version:5.3.24
Block user comment: N
Private report: N
New Comment:
Also please make sure this is not cpanel related (see also bug #64635)
Previous Comments:
[2013-04-12 04:15:04] 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-04-11 20:39:59] shakaran at gmail dot com
Another more different in this stacktrace:
(gdb) where
#0 0x2b657d1ed073 in scan (s=0x17560ea0 imap_header, len=value
optimized
out, errors=0x17560ea0, tzdb=0xd,
tz_get_wrapper=0x7fffcff08628) at /home/cpeasyapache/src/php-
5.3.23/ext/date/lib/parse_date.c:8374
#1 timelib_strtotime (s=0x17560ea0 imap_header, len=value optimized out,
errors=0x17560ea0, tzdb=0xd, tz_get_wrapper=0x7fffcff08628)
at /home/cpeasyapache/src/php-5.3.23/ext/date/lib/parse_date.c:24730
#2 0x in ?? ()
(gdb) thread apply all bt full
Thread 1 (Thread 0x2b657d0cdb40 (LWP 2470)):
#0 0x2b657d1ed073 in scan (s=0x17560ea0 imap_header, len=value
optimized
out, errors=0x17560ea0, tzdb=0xd,
tz_get_wrapper=0x7fffcff08628) at /home/cpeasyapache/src/php-
5.3.23/ext/date/lib/parse_date.c:8374
yych = value optimized out
yyaccept = 0
cursor = value optimized out
str = 0x17560ea0 imap_header
ptr = 0x17556590
yybm = \000\000\000\000\000\000\000\000\000d, '\000' repeats 22
times,
d\000\000\000\000\000\000\000\000\000\000\200@\240`\000\002\002\002\002\002\002
\002\002\002\002\000\000\000\000\000\000\000, '\b' repeats 26 times,
\000\000\000\000\000\000\030\030\030X\030\030\030X\030\030\030\030\030X\030\030
\030XXX\030\030\030\030\030\030, '\000' repeats 132 times
#1 timelib_strtotime (s=0x17560ea0 imap_header, len=value optimized out,
errors=0x17560ea0, tzdb=0xd, tz_get_wrapper=0x7fffcff08628)
at /home/cpeasyapache/src/php-5.3.23/ext/date/lib/parse_date.c:24730
in = {fd = 0, lim = 0x0, str = 0x17560ea0 imap_header, ptr =
0x51615639 Address 0x51615639 out of bounds,
cur = 0xd Address 0xd out of bounds, tok = 0x2b657da43e1c
dns_get_record, pos = 0x2b657dde8320 , line = 2099173936, len = 11109,
errors = 0x30ed950031, time = 0x7fffcff08510, tzdb = 0x0}
e = value optimized out
#2 0x in ?? ()
No symbol table info available.
[2013-04-11 20:36:52] shakaran at gmail dot com
Description:
I am using cPanel with cpeasyapache and php 5.3.23.
I get a apache core file when parse_date.c: is used in scan.
I start gdb in the core file showing this:
# gdb /usr/local/apache/bin/httpd core.5886
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/local/apache/bin/httpd...(no debugging symbols
found)...done.
[New Thread 5886]
warning: .dynamic section for /usr/lib64/libldap-2.3.so.0 is not at the
expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for /usr/lib64/liblber-2.3.so.0 is not at the
expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for /lib64/libssl.so.6 is not at the expected
address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for /lib64/libcrypto.so.6 is not at the expected
address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for /usr/lib64/libz.so.1 is not at the expected
address
warning: difference appears to be caused by prelink, adjusting expectations
Bug #64628 [Opn-Nab]: Tenere not working
Edit report at https://bugs.php.net/bug.php?id=64628edit=1 ID: 64628 Updated by: johan...@php.net Reported by:robin at dragonito dot net Summary:Tenere not working -Status: Open +Status: Not a bug Type: Bug Package:Variables related Operating System: Windows / Unix PHP Version:5.4.13 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is a design bug we can't fix anymore. use parenthesis. Previous Comments: [2013-04-11 07:41:24] robin at dragonito dot net changed Package to variable dont find operators [2013-04-11 07:35:01] robin at dragonito dot net Description: The tenere does not the same as c style! I should by the same. Im working on language plural problems and found this while looking for examples to find out right plurals for some languages. Got the tenere from here: http://docs.translatehouse.org/projects/localization-guide/en/latest/l10n/pluralforms.html?id=l10n/pluralforms In my example its for russian language. See $cstyled for wrong result and $workaround for the right result. In $cstyled it doesnt the result 1 instead its 2. Perhaps php does not c-style in this case, but i think its not correct how its results comming in this example. Test script: --- $cstyled = ($zahl%10==1 $zahl%100!=11 ? 0 : $zahl%10=2 $zahl%10=4 ($zahl%10010 || $zahl%100=20) ? 1 : 2); $workaround= ($zahl%10==1 $zahl%100!=11 ? 0 : ($zahl%10=2 $zahl%10=4 ($zahl%10010 || $zahl%100=20) ? 1 : 2)); -- Edit this bug report at https://bugs.php.net/bug.php?id=64628edit=1
Bug #64592 [Asn-Opn]: ReflectionClass::getMethods() returns methods out of scope
Edit report at https://bugs.php.net/bug.php?id=64592edit=1 ID: 64592 Updated by: johan...@php.net Reported by:benjamin dot morel at gmail dot com Summary:ReflectionClass::getMethods() returns methods out of scope -Status: Assigned +Status: Open Type: Bug Package:Reflection related Operating System: Linux PHP Version:5.4.13 Assigned To:johannes Block user comment: N Private report: N New Comment: In general reflection in PHP leaks the truth by not hiding implementation details. This falls into this category. Telling the truth is nice for maintainers but not really for users. We can't change it in released (or feature frozen) versions so 5.6 might be an option. For that we might collect more such cases and think about ringing Reflection on some higher level of abstraction. Previous Comments: [2013-04-07 12:53:40] fel...@php.net Hey Johannes, what do you think about this behavior? Since reflection has worked in this way for a long time... [2013-04-06 16:25:28] benjamin dot morel at gmail dot com @felipe, did you read the bug before closing it? We're not talking about not accessible, but not in scope. This is totally different. The fact is, if you run my example, getMethods() and getProperties() do not behave in the same way, thus either this is a bug in getMethods(), and if not, this is a bug in getProperties(). But I'm pretty sure it's getProperties() that behaves correctly here. Could you please comment on this? [2013-04-06 15:27:46] fel...@php.net It is not intended to just show the accessible ones, hence we already have introduced method like ReflectionMethod::setAccessible(). [2013-04-06 15:11:19] benjamin dot morel at gmail dot com Works like a charm with your patch, thanks! Any chance that gets into 5.4, or at least 5.5 (if there is a fear of breaking BC with existing libraries that would rely on this behaviour)? [2013-04-06 13:19:41] larue...@php.net The following patch has been added/updated: Patch Name: bug64592.patch Revision: 1365254381 URL: https://bugs.php.net/patch-display.php?bug=64592patch=bug64592.patchrevision=1365254381 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=64592 -- Edit this bug report at https://bugs.php.net/bug.php?id=64592edit=1
Bug #64592 [Asn-Opn]: ReflectionClass::getMethods() returns methods out of scope
Edit report at https://bugs.php.net/bug.php?id=64592edit=1 ID: 64592 Updated by: johan...@php.net Reported by:benjamin dot morel at gmail dot com Summary:ReflectionClass::getMethods() returns methods out of scope -Status: Assigned +Status: Open Type: Bug Package:Reflection related Operating System: Linux PHP Version:5.4.13 -Assigned To:johannes +Assigned To: Block user comment: N Private report: N Previous Comments: [2013-04-08 08:04:23] johan...@php.net In general reflection in PHP leaks the truth by not hiding implementation details. This falls into this category. Telling the truth is nice for maintainers but not really for users. We can't change it in released (or feature frozen) versions so 5.6 might be an option. For that we might collect more such cases and think about ringing Reflection on some higher level of abstraction. [2013-04-07 12:53:40] fel...@php.net Hey Johannes, what do you think about this behavior? Since reflection has worked in this way for a long time... [2013-04-06 16:25:28] benjamin dot morel at gmail dot com @felipe, did you read the bug before closing it? We're not talking about not accessible, but not in scope. This is totally different. The fact is, if you run my example, getMethods() and getProperties() do not behave in the same way, thus either this is a bug in getMethods(), and if not, this is a bug in getProperties(). But I'm pretty sure it's getProperties() that behaves correctly here. Could you please comment on this? [2013-04-06 15:27:46] fel...@php.net It is not intended to just show the accessible ones, hence we already have introduced method like ReflectionMethod::setAccessible(). [2013-04-06 15:11:19] benjamin dot morel at gmail dot com Works like a charm with your patch, thanks! Any chance that gets into 5.4, or at least 5.5 (if there is a fear of breaking BC with existing libraries that would rely on this behaviour)? 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=64592 -- Edit this bug report at https://bugs.php.net/bug.php?id=64592edit=1
Req #19621 [Csd]: Math needs a sign() function
Edit report at https://bugs.php.net/bug.php?id=19621edit=1
ID: 19621
Updated by: johan...@php.net
Reported by:bill at softky dot com
Summary:Math needs a sign() function
Status: Closed
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: Mandrake linux
PHP Version:4.2.0
-Assigned To:
+Assigned To:johannes
Block user comment: N
Private report: N
New Comment:
For usort() this is not needed. function($a,$b) { return $a['age'] - $b['age'];
} is fine.
Previous Comments:
[2013-04-04 15:22:54] php at yopmail dot com
sign is very usefull in usort function
exemple :
?php
$people = [
[name=John,age=20],
[name=Jack,age=30],
[name=Paul,age=25],
]
usort($people,function($a, $b){
return sign($a['age'] - $b['age']);
});
?
[2011-09-26 14:30:22] tom at kera dot name
Patrick, adding a new library function _absolutely_ breaks BC.
For example:
?php
function abs($x) {
return 3;
}
// Output: Fatal error: Cannot redeclare abs()
?
Do you want every script that declares a function `sign` to suddenly not work
any more? How would this *not* be a compatibility issue?
[2011-04-09 16:51:11] bogdan at moongate dot ro
Seconded. I've always rolled my own in PHP, but this is typically used in small
loops executed a lot, so moving this logic into the PHP core would probably
make a difference. If you're concerned sign() might already be used by various
existing scripts, why not implement is as the more math-like sgn()?
[2011-02-25 10:14:51] patrick at ibuildings dot nl
I also searched for a sign() function and ended up here. But I disagree with
Andrey's arguments not to include it into PHP.
Since when is it a policy to *not* include a function, simply because it does
not exist in a number of other languages? Doesn't PHP have its own 'vision'?
Secondly, a new function should not break BC.
As Bill stated, it would complement the abs() function and make the Math list a
more complete list, even though it's a simple function. It seems a better idea
to me to add sign() then let's say goto.
[2002-10-03 02:32:28] and...@php.net
Quick search showed that there is no well know scripting language that has such
function. C++/C# has this but they are not scripting languages.
The following code does the same. Also we have to think about BC(backward
compatibility) with older scripts.
function sign($x){
return (int)((abs($x)-$x)? -1:$x0);
}
Thank you for you suggestion.
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=19621
--
Edit this bug report at https://bugs.php.net/bug.php?id=19621edit=1
Bug #64582 [Opn]: file_get_contents() handles redirects wrong
Edit report at https://bugs.php.net/bug.php?id=64582edit=1
ID: 64582
Updated by: johan...@php.net
Reported by:spam2 at rhsoft dot net
Summary:file_get_contents() handles redirects wrong
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
RFC 2616 Section 14.30 requires a single absolute URI. for the location
header. Any relative location is not standards compliant.
Previous Comments:
[2013-04-04 14:55:58] spam2 at rhsoft dot net
Description:
[line 182] [id 950103] [msg path traversal attack] [data ../] [hostname
test.test.rh] [uri /contentlounge/updateservice/cms_demo/cms//../cms.php]
[unique_id UV2MrQoAAGMAAE356XkF]
in the folder /cms is a simple index.php with header('Location: ../cms.php');
every normal browser translates path and does not trigger modsec
php triggers the path traversal-rule
Expected result:
call the URL /contentlounge/updateservice/cms_demo/cms/cms.php
Actual result:
--
calling the URL /contentlounge/updateservice/cms_demo/cms//../cms.php
--
Edit this bug report at https://bugs.php.net/bug.php?id=64582edit=1
Bug #64568 [Fbk]: opcache no loadable
Edit report at https://bugs.php.net/bug.php?id=64568edit=1
ID: 64568
Updated by: johan...@php.net
Reported by:bugzilla77 at gmail dot com
Summary:opcache no loadable
Status: Feedback
Type: Bug
Package:opcache
Operating System: windows
PHP Version:5.5.0beta1
Block user comment: N
Private report: N
New Comment:
extension loads PHP modules, zend_extension loads Zend extensions. Those
are different things so there are different directives.
Previous Comments:
[2013-04-03 06:42:48] bugzilla77 at gmail dot com
Works,
but ini syntax for dlls is: extension=
not
zend_extension=
[2013-04-02 21:22:51] s...@php.net
Try Beta 2 and use zend_extension=php_opcache.dll
[2013-04-02 19:48:14] bugzilla77 at gmail dot com
Description:
opcache no loadable
Test script:
---
php.ini add: extension=php_opcache.dll
Expected result:
opcache in phpinfo()
extension_loaded('opcache') returns true
Actual result:
--
no opcache in phpinfo()
extension_loaded('opcache') returns false
--
Edit this bug report at https://bugs.php.net/bug.php?id=64568edit=1
Bug #64568 [Fbk-Nab]: opcache no loadable
Edit report at https://bugs.php.net/bug.php?id=64568edit=1
ID: 64568
Updated by: johan...@php.net
Reported by:bugzilla77 at gmail dot com
Summary:opcache no loadable
-Status: Feedback
+Status: Not a bug
Type: Bug
Package:opcache
Operating System: windows
PHP Version:5.5.0beta1
Block user comment: N
Private report: N
New Comment:
There are a few differences, many you won'T really notice (load order,
available internal hooks, ...) and some user notable (you can't use dl() on
Zend Extensions, there's different reflection, ...) which won't allow easy
unification. Especially as there are logical differences (Zend Extensions are
loaded by and into the engine, and the engine is more or less independent from
PHP where PHP extensions (modules) are loaded.
We'll most likely improve the error reporting in this situation:
http://news.php.net/php.internals/66909 everything else require major
refactoring.
Closing this issue.
Previous Comments:
[2013-04-03 11:00:21] bugzilla77 at gmail dot com
Add dll automatic detection (extension / Zend extension) for syntax unification.
From the user point view there is no difference.
[2013-04-03 08:23:55] johan...@php.net
extension loads PHP modules, zend_extension loads Zend extensions. Those
are different things so there are different directives.
[2013-04-03 06:42:48] bugzilla77 at gmail dot com
Works,
but ini syntax for dlls is: extension=
not
zend_extension=
[2013-04-02 21:22:51] s...@php.net
Try Beta 2 and use zend_extension=php_opcache.dll
[2013-04-02 19:48:14] bugzilla77 at gmail dot com
Description:
opcache no loadable
Test script:
---
php.ini add: extension=php_opcache.dll
Expected result:
opcache in phpinfo()
extension_loaded('opcache') returns true
Actual result:
--
no opcache in phpinfo()
extension_loaded('opcache') returns false
--
Edit this bug report at https://bugs.php.net/bug.php?id=64568edit=1
Bug #64534 [Opn-Nab]: Bad transfer variable from double to integer with specific number
Edit report at https://bugs.php.net/bug.php?id=64534edit=1 ID: 64534 Updated by: johan...@php.net Reported by:izolex4 at gmail dot com Summary:Bad transfer variable from double to integer with specific number -Status: Open +Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.3Git-2013-03-27 (Git) Block user comment: N Private report: N New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is, read this: http://www.floating-point-gui.de/ Thank you for your interest in PHP. . Previous Comments: [2013-03-27 15:16:12] izolex4 at gmail dot com Description: I have variable with type double with value 16.90 or 17.90 or 18.90 or 19.90. Now multiply variable x 100 and now set type of variable to integer with function settype and print this variable. Result will for example: 1989, even that correct result is 1990. This make only, when original value is 16.90 or 17.90 or 18.90 or 19.90. If is original value another (for example 10.90 or 19.80), result will be correct (for example 1090 or 1980), but now is result incorrect for example 1989. Test script: --- ?php $double = 19.90; // Only 16.90 or 17.90 or 18.90 or 19.90 will print bad result $integer = $double*100; // Now is value 1990 settype($integer, 'integer'); // This change value to 1989 - bug echo $integer; Expected result: Value of integer - 1990 Actual result: -- Value of integer - 1989 -- Edit this bug report at https://bugs.php.net/bug.php?id=64534edit=1
Bug #64411 [Opn-Nab]: ?(question sign) in mysql query comment
Edit report at https://bugs.php.net/bug.php?id=64411edit=1
ID: 64411
Updated by: johan...@php.net
Reported by:pingvein at gmail dot com
Summary:?(question sign) in mysql query comment
-Status: Open
+Status: Not a bug
Type: Bug
Package:PDO related
Operating System: Linux debian 3.2.0-4-amd64 #1 SM
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is a limitation in PDO's parser.This can't easily be fixed as people might
rely on it (in workarounds etc.) and as the parser would have to become driver
and database version-specific
Previous Comments:
[2013-03-14 14:12:01] pingvein at gmail dot com
Change Package
[2013-03-12 09:54:12] pingvein at gmail dot com
Description:
question sign in sql comment perceived as a parameter.
Test script:
---
?php
$dbhost ='localhost';
// username and password to log onto db server
$dbuser ='root';
$dbpass ='test';
// name of database
$dbname='test';
//Charset
$sqlchar='utf8';
$db = new PDO ( 'mysql:host=' . $dbhost . ';dbname=' . $dbname, $dbuser,
$dbpass);
$sth = $db-prepare(SELECT * from users where id = :user /* find user by id
script ?\ */);
$sth-execute(array(':user' = 1));
$sth-fetch();
Expected result:
Exception not thrown
Actual result:
--
Exception is thrown
--
Edit this bug report at https://bugs.php.net/bug.php?id=64411edit=1
Bug #64390 [Opn-Nab]: round() corrupted
Edit report at https://bugs.php.net/bug.php?id=64390edit=1 ID: 64390 Updated by: johan...@php.net Reported by:bugzilla77 at gmail dot com Summary:round() corrupted -Status: Open +Status: Not a bug Type: Bug Package:Math related Operating System: Win 7 PHP Version:5.5.0alpha5 Block user comment: N Private report: N New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is, read this: http://www.floating-point-gui.de/ Thank you for your interest in PHP. . Previous Comments: [2013-03-08 11:45:17] bugzilla77 at gmail dot com Description: Negative zero in mathematics does not exist. Test script: --- ?=round(-0.1)? Expected result: 0 Actual result: -- -0 -- Edit this bug report at https://bugs.php.net/bug.php?id=64390edit=1
Bug #64366 [Opn-Fbk]: php fails to compile with mysq 5.6.x support
Edit report at https://bugs.php.net/bug.php?id=64366edit=1 ID: 64366 Updated by: johan...@php.net Reported by:eugene at zhegan dot in Summary:php fails to compile with mysq 5.6.x support -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: Solaris PHP Version:5.4.12 Block user comment: N Private report: N New Comment: Without looking deeper there are some confusing things about your configuration: 1) ld: warning: file /usr/gcc/4.5/lib/gcc/i386-pc- solaris2.11/4.5.2/libgcc_eh.a(unwind-dw2.o): wrong ELF class: ELFCLASS32 Thnis indicates you're mixing 32 and 64 bit code. So some of the libraries you're trying to pull in seem to be 32 bit, whiel you'Ve added -m64 to the CFLAGS. n case you have fetched MySQL from mysql.com be sure to use the 64bit version when using -m64. 2) --with-mysql=/usr/local/mysql-5.6.10 \ --with-mysqli \ --with-pdo-mysql=/usr/local/mysql --with-pdo-mysql=/usr/local/mysql These are contradicting each other. ext/mysql is being compiled and linked against MySQL from /usr/local/mysql-5.6.10, mysqli is using mysqlnd, PDO_mysql is using /usr/local/mysql. You should stick to one. Suggested is usage of mysqlnd therefore simply using --with-mysql --with-mysqli --with-pdo-mysql 3) CFLAGS=-m64 -O -I/usr/local/freetype/include -I/usr/local/mysql-5.6.10/include -I/usr/local/gmp/include -I/usr/local/openssl/include -I/usr/local/c- client/include LDFLAGS=-R/usr/gcc/4.5/lib/amd64 -L/usr/gcc/4.5/lib/amd64 - R/usr/gcc/4.5/lib/gcc/i386-pc-solaris2.11/4.5.2/amd64 -L/usr /gcc/4.5/lib/gcc/i386-pc-solaris2.11/4.5.2/amd64 -L/usr/local/mysql- 5.6.10/lib/mysql -L/usr/local/gmp/lib -L/usr/local/openssl/lib -L/usr/local/c- client/lib -lstdc++ Most of these paths shouldn't be set manually. Adding -lstdc++ is a bad choice. Except when using the intl extension there should be no C++ in PHP. In case external libraries make use of C++ they should pull in the C++ lib they need. Usually system libraries and MySQL builds by Oracle use Solaris Studio (aka Sun studio) compilers, not gcc. libstdc++ is gcc-specific, though. If there is need to pull in that lib this should happen not by explicitly linking in that lib but by linking using $CXX, not $CC If those hints don't help please reduce the configure line to the minimum options needed for it to break n provide `uname -a` info so we can try to reproduce it. Previous Comments: [2013-03-06 08:12:00] eugene at zhegan dot in Description: PHP fails to compile with mysql 5.6.x support: /bin/sh /home/emz/src/php-5.4.12/libtool --silent --preserve-dup-deps -- mode=link /bin/gcc -export-dynamic -I/usr/include -m64 -O - I/usr/local/freetype/include -I/usr/local/mysql-5.6.10/include - I/usr/local/gmp/include -I/usr/local/openssl/include -I/usr/local/c- client/include -fvisibility=hidden -L/usr/ucblib -L/usr/gcc/4.5/lib/gcc/i386- pc-solaris2.11/4.5.2 -L/usr/local/openssl/lib -L/usr/local/libpng/lib - L/usr/local/mysql-5.6.10/lib -L/usr/local/mysql/lib -g -m64 -R /usr/ucblib -R /usr/gcc/4.5/lib/gcc/i386-pc-solaris2.11/4.5.2 -R /usr/local/openssl/lib -R /usr/local/libpng/lib -R /usr/local/mysql-5.6.10/lib -R /usr/local/mysql/lib Zend/zend_dtrace.d.o ext/date/php_date.lo ext/date/lib/astro.lo ext/date/lib/dow.lo ext/date/lib/parse_date.lo ext/date/lib/parse_tz.lo ext/date/lib/timelib.lo ext/date/lib/tm2unixtime.lo ext/date/lib/unixtime2tm.lo ext/date/lib/parse_iso_intervals.lo ext/date/lib/interval.lo ext/ereg/ereg.lo ext/ereg/regex/regcomp.lo ext/ereg/regex/regexec.lo ext/ereg/regex/regerror.lo ext/ereg/regex/regfree.lo ext/libxml/libxml.lo ext/pcre/pcrelib/pcre_chartables.lo ext/pcre/pcrelib/pcre_ucd.lo ext/pcre/pcrelib/pcre_compile.lo ext/pcre/pcrelib/pcre_config.lo ext/pcre/pcrelib/pcre_exec.lo ext/pcre/pcrelib/pcre_fullinfo.lo ext/pcre/pcrelib/pcre_get.lo ext/pcre/pcrelib/pcre_globals.lo ext/pcre/pcrelib/pcre_maketables.lo ext/pcre/pcrelib/pcre_newline.lo ext/pcre/pcrelib/pcre_ord2utf8.lo ext/pcre/pcrelib/pcre_refcount.lo ext/pcre/pcrelib/pcre_study.lo ext/pcre/pcrelib/pcre_tables.lo ext/pcre/pcrelib/pcre_valid_utf8.lo ext/pcre/pcrelib/pcre_version.lo ext/pcre/pcrelib/pcre_xclass.lo ext/pcre/php_pcre.lo ext/sqlite3/sqlite3.lo ext/sqlite3/libsqlite/sqlite3.lo ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/zlib/zlib_filter.lo ext/bcmath/bcmath.lo ext/bcmath/libbcmath/src/add.lo ext/bcmath/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src/neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/libbcmath/src/raisemod.lo ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/src/sub.lo ext/bcmath/libbcmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src/int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcmath/libbcmath/src/output.lo
Req #64286 [Opn-Nab]: Magic __call() not work through inheritance
Edit report at https://bugs.php.net/bug.php?id=64286edit=1
ID: 64286
Updated by: johan...@php.net
Reported by:joaner1206 at gmail dot com
Summary:Magic __call() not work through inheritance
-Status: Open
+Status: Not a bug
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: Linux 2.6
PHP Version:ä¸çè¾¹é
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
superTest has no access to private elements from any other class.
Previous Comments:
[2013-02-23 17:05:47] joaner1206 at gmail dot com
Description:
When the magic __call() form extends,It can't call the private or protected
function of child class, and worse, it would have been to call its own.
But I watch others magic like __set(), __get(), they will not be affected for
work in child.
Test script:
---
class superTest {
public function __call($func, $param) {
echo Is __call, PHP_EOL;
$this-$func($param);
}
}
final class test extends superTest {
private function hello($i) {
echo hello,world - $i[0], PHP_EOL;
}
/** It will call hello() , only once, everything is fine
public function __call($func, $param) {
echo Is __call in Child, PHP_EOL;
$this-$func($param);
} */
}
$test = new test();
$test-hello(1);
Expected result:
Is __call
Hello,world - 1
Actual result:
--
Is __call
Is __call
Is __call
Is __call
Is __call
Is __call
Is __call
...
// stack exception
--
Edit this bug report at https://bugs.php.net/bug.php?id=64286edit=1
Req #64266 [Opn-Nab]: Pass arrays as reference by default
Edit report at https://bugs.php.net/bug.php?id=64266edit=1
ID: 64266
Updated by: johan...@php.net
Reported by:stormbyte at gmail dot com
Summary:Pass arrays as reference by default
-Status: Open
+Status: Not a bug
Type: Feature/Change Request
Package:*General Issues
Operating System: Linux
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
C has no references, but pointers which are a quite different concept. Pass by
pointer is neccessary in C to allow maximum performance. In PHP we have copy on
write and prefer more intuitive APIs. When reading foo($variable) it is unclear
whether $variable will be read only or manipulated, which makes reading code
harder. By defaulting to copies this is lost.
Also mind that objects are not passed by reference but by handle.
To learn more please see
http://php.net/manual/en/language.references.php
http://php.net/manual/en/features.gc.refcounting-basics.php
http://php.net/manual/en/language.oop5.references.php
http://schlueters.de/blog/archives/125-Do-not-use-PHP-references.html
Previous Comments:
[2013-02-21 14:22:39] stormbyte at gmail dot com
Description:
One of major benefits from PHP is that it is very close to C/C++ style, so it
is its functions and coding style (very similar for, while and those
constructs) so if you come from C/C++ world, you have it easy.
To keep this consistence I suggest, as well as C/C++ does, passing arrays as
reference in function arguments by default, or at least an option to behave
like that.
For me, it does not make much sense to follow C/C++ coding styles and
behaviour, while not following that behaviour.
Furthermore, objects are already passed by reference as default, so why not
arrays? IMHO I think that inconsistence may confuse programmers.
Test script:
---
function foo($arr) {
array_push($arr, test);
}
function bar($arr) {
array_push($arr, test);
}
$a=array();
foo($a);
//$a is empty
bar($a);
//$a[0]=test
Expected result:
To be consistent with the rest behaviour of imitating C/C++ and pass arrays
as reference automatically as well as objects are.
Also, it may be a performance gain by doing that (which is one of the reasons
in C world it is that way)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64266edit=1
Bug #60840 [Asn-Csd]: undefined symbol: mysqlnd_debug_std_no_trace_funcs
Edit report at https://bugs.php.net/bug.php?id=60840edit=1 ID: 60840 Updated by: johan...@php.net Reported by:public at grik dot net Summary:undefined symbol: mysqlnd_debug_std_no_trace_funcs -Status: Assigned +Status: Closed Type: Bug Package:PDO related Operating System: linux PHP Version:5.4SVN-2012-01-22 (snap) Assigned To:mysql Block user comment: N Private report: N New Comment: Automatic comment on behalf of johan...@schlueters.de Revision: http://git.php.net/?p=php-src.git;a=commit;h=064c62e4cf078cf08a40478dfe0e64bd51789e57 Log: Fix #60840 (undefined symbol: mysqlnd_debug_std_no_trace_funcs) Previous Comments: [2013-02-19 23:35:55] johan...@php.net The following patch has been added/updated: Patch Name: bug60840.diff Revision: 1361316955 URL: https://bugs.php.net/patch-display.php?bug=60840patch=bug60840.diffrevision=1361316955 [2012-10-29 16:03:05] johan...@php.net public at grik dot net, the issue is when building the extensions shared we can't decide what to do with mysqlnd, should that be built-in or shared, too? Or maybe the user has a different mysqlnd? - We leave this to the user. [2012-06-14 10:03:03] public at grik dot net Johannes, thanks for the response, but according to http://php.net/ChangeLog-5.php ext/mysql, mysqli and pdo_mysql now use mysqlnd by default. in 5.4 So the issues are: 1. Why should we explicitly enable the feature used by default? 2. How can we NOT use mysqlnd in debug mode, if it issues an error for missing mysqlnd_debug_std_no_trace_funcs? [2012-06-14 09:57:57] fausten at pw-internet dot de Hi, the package is going to build with mysqlnd by default: # cd /usr/ports/databases/php5-pdo_mysql make config MYSQLND - Use MySQL Native Driver (Is selected by default) # make install clean After installation: The following line has been added to your /usr/local/etc/php/extensions.ini configuration file to automatically load the installed extension: extension=pdo_mysql.so So the extension sholud be loaded after restarting php. [2012-06-14 09:41:44] johan...@php.net When building the MySQL extensions you explicitly have to enable mysqlnd. i.e. --enable-mysqlnd=shared. If you build mysqlnd shared you have to remember to load it, too. I will look whether the build system can be made smarter and at least warn. I don't want to make the decision in there whether to build shared or static. If I'd make that decision I'd default to static mysqlnd. 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=60840 -- Edit this bug report at https://bugs.php.net/bug.php?id=60840edit=1
Bug #64251 [Opn-Nab]: preg_replace non-obvious behavior
Edit report at https://bugs.php.net/bug.php?id=64251edit=1
ID: 64251
Updated by: johan...@php.net
Reported by:root at microsoft dot com
Summary:preg_replace non-obvious behavior
-Status: Open
+Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: all
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
My::rand() will be called before calling preg_replace. The function you are
looking for is preg_replace_callback.
Previous Comments:
[2013-02-20 14:30:11] root at microsoft dot com
Description:
Behavior of preg_replace is non-obvious, if second argument is function call.
Test script:
---
class My{
function prepare($text){
return preg_replace(
'/\{(.+?)\}/',
$this-rand(explode('|', '\\1')),
$text
);
}
private function rand(array $values){
return $values[rand(0, sizeof($values)-1)];
}
}
echo (new My)-prepare('i choose {ps3|games}');
Expected result:
i choose ps
or
i choose games
Actual result:
--
i choose ps3|games
--
Edit this bug report at https://bugs.php.net/bug.php?id=64251edit=1
Bug #60840 [Nab-Opn]: undefined symbol: mysqlnd_debug_std_no_trace_funcs
Edit report at https://bugs.php.net/bug.php?id=60840edit=1 ID: 60840 Updated by: johan...@php.net Reported by:public at grik dot net Summary:undefined symbol: mysqlnd_debug_std_no_trace_funcs -Status: Not a bug +Status: Open Type: Bug Package:PDO related Operating System: linux PHP Version:5.4SVN-2012-01-22 (snap) Assigned To:mysql Block user comment: N Private report: N Previous Comments: [2012-10-29 16:03:05] johan...@php.net public at grik dot net, the issue is when building the extensions shared we can't decide what to do with mysqlnd, should that be built-in or shared, too? Or maybe the user has a different mysqlnd? - We leave this to the user. [2012-06-14 10:03:03] public at grik dot net Johannes, thanks for the response, but according to http://php.net/ChangeLog-5.php ext/mysql, mysqli and pdo_mysql now use mysqlnd by default. in 5.4 So the issues are: 1. Why should we explicitly enable the feature used by default? 2. How can we NOT use mysqlnd in debug mode, if it issues an error for missing mysqlnd_debug_std_no_trace_funcs? [2012-06-14 09:57:57] fausten at pw-internet dot de Hi, the package is going to build with mysqlnd by default: # cd /usr/ports/databases/php5-pdo_mysql make config MYSQLND - Use MySQL Native Driver (Is selected by default) # make install clean After installation: The following line has been added to your /usr/local/etc/php/extensions.ini configuration file to automatically load the installed extension: extension=pdo_mysql.so So the extension sholud be loaded after restarting php. [2012-06-14 09:41:44] johan...@php.net When building the MySQL extensions you explicitly have to enable mysqlnd. i.e. --enable-mysqlnd=shared. If you build mysqlnd shared you have to remember to load it, too. I will look whether the build system can be made smarter and at least warn. I don't want to make the decision in there whether to build shared or static. If I'd make that decision I'd default to static mysqlnd. [2012-06-14 09:32:56] fausten at pw-internet dot de Hi, same problem here: # cd /usr/ports/database/php5-pdo_mysql make install clean Build is successfully. % php foo.php PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20100525-debug/pdo_mysql.so' - /usr/local/lib/php/20100525-debug/pdo_mysql.so: Undefined symbol mysqlnd_debug_std_no_trace_funcs in Unknown on line 0 OS: FreeBSD 9.0 amd64 PHP: 5.4.3 builded from ports (# cd /usr/ports/lang/php5 %% make install clean) 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=60840 -- Edit this bug report at https://bugs.php.net/bug.php?id=60840edit=1
Bug #64248 [Opn-Nab]: Strange parse error when using language construct in for
Edit report at https://bugs.php.net/bug.php?id=64248edit=1
ID: 64248
Updated by: johan...@php.net
Reported by:bobwei9 at hotmail dot com
Summary:Strange parse error when using language construct in
for
-Status: Open
+Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Irrelevant (OS X 10.8)
PHP Version:master-Git-2013-02-19 (Git)
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
unset() jsut as many other language constructs has no return value and is no
expression. for expects expressions. This construct makes sense only in very
few cases, even though it might make the language a tiny bit simpler (less
exceptions) it is not worth changing the language ... (changing language has
effects for the whole environment, from IDEs to code analyzers, to ...)
Previous Comments:
[2013-02-19 21:05:21] bobwei9 at hotmail dot com
Oops, the expected result should be a notice and $max should be 'A' in the test
script...
[2013-02-19 21:03:57] bobwei9 at hotmail dot com
Description:
For example unsetting a var in the third part of a for-loop throws an E_PARSE
error.
Test script:
---
php -r '
$A = [1];
$B = [1,7];
$max = 'B';
for ($i='A'; ++$i$max; unset($$i))
var_dump($$i);'
Expected result:
array(1) {
[0]=
int(1)
}
array(2) {
[0]=
int(1)
[1]=
int(7)
}
Actual result:
--
PHP Parse error: syntax error, unexpected 'unset' (T_UNSET), expecting ')' in
Command line code on line 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=64248edit=1
Bug #64211 [Nab]: sha256 hashes #, , and + incorrectly.
Edit report at https://bugs.php.net/bug.php?id=64211edit=1 ID: 64211 Updated by: johan...@php.net Reported by:pwormer at science dot ru dot nl Summary:sha256 hashes #, , and + incorrectly. Status: Not a bug Type: Bug Package:hash related Operating System: windows/linux PHP Version:5.4.11 Block user comment: N Private report: N New Comment: That'S your problem. You have to escape the URL parameters. pswd = a#b; url = SHA256.php?pswd=+pswd will create the URL SHA256.php?pswd=a#b the browser will then cut of the #b from the URL before sending it to the server. $ php -r 'echo hash(sha256, a);' ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb Which is what you get. You should escape the data ... Additional comment: Don't transfer the password as part of the URL. URLs are stored in browser history etc. and might leak therefore. Always use POST data for that. (but still mind proper escaping) Previous Comments: [2013-02-15 10:40:47] pwormer at science dot ru dot nl I call PHP from JS through XMLHttp.open(GET, SHA256.php?pswd=+pswd). Maybe the problem lies in XMLHttp? [2013-02-15 10:29:20] pwormer at science dot ru dot nl Two more examples: 1. Password a b (no quotes, pswd contains three characters, middle one ASCII 32): JS-hashed password : c8687a08aa5d6ed2044328fa6a697ab8e96dc34291e8c2034ae8c38e6fcc6d65 PHP-hashed password: c8687a08aa5d6ed2044328fa6a697ab8e96dc34291e8c2034ae8c38e6fcc6d65 2. Password a#b (no quotes, pswd contains three characters, middle one ASCII 35): JS-hashed password : 8187fc8f7f007036dffc199544b33167632c7739733785bbdec0fbb9a2c43ca1 PHP-hashed password: ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb My problem is the difference in hash between JavaScript and PHP that occurs if and only if the pswd contains anywhere #, or +. By looking at PHP alone this problem cannot be solved. [2013-02-14 21:38:29] s...@php.net s/expecting/getting [2013-02-14 21:37:50] s...@php.net Can't reproduce on 32 or 64 bit Linux: $ php53 -r 'echo hash(sha256, #) . \n;' 334359b90efed75da5f0ada1d5e6b256f4a6bd0aee7eb39c0f90182a021ffc8b $ php54 -r 'echo hash(sha256, #) . \n;' 334359b90efed75da5f0ada1d5e6b256f4a6bd0aee7eb39c0f90182a021ffc8b Is it coincidence that (an empty string) gives the hash you are expecting for #. $ php53 -r 'echo hash(sha256, ) . \n;' e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 $ php54 -r 'echo hash(sha256, ) . \n;' e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 [2013-02-14 11:05:56] pwormer at science dot ru dot nl Description: The JavaScript functions at: http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/sha256.js and http://www.movable-type.co.uk/scripts/sha256.html give the same hash for any password of any length consisting of ASCII 32 through 128. Almost always the hash is the same as obtained from PHP: hash(sha256, $pswd). Exceptions (bugs?) are passwords containing one or more of the three characters: # (number sign), (ampersand), or + (plus sign). Tested with XAMPP (PHP 5.4.7), FireFox and Chrome and Linux server. Test script: --- See http://www.theochem.ru.nl/~pwormer/sha256bug.php This URL calls SHA256.php which contains the following four lines ?php $pswd = $_GET[pswd]; echo hash(sha256, $pswd); ? Expected result: I expect JavaScript and PHP to give same Sha-256 hashes Actual result: -- Hash of # (single character): JS: 334359b90efed75da5f0ada1d5e6b256f4a6bd0aee7eb39c0f90182a021ffc8b PHP: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -- Edit this bug report at https://bugs.php.net/bug.php?id=64211edit=1
Bug #64217 [Opn-Nab]: Method Declared with one parameter, Called with Two parameter , No warnings.
Edit report at https://bugs.php.net/bug.php?id=64217edit=1
ID: 64217
Updated by: johan...@php.net
Reported by:jana dot sriramulu at gmail dot com
Summary:Method Declared with one parameter, Called with Two
parameter , No warnings.
-Status: Open
+Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: Windows xp
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is documented behavior and a feature which won't be changed in the
foreseeable future.
See also func_get_args().
Previous Comments:
[2013-02-15 13:46:57] jana dot sriramulu at gmail dot com
Description:
?php
// PHP Version 5.3.3
ini_set('display_errors', '1');
error_reporting(-1);
class a {
public function func1($a)
{
echo brA = . $a;
}
public function func2()
{
$this-func1(5, 6);
}
}
$c = new a();
$c-func2();
Test script:
---
?php
// PHP Version 5.3.3
ini_set('display_errors', '1');
error_reporting(-1);
class a {
public function func1($a)
{
echo brA = . $a;
}
public function func2()
{
$this-func1(5, 6);
}
}
$c = new a();
$c-func2();
Expected result:
Fatal Error / Warning / Notices.
Actual result:
--
No Warnings/ Notices/ Fatal error.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64217edit=1
Bug #64209 [Opn-Nab]: mysqli.insert-id return autoincrement not insert id
Edit report at https://bugs.php.net/bug.php?id=64209edit=1 ID: 64209 Updated by: johan...@php.net Reported by:grek at pogodzinach dot net Summary:mysqli.insert-id return autoincrement not insert id -Status: Open +Status: Not a bug Type: Bug -Package:PHAR related +Package:MySQLi related Operating System: ubuntu PHP Version:5.4.11 Block user comment: N Private report: N New Comment: Insert ID is a term used by MySQL. If you want to change this, ask Oracle to fix this in MySQL. There is no reason for PHP to use different terminology. Previous Comments: [2013-02-14 10:46:40] grek at pogodzinach dot net Description: Hy mysqli.insert-id = this is error / bug or please rename funcion mysqli.insert-id to mysqli.autoincrement-value or add to mysqli.insert-id return primary row value - this func return 0 when primary value dont have auto increment Test script: --- any , always ! Expected result: return real insert id = primary rov value -- Edit this bug report at https://bugs.php.net/bug.php?id=64209edit=1
Sec Bug-Bug #64203 [Opn-Nab]: private property of class modified by mysql_fetch_object
Edit report at https://bugs.php.net/bug.php?id=64203edit=1
ID: 64203
Updated by: johan...@php.net
Reported by:pelister dot 79 at gmail dot com
Summary:private property of class modified by
mysql_fetch_object
-Status: Open
+Status: Not a bug
-Type: Security
+Type: Bug
Package:MySQL related
Operating System: Win XP
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2013-02-13 11:50:01] paj...@php.net
change mode and category for this report.
[2013-02-13 10:35:07] pelister dot 79 at gmail dot com
Description:
---
From manual page:
http://www.php.net/function.mysql-fetch-object#refsect1-function.mysql-fetch-object-notes
---
Private properties are accessed and values set with mysql_fetch_object, Can
private properties be accessed outside the class?
Test script:
---
class myclass {
private $option_name;
private $option_value;
private $option_id;
function __construct( ) {
echo Data Created br /;
}
function display( ) {
echo Name: $this-option_name, Value:
$this-option_value, Id: $this-option_id br /;
}
}
/* connect to db */
$query = SELECT * FROM simpleuser_options;
while( $row = mysql_fetch_object( $result, myclass))
$row-display();
--
Edit this bug report at https://bugs.php.net/bug.php?id=64203edit=1
Req #64201 [Opn-Nab]: Resource Identification in Autoload Callback
Edit report at https://bugs.php.net/bug.php?id=64201edit=1
ID: 64201
Updated by: johan...@php.net
Reported by:savinger at sc dot rr dot com
Summary:Resource Identification in Autoload Callback
-Status: Open
+Status: Not a bug
Type: Feature/Change Request
Package:*General Issues
Operating System: OSX
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
No this is not possible, especially as there are situations where we can't see
the difference. (Especially if you also think about interfaces) You have to use
a custom naming scheme or such.
Previous Comments:
[2013-02-13 06:08:30] savinger at sc dot rr dot com
wrong package
[2013-02-13 06:05:15] savinger at sc dot rr dot com
Description:
Is there any way for me to differentiate between traits and classes in my
autoload
function? Say I have a folder of classes and a folder of traits; it would be
nice
to be able to do something like...
Test script:
---
spl_autoload_register(function($resource) {
if ( /* $resource is class */ ) {
include 'classes/'.$resource.'.php';
}
if ( /* $resource is trait */ ) {
include 'traits/'.$resource.'.php';
}
});
--
Edit this bug report at https://bugs.php.net/bug.php?id=64201edit=1
Req #64185 [Opn]: is_callable does not check syntax
Edit report at https://bugs.php.net/bug.php?id=64185edit=1 ID: 64185 Updated by: johan...@php.net Reported by:hanskrentel at yahoo dot de Summary:is_callable does not check syntax Status: Open Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.4.11 Block user comment: N Private report: N New Comment: Even with classes such names could - theoretically - exist due to weird (3rd party) extensions etc. (i hope nobody does, but there's nothing stopping one) So syntax in this case does not mean one could use those names in syntactically correct PHP code but the overall structure matches something that might be used in a lookup Previous Comments: [2013-02-10 17:04:38] hanskrentel at yahoo dot de NikiC was so friendly to just remind me that checking for the method name *is* limited because of __call and __callStatic (basically everything for a method name works, including a zero-length string). So this feature request is actually more about the classname validation then the method name validation. [2013-02-10 16:04:21] hanskrentel at yahoo dot de Description: Using is_callable with the syntax_only parameter set to true does actually *not* check the syntax, for example of a valid classname or FQCN. Also not for the method name. My feature request is, that it will always check those strings according to the rules set in the PHP parser of the same PHP version the function ships with so that it can be used to validate PHP syntax as well. Same for calls with :: for static class name method calls. Test script: --- var_dump(is_callable(['', ''], true)); var_dump(is_callable(['', 'method'], true)); var_dump(is_callable(['0', 'method'], true)); var_dump(is_callable(['0\\foo', 'method'], true)); var_dump(is_callable(['\\0\\foo', 'method'], true)); Expected result: bool(false) bool(false) bool(false) bool(false) bool(false) Actual result: -- bool(true) bool(true) bool(true) bool(true) bool(true) -- Edit this bug report at https://bugs.php.net/bug.php?id=64185edit=1
Bug #64186 [Opn-Nab]: Curly brace syntax not accessing superglobals?
Edit report at https://bugs.php.net/bug.php?id=64186edit=1
ID: 64186
Updated by: johan...@php.net
Reported by:michal at durooil dot com
Summary:Curly brace syntax not accessing superglobals?
-Status: Open
+Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Windows 7 x64
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is to to just-in-time initialization of super globals. You either neet a
direct call to that same super global in the same function or have to disable
this optimization by setting auto_globals_jit in php.ini
Previous Comments:
[2013-02-11 00:22:08] michal at durooil dot com
Description:
This looks really weird to me.
Test script:
---
// works well
print_r(${'_GET'});
// this not however
// returns notice: Undefined variable: _GET
$name = '_GET';
print_r(${$name});
--
Edit this bug report at https://bugs.php.net/bug.php?id=64186edit=1
Req #64204 [Opn-Wfx]: Read only and write once paramater visibility
Edit report at https://bugs.php.net/bug.php?id=64204edit=1
ID: 64204
Updated by: johan...@php.net
Reported by:andy at mrhunt dot co dot uk
Summary:Read only and write once paramater visibility
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:Unknown/Other Function
Operating System: Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
No, this is not easy, mind cases like this:
$test = new Test();
$foo = $test-param_ro;
$foo = 'test';
Our current discussion state is more around accessors, while that's not yet
accepted either: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
Previous Comments:
[2013-02-13 15:12:33] andy at mrhunt dot co dot uk
Description:
This is a hopefully simple request to add an extra visibility type into classes
to
allow for paramaters that can be read outside the class like with public but
can
only be written too inside as with protected. I've put a sample of how I think
this should work below to hopefully give you a better idea of this.
Test script:
---
class Test
{
readonly $param_ro;
public funcion test()
{
$this-param_ro = 'test-ro'; // Works
}
}
$test = new Test();
echo $test-param_ro; // Works
$this-param_ro = 'test'; // Fails
--
Edit this bug report at https://bugs.php.net/bug.php?id=64204edit=1
Bug #64195 [Opn-Nab]: clone object with circular reference cause segfault
Edit report at https://bugs.php.net/bug.php?id=64195edit=1
ID: 64195
Updated by: johan...@php.net
Reported by:vovan-ve at yandex dot ru
Summary:clone object with circular reference cause segfault
-Status: Open
+Status: Not a bug
Type: Bug
Package:Class/Object related
Operating System: linux
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Infinite recursion leads to a stack overflow (clone calls clone, calls clone,
calls clone, ...) we have no good way to handle this.
Previous Comments:
[2013-02-12 11:33:20] vovan-ve at yandex dot ru
Description:
There are two objects of the same class. Both objects has a property. There are
circular object reference: $a-prop === $b $b-prop === $a. The class has
a __clone() handler which clones object in that property.
So, clonning such object cause segfault.
Yes, described architecture is ugly, but this is just for test.
Test code:
class A {
public $prop;
public function __clone() {
$this-prop = clone $this-prop;
}
}
// create two objects
$a = new A();
$b = new A();
// create circular reference
$b-prop = $a;
$a-prop = $b;
// see short dump with *RECURSION* marker
print_r($a);
// now make a problem
$c = clone $a;
// never will reach here
print_r($c);
5.5.0.a2, 5.4.11, 5.3.20 and 5.2.17 crashes with segfault. It is infinite
recursion. Also Fatal Error can be emited about memory allocation when small
memory_limit is set (1M for example).
Unlimited recursion for a simple function cause a fatal error, so the bug
always should cause the same fatal error.
Test script:
---
class A {
public $prop;
public function __clone() {
$this-prop = clone $this-prop;
}
}
$a = new A();
$b = new A();
$b-prop = $a;
$a-prop = $b;
print_r($a);
$c = clone $a;
print_r($c);
Expected result:
A Object
(
[prop] = A Object
(
[prop] = A Object
*RECURSION*
)
)
Fatal error: Allowed memory size of ... bytes exhausted (tried to allocate ...
bytes)
Actual result:
--
A Object
(
[prop] = A Object
(
[prop] = A Object
*RECURSION*
)
)
Segmentation fault (core dumped)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64195edit=1
