#44860 [NEW]: session_encode fails for php_binary serialiser
From: [EMAIL PROTECTED] Operating system: All PHP version: 6CVS-2008-04-29 (snap) PHP Bug Type: Session related Bug description: session_encode fails for php_binary serialiser Description: I've added a new test into the 6.0 branch called session_encode_variation7.phpt - the expected output for this test shows the problem. It shows that when unicode is enabled the output from session_encode when using the php_binary serialiser is wrong. Reproduce code: --- --TEST-- Test session_encode() function : variation --SKIPIF-- --INI-- session.serialize_handler=php_binary --FILE-- --EXPECTF-- *** Testing session_encode() : variation *** bool(true) string(24) "A2Zvb2k6MTIzNDU2Nzg5MDs=" bool(true) Done --UEXPECTF-- *** Testing session_encode() : variation *** bool(true) string(0) "" bool(true) Done Expected result: --UEXPECTF-- *** Testing session_encode() : variation *** bool(true) unicode(24) "A2Zvb2k6MTIzNDU2Nzg5MDs=" bool(true) Done Actual result: -- --UEXPECTF-- *** Testing session_encode() : variation *** bool(true) string(0) "" bool(true) Done -- Edit bug report at http://bugs.php.net/?id=44860&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44860&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44860&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44860&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44860&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44860&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44860&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44860&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44860&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44860&r=support Expected behavior:http://bugs.php.net/fix.php?id=44860&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44860&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44860&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44860&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44860&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44860&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44860&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44860&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44860&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44860&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44860&r=mysqlcfg
#44853 [Fbk->Opn]: filter_callback crash
ID: 44853
User updated by: vtsupermok at gmail dot com
Reported By: vtsupermok at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Filter related
Operating System: Win Vista
PHP Version: 5.2.5
New Comment:
I just try the latest window version but it still not work. The result
also same with before
Previous Comments:
[2008-04-28 13:48:54] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2008-04-28 10:14:30] vtsupermok at gmail dot com
Description:
In a filter_callback function, if the function return false, the system
crash, the apache hange.
if return other things other than false, for example 'aaa',true,1, it
works
Reproduce code:
---
function returnTrue($val){
return true;
}
function returnFalse($val){
return false;
}
var_dump(filter_var('', FILTER_CALLBACK,
array("options"=>"returnTrue")));
var_dump(filter_var('', FILTER_CALLBACK,
array("options"=>"returnFalse")));
Expected result:
bool(true)
bool(false)
Actual result:
--
nothing can see, because the system crashed
--
Edit this bug report at http://bugs.php.net/?id=44853&edit=1
#44853 [Opn->Fbk]: filter_callback crash
ID: 44853
Updated by: [EMAIL PROTECTED]
Reported By: vtsupermok at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Filter related
Operating System: Win Vista
PHP Version: 5.2.5
New Comment:
This bug was fixed in PHP 5.2.6RC1. Make sure the version used in your
test. (see the php version)
I can't reproduce on PHP 5.2.6RC6-dev.
Previous Comments:
[2008-04-29 09:51:09] vtsupermok at gmail dot com
I just try the latest window version but it still not work. The result
also same with before
[2008-04-28 13:48:54] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2008-04-28 10:14:30] vtsupermok at gmail dot com
Description:
In a filter_callback function, if the function return false, the system
crash, the apache hange.
if return other things other than false, for example 'aaa',true,1, it
works
Reproduce code:
---
function returnTrue($val){
return true;
}
function returnFalse($val){
return false;
}
var_dump(filter_var('', FILTER_CALLBACK,
array("options"=>"returnTrue")));
var_dump(filter_var('', FILTER_CALLBACK,
array("options"=>"returnFalse")));
Expected result:
bool(true)
bool(false)
Actual result:
--
nothing can see, because the system crashed
--
Edit this bug report at http://bugs.php.net/?id=44853&edit=1
#41539 [Asn]: MSSQL ext. with freetds treats '' (string of length 0) as NULL in VARCHAR(MAX)
ID: 41539
User updated by: phpbug dot 41539 at sub dot noloop dot net
-Reported By: frode at coretrek dot com
+Reported By: phpbug dot 41539 at sub dot noloop dot net
Status: Assigned
Bug Type: MSSQL related
Operating System: Linux and win32
PHP Version: 5.2.5
Assigned To: fmk
New Comment:
Changing emails, please ignore this comment.
Previous Comments:
[2007-11-15 15:33:27] frode at coretrek dot com
The previous comment was a bit imprecise. I compiled FreeTDS from CVS
tag BRANCH0_64 as of today, not from freetds-0.64.tar.gz+post64.diff.gz.
[2007-11-15 15:31:16] frode at coretrek dot com
I compiled (freetds 0.64 + post64.diff.gz) and then recompiled my
(unmodified) php 5.2.5 using
"--with-mssql=/path/to/the/freetds/installation", and whatever you did
in post64.diff.gz seems to fix the problem. The test case in my original
submission now prints:
array(3) {
["id"]=>
int(1)
["txt"]=>
string(0) ""
["txtmax"]=>
string(0) ""
}
array(3) {
["id"]=>
int(2)
["txt"]=>
NULL
["txtmax"]=>
NULL
}
as expected.
Thank you very much!
Is there a timeline/ETA for the next stable release of FreeTDS (0.65)?
Also, if any php developers are reading this: It would be great if the
win32 binary distribution of PHP could be compiled and linked with
FreeTDS instead of the Microsoft DBLIB libraries :)
[2007-11-15 14:11:43] freddy77 at gmail dot com
I'm a FreeTDS developer.
There was a problem with (n)text and (n)varchar(max), not with
(n)varchar (these types are blobs). For empty blobs pointer from dbdata
was NULL. I fixed the problem in CVS HEAD and 0.64 branch. You can find
cumulative post 0.64 patch at
http://freetds.sourceforge.net/post64.diff.gz, change is at
http://freetds.cvs.sourceforge.net/freetds/freetds/src/dblib/dblib.c?r1=1.244.2.3&r2=1.244.2.4
(similar change for CVS head).
bye
freddy77
[2007-10-19 08:43:59] frode at coretrek dot com
Is there a chance to get a fix for this in before 5.2.5?
[2007-08-13 08:19:34] frode at coretrek dot com
Is there a chance to get a fix for this in before 5.2.4?
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/41539
--
Edit this bug report at http://bugs.php.net/?id=41539&edit=1
#40928 [Opn]: escapeshellarg() does not quote percent (%) correctly for cmd.exe
ID: 40928 User updated by: phpbug dot 40928 at sub dot noloop dot net -Reported By: frode at coretrek dot com +Reported By: phpbug dot 40928 at sub dot noloop dot net Status: Open Bug Type: Feature/Change Request Operating System: Windows Server 2003 PHP Version: 5.2.1 New Comment: Changing email, please ignore this comment. Previous Comments: [2007-03-27 13:31:19] phpbug dot 40928 at sub dot noloop dot net Description: On win32, the function escapeshellarg() replaces percent characters (%) with spaces. Instead, the function should escape the percent character, perhaps using the ^% construct, so that the percent sign can be safely used as a an argument to an application executed through exec(). Reproduce code: --- Expected result: test%dir Actual result: -- test dir -- Edit this bug report at http://bugs.php.net/?id=40928&edit=1
#44851 [Fbk->Opn]: Interbase events crash PHP cli with segmentation fault
ID: 44851 User updated by: miha at link-go dot si Reported By: miha at link-go dot si -Status: Feedback +Status: Open Bug Type: InterBase related Operating System: linux PHP Version: 5.2.5 New Comment: CVS snapshot does not solve the problem. PHP usually exits (with segmentation fault) after a few minutes, let say 5 - 10 minutes. But the time is not constant. I have a simulator app that fills the database (and produces events - a few events per second). It appears to me like some kind of concurrency - access problem. Previous Comments: [2008-04-29 00:39:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2008-04-28 05:48:55] miha at link-go dot si Description: I have a socket server (pear Net_Server) running configuration on my test machine. The server runs OK. Then if I turn on events with ibase_set_event_handler, the server will fail within a few minutes with a segmentation fault. Until that happens everything works like a charm. My cli-based socket server application fails even with an empty event handler (an emty function returning true)! -- Edit this bug report at http://bugs.php.net/?id=44851&edit=1
#42499 [Com]: PDO_MYSQL: multi-statement execution via PDO::exec() makes connection unusable
ID: 42499 Comment by: kingoleg at mail dot ru Reported By: suhachov at gmail dot com Status: Assigned Bug Type: PDO related Operating System: FC PHP Version: 5.2.4 Assigned To: andrey New Comment: Hi, All Is there any solution for this? Previous Comments: [2008-04-05 21:06:13] mgrdinic at sledxchange dot com Any movement here? [2007-09-04 14:45:46] [EMAIL PROTECTED] Andrey, can you check this out please. (or reassing to whoever is supposed to be maintaining ext/pdo_mysql :) [2007-09-04 14:42:22] suhachov at gmail dot com I said it _only_ in reply to your response: > You report the bug with version 5.2.4, yet you seem to > be using 5.1.6?! > How about you try with 5.2.4 first? I mentioned in this issue, that it applies to 5.2.4 and usually it means something (unless reporter is insane). I spent a lot of time to find this peace of code inside PDO and find out how to work it around but you even didn't look to the source file to see that it wasn't changed since 5.1.X. I know you guys aren't paid for this, but we aren't paid for tracing bugs too. So lets respect each others efforts ... > so provide an url to the unified diff http://blog.ru/php-pdo-multi-result.patch > And make the patch against latest CVS snapshot rather than > release, it's lot easier to review and apply it then. ok, but this patch is release-independent, this area is unchanged for a long time. [2007-09-04 10:36:42] [EMAIL PROTECTED] First of all: Check your tone. You're not dealing with people who get paid for reading insults and/or aggressive tone. That is the best way to get your report totally ignored. If I had "brushed aside" this report, I wouldn't have bothered writing anything, this would be bogus right now.. Patches are more than welcome but we'd like to get them as files (this bug system sucks, I know) so provide an url to the unified diff. And make the patch against latest CVS snapshot rather than release, it's lot easier to review and apply it then. [2007-09-03 19:00:49] suhachov at gmail dot com # tar xjf php-5.2.4.tar.bz2 # cd php-5.2.4 # ./configure --disable-all --with-pdo-mysql --enable-pdo --enable-cli --disable-cgi # make # sapi/cli/php -n pdo-mysql-bug.php Warning: PDO::query(): SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute. in /home/andrew/src/php-5.2.4/pdo-mysql-bug.php on line 14 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/42499 -- Edit this bug report at http://bugs.php.net/?id=42499&edit=1
#43024 [Asn->Fbk]: Update PHP OpenSSL Files
ID: 43024 Updated by: [EMAIL PROTECTED] Reported By: dj02 dot net at nbl dot fi -Status: Assigned +Status: Feedback Bug Type: OpenSSL related Operating System: Windows Vista 6.0.6000 PHP Version: 5.2CVS-2008-02-01 (snap) Assigned To: pajoye New Comment: Update done on the build box. The latest snaps use openssl 0.9.8g. Please give them a try and let us know how it works. http://snaps.php.net/ (win32) Previous Comments: [2008-04-25 15:07:38] [EMAIL PROTECTED] Update to 0.9.8g in progress. The next 5.2.x release (5.2.6RC2 binaries will have it) will hopefully use this version. [2008-02-01 11:12:00] [EMAIL PROTECTED] Hi Edin, What is preventing us to update our windows binaries to the last openssl version? Only wondering if there is any possible issues :) [2008-02-01 09:44:46] dj02 dot net at nbl dot fi Still not updated. Could you update them. [2007-11-14 21:27:31] dj02 dot net at nbl dot fi Still not updated. [2007-10-25 13:29:23] dj02 dot net at nbl dot fi - 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/43024 -- Edit this bug report at http://bugs.php.net/?id=43024&edit=1
#44861 [NEW]: scrollable cursor don't work with pgsql
From: php at benjaminschulz dot com
Operating system: osx
PHP version: 5.3CVS-2008-04-29 (CVS)
PHP Bug Type: PDO related
Bug description: scrollable cursor don't work with pgsql
Description:
I don't see how to use scrollable cursors with pdo_pgsql
Reproduce code:
---
$db = new Pdo("pgsql:...");
$db->setAttribute(Pdo::ATTR_ERRMODE, Pdo::ERRMODE_EXCEPTION);
$res = $db->prepare("SELECT 'row1' UNION SELECT 'row2' UNION SELECT 'row3'
UNION SELECT 'row4'", array(PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL));
$res->execute();
var_dump($res->fetch());
// $res->fetch(Pdo::FETCH_NUM, PDO::FETCH_ORI_ABS, 2) won't throw an
exception but return false
Expected result:
array('row1')
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[34000]: Invalid cursor name: 7 ERROR: cursor
"pdo_pgsql_cursor_00d78a0c" does not exist' in ...
--
Edit bug report at http://bugs.php.net/?id=44861&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44861&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44861&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44861&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44861&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44861&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44861&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44861&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44861&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44861&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44861&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44861&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44861&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44861&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44861&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44861&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44861&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44861&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44861&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44861&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44861&r=mysqlcfg
#44862 [NEW]: Invalid encoding in pspell_config_create() w/ pspell_new_config() causes abort
From: twm at twmacinta dot com
Operating system: Red Hat Enterprise Linux ES 3
PHP version: 5.2.5
PHP Bug Type: Reproducible crash
Bug description: Invalid encoding in pspell_config_create() w/
pspell_new_config() causes abort
Description:
When I pass an invalid encoding as the fourth argument to the function
pspell_config_create() and then pass that return value to
pspell_new_config(), PHP aborts and stops running. This is causing the
"make test" script named "ext/pspell/tests/003.phpt" to fail on my system
when I try to test my new build of PHP. I have created a simpler test case
for this bug report and also read through the code a bit more to come up
with an analysis which I think might be helpful.
My test script works as expected in older versions of PHP on the same
operating system. In particular, it works fine in PHP 4.3 on the same OS.
This applies to both my custom compiled version of PHP as well as the most
recent build from Red Hat. I believe that the problem was introduced in
revision 1.45.2.4.2.5. See line 405 below:
http://cvs.php.net/viewvc.cgi/php-src/ext/pspell/pspell.c?r1=1.45.2.4.2.4&r2=1.45.2.4.2.5&pathrev=PHP_5_2
The problem is that delete_pspell_manager() is called on a pointer
obtained from new_pspell_manager() which isn't necessarily a pspell
manager. It can either be an error or a pspell manager. Here is the code
from the pspell library - note that the first return statement can result
in PHP getting something which isn't a pspell manager (which is what it
incorrectly frees):
PspellCanHaveError * new_pspell_manager(PspellConfig * c)
{
PspellCanHaveError * possible_err = find_word_list(c);
if (possible_err->error_number() != 0)
return possible_err;
PspellConfig * config = (PspellConfig *)(possible_err);
possible_err = new_pspell_manager_class(config);
delete config;
return possible_err;
}
Perhaps this error isn't being triggered on your test systems since it
depends upon whether the system's pspell library was compiled to enforce
assertions.
Note that there were several other changes like this made in revision
1.45.2.4.2.5. There were other lines added which call delete_pspell_*(),
possibly with an invalid argument. I don't know if they are a problem in
reality - I only caught the line that I'm reporting because "make test"
failed for me. I was a little hesitant to remove those lines in my own
code since they were added without other major changes, so there was
presumably some reason for them, though the revision comment and change log
don't mention what it was.
I used "php -n" to run all of the tests, so as to rule out "php.ini" as a
problem. I tried the test script with both PHP 5.2.5 and the latest CVS
snapshot, php5.2-200804291230.
Reproduce code:
---
$cfg2 = pspell_config_create('en', 'british', '', 'b0rked');
$p2 = pspell_new_config($cfg2);
print("Done\n");
Expected result:
Warning: pspell_new_config(): PSPELL couldn't open the dictionary. reason:
The encoding "b0rked" is not known. This could also mean that the file
"/usr/share/pspell/b0rked.map" could not be opened for reading or does not
exist. in /tmp/timtest20080429.php on line 3
Done
Actual result:
--
Warning: pspell_new_config(): PSPELL couldn't open the dictionary. reason:
The encoding "b0rked" is not known. This could also mean that the file
"/usr/share/pspell/b0rked.map" could not be opened for reading or does not
exist. in /tmp/timtest20080429.php on line 3
php: manager_impl.cc:30: void free_lt_handle(void*): Assertion `s == 0'
failed.
Aborted
--
Edit bug report at http://bugs.php.net/?id=44862&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44862&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44862&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44862&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44862&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44862&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44862&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44862&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44862&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44862&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44862&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44862&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44862&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44862&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44862&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44862&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44862&r=isapi
Install GNU Sed: http://bu
#44863 [NEW]: isset detects an array item that var_dump does not.
From: igordonin at gmail dot com
Operating system: Windows XP SP2
PHP version: 5.2.5
PHP Bug Type: Scripting Engine problem
Bug description: isset detects an array item that var_dump does not.
Description:
Development Environment is PHP 5.2.5, Apache 2.2.
When requesting PHP to unset an array item, there's a fatal error:
Fatal error: Cannot unset string offsets in C:\[hidden]\index.php on line
147
When I var_dump the array variable, the array item is not show as part of
that array, but the unset array item command is inside a if
(isset($variable["ArrayName"])) { ... which means that the item has to
exist in order for the unset to occur.
-
On my production enviroment, though, I'm running PHP Version 4.3.9, with
Apache Handler 2.0.52(Oracle) | API Version 20020903, and it does not cause
a Fatal Error, but the error is still there. Here's the URL:
http://helpdesk.mozart.com.br/public/index.php
-> Try to connect with anything. It matters not, I think.
If this is not a bug, I do apologize. It's just that I've checked this
code so many times and I can't find anything wrong ...
Thanks in advance.
Reproduce code:
---
# 1. Execute Query
$Query["Try_Login"] = Query_Repository("Try_Login", 0, 2, 0);
echo " This is the var_dump for array \$Query: ";
var_dump($Query);
echo "";
if (isset( $Query["Try_Login"]["Error"] )) { echo
"\$Query[\"Try_Login\"][\"Error\"] is set as: \"" .
$Query["Try_Login"]["Error"] . "\"."; }
die();
Here are the URLs for the functions that you might need to take a look at.
I saved them as txt so you may check them out.
Query_Repository:
http://helpdesk.mozart.com.br/public/query_repository.txt
Request_Value:
http://helpdesk.mozart.com.br/public/request_value.txt
validate_input:
http://helpdesk.mozart.com.br/public/validate_input.txt
Expected result:
$Query["Try_Login"] was supposed to be set only as string, either with
"conn_err" or "conn_ok". That's all var_dump really shows, and that's what
it's supposed to be ...
Actual result:
--
... but it was also supposed to not have an ["Error"] array Item. It's not
shown while using var_dump, but "isset" returns true, and it's value is set
to string "c". Still, I cannot unset it for it may produce a fatal error.
Fatal error: Cannot unset string offsets in C:\[hidden]\index.php on line
147
--
Edit bug report at http://bugs.php.net/?id=44863&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44863&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44863&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44863&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44863&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44863&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44863&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44863&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44863&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44863&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44863&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44863&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44863&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44863&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44863&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44863&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44863&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44863&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44863&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44863&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44863&r=mysqlcfg
#44863 [Opn->Bgs]: isset detects an array item that var_dump does not.
ID: 44863
Updated by: [EMAIL PROTECTED]
Reported By: igordonin at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP SP2
PHP Version: 5.2.5
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
$variable is a string and not an array.
Your error : "Fatal error: Cannot unset string offsets" is pretty
explicit about it.
Previous Comments:
[2008-04-29 18:34:23] igordonin at gmail dot com
Description:
Development Environment is PHP 5.2.5, Apache 2.2.
When requesting PHP to unset an array item, there's a fatal error:
Fatal error: Cannot unset string offsets in C:\[hidden]\index.php on
line 147
When I var_dump the array variable, the array item is not show as part
of that array, but the unset array item command is inside a if
(isset($variable["ArrayName"])) { ... which means that the item has to
exist in order for the unset to occur.
-
On my production enviroment, though, I'm running PHP Version 4.3.9,
with Apache Handler 2.0.52(Oracle) | API Version 20020903, and it does
not cause a Fatal Error, but the error is still there. Here's the URL:
http://helpdesk.mozart.com.br/public/index.php
-> Try to connect with anything. It matters not, I think.
If this is not a bug, I do apologize. It's just that I've checked this
code so many times and I can't find anything wrong ...
Thanks in advance.
Reproduce code:
---
# 1. Execute Query
$Query["Try_Login"] = Query_Repository("Try_Login", 0, 2, 0);
echo " This is the var_dump for array \$Query: ";
var_dump($Query);
echo "";
if (isset( $Query["Try_Login"]["Error"] )) { echo
"\$Query[\"Try_Login\"][\"Error\"] is set as: \"" .
$Query["Try_Login"]["Error"] . "\"."; }
die();
Here are the URLs for the functions that you might need to take a look
at. I saved them as txt so you may check them out.
Query_Repository:
http://helpdesk.mozart.com.br/public/query_repository.txt
Request_Value:
http://helpdesk.mozart.com.br/public/request_value.txt
validate_input:
http://helpdesk.mozart.com.br/public/validate_input.txt
Expected result:
$Query["Try_Login"] was supposed to be set only as string, either with
"conn_err" or "conn_ok". That's all var_dump really shows, and that's
what it's supposed to be ...
Actual result:
--
... but it was also supposed to not have an ["Error"] array Item. It's
not shown while using var_dump, but "isset" returns true, and it's value
is set to string "c". Still, I cannot unset it for it may produce a
fatal error.
Fatal error: Cannot unset string offsets in C:\[hidden]\index.php on
line 147
--
Edit this bug report at http://bugs.php.net/?id=44863&edit=1
#44863 [Bgs]: isset detects an array item that var_dump does not.
ID: 44863
User updated by: igordonin at gmail dot com
Reported By: igordonin at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP SP2
PHP Version: 5.2.5
New Comment:
You're wrong, var_dump says:
array(1) { ["Try_Login"]=> string(8) "conn_err" }
It's so an array!
Previous Comments:
[2008-04-29 18:39:38] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
$variable is a string and not an array.
Your error : "Fatal error: Cannot unset string offsets" is pretty
explicit about it.
[2008-04-29 18:34:23] igordonin at gmail dot com
Description:
Development Environment is PHP 5.2.5, Apache 2.2.
When requesting PHP to unset an array item, there's a fatal error:
Fatal error: Cannot unset string offsets in C:\[hidden]\index.php on
line 147
When I var_dump the array variable, the array item is not show as part
of that array, but the unset array item command is inside a if
(isset($variable["ArrayName"])) { ... which means that the item has to
exist in order for the unset to occur.
-
On my production enviroment, though, I'm running PHP Version 4.3.9,
with Apache Handler 2.0.52(Oracle) | API Version 20020903, and it does
not cause a Fatal Error, but the error is still there. Here's the URL:
http://helpdesk.mozart.com.br/public/index.php
-> Try to connect with anything. It matters not, I think.
If this is not a bug, I do apologize. It's just that I've checked this
code so many times and I can't find anything wrong ...
Thanks in advance.
Reproduce code:
---
# 1. Execute Query
$Query["Try_Login"] = Query_Repository("Try_Login", 0, 2, 0);
echo " This is the var_dump for array \$Query: ";
var_dump($Query);
echo "";
if (isset( $Query["Try_Login"]["Error"] )) { echo
"\$Query[\"Try_Login\"][\"Error\"] is set as: \"" .
$Query["Try_Login"]["Error"] . "\"."; }
die();
Here are the URLs for the functions that you might need to take a look
at. I saved them as txt so you may check them out.
Query_Repository:
http://helpdesk.mozart.com.br/public/query_repository.txt
Request_Value:
http://helpdesk.mozart.com.br/public/request_value.txt
validate_input:
http://helpdesk.mozart.com.br/public/validate_input.txt
Expected result:
$Query["Try_Login"] was supposed to be set only as string, either with
"conn_err" or "conn_ok". That's all var_dump really shows, and that's
what it's supposed to be ...
Actual result:
--
... but it was also supposed to not have an ["Error"] array Item. It's
not shown while using var_dump, but "isset" returns true, and it's value
is set to string "c". Still, I cannot unset it for it may produce a
fatal error.
Fatal error: Cannot unset string offsets in C:\[hidden]\index.php on
line 147
--
Edit this bug report at http://bugs.php.net/?id=44863&edit=1
#44863 [Bgs]: isset detects an array item that var_dump does not.
ID: 44863
Updated by: [EMAIL PROTECTED]
Reported By: igordonin at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP SP2
PHP Version: 5.2.5
New Comment:
Look: $Query is an array that contains a string at the index
"Try_Login". So $Query["Try_Login"] is a string.
You're unsetting $Query["Try_Login"]["Error"] so yes, you're trying to
unset an offset of a string.
Previous Comments:
[2008-04-29 18:43:26] igordonin at gmail dot com
You're wrong, var_dump says:
array(1) { ["Try_Login"]=> string(8) "conn_err" }
It's so an array!
[2008-04-29 18:39:38] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
$variable is a string and not an array.
Your error : "Fatal error: Cannot unset string offsets" is pretty
explicit about it.
[2008-04-29 18:34:23] igordonin at gmail dot com
Description:
Development Environment is PHP 5.2.5, Apache 2.2.
When requesting PHP to unset an array item, there's a fatal error:
Fatal error: Cannot unset string offsets in C:\[hidden]\index.php on
line 147
When I var_dump the array variable, the array item is not show as part
of that array, but the unset array item command is inside a if
(isset($variable["ArrayName"])) { ... which means that the item has to
exist in order for the unset to occur.
-
On my production enviroment, though, I'm running PHP Version 4.3.9,
with Apache Handler 2.0.52(Oracle) | API Version 20020903, and it does
not cause a Fatal Error, but the error is still there. Here's the URL:
http://helpdesk.mozart.com.br/public/index.php
-> Try to connect with anything. It matters not, I think.
If this is not a bug, I do apologize. It's just that I've checked this
code so many times and I can't find anything wrong ...
Thanks in advance.
Reproduce code:
---
# 1. Execute Query
$Query["Try_Login"] = Query_Repository("Try_Login", 0, 2, 0);
echo " This is the var_dump for array \$Query: ";
var_dump($Query);
echo "";
if (isset( $Query["Try_Login"]["Error"] )) { echo
"\$Query[\"Try_Login\"][\"Error\"] is set as: \"" .
$Query["Try_Login"]["Error"] . "\"."; }
die();
Here are the URLs for the functions that you might need to take a look
at. I saved them as txt so you may check them out.
Query_Repository:
http://helpdesk.mozart.com.br/public/query_repository.txt
Request_Value:
http://helpdesk.mozart.com.br/public/request_value.txt
validate_input:
http://helpdesk.mozart.com.br/public/validate_input.txt
Expected result:
$Query["Try_Login"] was supposed to be set only as string, either with
"conn_err" or "conn_ok". That's all var_dump really shows, and that's
what it's supposed to be ...
Actual result:
--
... but it was also supposed to not have an ["Error"] array Item. It's
not shown while using var_dump, but "isset" returns true, and it's value
is set to string "c". Still, I cannot unset it for it may produce a
fatal error.
Fatal error: Cannot unset string offsets in C:\[hidden]\index.php on
line 147
--
Edit this bug report at http://bugs.php.net/?id=44863&edit=1
#44863 [Bgs]: isset detects an array item that var_dump does not.
ID: 44863
User updated by: igordonin at gmail dot com
Reported By: igordonin at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP SP2
PHP Version: 5.2.5
New Comment:
You're right!
But is this expected to return true?
if (isset($Query["Try_Login"]["Error")) {
unset($Query["Try_Login"]["Error"]);
}
'Cause that's when I'm trying to unset $Query["Try_Login"]["Error"] ...
Previous Comments:
[2008-04-29 18:51:57] [EMAIL PROTECTED]
Look: $Query is an array that contains a string at the index
"Try_Login". So $Query["Try_Login"] is a string.
You're unsetting $Query["Try_Login"]["Error"] so yes, you're trying to
unset an offset of a string.
[2008-04-29 18:43:26] igordonin at gmail dot com
You're wrong, var_dump says:
array(1) { ["Try_Login"]=> string(8) "conn_err" }
It's so an array!
[2008-04-29 18:39:38] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
$variable is a string and not an array.
Your error : "Fatal error: Cannot unset string offsets" is pretty
explicit about it.
[2008-04-29 18:34:23] igordonin at gmail dot com
Description:
Development Environment is PHP 5.2.5, Apache 2.2.
When requesting PHP to unset an array item, there's a fatal error:
Fatal error: Cannot unset string offsets in C:\[hidden]\index.php on
line 147
When I var_dump the array variable, the array item is not show as part
of that array, but the unset array item command is inside a if
(isset($variable["ArrayName"])) { ... which means that the item has to
exist in order for the unset to occur.
-
On my production enviroment, though, I'm running PHP Version 4.3.9,
with Apache Handler 2.0.52(Oracle) | API Version 20020903, and it does
not cause a Fatal Error, but the error is still there. Here's the URL:
http://helpdesk.mozart.com.br/public/index.php
-> Try to connect with anything. It matters not, I think.
If this is not a bug, I do apologize. It's just that I've checked this
code so many times and I can't find anything wrong ...
Thanks in advance.
Reproduce code:
---
# 1. Execute Query
$Query["Try_Login"] = Query_Repository("Try_Login", 0, 2, 0);
echo " This is the var_dump for array \$Query: ";
var_dump($Query);
echo "";
if (isset( $Query["Try_Login"]["Error"] )) { echo
"\$Query[\"Try_Login\"][\"Error\"] is set as: \"" .
$Query["Try_Login"]["Error"] . "\"."; }
die();
Here are the URLs for the functions that you might need to take a look
at. I saved them as txt so you may check them out.
Query_Repository:
http://helpdesk.mozart.com.br/public/query_repository.txt
Request_Value:
http://helpdesk.mozart.com.br/public/request_value.txt
validate_input:
http://helpdesk.mozart.com.br/public/validate_input.txt
Expected result:
$Query["Try_Login"] was supposed to be set only as string, either with
"conn_err" or "conn_ok". That's all var_dump really shows, and that's
what it's supposed to be ...
Actual result:
--
... but it was also supposed to not have an ["Error"] array Item. It's
not shown while using var_dump, but "isset" returns true, and it's value
is set to string "c". Still, I cannot unset it for it may produce a
fatal error.
Fatal error: Cannot unset string offsets in C:\[hidden]\index.php on
line 147
--
Edit this bug report at http://bugs.php.net/?id=44863&edit=1
#44863 [Bgs]: isset detects an array item that var_dump does not.
ID: 44863
Updated by: [EMAIL PROTECTED]
Reported By: igordonin at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP SP2
PHP Version: 5.2.5
New Comment:
Yes this is expected:
non-numeric indexes are interpreted as 0 for string offsets.
so isset($string["foo"]) is equivalent to isset($string[0]) which
checks whether the string offset 0 exists, and it does, your string is
not empty.
Previous Comments:
[2008-04-29 18:56:29] igordonin at gmail dot com
You're right!
But is this expected to return true?
if (isset($Query["Try_Login"]["Error")) {
unset($Query["Try_Login"]["Error"]);
}
'Cause that's when I'm trying to unset $Query["Try_Login"]["Error"] ...
[2008-04-29 18:51:57] [EMAIL PROTECTED]
Look: $Query is an array that contains a string at the index
"Try_Login". So $Query["Try_Login"] is a string.
You're unsetting $Query["Try_Login"]["Error"] so yes, you're trying to
unset an offset of a string.
[2008-04-29 18:43:26] igordonin at gmail dot com
You're wrong, var_dump says:
array(1) { ["Try_Login"]=> string(8) "conn_err" }
It's so an array!
[2008-04-29 18:39:38] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
$variable is a string and not an array.
Your error : "Fatal error: Cannot unset string offsets" is pretty
explicit about it.
[2008-04-29 18:34:23] igordonin at gmail dot com
Description:
Development Environment is PHP 5.2.5, Apache 2.2.
When requesting PHP to unset an array item, there's a fatal error:
Fatal error: Cannot unset string offsets in C:\[hidden]\index.php on
line 147
When I var_dump the array variable, the array item is not show as part
of that array, but the unset array item command is inside a if
(isset($variable["ArrayName"])) { ... which means that the item has to
exist in order for the unset to occur.
-
On my production enviroment, though, I'm running PHP Version 4.3.9,
with Apache Handler 2.0.52(Oracle) | API Version 20020903, and it does
not cause a Fatal Error, but the error is still there. Here's the URL:
http://helpdesk.mozart.com.br/public/index.php
-> Try to connect with anything. It matters not, I think.
If this is not a bug, I do apologize. It's just that I've checked this
code so many times and I can't find anything wrong ...
Thanks in advance.
Reproduce code:
---
# 1. Execute Query
$Query["Try_Login"] = Query_Repository("Try_Login", 0, 2, 0);
echo " This is the var_dump for array \$Query: ";
var_dump($Query);
echo "";
if (isset( $Query["Try_Login"]["Error"] )) { echo
"\$Query[\"Try_Login\"][\"Error\"] is set as: \"" .
$Query["Try_Login"]["Error"] . "\"."; }
die();
Here are the URLs for the functions that you might need to take a look
at. I saved them as txt so you may check them out.
Query_Repository:
http://helpdesk.mozart.com.br/public/query_repository.txt
Request_Value:
http://helpdesk.mozart.com.br/public/request_value.txt
validate_input:
http://helpdesk.mozart.com.br/public/validate_input.txt
Expected result:
$Query["Try_Login"] was supposed to be set only as string, either with
"conn_err" or "conn_ok". That's all var_dump really shows, and that's
what it's supposed to be ...
Actual result:
--
... but it was also supposed to not have an ["Error"] array Item. It's
not shown while using var_dump, but "isset" returns true, and it's value
is set to string "c". Still, I cannot unset it for it may produce a
fatal error.
Fatal error: Cannot unset string offsets in C:\[hidden]\index.php on
line 147
--
Edit this bug report at http://bugs.php.net/?id=44863&edit=1
#44863 [Bgs]: isset detects an array item that var_dump does not.
ID: 44863
User updated by: igordonin at gmail dot com
Reported By: igordonin at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP SP2
PHP Version: 5.2.5
New Comment:
Hey, I don't mean to be annoying, hope didn't get there yet, but check
this out:
Query_Repository returns string "conn_err", so it's the same as:
$Query["Try_Login"] = "conn_err";
var_dump( $Query ) results in:
array(1) { ["Try_Login"]=> string(8) "conn_err" }
There's no suck key as ["Error"] at all ...
So what you mean is that isset will recognize
$Query["Try_Login"]["Error"] as $Query["Try_Login"][0] because of the
string offset and then return true?
You may be right, that may be in fact the current behavior, but I don't
see how that can be the best behavior at all!
I'm no expert though. So thank you very much for taking the time to
reply. I do appreciate it.
Previous Comments:
[2008-04-29 19:03:11] [EMAIL PROTECTED]
Yes this is expected:
non-numeric indexes are interpreted as 0 for string offsets.
so isset($string["foo"]) is equivalent to isset($string[0]) which
checks whether the string offset 0 exists, and it does, your string is
not empty.
[2008-04-29 18:56:29] igordonin at gmail dot com
You're right!
But is this expected to return true?
if (isset($Query["Try_Login"]["Error")) {
unset($Query["Try_Login"]["Error"]);
}
'Cause that's when I'm trying to unset $Query["Try_Login"]["Error"] ...
[2008-04-29 18:51:57] [EMAIL PROTECTED]
Look: $Query is an array that contains a string at the index
"Try_Login". So $Query["Try_Login"] is a string.
You're unsetting $Query["Try_Login"]["Error"] so yes, you're trying to
unset an offset of a string.
[2008-04-29 18:43:26] igordonin at gmail dot com
You're wrong, var_dump says:
array(1) { ["Try_Login"]=> string(8) "conn_err" }
It's so an array!
[2008-04-29 18:39:38] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
$variable is a string and not an array.
Your error : "Fatal error: Cannot unset string offsets" is pretty
explicit about it.
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/44863
--
Edit this bug report at http://bugs.php.net/?id=44863&edit=1
#44864 [NEW]: STREAM_CLIENT_ASYNC_CONNECT does does not work
From: fhoenig at kargo dot com
Operating system: FreeBSD 7.0 / AMD64
PHP version: 5.2.5
PHP Bug Type: Reproducible crash
Bug description: STREAM_CLIENT_ASYNC_CONNECT does does not work
Description:
The below code only works with sleeping in between stream_socket_client()
and the first IO on the socket. No error though.
Works on FreeBSD 6.2 and linux as well as OSX. Just not on Freebsd 7.0.
was installed through ports with default options.
What changed in freebsd 7 that could cause that? Fix through sysctl option
maybe?
Reproduce code:
---
$fp = stream_socket_client("tcp://www.google.com:80", $errno, $errstr, 0,
STREAM_CLIENT_CONNECT | STREAM_CLIENT_ASYNC_CONNECT);
//sleep(1); <=== works only with sleep uncommented.
if (!$fp) {
echo "$errstr ($errno)\n";
} else {
fwrite($fp, "GET / HTTP/1.0\r\nHost: www.example.com\r\nAccept:
*/*\r\n\r\n");
while (!feof($fp)) {
echo fgets($fp, 1024);
}
fclose($fp);
}
Expected result:
The html output from www.google.com/
Actual result:
--
Locks up after fwrite and never reads anything from the socket. No error.
--
Edit bug report at http://bugs.php.net/?id=44864&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44864&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44864&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44864&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44864&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44864&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44864&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44864&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44864&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44864&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44864&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44864&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44864&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44864&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44864&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44864&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44864&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44864&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44864&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44864&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44864&r=mysqlcfg
#44767 [Com]: Incorrect handling of a closing # to # based comments
ID: 44767 Comment by: whitewolf24 at hotmail dot com Reported By: ikickdogsforfun at hotmail dot com Status: Open Bug Type: Scripting Engine problem Operating System: Gentoo Linux PHP Version: 5.2.6RC5 New Comment: um, last I checked and have read in the manual # comments to the end of the line OR the end of the php block, which ever happens first. not to another # Previous Comments: [2008-04-17 20:49:53] ikickdogsforfun at hotmail dot com Description: A # comment can be closed by a second # causing PHP to act rather oddly. Any errors that occur on the same line but after the closing # are reported as an error on the next line, however if there are no errors anything after the second # is ignored and not processed as if it was a comment. I think based on this, there needs to be some concistency about what happens when a second # is encountered. Are these intended to be embedded comments which can be be closed? Or should everything being ignored after the first # untill a new line character is encountered? Reproduce code: --- This produces 2 errors, one on line 2, one on line 3, though they are both about line 3: This only echos out 'some': Expected result: I would expect to see 'some text' echoed out, as I was under the impression these kinds of comments were imbedded. Actual result: -- See the code section -- Edit this bug report at http://bugs.php.net/?id=44767&edit=1
#44865 [NEW]: max_file_size produces no error
From: jahajee dot com at gmail dot com Operating system: linux PHP version: 4.4.8 PHP Bug Type: *General Issues Bug description: max_file_size produces no error Description: I'm using optional file upload form with max file upload size of 200 Kb .Error check by backend script is done and error reported till the Max file size is 2 Mb (PHP max file size setting) .Since after that if the file size increases no file is actually send and hence the form is processed without any warning to the user. For example if the user uploads file of 1.6 Mb say then he gets an error that the file size is more than 200 Kb but if the uploaded file size is 2.3Mb no file is uploaded and the whole form processed without any error. Saw the same in other discussions but of no help .Can't use the GET method as the upload file is optional in the form. Jahajee Expected result: Expects to warn the user even if the file size is more than 2Mb(PHP Max file size setting) Actual result: -- No error reported and file processed without the uploaded file -- Edit bug report at http://bugs.php.net/?id=44865&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44865&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44865&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44865&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44865&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44865&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44865&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44865&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44865&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44865&r=support Expected behavior:http://bugs.php.net/fix.php?id=44865&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44865&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44865&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44865&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44865&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44865&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44865&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44865&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44865&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44865&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44865&r=mysqlcfg
#44864 [Opn]: STREAM_CLIENT_ASYNC_CONNECT does does not work
ID: 44864
User updated by: fhoenig at kargo dot com
Reported By: fhoenig at kargo dot com
Status: Open
Bug Type: Reproducible crash
Operating System: FreeBSD 7.0 / AMD64
PHP Version: 5.2.5
New Comment:
Actually I cased down the problem a bit further.
socket_select under these conditions is not waiting even is the tv_sec
is set to NULL (in which case it should wait infinitely)
instead of sleep, put: $num_changed_streams = stream_select($rfd, $wfd,
$efd, NULL);
something is wrong with sockets here...
Previous Comments:
[2008-04-29 21:25:52] fhoenig at kargo dot com
Description:
The below code only works with sleeping in between
stream_socket_client() and the first IO on the socket. No error though.
Works on FreeBSD 6.2 and linux as well as OSX. Just not on Freebsd 7.0.
was installed through ports with default options.
What changed in freebsd 7 that could cause that? Fix through sysctl
option maybe?
Reproduce code:
---
$fp = stream_socket_client("tcp://www.google.com:80", $errno, $errstr,
0, STREAM_CLIENT_CONNECT | STREAM_CLIENT_ASYNC_CONNECT);
//sleep(1); <=== works only with sleep uncommented.
if (!$fp) {
echo "$errstr ($errno)\n";
} else {
fwrite($fp, "GET / HTTP/1.0\r\nHost: www.example.com\r\nAccept:
*/*\r\n\r\n");
while (!feof($fp)) {
echo fgets($fp, 1024);
}
fclose($fp);
}
Expected result:
The html output from www.google.com/
Actual result:
--
Locks up after fwrite and never reads anything from the socket. No
error.
--
Edit this bug report at http://bugs.php.net/?id=44864&edit=1
#44862 [Opn->Fbk]: Invalid encoding in pspell_config_create() w/ pspell_new_config() causes abort
ID: 44862
Updated by: [EMAIL PROTECTED]
Reported By: twm at twmacinta dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Red Hat Enterprise Linux ES 3
PHP Version: 5.2.5
New Comment:
Which version of aspell library are you using? here things work as
intended.
Previous Comments:
[2008-04-29 17:18:41] twm at twmacinta dot com
Description:
When I pass an invalid encoding as the fourth argument to the function
pspell_config_create() and then pass that return value to
pspell_new_config(), PHP aborts and stops running. This is causing the
"make test" script named "ext/pspell/tests/003.phpt" to fail on my
system when I try to test my new build of PHP. I have created a simpler
test case for this bug report and also read through the code a bit more
to come up with an analysis which I think might be helpful.
My test script works as expected in older versions of PHP on the same
operating system. In particular, it works fine in PHP 4.3 on the same
OS. This applies to both my custom compiled version of PHP as well as
the most recent build from Red Hat. I believe that the problem was
introduced in revision 1.45.2.4.2.5. See line 405 below:
http://cvs.php.net/viewvc.cgi/php-src/ext/pspell/pspell.c?r1=1.45.2.4.2.4&r2=1.45.2.4.2.5&pathrev=PHP_5_2
The problem is that delete_pspell_manager() is called on a pointer
obtained from new_pspell_manager() which isn't necessarily a pspell
manager. It can either be an error or a pspell manager. Here is the
code from the pspell library - note that the first return statement can
result in PHP getting something which isn't a pspell manager (which is
what it incorrectly frees):
PspellCanHaveError * new_pspell_manager(PspellConfig * c)
{
PspellCanHaveError * possible_err = find_word_list(c);
if (possible_err->error_number() != 0)
return possible_err;
PspellConfig * config = (PspellConfig *)(possible_err);
possible_err = new_pspell_manager_class(config);
delete config;
return possible_err;
}
Perhaps this error isn't being triggered on your test systems since it
depends upon whether the system's pspell library was compiled to enforce
assertions.
Note that there were several other changes like this made in revision
1.45.2.4.2.5. There were other lines added which call
delete_pspell_*(), possibly with an invalid argument. I don't know if
they are a problem in reality - I only caught the line that I'm
reporting because "make test" failed for me. I was a little hesitant to
remove those lines in my own code since they were added without other
major changes, so there was presumably some reason for them, though the
revision comment and change log don't mention what it was.
I used "php -n" to run all of the tests, so as to rule out "php.ini" as
a problem. I tried the test script with both PHP 5.2.5 and the latest
CVS snapshot, php5.2-200804291230.
Reproduce code:
---
$cfg2 = pspell_config_create('en', 'british', '', 'b0rked');
$p2 = pspell_new_config($cfg2);
print("Done\n");
Expected result:
Warning: pspell_new_config(): PSPELL couldn't open the dictionary.
reason: The encoding "b0rked" is not known. This could also mean that
the file "/usr/share/pspell/b0rked.map" could not be opened for reading
or does not exist. in /tmp/timtest20080429.php on line 3
Done
Actual result:
--
Warning: pspell_new_config(): PSPELL couldn't open the dictionary.
reason: The encoding "b0rked" is not known. This could also mean that
the file "/usr/share/pspell/b0rked.map" could not be opened for reading
or does not exist. in /tmp/timtest20080429.php on line 3
php: manager_impl.cc:30: void free_lt_handle(void*): Assertion `s == 0'
failed.
Aborted
--
Edit this bug report at http://bugs.php.net/?id=44862&edit=1
#44863 [Bgs]: isset detects an array item that var_dump does not.
ID: 44863
Updated by: [EMAIL PROTECTED]
Reported By: igordonin at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP SP2
PHP Version: 5.2.5
New Comment:
for the last time, you've $Query['Try_Login'] = "conn_err"; and you're
doing an isset($Query['Try_Login']['Error']);
So, $Query['Try_Login'] is a string.
This is equivalent to $mystring = "conn_err"; and
isset($mystring['Error']) which is equivalent to isset($mystring[0]);
You're wrongly using isset() here, You probably want to check whether
'Error' is a defined index of $Query, so do isset($Query['Error'])..
instead of isset($Query['Try_Login']['Error']).
But really bugs.php.net is not a place for that kind of support, you
should check out php.net/support and find a medium that suits you
better.
Regards.
Previous Comments:
[2008-04-29 19:13:18] igordonin at gmail dot com
Hey, I don't mean to be annoying, hope didn't get there yet, but check
this out:
Query_Repository returns string "conn_err", so it's the same as:
$Query["Try_Login"] = "conn_err";
var_dump( $Query ) results in:
array(1) { ["Try_Login"]=> string(8) "conn_err" }
There's no suck key as ["Error"] at all ...
So what you mean is that isset will recognize
$Query["Try_Login"]["Error"] as $Query["Try_Login"][0] because of the
string offset and then return true?
You may be right, that may be in fact the current behavior, but I don't
see how that can be the best behavior at all!
I'm no expert though. So thank you very much for taking the time to
reply. I do appreciate it.
[2008-04-29 19:03:11] [EMAIL PROTECTED]
Yes this is expected:
non-numeric indexes are interpreted as 0 for string offsets.
so isset($string["foo"]) is equivalent to isset($string[0]) which
checks whether the string offset 0 exists, and it does, your string is
not empty.
[2008-04-29 18:56:29] igordonin at gmail dot com
You're right!
But is this expected to return true?
if (isset($Query["Try_Login"]["Error")) {
unset($Query["Try_Login"]["Error"]);
}
'Cause that's when I'm trying to unset $Query["Try_Login"]["Error"] ...
[2008-04-29 18:51:57] [EMAIL PROTECTED]
Look: $Query is an array that contains a string at the index
"Try_Login". So $Query["Try_Login"] is a string.
You're unsetting $Query["Try_Login"]["Error"] so yes, you're trying to
unset an offset of a string.
[2008-04-29 18:43:26] igordonin at gmail dot com
You're wrong, var_dump says:
array(1) { ["Try_Login"]=> string(8) "conn_err" }
It's so an array!
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/44863
--
Edit this bug report at http://bugs.php.net/?id=44863&edit=1
#38915 [Com]: Apache: system() (and similar) don't cleanup opened handles of Apache
ID: 38915 Comment by: support at ppnhosting dot com Reported By: dimmoborgir at gmail dot com Status: Open Bug Type: Feature/Change Request Operating System: UNIX PHP Version: 5.2.2, 4.4.7 New Comment: 5.2.3 also experiencing this 'bug' to the point of having to manually kill Exim to just Apache restarted.. the mail() function is suffering from the same problem. It is very annoying to see Apache failing to restart, because the MTA (exim via sendmail in our case) is already listening on port *:80 Previous Comments: [2008-03-07 10:45:53] martin at activevb dot de Will this ever be fixed... or shall we better rewrite our 3 lines of PHP code in Perl? :-| Is it possible to use apr_proc_create() and apr_pool_cleanup_for_exec() directly from PHP source code without patching PHP? [2008-02-19 03:59:36] anomie at users dot sf dot net On 29 Jan 6:20pm UTC, adrian dot rollett at unt dot edu wrote: > > For those of you that found this page while looking for info on why > exim is blocking port 80 after inheriting apache's file descriptors, > I believe I found the reason for this. It seems that exim will only > work with a maximum of 1000 file descriptors, (or 256 on older > systems) after which point it will hang, consuming all available cpu > cycles, and preventing apache from restarting. You should submit more detailed information on this to Exim's bug tracking system so it has a chance of being fixed. As far as this ridiculous bug, I've been working around it by using a small program that closes all FDs above 2 (either via the F_CLOSEM fcntl, reading /proc/self/fd, or just blindly calling close for every possible fd) and then execs the real program. [2008-01-29 18:20:39] adrian dot rollett at unt dot edu For those of you that found this page while looking for info on why exim is blocking port 80 after inheriting apache's file descriptors, I believe I found the reason for this. It seems that exim will only work with a maximum of 1000 file descriptors, (or 256 on older systems) after which point it will hang, consuming all available cpu cycles, and preventing apache from restarting. The only possible solutions I have found: 1. modify the source, and re-compile exim with a higher file descriptor limit. 2. run a cron job at regular intervals to search for hung exim processes and kill them. 3. switch MUAs. (postfix may fail more gracefully, but I haven't tried this yet) [2007-12-06 21:41:36] jameskyle at ucla dot edu Whether the blame lie with Apache or PHP is irrelevant. It directly impacts the security of PHP. Thus, the PHP team should work on a fix or apply substantial and vocal pressure on the Apache team. This would at least open discourse and allow the two teams to work toward a solution and determine the quickest path. The fact that this has remained a bug for an entire year is unacceptable. As is the relative silence on the topic from both of the primary development teams. [2007-12-06 20:56:01] gabe-php at mudbugmedia dot com I'm also running into a problem where, because my Apache is hosting 500+ vhosts, gobbling up 1000+ descriptors for logs. All this gets passed to any program it executes, causing problems with processes with a 1024 limit compiled in. Apache might be able to deal with having that many descriptors open, but we shouldn't assume anything PHP execs should. 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/38915 -- Edit this bug report at http://bugs.php.net/?id=38915&edit=1
#44860 [Opn]: session_encode fails for php_binary serialiser
ID: 44860 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: All PHP Version: 6CVS-2008-04-29 (snap) New Comment: string(0) "" ? I get another result... *** Testing session_encode() : variation *** bool(true) Warning: base64_encode() expects parameter 1 to be strictly a binary string, Unicode string given in ... on line 18 NULL bool(true) Previous Comments: [2008-04-29 09:05:46] [EMAIL PROTECTED] Description: I've added a new test into the 6.0 branch called session_encode_variation7.phpt - the expected output for this test shows the problem. It shows that when unicode is enabled the output from session_encode when using the php_binary serialiser is wrong. Reproduce code: --- --TEST-- Test session_encode() function : variation --SKIPIF-- --INI-- session.serialize_handler=php_binary --FILE-- --EXPECTF-- *** Testing session_encode() : variation *** bool(true) string(24) "A2Zvb2k6MTIzNDU2Nzg5MDs=" bool(true) Done --UEXPECTF-- *** Testing session_encode() : variation *** bool(true) string(0) "" bool(true) Done Expected result: --UEXPECTF-- *** Testing session_encode() : variation *** bool(true) unicode(24) "A2Zvb2k6MTIzNDU2Nzg5MDs=" bool(true) Done Actual result: -- --UEXPECTF-- *** Testing session_encode() : variation *** bool(true) string(0) "" bool(true) Done -- Edit this bug report at http://bugs.php.net/?id=44860&edit=1
#44866 [NEW]: curl CURLOPT_INFILE leaks handle reference
From: david at acz dot org Operating system: SLES 10 x86_64 PHP version: 5.2.5 PHP Bug Type: cURL related Bug description: curl CURLOPT_INFILE leaks handle reference Description: File handles are normally closed automatically when the reference count hits zero. For example, if you fopen() something in a function and only assign it to a local variable, the file is closed when the function returns. CURLOPT_INFILE breaks this behavior. Presumably, the curl resource destructor does not decrement the reference count for the file handle. Reproduce code: --- Expected result: bool(true) bool(true) bool(true) Actual result: -- bool(true) bool(true) bool(false) -- Edit bug report at http://bugs.php.net/?id=44866&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44866&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44866&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44866&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44866&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44866&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44866&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44866&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44866&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44866&r=support Expected behavior:http://bugs.php.net/fix.php?id=44866&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44866&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44866&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44866&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44866&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44866&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44866&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44866&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44866&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44866&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44866&r=mysqlcfg
