#44249 [NEW]: build test failed

2008-02-25 Thread jthrom2 at uiuc dot edu
From: jthrom2 at uiuc dot edu
Operating system: Fedora 7
PHP version:  5.2.5
PHP Bug Type: Compile Failure
Bug description:  build test failed

Description:

Installing PHP to use with MythWeb



Reproduce code:
---
./configure --with-mysql --with-apache=../apache_1.3.41

this appears down the page

Configuring extensions
checking whether to enable LIBXML support... yes
checking libxml2 install dir... no
checking for xml2-config path... /usr/bin/xml2-config
checking whether libxml build works... no
configure: error: build test failed.  Please check the config.log for
details.

Actual result:
--
from config.log

configure:20055: gcc -o conftest -g -O2   conftest.c 
  
 -lresolv -lm -ldl -lnsl  -lxml2 -lz -lm 1>&5
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for
-lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: cannot find -lz
collect2: ld returned 1 exit status
configure: failed program was:
#line 20044 "configure"
#include "confdefs.h"


char xmlInitParser();
int main() {
  xmlInitParser();
  return 0;
}

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


#43492 [Bgs]: problems with closing statements when selecting cursors

2008-02-25 Thread sixd
 ID:   43492
 Updated by:   [EMAIL PROTECTED]
 Reported By:  michael dot virnstein at brodos dot de
 Status:   Bogus
 Bug Type: OCI8 related
 Operating System: Linux
 PHP Version:  5.2.5
 New Comment:

With the fix for Bug #44206, the original testcase succeeds.  However
it is good practice to explicitly close cursors when they are no longer
needed.


Previous Comments:


[2008-02-21 19:33:32] [EMAIL PROTECTED]

Also see http://bugs.php.net/bug.php?id=44206



[2007-12-11 20:15:58] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

My colleague looked at this and sent the update below.  Note the two
added lines to the testcase allow the script to complete successfully.

/*

While fetching the data from the ref cursor, the parent statement
needs to be around.  It makes sense that the refcount of the statement
is to be incremented.  In the test case provided, the parent statement
goes out of scope before fetching the data from the ref cursor.  Also
when the parent statement goes out of scope, it is not released which
is causing the leak.

*/

function fetch($c, $i) {
global $s;   // ADDED
$s = ociparse($c, 'select cursor(select * from bug43492_tab) c from
bug43492_tab');
ociexecute($s, OCI_DEFAULT);
ocifetchinto($s, $result, OCI_ASSOC);
ociexecute($result['C'], OCI_DEFAULT);
return $result['C'];
}

for($i = 0; $i < 300; $i++) {
$cur = fetch($c, $i);
for($j = 0; $j < 10; $j++) {
ocifetchinto($cur, $row, OCI_NUM);
echo "row=$row[0] ";
}
echo "\n";
ocifreestatement($cur);
ocifreestatement($s);   // ADDED
}





[2007-12-04 09:09:53] michael dot virnstein at brodos dot de

edit summary



[2007-12-04 07:47:24] michael dot virnstein at brodos dot de

Description:

As requested in Bug #42496 (http://bugs.php.net/bug.php?id=42496),
here's a separate bug report for the cursor issue:

If you use a query with more than one cursor as result column, the
statement won't get closed correctly. You have to call
oci_free_statement() for as many times as there are result-cursors to
get the statement closed correctly.

I tried the fix for LOBs as reported in Bug #42496 for SQLT_RSET, but
that didn't work really well. There are two problems:

1. If you use the reproduce code below with the fix (removing
"zend_list_addref(outcol->statement->id);" from
SQLT_RSET in php_oci_define_callback function() [oci8_statement.c]),
you'll get an "ORA-01001: invalid cursor" when you try to fetch from the
returned
cursor. It seems that the statement ($stmt) is closed when leaving the
function.

2. If you use the reproduce code below without the fix above, you'll
get an "ORA-01000: maximum open cursors exceeded" when you hit you're
"open_cursors" db-setting. The statement ($stmt) never gets closed and
leaves a dangling cursor.

I don't know if that can be implemented easily, but the best thing
would
be, that a statement gets closed if it is already out of scope and
therefore not accessible from the php-code anymore and all nested
cursors got closed already.



Reproduce code:
---


Expected result:

Neither an "ORA-01001: invalid cursor" nor an "ORA-01000: maximum open
cursors exceeded"

Actual result:
--
Depends on the fix. Either "ORA-01001: invalid cursor" or "ORA-01000:
maximum open cursors exceeded"





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


#44226 [Fbk->Opn]: Throwing an exception causes crash

2008-02-25 Thread james dot j dot hackett at gmail dot com
 ID:   44226
 User updated by:  james dot j dot hackett at gmail dot com
 Reported By:  james dot j dot hackett at gmail dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: linux debian 2.6.18-5-686
 PHP Version:  5.3CVS-2008-02-23 (snap)
 New Comment:

There was no change when using the latest snapshot. I used a configure
of "./configure --with-apxs2=/usr/bin/apxs2".

I am able to run 5.2.5 with no problems.


Previous Comments:


[2008-02-24 19:50:01] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.3-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.3-win32-installer-latest.msi

Does not crash for me..please try the latest CVS snapshot. And if that
fails, provide the configure line you used.



[2008-02-23 14:44:12] james dot j dot hackett at gmail dot com

Description:

Throwing an exception causes a segmentation fault

Reproduce code:
---
getMessage();
}
?>


Expected result:

display "Hi, I am an Exception"

Actual result:
--
#0  0x in ?? ()
#1  0x2acf5c4008de in execute (op_array=0xa1af00, tsrm_ls=0xa00550)
zend_vm_execute.h:91
#2  0x2acf5c3db6aa in zend_execute_scripts (type=8,
tsrm_ls=0xa00550, retval=0xa98be8, file_count=3) zend.c:1173
#3  0x2acf5c38ba36 in php_execute_script (primary_file=0x4700cf40,
tsrm_ls=0xa00550) main.c:2026
#4  0x2acf5c474849 in php_handler (r=0x9fa5b8) sapi_apache2.c:629
#5  0x00437c4a in ap_run_handler ()
#6  0x0043affc in ap_invoke_handler ()
#7  0x00447248 in ap_process_request ()
#8  0x0044468c in ?? ()
#9  0x0043ec22 in ap_run_process_connection ()
#10 0x0044b696 in ?? ()
#11 0x2acf57bbd317 in start_thread () from /lib/libpthread.so.0
#12 0x2acf580a9d5d in clone () from /lib/libc.so.6
#13 0x in ?? ()






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


#44206 [Opn->Csd]: Cursor leak with REF CURSORS

2008-02-25 Thread sixd
 ID:   44206
 Updated by:   [EMAIL PROTECTED]
 Reported By:  christopher dot jones at oracle dot com
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: n/a
 PHP Version:  5.2.5
 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.

+--
| Fix has been merged to 5.2.6, 5.3 and 6.
| Thanks go to Haneef.
+--



Previous Comments:


[2008-02-21 19:29:30] christopher dot jones at oracle dot com

Description:

When more than one REF CURSOR is returned in a query, ORA-1000 occurs
after some iterations.
Haneef investigated and says:
  "The refcount of the parent statement is incremented by the ref
  cursors in php_oci_define_callback and is not decremented. The
  incrementing is necessary as the parent statement needs to be around
  while fetching the data from the ref cursor. The fix is to decrement
  the refcount of the parent statement before ref cursor is freed."
The fix is being tested.

Reproduce code:
---
 $v) {
if (is_resource($v) &&
get_resource_type($v) == "oci8 statement") {
oci_execute($v);
oci_fetch_all($v, $row[$k], 0, -1, OCI_ASSOC);
oci_free_statement($v);
}
}
}
echo $x, "\n";
}
oci_free_statement($sth);
}
print "Completed $x\n";
oci_close($c);
?>


Expected result:

...
398
399
Completed 400

Actual result:
--
...
295
296
PHP Warning:  oci_execute(): ORA-00604: error occurred at recursive SQL
level 1
ORA-01000: maximum open cursors exceeded in test.php on line 10
Exiting 297





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


#44008 [Opn->Csd]: Incorrect use of OCI-Lob->close() causes crash

2008-02-25 Thread sixd
 ID:   44008
 Updated by:   [EMAIL PROTECTED]
 Reported By:  christopher dot jones at oracle dot com
-Status:   Open
+Status:   Closed
 Bug Type: OCI8 related
 Operating System: n/a
 PHP Version:  5.3CVS-2008-01-31 (snap)
 Assigned To:  sixd
 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.

+--
| A different fix has been merged to 5.2.6, 5.3 and 6.
| Thanks go to Haneef.
+--



Previous Comments:


[2008-01-31 21:42:24] christopher dot jones at oracle dot com

Description:

Incorrect use of OCI-Lob->close() can cause a crash.  The crash is
ultimately due to Oracle bug 6786812 and is related to thread
handling.

It reproduces with PHP 5.3 (after DRCP support was added). It is
likely to reproduce in threaded builds of PHP 5.x on Windows.

There is a code workaround below, but because this might add to the
roundtrip count in the general case, I'd like to investigate other
solutions.

