#24424 [Com]: Complains about libxml even when not compiling with XML

2003-10-14 Thread faern at sbcglobal dot net
 ID:   24424
 Comment by:   faern at sbcglobal dot net
 Reported By:  liz at xcalibur dot demon dot co dot uk
 Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: linux  2.4.20
 PHP Version:  5.0.0b1 (beta1)
 New Comment:

Nope, still broken.

checking for simplexml support... yes
configure: error: libxml2 version 2.5.1 or greater required.

This is after urpmi the version I had.

This stinks, I don't want to break a ton of dependencies
over a feature I don't even want.

You need to add --leave-xml-the-hell-alone

:(


Previous Comments:


[2003-08-20 01:48:29] schweitzerh at hotmail dot comm

I was having the same issue this guy was experiencing, but I actually
was recompiling PHP specifically for XML support. Installing
libxml2-devel did the trick!

Thanks!



[2003-07-01 01:11:59] [EMAIL PROTECTED]

--enable-wddx requires libxml2 too



[2003-07-01 01:06:24] liz at xcalibur dot demon dot co dot uk

Given I have submitted my entire configuration, please, tell me what.

The line now reads

./configure --with-mysql=/usr/bin
--with-apache=/usr/src/web/apache_1.3.27 --enable-discard-path
--enable-track-vars --disable-debug --enable-dbase --enable-trans-sid
--enable-inline-optimization --enable-ftp --enable-sockets --with-imap
--with-imap-ssl=/usr/include/openssl --enable-libgcc --disable-ipv6
--enable-exif --with-gd --with-jpeg-dir=/usr/local/bin --with-zlib
-dir=/usr/local/lib --enable-dio --enable-gd-native-ttf
--enable-sysvmsg --enable-sysvsem --enable-sysvshm --enable-wddx
--enable-yp --disable-xml --disable-simplexml --disable-dom



[2003-06-30 17:55:58] [EMAIL PROTECTED]

It works just fine. You're just doing something wrong.




[2003-06-30 17:05:17] [EMAIL PROTECTED]

--disable-xml --disable-simplexml --disable-dom --without-pear
does it with latest CVS.




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

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


#25798 [Fbk->Ver]: forever-running or no-error-abort in preg_match

2003-10-14 Thread sniper
 ID:   25798
 Updated by:   [EMAIL PROTECTED]
 Reported By:  musha dot yoshinori at nifty dot ne dot jp
-Status:   Feedback
+Status:   Verified
 Bug Type: PCRE related
 Operating System: Windows XP Pro
-PHP Version:  4.3.3
+PHP Version:  4.3.4RC2-dev
 New Comment:

Reproduced with latest CVS (under Windows XP), PHP as Apache2 module.
Works fine with CLI.



Previous Comments:


[2003-10-15 01:51:59] [EMAIL PROTECTED]

No, it's not okay, most likely you're mixing two different set of dlls
from different PHP versions. Make sure you don't have ANY php4ts.dll
files in your system except for the one that comes with the snapshot.




[2003-10-14 22:45:30] musha dot yoshinori at nifty dot ne dot jp

I am sorry for late. I was busy for business.

Now, I checked the bug using the latest version of PHP, 
PHP/4.3.4RC2-dev. As the result, I found that the bug appeared again. 

By the bug, I feel that it is difficult to describe regular expressions
avoiding the bug in preg_match. I want to describe regular expressions
more freely.

By the way, in the latest version, phpinfo() shows "Apache Version:
Apache/2.0.46 (Win32) PHP/4.3.4RC2-dev", but phpversion() shows
"4.3.3". Is it OK? 

Thank you.



[2003-10-10 11:50:21] [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





[2003-10-09 00:09:43] musha dot yoshinori at nifty dot ne dot jp

I know that it depends on platforms. I use PHP on Windows XP Pro,
Apache2.0.46 and PHP4.3.3. It also appears on PHP4.3.3RC1. A preg_match
with the same regular expression works fine on other platform. 
Thank you.



[2003-10-08 22:36:43] [EMAIL PROTECTED]

Works fine here on Linux, what locale are you using?



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

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


#25798 [Opn->Fbk]: forever-running or no-error-abort in preg_match

2003-10-14 Thread sniper
 ID:   25798
 Updated by:   [EMAIL PROTECTED]
 Reported By:  musha dot yoshinori at nifty dot ne dot jp
-Status:   Open
+Status:   Feedback
 Bug Type: PCRE related
 Operating System: Windows XP Pro
 PHP Version:  4.3.3
 New Comment:

No, it's not okay, most likely you're mixing two different set of dlls
from different PHP versions. Make sure you don't have ANY php4ts.dll
files in your system except for the one that comes with the snapshot.



Previous Comments:


[2003-10-14 22:45:30] musha dot yoshinori at nifty dot ne dot jp

I am sorry for late. I was busy for business.

Now, I checked the bug using the latest version of PHP, 
PHP/4.3.4RC2-dev. As the result, I found that the bug appeared again. 

By the bug, I feel that it is difficult to describe regular expressions
avoiding the bug in preg_match. I want to describe regular expressions
more freely.

By the way, in the latest version, phpinfo() shows "Apache Version:
Apache/2.0.46 (Win32) PHP/4.3.4RC2-dev", but phpversion() shows
"4.3.3". Is it OK? 

Thank you.



[2003-10-14 20:31:51] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2003-10-10 11:50:21] [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





[2003-10-09 00:09:43] musha dot yoshinori at nifty dot ne dot jp

I know that it depends on platforms. I use PHP on Windows XP Pro,
Apache2.0.46 and PHP4.3.3. It also appears on PHP4.3.3RC1. A preg_match
with the same regular expression works fine on other platform. 
Thank you.



[2003-10-08 22:36:43] [EMAIL PROTECTED]

Works fine here on Linux, what locale are you using?



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

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


#25838 [Bgs]: Dom_Node->child_nodes() is not live as the W3C DOM specification demands

2003-10-14 Thread chregu
 ID:   25838
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Martin dot Honnen at arcor dot de
 Status:   Bogus
 Bug Type: DOM XML related
 Operating System: Windows XP
 PHP Version:  4.3.3
 New Comment:

Just for your Information:

Once we have implemented NodeLists in the new ext/dom for PHP5, this
should work as expected by the W3C.


Previous Comments:


[2003-10-13 05:29:14] Martin dot Honnen at arcor dot de

But the DOM specification says "changes are automatically reflected in
the NodeList, without further action on the user's part". If you have
to call child_nodes() again and again to have it updated then changes
are not automatically reflected in the NodeList. Compare a simple
JavaScript program to be run in Mozilla:

var xmlDocument = document.implementation.createDocument('', '',
null);
var rootElement = xmlDocument.createElement('gods');
xmlDocument.appendChild(rootElement);
var childNodes = rootElement.childNodes;
for (var i = 0; i < 5; i++) {
  var god = xmlDocument.createElement('god');
  god.setAttribute('name', 'god ' + i);
  rootElement.appendChild(god);
  alert(childNodes.length);
}

You will find that childNodes.length is incremented although childNodes
is created outside of the loop.



[2003-10-12 22:15:27] [EMAIL PROTECTED]

It works fine when you actually set the $childNodes variable inside the
for() loop.




[2003-10-11 12:23:04] Martin dot Honnen at arcor dot de

Description:

The W3C DOM Level 2 specification at
  http://www.w3.org/TR/DOM-Level-2-Core/core.html#td-live
says about NodeList collections that they should be live, meaning

if a DOM user gets a NodeList object containing the children of an
Element, then subsequently adds more children to that element (or
removes children, or modifies them), those changes are automatically
reflected in the NodeList, without further action on the user's part.

However my test with PHP 4.3.3 and the following settings for DOMXML

DOM/XML enabled
DOM/XML API Version 20020815
libxml Version  20507
HTML Supportenabled
XPath Support   enabled
XPointer Supportenabled
DOM/XSLTenabled
libxslt Version 1.0.30
libxslt compiled against libxml Version 2.5.7

shows that the result returned from Node->child_nodes() is not live but
static.

Reproduce code:
---
\n";
  echo htmlentities($xmlDocument->dump_mem(true));
  echo "\n";
}
$xmlDocument = domxml_new_doc("1.0");
$rootElement = $xmlDocument->create_element("gods");
$xmlDocument->append_child($rootElement);
$childNodes = $rootElement->child_nodes();
echo 'count($childNodes): ' . count($childNodes) . "\n";
$xmlDocument->append_child($rootElement);
for ($i = 0; $i < 5; $i++) {
  $god = $xmlDocument->create_element("god");
  $god->set_attribute("name", "god $i");
  $rootElement->append_child($god);
  dumpDoc($xmlDocument);
  echo 'count($childNodes): ' . count($childNodes) . "\n";
}
?>

Expected result:

I would expect count($childNodes) to be incremented every time
$rootElement->append_child($god) is called. That is what the W3C DOM
understands to be a live collection, and that is what happens with
conformant DOM implementations (as the one in Mozilla or the one in
SUN's Java SDK 1.4).

Actual result:
--
The output with dump_mem shows that child elements are added but the
output of count($childNodes) is always 0.





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


#25777 [Opn->Csd]: char and varchar fields are being rtrimmed (and also ltrimmed?) using freetds

2003-10-14 Thread iliaa
 ID:   25777
 Updated by:   [EMAIL PROTECTED]
 Reported By:  duh at dowebwedo dot com
-Status:   Open
+Status:   Closed
 Bug Type: MSSQL related
 Operating System: Debian GNU/Linux 3.0
 PHP Version:  4.3.4RC1
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2003-10-10 06:12:57] duh at dowebwedo dot com

the configure line is:

'./configure' '--with-mysql' '--with-apxs=/www/bin/apxs'
'--with-gd=/usr/local' '--with-png-dir' '--with-freetype-dir'
'--with-pear' '--with-zlib-dir' '--enable-track-vars'
'--enable-trans-sid' '--disable-posix-threads' '--enable-shared'
'--with-pgsql=/usr' '--with-unixODBC=/usr/local/easysoft/unixODBC'
'--with-mssql=/usr/local'



[2003-10-07 19:09:27] [EMAIL PROTECTED]

What was the configure line used to configure PHP?




[2003-10-07 09:43:10] duh at dowebwedo dot com

Description:

I am busy developing a new improved version of our intranet running on
Apache/php/Debian and moved in this version from ODBC to MSSQL/Sybase
connections (ODBC gave a lot of overhead and appeared being quite
slow).

In several intranet functions we aquire data from the Exact financial
suite (http://www.exactsoftware.com) which is largely used in The
Netherlands and abroad and which currently uses MSSQL as a database
backend. In the most recent versions of exact you can still see their
MS-DOS history (exact used btrieve and several other MS-DOS databases
in the old days) because several columns are still padded to the
maximum column width. Hence the word "hi" in a varchar(8) would be
stored as "hi  " (hi+6 spaces). 

Now when using mssql_* functions in php over freetds all selected
values are right trimmed, so SELECT hi FROM table will return "hi"
instead of the actual data in the table "hi  ". I have currently
only tried selecting, i don't know what happens when inserting
(probably the same?).

Obviously, this is not what I want since this would lead to data
inconsistency (in your financial system!) and an unuseable financial
system (which ofcourse is the worst that could happen to a company).

At first I thought it was due to the fact that sybase used to right
trim these values so freetds does it as well for compatibility's sake.
But when I executed a query command line through the tsql
(/usr/local/bin/tsql) application it appeared that then the values were
NOT being right trimmed. So appearantly the interface between freetds
and my application (which in my opinion can only be php) does the
trimming of values with spaces.

Ofcourse one could say that I need to trim or append spaces to these
values myself, but since most data and software is dynamic and only
some (var)char fields will get appended and some don't, there is no way
of telling which columns should be appended (or prepended) and which
shouldn't.

For the sake of data consistency I would either like to see this bug
fixed, or -if it is no bug but a feature- see a configuration option
being introduced to overrule this trimming.

Reproduce code:
---
In php the following code will return trimmed values:
$db= mssql_connect('server','user','pass'); 
$result= mssql_query("SELECT TOP 1 medewerker FROM Efw_001.[dbo].Prres1
WHERE medewerker IS NOT NULL AND medewerker LIKE '%  %'");
$a  = mssql_fetch_assoc($result); 
print_r($a);

but commandline this values are not being trimmed:
# tsql -S server -U user -P pass
locale is "C"
charset is "ANSI_X3.4-1968"
Msg 5703, Level 0, State 1, Server NTS1, Line 0
Changed language setting to us_english.
1> SELECT TOP 1 medewerker FROM Efw_001.[dbo].Prres1 WHERE medewerker
IS NOT NULL AND medewerker LIKE '%  %'
2> go
medewerker
'100 ' (size=8)
1> SELECT TOP 1 rtrim(medewerker) as trimmed_medewerker FROM
Efw_001.[dbo].Prres1 WHERE medewerker IS NOT NULL AND medewerker LIKE
'%  %'
2> go
trimmed_medewerker
'100' (size=3)

(I added single quotes around the results and wrote the sizes behind it
so you can see the difference between the two queries)

Expected result:

Obviously I expect to get exactly the same data that is stored in the
database instead of modified (trimmed) data.






-- 
Edit this bug report at http://bugs.php.net/?id=2577

#25874 [Opn->Bgs]: var_export does not output valid code

2003-10-14 Thread iliaa
 ID:   25874
 Updated by:   [EMAIL PROTECTED]
 Reported By:  fire at firepages dot com dot au
-Status:   Open
+Status:   Bogus
 Bug Type: Variables related
 Operating System: XP
 PHP Version:  4.3.3
 New Comment:

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

The trailing comma while unusual is perfectly valid and the code
evaluates correctly.


Previous Comments:


[2003-10-14 22:21:48] fire at firepages dot com dot au

Description:

output from var_export($var,true) has trailing comma so you have to
strip that manually before utilising the returned string.

the manual example shows this behaviour so perhaps its a feature ?

Reproduce code:
---
$yaks = array( 'dfdf'=>'a' , 'b' , 'c' , 'd' ) ;
echo '$llama = ' . var_export( $yaks , true ) . ' ;' ;

Expected result:

$llama = array ( 'dfdf' => 'a', 0 => 'b', 1 => 'c', 2 => 'd' ) ;

Actual result:
--
$llama = array ( 'dfdf' => 'a', 0 => 'b', 1 => 'c', 2 => 'd', ) ;





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


#25798 [NoF->Opn]: forever-running or no-error-abort in preg_match

2003-10-14 Thread musha dot yoshinori at nifty dot ne dot jp
 ID:   25798
 User updated by:  musha dot yoshinori at nifty dot ne dot jp
 Reported By:  musha dot yoshinori at nifty dot ne dot jp
-Status:   No Feedback
+Status:   Open
 Bug Type: PCRE related
 Operating System: Windows XP Pro
 PHP Version:  4.3.3
 New Comment:

I am sorry for late. I was busy for business.

Now, I checked the bug using the latest version of PHP, 
PHP/4.3.4RC2-dev. As the result, I found that the bug appeared again. 

By the bug, I feel that it is difficult to describe regular expressions
avoiding the bug in preg_match. I want to describe regular expressions
more freely.

By the way, in the latest version, phpinfo() shows "Apache Version:
Apache/2.0.46 (Win32) PHP/4.3.4RC2-dev", but phpversion() shows
"4.3.3". Is it OK? 

Thank you.


Previous Comments:


[2003-10-14 20:31:51] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2003-10-10 11:50:21] [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





[2003-10-09 00:09:43] musha dot yoshinori at nifty dot ne dot jp

I know that it depends on platforms. I use PHP on Windows XP Pro,
Apache2.0.46 and PHP4.3.3. It also appears on PHP4.3.3RC1. A preg_match
with the same regular expression works fine on other platform. 
Thank you.



[2003-10-08 22:36:43] [EMAIL PROTECTED]

Works fine here on Linux, what locale are you using?



[2003-10-08 14:04:09] musha dot yoshinori at nifty dot ne dot jp

Description:

PHP aborts without any message or runs forever in below case.
Platform: Windows XP Pro, Apache2.0.46, PHP4.3.3

For example, in preg_match('/a(?:.)+z/',$str,$match), the length of
string matched between 'a' and 'z' is more than approximately 1KB. It
always appears. According to the length, PHP aborts without any message
or runs forever.

It also appears in preg_match('/a(?>.)+z/',$str,$match), but does not
appear in preg_match('/a(.)+z/',$str,$match) and
preg_match('/a.+z/',$str,$match).

Actually, I want to use
preg_match_all('/]*>((?>.(?!<\/tr>))+.)<\/tr>/is',$str,$matches)
and so on.

Reproduce code:
---
$str =<

#25874 [NEW]: var_export does not output valid code

2003-10-14 Thread fire at firepages dot com dot au
From: fire at firepages dot com dot au
Operating system: XP
PHP version:  4.3.3
PHP Bug Type: Variables related
Bug description:  var_export does not output valid code

Description:

output from var_export($var,true) has trailing comma so you have to strip
that manually before utilising the returned string.

the manual example shows this behaviour so perhaps its a feature ?

Reproduce code:
---
$yaks = array( 'dfdf'=>'a' , 'b' , 'c' , 'd' ) ;
echo '$llama = ' . var_export( $yaks , true ) . ' ;' ;

Expected result:

$llama = array ( 'dfdf' => 'a', 0 => 'b', 1 => 'c', 2 => 'd' ) ;

Actual result:
--
$llama = array ( 'dfdf' => 'a', 0 => 'b', 1 => 'c', 2 => 'd', ) ;

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


#20006 [Ana->Ver]: cannot use 2 database connections

2003-10-14 Thread sniper
 ID:   20006
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kezal at mail dot ru
-Status:   Analyzed
+Status:   Verified
 Bug Type: OCI8 related
 Operating System: Linux (RH)
 PHP Version:  4.3.3RC4-dev


Previous Comments:


[2002-10-21 08:48:34] [EMAIL PROTECTED]

Also,

once you're there, Thies, what could we about maintaining the
connections over the database reloads as reported in several posts
earlier.

I am, refering for the cases when, after restarting Oracle you'd need
to necessarely restart apache. I tried to research on it and it seems
to me that this is doable by controlling the connection via Zend
handlers (or something like that) but I am still learning about Zend
Engine, so couldn't fix that part yet.

Maxim Maletsky



[2002-10-21 05:29:05] [EMAIL PROTECTED]

i could verfy that indeed there is a problem. please add a 
2nd tnsname for the same database and do 
$a = ocilogon(.., .., tns1); 
$b = ocilogon(.., .., tns2); 
to get two independent database connections. 
 
i really hope that i find some time to fix this soon!! 
 



[2002-10-21 04:08:02] kezal at mail dot ru

If you have created 2nd connection, you cannot use
1st connection. I think 2nd connection doesn't create its own Oracle
cursor till first oraparse/exec executed

=== cut ===
//1. Connect and exec OK.
$conn_id1 = ociLogon("test","test123");
$stmt1 = ociparse($conn_id1,"select count(*) from tbl_lang_");
ociexecute($stmt1);

//2. Connect OK.
$conn_id2 = ociLogon("book1","book123");

//3. Exec fails!
$stmt1 = ociparse($conn_id1,"select count(*) from tbl_lang_");
ociexecute($stmt1);
=== cut ===





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


#19434 [Opn->Fbk]: oci8 + ldap -> crash

2003-10-14 Thread sniper
 ID:   19434
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ronan dot salmon at staff dot ittralee dot ie
-Status:   Open
+Status:   Feedback
 Bug Type: OCI8 related
 Operating System: redhat 7.3
 PHP Version:  4.3.3RC4-dev
 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




Previous Comments:


[2003-07-17 03:40:47] ronan dot salmon at staff dot ittralee dot ie

Sorry, I don't know what I've done yesterday but in fact LDAP doesn't
work alone anymore.

Here the script :
Wrong username or password!\n";
exit;
}
?>

I'm using the same php as yesterday.

[~/php]# gdb ./php4-STABLE-200307160330/sapi/cgi/php login.php
(gdb) run login.php
Starting program: /root/php/php4-STABLE-200307160330/sapi/cgi/php
login.php
[New Thread 16384 (LWP 23469)]
 
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 23469)]
0x40a71a34 in _int_free () from /lib/libc.so.6
(gdb) bt
#0  0x40a71a34 in _int_free () from /lib/libc.so.6
#1  0x40a709cc in free () from /lib/libc.so.6
#2  0x08065d81 in zif_ldap_get_entries (ht=2, return_value=0x8208040,
this_ptr=0x0, return_value_used=1, tsrm_ls=0x40d76440)
at /root/php/php4-STABLE-200307160330/ext/ldap/ldap.c:953
#3  0x0813ce45 in execute (op_array=0x8203028, tsrm_ls=0x81876b0)
at /root/php/php4-STABLE-200307160330/Zend/zend_execute.c:1616
#4  0x0812f7f1 in zend_execute_scripts (type=8, tsrm_ls=0x81876b0,
retval=0x0,
file_count=3) at
/root/php/php4-STABLE-200307160330/Zend/zend.c:886
#5  0x08106305 in php_execute_script (primary_file=0xb980,
tsrm_ls=0x81876b0) at
/root/php/php4-STABLE-200307160330/main/main.c:1685
#6  0x08142609 in main (argc=2, argv=0xba14)
at /root/php/php4-STABLE-200307160330/sapi/cgi/cgi_main.c:1542
#7  0x40a195cd in __libc_start_main () from /lib/libc.so.6



