#31933 [Fbk->Opn]: cgi timeout when post forms bigger than 477 bytes

[giulio dot pons at archebit dot com]

 ID:   31933
 User updated by:  giulio dot pons at archebit dot com
 Reported By:  giulio dot pons at archebit dot com
-Status:   Feedback
+Status:   Open
 Bug Type: IIS related
 Operating System: windows 2000
 PHP Version:  4.3.10
 New Comment:

the problem was solved by editing a very very deep setting in the IIS:
the UploadReadAheadSize value with the AC-MetaDataEditTool.exe
downloaded from Microsoft:
http://www.microsoft.com/downloads/details.aspx?FamilyID=48364A72-D54E-46DC-AACF-E3BE887D17A6&displaylang=en


Previous Comments:


[2005-02-12 03:23:41] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2005-02-11 16:16:28] giulio dot pons at archebit dot com

Description:

same problem of another bug reported here (#21660), same test.php.
my PHP version is 4.3.10.
server is microsoft windows 2000.
iis is version 5.
php as cgi.
i've tried many versions of php cause i don't have this problem on
another server with php version 4.3.3.
the textarea posted hang php when it contains a text longer than 377
bytes.
do i have to post other data to you so you can understand better?
thank you very much.
giulio

Reproduce code:
---







Expected result:

blank page

Actual result:
--
the php.exe hangs.
you can see it in the task manager. it doesn't use CPU, only memory.
nothing happens till iis goes in timeout and return the CGI timeout
message.





-- 
Edit this bug report at http://bugs.php.net/?id=31933&edit=1

#32015 [Opn->Fbk]: StrtoTime Function Giving Different Timestamps in different versions

[derick]

 ID:   32015
 Updated by:   [EMAIL PROTECTED]
 Reported By:  rj at meadowbrook dot net
-Status:   Open
+Status:   Feedback
 Bug Type: *Calendar problems
 Operating System: Linux
 PHP Version:  5.0.2
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.0-win32-latest.zip


Previous Comments:


[2005-02-18 04:09:34] rj at meadowbrook dot net

Description:

The exact same function produces two different timestamp results:

PHP 4.3.2
strtotime('12/01/04 9:00 AM');
produces 1101909600

PHP 5.0.2
strtotime('12/01/04 9:00 AM');
produces 1101909622

Any combination produces a result 22 seconds less in 5.0.2 that the
result in 4.3.2

Reproduce code:
---
n/a

Expected result:

n/a

Actual result:
--
n/a





-- 
Edit this bug report at http://bugs.php.net/?id=32015&edit=1

#31933 [Opn->Bgs]: cgi timeout when post forms bigger than 477 bytes

[tony2001]

 ID:   31933
 Updated by:   [EMAIL PROTECTED]
 Reported By:  giulio dot pons at archebit dot com
-Status:   Open
+Status:   Bogus
 Bug Type: IIS related
 Operating System: windows 2000
 PHP Version:  4.3.10
 New Comment:

No PHP bug -> bogus.


Previous Comments:


[2005-02-18 09:24:35] giulio dot pons at archebit dot com

the problem was solved by editing a very very deep setting in the IIS:
the UploadReadAheadSize value with the AC-MetaDataEditTool.exe
downloaded from Microsoft:
http://www.microsoft.com/downloads/details.aspx?FamilyID=48364A72-D54E-46DC-AACF-E3BE887D17A6&displaylang=en



[2005-02-12 03:23:41] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2005-02-11 16:16:28] giulio dot pons at archebit dot com

Description:

same problem of another bug reported here (#21660), same test.php.
my PHP version is 4.3.10.
server is microsoft windows 2000.
iis is version 5.
php as cgi.
i've tried many versions of php cause i don't have this problem on
another server with php version 4.3.3.
the textarea posted hang php when it contains a text longer than 377
bytes.
do i have to post other data to you so you can understand better?
thank you very much.
giulio

Reproduce code:
---







Expected result:

blank page

Actual result:
--
the php.exe hangs.
you can see it in the task manager. it doesn't use CPU, only memory.
nothing happens till iis goes in timeout and return the CGI timeout
message.





-- 
Edit this bug report at http://bugs.php.net/?id=31933&edit=1

#29853 [Com]: Output buffering = Off is slow

[markus dot gawlowicz at 104 dot 6rtl dot com]

 ID:   29853
 Comment by:   markus dot gawlowicz at 104 dot 6rtl dot com
 Reported By:  webmaster at neteject dot com
 Status:   Open
 Bug Type: Performance problem
 Operating System: Windows 2003
 PHP Version:  5.0.0
 New Comment:

did have experienced exatcly the same problems. once the application
was transfered to IIS6 on W2K3 the page runs extremely slow.

have switched the outputt buffering on now("output_bufering=16192" in
php.ini)

the page runs now fast as hell :)

100% success


Previous Comments:


[2005-02-02 15:50:46] tpiper at pinnacle dot co dot uk

We're also getting it with PHP 4.3.10 running on IIS6 on W2K3 Server.
Output Buffing on in php.ini fixes it for us too.



[2005-01-14 18:12:07] m2pc at hotmail dot com

I migrated a large-scale PHP application from Win2K Advanced Server to
Windows 2003 Standard Edition and noticed huge delays and page
timeouts.  I tried switching PHP to CGI instead of ISAPI module and got
HTTP header errors.

Then I tried setting "Output Buffering = On" in my php.ini file,
switched back to ISAPI mode, restarted IIS and now it runs lightning
fast!

It seems to be an issue with IIS6 on the new Windows Server OS, as the
same exact application runs fine on earlier versions of IIS with output
buffering off.



[2004-10-13 18:28:42] matt at cloverbasin dot com

Windows 2003 Standard, IIS6.0, PHP 4.3.2, PHP4ISAPI.dll