--- oci8_lob.c  24 Jan 2008 14:09:36 -  1.7.2.6.2.14.2.3
+++ oci8_lob.c  31 Jan 2008 21:27:10 -
@@ -570,13 +570,17 @@
int php_oci_lob_close (php_oci_descriptor *descriptor TSRMLS_DC)
{
php_oci_connection *connection = descriptor->connection;
-   
-   PHP_OCI_CALL_RETURN(connection->errcode, OCILobClose,
(connection->svc, connection->err, descriptor->descriptor));
+   boolean flag = 0;
 
-   if (connection->errcode != OCI_SUCCESS) {
-   php_oci_error(connection->err, connection->errcode TSRMLS_CC);
-   PHP_OCI_HANDLE_ERROR(connection, connection->errcode);
-   return 1;
+   PHP_OCI_CALL_RETURN(connection->errcode, OCILobIsOpen,
(connection->svc, connection->err, descriptor->descriptor, &flag));
+   if (connection->errcode == OCI_SUCCESS && flag) {
+   PHP_OCI_CALL_RETURN(connection->errcode, OCILobClose,
(connection->svc, connection->err, descriptor->descriptor));
+   
+   if (connection->errcode != OCI_SUCCESS) {
+   php_oci_error(connection->err, connection->errcode 
TSRMLS_CC);
+   PHP_OCI_HANDLE_ERROR(connection, connection->errcode);
+   return 1;
+   }
}

Reproduce code:
---
load();
echo $r;

// Incorrectly closing the lob causes a crash.  OCI-LOB->close() is
// documented for use only with OCI-Lob->writeTemporary()
$textLob->close();

print "ok\n";

?>






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


#44239 [Opn]: getimagesize should be able to work on string data as well...

2008-02-25 Thread npeelman at cfl dot rr dot com
 ID:   44239
 User updated by:  npeelman at cfl dot rr dot com
 Reported By:  npeelman at cfl dot rr dot com
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: n/a
-PHP Version:  5.2.5
+PHP Version:  5.1.6
 New Comment:

Ok, I found the example for using streams with variables and it works
just fine with getimagesize but, I still think it would be easy enough
for getimagesize to simply work on the string variable should the
attempt to open a filename fails.


Previous Comments:


[2008-02-25 04:02:38] npeelman at cfl dot rr dot com

Description:

  Any reason why getimagesize couldn't be extended to accept image data
in string format such as:

array getimagesize (string $filename | string $string [, array
&$imageinfo])

  This would be very handy for pulling image info from data stored in
cache (such as APC) or BLOB data from a database without first
converting with imagecreatefromstring() -> temp file ->
getimagesize($temp_file).

  I see BUG #25507 but no example is given on how to achieve it. It
seems to me that the binary data in the string variable is already in
the format needed. 

  I'm actually on PHP version 5.1.6 (ubuntu linux) as per phpinfo().

Thank you for your time,
Norman Peelman

Reproduce code:
---
n/a

Expected result:

n/a

Actual result:
--
n/a





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


#44242 [Opn->Csd]: metaphone('CMXFXM') crashes PHP

2008-02-25 Thread felipe
 ID:   44242
 Updated by:   [EMAIL PROTECTED]
 Reported By:  nicolas at audiofanzine dot com
-Status:   Open
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Linux & Windows
 PHP Version:  5.2.5
 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:


[2008-02-25 16:05:23] nicolas at audiofanzine dot com

Description:

The following code results in a PHP crash with a "zend_mm_heap
corrupted" message, either on an UTF-8 environement or ISO-8859-1, with
Linux or Windows.

Reproduce code:
---


Actual result:
--
KMKSFKSM[Mon Feb 25 17:02:41 2008]  Script:  'test.php'
---
/usr/local/src/php/Zend/zend_variables.h(35) : Block 0xb79dcfb4
status:
/usr/local/src/php/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning:  OK (allocated on
/usr/local/src/php/ext/standard/metaphone.c:435, 8 bytes)
Start:  OK
  End:  Overflown (magic=0x instead of 0xC5FC605D)
1 byte(s) overflown
---
[Mon Feb 25 17:02:41 2008]  Script:  'test.php'
/usr/local/src/php/ext/standard/metaphone.c(435) :  Freeing 0xB79DCFB4
(8 bytes), script=test.php
=== Total 1 memory leaks detected ===






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


#43960 [Asn->Csd]: strtotime() returns timestamp in the future when given a bogus string

2008-02-25 Thread derick
 ID:   43960
 Updated by:   [EMAIL PROTECTED]
 Reported By:  chris dot corbyn at sitepoint dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Date/time related
 Operating System: OS X/Linux
 PHP Version:  5.2.5
 Assigned To:  derick
 New Comment:

This is in CVS now (or was for some weeks).


Previous Comments:


[2008-01-29 10:15:48] chris dot corbyn at sitepoint dot com

Thanks for the detailed and useful explanation.  Checking for more than

two occurrences of timezone specification and returning false is such a

scenario would be the way to go I agree.

Thanks very much,

Chris.



[2008-01-29 07:31:52] [EMAIL PROTECTED]

"I" is seen as a timezone (Like L or Z could be). There is thus nothing
wrong with that specific string. However, in the first one the parser
sees many different timezone strings, parsing with date_parse() shows:

[EMAIL PROTECTED]:~/dev/php/php-5.3dev$ sapi/cli/php 

array(16) {
  ["year"]=>
  bool(false)
  ["month"]=>
  bool(false)
  ["day"]=>
  bool(false)
  ["hour"]=>
  bool(false)
  ["minute"]=>
  bool(false)
  ["second"]=>
  bool(false)
  ["fraction"]=>
  bool(false)
  ["warning_count"]=>
  int(6)
  ["warnings"]=>
  array(6) {
[2]=>
string(29) "Double timezone specification"
[7]=>
string(29) "Double timezone specification"
[10]=>
string(29) "Double timezone specification"
[14]=>
string(29) "Double timezone specification"
[21]=>
string(29) "Double timezone specification"
[24]=>
string(29) "Double timezone specification"
  }
  ["error_count"]=>
  int(0)
  ["errors"]=>
  array(0) {
  }
  ["is_localtime"]=>
  bool(true)
  ["zone_type"]=>
  int(2)
  ["zone"]=>
  int(-540)
  ["is_dst"]=>
  bool(false)
  ["tz_abbr"]=>
  string(1) "I"
}

I don't know whether I can make a double timezone string an error, as
it's common to use things like "GMT+04:00" which would trigger the same
error then - while being a valid string. I think the most I can do if
when it sees *more* than two timezones it turns it into errors.



[2008-01-29 05:29:03] chris dot corbyn at sitepoint dot com

Description:

When writing a unit test to ensure bogus data cannot be passed to our
e-commerce paypal request-response library we've stumbled upon an
unexpected problem.  I enjoy the occassional (1-2 per day) slice whilst
at work so I passed this as a test bogus string.



This returns a timestamp exactly 2 hours in the future.  This has been
tested on 2 different macs and a linux server.

We've pinned it down to the "i".  What we really expected was a boolean
false return value.

Reproduce code:
---


Expected result:

A boolean FALSE return is expected.

Actual result:
--
An integer representing a UNIX timestamp exactly 2 hours in the future
is returned.





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


#44176 [Opn->Bgs]: Problems with strtotime or strftime and DST

2008-02-25 Thread derick
 ID:   44176
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jason dot young at daystar dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Date/time related
 Operating System: win 2003 IIs 6
 PHP Version:  5.2.5
 New Comment:

There is no "2am" in "America/Chicago" on March 9th, as the time goes
from 01:59:59 directly to 03:00:00:

zdump -v America/Chicago shows:

America/Chicago  Sun Nov  4 07:00:00 2007 UTC = Sun Nov  4 01:00:00
2007 CST isdst=0 gmtoff=-21600
America/Chicago  Sun Mar  9 07:59:59 2008 UTC = Sun Mar  9 01:59:59
2008 CST isdst=0 gmtoff=-21600
America/Chicago  Sun Mar  9 08:00:00 2008 UTC = Sun Mar  9 03:00:00
2008 CDT isdst=1 gmtoff=-18000
America/Chicago  Sun Nov  2 06:59:59 2008 UTC = Sun Nov  2 01:59:59
2008 CDT isdst=1 gmtoff=-18000
America/Chicago  Sun Nov  2 07:00:00 2008 UTC = Sun Nov  2 01:00:00
2008 CST isdst=0 gmtoff=-21600
America/Chicago  Sun Mar  8 07:59:59 2009 UTC = Sun Mar  8 01:59:59
2009 CST isdst=0 gmtoff=-21600



Previous Comments:


[2008-02-19 20:06:22] jason dot young at daystar dot com

Description:

Ok I'm trying to do some calendar work right during this summers time
change hour. 3/9/2008 at 2 a.m. I work for a television network and we
have to created scheduals for every hour of every day. (This includes 2
am) strtotime or possibly strftime is not handling that 2:00 am hour
correctly here is some testing:

Reproduce code:
---


Output:
Sun 03/09/08 03:00 AM --- 03/09/08 03:00 AM --- 1204869600 ---
1204869600 --- 1205049600 --- 1205049600

I've tried setting the TZ to US/CDT that didn't help ($test =
putenv("TZ=US/CDT");)


Expected result:

I expect the code to return a formated verson of the date "Mar 9 2008
2:00AM"

Actual result:
--
Sun 03/09/08 03:00 AM 

I apologize in advance if this is my misuse. 





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


#43708 [Fbk->Opn]: mysqli_stmt_affected_rows return values don't match documentation

2008-02-25 Thread mo at modejong dot com
 ID:   43708
 User updated by:  mo at modejong dot com
 Reported By:  mo at modejong dot com
-Status:   Feedback
+Status:   Open
 Bug Type: MySQLi related
 Operating System: WinXP
 PHP Version:  5.2.5
 New Comment:

The server version is reported as:

5.0.45-community-nt-log

I don't know how to determine what the version of
libmysql.dll is for this install. I got it as part
of xampplite 1.6.4.


Previous Comments:


[2008-02-18 15:23:45] [EMAIL PROTECTED]

What MySQL version are you using and what version of the libmysql (I
assume you do not use mysqlnd, do you) do you use? 

I'm asking because of http://bugs.mysql.com/bug.php?id=23383 . 

Ulf



[2007-12-29 21:32:26] mo at modejong dot com

Description:

The mysqli_stmt_affected_rows implementation does not
match the documentation for this function WRT return
values when no rows are matched or when a SQL error
is found. If you run the source code below, it should
output:

1 (a)
2 (b)
mysqli_stmt_affected_rows(): int(1)
1 (b)
2 (b)
mysqli_stmt_affected_rows(): int(2)
1 (c)
2 (c)
mysqli_stmt_affected_rows(): int(0)
mysqli_stmt_affected_rows(): int(-1)

When run in PHP 5.2.4, the final two lines are:

mysqli_stmt_affected_rows(): int(-1)
mysqli_stmt_affected_rows(): NULL

The docs explicitly state that 0 will be returned
when no rows match and -1 will be returned when
an SQL error is found. The PHP impl should match
the documentation.

Reproduce code:
---


Expected result:

See description

Actual result:
--
See description





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


#44219 [Fbk->Csd]: Fix for Bug #44209 Causes Test Regression

2008-02-25 Thread derick
 ID:   44219
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kirkland at ubuntu dot com
-Status:   Feedback
+Status:   Closed
 Bug Type: Date/time related
 Operating System: Linux 64 bit
 PHP Version:  5.2.5
 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:


[2008-02-25 11:35:45] bisho at onirica dot com

It seens a test-problem, not a regression. The new output of
int(-62169962400) is correct.



[2008-02-24 19:51:42] [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-02-22 20:31:34] kirkland at ubuntu dot com

Test script:
# cat /tmp/foo.php 


Built without patch:
# php /tmp/foo.php 
bool(false)


Built with patch:
# ./cli-build/sapi/cli/php /tmp/foo.php 
int(-62169962400)



[2008-02-22 20:21:41] kirkland at ubuntu dot com

In other words, adding that 3-line patch creates the following test
regressions.  The following tests now fail on 64-bit Linux:

+ Bug #41523 (strtotime('-00-00 00:00:00') is parsed as 1999-11-30)
[ext/date/tests/bug41523.phpt]

+ mktime() [3] [ext/date/tests/mktime-3.phpt]

+ strtotime() and mysql timestamps
[ext/date/tests/strtotime-mysql.phpt]

+ strtotime() function [ext/date/tests/strtotime3.phpt]

+ wddx deserialization test [ext/wddx/tests/001.phpt]



[2008-02-22 19:12:18] kirkland at ubuntu dot com

The diff shown in that pastebin is from two subsequent runs, both on
64-bit Linux.

The only difference between the two is:

+++ php-src/ext/date/lib/timelib.h  Fri Feb 22 09:48:18 2008
...
+#if HAVE_LIMITS_H
+#include 
+#endif
...



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

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


#44248 [NEW]: RFC2616 transgression while HTTPS request through proxy with SoapClient object

2008-02-25 Thread jboffel at gmail dot com
From:  jboffel at gmail dot com
Operating system: Linux RedHat Enterprise
PHP version:  5.2.5
PHP Bug Type: SOAP related
Bug description:  RFC2616 transgression while HTTPS request through proxy with 
SoapClient object

Description:

Configure line :
No need for a configure line here, just need the php extension soap.so

Setup :
You have to make a soap call on an https based webservice through an
Apache proxy (Apache or any proxy which is following rfc2616).

Explanation : 

When you make an HTTPS connection in HTTP/1.1 through a proxy you MUST
include an host parameter in the HTTP header like that :
CONNECT uri-test:443 HTTP/1.1
Host: uri-test

And what's done today is :
CONNECT uri-test:443 HTTP/1.1

So we're clearly missing the Host parameter like explaining below,

rfc2616 require this :

   A client MUST include a Host header field in all HTTP/1.1 request
   messages . If the requested URI does not include an Internet host
   name for the service being requested, then the Host header field MUST
   be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
   request message it forwards does contain an appropriate Host header
   field that identifies the service being requested by the proxy. All
   Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
   status code to any HTTP/1.1 request message which lacks a Host header
   field.

The problem is based in php_http.c in ext/soap/ of ANY existing version of
PHP (not only 5.2.5)

Well, there is two possible fix at least :

1) Add after line 169 :
smart_str_append_const(&soap_headers, "Host: ");
smart_str_appends(&soap_headers, phpurl->host);
smart_str_append_const(&soap_headers, "\r\n");

The problem here is that I'm NOT sure that every time in HTTPS connection
we need to put exactly the value of phpurl-host.
For example I don't know if it's possible to be in a situation like this :
(IP like x.x.x.x)
CONNECT IP:443 HTTP/1.1
Host: www.test.com
If yes, this fix is not perfect.

2) Modify line 169 from :
smart_str_append_const(&soap_headers, " HTTP/1.1\r\n");
to :
smart_str_append_const(&soap_headers, " HTTP/1.0\r\n");