[2003-07-16 14:31:31] [EMAIL PROTECTED]

Can you try and reduce your script to smallest possible that causes the
crash? (like with only the ldap stuff?)




[2002-09-26 20:22:44] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

Reduce your configure options to bare minimum,
only use --with-apxs, --with-oci8 and --with-ldap and
don't compile them as shared!

Do this using the latest snapshot above.




[2002-09-16 07:13:50] [EMAIL PROTECTED]

Oracle has it's own ldap stuff. You can't compile both openldap and
oracle together. But you don't need to:

--with-ldap=/home/oracle/Oracle-9.0.1

works too.




[2002-09-16 06:49:24] ronan dot salmon at staff dot ittralee dot ie

php-4.2.3
apache-1.3.23-14
redhat 7.3
kernel 2.4.18-10 i686
oracle 9.0.1
openldap 2.0.23

Configure command :
 './configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib'
'--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--prefix=/usr'
'--with-config-file-path=/etc' '--enable-force-cgi-redirect'
'--disable-debug' '--enable-pic' '--disable-rpath'
'--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl'
'--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr'
'--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf'
'--with-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp'
'--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png'
'--with-pspell' '--with-regex=system' '--with-xml'
'--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU'
'--enable-bcmath' '--enable-debugger' '--enable-exif' '--enable-ftp'
'--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets'
'--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path'
'--enable-track-vars' '--enable-trans-sid' '--enable-yp'
'--enable-wddx' '--without-oci8' '--with-imap=shared' '--with-imap-ssl'
'--with-kerberos=/usr/kerberos' '--with-ldap=shared'
'--with-mysql=shared,/usr'
'--with-oci8=shared,/home/oracle/Oracle-9.0.1' '--enable-sigchild'
'--with-pgsql=shared' '--with-snmp=shared,/usr' '--with-snmp=shared'
'--enable-ucd-snmp-hack' '--with-unixODBC=shared'
'--enable-memory-limit' '--enable-bcmath' '--enable-shmop'
'--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio'
'--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans'
'--with-apxs=/usr/sbin/apxs'

If I use l

#17908 [Asn->Fbk]: Can't retrieve info using OCIColumnIsNULL()

2003-10-14 Thread sniper
 ID:   17908
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ThorpeJ at gao dot gov
-Status:   Assigned
+Status:   Feedback
 Bug Type: OCI8 related
 Operating System: Linux 7.1
 PHP Version:  4.0CVS-2002-06-21
 Assigned To:  maxim
 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




Previous Comments:


[2002-10-20 15:33:55] [EMAIL PROTECTED]

true,

actually, what i noticed is that if you do a fetch *before* calling
OCIColumnIsNULL() you then get the right results.

/**/
$conn = OCILogon($user, $pwd, $db);
$stmt = OCIParse($conn, "select * from $table");
OCIExecute($stmt);
$nrows = OCIFetchStatement($stmt, $res);  // adding this
$ncols = OCINumCols($stmt);
for ( $i = 1; $i <= $ncols; $i++ ) {
  echo "NAME: " . OCIColumnName($stmt,$i) . "";
  echo "TYPE: " . OCIColumnType($stmt,$i) . "";
  echo "SIZE: " . OCIColumnSize($stmt,$i) . "";
  echo "ISNULL: " . OCIColumnIsNULL($stmt,$i) . ""; //Function does
not return any information
}
/**/

Will go to fix that.



[2002-06-21 14:20:29] ThorpeJ at gao dot gov

I've tried using OCIColumnIsNULL() to retrieve info on which fields
were NULL/NOT NULL in an Oracle database table, and the function did
not return anything (using OCIColumnName, OCIColumnType, and
OCIColumnSize in the same program worked fine). The script below is a
simple example:

/**/
$conn = OCILogon($user, $pwd, $db);
$stmt = OCIParse($conn, "select * from $table");
OCIExecute($stmt);
$ncols = OCINumCols($stmt);
for ( $i = 1; $i <= $ncols; $i++ ) {
  echo "NAME: " . OCIColumnName($stmt,$i) . "";
  echo "TYPE: " . OCIColumnType($stmt,$i) . "";
  echo "SIZE: " . OCIColumnSize($stmt,$i) . "";
  echo "ISNULL: " . OCIColumnIsNULL($stmt,$i) . ""; //Function does
not return any information
}
/**/




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


#17381 [Asn->Bgs]: OCI fetch routines not working with UTF8 DB

2003-10-14 Thread sniper
 ID:   17381
 Updated by:   [EMAIL PROTECTED]
 Reported By:  robert dot earls at lsi dot co dot uk
-Status:   Assigned
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: Win NT
 PHP Version:  4.2.1
 Assigned To:  maxim
 New Comment:

Too old version (we're at 4.3.3 now) and also, the environment
variables HAVE to be set in the shell, NOT in the script.
They won't work otherwise.



Previous Comments:


[2002-05-23 06:50:05] robert dot earls at lis dot co dot uk

Can I just point out that I have used putenv, to set NLS_LANG in the
example, because I thought that the system-wide environment variable
$NLS_LANG was not being picked up.  It is currently set to
"American_America.UTF8".



[2002-05-23 05:32:37] robert dot earls at lsi dot co dot uk

I seem to be unable to return un-corrupted data from a UTF8 Oracle
database.

Consider this example:-  (appologies for debugging)

";
print $mycolumndump;
print "";
print mb_detect_encoding($mycolumn, "auto");
print "";
print mb_internal_encoding();
print "";
print_r( mb_get_info("all"));

}
?>

e.g.
If mycolumn contains a single UTF8 character E594B4 (three bytes)

I get the result:-

found:bf {upsidedown question mark} len=1

Typ=1 Len=3 228,148,180
EUC-JP
UTF-8

-

I would have expected to see:

found:e594b4 {a japanese glyph} len=3

I suppose the question is, does the OCI interface work correctly with
multi-byte strings?




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


#17897 [Com]: POST form variables are empty

2003-10-14 Thread will at muppetmasters dot com
 ID:   17897
 Comment by:   will at muppetmasters dot com
 Reported By:  hofmann at isl dot org
 Status:   Bogus
 Bug Type: Apache2 related
 Operating System: Linux
 PHP Version:  4.2.1
 New Comment:

air01 seems to be correct.

the $_POST built-in variable / superglobal / whatever you want to call
it doesn't work properly with register_globals set to 'off', which is
ironic since it is recommended for good practice that you turn it off.

advice is to leave it on until they fix this problemvery
irritating! :-)


Previous Comments:


[2003-06-16 15:23:50] sbeam at syxyz dot net

to "air01 at gmx dot de" you will notice if you read the original bug
report it is about $_POST and therefore has nothing to do with
register_globals.

confirmed that BorisATCrazySnowBoarder.com's solution of adding
AddType application/x-httpd-php .php
to the httpd.conf file works. This is on a RedHat 9 system (with the
stock Apache 2.0.40 rpm and PHP4.2.2), which does not come with that
directive by default.



[2003-02-04 05:59:50] dave at nicedayin dot co dot uk

just to say thanks, this thread has just solved a problem with an ASP
based system I am writing. Dreamweaver MX places form actions in as
script sources by default, and so does not always put full url in the
action field. As such all my post variables dissapeared, then I found
this form, hard coded the action page and it worked !



[2003-01-03 07:40:16] air01 at gmx dot de

Following extraction helped me to solve the problem that, variables are
missing in the *.php after submition.


>>Hi there... The problem is actually that in PHP 4.2, Register Globals
is automatically defaulted to OFF. This means that variables that were
normally in the global space such as GET and POST variables are no
longer in the global space by default.

PHP Announcement: http://www.php.net/release_4_2_0.php


You can still force the old default behavior by changing the php.ini
file and set the value for register_globals to "On". This will allow
you to access the variables as they are named in the forms

Documentation:
http://www.php.net/manual/en/configuration.php#ini.register-globals

<<

By the way, I found this Information on expert-exchange.com
http://www.experts-exchange.com/Web/Web_Languages/PHP/Q_20293768.html


My configuration:

PHP 4.2.3
Apache 2.0.43
Windows 2k



[2002-12-13 21:25:05] donny at net-yan dot com

I think the problem is PHP4.  Because I installed PHP on both Apache
and IIS of W2k.  I got the same problem.  The following are the test
program (test.php).  


  
TEST  
  
  


  
  
  

  


I always get empty Arrays.  I never imagine that such simple function
have bugs in PHP, or I know to little about the PHP settings!

Who can HELP!!!  My system cannot progress!!!



[2002-11-18 03:03:47] hofmann at isl dot org

ok the solution to my problem is simple - I am using
AddOutputFilter PHP;INCLUDES .php

so the post variables are missing - thats because you need also to set

AddInputFilter PHP .php

otherwise Apache2 will not forward the POST vars!



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

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


#25863 [Opn->Fbk]: The specified CGI application misbehaved ...

2003-10-14 Thread sniper
 ID:   25863
 Updated by:   [EMAIL PROTECTED]
 Reported By:  salmanarshad2000 at yahoo dot com
-Status:   Open
+Status:   Feedback
 Bug Type: IIS related
 Operating System: Windows XP, 2000
 PHP Version:  4.3.3
 New Comment:

Please provide short test case (all settings, script(s) whatever else
is needed to reproduce this) so we can reproduce this ourselves.



Previous Comments:


[2003-10-14 08:44:21] salmanarshad2000 at yahoo dot com

Description:

This bug or issue has been around for quite a while and seems like
nobody cares. The bug list is filled with hundreds of complains about
the "The specified CGI application misbehaved ..." error each time
these people have BOGUSed or CLOSEd saying things like "The version you
are using is too old, please try the latest version ...", "This is not
a php bug, please go to ...", "Not enough evidence ..." or "Problem
with Windows, not PHP". Quite a few versions of php have been released
in the meanwhile, but this issue hasn't been fixed, people who upgrade
their php installation come back with the same complains. I see no good
reason for this ignorance.

Problem Statement
-
When browsing a php application, the IIS server randomly throws the
error message:

CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers. The headers it did return are:


Observations

This happened only when:
- PHP.exe is used as a CGI on IIS 
- The php scripts contained 2 or more frames (e.g. phpMyAdmin)
- MySQL operation was executed (update, insert, delete etc.)
- header("Location: ...") is used to redirect user after a MySQL
operation to a page that also performs a MySQL operation
- The pages are viewed from local computer
- A very fast computer is used

This did not happened when:
- Apache server for windows with php support was used
- The php scripts contained 2 or more frames but all frames contained
php scripts with Hello World and a random number
- Frequency of errors was much lesser when same pages were accessed
from the network
- Pentium 2, 300 MHz was used (a slow computer)

History
---
Following bugs are all related to this problem. This is just a reminder
for the fact that this issue has been discussed quite a few times and
it is still present. People also found these interesting things that
might help to get the problem solved.

- BugID #25567 getting errors when doing a mysql_db_query() and then
header("location")
- BugID #24916 header("location")
- BugID #23208 using two or more frames
- BugID #19381 no details :(
- BugID #19676 works on one (slow) system but does not work on other
- BugID #18901 header("location") after delete or update, error occurs
under under load
- BugID #16313 header("location") and db operations
- BugID #23050 mysql_query() followed by header("location")
- BugID #17468 header("location")
- BugID #9852  thousands of lines describing the problem, including
frames, manually slowing down the script, pages work from outside the
machine nut not locally, two database connections in rapid succession
etc

Things that have been said earlier
--
"This is a problem with Microsoft OS"
No this is not, it works on exact same OS running on slower hardware or
when the application is accessed across a network. And even if it is,
the developers should try to find a work around instead of blaming M$
and telling it to fix it. After all, when you develop some app for an
environment, you don't change the environment to suit your app
(although sometimes it is easier to do so).

"This is not a php bug"
Well this could be right, since there is one other suspect, MySQL. But
somebody please figure out where the problem is? Also, MySQL is now an
integral part of php so problem could lie in the integration part.

My Opinion
---
May be php.exe is not fast enough to keep up with the pace at which IIS
can throw requests at it. Or ... may be it is a problem with the MySQL
connections ... attempting to create connections too quickly may be the
cause. Users having same problem please feel free to contribute with
their observations and suggestions.






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


#23220 [Fbk->NoF]: fgets() causes warning while reading data via SSL channel (HTTPS)

2003-10-14 Thread sniper
 ID:   23220
 Updated by:   [EMAIL PROTECTED]
 Reported By:  storozhilov at mail dot ru
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Filesystem function related
 Operating System: FreeBSD 4.8
 PHP Version:  4-STABLE-200307070330
 Assigned To:  wez
 New Comment:

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.




Previous Comments:


[2003-10-08 07:30:39] [EMAIL PROTECTED]

Could you try the next stable snapshot (due in a few minutes)?

I comitted a fix for a different bug that might make a
difference to this one.

If it hasn't fixed it, could you post an https:// URL
that reproduces the problem, so that I can investigate
further?




[2003-09-24 11:36:55] chris dot edwards at obinet dot com

Getting the exact same error.  Same OS, same version of PHP.

Changing the length of the string offered no changes.  I still get:

 SSL: fatal protocol error 

I'm getting this for fread() and fgets().



[2003-08-21 20:25:22] info at splendense dot nl

Using '$buff = fgets ($f, 355);' does not give any error, however 356
does for me (php 4.3.2 solaris).

My script seems to work fine but maybe a response string greater than
355 chars will not work?!?



[2003-08-21 20:18:33] scottm at spamcop dot net

I've not verified this patch will work and I'll hopefully test it
tomorrow.

I believe it is reaching the end of the file and nr_bytes is returning
0 and this is being caught by an if statement which should be looking
for -1.

--- network.c   Thu Aug 21 21:06:43 2003
+++ network.c.patched   Thu Aug 21 21:13:09 2003
@@ -1011,13 +1011,14 @@
do {
nr_bytes = SSL_read(sock->ssl_handle, buf,
count);
 
-   if (nr_bytes <= 0) {
+   if (nr_bytes < 0) {
retry = handle_ssl_error(stream,
nr_bytes TSRMLS_CC);
if (retry == 0 &&
!SSL_pending(sock->ssl_handle)) {
stream->eof = 1;
}
} else {
-   /* we got the data */
+   /* we got the data */
+   stream->eof = 1;
break;
}
} while (retry);



[2003-08-05 09:43:36] uk at access dot lv

php4.3.2 configured with-openssl

if ($f = fopen('https://site', 'r')) {
while (!feof($f)) {
$buff = fgets ($f, 1024);
echo $buff;
}
}
fclose ($f);

Warning: fgets(): SSL: fatal protocol error

if i read just some bits then no error.



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

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


#25798 [Fbk->NoF]: forever-running or no-error-abort in preg_match

2003-10-14 Thread sniper
 ID:   25798
 Updated by:   [EMAIL PROTECTED]
 Reported By:  musha dot yoshinori at nifty dot ne dot jp
-Status:   Feedback
+Status:   No Feedback
 Bug Type: PCRE related
 Operating System: Windows XP Pro
 PHP Version:  4.3.3
 New Comment:

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.




Previous Comments:


[2003-10-10 11:50:21] [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





[2003-10-09 00:09:43] musha dot yoshinori at nifty dot ne dot jp

I know that it depends on platforms. I use PHP on Windows XP Pro,
Apache2.0.46 and PHP4.3.3. It also appears on PHP4.3.3RC1. A preg_match
with the same regular expression works fine on other platform. 
Thank you.



[2003-10-08 22:36:43] [EMAIL PROTECTED]

Works fine here on Linux, what locale are you using?



[2003-10-08 14:04:09] musha dot yoshinori at nifty dot ne dot jp

Description:

PHP aborts without any message or runs forever in below case.
Platform: Windows XP Pro, Apache2.0.46, PHP4.3.3

For example, in preg_match('/a(?:.)+z/',$str,$match), the length of
string matched between 'a' and 'z' is more than approximately 1KB. It
always appears. According to the length, PHP aborts without any message
or runs forever.

It also appears in preg_match('/a(?>.)+z/',$str,$match), but does not
appear in preg_match('/a(.)+z/',$str,$match) and
preg_match('/a.+z/',$str,$match).

Actually, I want to use
preg_match_all('/]*>((?>.(?!<\/tr>))+.)<\/tr>/is',$str,$matches)
and so on.

Reproduce code:
---
$str =<

#25825 [Asn->Csd]: Windows PHP always returns UTC time and BST as the timezone

2003-10-14 Thread wez
 ID:   25825
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pennington at rhodes dot edu
-Status:   Assigned
+Status:   Closed
 Bug Type: Date/time related
 Operating System: Windows 2000
 PHP Version:  4.3.3
 Assigned To:  wez
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

The problem was that putenv("TZ=...") would call tzset() in order to
update the libc with the timezone information for the time related
functions, but PHP would not call tzset() again when the environment
was reset.

I've checked in a fix for this problem, which should hopefully make
things better.

However, a word of warning:
The environmental variables are process-wide, so changing
them in a threaded environment like ISAPI may cause some
gotchas in high-concurrency scenarios (eg: two threads
might be playing with the same env var at the same time).

I'm marking this report as closed as the next snapshots
will contain the fix.  If the problem is still present
in those, please reopen this report.



Previous Comments:


[2003-10-14 18:37:33] [EMAIL PROTECTED]

Yes; that is what is happening.
I'll look into having PHP reset to the system default locale at the
start of each request.



[2003-10-14 14:22:09] pennington at rhodes dot edu

Ahh, the TikiWiki PHP application (in /lib/date/TimeZone.php) that we
are running does use putenv() in the following function:



/**
 * Is the given date/time in DST for this time zone
 *
 * Attempts to determine if a given Date object represents a
date/time
 * that is in DST for this time zone.  WARNINGS: this basically
attempts to
 * "trick" the system into telling us if we're in DST for a given
time zone.
 * This uses putenv() which may not work in safe mode, and relies
on unix time
 * which is only valid for dates from 1970 to ~2038.  This relies
on the
 * underlying OS calls, so it may not work on Windows or on a
system where
 * zoneinfo is not installed or configured properly.
 *
 * @access public
 * @param object Date $date the date/time to test
 * @return boolean true if this date is in DST for this time zone
 */
function inDaylightTime($date)
{
$env_tz = "";
if(getenv("TZ")) {
$env_tz = getenv("TZ");
}
putenv("TZ=".$this->id);
$ltime = localtime($date->getTime(), true);
putenv("TZ=".$env_tz);
return $ltime['tm_isdst'];
}

---

Are you saying that this could change the environment variable for
timezone for the entire server for good (at least until IIS5 is
restarted) once this code is executed? And this would affect pages that
don't even include the function above?



[2003-10-14 12:15:49] [EMAIL PROTECTED]

The only other way to manipulate locale is via putenv(), which would
change LC_* environment variable.



[2003-10-14 10:29:48] pennington at rhodes dot edu

I searched through all of the PHP code in use on this machine for the
setlocale() function and only found two entries, both of which were
commented out.

The only ISAPI filter we are using is PHP, and there is no ASP or other
code on that machine. In other words, we are only using it to serve PHP
pages, and none of those scripts use setlocale().

Would it be wise to unload the ASP stuff from the app mappings in IIS5
if we aren't using it so we can test to rule out ASP as the problem?

Are there any other PHP functions (other than setlocale) that
manipulate the locale?



[2003-10-13 18:41:27] [EMAIL PROTECTED]

Do any of your scripts use setlocale() or other similar function to
manipulate the locale?

My gut feeling is that something is (and it might be ASP or some other
ISAPI you have there), and that it isn't being reset back to the system
default.



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

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


#25428 [Opn->Csd]: xmlrpc_server_call_method() causes segfault

2003-10-14 Thread gschlossnagle
 ID:   25428
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mfladischer at gmx dot net
-Status:   Open
+Status:   Closed
 Bug Type: XMLRPC-EPI related
 Operating System: RedHat 9
 PHP Version:  5CVS-2003-09-08 (dev)
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

Patch applied.


Previous Comments:


[2003-10-14 20:09:57] web-php-bugs at sklar dot com

This diff against v1.35 of ext/xmlrpc/xmlrpc-epi.php.c fixes the
problem.

diff -r1.35 xmlrpc-epi-php.c
1033c1033,1037
<   set_output_options(&out, *output_opts);
---
>   if (argc == 3) {
> set_output_options(&out, NULL);
> } else {
> set_output_options(&out, *output_opts);
> }



[2003-09-08 03:38:40] mfladischer at gmx dot net

Description:

When i'm trying to run a XML-RPC server  (using the xml-rpc-extension)
with PHP5 i get a segfault.

Reproduce code:
---


Expected result:




 
  
   

 
  system.listMethods
 
 
  system.methodHelp
 
 
  system.methodSignature
 
 
  system.describeMethods
 
 
  system.multiCall
 
 
  system.getCapabilities
 

   
  
 



Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 19945)]
0x0822d92f in zif_xmlrpc_server_call_method (ht=3,
return_value=0x408ef0ac, this_ptr=0x0, return_value_used=1)
at /linux/devel/php5/ext/xmlrpc/xmlrpc-epi-php.c:1033
1033set_output_options(&out, *output_opts);
(gdb) bt
#0  0x0822d92f in zif_xmlrpc_server_call_method (ht=3,
return_value=0x408ef0ac, this_ptr=0x0, return_value_used=1)
at /linux/devel/php5/ext/xmlrpc/xmlrpc-epi-php.c:1033
#1  0x082a2583 in zend_do_fcall_common_helper (execute_data=0xbfffd180,
op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:2541
#2  0x082a2d25 in zend_do_fcall_handler (execute_data=0xbfffd180,
op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:2687
#3  0x0829e834 in execute (op_array=0x408ee410) at
/linux/devel/php5/Zend/zend_execute.c:1267
#4  0x0827f0f7 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /linux/devel/php5/Zend/zend.c:1018
#5  0x0823f15c in php_execute_script (primary_file=0xb580) at
/linux/devel/php5/main/main.c:1625
#6  0x082acea7 in main (argc=2, argv=0xb614) at
/linux/devel/php5/sapi/cli/php_cli.c:910
#7  0x40767bf7 in __libc_start_main () from /lib/i686/libc.so.6






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


