#44860 [NEW]: session_encode fails for php_binary serialiser

2008-04-29 Thread [EMAIL PROTECTED]
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

2008-04-29 Thread vtsupermok at gmail dot com
 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

2008-04-29 Thread felipe
 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)

2008-04-29 Thread phpbug dot 41539 at sub dot noloop dot net
 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

2008-04-29 Thread phpbug dot 40928 at sub dot noloop dot net
 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

2008-04-29 Thread miha at link-go dot si
 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

2008-04-29 Thread kingoleg at mail dot ru
 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

2008-04-29 Thread pajoye
 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

2008-04-29 Thread php at benjaminschulz dot com
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

2008-04-29 Thread twm at twmacinta dot com
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.

2008-04-29 Thread igordonin at gmail dot com
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.

2008-04-29 Thread colder
 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.

2008-04-29 Thread igordonin at gmail dot com
 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.

2008-04-29 Thread colder
 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.

2008-04-29 Thread igordonin at gmail dot com
 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.

2008-04-29 Thread colder
 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.

2008-04-29 Thread igordonin at gmail dot com
 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

2008-04-29 Thread fhoenig at kargo dot com
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

2008-04-29 Thread whitewolf24 at hotmail dot com
 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

2008-04-29 Thread jahajee dot com at gmail dot com
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

2008-04-29 Thread fhoenig at kargo dot com
 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

2008-04-29 Thread iliaa
 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.

2008-04-29 Thread colder
 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

2008-04-29 Thread support at ppnhosting dot com
 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

2008-04-29 Thread felipe
 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

2008-04-29 Thread david at acz dot org
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