Of course solution 2 force us to downgrade to protocol HTTP/1.0 which
won't be able to access HTTPS virtualhosted website on a single IP address.

Reproduce code:
---
Short script :

"localhost",
   'proxy_port'=>
8080,'uri'=>"https://test-uri/";));

$client->SomeFunction($a, $b, $c);
?>

Expected result:

HTTP header like that :

CONNECT uri-test:443 HTTP/1.1
Host: uri-test

Actual result:
--
CONNECT uri-test:443 HTTP/1.1

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


#41631 [Com]: default_socket_timeout does not work with SSL

2008-02-25 Thread konstantin dot ryabitsev at mcgill dot ca
 ID:   41631
 Comment by:   konstantin dot ryabitsev at mcgill dot ca
 Reported By:  david at acz dot org
 Status:   Assigned
 Bug Type: OpenSSL related
 Operating System: SuSE Linux
 PHP Version:  5.2.3
 Assigned To:  pajoye
 New Comment:

This is still happening on 5.2.5, and is really annoying when a soap
server you are connecting to accepts the connection and then hangs.
Effectively, this quickly results in a denial of service for the entire 
site, as the end-result is hung HTTP processes.

Please consider this for a high-priority fix.


Previous Comments:


[2007-06-08 15:58:24] david at acz dot org

I have a (partial?) fix:

Index: main/streams/xp_socket.c
===
RCS file: /repository/php-src/main/streams/xp_socket.c,v
retrieving revision 1.33.2.2.2.4
diff -u -p -d -r1.33.2.2.2.4 xp_socket.c
--- main/streams/xp_socket.c1 Jan 2007 09:36:12 -  
1.33.2.2.2.4
+++ main/streams/xp_socket.c8 Jun 2007 15:55:57 -
@@ -103,7 +103,7 @@ retry:
return didwrite;
 }