#25867 [Bgs]: Sleep() no more work corectly on 4.3.3

2003-10-14 Thread sniper
 ID:   25867
 Updated by:   [EMAIL PROTECTED]
 Reported By:  plc2k at altern dot org
 Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: windows
 PHP Version:  4.3.3
 New Comment:

Your script works just like it should work. No bug here.



Previous Comments:


[2003-10-14 13:40:22] plc2k at altern dot org

have you tested my example at least ?
as i said it work on older version and not on the new one, so for me
it's bug i see nothing on http://fr.php.net/sleep to let me know i'm
wrong in my code...
i posted a ot of messages in lot of forums, nobody know why it don't
work ...



[2003-10-14 13:31:54] plc2k at altens dot org

this is not a bug ? so why it work in older version ? 
i spend many time and used many forums, nobody know ..
so i 'm ok to read again the doc .. but ...
why it work in older version ...



[2003-10-14 12:33:25] [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

..




[2003-10-14 12:29:08] plc2k at altern dot org

Description:

i used a sleep() function in my php page, and after an upgrade of php,
this one no more work.
so it work on older version of php like 4.2.0 but not on last one, like
4.3.3

Reproduce code:
---
. ";
sleep(2);
}
?>

Expected result:

test . . . . . . . . . .

(here the "." are add one by one every 2 seconds)

Actual result:
--
test. . . . . . . . . . . . . 
Fatal error: Maximum execution time of 30 seconds exceeded in
c:\uptest2.php on line 8

(here, all the points appear at the timeout)





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


#25428 [Com]: xmlrpc_server_call_method() causes segfault

2003-10-14 Thread web-php-bugs at sklar dot com
 ID:   25428
 Comment by:   web-php-bugs at sklar dot com
 Reported By:  mfladischer at gmx dot net
 Status:   Open
 Bug Type: XMLRPC-EPI related
 Operating System: RedHat 9
 PHP Version:  5CVS-2003-09-08 (dev)
 New Comment:

This diff against v1.35 of ext/xmlrpc/xmlrpc-epi.php.c fixes the
problem.

diff -r1.35 xmlrpc-epi-php.c
1033c1033,1037
<   set_output_options(&out, *output_opts);
---
>   if (argc == 3) {
> set_output_options(&out, NULL);
> } else {
> set_output_options(&out, *output_opts);
> }


Previous Comments:


[2003-09-08 03:38:40] mfladischer at gmx dot net

Description:

When i'm trying to run a XML-RPC server  (using the xml-rpc-extension)
with PHP5 i get a segfault.

Reproduce code:
---


Expected result:




 
  
   

 
  system.listMethods
 
 
  system.methodHelp
 
 
  system.methodSignature
 
 
  system.describeMethods
 
 
  system.multiCall
 
 
  system.getCapabilities
 

   
  
 



Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 19945)]
0x0822d92f in zif_xmlrpc_server_call_method (ht=3,
return_value=0x408ef0ac, this_ptr=0x0, return_value_used=1)
at /linux/devel/php5/ext/xmlrpc/xmlrpc-epi-php.c:1033
1033set_output_options(&out, *output_opts);
(gdb) bt
#0  0x0822d92f in zif_xmlrpc_server_call_method (ht=3,
return_value=0x408ef0ac, this_ptr=0x0, return_value_used=1)
at /linux/devel/php5/ext/xmlrpc/xmlrpc-epi-php.c:1033
#1  0x082a2583 in zend_do_fcall_common_helper (execute_data=0xbfffd180,
op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:2541
#2  0x082a2d25 in zend_do_fcall_handler (execute_data=0xbfffd180,
op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:2687
#3  0x0829e834 in execute (op_array=0x408ee410) at
/linux/devel/php5/Zend/zend_execute.c:1267
#4  0x0827f0f7 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /linux/devel/php5/Zend/zend.c:1018
#5  0x0823f15c in php_execute_script (primary_file=0xb580) at
/linux/devel/php5/main/main.c:1625
#6  0x082acea7 in main (argc=2, argv=0xb614) at
/linux/devel/php5/sapi/cli/php_cli.c:910
#7  0x40767bf7 in __libc_start_main () from /lib/i686/libc.so.6






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


#25870 [Opn->Bgs]: Session variables do NOT work as expected

2003-10-14 Thread sniper
 ID:   25870
 Updated by:   [EMAIL PROTECTED]
 Reported By:  memoimyself at yahoo dot com dot br
-Status:   Open
+Status:   Bogus
 Bug Type: Session related
 Operating System: Windows 2000 SP 4
 PHP Version:  4.3.3
 New Comment:

Works fine for me under Windows. (using Apache 2.0.47 and a working
script). Please don't reopen this, there is no bug here.



Previous Comments:


[2003-10-14 18:25:02] memoimyself at yahoo dot com dot br

First of all, thanks a lot for taking time to reply to my post so
quickly.

Now, while I have not taken any offence whatsoever and can only imagine
how busy you must be, I am *not* a newby and have *always* called
start.php before test.php. The session variable ($_SESSION['test'])
simply will *not* be registered unless I *reload* start.php (i.e. load
it twice). On the start.php page I have included a
link to test.php, so that the second page is only called after the
first, i.e. the session variable was *supposed* to have been
initialized.

Perhaps this is a bug only affecting PHP under Windows?



[2003-10-14 17:57:17] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

Works fine, if start.php which intializes the session variable is
always started before test.php, which uses it.



[2003-10-14 14:51:12] memoimyself at yahoo dot com dot br

Actually, I've found out that using session_register() won't help at
all. What does work is if I reload the page where the session variable
is set (start.php) and then open the page where the session variable is
used (test.php). For obvious reasons, this is not a very convenient
solution in a production environment. :-)



[2003-10-14 14:27:17] memoimyself at yahoo dot com dot br

Using Apache 2.0.46 and PHP as an Apache module (as opposed to CGI).



[2003-10-14 14:03:48] memoimyself at yahoo dot com dot br

Description:

I read in the manual that the use of session_register() is deprecated
and that session variables should now be registered simply by creating,
and assigning a value to, a member of the $_SESSION array.

Well, try as I may, I just cannot register session variables without
using session_register(). If, however, I use session_register() before
assigning a value to the new session variable via $_SESSION['x'],
everything works fine.

Reproduce code:
---
// PAGE A (start.php):



/***/

// PAGE B (test.php, called after start.php, obviously):



Expected result:

OUTPUT TO SCREEN:

my test

Actual result:
--
OUTPUT TO SCREEN:

Notice: Undefined index: test in D:\htdocs\Test\session\test.php on
line 3






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


#21532 [Opn->Fbk]: incorrect warning

2003-10-14 Thread sniper
 ID:   21532
 Updated by:   [EMAIL PROTECTED]
 Reported By:  czuma at poland dot org
-Status:   Open
+Status:   Feedback
 Bug Type: *Directory/Filesystem functions
 Operating System: Solaris 8
 PHP Version:  4.3.2
 Assigned To:  wez
 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




Previous Comments:


[2003-10-14 14:09:19] czuma at poland dot org

The same problem in PHP 4.3.3.



[2003-08-01 06:10:27] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2003-07-27 13:52:02] [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





[2003-03-22 14:20:35] czuma at poland dot org

I have checked php4-STABLE-200303221630 (PHP/4.3.2-RC)

Unfortunately, it doesn't work. I still see incorrect warning.



[2003-03-01 12:07:47] czuma at poland dot org

I have checked php4-STABLE-200303011230

Unfortunately it doesn't work. I still see incorrect warning:

"SAFE MODE Restriction in effect. The script whose uid is XXX is not
allowed to access /www/user/data owned by uid 0 in
/www/user/stale/table1a.php on line 3"

"Line 3": 
$my=opendir("/www/user/data/$dat");

Probably: $dat=blabla/bleble.txt

Directory "blabla" doesn't exist. I see correct and then incorrect
warning.



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

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


#25827 [Opn->Bgs]: PHP LDAP queries against Active Directory return incomplete arrays

2003-10-14 Thread sniper
 ID:   25827
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pennington at rhodes dot edu
-Status:   Open
+Status:   Bogus
 Bug Type: LDAP related
 Operating System: Windows 2000
 PHP Version:  4.3.3
 New Comment:

We only wrap around the OpenLDAP libraries. So it's definately  not PHP
bug -> bogus.

You should report this to the openldap folks, they propably already
know about it or are very willing to fix it if it's not already fixed.
Please let us know what the response is so we can possibly update the
used openldap libraries in the win32 binaries build.



Previous Comments:


[2003-10-14 14:08:51] pennington at rhodes dot edu

OK, you're right, after a few minutes, I found an ldapsearch command
that would work:

ldapsearch -x -b "CN=_some_user_,CN=Users,DC=rhodes,DC=edu" -D
"CN=_search_auth_user_,CN=Users,DC=rhodes,DC=edu" -H
ldap://someserver.rhodes.edu -W

The "memberof" attribute results look like this:

memberOf: CN=STAFF_DL,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=Planning,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=FACSTAFF,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=Council,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=PRESIDENT,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=FACTBOOK,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=INFO_SERVICES,OU=Security
Groups,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=CABINET,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=Senior2006,OU=Distribution
Lists,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=NT Users,CN=Users,DC=rhodes,DC=edu
memberOf: CN=NTSETUP,CN=Users,DC=rhodes,DC=edu
memberOf: CN=Domain Users,CN=Users,DC=rhodes,DC=edu

Again, only 12 results were returned rather than the 13 that exist
there in Active Directory.

However, I've started doing a count based on attributes found by
ldapsearch and Softerra's LDAPBrowser (which I think also uses
openldap) and found that people missing an attibute value in ldapsearch
were missing the same value in LDAPBrowser.

Anyway, I think what we are down to is one of two possibilities:

1) OpenLDAP's search tool is not receiving all attribute values for a
particular search; or

2) Active Directory is not supplying the missing value when queried for
it using LDAP but does reply properly when Microsoft admin tools are
used.

I guess we could solve this if someone knows a good, freely-available,
non-openldap-based LDAP search utility.

Regardless, this doesn't look like a PHP bug per se, thought it could
be a OpenLDAP bug that has found its way into PHP with the rest of the
OpenLDAP code...



[2003-10-14 12:26:58] [EMAIL PROTECTED]

There is no kerberos support in PHP ldap either, and that partially
works, so why would you need it with the command line binary?




[2003-10-14 11:59:27] pennington at rhodes dot edu

It appears that ldapsearch at that URL is not compiled with Kerberos
support, which may be required to search Active Directory LDAP servers.
I'm still doing research, however...

D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D
pennington -k
ldapsearch: not compiled with Kerberos support

I tried it with just SASL and that wasn't appreciated either:

D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D
pennington -I
ldap_sasl_interactive_bind_s: Unknown authentication method (86)
additional info: SASL(-4): no mechanism available: Unable to
find a call
back: 2

Can anyone verify that Kerberos support is required to search Active
Directory LDAP servers? Is anyone using the OpenLDAP ldapsearch program
to search Active Directory LDAP servers? If so, what kind of command
should I use to get ldapsearch to search Active Directory?

I am using "CN=Users,DC=rhodes,DC=edu" for the Base DN,
"CN=_search_value_" for the name to search for, and to bind to the
Active Directory LDAP server, you have to use this string as the
username: "CN=_authorized_user_,CN=Users,DC=rhodes,DC=edu"



[2003-10-14 11:12:30] [EMAIL PROTECTED]

PHP uses OpenLDAP libraries for ldap functionality in the windows
binaries. So try your query with the openldap 'ldapsearch.exe' found in
this package:

http://prdownloads.sf.net/acctsync/openldap-binaries-2.1.16-04APR03.zip





[2003-10-13 12:05:40] pennington at rhodes dot edu

I obviously can't provide general access for testing to our Active
Directory server, because you need an account on the Active Directory
server to even search the directory, as with most LDAP servers.

I find it strange that no one has seen this before, because Microsoft's
Active Di

#25871 [Opn->Bgs]: imagecreatetruecolor uses memory excessively

2003-10-14 Thread sniper
 ID:   25871
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bb at ii dot nl
-Status:   Open
+Status:   Bogus
-Bug Type: Performance problem
+Bug Type: GD related
 Operating System: RedHat Linux
 PHP Version:  4.3.3
 New Comment:

That's GD problem, not PHP. Report it to the GD author.



Previous Comments:


[2003-10-14 19:41:34] bb at ii dot nl

I have read the documentation, but I could not find any reference to a
maximum image size supported. The problem does indeed seem to be memory
running out. When I increased the memory available to PHP to 50mb, the
large images no longer terminated the script.

I've changed the bug report to a 'performance problem', as I believe
imagecreatetruecolor is somewhat wasteful with resources. The script
terminates with a 1310x4000 image, about 5.3mpix in size, with a 25mb
memory limit. Apparently imagecreatetruecolor takes almost twice the
memory it should.

Sorry about not investigating the memory thing sooner, before
submitting. I should've thought of that myself.



[2003-10-14 17:33:27] [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

PHP crashes (probably just exists) due to reaching the memory limit and
being unable to allocate additional memory.



[2003-10-14 15:27:54] bb at ii dot nl

Description:

ImageCreateTrueColor crashes PHP if I allocate an image over ~400
pixels in size.

I use PHP 4.3.3 with GD version: bundled (2.0.15 compatible)

Memory_limit is set to 26214400

Reproduce code:
---
$im = imagecreatetruecolor(1500,4000);


Actual result:
--
PHP crashes





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


#25871 [Bgs->Opn]: imagecreatetruecolor uses memory excessively

2003-10-14 Thread bb at ii dot nl
 ID:   25871
 User updated by:  bb at ii dot nl
-Summary:  imagecreatetruecolor crashes if image over 4mpix
 Reported By:  bb at ii dot nl
-Status:   Bogus
+Status:   Open
-Bug Type: Reproducible crash
+Bug Type: Performance problem
 Operating System: RedHat Linux
 PHP Version:  4.3.3
 New Comment:

I have read the documentation, but I could not find any reference to a
maximum image size supported. The problem does indeed seem to be memory
running out. When I increased the memory available to PHP to 50mb, the
large images no longer terminated the script.

I've changed the bug report to a 'performance problem', as I believe
imagecreatetruecolor is somewhat wasteful with resources. The script
terminates with a 1310x4000 image, about 5.3mpix in size, with a 25mb
memory limit. Apparently imagecreatetruecolor takes almost twice the
memory it should.

Sorry about not investigating the memory thing sooner, before
submitting. I should've thought of that myself.


Previous Comments:


[2003-10-14 17:33:27] [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

PHP crashes (probably just exists) due to reaching the memory limit and
being unable to allocate additional memory.



[2003-10-14 15:29:27] bb at ii dot nl

OS is RedHat, not Debian



[2003-10-14 15:27:54] bb at ii dot nl

Description:

ImageCreateTrueColor crashes PHP if I allocate an image over ~400
pixels in size.

I use PHP 4.3.3 with GD version: bundled (2.0.15 compatible)

Memory_limit is set to 26214400

Reproduce code:
---
$im = imagecreatetruecolor(1500,4000);


Actual result:
--
PHP crashes





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


#25825 [Opn->Asn]: Windows PHP always returns UTC time and BST as the timezone

2003-10-14 Thread wez
 ID:   25825
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pennington at rhodes dot edu
-Status:   Open
+Status:   Assigned
 Bug Type: Date/time related
 Operating System: Windows 2000
 PHP Version:  4.3.3
 Assigned To:  wez
 New Comment:

Yes; that is what is happening.
I'll look into having PHP reset to the system default locale at the
start of each request.


Previous Comments:


[2003-10-14 14:22:09] pennington at rhodes dot edu

Ahh, the TikiWiki PHP application (in /lib/date/TimeZone.php) that we
are running does use putenv() in the following function:



/**
 * Is the given date/time in DST for this time zone
 *
 * Attempts to determine if a given Date object represents a
date/time
 * that is in DST for this time zone.  WARNINGS: this basically
attempts to
 * "trick" the system into telling us if we're in DST for a given
time zone.
 * This uses putenv() which may not work in safe mode, and relies
on unix time
 * which is only valid for dates from 1970 to ~2038.  This relies
on the
 * underlying OS calls, so it may not work on Windows or on a
system where
 * zoneinfo is not installed or configured properly.
 *
 * @access public
 * @param object Date $date the date/time to test
 * @return boolean true if this date is in DST for this time zone
 */
function inDaylightTime($date)
{
$env_tz = "";
if(getenv("TZ")) {
$env_tz = getenv("TZ");
}
putenv("TZ=".$this->id);
$ltime = localtime($date->getTime(), true);
putenv("TZ=".$env_tz);
return $ltime['tm_isdst'];
}

---

Are you saying that this could change the environment variable for
timezone for the entire server for good (at least until IIS5 is
restarted) once this code is executed? And this would affect pages that
don't even include the function above?



[2003-10-14 12:15:49] [EMAIL PROTECTED]

The only other way to manipulate locale is via putenv(), which would
change LC_* environment variable.



[2003-10-14 10:29:48] pennington at rhodes dot edu

I searched through all of the PHP code in use on this machine for the
setlocale() function and only found two entries, both of which were
commented out.

The only ISAPI filter we are using is PHP, and there is no ASP or other
code on that machine. In other words, we are only using it to serve PHP
pages, and none of those scripts use setlocale().

Would it be wise to unload the ASP stuff from the app mappings in IIS5
if we aren't using it so we can test to rule out ASP as the problem?

Are there any other PHP functions (other than setlocale) that
manipulate the locale?



[2003-10-13 18:41:27] [EMAIL PROTECTED]

Do any of your scripts use setlocale() or other similar function to
manipulate the locale?

My gut feeling is that something is (and it might be ASP or some other
ISAPI you have there), and that it isn't being reset back to the system
default.



[2003-10-13 17:53:32] pennington at rhodes dot edu

Interestingly, when testing to see if this UTC display of time would
happen for PHP installed as a CGI (couldn't reproduce with Apache2 or
IIS5 as a CGI), I noticed that the UTC time problem does not show up
right away with PHP installed as ISAPI on IIS5. Rather, when you stop
the IIS service and then start it again, for a period of time, the
correct time is displayed using echo date("D M j G:i:s T Y");

However, after a period of time passes (say an hour or so on a server
averaging a few users at a time), the time switches to UTC and does not
go back.

If you stop IIS and then start it again, the time goes back to the
correct time and the cycle starts again.

Note that this is using ISAPI on IIS5 on Windows 2000 Server. I been
trying PHP in ISAPI and CGI mode on a Windows 2000 workstation because
I've been having trouble getting the Windows 2000 Server, which uses
PHP ISAPI just fine, to run PHP in CGI mode. It should be as easy as
setting cgi.force_redirect = 0 and changing the app mapping
configuration to point to the php.exe and not the php4isapi.dll but I'm
not having any luck (get "not authorized to view this page" on php
scripts). This method works fine on the Win2K workstation. Anyway, this
is not related to the UTC time issue...



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

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



#25870 [Bgs->Opn]: Session variables do NOT work as expected

2003-10-14 Thread memoimyself at yahoo dot com dot br
 ID:   25870
 User updated by:  memoimyself at yahoo dot com dot br
-Summary:  Session variables do NOT work as expected without
   session_register()
 Reported By:  memoimyself at yahoo dot com dot br
-Status:   Bogus
+Status:   Open
 Bug Type: Session related
 Operating System: Windows 2000 SP 4
 PHP Version:  4.3.3
 New Comment:

First of all, thanks a lot for taking time to reply to my post so
quickly.

Now, while I have not taken any offence whatsoever and can only imagine
how busy you must be, I am *not* a newby and have *always* called
start.php before test.php. The session variable ($_SESSION['test'])
simply will *not* be registered unless I *reload* start.php (i.e. load
it twice). On the start.php page I have included a
link to test.php, so that the second page is only called after the
first, i.e. the session variable was *supposed* to have been
initialized.

Perhaps this is a bug only affecting PHP under Windows?


Previous Comments:


[2003-10-14 17:57:17] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

Works fine, if start.php which intializes the session variable is
always started before test.php, which uses it.



[2003-10-14 14:51:12] memoimyself at yahoo dot com dot br

Actually, I've found out that using session_register() won't help at
all. What does work is if I reload the page where the session variable
is set (start.php) and then open the page where the session variable is
used (test.php). For obvious reasons, this is not a very convenient
solution in a production environment. :-)



[2003-10-14 14:27:17] memoimyself at yahoo dot com dot br

Using Apache 2.0.46 and PHP as an Apache module (as opposed to CGI).



[2003-10-14 14:03:48] memoimyself at yahoo dot com dot br

Description:

I read in the manual that the use of session_register() is deprecated
and that session variables should now be registered simply by creating,
and assigning a value to, a member of the $_SESSION array.

Well, try as I may, I just cannot register session variables without
using session_register(). If, however, I use session_register() before
assigning a value to the new session variable via $_SESSION['x'],
everything works fine.

Reproduce code:
---
// PAGE A (start.php):



/***/

// PAGE B (test.php, called after start.php, obviously):



Expected result:

OUTPUT TO SCREEN:

my test

Actual result:
--
OUTPUT TO SCREEN:

Notice: Undefined index: test in D:\htdocs\Test\session\test.php on
line 3






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


#25870 [Opn->Bgs]: Session variables do NOT work as expected without session_register()

2003-10-14 Thread iliaa
 ID:   25870
 Updated by:   [EMAIL PROTECTED]
 Reported By:  memoimyself at yahoo dot com dot br
-Status:   Open
+Status:   Bogus
 Bug Type: Session related
 Operating System: Windows 2000 SP 4
 PHP Version:  4.3.3
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

Works fine, if start.php which intializes the session variable is
always started before test.php, which uses it.


Previous Comments:


[2003-10-14 14:51:12] memoimyself at yahoo dot com dot br

Actually, I've found out that using session_register() won't help at
all. What does work is if I reload the page where the session variable
is set (start.php) and then open the page where the session variable is
used (test.php). For obvious reasons, this is not a very convenient
solution in a production environment. :-)