PHP page rendering is excrutiatingly slow, static HTML pages still
render quickly.  CGI/PHP.exe does not seem to exhibit this behavior.

The "Output Buffering = On" workaround seemed to be succesful.



[2004-09-02 19:30:29] php at sharpdreams dot com

I also experienced this, and yes it is an IIS issue. AFAIK, output
buffering is the only solution. You can do your own output buffering in
the page if certain blocks need to be pushed to the client (ie, in long
calculations).



[2004-08-26 17:50:00] webmaster at neteject dot com

Description:

PHP 5.0.1 ISAPI Windows 2003 Enterprise Server.

I have tested this on different machines with W2003 Server Enterprise
installed.

I have webppages with a lot of phpchunks with sql and different
calculations.

When have outbuffering to off the page is printed very slow and halts
in almost every chunk. Setting the output to On prints the page fast.

I have tested this on my local network. I have connected to 1 xp
machine and 2 w2003 machines. XP did not have any problems with output
buffering off.

One interesting thing is that the page runs quite fast on the local
computer which makes me wonder if it has any conjunction with how IIS 6
works. Anyway, the fact still remains that running with output buffering
on produces a fast page from anywhere.

Reproduce code:
---







etc...

Expected result:

Page loading in chunks






-- 
Edit this bug report at http://bugs.php.net/?id=29853&edit=1

#32018 [NEW]: mssql_query() doesnt seem to return a postive result identifier on success

[bobpilly at yahoo dot co dot uk]

From: bobpilly at yahoo dot co dot uk
Operating system: Fedora Core 3 2.6.10-1.760_FC3
PHP version:  5.0.3
PHP Bug Type: MSSQL related
Bug description:  mssql_query() doesnt seem to return a postive result 
identifier on success

Description:

I have just upgraded to php 5.0.3 and a simple if statement based on the
identifier that worked with php 5.0.2 no longer works. I have now
downgraded back to php 5.0.2 and everything is working fine again. when
trying a print of $result in 5.0.2 i am returned a '1' character, when
trying the same in 5.0.3 the $result variable is empty. 
I have checked the database and the query in running correctly and the
field is being updated.
May be a case that the function has changed and its not in the online
documentation yet?

Reproduce code:
---
$numero= mssql_connect($dbserver,$dbuser,$dbpass)
or die ("Unable to connect to database server");

$query = "update test_table set phonenum = '$phonenum' where ind =
'$ind'";
$result = mssql_query($query,$numero);
if($result){
  print "update success!";
}
else{
  print "update failure!";
}

Expected result:

update success!

Actual result:
--
update failure!

-- 
Edit bug report at http://bugs.php.net/?id=32018&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=32018&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=32018&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=32018&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32018&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32018&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=32018&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=32018&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=32018&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32018&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=32018&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=32018&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=32018&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32018&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=32018&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32018&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=32018&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32018&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=32018&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=32018&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=32018&r=mysqlcfg

#32018 [Opn->Fbk]: mssql_query() doesnt seem to return a postive result identifier on success

[tony2001]

 ID:   32018
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bobpilly at yahoo dot co dot uk
-Status:   Open
+Status:   Feedback
 Bug Type: MSSQL related
 Operating System: Fedora Core 3 2.6.10-1.760_FC3
 PHP Version:  5.0.3
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php5-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.0-win32-latest.zip




Previous Comments:


[2005-02-18 12:19:41] bobpilly at yahoo dot co dot uk

Description:

I have just upgraded to php 5.0.3 and a simple if statement based on
the identifier that worked with php 5.0.2 no longer works. I have now
downgraded back to php 5.0.2 and everything is working fine again. when
trying a print of $result in 5.0.2 i am returned a '1' character, when
trying the same in 5.0.3 the $result variable is empty. 
I have checked the database and the query in running correctly and the
field is being updated.
May be a case that the function has changed and its not in the online
documentation yet?

Reproduce code:
---
$numero= mssql_connect($dbserver,$dbuser,$dbpass)
or die ("Unable to connect to database server");

$query = "update test_table set phonenum = '$phonenum' where ind =
'$ind'";
$result = mssql_query($query,$numero);
if($result){
  print "update success!";
}
else{
  print "update failure!";
}

Expected result:

update success!

Actual result:
--
update failure!





-- 
Edit this bug report at http://bugs.php.net/?id=32018&edit=1

#31995 [Opn]: Oracle select

[wojciech dot superson at bph dot pl]

 ID:   31995
 User updated by:  wojciech dot superson at bph dot pl
 Reported By:  wojciech dot superson at bph dot pl
 Status:   Open
 Bug Type: OCI8 related
 Operating System: MS Windows 2003 Serwer
 PHP Version:  5.0.3
 New Comment:

I have one more problem, I think it is connected to the original one.
Very often, there is message in apache error.log file "PHP Warning: 
oci_fetch_all() [function.oci-fetch-all]:
OCIFetchStatement: ORA-01001: invalid cursor\n in d:\\program
files\\apache group\\Apache\\htdocs\\moa\\php\\oracle.php on line 188.
The line 188 is within the OracleExecProcSelect function which I have
sent you before.


Previous Comments:


[2005-02-16 10:49:55] wojciech dot superson at bph dot pl

Description:

I use PHP 5.0.3 with Oracle 9.2.0.5.0 on HP-UX 11.11 and Apache 1.3.31.
Aplication works fine and calls the same queries (as Oracle stored
procedures) many times. The problem is that sometimes (more less once
every 30/40 times) query returns only one/two record(s) neverless there
are many records in database for this query. I am not able to reproduce
the problem on wish. I attach the source code of the function I use to
call the Oracle stored procedure for every query in the application.
The name of procedure is passed in $statement variable.


