[PHP-BUG] Req #52623 [NEW]: PDO::MYSQL_ATTR_MAX_BUFFER_SIZE not supported in mysqlnd
From: Operating system: any PHP version: 5.3SVN-2010-08-17 (SVN) Package: MySQL related Bug Type: Feature/Change Request Bug description:PDO::MYSQL_ATTR_MAX_BUFFER_SIZE not supported in mysqlnd Description: Seems as if mysqlnd driver doesn't support PDO::MYSQL_ATTR_MAX_BUFFER_SIZE constant. In pdo_mysql.c (from svn http://svn.php.net/repository/php/php- src/branches/PHP_5_3/ext/pdo_mysql/pdo_mysql.c), I can see: #ifndef PDO_USE_MYSQLND REGISTER_PDO_CLASS_CONST_LONG(MYSQL_ATTR_MAX_BUFFER_SIZE, (long)PDO_MYSQL_ATTR_MAX_BUFFER_SIZE); ... #endif So, this constant (and some others) are only defined when mysqlnd isn't the active driver. Test script: --- echo PDO::MYSQL_ATTR_MAX_BUFFER_SIZE; Expected result: Output 1005 Actual result: -- Fatal error: Undefined class constant 'MYSQL_ATTR_MAX_BUFFER_SIZE' in php shell code on line 1 -- Edit bug report at http://bugs.php.net/bug.php?id=52623edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52623r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52623r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52623r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52623r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52623r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52623r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52623r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52623r=needscript Try newer version: http://bugs.php.net/fix.php?id=52623r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52623r=support Expected behavior: http://bugs.php.net/fix.php?id=52623r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52623r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52623r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52623r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52623r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52623r=dst IIS Stability: http://bugs.php.net/fix.php?id=52623r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52623r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52623r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52623r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52623r=mysqlcfg
Req #42965 [Asn-Csd]: copy() should support context parameters for URLs
Edit report at http://bugs.php.net/bug.php?id=42965edit=1 ID: 42965 Updated by: ka...@php.net Reported by:mmatson at apple dot com Summary:copy() should support context parameters for URLs -Status: Assigned +Status: Closed Type: Feature/Change Request Package:*General Issues Operating System: OS X 10.4.10 PHP Version:5.2.4 Assigned To:kalle Block user comment: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Fixed for 5.3.4, see svn logs for more info why it wasn't working in 5.3.0-5.3.3 Previous Comments: [2010-08-16 23:56:37] ka...@php.net Automatic comment from SVN on behalf of kalle Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=302376 Log: Fixed the context parameter on copy() to actually have an effect # After looking at the logs, Jani did a bad merge into 5.3, so that # the context parameter sent to copy() actually isn't used at all. This # relatively simple patch fixes that for trunk. # # See FR #42965 # internals: # This changes the php_copy_*() decls to contain an additional parameter for stream contexts [2007-10-15 02:21:55] mmatson at apple dot com Description: The copy function should accept context parameters since it can accept URL's of the fopen wrapper variety. Specific situation where this is needed is when using ftp:// url's you should be able to specify overwrite context for the destination URL. Reproduce code: --- N/A: feature request for filesystem function Expected result: copy should be able to over write a destination file when using ftp:// url's Actual result: -- Throws error: PHP Warning: copy(ftp://@host.com/testFTP/test): failed to open stream: Remote file already exists and overwrite context option not specified. -- Edit this bug report at http://bugs.php.net/bug.php?id=42965edit=1
Bug #52397 [Opn-Bgs]: json_encode display_errors dependency
Edit report at http://bugs.php.net/bug.php?id=52397edit=1
ID: 52397
Updated by: il...@php.net
Reported by:david at grudl dot com
Summary:json_encode display_errors dependency
-Status: Open
+Status: Bogus
Type: Bug
Package:JSON related
PHP Version:5.3.3RC3
Block user comment: N
New Comment:
The return values are the same and so is the operation...
Previous Comments:
[2010-07-22 01:00:35] david at grudl dot com
Description:
Invalid UTF-8 string throws E_WARNING depending on the configuration
directive display_errors:
ini_set('display_errors', 0);
json_encode(\xFF); // PHP Warning: json_encode(): Invalid UTF-8
sequence in argument (in error log)
ini_set('display_errors', 1);
json_encode(\xFF); // *nothing*
This directive determines whether errors should be printed to the screen
as part of the output or if they should be hidden from the user. It
should not be used to change json_encode behaviour.
The same bug affects htmlentities() and htmlspecialchars()
Test script:
---
ini_set('display_errors', 0);
json_encode(\xFF);
htmlspecialchars(\xFF, ENT_COMPAT, 'utf-8');
htmlentities(\xFF, ENT_COMPAT, 'utf-8');
--
Edit this bug report at http://bugs.php.net/bug.php?id=52397edit=1
Bug #52284 [Ver-Bgs]: Reproducible crash using curl_multi functions with FTP
Edit report at http://bugs.php.net/bug.php?id=52284edit=1
ID: 52284
Updated by: il...@php.net
Reported by:ahar...@php.net
Summary:Reproducible crash using curl_multi functions with
FTP
-Status: Verified
+Status: Bogus
Type: Bug
Package:cURL related
Operating System: Ubuntu 10.04 (and others)
PHP Version:5.3SVN-2010-07-08 (SVN)
Block user comment: 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.
Not a PHP bug, the issue exists within libcurl.
Previous Comments:
[2010-07-28 16:22:10] profy dot net at gmail dot com
I think recompile will help.
But I prefer to use distro's php versions for maintainability.
We use several ubuntu versions in production.
Anyway, I added workaround in my code to switch into one-thread mode
when dealing with FTP urls while bug still exists in packaged php5-curl
extension.
[2010-07-27 17:18:14] paj...@php.net
@srinata
I don't think there is a release after 7.21.0. We have to wait for it :)
[2010-07-27 16:49:14] srina...@php.net
Ok, been debugging this since morning for fun. As Pierre mentioned
earlier, this
bug turns out to be a libcurl bug and a recent commit within libcurl
fixes the
underlying multi handler issue.
now, ubuntu has not shipped with recent versions of libcurl yet. so, you
will
need to manually download libcurl from below: and install to say
/usr/local
http://curl.haxx.se/snapshots/
once this new curl is installed, you will need to recompile php with
--with-
curl=/usr/local
if this satisfies ur concern, then we can close this bug.
hope this helps.
[2010-07-27 07:48:00] profy dot net at gmail dot com
Reproduced every time when call test script.
Test script:
---
?php
function multi_request($urls, $url_options = array()) {
$mh = curl_multi_init();
foreach ($urls as $id = $url) {
$curly[$id] = curl_init();
curl_setopt($curly[$id], CURLOPT_URL, $url);
curl_setopt($curly[$id], CURLOPT_RETURNTRANSFER, true);
// I've add this opt to speed up request, bug appearing
with or
without this line
curl_setopt($curly[$id], CURLOPT_NOBODY, true);
curl_multi_add_handle($mh, $curly[$id]);
}
$running = null;
do {
$status = curl_multi_exec($mh, $running);
usleep(1000);
} while($status == CURLM_CALL_MULTI_PERFORM || $running);
foreach ($curly as $id = $c) {
$result[$id] = curl_multi_getcontent($c);
curl_multi_remove_handle($mh, $c);
curl_close($c);
}
curl_multi_close($mh);
return $result;
}
$urls = array(
4358521 =
ftp://ftp.ea.com/pub/ea/patches/nfs-underground/pc/en-uk/NFSU_EUROPE_PATCH_4.exe;,
7458288 =
ftp://ftp.nero.com/software/plugins/WMAPlugin20937.exe;,
);
echo pre;
print_R(multi_request($urls));
echo /pre;
[2010-07-27 04:57:11] srina...@php.net
able to reproduce this issue. here is the stack trace:
(gdb) where
#0 0x00520a58 in curl_write_header (data=0x18d3b78 221
Goodbye.\r\nomplete.\r, size=1, nmemb=14, ctx=0x1876e58)
at
/home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/interface.c:1123
#1 0x7f106e187c26 in ?? () from /usr/lib/libcurl.so.4
#2 0x7f106e1885ad in ?? () from /usr/lib/libcurl.so.4
#3 0x7f106e18b2ed in ?? () from /usr/lib/libcurl.so.4
#4 0x7f106e18c64f in ?? () from /usr/lib/libcurl.so.4
#5 0x7f106e18c792 in ?? () from /usr/lib/libcurl.so.4
#6 0x7f106e18e9b2 in ?? () from /usr/lib/libcurl.so.4
#7 0x7f106e1a4813 in curl_multi_cleanup () from
/usr/lib/libcurl.so.4
#8 0x00527208 in _php_curl_multi_close (rsrc=0x1871970) at
/home/sriramn/dev/php-src/branches/PHP_5_3/ext/curl/multi.c:327
#9 0x007f246e in list_entry_destructor (ptr=0x1871970) at
/home/sriramn/dev/php-src/branches/PHP_5_3/Zend/zend_list.c:184
#10 0x007efa3b in zend_hash_del_key_or_index (ht=0xe1eaf0,
arKey=0x0, nKeyLength=0, h=4, flag=1) at
[PHP-BUG] Bug #52624 [NEW]: tempnam() in SAFE Mode
From:
Operating system: RHEL 5
PHP version: 5.2.14
Package: Unknown/Other Function
Bug Type: Bug
Bug description:tempnam() in SAFE Mode
Description:
Dear php Team,
We are using php 5.2.13 and Safe_mod is ON.
we have a problem using tempnam, at first we had tempnam('',tempfile);
This did not work - error can not access /tmp
Later I investigated and have written the testscript and have following
behavior. Attention script must be owned by non root user
the script with 7th line $tmp_name = tempnam ( 'tmp', 'tempname' ); works
fine also with safe_mode
when i change it to $tmp_name = tempnam ( '/tmp', 'tempname' ); a safe_mode
restriction takes effect (the one with compares UID/GID and puts out
Warning: tempnam() [function.tempnam]: SAFE MODE Restriction in effect. The
script whose uid/gid is 506/506 is not allowed to access /tmp owned by
uid/gid 0/0 in /home/httpd/html/default/tempfile.php on line 7
but why does it work without the beginning '/'?
Can you clarify this behavior please? and another issuse is that when i try
with $tmp_name = tempnam ( '/tmp', 'tempname' ); it does not make a
diference putting /tmp to openbasedir or safe_mode_includedir it dies not
work.
I have also read the changelog and have found that since PHP 5.2.12 some
issues with tempname and safe_mode have been fixed - there was a bug that
tempnam ignores safe_mode. And this correct because i tested with php
5.2.11 and it worked with /tmp also. Can you tell me ehat exactly is
changed saince version 5.2.12?
Test script:
---
?PHP
$xx = sys_get_temp_dir();
echo $xx . 'br';
for ( $x = 0; $x = 5; $x++ )
{
$tmp_name = tempnam ( 'tmp', 'tempname' );
echo $tmp_name . 'br';
}
$str = 'standing in a tempfile';
$tmp_file = fopen ( $tmp_name, 'w' );
fputs ( $tmp_file, $str );
fclose ( $tmp_file );
$fp = fopen ( $tmp_name, 'r' );
$str = fgets ( $fp, 50 );
fclose ( $fp );
echo $str;
?
Expected result:
script above works fine also in safe mode change 7th line from
$tmp_name = tempnam ( 'tmp', 'tempname' );
to
$tmp_name = tempnam ( '/tmp', 'tempname' ); bringe a safe_mode restriction
which is also ok, but why does it work without / and why does it not make a
diference putting /tmp to openbasedir or safe_mode_include_dir
--
Edit bug report at http://bugs.php.net/bug.php?id=52624edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52624r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52624r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52624r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52624r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52624r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52624r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52624r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52624r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52624r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52624r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52624r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52624r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52624r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52624r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52624r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52624r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52624r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52624r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52624r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52624r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52624r=mysqlcfg
Req #50667 [Asn]: Deprecate mysql_list_databases
Edit report at http://bugs.php.net/bug.php?id=50667edit=1 ID: 50667 Updated by: and...@php.net Reported by:rtshilston at gmail dot com Summary:Deprecate mysql_list_databases Status: Assigned Type: Feature/Change Request Package:*General Issues PHP Version:5.3.1 Assigned To:andrey Block user comment: N New Comment: I removed aliases in MySQLi. I haven't touched ext/mysql Previous Comments: [2010-08-16 23:06:02] ka...@php.net Andrey, didn't you remove those aliases not so long ago, if so could you re-classify this if needed to a documentation issue? [2010-01-05 10:56:43] rtshilston at gmail dot com Description: mysql_list_tables and mysql_list_fields have both been deprecated. For consistency, I think that mysql_list_dbs should be deprecated as it too can be performed with a simple SQL query: SHOW databases. Reproduce code: --- --- From manual page: function.mysql-list-dbs --- -- Edit this bug report at http://bugs.php.net/bug.php?id=50667edit=1
Req #43948 [Com]: IMAP: Add imap_myrights() function
Edit report at http://bugs.php.net/bug.php?id=43948edit=1 ID: 43948 Comment by: p at rdus dot de Reported by:diegows at xtech dot com dot ar Summary:IMAP: Add imap_myrights() function Status: Feedback Type: Feature/Change Request Package:IMAP related PHP Version:trunk Assigned To:pajoye Block user comment: N New Comment: We tracked the status of the uw imap c-client annotation patch here: https://issues.kolab.org/merge10 I resubmitted the patch three years ago (http://mailman2.u.washington.edu/pipermail/imap-uw/2007-March/001202.html) and it was stalled as Marc Crispin wanted to wait for the ANNOTATEMORE draft to become a real RFC (http://mailman2.u.washington.edu/pipermail/imap-uw/2007-March/001203.html). While this has happened in the meantime (http://mailman.rfc-editor.org/pipermail/rfc-dist/2009-February/002184.html) c-client development seems to have ceased in the meantime, too. For Kolab I'm pretty certain we will switch to the newer Horde_Imap_Client library. I already prepared it with the necessary extensions (https://issues.kolab.org/msg21509). Horde_Imap_Client seems to run faster than the c-client based code though I have to admit that this is just a result from the simple test script and no solid benchmark. As Hored_Imap_Client is not really released yet and would make a bunch of other updates necessary for the Kolab server we'd be quite happy though if annotation support would already work with the imap_* functions available within PHP. I know the situation concerning c-client is messy. Is there anything we can do in order to get the patch accepted? Previous Comments: [2010-07-30 13:51:37] mkoppa...@php.net Updated the annotations patch to add HAVE_IMAP_ANNOTATIONS [2010-07-30 13:51:12] mkoppa...@php.net The following patch has been added/updated: Patch Name: imap_annotation.patch Revision: 1280490672 URL: http://bugs.php.net/patch-display.php?bug=43948patch=imap_annotation.patchrevision=1280490672 [2010-07-30 10:28:10] paj...@php.net Right, c-client needs to be patched. It does not sound too good to me but I would like to add some HAVE_ to the c-client patch for cleaner detection. I also dropped a mail to the the uw imap mailing list to ask what's the status of this patch (if has been actually proposed, rejected, etc.). [2010-07-29 20:15:43] mkoppa...@php.net It looks like c-client needs to be patched to support annotations: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/patches/imap/ Can't find annotation support in upstream c-client 2007e. [2010-07-29 19:32:57] clint at ubuntu dot com Thanks for taking this on pajoye. We are tracking this bug in Ubuntu here: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/610630 As soon as its committed, we'll most likely apply the patches to 5.3.2 or 5.3.3 for release with Maverick 10.10 to make Kolab function properly. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=43948 -- Edit this bug report at http://bugs.php.net/bug.php?id=43948edit=1
Bug #52617 [Opn-Bgs]: call_user_func_array don't properly get parameters to a method
Edit report at http://bugs.php.net/bug.php?id=52617edit=1
ID: 52617
Updated by: johan...@php.net
Reported by:s dot cimini at email dot it
Summary:call_user_func_array don't properly get parameters
to a method
-Status: Open
+Status: Bogus
Type: Bug
Package:Unknown/Other Function
Operating System: Ubuntu Server 10.04 32 bit
PHP Version:5.3.3
Block user comment: N
New Comment:
The behavior of PHP 5.2 was wrong and got fixed. bind_param expects
references, so you have to pass an array of referenced variables to the
method. If you have full error reporting you should receive an error
message about this.
Previous Comments:
[2010-08-17 03:32:27] fel...@php.net
I cannot reproduce any problem using the follow sample code:
var_dump(call_user_func_array(array(new simplexmlelement('ab//a'),
'xpath'), array('//a')));
[2010-08-16 11:24:18] s dot cimini at email dot it
Description:
The PHP version is 5.3.2 and not 5.3.3, but 5.3.2 is not present in the
combo.
When i try do execute a script that with PHP 5.2.9 on a Windows pc works
in a Ubuntu server 10.04 with PHP 5.3.2 don't work.
It appears that the second part of the function, the part relative to
the parameters, don't get the parameters to the method of the first
part.
Test script:
---
$db_user=root;
$db_password=password;
$db_host=localhost;
$mysqli = new mysqli($db_host, $db_user, $db_password, database);
$query = select id from table where name like ?;
$types=s;
$values[]=a%;
$stmt = $mysqli-prepare($query);
call_user_func_array(array($stmt, bind_param),
array_merge(array($types),$values));
$stmt-execute();
$stmt-bind_result($id);
while($stmt-fetch()){
echo($id.br /);
}
$mysqli-close();
Expected result:
A list of ids.
Actual result:
--
Nothing and the excution don't give any errors
--
Edit this bug report at http://bugs.php.net/bug.php?id=52617edit=1
Req #50667 [Asn-Csd]: Deprecate mysql_list_databases
Edit report at http://bugs.php.net/bug.php?id=50667edit=1 ID: 50667 Updated by: and...@php.net Reported by:rtshilston at gmail dot com Summary:Deprecate mysql_list_databases -Status: Assigned +Status: Closed Type: Feature/Change Request Package:*General Issues PHP Version:5.3.1 Assigned To:andrey Block user comment: N New Comment: Deprecated in trunk, if next minor release is 5.4.0, then it will be there. Thanks! Previous Comments: [2010-08-17 15:40:13] and...@php.net I removed aliases in MySQLi. I haven't touched ext/mysql [2010-08-16 23:06:02] ka...@php.net Andrey, didn't you remove those aliases not so long ago, if so could you re-classify this if needed to a documentation issue? [2010-01-05 10:56:43] rtshilston at gmail dot com Description: mysql_list_tables and mysql_list_fields have both been deprecated. For consistency, I think that mysql_list_dbs should be deprecated as it too can be performed with a simple SQL query: SHOW databases. Reproduce code: --- --- From manual page: function.mysql-list-dbs --- -- Edit this bug report at http://bugs.php.net/bug.php?id=50667edit=1
Bug #52613 [Asn-Fbk]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613edit=1 ID: 52613 Updated by: and...@php.net Reported by:manuel at mausz dot at Summary:crash in mysqlnd -Status: Assigned +Status: Feedback Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N New Comment: If PHP hits the memory limit then mysqlnd loses all control, because Zend takes it. Can you show more information about the crash? Just the bt, without line numbers doesn't help. valgrind output will be even better. Previous Comments: [2010-08-15 17:45:22] manuel at mausz dot at Description: mysqlnd trys to free memory which must not be valid (e.g. if memory_limit prevents that) Test script: --- * create a database table with a bunch of string-columns and fill in a lot of data * write a php script which fetches the content of the whole table and stores the content in an array * run the php script in a shell loop which increases the memory limit by a few kB per step. e.g: for i in $(seq 1 100); do let mem=$i*10; echo $mem; ./sapi/cli/php -dmemory_limit=$mem crash.php; done Expected result: no crash Actual result: -- (gdb) bt #0 0x0838b494 in mysqlnd_palloc_zval_ptr_dtor () #1 0x0838bbc2 in php_mysqlnd_res_free_buffered_data_pub () #2 0x0838be4a in php_mysqlnd_res_free_result_buffers_pub () #3 0x0838bf4f in mysqlnd_internal_free_result_contents () #4 0x0838bfa8 in mysqlnd_internal_free_result () #5 0x0838f984 in php_mysqlnd_res_free_result_pub () #6 0x081ef818 in _free_mysql_result () #7 0x08408ecc in list_entry_destructor () #8 0x08406e2f in zend_hash_apply_deleter () #9 0x08406f13 in zend_hash_graceful_reverse_destroy () #10 0x0840902e in zend_destroy_rsrc_list () #11 0x083fa116 in zend_deactivate () #12 0x0839adfb in php_request_shutdown () #13 0x084b6b22 in main () -- Edit this bug report at http://bugs.php.net/bug.php?id=52613edit=1
[PHP-BUG] Req #52626 [NEW]: New magic method for procedural calls on object.
From:
Operating system: *
PHP version: Irrelevant
Package: Class/Object related
Bug Type: Feature/Change Request
Bug description:New magic method for procedural calls on object.
Description:
?php
$a = Array();
$a['a'] = 'text';
$a['b'] = 15;
$a['c'] = 155.12;
?
Classic style:
?php
ksort( $a );
is_array( $a );
?
Object style:
?php
$oa = new ObjArray($a); // extends ArrayIterator or ArrayObject
$oa-ksort();
$oa-is_array(); //implemented in ObjArray
?
But what if :
?php
$oa = new ObjArray($a); // extends ArrayIterator or ArrayObject
ksort( $oa );
is_array( $oa );
?
(SplTypes project is dead and I need object types.)
Now it is not possible to control, what functions are executed on object.
If a language function is used on a object, php would
Variant 1) try to call object function of the same name,
Variant 2) call magic method __callOnObject if exists
Both variants can be implemented together.
Possible problem in variant 1)
Programmer would need to take care, to really implement exact same
structure of parameters, with all optional parameters, elze it would throw
errors on different arguments.
There could by a variant 1a) where, called function doesn't list all
arguments, but passes an array of arguments. But that would make object
calls too different from procedural.
Test script:
---
Variant 1)
class ObjArray extends ArrayIterator{
public function is_array( $var ){
return is_array( $this-storage );
}
public function is_object( $var ){
return is_object( $this-storage );
}
}
$obj = new ObjArray( Array( 1, 2 ) );
var_dump( is_array( $obj ) );
var_dump( is_object( $obj ) );
Variant 2)
class ObjArray extends ArrayIterator{
public function __callOnObject( $calledFunction, $params ){
switch $calledFunction {
case is_array:
return $this-is_array( $params[0] );
break;
case is_object:
return $this-is_object( $params[0] );
break;
default:
return $calledFunction( insert_params_irrelevant_how( $params ) );
}
}
public function is_array( $var ){
return is_array( $this-storage );
}
public function is_object( $var ){
return is_object( $this-storage );
}
}
$obj = new ObjArray( Array( 1, 2 ) );
var_dump( is_array( $obj ) );
var_dump( is_object( $obj ) );
Expected result:
Variant 1)
//$obj = new ObjArray( Array( 1, 2 ) );
//var_dump( is_array( $obj ) );
//should translate to var_dump( $obj-is_array( $obj ) );
bool(true)
//var_dump( is_object( $obj ) );
//should translate to var_dump( $obj-is_object( $obj ) );
bool(false)
Variant 2)
//$obj = new ObjArray( Array( 1, 2 ) );
//var_dump( is_array( $obj ) );
//should translate to var_dump( $obj-__callOnObject( is_array, Array(
$obj ) ) );
//swith/case finds function is_array and calls $obj-is_array( $obj );
bool(true)
//var_dump( is_object( $obj ) );
//should translate to var_dump( $obj-__callOnObject( is_object, Array(
$obj ) ) );
//swith/case finds function is_object and calls $obj-is_object( $obj );
bool(false)
Actual result:
--
//$obj = new ObjArray( Array( 1, 2 ) );
//var_dump( is_array( $obj ) );
bool(false)
//var_dump( is_object( $obj ) );
bool(true)
--
Edit bug report at http://bugs.php.net/bug.php?id=52626edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52626r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52626r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52626r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52626r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52626r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52626r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52626r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52626r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52626r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52626r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52626r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52626r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52626r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52626r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52626r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52626r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52626r=isapi
Install GNU Sed:
[PHP-BUG] Bug #52627 [NEW]: Iterators trigger_error causes crash
From:
Operating system:
PHP version: 5.3.3
Package: Reproducible crash
Bug Type: Bug
Bug description:Iterators trigger_error causes crash
Description:
Throwing any error in foreach causes PHP to crash since PHP 5.1.3
Test script:
---
class MyFilterIterator extends FilterIterator
{
function accept() { return TRUE; }
}
$iterator = new RecursiveArrayIterator(array(1));
$iterator = new RecursiveIteratorIterator($iterator);
$iterator = new MyFilterIterator($iterator);
foreach ($iterator as $component) {
trigger_error('User error', E_USER_ERROR);
// or trigger fatal error by calling undefined function xyz()
}
--
Edit bug report at http://bugs.php.net/bug.php?id=52627edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52627r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52627r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52627r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52627r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52627r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52627r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52627r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52627r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52627r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52627r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52627r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52627r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52627r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52627r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52627r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52627r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52627r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52627r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52627r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52627r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52627r=mysqlcfg
Bug #52613 [Fbk-Asn]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613edit=1 ID: 52613 User updated by:manuel at mausz dot at Reported by:manuel at mausz dot at Summary:crash in mysqlnd -Status: Feedback +Status: Assigned Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N New Comment: ==22090== Memcheck, a memory error detector ==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=390 crash2.php ==22090== Fatal error: Allowed memory size of 390 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12 ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22090== ==22090== ==22090== Process terminating with default action of signal 11 (SIGSEGV) ==22090== Access not within mapped region at address 0x8 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== If you believe this happened as a result of a stack ==22090== overflow in your program's main thread (unlikely but ==22090== possible), you can try to increase the size of the ==22090== main thread stack using the --main-stacksize= flag. ==22090== The main thread stack size used in this run was 8388608. ==22090== ==22090== HEAP SUMMARY: ==22090== in use at exit: 5,336,261 bytes in 31,521 blocks ==22090== total heap usage: 87,945 allocs, 56,424 frees, 11,136,282 bytes allocated ==22090== ==22090== LEAK SUMMARY: ==22090==definitely lost: 0 bytes in 0 blocks ==22090==indirectly lost: 0 bytes in 0 blocks ==22090== possibly lost: 363,504 bytes in 3,303 blocks ==22090==still reachable: 4,972,757 bytes in 28,218 blocks ==22090== suppressed: 0 bytes in 0 blocks ==22090== Rerun with --leak-check=full to see details of leaked memory ==22090== ==22090== For counts of detected and suppressed errors, rerun with: -v ==22090== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7) Segmentation fault Previous Comments: [2010-08-17 17:53:41] and...@php.net If PHP hits the memory limit then mysqlnd loses all control, because Zend takes it. Can you show more information about the crash? Just the bt, without line numbers doesn't help. valgrind output will be even better. [2010-08-15 17:45:22] manuel at mausz dot at Description: mysqlnd trys to free memory which must not be valid (e.g. if memory_limit prevents that) Test script: --- * create a database table with a bunch of string-columns and fill in a lot of data * write a php script which fetches the content of the whole table and stores the content in an array * run the php script in a shell loop which increases the memory limit by a few kB per step. e.g: for i in $(seq 1 100); do let mem=$i*10; echo $mem;
Bug #52627 [Opn-Fbk]: Iterators trigger_error causes crash
Edit report at http://bugs.php.net/bug.php?id=52627edit=1
ID: 52627
Updated by: ahar...@php.net
Reported by:david at grudl dot com
Summary:Iterators trigger_error causes crash
-Status: Open
+Status: Feedback
Type: Bug
Package:Reproducible crash
PHP Version:5.3.3
Block user comment: 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.
I can't reproduce this on OS X or Linux. Besides needing a backtrace,
we'll also need to know what operating system you're running.
Previous Comments:
[2010-08-17 18:11:32] david at grudl dot com
Description:
Throwing any error in foreach causes PHP to crash since PHP 5.1.3
Test script:
---
class MyFilterIterator extends FilterIterator
{
function accept() { return TRUE; }
}
$iterator = new RecursiveArrayIterator(array(1));
$iterator = new RecursiveIteratorIterator($iterator);
$iterator = new MyFilterIterator($iterator);
foreach ($iterator as $component) {
trigger_error('User error', E_USER_ERROR);
// or trigger fatal error by calling undefined function xyz()
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=52627edit=1
[PHP-BUG] Req #52628 [NEW]: substr() returns false for empty string
From:
Operating system:
PHP version: Irrelevant
Package: Strings related
Bug Type: Feature/Change Request
Bug description:substr() returns false for empty string
Description:
substr() should not return FALSE if is used with empty string. Yes, it is
documented behaviour (If $string is less than or equal to $start characters
long, FALSE will be returned), but it is not expected behaviour. There is
no way to use smaller $start.
Test script:
---
substr('x', 0, 2) // returns again 'x'
substr('', 0, 2) // returns FALSE but '' is expected
--
Edit bug report at http://bugs.php.net/bug.php?id=52628edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52628r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52628r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52628r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52628r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52628r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52628r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52628r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52628r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52628r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52628r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52628r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52628r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52628r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52628r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52628r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52628r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52628r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52628r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52628r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52628r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52628r=mysqlcfg
Bug #52613 [Asn-Fbk]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613edit=1 ID: 52613 Updated by: and...@php.net Reported by:manuel at mausz dot at Summary:crash in mysqlnd -Status: Assigned +Status: Feedback Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N New Comment: This looks strange. ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090== Access not within mapped region at address 0x8 current_row in the calling function is NULL. Dereferencing NULL with index gives use first 0x0, then 0x4 and 0x8 - you are on 32bit system, thus 3 fields, in this case, on 64bit, this should have been the second field. But how is current_row NULL when there is explicit check just before that call. Anyway, could you try this patch (it is against 5.3.4-dev) and tell me whether it works for you. Your sources are a bit different, put it will probably apply without problem, with some notices. http://hristov.com/tmp/52613.patch.txt Thanks! Previous Comments: [2010-08-17 18:13:07] manuel at mausz dot at ==22090== Memcheck, a memory error detector ==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=390 crash2.php ==22090== Fatal error: Allowed memory size of 390 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12 ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22090== ==22090== ==22090== Process terminating with default action of signal 11 (SIGSEGV) ==22090== Access not within mapped region at address 0x8 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== If you believe this happened as a result of a stack ==22090== overflow in your program's main thread (unlikely but ==22090== possible), you can try to increase the size of the ==22090== main thread stack using the --main-stacksize= flag. ==22090== The main thread stack size used in this run was 8388608. ==22090== ==22090== HEAP SUMMARY: ==22090== in use at exit: 5,336,261 bytes in 31,521 blocks ==22090== total heap usage: 87,945 allocs, 56,424 frees, 11,136,282 bytes allocated ==22090== ==22090== LEAK SUMMARY: ==22090==definitely lost: 0 bytes in 0 blocks ==22090==indirectly lost: 0 bytes in 0 blocks ==22090== possibly lost: 363,504 bytes in 3,303 blocks ==22090==still reachable: 4,972,757 bytes in 28,218 blocks ==22090== suppressed: 0 bytes in 0 blocks ==22090== Rerun with --leak-check=full to see details of leaked memory ==22090== ==22090== For counts of detected and suppressed errors, rerun with: -v ==22090== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 7) Segmentation fault
Bug #52627 [Fbk-Opn]: Iterators trigger_error causes crash
Edit report at http://bugs.php.net/bug.php?id=52627edit=1
ID: 52627
User updated by:david at grudl dot com
Reported by:david at grudl dot com
Summary:Iterators trigger_error causes crash
-Status: Feedback
+Status: Open
Type: Bug
Package:Reproducible crash
PHP Version:5.3.3
Block user comment: N
New Comment:
I am sorry, this bug affects only 5.1.3 - 5.3.2 and is fixed in 5.3.3.
Previous Comments:
[2010-08-17 18:16:12] ahar...@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.
I can't reproduce this on OS X or Linux. Besides needing a backtrace,
we'll also need to know what operating system you're running.
[2010-08-17 18:11:32] david at grudl dot com
Description:
Throwing any error in foreach causes PHP to crash since PHP 5.1.3
Test script:
---
class MyFilterIterator extends FilterIterator
{
function accept() { return TRUE; }
}
$iterator = new RecursiveArrayIterator(array(1));
$iterator = new RecursiveIteratorIterator($iterator);
$iterator = new MyFilterIterator($iterator);
foreach ($iterator as $component) {
trigger_error('User error', E_USER_ERROR);
// or trigger fatal error by calling undefined function xyz()
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=52627edit=1
Bug #52627 [Opn-Csd]: Iterators trigger_error causes crash
Edit report at http://bugs.php.net/bug.php?id=52627edit=1
ID: 52627
User updated by:david at grudl dot com
Reported by:david at grudl dot com
Summary:Iterators trigger_error causes crash
-Status: Open
+Status: Closed
Type: Bug
Package:Reproducible crash
PHP Version:5.3.3
Block user comment: N
New Comment:
Closing
Previous Comments:
[2010-08-17 18:36:21] david at grudl dot com
I am sorry, this bug affects only 5.1.3 - 5.3.2 and is fixed in 5.3.3.
[2010-08-17 18:16:12] ahar...@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.
I can't reproduce this on OS X or Linux. Besides needing a backtrace,
we'll also need to know what operating system you're running.
[2010-08-17 18:11:32] david at grudl dot com
Description:
Throwing any error in foreach causes PHP to crash since PHP 5.1.3
Test script:
---
class MyFilterIterator extends FilterIterator
{
function accept() { return TRUE; }
}
$iterator = new RecursiveArrayIterator(array(1));
$iterator = new RecursiveIteratorIterator($iterator);
$iterator = new MyFilterIterator($iterator);
foreach ($iterator as $component) {
trigger_error('User error', E_USER_ERROR);
// or trigger fatal error by calling undefined function xyz()
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=52627edit=1
Req #52517 [Csd]: E_COMPILE_WARNING is not
Edit report at http://bugs.php.net/bug.php?id=52517edit=1 ID: 52517 User updated by:david at grudl dot com Reported by:david at grudl dot com Summary:E_COMPILE_WARNING is not Status: Closed Type: Feature/Change Request Package:Compile Warning PHP Version:5.3.3 Assigned To:kalle Block user comment: N New Comment: It is not about declare struct, it is about handing warnings notices by user-handler (and logging them e.g.). I am unable to catch and log this warning. Please re-open this issue. Previous Comments: [2010-08-16 21:42:34] ka...@php.net The declare struct have meaning for the script at compile time, not execution time hence its an E_COMPILE_WARNING. [2010-08-02 18:54:03] david at grudl dot com run-time error - runtime warning [2010-08-02 18:51:39] david at grudl dot com Description: E_COMPILE_WARNING is the only run-time error not catchable by user-defined error handler function (via set_error_handler). I suggest change this behavior. Test script: --- ?php declare(foo='bar'); // throws E_COMPILE_WARNING -- Edit this bug report at http://bugs.php.net/bug.php?id=52517edit=1
Bug #52613 [Fbk-Asn]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613edit=1 ID: 52613 User updated by:manuel at mausz dot at Reported by:manuel at mausz dot at Summary:crash in mysqlnd -Status: Feedback +Status: Assigned Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N New Comment: Patch works. No crashes anymore. Although I have to say that I added a check for current_row[col] myself and got some very weird memory corruptions on one webserver (out of ~40) after executing a simple mysql query. Don't know why they occured after adding that check.. Applying your patch to 5.3.3 didn't work, so I added your changes by hand and rediffed: http://pastie.org/private/lu8ajelnwwijjiebzzrrta Previous Comments: [2010-08-17 18:28:26] and...@php.net This looks strange. ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090== Access not within mapped region at address 0x8 current_row in the calling function is NULL. Dereferencing NULL with index gives use first 0x0, then 0x4 and 0x8 - you are on 32bit system, thus 3 fields, in this case, on 64bit, this should have been the second field. But how is current_row NULL when there is explicit check just before that call. Anyway, could you try this patch (it is against 5.3.4-dev) and tell me whether it works for you. Your sources are a bit different, put it will probably apply without problem, with some notices. http://hristov.com/tmp/52613.patch.txt Thanks! [2010-08-17 18:13:07] manuel at mausz dot at ==22090== Memcheck, a memory error detector ==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=390 crash2.php ==22090== Fatal error: Allowed memory size of 390 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12 ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22090== ==22090== ==22090== Process terminating with default action of signal 11 (SIGSEGV) ==22090== Access not within mapped region at address 0x8 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== If you believe this happened as a result of a stack ==22090== overflow in your program's main thread (unlikely but ==22090== possible), you can try to increase the size of the ==22090== main thread stack using the --main-stacksize= flag. ==22090== The main thread stack size used in this run was 8388608. ==22090== ==22090== HEAP SUMMARY: ==22090== in use at exit: 5,336,261 bytes in 31,521 blocks ==22090== total heap usage: 87,945 allocs, 56,424 frees, 11,136,282 bytes allocated ==22090== ==22090== LEAK SUMMARY: ==22090==definitely lost: 0 bytes in 0 blocks ==22090==indirectly
Bug #50830 [Com]: FILTER_VALIDATE_IP incorrectly validates a compressed IPv4-mapped IPv6 address
Edit report at http://bugs.php.net/bug.php?id=50830edit=1
ID: 50830
Comment by: michael at squiloople dot com
Reported by:mikerushton at hotmail dot co dot uk
Summary:FILTER_VALIDATE_IP incorrectly validates a
compressed IPv4-mapped IPv6 address
Status: Open
Type: Bug
Package:Filter related
Operating System: *
PHP Version:5.*, 6
Block user comment: N
New Comment:
It has come to my attention that the regular expression I provided above
uses
RFC 5321 as the authority on IPv6 address format. This differs from RFC
4291
however, which is the ACTUAL authority on IPv6 address format. The key
difference between the two is that 4291 allows a double colon to
represent just
ONE 16-bit group of zeros whereas 5321 requires that it represent at
least TWO
groups. As such, I have provided a modified regular expression which
conforms
with 4291 in this respect (and have also removed the unnecessary
capturing
groups present in my earlier regex)
(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){7})|(?:(?!(?:.*[a-f0-
9](?::|$)){8,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,6})?::(?:[a-f0-
9]{1,4}(?::[a-f0-9]{1,4}){0,6})?)))|(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){5}:)|(?:(?!(?:.*[a-f0-9]:){6,})(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){0,4})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,4}:)?)))?(?:25[0-5]|2[0-
4][0-9]|1[0-9]{2}|[1-9]?[0-9])(?:\.(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-
9])){3}))
Previous Comments:
[2010-02-01 15:34:13] mikerushton at hotmail dot co dot uk
An addition: here's my solution (as a regular expression):
(?:(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){7})|(?:(?!(?:.*[a-f0-9](?
::|$)){7,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,5})?::(?:[a-f0-9]{1,4}(?
::[a-f0-9]{1,4}){0,5})?)))|(?:(?:(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){5}:)|(?:(?!(?:.*[a-f0-9]:){5,})(?:[a-f0-9]{1,4}(?::[a-f0-
9]{1,4}){0,3})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,3}:)?))?(?:(?
:25[0-5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))(?:\.(?:(?:25[0-
5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))){3}))
[2010-01-24 15:45:29] mikerushton at hotmail dot co dot uk
Description:
FILTER_VALIDATE_IP validates the incorrect 0:::255.255.255.255 and does
not validate the correct 0::255.255.255.255
According to RFC 5321, the correct syntax is:
[IPv6-hex *3(: IPv6-hex)] :: [IPv6-hex *3(: IPv6-hex) :] IPv4-
address-literal
This does not allow for three consecutive colons.
Reproduce code:
---
// First
filter_var(':::255.255.255.255', FILTER_VALIDATE_IP);
// Second
filter_var('::255.255.255.255', FILTER_VALIDATE_IP);
Expected result:
// First
bool(false)
// Second
string(21) '::255.255.255.255'
Actual result:
--
// First
string(22) ':::255.255.255.255'
// Second
bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=50830edit=1
Bug #52613 [Asn]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613edit=1 ID: 52613 Updated by: and...@php.net Reported by:manuel at mausz dot at Summary:crash in mysqlnd Status: Assigned Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N New Comment: Can you test on the server, which exposed this memory problem? If it is ok, then I will commit the patch to the repository. Thanks! Previous Comments: [2010-08-17 18:47:19] manuel at mausz dot at Patch works. No crashes anymore. Although I have to say that I added a check for current_row[col] myself and got some very weird memory corruptions on one webserver (out of ~40) after executing a simple mysql query. Don't know why they occured after adding that check.. Applying your patch to 5.3.3 didn't work, so I added your changes by hand and rediffed: http://pastie.org/private/lu8ajelnwwijjiebzzrrta [2010-08-17 18:28:26] and...@php.net This looks strange. ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090== Access not within mapped region at address 0x8 current_row in the calling function is NULL. Dereferencing NULL with index gives use first 0x0, then 0x4 and 0x8 - you are on 32bit system, thus 3 fields, in this case, on 64bit, this should have been the second field. But how is current_row NULL when there is explicit check just before that call. Anyway, could you try this patch (it is against 5.3.4-dev) and tell me whether it works for you. Your sources are a bit different, put it will probably apply without problem, with some notices. http://hristov.com/tmp/52613.patch.txt Thanks! [2010-08-17 18:13:07] manuel at mausz dot at ==22090== Memcheck, a memory error detector ==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=390 crash2.php ==22090== Fatal error: Allowed memory size of 390 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12 ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22090== ==22090== ==22090== Process terminating with default action of signal 11 (SIGSEGV) ==22090== Access not within mapped region at address 0x8 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== If you believe this happened as a result of a stack ==22090== overflow in your program's main thread (unlikely but ==22090== possible), you can try to increase the size of the ==22090== main thread stack using the --main-stacksize= flag. ==22090== The main thread stack size used in this run was 8388608. ==22090== ==22090== HEAP SUMMARY: ==22090== in use at exit: 5,336,261
Bug #52613 [Asn-Fbk]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613edit=1 ID: 52613 Updated by: and...@php.net Reported by:manuel at mausz dot at Summary:crash in mysqlnd -Status: Assigned +Status: Feedback Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N Previous Comments: [2010-08-17 19:04:56] and...@php.net Can you test on the server, which exposed this memory problem? If it is ok, then I will commit the patch to the repository. Thanks! [2010-08-17 18:47:19] manuel at mausz dot at Patch works. No crashes anymore. Although I have to say that I added a check for current_row[col] myself and got some very weird memory corruptions on one webserver (out of ~40) after executing a simple mysql query. Don't know why they occured after adding that check.. Applying your patch to 5.3.3 didn't work, so I added your changes by hand and rediffed: http://pastie.org/private/lu8ajelnwwijjiebzzrrta [2010-08-17 18:28:26] and...@php.net This looks strange. ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090== Access not within mapped region at address 0x8 current_row in the calling function is NULL. Dereferencing NULL with index gives use first 0x0, then 0x4 and 0x8 - you are on 32bit system, thus 3 fields, in this case, on 64bit, this should have been the second field. But how is current_row NULL when there is explicit check just before that call. Anyway, could you try this patch (it is against 5.3.4-dev) and tell me whether it works for you. Your sources are a bit different, put it will probably apply without problem, with some notices. http://hristov.com/tmp/52613.patch.txt Thanks! [2010-08-17 18:13:07] manuel at mausz dot at ==22090== Memcheck, a memory error detector ==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=390 crash2.php ==22090== Fatal error: Allowed memory size of 390 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12 ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22090== ==22090== ==22090== Process terminating with default action of signal 11 (SIGSEGV) ==22090== Access not within mapped region at address 0x8 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== If you believe this happened as a result of a stack ==22090== overflow in your program's main thread (unlikely but ==22090== possible), you can try to increase the size of the ==22090== main thread stack using the --main-stacksize= flag. ==22090== The main
Bug #47021 [Com]: SoapClient stumbles over WSDL delivered with Transfer-Encoding: chunked
Edit report at http://bugs.php.net/bug.php?id=47021edit=1 ID: 47021 Comment by: n dot engyozov at taxundo dot com Reported by:daniel dot gorski at develnet dot org Summary:SoapClient stumbles over WSDL delivered with Transfer-Encoding: chunked Status: To be documented Type: Bug Package:SOAP related Operating System: Linux PHP Version:5.3CVS-2009-01-06 (CVS) Block user comment: N New Comment: I can confirm the problem is still present in my PHP version 5.3.3 even after recompiling with changes made by Dmitry and with disabled curlwrapper. The problem breaks wsdls from yahoo i google APIs. Previous Comments: [2010-03-03 12:26:58] pcdinh at gmail dot com Have you tried to recompile PHP with --without-curlwrapper? I solved my case. [2009-05-17 05:18:55] shadda at gmail dot com I ran into this bug today myself, and after having compiled the latest snapshot as of 8:00pm CST 2009-05-16 I am still experiencing this error. [2009-04-16 10:56:27] bj...@php.net This was fixed by introducing an 'dechunk' stream filter, see http://news.php.net/php.cvs/57042 [2009-04-16 10:34:48] dmi...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-01-26 10:54:53] giovanni at giacobbi dot net Please see related discussion: http://marc.info/?t=12329199332r=1w=2 See also bug report #43069 which actually caused this bug. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=47021 -- Edit this bug report at http://bugs.php.net/bug.php?id=47021edit=1
Bug #52613 [Fbk-Asn]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613edit=1 ID: 52613 User updated by:manuel at mausz dot at Reported by:manuel at mausz dot at Summary:crash in mysqlnd -Status: Feedback +Status: Assigned Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N New Comment: Did that already. No memory corruption for now. If it happens again I'll tell you. Previous Comments: [2010-08-17 19:04:56] and...@php.net Can you test on the server, which exposed this memory problem? If it is ok, then I will commit the patch to the repository. Thanks! [2010-08-17 18:47:19] manuel at mausz dot at Patch works. No crashes anymore. Although I have to say that I added a check for current_row[col] myself and got some very weird memory corruptions on one webserver (out of ~40) after executing a simple mysql query. Don't know why they occured after adding that check.. Applying your patch to 5.3.3 didn't work, so I added your changes by hand and rediffed: http://pastie.org/private/lu8ajelnwwijjiebzzrrta [2010-08-17 18:28:26] and...@php.net This looks strange. ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090== Access not within mapped region at address 0x8 current_row in the calling function is NULL. Dereferencing NULL with index gives use first 0x0, then 0x4 and 0x8 - you are on 32bit system, thus 3 fields, in this case, on 64bit, this should have been the second field. But how is current_row NULL when there is explicit check just before that call. Anyway, could you try this patch (it is against 5.3.4-dev) and tell me whether it works for you. Your sources are a bit different, put it will probably apply without problem, with some notices. http://hristov.com/tmp/52613.patch.txt Thanks! [2010-08-17 18:13:07] manuel at mausz dot at ==22090== Memcheck, a memory error detector ==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=390 crash2.php ==22090== Fatal error: Allowed memory size of 390 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12 ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22090== ==22090== ==22090== Process terminating with default action of signal 11 (SIGSEGV) ==22090== Access not within mapped region at address 0x8 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== If you believe this happened as a result of a stack ==22090== overflow in your program's main thread (unlikely but ==22090== possible), you can try to
Bug #52613 [Asn]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613edit=1 ID: 52613 Updated by: and...@php.net Reported by:manuel at mausz dot at Summary:crash in mysqlnd Status: Assigned Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N New Comment: alrighty, then I will commit it. If something happens feel free to reopen or create a new report with reference to this one. Previous Comments: [2010-08-17 19:16:17] manuel at mausz dot at Did that already. No memory corruption for now. If it happens again I'll tell you. [2010-08-17 19:04:56] and...@php.net Can you test on the server, which exposed this memory problem? If it is ok, then I will commit the patch to the repository. Thanks! [2010-08-17 18:47:19] manuel at mausz dot at Patch works. No crashes anymore. Although I have to say that I added a check for current_row[col] myself and got some very weird memory corruptions on one webserver (out of ~40) after executing a simple mysql query. Don't know why they occured after adding that check.. Applying your patch to 5.3.3 didn't work, so I added your changes by hand and rediffed: http://pastie.org/private/lu8ajelnwwijjiebzzrrta [2010-08-17 18:28:26] and...@php.net This looks strange. ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090== Access not within mapped region at address 0x8 current_row in the calling function is NULL. Dereferencing NULL with index gives use first 0x0, then 0x4 and 0x8 - you are on 32bit system, thus 3 fields, in this case, on 64bit, this should have been the second field. But how is current_row NULL when there is explicit check just before that call. Anyway, could you try this patch (it is against 5.3.4-dev) and tell me whether it works for you. Your sources are a bit different, put it will probably apply without problem, with some notices. http://hristov.com/tmp/52613.patch.txt Thanks! [2010-08-17 18:13:07] manuel at mausz dot at ==22090== Memcheck, a memory error detector ==22090== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==22090== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==22090== Command: /root/php-5.3.3/sapi/cli/php -dmemory_limit=390 crash2.php ==22090== Fatal error: Allowed memory size of 390 bytes exhausted (tried to allocate 20 bytes) in /var/www/test2/crash2.php on line 12 ==22090== Invalid read of size 4 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29: php_request_shutdown (main.c:1633) ==22090== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22090== ==22090== ==22090== Process terminating with default action of signal 11 (SIGSEGV) ==22090== Access not within mapped region at address 0x8 ==22090==at 0x82BC0E2: mysqlnd_palloc_zval_ptr_dtor (mysqlnd_result.c:103) ==22090==by 0x82BE1A8: php_mysqlnd_res_free_buffered_data_pub (mysqlnd_result.c:208) ==22090==by 0x82BE0AF: php_mysqlnd_res_free_result_buffers_pub (mysqlnd_result.c:253) ==22090==by 0x82BD86F: mysqlnd_internal_free_result_contents (mysqlnd_result.c:285) ==22090==by 0x82BD81F: mysqlnd_internal_free_result (mysqlnd_result.c:302) ==22090==by 0x82BCDA5: php_mysqlnd_res_free_result_pub (mysqlnd_result.c:1336) ==22090==by 0x8178D46: _free_mysql_result (php_mysql.c:417) ==22090==by 0x83236F1: list_entry_destructor (zend_list.c:184) ==22090==by 0x83209D6: zend_hash_apply_deleter (zend_hash.c:611) ==22090==by 0x8320C56: zend_hash_graceful_reverse_destroy (zend_hash.c:646) ==22090==by 0x8315475: zend_deactivate (zend.c:896) ==22090==by 0x82C5D29:
Bug #52613 [Asn-Csd]: crash in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=52613edit=1 ID: 52613 Updated by: and...@php.net Reported by:manuel at mausz dot at Summary:crash in mysqlnd -Status: Assigned +Status: Closed Type: Bug Package:MySQL related Operating System: Unix PHP Version:5.3.3 Assigned To:andrey Block user comment: N Previous Comments: [2010-08-17 20:08:26] and...@php.net alrighty, then I will commit it. If something happens feel free to reopen or create a new report with reference to this one. [2010-08-17 20:08:26] and...@php.net Automatic comment from SVN on behalf of andrey Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=302398 Log: Fix for Bug #52613 crash in mysqlnd [2010-08-17 19:16:17] manuel at mausz dot at Did that already. No memory corruption for now. If it happens again I'll tell you. [2010-08-17 19:04:56] and...@php.net Can you test on the server, which exposed this memory problem? If it is ok, then I will commit the patch to the repository. Thanks! [2010-08-17 18:47:19] manuel at mausz dot at Patch works. No crashes anymore. Although I have to say that I added a check for current_row[col] myself and got some very weird memory corruptions on one webserver (out of ~40) after executing a simple mysql query. Don't know why they occured after adding that check.. Applying your patch to 5.3.3 didn't work, so I added your changes by hand and rediffed: http://pastie.org/private/lu8ajelnwwijjiebzzrrta The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52613 -- Edit this bug report at http://bugs.php.net/bug.php?id=52613edit=1
Req #52517 [Csd]: E_COMPILE_WARNING is not
Edit report at http://bugs.php.net/bug.php?id=52517edit=1 ID: 52517 Updated by: ka...@php.net Reported by:david at grudl dot com Summary:E_COMPILE_WARNING is not Status: Closed Type: Feature/Change Request Package:Compile Warning PHP Version:5.3.3 Assigned To:kalle Block user comment: N New Comment: Yes it is, as declare is evaluated at compile time, not execution time hence its not possible to catch the warning anyway as its thrown before the executor is hit. Previous Comments: [2010-08-17 18:43:36] david at grudl dot com It is not about declare struct, it is about handing warnings notices by user-handler (and logging them e.g.). I am unable to catch and log this warning. Please re-open this issue. [2010-08-16 21:42:34] ka...@php.net The declare struct have meaning for the script at compile time, not execution time hence its an E_COMPILE_WARNING. [2010-08-02 18:54:03] david at grudl dot com run-time error - runtime warning [2010-08-02 18:51:39] david at grudl dot com Description: E_COMPILE_WARNING is the only run-time error not catchable by user-defined error handler function (via set_error_handler). I suggest change this behavior. Test script: --- ?php declare(foo='bar'); // throws E_COMPILE_WARNING -- Edit this bug report at http://bugs.php.net/bug.php?id=52517edit=1
Bug #44643 [Com]: bound parameters ignore explicit type definitions
Edit report at http://bugs.php.net/bug.php?id=44643edit=1
ID: 44643
Comment by: kraven at kraven dot org
Reported by:ethan dot nelson at ltd dot org
Summary:bound parameters ignore explicit type definitions
Status: Open
Type: Bug
Package:PDO related
Operating System: *
PHP Version:5.2CVS-2009-03-20
Block user comment: N
New Comment:
This is caused by a long standing MS SQL ODBC Client bug.
http://connect.microsoft.com/SQLServer/feedback/details/521409/odbc-client-mssql-does-not-work-with-bound-parameters-in-subquery
Last update on 8/3/2010 was that it would be resolved in a future
release of the SQL Server Native Access Client.
Previous Comments:
[2009-05-21 21:49:40] ethan dot nelson at ltd dot org
This also happens for the new Native Client 10.0 driver for SQL 2008.
SELECT * FROM (SELECT 'test' = :id) a WHERE a.test = :id2
Array
(
[0] = 42000
[1] = 402
[2] = [Microsoft][SQL Server Native Client 10.0][SQL Server]The
data types text and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)
[3] = 42000
)
PHP Version 5.2.9-2
System Windows NT LTD-PWWW2 5.2 build 3790
Build Date Apr 9 2009 08:22:37
Configure Command cscript /nologo configure.js --enable-snapshot-
build --enable-debug-pack --with-snapshot-template=d:\php-
sdk\snap_5_2\vc6\x86\template --with-php-build=d:\php-
sdk\snap_5_2\vc6\x86\php_build --with-pdo-oci=D:\php-
sdk\oracle\instantclient10\sdk,shared --with-oci8=D:\php-
sdk\oracle\instantclient10\sdk,shared
Server API ISAPI
[2009-03-20 17:12:18] phpbugs at matthewboehm dot com
RHEL-5.3 php5.2-200903201530
Invalid character value for cast specification: 206 [FreeTDS][SQL
Server]Operand type clash: text is incompatible with int
(SQLExecute[206] at /usr/src/php5.2-
200903201530/ext/pdo_odbc/odbc_stmt.c:133
[2008-10-28 17:37:00] ethan dot nelson at ltd dot org
?php
ini_set(display_errors,yes);
$poo = new PDO(odbc:DEVELOPMENT);
$query = SELECT * FROM (SELECT 'test' = :id) a WHERE a.test = :id2;
$stm = $poo-prepare($query);
echo $query.br\n;
$id = 1;
$stm-bindParam(':id',$id,PDO::PARAM_INT);
$id2 = 1;
$stm-bindParam(':id2',$id2,PDO::PARAM_INT);
echo pre\n;
if ($stm-execute()) print_r($stm-fetchAll(PDO::FETCH_ASSOC));
else print_r( $stm-errorInfo());
echo /pre\n;
phpinfo();
?
---The above returns the below result:
SELECT * FROM (SELECT 'test' = :id) a WHERE a.test = :id2
Array
(
[0] = 42000
[1] = 402
[2] = [Microsoft][SQL Native Client][SQL Server]The data types
text and text are incompatible in the equal to operator.
(SQLExecute[402] at ext\pdo_odbc\odbc_stmt.c:133)
[3] = 42000
)
PHP Version 5.2.7RC2-dev
[2008-04-05 00:19:04] ethan dot nelson at ltd dot org
Description:
There is a type switching problem with bound parameters in PDO when the
query contains a WHERE clause:
works - SELECT * FROM (SELECT 'test' = 1) a
works - SELECT * FROM (SELECT 'test' = 1) a WHERE a.test = 1
fails - SELECT * FROM (SELECT 'test' = :id) a WHERE a.test = 1
works - SELECT * FROM (SELECT 'test' = 1) a WHERE a.test = :id
fails - SELECT * FROM (SELECT 'test' = :id) a WHERE a.test = :id2
Reproduce code:
---
$con = new PDO('odbc:Brokerage EPC Database');
$query = SELECT * FROM (SELECT 'test' = 1) a;
$stm = $con-prepare($query);
echo $query.br\n;
if ($stm-execute()) echo Yea!p\n;
else echo Boo!p\n;
$query = SELECT * FROM (SELECT 'test' = 1) a WHERE a.test = 1;
$stm = $con-prepare($query);
echo $query.br\n;
if ($stm-execute()) echo Yea!p\n;
else echo Boo!p\n;
$query = SELECT * FROM (SELECT 'test' = :id) a WHERE a.test = 1;
$stm = $con-prepare($query);
echo $query.br\n;
$id = 1;
$stm-bindParam(':id',$id,PDO::PARAM_INT);
if ($stm-execute()) echo Yea!p\n;
else echo Boo!p\n;
$query = SELECT * FROM (SELECT 'test' = 1) a WHERE a.test = :id2;
$stm = $con-prepare($query);
echo $query.br\n;
$id2 = 1;
$stm-bindParam(':id2',$id2,PDO::PARAM_INT);
if ($stm-execute()) echo Yea!p\n;
else echo Boo!p\n;
$query = SELECT * FROM (SELECT 'test' = :id) a WHERE a.test = :id2;
$stm = $con-prepare($query);
echo $query.br\n;
$id = 1;
$stm-bindParam(':id',$id,PDO::PARAM_INT);
$id2 = 1;
$stm-bindParam(':id2',$id2,PDO::PARAM_INT);
if ($stm-execute()) echo Yea!p\n;
else echo Boo!p\n;
Expected result:
SELECT * FROM (SELECT 'test' = 1) a
Yea!
SELECT * FROM (SELECT 'test' = 1) a WHERE a.test = 1
Yea!
SELECT * FROM (SELECT 'test' = :id) a WHERE a.test = 1
Yea!
SELECT * FROM
Bug #36561 [Com]: PDO_ODBC/MSSQL does not work with bound params in subquery
Edit report at http://bugs.php.net/bug.php?id=36561edit=1
ID: 36561
Comment by: kraven at kraven dot org
Reported by:travis at raybold dot com
Summary:PDO_ODBC/MSSQL does not work with bound params in
subquery
Status: Bogus
Type: Bug
Package:PDO related
Operating System: Windows XP
PHP Version:5.2.4
Assigned To:fmk
Block user comment: N
New Comment:
This is caused by a long standing MS SQL ODBC Client bug.
http://connect.microsoft.com/SQLServer/feedback/details/521409/odbc-client-mssql-does-not-work-with-bound-parameters-in-subquery
Last update on 8/3/2010 was that it would be resolved in a future
release of the SQL Server Native Access Client.
Previous Comments:
[2009-04-25 14:37:25] j...@php.net
Not PHP bug - bogus.
[2008-03-03 20:50:31] auroraeosr...@php.net
This appears to be a bug with prepared statements in the underlying
microsoft client driver implementation...
Even the microsoft SQL Server 2005 Driver for php suffers from this bug
?php
$iTestID=1;
$connection = sqlsrv_connect($dsn);
$statement = sqlsrv_prepare($connection,
'SELECT TestID FROM zTest_TBL WHERE TestID IN (SELECT TestID FROM
zTest_TBL WHERE TestID = ?)',
array($iTestID));
$value = sqlsrv_execute($statement);
print_r(sqlsrv_errors());
?
so it appears the issue is upstream and we have to wait for microsoft..
[2008-01-06 23:02:41] emil at troxy dot net
I was able to reproduce this error using the 2008-01-05 snapshot of
PDO_ODBC.
Reproduce code:
---
?php
$db = new PDO('odbc:Driver={SQL Server}; Server=localhost; Uid=test;
Pwd=test; Database=test;');
$db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$db-exec('CREATE TABLE #foo (id INT NOT NULL)');
$db-exec('INSERT INTO #foo VALUES(1)');
$stmt = $db-prepare('SELECT id FROM #foo WHERE id IN (SELECT id FROM
#foo WHERE id = ?)');
$stmt-bindValue(1, 1, PDO::PARAM_INT);
$stmt-execute();
var_dump($stmt-fetch(PDO::FETCH_ASSOC));
?
Expected result:
array(1) { [id]= string(1) 1 }
Actual result:
--
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[42000]: Syntax error or access violation: 306 [Microsoft][ODBC
SQL Server Driver][SQL Server]The text, ntext, and image data types
cannot be compared or sorted, except when using IS NULL or LIKE
operator. (SQLExecute[306] at ..\pecl_5_2\pdo_odbc\odbc_stmt.c:133)'
A trace using the Profiler tool shows that the bound integer value is
incorrectly interpreted as text:
CREATE TABLE #foo (id INT NOT NULL)
go
INSERT INTO #foo VALUES(1)
go
declare @P1 int
set @P1=NULL
exec sp_prepare @P1 output, N'@P1 text', N'SELECT id FROM #foo WHERE id
IN (SELECT id FROM #foo WHERE id = @P1)', 1
select @P1
go
Incorrect: N'@P1 text'
It should be: N'@P1 int'
[2007-08-31 07:35:18] j...@php.net
Assigned to the maintainer.
[2007-08-31 07:33:12] j...@php.net
Very nice that you didn't bother trying with the RCs..
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=36561
--
Edit this bug report at http://bugs.php.net/bug.php?id=36561edit=1
Bug #52070 [Opn-Csd]: imagedashedline() - dashed line sometimes is not visible
Edit report at http://bugs.php.net/bug.php?id=52070edit=1
ID: 52070
User updated by:tgabor72 at freemail dot hu
Reported by:tgabor72 at freemail dot hu
Summary:imagedashedline() - dashed line sometimes is not
visible
-Status: Open
+Status: Closed
Type: Bug
Package:GD related
Operating System: WinXP - IIS -fastcgi
PHP Version:5.3.2
Block user comment: N
New Comment:
You can use the imagepatternedline() function with extra features
instead of imagedashedline() to give a visible dashedlines and other any
kind of patterned lines on your images. The routine also manages the
thickness of the line. Have fun!
// imagepatternedline() function
// Routine was developed to draw any kind of straight line with
thickness. Routine uses imageline() function to draw line.
// Parameters are (similar to imageline() function):
// $image: (resource) imagefile
// $xstart, $ystart: (int) x,y coordinates for first point
// $xend, $yend: (int) x,y coordinates for last point
// $color: (int) color identifier that created with
imagecolorallocate()
// extra parameters:
// $thickness: (int) thickness of line in pixel
// $pattern: (string) pattern of line, which repeats continuously
while line is being drawed.
// If there is '1' in the pattern that means the actual dot of line is
visible,
// '0' means dot is not visible (space between two line elements).
// All characters regard for one pixel. Default: 1 dot wide dashed
line with 4-4 dots and spaces.
// Examples for pattern:
// 1 or continuous line
// 10 close dotline
// 1 dotline
// 001100 dotline for design drawing
// 11001100110011 double dotline
// some examples for using imagepatternedline():
// imagepatternedline($image,300,300,442,442,$color,200,); // a square
with 200 length of edge and rotated 45 degrees
// imagepatternedline($image,100,200,289,200,$color,100,
// 11001100110011001100111100
// .00110000110011110011001100
// .11110011110000
// .00110011111100110011); // barcode
function imagepatternedline($image, $xstart, $ystart, $xend, $yend,
$color, $thickness=1, $pattern=1111) {
$pattern=(!strlen($pattern)) ? 1 : $pattern;
$x=$xend-$xstart;
$y=$yend-$ystart;
$length=floor(sqrt(pow(($x),2)+pow(($y),2)));
$fullpattern=$pattern;
while (strlen($fullpattern)$length) $fullpattern.=$pattern;
if (!$length) {
if ($fullpattern[0]) imagefilledellipse($image, $xstart, $ystart,
$thickness, $thickness, $color);
return;
}
$x1=$xstart;
$y1=$ystart;
$x2=$x1;
$y2=$y1;
$mx=$x/$length;
$my=$y/$length;
$line=;
for($i=0;$i$length;$i++){
if (strlen($line)==0 or $fullpattern[$i]==$line[0]) {
$line.=$fullpattern[$i];
}else{
$x2+=strlen($line)*$mx;
$y2+=strlen($line)*$my;
if ($line[0]) imageline($image, round($x1), round($y1),
round($x2-$mx), round($y2-$my), $color);
$k=1;
for($j=0;$j$thickness-1;$j++) {
$k1=-(($k-0.5)*$my)*(floor($j*0.5)+1)*2;
$k2= (($k-0.5)*$mx)*(floor($j*0.5)+1)*2;
$k=1-$k;
if ($line[0]) {
imageline($image, round($x1)+$k1, round($y1)+$k2,
round($x2-$mx)+$k1, round($y2-$my)+$k2, $color);
if ($y) imageline($image, round($x1)+$k1+1,
round($y1)+$k2, round($x2-$mx)+$k1+1, round($y2-$my)+$k2, $color);
if ($x) imageline($image, round($x1)+$k1,
round($y1)+$k2+1, round($x2-$mx)+$k1, round($y2-$my)+$k2+1, $color);
}
}
$x1=$x2;
$y1=$y2;
$line=$fullpattern[$i];
}
}
$x2+=strlen($line)*$mx;
$y2+=strlen($line)*$my;
if ($line[0]) imageline($image, round($x1), round($y1), round($xend),
round($yend), $color);
$k=1;
for($j=0;$j$thickness-1;$j++) {
$k1=-(($k-0.5)*$my)*(floor($j*0.5)+1)*2;
$k2= (($k-0.5)*$mx)*(floor($j*0.5)+1)*2;
$k=1-$k;
if ($line[0]) {
imageline($image, round($x1)+$k1, round($y1)+$k2,
round($xend)+$k1, round($yend)+$k2, $color);
if ($y) imageline($image, round($x1)+$k1+1, round($y1)+$k2,
round($xend)+$k1+1, round($yend)+$k2, $color);
if ($x) imageline($image, round($x1)+$k1, round($y1)+$k2+1,
round($xend)+$k1, round($yend)+$k2+1, $color);
}
}
}
Previous Comments:
[2010-06-13 00:28:12] tgabor72 at freemail dot hu
Description:
This bug first was realized by me in php 5.3.1. imagedashedline()
function is not work properly. Tipically horizontal and sharp-angled
dashed lines is not visible after running this function. Could someone
make a patch or fix this
Req #49576 [Com]: Filter var for validating email is not validating emails correctly
Edit report at http://bugs.php.net/bug.php?id=49576edit=1
ID: 49576
Comment by: michael at squiloople dot com
Reported by:mparkin at de-facto dot com
Summary:Filter var for validating email is not validating
emails correctly
Status: Feedback
Type: Feature/Change Request
Package:*General Issues
Operating System: *
PHP Version:5.*
Assigned To:rasmus
Block user comment: N
New Comment:
You might find this useful, taken directly from my article on E-mail
address
validation, in deciding whether or not to allow single-label domain
names:
There is some confusion over whether or not single-label domain names
are
allowed â mich...@squiloople, for example. People often cite the
following
section in RFC 5321 to argue that they are not allowed:
'Only resolvable, fully-qualified domain names (FQDNs) are permitted
when
domain names are used in SMTP. In other words, names that can be
resolved to MX
RRs or address (i.e., A or ) RRs (as discussed in Section 5) are
permitted,
as are CNAME RRs whose targets can be resolved, in turn, to MX or
address RRs.
Local nicknames or unqualified names MUST NOT be used.'
The implicit premise here is that TLD-only domain names cannot be
resolved to
MX RRs. This is simply untrue: both checkdnsrr('ai', 'MX') and
getmxrr('ai',
$array) return true, showing that single-label domain names can, and do,
resolve
to MX RRs. Additionally, http://www.to/ is a valid, and active, domain.
Therefore, mich...@squiloople is valid (although in this example,
âsquiloopleâ
is not a TLD).
And as an extra note, hereâs another excerpt from RFC 5321:
'In the case of a top-level domain used by itself in an email address,
a single
string is used without any dots.'
Previous Comments:
[2010-08-15 02:09:23] paj...@php.net
Have you tried with 5.2.14 or 5.3.3?
[2010-08-14 21:10:33] grangeway at hotmail dot com
Additionally:
1) at the moment, I believe the current regex does not allow f...@com as
an
email address. Albeit, it's going back almost 10 years now - I'm pretty
sure I
received an email from someone @tld, complaining that a regex did not
allow
their valid email address to sign up.
2) The issue the user hit is the phpmailer class contains the following
code to
validate email addresses against FILTER_VALIDATE_EMAIL regardless of
whether
SMTP or mail() is the sending method.
550 public static function ValidateAddress($address) {
551if (function_exists('filter_var')) { //Introduced in PHP 5.2
...
else
regex
[2010-08-14 20:48:24] ka...@php.net
Re-opened, the last comment seems quite valid to me, don't you think so
Rasmus?
[2010-08-05 16:41:58] alexsander dot rosa at gmail dot com
The format usern...@box for local networks IS allowed when the mail()
method is used. I quote RFC 5321: local aliases MUST NOT appear in any
SMTP transaction. They say NOTHING about mail() method in the RFC.
[2010-04-02 19:57:45] ras...@php.net
A much better RFC-compliant regex has been committed now.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=49576
--
Edit this bug report at http://bugs.php.net/bug.php?id=49576edit=1
Req #52517 [Csd]: E_COMPILE_WARNING is not
Edit report at http://bugs.php.net/bug.php?id=52517edit=1 ID: 52517 Updated by: ka...@php.net Reported by:david at grudl dot com Summary:E_COMPILE_WARNING is not Status: Closed Type: Feature/Change Request Package:Compile Warning PHP Version:5.3.3 Assigned To:kalle -Block user comment: N +Block user comment: Y New Comment: There is alot of difference between them. Using your example code the declare statement is hit at compile time, so before the the executor is triggered that hooks into the error handler the warning is already thrown. Same things goes for includes, although they are as you rightly put it, executed at runtime. This is how the Zend Engine is designed and not going to change. Previous Comments: [2010-08-17 21:47:22] david at grudl dot com There is not difference between compile time or execution time. Compilation is invoked by include or require or eval in run time. So statements require throw E_COMPILE_WARNING and you cannot handle them using user-defined error handler. [2010-08-17 20:20:11] ka...@php.net Yes it is, as declare is evaluated at compile time, not execution time hence its not possible to catch the warning anyway as its thrown before the executor is hit. [2010-08-17 18:43:36] david at grudl dot com It is not about declare struct, it is about handing warnings notices by user-handler (and logging them e.g.). I am unable to catch and log this warning. Please re-open this issue. [2010-08-16 21:42:34] ka...@php.net The declare struct have meaning for the script at compile time, not execution time hence its an E_COMPILE_WARNING. [2010-08-02 18:54:03] david at grudl dot com run-time error - runtime warning The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52517 -- Edit this bug report at http://bugs.php.net/bug.php?id=52517edit=1
[PHP-BUG] Bug #52630 [NEW]: additional syntax for closures
From:
Operating system: all
PHP version: 5.3.3
Package: Variables related
Bug Type: Bug
Bug description:additional syntax for closures
Description:
hi, would be nice having this syntax for closures
$this-addResult
(
(
function ($param) use ($x) { return $x*$param; }
)($result)
);
a closure defined and executed in the same instruction, as JavaScript
allows
--
Edit bug report at http://bugs.php.net/bug.php?id=52630edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52630r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52630r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52630r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52630r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52630r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52630r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52630r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52630r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52630r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52630r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52630r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52630r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52630r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52630r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52630r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52630r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52630r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52630r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52630r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52630r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52630r=mysqlcfg
Req #52628 [Opn-Csd]: substr() returns false for empty string
Edit report at http://bugs.php.net/bug.php?id=52628edit=1
ID: 52628
Updated by: ka...@php.net
Reported by:david at grudl dot com
Summary:substr() returns false for empty string
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:Strings related
PHP Version:Irrelevant
-Assigned To:
+Assigned To:kalle
Block user comment: N
New Comment:
I don't think it makes any sense to pass an empty string directly to
substr and make it behave weirdly. Just wrap it inside an if statement
to check if the string is empty if you are using userdata.
In either case, calling sub string on an empty string would return
nothing, simply casting it to a string makes it empty:
$string = (string) substr('', 0, 2);
Previous Comments:
[2010-08-17 18:22:33] david at grudl dot com
Description:
substr() should not return FALSE if is used with empty string. Yes, it
is documented behaviour (If $string is less than or equal to $start
characters long, FALSE will be returned), but it is not expected
behaviour. There is no way to use smaller $start.
Test script:
---
substr('x', 0, 2) // returns again 'x'
substr('', 0, 2) // returns FALSE but '' is expected
--
Edit this bug report at http://bugs.php.net/bug.php?id=52628edit=1
Bug #52630 [Opn]: additional syntax for closures
Edit report at http://bugs.php.net/bug.php?id=52630edit=1
ID: 52630
Updated by: ka...@php.net
Reported by:giorgio dot liscio at email dot it
Summary:additional syntax for closures
Status: Open
Type: Bug
Package:Variables related
Operating System: all
PHP Version:5.3.3
-Assigned To:
+Assigned To:stas
Block user comment: N
New Comment:
I belive stas' had a patch for this? Or atleast function call chaining,
but I assume if implemented it would allow this syntax?
Previous Comments:
[2010-08-17 22:17:26] giorgio dot liscio at email dot it
Description:
hi, would be nice having this syntax for closures
$this-addResult
(
(
function ($param) use ($x) { return $x*$param; }
)($result)
);
a closure defined and executed in the same instruction, as JavaScript
allows
--
Edit this bug report at http://bugs.php.net/bug.php?id=52630edit=1
Req #52628 [Csd]: substr() returns false for empty string
Edit report at http://bugs.php.net/bug.php?id=52628edit=1
ID: 52628
User updated by:david at grudl dot com
Reported by:david at grudl dot com
Summary:substr() returns false for empty string
Status: Closed
Type: Feature/Change Request
Package:Strings related
PHP Version:Irrelevant
Assigned To:kalle
Block user comment: N
New Comment:
Example: I have string $s and want to short it to 5 characters:
$res = substr($s, 0, 5);
Question: is $res string of boolean?
Previous Comments:
[2010-08-17 22:19:54] ka...@php.net
I don't think it makes any sense to pass an empty string directly to
substr and make it behave weirdly. Just wrap it inside an if statement
to check if the string is empty if you are using userdata.
In either case, calling sub string on an empty string would return
nothing, simply casting it to a string makes it empty:
$string = (string) substr('', 0, 2);
[2010-08-17 18:22:33] david at grudl dot com
Description:
substr() should not return FALSE if is used with empty string. Yes, it
is documented behaviour (If $string is less than or equal to $start
characters long, FALSE will be returned), but it is not expected
behaviour. There is no way to use smaller $start.
Test script:
---
substr('x', 0, 2) // returns again 'x'
substr('', 0, 2) // returns FALSE but '' is expected
--
Edit this bug report at http://bugs.php.net/bug.php?id=52628edit=1
Req #52628 [Csd]: substr() returns false for empty string
Edit report at http://bugs.php.net/bug.php?id=52628edit=1
ID: 52628
Updated by: ka...@php.net
Reported by:david at grudl dot com
Summary:substr() returns false for empty string
Status: Closed
Type: Feature/Change Request
Package:Strings related
PHP Version:Irrelevant
Assigned To:kalle
-Block user comment: N
+Block user comment: Y
New Comment:
Then check the return value of substr():
if(($string = substr($old_string, 0, 5)) === false) {
/* error */
}
There is a million ways to over come this problem, simply check the
string first before trying to substring it
Previous Comments:
[2010-08-17 22:22:31] david at grudl dot com
Example: I have string $s and want to short it to 5 characters:
$res = substr($s, 0, 5);
Question: is $res string of boolean?
[2010-08-17 22:19:54] ka...@php.net
I don't think it makes any sense to pass an empty string directly to
substr and make it behave weirdly. Just wrap it inside an if statement
to check if the string is empty if you are using userdata.
In either case, calling sub string on an empty string would return
nothing, simply casting it to a string makes it empty:
$string = (string) substr('', 0, 2);
[2010-08-17 18:22:33] david at grudl dot com
Description:
substr() should not return FALSE if is used with empty string. Yes, it
is documented behaviour (If $string is less than or equal to $start
characters long, FALSE will be returned), but it is not expected
behaviour. There is no way to use smaller $start.
Test script:
---
substr('x', 0, 2) // returns again 'x'
substr('', 0, 2) // returns FALSE but '' is expected
--
Edit this bug report at http://bugs.php.net/bug.php?id=52628edit=1
Bug #52596 [Com]: SOAP result empty NULL lastResponse filled
Edit report at http://bugs.php.net/bug.php?id=52596edit=1 ID: 52596 Comment by: christian dot gnoth at arcor dot de Reported by:christian dot gnoth at arcor dot de Summary:SOAP result empty NULL lastResponse filled Status: Open Type: Bug Package:SOAP related Operating System: Linux PHP Version:5.2.14 Block user comment: N New Comment: ?? Previous Comments: [2010-08-14 23:43:29] christian dot gnoth at arcor dot de has anyone an idea??? [2010-08-12 22:40:05] christian dot gnoth at arcor dot de Description: I have a script which makes a WSDL SOAP call and the result is empty. No error. The __getLastResponse() is filled. Test script: --- please take a look at: http://files.it-gnoth.de/software/source/php/soap_sample/wsdl-native.php this directory you can browse: http://files.it-gnoth.de/software/source/php/soap_sample with right mouse click it should be possible to download the file. auth token: 49fb1f08bfd34d2b92949af0f9b9bb61 client id: 225 method: get status: active -- Edit this bug report at http://bugs.php.net/bug.php?id=52596edit=1
Bug #52630 [Com]: additional syntax for closures
Edit report at http://bugs.php.net/bug.php?id=52630edit=1
ID: 52630
Comment by: giorgio dot liscio at email dot it
Reported by:giorgio dot liscio at email dot it
Summary:additional syntax for closures
Status: Assigned
Type: Bug
Package:Variables related
Operating System: all
PHP Version:5.3.3
Assigned To:stas
Block user comment: N
New Comment:
any alternative syntax can be good if the result is the same, defining
end invoking on the same instruction without using any var
now:
$f = function($x) use($y){return $x * $y;};
$f(22);
request:
(function($x) use($y) {return $x * $y;})(22);
or
function($x) use($y) {return $x * $y;}(22);
or
function($x) use($y) invoke(22) {return $x * $y;};
etc
Previous Comments:
[2010-08-17 22:21:17] ka...@php.net
I belive stas' had a patch for this? Or atleast function call chaining,
but I assume if implemented it would allow this syntax?
[2010-08-17 22:17:26] giorgio dot liscio at email dot it
Description:
hi, would be nice having this syntax for closures
$this-addResult
(
(
function ($param) use ($x) { return $x*$param; }
)($result)
);
a closure defined and executed in the same instruction, as JavaScript
allows
--
Edit this bug report at http://bugs.php.net/bug.php?id=52630edit=1
Bug #52630 [Asn]: additional syntax for closures
Edit report at http://bugs.php.net/bug.php?id=52630edit=1
ID: 52630
Updated by: ka...@php.net
Reported by:giorgio dot liscio at email dot it
Summary:additional syntax for closures
Status: Assigned
Type: Bug
Package:Variables related
Operating System: all
PHP Version:5.3.3
Assigned To:stas
Block user comment: N
New Comment:
I like the:
function($x) use($y) {return $x * $y;}(22);
approach, its consistent with that of other languages, like JavaScript
Previous Comments:
[2010-08-17 22:41:04] giorgio dot liscio at email dot it
any alternative syntax can be good if the result is the same, defining
end invoking on the same instruction without using any var
now:
$f = function($x) use($y){return $x * $y;};
$f(22);
request:
(function($x) use($y) {return $x * $y;})(22);
or
function($x) use($y) {return $x * $y;}(22);
or
function($x) use($y) invoke(22) {return $x * $y;};
etc
[2010-08-17 22:21:17] ka...@php.net
I belive stas' had a patch for this? Or atleast function call chaining,
but I assume if implemented it would allow this syntax?
[2010-08-17 22:17:26] giorgio dot liscio at email dot it
Description:
hi, would be nice having this syntax for closures
$this-addResult
(
(
function ($param) use ($x) { return $x*$param; }
)($result)
);
a closure defined and executed in the same instruction, as JavaScript
allows
--
Edit this bug report at http://bugs.php.net/bug.php?id=52630edit=1
Bug #52621 [Opn]: pdo-oci fails to locate 64-bit Oracle installations
Edit report at http://bugs.php.net/bug.php?id=52621edit=1 ID: 52621 Updated by: ka...@php.net Reported by:jbnance at tresgeek dot net Summary:pdo-oci fails to locate 64-bit Oracle installations Status: Open Type: Bug -Package:Compile Failure +Package:Oracle related Operating System: Linux PHP Version:5.3.3 -Assigned To: +Assigned To:sixd Block user comment: N New Comment: Chris, now there is a patch for it, might be worth reviewing from an Oracle standpoint :) Previous Comments: [2010-08-16 23:19:55] jbnance at tresgeek dot net Notes for end users, in order to use this you have to rebuild configure (buildconf --force after applying the patch). After applying and rebuilding, the following should work: ./configure --with-pdo-oci=instantclient,/usr,10.2.0.4 or ./configure --with-pdo-oci=shared,instantclient,/usr,10.2.0.4 Note that this is different from the non-PDO OCI configure option: --with-oci8=instantclient,/usr/lib/oracle/10.2.0.4/client64/lib or --with-oci8=shared,instantclient,/usr/lib/oracle/10.2.0.4/client64/lib (the version is a parameter in the PDO OCI option). [2010-08-16 23:18:54] jbnance at tresgeek dot net Added patches for 5.2 and 5.3 series. [2010-08-16 23:16:35] jbnance at tresgeek dot net Description: This is the same as bug 44989, but 44989 isn't getting any attention even though I have submitted a fix for the issue, and I'm not the original reporter so I can't update status. Test script: --- Using the Oracle provided 64bit InstantClient RPMs (currently using 11.1.0.1-1): ./configure --with-pdo-oci=instantclient,/usr/include,11.1.0 ... Produces: checking Oracle OCI support for PDO... yes checking Oracle Install-Dir... instantclient,/usr/include,11.1.0 checking if that is sane... yes checking for oci.h... configure: error: I'm too dumb to figure out where the include dir is in your Instant Client install Expected result: Libraries and headers located, compile succeeds. Actual result: -- Configure exits unable to locate libraries or headers. -- Edit this bug report at http://bugs.php.net/bug.php?id=52621edit=1
Bug #52573 [Csd]: SplFileObject::fscanf Segmentation fault
Edit report at http://bugs.php.net/bug.php?id=52573edit=1
ID: 52573
Updated by: fel...@php.net
Reported by:ti dot bugmenot at gmail dot com
Summary:SplFileObject::fscanf Segmentation fault
Status: Closed
Type: Bug
Package:SPL related
Operating System: FreeBSD
PHP Version:PHP 5.3.99-dev (snapshot 201008160630)
Assigned To:felipe
Block user comment: N
New Comment:
Thanks for the feedback, I've fixed this issue in SVN.
Thanks.
Previous Comments:
[2010-08-18 03:59:39] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=302420
Log: - Improved fix for bug #52573
[2010-08-16 09:04:46] ti dot bugmenot at gmail dot com
Fail.
CODE:
?php // test
error_reporting(E_ALL);
echo TEST 2:\n;
$result = null;
$f = new SplFileObject(__FILE__, 'r');
$f-fscanf('?php // %s', $result);
echo $result;
/opt/php-trunk/bin/php /tmp/test.php
RESULT:
Warning: Parameter 3 to fscanf() expected to be a reference, value given
in /tmp/test.php on line 8
CODE:
?php // test
error_reporting(E_ALL);
echo TEST 3:\n;
$result = null;
$f = new SplFileObject(__FILE__, 'r');
$f-fscanf('?php // %s', $result);
echo $result;
RESULT:
Fatal error: Call-time pass-by-reference has been removed in
/tmp/test.php on line 8
http://snaps.php.net/php-trunk-201008160630.tar.bz2
[2010-08-11 00:37:31] fel...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2010-08-11 00:37:26] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=302085
Log: - Fixed bug #52573 (SplFileObject::fscanf Segmentation fault)
[2010-08-10 10:15:00] ti dot bugmenot at gmail dot com
Description:
Segmentation fault when using additional parameters
SplFileObject::fscanf
Test script:
---
?php // test
error_reporting(E_ALL);
echo TEST 1:\n;
$f = new SplFileObject(__FILE__, 'r');
$f-fscanf('?php // %s', $result);
echo $result;
echo TEST 2:\n;
$result = null;
$f = new SplFileObject(__FILE__, 'r');
$f-fscanf('?php // %s', $result);
echo $result;
Expected result:
TEST 1:
test
TEST 2:
test
Actual result:
--
TEST 1:
br /
bNotice/b: Undefined variable: result in b/tmp/fail.php/b on
line b7/bbr /
br /
bNotice/b: Undefined variable: result in b/tmp/fail.php/b on
line b8/bbr /
TEST 2:
br /
bWarning/b: Parameter 3 to fscanf() expected to be a reference,
value given in b/tmp/fail.php/b on line b15/bbr /
Segmentation fault
--
Edit this bug report at http://bugs.php.net/bug.php?id=52573edit=1