[2003-10-14 14:27:17] memoimyself at yahoo dot com dot br

Using Apache 2.0.46 and PHP as an Apache module (as opposed to CGI).



[2003-10-14 14:03:48] memoimyself at yahoo dot com dot br

Description:

I read in the manual that the use of session_register() is deprecated
and that session variables should now be registered simply by creating,
and assigning a value to, a member of the $_SESSION array.

Well, try as I may, I just cannot register session variables without
using session_register(). If, however, I use session_register() before
assigning a value to the new session variable via $_SESSION['x'],
everything works fine.

Reproduce code:
---
// PAGE A (start.php):



/***/

// PAGE B (test.php, called after start.php, obviously):



Expected result:

OUTPUT TO SCREEN:

my test

Actual result:
--
OUTPUT TO SCREEN:

Notice: Undefined index: test in D:\htdocs\Test\session\test.php on
line 3






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


#25868 [Opn->Csd]: error in mail()- function

2003-10-14 Thread iliaa
 ID:   25868
 Updated by:   [EMAIL PROTECTED]
 Reported By:  info at xaran dot de
-Status:   Open
+Status:   Closed
 Bug Type: Mail related
 Operating System: Win XP SP1
 PHP Version:  4.3.3
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2003-10-14 13:19:31] info at xaran dot de

Description:

There is a description of the error available as a PDF- document at
http://www.xaran.de/php.pdf.

Reproduce code:
---
There is a description of the error available as a PDF- document at
http://www.xaran.de/php.pdf.

Expected result:

There is a description of the error available as a PDF- document at
http://www.xaran.de/php.pdf.

Actual result:
--
There is a description of the error available as a PDF- document at
http://www.xaran.de/php.pdf.





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


#25862 [Opn->WFx]: mail() always return FALSE

2003-10-14 Thread iliaa
 ID:   25862
 Updated by:   [EMAIL PROTECTED]
 Reported By:  thouraud at bondy dot ird dot fr
-Status:   Open
+Status:   Wont fix
 Bug Type: Mail related
 Operating System: solaris 9
 PHP Version:  4.3.3
 New Comment:

When PHP is compiled with --enable-sigchild the return codes of
executed programs are lost. Once of those programs is sendmail, since
PHP cannot fetch the return code it assumes the program had failed.
Hence the always FALSE return value of mail(). Normally mail() returns
false only when communication between PHP & sendmail fails.


Previous Comments:


[2003-10-14 13:05:24] thouraud at bondy dot ird dot fr

Without the --enable-sigchild configure option, it seems that mail()
alwayes return TRUE.

Even if the mail server returns an "unknown error" with a false email,
or an "No recipients specified" with a blank first field of mail().

Is that normal ? When mail() returns FALSE ?



[2003-10-14 11:13:37] [EMAIL PROTECTED]

Okay, try removing the --enable-sigchild configure option
and reconfigure/compile PHP. (don't forget to delete config.cache
before reconfiguring!)




[2003-10-14 10:44:48] thouraud at bondy dot ird dot fr

the configure line is :

./configure  --with-apxs=/opt/apache/bin/apxs --prefix=/opt/apache
--with-config-file-path=/opt/apache/conf --with-mysql --disable-debug
--enable-trans-sid --with-oci8=/opt/oracle/product/9201 --enable-dbase
--enable-safe-mode --disable-magic-quotes --enable-sigchild
--enable-ldap --with-zlib=/opt/sfwplus --enable-mbstring
--enable-mbregex --enable-zend-multibyte --enable-bcmath
--enable-calendar --enable-exif --with-jpeg-dir=/opt/sfwplus
--with-png-dir=/opt/sfwplus --with-tiff-dir=/opt/sfwplus --with-gd
--with-iconv --with-pgsql=/opt/postgres



[2003-10-14 10:34:18] [EMAIL PROTECTED]

What was the configure line you used to configure PHP?




[2003-10-14 08:26:31] thouraud at bondy dot ird dot fr

Description:

The mail() function always return FALSE.
Even if the mail is sent !

Test with the sun's sendmail and postfix 2.0.16.
The mail can go out with no problem.

The result get the same safe_mode or not.

apache 1.3.28 with php as a module

Reproduce code:
---
" ;
  if ($ret) {
print 'OK' ;
  } else {
print 'KO' ;
  }

?>


Expected result:

if we can send mail to [EMAIL PROTECTED]
then OK and [EMAIL PROTECTED] receive the mail.


if any error to sent mail 
then KO and no mail !

Actual result:
--
always KO

but the mail are been received !





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


#25873 [Opn->Bgs]: local setting (.htaccess) of upload_max_filesize prevents file uploads to work

2003-10-14 Thread iliaa
 ID:   25873
 Updated by:   [EMAIL PROTECTED]
 Reported By:  arnaud dot mlist1 at free dot fr
-Status:   Open
+Status:   Bogus
 Bug Type: Apache2 related
 Operating System: Linux
 PHP Version:  4.3.2
 New Comment:

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

Apache 2 code has change quite significantly since 4.2.2 and behaviour
in 4.2.2 is not applicable.


Previous Comments:


[2003-10-14 16:21:43] arnaud dot mlist1 at free dot fr

Description:

I think the problem is linked to Apache 2.0 but I am not really sure :
could be the version of PHP (4.2.2) (but I cannot upgrade : it not my
machine...)
Everythink works as expected on Apache 1.3 with PHP 4.3.2.

The problem : when trying to modify local setting of
upload_max_filesize (in local .htaccess), phpinfo() shows the
modification as expected, but file uploads don't work anymore (even
with very small files of one byte). The function is_uploaded_file
($file) returns false in my scripts. Even when I use locally the same
value as in the main php.ini, file uploads fail...
If I delete the line from the .htaccess, then everything works fine.

I also tried to modify locally other PHP settings to see if the problem
was linked to modification of ANY local setting, but file uploads were
not affected.

I know I should try to run PHP 4.2.2 on my Apache 1.3, to see if things
work differently, but I thought I would ask first.

Thanks for anyone digging into this problem

Expected result:

$HTTP_POST_FILES['import_file']['tmp_name'] should not be empty

Actual result:
--
$HTTP_POST_FILES['import_file']['tmp_name'] is empty when local setting
of upload_max_filesize is used





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


#25872 [Opn->Bgs]: Query of MS-Word char causes ISO number to show up instead of actual character

2003-10-14 Thread iliaa
 ID:   25872
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mrtima at aol dot com
-Status:   Open
+Status:   Bogus
 Bug Type: MySQL related
 Operating System: Any
 PHP Version:  4.3.1
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

You are probably inserting the encoded values into MySQL.


Previous Comments:


[2003-10-14 15:58:37] mrtima at aol dot com

Description:

When certain MS-Word characters such as (Â’) are returned from a query
in MySQL and displayed to a webpage, you see ’ instead.

MS-Word parenthesis = Â’
Standard ASCII paranthesis = '

Reproduce code:
---
//database connection params
include("db_conn.php");

//the database should have a MS-Word parenthesis in it (Â’)
$result = mysql_query("SELECT textvalue FROM anytable");
$fetch_result = mysql_fetch_object($result);

//display result to a webpage
echo $fetch_result->textvalue;





Expected result:

Â’

Actual result:
--
’





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


#21938 [Com]: Wrong error line numbers

2003-10-14 Thread chris at antiochwebhost dot com
 ID:   21938
 Comment by:   chris at antiochwebhost dot com
 Reported By:  arne dot brachhold at co4 dot de
 Status:   No Feedback
 Bug Type: Scripting Engine problem
 Operating System: Windows 2000
 PHP Version:  4.3.1-dev
 New Comment:

I too am having this problem...

Example:

Parse error: parse error, unexpected T_STRING, expecting ',' or ';' in
/home/httpd/vhosts/soundthetrumpet.org/httpdocs/Admin_Center/Communicator.php
on line 540

-

There is absolutely no reason that I should be having this problem as
that entire section of the file is non-php.

I'm using v4.3.3 strangely enough, so I'm not sure if this is a version
issue.


Previous Comments:


[2003-04-08 14:39:33] duerra at yahoo dot com

I am having this problem is as well.  It doesn't happen in all my
scripts, but mainly on the larger ones.  The only consistency here is
that it's telling me that the error occures BEFORE it actually does,
whether it's telling me 10 lines or 50 lines, though, isn't
consistent.

Example:  

//line 145
echo "something"

PHP may tell me that I have an error on line 105, or something like
that.

This is very peculiar, but it is also very existent.  Any word yet on
what could be going wrong??



[2003-02-20 08:04:37] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2003-02-13 02:21:22] [EMAIL PROTECTED]

What was the result when testing with CGI binary?
(on command line!)

I can't reproduce this with even over 1000 lines of code..




[2003-02-05 03:45:55] arne dot brachhold at co4 dot de

It shows the correct line on short scripts like yours.
But when I create a script, write 20 times

if(isset($blubb)) {


}

ans then blubb(); which is now on line 88, it tells me the error is on
line 66. As longer the script is as higher is the difference.

Sorry at the moment i don't have the time to test this with the CGI
Binary. But i can do this on weekend.



[2003-02-04 18:19:09] [EMAIL PROTECTED]

Using PHP 4.3.1-dev and running this script:



What line is the error reported on? (using PHP CLI binary)
And what about with PHP CGI binary ?

For me, it says the error is on line 3, which is correct.



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

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


#25871 [Opn->Bgs]: imagecreatetruecolor crashes if image over 4mpix

2003-10-14 Thread iliaa
 ID:   25871
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bb at ii dot nl
-Status:   Open
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: RedHat Linux
 PHP Version:  4.3.3
 New Comment:

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

PHP crashes (probably just exists) due to reaching the memory limit and
being unable to allocate additional memory.


Previous Comments:


[2003-10-14 15:29:27] bb at ii dot nl

OS is RedHat, not Debian



[2003-10-14 15:27:54] bb at ii dot nl

Description:

ImageCreateTrueColor crashes PHP if I allocate an image over ~400
pixels in size.

I use PHP 4.3.3 with GD version: bundled (2.0.15 compatible)

Memory_limit is set to 26214400

Reproduce code:
---
$im = imagecreatetruecolor(1500,4000);


Actual result:
--
PHP crashes





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


#1 [Opn->Fbk]: Test Bugs

2003-10-14 Thread
 ID:   1
 Updated by:   @php.net
 Reported By:  support at championaccess dot net
-Status:   Open
+Status:   Feedback
 Bug Type: *General Issues
 Operating System: windows
 PHP Version:  4.3.2
-Assigned To:  
+Assigned To:  support
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.




Previous Comments:


[2003-10-14 13:23:09] support at championaccess dot net

simple test of the php-web-bugs..




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


#25873 [NEW]: local setting (.htaccess) of upload_max_filesize prevents file uploads to work

2003-10-14 Thread arnaud dot mlist1 at free dot fr
From: arnaud dot mlist1 at free dot fr
Operating system: Linux
PHP version:  4.3.2
PHP Bug Type: Apache2 related
Bug description:  local setting (.htaccess) of upload_max_filesize prevents file 
uploads to work

Description:

I think the problem is linked to Apache 2.0 but I am not really sure :
could be the version of PHP (4.2.2) (but I cannot upgrade : it not my
machine...)
Everythink works as expected on Apache 1.3 with PHP 4.3.2.

The problem : when trying to modify local setting of upload_max_filesize
(in local .htaccess), phpinfo() shows the modification as expected, but
file uploads don't work anymore (even with very small files of one byte).
The function is_uploaded_file ($file) returns false in my scripts. Even
when I use locally the same value as in the main php.ini, file uploads
fail...
If I delete the line from the .htaccess, then everything works fine.

I also tried to modify locally other PHP settings to see if the problem
was linked to modification of ANY local setting, but file uploads were not
affected.

I know I should try to run PHP 4.2.2 on my Apache 1.3, to see if things
work differently, but I thought I would ask first.

Thanks for anyone digging into this problem

Expected result:

$HTTP_POST_FILES['import_file']['tmp_name'] should not be empty

Actual result:
--
$HTTP_POST_FILES['import_file']['tmp_name'] is empty when local setting of
upload_max_filesize is used

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


#25872 [NEW]: Query of MS-Word char causes ISO number to show up instead of actual character

2003-10-14 Thread mrtima at aol dot com
From: mrtima at aol dot com
Operating system: Any
PHP version:  4.3.1
PHP Bug Type: MySQL related
Bug description:  Query of MS-Word char causes ISO number to show up instead of actual 
character

Description:

When certain MS-Word characters such as (Â’) are returned from a query in
MySQL and displayed to a webpage, you see ’ instead.

MS-Word parenthesis = Â’
Standard ASCII paranthesis = '

Reproduce code:
---
//database connection params
include("db_conn.php");

//the database should have a MS-Word parenthesis in it (Â’)
$result = mysql_query("SELECT textvalue FROM anytable");
$fetch_result = mysql_fetch_object($result);

//display result to a webpage
echo $fetch_result->textvalue;





Expected result:

Â’

Actual result:
--
’

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


#25871 [Opn]: imagecreatetruecolor crashes if image over 4mpix

2003-10-14 Thread bb at ii dot nl
 ID:   25871
 User updated by:  bb at ii dot nl
 Reported By:  bb at ii dot nl
 Status:   Open
 Bug Type: Reproducible crash
-Operating System: Debian Linux
+Operating System: RedHat Linux
 PHP Version:  4.3.3
 New Comment:

OS is RedHat, not Debian


Previous Comments:


[2003-10-14 15:27:54] bb at ii dot nl

Description:

ImageCreateTrueColor crashes PHP if I allocate an image over ~400
pixels in size.

I use PHP 4.3.3 with GD version: bundled (2.0.15 compatible)

Memory_limit is set to 26214400

Reproduce code:
---
$im = imagecreatetruecolor(1500,4000);


Actual result:
--
PHP crashes





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


#25871 [NEW]: imagecreatetruecolor crashes if image over 4mpix

2003-10-14 Thread bb at ii dot nl
From: bb at ii dot nl
Operating system: Debian Linux
PHP version:  4.3.3
PHP Bug Type: Reproducible crash
Bug description:  imagecreatetruecolor crashes if image over 4mpix

Description:

ImageCreateTrueColor crashes PHP if I allocate an image over ~400
pixels in size.

I use PHP 4.3.3 with GD version: bundled (2.0.15 compatible)

Memory_limit is set to 26214400

Reproduce code:
---
$im = imagecreatetruecolor(1500,4000);


Actual result:
--
PHP crashes

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


#25870 [Opn]: Session variables do NOT work as expected without session_register()

2003-10-14 Thread memoimyself at yahoo dot com dot br
 ID:   25870
 User updated by:  memoimyself at yahoo dot com dot br
 Reported By:  memoimyself at yahoo dot com dot br
 Status:   Open
 Bug Type: Session related
 Operating System: Windows 2000 SP 4
 PHP Version:  4.3.3
 New Comment:

Actually, I've found out that using session_register() won't help at
all. What does work is if I reload the page where the session variable
is set (start.php) and then open the page where the session variable is
used (test.php). For obvious reasons, this is not a very convenient
solution in a production environment. :-)


Previous Comments:


[2003-10-14 14:27:17] memoimyself at yahoo dot com dot br

Using Apache 2.0.46 and PHP as an Apache module (as opposed to CGI).



[2003-10-14 14:03:48] memoimyself at yahoo dot com dot br

Description:

I read in the manual that the use of session_register() is deprecated
and that session variables should now be registered simply by creating,
and assigning a value to, a member of the $_SESSION array.

Well, try as I may, I just cannot register session variables without
using session_register(). If, however, I use session_register() before
assigning a value to the new session variable via $_SESSION['x'],
everything works fine.

Reproduce code:
---
// PAGE A (start.php):



/***/

// PAGE B (test.php, called after start.php, obviously):



Expected result:

OUTPUT TO SCREEN:

my test

Actual result:
--
OUTPUT TO SCREEN:

Notice: Undefined index: test in D:\htdocs\Test\session\test.php on
line 3






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


#25870 [Opn]: Session variables do NOT work as expected without session_register()

2003-10-14 Thread memoimyself at yahoo dot com dot br
 ID:   25870
 User updated by:  memoimyself at yahoo dot com dot br
 Reported By:  memoimyself at yahoo dot com dot br
 Status:   Open
 Bug Type: Session related
 Operating System: Windows 2000 SP 4
 PHP Version:  4.3.3
 New Comment:

Using Apache 2.0.46 and PHP as an Apache module (as opposed to CGI).


Previous Comments:


[2003-10-14 14:03:48] memoimyself at yahoo dot com dot br

Description:

I read in the manual that the use of session_register() is deprecated
and that session variables should now be registered simply by creating,
and assigning a value to, a member of the $_SESSION array.

Well, try as I may, I just cannot register session variables without
using session_register(). If, however, I use session_register() before
assigning a value to the new session variable via $_SESSION['x'],
everything works fine.

Reproduce code:
---
// PAGE A (start.php):



/***/

// PAGE B (test.php, called after start.php, obviously):



Expected result:

OUTPUT TO SCREEN:

my test

Actual result:
--
OUTPUT TO SCREEN:

Notice: Undefined index: test in D:\htdocs\Test\session\test.php on
line 3






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


#25825 [Fbk->Opn]: Windows PHP always returns UTC time and BST as the timezone

2003-10-14 Thread pennington at rhodes dot edu
 ID:   25825
 User updated by:  pennington at rhodes dot edu
 Reported By:  pennington at rhodes dot edu
-Status:   Feedback
+Status:   Open
 Bug Type: Date/time related
 Operating System: Windows 2000
 PHP Version:  4.3.3
 Assigned To:  wez
 New Comment:

Ahh, the TikiWiki PHP application (in /lib/date/TimeZone.php) that we
are running does use putenv() in the following function:



/**
 * Is the given date/time in DST for this time zone
 *
 * Attempts to determine if a given Date object represents a
date/time
 * that is in DST for this time zone.  WARNINGS: this basically
attempts to
 * "trick" the system into telling us if we're in DST for a given
time zone.
 * This uses putenv() which may not work in safe mode, and relies
on unix time
 * which is only valid for dates from 1970 to ~2038.  This relies
on the
 * underlying OS calls, so it may not work on Windows or on a
system where
 * zoneinfo is not installed or configured properly.
 *
 * @access public
 * @param object Date $date the date/time to test
 * @return boolean true if this date is in DST for this time zone
 */