Reproduce code:
---
function OracleExecProcSelect( $conn,$statement,& $results, &
$errorcode=-1, & $errordesc="" )
{   
$curs = oci_new_cursor( $conn );
$stmt = oci_parse( $conn,"begin ".$statement." end;");
if ( ! oci_bind_by_name( $stmt,"data",$curs,-1,OCI_B_CURSOR ) ) return
;
if ( ! oci_bind_by_name( $stmt,":error_code",$errorcode,32 ) ) return
;
if ( ! oci_bind_by_name( $stmt,":error_desc",$errordesc,255 ) ) return
;

oci_execute( $stmt,OCI_DEFAULT );
oci_execute( $curs,OCI_DEFAULT );

$nrows = oci_fetch_all( $curs,$results );

oci_free_statement($stmt);
oci_free_statement($curs);

  return $nrows;
}

Expected result:

I should get the array ($results) with rows returned by the Oracle
stored procedure (its name is passed by $statement variable). It works
fine but sometimes it returns only one/two rows. Then I call this
procedure from sqlplus I get all requested records.






-- 
Edit this bug report at http://bugs.php.net/?id=31995&edit=1

#31931 [Csd->Opn]: image upload returns path and red cross

[website at cellpacksolutions dot com]

 ID:   31931
 User updated by:  website at cellpacksolutions dot com
 Reported By:  website at cellpacksolutions dot com
-Status:   Closed
+Status:   Open
 Bug Type: HTTP related
 Operating System: linux
 PHP Version:  4CVS-2005-02-11 (stable)
 Assigned To:  iliaa
 New Comment:

Hi, the host has just updated to the latest cvs, however this problem
still exists!


Previous Comments:


[2005-02-15 01:29:06] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





[2005-02-14 22:39:45] tech at rzpressure dot co dot uk

i get this to, it seems as though basename is no longer stripping
windows paths. mind this seems to only affect ie browsers!



[2005-02-14 12:36:35] website at cellpacksolutions dot com

I have tried using the basic upload code posted on the following
thread:

http://www.phpfreaks.com/forums/index.php?showtopic=52077&pid=202571&st=0&#entry202571

which returns:

File (C:\\SEARCH PROGRAM\\product_pics\\3b880.jpg) uploaded!
testupload C:\\SEARCH PROGRAM\\product_pics\\3b880.jpg jpg 

scrolling over and selecting properties of the link shows:

http://domainname.co.uk/testupload/C://SEARCH

this is using the latest cvs version 9 am this morning!



[2005-02-14 12:23:52] website at cellpacksolutions dot com

just recieved this comment from our hosts this morning:

We have tested the most recent available snapshot (9:30am) and the bug
regarding PHP file uploads is still present.  I would advise using the
temporary workaround (all it does is remove everything upto and include
the
final \ thus providing you with only the filename) until the issue is
resolved with PHP 4.3.11.

As advised, unfortunately we are unable to revert back to 4.3.10 as
this
contains severe vulnerabilities which we are unable to allow to exist
on our
systems.  I will leave this ticket suspended in our queue and when we
have
further information for you we will mail you again.



[2005-02-12 17:48:18] [EMAIL PROTECTED]

Already fixed in CVS. (Can't reproduce with 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/31931

-- 
Edit this bug report at http://bugs.php.net/?id=31931&edit=1

#32019 [NEW]: Auto EXPLAIN feature of mysql.trace_mode doesn't work on MySQL 4.1

[[EMAIL PROTECTED]]

From: [EMAIL PROTECTED]
Operating system: All
PHP version:  5.0.3
PHP Bug Type: MySQL related
Bug description:  Auto EXPLAIN feature of mysql.trace_mode doesn't work on 
MySQL 4.1

Description:

MySQL 4.1 and greater return more information in EXPLAIN than older
version. Thus "automatic EXPLAIN on every SELECT" feature of
mysql.trace_mode doesn't work.

MySQL 4.0 and earlier return join type in 2nd column, 4.1 and greater in
4th column.

Moreover, full index scan is represented by "index" and not "INDEX" type.
See http://dev.mysql.com/doc/mysql/en/explain.html

The problem lies on line 1256 of ext/mysql/php_mysql.c, revision 1.210.

In my eyes, this feature of mysql.trace_mode is unnecessary and can be
removed as the full table scan and full index scan can be perfectly valid
in some cases and shouldn't produce an error. But if it will be kept, it
should work on all MySQL versions.

Reproduce code:
---



Expected result:

Your query requires a full tablescan ...

Actual result:
--
Nothing.

-- 
Edit bug report at http://bugs.php.net/?id=32019&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=32019&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=32019&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=32019&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32019&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32019&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=32019&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=32019&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=32019&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32019&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=32019&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=32019&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=32019&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32019&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=32019&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32019&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=32019&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32019&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=32019&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=32019&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=32019&r=mysqlcfg

#32011 [Opn->Csd]: Fragments witch replaced Nodes are not globaly useable

[rrichards]

 ID:   32011
 Updated by:   [EMAIL PROTECTED]
 Reported By:  clynx at succont dot de
-Status:   Open
+Status:   Closed
 Bug Type: DOM XML related
 Operating System: FreeBSD 4.11
 PHP Version:  5.0.3
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2005-02-17 16:17:26] clynx at succont dot de

Description:

DomDocumentFragments witch replaced existing Nodes in a DomDocument is
not globaly useable.

 * Create a DocumentFragment on an existing DomDocument.
 * Append one (or more) Child to this Fragment
 * Replace existing Node with this Fragment

The Methods DomDocument->saveXML() displays the Document in the right
way. 
When you use getElementsByTagName, XPath, or e.g. the XSL Extension
these new Elements are not there.

So in the Example the  will never be useable, only
viewable.

Reproduce code:
---




XMLCONTENT;

