#49954 [Fbk->Csd]: Crypt() does not work for string < 4 character
ID: 49954
User updated by: rgr at woodwing dot com
Reported By: rgr at woodwing dot com
-Status: Feedback
+Status: Closed
Bug Type: *Encryption and hash functions
Operating System: win32 only - Win XP 64-bit
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Hello Pajoye,
thank you for your response. I have tried the 5.3.2-dev build from
snapshot and this issue is indeed fixed there.
Good to know this is fixed in a later version.
Previous Comments:
[2009-11-02 20:47:57] paj...@php.net
May be related to #50052. Please try a SVN snapshot.
[2009-10-31 16:53:13] paj...@php.net
I can't reproduce it here. Can you try using a php 5.3 VC9 snapshot
please? http://windows.php.net/snapshots/
[2009-10-30 12:47:59] carlodeboer at me dot com
We are also experiencing problems with this bug. Especially during
testing and pilot studies it is quite common to have short passwords.
Upgrading to PHP 5.3 is not possible with this bug since we have to
support existing installations with short passwords.
[2009-10-27 13:44:50] vdklah at hotmail dot com
This problem is pretty bad; After PHP 5.2->5.3 migration, users having
short passwords are no longer allowed to login (to our system) due to
the crypt mismatch! And, even worse, they are not allowed to change
their password due to the very same problem!
[2009-10-22 11:51:05] rgr at woodwing dot com
Description:
The function Crypt() does not work with less than 4 characters in PHP
5.3.0. See the code sample below.
When using 'test' as $user_input and $password it does work correct.
Reproduce code:
---
---
>From manual page: function.crypt#Examples
---
$user_input = 'tes';
$password = crypt('tes'); // let the salt be automatically generated
if (crypt($user_input, $password) == $password) {
echo "Password verified!";
}
Expected result:
The comparison should result true.
Actual result:
--
The comparison returns false.
--
Edit this bug report at http://bugs.php.net/?id=49954&edit=1
#48528 [NoF->Csd]: mysqlnd causes PDO/MySQLi to leak memory
ID: 48528
Updated by: u...@php.net
Reported By: bugs dot php dot net at moesen dot nu
-Status: No Feedback
+Status: Closed
Bug Type: MySQL related
Operating System: Linux 2.6
PHP Version: 5.3CVS-2009-06-11 (snap)
New Comment:
Duplicate of http://bugs.php.net/bug.php?id=48343 - there is no leak,
mysqlnd and libmysql work differently.
Previous Comments:
[2009-10-30 12:32:15] guenter at grodotzki dot ph
same problem here, though with the normal mysql_query + mysql_fetch*
functions
[2009-06-20 01:00:00] 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".
[2009-06-16 08:31:16] bugs dot php dot net at moesen dot nu
> libmysql's allocations are hidden.
OK, that explains the numbers. Thanks.
> Do you really get OOM with mysqlnd?
Yes, for the same dataset.
> as you can see the memory usage with USE_RESULT doesn't jump
Thanks for that pointer. I completely missed it in the documentation,
and since we never had any problems before switching over to 5.3, I
never needed it. The human equivalent of lazy evaluation, I guess.
So if I understand it correctly, libmysql is not subject to PHP's
memory limit, whereas mysqlnd is?
[2009-06-12 07:36:09] and...@php.net
Do you really get OOM with mysqlnd? memory_get_usage() is constant with
libmysql because libmysql allocates its memory with malloc while Zend
and all PHP functions mostly use emalloc. emalloc counts the allocated
memory. libmysql's allocations are hidden.
I tried your script, created a simple table with the same name and
- int
- double
- varchar
- decimal
columns.
I have 33 rows. Here is the output when the data is fetched with
MYSQLI_STORE_RESULT, which is the default:
361756 <- before $result = $db->query
366384
366656
366928
367200
367472
367744
368016
368288
368560
368832
369104
369376
369648
369920
370192
370464
370736
371008
371280
371552
371824
372096
372368
372640
372912
373184
373456
373728
374000
374272
374544
374816
375088
362840 <- this is the result after I do $result->free_result(), which
means that the memory doesn't leak. Most of it is reclaimed. It can be
that Zend also cache some zvals in its zval cache, which means that
memory has not leaked and is there for further usage.
Here is with MYSQLI_USE_RESULT:
361756 <- before $result = $db->query
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
362840 <- After $result->free_result()
So, as you can see the memory usage with USE_RESULT doesn't jump, for a
reaon. Because data is not stored on the client side. With libmysql you
cannot see it, but the usage is there.
[2009-06-11 12:17:57] bugs dot php dot net at moesen dot nu
Description:
PHP 5.3 leaks memory when using the MySQL functions, both through PDO
and MySQLi directly. When recompiled without mysqlnd, the same code
works fine.
./configure --with-mysql=shared,mysqlnd --with-mysqli=shared,mysqlnd
--with-pdo-mysql=shared,mysqlnd [ . . . ]
Recompiled today's snapshot without the ',mysqlnd'.
Reproduce code:
---
PDO:
$db = new PDO($dsn, $user, $pass);
$stmt = $test->prepare('SELECT * FROM
tech_eciffOkcab.crawlPriceComp');
$result = $stmt->execute();
while($result && $row = $stmt->fetch(PDO::FETCH_ASSOC)) {
echo memory_get_usage(), "\n";
}
MySQLi:
$db = new MySQLi($host, $user, $pass);
$result = $db->query('SELECT * FROM tech_eciffOkcab.crawlPriceComp');
while ($result && $row = $result->fetch_assoc()) {
echo memory_get_usage(), "\n";
}
Expected result:
Consistent memory_get_usage();
I.e., no extra memory required, and thus no out-of-memory errors.
Actual result:
--
Linearly increasing memory_get_usage();
PDO:
23168400
23169064
...
33552804
33552916
-> OOM and segfault.
MySQLi:
23168216
23168700
...
33552812
33552924
-> OOM and segfault.
--
Edit this bug report at http://bugs.php.net/?id=48528&edit=1
#50021 [Opn->Fbk]: Predefined Statements doesn't allow Strings with more than 256 letters.
ID: 50021
Updated by: u...@php.net
Reported By: novitools dot novi at web dot de
-Status: Open
+Status: Feedback
Bug Type: MySQLi related
Operating System: Windows Vista
PHP Version: 5.3.0
New Comment:
Please run you query in the MySQL prompt and show the meta data that is
returned from MySQL. Start the MySQL prompt with "mysql
--column-type-info" followed by your usual "-u", "-p", "-h" etc.
options.
For example:
nixn...@ulflinux:~> /usr/local/mysql/bin/mysql --column-type-info
-uroot -proot
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 13
Server version: 5.1.39-debug Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
mysql> select 1;
Field 1: `1`
Catalog:`def`
Database: ``
Table: ``
Org_table: ``
Type: LONGLONG
Collation: binary (63)
Length: 1
Max_length: 1
Decimals: 0
Flags: NOT_NULL BINARY NUM
+---+
| 1 |
+---+
| 1 |
+---+
1 row in set (0.00 sec)
But, of course, run your failing query and run mysql prompt on your
system.
Thanks,
Ulf
Previous Comments:
[2009-10-30 15:12:35] novitools dot novi at web dot de
So the problem only occurs on specific versions:
No Problem with this Versions:
client_version 50005
server_version 50132
Big Problem with this Versions:
client_version 50137
server_version 50137
[2009-10-29 17:58:24] friedrich dot mark at freenet dot de
Same Problem here:
$db = new mysqli('localhost', 'root', '', 'test');
$stmt = $db->stmt_init();
$sql = "SELECT `text` FROM `longtext` WHERE `id` = 1";
$stmt->prepare($sql);
$stmt->execute();
$stmt->bind_result($text);
$stmt->fetch();
$stmt->close();
var_dump(phpversion());
var_dump($db->client_version);
var_dump($db->server_version);
var_dump($db->protocol_version);
var_dump($text);
Output:
string(5) "5.3.0"
int(50137)
int(50137)
int(10)
string(256) "Lorem ipsum dolor sit amet, consetetur sadipscing elitr,
sed diam nonumy eirmod tempor invidunt ut labore et dolore magna
aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo
dolores et ea rebum. Stet clita kasd gubergren, no sea takimata "
OS: Win 7
SQL:
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
CREATE DATABASE `test` DEFAULT CHARACTER SET latin1 COLLATE
latin1_swedish_ci;
USE `test`;
CREATE TABLE IF NOT EXISTS `longtext` (
`id` int(11) NOT NULL,
`text` text NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
INSERT INTO `longtext` (`id`, `text`) VALUES
(1, 'Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam
nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat,
sed diam voluptua. At vero eos et accusam et justo duo dolores et ea
rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem
ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing
elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna
aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo
dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus
est Lorem ipsum dolor sit amet.');
[2009-10-29 17:07:41] novitools dot novi at web dot de
When I run the test from hellbringer at gmail dot com I get a different
result. Also the MySQL-Versions are different:
string(5) "5.3.0"
int(50137)
int(50137)
int(10)
string(256) "You can only read the first 256 words of this text.
That
is why I must write such a long text, because I must reach the limit
of
256 words. The same error occours, when you try to select a text
column
from the database. But I didn't had this error befo"
Are there any setting that can cause this problem?
[2009-10-29 16:26:39] hellbringer at gmail dot com
Works for me in PHP 5.3.0:
stmt_init();
$sql = "SELECT 'You can only read the first 256 words of this text.
That
is why I must write such a long text, because I must reach the limit
of
256 words. The same error occours, when you try to select a text
column
from the database. But I didn\'t had this error before in a previous
version of php.'";
$stmt->prepare($sql);
$stmt->execute();
$stmt->bind_result($text);
$stmt->fetch();
$stmt->close();
var_dump(phpversion());
var_dump($db->client_version);
var_dump($db->server_version);
var_dump($db->protocol_version);
var_dump($text);
?>
Output:
string(5) "5.3.0"
int(50005)
int(50132)
int(10)
string(288) "You can only read the first 256 words of this text. That
is why I must write such a long text, because I must reach the limit
of
256 words. The same error occours, when you try to select a text
column
from the database. But I didn't had this error before in a previous
version of php."
#50060 [Opn->Bgs]: "failed creating formpost data" if post array value starts with '@'
ID: 50060
Updated by: scott...@php.net
Reported By: bugs dot php dot net at sgerrand dot com
-Status: Open
+Status: Bogus
Bug Type: cURL related
Operating System: Linux (Ubuntu x86_64 2.6.31-14)
PHP Version: 5.2.11
New Comment:
@ has a special meaning with cURL and takes the contents of the file.
Previous Comments:
[2009-11-03 07:29:36] bugs dot php dot net at sgerrand dot com
Description:
PHP's cURL library dies returning the error message "failed creating
formpost data" when trying to use an array that contains a value
starting with '@'.
If the array is changed to a string in URL encoded like format, the
problem does not occur.
Reproduce code:
---
http://www.php.net';
$postData = array('key' => '@value');
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $postData);
if (! curl_exec($ch) ) print 'cURL error: ' . curl_error($ch);
else print "cURL success";
curl_close($ch);
?>
Expected result:
cURL success
Actual result:
--
cURL error: failed creating formpost data
--
Edit this bug report at http://bugs.php.net/?id=50060&edit=1
#49997 [Opn->Fbk]: Implementing a namespaced interface crashes
ID: 49997
Updated by: scott...@php.net
Reported By: flavius dot as at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Linux x86_64
PHP Version: 5.3.0
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
There was a fix for autoload crashing on an interface in bug #49908
Previous Comments:
[2009-11-03 05:59:15] flavius dot as at gmail dot com
Could someone do something with this report?
[2009-11-03 01:00:00] 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".
[2009-10-28 19:30:23] flavius dot as at gmail dot com
Sorry for the incomplete post.
This happens in my scripts because it's trying to autoload an
interface.
My code was indeed buggy, but I woudn't expect PHP to crash.
[2009-10-28 19:27:29] flavius dot as at gmail dot com
After some debugging, I came to the conclusion that it crashes because
of an exception being thrown inside a spl_register_autoload()'ed
userland method.
Here's the bt:
#0 zend_lookup_class_ex (name=0x15b9d40 "Exception", name_length=9,
use_autoload=1, ce=0x7fffb2e0) at
/home/flav/php-5.3.0/Zend/zend_execute_API.c:1016
#1 0x007954d1 in zend_fetch_class (class_name=0x15b9d40
"Exception", class_name_len=9, fetch_type=4)
at /home/flav/php-5.3.0/Zend/zend_execute_API.c:1524
#2 0x007d8d22 in ZEND_FETCH_CLASS_SPEC_CONST_HANDLER
(execute_data=0x76552cc0) at
/home/flav/php-5.3.0/Zend/zend_vm_execute.h:724
#3 0x007d6b50 in execute (op_array=0x15bc828) at
/home/flav/php-5.3.0/Zend/zend_vm_execute.h:104
#4 0x007940e5 in zend_call_function (fci=0x7fffb640,
fci_cache=0x7fffb5d0) at
/home/flav/php-5.3.0/Zend/zend_execute_API.c:936
#5 0x007bfae4 in zend_call_method (object_pp=0x0,
obj_ce=0x15b8eb0, fn_proxy=0x15b09f8, function_name=0x15ba410
"\\yap\\base::autoload",
function_name_len=20, retval_ptr_ptr=0x7fffb748, param_count=1,
arg1=0x15f8930, arg2=0x0) at
/home/flav/php-5.3.0/Zend/zend_interfaces.c:97
#6 0x00600de0 in zif_spl_autoload_call (ht=1,
return_value=0x161c620, return_value_ptr=0x7fffba70, this_ptr=0x0,
return_value_used=1)
at /home/flav/php-5.3.0/ext/spl/php_spl.c:395
#7 0x007942c2 in zend_call_function (fci=0x7fffba20,
fci_cache=0x7fffb9f0) at
/home/flav/php-5.3.0/Zend/zend_execute_API.c:958
#8 0x00794999 in zend_lookup_class_ex (name=0x15f8a30
"YAP\\patterns\\IInheritable", name_length=25, use_autoload=1,
ce=0x7fffbb20)
at /home/flav/php-5.3.0/Zend/zend_execute_API.c:1089
#9 0x007954d1 in zend_fetch_class (class_name=0x15f8a30
"YAP\\patterns\\IInheritable", class_name_len=25, fetch_type=6)
at /home/flav/php-5.3.0/Zend/zend_execute_API.c:1524
#10 0x007d93d3 in ZEND_ADD_INTERFACE_SPEC_CONST_HANDLER
(execute_data=0x76552bb8) at
/home/flav/php-5.3.0/Zend/zend_vm_execute.h:890
#11 0x007d6b50 in execute (op_array=0x15f68c8) at
/home/flav/php-5.3.0/Zend/zend_vm_execute.h:104
#12 0x007a38de in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/flav/php-5.3.0/Zend/zend.c:1188
#13 0x0072ed19 in php_execute_script
(primary_file=0x7fffe1b0) at /home/flav/php-5.3.0/main/main.c:2196
#14 0x0088c885 in main (argc=7, argv=0x7fffe408) at
/home/flav/php-5.3.0/sapi/cli/php_cli.c:1188
[2009-10-26 16:54:38] flavius dot as at gmail dot com
Done. The output:
Reading symbols from /home/flav/php-5.3.0/sapi/cli/php...done.
(gdb) run /usr/bin/phpunit --bootstrap bootstrap.php --configuration
phpunit.xml testunit/
Starting program: /home/flav/php-5.3.0/sapi/cli/php /usr/bin/phpunit
--bootstrap bootstrap.php --configuration phpunit.xml testunit/
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x007d93db in ZEND_ADD_INTERFACE_SPEC_CONST_HANDLER
(execute_data=0x765529a8) at
/home/flav/php-5.3.0/Zend/zend_vm_execute.h:892
892 if (!(iface->ce_flags & ZEND_ACC_INTERFACE)) {
(gdb) bt
#0 0x007d93db in ZEND_ADD_INTERFACE_SPEC_CONST_HANDLER
(execute_data=0x765529a8) at
/home/flav/php-5.3.0/Zend/zend_vm_execute.h:892
#1 0x007d6b50 in execute (op_array=0x161f078) at
/home/flav/php-5.3.0/Zend/zend_vm_execute.h:104
#2 0x007a38de in zend_exe
#49965 [Opn->Asn]: Setting MYSQLI_OPT_CONNECT_TIMEOUT does not seem to have an effect on timeout
ID: 49965
Updated by: j...@php.net
Reported By: ed at bellcpa dot com
-Status: Open
+Status: Assigned
Bug Type: MySQLi related
-Operating System: any
+Operating System: *
PHP Version: 5.*, 6.*
Assigned To: mysql
Previous Comments:
[2009-10-29 18:19:45] u...@php.net
I discussed this with Andrey. We propose to change ext/mysqli to cast
$value passed to mysqli_options to an appropriate type internally. Old
code should not notice the change because it should be using an
appropriate type for $value in mysqli_options($link, $option, $value)
already.
I'll soon patch ext/mysqli.
[2009-10-28 23:58:12] ed at bellcpa dot com
Ah, makes perfect sense. Glad it wasn't something more serious and
sorry for the oversight. Enclosing my option value in intval() solved it
as expected.
Thanks!
[2009-10-28 23:48:10] u...@php.net
Hi Ed,
thanks for the additional information given in a private mail.
Yes, it matters what type the option value has that you pass to
mysqli_options(). It matters ever since 5.0. It is irrelevant if you use
mysqlnd or libmysql.
mysqli_options(mysqli $link, int $option, mixed $value) inspects the
type of the $value parameter. If you pass a string value, as stated in
your private mail, ext/mysqli forwards a string to mysqlnd resp.
libmysql. Both mysqlnd and libmysql expect that the data they get is of
the appropriate type for $option allowing them to use a simple cast to
interpret the data.
String is not the appropriate type for MYSQLI_OPT_CONNECT_TIMEOUT - the
cast inside mysqlnd/libmysql causes a bogus value to be used...
This will not work:
$timeout = "5"
mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, $timeout);
mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, "5");
You must use the following:
$timeout = 5;
mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, $timeout);
mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, 5);
[2009-10-28 17:52:26] u...@php.net
Interesting. I assume it does not matter if you use 5.3.0 or
5.3.2-dev?
Thanks so far!
Ulf
[2009-10-28 17:40:27] ed at bellcpa dot com
Ulf,
Here is the fsockopen() result, looks like timeout works as expected:
C:\temp2>php testme.php
PHP Warning: fsockopen(): unable to connect to
tcp://192.168.201.222:3306 (A co
nnection attempt failed because the connected party did not properly
respond aft
er a period of time, or established connection failed because connected
host has
failed to respond.
) in C:\temp2\testme.php on line 6
PHP Stack trace:
PHP 1. {main}() C:\temp2\testme.php:0
PHP 2. fsockopen() C:\temp2\testme.php:6
Warning: fsockopen(): unable to connect to tcp://192.168.201.222:3306
(A connect
ion attempt failed because the connected party did not properly respond
after a
period of time, or established connection failed because connected host
has fail
ed to respond.
) in C:\temp2\testme.php on line 6
Call Stack:
0.0312 324832 1. {main}() C:\temp2\testme.php:0
0.0491 325280 2. fsockopen() C:\temp2\testme.php:6
bool(false)
int(10060)
string(185) "A connection attempt failed because the connected party
did not pro
perly respond after a period of time, or established connection failed
because c
onnected host has failed to respond.
"
float(5.1100761890411)
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/49965
--
Edit this bug report at http://bugs.php.net/?id=49965&edit=1
#50024 [Opn->Fbk]: basename() chops first character in filename
ID: 50024
Updated by: j...@php.net
Reported By: peo at bsdlabs dot com
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: FreeBSD
PHP Version: 5.2.11
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.
Previous Comments:
[2009-10-27 18:47:21] peo at bsdlabs dot com
Description:
The platform is:
FreeBSD 7.2-STABLE #0: Thu Oct 15 07:23:17 CEST 2009
- Problem not tied to a specific version of OS or PHP
- Vanilla installation of Horde http://www.horde.org
- Identical problem present on two servers
- Problem started to occur spring 2009
- Low server load
- Intermittent
- Comes and goes at certain times during the day. Usually, the problem
will start around 11:30 CEST or 10:30 CET, last for 24h and then go away
for another 24h.
And yes, we have looked for causes for this behaviour
- Happens regardless of cache configuration in Horde, even without any
caching
- Happens regardless of cache and session settings in php.ini
- The below is an *example*
- One more user on the Horde lists have reported same problem with same
OS (FreeBSD)
Reproduce code:
---
function factory($driver, $params = array())
{
if (is_array($driver)) {
$app = $driver[0];
$driver = $driver[1];
}
$driver = basename($driver);
if (empty($driver) || $driver == 'none') {
return new Horde_Cache($params);
}
if (!empty($app)) {
include_once $app . '/lib/Cache/' . $driver . '.php';
} elseif (file_exists(dirname(__FILE__) . '/Cache/' . $driver .
'.php')) {
include_once dirname(__FILE__) . '/Cache/' . $driver .
'.php';
} else {
include_once 'Horde/Cache/' . $driver . '.php';
}
$class = 'Horde_Cache_' . $driver;
if (class_exists($class)) {
$cache = new $class($params);
} else {
$cache = PEAR::raiseError('Class definition of ' . $class .
' not found.');
}
return $cache;
}
Expected result:
Should return memcache.php in this case, but it could be "none.php"
(where the actual output will be "one.php")
Actual result:
--
[21-Oct-2009 07:28:28] after basename d string(8) "memcache"
string(7) "emcache"
[21-Oct-2009 07:28:28] backtrace NULL
string(7) "emcache"
#0 Horde_Cache->factory(memcache, Array ([hostspec] => Array ([0] =>
localhost),[port] => Array ([0] => 11211),[weight] => Array
(),[persistent] => ,[compression] => ,[large_items] => 1,[enabled] =>
1)) called at [/usr/local/www/horde/lib/Horde/Cache.php:234]
#1 Horde_Cache->singleton(memcache, Array ([hostspec] => Array ([0] =>
localhost),[port] => Array ([0] => 11211),[weight] => Array
(),[persistent] => ,[compression] => ,[large_items] => 1,[enabled] =>
1)) called at [/usr/local/www/horde/lib/Horde/Perms/sql.php:57]
#2 Perms_sql->Perms_sql(Array ([username] => horde,[password] =>
,[protocol] => unix,[database] => horde,[charset] =>
iso-8859-1,[splitread] => ,[ssl] => ,[phptype] => mysqli)) called at
[/usr/local/www/horde/lib/Horde/Perms.php:462]
#3 Perms->factory(sql, Array ([username] => horde,[password] =>
,[protocol] => unix,[database] => horde,[charset] =>
iso-8859-1,[splitread] => ,[ssl] => ,[phptype] => mysqli)) called at
[/usr/local/www/horde/lib/Horde/Perms.php:496]
#4 Perms->singleton() called at
[/usr/local/www/horde/lib/Horde/Registry.php:278]
#5 Registry->Registry(0) called at
[/usr/local/www/horde/lib/Horde/Registry.php:139]
#6 Registry::singleton() called at
[/usr/local/www/horde/imp/lib/base.php:49]
#7 require_once(/usr/local/www/horde/imp/lib/base.php) called at
[/usr/local/www/horde/imp/redirect.php:89]
#8 require(/usr/local/www/horde/imp/redirect.php) called at
[/usr/local/www/horde/imp/index.php:26]
NULL
[21-Oct-2009 07:28:28] PHP Warning:
include_once(Horde/Cache/emcache.php) [function.include-once]: failed to open
stream: No such file or directory in
/usr/local/www/horde/lib/Horde/Cache.php on line 194
[21-Oct-2009 07:28:28] PHP Warning: include_once() [function.include]: Failed opening
'Horde/Cache/emcache.php' for inclusion
(include_path='/usr/local/www/horde/lib:.:/usr/local/share/pear') in
/usr/local/www/horde/lib/Horde/Cache.php on line 194
[21-Oct-2009 07:28:39] after basename d string(8) "memcache"
string(7) "emcache"
#50060 [Bgs]: "failed creating formpost data" if post array value starts with '@'
ID: 50060
User updated by: bugs dot php dot net at sgerrand dot com
Reported By: bugs dot php dot net at sgerrand dot com
Status: Bogus
Bug Type: cURL related
Operating System: Linux (Ubuntu x86_64 2.6.31-14)
PHP Version: 5.2.11
New Comment:
Please refer to the documentation for curl_setopt() -
http://php.net/curl_setopt
CURLOPT_POSTFIELDS The full data to post in a HTTP "POST"
operation. To post a file, prepend a filename with @ and use the full
path. This can either be passed as a urlencoded string like
'para1=val1¶2=val2&...' or as an array with the field name as key
and field data as value. If value is an array, the Content-Type header
will be set to multipart/form-data.
The case I have logged is when data to be posted using this option is
an array which happens to have a value that starts with '@', as per
the example. This edge case is being caused by the function used to
create the form data to pass to cURL.
I would note that the cURL command line client on any POSIX system can
perform this without issue - i.e.:
curl -d 'k...@value' http://www.php.net/
Previous Comments:
[2009-11-03 10:18:06] scott...@php.net
@ has a special meaning with cURL and takes the contents of the file.
[2009-11-03 07:29:36] bugs dot php dot net at sgerrand dot com
Description:
PHP's cURL library dies returning the error message "failed creating
formpost data" when trying to use an array that contains a value
starting with '@'.
If the array is changed to a string in URL encoded like format, the
problem does not occur.
Reproduce code:
---
http://www.php.net';
$postData = array('key' => '@value');
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $postData);
if (! curl_exec($ch) ) print 'cURL error: ' . curl_error($ch);
else print "cURL success";
curl_close($ch);
?>
Expected result:
cURL success
Actual result:
--
cURL error: failed creating formpost data
--
Edit this bug report at http://bugs.php.net/?id=50060&edit=1
#50059 [Opn->Bgs]: strototime() incorrectly parses first sunday of Nov 2009
ID: 50059
Updated by: j...@php.net
Reported By: herrnoel at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Linux/Debian 5.0.3
PHP Version: 5.2.11
New Comment:
1. Too old and wrong PHP version. (we only support what we release, not
some badly patched binaries from 3rd party)
2. This is not a bug, strotime() is not an AI which can parse any crap
you pass it. Please ask support on the right forum.
Previous Comments:
[2009-11-03 03:19:01] herrnoel at gmail dot com
Description:
Actual php version is latest from debian stable: PHP 5.2.6-1+lenny3
When using strtotime() for some really handy english parsing, it works
great EXCEPT for the first day of the month.
The format is as follows:
[1-4] [day of week] [month] [year]
If the day of the week is the first day of the month, this will return
the date starting one week ahead of the first day of the month.
Otherwise, the behavior is as expected.
This is repeatable for all months. If you leave out the initial digit,
the broken first day of the month works, but then you must use 1 to
indicate the 2nd instance of that day and so on.
Reproduce code:
---
echo date('Y-m-d', strtotime('1 thu oct 2009')); # first day of month
echo date('Y-m-d', strtotime('1 fri oct 2009')); # second day of month
echo date('Y-m-d', strtotime('1 sun nov 2009')); # first day of month
echo date('Y-m-d', strtotime('2 sun nov 2009')); # second sunday of
month (sunday is the first day of month)
Expected result:
2009-10-01
2009-10-02
2009-11-01
2009-11-08
Actual result:
--
2009-10-08
2009-10-02
2009-11-08
2009-11-15
--
Edit this bug report at http://bugs.php.net/?id=50059&edit=1
#50057 [Opn->Fbk]: crash in _php_pgsql_notice_ptr_dtor -> efree with Horde
ID: 50057
Updated by: j...@php.net
Reported By: proforg at maloletka dot ru
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Debian Lenny 2.6.26-2-amd64
PHP Version: 5.2SVN-2009-11-02 (snap)
New Comment:
Can you reproduce this without the 3rd party patches? (no, we do not
support this FPM thing!)
Previous Comments:
[2009-11-03 02:22:59] proforg at maloletka dot ru
the same for 5.2.10 and 5.2.11
but 5.2.9 works fine
[2009-11-02 23:10:30] proforg at maloletka dot ru
Description:
php5.2-200911021930 + apache2 / fpm sapi frequently crashes on debian
horde3 + imp4 installation.
Reproduce code:
---
Current debian horde and imp packages.
Actual result:
--
fpm log output:
Nov 03 01:51:13.738647 [WARNING] fpm_children_bury(), line 217: child
19892 (pool www-data) exited on signal 11 SIGSEGV (core
dumped) after 2377.432524 seconds from start
Nov 03 01:51:13.738687 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr: "[Tue Nov 3
01:36:48 2009] Script: '/usr/share/horde3//index.php'"
Nov 03 01:51:13.738716 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr:
"/usr/local/src/php5.2-200911021930/ext/pgsql/pgsql.c(289) : Freeing
0x029A97C0 (46 bytes),
script=/usr/share/horde3//index.php", pipe is closed
Nov 03 01:51:13.738738 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr: "[Tue Nov 3
01:36:48 2009] Script: '/usr/share/horde3//index.php'", pipe is
closed
Nov 03 01:51:13.738758 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr:
"/usr/local/src/php5.2-200911021930/ext/pgsql/pgsql.c(361) : Freeing
0x02540370 (16 bytes),
script=/usr/share/horde3//index.php", pipe is closed
Nov 03 01:51:13.738779 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr: "=== Total 2
memory leaks detected ===", pipe is closed
backtrace:
[New process 19892]
#0 0x00734d34 in zend_mm_check_ptr (heap=0x1e392a0,
ptr=0x69766f7270207469, silent=1,
__zend_filename=0x8913f8 "/usr/local/src/php5.2-
200911021930/ext/pgsql/pgsql.c", __zend_lineno=379,
__zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/local/src/php5.2-200911021930/Zend/zend_alloc.c:1304
1304if (p->info._size != ZEND_MM_NEXT_BLOCK(p)-
>info._prev) {
(gdb) bt
#0 0x00734d34 in zend_mm_check_ptr (heap=0x1e392a0,
ptr=0x69766f7270207469, silent=1,
__zend_filename=0x8913f8 "/usr/local/src/php5.2-
200911021930/ext/pgsql/pgsql.c", __zend_lineno=379,
__zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/local/src/php5.2-200911021930/Zend/zend_alloc.c:1304
#1 0x007367da in _zend_mm_free_int (heap=0x1e392a0,
p=0x69766f7270207469, __zend_filename=0x8913f8
"/usr/local/src/php5.2-200911021930/ext/pgsql/pgsql.c",
__zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/local/src/php5.2-
200911021930/Zend/zend_alloc.c:1943
#2 0x00737d76 in _efree (ptr=0x69766f7270207469,
__zend_filename=0x8913f8 "/usr/local/src/php5.2-
200911021930/ext/pgsql/pgsql.c", __zend_lineno=379,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/usr/local/src/php5.2-200911021930/Zend/zend_alloc.c:2311
#3 0x005a7ba0 in _php_pgsql_notice_ptr_dtor (ptr=0x1fe2928)
at /usr/local/src/php5.2-
200911021930/ext/pgsql/pgsql.c:379
#4 0x0076503d in zend_hash_clean (ht=0xb83a88) at
/usr/local/src/php5.2-200911021930/Zend/zend_hash.c:552
#5 0x005a843e in zm_deactivate_pgsql (type=1,
module_number=18) at /usr/local/src/php5.2-
200911021930/ext/pgsql/pgsql.c:578
#6 0x0075f9c5 in module_registry_cleanup (module=0x1e70e80)
at /usr/local/src/php5.2-
200911021930/Zend/zend_API.c:1976
#7 0x007658a5 in zend_hash_reverse_apply (ht=0xb87e60,
apply_func=0x75f98a ) at
/usr/local/src/php5.2-200911021930/Zend/zend_hash.c:755
#8 0x00756f2d in zend_deactivate_modules () at
/usr/local/src/php5.2-200911021930/Zend/zend.c:838
#9 0x006fed04 in php_request_shutdown (dummy=0x0) at
/usr/local/src/php5.2-200911021930/main/main.c:1474
#10 0x007de90f in main (argc=6, argv=0x7fff4f59af58) at
/usr/local/src/php5.2-
200911021930/sapi/fpm/cgi/cgi_main.c:1589
php build options:
--with-fpm --with-libevent=shared,/usr --with-pgsql --with-gd --with-
mhash --with-mcrypt --with-pear=/usr/share/php/ --enable-
debug --with-imap --with-kerberos --with-imap-ssl --with-gettext
same result with apache2 sapi
--
Edit this bug report at http://bugs.php.net/?id=50057&edit=1
#50054 [Opn->Bgs]: magick/semaphore.c Assertion
ID: 50054 Updated by: j...@php.net Reported By: technik at cyberagent dot de -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Debian 5.0.3 Linux version 2.6.2 PHP Version: 5.3.0 New Comment: Wrong place to report bugs in PECL extensions. Try http://pecl.php.net/bugs/ instead. Previous Comments: [2009-11-02 15:00:57] technik at cyberagent dot de Description: goofy:~ # php -m [PHP Modules] Core ctype curl date dom ereg facedetect fileinfo filter ftp gd geoip gettext hash iconv idn imagick imap json libpuzzle libxml lzf magickwand mbstring mcrypt memcache mhash mysql mysqli openssl pcre PDO pdo_sqlite Phar posix Reflection session SimpleXML SPL SQLite sqlite3 standard tidy tokenizer xml xmlreader xmlwriter xsl zip zlib [Zend Modules] php: magick/semaphore.c:288: LockSemaphoreInfo: Assertion `semaphore_info != (SemmaphoreInfo *) ((void *)0)' failed. Aborted goofy:~ # (assertion occures on every php call) Reproduce code: --- none -- Edit this bug report at http://bugs.php.net/?id=50054&edit=1
#50035 [Opn->Fbk]: Crash during shutdown, zm_shutdown_ps_mm
ID: 50035 Updated by: j...@php.net -Summary: Segfault on Exit Reported By: dhertel at gmail dot com -Status: Open +Status: Feedback -Bug Type: Reproducible crash +Bug Type: Session related Operating System: linux 2.6.27 PHP Version: 5.3.1RC2 New Comment: It crashes in mod_mm.c line 256 which is ps_mm_destroy() doing mm_destroy(). See also bug #46434 which is about another MM related crash in session module. I would guess it's either MM which is buggy or we're doing something wrong here. (what libmm version do you have?) Please try also with PHP 5.2.11 (no need for backtrace, just let us know if it crashes also). Previous Comments: [2009-10-29 19:41:35] dhertel at gmail dot com that somehow doesn't surprise me, as this segfault doesn't seem to come from the script... if i got the backtrace right, php segfaults after the script finished - correct me if i'm wrong :) [2009-10-29 19:36:18] sjo...@php.net I could not reproduce the crash with either script. [2009-10-29 15:07:59] dhertel at gmail dot com I'm sorry i couln't provide a shorter script :-(. I can't reproduce the segfault with a simple script. I now stripped everything unnecessary from the script... doesn't need anything external now... Strange thing is that the segfault doesn't occur every time the script ends but sometimes... and the more iterations mmae_core2 runs (line 59), the more often it seems to occur http://pastebin.org/49264 [2009-10-29 14:12:29] dhertel at gmail dot com Description: I'm writing a CLI program with forking and ipc and stuff. It seems to work fine but in the current test the script eventually produces a segfault - every time... but only if i let it run until it's shutting down itself. if i interrupt it, it shuts down without segfaulting php -i says it's version 5.3.1RC3-dev but i also had this problem with 5.3.0 (which unfortunately i can't downgrade to anymore to make a trace there) when using valgrind to check memory the segfault doesn't happen Reproduce code: --- Though I don't believe that it's a problem with my actual code (as there are no execute() lines in the Backtrace), here it is: http://pastebin.org/49244 the PFW_* classes are for handling processes in general, the MMAE_* classes are part of the actual software using PFW_*, where MMAE_Boot stays but Core and Core2 are only for seing if my PFW_* actually works. Expected result: no segfault Actual result: -- segfault so here's the back trace #0 0xb7441570 in ?? () #1 0x080b88d3 in zm_shutdown_ps_mm (type=1, module_number=7) at /usr/src/debug/php-5.3.1_git200910272307/ext/session/mod_mm.c:256 #2 0x080b6fd1 in zm_shutdown_session (type=1, module_number=7) at /usr/src/debug/php-5.3.1_git200910272307/ext/session/session.c:2192 #3 0x081bde7a in module_destructor (module=0x82cd180) at /usr/src/debug/php-5.3.1_git200910272307/Zend/zend_API.c:2098 #4 0x081c4192 in zend_hash_apply_deleter (ht=0x82bbbc0, p=0x82cd150) at /usr/src/debug/php-5.3.1_git200910272307/Zend/zend_hash.c:611 #5 0x081c4457 in zend_hash_graceful_reverse_destroy (ht=0x82bbbc0) at /usr/src/debug/php-5.3.1_git200910272307/Zend/zend_hash.c:646 #6 0x081b85ac in zend_shutdown () at /usr/src/debug/php-5.3.1_git200910272307/Zend/zend.c:759 #7 0x0815d732 in php_module_shutdown () at /usr/src/debug/php-5.3.1_git200910272307/main/main.c:2103 #8 0x0824569c in main (argc=2, argv=0xbff47784) at /usr/src/debug/php-5.3.1_git200910272307/sapi/cli/php_cli.c:1385 -- Edit this bug report at http://bugs.php.net/?id=50035&edit=1
#50033 [Opn->Bgs]: Not finding openssl functions despite being enabled
ID: 50033 Updated by: j...@php.net Reported By: ashley at zware dot co dot uk -Status: Open +Status: Bogus Bug Type: OpenSSL related Operating System: Fedora 11 -PHP Version: 5.2.11 +PHP Version: 5.2.9 New Comment: We do not support 3rd party binary packages. Please report to correct place at fedora. Previous Comments: [2009-10-29 08:13:44] ashley at zware dot co dot uk Description: Although openssl reports itself as being enabled in phpinfo (version OpenSSL 0.9.8k-fips 25 Mar 2009 ), I get Fatal error: Call to undefined function openssl_digest() and similiar for other openssl functions. Actually on PHP 5.2.9 as that is most recent FC11 package. SSL is working in apache with mod_ssl loaded and certificates are in place (self cert - its a dev machine.) Reproduce code: --- $a = openssl_digest($data,$method); Expected result: output from the digest function as per docs. Actual result: -- ( ! ) Fatal error: Call to undefined function openssl_digest() in /var/www/vhosts/zware/application/modules/test/controllers/IndexController.php on line 77 -- Edit this bug report at http://bugs.php.net/?id=50033&edit=1
#50027 [Opn->Fbk]: $this becomes a non-object
ID: 50027 Updated by: j...@php.net Reported By: phpbugs at colin dot guthr dot ie -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Mandriva Linux (Cooker x86_64) PHP Version: 5.3.1RC2 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. Previous Comments: [2009-10-28 09:05:14] phpbugs at colin dot guthr dot ie Description: This is a really hard bug to reproduce (e.g. build a simple test case) but I can reliably do so here with my application. I'll attempt to describe the problem in depth, although I warn in advance that it's a bit of a confusing one. During a particular request, PHP seems to corrupt itself quite badly which cases $this to become corrupted within an object. When this happens, is_object($this) still returns true, but any attempt to access a member variable (e.g. $this->mFuncs) will result in the "Notice: Trying to get property of non-object" warning. Similar warning exist when trying to call methods etc. Once this corruption happens, it will remain until the Apache process is restarted (mpm-prefork) although some requests will succeed (I presume it depends what mpm-preforked httpd handler is used?). When this happens, a much simpler test case (which I'll link to) fails also (i.e. it seems that the initial trigger of this causes it to continue, but the simpler test case itself does not seem enough to trigger it initially). The trigger case I have is a rather complex Zend Framework application that I sadly cannot share. I have confirmed this problem is present on 5.3.0 and 5.3.1RC2, so I suspect it's a 5.3.x problem over all. I cannot reproduce the problem on 5.2.11. All builds use -O0 for optimisations (as higher values have proven to cause problems, particularly on x86_64). Reproduce code: --- A tarball containing three PHP files: one a UniversalAutoloader structure we use in our projects (it predates spl stuff and actually gives us a different fallback mechanism anyway), and a simple test class that is meant to be autoloaded. Then the test.php file which actually exhibits the bug. As noted previously however, this test case only *exhibits* this bug if the problem is triggered already by some other code. You can see from the backtrace.txt the effect of it failing. I provide this in the hope that it allows something obvious to jump out at you, but I suspect the problem is really some form of stack frame corruption or similar (possibly due to x86_64 as I've not tested to see if it affects 5.3.1 although I will be able to do so in the coming weeks). The URL for this bundle is: http://colin.guthr.ie/php-bug.tar Expected result: It should just echo "Foo\n". But as you can see the Notice is triggered and the is_array() check fails (as can be seen, it is impossible for the variable to be anything other than an array). Actual result: -- *After* triggering the problem, $this becomes a non-object (although in other tests (is_object($this) still returns true). -- Edit this bug report at http://bugs.php.net/?id=50027&edit=1
#50061 [NEW]: 5.2.11 doesn't reconize mysql_connect function
From: lunaelipsis at hotmail dot com Operating system: Windows 7 PHP version: 5.2.11 PHP Bug Type: MySQL related Bug description: 5.2.11 doesn't reconize mysql_connect function Description: I encountered the known issue of the "Fatal error: Call to undefined function mysql_connect()" with PHP 5.2.11 runnnig Apache 2.2 on Windows 7 connecting to distant MySQL 5 database. What i did to try to resolve it : Checked that C:\PHP was in windows PATH variable Checked that libmysql.dll was present Checked that php_mysql.dll was present Checked that extension=php_mysql.dll was uncommented Ran cmd.exe -> php -m it shown every module loaded with php including MySQL. Reproduce code: --- Install PHP 5.2.11 on Windows 7 with Apache 2.2 and do the required configurations to use mysql. Expected result: PHP doesn't reconize any mysql_* functions Actual result: -- I reinstalled php 5.2.9.9 and it worked directly. -- Edit bug report at http://bugs.php.net/?id=50061&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50061&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50061&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50061&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50061&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50061&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50061&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50061&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50061&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50061&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50061&r=support Expected behavior: http://bugs.php.net/fix.php?id=50061&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50061&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50061&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50061&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50061&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50061&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50061&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50061&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50061&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50061&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50061&r=mysqlcfg
#50060 [Bgs]: "failed creating formpost data" if post array value starts with '@'
ID: 50060
Updated by: scott...@php.net
Reported By: bugs dot php dot net at sgerrand dot com
Status: Bogus
Bug Type: cURL related
Operating System: Linux (Ubuntu x86_64 2.6.31-14)
PHP Version: 5.2.11
New Comment:
-d is for the whole data, what we really have here is -F for formdata.
curl -F 'k...@value' http://www.php.net/
Previous Comments:
[2009-11-03 10:44:13] bugs dot php dot net at sgerrand dot com
Please refer to the documentation for curl_setopt() -
http://php.net/curl_setopt
CURLOPT_POSTFIELDS The full data to post in a HTTP "POST"
operation. To post a file, prepend a filename with @ and use the full
path. This can either be passed as a urlencoded string like
'para1=val1¶2=val2&...' or as an array with the field name as key
and field data as value. If value is an array, the Content-Type header
will be set to multipart/form-data.
The case I have logged is when data to be posted using this option is
an array which happens to have a value that starts with '@', as per
the example. This edge case is being caused by the function used to
create the form data to pass to cURL.
I would note that the cURL command line client on any POSIX system can
perform this without issue - i.e.:
curl -d 'k...@value' http://www.php.net/
[2009-11-03 10:18:06] scott...@php.net
@ has a special meaning with cURL and takes the contents of the file.
[2009-11-03 07:29:36] bugs dot php dot net at sgerrand dot com
Description:
PHP's cURL library dies returning the error message "failed creating
formpost data" when trying to use an array that contains a value
starting with '@'.
If the array is changed to a string in URL encoded like format, the
problem does not occur.
Reproduce code:
---
http://www.php.net';
$postData = array('key' => '@value');
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $postData);
if (! curl_exec($ch) ) print 'cURL error: ' . curl_error($ch);
else print "cURL success";
curl_close($ch);
?>
Expected result:
cURL success
Actual result:
--
cURL error: failed creating formpost data
--
Edit this bug report at http://bugs.php.net/?id=50060&edit=1
#50057 [Com]: crash in _php_pgsql_notice_ptr_dtor -> efree with Horde
ID: 50057
Comment by: proforg at maloletka dot ru
Reported By: proforg at maloletka dot ru
Status: Feedback
Bug Type: PostgreSQL related
Operating System: Debian Lenny 2.6.26-2-amd64
PHP Version: 5.2SVN-2009-11-02 (snap)
New Comment:
Yes, definitely, same result at least with apache2 sapi.
I'll try to have some more tests and backtraces with clear cgi-fcgi
sapi
later today,
Previous Comments:
[2009-11-03 10:45:38] j...@php.net
Can you reproduce this without the 3rd party patches? (no, we do not
support this FPM thing!)
[2009-11-03 02:22:59] proforg at maloletka dot ru
the same for 5.2.10 and 5.2.11
but 5.2.9 works fine
[2009-11-02 23:10:30] proforg at maloletka dot ru
Description:
php5.2-200911021930 + apache2 / fpm sapi frequently crashes on debian
horde3 + imp4 installation.
Reproduce code:
---
Current debian horde and imp packages.
Actual result:
--
fpm log output:
Nov 03 01:51:13.738647 [WARNING] fpm_children_bury(), line 217: child
19892 (pool www-data) exited on signal 11 SIGSEGV (core
dumped) after 2377.432524 seconds from start
Nov 03 01:51:13.738687 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr: "[Tue Nov 3
01:36:48 2009] Script: '/usr/share/horde3//index.php'"
Nov 03 01:51:13.738716 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr:
"/usr/local/src/php5.2-200911021930/ext/pgsql/pgsql.c(289) : Freeing
0x029A97C0 (46 bytes),
script=/usr/share/horde3//index.php", pipe is closed
Nov 03 01:51:13.738738 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr: "[Tue Nov 3
01:36:48 2009] Script: '/usr/share/horde3//index.php'", pipe is
closed
Nov 03 01:51:13.738758 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr:
"/usr/local/src/php5.2-200911021930/ext/pgsql/pgsql.c(361) : Freeing
0x02540370 (16 bytes),
script=/usr/share/horde3//index.php", pipe is closed
Nov 03 01:51:13.738779 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr: "=== Total 2
memory leaks detected ===", pipe is closed
backtrace:
[New process 19892]
#0 0x00734d34 in zend_mm_check_ptr (heap=0x1e392a0,
ptr=0x69766f7270207469, silent=1,
__zend_filename=0x8913f8 "/usr/local/src/php5.2-
200911021930/ext/pgsql/pgsql.c", __zend_lineno=379,
__zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/local/src/php5.2-200911021930/Zend/zend_alloc.c:1304
1304if (p->info._size != ZEND_MM_NEXT_BLOCK(p)-
>info._prev) {
(gdb) bt
#0 0x00734d34 in zend_mm_check_ptr (heap=0x1e392a0,
ptr=0x69766f7270207469, silent=1,
__zend_filename=0x8913f8 "/usr/local/src/php5.2-
200911021930/ext/pgsql/pgsql.c", __zend_lineno=379,
__zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/local/src/php5.2-200911021930/Zend/zend_alloc.c:1304
#1 0x007367da in _zend_mm_free_int (heap=0x1e392a0,
p=0x69766f7270207469, __zend_filename=0x8913f8
"/usr/local/src/php5.2-200911021930/ext/pgsql/pgsql.c",
__zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/local/src/php5.2-
200911021930/Zend/zend_alloc.c:1943
#2 0x00737d76 in _efree (ptr=0x69766f7270207469,
__zend_filename=0x8913f8 "/usr/local/src/php5.2-
200911021930/ext/pgsql/pgsql.c", __zend_lineno=379,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/usr/local/src/php5.2-200911021930/Zend/zend_alloc.c:2311
#3 0x005a7ba0 in _php_pgsql_notice_ptr_dtor (ptr=0x1fe2928)
at /usr/local/src/php5.2-
200911021930/ext/pgsql/pgsql.c:379
#4 0x0076503d in zend_hash_clean (ht=0xb83a88) at
/usr/local/src/php5.2-200911021930/Zend/zend_hash.c:552
#5 0x005a843e in zm_deactivate_pgsql (type=1,
module_number=18) at /usr/local/src/php5.2-
200911021930/ext/pgsql/pgsql.c:578
#6 0x0075f9c5 in module_registry_cleanup (module=0x1e70e80)
at /usr/local/src/php5.2-
200911021930/Zend/zend_API.c:1976
#7 0x007658a5 in zend_hash_reverse_apply (ht=0xb87e60,
apply_func=0x75f98a ) at
/usr/local/src/php5.2-200911021930/Zend/zend_hash.c:755
#8 0x00756f2d in zend_deactivate_modules () at
/usr/local/src/php5.2-200911021930/Zend/zend.c:838
#9 0x006fed04 in php_request_shutdown (dummy=0x0) at
/usr/local/src/php5.2-200911021930/main/main.c:1474
#10 0x007de90f in main (argc=6, argv=0x7fff4f59af58) at
/usr/local/src/php5.2-
200911021930/sapi/fpm/cgi/cgi_main.c:1589
php build options:
--with-fpm --with-libevent=shared,/usr --with-pgsql --with-gd --with-
mhash --with-mcrypt --with-pear=/usr/share/php/ --enable-
debug --with-imap --with-kerb
#50061 [Opn->Bgs]: 5.2.11 doesn't reconize mysql_connect function
ID: 50061 Updated by: paj...@php.net Reported By: lunaelipsis at hotmail dot com -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: Windows 7 PHP Version: 5.2.11 New Comment: You certainly use two different php for CLI (php -m) and apache. Verify that the php.ini loaded by the apache's php is the same than cli. But there is no bug here, it is a configuration problem. Previous Comments: [2009-11-03 11:18:41] lunaelipsis at hotmail dot com Description: I encountered the known issue of the "Fatal error: Call to undefined function mysql_connect()" with PHP 5.2.11 runnnig Apache 2.2 on Windows 7 connecting to distant MySQL 5 database. What i did to try to resolve it : Checked that C:\PHP was in windows PATH variable Checked that libmysql.dll was present Checked that php_mysql.dll was present Checked that extension=php_mysql.dll was uncommented Ran cmd.exe -> php -m it shown every module loaded with php including MySQL. Reproduce code: --- Install PHP 5.2.11 on Windows 7 with Apache 2.2 and do the required configurations to use mysql. Expected result: PHP doesn't reconize any mysql_* functions Actual result: -- I reinstalled php 5.2.9.9 and it worked directly. -- Edit this bug report at http://bugs.php.net/?id=50061&edit=1
#50021 [Fbk->Opn]: Predefined Statements doesn't allow Strings with more than 256 letters.
ID: 50021
User updated by: novitools dot novi at web dot de
Reported By: novitools dot novi at web dot de
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: Windows Vista
PHP Version: 5.3.0
New Comment:
Here is the result:
Field 1: `You can only read the first 256 words of this text. That
is why I must write such a long text, because I must reach the limit
of
256 words. The same error occours, when you try to select a text
column
from the database. But I didn't had this error before `
Catalog:`def`
Database: ``
Table: ``
Org_table: ``
Type: VAR_STRING
Collation: latin1_swedish_ci (8)
Length: 284
Max_length: 284
Decimals: 31
Flags: NOT_NULL
+---
---+
| You can only read the first 256 words of this text. That
is why I must write such a long text, because I must reach the limit
of
256 words. The same error occours, when you try to select a text
column
from the database. But I didn't had this error before
|
+---
---+
| You can only read the first 256 words of this text. That
is why I must write such a long text, because I must reach the limit
of
256 words. The same error occours, when you try to select a text
column
from the database. But I didn't had this error before in a previous
version of php. |
+---
---+
1 row in set (0.00 sec)
Previous Comments:
[2009-11-03 09:54:50] u...@php.net
Please run you query in the MySQL prompt and show the meta data that is
returned from MySQL. Start the MySQL prompt with "mysql
--column-type-info" followed by your usual "-u", "-p", "-h" etc.
options.
For example:
nixn...@ulflinux:~> /usr/local/mysql/bin/mysql --column-type-info
-uroot -proot
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 13
Server version: 5.1.39-debug Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
mysql> select 1;
Field 1: `1`
Catalog:`def`
Database: ``
Table: ``
Org_table: ``
Type: LONGLONG
Collation: binary (63)
Length: 1
Max_length: 1
Decimals: 0
Flags: NOT_NULL BINARY NUM
+---+
| 1 |
+---+
| 1 |
+---+
1 row in set (0.00 sec)
But, of course, run your failing query and run mysql prompt on your
system.
Thanks,
Ulf
[2009-10-30 15:12:35] novitools dot novi at web dot de
So the problem only occurs on specific versions:
No Problem with this Versions:
client_version 50005
server_version 50132
Big Problem with this Versions:
client_version 50137
server_version 50137
[2009-10-29 17:58:24] friedrich dot mark at freenet dot de
Same Problem here:
$db = new mysqli('localhost', 'root', '', 'test');
$stmt = $db->stmt_init();
$sql = "SELECT `text` FROM `longtext` WHERE `id` = 1";
$stmt->prepare($sql);
$stmt->execute();
$stmt->bind_result($text);
$stmt->fetch();
$stmt->close();
var_dump(phpversion());
var_dump($db->client_version);
var_dump($db->server_version);
var_dump($db->protocol_version);
var_dump($text);
Output:
string(5) "5.3.0"
int(50137)
int(50137)
int(10)
string(256) "Lorem ipsum dolor sit amet, consetetur sadipscing elitr,
sed diam nonumy eirmod tempor invidunt ut labore et dolore magna
aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo
dolores et ea rebum. Stet clita kasd gubergren, no sea takimata "
OS: Win 7
SQL:
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
CREATE DATABASE `test` DEFAULT CHARACTER SET latin1 COLLATE
latin1_swedish_ci;
USE `test`;
CREATE TABLE IF NOT EXISTS `longtext` (
`id` int(11) NOT NULL,
`text` text NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
INSERT INTO `longtext` (`id`, `text`) VALUES
(1, 'Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam
nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat,
sed diam voluptua. At vero eos et accusam et justo duo dolores et ea
rebum. Stet clita kasd gubergren, no sea takimata sanct
#49965 [Asn->Csd]: Setting MYSQLI_OPT_CONNECT_TIMEOUT does not seem to have an effect on timeout
ID: 49965 Updated by: u...@php.net Reported By: ed at bellcpa dot com -Status: Assigned +Status: Closed Bug Type: MySQLi related Operating System: * PHP Version: 5.*, 6.* Assigned To: mysql 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. Previous Comments: [2009-11-03 14:56:04] s...@php.net Automatic comment from SVN on behalf of uw Revision: http://svn.php.net/viewvc/?view=revision&revision=290170 Log: Fix for bug #49965 . Let mysqli_options() try to cast option values to the appropriate type. [2009-10-29 18:19:45] u...@php.net I discussed this with Andrey. We propose to change ext/mysqli to cast $value passed to mysqli_options to an appropriate type internally. Old code should not notice the change because it should be using an appropriate type for $value in mysqli_options($link, $option, $value) already. I'll soon patch ext/mysqli. [2009-10-28 23:58:12] ed at bellcpa dot com Ah, makes perfect sense. Glad it wasn't something more serious and sorry for the oversight. Enclosing my option value in intval() solved it as expected. Thanks! [2009-10-28 23:48:10] u...@php.net Hi Ed, thanks for the additional information given in a private mail. Yes, it matters what type the option value has that you pass to mysqli_options(). It matters ever since 5.0. It is irrelevant if you use mysqlnd or libmysql. mysqli_options(mysqli $link, int $option, mixed $value) inspects the type of the $value parameter. If you pass a string value, as stated in your private mail, ext/mysqli forwards a string to mysqlnd resp. libmysql. Both mysqlnd and libmysql expect that the data they get is of the appropriate type for $option allowing them to use a simple cast to interpret the data. String is not the appropriate type for MYSQLI_OPT_CONNECT_TIMEOUT - the cast inside mysqlnd/libmysql causes a bogus value to be used... This will not work: $timeout = "5" mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, $timeout); mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, "5"); You must use the following: $timeout = 5; mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, $timeout); mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, 5); [2009-10-28 17:52:26] u...@php.net Interesting. I assume it does not matter if you use 5.3.0 or 5.3.2-dev? Thanks so far! Ulf 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/49965 -- Edit this bug report at http://bugs.php.net/?id=49965&edit=1
#50063 [NEW]: safe_mode_include_dir fails
From: christian at elmerot dot se
Operating system: Debian Etch, Lenny
PHP version: 5.3.0
PHP Bug Type: Safe Mode/open_basedir
Bug description: safe_mode_include_dir fails
Description:
Using the following config options ignores the safe_mode_include_dir and
does a uid-check even though the php-file is in the safe_mode_include_dir.
This is likely still present in 5.3.1RC2
safe_mode = On
safe_mode_include_dir = /usr/share/php
include_path = ".:/usr/share/php"
The following code:
To me it appears that PHP 5.3.x now use a different code-path to open
files as the following patch against the function
php_plain_files_stream_opener 5.3.0 solves the issue for us as it appears
there is no safe_mode_include_dir-check although there is a safe_mode
uid-check:
--- main/streams/plain_wrapper.c2009-11-03 15:52:59.414872711 +0100
+++ main/streams/plain_wrapper.c2009-11-03 15:52:59.420045302 +0100
@@ -988,6 +988,10 @@
return NULL;
}
+ if ((php_check_safe_mode_include_dir(path TSRMLS_CC)) == 0) {
+ return php_stream_fopen_rel(path, mode, opened_path, options);
+ }
+
if ((options & ENFORCE_SAFE_MODE) && PG(safe_mode) &&
(!php_checkuid(path, mode, CHECKUID_CHECK_MODE_PARAM)))
return NULL;
Reproduce code:
---
Expected result:
OK
Actual result:
--
Warning: require() [function.require]: SAFE MODE Restriction in effect.
The script whose uid is 771909 is not allowed to access
/usr/share/php/PEAR/Exception.php owned by uid 0 in
/x/peartest.php on line 2
Warning: require(/usr/share/php/PEAR/Exception.php) [function.require]:
failed to open stream: No such file or directory in
/x/peartest.php on line 2
Fatal error: require() [function.require]: Failed opening required
'PEAR/Exception.php' (include_path='.:/usr/share/php') in
/x/peartest.php on line 2
--
Edit bug report at http://bugs.php.net/?id=50063&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50063&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50063&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50063&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50063&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50063&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50063&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50063&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50063&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50063&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50063&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50063&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50063&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50063&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50063&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50063&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50063&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50063&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50063&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50063&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50063&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50063&r=mysqlcfg
#50064 [NEW]: SOAP response by is not encoded
From: ckl at ecw dot de Operating system: Windows XP SP3 PHP version: 5.2.11 PHP Bug Type: SOAP related Bug description: SOAP response by is not encoded Description: I developed a Spring-WS webservice which I try to call by PHP. WSDL file: --- http://schemas.xmlsoap.org/wsdl/"; xmlns:sch="http://www.ecw.de/adg/person/schema/beans"; xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:tns="http://www.ecw.de/adg/person/schema/beans"; targetNamespace="http://www.ecw.de/adg/person/schema/beans";> http://www.w3.org/2001/XMLSchema"; xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"; xmlns="http://www.ecw.de/adg/person/schema/beans"; xmlns:pb="http://www.ecw.de/adg/person/schema/beans"; xmlns:schemas="http://www.ecw.de/adg/person/schema/beans"; xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"; attributeFormDefault="unqualified" elementFormDefault="unqualified" jaxb:extensionBindingPrefixes="xjc" jaxb:version="1.0" targetNamespace="http://www.ecw.de/adg/person/schema/beans"; xmlns:tns="http://www.ecw.de/adg/person/schema/beans";> http://schemas.xmlsoap.org/soap/http"/> http://localhost:8080/ADG/personService"/> --- Response from Spring-WS (fetched by proxying the request/response): --- http://schemas.xmlsoap.org/soap/envelope/";> http://www.ecw.de/adg/person/schema/beans";> http://www.w3.org/2001/XMLSchema-instance"/> http://www.w3.org/2001/XMLSchema-instance"/> http://www.w3.org/2001/XMLSchema-instance"/> desc name CN=Person,CN=Schema,CN=Configuration,DC=dc,DC=com 2 CN=... m...@domain.com display-name top test Some groupname 123 test http://www.w3.org/2001/XMLSchema-instance"/> 129017292450890526 7021 test false \\srv\profiles t...@domain.com http://www.w3.org/2001/XMLSchema-instance"/> --- It seems to be that SOAPClient or the underlying XML library (SimpleXML? - not sure which XML-library is used by SOAPClient) is not able to handle the namespaces in response. Reproduce code: --- true, 'version' => SOAP_1_1, 'exceptions' => true, 'uri' => 'http://www.ecw.de/adg/person/
#50063 [Opn]: safe_mode_include_dir fails
ID: 50063
User updated by: christian at elmerot dot se
Reported By: christian at elmerot dot se
Status: Open
Bug Type: Safe Mode/open_basedir
Operating System: Debian Etch, Lenny
PHP Version: 5.3.0
New Comment:
"Actual output" should be:
Warning: require_once() [function.require-once]: SAFE MODE Restriction
in effect. The script whose uid is 35873 is not allowed to access
/usr/share/php/PEAR/Exception.php owned by uid 0 in //peartest.php
on line 2
Warning: require_once(/usr/share/php/PEAR/Exception.php)
[function.require-once]: failed to open stream: No such file or
directory in //peartest.php on line 2
Fatal error: require_once() [function.require]: Failed opening required
'PEAR/Exception.php' (include_path='.:/usr/share/php') in
//peartest.php on line 2
And of course the file is there: ls -l
/usr/share/php/PEAR/Exception.php
-rw-r--r-- 1 root root 12818 Apr 29 2009
/usr/share/php/PEAR/Exception.php
Previous Comments:
[2009-11-03 16:15:58] christian at elmerot dot se
Description:
Using the following config options ignores the safe_mode_include_dir
and does a uid-check even though the php-file is in the
safe_mode_include_dir. This is likely still present in 5.3.1RC2
safe_mode = On
safe_mode_include_dir = /usr/share/php
include_path = ".:/usr/share/php"
The following code:
To me it appears that PHP 5.3.x now use a different code-path to open
files as the following patch against the function
php_plain_files_stream_opener 5.3.0 solves the issue for us as it
appears there is no safe_mode_include_dir-check although there is a
safe_mode uid-check:
--- main/streams/plain_wrapper.c2009-11-03 15:52:59.414872711 +0100
+++ main/streams/plain_wrapper.c2009-11-03 15:52:59.420045302 +0100
@@ -988,6 +988,10 @@
return NULL;
}
+ if ((php_check_safe_mode_include_dir(path TSRMLS_CC)) == 0) {
+ return php_stream_fopen_rel(path, mode, opened_path, options);
+ }
+
if ((options & ENFORCE_SAFE_MODE) && PG(safe_mode) &&
(!php_checkuid(path, mode, CHECKUID_CHECK_MODE_PARAM)))
return NULL;
Reproduce code:
---
Expected result:
OK
Actual result:
--
Warning: require() [function.require]: SAFE MODE Restriction in effect.
The script whose uid is 771909 is not allowed to access
/usr/share/php/PEAR/Exception.php owned by uid 0 in
/x/peartest.php on line 2
Warning: require(/usr/share/php/PEAR/Exception.php) [function.require]:
failed to open stream: No such file or directory in
/x/peartest.php on line 2
Fatal error: require() [function.require]: Failed opening required
'PEAR/Exception.php' (include_path='.:/usr/share/php') in
/x/peartest.php on line 2
--
Edit this bug report at http://bugs.php.net/?id=50063&edit=1
#41461 [Com]: E_STRICT notice when overriding methods not defined by an Interface in hierarchy
ID: 41461
Comment by: markskilbeck at gmail dot com
Reported By: ralph at smashlabs dot com
Status: Verified
Bug Type: Class/Object related
Operating System: *
PHP Version: 5.*, 6CVS (2009-04-25)
New Comment:
PHP does not allow for method overloading.
Previous Comments:
[2009-07-27 08:02:01] php at whoah dot net
Should this not be possible without errors or notices? I am
overloading an overridden method. If memory serves me, I am able to do
this in other OO languages (Java, .NET/C#).
class BaseClass {
public function TestFunction ($parameter) {
var_dump($parameter);
}
}
class FooClass extends BaseClass {
public function TestFunction () {
parent::TestFunction('This is Foo');
}
}
class BarClass extends BaseClass {
public function TestFunction () {
parent::TestFunction('This is Bar');
}
}
$test = new FooClass();
$test->TestFunction();
$test = new BarClass();
$test->TestFunction();
Instead:
Strict Standards: Declaration of FooClass::TestFunction() should be
compatible with that of BaseClass::TestFunction()
Strict Standards: Declaration of BarClass::TestFunction() should be
compatible with that of BaseClass::TestFunction()
[2008-08-08 19:57:45] s...@php.net
I took a look into it, here's some findings:
1. There's no difference between how arguments are matched with and
without interface. The difference is that with no interface binding
would happen in this case in compile time, so if your error reporting
did not have E_STRICT by default, error_reporting(E_ALL | E_STRICT) is
not executed and so the error is not seen.
2. someFunc($uno, $dos, $tres) is not a good replacement for
someFunc($uno, $dos) even ignoring the by-ref return, since it has extra
required argument. Making it not required should pass the strict check.
3. I think it can be allowed to override function that returns by-val
with function that returns by-ref, but not vice versa.
[2007-06-19 21:52:26] ralph at smashlabs dot com
Marcus,
After re-reading, I didn't think that I was clear in my original bug
report, so I attempted to clarify the matter (2 posts up). I still
think this is a problem and that it hinders the usage of interfaces as
it restricts concrete classes from overriding methods introduced at the
abstract layer, not the interface layer.
If this is still by design, go ahead and close, but I wanted to make
absolutely sure as most people either do not care about E_STRICT, or
haven't run into the problem yet ;)
Thanks again,
Ralph
[2007-05-28 17:53:41] ralph at smashlabs dot com
PS. I did check this with the internals list before I posted.. And I
think you actually confirmed it for me on the list
http://news.php.net/php.internals/29646
Thank you for your time,
-ralph
[2007-05-28 17:42:50] ralph at smashlabs dot com
I am sorry, perhaps I should rephrase (I was rushed when I wrote the
original bug report) and I don't think I was especially clear.
In general, we are speaking strictly of Method Overriding. PHP
currently allows concrete classes to override methods in abstract
classes as demonstrated by this code:
webdevelo...@webdevelopment ~/tmp $ cat test_method_override.php
http://bugs.php.net/41461
--
Edit this bug report at http://bugs.php.net/?id=41461&edit=1
#50066 [NEW]: 1st request after expiration loads session data but not subsequent request
From: phpbug at reider dot net Operating system: debian PHP version: 5.3.1RC2 PHP Bug Type: Session related Bug description: 1st request after expiration loads session data but not subsequent request Description: sessions don't appear to expire when expected. for example: a logon request arrives and the app calls session_start() and stores authentication data in the session. session.gc_maxlifetime+n seconds later, a 2nd request arrives. The authentication data is loaded and the 2nd request is processed as if the session is active. A few seconds later a 3rd request arrives; in the 3rd request all the session data is gone, as if the session only just timed out even though the user requested immediately after the 2nd response. Apparently, php deserializes session data and does gc() (if it is to be done) afterwards; so in the 2nd request, the data is loaded into the session, *then* the files are removed. I expected that the 2nd, not 3rd request would have no session data Wouldn'tm it makeore sense to gc *before* loading the session data? That way, it would be the *2nd* request to perceive a session timeout, instead of the 3rd. Reproduce code: --- I have session.gc_probability=100 and session.gc_divisor=100 to run gc on each request. Expected result: I expected that the 2nd, not 3rd request would have the session data not deserialized. While in practice it will usually be the case that the the gc will occur in a different users process, nevertheless, I suggest that if session_start() does a gc which results in the session data being removed, it should not also load it into the session. -- Edit bug report at http://bugs.php.net/?id=50066&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50066&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50066&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50066&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50066&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50066&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50066&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50066&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50066&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50066&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50066&r=support Expected behavior: http://bugs.php.net/fix.php?id=50066&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50066&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50066&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50066&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50066&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50066&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50066&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50066&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50066&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50066&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50066&r=mysqlcfg
#50065 [Opn->Bgs]: Need a way to force calls to time() to be replaced by $_SERVER['REQUEST_TIME']
ID: 50065
Updated by: johan...@php.net
Reported By: leroutier at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 5.2.11
New Comment:
There are too many cases where different time() calls expect different
results and in your example we'd need to "break" the whole date system
to return fake data. Nothing that can be done in a sane way.
Previous Comments:
[2009-11-03 17:42:13] leroutier at gmail dot com
Description:
Got lazy developers that can't understand that any call to date, time,
strftime and so on without a timestamp as parameter would always mean
extra system calls.
So, they get fun adding shitty code like :
$caching_time = mktime(1,0,0,date("m"),date("d")+1,date("Y"))- time();
Cool, 4 syscalls in one expression.
As I can't make them think about my dear servers (they always say
something like "add more servers"), I'd like a way in PHP configuration
to bypass all calls to time() and timestamp-less calls to be replaced by
$_SERVER['REQUEST_TIME']
I understand the correct solution would be to correct their code but
I'm sure lots of sysadmins would like this.
--
Edit this bug report at http://bugs.php.net/?id=50065&edit=1
#50065 [NEW]: Need a way to force calls to time() to be replaced by $_SERVER['REQUEST_TIME']
From: leroutier at gmail dot com
Operating system: Linux
PHP version: 5.2.11
PHP Bug Type: Feature/Change Request
Bug description: Need a way to force calls to time() to be replaced by
$_SERVER['REQUEST_TIME']
Description:
Got lazy developers that can't understand that any call to date, time,
strftime and so on without a timestamp as parameter would always mean extra
system calls.
So, they get fun adding shitty code like :
$caching_time = mktime(1,0,0,date("m"),date("d")+1,date("Y"))- time();
Cool, 4 syscalls in one expression.
As I can't make them think about my dear servers (they always say
something like "add more servers"), I'd like a way in PHP configuration to
bypass all calls to time() and timestamp-less calls to be replaced by
$_SERVER['REQUEST_TIME']
I understand the correct solution would be to correct their code but I'm
sure lots of sysadmins would like this.
--
Edit bug report at http://bugs.php.net/?id=50065&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50065&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50065&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50065&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50065&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50065&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50065&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50065&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50065&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50065&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50065&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50065&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50065&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50065&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50065&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50065&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50065&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50065&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50065&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50065&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50065&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50065&r=mysqlcfg
#50059 [Bgs]: strototime() incorrectly parses first sunday of Nov 2009
ID: 50059
Updated by: der...@php.net
Reported By: herrnoel at gmail dot com
Status: Bogus
Bug Type: Date/time related
Operating System: Linux/Debian 5.0.3
PHP Version: 5.2.11
New Comment:
No, it is not a wrapper around anything, but it's still not a bug.
There is lots of logic involved here but that belongs in the docs (and
there is already an issue open for that I think).
Previous Comments:
[2009-11-03 23:01:50] herrnoel at gmail dot com
1) OK that's a sort of fair point. I'll see if I can drum up some
access to a compiled install...
2) strtotime() is a wrapper to GNU's date function right?
http://www.gnu.org/software/coreutils/manual/coreutils.html#Day-of-week-items
I believe this is correct syntax.
"A number may precede a day of the week item to move forward
supplementary weeks. It is best used in expression like third monday.
In this context, last day or next day is also acceptable; they move
one week before or after the day that day by itself would represent. "
The ordinal spellings of numbers are just aliases to integers -- I
prefer the terser, numeric format.
[2009-11-03 10:44:49] j...@php.net
1. Too old and wrong PHP version. (we only support what we release, not
some badly patched binaries from 3rd party)
2. This is not a bug, strotime() is not an AI which can parse any crap
you pass it. Please ask support on the right forum.
[2009-11-03 03:19:01] herrnoel at gmail dot com
Description:
Actual php version is latest from debian stable: PHP 5.2.6-1+lenny3
When using strtotime() for some really handy english parsing, it works
great EXCEPT for the first day of the month.
The format is as follows:
[1-4] [day of week] [month] [year]
If the day of the week is the first day of the month, this will return
the date starting one week ahead of the first day of the month.
Otherwise, the behavior is as expected.
This is repeatable for all months. If you leave out the initial digit,
the broken first day of the month works, but then you must use 1 to
indicate the 2nd instance of that day and so on.
Reproduce code:
---
echo date('Y-m-d', strtotime('1 thu oct 2009')); # first day of month
echo date('Y-m-d', strtotime('1 fri oct 2009')); # second day of month
echo date('Y-m-d', strtotime('1 sun nov 2009')); # first day of month
echo date('Y-m-d', strtotime('2 sun nov 2009')); # second sunday of
month (sunday is the first day of month)
Expected result:
2009-10-01
2009-10-02
2009-11-01
2009-11-08
Actual result:
--
2009-10-08
2009-10-02
2009-11-08
2009-11-15
--
Edit this bug report at http://bugs.php.net/?id=50059&edit=1
#48498 [Opn]: COM object instantiation throws 'Invalid Syntax' exception
ID: 48498
Updated by: ksin...@php.net
Reported By: will at flourishlib dot com
Status: Open
Bug Type: COM related
Operating System: Windows XP SP3
PHP Version: 5.2.10RC1
New Comment:
I was able to use CapiCom.Utilities.1 with PHP 5.2.11. Error is
generated when capicom is not registered and class is not available on
the machine.
Previous Comments:
[2009-06-27 00:11:06] paul at mantisforge dot org
This functionality seems to work fine in the 5.3.0 rc builds ( PHP
5.3.0RC5-dev (cli) (built: Jun 27 2009 00:33:01) (DEBUG)).
The following script appears to work for me against most of the
capicom.utilities functions:
getMessage() . "\n";
echo 'exception initialising com object... terminating...';
}
$string = 'foo';
$encoded = $util->Base64Encode($string); /* encoded string is \r\n
terminated */
echo $encoded . ' is base 64 encoded string:' . $util-
>Base64Decode($encoded) . "\n";
echo "\n\n";
$hex = $util->BinaryToHex($string);
echo "BinaryToHex: " . $util->BinaryToHex($string) . "\n";
echo "hextobinary: " . $util->HexToBinary($hex) . "\n";
define( 'CAPICOM_ENCODE_BASE64', 0 );
echo "Random Number: " . $util->GetRandom(10, CAPICOM_ENCODE_BASE64) .
"\n";
$variant = $util->BinaryStringToByteArray($string);
$i = 0;
foreach( $variant as $v) {
echo "Byte(" . $i++ . "): " . $v . "\n";
}
Outputing:
ZgBvAG8A
is base 64 encoded string:foo
BinaryToHex: 66006F006F00
hextobinary: foo
Random Number: PiMSnPtckiHFCQ==
Byte(0): 102
Byte(1): 0
Byte(2): 111
Byte(3): 0
Byte(4): 111
Byte(5): 0
--
1) It might be worth trying a newer version of php
2) it might be worth checking that the com object is registered
correctly by attempting to access it from a vbscript
[2009-06-08 18:05:57] will at flourishlib dot com
Description:
In previous versions of PHP it was possible to create a COM object for
CAPICOM to generate random data. I'm not sure at what version it broke,
but now trying to instantiate the COM object, an exception is thrown
with the message "Failed to create COM object 'CAPICOM.Utilities.1':
Invalid syntax".
This behavior seem to be present on both 5.2.9-2 and 5.2.10RC1.
I've been unable to figure out what this error really means. The ProgID
I'm specifying is valid according to Microsoft -
http://msdn.microsoft.com/en-us/library/aa388176(VS.85).aspx.
Any sort of direction would be useful in trying to solve this issue.
Reproduce code:
---
new COM('CAPICOM.Utilities.1');
Expected result:
A COM object that can be used.
Actual result:
--
An exception with the message:
Failed to create COM object 'CAPICOM.Utilities.1': Invalid syntax
--
Edit this bug report at http://bugs.php.net/?id=48498&edit=1
#50057 [Fbk]: crash in _php_pgsql_notice_ptr_dtor -> efree with Horde
ID: 50057
Updated by: scott...@php.net
Reported By: proforg at maloletka dot ru
Status: Feedback
Bug Type: PostgreSQL related
Operating System: Debian Lenny 2.6.26-2-amd64
PHP Version: 5.2SVN-2009-11-02 (snap)
New Comment:
Can you provide a reproduce script and also would it be possible to run
what you have through valgrind to get a better memory trace.
Previous Comments:
[2009-11-04 00:55:39] proforg at maloletka dot ru
php5.2-200911032130
configure options: --enable-fastcgi --enable-force-cgi-redirect
--with-pgsql --with-pear=/usr/share/php/ --enable-debug --with-imap
--with-
kerberos --with-imap-ssl --with-gettext
run options: /usr/local/bin/php-cgi -b 127.0.0.1:9919 -c
/etc/php5/fpm/
backtrace:
[New process 4752]
#0 0x006fc288 in zend_mm_check_ptr (heap=0xcd8390, ptr=0x1,
silent=1, __zend_filename=0x830c38 "/usr/local/src/php5.2-
200911032130/ext/pgsql/pgsql.c",
__zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/local/src/php5.2-200911032130/Zend/zend_alloc.c:1304
1304if (p->info._size != ZEND_MM_NEXT_BLOCK(p)->info._prev)
{
(gdb) bt
#0 0x006fc288 in zend_mm_check_ptr (heap=0xcd8390, ptr=0x1,
silent=1, __zend_filename=0x830c38 "/usr/local/src/php5.2-
200911032130/ext/pgsql/pgsql.c",
__zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/local/src/php5.2-200911032130/Zend/zend_alloc.c:1304
#1 0x006fdd2e in _zend_mm_free_int (heap=0xcd8390, p=0x1,
__zend_filename=0x830c38 "/usr/local/src/php5.2-
200911032130/ext/pgsql/pgsql.c", __zend_lineno=379,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/usr/local/src/php5.2-200911032130/Zend/zend_alloc.c:1943
#2 0x006ff2ca in _efree (ptr=0x1, __zend_filename=0x830c38
"/usr/local/src/php5.2-200911032130/ext/pgsql/pgsql.c",
__zend_lineno=379,
__zend_orig_filename=0x0,
__zend_orig_lineno=0) at
/usr/local/src/php5.2-200911032130/Zend/zend_alloc.c:2311
#3 0x0056e2f0 in _php_pgsql_notice_ptr_dtor (ptr=0x134b848) at
/usr/local/src/php5.2-200911032130/ext/pgsql/pgsql.c:379
#4 0x0072c591 in zend_hash_clean (ht=0xb12388) at
/usr/local/src/php5.2-200911032130/Zend/zend_hash.c:552
#5 0x0056eb8e in zm_deactivate_pgsql (type=1,
module_number=14) at
/usr/local/src/php5.2-200911032130/ext/pgsql/pgsql.c:578
#6 0x00726f19 in module_registry_cleanup (module=0xd041d0) at
/usr/local/src/php5.2-200911032130/Zend/zend_API.c:1976
#7 0x0072cdf9 in zend_hash_reverse_apply (ht=0xb16760,
apply_func=0x726ede ) at
/usr/local/src/php5.2-
200911032130/Zend/zend_hash.c:755
#8 0x0071e481 in zend_deactivate_modules () at
/usr/local/src/php5.2-200911032130/Zend/zend.c:838
#9 0x006c6258 in php_request_shutdown (dummy=0x0) at
/usr/local/src/php5.2-200911032130/main/main.c:1474
#10 0x007a6ce5 in main (argc=5, argv=0x7fff3f4b5eb8) at
/usr/local/src/php5.2-200911032130/sapi/cgi/cgi_main.c:2057
[2009-11-03 12:33:45] proforg at maloletka dot ru
Yes, definitely, same result at least with apache2 sapi.
I'll try to have some more tests and backtraces with clear cgi-fcgi
sapi
later today,
[2009-11-03 10:45:38] j...@php.net
Can you reproduce this without the 3rd party patches? (no, we do not
support this FPM thing!)
[2009-11-03 02:22:59] proforg at maloletka dot ru
the same for 5.2.10 and 5.2.11
but 5.2.9 works fine
[2009-11-02 23:10:30] proforg at maloletka dot ru
Description:
php5.2-200911021930 + apache2 / fpm sapi frequently crashes on debian
horde3 + imp4 installation.
Reproduce code:
---
Current debian horde and imp packages.
Actual result:
--
fpm log output:
Nov 03 01:51:13.738647 [WARNING] fpm_children_bury(), line 217: child
19892 (pool www-data) exited on signal 11 SIGSEGV (core
dumped) after 2377.432524 seconds from start
Nov 03 01:51:13.738687 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr: "[Tue Nov 3
01:36:48 2009] Script: '/usr/share/horde3//index.php'"
Nov 03 01:51:13.738716 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr:
"/usr/local/src/php5.2-200911021930/ext/pgsql/pgsql.c(289) : Freeing
0x029A97C0 (46 bytes),
script=/usr/share/horde3//index.php", pipe is closed
Nov 03 01:51:13.738738 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr: "[Tue Nov 3
01:36:48 2009] Script: '/usr/share/horde3//index.php'", pipe is
closed
Nov 03 01:51:13.738758 [WARNING] fpm_stdio_child_said(), line 167:
child 19892
#50066 [Bgs]: 1st request after expiration loads session data but not subsequent request
ID: 50066 User updated by: phpbug at reider dot net Reported By: phpbug at reider dot net Status: Bogus Bug Type: Session related Operating System: debian PHP Version: 5.3.1RC2 New Comment: Johannes, Thanks for the update. It is true that it will be infrequent in practice because as you say users will clean each others sessions, but I would like to apply this very argument in favor of changing it - the latency problem will in practice not present itself in higher traffic scenarios. Meanwhile it does make a difference in low volume scenarios (of which development is a primary case). What we have now is that sessions appears active on a request made after a long idle period, but then appears inactive on the request immediately following. It is really unexpected and feels 'backwards'. I suggest that the latency (given the above premise that this only affects the low traffic scnario) is in fact the lesser evil, and changing it would make for more consistent behavior - it would work the same irrespective of random state changes occurring on the machine that are not really part of the user transaction. Previous Comments: [2009-11-03 19:47:39] johan...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Removing the data before handling the request increases the latency till the user gets a response (as the session files are being deleted) and as you said there should be no practical effect with this as usually you have more than one user so they\'ll clean each others sessions. [2009-11-03 18:07:03] phpbug at reider dot net Description: sessions don't appear to expire when expected. for example: a logon request arrives and the app calls session_start() and stores authentication data in the session. session.gc_maxlifetime+n seconds later, a 2nd request arrives. The authentication data is loaded and the 2nd request is processed as if the session is active. A few seconds later a 3rd request arrives; in the 3rd request all the session data is gone, as if the session only just timed out even though the user requested immediately after the 2nd response. Apparently, php deserializes session data and does gc() (if it is to be done) afterwards; so in the 2nd request, the data is loaded into the session, *then* the files are removed. I expected that the 2nd, not 3rd request would have no session data Wouldn'tm it makeore sense to gc *before* loading the session data? That way, it would be the *2nd* request to perceive a session timeout, instead of the 3rd. Reproduce code: --- I have session.gc_probability=100 and session.gc_divisor=100 to run gc on each request. Expected result: I expected that the 2nd, not 3rd request would have the session data not deserialized. While in practice it will usually be the case that the the gc will occur in a different users process, nevertheless, I suggest that if session_start() does a gc which results in the session data being removed, it should not also load it into the session. -- Edit this bug report at http://bugs.php.net/?id=50066&edit=1
#50059 [Bgs]: strototime() incorrectly parses first sunday of Nov 2009
ID: 50059
User updated by: herrnoel at gmail dot com
Reported By: herrnoel at gmail dot com
Status: Bogus
Bug Type: Date/time related
Operating System: Linux/Debian 5.0.3
PHP Version: 5.2.11
New Comment:
OK thanks for the clarification. Yes the docs could be improved for
this particular function on php.net.
Interestingly enough, I found a syntax that seems to work:
strtotime('+0 week sun nov 2009');
strtotime('+1 week sun nov 2009');
strtotime('-1 week sun nov 2009');
etc.
This seems to yield valid timestamps and gives me an easy integer based
interval incrementer.
I'm parsing ical RRULE sets. Believe me I'm grateful for this
function's existence.
Previous Comments:
[2009-11-03 23:52:45] der...@php.net
No, it is not a wrapper around anything, but it's still not a bug.
There is lots of logic involved here but that belongs in the docs (and
there is already an issue open for that I think).
[2009-11-03 23:01:50] herrnoel at gmail dot com
1) OK that's a sort of fair point. I'll see if I can drum up some
access to a compiled install...
2) strtotime() is a wrapper to GNU's date function right?
http://www.gnu.org/software/coreutils/manual/coreutils.html#Day-of-week-items
I believe this is correct syntax.
"A number may precede a day of the week item to move forward
supplementary weeks. It is best used in expression like third monday.
In this context, last day or next day is also acceptable; they move
one week before or after the day that day by itself would represent. "
The ordinal spellings of numbers are just aliases to integers -- I
prefer the terser, numeric format.
[2009-11-03 10:44:49] j...@php.net
1. Too old and wrong PHP version. (we only support what we release, not
some badly patched binaries from 3rd party)
2. This is not a bug, strotime() is not an AI which can parse any crap
you pass it. Please ask support on the right forum.
[2009-11-03 03:19:01] herrnoel at gmail dot com
Description:
Actual php version is latest from debian stable: PHP 5.2.6-1+lenny3
When using strtotime() for some really handy english parsing, it works
great EXCEPT for the first day of the month.
The format is as follows:
[1-4] [day of week] [month] [year]
If the day of the week is the first day of the month, this will return
the date starting one week ahead of the first day of the month.
Otherwise, the behavior is as expected.
This is repeatable for all months. If you leave out the initial digit,
the broken first day of the month works, but then you must use 1 to
indicate the 2nd instance of that day and so on.
Reproduce code:
---
echo date('Y-m-d', strtotime('1 thu oct 2009')); # first day of month
echo date('Y-m-d', strtotime('1 fri oct 2009')); # second day of month
echo date('Y-m-d', strtotime('1 sun nov 2009')); # first day of month
echo date('Y-m-d', strtotime('2 sun nov 2009')); # second sunday of
month (sunday is the first day of month)
Expected result:
2009-10-01
2009-10-02
2009-11-01
2009-11-08
Actual result:
--
2009-10-08
2009-10-02
2009-11-08
2009-11-15
--
Edit this bug report at http://bugs.php.net/?id=50059&edit=1
#50057 [Com]: crash in _php_pgsql_notice_ptr_dtor -> efree with Horde
ID: 50057
Comment by: proforg at maloletka dot ru
Reported By: proforg at maloletka dot ru
Status: Feedback
Bug Type: PostgreSQL related
Operating System: Debian Lenny 2.6.26-2-amd64
PHP Version: 5.2SVN-2009-11-02 (snap)
New Comment:
php5.2-200911032130
configure options: --enable-fastcgi --enable-force-cgi-redirect
--with-pgsql --with-pear=/usr/share/php/ --enable-debug --with-imap
--with-
kerberos --with-imap-ssl --with-gettext
run options: /usr/local/bin/php-cgi -b 127.0.0.1:9919 -c
/etc/php5/fpm/
backtrace:
[New process 4752]
#0 0x006fc288 in zend_mm_check_ptr (heap=0xcd8390, ptr=0x1,
silent=1, __zend_filename=0x830c38 "/usr/local/src/php5.2-
200911032130/ext/pgsql/pgsql.c",
__zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/local/src/php5.2-200911032130/Zend/zend_alloc.c:1304
1304if (p->info._size != ZEND_MM_NEXT_BLOCK(p)->info._prev)
{
(gdb) bt
#0 0x006fc288 in zend_mm_check_ptr (heap=0xcd8390, ptr=0x1,
silent=1, __zend_filename=0x830c38 "/usr/local/src/php5.2-
200911032130/ext/pgsql/pgsql.c",
__zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/local/src/php5.2-200911032130/Zend/zend_alloc.c:1304
#1 0x006fdd2e in _zend_mm_free_int (heap=0xcd8390, p=0x1,
__zend_filename=0x830c38 "/usr/local/src/php5.2-
200911032130/ext/pgsql/pgsql.c", __zend_lineno=379,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/usr/local/src/php5.2-200911032130/Zend/zend_alloc.c:1943
#2 0x006ff2ca in _efree (ptr=0x1, __zend_filename=0x830c38
"/usr/local/src/php5.2-200911032130/ext/pgsql/pgsql.c",
__zend_lineno=379,
__zend_orig_filename=0x0,
__zend_orig_lineno=0) at
/usr/local/src/php5.2-200911032130/Zend/zend_alloc.c:2311
#3 0x0056e2f0 in _php_pgsql_notice_ptr_dtor (ptr=0x134b848) at
/usr/local/src/php5.2-200911032130/ext/pgsql/pgsql.c:379
#4 0x0072c591 in zend_hash_clean (ht=0xb12388) at
/usr/local/src/php5.2-200911032130/Zend/zend_hash.c:552
#5 0x0056eb8e in zm_deactivate_pgsql (type=1,
module_number=14) at
/usr/local/src/php5.2-200911032130/ext/pgsql/pgsql.c:578
#6 0x00726f19 in module_registry_cleanup (module=0xd041d0) at
/usr/local/src/php5.2-200911032130/Zend/zend_API.c:1976
#7 0x0072cdf9 in zend_hash_reverse_apply (ht=0xb16760,
apply_func=0x726ede ) at
/usr/local/src/php5.2-
200911032130/Zend/zend_hash.c:755
#8 0x0071e481 in zend_deactivate_modules () at
/usr/local/src/php5.2-200911032130/Zend/zend.c:838
#9 0x006c6258 in php_request_shutdown (dummy=0x0) at
/usr/local/src/php5.2-200911032130/main/main.c:1474
#10 0x007a6ce5 in main (argc=5, argv=0x7fff3f4b5eb8) at
/usr/local/src/php5.2-200911032130/sapi/cgi/cgi_main.c:2057
Previous Comments:
[2009-11-03 12:33:45] proforg at maloletka dot ru
Yes, definitely, same result at least with apache2 sapi.
I'll try to have some more tests and backtraces with clear cgi-fcgi
sapi
later today,
[2009-11-03 10:45:38] j...@php.net
Can you reproduce this without the 3rd party patches? (no, we do not
support this FPM thing!)
[2009-11-03 02:22:59] proforg at maloletka dot ru
the same for 5.2.10 and 5.2.11
but 5.2.9 works fine
[2009-11-02 23:10:30] proforg at maloletka dot ru
Description:
php5.2-200911021930 + apache2 / fpm sapi frequently crashes on debian
horde3 + imp4 installation.
Reproduce code:
---
Current debian horde and imp packages.
Actual result:
--
fpm log output:
Nov 03 01:51:13.738647 [WARNING] fpm_children_bury(), line 217: child
19892 (pool www-data) exited on signal 11 SIGSEGV (core
dumped) after 2377.432524 seconds from start
Nov 03 01:51:13.738687 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr: "[Tue Nov 3
01:36:48 2009] Script: '/usr/share/horde3//index.php'"
Nov 03 01:51:13.738716 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr:
"/usr/local/src/php5.2-200911021930/ext/pgsql/pgsql.c(289) : Freeing
0x029A97C0 (46 bytes),
script=/usr/share/horde3//index.php", pipe is closed
Nov 03 01:51:13.738738 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr: "[Tue Nov 3
01:36:48 2009] Script: '/usr/share/horde3//index.php'", pipe is
closed
Nov 03 01:51:13.738758 [WARNING] fpm_stdio_child_said(), line 167:
child 19892 (pool www-data) said into stderr:
"/usr/local/src/php5.2-200911021930/ext/pgsql/pgsql.c(361) : Freeing
0x02540370 (16 bytes),
script=/usr/share/horde3//index.php", pipe is closed
Nov 03 01:51:13.738779 [WARNING] fpm_stdio_child_said(), line 167
#50059 [Bgs]: strototime() incorrectly parses first sunday of Nov 2009
ID: 50059
User updated by: herrnoel at gmail dot com
Reported By: herrnoel at gmail dot com
Status: Bogus
Bug Type: Date/time related
Operating System: Linux/Debian 5.0.3
PHP Version: 5.2.11
New Comment:
1) OK that's a sort of fair point. I'll see if I can drum up some
access to a compiled install...
2) strtotime() is a wrapper to GNU's date function right?
http://www.gnu.org/software/coreutils/manual/coreutils.html#Day-of-week-items
I believe this is correct syntax.
"A number may precede a day of the week item to move forward
supplementary weeks. It is best used in expression like third monday.
In this context, last day or next day is also acceptable; they move
one week before or after the day that day by itself would represent. "
The ordinal spellings of numbers are just aliases to integers -- I
prefer the terser, numeric format.
Previous Comments:
[2009-11-03 10:44:49] j...@php.net
1. Too old and wrong PHP version. (we only support what we release, not
some badly patched binaries from 3rd party)
2. This is not a bug, strotime() is not an AI which can parse any crap
you pass it. Please ask support on the right forum.
[2009-11-03 03:19:01] herrnoel at gmail dot com
Description:
Actual php version is latest from debian stable: PHP 5.2.6-1+lenny3
When using strtotime() for some really handy english parsing, it works
great EXCEPT for the first day of the month.
The format is as follows:
[1-4] [day of week] [month] [year]
If the day of the week is the first day of the month, this will return
the date starting one week ahead of the first day of the month.
Otherwise, the behavior is as expected.
This is repeatable for all months. If you leave out the initial digit,
the broken first day of the month works, but then you must use 1 to
indicate the 2nd instance of that day and so on.
Reproduce code:
---
echo date('Y-m-d', strtotime('1 thu oct 2009')); # first day of month
echo date('Y-m-d', strtotime('1 fri oct 2009')); # second day of month
echo date('Y-m-d', strtotime('1 sun nov 2009')); # first day of month
echo date('Y-m-d', strtotime('2 sun nov 2009')); # second sunday of
month (sunday is the first day of month)
Expected result:
2009-10-01
2009-10-02
2009-11-01
2009-11-08
Actual result:
--
2009-10-08
2009-10-02
2009-11-08
2009-11-15
--
Edit this bug report at http://bugs.php.net/?id=50059&edit=1
#50066 [Opn->Bgs]: 1st request after expiration loads session data but not subsequent request
ID: 50066 Updated by: johan...@php.net Reported By: phpbug at reider dot net -Status: Open +Status: Bogus Bug Type: Session related Operating System: debian PHP Version: 5.3.1RC2 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Removing the data before handling the request increases the latency till the user gets a response (as the session files are being deleted) and as you said there should be no practical effect with this as usually you have more than one user so they'll clean each others sessions. Previous Comments: [2009-11-03 18:07:03] phpbug at reider dot net Description: sessions don't appear to expire when expected. for example: a logon request arrives and the app calls session_start() and stores authentication data in the session. session.gc_maxlifetime+n seconds later, a 2nd request arrives. The authentication data is loaded and the 2nd request is processed as if the session is active. A few seconds later a 3rd request arrives; in the 3rd request all the session data is gone, as if the session only just timed out even though the user requested immediately after the 2nd response. Apparently, php deserializes session data and does gc() (if it is to be done) afterwards; so in the 2nd request, the data is loaded into the session, *then* the files are removed. I expected that the 2nd, not 3rd request would have no session data Wouldn'tm it makeore sense to gc *before* loading the session data? That way, it would be the *2nd* request to perceive a session timeout, instead of the 3rd. Reproduce code: --- I have session.gc_probability=100 and session.gc_divisor=100 to run gc on each request. Expected result: I expected that the 2nd, not 3rd request would have the session data not deserialized. While in practice it will usually be the case that the the gc will occur in a different users process, nevertheless, I suggest that if session_start() does a gc which results in the session data being removed, it should not also load it into the session. -- Edit this bug report at http://bugs.php.net/?id=50066&edit=1
#50057 [Com]: crash in _php_pgsql_notice_ptr_dtor -> efree with Horde
ID: 50057
Comment by: proforg at maloletka dot ru
Reported By: proforg at maloletka dot ru
Status: Feedback
Bug Type: PostgreSQL related
Operating System: Debian Lenny 2.6.26-2-amd64
PHP Version: 5.2SVN-2009-11-02 (snap)
New Comment:
Unfortunately, at the moment, I'm not able to figure out exact part of
the code which causes this segfault. Horde code is quite large and not
very clear. I'll try to simplify it as much as posible and send you
test
case ASAP, but I can't even estimate how much time may it take.
Moreover, this error occures not every request, sometimes only on each
second, or third request.
Requested valgrind output: http://maloletka.ru/valgrind.out.gz
Previous Comments:
[2009-11-04 01:42:09] scott...@php.net
Can you provide a reproduce script and also would it be possible to run
what you have through valgrind to get a better memory trace.
[2009-11-04 00:55:39] proforg at maloletka dot ru
php5.2-200911032130
configure options: --enable-fastcgi --enable-force-cgi-redirect
--with-pgsql --with-pear=/usr/share/php/ --enable-debug --with-imap
--with-
kerberos --with-imap-ssl --with-gettext
run options: /usr/local/bin/php-cgi -b 127.0.0.1:9919 -c
/etc/php5/fpm/
backtrace:
[New process 4752]
#0 0x006fc288 in zend_mm_check_ptr (heap=0xcd8390, ptr=0x1,
silent=1, __zend_filename=0x830c38 "/usr/local/src/php5.2-
200911032130/ext/pgsql/pgsql.c",
__zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/local/src/php5.2-200911032130/Zend/zend_alloc.c:1304
1304if (p->info._size != ZEND_MM_NEXT_BLOCK(p)->info._prev)
{
(gdb) bt
#0 0x006fc288 in zend_mm_check_ptr (heap=0xcd8390, ptr=0x1,
silent=1, __zend_filename=0x830c38 "/usr/local/src/php5.2-
200911032130/ext/pgsql/pgsql.c",
__zend_lineno=379, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/local/src/php5.2-200911032130/Zend/zend_alloc.c:1304
#1 0x006fdd2e in _zend_mm_free_int (heap=0xcd8390, p=0x1,
__zend_filename=0x830c38 "/usr/local/src/php5.2-
200911032130/ext/pgsql/pgsql.c", __zend_lineno=379,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/usr/local/src/php5.2-200911032130/Zend/zend_alloc.c:1943
#2 0x006ff2ca in _efree (ptr=0x1, __zend_filename=0x830c38
"/usr/local/src/php5.2-200911032130/ext/pgsql/pgsql.c",
__zend_lineno=379,
__zend_orig_filename=0x0,
__zend_orig_lineno=0) at
/usr/local/src/php5.2-200911032130/Zend/zend_alloc.c:2311
#3 0x0056e2f0 in _php_pgsql_notice_ptr_dtor (ptr=0x134b848) at
/usr/local/src/php5.2-200911032130/ext/pgsql/pgsql.c:379
#4 0x0072c591 in zend_hash_clean (ht=0xb12388) at
/usr/local/src/php5.2-200911032130/Zend/zend_hash.c:552
#5 0x0056eb8e in zm_deactivate_pgsql (type=1,
module_number=14) at
/usr/local/src/php5.2-200911032130/ext/pgsql/pgsql.c:578
#6 0x00726f19 in module_registry_cleanup (module=0xd041d0) at
/usr/local/src/php5.2-200911032130/Zend/zend_API.c:1976
#7 0x0072cdf9 in zend_hash_reverse_apply (ht=0xb16760,
apply_func=0x726ede ) at
/usr/local/src/php5.2-
200911032130/Zend/zend_hash.c:755
#8 0x0071e481 in zend_deactivate_modules () at
/usr/local/src/php5.2-200911032130/Zend/zend.c:838
#9 0x006c6258 in php_request_shutdown (dummy=0x0) at
/usr/local/src/php5.2-200911032130/main/main.c:1474
#10 0x007a6ce5 in main (argc=5, argv=0x7fff3f4b5eb8) at
/usr/local/src/php5.2-200911032130/sapi/cgi/cgi_main.c:2057
[2009-11-03 12:33:45] proforg at maloletka dot ru
Yes, definitely, same result at least with apache2 sapi.
I'll try to have some more tests and backtraces with clear cgi-fcgi
sapi
later today,
[2009-11-03 10:45:38] j...@php.net
Can you reproduce this without the 3rd party patches? (no, we do not
support this FPM thing!)
[2009-11-03 02:22:59] proforg at maloletka dot ru
the same for 5.2.10 and 5.2.11
but 5.2.9 works fine
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/50057
--
Edit this bug report at http://bugs.php.net/?id=50057&edit=1
#50068 [Opn]: const problem
ID: 50068 Updated by: ksin...@php.net Reported By: jachym dot tousek at gmail dot com Status: Open Bug Type: Scripting Engine problem Operating System: Windows 7 PHP Version: 5.3.1RC3 New Comment: I think this behavior is by design. const expressions are evaluated at compile time. So only few operations are supported in a const expression and string concatenation is not one of those. I could repro this in PHP 5.2 (after putting it under a class). Previous Comments: [2009-11-03 20:16:44] jachym dot tousek at gmail dot com Description: const is not working Reproduce code: --- http://bugs.php.net/?id=50068&edit=1
#50068 [Bgs]: const problem
ID: 50068
Updated by: scott...@php.net
Reported By: jachym dot tousek at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows 7
PHP Version: 5.3.1RC3
New Comment:
const is a compile time constant and only allows simple scalar values.
define is a constant resolved at runtime and it allows full expressions
when being defined.
Previous Comments:
[2009-11-03 22:26:15] jachym dot tousek at gmail dot com
Well i've checked
[http://www.php.net/manual/en/language.constants.syntax.php] and also
updated from 5.3.0 to 5.3.1RC3 before sending this report, but there is
nothing about const name = 'value'; being different from
define('name','value'); and i can not understand it even now.
[2009-11-03 21:46:58] fel...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
[2009-11-03 21:11:32] ksin...@php.net
I think this behavior is by design. const expressions are evaluated at
compile time. So only few operations are supported in a const expression
and string concatenation is not one of those. I could repro this in PHP
5.2 (after putting it under a class).
[2009-11-03 20:16:44] jachym dot tousek at gmail dot com
Description:
const is not working
Reproduce code:
---
http://bugs.php.net/?id=50068&edit=1
#50071 [NEW]: Not honored: display_errors = stderr
From: rank1seeker at gmail dot com Operating system: FreeBSD 7.2 PHP version: 5.3SVN-2009-11-03 (snap) PHP Bug Type: *Configuration Issues Bug description: Not honored: display_errors = stderr Description: display_errors = stderr, acts like display_errors = On Reproduce code: --- In php.ini: display_errors = stderr Expected result: Errors displayed to STDERR Actual result: -- Errors displayed to STDOUT (visible in browser) Some page[phpinfo();] parsed by fcgi Result(part): display_errors On(Local Value) On(Master Value) -- Edit bug report at http://bugs.php.net/?id=50071&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50071&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50071&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50071&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50071&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50071&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50071&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50071&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50071&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50071&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50071&r=support Expected behavior: http://bugs.php.net/fix.php?id=50071&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50071&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50071&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50071&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50071&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50071&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50071&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50071&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50071&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50071&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50071&r=mysqlcfg
#50068 [Bgs]: const problem
ID: 50068
User updated by: jachym dot tousek at gmail dot com
Reported By: jachym dot tousek at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows 7
PHP Version: 5.3.1RC3
New Comment:
Well i've checked
[http://www.php.net/manual/en/language.constants.syntax.php] and also
updated from 5.3.0 to 5.3.1RC3 before sending this report, but there is
nothing about const name = 'value'; being different from
define('name','value'); and i can not understand it even now.
Previous Comments:
[2009-11-03 21:46:58] fel...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
[2009-11-03 21:11:32] ksin...@php.net
I think this behavior is by design. const expressions are evaluated at
compile time. So only few operations are supported in a const expression
and string concatenation is not one of those. I could repro this in PHP
5.2 (after putting it under a class).
[2009-11-03 20:16:44] jachym dot tousek at gmail dot com
Description:
const is not working
Reproduce code:
---
http://bugs.php.net/?id=50068&edit=1
#50060 [Bgs]: "failed creating formpost data" if post array value starts with '@'
ID: 50060
User updated by: bugs dot php dot net at sgerrand dot com
Reported By: bugs dot php dot net at sgerrand dot com
Status: Bogus
Bug Type: cURL related
Operating System: Linux (Ubuntu x86_64 2.6.31-14)
PHP Version: 5.2.11
New Comment:
Regardless, if the existing functionality for constructing form data
with the CURLOPT_POSTFIELDS option will not be changed, can the
documentation for curl_setopt() be altered to more explicitly indicate
that *any* array value that starts with '@' will be treated as a file
for upload.
Previous Comments:
[2009-11-03 11:58:30] scott...@php.net
-d is for the whole data, what we really have here is -F for formdata.
curl -F 'k...@value' http://www.php.net/
[2009-11-03 10:44:13] bugs dot php dot net at sgerrand dot com
Please refer to the documentation for curl_setopt() -
http://php.net/curl_setopt
CURLOPT_POSTFIELDS The full data to post in a HTTP "POST"
operation. To post a file, prepend a filename with @ and use the full
path. This can either be passed as a urlencoded string like
'para1=val1¶2=val2&...' or as an array with the field name as key
and field data as value. If value is an array, the Content-Type header
will be set to multipart/form-data.
The case I have logged is when data to be posted using this option is
an array which happens to have a value that starts with '@', as per
the example. This edge case is being caused by the function used to
create the form data to pass to cURL.
I would note that the cURL command line client on any POSIX system can
perform this without issue - i.e.:
curl -d 'k...@value' http://www.php.net/
[2009-11-03 10:18:06] scott...@php.net
@ has a special meaning with cURL and takes the contents of the file.
[2009-11-03 07:29:36] bugs dot php dot net at sgerrand dot com
Description:
PHP's cURL library dies returning the error message "failed creating
formpost data" when trying to use an array that contains a value
starting with '@'.
If the array is changed to a string in URL encoded like format, the
problem does not occur.
Reproduce code:
---
http://www.php.net';
$postData = array('key' => '@value');
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $postData);
if (! curl_exec($ch) ) print 'cURL error: ' . curl_error($ch);
else print "cURL success";
curl_close($ch);
?>
Expected result:
cURL success
Actual result:
--
cURL error: failed creating formpost data
--
Edit this bug report at http://bugs.php.net/?id=50060&edit=1
#50021 [Opn]: Predefined Statements doesn't allow Strings with more than 256 letters.
ID: 50021
Updated by: u...@php.net
Reported By: novitools dot novi at web dot de
Status: Open
Bug Type: MySQLi related
Operating System: Windows Vista
PHP Version: 5.3.0
New Comment:
Thanks for the feedback!
I feared that meta data would indicate the correct length. To be
honest, I have no idea so far what may be causing it.
Previous Comments:
[2009-11-03 14:33:21] novitools dot novi at web dot de
Here is the result:
Field 1: `You can only read the first 256 words of this text. That
is why I must write such a long text, because I must reach the limit
of
256 words. The same error occours, when you try to select a text
column
from the database. But I didn't had this error before `
Catalog:`def`
Database: ``
Table: ``
Org_table: ``
Type: VAR_STRING
Collation: latin1_swedish_ci (8)
Length: 284
Max_length: 284
Decimals: 31
Flags: NOT_NULL
+---
---+
| You can only read the first 256 words of this text. That
is why I must write such a long text, because I must reach the limit
of
256 words. The same error occours, when you try to select a text
column
from the database. But I didn't had this error before
|
+---
---+
| You can only read the first 256 words of this text. That
is why I must write such a long text, because I must reach the limit
of
256 words. The same error occours, when you try to select a text
column
from the database. But I didn't had this error before in a previous
version of php. |
+---
---+
1 row in set (0.00 sec)
[2009-11-03 09:54:50] u...@php.net
Please run you query in the MySQL prompt and show the meta data that is
returned from MySQL. Start the MySQL prompt with "mysql
--column-type-info" followed by your usual "-u", "-p", "-h" etc.
options.
For example:
nixn...@ulflinux:~> /usr/local/mysql/bin/mysql --column-type-info
-uroot -proot
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 13
Server version: 5.1.39-debug Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
mysql> select 1;
Field 1: `1`
Catalog:`def`
Database: ``
Table: ``
Org_table: ``
Type: LONGLONG
Collation: binary (63)
Length: 1
Max_length: 1
Decimals: 0
Flags: NOT_NULL BINARY NUM
+---+
| 1 |
+---+
| 1 |
+---+
1 row in set (0.00 sec)
But, of course, run your failing query and run mysql prompt on your
system.
Thanks,
Ulf
[2009-10-30 15:12:35] novitools dot novi at web dot de
So the problem only occurs on specific versions:
No Problem with this Versions:
client_version 50005
server_version 50132
Big Problem with this Versions:
client_version 50137
server_version 50137
[2009-10-29 17:58:24] friedrich dot mark at freenet dot de
Same Problem here:
$db = new mysqli('localhost', 'root', '', 'test');
$stmt = $db->stmt_init();
$sql = "SELECT `text` FROM `longtext` WHERE `id` = 1";
$stmt->prepare($sql);
$stmt->execute();
$stmt->bind_result($text);
$stmt->fetch();
$stmt->close();
var_dump(phpversion());
var_dump($db->client_version);
var_dump($db->server_version);
var_dump($db->protocol_version);
var_dump($text);
Output:
string(5) "5.3.0"
int(50137)
int(50137)
int(10)
string(256) "Lorem ipsum dolor sit amet, consetetur sadipscing elitr,
sed diam nonumy eirmod tempor invidunt ut labore et dolore magna
aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo
dolores et ea rebum. Stet clita kasd gubergren, no sea takimata "
OS: Win 7
SQL:
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
CREATE DATABASE `test` DEFAULT CHARACTER SET latin1 COLLATE
latin1_swedish_ci;
USE `test`;
CREATE TABLE IF NOT EXISTS `longtext` (
`id` int(11) NOT NULL,
`text` text NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
INSERT INTO `longtext` (`id`, `text`) VALUES
(1, 'Lorem ipsum dolor sit amet, conse
#50068 [NEW]: const problem
From: jachym dot tousek at gmail dot com Operating system: Windows 7 PHP version: 5.3.1RC3 PHP Bug Type: Scripting Engine problem Bug description: const problem Description: const is not working Reproduce code: --- http://bugs.php.net/?id=50068&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50068&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50068&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50068&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50068&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50068&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50068&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50068&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50068&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50068&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50068&r=support Expected behavior: http://bugs.php.net/fix.php?id=50068&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50068&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50068&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50068&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50068&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50068&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50068&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50068&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50068&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50068&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50068&r=mysqlcfg
#46264 [Opn]: FoxPro DBF files can not be opened
ID: 46264 Updated by: sjo...@php.net Reported By: pierre dot beaumadier at gmail dot com Status: Open Bug Type: dBase related Operating System: GNU/Linux PHP Version: 5.2CVS-2008-10-09 New Comment: I've put the file Mr Moseby provided online here: http://www.gissen.nl/files/mach07.DBF Previous Comments: [2009-11-01 20:28:11] sjo...@php.net Asked for DBF files per e-mail. [2009-10-29 12:19:20] jmoseby at elasticfabrics dot com I have this problem too. It is a major problem for me. I can provide example dbf files on request. Running ubuntu hardy 2.6.24-19-generic. #php --version PHP 5.2.9-0.dotdeb.2 with Suhosin-Patch 0.9.7 (cli) (built: Apr 7 2009 20:42:41) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies [2008-10-09 13:53:38] pierre dot beaumadier at gmail dot com Same error with the latest snapshot. [2008-10-09 12:24:38] j...@php.net Not all fixed bugs are evident in the NEWS. Some people are lazy to write proper descriptions. [2008-10-09 12:19:14] pierre dot beaumadier at gmail dot com For information I tested on this version : $ php --version PHP 5.2.4-2ubuntu5.3 with Suhosin-Patch 0.9.6.2 (cli) (built: Jul 23 2008 06:44:49) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies I looked up in the bugs list but didn't see anything related to my problem. I will try to test the latest snapshot. 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/46264 -- Edit this bug report at http://bugs.php.net/?id=46264&edit=1
#50068 [Opn->Bgs]: const problem
ID: 50068 Updated by: fel...@php.net Reported By: jachym dot tousek at gmail dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows 7 PHP Version: 5.3.1RC3 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2009-11-03 21:11:32] ksin...@php.net I think this behavior is by design. const expressions are evaluated at compile time. So only few operations are supported in a const expression and string concatenation is not one of those. I could repro this in PHP 5.2 (after putting it under a class). [2009-11-03 20:16:44] jachym dot tousek at gmail dot com Description: const is not working Reproduce code: --- http://bugs.php.net/?id=50068&edit=1
#50072 [NEW]: Lighttpd spawn-fcgi CRASH . child exited with: 254
From: sasha181 at mail dot ru Operating system: freebsd 7.1 amd64 PHP version: 5.2.11 PHP Bug Type: Unknown/Other Function Bug description: Lighttpd spawn-fcgi CRASH . child exited with: 254 Description: Today, I upgrade my server's PHP to 5.2.11, after installed PHP, when I start PHP Fast-CGI via spawn-fcgi,it reports the following error message and quit. spawn-fcgi.c.218: child exited with: 254, Unknown error 254 spawn-fcgi version is 1.6.2 And this version of spawn-fcgi works well with php5.2.10 -- Edit bug report at http://bugs.php.net/?id=50072&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50072&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50072&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50072&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50072&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50072&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50072&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50072&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50072&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50072&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50072&r=support Expected behavior: http://bugs.php.net/fix.php?id=50072&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50072&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50072&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50072&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50072&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50072&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50072&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50072&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50072&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50072&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50072&r=mysqlcfg
#50072 [Opn->Csd]: Lighttpd spawn-fcgi CRASH . child exited with: 254
ID: 50072 User updated by: sasha181 at mail dot ru Reported By: sasha181 at mail dot ru -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: freebsd 7.1 amd64 PHP Version: 5.2.11 New Comment: on another similar system, the problem is not reproduced Previous Comments: [2009-11-04 06:36:35] sasha181 at mail dot ru Description: Today, I upgrade my server's PHP to 5.2.11, after installed PHP, when I start PHP Fast-CGI via spawn-fcgi,it reports the following error message and quit. spawn-fcgi.c.218: child exited with: 254, Unknown error 254 spawn-fcgi version is 1.6.2 And this version of spawn-fcgi works well with php5.2.10 -- Edit this bug report at http://bugs.php.net/?id=50072&edit=1
#50035 [Fbk->Opn]: Crash during shutdown, zm_shutdown_ps_mm -> ps_mm_destroy -> mm_destroy
ID: 50035 User updated by: dhertel at gmail dot com Reported By: dhertel at gmail dot com -Status: Feedback +Status: Open Bug Type: Session related Operating System: linux 2.6.27 PHP Version: 5.3.1RC2 New Comment: unfortunately i can't as i use methods which have been introduced in php 5.3 my libmm version is 1.4.2 (1.4.2-16.79 from opensuse 11.1) Previous Comments: [2009-11-03 10:54:01] j...@php.net It crashes in mod_mm.c line 256 which is ps_mm_destroy() doing mm_destroy(). See also bug #46434 which is about another MM related crash in session module. I would guess it's either MM which is buggy or we're doing something wrong here. (what libmm version do you have?) Please try also with PHP 5.2.11 (no need for backtrace, just let us know if it crashes also). [2009-10-29 19:41:35] dhertel at gmail dot com that somehow doesn't surprise me, as this segfault doesn't seem to come from the script... if i got the backtrace right, php segfaults after the script finished - correct me if i'm wrong :) [2009-10-29 19:36:18] sjo...@php.net I could not reproduce the crash with either script. [2009-10-29 15:07:59] dhertel at gmail dot com I'm sorry i couln't provide a shorter script :-(. I can't reproduce the segfault with a simple script. I now stripped everything unnecessary from the script... doesn't need anything external now... Strange thing is that the segfault doesn't occur every time the script ends but sometimes... and the more iterations mmae_core2 runs (line 59), the more often it seems to occur http://pastebin.org/49264 [2009-10-29 14:12:29] dhertel at gmail dot com Description: I'm writing a CLI program with forking and ipc and stuff. It seems to work fine but in the current test the script eventually produces a segfault - every time... but only if i let it run until it's shutting down itself. if i interrupt it, it shuts down without segfaulting php -i says it's version 5.3.1RC3-dev but i also had this problem with 5.3.0 (which unfortunately i can't downgrade to anymore to make a trace there) when using valgrind to check memory the segfault doesn't happen Reproduce code: --- Though I don't believe that it's a problem with my actual code (as there are no execute() lines in the Backtrace), here it is: http://pastebin.org/49244 the PFW_* classes are for handling processes in general, the MMAE_* classes are part of the actual software using PFW_*, where MMAE_Boot stays but Core and Core2 are only for seing if my PFW_* actually works. Expected result: no segfault Actual result: -- segfault so here's the back trace #0 0xb7441570 in ?? () #1 0x080b88d3 in zm_shutdown_ps_mm (type=1, module_number=7) at /usr/src/debug/php-5.3.1_git200910272307/ext/session/mod_mm.c:256 #2 0x080b6fd1 in zm_shutdown_session (type=1, module_number=7) at /usr/src/debug/php-5.3.1_git200910272307/ext/session/session.c:2192 #3 0x081bde7a in module_destructor (module=0x82cd180) at /usr/src/debug/php-5.3.1_git200910272307/Zend/zend_API.c:2098 #4 0x081c4192 in zend_hash_apply_deleter (ht=0x82bbbc0, p=0x82cd150) at /usr/src/debug/php-5.3.1_git200910272307/Zend/zend_hash.c:611 #5 0x081c4457 in zend_hash_graceful_reverse_destroy (ht=0x82bbbc0) at /usr/src/debug/php-5.3.1_git200910272307/Zend/zend_hash.c:646 #6 0x081b85ac in zend_shutdown () at /usr/src/debug/php-5.3.1_git200910272307/Zend/zend.c:759 #7 0x0815d732 in php_module_shutdown () at /usr/src/debug/php-5.3.1_git200910272307/main/main.c:2103 #8 0x0824569c in main (argc=2, argv=0xbff47784) at /usr/src/debug/php-5.3.1_git200910272307/sapi/cli/php_cli.c:1385 -- Edit this bug report at http://bugs.php.net/?id=50035&edit=1
