#43306 [Com]: File Download Problem.
ID: 43306
Comment by: marcell at equylybra dot com
Reported By: d dot tas40 at chello dot nl
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.2.5
New Comment:
Also having issues using the same script. I get no errors when
downloading files with sizes below 20Mb.
>From 20Mb files are perfectly downloaded via FTP but are saved with a
corrupted file size (0Kb) when downloaded via PHP. Tryed the solution
proposed by "webmaster at anpera dot net" too but I had no success.
Tryed without Content-Lenght header with no effect. Also tryed with
different Content-Types (e.g.
'application/octet-stream','application/force-download','application/zip').
I am on PHP 5.2.8 with Apache 2.2.11 under Linux
Previous Comments:
[2008-12-24 18:31:39] jon at jonraivala dot com
Using strlen of the blob instead of filesize in the header works for
me.
Example -
header("Content-Length: ".strlen($blob_data));
Hope this helps someone.
[2008-10-23 09:54:32] arasan at mahiti dot org
I've used this code but the download rate is very slow compared to
ordinary download. whether there is any way to overcome this?
[2008-09-25 04:51:26] lbarn...@php.net
Please try without any Content-Length header, your HTTP server is
probably using a chunked transfert encoding. Also try with a
Content-Type like 'application/octet-stream'.
Also check the character_set_* variables in your MySQL connection, the
server may try to convert the query or the results if some variables do
not match (blobs are binary but queries and results are not).
[2008-09-25 02:54:18] alphajet1024 at hotmail dot com
I have the very same problem, but my host server is PHP Version 4.3.11
with Linux OS, i use the following code snippest to recieve the file
from form and upload it to a BLOB field in SQL, the code works fine with
all file extensions, except rar and zip files, they mostly are
corrupted.
upload.php
0)
{
$fileName = $_FILES['userfile']['name'];
$tmpName = $_FILES['userfile']['tmp_name'];
$fileSize = $_FILES['userfile']['size'];
$fileType = $_FILES['userfile']['type'];
$fp = fopen($tmpName, 'r');
$content = fread($fp, filesize($tmpName));
$content = addslashes($content);
fclose($fp);
if(!get_magic_quotes_gpc())
{
$fileName = addslashes($fileName);
}
include('conf.php');
// open database connection
$connection = mysql_connect($host, $user, $pass)
or die ('Unable to connect!');
// select database
mysql_select_db($db)
or die ('Unable to select database!');
$query = "INSERT INTO upload (name, size, type, content ) ".
"VALUES ('$fileName', '$fileSize', '$fileType', '$content')";
mysql_query($query) or die('Error, query failed ' . mysql_error());
?>
download.php
[2008-01-12 17:08:06] webmaster at anpera dot net
I have a similar problem with PHP 5.2.4 / 5.2.5 with Apache2.2 under
Windows 2003.
Downloaded files are missing exactly 15 bytes at the end. ZIP and RAR
files can't be opened correctly after download but definitely are okay
on the server's hard drive.
With
$filesize=filesize($filename)+15;
the downloads are working.
$size = @filesize($filename)+15;
header('Pragma: public');
[...]
header("Content-Length: $size");
$fp = @fopen($filename, 'rb');
[...]
while (!feof($fp)){
echo fread($fp, 8192);
}
fclose($fp);
[...]
flush();
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/43306
--
Edit this bug report at http://bugs.php.net/?id=43306&edit=1
#47877 [Opn->Fbk]: ALERT - canary mismatch on efree() - heap overflow detected
ID: 47877 Updated by: ka...@php.net Reported By: leif at neland dot dk -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: Debian 5 PHP Version: 5.2.9 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Aswell as a backtrace would help give some insight on the matter for the maintainer Previous Comments: [2009-04-02 12:22:02] leif at neland dot dk Description: Basically the same bug as 43861, it seems. Some mssql-queries triggers ALERT - canary mismatch on efree() - heap overflow detected I'm willing to patch, submit traces etc :-) Reproduce code: --- Code probably irrellevant. Expected result: No errors in the log -- Edit this bug report at http://bugs.php.net/?id=47877&edit=1
#22055 [Com]: Memory leak with references in objects
ID: 22055
Comment by: medge at neverathome dot net
Reported By: jparneodo at yahoo dot fr
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: RedHat 7.2
PHP Version: 4.3.1-dev
New Comment:
This problem still exists - this is causing us extreme headaches as we
will need to have two object models in our system.
One which is useful, and one which is "in case we have to do anything
with high load in PHP" and isn't an object model at all.
This seems like a pretty critical bug.
Previous Comments:
[2009-04-01 13:45:54] phpuser at gmail dot com
Having the same issue with php 5.2.9.
As stated above, this is a major problem, as I'm using php to
import/export data between databases, and I'm talking about millions
rows.
I have to split the data to import, because even after using unset()
the memory used by objects isn't released.
Please do something about this bug. It has been reported 6 years ago
and is still here !!
Tested with php 5.2.6 and 5.2.9, both with linux and windows xp.
[2007-03-01 03:51:12] matthieu dot aubry at gmail dot com
I also have the same problem using
PHP Version => 5.1.2
Build Date => Nov 2 2006 12:28:13
Server API => Command Line Interface
This bug is really annoying.
I'm working on a project which loads thousands of files parsed into
objects.
I use the technic
$this->myObjectMember->register($this);
which creates cross references.
Calling unset() doesn't change anything, as seen in the examples
provided above.
I would love to see this bug fixed! Thank you.
[2005-06-17 16:25:54] apinstein at mac dot com
I have experienced this problem on PHP5 as well... here's a
test script:
echo memory_get_usage() . " (initial)\n";
$t = new test;
echo memory_get_usage() . " (after: \$t = new test();)\n";
unset($t);
echo memory_get_usage() . " (after: unset(\$t);)\n";
echo "done\n";
class test
{
protected $str;
protected $t2;
function __construct()
{
print "construct test\n";
$this->str = str_repeat('1234567890', 1000);
$this->t2 = new test2($this);
}
function __destruct()
{
print "destruct test\n";
}
}
class test2
{
protected $str;
protected $t1;
function __construct($t1)
{
print "construct test2\n";
$this->str = str_repeat('1234567890', 1000);
$this->t1 = $t1;
}
function __destruct()
{
print "destruct test2\n";
unset($this->str);
}
}
And the output of this script:
51416 (initial)
construct test
construct test2
72000 (after: $t = new test();)
72000 (after: unset($t);)
done
destruct test
destruct test2
It's definitely a real problem. Simply removing the cross-
referenced instance vars will remove the problem. However,
as you can see, even explicitly calling unset() still
doesn't release the objects or call destructors until the
script EXITS.
This is a *MAJOR* problem for anyone using OO to process
large amounts of information.
[2004-03-01 05:07:55] tom at scl dot co dot uk
Is anyone looking into this?
I've found any method of releasing the objects fails, no just using the
unset() function, if the object just go out of scope they aren't
released, for ezample, if you do something like
function MyFunc() {
$x = new C;
$y = new C;
$x->ref =& $y;
$y->ref =& $x;
}
Then after the function has finished then the memory allocated for the
local variables $x and $y is not freed up.
[2004-02-23 11:21:41] tom at scl dot co dot uk
I had this problem with PHP4.3.3. I then found this bug report and
upgraded to PHP5.0.0b4 to try and fix this problem and I still get the
memory leak problem, there is some demo code below, you need to change
/path/to/large/file. I've been using a file which is about 1.5mb and
when PHP is set to stop when it reaches 8mb then it only makes it
through the loop twice.
I'm 1.5 years into a project and I could really do with knowing if this
is going to be fixed anytime soon so I can either wait for the fix or
try and find a work around. Thanks for your time,
Tom
---
val = file('/path/to/large/file');
}
}
while (1) {
$x = new C;
$y = new C;
$x->ref =& $y;
$y->ref =& $x;
unset($y);
unset($x);
echo ".";
}
?>
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/22055
--
Edit this bug report at http://bugs.php.net/?id=22055&edit=1
#47824 [Com]: 64-bit build make check segmentation fault
ID: 47824 Comment by: Michael dot Zehmeister at dier dot tas dot gov dot au Reported By: jr at e-integration dot net Status: Feedback Bug Type: Reproducible crash Operating System: Solaris 10 SPARC u6 PHP Version: 5.2.9 New Comment: I no longer think this is a PHP bug. I believe the problem is actually with the build of gcc. Configuring php without --enable-debug but setting CFLAGS to -g doesn't segfault (indicating the problem is with gcc). So I tried again after setting CFLAGS to -O1 and make test runs fine. As such I think the bug is probably in the gcc optimisation process. I'll investigate this further, but if this is the case then it's not relevant to PHP. If the original poster wants to try 'export CFLAGS=-O1' to see if he encounters the same behaviour then this bug can probably be closed. Cheers. Previous Comments: [2009-04-02 03:50:50] Michael dot Zehmeister at dier dot tas dot gov dot au I am experiencing the exact same issue as the original submitter on a Sparc 64-bit sun4u system. I recompiled with --enable-debug to obtain a backtrace to submit but having done so make test no longer seg faults. This is reproducible: without debug it seg faults at the start of make test, with debug enabled and all other options identical it doesn't. Given that I can't get a backtrace what alternative information can I provide? --- Build details: GNU gcc version 4.3.3 (GCC) GNU Make 3.81 ./configure \ --enable-debug \ --prefix=/opt/php \ --with-config-file-path=/opt/php/etc \ --enable-inline-optimization \ --with-gd \ --with-jpeg-dir=/opt/libjpeg \ --with-png-dir=/opt/libpng \ --enable-bcmath \ --with-openssl=/opt/openssl \ --with-zlib=/opt/zlib \ --enable-wddx \ --enable-ftp \ --disable-cgi \ --with-curl=/opt/curl \ --with-gettext \ --enable-sockets \ --enable-pcntl \ --with-pspell=shared,/opt/aspell \ --enable-mbstring=all \ --enable-shmop \ --with-pear \ --with-ldap=/opt/openldap \ --enable-exif \ --with-freetype-dir=/opt/freetype \ --with-pdo-oci \ --with-oci8=/opt/oracle/product/10.2.0/client \ --with-apxs2=/opt/httpd/bin/apxs \ --enable-gd-native-ttf \ > ../doc/config.out 2>&1 [2009-03-31 07:09:47] j...@php.net Can you provide the backtrace of the crash..? [2009-03-29 03:34:58] jr at e-integration dot net Used the following build tools: gcc 4.2.4 gmake 3.81 re2c 0.13.5 bison 2.4.1 [2009-03-29 03:31:52] jr at e-integration dot net Description: # make The make completes without error. # ./sapi/cli/php --version PHP 5.2.9 (cli) (built: Mar 26 2009 23:43:41) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies # make test Build complete. Don't forget to run 'make test'. Segmentation Fault - core dumped make: [test] Error 139 (ignored) Build environment: Solaris 10 SPARC u6; 64-bit used gcc 4.2.4 and GNU make 3.81 Expected result: make test creates two core files if you have coreadm set like so: # coreadm global core file pattern: global core file content: default init core file pattern: /var/core/init_core.%n.%z.%u.%f.%p init core file content: default global core dumps: disabled per-process core dumps: enabled global setid core dumps: disabled per-process setid core dumps: enabled global core dump logging: enabled # ls -lt /var/core/ total 106272 -rw--- 1 root root 27865628 Mar 27 10:38 init_core.halo.global.0.php.7926 -rw--- 1 root root 26489372 Mar 27 10:38 init_core.halo.global.0.php.7924 -rw--- 1 root root 27865628 Mar 27 10:30 init_core.halo.global.0.php.7757 -rw--- 1 root root 26489372 Mar 27 10:30 init_core.halo.global.0.php.7751 -- Edit this bug report at http://bugs.php.net/?id=47824&edit=1
#47882 [Opn->Bgs]: calls to mysql_connect crash
ID: 47882 Updated by: johan...@php.net Reported By: ldjones at us dot ibm dot com -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: Windows XP SP3 PHP Version: 5.2.9 New Comment: Your system loads libmysql.dll from 5.1 instead f the 5.0 version which was used when linking PHP but these libraries are incompatible. You can safely use the 5.0 dll to connect to a 5.1 serer though. Previous Comments: [2009-04-02 21:45:31] ldjones at us dot ibm dot com Description: I am wondering why Bug 46842 was closed with no resolution? The status shows as "Bogus". However, I just bought a new laptop and installed MySQL 5.1.33, Apache 2.2.11, and PHP 5.2.9-1. Then I couldn't run anymore because Apache dies with the exact same problem reported with Bug 46842. In other words, it's not bogus at all. I configured php.ini the same as I did on my old laptop (Apache 2.2.8, MySQL 5.0.22, PHP 5.2.5) by turning on CURL, MySQL, MySQLi, and OpenSSL. By the way, I got by the problem by following the advice of one of the people who posted on Bug 46842 - I copied the libmysql.dll from PHP 5.2.5 and overwrote the one supplied by PHP 5.2.9, but I only did that because I can't afford down time. I would gladly undo that change if someone would fix the problem. Thanks, Lonnie Jones Reproduce code: --- Expected result: Connected successfully. Actual result: -- The browser says Apache can no longer function and will close. Apache doesn't close, but I don't get a connection either. -- Edit this bug report at http://bugs.php.net/?id=47882&edit=1
#47883 [NEW]: wish: syntax error, unexpected $end should show start point
From: php at richardneill dot org
Operating system: Linux
PHP version: 5.2.9
PHP Bug Type: Feature/Change Request
Bug description: wish: syntax error, unexpected $end should show start point
Description:
If I have a script with a syntax error, such as a missing '}' somewhere,
PHP will helpfully tell me that there's a problem, but direct me to look in
the wrong place.
The error message is as follows:
Parse error: syntax error, unexpected $end in [FILENAME] at
[NUMBER_OF_LAST_LINE]
This is unhelpful for 2 reasons.
* It isn't clear what type of syntax error would cause this - there's no
way to know what character PHP was expecting to see.
* I have no easy way of finding the offending line where the bug really
lies, apart from commenting out parts of the source and doing a
binary-search within it. Essentially, PHP is saying "You have an error, but
I won't tell you where".
Expected result:
The following would be clearer and *far* more helpful.
Syntax error: unexpected $end in [FILENAME] at LINENUM: missing
an expected '}' character. (The corresponding, unmatched '{' is
probably at line xxx.)
Of course, it's not always possible for PHP to know which open-brace is
the unmatched one - however, it could usually take a reasonable best guess
by iterating *backwards* through the source, and doing:
1 $nest_depth=0
2 If a '}' is encountered, $nest_depth++
3 If a '{' is encountered, $nest_depth--
4 If $nest_depth == -1, we have located the open-brace that isn't
closed. Print LINENUM.
--
Edit bug report at http://bugs.php.net/?id=47883&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47883&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47883&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47883&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47883&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47883&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47883&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47883&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47883&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47883&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47883&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47883&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47883&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47883&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47883&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47883&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47883&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47883&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47883&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47883&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47883&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47883&r=mysqlcfg
#47882 [NEW]: calls to mysql_connect crash
From: ldjones at us dot ibm dot com Operating system: Windows XP SP3 PHP version: 5.2.9 PHP Bug Type: MySQL related Bug description: calls to mysql_connect crash Description: I am wondering why Bug 46842 was closed with no resolution? The status shows as "Bogus". However, I just bought a new laptop and installed MySQL 5.1.33, Apache 2.2.11, and PHP 5.2.9-1. Then I couldn't run anymore because Apache dies with the exact same problem reported with Bug 46842. In other words, it's not bogus at all. I configured php.ini the same as I did on my old laptop (Apache 2.2.8, MySQL 5.0.22, PHP 5.2.5) by turning on CURL, MySQL, MySQLi, and OpenSSL. By the way, I got by the problem by following the advice of one of the people who posted on Bug 46842 - I copied the libmysql.dll from PHP 5.2.5 and overwrote the one supplied by PHP 5.2.9, but I only did that because I can't afford down time. I would gladly undo that change if someone would fix the problem. Thanks, Lonnie Jones Reproduce code: --- Expected result: Connected successfully. Actual result: -- The browser says Apache can no longer function and will close. Apache doesn't close, but I don't get a connection either. -- Edit bug report at http://bugs.php.net/?id=47882&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47882&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47882&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47882&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47882&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47882&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47882&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47882&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47882&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47882&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47882&r=support Expected behavior: http://bugs.php.net/fix.php?id=47882&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47882&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47882&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47882&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47882&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47882&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47882&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47882&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47882&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47882&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47882&r=mysqlcfg
#47879 [Opn->Bgs]: FILTER_VALIDATE_EMAIL Error
ID: 47879
Updated by: il...@php.net
Reported By: cory dot jacobsen at zu dot com
-Status: Open
+Status: Bogus
Bug Type: Filter related
Operating System: *
PHP Version: 5.2.9
New Comment:
Actually you can if its an internal domain name.
Previous Comments:
[2009-04-02 15:51:54] cory dot jacobsen at zu dot com
Description:
Some email addresses that are obviously wrong, pass the validation
with
FILTER_VALIDATE_EMAIL. You can not have a top level domain with one
character only.
Reproduce code:
---
var_dump(filter_var("x...@y.z", FILTER_VALIDATE_EMAIL));
Expected result:
bool(false)
Actual result:
--
string(5) "x...@y.z"
--
Edit this bug report at http://bugs.php.net/?id=47879&edit=1
#47776 [Bgs]: -without-ldap-sasl option is ignored
ID: 47776 User updated by: tprohaska2 at honeywell dot com Reported By: tprohaska2 at honeywell dot com Status: Bogus Bug Type: Compile Failure Operating System: AIX 5.3 PHP Version: 5.2.9 New Comment: Then the option --without-ldap-sasl is bogus. Previous Comments: [2009-03-31 07:40:32] j...@php.net Your ldap lib is compiled with sasl, hence you're REQUIRED to use this. (no, this is not a bug) [2009-03-25 16:05:37] tprohaska2 at honeywell dot com Description: configure fails while looking for sasl symbols --without-ldap-sasl as chosen Reproduce code: --- ./configure \ --with-ldap=/webapp/DSRSK/lib/ldapcsdk \ --with-oci8=instantclient,/webapp/instantclient10_1 \ --with-apxs2=/webapp/apache/2.2.11/bin/apxs \ --with-config-file-path=/webapp/apache/2.2.11/conf/httpd.conf \ --with-zlib-dir=/webapp/local/lib \ --without-ldap-sasl \ --enable-shared \ --disable-static \ --without-zlib-dir \ --without-bz2 \ --without-sqlite \ Expected result: expect it not to fail - expect it to not look for sasl related symbols Actual result: -- configure:53481: checking for ldap_parse_result configure:53509: gcc -o conftest -I/usr/include -DHAVE_LONG_LONG -I/webapp/DSRS K/lib/ldapcsdk/include -L/usr/lib -L/opt/freeware/lib -L/opt/freeware/lib -L/we bapp/DSRSK/lib/ldapcsdk/lib -L/webapp/DSRSK/lib/ldapcsdk/lib conftest.c -lssl3 - lprldap50 -lldap50 -lssldap50 -llber50 -lplds4 -lplc4 -lnspr4 -lm -lxml2 -licon v -lm -lxml2 -liconv -lm 1>&5 ld: 0711-317 ERROR: Undefined symbol: .pthread_getspecific ld: 0711-317 ERROR: Undefined symbol: .pthread_setspecific ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_destroy ld: 0711-317 ERROR: Undefined symbol: .pthread_mutex_init ld: 0711-317 ERROR: Undefined symbol: .sasl_setprop ld: 0711-317 ERROR: Undefined symbol: .sasl_client_start ld: 0711-317 ERROR: Undefined symbol: .sasl_client_step ld: 0711-317 ERROR: Undefined symbol: .sasl_getprop ld: 0711-317 ERROR: Undefined symbol: .sasl_client_new ld: 0711-317 ERROR: Undefined symbol: .sasl_dispose ld: 0711-317 ERROR: Undefined symbol: .sasl_encode ld: 0711-317 ERROR: Undefined symbol: .sasl_decode ld: 0711-317 ERROR: Undefined symbol: .sasl_set_alloc ld: 0711-317 ERROR: Undefined symbol: .sasl_client_init ld: 0711-317 ERROR: Undefined symbol: .pthread_key_create ld: 0711-317 ERROR: Undefined symbol: pthread_mutex_lock ... ... ... -- Edit this bug report at http://bugs.php.net/?id=47776&edit=1
#47881 [NEW]: Allow read/write setting for class members
From: e dot sand at elisand dot com Operating system: Irrelevant PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: Allow read/write setting for class members Description: I believe having the ability to define read & write permissions on class members would help with certain problems encountered when currently trying to implement similar features using __get() and __set(). I would like to propose that three "flags" be defined and would be used with the public, protected and private declarations. The flags would be ro (read-only), wo (write-only) and rw (read-write; for completeness). They would be prepended (or appended) to a visibility declarations, for example: ro_public, rw_protected or wo_private. These three flags would allow more control over member access than attempting to use __get() and/or __set() which, to achieve similar results, could require many lines of additional logic and code. As it is currently in PHP 5.2.x, due to the implementation of trigger_error() (in that you cannot perfectly mimic an internal E_ERROR), it is not possible to transparently implement features such as what I am proposing here. Setting the various flags on the different visibility declarations would have differing results. I will (attempt) to explain how these flags would function depending on visibility. * Setting ro/wo on a public declaration would mean that public access can only read/write to that member; access by direct and extended classes of that member would be unrestricted. * Setting ro/wo on a protected declaration would mean that extended classes can only read/write to that member; public access is still prohibited and direct class access is still unrestricted. * Setting ro/wo on a private declaration would mean that direct class access is read/write only; public and extended class access is still prohibited. Note: from the examples, you can see why the "rw" flag isn't required - I mentioned it simply for completeness if it would make sense to allow people to define it, otherwise it can be omitted since it is simply the "default" access permission. -- Edit bug report at http://bugs.php.net/?id=47881&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47881&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47881&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47881&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47881&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47881&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47881&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47881&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47881&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47881&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47881&r=support Expected behavior: http://bugs.php.net/fix.php?id=47881&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47881&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47881&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47881&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47881&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47881&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47881&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47881&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47881&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47881&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47881&r=mysqlcfg
#47880 [NEW]: Garbage Collector crashes
From: patric at zap dot lu Operating system: Debian Lenny PHP version: 5.3.0RC1 PHP Bug Type: Scripting Engine problem Bug description: Garbage Collector crashes Description: We got a huge framework which runs as CLI. With lots of circular references, we use 5.3 as it solves the out of memory problem. Unfortunately it crashes randomly after a while. We can't reproduce it as it crashes, as it likes. Reproduce code: --- Not possible, as we can't locate a specific line of code. Happens randomly Actual result: -- The GDP output for this problem: Core was generated by `/blade/exec/10.1.0.10/php/bin/php -c/blade/run/configs/10.1.0.10-php-daemon.ini'. Program terminated with signal 11, Segmentation fault. [New process 25897] #0 0x08347bc9 in children_scan (pz=0xba2c09f5) at /blade/install/daemon/php/Zend/zend_gc.c:431 431 zval_scan(*pz TSRMLS_CC); (gdb) bz Undefined command: "bz". Try "help". (gdb) bt #0 0x08347bc9 in children_scan (pz=0xba2c09f5) at /blade/install/daemon/php/Zend/zend_gc.c:431 #1 0x08337af3 in zend_hash_apply (ht=0xa1d442c, apply_func=0x8347bc0 ) at /blade/install/daemon/php/Zend/zend_hash.c:673 #2 0x08347b8a in zval_scan (pz=0x8f3f409) at /blade/install/daemon/php/Zend/zend_gc.c:421 #3 0x08347bd0 in children_scan (pz=0x9c7f47c) at /blade/install/daemon/php/Zend/zend_gc.c:431 #4 0x08337af3 in zend_hash_apply (ht=0xa4b3758, apply_func=0x8347bc0 ) at /blade/install/daemon/php/Zend/zend_hash.c:673 #5 0x08347b8a in zval_scan (pz=0x8f3f409) at /blade/install/daemon/php/Zend/zend_gc.c:421 #6 0x08347bd0 in children_scan (pz=0x9fa05b8) at /blade/install/daemon/php/Zend/zend_gc.c:431 #7 0x08337af3 in zend_hash_apply (ht=0x9fb2308, apply_func=0x8347bc0 ) at /blade/install/daemon/php/Zend/zend_hash.c:673 #8 0x08347a61 in zobj_scan (pz=0x9fb2338) at /blade/install/daemon/php/Zend/zend_gc.c:401 #9 0x08347ba7 in zval_scan (pz=0x8f3f409) at /blade/install/daemon/php/Zend/zend_gc.c:416 #10 0x08347bd0 in children_scan (pz=0xa08cbf0) at /blade/install/daemon/php/Zend/zend_gc.c:431 #11 0x08337af3 in zend_hash_apply (ht=0xa166234, apply_func=0x8347bc0 ) at /blade/install/daemon/php/Zend/zend_hash.c:673 #12 0x08347a61 in zobj_scan (pz=0x9dc7b48) at /blade/install/daemon/php/Zend/zend_gc.c:401 #13 0x08347ba7 in zval_scan (pz=0x8f3f409) at /blade/install/daemon/php/Zend/zend_gc.c:416 #14 0x08347bd0 in children_scan (pz=0xa48d5d4) at /blade/install/daemon/php/Zend/zend_gc.c:431 #15 0x08337af3 in zend_hash_apply (ht=0xa34b5a8, apply_func=0x8347bc0 ) at /blade/install/daemon/php/Zend/zend_hash.c:673 #16 0x08347b8a in zval_scan (pz=0x8f3f409) at /blade/install/daemon/php/Zend/zend_gc.c:421 #17 0x08347bd0 in children_scan (pz=0xa0b1140) at /blade/install/daemon/php/Zend/zend_gc.c:431 #18 0x08337af3 in zend_hash_apply (ht=0xa0b1104, apply_func=0x8347bc0 ) at /blade/install/daemon/php/Zend/zend_hash.c:673 #19 0x08347a61 in zobj_scan (pz=0xa0b10e8) at /blade/install/daemon/php/Zend/zend_gc.c:401 #20 0x08347ba7 in zval_scan (pz=0x8f3f409) at /blade/install/daemon/php/Zend/zend_gc.c:416 #21 0x08347bd0 in children_scan (pz=0xa1316a8) at /blade/install/daemon/php/Zend/zend_gc.c:431 #22 0x08337af3 in zend_hash_apply (ht=0x9ecb34c, apply_func=0x8347bc0 ) at /blade/install/daemon/php/Zend/zend_hash.c:673 #23 0x08347b8a in zval_scan (pz=0x8f3f409) at /blade/install/daemon/php/Zend/zend_gc.c:421 #24 0x08347bd0 in children_scan (pz=0xa131700) at /blade/install/daemon/php/Zend/zend_gc.c:431 #25 0x08337af3 in zend_hash_apply (ht=0xa230760, apply_func=0x8347bc0 ) at /blade/install/daemon/php/Zend/zend_hash.c:673 #26 0x08347b8a in zval_scan (pz=0x8f3f409) at /blade/install/daemon/php/Zend/zend_gc.c:421 #27 0x08347bd0 in children_scan (pz=0x9ecb31c) at /blade/install/daemon/php/Zend/zend_gc.c:431 #28 0x08337af3 in zend_hash_apply (ht=0xa20d110, apply_func=0x8347bc0 ) at /blade/install/daemon/php/Zend/zend_hash.c:673 #29 0x08347b8a in zval_scan (pz=0x8f3f409) at /blade/install/daemon/php/Zend/zend_gc.c:421 #30 0x08347bd0 in children_scan (pz=0xa15a368) at /blade/install/daemon/php/Zend/zend_gc.c:431 #31 0x08337af3 in zend_hash_apply (ht=0xa06989c, apply_func=0x8347bc0 ) at /blade/install/daemon/php/Zend/zend_hash.c:673 #32 0x08347a61 in zobj_scan (pz=0xa04dc24) at /blade/install/daemon/php/Zend/zend_gc.c:401 #33 0x08347ba7 in zval_scan (pz=0x8f3f409) at /blade/install/daemon/php/Zend/zend_gc.c:416 #34 0x08347bd0 in children_scan (pz=0xa079624) at /blade/install/daemon/php/Zend/zend_gc.c:431 #35 0x08337af3 in zend_hash_apply (ht=0xa29e8d0, apply_func=0x8347bc0 ) at /blade/install/daemon/php/Zend/zend_hash.c:673 #36 0x08347b8a in zval_scan (pz=0x8f3f409) at /blade/install/daemon/php/Zend/zend_gc.c:421 #37 0x08347bd0 in children_scan (pz=0xa0ba6c0) at /blade/install/daemon/php/Zend/zend_gc.c:431 #38 0x08337af3 in zend_hash_apply (ht=0x9f32824, apply_func=0x8347bc0 ) at /blade/install/daemon/php/Zend/zend_has
#44173 [Asn->Csd]: PDO->query() parameter parsing/checking needs an update
ID: 44173
Updated by: mbecc...@php.net
Reported By: uwendel at mysql dot com
-Status: Assigned
+Status: Closed
Bug Type: PDO related
Operating System: Irrelevant
PHP Version: 5.3CVS-2008-02-19 (CVS)
Assigned To: mbeccati
New Comment:
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.
Previous Comments:
[2009-03-22 19:36:38] matteo at beccati dot com
The following patch also removes the goto from the function, as
suggested by Johannes:
http://www.beccati.com/misc/php/pdo_pgsql_bug44173_php_5.3_v2.patch
[2009-03-22 17:59:16] matteo at beccati dot com
Fix is available here:
http://www.beccati.com/misc/php/pdo_pgsql_bug44173_php_5.3.patch
[2008-02-19 16:25:01] uwendel at mysql dot com
And a last one...
[7] PDO->query('SELECT', PDO::FETCH_CLASS) -> proper error message
nixn...@ulflinux:~/php53> sapi/cli/php -r 'error_reporting(E_ALL);
$pdo=new PDO("sqlite:/tmp/foo.db");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
@$pdo->exec("DROP TABLE test"); $pdo->exec("CREATE TABLE test(id INT)");
$pdo->exec("INSERT INTO test(id) VALUES (1)");
var_dump($pdo->query("SELECT id FROM test", PDO::FETCH_CLASS,
"unknown"));'
Warning: PDO::query(): SQLSTATE[]: <> in Command line
code on line 1
bool(false)
I have not checked other error modes of PDO. I do not know if PDO shall
raise an exception for every warning it prints, if that's intended at
all.
[2008-02-19 16:21:04] uwendel at mysql dot com
[6] PDO->query("SELECT", PDO::FETCH_COLUMN) -> error message could be
better
nixn...@ulflinux:~/php53> sapi/cli/php -r 'error_reporting(E_ALL);
$pdo=new PDO("sqlite:/tmp/foo.db");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
@$pdo->exec("DROP TABLE test"); $pdo->exec("CREATE TABLE test(id INT)");
$pdo->exec("INSERT INTO test(id) VALUES (1)");
var_dump($pdo->query("SELECT id FROM test", PDO::FETCH_COLUMN));'
Warning: PDO::query(): SQLSTATE[]: <> in Command line
code on line 1
bool(false)
[2008-02-19 16:18:07] uwendel at mysql dot com
[5] PDO->query('SELECT ...', PDO::FETCH_INTO) -> no proper error
message
nixn...@ulflinux:~/php53> sapi/cli/php -r 'error_reporting(E_ALL);
$pdo=new PDO("sqlite:/tmp/foo.db");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
@$pdo->exec("DROP TABLE test"); $pdo->exec("CREATE TABLE test(id INT)");
$pdo->exec("INSERT INTO test(id) VALUES (1)");
var_dump($pdo->query("SELECT id FROM test", PDO::FETCH_INTO));'
Warning: PDO::query(): SQLSTATE[]: <> in Command line
code on line 1
bool(false)
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/44173
--
Edit this bug report at http://bugs.php.net/?id=44173&edit=1
#47724 [Com]: Reproducable segmenation fault using symfony and doctrine
ID: 47724 Comment by: scott at danielfamily dot com Reported By: scott at danielfamily dot com Status: No Feedback Bug Type: Reproducible crash Operating System: Centos 5.2 PHP Version: 5.2.9 New Comment: We have since found another consistent failure case in a thread of code that is unrelated to the one reported here. It is another case where adding a single instruction makes the fault disappear. Previous Comments: [2009-03-31 12:10:48] peter at f-is dot eu Scott, thanks for your work at the VMWARE image, and Scott MacVicar for looking into it. I really hope this annoying bug finally get's fixed. I've been playing with Duma, Valgrind and GDB for a few days, but my knowledge about these tools, c programming, or the internals of PHP seem insufficient. >From what i can tell, this is a reference counting problem. Some object has 3 references, and than some time later the some memory location contains a String, with 1 reference, which gets dereferenced and de-allocated. During php shutdown, the original object is being read, and because the memory is 'gone' it segfaults. The String that seems to overwrite the object is being provided by the __toString function of the original object. So i guess something goes wrong there. I can't stress enough that my experience with C is extremely limited, so the above may be completely wrong :P. There is also no way for me to be sure that this is the same bug that Scott has, but the symptoms are the same. This is the information valgrind spits out about the crash is the following. Note that this only happens in crashing pages, or pages that sometimes crash, depending on input: ==29860== Invalid read of size 4 ==29860==at 0x63EBB7: _zval_ptr_dtor (zend_execute_API.c:410) ==29860==by 0x64F079: _zval_ptr_dtor_wrapper (zend_variables.c:177) ==29860==by 0x65F9C8: zend_hash_destroy (zend_hash.c:526) ==29860==by 0x64EC8A: _zval_dtor_func (zend_variables.c:45) ==29860==by 0x63E978: _zval_dtor (zend_variables.h:35) ==29860==by 0x63EC31: _zval_ptr_dtor (zend_execute_API.c:414) ==29860==by 0x64F079: _zval_ptr_dtor_wrapper (zend_variables.c:177) ==29860==by 0x65F9C8: zend_hash_destroy (zend_hash.c:526) ==29860==by 0x675161: zend_object_std_dtor (zend_objects.c:45) ==29860==by 0x675600: zend_objects_free_object_storage (zend_objects.c:122) ==29860==by 0x679E67: zend_objects_store_del_ref_by_handle (zend_objects_API.c:211) ==29860==by 0x679C45: zend_objects_store_del_ref (zend_objects_API.c:169) ==29860== Address 0xBF348B8 is 16 bytes inside a block of size 24 free'd ==29860==at 0x4A0541E: free (vg_replace_malloc.c:233) ==29860==by 0x62E4EB: _efree (zend_alloc.c:2303) ==29860==by 0x63ECD9: safe_free_zval_ptr_rel (zend_execute.h:70) ==29860==by 0x63EC51: _zval_ptr_dtor (zend_execute_API.c:415) ==29860==by 0x67D57C: zend_ptr_stack_clear_multiple (zend_execute.h:155) ==29860==by 0x67CE1E: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:307) ==29860==by 0x683160: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1729) ==29860==by 0x67C11B: execute (zend_vm_execute.h:92) ==29860==by 0x6951FA: ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER (zend_vm_execute.h:7811) ==29860==by 0x67C11B: execute (zend_vm_execute.h:92) ==29860==by 0x6517CC: zend_execute_scripts (zend.c:1134) ==29860==by 0x5F108F: php_execute_script (main.c:2023) This is the output of php that I got by enabling debugging options. They concern the same memory region as the above: Reducing refcount for bf348a8 (feff5738) type 5: 16->15 Reducing refcount for bf348a8 (feff5ba8) type 5: 15->14 Reducing refcount for bf348a8 (feff5cf0) type 5: 14->13 Reducing refcount for bf348a8 (bf45c08) type 5: 13->12 Reducing refcount for bf348a8 (bf45cc0) type 5: 12->11 Reducing refcount for bf348a8 (bf351a8) type 5: 11->10 Reducing refcount for bf348a8 (a0a518) type 5: 10->9 Reducing refcount for bf348a8 (feff84a8) type 5: 10->9 Reducing refcount for bf348a8 (bf350a8) type 5: 9->8 Reducing refcount for bf348a8 (a0a518) type 5: 8->7 Reducing refcount for bf348a8 (feff8d28) type 5: 7->6 Reducing refcount for bf348a8 (bf34b70) type 5: 6->5 Reducing refcount for bf348a8 (a0a518) type 5: 5->4 Reducing refcount for bf348a8 (a0a518) type 5: 4->3 Reducing refcount for bf348a8 (feffa048) type 6: 1->0 Destroying bf348a8 of type 6 Reducing refcount for bf348a8 (bf44e38) type 6: 0->-1 Reducing refcount for bf348a8 (bf35f70) type 6: -1->-2 [2009-03-31 03:21:39] scott at danielfamily dot com Scott MacVicar from the PHP team send me a note saying he would look at the bug. I uploaded the VMWARE appliance and send him the information, but have not heard back after some days. Still hoping for some love. -
#47818 [Asn->Csd]: Segfault due to bound callback param
ID: 47818 Updated by: fel...@php.net Reported By: galaxy dot mipt at gmail dot com -Status: Assigned +Status: Closed Bug Type: XMLRPC-EPI related Operating System: Linux 2.6.18 x86 PHP Version: 5.2.9 Assigned To: felipe New Comment: 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. Fixed in 5.2, 5.3 and HEAD. Thanks. Previous Comments: [2009-04-01 02:44:19] galaxy dot mipt at gmail dot com xmlrpc-epi-php.c, line 1115 (xmlrpc_server_call_method): /* cleanup after ourselves. what a sty! */ zval_dtor(data.xmlrpc_method); FREE_ZVAL(data.xmlrpc_method); zval_dtor(data.return_data); FREE_ZVAL(data.return_data); If I get it right data.xmlrpc_method is completely destructed after method call. What if it has more than 1 reference like in reproduce code? [2009-04-01 02:04:44] galaxy dot mipt at gmail dot com Okay, here's the backtrace from my app (not sure if this is helpful as it does not contain references to XML-RPC extension): #0 0x0078c0ec in memcpy () from /lib/tls/libc.so.6 #1 0x012a4fc2 in php_var_serialize_intern (buf=0xbfa05560, struc=Variable "struc" is not available. ) at /home/local/php-5.2.9/ext/standard/var.c:536 #2 0x012a4b12 in php_var_serialize_intern (buf=0xbfa05560, struc=0x914d4f8, var_hash=0xbfa05570) at /home/local/php-5.2.9/ext/standard/var.c:824 #3 0x012a4b12 in php_var_serialize_intern (buf=0xbfa05560, struc=0xb7f3b114, var_hash=0xbfa05570) at /home/local/php-5.2.9/ext/standard/var.c:824 #4 0x012a4b12 in php_var_serialize_intern (buf=0xbfa05560, struc=0xb7f3b2ec, var_hash=0xbfa05570) at /home/local/php-5.2.9/ext/standard/var.c:824 #5 0x012a7ae5 in php_var_serialize (buf=0xbfa05560, struc=0x9216500, var_hash=0xbfa05570) at /home/local/php-5.2.9/ext/standard/var.c:842 #6 0x012a7b71 in zif_serialize (ht=1, return_value=0xb7f3e694, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /home/local/php-5.2.9/ext/standard/var.c:865 #7 0x0132c009 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa05b90) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:200 #8 0x0132b7b5 in execute (op_array=0x8fa87e0) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:92 #9 0x0132ba01 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa05fd0) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:234 #10 0x0132b7b5 in execute (op_array=0x8f9a988) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:92 #11 0x0132ba01 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa06280) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:234 #12 0x0132b7b5 in execute (op_array=0x8f8342c) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:92 #13 0x01312029 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/local/php-5.2.9/Zend/zend.c:1134 #14 0x012d96dd in php_execute_script (primary_file=0xbfa08560) at /home/local/php-5.2.9/main/main.c:2023 #15 0x0138d2b6 in apache_php_module_main (r=0x8f71984, display_source_mode=0) at /home/local/php-5.2.9/sapi/apache/sapi_apache.c:53 #16 0x0138dc48 in send_php (r=0x8f71984, display_source_mode=0, filename=0x0) at /home/local/php-5.2.9/sapi/apache/mod_php5.c:664 #17 0x0138de3e in send_parsed_php (r=0x8f71984) at /home/local/php-5.2.9/sapi/apache/mod_php5.c:679 #18 0x0809e808 in ap_invoke_handler () #19 0x080b3eca in process_request_internal () #20 0x080b4323 in ap_internal_redirect () #21 0x0806d3c7 in handler_redirect () #22 0x0809e808 in ap_invoke_handler () #23 0x080b3eca in process_request_internal () #24 0x080b3f29 in ap_process_request () #25 0x080aad2b in child_main () #26 0x080ab014 in make_child () #27 0x080ab34d in perform_idle_server_maintenance () #28 0x080ab95a in standalone_main () #29 0x080abf7d in main () As I mentioned earlier the crash is not very stable, I caught this on PHP compiled without --enable-debug because I could not make it crash otherwise after reasonable effort. With debug enabled though it reports memory leaks: [Wed Apr 1 01:31:18 2009] Script: '/home/local/public_html/site/index.php' /home/local/php-5.2.9/Zend/zend_variables.h(45) : Freeing 0xB7E9DC64 (1 bytes), script=/home/local/public_html/site/index.php /home/local/php-5.2.9/Zend/zend_variables.c(120) : Actual location (location was relayed) [Wed Apr 1 01:31:18 2009] Script: '/home/local/public_html/site/index.php' /home/local/php-5.2.9/ext/xmlrpc/xmlrpc-epi-php.c(362) : Freeing 0x0939CEA8 (21 bytes), script=/home/local/public_html/site/index.php === Total 2 memory leaks detected === Up in backtrace it crashed at serialize step but it tends to occasinally crash at any access attempts to the vari
#47879 [NEW]: FILTER_VALIDATE_EMAIL Error
From: cory dot jacobsen at zu dot com
Operating system: *
PHP version: 5.2.9
PHP Bug Type: Filter related
Bug description: FILTER_VALIDATE_EMAIL Error
Description:
Some email addresses that are obviously wrong, pass the validation with
FILTER_VALIDATE_EMAIL. You can not have a top level domain with one
character only.
Reproduce code:
---
var_dump(filter_var("x...@y.z", FILTER_VALIDATE_EMAIL));
Expected result:
bool(false)
Actual result:
--
string(5) "x...@y.z"
--
Edit bug report at http://bugs.php.net/?id=47879&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47879&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47879&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47879&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47879&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47879&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47879&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47879&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47879&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47879&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47879&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47879&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47879&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47879&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47879&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47879&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47879&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47879&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47879&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47879&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47879&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47879&r=mysqlcfg
#47818 [Opn->Asn]: Segfault due to bound callback param
ID: 47818 Updated by: fel...@php.net Reported By: galaxy dot mipt at gmail dot com -Status: Open +Status: Assigned Bug Type: XMLRPC-EPI related Operating System: Linux 2.6.18 x86 PHP Version: 5.2.9 -Assigned To: +Assigned To: felipe Previous Comments: [2009-04-01 02:44:19] galaxy dot mipt at gmail dot com xmlrpc-epi-php.c, line 1115 (xmlrpc_server_call_method): /* cleanup after ourselves. what a sty! */ zval_dtor(data.xmlrpc_method); FREE_ZVAL(data.xmlrpc_method); zval_dtor(data.return_data); FREE_ZVAL(data.return_data); If I get it right data.xmlrpc_method is completely destructed after method call. What if it has more than 1 reference like in reproduce code? [2009-04-01 02:04:44] galaxy dot mipt at gmail dot com Okay, here's the backtrace from my app (not sure if this is helpful as it does not contain references to XML-RPC extension): #0 0x0078c0ec in memcpy () from /lib/tls/libc.so.6 #1 0x012a4fc2 in php_var_serialize_intern (buf=0xbfa05560, struc=Variable "struc" is not available. ) at /home/local/php-5.2.9/ext/standard/var.c:536 #2 0x012a4b12 in php_var_serialize_intern (buf=0xbfa05560, struc=0x914d4f8, var_hash=0xbfa05570) at /home/local/php-5.2.9/ext/standard/var.c:824 #3 0x012a4b12 in php_var_serialize_intern (buf=0xbfa05560, struc=0xb7f3b114, var_hash=0xbfa05570) at /home/local/php-5.2.9/ext/standard/var.c:824 #4 0x012a4b12 in php_var_serialize_intern (buf=0xbfa05560, struc=0xb7f3b2ec, var_hash=0xbfa05570) at /home/local/php-5.2.9/ext/standard/var.c:824 #5 0x012a7ae5 in php_var_serialize (buf=0xbfa05560, struc=0x9216500, var_hash=0xbfa05570) at /home/local/php-5.2.9/ext/standard/var.c:842 #6 0x012a7b71 in zif_serialize (ht=1, return_value=0xb7f3e694, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /home/local/php-5.2.9/ext/standard/var.c:865 #7 0x0132c009 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa05b90) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:200 #8 0x0132b7b5 in execute (op_array=0x8fa87e0) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:92 #9 0x0132ba01 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa05fd0) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:234 #10 0x0132b7b5 in execute (op_array=0x8f9a988) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:92 #11 0x0132ba01 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa06280) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:234 #12 0x0132b7b5 in execute (op_array=0x8f8342c) at /home/local/php-5.2.9/Zend/zend_vm_execute.h:92 #13 0x01312029 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/local/php-5.2.9/Zend/zend.c:1134 #14 0x012d96dd in php_execute_script (primary_file=0xbfa08560) at /home/local/php-5.2.9/main/main.c:2023 #15 0x0138d2b6 in apache_php_module_main (r=0x8f71984, display_source_mode=0) at /home/local/php-5.2.9/sapi/apache/sapi_apache.c:53 #16 0x0138dc48 in send_php (r=0x8f71984, display_source_mode=0, filename=0x0) at /home/local/php-5.2.9/sapi/apache/mod_php5.c:664 #17 0x0138de3e in send_parsed_php (r=0x8f71984) at /home/local/php-5.2.9/sapi/apache/mod_php5.c:679 #18 0x0809e808 in ap_invoke_handler () #19 0x080b3eca in process_request_internal () #20 0x080b4323 in ap_internal_redirect () #21 0x0806d3c7 in handler_redirect () #22 0x0809e808 in ap_invoke_handler () #23 0x080b3eca in process_request_internal () #24 0x080b3f29 in ap_process_request () #25 0x080aad2b in child_main () #26 0x080ab014 in make_child () #27 0x080ab34d in perform_idle_server_maintenance () #28 0x080ab95a in standalone_main () #29 0x080abf7d in main () As I mentioned earlier the crash is not very stable, I caught this on PHP compiled without --enable-debug because I could not make it crash otherwise after reasonable effort. With debug enabled though it reports memory leaks: [Wed Apr 1 01:31:18 2009] Script: '/home/local/public_html/site/index.php' /home/local/php-5.2.9/Zend/zend_variables.h(45) : Freeing 0xB7E9DC64 (1 bytes), script=/home/local/public_html/site/index.php /home/local/php-5.2.9/Zend/zend_variables.c(120) : Actual location (location was relayed) [Wed Apr 1 01:31:18 2009] Script: '/home/local/public_html/site/index.php' /home/local/php-5.2.9/ext/xmlrpc/xmlrpc-epi-php.c(362) : Freeing 0x0939CEA8 (21 bytes), script=/home/local/public_html/site/index.php === Total 2 memory leaks detected === Up in backtrace it crashed at serialize step but it tends to occasinally crash at any access attempts to the variable that stores the unfortunate XML-RPC method name. [2009-03-31 07:12:12] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind t
#47878 [NEW]: ScriptControl function capitalization discrepancy
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5.3.0RC1
PHP Bug Type: COM related
Bug description: ScriptControl function capitalization discrepancy
Description:
It is possible to call a PHP function in a class that has been stuffed
into a ScriptControl using the code below. However, the name of the
function must be given as lower case, which is probably not the intent.
This is especially odd when the original function's name contains capital
letters.
Reproduce code:
---
http://bugs.php.net/bug.php?id=33386
class twoFuncs {
public function Func1() { echo " func one\n"; }
public function func2() { echo " func two\n"; } }
$clsInstTF = new twoFuncs; // class instance
$oScript = new COM("MSScriptControl.ScriptControl");
$oScript->Language = "VBScript";
$oScript->AddObject ("tF", $clsInstTF, true);
$clsInstTF->func1();// OK
$clsInstTF->Func1();// OK
$oScript->ExecuteStatement ("tF.func1");// OK
$oScript->ExecuteStatement ("tf.func1");// OK
$oScript->ExecuteStatement ("tF.Func1");// Error
?>
Expected result:
I expect so see " func one" repeated on five consecutive lines
Actual result:
--
" func one" is repeated four times, and on the 5th attempt an error
results:
Object doesn't support this property or method: 'tF.Func1'
My guess is that what is happening is that when the function name is being
matched, the actual function name is being lower cased while the function
name being sought is not being lower cased. Note that class instance in
the VBScript script control is matched regardless of capitalization.
In contrast, if the language line is changed to:
$oScript->Language = "VBScript";
then 4th test line (tf.func1) should be commented out because JScript is
case sensitive there. But after that commenting out, the last line still
errors.
This bug is similar to, but distinct from, bug 33386
Csaba Gabor from Vienna
--
Edit bug report at http://bugs.php.net/?id=47878&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47878&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47878&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47878&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47878&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47878&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47878&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47878&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47878&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47878&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47878&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47878&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47878&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47878&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47878&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47878&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47878&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47878&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47878&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47878&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47878&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47878&r=mysqlcfg
#47811 [Asn]: preg_match that can cause segmentation fault
ID: 47811
Updated by: fel...@php.net
Reported By: travis at wikihow dot com
Status: Assigned
Bug Type: Reproducible crash
Operating System: CentOS release 4.4 & Mac OS 10.4
PHP Version: 5.2.9
Assigned To: nlopess
New Comment:
This stack overflow is expected. See the earlies bug reports.
Previous Comments:
[2009-04-02 12:27:26] Phil dot H at gmx dot net
Another php preg_match crash using php 5.2.9-1 on Windows XP and
2003R2:
(?:.(?!\[% ))*.(?=\[%| $))/isx';
if (preg_match($regexp, $string, $aMatches, PREG_OFFSET_CAPTURE, 0)) {
echo "matched\n";
}
echo "finished";
?>
[2009-03-30 12:22:15] paj...@php.net
Nuno, can you take a look please? Can reproduce it here too.
[2009-03-30 11:24:40] scope at planetavent dot de
Here's another snippet:
This one crashes apache 2.2.8 and 2.2.11 with php-5.2.9 and php-5.2.9-1
on windows 2003.
[2009-03-27 23:53:44] dennis dot birkholz at nexxes dot net
I have a similar segfault testcase for preg_match. It always crashes at
a stringlength of around 6700. PHP is 5.2.8 on gentoo linux.
# Create my test-string
for ($i=0; $i<2; $i++) {
$string .= 'a';
}
# The pattern matches for \\, \", everything except " and "
$pattern = '/^(|\\"|[^"]|")+$/';
print "Trying with string length " . "\033" . '[s';
for ($counter=6600; $counter@im', $text, $matches);
Reproduce code:
---
http://wikidiy.com/php_bug_crash.txt
Expected result:
Apache not supposed to crash, completes preg_match, dumps $matches
array.
Actual result:
--
Apache seg faults
[Fri Mar 27 12:16:05 2009] [notice] child pid 6391 exit signal
Segmentation fault (11)
--
Edit this bug report at http://bugs.php.net/?id=47811&edit=1
#47811 [Com]: preg_match that can cause segmentation fault
ID: 47811
Comment by: Phil dot H at gmx dot net
Reported By: travis at wikihow dot com
Status: Assigned
Bug Type: Reproducible crash
Operating System: CentOS release 4.4 & Mac OS 10.4
PHP Version: 5.2.9
Assigned To: nlopess
New Comment:
Another php preg_match crash using php 5.2.9-1 on Windows XP and
2003R2:
(?:.(?!\[% ))*.(?=\[%| $))/isx';
if (preg_match($regexp, $string, $aMatches, PREG_OFFSET_CAPTURE, 0)) {
echo "matched\n";
}
echo "finished";
?>
Previous Comments:
[2009-03-30 12:22:15] paj...@php.net
Nuno, can you take a look please? Can reproduce it here too.
[2009-03-30 11:24:40] scope at planetavent dot de
Here's another snippet:
This one crashes apache 2.2.8 and 2.2.11 with php-5.2.9 and php-5.2.9-1
on windows 2003.
[2009-03-27 23:53:44] dennis dot birkholz at nexxes dot net
I have a similar segfault testcase for preg_match. It always crashes at
a stringlength of around 6700. PHP is 5.2.8 on gentoo linux.
# Create my test-string
for ($i=0; $i<2; $i++) {
$string .= 'a';
}
# The pattern matches for \\, \", everything except " and "
$pattern = '/^(|\\"|[^"]|")+$/';
print "Trying with string length " . "\033" . '[s';
for ($counter=6600; $counter@im', $text, $matches);
Reproduce code:
---
http://wikidiy.com/php_bug_crash.txt
Expected result:
Apache not supposed to crash, completes preg_match, dumps $matches
array.
Actual result:
--
Apache seg faults
[Fri Mar 27 12:16:05 2009] [notice] child pid 6391 exit signal
Segmentation fault (11)
--
Edit this bug report at http://bugs.php.net/?id=47811&edit=1
#47877 [NEW]: ALERT - canary mismatch on efree() - heap overflow detected
From: leif at neland dot dk Operating system: Debian 5 PHP version: 5.2.9 PHP Bug Type: MSSQL related Bug description: ALERT - canary mismatch on efree() - heap overflow detected Description: Basically the same bug as 43861, it seems. Some mssql-queries triggers ALERT - canary mismatch on efree() - heap overflow detected I'm willing to patch, submit traces etc :-) Reproduce code: --- Code probably irrellevant. Expected result: No errors in the log -- Edit bug report at http://bugs.php.net/?id=47877&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47877&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47877&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47877&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47877&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47877&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47877&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47877&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47877&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47877&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47877&r=support Expected behavior: http://bugs.php.net/fix.php?id=47877&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47877&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47877&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47877&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47877&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47877&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47877&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47877&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47877&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47877&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47877&r=mysqlcfg
#47876 [Opn]: Wrong mb_detect_encoding() with string "chr�any"
ID: 47876
User updated by: FrancS at seznam dot cz
Reported By: FrancS at seznam dot cz
Status: Open
Bug Type: mbstring related
Operating System: Windows XP
PHP Version: 5.2.9
New Comment:
I look again on it and problem is with "áÂÂ" in word with no other
accent chars in it.
Previous Comments:
[2009-04-02 10:08:07] FrancS at seznam dot cz
Description:
Hi,
today I discover a problem with mb function mb_detect_encoding().
I have a string "chráÂÂany" in czech language. It seems that this
function everytime return UTF-8 encoding, even if I load the text from a
file with encoding "windows-1250" or "ISO-8859-2".
Reproduce code:
---
// test.txt is text file with charset "windows-1250" or "ISO-8859-2"
$string = file_get_contents('test.txt');
var_dump(mb_detect_encoding($string, mb_list_encodings(), true));
Expected result:
SJIS
Actual result:
--
utf-8
--
Edit this bug report at http://bugs.php.net/?id=47876&edit=1
#47876 [NEW]: Wrong mb_detect_encoding() with string "chr�any"
From: FrancS at seznam dot cz
Operating system: Windows XP
PHP version: 5.2.9
PHP Bug Type: mbstring related
Bug description: Wrong mb_detect_encoding() with string "chráÂÂany"
Description:
Hi,
today I discover a problem with mb function mb_detect_encoding().
I have a string "chráÂÂany" in czech language. It seems that this function
everytime return UTF-8 encoding, even if I load the text from a file with
encoding "windows-1250" or "ISO-8859-2".
Reproduce code:
---
// test.txt is text file with charset "windows-1250" or "ISO-8859-2"
$string = file_get_contents('test.txt');
var_dump(mb_detect_encoding($string, mb_list_encodings(), true));
Expected result:
SJIS
Actual result:
--
utf-8
--
Edit bug report at http://bugs.php.net/?id=47876&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47876&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47876&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47876&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47876&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47876&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47876&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47876&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47876&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47876&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47876&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47876&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47876&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47876&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47876&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47876&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47876&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47876&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47876&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47876&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47876&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47876&r=mysqlcfg
#47851 [Opn->Csd]: is_callable throws fatal error
ID: 47851
Updated by: dmi...@php.net
Reported By: mbecc...@php.net
-Status: Open
+Status: Closed
Bug Type: Class/Object related
Operating System: Irrelevant
PHP Version: 5.3CVS-2009-03-31 (CVS)
-Assigned To:
+Assigned To: dmitry
New Comment:
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.
Previous Comments:
[2009-03-31 15:36:37] mbecc...@php.net
Description:
Under some circumstances is_callable() throws a fatal error when
testing if the PHP4-style constructor of the class (e.g.
is_callable(array('test1', 'test1')).
Unfortunately I wasn't able to create a self-contained example, but the
issue seems to happen often when using Simpletest Mocks in the OpenX
test suite.
It's ok if is_callable returns false if the method cannot be called
statically, but definitely a fatal error isn't expected.
Reproduce code:
---
echo "Test";
is_callable(array('OX_Dal_Maintenance_Statistics',
'OX_Dal_Maintenance_Statistics'));
Expected result:
Test
Actual result:
--
Test
Fatal error: Non-static method
OX_Dal_Maintenance_Statistics::OX_Dal_Maintenance_Statistics() cannot be
called statically in ...
--
Edit this bug report at http://bugs.php.net/?id=47851&edit=1
#36014 [Com]: PDO_MYSQL missing mysql_query
ID: 36014 Comment by: cocowool at gmail dot com Reported By: FranciscSimon at yahoo dot de Status: No Feedback Bug Type: PDO related Operating System: Mandriva 2006 PHP Version: 5.1.2 New Comment: i also had this problem my system is fc10 and php is 5.2.6 when i used "pecl install pdo_mysql" the error listed below: downloading PDO_MYSQL-1.0.2.tgz ... Starting to download PDO_MYSQL-1.0.2.tgz (14,778 bytes) .done: 14,778 bytes 7 source files, building running: phpize Configuring for: PHP Api Version: 20041225 Zend Module Api No: 20060613 Zend Extension Api No: 220060519 config.m4:104: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached ../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from... aclocal.m4:2729: PHP_CHECK_PDO_INCLUDES is expanded from... config.m4:104: the top level config.m4:104: warning: AC_CACHE_VAL(pdo_inc_path, ...): suspicious cache-id, must contain _cv_ to be cached ../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from... ../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from... aclocal.m4:2729: PHP_CHECK_PDO_INCLUDES is expanded from... config.m4:104: the top level building in /var/tmp/pear-build-root/PDO_MYSQL-1.0.2 running: /var/tmp/PDO_MYSQL/configure checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for a sed that does not truncate output... /bin/sed checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc and cc understand -c and -o together... yes checking for system library directory... lib checking if compiler supports -R... no checking if compiler supports -Wl,-rpath,... yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for PHP prefix... /usr checking for PHP includes... -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM -I/usr/include/php/Zend -I/usr/include/php/ext -I/usr/include/php/ext/date/lib checking for PHP extension directory... /usr/lib/php/modules checking for PHP installed headers prefix... /usr/include/php checking for re2c... no configure: WARNING: You will need re2c 0.12.0 or later if you want to regenerate PHP parsers. checking for gawk... gawk checking for MySQL support for PDO... yes, shared checking for mysql_config... /usr/bin/mysql_config checking for mysql_query in -lmysqlclient... no configure: error: mysql_query missing!? ERROR: `/var/tmp/PDO_MYSQL/configure' failed anyone can help thanks Previous Comments: [2006-01-22 01:00:03] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-01-16 15:13:04] dstloukal at post dot cz Hello, I had the same problem. So I tried to use ./configure --with-pdo-mysql=/path/to/your/mysql/installation (E.G.: /usr/local/mysql) and it is all right now. [2006-01-14 22:53:46] tony2...@php.net Put your config.log somewhere and paste the URL here. [2006-01-14 21:54:49] FranciscSimon at yahoo dot de Description: Hi, i installed first PDO with pecl install PDO. After i tried first pecl install PDO_MYSQL and it doesn't work. After that i decide to compile it manualy. during ./configure it shows me this configure: error => configure: WARNING: You will need re2c 0.9.11 or later if you want to regenerate PHP parsers. checking for gawk... gawk checking for MySQL support for PDO... yes, shared checking for mysql_config... /usr/bin/mysql_config checking for mysql_query in -lmysqlclient... no configure: error: mysql_query missing!? compiling command was phpize && ./configure && make && make install THX :-) Frank Reproduce code: --- configure: WARNING: You will need re2c 0.9.11 or later if you want to regenerate PHP parsers. checking for gawk... gawk checking for MySQL support for PDO... yes, shared checking for mysql_config... /usr/bin/mysql_config checking for mysql_query in -lmysqlclient... no configure: error: mysql_quer
#47873 [Fbk->Opn]: PHP can not parse extension_dir
ID: 47873 User updated by: ronaldo dot sy at gmail dot com Reported By: ronaldo dot sy at gmail dot com -Status: Feedback +Status: Open Bug Type: *Configuration Issues Operating System: Windows 7 PHP Version: 5.2.9 New Comment: Yes, because when I check the "Loaded Configuration File" fiels at phpinfo, it show to the correct php.ini file (which located at c:\php\php.ini) Previous Comments: [2009-04-02 07:38:06] paj...@php.net Using a php.ini I suppose? If yes, are you the php.ini is loaded? [2009-04-02 06:06:07] ronaldo dot sy at gmail dot com Description: It seems PHP can not parse the location of extension_dir. I already change the location at php.ini, but every time I open the phpinfo page the extension_dir keep pointing to c:\php5, After I use version 5.28 the problem is gone. I use IIS version 7.5 -- Edit this bug report at http://bugs.php.net/?id=47873&edit=1
#47870 [Opn]: array() returns NULL
ID: 47870 Updated by: mbecc...@php.net Reported By: mbecc...@php.net Status: Open Bug Type: Arrays related Operating System: FreeBSD 6.2 PHP Version: 5.3CVS-2009-04-01 (CVS) New Comment: I've tried to reduce the affected test to a smaller test case with no luck. As soon as I remove something from it. It suddenly starts to pass with no segfault. Previous Comments: [2009-04-02 00:36:03] mbecc...@php.net mat...@phenom-ubuntu:~/OX-trunk/tests$ valgrind --tool=memcheck --num-callers=30 --log-file=php.log /usr/local/bin/php run.php --type=unit --level=file --layer=dal --folder=lib/OA/Dal/Maintenance --file=Priority_getZoneImpressionForecasts.dal.test.php --format=text --host=test Priority_getZoneImpressionForecasts.dal.test.php Segmentation fault mat...@phenom-ubuntu:~/OX-trunk/tests$ cat php.log ==11808== Memcheck, a memory error detector. ==11808== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==11808== Using LibVEX rev 1854, a library for dynamic binary translation. ==11808== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==11808== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation framework. ==11808== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==11808== For more details, rerun with: -v ==11808== ==11808== My PID = 11808, parent PID = 10101. Prog and args are: ==11808==/usr/local/bin/php ==11808==run.php ==11808==--type=unit ==11808==--level=file ==11808==--layer=dal ==11808==--folder=lib/OA/Dal/Maintenance ==11808==--file=Priority_getZoneImpressionForecasts.dal.test.php ==11808==--format=text ==11808==--host=test ==11808==Priority_getZoneImpressionForecasts.dal.test.php ==11808== ==11808== Conditional jump or move depends on uninitialised value(s) ==11808==at 0x7FF79D: _zval_ptr_dtor (zend_execute_API.c:430) ==11808==by 0x824537: zend_hash_clean (zend_hash.c:552) ==11808==by 0x849231: zend_leave_helper_SPEC (zend_vm_execute.h:208) ==11808==by 0x8DC019: ZEND_RETURN_SPEC_CV_HANDLER (zend_vm_execute.h:22098) ==11808==by 0x848774: execute (zend_vm_execute.h:104) ==11808==by 0x814198: zend_execute_scripts (zend.c:1188) ==11808==by 0x768884: php_execute_script (main.c:2157) ==11808==by 0x9125CE: main (php_cli.c:1159) ==11808== ==11808== Conditional jump or move depends on uninitialised value(s) ==11808==at 0x7FF861: _zval_ptr_dtor (zend_execute_API.c:441) ==11808==by 0x824537: zend_hash_clean (zend_hash.c:552) ==11808==by 0x849231: zend_leave_helper_SPEC (zend_vm_execute.h:208) ==11808==by 0x8DC019: ZEND_RETURN_SPEC_CV_HANDLER (zend_vm_execute.h:22098) ==11808==by 0x848774: execute (zend_vm_execute.h:104) ==11808==by 0x814198: zend_execute_scripts (zend.c:1188) ==11808==by 0x768884: php_execute_script (main.c:2157) ==11808==by 0x9125CE: main (php_cli.c:1159) ==11808== ==11808== Conditional jump or move depends on uninitialised value(s) ==11808==at 0x881939: zend_assign_to_variable (zend_execute.c:664) ==11808==by 0x8FCC90: ZEND_ASSIGN_SPEC_CV_VAR_HANDLER (zend_vm_execute.h:27359) ==11808==by 0x848774: execute (zend_vm_execute.h:104) ==11808==by 0x814198: zend_execute_scripts (zend.c:1188) ==11808==by 0x768884: php_execute_script (main.c:2157) ==11808==by 0x9125CE: main (php_cli.c:1159) ==11808== ==11808== Conditional jump or move depends on uninitialised value(s) ==11808==at 0x881991: zend_assign_to_variable (zend_execute.c:669) ==11808==by 0x8FCC90: ZEND_ASSIGN_SPEC_CV_VAR_HANDLER (zend_vm_execute.h:27359) ==11808==by 0x848774: execute (zend_vm_execute.h:104) ==11808==by 0x814198: zend_execute_scripts (zend.c:1188) ==11808==by 0x768884: php_execute_script (main.c:2157) ==11808==by 0x9125CE: main (php_cli.c:1159) ==11808== ==11808== Conditional jump or move depends on uninitialised value(s) ==11808==at 0x881A77: zend_assign_to_variable (zend_execute.c:684) ==11808==by 0x8FCC90: ZEND_ASSIGN_SPEC_CV_VAR_HANDLER (zend_vm_execute.h:27359) ==11808==by 0x848774: execute (zend_vm_execute.h:104) ==11808==by 0x814198: zend_execute_scripts (zend.c:1188) ==11808==by 0x768884: php_execute_script (main.c:2157) ==11808==by 0x9125CE: main (php_cli.c:1159) ==11808== ==11808== Conditional jump or move depends on uninitialised value(s) ==11808==at 0x881939: zend_assign_to_variable (zend_execute.c:664) ==11808==by 0x8EF8A8: ZEND_ASSIGN_SPEC_CV_TMP_HANDLER (zend_vm_execute.h:25711) ==11808==by 0x848774: execute (zend_vm_execute.h:104) ==11808==by 0x814198: zend_execute_scripts (zend.c:1188) ==11808==by 0x768884: php_execute_script (main.c:2157) ==11808==by 0x9125CE: main (php_cli.c:1159) ==11808== ==11808== Conditional jump or move depends on uninitialised value(s) ==11808==at 0x881991: zend_assign_to_variable (zend_execute.c:669) ==
#47875 [NEW]: no option to set HTML input encoding
From: thomas dot koch at ymc dot ch Operating system: Debian Lenny PHP version: 5.2.9 PHP Bug Type: XML related Bug description: no option to set HTML input encoding Description: Enhancement request. I need a possibility to indicate the html input encoding (as parsed from the HTTP headers) when parsing a html string with DOMDocument::loadHTML. Using loadHTMLFile is not always an option. libxml2 honors the content-type meta tag, but this may not always be present. How should the input encoding be indicated? In DOMDocument::__construct() or in DOMDocument::encoding or is that both the same? One could look in libxml2/HTMLparser.c#5580, function htmlCreateFileParserCtxt(const char *filename, const char *encoding) There the encoding is set by first building a "charset=$encoding" string and passing it to htmlCheckEncoding, which in turn parses the encoding out of the string again. This may be worth cleaning up together with upstream. Reproduce code: --- http://www.w3.org/TR/REC-html40/loose.dtd";> süà EOT; $dom = new DOMDocument; var_dump( $dom->loadHTML( $html ) ); $elem = $dom->getElementById( 'umlaut' ); echo $elem->textContent; -- Edit bug report at http://bugs.php.net/?id=47875&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47875&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47875&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47875&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47875&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47875&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47875&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47875&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47875&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47875&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47875&r=support Expected behavior: http://bugs.php.net/fix.php?id=47875&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47875&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47875&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47875&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47875&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47875&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47875&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47875&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47875&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47875&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47875&r=mysqlcfg
#47862 [Com]: stream_socket_client with tls gives an unknown error on solaris 8
ID: 47862
Comment by: llongo at sata-hts dot com
Reported By: llongo at sata-hts dot com
Status: Feedback
Bug Type: Streams related
Operating System: solaris 8
PHP Version: 5.2.9
New Comment:
I've solved the problem installing the patch 112438 for Solaris 8,
which does not have natively support for /dev/urandom and /dev/random.
(http://sunsolve.sun.com/search/document.do?assetkey=1-21-112438-03-1)
Thanks for your help, this is not a php bug.
Previous Comments:
[2009-04-02 07:21:23] llongo at sata-hts dot com
The openssl version of solaris 8 (sparc) is 0.9.8k (downloaded from
http://www.sunfreeware.com/indexsparc8.html), while in the Solaris 10
the openssl version is 0.9.7 and in CentOS 5 is 0.9.8b.
[2009-04-01 13:34:09] j...@php.net
Check the openssl versios in the working / failing servers.
[2009-04-01 13:32:40] llongo at sata-hts dot com
Description:
The client script should connect through tls to server and send him
some messages, but an error occurs and the tls connection cannot be
established. The client script works fine on CentOS 5 (x86_64) and
Solaris 10 (x86), but gives the error reported only on Solaris 8 (sparc)
[tls is supported], while server script always runs on CentOS5
(x86_64).
This is the configure option for php:
./configure \
--enable-xml \
--enable-libxml \
--with-tsrm-pthreads \
--with-openssl \
--with-zlib \
--with-pcre-regex \
--with-pear \
--enable-sysvsem \
--enable-sysvshm \
--enable-sysvmsg \
--enable-shmop \
--enable-pcntl \
--with-gettext \
--enable-sockets \
--enable-mbstring \
--with-imap-ssl \
--with-mcrypt \
--disable-cgi \
--with-gnu-ld
Reproduce code:
---
array('capture_peer_cert'=>TRUE)));
$fp = stream_socket_client("tls://192.168.14.200:8000", $errno,
$errstr, 30, STREAM_CLIENT_CONNECT, $context);
if (!$fp) {
die("error creating socket (".$errno."):".$errstr."\n");
}
$i_sleep = 1;
for ($i_counter = 0; $i_counter < 10; $i_counter++) {
$s_msg = "message sent ".$i_counter;
fwrite($fp,$s_msg);
sleep($i_sleep);
}
fclose($fp);
?>
0){
$data = fread($conn,8192);
if($data == "") {
fclose($socket);
die("socket error reading\n");
}
echo "MESSAGE RECEIVED: ".$data."\n";
}
}
?>
Expected result:
Client connects to server, sends 10 messages and then exits. The server
output is:
MESSAGE RECEIVED: message sent 0
MESSAGE RECEIVED: message sent 1
MESSAGE RECEIVED: message sent 2
MESSAGE RECEIVED: message sent 3
MESSAGE RECEIVED: message sent 4
MESSAGE RECEIVED: message sent 5
MESSAGE RECEIVED: message sent 6
MESSAGE RECEIVED: message sent 7
MESSAGE RECEIVED: message sent 8
MESSAGE RECEIVED: message sent 9
socket error reading
Actual result:
--
Client doesn't connect to server and the output is:
CLIENT:
Warning: stream_socket_client(): SSL: Error 0 in /client.php on line 2
Warning: stream_socket_client(): Failed to enable crypto in /client.php
on line 2
Warning: stream_socket_client(): unable to connect to
tls://192.168.14.200:8000 (Unknown error) in /client.php on line 2
error creating socket (0):
SERVER:
PHP Warning: stream_socket_accept(): Failed to enable crypto in
/server.php on line 9
Warning: stream_socket_accept(): Failed to enable crypto in /server.php
on line 9
PHP Warning: stream_socket_accept(): accept failed: Success in
/server.php on line 9
Warning: stream_socket_accept(): accept failed: Success in /server.php
on line 9
error waiting for connection
--
Edit this bug report at http://bugs.php.net/?id=47862&edit=1
#47874 [NEW]: crash while prepare statement
From: jan dot schmidt at vitronic dot de
Operating system: Win XP SP3
PHP version: 5.2.9
PHP Bug Type: PDO related
Bug description: crash while prepare statement
Description:
I'm running an Apache 2.2.9 Webserver and a MySQL 5.1.31 Database and want
to insert a lot of rows over PDO MySQL Extension. But if the testscript is
very often requested, php crashes while preparing a statement.
I find out that the easiest way to reproduce the crash is to open the
testscript in firefox and keep the F5 Key pressed.
For the backtrace i used the php 5.2 snap from 2009-04-01.
Only the pdo and pdo_mysql extensions are loaded.
Reproduce code:
---
true));
$dbhandle->exec('SET CHARACTER SET utf8');
$dbhandle->exec('CREATE DATABASE testdb');
$dbhandle->exec('CREATE TABLE testdb.testtable(id bigint(20) NOT NULL
AUTO_INCREMENT, testcol text collate utf8_unicode_ci NOT NULL, PRIMARY
KEY(id))');
for($i = 0;$i < 100;$i++)
{
$stmt = $dbhandle->prepare('INSERT INTO testdb.testtable (testcol)
VALUES (:testcol)');
$stmt->bindValue(':testcol','testentrie nr '.$i,PDO::PARAM_STR);
$stmt->execute();
}
?>
Expected result:
Script insert 100 rows to Table testtable.
Actual result:
--
Script Crashes
Backtrace:
_zend_mm_free_int(_zend_mm_heap * 0x0110faf8, void * 0x002e) line 1974
+ 132 bytes
_efree(void * 0x00fb5200) line 2306 + 11 bytes
_zval_ptr_dtor(_zval_struct * * 0x0558fa8c) line 415 + 37 bytes
zend_std_write_property(_zval_struct * 0x015e2b9a, _zval_struct *
0x05d6d530, _zval_struct * 0x00fb5200, void * * * 0x05d6d230) line 417 + 12
bytes
pdo_stmt_construct(_pdo_stmt_t * 0x015e2a0d, _zval_struct * 0x05d6d348,
_zend_class_entry * 0x05d6d530, _zval_struct * 0x00fb5090, void * * *
0x) line 447
zim_PDO_prepare(int 7916969, _zval_struct * 0x00fb5090, _zval_struct * *
0x05d6d530, _zval_struct * 0x, int 93948008, void * * * 0x0001)
line 581 + 22 bytes
zend_do_fcall_common_helper_SPEC(_zend_execute_data * 0x0078c5c5, void * *
* 0x0558fbb0) line 200 + 61 bytes
ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data * 0x0558fbb0, void *
* * 0x0110ece0) line 322 + 17 bytes
execute(_zend_op_array * 0x0082e6fd, void * * * 0x0008) line 92 + 12
bytes
php_execute_script(_zend_file_handle * 0x05d6d4dc, void * * * 0x)
line 2023 + 18 bytes
05d6d19c()
05d6d190()
PHP_PDO! pdo_row_object_handlers + 200 bytes
--
Edit bug report at http://bugs.php.net/?id=47874&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47874&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47874&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47874&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47874&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47874&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47874&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47874&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47874&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47874&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47874&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47874&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47874&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47874&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47874&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47874&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47874&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47874&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47874&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47874&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47874&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47874&r=mysqlcfg
#47873 [Opn->Fbk]: PHP can not parse extension_dir
ID: 47873 Updated by: paj...@php.net Reported By: ronaldo dot sy at gmail dot com -Status: Open +Status: Feedback Bug Type: *Configuration Issues Operating System: Windows 7 PHP Version: 5.2.9 New Comment: Using a php.ini I suppose? If yes, are you the php.ini is loaded? Previous Comments: [2009-04-02 06:06:07] ronaldo dot sy at gmail dot com Description: It seems PHP can not parse the location of extension_dir. I already change the location at php.ini, but every time I open the phpinfo page the extension_dir keep pointing to c:\php5, After I use version 5.28 the problem is gone. I use IIS version 7.5 -- Edit this bug report at http://bugs.php.net/?id=47873&edit=1
#47862 [Com]: stream_socket_client with tls gives an unknown error on solaris 8
ID: 47862
Comment by: llongo at sata-hts dot com
Reported By: llongo at sata-hts dot com
Status: Feedback
Bug Type: Streams related
Operating System: solaris 8
PHP Version: 5.2.9
New Comment:
The openssl version of solaris 8 (sparc) is 0.9.8k (downloaded from
http://www.sunfreeware.com/indexsparc8.html), while in the Solaris 10
the openssl version is 0.9.7 and in CentOS 5 is 0.9.8b.
Previous Comments:
[2009-04-01 13:34:09] j...@php.net
Check the openssl versios in the working / failing servers.
[2009-04-01 13:32:40] llongo at sata-hts dot com
Description:
The client script should connect through tls to server and send him
some messages, but an error occurs and the tls connection cannot be
established. The client script works fine on CentOS 5 (x86_64) and
Solaris 10 (x86), but gives the error reported only on Solaris 8 (sparc)
[tls is supported], while server script always runs on CentOS5
(x86_64).
This is the configure option for php:
./configure \
--enable-xml \
--enable-libxml \
--with-tsrm-pthreads \
--with-openssl \
--with-zlib \
--with-pcre-regex \
--with-pear \
--enable-sysvsem \
--enable-sysvshm \
--enable-sysvmsg \
--enable-shmop \
--enable-pcntl \
--with-gettext \
--enable-sockets \
--enable-mbstring \
--with-imap-ssl \
--with-mcrypt \
--disable-cgi \
--with-gnu-ld
Reproduce code:
---
array('capture_peer_cert'=>TRUE)));
$fp = stream_socket_client("tls://192.168.14.200:8000", $errno,
$errstr, 30, STREAM_CLIENT_CONNECT, $context);
if (!$fp) {
die("error creating socket (".$errno."):".$errstr."\n");
}
$i_sleep = 1;
for ($i_counter = 0; $i_counter < 10; $i_counter++) {
$s_msg = "message sent ".$i_counter;
fwrite($fp,$s_msg);
sleep($i_sleep);
}
fclose($fp);
?>
0){
$data = fread($conn,8192);
if($data == "") {
fclose($socket);
die("socket error reading\n");
}
echo "MESSAGE RECEIVED: ".$data."\n";
}
}
?>
Expected result:
Client connects to server, sends 10 messages and then exits. The server
output is:
MESSAGE RECEIVED: message sent 0
MESSAGE RECEIVED: message sent 1
MESSAGE RECEIVED: message sent 2
MESSAGE RECEIVED: message sent 3
MESSAGE RECEIVED: message sent 4
MESSAGE RECEIVED: message sent 5
MESSAGE RECEIVED: message sent 6
MESSAGE RECEIVED: message sent 7
MESSAGE RECEIVED: message sent 8
MESSAGE RECEIVED: message sent 9
socket error reading
Actual result:
--
Client doesn't connect to server and the output is:
CLIENT:
Warning: stream_socket_client(): SSL: Error 0 in /client.php on line 2
Warning: stream_socket_client(): Failed to enable crypto in /client.php
on line 2
Warning: stream_socket_client(): unable to connect to
tls://192.168.14.200:8000 (Unknown error) in /client.php on line 2
error creating socket (0):
SERVER:
PHP Warning: stream_socket_accept(): Failed to enable crypto in
/server.php on line 9
Warning: stream_socket_accept(): Failed to enable crypto in /server.php
on line 9
PHP Warning: stream_socket_accept(): accept failed: Success in
/server.php on line 9
Warning: stream_socket_accept(): accept failed: Success in /server.php
on line 9
error waiting for connection
--
Edit this bug report at http://bugs.php.net/?id=47862&edit=1