$dom = new DomDocument;
$dom->loadXML( $xmlData );

$fragment = $dom->createDocumentFragment();
$replacement = $dom->createElement( 'replacement' );
$fragment->appendChild( $replacement );
$additionalNode = $dom->createElement( 'additionalNode' );
$fragment->appendChild( $additionalNode );

foreach( $dom->getElementsByTagName( 'replace' ) AS $node ) {
$node->parentNode->replaceChild( $fragment, $node );
}

echo "replacement tags found: " . $dom->getElementsByTagName(
'replacment' )->length . "\n\n";
echo "xml code used:\n";
echo $dom->saveXML();
?>

Expected result:

replacement tags found: 0

xml code used:





Actual result:
--
replacement tags found: 1

xml code used:









-- 
Edit this bug report at http://bugs.php.net/?id=32011&edit=1

#31984 [Opn]: sessions fail randomly, causes a segmentation fault in apache

[root at mediamonks dot net]

 ID:   31984
 User updated by:  root at mediamonks dot net
 Reported By:  root at mediamonks dot net
 Status:   Open
 Bug Type: Session related
 Operating System: FreeBSD 4.11-STABLE
 PHP Version:  5.0.3
 New Comment:

I thought I'd give the mm handler a try as a workaround, but the same
problem is present there:

PHP Fatal error:  Unknown: Cannot find save handler \x02 in Unknown on
line 0
[Fri Feb 18 13:08:04 2005] [notice] child pid 73434 exit signal
Segmentation fault (11)


Previous Comments:


[2005-02-16 16:02:35] root at mediamonks dot net

That CVS build has screwed even more on my system...

Log file records:

httpd in free(): warning: page is already free
httpd in free(): warning: page is already free
httpd in free(): warning: page is already free
httpd in free(): warning: page is already free
Allowed memory size of 16777216 bytes exhausted (tried to allocate 1
bytes)
httpd in free(): warning: page is already free
httpd in free(): warning: page is already free
httpd in free(): warning: page is already free
httpd in free(): warning: page is already free
httpd in free(): warning: page is already free
httpd in free(): warning: page is already free
httpd in free(): warning: page is already free
httpd in free(): warning: page is already free
httpd in free(): warning: page is already free
httpd in free(): warning: page is already free
[Wed Feb 16 16:00:54 2005] [notice] child pid 21258 exit signal
Segmentation fault (11)

This repeats thousands of times, apache children segfault after each 10
or so, original save handler error remains.



[2005-02-16 00:23:58] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.0-win32-latest.zip





[2005-02-15 14:30:56] root at mediamonks dot net

with notices on the log file records:

PHP Fatal error:  Unknown: Cannot find save handler \x02 in Unknown on
line 0
PHP Fatal error:  Unknown: Cannot find save handler \x02 in Unknown on
line 0
PHP Fatal error:  Unknown: Cannot find save handler \x02 in Unknown on
line 0
[Tue Feb 15 14:27:45 2005] [notice] child pid 83780 exit signal
Segmentation fault (11)
[Tue Feb 15 14:27:45 2005] [notice] child pid 83776 exit signal
Segmentation fault (11)
[Tue Feb 15 14:27:45 2005] [notice] child pid 83710 exit signal
Segmentation fault (11)
PHP Fatal error:  Unknown: Cannot find save handler \x02 in Unknown on
line 0
PHP Fatal error:  Unknown: Cannot find save handler \x02 in Unknown on
line 0
[Tue Feb 15 14:27:48 2005] [notice] child pid 83752 exit signal
Segmentation fault (11)
[Tue Feb 15 14:27:48 2005] [notice] child pid 83713 exit signal
Segmentation fault (11)



[2005-02-15 13:44:44] root at mediamonks dot net

Description:

Apache 2.0.53 & mod_php5 5.0.3

Sessions occasionally work, but in two-thirds of the session requests
an error is generated and the apache child segfaults.

Error recorded in the logfile:

PHP Fatal error:  Unknown: Cannot find save handler \x02 in Unknown on
line 0

Error reported on site:

Notice: Undefined variable: HTTP_SESSION_VARS in 
Notice: Undefined variable: _SESSION in in 
Warning: session_register() [function.session-register]: Cannot find
save handler  in 
Warning: session_register() [function.session-register]: Cannot find
save handler  in 

I'm using php.ini-recommended as php.ini.

Tried commenting out session.save_handler, setting it to "files" and
just files.

Reproduce code:
---
session_start();






-- 
Edit this bug report at http://bugs.php.net/?id=31984&edit=1

#32020 [NEW]: NULL is saved as 0 in variables

[dreeh at ets-online dot de]

From: dreeh at ets-online dot de
Operating system: Linux
PHP version:  4.3.10
PHP Bug Type: Scripting Engine problem
Bug description:  NULL is saved as 0 in variables

Description:

when i assign NULL to a variable, it's saved as 0.
see my example...



Reproduce code:
---
$variable[0] = NULL;
$variable[1] = null;
$variable[2] = 0;
$variable[3] = "";

Expected result:

i'm expecting:

Array
(
[0] => 
[1] => 
[2] => 0
[3] => 
)

Actual result:
--
i'm getting this:

Array
(
[0] => 0
[1] => 
[2] => 0
[3] => 
)

-- 
Edit bug report at http://bugs.php.net/?id=32020&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=32020&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=32020&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=32020&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32020&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32020&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=32020&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=32020&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=32020&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32020&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=32020&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=32020&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=32020&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32020&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=32020&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32020&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=32020&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32020&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=32020&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=32020&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=32020&r=mysqlcfg

#32018 [Fbk->Opn]: mssql_query() doesnt seem to return a postive result identifier on success