-static void php_sock_stream_wait_for_data(php_stream *stream,
php_netstream_data_t *sock TSRMLS_DC)
+void php_sock_stream_wait_for_data(php_stream *stream,
php_netstream_data_t *sock TSRMLS_DC)
 {
int retval;
struct timeval *ptimeout;
Index: ext/openssl/xp_ssl.c
===
RCS file: /repository/php-src/ext/openssl/xp_ssl.c,v
retrieving revision 1.22.2.3.2.8
diff -u -p -d -r1.22.2.3.2.8 xp_ssl.c
--- ext/openssl/xp_ssl.c27 May 2007 17:05:51 - 
1.22.2.3.2.8
+++ ext/openssl/xp_ssl.c8 Jun 2007 15:55:57 -
@@ -35,6 +35,8 @@
 #include 
 #endif

+void php_sock_stream_wait_for_data(php_stream *stream,
php_netstream_data_t *sock TSRMLS_DC);
+
 int php_openssl_apply_verification_policy(SSL *ssl, X509 *peer,
php_stream *stream TSRMLS_DC);
 SSL *php_SSL_new_from_context(SSL_CTX *ctx, php_stream *stream
TSRMLS_DC);
 int php_openssl_get_x509_list_id(void);
@@ -219,6 +221,12 @@ static size_t php_openssl_sockop_read(ph
php_openssl_netstream_data_t *sslsock =
(php_openssl_netstream_data_t*)stream->abstract;
int nr_bytes = 0;

+   if (sslsock->s.is_blocked) {
+   php_sock_stream_wait_for_data(stream, &(sslsock->s)
TSRMLS_CC);
+   if (sslsock->s.timeout_event)
+   return 0;
+   }
+
if (sslsock->ssl_active) {
int retry = 1;



[2007-06-08 01:15:24] david at acz dot org

Description:

The default socket timeout does not work with SSL streams.  An strace
shows PHP calls read(2) and blocks forever.

Reproduce code:
---
Create sleepforever.php:



Try it with HTTP:

$ php -n -r 'ini_set("default_socket_timeout", 1);
fopen("http://127.0.0.1/sleepforever.php";, "r");'

Now try it with HTTPS:

$ time php -n -r 'ini_set("default_socket_timeout", 1);
fopen("https://127.0.0.1/sleepforever.php";, "r");'


Expected result:

Warning: fopen(http://127.0.0.1/sleepforever.php): failed to open
stream: HTTP request failed!  in Command line code on line 1

real0m2.052s
user0m0.020s
sys 0m0.010s


Actual result:
--
The process blocks forever.  An strace shows this:

connect(3, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in
progress)
poll([{fd=3, events=POLLIN|POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}],
1, 1000) = 1
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
fcntl64(3, F_SETFL, O_RDWR) = 0
write(3, "\200j\1\3\1\0Q\0\0\0\20\0\0\26\0\0\23\0\0\n\7\0\300\0\0"...,
108) = 108
read(3, "\26\3\1\0J\2\0", 7)= 7
*** ELIDED ***
write(3, "\27\3\1\0\30N~h\231u\31S]94^\253\235\26t\324\214\t/\261"...,
29) = 29
poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 0) = 0
read(3, *** THIS BLOCKS FOREVER ***






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


#41350 [Com]: Error in my_thread_global_end()

2008-02-25 Thread sharadrb at yahoo dot com
 ID:   41350
 Comment by:   sharadrb at yahoo dot com
 Reported By:  graham at directhostinguk dot com
 Status:   No Feedback
 Bug Type: MySQL related
 Operating System: Windows 2003
 PHP Version:  5.2.3
 New Comment:

Even I had same issue with PHP version 5.2.5. So, I rolled back to
older version 5.2.1 which does not have this issue. Now, I don't have
this issue with version 5.2.1


Previous Comments:


[2008-02-20 17:05:01] brandonkahre at charter dot net

I am still experiencing this bug as of Feb-20-2008.  I am running PHP
5.2.4 in a Windows XP environment with MySQL 4.2.20.  To leave no room
for confusion, the problems and steps I am using to recreate this bug
are described in Bug #44009 (http://bugs.php.net/bug.php?id=44009).

I have tried the following PHP versions:
PHP 5.2.4
PHP 5.2.5
PHP 5.2.6-latest

I have tried patching the Windows php_mysql.dll extension using the
following sources:
PHP 5.2.1: http://www.php.net/releases/#5.2.1 [copy /ext/php_mysql.dll
only] - this did not fix any problems
MySQL: http://dev.mysql.com/downloads/connector/php/ [mysql extension
(PHP 5.2.0) for MySQL Server 4.1.21] - could not connect to MySQL
server.  Please note that the extension is for PHP 5.1.6.6
MySQL: http://dev.mysql.com/downloads/connector/php/ [mysql extension
(PHP 5.2.0) for MySQL Server 5.0.27] - this did not fix any problems
IT-Guys (mentioned in this bug tracker):
http://www.it-etc.com/2007/10/25/php-error-524-getting-error-error-in-my_thread_global_end-1-threads-didnt-exit/
- this did not fix any problems.  The extensions provided seem to be for
PHP 5.2.0.0



[2008-02-13 17:25:20] byerly0503 at gmail dot com

This bug caused me to spend an hour on the issue.  I kept ignoring all
of the help related to MySQL since the script I was trying to run,
didn't use MySQL.  

Please fix this by including the right DLL or adjust the installer to
give a warning message:  "Despite downloading this package, you will
need to download an older package, replace the mysql dll, in order to
use PHP."



[2008-02-08 06:56:04] OPunWide at hotmail dot com

I'm a newbie at this, and am installing php for the first time. Very
basic setup, running WinXP, using IIS 5.1 and PHP 5.2.5, installed using
the Windows installer. 

When I first installed I included support for MySQL in the options, but
had not installed MySQL. The error happened with a psp script consisting
only of pspinfo(). I went back to the installer and removed support for
MySQL and the problem went away.

I don't think the folks at MySQL can be blamed for this one.



[2008-02-07 22:27:08] WS6TA at txlanes dot com

I have to agree about the impression this makes on potential LAMP
adopters.  I am a long-time Windows/MSSQL person looking at the LAMP
stack as an alternative to MS.  However, I download PHP 5.2.5 and start
reading the manual only to get the error "Error in
my_thread_global_end()" the first time I used the CLI.  So, I go
searching and find all kinds of references to dll swaps for PHP side AND
the MySQL side.  I don't even have MySQL installed yet...  I was looking
at PHP's ability to be a standalone scripting tool as well as a
web-database tool.

Anyway, I then find this thread where it appears the bug has been
around since approximately May 2007 and PHP version 5.2.3.  I commented
out "extension=php_mysql.dll" in the php.ini to stop the error, but I
think I will want this extension once I install MySQL.

My hat's off to the people that started and have contributed to the PHP
codebase.  Please understand that I am not trying to bash anyone.  I
simply want to reiterate the PHP is crucial component to the LAMP stack
and having to search for a bug fix on the very first run discourages
potential new adopters.  I'm very impressed with what I know about PHP
thus far and would hate to think a potential  adopter could be
discouraged at square one in their evaluation.



[2008-01-22 20:30:48] codeslinger at compsalot dot com

Ping,
Can we get php updated please?  This problem is now one year old.

Everyone who updates to the latest Windows php = 5.2.5 encounters this
bug, it results in total breakage of loading the mysql dll.

This bug has cost thousands upon thousands of man-hours to be
expended/wasted by site admins in trying to locate the cause of the
problem and the fix for it.  In some cases it has also caused people to
abandon the use of php-mysql programs altogether.

According to MySQL Bug: http://bugs.mysql.com/bug.php?id=25621

The final resolution is that the problem was with mysql not php and
that the problem was fixed awhile ago, and that all that is ne

#44134 [Fbk->Csd]: sessions calling causes timeout and failed response in simplexml and curl

2008-02-25 Thread doc+phpbugs at skynet dot ie
 ID:   44134
 User updated by:  doc+phpbugs at skynet dot ie
 Reported By:  doc+phpbugs at skynet dot ie
-Status:   Feedback
+Status:   Closed
 Bug Type: Session related
 Operating System: ubuntu linux
 PHP Version:  5.2.5
 New Comment:

hello, yes, sessions were being started automatically, and thanks, that
solved the problem. I didn't realise you could get them locking like
that.

Thanks, closing the bug.


Previous Comments:


[2008-02-24 00:31:14] [EMAIL PROTECTED]

s/complete/incomplete/ :)



[2008-02-24 00:30:54] [EMAIL PROTECTED]