function inDaylightTime($date)
{
$env_tz = "";
if(getenv("TZ")) {
$env_tz = getenv("TZ");
}
putenv("TZ=".$this->id);
$ltime = localtime($date->getTime(), true);
putenv("TZ=".$env_tz);
return $ltime['tm_isdst'];
}

---

Are you saying that this could change the environment variable for
timezone for the entire server for good (at least until IIS5 is
restarted) once this code is executed? And this would affect pages that
don't even include the function above?


Previous Comments:


[2003-10-14 12:15:49] [EMAIL PROTECTED]

The only other way to manipulate locale is via putenv(), which would
change LC_* environment variable.



[2003-10-14 10:29:48] pennington at rhodes dot edu

I searched through all of the PHP code in use on this machine for the
setlocale() function and only found two entries, both of which were
commented out.

The only ISAPI filter we are using is PHP, and there is no ASP or other
code on that machine. In other words, we are only using it to serve PHP
pages, and none of those scripts use setlocale().

Would it be wise to unload the ASP stuff from the app mappings in IIS5
if we aren't using it so we can test to rule out ASP as the problem?

Are there any other PHP functions (other than setlocale) that
manipulate the locale?



[2003-10-13 18:41:27] [EMAIL PROTECTED]

Do any of your scripts use setlocale() or other similar function to
manipulate the locale?

My gut feeling is that something is (and it might be ASP or some other
ISAPI you have there), and that it isn't being reset back to the system
default.



[2003-10-13 17:53:32] pennington at rhodes dot edu

Interestingly, when testing to see if this UTC display of time would
happen for PHP installed as a CGI (couldn't reproduce with Apache2 or
IIS5 as a CGI), I noticed that the UTC time problem does not show up
right away with PHP installed as ISAPI on IIS5. Rather, when you stop
the IIS service and then start it again, for a period of time, the
correct time is displayed using echo date("D M j G:i:s T Y");

However, after a period of time passes (say an hour or so on a server
averaging a few users at a time), the time switches to UTC and does not
go back.

If you stop IIS and then start it again, the time goes back to the
correct time and the cycle starts again.

Note that this is using ISAPI on IIS5 on Windows 2000 Server. I been
trying PHP in ISAPI and CGI mode on a Windows 2000 workstation because
I've been having trouble getting the Windows 2000 Server, which uses
PHP ISAPI just fine, to run PHP in CGI mode. It should be as easy as
setting cgi.force_redirect = 0 and changing the app mapping
configuration to point to the php.exe and not the php4isapi.dll but I'm
not having any luck (get "not authorized to view this page" on php
scripts). This method works fine on the Win2K workstation. Anyway, this
is not related to the UTC time issue...



[2003-10-13 12:14:05] [EMAIL PROTECTED]

Do you get the same problem running CGI?




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

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


#21532 [NoF->Opn]: incorrect warning

2003-10-14 Thread czuma at poland dot org
 ID:   21532
 User updated by:  czuma at poland dot org
 Reported By:  czuma at poland dot org
-Status:   No Feedback
+Status:   Open
 Bug Type: *Directory/Filesystem functions
 Operating System: Solaris 8
 PHP Version:  4.3.2
 Assigned To:  wez
 New Comment:

The same problem in PHP 4.3.3.


Previous Comments:


[2003-08-01 06:10:27] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2003-07-27 13:52:02] [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





[2003-03-22 14:20:35] czuma at poland dot org

I have checked php4-STABLE-200303221630 (PHP/4.3.2-RC)

Unfortunately, it doesn't work. I still see incorrect warning.



[2003-03-01 12:07:47] czuma at poland dot org

I have checked php4-STABLE-200303011230

Unfortunately it doesn't work. I still see incorrect warning:

"SAFE MODE Restriction in effect. The script whose uid is XXX is not
allowed to access /www/user/data owned by uid 0 in
/www/user/stale/table1a.php on line 3"

"Line 3": 
$my=opendir("/www/user/data/$dat");

Probably: $dat=blabla/bleble.txt

Directory "blabla" doesn't exist. I see correct and then incorrect
warning.



[2003-02-25 01:42:35] rohan at cs dot rmit dot edu dot au

Opps, lost part of the error... it is: 

Warning: filemtime() [function.filemtime]: SAFE MODE Restriction in
effect. The script whose uid/gid is 1/31748 is not allowed to access
/home/m/malsmith/.HTMLinfo/lastmodified owned by uid/gid 31748/103 in
/home/m/malsmith/.HTMLinfo/software.php on line 3



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

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


#25827 [Fbk->Opn]: PHP LDAP queries against Active Directory return incomplete arrays

2003-10-14 Thread pennington at rhodes dot edu
 ID:   25827
 User updated by:  pennington at rhodes dot edu
 Reported By:  pennington at rhodes dot edu
-Status:   Feedback
+Status:   Open
 Bug Type: LDAP related
 Operating System: Windows 2000
 PHP Version:  4.3.3
 New Comment:

OK, you're right, after a few minutes, I found an ldapsearch command
that would work:

ldapsearch -x -b "CN=_some_user_,CN=Users,DC=rhodes,DC=edu" -D
"CN=_search_auth_user_,CN=Users,DC=rhodes,DC=edu" -H
ldap://someserver.rhodes.edu -W

The "memberof" attribute results look like this:

memberOf: CN=STAFF_DL,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=Planning,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=FACSTAFF,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=Council,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=PRESIDENT,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=FACTBOOK,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=INFO_SERVICES,OU=Security
Groups,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=CABINET,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=Senior2006,OU=Distribution
Lists,OU=Groups,DC=rhodes,DC=edu
memberOf: CN=NT Users,CN=Users,DC=rhodes,DC=edu
memberOf: CN=NTSETUP,CN=Users,DC=rhodes,DC=edu
memberOf: CN=Domain Users,CN=Users,DC=rhodes,DC=edu

Again, only 12 results were returned rather than the 13 that exist
there in Active Directory.

However, I've started doing a count based on attributes found by
ldapsearch and Softerra's LDAPBrowser (which I think also uses
openldap) and found that people missing an attibute value in ldapsearch
were missing the same value in LDAPBrowser.

Anyway, I think what we are down to is one of two possibilities:

1) OpenLDAP's search tool is not receiving all attribute values for a
particular search; or

2) Active Directory is not supplying the missing value when queried for
it using LDAP but does reply properly when Microsoft admin tools are
used.

I guess we could solve this if someone knows a good, freely-available,
non-openldap-based LDAP search utility.

Regardless, this doesn't look like a PHP bug per se, thought it could
be a OpenLDAP bug that has found its way into PHP with the rest of the
OpenLDAP code...


Previous Comments:


[2003-10-14 12:26:58] [EMAIL PROTECTED]

There is no kerberos support in PHP ldap either, and that partially
works, so why would you need it with the command line binary?




[2003-10-14 11:59:27] pennington at rhodes dot edu

It appears that ldapsearch at that URL is not compiled with Kerberos
support, which may be required to search Active Directory LDAP servers.
I'm still doing research, however...

D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D
pennington -k
ldapsearch: not compiled with Kerberos support

I tried it with just SASL and that wasn't appreciated either:

D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D
pennington -I
ldap_sasl_interactive_bind_s: Unknown authentication method (86)
additional info: SASL(-4): no mechanism available: Unable to
find a call
back: 2

Can anyone verify that Kerberos support is required to search Active
Directory LDAP servers? Is anyone using the OpenLDAP ldapsearch program
to search Active Directory LDAP servers? If so, what kind of command
should I use to get ldapsearch to search Active Directory?

I am using "CN=Users,DC=rhodes,DC=edu" for the Base DN,
"CN=_search_value_" for the name to search for, and to bind to the
Active Directory LDAP server, you have to use this string as the
username: "CN=_authorized_user_,CN=Users,DC=rhodes,DC=edu"



[2003-10-14 11:12:30] [EMAIL PROTECTED]

PHP uses OpenLDAP libraries for ldap functionality in the windows
binaries. So try your query with the openldap 'ldapsearch.exe' found in
this package:

http://prdownloads.sf.net/acctsync/openldap-binaries-2.1.16-04APR03.zip





[2003-10-13 12:05:40] pennington at rhodes dot edu

I obviously can't provide general access for testing to our Active
Directory server, because you need an account on the Active Directory
server to even search the directory, as with most LDAP servers.

I find it strange that no one has seen this before, because Microsoft's
Active Directory is probably the most widely-used commercial LDAP
server in the world.

However, it is obvious that, if an attribute has 13 values when looking
at it via another LDAP query tool and if PHP thinks that it has the
same number of values because it creates that many keys in the array,
the error must be that PHP is not setting the last value in the array
(for which there already is a key) or Active Directory is not giving
the last value to PHP for it to set

#25870 [NEW]: Session variables do NOT work as expected without session_register()

2003-10-14 Thread memoimyself at yahoo dot com dot br
From: memoimyself at yahoo dot com dot br
Operating system: Windows 2000 SP 4
PHP version:  4.3.3
PHP Bug Type: Session related
Bug description:  Session variables do NOT work as expected without session_register()

Description:

I read in the manual that the use of session_register() is deprecated and
that session variables should now be registered simply by creating, and
assigning a value to, a member of the $_SESSION array.

Well, try as I may, I just cannot register session variables without using
session_register(). If, however, I use session_register() before assigning
a value to the new session variable via $_SESSION['x'], everything works
fine.

Reproduce code:
---
// PAGE A (start.php):



/***/

// PAGE B (test.php, called after start.php, obviously):



Expected result:

OUTPUT TO SCREEN:

my test

Actual result:
--
OUTPUT TO SCREEN:

Notice: Undefined index: test in D:\htdocs\Test\session\test.php on line
3


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


#10027 [Com]: HTTP_REFERER

2003-10-14 Thread paul at bladetechnology dot co dot uk
 ID:   10027
 Comment by:   paul at bladetechnology dot co dot uk
 Reported By:  brad at youreshop dot com
 Status:   Closed
 Bug Type: *Web Server problem
 Operating System: Linux Redhat 6.2
 PHP Version:  4.0.4pl1
 New Comment:

The last comment was correct. It's caused by one of the Norton products
(Norton Personal Firwall in my case) changing the HTTP_REFERER header
into HTTP_WEFERER (elmer fudd?) and encrypting it.  You can solve this
by creating a rule in the firewall software to pass unaltered headers
to named sites.


Previous Comments:


[2002-05-09 08:38:17] mn at red1 dot net

I experienced the same problem using PHP4.2.0 (win32) with Apache on
WinME.
On the phpinfo() page HTTP_REFERER was shown as HTTP_WEFERER with a
value of a string of letters.

When I disabled "Norton Internet Security" the problem disappeared. 

What is more, scripts on a remote server which were reliant on getting
data from HTTP_REFERER would not run with "NIS" enabled.

Did you have a similar programme running?



[2002-03-07 06:15:43] [EMAIL PROTECTED]

HTTP_WEFERER has nothing todo with PHP its some 
data your browser gives out to the world.



[2002-03-07 04:19:22] alexleu at starglory dot com

Both windows2000 & FreeBSD 3.4 found SAME Problem With Apache! 
How to decode HTTP_WEFERER?



[2001-04-29 11:50:00] [EMAIL PROTECTED]

No feedback.

closing



[2001-03-29 11:11:48] [EMAIL PROTECTED]

Works for me just fine with latest CVS. (snapshot can be found at
http://snaps.php.net/ )

Which webserver are you using? Apache?

--Jani




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

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


#25867 [Bgs]: Sleep() no more work corectly on 4.3.3

2003-10-14 Thread plc2k at altern dot org
 ID:   25867
 User updated by:  plc2k at altern dot org
 Reported By:  plc2k at altern dot org
 Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: windows
 PHP Version:  4.3.3
 New Comment:

have you tested my example at least ?
as i said it work on older version and not on the new one, so for me
it's bug i see nothing on http://fr.php.net/sleep to let me know i'm
wrong in my code...
i posted a ot of messages in lot of forums, nobody know why it don't
work ...


Previous Comments:


[2003-10-14 13:31:54] plc2k at altens dot org

this is not a bug ? so why it work in older version ? 
i spend many time and used many forums, nobody know ..
so i 'm ok to read again the doc .. but ...
why it work in older version ...



[2003-10-14 12:33:25] [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

..




[2003-10-14 12:29:08] plc2k at altern dot org

Description:

i used a sleep() function in my php page, and after an upgrade of php,
this one no more work.
so it work on older version of php like 4.2.0 but not on last one, like
4.3.3

Reproduce code:
---
. ";
sleep(2);
}
?>

Expected result:

test . . . . . . . . . .

(here the "." are add one by one every 2 seconds)

Actual result:
--
test. . . . . . . . . . . . . 
Fatal error: Maximum execution time of 30 seconds exceeded in
c:\uptest2.php on line 8

(here, all the points appear at the timeout)





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


#25867 [Com]: Sleep() no more work corectly on 4.3.3

2003-10-14 Thread plc2k at altens dot org
 ID:   25867
 Comment by:   plc2k at altens dot org
 Reported By:  plc2k at altern dot org
 Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: windows
 PHP Version:  4.3.3
 New Comment:

this is not a bug ? so why it work in older version ? 
i spend many time and used many forums, nobody know ..
so i 'm ok to read again the doc .. but ...
why it work in older version ...


Previous Comments:


[2003-10-14 12:33:25] [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

..




[2003-10-14 12:29:08] plc2k at altern dot org

Description:

i used a sleep() function in my php page, and after an upgrade of php,
this one no more work.
so it work on older version of php like 4.2.0 but not on last one, like
4.3.3

Reproduce code:
---
. ";
sleep(2);
}
?>

Expected result:

test . . . . . . . . . .

(here the "." are add one by one every 2 seconds)

Actual result:
--
test. . . . . . . . . . . . . 
Fatal error: Maximum execution time of 30 seconds exceeded in
c:\uptest2.php on line 8

(here, all the points appear at the timeout)





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


#25868 [NEW]: error in mail()- function

2003-10-14 Thread info at xaran dot de
From: info at xaran dot de
Operating system: Win XP SP1
PHP version:  4.3.3
PHP Bug Type: Mail related
Bug description:  error in mail()- function

Description:

There is a description of the error available as a PDF- document at
http://www.xaran.de/php.pdf.

Reproduce code:
---
There is a description of the error available as a PDF- document at
http://www.xaran.de/php.pdf.

Expected result:

There is a description of the error available as a PDF- document at
http://www.xaran.de/php.pdf.

Actual result:
--
There is a description of the error available as a PDF- document at
http://www.xaran.de/php.pdf.

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


#25862 [Fbk->Opn]: mail() always return FALSE

2003-10-14 Thread thouraud at bondy dot ird dot fr
 ID:   25862
 User updated by:  thouraud at bondy dot ird dot fr
 Reported By:  thouraud at bondy dot ird dot fr
-Status:   Feedback
+Status:   Open
 Bug Type: Mail related
 Operating System: solaris 9
 PHP Version:  4.3.3
 New Comment:

Without the --enable-sigchild configure option, it seems that mail()
alwayes return TRUE.

Even if the mail server returns an "unknown error" with a false email,
or an "No recipients specified" with a blank first field of mail().

Is that normal ? When mail() returns FALSE ?


Previous Comments:


[2003-10-14 11:13:37] [EMAIL PROTECTED]

Okay, try removing the --enable-sigchild configure option
and reconfigure/compile PHP. (don't forget to delete config.cache
before reconfiguring!)




[2003-10-14 10:44:48] thouraud at bondy dot ird dot fr

the configure line is :

./configure  --with-apxs=/opt/apache/bin/apxs --prefix=/opt/apache
--with-config-file-path=/opt/apache/conf --with-mysql --disable-debug
--enable-trans-sid --with-oci8=/opt/oracle/product/9201 --enable-dbase
--enable-safe-mode --disable-magic-quotes --enable-sigchild
--enable-ldap --with-zlib=/opt/sfwplus --enable-mbstring
--enable-mbregex --enable-zend-multibyte --enable-bcmath
--enable-calendar --enable-exif --with-jpeg-dir=/opt/sfwplus
--with-png-dir=/opt/sfwplus --with-tiff-dir=/opt/sfwplus --with-gd
--with-iconv --with-pgsql=/opt/postgres



[2003-10-14 10:34:18] [EMAIL PROTECTED]

What was the configure line you used to configure PHP?




[2003-10-14 08:26:31] thouraud at bondy dot ird dot fr

Description:

The mail() function always return FALSE.
Even if the mail is sent !

Test with the sun's sendmail and postfix 2.0.16.
The mail can go out with no problem.

The result get the same safe_mode or not.

apache 1.3.28 with php as a module

Reproduce code:
---
" ;
  if ($ret) {
print 'OK' ;
  } else {
print 'KO' ;
  }

?>


Expected result:

if we can send mail to [EMAIL PROTECTED]
then OK and [EMAIL PROTECTED] receive the mail.


if any error to sent mail 
then KO and no mail !

Actual result:
--
always KO

but the mail are been received !





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


#25866 [Bgs]: Using error_reporting() function don't change output of phpinfo() function

2003-10-14 Thread sfournier at dmsolutions dot ca
 ID:   25866
 User updated by:  sfournier at dmsolutions dot ca
 Reported By:  sfournier at dmsolutions dot ca
 Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: Linux
 PHP Version:  4.3.3
 New Comment:

Oh. Ok my bad. So the local is the runtime and master is the value from
the ini. Right ?


Previous Comments:


[2003-10-14 12:31:13] [EMAIL PROTECTED]

First is the local value, second is master.

error_reporting => 1 => 2047

(local being the runtime value..)




[2003-10-14 12:28:34] [EMAIL PROTECTED]

It's showing the INI setting, that's totally different than a runtime
setting.




[2003-10-14 12:26:40] sfournier at dmsolutions dot ca

Description:

Same as http://bugs.php.net/bug.php?id=18498 but with PHP 4.3.3


My php.ini contain this line:
.
.
error_reporting  =  E_ALL & ~E_NOTICE
.
.

With this simple script the error_reporting parameter is set to 2039,
wich is ok.



Using the same php.ini, with this other script the error_reporting
parameter is *still* set to 2039. Shouldn't be set to 1 ?








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


#25794 [Opn->Asn]: Cannot open existing hash db3 file with write

2003-10-14 Thread sniper
 ID:   25794
 Updated by:   [EMAIL PROTECTED]
 Reported By:  rcovell at rolet dot com
-Status:   Open
+Status:   Assigned
 Bug Type: DBM/DBA related
 Operating System: FreeBSD 4.8
 PHP Version:  4.3.4RC1
-Assigned To:  
+Assigned To:  helly


Previous Comments:


[2003-10-08 10:10:39] rcovell at rolet dot com

Description:

Basically I cannot get php to open an existing (not created by php) db3
hash file when using either "w" or "c".  It seems that php is looking
for a btree format.  My database is a hash file.

More information:
Trying to read/write information to an existing db3 database (sendmail
aliases file).

I can read the file just fine.  But when I try to issue:

$id = dba_open ("aliases5.db", "w", "db3");

I get:
[Wed Oct  8 08:56:44 2003] [error] PHP Warning: 
dba_open(aliases5.db,w): Driver initialization failed for handler: db3:
Invalid argument in /usr/local/www/data/maillists/test3.php on line 3

After further testing I dumped the entire aliases db to a text file
using perl and recreated a copy of it with php:

$id = dba_open ("aliases5.db", "c", "db3");

This worked when creating a new file.  The file sizes where were
different from the original so performed a db3_dump on the newly
created php db3 database.  It seems that php is defaulting to a btree
format when trying to open with either w or c.  My output from the
db3_dump on the php created db3:
VERSION=3
format=bytevalue
type=btree
HEADER=END

And from the one that sendmail created:
VERSION=3
format=bytevalue
type=hash
h_nelem=172
HEADER=END





Reproduce code:
---
//Note you need a hash database for this to fail
$id = dba_open ("aliases5.db", "w", "db3");
if (!$id) {
echo "dba_open failed\n";
exit;
}
dba_insert ("bkey", "bvalue", $id);

$key = dba_firstkey ($id);

while ($key != false)
{
echo "Key: " . $key . "->Value: " . dba_fetch ( $key, $id);
$key = dba_nextkey ($id);
}

dba_close ($id);


Expected result:

To be able to insert into an existing (not created by php) db3 hash
database.

Actual result:
--
[Wed Oct  8 08:56:44 2003] [error] PHP Warning: 
dba_open(aliases5.db,w): Driver initialization failed for handler: db3:
Invalid argument in /usr/local/www/data/maillists/test3.php on line 3





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


#25793 [Bgs]: special POST or GET query crashes PHP under Windows

2003-10-14 Thread sniper
 ID:   25793
 Updated by:   [EMAIL PROTECTED]
 Reported By:  valyala at tut dot by
 Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Win2k sp3, WinXP, Win2003
 PHP Version:  4.3.3RC1 - RC4
 New Comment:

Could not reproduce with PHP 4.3.4RC2-dev, that is.



Previous Comments:


[2003-10-14 12:34:52] [EMAIL PROTECTED]

You're doing something wrong, I can NOT reproduce this.
Make sure you actually have ONLY one php4ts.dll, etc. in your system.




[2003-10-13 09:23:30] valyala at tut dot by

I am using Apache 1.3.27 webserver.
This string is in apache's httpd.conf file:
LoadModule php4_module "c:/usr/bin/php/sapi/php4apache.dll"



[2003-10-13 03:26:56] [EMAIL PROTECTED]

I can not reproduce this within WinXP + Apache2 (PHP as apache2
module). 

What SAPI module are you using? (isapi,apache1/2, CGI binary..)
Webserver?




[2003-10-08 09:34:18] valyala at tut dot by

Description:

this query strings crashes PHP under Windows:
1[]
437378[index]
232[index]=value&something_else

the query string must begins with any decimal number, following braces
with optional index string.

Sorry for my English :)