[bobpilly at yahoo dot co dot uk]

 ID:   32018
 User updated by:  bobpilly at yahoo dot co dot uk
 Reported By:  bobpilly at yahoo dot co dot uk
-Status:   Feedback
+Status:   Open
 Bug Type: MSSQL related
 Operating System: Fedora Core 3 2.6.10-1.760_FC3
 PHP Version:  5.0.3
 New Comment:

Hi

Thanks very much this worked with no problems at all.


Previous Comments:


[2005-02-18 12:29:14] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.0-win32-latest.zip





[2005-02-18 12:19:41] bobpilly at yahoo dot co dot uk

Description:

I have just upgraded to php 5.0.3 and a simple if statement based on
the identifier that worked with php 5.0.2 no longer works. I have now
downgraded back to php 5.0.2 and everything is working fine again. when
trying a print of $result in 5.0.2 i am returned a '1' character, when
trying the same in 5.0.3 the $result variable is empty. 
I have checked the database and the query in running correctly and the
field is being updated.
May be a case that the function has changed and its not in the online
documentation yet?

Reproduce code:
---
$numero= mssql_connect($dbserver,$dbuser,$dbpass)
or die ("Unable to connect to database server");

$query = "update test_table set phonenum = '$phonenum' where ind =
'$ind'";
$result = mssql_query($query,$numero);
if($result){
  print "update success!";
}
else{
  print "update failure!";
}

Expected result:

update success!

Actual result:
--
update failure!





-- 
Edit this bug report at http://bugs.php.net/?id=32018&edit=1

#32014 [Opn->Bgs]: Last-Modified is set to PHP file mtime

[tony2001]

 ID:   32014
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ceefour at gauldong dot net
-Status:   Open
+Status:   Bogus
 Bug Type: Session related
 Operating System: All
 PHP Version:  5.0.3
 New Comment:

This is expected behaviour, use header("Last-Modified: ..."); to change
the default value of this header.


Previous Comments:


[2005-02-18 02:00:43] ceefour at gauldong dot net

Description:

When using 'public' or 'private' cache limiter (maybe other cache
limiters, except 'nocache'), PHP will output the PHP script's mtime as
the Last-Modified header. While this is okay for some purposes, the
dynamic nature of PHP scripts make this a bad "feature".

It's possible to circumvent this problem by manually sending a header()
but IMHO this should never be necessary.

My proposal would be to change these affected limiters to either not
output Last-Modified or output a current time Last-Modified header
using the format date('D, d M Y H:i:s O'). Note that date('r') doesn't
work in some cases.






-- 
Edit this bug report at http://bugs.php.net/?id=32014&edit=1

#31995 [Opn->Fbk]: Oracle select

[tony2001]

 ID:   31995
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wojciech dot superson at bph dot pl
-Status:   Open
+Status:   Feedback
 Bug Type: OCI8 related
 Operating System: MS Windows 2003 Serwer
 PHP Version:  5.0.3
 New Comment:

How could we reproduce it?


Previous Comments:


[2005-02-18 12:13:32] wojciech dot superson at bph dot pl

I have one more problem, I think it is connected to the original one.
Very often, there is message in apache error.log file "PHP Warning: 
oci_fetch_all() [function.oci-fetch-all]:
OCIFetchStatement: ORA-01001: invalid cursor\n in d:\\program
files\\apache group\\Apache\\htdocs\\moa\\php\\oracle.php on line 188.
The line 188 is within the OracleExecProcSelect function which I have
sent you before.



[2005-02-16 10:49:55] wojciech dot superson at bph dot pl

Description:

I use PHP 5.0.3 with Oracle 9.2.0.5.0 on HP-UX 11.11 and Apache 1.3.31.
Aplication works fine and calls the same queries (as Oracle stored
procedures) many times. The problem is that sometimes (more less once
every 30/40 times) query returns only one/two record(s) neverless there
are many records in database for this query. I am not able to reproduce
the problem on wish. I attach the source code of the function I use to
call the Oracle stored procedure for every query in the application.
The name of procedure is passed in $statement variable.


Reproduce code:
---
function OracleExecProcSelect( $conn,$statement,& $results, &
$errorcode=-1, & $errordesc="" )
{   
$curs = oci_new_cursor( $conn );
$stmt = oci_parse( $conn,"begin ".$statement." end;");
if ( ! oci_bind_by_name( $stmt,"data",$curs,-1,OCI_B_CURSOR ) ) return
;
if ( ! oci_bind_by_name( $stmt,":error_code",$errorcode,32 ) ) return
;
if ( ! oci_bind_by_name( $stmt,":error_desc",$errordesc,255 ) ) return
;

oci_execute( $stmt,OCI_DEFAULT );
oci_execute( $curs,OCI_DEFAULT );

$nrows = oci_fetch_all( $curs,$results );

oci_free_statement($stmt);
oci_free_statement($curs);

  return $nrows;
}

Expected result:

I should get the array ($results) with rows returned by the Oracle
stored procedure (its name is passed by $statement variable). It works
fine but sometimes it returns only one/two rows. Then I call this
procedure from sqlplus I get all requested records.






-- 
Edit this bug report at http://bugs.php.net/?id=31995&edit=1

#32018 [Opn->Csd]: mssql_query() doesnt seem to return a postive result identifier on success

[tony2001]

 ID:   32018
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bobpilly at yahoo dot co dot uk
-Status:   Open
+Status:   Closed
 Bug Type: MSSQL related
 Operating System: Fedora Core 3 2.6.10-1.760_FC3
 PHP Version:  5.0.3


Previous Comments:


[2005-02-18 13:52:50] bobpilly at yahoo dot co dot uk

Hi

Thanks very much this worked with no problems at all.



[2005-02-18 12:29:14] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.0-win32-latest.zip





[2005-02-18 12:19:41] bobpilly at yahoo dot co dot uk

Description:

I have just upgraded to php 5.0.3 and a simple if statement based on
the identifier that worked with php 5.0.2 no longer works. I have now
downgraded back to php 5.0.2 and everything is working fine again. when
trying a print of $result in 5.0.2 i am returned a '1' character, when
trying the same in 5.0.3 the $result variable is empty. 
I have checked the database and the query in running correctly and the
field is being updated.
May be a case that the function has changed and its not in the online
documentation yet?

Reproduce code:
---
$numero= mssql_connect($dbserver,$dbuser,$dbpass)
or die ("Unable to connect to database server");

$query = "update test_table set phonenum = '$phonenum' where ind =
'$ind'";
$result = mssql_query($query,$numero);
if($result){
  print "update success!";
}
else{
  print "update failure!";
}

Expected result:

update success!

Actual result:
--
update failure!





-- 
Edit this bug report at http://bugs.php.net/?id=32018&edit=1

#32021 [NEW]: Crash caused by range('', 'z')

[mueller_rainer at gmx dot de]

From: mueller_rainer at gmx dot de
Operating system: 
PHP version:  5.0.3
PHP Bug Type: Reproducible crash
Bug description:  Crash caused by range('', 'z')

Description:

If you use '' as the first parameter and a non-empty string as second
parameter for range() PHP crashes/produces a segfault.

Tested on Windows with 5.0.3 and also on Linux with CVS Snapshot PHP
5.0.4-dev.

Reproduce code:
---
$foo = range('', 'z');

Expected result:

range() should return an empty array.


-- 
Edit bug report at http://bugs.php.net/?id=32021&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=32021&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=32021&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=32021&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32021&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32021&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=32021&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=32021&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=32021&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32021&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=32021&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=32021&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=32021&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32021&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=32021&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32021&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=32021&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32021&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=32021&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=32021&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=32021&r=mysqlcfg

#32020 [Opn->Fbk]: NULL is saved as 0 in variables

[tony2001]

 ID:   32020
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dreeh at ets-online dot de
-Status:   Open
+Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  4.3.10
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Can't reproduce.


Previous Comments:


[2005-02-18 13:50:14] dreeh at ets-online dot de

Description:

when i assign NULL to a variable, it's saved as 0.
see my example...



Reproduce code:
---
$variable[0] = NULL;
$variable[1] = null;
$variable[2] = 0;
$variable[3] = "";

Expected result:

i'm expecting:

Array
(
[0] => 
[1] => 
[2] => 0
[3] => 
)

Actual result:
--
i'm getting this:

Array
(
[0] => 0
[1] => 
[2] => 0
[3] => 
)





-- 
Edit this bug report at http://bugs.php.net/?id=32020&edit=1

#32022 [NEW]: Wrong implementation of mssql.datetimeconvert=Off

[akukula at navopgd dot pl]

From: akukula at navopgd dot pl
Operating system: Mandrake Linux 10.1
PHP version:  4.3.8
PHP Bug Type: MSSQL related
Bug description:  Wrong implementation of mssql.datetimeconvert=Off

Description:

Turning off mssql.datetimeconvert causes dates returned from SQL queries
to be shifted one month back.

The bug is in line 892 of php_mssql.c,v 1.86.2.41

According to description found in:



dbdatecrack() returns month in range 0...11. So in sprintf() the argument
dateinfo.month should become dateinfo.month+1

Reproduce code:
---
mssql_query("SELECT CONVERT(DATETIME, '2005-01-01')");
$a = mssql_fetch_row($res); echo $a[0] . "\n";
mssql_query("SELECT CONVERT(DATETIME, '2005-12-01')");
$a = mssql_fetch_row($res); echo $a[0] . "\n";


Expected result:

2005-01-01 00:00:00
2005-12-01 00:00:00


Actual result:
--
2005-00-01 00:00:00
2005-11-01 00:00:00


-- 
Edit bug report at http://bugs.php.net/?id=32022&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=32022&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=32022&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=32022&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32022&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32022&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=32022&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=32022&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=32022&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32022&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=32022&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=32022&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=32022&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32022&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=32022&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32022&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=32022&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32022&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=32022&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=32022&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=32022&r=mysqlcfg

#32022 [Opn->Bgs]: Wrong implementation of mssql.datetimeconvert=Off

[fmk]

 ID:   32022
 Updated by:   [EMAIL PROTECTED]
 Reported By:  akukula at navopgd dot pl
-Status:   Open
+Status:   Bogus
 Bug Type: MSSQL related
 Operating System: Mandrake Linux 10.1
 PHP Version:  4.3.8
 New Comment:

FreeTDS should be compiled using --enable-msdblib if you are compiling
php with --with-mssql.


Previous Comments:


[2005-02-18 16:03:22] akukula at navopgd dot pl

Description:

Turning off mssql.datetimeconvert causes dates returned from SQL
queries to be shifted one month back.

The bug is in line 892 of php_mssql.c,v 1.86.2.41

According to description found in:



dbdatecrack() returns month in range 0...11. So in sprintf() the
argument dateinfo.month should become dateinfo.month+1

Reproduce code:
---
mssql_query("SELECT CONVERT(DATETIME, '2005-01-01')");
$a = mssql_fetch_row($res); echo $a[0] . "\n";
mssql_query("SELECT CONVERT(DATETIME, '2005-12-01')");
$a = mssql_fetch_row($res); echo $a[0] . "\n";


Expected result:

2005-01-01 00:00:00
2005-12-01 00:00:00


Actual result:
--
2005-00-01 00:00:00
2005-11-01 00:00:00






-- 
Edit this bug report at http://bugs.php.net/?id=32022&edit=1

#32020 [Opn->Bgs]: NULL is saved as 0 in variables

[tony2001]

 ID:   32020
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dreeh at ets-online dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  4.3.10
 New Comment:

Do not file bugs when you have Zend extensions (zend_extension=)
loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache,
APC, Xdebug and ionCube loader.  These extensions often modify engine
behavior which is not related to PHP itself.

That's eAccelerator bug and it has nothing to do with PHP itself.


Previous Comments:


[2005-02-18 14:34:11] dreeh at ets-online dot de

i can reproduce it.

the problem ist only existent, if

- i run php with normal php-sourcecode files
- i run php with eaccelerator with (eaccelerator-encoded) php-compiled
files

the problem is not repuducable, if

- i run php with eaccelerator and normal php-sourcecode files



[2005-02-18 14:14:55] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Can't reproduce.



[2005-02-18 13:50:14] dreeh at ets-online dot de

Description:

when i assign NULL to a variable, it's saved as 0.
see my example...



Reproduce code:
---
$variable[0] = NULL;
$variable[1] = null;
$variable[2] = 0;
$variable[3] = "";

Expected result:

i'm expecting:

Array
(
[0] => 
[1] => 
[2] => 0
[3] => 
)

Actual result:
--
i'm getting this:

Array
(
[0] => 0
[1] => 
[2] => 0
[3] => 
)





-- 
Edit this bug report at http://bugs.php.net/?id=32020&edit=1

#32022 [Bgs->Opn]: Wrong implementation of mssql.datetimeconvert=Off

[akukula at navopgd dot pl]

 ID:   32022
 User updated by:  akukula at navopgd dot pl
 Reported By:  akukula at navopgd dot pl
-Status:   Bogus
+Status:   Open
 Bug Type: MSSQL related
 Operating System: Mandrake Linux 10.1
 PHP Version:  4.3.8
 New Comment:

This is not bogus and I ask you to apply this simple fix. This
sprintf() violates dbdatecrack() specification. sprintf() prints
invalid date and recompilation of external library is not a fix.


Previous Comments:


[2005-02-18 16:20:08] [EMAIL PROTECTED]

FreeTDS should be compiled using --enable-msdblib if you are compiling
php with --with-mssql.



[2005-02-18 16:03:22] akukula at navopgd dot pl

Description:

Turning off mssql.datetimeconvert causes dates returned from SQL
queries to be shifted one month back.

The bug is in line 892 of php_mssql.c,v 1.86.2.41

According to description found in:



dbdatecrack() returns month in range 0...11. So in sprintf() the
argument dateinfo.month should become dateinfo.month+1

Reproduce code:
---
mssql_query("SELECT CONVERT(DATETIME, '2005-01-01')");
$a = mssql_fetch_row($res); echo $a[0] . "\n";
mssql_query("SELECT CONVERT(DATETIME, '2005-12-01')");
$a = mssql_fetch_row($res); echo $a[0] . "\n";


Expected result:

2005-01-01 00:00:00
2005-12-01 00:00:00


Actual result:
--
2005-00-01 00:00:00
2005-11-01 00:00:00






-- 
Edit this bug report at http://bugs.php.net/?id=32022&edit=1

#32023 [NEW]: move_uploaded_file ignore destination and put to default tmp

[sopak at matrixway dot cz]

From: sopak at matrixway dot cz
Operating system: linux
PHP version:  4.3.10
PHP Bug Type: Filesystem function related
Bug description:  move_uploaded_file ignore destination and put to default tmp 

Description:

move_uploaded_file ignore destination 

if destination  contains  any relative path function will put file to
default tmp(and no error message is sent, and strip relative path) ,
without(move to actual position) path or with absolute path will function
move file to right destination

I used php 4.3.10
safe_mode on
base_dir I checked  twice ;]

I can tell this  bug was not in 4.3.9

Reproduce code:
---
   
$downloadDir="./tmp"; //local TMP dir in my space
   
$file=$downloadDir."upload_".md5($HTTP_POST_FILES['file']['tmp_name']);
   
move_uploaded_file($HTTP_POST_FILES['file']['tmp_name'],$file);

//file  is  stored in /tmp/$file have to be  in ./tmp/$file


-- 
Edit bug report at http://bugs.php.net/?id=32023&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=32023&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=32023&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=32023&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32023&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32023&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=32023&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=32023&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=32023&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32023&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=32023&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=32023&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=32023&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32023&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=32023&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32023&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=32023&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32023&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=32023&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=32023&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=32023&r=mysqlcfg

#32024 [NEW]: fclose(STDIN|STDOUT|STDERR) has no effect

[davidcrawford at sympatico dot ca]

From: davidcrawford at sympatico dot ca
Operating system: FreeBSD4.10
PHP version:  5.0.3
PHP Bug Type: CGI related
Bug description:  fclose(STDIN|STDOUT|STDERR) has no effect

Description:

I am trying to run a simple PHP script in the background (as a daemon)
using the PHP 5 CLI. I first set the execution time limit to 0 (no limit),
and then I attempt to close STDIN, STDOUT, STDERR using fclose(), but the
pipes are _NOT_ being closed.

This problem seems quite similar to bug #27865, which is labelled as
"fixed", but the behaviour I am getting in this instance is not as
documented.

Reproduce code:
---
set_time_limit(0);

fclose(STDIN);
fclose(STDOUT);
fclose(STDERR);

sleep(...sync timing with system clock...);

while (TRUE) {
   system(...generate call...);
   sleep(...sleep some more...);
} // END while

Expected result:

After invocation from the command line, the program should close all STD
pipes, and run in the background. A new prompt should appear in the shell,
ready to accept my next command while the PHP script is running in the
background without open pipes to my current terminal.

Actual result:
--
A new command prompt does not appear, instead the terminal hangs in
suspense waiting for the process to complete. The script is designed to
run forever in a tight loop. Hitting Ctrl+C gets the command prompt back,
but interrupts and kills the PHP process.