That's still quite complete script, or do you start sessions
automatically? (it's missing session_start(); :)

And as you're obviously calling another script on same server with same
session as the current one, you should be using this:

http://php.net/session_write_close

You should put the call to session_write_close(); before the
curl/simplexml calls.



[2008-02-19 17:46:24] doc+phpbugs at skynet dot ie

Sorry, I meant to add that the url listed here isn't real but the
result should happen with any url which utilises a session on
connection.



[2008-02-18 18:55:45] doc+phpbugs at skynet dot ie

http://magpiedev.com/data.php');
$data_source_url = DATAURL.'?bget=1&'.session_name().'='.session_id();
$basket_details = simplexml_load_file($data_source_url);
?>



[2008-02-18 09:36:18] [EMAIL PROTECTED]

Please provide a proper reproducing script. The one here is not
enough.
Proper script is 100% self-contained and starts with  (for the sake of being clear where the script really ends :)



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

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


#43861 [NoF]: suhosin patch detects heap overflow on mssql_free_result()

2008-02-25 Thread rasmus
 ID:   43861
 Updated by:   [EMAIL PROTECTED]
 Reported By:  skennedy at vcn dot com
 Status:   No Feedback
 Bug Type: MSSQL related
 Operating System: FreeBSD 6.2
 PHP Version:  5.2.5
 New Comment:

Andy, this bug is specific to MSSQL and you indicated you are using
MySQL, so I don't see how your issue is the similar.


Previous Comments:


[2008-02-25 09:58:25] andy at diginights dot com

Same issue here, we get white pages browsing our site.
Also we get "ALERT - canary mismatch on efree() - heap overflow
detected" in apache  error log.
Using 
apache 2.2.8-1
php 5.2.5-2
mysql 5.0.51-3

Software ist Burning Board (http://woltlab.de/)



[2008-02-18 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2008-02-10 14:50:28] [EMAIL PROTECTED]

Can you please try a CVS snapshot on PHP 5.3.0 in about 4-5 hours. I've

just applied a patch to the code that may fix your problem. 

Alternatively you can try the patch yourself from this URL;

http://cvs.php.net/viewvc.cgi/php-src/ext/mssql/php_mssql.c?
r1=1.152.2.13.2.4.2.3&r2=1.152.2.13.2.4.2.4&diff_format=u




[2008-02-10 07:57:04] cxcxcxcx at gmail dot com

I have encountered a similar problem. When "select" contains
'smalldatetime' or 'datetime' columns.

I am using Debian Sid and php5 php5-sybase.



[2008-01-31 00:16:10] [EMAIL PROTECTED]

Ok, there we go.  Looks like there is an off-by-one in there.  But
looking at the PHP code, it seems ok.

int res_length = dbdatlen(mssql_ptr->link,offset);
...
res_buf = (unsigned char *) emalloc(res_length+1);
res_length =
dbconvert(NULL,coltype(offset),dbdata(mssql_ptr->link,offset),
res_length, SQLCHAR,res_buf,-1);
res_buf[res_length] = '\0';

So, we aren't going beyond the buffer, it is somewhere in the
dbconvert() code writing to res_buf that is off.  Passing in a larger
buffer would fix it, but it would be good to understand why dbdatlen()
isn't returning the right length.  Is it an encoding issue?  One assumes
single-byte encoding and the other multi-byte or something?

Looping in Frank to have a look.





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

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


#44246 [NEW]: closedir() accepts a file resource opened by fopen()

2008-02-25 Thread [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Operating system: Windows XP
PHP version:  5.2CVS-2008-02-25 (CVS)
PHP Bug Type: *Directory/Filesystem functions
Bug description:  closedir() accepts a file resource opened by fopen()

Description:

closedir() will accept a file resource opened by fopen() as the $directory
argument. In the documentation for closedir() it says the following: "The
stream must have previously been opened by opendir()". It seems that the
resource type is not being checked correctly. 
A directory opened with opendir() can also be passed to fclose() without
an error message being generated.

Reproduce code:
---


Expected result:

resource(5) of type (stream)

Warning: closedir(): supplied argument is not a valid Directory resource
in ...
resource(5) of type (stream)
resource(6) of type (stream)

Warning: fclose(): supplied argument is not a valid stream resource in
...
bool(false)
resource(6) of type (stream)

Actual result:
--
resource(5) of type (stream)
resource(5) of type (Unknown)
resource(6) of type (stream)
bool(true)
resource(6) of type (stream)


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


#44223 [Fbk->Opn]: round() sometimes returns value in E notation

2008-02-25 Thread kjohnson at zootweb dot com
 ID:   44223
 User updated by:  kjohnson at zootweb dot com
 Reported By:  kjohnson at zootweb dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Math related
 Operating System: Linux 2.6.20.2
 PHP Version:  5.2.5
 New Comment:

Thanks for your response!

Sorry, I am not able to change my PHP version, so I can't try the CVS
snapshot.


Previous Comments:


[2008-02-24 19:51:06] [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-02-22 22:20:33] kjohnson at zootweb dot com

Description:

For certain values, not necessarily large numbers, round() returns the
value in exponential notation instead of the usual decimal format. Some
of these "special" values are 120, 140, 230, 240.

It seems to be just certain multiples of 100,000. Generate your own
list with the code below. I suggest you start with input of:
Start = 100
Increment = 10
Iterations = 100 to 200

Reproduce code:
---



Start value:   
Increment:    
Iterations: 


Start: ", $_POST['start'], "; Increment: ",
$_POST['increment'], "";

  $tmp = $_POST['start'];
  echo round($tmp),"";
  for($i = 0; $i < $_POST['iterations']; $i++ ) {
$tmp += $_POST['increment'];
echo round($tmp),"";
  }
}
?>


Expected result:

All values to be returned in standard decimal format, e.g., "120".

Actual result:
--
Certain values are returned in exponential format, e.g., "1.2E+6".





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


#44242 [NEW]: metaphone('CMXFXM') crashes PHP

2008-02-25 Thread nicolas at audiofanzine dot com
From: nicolas at audiofanzine dot com
Operating system: Linux & Windows
PHP version:  5.2.5
PHP Bug Type: Reproducible crash
Bug description:  metaphone('CMXFXM') crashes PHP

Description:

The following code results in a PHP crash with a "zend_mm_heap corrupted"
message, either on an UTF-8 environement or ISO-8859-1, with Linux or
Windows.

Reproduce code:
---


Actual result:
--
KMKSFKSM[Mon Feb 25 17:02:41 2008]  Script:  'test.php'
---
/usr/local/src/php/Zend/zend_variables.h(35) : Block 0xb79dcfb4 status:
/usr/local/src/php/Zend/zend_variables.c(36) : Actual location (location
was relayed)
Beginning:  OK (allocated on
/usr/local/src/php/ext/standard/metaphone.c:435, 8 bytes)
Start:  OK
  End:  Overflown (magic=0x instead of 0xC5FC605D)
1 byte(s) overflown
---
[Mon Feb 25 17:02:41 2008]  Script:  'test.php'
/usr/local/src/php/ext/standard/metaphone.c(435) :  Freeing 0xB79DCFB4 (8
bytes), script=test.php
=== Total 1 memory leaks detected ===


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


#43579 [Opn]: sessions time out on 5.2.5

2008-02-25 Thread assid at assid dot com
 ID:   43579
 User updated by:  assid at assid dot com
 Reported By:  assid at assid dot com
 Status:   Open
 Bug Type: Session related
 Operating System: Debian etch
 PHP Version:  5.2.5
 New Comment:

I have to downgrade to 5.2.4, as this is a production box. Please let
me know when you are available, and I will load the necessary module at
that moment.

I am also available on IRC / freenode as Assid


Previous Comments:


[2008-02-25 13:12:46] assid at assid dot com

With regards to session files and squirrelmail

I checked the part that you told me. The headers look exactly the same.
Sometimes I get the session kicking me out. The headers during which,
looks exactly the same as the ones when it doesnt kick me out. However,
sometimes i just rightclick in that frame and reload frame and it works,
or i click on any of the available imap folders on the left side.

During the time it kicks me out, the session file still exists, would
explain WHY i can still continue using AFTER that. 

from my previous test and this into consideration, i would GUESS its
something to do with session generation / session file handling or
something related to this.



[2008-02-25 08:30:07] assid at assid dot com

okay here you go, 5 hours of sleep helped a bit.

http://spherelinx.com/session.php
Now refresh this slowly (i mean one F5 per second or 2 seconds), till
you hit something like 8-10.

Now press F5 rapidly (dont hold), like 5-8 times. You end up with a new
counter. 

Refresh this counter slowly, and again repeat the above step. Sometimes
you get it to go back to the older counter.

reproduce code: http://spherelinx.com/session.phps
phpinfo - http://spherelinx.com/phpinfo.php

>From my guess, session_name fails or causes some kind of glitch



[2008-02-25 01:28:12] [EMAIL PROTECTED]

Many people, including myself, are running SquirrelMail quite fine on
5.2.5 without any sort of session problems.  The fact that it also
happens in other applications points to a general problem on your end. 
Sessions are really simple.  There are 3 parts to an active session.

1. Your browser sends a session cookie
2. The PHP script that receives the cookie calls session_start()
3. session_start() reads the session data from the session data

So, to debug this, look at each part.  Install something like the
LiveHTTPHeaders Firefox extension and make sure the cookie is being
sent.  Second, make sure there is a session_start() call in the
receiving code.  And third, check to make sure that the session data is
in the session data store.  If you are using the file-based session
store, match the session cookie to the session filename and watch it as
you click around.  Does it suddenly disappear?  If so, figure out why. 


Also check all your session.* settings and if you have multiple servers
behind any sort of load balancer, a per-server file-based session store
obviously won't work.  NFS-based stuff can also cause problems for a
file-based session store.

You can also write your own very simple trivial session test to verify
that sessions are working at all on your setup.



[2008-02-24 20:23:25] assid at assid dot com

The problem is I didnt make squirrelmail. So i am not sure of what i
can provide as the reproducable script. I am using the current stable
release.

I wanted to give something else to my users in the meantime, so i tried
horde, and well, that seems to have session timeout issues as well.



[2008-02-24 20:10:03] [EMAIL PROTECTED]

Please provide a short reproducing script.



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

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



#43207 [Com]: .htaccess settings missing (sometimes)

2008-02-25 Thread manuel at mausz dot at
 ID:   43207
 Comment by:   manuel at mausz dot at
 Reported By:  phpmyforum at gmail dot com
 Status:   Open
 Bug Type: Apache2 related
 Operating System: Linux
 PHP Version:  5.2.5
 New Comment:

same as 43677. maybe some dev should finally apply one of my patches.


Previous Comments:


[2008-02-25 12:12:25] phpmyforum at gmail dot com

> Try change the php_flag to php_value and use 0 or 1 as value.

Didn't help.


Today I could reproduce this behavior with PHP 5.2.5!



[2008-01-14 16:19:26] dan at eskhosting dot com

php_value/php_flag - no different too.



[2008-01-14 16:05:14] dan at eskhosting dot com

register_globals are switching On/Off randomise!
Values: 1/On/true, 0/Off/false; place: .htacess, httpd.conf - no
difference.
Only global setting in php.ini are effective.
Other variables works good.

System: Red Hat Enterprise Linux ES release 4 (Nahant Update 6)
PHP: 5.2.5
'./configure' '--with-apxs=/usr/local/apache/bin/apxs'
'--prefix=/usr/local' '--enable-bcmath' '--enable-calendar'
'--with-curl' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-gettext'
'--with-iconv' '--enable-mbstring' '--enable-mbregex' '--with-mcrypt'
'--enable-magic-quotes' '--with-mysqli' '--with-mysql=/usr'
'--with-openssl' '--enable-discard-path' '--with-pear'
'--with-pgsql=/usr' '--enable-safe-mode' '--enable-sockets' '--with-ttf'
'--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--with-xmlrpc'
'--with-xsl=/usr' '--enable-zip' '--with-zlib' '--with-bz2'
Apache: 1.3.37



[2007-11-19 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2007-11-11 18:49:12] [EMAIL PROTECTED]

Try change the php_flag to php_value and use 0 or 1 as value.



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

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


#43227 [Opn]: eregi() mbregex compile err: premature end of regular expression in

2008-02-25 Thread baco at infomaniak dot ch
 ID:   43227
 User updated by:  baco at infomaniak dot ch
 Reported By:  baco at infomaniak dot ch
 Status:   Open
 Bug Type: mbstring related
 Operating System: Linux Debian
 PHP Version:  4.4.7
 New Comment:

As workaround try to force mbstring.func_overload = 0 in your php.ini
and use this patch.

PHP5

unix_mbstring_func_overload.patch
--- ext/mbstring/mbstring.c 2007-09-24 13:51:36.0 +0200
+++ ext/mbstring/mbstring.c 2007-12-04 18:00:10.023564681 +0100
@@ -765,8 +765,8 @@
 PHP_INI_ENTRY("mbstring.script_encoding", NULL, PHP_INI_ALL, 
OnUpdate_mbstring_script_encoding)
 #endif /* ZEND_MULTIBYTE */
 PHP_INI_ENTRY("mbstring.substitute_character", NULL, 
PHP_INI_ALL, OnUpdate_mbstring_substitute_character)
-STD_PHP_INI_ENTRY("mbstring.func_overload", "0", 
PHP_INI_SYSTEM |
-PHP_INI_PERDIR, OnUpdateLong, func_overload, 
zend_mbstring_globals, mbstring_globals)
+STD_PHP_INI_ENTRY("mbstring.func_overload", "0",
+PHP_INI_SYSTEM, OnUpdateLong, func_overload, 
zend_mbstring_globals, mbstring_globals)

 STD_PHP_INI_BOOLEAN("mbstring.encoding_translation", "0",
 PHP_INI_SYSTEM | PHP_INI_PERDIR, 
OnUpdate_mbstring_encoding_translation,

PHP4

--- ext/mbstring/mbstring.c 2007-04-04 17:28:18.0 +0200
+++ ext/mbstring/mbstring.c 2007-12-04 18:05:29.363559316 +0100
@@ -815,8 +815,8 @@
 PHP_INI_ENTRY("mbstring.script_encoding", NULL, PHP_INI_ALL, 
OnUpdate_mbstring_script_encoding)
 #endif /* ZEND_MULTIBYTE */
 PHP_INI_ENTRY("mbstring.substitute_character", NULL, 
PHP_INI_ALL, OnUpdate_mbstring_substitute_character)
-STD_PHP_INI_ENTRY("mbstring.func_overload", "0", 
PHP_INI_SYSTEM |
-PHP_INI_PERDIR, OnUpdateInt, func_overload, 
zend_mbstring_globals, mbstring_globals)
+STD_PHP_INI_ENTRY("mbstring.func_overload", "0",
+PHP_INI_SYSTEM, OnUpdateInt, func_overload, 
zend_mbstring_globals, mbstring_globals)

 STD_PHP_INI_BOOLEAN("mbstring.encoding_translation", "0",
 PHP_INI_SYSTEM | PHP_INI_PERDIR, 
OnUpdate_mbstring_encoding_translation,


Previous Comments:


[2008-02-25 13:18:00] lip at lip dot net dot ua

I think these bugs are similar.
http://bugs.php.net/bug.php?id=44237



[2007-11-09 16:03:14] baco at infomaniak dot ch

Description:

eregi() produce random errors like "function.mb-eregi: mbregex compile
err: premature end of regular expression in" when used with special
chars like accents.

N.B. On the web you can found a lot of reports of this issue. Some post
suggests forcing mbstring.func_overload = 0 but it doesn't work for me.

If Apache1 is restarted the error doesn't come anymore before an amount
of time and request.

$ GET http://localhost/test.php
ok

$ GET http://localhost/test.php
ok

$ GET http://localhost/test.php

Warning:  mb_eregi() [function.mb-eregi]: mbregex compile err:
premature end of regular expression in
/home/www/ca8b72beb934995c1afb34e1a3ceb893/web/test.php on line
2

$ GET http://localhost/test.php

Warning:  mb_eregi() [function.mb-eregi]: mbregex compile err:
premature end of regular expression in
/home/www/ca8b72beb934995c1afb34e1a3ceb893/web/test.php on line
2

$ GET http://localhost/test.php

Warning:  mb_eregi() [function.mb-eregi]: mbregex compile err:
premature end of regular expression in
/home/www/ca8b72beb934995c1afb34e1a3ceb893/web/test.php on line
2

$ GET http://localhost/test.php
ok

$ GET http://localhost/test.php
ok

...


Reproduce code:
---


Expected result:

OK

Actual result:
--

Warning:  mb_eregi() [function.mb-eregi]: mbregex compile err:
premature end of regular expression in
/home/www/ca8b72beb934995c1afb34e1a3ceb893/web/test.php on line
2





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


#44237 [Com]: mbstring.func_overload

2008-02-25 Thread baco at infomaniak dot ch
 ID:   44237
 Comment by:   baco at infomaniak dot ch
 Reported By:  lip at lip dot net dot ua
 Status:   Open
 Bug Type: Apache2 related
 Operating System: Debian 4.0
 PHP Version:  5.2.5
 New Comment:

As workaround try to force mbstring.func_overload = 0 in your php.ini
and use this patch.

PHP5

unix_mbstring_func_overload.patch
--- ext/mbstring/mbstring.c 2007-09-24 13:51:36.0 +0200
+++ ext/mbstring/mbstring.c 2007-12-04 18:00:10.023564681 +0100
@@ -765,8 +765,8 @@
 PHP_INI_ENTRY("mbstring.script_encoding", NULL, PHP_INI_ALL, 
OnUpdate_mbstring_script_encoding)
 #endif /* ZEND_MULTIBYTE */
 PHP_INI_ENTRY("mbstring.substitute_character", NULL, 
PHP_INI_ALL, OnUpdate_mbstring_substitute_character)
-STD_PHP_INI_ENTRY("mbstring.func_overload", "0", 
PHP_INI_SYSTEM |
-PHP_INI_PERDIR, OnUpdateLong, func_overload, 
zend_mbstring_globals, mbstring_globals)
+STD_PHP_INI_ENTRY("mbstring.func_overload", "0",
+PHP_INI_SYSTEM, OnUpdateLong, func_overload, 
zend_mbstring_globals, mbstring_globals)

 STD_PHP_INI_BOOLEAN("mbstring.encoding_translation", "0",
 PHP_INI_SYSTEM | PHP_INI_PERDIR, 
OnUpdate_mbstring_encoding_translation,

PHP4

--- ext/mbstring/mbstring.c 2007-04-04 17:28:18.0 +0200
+++ ext/mbstring/mbstring.c 2007-12-04 18:05:29.363559316 +0100
@@ -815,8 +815,8 @@
 PHP_INI_ENTRY("mbstring.script_encoding", NULL, PHP_INI_ALL, 
OnUpdate_mbstring_script_encoding)
 #endif /* ZEND_MULTIBYTE */
 PHP_INI_ENTRY("mbstring.substitute_character", NULL, 
PHP_INI_ALL, OnUpdate_mbstring_substitute_character)
-STD_PHP_INI_ENTRY("mbstring.func_overload", "0", 
PHP_INI_SYSTEM |
-PHP_INI_PERDIR, OnUpdateInt, func_overload, 
zend_mbstring_globals, mbstring_globals)
+STD_PHP_INI_ENTRY("mbstring.func_overload", "0",
+PHP_INI_SYSTEM, OnUpdateInt, func_overload, 
zend_mbstring_globals, mbstring_globals)

 STD_PHP_INI_BOOLEAN("mbstring.encoding_translation", "0",
 PHP_INI_SYSTEM | PHP_INI_PERDIR, 
OnUpdate_mbstring_encoding_translation,


Previous Comments:


[2008-02-24 22:23:08] lip at lip dot net dot ua

Expected result:

php1.net - Warning:  mb_ereg() function.mb-ereg: mbregex compile err:
premature end of char-class in /var/www/php2/mb.php

php2.net - galaD

Actual result:
--
php1.net - Warning
php2.net - Warning



[2008-02-24 22:03:13] lip at lip dot net dot ua

Description:

PHP 5.2.5
Apache/2.2.8

If I use mbstring.func_overload in .htaccess 
other virtual-host doesn't work.

For example:

DocumentRoot /var/www/php1
ServerName php1.net



DocumentRoot /var/www/php2
ServerName php2.net


in /var/www/php1/.htaccess
php_value mbstring.func_overload 6

In this situation php2.net/mb.php doesn't work when I refresh few
times php1.net/mb.php and php2.net/mb.php



Reproduce code:
---
--mb.php---


Expected result:

galaD

Actual result:
--
Warning:  mb_ereg() function.mb-ereg: mbregex compile err: premature
end of char-class in /var/www/php2/mb.php





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


#43227 [Com]: eregi() mbregex compile err: premature end of regular expression in

2008-02-25 Thread lip at lip dot net dot ua
 ID:   43227
 Comment by:   lip at lip dot net dot ua
 Reported By:  baco at infomaniak dot ch
 Status:   Open
 Bug Type: mbstring related
 Operating System: Linux Debian
 PHP Version:  4.4.7
 New Comment:

I think these bugs are similar.
http://bugs.php.net/bug.php?id=44237


Previous Comments:


[2007-11-09 16:03:14] baco at infomaniak dot ch

Description:

eregi() produce random errors like "function.mb-eregi: mbregex compile
err: premature end of regular expression in" when used with special
chars like accents.

N.B. On the web you can found a lot of reports of this issue. Some post
suggests forcing mbstring.func_overload = 0 but it doesn't work for me.

If Apache1 is restarted the error doesn't come anymore before an amount
of time and request.

$ GET http://localhost/test.php
ok

$ GET http://localhost/test.php
ok

$ GET http://localhost/test.php

Warning:  mb_eregi() [function.mb-eregi]: mbregex compile err:
premature end of regular expression in
/home/www/ca8b72beb934995c1afb34e1a3ceb893/web/test.php on line
2

$ GET http://localhost/test.php

Warning:  mb_eregi() [function.mb-eregi]: mbregex compile err:
premature end of regular expression in
/home/www/ca8b72beb934995c1afb34e1a3ceb893/web/test.php on line
2

$ GET http://localhost/test.php

Warning:  mb_eregi() [function.mb-eregi]: mbregex compile err:
premature end of regular expression in
/home/www/ca8b72beb934995c1afb34e1a3ceb893/web/test.php on line
2

$ GET http://localhost/test.php
ok

$ GET http://localhost/test.php
ok

...


Reproduce code:
---


Expected result:

OK

Actual result:
--

Warning:  mb_eregi() [function.mb-eregi]: mbregex compile err:
premature end of regular expression in
/home/www/ca8b72beb934995c1afb34e1a3ceb893/web/test.php on line
2





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


#43579 [Opn]: sessions time out on 5.2.5

2008-02-25 Thread assid at assid dot com
 ID:   43579
 User updated by:  assid at assid dot com
 Reported By:  assid at assid dot com
 Status:   Open
 Bug Type: Session related
 Operating System: Debian etch
 PHP Version:  5.2.5
 New Comment:

With regards to session files and squirrelmail

I checked the part that you told me. The headers look exactly the same.
Sometimes I get the session kicking me out. The headers during which,
looks exactly the same as the ones when it doesnt kick me out. However,
sometimes i just rightclick in that frame and reload frame and it works,
or i click on any of the available imap folders on the left side.

During the time it kicks me out, the session file still exists, would
explain WHY i can still continue using AFTER that. 

from my previous test and this into consideration, i would GUESS its
something to do with session generation / session file handling or
something related to this.


Previous Comments:


[2008-02-25 08:30:07] assid at assid dot com

okay here you go, 5 hours of sleep helped a bit.

http://spherelinx.com/session.php
Now refresh this slowly (i mean one F5 per second or 2 seconds), till
you hit something like 8-10.

Now press F5 rapidly (dont hold), like 5-8 times. You end up with a new
counter. 

Refresh this counter slowly, and again repeat the above step. Sometimes
you get it to go back to the older counter.

reproduce code: http://spherelinx.com/session.phps
phpinfo - http://spherelinx.com/phpinfo.php

>From my guess, session_name fails or causes some kind of glitch



[2008-02-25 01:28:12] [EMAIL PROTECTED]

Many people, including myself, are running SquirrelMail quite fine on
5.2.5 without any sort of session problems.  The fact that it also
happens in other applications points to a general problem on your end. 
Sessions are really simple.  There are 3 parts to an active session.

1. Your browser sends a session cookie
2. The PHP script that receives the cookie calls session_start()
3. session_start() reads the session data from the session data

So, to debug this, look at each part.  Install something like the
LiveHTTPHeaders Firefox extension and make sure the cookie is being
sent.  Second, make sure there is a session_start() call in the
receiving code.  And third, check to make sure that the session data is
in the session data store.  If you are using the file-based session
store, match the session cookie to the session filename and watch it as
you click around.  Does it suddenly disappear?  If so, figure out why. 


Also check all your session.* settings and if you have multiple servers
behind any sort of load balancer, a per-server file-based session store
obviously won't work.  NFS-based stuff can also cause problems for a
file-based session store.

You can also write your own very simple trivial session test to verify
that sessions are working at all on your setup.



[2008-02-24 20:23:25] assid at assid dot com

The problem is I didnt make squirrelmail. So i am not sure of what i
can provide as the reproducable script. I am using the current stable
release.

I wanted to give something else to my users in the meantime, so i tried
horde, and well, that seems to have session timeout issues as well.



[2008-02-24 20:10:03] [EMAIL PROTECTED]

Please provide a short reproducing script.



[2008-02-24 19:16:31] assid at assid dot com

I decided to try and give php5.2-200802241730 a try to see perhaps if
the bug is know and rectified.

I know still have the session time outs, except now its worse. Instead
of being able to continue after clicking on the folder on the left side,
it now logs out totally, effectively destroying the session.



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

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


#43207 [NoF->Opn]: .htaccess settings missing (sometimes)

2008-02-25 Thread phpmyforum at gmail dot com
 ID:   43207
 User updated by:  phpmyforum at gmail dot com
 Reported By:  phpmyforum at gmail dot com
-Status:   No Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: Linux
-PHP Version:  5.2.5RC2
+PHP Version:  5.2.5
 New Comment:

> Try change the php_flag to php_value and use 0 or 1 as value.

Didn't help.


Today I could reproduce this behavior with PHP 5.2.5!


Previous Comments:


[2008-01-14 16:19:26] dan at eskhosting dot com

php_value/php_flag - no different too.



[2008-01-14 16:05:14] dan at eskhosting dot com

register_globals are switching On/Off randomise!
Values: 1/On/true, 0/Off/false; place: .htacess, httpd.conf - no
difference.
Only global setting in php.ini are effective.
Other variables works good.

System: Red Hat Enterprise Linux ES release 4 (Nahant Update 6)
PHP: 5.2.5
'./configure' '--with-apxs=/usr/local/apache/bin/apxs'
'--prefix=/usr/local' '--enable-bcmath' '--enable-calendar'
'--with-curl' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-gettext'
'--with-iconv' '--enable-mbstring' '--enable-mbregex' '--with-mcrypt'
'--enable-magic-quotes' '--with-mysqli' '--with-mysql=/usr'
'--with-openssl' '--enable-discard-path' '--with-pear'
'--with-pgsql=/usr' '--enable-safe-mode' '--enable-sockets' '--with-ttf'
'--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--with-xmlrpc'
'--with-xsl=/usr' '--enable-zip' '--with-zlib' '--with-bz2'
Apache: 1.3.37



[2007-11-19 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2007-11-11 18:49:12] [EMAIL PROTECTED]

Try change the php_flag to php_value and use 0 or 1 as value.



[2007-11-06 18:25:23] phpmyforum at gmail dot com

Description:

Since I upgraded from php4 to PHP 5.2.5RC2 .htaccess php_* options
getting ignored.
This happens for most, but not all requests.

The default (php.ini) option for register_globals is off.

My .htaccess file looks like this:

php_flag register_globals on


Now I downgraded to PHP 5.2.4 and it's working again.

Hint: this bug looks very similar to #28522.

PS: this may happen for other options

'./configure' '--prefix=/bbo/php'
'--with-apxs2=/bbo/apachessl/bin/apxs'
'--with-config-file-path=/bbo/etc/httpd' '--with-openssl=/bbo/usr'
'--with-zlib' '--with-zlib-dir=/bbo/usr' '--with-bz2=/bbo/usr'
'--enable-ftp' '--enable-exif' '--with-gd=/bbo/usr'
'--enable-gd-native-ttf' '--with-jpeg-dir=/bbo/usr'
'--with-png-dir=/bbo/usr' '--with-freetype-dir=/bbo/usr'
'--with-mysql=/bbo/usr' '--with-mysqli=/bbo/usr/bin/mysql_config'
'--with-pdo-mysql=/bbo/usr' '--with-iconv' '--with-iconv-dir=/bbo/usr'
'--with-curl=/bbo/usr' '--with-curlwrappers' '--enable-soap'
'--enable-sockets' '--enable-mbstring=all' '--enable-mbregex'
'--with-xsl=/bbo/usr' '--with-libxml-dir=/bbo/usr'
'--with-pspell=/bbo/usr' '--with-ldap=/bbo/usr' '--with-tidy=/bbo/usr'
'--with-gettext=/bbo/usr' '--with-mcrypt=/bbo/usr'
'--with-pcre-regex=/bbo/usr' '--enable-sigchild' '--enable-sysvshm'
'--enable-sysvsem' '--enable-zip' '--disable-short-tags'
'--with-pear=/bbo/php_includes'
'--with-imap=/download/webserver/files/imap/' '--with-imap-ssl'
'--without-kerberos'






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


#44241 [NEW]: PHP Access Violation on Mysqli->fetch_array()

2008-02-25 Thread alessandroministeri at hotmail dot com
From: alessandroministeri at hotmail dot com
Operating system: Windows Vista Home Premium
PHP version:  5.2.5
PHP Bug Type: Reproducible crash
Bug description:  PHP Access Violation on Mysqli->fetch_array()

Description:

Hi all,
i've founded a bug with MySQL 5.1.23 when perform a fetch_array() MySQLI
method.

It return an Access Violation.

I'm tried on PHP 5.X both on CGI and ISAPI Mode with iis 7.0

I rollback to MySQL 5.0.x and it runs correctly.


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


#44205 [Opn]: MB string conversion to support CP1250 character set

2008-02-25 Thread egil at wp dot pl
 ID:   44205
 User updated by:  egil at wp dot pl
 Reported By:  egil at wp dot pl
 Status:   Open
 Bug Type: mbstring related
 Operating System: Windows
 PHP Version:  5.2.5
 New Comment:

This should help - best-fit mapping to Unicode for CP1250:
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1250.txt


Previous Comments:


[2008-02-21 18:03:01] egil at wp dot pl

Description:

It would be nice if MB string conversion would allow using CP1250 as on
of it's character sets. This would make Central Europeans (such as
myself) life a little easier ;).






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


#44217 [Fbk->Opn]: Output after stdout/stderr closed cause immediate exit

2008-02-25 Thread exe at travian dot org
 ID:   44217
 User updated by:  exe at travian dot org
 Reported By:  exe at travian dot org
-Status:   Feedback
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: GNU/Linux Kernel 2.6.18
 PHP Version:  5.2.5
 New Comment:

I'd expect php to discard every output after STDOUT is closed, instead
of doing a silent exit (which is hard to track because no error handler
or shutdown function is called). Another option (if output in this
situation is considered to be an error) would be to trigger a
warning/fatal and/or call the shutdown function. This would, at least,
make it possible to track this issue.

I have to close STDOUT and STDERR in a daemonized processes to detach
from the controlling terminal.


Previous Comments:


[2008-02-24 00:40:01] [EMAIL PROTECTED]

Another bug #44218 describes some more expected behaviour caused by
closing the input/output streams.

NOTE: Correct manual page:
http://www.php.net/manual/en/wrappers.php.php



[2008-02-24 00:34:08] [EMAIL PROTECTED]

That's quite expected since you're still trying to output to STDOUT.
Why do you want to close STDOUT anyway?

See also: http://www.php.net/wrappers.php



[2008-02-22 17:32:15] exe at travian dot org

Description:

If STDOUT and/or STDERR are closed, output by the php script cause the
interpreter to exit immediately.

According to strace output, php tries to write to the closed STDOUT
file handle, causing a "Bad file descriptor" error and exit of the
interpreter:

[...]
close(1)= 0
[...]
write(1, "foo", 3)  = -1 EBADF (Bad file
descriptor)
close(0)= 0
close(2)= 0
[...]
exit_group(0)   = ?
Process 19177 detached

Reproduce code:
---


Expected result:

No output, php sleeping for 10 seconds.

Actual result:
--
php exits immediately, strace shows an "Bad file descriptor" on the
write() try to STDOUT:

[...]
read(3, "http://bugs.php.net/?id=44217&edit=1


#44219 [Com]: Fix for Bug #44209 Causes Test Regression

2008-02-25 Thread bisho at onirica dot com
 ID:   44219
 Comment by:   bisho at onirica dot com
 Reported By:  kirkland at ubuntu dot com
 Status:   Feedback
 Bug Type: Date/time related
 Operating System: Linux 64 bit
 PHP Version:  5.2.5
 New Comment:

It seens a test-problem, not a regression. The new output of
int(-62169962400) is correct.


Previous Comments:


[2008-02-24 19:51:42] [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-02-22 20:31:34] kirkland at ubuntu dot com

Test script:
# cat /tmp/foo.php 


Built without patch:
# php /tmp/foo.php 
bool(false)


Built with patch:
# ./cli-build/sapi/cli/php /tmp/foo.php 
int(-62169962400)



[2008-02-22 20:21:41] kirkland at ubuntu dot com

In other words, adding that 3-line patch creates the following test
regressions.  The following tests now fail on 64-bit Linux:

+ Bug #41523 (strtotime('-00-00 00:00:00') is parsed as 1999-11-30)
[ext/date/tests/bug41523.phpt]

+ mktime() [3] [ext/date/tests/mktime-3.phpt]

+ strtotime() and mysql timestamps
[ext/date/tests/strtotime-mysql.phpt]

+ strtotime() function [ext/date/tests/strtotime3.phpt]

+ wddx deserialization test [ext/wddx/tests/001.phpt]



[2008-02-22 19:12:18] kirkland at ubuntu dot com

The diff shown in that pastebin is from two subsequent runs, both on
64-bit Linux.

The only difference between the two is:

+++ php-src/ext/date/lib/timelib.h  Fri Feb 22 09:48:18 2008
...
+#if HAVE_LIMITS_H
+#include 
+#endif
...



[2008-02-22 18:38:26] [EMAIL PROTECTED]

Not really... it's just that results are sometimes different on 32 vs
64 bit. 



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

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


#43861 [Com]: suhosin patch detects heap overflow on mssql_free_result()

2008-02-25 Thread andy at diginights dot com
 ID:   43861
 Comment by:   andy at diginights dot com
 Reported By:  skennedy at vcn dot com
 Status:   No Feedback
 Bug Type: MSSQL related
 Operating System: FreeBSD 6.2
 PHP Version:  5.2.5
 New Comment:

Same issue here, we get white pages browsing our site.
Also we get "ALERT - canary mismatch on efree() - heap overflow
detected" in apache  error log.
Using 
apache 2.2.8-1
php 5.2.5-2
mysql 5.0.51-3

Software ist Burning Board (http://woltlab.de/)


Previous Comments:


[2008-02-18 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2008-02-10 14:50:28] [EMAIL PROTECTED]

Can you please try a CVS snapshot on PHP 5.3.0 in about 4-5 hours. I've

just applied a patch to the code that may fix your problem. 

Alternatively you can try the patch yourself from this URL;

http://cvs.php.net/viewvc.cgi/php-src/ext/mssql/php_mssql.c?
r1=1.152.2.13.2.4.2.3&r2=1.152.2.13.2.4.2.4&diff_format=u




[2008-02-10 07:57:04] cxcxcxcx at gmail dot com

I have encountered a similar problem. When "select" contains
'smalldatetime' or 'datetime' columns.

I am using Debian Sid and php5 php5-sybase.



[2008-01-31 00:16:10] [EMAIL PROTECTED]

Ok, there we go.  Looks like there is an off-by-one in there.  But
looking at the PHP code, it seems ok.

int res_length = dbdatlen(mssql_ptr->link,offset);
...
res_buf = (unsigned char *) emalloc(res_length+1);
res_length =
dbconvert(NULL,coltype(offset),dbdata(mssql_ptr->link,offset),
res_length, SQLCHAR,res_buf,-1);
res_buf[res_length] = '\0';

So, we aren't going beyond the buffer, it is somewhere in the
dbconvert() code writing to res_buf that is off.  Passing in a larger
buffer would fix it, but it would be good to understand why dbdatlen()
isn't returning the right length.  Is it an encoding issue?  One assumes
single-byte encoding and the other multi-byte or something?

Looping in Frank to have a look.





[2008-01-30 21:23:02] skennedy at vcn dot com

Okay, here is that:

http://www.bandwidthbuilders.com/valgrind-output-nozendalloc.txt



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

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


#44238 [Opn->Fbk]: Using LDAP causes script crash

2008-02-25 Thread jani
 ID:   44238
 Updated by:   [EMAIL PROTECTED]
 Reported By:  BenBE at omorphia dot de
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Debian Etch
 PHP Version:  5.2.5
 New Comment:

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




Previous Comments:


[2008-02-24 22:55:32] BenBE at omorphia dot de

Description:

When updating PHP5 to the latest version (5.2.5-2 or newer), using the
LDAP extension produces a crash, causing the script to abort.

Version 5.2.4-2 was latest version, that didn't crash that way. Also
tried with 5.2.5-2, but same problem.

Reproduce code:
---
function get_ldap_name($unix)
{
$ds = ldap_connect("ldap.example.com");
$ldap_arr = get_ldap_info($unix, $ds);
if ((is_array($ldap_arr)) && array_key_exists(0, $ldap_arr)) {
$data = $ldap_arr[0]['cn'][0];
ldap_close($ds);
return $data;
}
ldap_close($ds);
return false;
}


Expected result:

Script returns the full name of the user specified

Actual result:
--
tail -f /var/log/apache2/error.log

apache2: getattr.c:80: ldap_first_attribute: Assertion `len != 0'
failed.
[Sun Feb 24 23:23:09 2008] [notice] child pid 1578 exit signal Aborted
(6)
apache2: getattr.c:80: ldap_first_attribute: Assertion `len != 0'
failed.
[Sun Feb 24 23:23:14 2008] [notice] child pid 1580 exit signal Aborted
(6)






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


#44240 [NEW]: No data returned by ODBC

2008-02-25 Thread johann dot maurer at bfh dot ch
From: johann dot maurer at bfh dot ch
Operating system: Win2003 SP2
PHP version:  5.2.5
PHP Bug Type: ODBC related
Bug description:  No data returned by ODBC

Description:

OS: Win2003 SP2
IIS: 6.0.3790
ISAPI - connection


No data is returned from DB (Sybase-Anywhere) over ODBC interface since
running php 5.2.5. Connection and select are OK, but no data is returned.
I tested without changing anything on the ODBC setup, only switched
PHP-Version, restarted iis.


Thanks
Johann

Reproduce code:
---
";
$qry = "select * from rektor.odbc_Test where Data like 'a%' ";
echo "qry = $qry \n";
$dbid = odbc_exec($dbo,$qry);
echo "dbid = $dbid ";
$res = odbc_result_all($dbid);
if ($res == false) echo 'fetch = false! ';
echo "fetch = '$res' ";
print_r($a_res);
odbc_free_result($dbid);
?>


Expected result:

Testoutput with php 5.1.2
-

odbc = Resource id #3
qry = select * from rektor.odbc_Test where Data like 'a%'
dbid = Resource id #4
ColID   Data
1   a
2   abcdefgh
fetch = '2'  


Actual result:
--
Testoutput with php 5.2.5
-

odbc = Resource id #3
qry = select * from rektor.odbc_Test where Data like 'a%'
dbid = Resource id #4
ColID   Data


fetch = '2' 

Comment: Two blank rows returned.

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


#43579 [Fbk->Opn]: sessions time out on 5.2.5

2008-02-25 Thread assid at assid dot com
 ID:   43579
 User updated by:  assid at assid dot com
 Reported By:  assid at assid dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Session related
 Operating System: Debian etch
 PHP Version:  5.2.5
 New Comment:

okay here you go, 5 hours of sleep helped a bit.

http://spherelinx.com/session.php
Now refresh this slowly (i mean one F5 per second or 2 seconds), till
you hit something like 8-10.

Now press F5 rapidly (dont hold), like 5-8 times. You end up with a new
counter. 

Refresh this counter slowly, and again repeat the above step. Sometimes
you get it to go back to the older counter.

reproduce code: http://spherelinx.com/session.phps
phpinfo - http://spherelinx.com/phpinfo.php

>From my guess, session_name fails or causes some kind of glitch


Previous Comments:


[2008-02-25 01:28:12] [EMAIL PROTECTED]

Many people, including myself, are running SquirrelMail quite fine on
5.2.5 without any sort of session problems.  The fact that it also
happens in other applications points to a general problem on your end. 
Sessions are really simple.  There are 3 parts to an active session.

1. Your browser sends a session cookie
2. The PHP script that receives the cookie calls session_start()
3. session_start() reads the session data from the session data

So, to debug this, look at each part.  Install something like the
LiveHTTPHeaders Firefox extension and make sure the cookie is being
sent.  Second, make sure there is a session_start() call in the
receiving code.  And third, check to make sure that the session data is
in the session data store.  If you are using the file-based session
store, match the session cookie to the session filename and watch it as
you click around.  Does it suddenly disappear?  If so, figure out why. 


Also check all your session.* settings and if you have multiple servers
behind any sort of load balancer, a per-server file-based session store
obviously won't work.  NFS-based stuff can also cause problems for a
file-based session store.

You can also write your own very simple trivial session test to verify
that sessions are working at all on your setup.



[2008-02-24 20:23:25] assid at assid dot com

The problem is I didnt make squirrelmail. So i am not sure of what i
can provide as the reproducable script. I am using the current stable
release.

I wanted to give something else to my users in the meantime, so i tried
horde, and well, that seems to have session timeout issues as well.



[2008-02-24 20:10:03] [EMAIL PROTECTED]

Please provide a short reproducing script.



[2008-02-24 19:16:31] assid at assid dot com

I decided to try and give php5.2-200802241730 a try to see perhaps if
the bug is know and rectified.

I know still have the session time outs, except now its worse. Instead
of being able to continue after clicking on the folder on the left side,
it now logs out totally, effectively destroying the session.



[2008-02-11 03:45:29] jsnyxx at gmail dot com

We've found similar problems -- see our report here:

http://xcache.lighttpd.net/ticket/163

(We initially thought that it was Xcache, but that doesn't seem to be
the case now).



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

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