Reproduce code:
---
GET /any_php_script.php?1[] HTTP/1.1


Expected result:

If my script looks like this:


I expected:
Array
(
[1] => Array
(
[0] => 
)

)


Actual result:
--
No response headers received because request failed :
ERROR_INTERNET_CONNECTION_RESET

And windows shows error message: "Apache.exe has generated errors and
will be closed by Windows. You will need to restart the program"





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


#25793 [Opn->Bgs]: special POST or GET query crashes PHP under Windows

2003-10-14 Thread sniper
 ID:   25793
 Updated by:   [EMAIL PROTECTED]
 Reported By:  valyala at tut dot by
-Status:   Open
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Win2k sp3, WinXP, Win2003
 PHP Version:  4.3.3RC1 - RC4
 New Comment:

You're doing something wrong, I can NOT reproduce this.
Make sure you actually have ONLY one php4ts.dll, etc. in your system.



Previous Comments:


[2003-10-13 09:23:30] valyala at tut dot by

I am using Apache 1.3.27 webserver.
This string is in apache's httpd.conf file:
LoadModule php4_module "c:/usr/bin/php/sapi/php4apache.dll"



[2003-10-13 03:26:56] [EMAIL PROTECTED]

I can not reproduce this within WinXP + Apache2 (PHP as apache2
module). 

What SAPI module are you using? (isapi,apache1/2, CGI binary..)
Webserver?




[2003-10-08 09:34:18] valyala at tut dot by

Description:

this query strings crashes PHP under Windows:
1[]
437378[index]
232[index]=value&something_else

the query string must begins with any decimal number, following braces
with optional index string.

Sorry for my English :)

Reproduce code:
---
GET /any_php_script.php?1[] HTTP/1.1


Expected result:

If my script looks like this:


I expected:
Array
(
[1] => Array
(
[0] => 
)

)


Actual result:
--
No response headers received because request failed :
ERROR_INTERNET_CONNECTION_RESET

And windows shows error message: "Apache.exe has generated errors and
will be closed by Windows. You will need to restart the program"





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


#25867 [Opn->Bgs]: Sleep() no more work corectly on 4.3.3

2003-10-14 Thread sniper
 ID:   25867
 Updated by:   [EMAIL PROTECTED]
 Reported By:  plc2k at altern dot org
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: windows
 PHP Version:  4.3.3
 New Comment:

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

..



Previous Comments:


[2003-10-14 12:29:08] plc2k at altern dot org

Description:

i used a sleep() function in my php page, and after an upgrade of php,
this one no more work.
so it work on older version of php like 4.2.0 but not on last one, like
4.3.3

Reproduce code:
---
. ";
sleep(2);
}
?>

Expected result:

test . . . . . . . . . .

(here the "." are add one by one every 2 seconds)

Actual result:
--
test. . . . . . . . . . . . . 
Fatal error: Maximum execution time of 30 seconds exceeded in
c:\uptest2.php on line 8

(here, all the points appear at the timeout)





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


#25866 [Bgs]: Using error_reporting() function don't change output of phpinfo() function

2003-10-14 Thread sniper
 ID:   25866
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sfournier at dmsolutions dot ca
 Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: Linux
 PHP Version:  4.3.3
 New Comment:

First is the local value, second is master.

error_reporting => 1 => 2047

(local being the runtime value..)



Previous Comments:


[2003-10-14 12:28:34] [EMAIL PROTECTED]

It's showing the INI setting, that's totally different than a runtime
setting.




[2003-10-14 12:26:40] sfournier at dmsolutions dot ca

Description:

Same as http://bugs.php.net/bug.php?id=18498 but with PHP 4.3.3


My php.ini contain this line:
.
.
error_reporting  =  E_ALL & ~E_NOTICE
.
.

With this simple script the error_reporting parameter is set to 2039,
wich is ok.



Using the same php.ini, with this other script the error_reporting
parameter is *still* set to 2039. Shouldn't be set to 1 ?








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


#25867 [NEW]: Sleep() no more work corectly on 4.3.3

2003-10-14 Thread plc2k at altern dot org
From: plc2k at altern dot org
Operating system: windows
PHP version:  4.3.3
PHP Bug Type: Unknown/Other Function
Bug description:  Sleep() no more work corectly on 4.3.3

Description:

i used a sleep() function in my php page, and after an upgrade of php,
this one no more work.
so it work on older version of php like 4.2.0 but not on last one, like
4.3.3

Reproduce code:
---
. ";
sleep(2);
}
?>

Expected result:

test . . . . . . . . . .

(here the "." are add one by one every 2 seconds)

Actual result:
--
test. . . . . . . . . . . . . 
Fatal error: Maximum execution time of 30 seconds exceeded in
c:\uptest2.php on line 8

(here, all the points appear at the timeout)

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


#25866 [Opn->Bgs]: Using error_reporting() function don't change output of phpinfo() function

2003-10-14 Thread sniper
 ID:   25866
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sfournier at dmsolutions dot ca
-Status:   Open
+Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: Linux
 PHP Version:  4.3.3
 New Comment:

It's showing the INI setting, that's totally different than a runtime
setting.



Previous Comments:


[2003-10-14 12:26:40] sfournier at dmsolutions dot ca

Description:

Same as http://bugs.php.net/bug.php?id=18498 but with PHP 4.3.3


My php.ini contain this line:
.
.
error_reporting  =  E_ALL & ~E_NOTICE
.
.

With this simple script the error_reporting parameter is set to 2039,
wich is ok.



Using the same php.ini, with this other script the error_reporting
parameter is *still* set to 2039. Shouldn't be set to 1 ?








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


#25827 [Opn->Fbk]: PHP LDAP queries against Active Directory return incomplete arrays

2003-10-14 Thread sniper
 ID:   25827
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pennington at rhodes dot edu
-Status:   Open
+Status:   Feedback
 Bug Type: LDAP related
 Operating System: Windows 2000
 PHP Version:  4.3.3
 New Comment:

There is no kerberos support in PHP ldap either, and that partially
works, so why would you need it with the command line binary?



Previous Comments:


[2003-10-14 11:59:27] pennington at rhodes dot edu

It appears that ldapsearch at that URL is not compiled with Kerberos
support, which may be required to search Active Directory LDAP servers.
I'm still doing research, however...

D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D
pennington -k
ldapsearch: not compiled with Kerberos support

I tried it with just SASL and that wasn't appreciated either:

D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D
pennington -I
ldap_sasl_interactive_bind_s: Unknown authentication method (86)
additional info: SASL(-4): no mechanism available: Unable to
find a call
back: 2

Can anyone verify that Kerberos support is required to search Active
Directory LDAP servers? Is anyone using the OpenLDAP ldapsearch program
to search Active Directory LDAP servers? If so, what kind of command
should I use to get ldapsearch to search Active Directory?

I am using "CN=Users,DC=rhodes,DC=edu" for the Base DN,
"CN=_search_value_" for the name to search for, and to bind to the
Active Directory LDAP server, you have to use this string as the
username: "CN=_authorized_user_,CN=Users,DC=rhodes,DC=edu"



[2003-10-14 11:12:30] [EMAIL PROTECTED]

PHP uses OpenLDAP libraries for ldap functionality in the windows
binaries. So try your query with the openldap 'ldapsearch.exe' found in
this package:

http://prdownloads.sf.net/acctsync/openldap-binaries-2.1.16-04APR03.zip





[2003-10-13 12:05:40] pennington at rhodes dot edu

I obviously can't provide general access for testing to our Active
Directory server, because you need an account on the Active Directory
server to even search the directory, as with most LDAP servers.

I find it strange that no one has seen this before, because Microsoft's
Active Directory is probably the most widely-used commercial LDAP
server in the world.

However, it is obvious that, if an attribute has 13 values when looking
at it via another LDAP query tool and if PHP thinks that it has the
same number of values because it creates that many keys in the array,
the error must be that PHP is not setting the last value in the array
(for which there already is a key) or Active Directory is not giving
the last value to PHP for it to set in the array.

Is anyone else using AD and PHP/LDAP seeing similar behavior? Can we
not put this in feedback mode and request more information?



[2003-10-13 11:55:58] [EMAIL PROTECTED]

Please provide access to this 'active directory' thing.
(If you can't, we can't fix it either)




[2003-10-13 11:50:09] pennington at rhodes dot edu

I added:

var_dump($info[$i][$data][$jj]);

to the output of the test script and got this output for the last two
values of the array for that attribute:

0 1 11 memberof:  CN=Domain Users,CN=Users,DC=rhodes,DC=edu
string(41) "CN=Domain Users,CN=Users,DC=rhodes,DC=edu"
0 1 12 memberof:  
NULL 

Now, I know that there are 13 LDAP values for this attribute
(memberof). I can see this in various LDAP tools pointed to Active
Directory for this user. And, when I do a:

count($info[$i][memberof]);

I get 13, which is correct.

As you can see, the final value has a key value in the array for this
attribute, but no data is returned with that key. Obviously, PHP is not
putting the last value for that attribute in the array but has created
a key value to hold the data.

How is this a problem in the script? Looks like a bug in PHP to me...



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

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


#25866 [NEW]: Using error_reporting() function don't change output of phpinfo() function

2003-10-14 Thread sfournier at dmsolutions dot ca
From: sfournier at dmsolutions dot ca
Operating system: Linux
PHP version:  4.3.3
PHP Bug Type: PHP options/info functions
Bug description:  Using error_reporting() function don't change output of phpinfo() 
function

Description:

Same as http://bugs.php.net/bug.php?id=18498 but with PHP 4.3.3


My php.ini contain this line:
.
.
error_reporting  =  E_ALL & ~E_NOTICE
.
.

With this simple script the error_reporting parameter is set to 2039, wich
is ok.



Using the same php.ini, with this other script the error_reporting
parameter is *still* set to 2039. Shouldn't be set to 1 ?




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


#25825 [Opn->Fbk]: Windows PHP always returns UTC time and BST as the timezone

2003-10-14 Thread iliaa
 ID:   25825
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pennington at rhodes dot edu
-Status:   Open
+Status:   Feedback
 Bug Type: Date/time related
 Operating System: Windows 2000
 PHP Version:  4.3.3
 Assigned To:  wez
 New Comment:

The only other way to manipulate locale is via putenv(), which would
change LC_* environment variable.


Previous Comments:


[2003-10-14 10:29:48] pennington at rhodes dot edu

I searched through all of the PHP code in use on this machine for the
setlocale() function and only found two entries, both of which were
commented out.

The only ISAPI filter we are using is PHP, and there is no ASP or other
code on that machine. In other words, we are only using it to serve PHP
pages, and none of those scripts use setlocale().

Would it be wise to unload the ASP stuff from the app mappings in IIS5
if we aren't using it so we can test to rule out ASP as the problem?

Are there any other PHP functions (other than setlocale) that
manipulate the locale?



[2003-10-13 18:41:27] [EMAIL PROTECTED]

Do any of your scripts use setlocale() or other similar function to
manipulate the locale?

My gut feeling is that something is (and it might be ASP or some other
ISAPI you have there), and that it isn't being reset back to the system
default.



[2003-10-13 17:53:32] pennington at rhodes dot edu

Interestingly, when testing to see if this UTC display of time would
happen for PHP installed as a CGI (couldn't reproduce with Apache2 or
IIS5 as a CGI), I noticed that the UTC time problem does not show up
right away with PHP installed as ISAPI on IIS5. Rather, when you stop
the IIS service and then start it again, for a period of time, the
correct time is displayed using echo date("D M j G:i:s T Y");

However, after a period of time passes (say an hour or so on a server
averaging a few users at a time), the time switches to UTC and does not
go back.

If you stop IIS and then start it again, the time goes back to the
correct time and the cycle starts again.

Note that this is using ISAPI on IIS5 on Windows 2000 Server. I been
trying PHP in ISAPI and CGI mode on a Windows 2000 workstation because
I've been having trouble getting the Windows 2000 Server, which uses
PHP ISAPI just fine, to run PHP in CGI mode. It should be as easy as
setting cgi.force_redirect = 0 and changing the app mapping
configuration to point to the php.exe and not the php4isapi.dll but I'm
not having any luck (get "not authorized to view this page" on php
scripts). This method works fine on the Win2K workstation. Anyway, this
is not related to the UTC time issue...



[2003-10-13 12:14:05] [EMAIL PROTECTED]

Do you get the same problem running CGI?




[2003-10-13 09:52:27] pennington at rhodes dot edu

[EMAIL PROTECTED] wanted to know "Which SAPI are you running? CGI? ISAPI?
Apache? Something else?"

I'm running ISAPI.

I fail to see how this bug is identical to bug #23467, because I am
getting an incorrect offset of time from GMT in addition to the
incorrect time zone appearing. Unless, of course, time in general is
screwed up for PHP on Win32...



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

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


#25827 [Fbk->Opn]: PHP LDAP queries against Active Directory return incomplete arrays

2003-10-14 Thread pennington at rhodes dot edu
 ID:   25827
 User updated by:  pennington at rhodes dot edu
 Reported By:  pennington at rhodes dot edu
-Status:   Feedback
+Status:   Open
 Bug Type: LDAP related
 Operating System: Windows 2000
 PHP Version:  4.3.3
 New Comment:

It appears that ldapsearch at that URL is not compiled with Kerberos
support, which may be required to search Active Directory LDAP servers.
I'm still doing research, however...

D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D
pennington -k
ldapsearch: not compiled with Kerberos support

I tried it with just SASL and that wasn't appreciated either:

D:\openldap\bin>ldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D
pennington -I
ldap_sasl_interactive_bind_s: Unknown authentication method (86)
additional info: SASL(-4): no mechanism available: Unable to
find a call
back: 2

Can anyone verify that Kerberos support is required to search Active
Directory LDAP servers? Is anyone using the OpenLDAP ldapsearch program
to search Active Directory LDAP servers? If so, what kind of command
should I use to get ldapsearch to search Active Directory?

I am using "CN=Users,DC=rhodes,DC=edu" for the Base DN,
"CN=_search_value_" for the name to search for, and to bind to the
Active Directory LDAP server, you have to use this string as the
username: "CN=_authorized_user_,CN=Users,DC=rhodes,DC=edu"


Previous Comments:


[2003-10-14 11:12:30] [EMAIL PROTECTED]

PHP uses OpenLDAP libraries for ldap functionality in the windows
binaries. So try your query with the openldap 'ldapsearch.exe' found in
this package:

http://prdownloads.sf.net/acctsync/openldap-binaries-2.1.16-04APR03.zip





[2003-10-13 12:05:40] pennington at rhodes dot edu

I obviously can't provide general access for testing to our Active
Directory server, because you need an account on the Active Directory
server to even search the directory, as with most LDAP servers.

I find it strange that no one has seen this before, because Microsoft's
Active Directory is probably the most widely-used commercial LDAP
server in the world.

However, it is obvious that, if an attribute has 13 values when looking
at it via another LDAP query tool and if PHP thinks that it has the
same number of values because it creates that many keys in the array,
the error must be that PHP is not setting the last value in the array
(for which there already is a key) or Active Directory is not giving
the last value to PHP for it to set in the array.

Is anyone else using AD and PHP/LDAP seeing similar behavior? Can we
not put this in feedback mode and request more information?



[2003-10-13 11:55:58] [EMAIL PROTECTED]

Please provide access to this 'active directory' thing.
(If you can't, we can't fix it either)




[2003-10-13 11:50:09] pennington at rhodes dot edu

I added:

var_dump($info[$i][$data][$jj]);

to the output of the test script and got this output for the last two
values of the array for that attribute:

0 1 11 memberof:  CN=Domain Users,CN=Users,DC=rhodes,DC=edu
string(41) "CN=Domain Users,CN=Users,DC=rhodes,DC=edu"
0 1 12 memberof:  
NULL 

Now, I know that there are 13 LDAP values for this attribute
(memberof). I can see this in various LDAP tools pointed to Active
Directory for this user. And, when I do a:

count($info[$i][memberof]);

I get 13, which is correct.

As you can see, the final value has a key value in the array for this
attribute, but no data is returned with that key. Obviously, PHP is not
putting the last value for that attribute in the array but has created
a key value to hold the data.

How is this a problem in the script? Looks like a bug in PHP to me...



[2003-10-12 22:10:52] [EMAIL PROTECTED]

Some var_dump() here and there will reveal you why your script doesn't
work. Not PHP bug.




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

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


#25862 [Opn->Fbk]: mail() always return FALSE

2003-10-14 Thread sniper
 ID:   25862
 Updated by:   [EMAIL PROTECTED]
 Reported By:  thouraud at bondy dot ird dot fr
-Status:   Open
+Status:   Feedback
 Bug Type: Mail related
 Operating System: solaris 9
 PHP Version:  4.3.3
 New Comment:

Okay, try removing the --enable-sigchild configure option
and reconfigure/compile PHP. (don't forget to delete config.cache
before reconfiguring!)



Previous Comments:


[2003-10-14 10:44:48] thouraud at bondy dot ird dot fr

the configure line is :

./configure  --with-apxs=/opt/apache/bin/apxs --prefix=/opt/apache
--with-config-file-path=/opt/apache/conf --with-mysql --disable-debug
--enable-trans-sid --with-oci8=/opt/oracle/product/9201 --enable-dbase
--enable-safe-mode --disable-magic-quotes --enable-sigchild
--enable-ldap --with-zlib=/opt/sfwplus --enable-mbstring
--enable-mbregex --enable-zend-multibyte --enable-bcmath
--enable-calendar --enable-exif --with-jpeg-dir=/opt/sfwplus
--with-png-dir=/opt/sfwplus --with-tiff-dir=/opt/sfwplus --with-gd
--with-iconv --with-pgsql=/opt/postgres



[2003-10-14 10:34:18] [EMAIL PROTECTED]

What was the configure line you used to configure PHP?




[2003-10-14 08:26:31] thouraud at bondy dot ird dot fr

Description:

The mail() function always return FALSE.
Even if the mail is sent !

Test with the sun's sendmail and postfix 2.0.16.
The mail can go out with no problem.

The result get the same safe_mode or not.

apache 1.3.28 with php as a module

Reproduce code:
---
" ;
  if ($ret) {
print 'OK' ;
  } else {
print 'KO' ;
  }

?>


Expected result:

if we can send mail to [EMAIL PROTECTED]
then OK and [EMAIL PROTECTED] receive the mail.


if any error to sent mail 
then KO and no mail !

Actual result:
--
always KO

but the mail are been received !





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



#25827 [Opn->Fbk]: PHP LDAP queries against Active Directory return incomplete arrays

2003-10-14 Thread sniper
 ID:   25827
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pennington at rhodes dot edu
-Status:   Open
+Status:   Feedback
 Bug Type: LDAP related
 Operating System: Windows 2000
 PHP Version:  4.3.3
 New Comment:

PHP uses OpenLDAP libraries for ldap functionality in the windows
binaries. So try your query with the openldap 'ldapsearch.exe' found in
this package:

http://prdownloads.sf.net/acctsync/openldap-binaries-2.1.16-04APR03.zip




Previous Comments:


[2003-10-13 12:05:40] pennington at rhodes dot edu

I obviously can't provide general access for testing to our Active
Directory server, because you need an account on the Active Directory
server to even search the directory, as with most LDAP servers.

I find it strange that no one has seen this before, because Microsoft's
Active Directory is probably the most widely-used commercial LDAP
server in the world.

However, it is obvious that, if an attribute has 13 values when looking
at it via another LDAP query tool and if PHP thinks that it has the
same number of values because it creates that many keys in the array,
the error must be that PHP is not setting the last value in the array
(for which there already is a key) or Active Directory is not giving
the last value to PHP for it to set in the array.

Is anyone else using AD and PHP/LDAP seeing similar behavior? Can we
not put this in feedback mode and request more information?