I can get the desired result by using I/O tricks from the command line:

./script.php &

But, this solution has limitations.

-- 
Edit bug report at http://bugs.php.net/?id=32024&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=32024&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=32024&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=32024&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32024&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32024&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=32024&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=32024&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=32024&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32024&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=32024&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=32024&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=32024&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32024&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=32024&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32024&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=32024&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32024&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=32024&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=32024&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=32024&r=mysqlcfg

#32006 [Fbk->Opn]: convert_uudecode not always working

[hoarau76 at free dot fr]

 ID:   32006
 User updated by:  hoarau76 at free dot fr
 Reported By:  hoarau76 at free dot fr
-Status:   Feedback
+Status:   Open
 Bug Type: Strings related
 Operating System: windows XP pro
 PHP Version:  5.0.3
 New Comment:

I gave all information you need to check this bug.
If you need something more, please tell me what you need EXACTLY


Previous Comments:


[2005-02-17 08:15:25] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.




[2005-02-17 01:23:05] hoarau76 at free dot fr

Description:

I can't uudecode a string
it works under perl or winrar, but not with php 5.03

Reproduce code:
---
http://www.chez.com/hoarau/bad_size.alt.binaries.picture.erotica.breasts.natural.87617";);

   if (preg_match("/begin ([0-7]+) (.+)\r?\n(.+)\r?\nend/Us", $data,
$part))
{
$file = convert_uudecode($part[3]);
}
 
?>

Expected result:

I expect this script to work but it doesn't and gave me:

PHP Warning:  convert_uudecode(): The given parameter is not a valid
uuencoded s
tring. in C:\a.php on line 7






-- 
Edit this bug report at http://bugs.php.net/?id=32006&edit=1

#32024 [Bgs]: fclose(STDIN|STDOUT|STDERR) has no effect

[davidcrawford at sympatico dot ca]

 ID:   32024
 User updated by:  davidcrawford at sympatico dot ca
 Reported By:  davidcrawford at sympatico dot ca
 Status:   Bogus
 Bug Type: CGI related
 Operating System: FreeBSD4.10
 PHP Version:  5.0.3
 New Comment:

I re-compiled my PHP CGI/CLI with --enable-pcntl after reading up on
the PCNTL extension capabilities.

Thank you very much for pointing out the error in my method, I am glad
that this was not a PHP issue.


Previous Comments:


[2005-02-18 20:17:18] [EMAIL PROTECTED]

For a process to detach from the shell, you need to fork off a child
and exit from the parent.




[2005-02-18 20:10:07] davidcrawford at sympatico dot ca

Description:

I am trying to run a simple PHP script in the background (as a daemon)
using the PHP 5 CLI. I first set the execution time limit to 0 (no
limit), and then I attempt to close STDIN, STDOUT, STDERR using
fclose(), but the pipes are _NOT_ being closed.

This problem seems quite similar to bug #27865, which is labelled as
"fixed", but the behaviour I am getting in this instance is not as
documented.

Reproduce code:
---
set_time_limit(0);

fclose(STDIN);
fclose(STDOUT);
fclose(STDERR);

sleep(...sync timing with system clock...);

while (TRUE) {
   system(...generate call...);
   sleep(...sleep some more...);
} // END while

Expected result:

After invocation from the command line, the program should close all
STD pipes, and run in the background. A new prompt should appear in the
shell, ready to accept my next command while the PHP script is running
in the background without open pipes to my current terminal.

Actual result:
--
A new command prompt does not appear, instead the terminal hangs in
suspense waiting for the process to complete. The script is designed to
run forever in a tight loop. Hitting Ctrl+C gets the command prompt
back, but interrupts and kills the PHP process.

I can get the desired result by using I/O tricks from the command
line:

./script.php &

But, this solution has limitations.





-- 
Edit this bug report at http://bugs.php.net/?id=32024&edit=1

#25876 [Com]: session_start(): Failed to initialize storage module

[friend at nowhere dot com]

 ID:   25876
 Comment by:   friend at nowhere dot com
 Reported By:  golden at riscom dot com
 Status:   Feedback
 Bug Type: Session related
 Operating System: freebsd 4.8
 PHP Version:  4.3.9-4.3.10
 New Comment:

Set "session.use_trans_sid = 0" in your php.ini.  Problem solved!


Previous Comments:


[2005-02-13 15:32:00] johan at dotco dot co dot za

I've had the same problem after upgrading to PHP 4.3.10, in that I also
started getting "Fatal error: session_start(): Failed to initialize
storage module: user (path: /tmp) " every now and then.  The solution
was to upgrade to the latest ZendOptimizer here:
http://zend.com/store/products/zend-optimizer.php.  There is a comment
posted about an "incompatibility" with older ZendOptimizer versions on
the Zend site.  I believe they are refering to this error.



[2005-02-12 03:55:39] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2004-12-27 18:44:50] bugs dot php dot net at spacedump dot pp dot se

I have the same problem and added 'php_admin_value session.save_handler
files' to a couple of virtualhosts in my apache configuration.
The problem seem to dissapear then.

(Of course since the child changes it settings to the ones in the
virtual host definition (i suppose))

(Maybe do some fancy thing that sets this to it's default value when
the child gets the request?)



[2004-12-27 16:47:04] mak123 at poczta dot onet dot pl

strange - I face this problem about week after upgrading to php.4.3.10
(apache 1.3.33, rh.es.3). first few days without any error ...
meanwhile no updates, tripwire shows no changes in any system files...



[2004-12-27 16:09:31] onno at triptic dot nl

I should probably mention that more sites use this machine, and I don't
know in which way they are using sessions that might give conflicts or
something.



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/25876

-- 
Edit this bug report at http://bugs.php.net/?id=25876&edit=1