[2003-10-13 11:55:58] [EMAIL PROTECTED]

Please provide access to this 'active directory' thing.
(If you can't, we can't fix it either)




[2003-10-13 11:50:09] pennington at rhodes dot edu

I added:

var_dump($info[$i][$data][$jj]);

to the output of the test script and got this output for the last two
values of the array for that attribute:

0 1 11 memberof:  CN=Domain Users,CN=Users,DC=rhodes,DC=edu
string(41) "CN=Domain Users,CN=Users,DC=rhodes,DC=edu"
0 1 12 memberof:  
NULL 

Now, I know that there are 13 LDAP values for this attribute
(memberof). I can see this in various LDAP tools pointed to Active
Directory for this user. And, when I do a:

count($info[$i][memberof]);

I get 13, which is correct.

As you can see, the final value has a key value in the array for this
attribute, but no data is returned with that key. Obviously, PHP is not
putting the last value for that attribute in the array but has created
a key value to hold the data.

How is this a problem in the script? Looks like a bug in PHP to me...



[2003-10-12 22:10:52] [EMAIL PROTECTED]

Some var_dump() here and there will reveal you why your script doesn't
work. Not PHP bug.




[2003-10-10 15:04:36] pennington at rhodes dot edu

Description:

I am querying an Active Directory server with PHP via LDAP to retrieve
all of a particular user's attributes. All of that user's attributes in
the LDAP directory are placed in a multi-dimensional array that I can
query for a particular attribute I am interested in and return all of
those values from the array by looping through that part of the array,
using the correct key value.

So, in other words, I am using PHP's LDAP to grab all information about
a user in Active Directory and put it into a single, multi-dimensional
array called $info. This array has three levels of keys, such that:

$info[0][description][0]

would equal

Staff

because that is what is set up for the description attribute for a
person in Active Directory. I am then looping through the entire array
looking for values set with certain keys that I am interested in, which
could be holding data in any order.

The problem occurs when I loop through the multi-dimensional array for
attributes that share the second key, such as:

$info[0][memberof]

Because several different memberof attributes can be stored for a
person in Active Directory, the LDAP-built array has values like:

$info[0][memberof][0] = Domain Admin
$info[0][memberof][1] = Finance User
$info[0][memberof][2] = Local Admin

and so on. If I count the number of member attributes that are actually
in the LDAP server, I get a particular value, say 15. When I loop
through these attributes in the array and count them up, I also get
that same number. However, when I try to report back all of these
attributes by printing them out, only 14 appear.

In other words, while the correct number of attributes are put into the
array by PHP using LDAP, one of the keys in the array has no data
associated with it (and should have data associated with it). This
holds true for any LDAP-created array where an LDAP attribute has more
than one value associated with it. All of those values are 

#25862 [Fbk->Opn]: mail() always return FALSE

2003-10-14 Thread thouraud at bondy dot ird dot fr
 ID:   25862
 User updated by:  thouraud at bondy dot ird dot fr
 Reported By:  thouraud at bondy dot ird dot fr
-Status:   Feedback
+Status:   Open
 Bug Type: Mail related
 Operating System: solaris 9
 PHP Version:  4.3.3
 New Comment:

the configure line is :

./configure  --with-apxs=/opt/apache/bin/apxs --prefix=/opt/apache
--with-config-file-path=/opt/apache/conf --with-mysql --disable-debug
--enable-trans-sid --with-oci8=/opt/oracle/product/9201 --enable-dbase
--enable-safe-mode --disable-magic-quotes --enable-sigchild
--enable-ldap --with-zlib=/opt/sfwplus --enable-mbstring
--enable-mbregex --enable-zend-multibyte --enable-bcmath
--enable-calendar --enable-exif --with-jpeg-dir=/opt/sfwplus
--with-png-dir=/opt/sfwplus --with-tiff-dir=/opt/sfwplus --with-gd
--with-iconv --with-pgsql=/opt/postgres


Previous Comments:


[2003-10-14 10:34:18] [EMAIL PROTECTED]

What was the configure line you used to configure PHP?




[2003-10-14 08:26:31] thouraud at bondy dot ird dot fr

Description:

The mail() function always return FALSE.
Even if the mail is sent !

Test with the sun's sendmail and postfix 2.0.16.
The mail can go out with no problem.

The result get the same safe_mode or not.

apache 1.3.28 with php as a module

Reproduce code:
---
" ;
  if ($ret) {
print 'OK' ;
  } else {
print 'KO' ;
  }

?>


Expected result:

if we can send mail to [EMAIL PROTECTED]
then OK and [EMAIL PROTECTED] receive the mail.


if any error to sent mail 
then KO and no mail !

Actual result:
--
always KO

but the mail are been received !





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


#25862 [Opn->Fbk]: mail() always return FALSE

2003-10-14 Thread sniper
 ID:   25862
 Updated by:   [EMAIL PROTECTED]
 Reported By:  thouraud at bondy dot ird dot fr
-Status:   Open
+Status:   Feedback
 Bug Type: Mail related
 Operating System: solaris 9
 PHP Version:  4.3.3
 New Comment:

What was the configure line you used to configure PHP?



Previous Comments:


[2003-10-14 08:26:31] thouraud at bondy dot ird dot fr

Description:

The mail() function always return FALSE.
Even if the mail is sent !

Test with the sun's sendmail and postfix 2.0.16.
The mail can go out with no problem.

The result get the same safe_mode or not.

apache 1.3.28 with php as a module

Reproduce code:
---
" ;
  if ($ret) {
print 'OK' ;
  } else {
print 'KO' ;
  }

?>


Expected result:

if we can send mail to [EMAIL PROTECTED]
then OK and [EMAIL PROTECTED] receive the mail.


if any error to sent mail 
then KO and no mail !

Actual result:
--
always KO

but the mail are been received !





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


#25825 [Fbk->Opn]: Windows PHP always returns UTC time and BST as the timezone

2003-10-14 Thread pennington at rhodes dot edu
 ID:   25825
 User updated by:  pennington at rhodes dot edu
 Reported By:  pennington at rhodes dot edu
-Status:   Feedback
+Status:   Open
 Bug Type: Date/time related
 Operating System: Windows 2000
 PHP Version:  4.3.3
 Assigned To:  wez
 New Comment:

I searched through all of the PHP code in use on this machine for the
setlocale() function and only found two entries, both of which were
commented out.

The only ISAPI filter we are using is PHP, and there is no ASP or other
code on that machine. In other words, we are only using it to serve PHP
pages, and none of those scripts use setlocale().

Would it be wise to unload the ASP stuff from the app mappings in IIS5
if we aren't using it so we can test to rule out ASP as the problem?

Are there any other PHP functions (other than setlocale) that
manipulate the locale?


Previous Comments:


[2003-10-13 18:41:27] [EMAIL PROTECTED]

Do any of your scripts use setlocale() or other similar function to
manipulate the locale?

My gut feeling is that something is (and it might be ASP or some other
ISAPI you have there), and that it isn't being reset back to the system
default.



[2003-10-13 17:53:32] pennington at rhodes dot edu

Interestingly, when testing to see if this UTC display of time would
happen for PHP installed as a CGI (couldn't reproduce with Apache2 or
IIS5 as a CGI), I noticed that the UTC time problem does not show up
right away with PHP installed as ISAPI on IIS5. Rather, when you stop
the IIS service and then start it again, for a period of time, the
correct time is displayed using echo date("D M j G:i:s T Y");

However, after a period of time passes (say an hour or so on a server
averaging a few users at a time), the time switches to UTC and does not
go back.

If you stop IIS and then start it again, the time goes back to the
correct time and the cycle starts again.

Note that this is using ISAPI on IIS5 on Windows 2000 Server. I been
trying PHP in ISAPI and CGI mode on a Windows 2000 workstation because
I've been having trouble getting the Windows 2000 Server, which uses
PHP ISAPI just fine, to run PHP in CGI mode. It should be as easy as
setting cgi.force_redirect = 0 and changing the app mapping
configuration to point to the php.exe and not the php4isapi.dll but I'm
not having any luck (get "not authorized to view this page" on php
scripts). This method works fine on the Win2K workstation. Anyway, this
is not related to the UTC time issue...



[2003-10-13 12:14:05] [EMAIL PROTECTED]

Do you get the same problem running CGI?




[2003-10-13 09:52:27] pennington at rhodes dot edu

[EMAIL PROTECTED] wanted to know "Which SAPI are you running? CGI? ISAPI?
Apache? Something else?"

I'm running ISAPI.

I fail to see how this bug is identical to bug #23467, because I am
getting an incorrect offset of time from GMT in addition to the
incorrect time zone appearing. Unless, of course, time in general is
screwed up for PHP on Win32...



[2003-10-12 19:46:15] [EMAIL PROTECTED]

This is not different to bug #23467




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

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


#25828 [Fbk->Csd]: enormus time get result from fgets via fsocketopen

2003-10-14 Thread scouture at novo dot ca
 ID:   25828
 User updated by:  scouture at novo dot ca
 Reported By:  scouture at novo dot ca
-Status:   Feedback
+Status:   Closed
 Bug Type: Performance problem
 Operating System: win2000
 PHP Version:  4.3.3
 New Comment:

I've changed my function using stream_select and fread instead and it
works fine.

So was more a coding problem than a bug finaly.

Sorry for your time and thanks for your help


Previous Comments:


[2003-10-10 17:09:26] [EMAIL PROTECTED]

Also, you really should not use stream_get_meta_data() and the
unread_bytes value to drive your scripts.



[2003-10-10 17:02:52] [EMAIL PROTECTED]

Does the returned data include a newline?

If not you should be using fread().
OR, you can use stream_select(),
OR you can use stream_set_timeout() to reduce the default
timeout from 60 seconds to something more appropriate to your
application.



[2003-10-10 16:01:34] scouture at novo dot ca

Description:

I was using php 4.2.2 before updating to 4.3.3.
I have to talk to another application server using socket.
With 4.2.2, i had my response in less than a second but it take me
about 60 sec with php 4.3.3



Reproduce code:
---
function getFromSocket($message){
  set_time_limit (0);   
$res = @fsockopen ("192.168.10.5", "3734", $errno, $errstr,30);
if(!$res)   {   
exit; //some eror...
}
else{   
fputs($res, $message);   
//samething, reponding server end the response by SCKEND
// while (substr_count($buff, "SCKEND")!= 1) 
   while ($bytes != "0"){  
  $buff .= fgets($res,4096);
  //$array_statusSocket = socket_get_status($res); //for 4.2.2
  $array_statusSocket = stream_get_meta_data($res); 
  $bytes = $array_statusSocket["unread_bytes"];  
}
fclose ($res);
}
return $buff;
}
function getMicrotime(){
list($usec, $sec) = explode(" ",microtime());
return ((float)$usec + (float)$sec);
}
$time_requete = getMicrotime();
$str_resultatSocket =
getFromSocket("LOG|novojustice|justicenovo|intranet||SCKEND");
$time_requete2 = getMicrotime();
echo $time_requete2-$time_requete ." time";
exit;

Expected result:

have the result more quickly

Actual result:
--
took about 60sec..





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


#25864 [Opn->Bgs]: sprintf error

2003-10-14 Thread tony2001
 ID:   25864
 Updated by:   [EMAIL PROTECTED]
 Reported By:  heppevonhambach at web dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: linux
 PHP Version:  Irrelevant
 New Comment:

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

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


Previous Comments:


[2003-10-14 10:01:43] tony2001 at phpclub dot net

pay attention:
var_dump($n); will output float(1234567890120).
i.e. your integer were automagically converted to float.
so you need to use:
$s = sprintf( "%0{$nL}.0f",$n );
to get expected result.

look here for more info:
http://www.php.net/manual/en/language.types.integer.php



[2003-10-14 09:14:13] heppevonhambach at web dot de

Description:

looks like sprintf has problems with big numbers 


Reproduce code:
---
$n = 1234567890123;
$nL = 17;
$s = sprintf( "%0{$nL}d",$n );


Expected result:

1234567890123

Actual result:
--
0001912276171





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


#25864 [Com]: sprintf error

2003-10-14 Thread tony2001 at phpclub dot net
 ID:   25864
 Comment by:   tony2001 at phpclub dot net
 Reported By:  heppevonhambach at web dot de
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: linux
 PHP Version:  Irrelevant
 New Comment:

pay attention:
var_dump($n); will output float(1234567890120).
i.e. your integer were automagically converted to float.
so you need to use:
$s = sprintf( "%0{$nL}.0f",$n );
to get expected result.

look here for more info:
http://www.php.net/manual/en/language.types.integer.php


Previous Comments:


[2003-10-14 09:14:13] heppevonhambach at web dot de

Description:

looks like sprintf has problems with big numbers 


Reproduce code:
---
$n = 1234567890123;
$nL = 17;
$s = sprintf( "%0{$nL}d",$n );


Expected result:

1234567890123

Actual result:
--
0001912276171





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


#25864 [NEW]: sprintf error

2003-10-14 Thread heppevonhambach at web dot de
From: heppevonhambach at web dot de
Operating system: linux
PHP version:  Irrelevant
PHP Bug Type: Unknown/Other Function
Bug description:  sprintf error

Description:

looks like sprintf has problems with big numbers 


Reproduce code:
---
$n = 1234567890123;
$nL = 17;
$s = sprintf( "%0{$nL}d",$n );


Expected result:

1234567890123

Actual result:
--
0001912276171

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


#25860 [Opn->Fbk]: php stops working with extension=php_oci8.dll enabled

2003-10-14 Thread sniper
 ID:   25860
 Updated by:   [EMAIL PROTECTED]
 Reported By:  cchrist at csas dot cz
-Status:   Open
+Status:   Feedback
 Bug Type: OCI8 related
 Operating System: Windows 2000 Server
 PHP Version:  4.3.3
 New Comment:

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.



Previous Comments:


[2003-10-14 08:05:58] cchrist at csas dot cz

Description:

I don't know, how this is possible, but I have the following error on
my production environment (W2K Server, IIS 5.0, MSSQL Server 2000 SP3,
PHP 4.3.3, Oracle client 9.2.1)

The working config is: gd and mssql. This works without problems. But
we have also scripts, accessing an oracle database via OCI. When the
extension extension=php_oci8.dll
is enabled, after a few hours, PHP stops producing output and after a
timeout the process is terminated by IIS.

Does anybody know a cure for that behaviour?

This seems to be known already in PHP Version 4.0.4 (see
http://bugs.php.net/bug.php?id=7575&edit=2)

kind regards
Christoph Christ






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


#25861 [Opn->Bgs]: bug in php 4.2

2003-10-14 Thread sniper
 ID:   25861
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kailash at sarksoft dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: redhat 9.0
 PHP Version:  4.3.1
 New Comment:

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

PHP 4.3.3 is the latest release.



Previous Comments:


[2003-10-14 08:21:39] kailash at sarksoft dot com

Description:

I am using register_shutdown_function which is not working under
php-4.2.2-17
httpd-2.0.40-21
Redhat 9.0


The function does not getting called at all. Also there are no errors
reported in  error_log as specified in php manual.


Apparently the php script seems to working on
mod_php4-4.3.1-24
apache-1.3.27-38
Suse 8.2
Here there is a error in error_log as per php manual
PHP Fatal error:  Unknown(): Unable to open testDW.php in Unknown on
line 0


This is the code I am using to check for download from broswer

#test.php



#testDW.php









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


#25863 [NEW]: The specified CGI application misbehaved ...

2003-10-14 Thread salmanarshad2000 at yahoo dot com
From: salmanarshad2000 at yahoo dot com
Operating system: Windows XP, 2000
PHP version:  4.3.3
PHP Bug Type: IIS related
Bug description:  The specified CGI application misbehaved ...

Description:

This bug or issue has been around for quite a while and seems like nobody
cares. The bug list is filled with hundreds of complains about the "The
specified CGI application misbehaved ..." error each time these people
have BOGUSed or CLOSEd saying things like "The version you are using is
too old, please try the latest version ...", "This is not a php bug,
please go to ...", "Not enough evidence ..." or "Problem with Windows, not
PHP". Quite a few versions of php have been released in the meanwhile, but
this issue hasn't been fixed, people who upgrade their php installation
come back with the same complains. I see no good reason for this
ignorance.

Problem Statement
-
When browsing a php application, the IIS server randomly throws the error
message:

CGI Error
The specified CGI application misbehaved by not returning a complete set
of HTTP headers. The headers it did return are:


Observations

This happened only when:
- PHP.exe is used as a CGI on IIS 
- The php scripts contained 2 or more frames (e.g. phpMyAdmin)
- MySQL operation was executed (update, insert, delete etc.)
- header("Location: ...") is used to redirect user after a MySQL operation
to a page that also performs a MySQL operation
- The pages are viewed from local computer
- A very fast computer is used

This did not happened when:
- Apache server for windows with php support was used
- The php scripts contained 2 or more frames but all frames contained php
scripts with Hello World and a random number
- Frequency of errors was much lesser when same pages were accessed from
the network
- Pentium 2, 300 MHz was used (a slow computer)

History
---
Following bugs are all related to this problem. This is just a reminder
for the fact that this issue has been discussed quite a few times and it
is still present. People also found these interesting things that might
help to get the problem solved.

- BugID #25567 getting errors when doing a mysql_db_query() and then
header("location")
- BugID #24916 header("location")
- BugID #23208 using two or more frames
- BugID #19381 no details :(
- BugID #19676 works on one (slow) system but does not work on other
- BugID #18901 header("location") after delete or update, error occurs
under under load
- BugID #16313 header("location") and db operations
- BugID #23050 mysql_query() followed by header("location")
- BugID #17468 header("location")
- BugID #9852  thousands of lines describing the problem, including
frames, manually slowing down the script, pages work from outside the
machine nut not locally, two database connections in rapid succession etc

Things that have been said earlier
--
"This is a problem with Microsoft OS"
No this is not, it works on exact same OS running on slower hardware or
when the application is accessed across a network. And even if it is, the
developers should try to find a work around instead of blaming M$ and
telling it to fix it. After all, when you develop some app for an
environment, you don't change the environment to suit your app (although
sometimes it is easier to do so).

"This is not a php bug"
Well this could be right, since there is one other suspect, MySQL. But
somebody please figure out where the problem is? Also, MySQL is now an
integral part of php so problem could lie in the integration part.

My Opinion
---
May be php.exe is not fast enough to keep up with the pace at which IIS
can throw requests at it. Or ... may be it is a problem with the MySQL
connections ... attempting to create connections too quickly may be the
cause. Users having same problem please feel free to contribute with their
observations and suggestions.


-- 
Edit bug report at http://bugs.php.net/?id=25863&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25863&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25863&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25863&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25863&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25863&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25863&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25863&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25863&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25863&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25863&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25863&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25863&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25863&r=dst

#25862 [NEW]: mail() always return FALSE

2003-10-14 Thread thouraud at bondy dot ird dot fr
From: thouraud at bondy dot ird dot fr
Operating system: solaris 9
PHP version:  4.3.3
PHP Bug Type: Mail related
Bug description:  mail() always return FALSE

Description:

The mail() function always return FALSE.
Even if the mail is sent !

Test with the sun's sendmail and postfix 2.0.16.
The mail can go out with no problem.

The result get the same safe_mode or not.

apache 1.3.28 with php as a module

Reproduce code:
---
" ;
  if ($ret) {
print 'OK' ;
  } else {
print 'KO' ;
  }

?>


Expected result:

if we can send mail to [EMAIL PROTECTED]
then OK and [EMAIL PROTECTED] receive the mail.


if any error to sent mail 
then KO and no mail !

Actual result:
--
always KO

but the mail are been received !

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


#25861 [NEW]: bug in php 4.2

2003-10-14 Thread kailash at sarksoft dot com
From: kailash at sarksoft dot com
Operating system: redhat 9.0
PHP version:  4.3.1
PHP Bug Type: Scripting Engine problem
Bug description:  bug in  php 4.2

Description:

I am using register_shutdown_function which is not working under
php-4.2.2-17
httpd-2.0.40-21
Redhat 9.0


The function does not getting called at all. Also there are no errors
reported in  error_log as specified in php manual.


Apparently the php script seems to working on
mod_php4-4.3.1-24
apache-1.3.27-38
Suse 8.2
Here there is a error in error_log as per php manual
PHP Fatal error:  Unknown(): Unable to open testDW.php in Unknown on line
0


This is the code I am using to check for download from broswer

#test.php



#testDW.php





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


#25860 [NEW]: php stops working with extension=php_oci8.dll enabled

2003-10-14 Thread cchrist at csas dot cz
From: cchrist at csas dot cz
Operating system: Windows 2000 Server
PHP version:  4.3.3
PHP Bug Type: OCI8 related
Bug description:  php stops working with extension=php_oci8.dll   enabled

Description:

I don't know, how this is possible, but I have the following error on my
production environment (W2K Server, IIS 5.0, MSSQL Server 2000 SP3, PHP
4.3.3, Oracle client 9.2.1)

The working config is: gd and mssql. This works without problems. But we
have also scripts, accessing an oracle database via OCI. When the
extension extension=php_oci8.dll
is enabled, after a few hours, PHP stops producing output and after a
timeout the process is terminated by IIS.

Does anybody know a cure for that behaviour?

This seems to be known already in PHP Version 4.0.4 (see
http://bugs.php.net/bug.php?id=7575&edit=2)

kind regards
Christoph Christ


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


#24687 [Opn->WFx]: Fatal error: Only variables or references can be returned by reference

2003-10-14 Thread sniper
 ID:   24687
 Updated by:   [EMAIL PROTECTED]
 Reported By:  nologic at pchome dot com dot tw
-Status:   Open
+Status:   Wont fix
 Bug Type: Zend Engine 2 problem
 Operating System: *
 PHP Version:  5CVS
 New Comment:

Fix your scripts.



Previous Comments:


[2003-08-16 04:14:19] jan at horde dot org

Any idea yet if this will be fixed/addressed or should we start
converting scripts to not use referenced return type or build variables
that get returned?



[2003-07-24 03:16:39] mikkel at linet dot dk

I have the same problem with PHP5 snap 200307240730, PEAR DB will not
work, as many functions has "&" in front of them. So a "return new
DB_Result" does not work.

Mayby this should only be a "notice" instead of a "fatal" error.



[2003-07-22 11:53:29] [EMAIL PROTECTED]

Yes, it is quite complicated.  You can only return variables by
reference, a function's return value is not something we can 'connect'
to...



[2003-07-17 03:35:38] [EMAIL PROTECTED]

If you do it like this it works:

class TextSanitizer
{
 function &htmlSpecialChars($text) {
  $foo = preg_replace("/&/i", '&', htmlspecialchars($text,
ENT_QUOTES));
  return $foo;
 }
}

So would it really be *that* hard to make it work?



[2003-07-17 03:23:15] [EMAIL PROTECTED]

It never really worked (caused memory corruption).
Unlikely to be changed, since it doesn't make sense, but we'll see.



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

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


#15209 [Com]: Under Apache, register_shutdown_function() broke between 4.0.x to 4.1.x

2003-10-14 Thread kailash at sarksoft dot com
 ID:   15209
 Comment by:   kailash at sarksoft dot com
 Reported By:  priebe at mi-corporation dot com
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: RH Linux 7.3
 PHP Version:  4.1.x-4.3.0
 New Comment:

There is a bug for register_shutdown_function httpd-2.0.40-21 and
php-4.2.2-17 under redhat 9.0

It seems to be working fine with php-4.3 and apache 1.3 under suse 8.2


Previous Comments:


[2003-02-24 02:53:46] [EMAIL PROTECTED]

Closing as bogus.
If we ever support this kind of behavior, it won't be a part of
register_shutdown_function().
If there was a working patch for apache_register_shutdown_function(), I
missed it - please resend.



[2002-12-30 11:26:27] [EMAIL PROTECTED]

The functionality for register_shutdown_function under 4.0.x will be
replaced with a function named apache_register_shutdown_function.  This
should be available under 4.3.1 and later versions of PHP.  I will
close this bug when the patch has been committed.



[2002-12-27 10:52:01] [EMAIL PROTECTED]

I created a patch to add this functionality back under mod_php4
systems.  This patch was posted to the php-dev list yesterday.  Check
out the list archives.  An improved patch will be posted later today.



[2002-12-23 11:25:38] brianm-php at dealnews dot com

The following script will cause IE to stop loading the page when
zlib.output_compression is used.  This was not true before the changes
to register_shutdown_function as the output was not sent.

You can see a test at http://dealnews.com/zlibshutdown.php.  Mozilla
gracefully handles the mixed output by truncating the non-compressed
data.









This is in the HTML body.








[2002-12-12 11:37:31] [EMAIL PROTECTED]

I gave up on my patch.  Too much work, not enought time, and
ultimately, I couldn't find a place in PHP land where PHP was still
running and Apache had closed the connection to put my hooks in.  There
may be a way to tell Apache to close the connection through SAPI, but I
am not aware of it.  (I'm not an apache hacker).  Someone posted a way
to fork a process to the background, but it isn't a PHP land solution.

>From Carsten Gehling:
Maybe this is what you need?

http://www.naken.cc/mikehup.php

I use this on a CMS site, where the users upload imagefiles with ftp.
After
that, they use a php webinterface to start an importscript (written in
Perl). By doing this command in php:

system("/usr/local/bin/mikehup /usr/bin/perl
/www/servers/netlag/cronscripts/import_billede.pl &");

The importscript is started and executes in the background while the
php-script finishes execution.

Hope that helps

- Carsten



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

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


#18670 [Com]: strtotime() bug

2003-10-14 Thread sergio at wgo dot com dot br
 ID:   18670
 Comment by:   sergio at wgo dot com dot br
 Reported By:  nic at bbmcarlson dot com
 Status:   Open
 Bug Type: Date/time related
 Operating System: Linux
 PHP Version:  4.3.3RC5-dev
 New Comment:

I have a problem to use StrToTime with the date 2003-10-12. Its return
-1.

I'm using the version PHP 4.3.2

";
Echo Date( 'd-m-Y', StrToTime( $data11 ) )."";
Echo StrToTime( $data11 )."";

Echo Date( 'd-m-Y', StrToTime( $data20 ) )." ** on my server, display
'31-12-1969'...BUG or What ? ";
Echo Date( 'd-m-Y', StrToTime( $data21 ) )." ** on my server, display
'31-12-1969'...BUG or What ? ";
Echo StrToTime( $data21 )." display -1 ";

Echo Date( 'd-m-Y', StrToTime( $data30 ) )."";
Echo Date( 'd-m-Y', StrToTime( $data31 ) )."";
Echo StrToTime( $data31 )."";

?>


Previous Comments:


[2003-02-11 14:12:37] mphillips at lufkin dot org

I have noticed that when you do something like
$sdate = date9'Y-m-d', strtotime('02-09-2003'));

$sdate is getting '2008-02-24'.

Is this a common occurance



[2002-10-31 12:07:20] matt at codewalkers dot com

I also can confirm that strtotime acts funny when the same day does not
exist in the next month:



displays:

December



[2002-09-24 17:07:42] spud at nothingness dot org

In PHP 4.2.3, the difference between "2" and "next" are still screwy in
strtotime(). I'm trying to parse icalendar recurrence formats, so I
need to calculate things like the "second Monday" in a month. Sample
code below illustrates the difference between "2" and "next" (which
should be identical).

');
echo ('Start date: Sunday, Sep 1 2002');
$first = strtotime('first Monday',$start);
echo ('"First" Monday: '.date('l, M d Y',$first).'');
$oneth = strtotime('1 Monday',$start);
echo ('"1" Monday: '.date('l, M d Y',$oneth).'');
$next = strtotime('next Monday',$start);
echo ('"Next" Monday: '.date('l, M d Y',$next).'');
$twoth = strtotime('2 Monday',$start);
echo ('"2" Monday: '.date('l, M d Y',$twoth).'');
$third = strtotime('third Monday',$start);
echo ('"Third" Monday: '.date('l, M d Y',$third).'');
$threeth = strtotime('3 Monday',$start);
echo ('"3" Monday: '.date('l, M d Y',$threeth).'');
?>



[2002-07-31 18:07:05] [EMAIL PROTECTED]

Assigning to rasmus as it sounds like he already knows whats wrong.



[2002-07-31 10:51:09] [EMAIL PROTECTED]

so can we assign this bug to you Rasmus?



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

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


#25852 [Csd->Bgs]: gmstrftime - the %T option didn't woks

2003-10-14 Thread eru
 ID:   25852
 Updated by:   [EMAIL PROTECTED]
 Reported By:  willertan1980 at yahoo dot com
-Status:   Closed
+Status:   Bogus
 Bug Type: Date/time related
 Operating System: WinXP sp1
 PHP Version:  4.3.3
 New Comment:

That's why the status was set to "bogus" :)
Please leave it on this.



Previous Comments:


[2003-10-14 05:51:03] willertan1980 at yahoo dot com

thank , now i knew it. may i know how to delete this false report?. i
think it is useless to make this bug report



[2003-10-13 19:15:40] [EMAIL PROTECTED]

RTFM: "Note:  Not all conversion specifiers may be supported by your C
library, in which case they will not be supported by PHP's
strftime()...e.g. %e, %T, %R and %D (there might be more) and dates
prior to Jan 1, 1970 will not work on Windows"
 



[2003-10-13 13:09:51] willertan1980 at yahoo dot com

Description:

im not sure , this is a bug or not. 
Im WinXP user, works on IIS with PHP 4.3.3
and i found that 

echo gmstrftime('%Y %b %d %T ');

will out put 2003 Oct 13 and 

echo gmstrftime('%Y %b %d %H:%M:%S');

the output is 2003 Oct 13 16:20:03

the %T is missing...

%T - current time, equal to %H:%M:%S


this also happen to strftime







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


#25859 [Opn->Bgs]: php.exe consumes 100% cpu

2003-10-14 Thread mboeren
 ID:   25859
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mfelden at gsd-web dot de
-Status:   Open
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: windows 2000 server
 PHP Version:  4.3.2
 New Comment:

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

I'm assuming the select query gets a lot of data: since dbx_query
retrieves and buffers all data this could lead to a very long execution
time.
If this is not the case, please re-open this bug report.
Otherwise, read on:

First: alter your sql statement to only retrieve fields you actually
need, such as 'field' and 'id'. Don't use * in a select statement.

Second: your query() function is not very efficient: it would be much
better to put the dbx_connect() and dbx_close() calls outside the
function, preferably at the beginning and end of the script or perhaps
the get_data() function. And when you do that you might as well skip
the query() function definition altogether :-)

If you are retrieving a lot of records, the new version of dbx_query()
(in CVS only) has support for the DBX_RESULT_UNBUFFERED flag where you
can retrieve data record by record, which is probably what you want as
it is a lot more efficient.

If you are unable to get the CVS version, perhaps you should use the
mysql_unbuffered_query() directly...



Previous Comments:


[2003-10-14 06:00:28] mfelden at gsd-web dot de

Description:

PHP is running on the local http-server IIS. A script loaded in IE 5
causes a new instance of php.exe running on the server. It instantly
consumes 100% of the cpu power. This blocks the server, so the query
could not be completed. The IIS sends a Timeout after 30 seconds. I
can't change it, due to the MMC which says, there is no IIS. Even after
closing the IE-Window php.exe is consuming 100% of the cpu power for
the next say 5 minutes. During this php.exe dis- and appears in the
process list again and again. In php.ini php_iisfunc.dll is commented
out.

It is no fun.

Reproduce code:
---
Import
Daten holen

  

590 and
id<691";
$result = query($query, $source);

for($i = 0; $i < $result->rows; $i++)
{
$query = "UPDATE corpus SET strasse ='" .
$result->data[$i]['field'] . "' WHERE id = " .
$result->data[$i]['id'];
query($query);
}   
}
}
function query($query)
{
  $link = dbx_connect (DBX_MSSQL, "1.2.3.4", "db", "user", "pwd",
DBX_PERSISTENT| DBX_RESULT_INFO) or die ("Fehler beim Verbinden");  
  $result = dbx_query($link, $query);
  dbx_close ($link);
  return $result;
}
?>


Expected result:

Query completed

Actual result:
--
Timeout after 30 sec





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


#25859 [NEW]: php.exe consumes 100% cpu

2003-10-14 Thread mfelden at gsd-web dot de
From: mfelden at gsd-web dot de
Operating system: windows 2000 server
PHP version:  4.3.2
PHP Bug Type: *General Issues
Bug description:  php.exe consumes 100% cpu

Description:

PHP is running on the local http-server IIS. A script loaded in IE 5
causes a new instance of php.exe running on the server. It instantly
consumes 100% of the cpu power. This blocks the server, so the query could
not be completed. The IIS sends a Timeout after 30 seconds. I can't change
it, due to the MMC which says, there is no IIS. Even after closing the
IE-Window php.exe is consuming 100% of the cpu power for the next say 5
minutes. During this php.exe dis- and appears in the process list again
and again. In php.ini php_iisfunc.dll is commented out.

It is no fun.

Reproduce code:
---
Import
Daten holen

  

590 and
id<691";
$result = query($query, $source);

for($i = 0; $i < $result->rows; $i++)
{
$query = "UPDATE corpus SET strasse ='" . $result->data[$i]['field'] .
"' WHERE id = " . $result->data[$i]['id'];
query($query);
}   
}
}
function query($query)
{
  $link = dbx_connect (DBX_MSSQL, "1.2.3.4", "db", "user", "pwd",
DBX_PERSISTENT| DBX_RESULT_INFO) or die ("Fehler beim Verbinden");  
  $result = dbx_query($link, $query);
  dbx_close ($link);
  return $result;
}
?>


Expected result:

Query completed

Actual result:
--
Timeout after 30 sec

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


#25852 [Bgs->Csd]: gmstrftime - the %T option didn't woks

2003-10-14 Thread willertan1980 at yahoo dot com
 ID:   25852
 User updated by:  willertan1980 at yahoo dot com
 Reported By:  willertan1980 at yahoo dot com
-Status:   Bogus
+Status:   Closed
 Bug Type: Date/time related
 Operating System: WinXP sp1
 PHP Version:  4.3.3
 New Comment:

thank , now i knew it. may i know how to delete this false report?. i
think it is useless to make this bug report


Previous Comments:


[2003-10-13 19:15:40] [EMAIL PROTECTED]

RTFM: "Note:  Not all conversion specifiers may be supported by your C
library, in which case they will not be supported by PHP's
strftime()...e.g. %e, %T, %R and %D (there might be more) and dates
prior to Jan 1, 1970 will not work on Windows"
 



[2003-10-13 13:09:51] willertan1980 at yahoo dot com

Description:

im not sure , this is a bug or not. 
Im WinXP user, works on IIS with PHP 4.3.3
and i found that 

echo gmstrftime('%Y %b %d %T ');

will out put 2003 Oct 13 and 

echo gmstrftime('%Y %b %d %H:%M:%S');

the output is 2003 Oct 13 16:20:03

the %T is missing...

%T - current time, equal to %H:%M:%S


this also happen to strftime







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


#25850 [Com]: SWITCH

2003-10-14 Thread tony2001 at phpclub dot net
 ID:   25850
 Comment by:   tony2001 at phpclub dot net
 Reported By:  jakespotgieter at hotmail dot com
 Status:   Bogus
 Bug Type: Zend Engine 2 problem
 Operating System: Windows
 PHP Version:  5CVS-2003-10-13 (dev)
 New Comment:

I can't find any bug here.
Passing to the script "?method=Bar" in query string and having $i equal
to true it works well under PHP5-CVS.
If you get any errors here - copy/paste it and wrote a letter to
[EMAIL PROTECTED]


Previous Comments:


[2003-10-13 11:58:41] [EMAIL PROTECTED]

The syntax of the header() call is wrong too.




[2003-10-13 08:23:02] jakespotgieter at hotmail dot com

Sorry, I wrote this code quickly, trust me its got nothing to do with a
parse error. It doesnt work on the Zend engine 2. I ported it back to
4.3, and it worked. I didnt change anything in the code.

SWITCH ($_GET['method']){
  CASE 'Foo':
 //do something
  BREAK;
CASE 'Bar':
 if($i == true){
header("location:?method=Foo");
 }else{
  //do something else  
 }
  BREAK;
}



[2003-10-13 07:55:12] [EMAIL PROTECTED]

Not a bug, but wrong syntax.



[2003-10-13 07:42:27] [EMAIL PROTECTED]

There is parse error in your code:
you forgot to add semicolon at the end of line with Header().
This code cannot be parsed correctly neither under PHP5CVS, nor
PHP4.3.3.
Having this error fixed, code works ok (but complies on undefined
variables).
So, this is problem of your code.



[2003-10-13 07:25:43] jakespotgieter at hotmail dot com

Description:

When there are multiple cases within a switch block, if you try to use
the header function, more specifically header("location:$url") it
doesn't work. When I ran the same code under 4.3.3 it worked.

Reproduce code:
---
SWITCH ($_GET['method']){
  CASE 'Foo':
 //do something
  BREAK;
CASE 'Bar':
 if($i == true){
header("location:?method=Foo")
 }else{
  //do something else  
 }
  BREAK;
}






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


#22459 [Com]: Fatal error: session_start() [function.session-start]

2003-10-14 Thread mikael at chl dot chalmers dot se
 ID:   22459
 Comment by:   mikael at chl dot chalmers dot se
 Reported By:  froeschlin at designpark dot de
 Status:   Bogus
 Bug Type: Session related
 Operating System: Red-Hat/Linux
 PHP Version:  4.3.3
 New Comment:

Have the same problem, tried using both files and mm for storage
handler, changing all the session settings etc. Have had the problem
through php4.3.2 -> 4.3.4RC1 with the same results, php randomly
outputting these errors on perhaps every 1/4 of the session inits.

config: http://www.geckominus.com/phpinfo.php


Previous Comments:


[2003-08-28 19:40:48] [EMAIL PROTECTED]

That url says 'PHP 4.2.2', please upgrade to 4.3.3 first.




[2003-02-27 09:48:18] froeschlin at designpark dot de

We have remove the Optimizer but after 2-3 hours the error come again.



[2003-02-27 08:48:57] [EMAIL PROTECTED]

Turn off Zend Optimizer v2.1.0 and see if the problem persists.



[2003-02-27 08:33:48] froeschlin at designpark dot de

When we use session_start() we get a random coming error on our system
who give us out the folloing massage:

Fatal error: session_start() [function.session-start]: Failed to
initialize session module 

Sometimes the error dont come over days. 
We cant recognize why and how it develops.
Also the compiling of php are error less.

Our config -> http://217.175.242.77/phpinfo.php




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


#21676 [Com]: GetImageSize nolonger works

2003-10-14 Thread hex6ng at yahoo dot com
 ID:   21676
 Comment by:   hex6ng at yahoo dot com
 Reported By:  moderator at blackpeeps dot com
 Status:   Closed
 Bug Type: GetImageSize related
 Operating System: RAQ4-Latest Patches/Apache 1.3.2
 PHP Version:  4.3.0
 New Comment:

I'm experiencing the same problem after I upgraded php from version
4.2.4-CVS (php4-STABLE-20030230) to 4.3.3 Release. The reason I
upgraded was because 4.3.3 fixes the PATH_INFO bug that I had.
But..A whole bunch of my thumbnails stopped showing up. The really
odd thing is I'm using Imagick instead of GD. But I'm also using
getimagesize(). I changed my function to use ALL three methods of
retrieving the size, but ALL return null size for these images.
http://filegrid.net/index.html?meta_id=5ca930302a942ef8906a6a80855856af

here is the function I use to get the size
function file_image_size($meta_id)
{
$file_obj = file_object($meta_id);
if(!$file_obj) return NULL;
$image_size = getimagesize($file_obj->file_location);
if(!$image_size[0])
{
if(!$image_size[0])
{
$handle = imagick_readimage($file_obj->file_location);
if(imagick_iserror( $handle ))
return NULL;
$image_size[0] = imagick_getwidth($handle);
$image_size[1] = imagick_getheight($handle);
//imagick_free($handle);
if(!$image_size[0] && stristr($file_obj->mime_type,
'image/jp'))
{
$img = imagecreatefromjpeg ($filename);
$image_size[0] = imagesx ($img);
$image_size[1] = imagesy ($img);
imagedestroy ($img);
}
}
}

return $image_size;
}


Previous Comments:


[2003-05-12 03:07:57] fmeriot at hotmail dot com

I'have experienced the same problem with the getimagesize() function. I
use it to test the size of a distant image to display on my site. If
width is greater than 500 pix I force the width parameter to 500. This
function works with some images but not with all.

Example:

It works with this one:
http://images.ea.com/eagames/official/bf1942/screenshots_rome/full_screen_21.jpg

It doesn't work with this one:
http://www.dayofdefeatmod.com/media/images/Jagd1.jpg

I have no error message. When I do that:

$size = 
@getimagesize("http://www.dayofdefeatmod.com/media/images/Jagd1.jpg";);
echo $size[0];

Nothing happens, nothing appears.



[2003-04-29 16:10:24] michael dot mauch at gmx dot de

So you have two options:

a) Wait until PHP 4.3.2 is released and installed at your site.
b) Invent a time travel machine and give it to the PHP developers, so
PHP 4.3.0 can be fixed before it was installed at your site.



[2003-04-29 09:23:20] ruud at webhero dot nl

It still doesn't work.
My site still does have problems with @Getimagesize

example:
http://www.gamemag.nl/nieuws/item.php?id=2109

You see three screens, the fourth doesn't work.
All images are from an external website and use the same functions.

I don't have permission to change my PHPversion.

Please help,
Rudy Luiten



[2003-02-22 05:19:09] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

This one has been fixed by fixing a streams issue.



[2003-01-31 13:52:04] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





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

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