date:20050517

#33044 [Opn->Bgs]: My Soap Server programmed by PHP can't get variable $HTTP_RAW_POST_DATA

2005-05-17 Thread sniper

#33039 [Opn->Ver]: on shutdown: Notice: Unknown: Mailbox is empty (errflg=1) in Unknown on line 0

2005-05-17 Thread sniper

 ID:   33039
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mpb dot mail at gmail dot com
-Status:   Open
+Status:   Verified
 Bug Type: IMAP related
 Operating System: *
-PHP Version:  5.*, 4.*
+PHP Version:  4.*, 5.*


Previous Comments:


[2005-05-17 02:10:28] mpb dot mail at gmail dot com

I downloaded:

http://snaps.php.net/php5-STABLE-latest.tar.gz

which was: php5-STABLE-200505161832


$ ./configure --with-imap --with-imap-ssl --disable-cgi
$ make
$ cd sapi/cli
$ ./php ~/test.php

Notice: Unknown: Mailbox is empty (errflg=1) in Unknown on line 0



So... the problem is still there.

$ cat ~/test.php


Please let me know if you would like me to create an empty POP mailbox
for you to test against.

Thanks!



[2005-05-16 09:58:31] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-05-16 08:35:15] mpb dot mail at gmail dot com

Description:

If you imap_open an empty pop mailbox, a "Mailbox is empty (errflg=1)"
notice will be printed during PHP's "shutdown" or "cleanup" phase after
your script has finished running (assuming E_NOTICE is set, of course).

As there is nothing wrong with having an empty mailbox, I believe that
PHP should not print this notice.  I suspect that PHP is
misinterpreting a return code from the IMAP library, or is making an
unnecessary call to the IMAP library.  It is also possible that the
IMAP library is buggy and should not be returning an errflg=1 (whatever
that means).

If, in the reproduce code, you uncomment the final ini_set then the
notice will not be printed (as E_NOTICE is no longer set during PHP's
shutdown).

If you are unable to reproduce this problem with the empty POP mailbox
of your choice, let me know and I will set up a POP mailbox for you to
test against.

See also bug 7207.

Reproduce code:
---
ini_set ('error_reporting', E_ALL);

$imap = imap_open
  ( '{host.com:110/pop/novalidate-cert}INBOX',
'user', 'password' );

trigger_error ('test notice');

sleep (5);

// ini_set ('error_reporting', E_ALL ^ E_NOTICE);


Expected result:

Notice: test notice in /root/pinstall/local/vl0/test.php on line 8


Actual result:
--
Notice: test notice in /root/pinstall/local/vl0/test.php on line 8

Notice: Unknown: Mailbox is empty (errflg=1) in Unknown on line 0






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

#32486 [Opn->Fbk]: odbc_fetch_into returns wrong data

2005-05-17 Thread sniper

 ID:   32486
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tho at e-dict dot net
-Status:   Open
+Status:   Feedback
 Bug Type: Adabas-D related
 Operating System: Linux
 PHP Version:  4.3.9
 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:


[2005-05-11 16:30:24] tho at e-dict dot net

Tried php4-STABLE-200501211130 and still get wrong results. The \0
issue described before could not be reproduced since the field in the
second line was longer then in the first line. But I found out, that in
all cases the \0 issue occoured, there was a date field right before the
string field and this date field contained the data from the previous
line. e.g.
1992-09-09, [EMAIL PROTECTED]
1960-01-09, [EMAIL PROTECTED]
results in
1992-09-09, [EMAIL PROTECTED]
1992-09-09, [EMAIL PROTECTED]



[2005-03-29 17:38:24] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-03-29 16:58:34] tho at e-dict dot net

Description:

Sometimes after odbc_fetch_into($query, $row) $row contains parts of
data from the previous fetched row. For now I'm not able to reproduce
this behavior reliably, it just happens once in a while. 
What happens is that if the data of the previous row is longer than in
the current, the result contains '$currentdata\0$somepreviousdata',
e.g.
previous row: "[EMAIL PROTECTED]"
current row:  "[EMAIL PROTECTED]"
results in
"[EMAIL PROTECTED]"
IOW the field is as long as the data in the previous row, contains a \0
terminator after the field content and then the rest of the previous
field.
This also happens if a unset($row) is done before calling
odbc_fetch_into()

Reproduce code:
---
N/A






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

#32954 [Opn->Fbk]: ifx_fetch_row() : SEGV if row has TEXT fields (PHP Apache Module only)

2005-05-17 Thread sniper

 ID:   32954
 Updated by:   [EMAIL PROTECTED]
 Reported By:  andreybl at matrix dot co dot il
-Status:   Open
+Status:   Feedback
 Bug Type: Informix related
 Operating System: Red Hat 3.0 ES
 PHP Version:  4.3.11
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2005-05-05 12:29:55] andreybl at matrix dot co dot il

Description:

Apache version: 1.3.33
Informix server version: IDS 9.40.UC5
Informix SDK version: csdk_informix.2.90

'./configure' '--with-informix=/isoc/informix'
'--with-config-file-path=/isoc/apache/conf' '--enable-track-vars'
'--with-apache=/isoc/sources/apache' '--without-mysql' 

NOTE: 
The problem occurs in PHP Apache Module ONLY and NOT occurs in PHP
CGI.

Description:
Segmentation Fault in httpd when call to the 
ifx_fetch_row() while among the fields to be selected there is a field
of type TEXT containing NON-NULL data:

- In httpd log file (./apache/logs/error_log): 

[Thu May  5 12:02:10 2005] [notice] child pid 20754 exit signal
Segmentation fault (11)

- In browser: 

"The page cannot be displayed"

Seems my BUG is simillar to #8715, which was closed since there was No
feedback. So probably the problem in #8715 still persists too.

Please, take care of this report as soon as possible, since it is of
Critical severity for me. Actually this stops the whole project.

Thanks,
Andrey





Reproduce code:
---
$trace = fopen('/tmp/php_bug.txt', 'w+');

$conn_id = ifx_connect('DB', 'USER', 'PASS');
if (!$conn_id)
{
echo "FAILED TO CONNECT"; die();
}
fwrite($trace, "after ifx_connect\n"); fflush($trace);

$res_id  = ifx_query('SELECT * FROM registrars where regid = 5',
$conn_id);
if (!$res_id)
{
echo "FAILED TO PREPARE"; echo ifx_getsqlca(); die();
}
fwrite($trace, "after ifx_query\n"); fflush($trace);

$row = ifx_fetch_row($res_id);
fwrite($trace, "after ifx_fetch_row: regid = {$row['regid']}\n");
fflush($trace);

ifx_free_result($res_id);
fwrite($trace, "after ifx_free_result\n"); fflush($trace);

ifx_close($conn_id);
fwrite($trace, "after ifx_close\n"); fflush($trace);

Expected result:

Hm. I expect the httpd not to crash.

Actual result:
--
Here is the backtrace:
Program received signal SIGSEGV, Segmentation fault.
0xb7359e6f in _int_free () from /lib/tls/libc.so.6
(gdb) bt
#0  0xb7359e6f in _int_free () from /lib/tls/libc.so.6
#1  0xb7358e68 in free () from /lib/tls/libc.so.6
#2  0xb7583c3c in ifx_free_sqldata () from
/isoc/informix/lib/esql/libifsql.so
#3  0xb7583a80 in sqli_desc_dealloc () from
/isoc/informix/lib/esql/libifsql.so
#4  0x080b4a14 in zif_ifx_free_result ()
#5  0x080abca6 in execute ()
#6  0x0809fa5b in zend_execute_scripts ()
#7  0x0808193b in php_execute_script ()
#8  0x080aee8e in apache_php_module_main ()
#9  0x0807a772 in ap_get_server_built ()
#10 0x0807a7dc in ap_get_server_built ()
#11 0x0812e6d3 in ap_invoke_handler ()
#12 0x0814356f in ap_some_auth_required ()
#13 0x081435ce in ap_process_request ()
#14 0x0813a731 in ap_child_terminate ()
#15 0x0813a8d1 in ap_child_terminate ()
#16 0x0813aa37 in ap_child_terminate ()
#17 0x0813b0ee in ap_child_terminate ()
#18 0x0813b90c in main ()
(gdb) qui

In the test program above I fetch only one row. If the TEXT field in
the row has NULL value everything's OK and the output in the
php_bug.txt file (see the programm) is the following:

after ifx_connect
after ifx_query
after ifx_fetch_row: regid = 3
after ifx_free_result
after ifx_close

i.e. all the functions returned ok.

If the TEXT field in the row has non-NULL data, then the SEGV occurs
and the output in the php_bug.txt test file is:
after ifx_connect
after ifx_query
after ifx_fetch_row: regid = 11

i.e. ifx_free_result did not return.

NOTE: if the TEXT-type field is not in the list of the filds to be
selected, then everything is OK.






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

#32486 [Fbk]: odbc_fetch_into returns wrong data

2005-05-17 Thread sniper

 ID:   32486
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tho at e-dict dot net
 Status:   Feedback
 Bug Type: Adabas-D related
 Operating System: Linux
 PHP Version:  4.3.9
 New Comment:

(or did you make a typo with the snapshot name?)



Previous Comments:


[2005-05-17 09:10:18] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-05-11 16:30:24] tho at e-dict dot net

Tried php4-STABLE-200501211130 and still get wrong results. The \0
issue described before could not be reproduced since the field in the
second line was longer then in the first line. But I found out, that in
all cases the \0 issue occoured, there was a date field right before the
string field and this date field contained the data from the previous
line. e.g.
1992-09-09, [EMAIL PROTECTED]
1960-01-09, [EMAIL PROTECTED]
results in
1992-09-09, [EMAIL PROTECTED]
1992-09-09, [EMAIL PROTECTED]



[2005-03-29 16:58:34] tho at e-dict dot net

Description:

Sometimes after odbc_fetch_into($query, $row) $row contains parts of
data from the previous fetched row. For now I'm not able to reproduce
this behavior reliably, it just happens once in a while. 
What happens is that if the data of the previous row is longer than in
the current, the result contains '$currentdata\0$somepreviousdata',
e.g.
previous row: "[EMAIL PROTECTED]"
current row:  "[EMAIL PROTECTED]"
results in
"[EMAIL PROTECTED]"
IOW the field is as long as the data in the previous row, contains a \0
terminator after the field content and then the rest of the previous
field.
This also happens if a unset($row) is done before calling
odbc_fetch_into()

Reproduce code:
---
N/A






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

#30215 [Com]: strtotime returning huge timestamps instead of -1

2005-05-17 Thread weecka at stablebeast dot com

 ID:   30215
 Comment by:   weecka at stablebeast dot com
 Reported By:  pmurray at nevada dot net dot nz
 Status:   Assigned
 Bug Type: Date/time related
 Operating System: Linux 64bit - Opteron
 PHP Version:  4.3.10-dev
 Assigned To:  derick
 New Comment:

I get the same bug with PHP 5.0.4
mmOK..


Previous Comments:


[2005-05-11 13:59:52] olivier at oxeva dot fr

I could reproduce this bug on Bi-Xeon; fedora rc3



[2005-02-13 19:48:04] borishim at hotmail dot com

I could reproduce this on 6.0-CURRENT of FreeBSD/amd64 box 
(which is 64bit OS also.)



[2005-02-11 18:18:36] sstillwell at aerostich dot com

PHP Version: 4.3.2-19 (RHEL)
OS: RHEL x86_64
CPU: Dual Intel Xeon 2.8 EM64T

I am getting this same bug as well.

This code
print strtotime(time());

Produces this 
3434798239200

Looks like PHP is not quite ready for 64 bit plateforms at this time.



[2004-09-24 05:21:54] pmurray at nevada dot net dot nz

Description:

When using strtotime(), it returns a bogus timestamp instead of -1.

Gentoo 64bit (Opteron) 2004.2, Glibc 2.3.4, PHP 4.3.8;
strtotime(time()) returns 3396548642400

Gentoo 32bit (Pentium 4) 2004.2, Glibc 2.3.3, PHP 4.3.8 returns -1

FreeBSD 32bit, PHP 4.3.8 and 5.0.1 returns -1

This causes the examples in the date_format modifier page in the Smarty
documentation to fail. IE

{$smarty.now|date_format:"%Y"} 

Could this be related to being on a 64bit platform?

Reproduce code:
---
strtotime(time());



Expected result:

Return -1

Actual result:
--
Return 3396548642400





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

#32954 [Fbk->Opn]: ifx_fetch_row() : SEGV if row has TEXT fields (PHP Apache Module only)

2005-05-17 Thread andreybl at matrix dot co dot il

 ID:   32954
 User updated by:  andreybl at matrix dot co dot il
 Reported By:  andreybl at matrix dot co dot il
-Status:   Feedback
+Status:   Open
 Bug Type: Informix related
 Operating System: Red Hat 3.0 ES
 PHP Version:  4.3.11
 New Comment:

Hi.
You propose me to check with the snapshot of the fifth (5)
version of PHP.
The problem, that I MUST use the fourth (4)


Previous Comments:


[2005-05-17 09:07:23] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-05-05 12:29:55] andreybl at matrix dot co dot il

Description:

Apache version: 1.3.33
Informix server version: IDS 9.40.UC5
Informix SDK version: csdk_informix.2.90

'./configure' '--with-informix=/isoc/informix'
'--with-config-file-path=/isoc/apache/conf' '--enable-track-vars'
'--with-apache=/isoc/sources/apache' '--without-mysql' 

NOTE: 
The problem occurs in PHP Apache Module ONLY and NOT occurs in PHP
CGI.

Description:
Segmentation Fault in httpd when call to the 
ifx_fetch_row() while among the fields to be selected there is a field
of type TEXT containing NON-NULL data:

- In httpd log file (./apache/logs/error_log): 

[Thu May  5 12:02:10 2005] [notice] child pid 20754 exit signal
Segmentation fault (11)

- In browser: 

"The page cannot be displayed"

Seems my BUG is simillar to #8715, which was closed since there was No
feedback. So probably the problem in #8715 still persists too.

Please, take care of this report as soon as possible, since it is of
Critical severity for me. Actually this stops the whole project.

Thanks,
Andrey





Reproduce code:
---
$trace = fopen('/tmp/php_bug.txt', 'w+');

$conn_id = ifx_connect('DB', 'USER', 'PASS');
if (!$conn_id)
{
echo "FAILED TO CONNECT"; die();
}
fwrite($trace, "after ifx_connect\n"); fflush($trace);

$res_id  = ifx_query('SELECT * FROM registrars where regid = 5',
$conn_id);
if (!$res_id)
{
echo "FAILED TO PREPARE"; echo ifx_getsqlca(); die();
}
fwrite($trace, "after ifx_query\n"); fflush($trace);

$row = ifx_fetch_row($res_id);
fwrite($trace, "after ifx_fetch_row: regid = {$row['regid']}\n");
fflush($trace);

ifx_free_result($res_id);
fwrite($trace, "after ifx_free_result\n"); fflush($trace);

ifx_close($conn_id);
fwrite($trace, "after ifx_close\n"); fflush($trace);

Expected result:

Hm. I expect the httpd not to crash.

Actual result:
--
Here is the backtrace:
Program received signal SIGSEGV, Segmentation fault.
0xb7359e6f in _int_free () from /lib/tls/libc.so.6
(gdb) bt
#0  0xb7359e6f in _int_free () from /lib/tls/libc.so.6
#1  0xb7358e68 in free () from /lib/tls/libc.so.6
#2  0xb7583c3c in ifx_free_sqldata () from
/isoc/informix/lib/esql/libifsql.so
#3  0xb7583a80 in sqli_desc_dealloc () from
/isoc/informix/lib/esql/libifsql.so
#4  0x080b4a14 in zif_ifx_free_result ()
#5  0x080abca6 in execute ()
#6  0x0809fa5b in zend_execute_scripts ()
#7  0x0808193b in php_execute_script ()
#8  0x080aee8e in apache_php_module_main ()
#9  0x0807a772 in ap_get_server_built ()
#10 0x0807a7dc in ap_get_server_built ()
#11 0x0812e6d3 in ap_invoke_handler ()
#12 0x0814356f in ap_some_auth_required ()
#13 0x081435ce in ap_process_request ()
#14 0x0813a731 in ap_child_terminate ()
#15 0x0813a8d1 in ap_child_terminate ()
#16 0x0813aa37 in ap_child_terminate ()
#17 0x0813b0ee in ap_child_terminate ()
#18 0x0813b90c in main ()
(gdb) qui

In the test program above I fetch only one row. If the TEXT field in
the row has NULL value everything's OK and the output in the
php_bug.txt file (see the programm) is the following:

after ifx_connect
after ifx_query
after ifx_fetch_row: regid = 3
after ifx_free_result
after ifx_close

i.e. all the functions returned ok.

If the TEXT field in the row has non-NULL data, then the SEGV occurs
and the output in the php_bug.txt test file is:
after ifx_connect
after ifx_query
after ifx_fetch_row: regid = 11

i.e. ifx_free_result did not return.

NOTE: if the TEXT-type field is not in the list of the filds to be
selected, then everything is OK.






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

#32954 [Opn->Fbk]: ifx_fetch_row() : SEGV if row has TEXT fields (PHP Apache Module only)

2005-05-17 Thread sniper

 ID:   32954
 Updated by:   [EMAIL PROTECTED]
 Reported By:  andreybl at matrix dot co dot il
-Status:   Open
+Status:   Feedback
 Bug Type: Informix related
 Operating System: Red Hat 3.0 ES
 PHP Version:  4.3.11
 New Comment:

Yes, but we're focused on PHP 5 now. If you can check it happens with
PHP 5 too, there's much more interest in fixing it and backporting the
fix to PHP 4 too.



Previous Comments:


[2005-05-17 10:23:14] andreybl at matrix dot co dot il

Hi.
You propose me to check with the snapshot of the fifth (5)
version of PHP.
The problem, that I MUST use the fourth (4)



[2005-05-17 09:07:23] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-05-05 12:29:55] andreybl at matrix dot co dot il

Description:

Apache version: 1.3.33
Informix server version: IDS 9.40.UC5
Informix SDK version: csdk_informix.2.90

'./configure' '--with-informix=/isoc/informix'
'--with-config-file-path=/isoc/apache/conf' '--enable-track-vars'
'--with-apache=/isoc/sources/apache' '--without-mysql' 

NOTE: 
The problem occurs in PHP Apache Module ONLY and NOT occurs in PHP
CGI.

Description:
Segmentation Fault in httpd when call to the 
ifx_fetch_row() while among the fields to be selected there is a field
of type TEXT containing NON-NULL data:

- In httpd log file (./apache/logs/error_log): 

[Thu May  5 12:02:10 2005] [notice] child pid 20754 exit signal
Segmentation fault (11)

- In browser: 

"The page cannot be displayed"

Seems my BUG is simillar to #8715, which was closed since there was No
feedback. So probably the problem in #8715 still persists too.

Please, take care of this report as soon as possible, since it is of
Critical severity for me. Actually this stops the whole project.

Thanks,
Andrey





Reproduce code:
---
$trace = fopen('/tmp/php_bug.txt', 'w+');

$conn_id = ifx_connect('DB', 'USER', 'PASS');
if (!$conn_id)
{
echo "FAILED TO CONNECT"; die();
}
fwrite($trace, "after ifx_connect\n"); fflush($trace);

$res_id  = ifx_query('SELECT * FROM registrars where regid = 5',
$conn_id);
if (!$res_id)
{
echo "FAILED TO PREPARE"; echo ifx_getsqlca(); die();
}
fwrite($trace, "after ifx_query\n"); fflush($trace);

$row = ifx_fetch_row($res_id);
fwrite($trace, "after ifx_fetch_row: regid = {$row['regid']}\n");
fflush($trace);

ifx_free_result($res_id);
fwrite($trace, "after ifx_free_result\n"); fflush($trace);

ifx_close($conn_id);
fwrite($trace, "after ifx_close\n"); fflush($trace);

Expected result:

Hm. I expect the httpd not to crash.

Actual result:
--
Here is the backtrace:
Program received signal SIGSEGV, Segmentation fault.
0xb7359e6f in _int_free () from /lib/tls/libc.so.6
(gdb) bt
#0  0xb7359e6f in _int_free () from /lib/tls/libc.so.6
#1  0xb7358e68 in free () from /lib/tls/libc.so.6
#2  0xb7583c3c in ifx_free_sqldata () from
/isoc/informix/lib/esql/libifsql.so
#3  0xb7583a80 in sqli_desc_dealloc () from
/isoc/informix/lib/esql/libifsql.so
#4  0x080b4a14 in zif_ifx_free_result ()
#5  0x080abca6 in execute ()
#6  0x0809fa5b in zend_execute_scripts ()
#7  0x0808193b in php_execute_script ()
#8  0x080aee8e in apache_php_module_main ()
#9  0x0807a772 in ap_get_server_built ()
#10 0x0807a7dc in ap_get_server_built ()
#11 0x0812e6d3 in ap_invoke_handler ()
#12 0x0814356f in ap_some_auth_required ()
#13 0x081435ce in ap_process_request ()
#14 0x0813a731 in ap_child_terminate ()
#15 0x0813a8d1 in ap_child_terminate ()
#16 0x0813aa37 in ap_child_terminate ()
#17 0x0813b0ee in ap_child_terminate ()
#18 0x0813b90c in main ()
(gdb) qui

In the test program above I fetch only one row. If the TEXT field in
the row has NULL value everything's OK and the output in the
php_bug.txt file (see the programm) is the following:

after ifx_connect
after ifx_query
after ifx_fetch_row: regid = 3
after ifx_free_result
after ifx_close

i.e. all the functions returned ok.

If the TEXT field in the row has non-NULL data, then the SEGV occurs
and the output in the php_bug.txt test file is:
after ifx_connect
after ifx_query
after ifx_fetch_row: regid = 11

i.e. ifx_free_result did not return.

NOTE: if the TEXT-type field is not in the list of the filds to be
selected, then everything is OK.






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

#32722 [Opn->Bgs]: OCINewCollection hang after parse error.

2005-05-17 Thread sniper

 ID:   32722
 Updated by:   [EMAIL PROTECTED]
 Reported By:  fsurleau at skyservices dot net
-Status:   Open
+Status:   Bogus
 Bug Type: OCI8 related
 Operating System: linux
 PHP Version:  4.3.11
 New Comment:

Yes, amazing but true: Even Oracle has bugs in it!



Previous Comments:


[2005-04-20 19:39:52] fsurleau at skyservices dot net

A small bug in collection.php :
if( @OCINewCollection( $cnx, "MY_COLLECTION_TYPE" ) )
of course should be :
if( ! @OCINewCollection( $cnx, "MY_COLLECTION_TYPE" ) )

An other thing, this bug occurs with Oracle 9.2 Oci8 client.

With Oracle10g Oci8 or Oracle10g instant client, the problem doesn't
occur.

But... I can't use the oracle10g client because of bug #32741.

Maybe this indicates that the bug isn't in PHP's OCI8 API ?
Regards,
Fred.



[2005-04-19 14:45:42] fsurleau at skyservices dot net

The xxx in the query is juste an example of query with a quote to
generate the ORA-01756 error.

You can run the scripts with your own Oracle base replacing $user,
$pass, $db_name with your own ids.



[2005-04-19 14:27:52] [EMAIL PROTECTED]

Could you please prepare a short reproduce script, which I can
copy&paste to reproduce the problem? Those parts of your code with
'xxx' and undeclared variables do not help much. Thanks. 



[2005-04-18 13:19:31] fsurleau at skyservices dot net

Sorry, I can't use PHP5.



[2005-04-18 13:18:03] fsurleau at skyservices dot net

Reproduce bad_query.php code is :
$cnx = ociPLogon( $user, $pass, $db_name );
if( ! @ociparse( $cnx, "select sysdate from dual where
'xx'='xxx\\'xxx'" ) )
{
$oerr = OCIError( $cnx );
echo "Error in statement : ".$oerr['message'] . "";
}
echo "PID=" . getmypid();


The collection.php code is :
$cnx = ociPLogon( $user, $pass, $db_name );
if( @OCINewCollection( $cnx, "MY_COLLECTION_TYPE" ) )
{
$oerr = OCIError( $cnx );
echo "Error for collection : " . $oerr['message'] . "";
}
else
{
echo "OK for collection .";
}
echo "PID=" . getmypid();

It was cut at first post...



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

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

#32954 [Opn->Fbk]: ifx_fetch_row() : SEGV if row has TEXT fields (PHP Apache Module only)

2005-05-17 Thread sniper

 ID:   32954
 Updated by:   [EMAIL PROTECTED]
 Reported By:  andreybl at matrix dot co dot il
-Status:   Open
+Status:   Feedback
 Bug Type: Informix related
 Operating System: Red Hat 3.0 ES
 PHP Version:  4.3.11
 New Comment:

That does not matter. (1.3.33 is better though, IMO :)


Previous Comments:


[2005-05-17 10:29:54] andreybl at matrix dot co dot il

I see. Well. What Apache version do You want me to use: 1 or 2?



[2005-05-17 10:24:59] [EMAIL PROTECTED]

Yes, but we're focused on PHP 5 now. If you can check it happens with
PHP 5 too, there's much more interest in fixing it and backporting the
fix to PHP 4 too.




[2005-05-17 10:23:14] andreybl at matrix dot co dot il

Hi.
You propose me to check with the snapshot of the fifth (5)
version of PHP.
The problem, that I MUST use the fourth (4)



[2005-05-17 09:07:23] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-05-05 12:29:55] andreybl at matrix dot co dot il

Description:

Apache version: 1.3.33
Informix server version: IDS 9.40.UC5
Informix SDK version: csdk_informix.2.90

'./configure' '--with-informix=/isoc/informix'
'--with-config-file-path=/isoc/apache/conf' '--enable-track-vars'
'--with-apache=/isoc/sources/apache' '--without-mysql' 

NOTE: 
The problem occurs in PHP Apache Module ONLY and NOT occurs in PHP
CGI.

Description:
Segmentation Fault in httpd when call to the 
ifx_fetch_row() while among the fields to be selected there is a field
of type TEXT containing NON-NULL data:

- In httpd log file (./apache/logs/error_log): 

[Thu May  5 12:02:10 2005] [notice] child pid 20754 exit signal
Segmentation fault (11)

- In browser: 

"The page cannot be displayed"

Seems my BUG is simillar to #8715, which was closed since there was No
feedback. So probably the problem in #8715 still persists too.

Please, take care of this report as soon as possible, since it is of
Critical severity for me. Actually this stops the whole project.

Thanks,
Andrey





Reproduce code:
---
$trace = fopen('/tmp/php_bug.txt', 'w+');

$conn_id = ifx_connect('DB', 'USER', 'PASS');
if (!$conn_id)
{
echo "FAILED TO CONNECT"; die();
}
fwrite($trace, "after ifx_connect\n"); fflush($trace);

$res_id  = ifx_query('SELECT * FROM registrars where regid = 5',
$conn_id);
if (!$res_id)
{
echo "FAILED TO PREPARE"; echo ifx_getsqlca(); die();
}
fwrite($trace, "after ifx_query\n"); fflush($trace);

$row = ifx_fetch_row($res_id);
fwrite($trace, "after ifx_fetch_row: regid = {$row['regid']}\n");
fflush($trace);

ifx_free_result($res_id);
fwrite($trace, "after ifx_free_result\n"); fflush($trace);

ifx_close($conn_id);
fwrite($trace, "after ifx_close\n"); fflush($trace);

Expected result:

Hm. I expect the httpd not to crash.

Actual result:
--
Here is the backtrace:
Program received signal SIGSEGV, Segmentation fault.
0xb7359e6f in _int_free () from /lib/tls/libc.so.6
(gdb) bt
#0  0xb7359e6f in _int_free () from /lib/tls/libc.so.6
#1  0xb7358e68 in free () from /lib/tls/libc.so.6
#2  0xb7583c3c in ifx_free_sqldata () from
/isoc/informix/lib/esql/libifsql.so
#3  0xb7583a80 in sqli_desc_dealloc () from
/isoc/informix/lib/esql/libifsql.so
#4  0x080b4a14 in zif_ifx_free_result ()
#5  0x080abca6 in execute ()
#6  0x0809fa5b in zend_execute_scripts ()
#7  0x0808193b in php_execute_script ()
#8  0x080aee8e in apache_php_module_main ()
#9  0x0807a772 in ap_get_server_built ()
#10 0x0807a7dc in ap_get_server_built ()
#11 0x0812e6d3 in ap_invoke_handler ()
#12 0x0814356f in ap_some_auth_required ()
#13 0x081435ce in ap_process_request ()
#14 0x0813a731 in ap_child_terminate ()
#15 0x0813a8d1 in ap_child_terminate ()
#16 0x0813aa37 in ap_child_terminate ()
#17 0x0813b0ee in ap_child_terminate ()
#18 0x0813b90c in main ()
(gdb) qui

In the test program above I fetch only one row. If the TEXT field in
the row has NULL value everything's OK and the output in the
php_bug.txt file (see the programm) is the following:

after ifx_connect
after ifx_query
after ifx_fetch_row: regid = 3
after ifx_free_result
after ifx_close

i.e. all the functions returned ok.

If the TEXT field in the row has non-NULL data, then the SEGV occurs
and the output in the php_bug.txt test file is:
after ifx_connect
after ifx_query
after ifx_fetch_row: regid = 11

i.e. ifx_free_result did not return.

NOTE: if the TEXT-type field is not in the list of the filds to be
selected, then everything is OK.



-

#32494 [Ver]: crash when using expat in a class

2005-05-17 Thread sniper

 ID:   32494
 Updated by:   [EMAIL PROTECTED]
 Reported By:  evert at rooftopsolutions dot nl
 Status:   Verified
 Bug Type: XML related
 Operating System: Linux glibc 2.3.4
 PHP Version:  4CVS-2005-03-30
 New Comment:

Does NOT happen with PHP 5 (using libxml instead of expat)



Previous Comments:


[2005-05-05 01:01:03] evert at rooftopsolutions dot nl

Thank you rmartins!!!



[2005-05-05 00:10:43] rmartins at dcc dot online dot pt

Try freeing the parser via xml_parser_free()

Ricardo Martins



[2005-03-30 02:05:33] evert at rooftopsolutions dot nl

Description:

My PHP crashes when using expat functions in a class.
My scripts opens the 'test' file, but it doesn't matter if it exists or
not.

Right now I'm unable to check this with the latest cvs, but I did test
this on multiple servers running 4.3.10

Reproduce code:
---
parser = xml_parser_create('UTF-8');
  
xml_parser_set_option($this->parser,XML_OPTION_CASE_FOLDING,false);
   xml_set_element_handler($this->parser,array($this,
'onStartElement'),array($this,'onEndElement'));
  
xml_set_character_data_handler($this->parser,array($this,'onCDATA'));
  
xml_set_processing_instruction_handler($this->parser,array($this,'onProcessInstruction'));
   if (!xml_parse($this->parser,$data)) {
  
$this->onXMLError(xml_get_current_line_number($this->parser),
xml_get_error_code($this->parser),
xml_error_string(xml_get_error_code($
this->parser)));
   return false;
   } else return $this->parsedData;

   }

   function execute($data) {

   return $this->xmlparse($data);

   }

 }

 $disp = new sParser();

 $disp->execute(file_get_contents('test'));


?> 

Expected result:

No errors

Actual result:
--
PHP Crash

my apache logs says:

[Tue Mar 29 07:07:25 2005] [notice] child pid 9106 exit signal Aborted
(6)
*** glibc detected *** double free or corruption (!prev): 0x08205058
***






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

#32954 [Fbk->Opn]: ifx_fetch_row() : SEGV if row has TEXT fields (PHP Apache Module only)

2005-05-17 Thread andreybl at matrix dot co dot il

 ID:   32954
 User updated by:  andreybl at matrix dot co dot il
 Reported By:  andreybl at matrix dot co dot il
-Status:   Feedback
+Status:   Open
 Bug Type: Informix related
 Operating System: Red Hat 3.0 ES
 PHP Version:  4.3.11
 New Comment:

I see. Well. What Apache version do You want me to use: 1 or 2?


Previous Comments:


[2005-05-17 10:24:59] [EMAIL PROTECTED]

Yes, but we're focused on PHP 5 now. If you can check it happens with
PHP 5 too, there's much more interest in fixing it and backporting the
fix to PHP 4 too.




[2005-05-17 10:23:14] andreybl at matrix dot co dot il

Hi.
You propose me to check with the snapshot of the fifth (5)
version of PHP.
The problem, that I MUST use the fourth (4)



[2005-05-17 09:07:23] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-05-05 12:29:55] andreybl at matrix dot co dot il

Description:

Apache version: 1.3.33
Informix server version: IDS 9.40.UC5
Informix SDK version: csdk_informix.2.90

'./configure' '--with-informix=/isoc/informix'
'--with-config-file-path=/isoc/apache/conf' '--enable-track-vars'
'--with-apache=/isoc/sources/apache' '--without-mysql' 

NOTE: 
The problem occurs in PHP Apache Module ONLY and NOT occurs in PHP
CGI.

Description:
Segmentation Fault in httpd when call to the 
ifx_fetch_row() while among the fields to be selected there is a field
of type TEXT containing NON-NULL data:

- In httpd log file (./apache/logs/error_log): 

[Thu May  5 12:02:10 2005] [notice] child pid 20754 exit signal
Segmentation fault (11)

- In browser: 

"The page cannot be displayed"

Seems my BUG is simillar to #8715, which was closed since there was No
feedback. So probably the problem in #8715 still persists too.

Please, take care of this report as soon as possible, since it is of
Critical severity for me. Actually this stops the whole project.

Thanks,
Andrey





Reproduce code:
---
$trace = fopen('/tmp/php_bug.txt', 'w+');

$conn_id = ifx_connect('DB', 'USER', 'PASS');
if (!$conn_id)
{
echo "FAILED TO CONNECT"; die();
}
fwrite($trace, "after ifx_connect\n"); fflush($trace);

$res_id  = ifx_query('SELECT * FROM registrars where regid = 5',
$conn_id);
if (!$res_id)
{
echo "FAILED TO PREPARE"; echo ifx_getsqlca(); die();
}
fwrite($trace, "after ifx_query\n"); fflush($trace);

$row = ifx_fetch_row($res_id);
fwrite($trace, "after ifx_fetch_row: regid = {$row['regid']}\n");
fflush($trace);

ifx_free_result($res_id);
fwrite($trace, "after ifx_free_result\n"); fflush($trace);

ifx_close($conn_id);
fwrite($trace, "after ifx_close\n"); fflush($trace);

Expected result:

Hm. I expect the httpd not to crash.

Actual result:
--
Here is the backtrace:
Program received signal SIGSEGV, Segmentation fault.
0xb7359e6f in _int_free () from /lib/tls/libc.so.6
(gdb) bt
#0  0xb7359e6f in _int_free () from /lib/tls/libc.so.6
#1  0xb7358e68 in free () from /lib/tls/libc.so.6
#2  0xb7583c3c in ifx_free_sqldata () from
/isoc/informix/lib/esql/libifsql.so
#3  0xb7583a80 in sqli_desc_dealloc () from
/isoc/informix/lib/esql/libifsql.so
#4  0x080b4a14 in zif_ifx_free_result ()
#5  0x080abca6 in execute ()
#6  0x0809fa5b in zend_execute_scripts ()
#7  0x0808193b in php_execute_script ()
#8  0x080aee8e in apache_php_module_main ()
#9  0x0807a772 in ap_get_server_built ()
#10 0x0807a7dc in ap_get_server_built ()
#11 0x0812e6d3 in ap_invoke_handler ()
#12 0x0814356f in ap_some_auth_required ()
#13 0x081435ce in ap_process_request ()
#14 0x0813a731 in ap_child_terminate ()
#15 0x0813a8d1 in ap_child_terminate ()
#16 0x0813aa37 in ap_child_terminate ()
#17 0x0813b0ee in ap_child_terminate ()
#18 0x0813b90c in main ()
(gdb) qui

In the test program above I fetch only one row. If the TEXT field in
the row has NULL value everything's OK and the output in the
php_bug.txt file (see the programm) is the following:

after ifx_connect
after ifx_query
after ifx_fetch_row: regid = 3
after ifx_free_result
after ifx_close

i.e. all the functions returned ok.

If the TEXT field in the row has non-NULL data, then the SEGV occurs
and the output in the php_bug.txt test file is:
after ifx_connect
after ifx_query
after ifx_fetch_row: regid = 11

i.e. ifx_free_result did not return.

NOTE: if the TEXT-type field is not in the list of the filds to be
selected, then everything is OK.






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

#32386 [Opn->Bgs]: Sablotron error on line 1: XML parser error 3

2005-05-17 Thread sniper

 ID:   32386
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ian_real at dominios dot net
-Status:   Open
+Status:   Bogus
 Bug Type: XSLT related
 Operating System: Suse 9.2 2.6.8-24-smp x86_64
 PHP Version:  4CVS-2005-03-20 (stable)
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

See bug #31841


Previous Comments:


[2005-03-20 21:25:35] ian_real at dominios dot net

Description:

XSLT test fails
Sablotron version is 1.0.2



/temp/php4-STABLE-200503201730/ext/xslt/tests/xslt_set_object.phpt


 EXPECTED OUTPUT
OK
OK
 ACTUAL OUTPUT
Warning: Sablotron error on line 1: XML parser error 3: no element
found in /temp/php4-STABLE-200503201730/ext/xslt/tests/xslt_set_$
  
Warning: Sablotron error on line 1: XML parser error 3: no element
found in /temp/php4-STABLE-200503201730/ext/xslt/tests/xslt_set_$
OK
OK
 FAILED







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

#31971 [Opn->Fbk]: ftp_login fails on messsage from FTP+SSL server (234 Enabling SSL)

2005-05-17 Thread sniper

 ID:   31971
 Updated by:   [EMAIL PROTECTED]
 Reported By:  frantisek at augusztin dot com
-Status:   Open
+Status:   Feedback
 Bug Type: FTP related
 Operating System: Linux (Fedora Core 3)
 PHP Version:  4.3.11
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2005-05-13 15:23:43] frantisek at augusztin dot com

The SSL_CTX_set_options must be called for both control and data
connection :

264a265
>   SSL_CTX_set_options(ctx,SSL_OP_ALL);
1405a1407,1408
>   SSL_CTX_set_options(ctx,SSL_OP_ALL);
>



[2005-05-05 12:57:00] frantisek at augusztin dot com

Here is the solution (now it works for me) .

Here is the diff (against 4.3.11) for file ext/ftp/ftp.c:

265c265,266
<
---
>   SSL_CTX_set_options(ctx,SSL_OP_ALL);
>

Yeah, it's one line at 265th line - here is how it looks in source code
:

ctx = SSL_CTX_new(SSLv23_client_method());
if (ctx == NULL) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, 
"ftp_login: failed to
create the SSL context");
return 0;
}
SSL_CTX_set_options(ctx,SSL_OP_ALL);

ftp->ssl_handle = SSL_new(ctx);



[2005-02-22 00:48:29] [EMAIL PROTECTED]

Please provide address of FTP/SSL server which can be used to replicate
the bug.



[2005-02-14 17:32:32] frantisek at augusztin dot com

After examining (and debuging PHP code) i found out, that the ftp_login
function exits after getting the response for PBSZ command (from
ext/ftp/ftp.c, lines 305-313) :

   if (!ftp->old_ssl) {

/* set protection buffersize to zero */
if (!ftp_putcmd(ftp, "PBSZ", "0")) {
return 0;
}
if (!ftp_getresp(ftp)) {
return 0; /* <<< here it exits
}

Why ? What can i do to make it work ? As i said, using regular FTP+SSL
client it works.



[2005-02-14 16:19:47] frantisek at augusztin dot com

Description:

PHP returns following error when connecting using example code:
Warning: ftp_login() : Enabling SSL in /var/www/html/test.php on line
3

Using FTP client the following messages are displayed in the log window
of the client :

*** Connecting to 'XXX.XXX.XXX.XXX:21'...
220 Service Ready for new User
AUTH TLS
234 Enabling SSL

FTP clearly fails on this messsage. But i don't understand why, because
i found in source code, that 234 is not an error, but a valid result
code for this operation.
FTP System type is "215 NETWARE  Type : L8"

Reproduce code:
---


Expected result:

No warning message and successfull connection to FTP server.

Actual result:
--
Warning: ftp_login() : Enabling SSL in /var/www/html/test.php on line 3





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

#31558 [Opn->Fbk]: "apachectl graceful" leaks

2005-05-17 Thread sniper

 ID:   31558
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jdw at nearlyfreespeech dot net
-Status:   Open
+Status:   Feedback
 Bug Type: Apache related
 Operating System: FreeBSD
 PHP Version:  4CVS-2005-01-21
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2005-01-22 06:55:13] jdw at nearlyfreespeech dot net

I also looked at the source code.  Without a detailed understanding of
zend_hash_*, it isn't clear that all the per_dir_info malloc() cases in
sapi/apache/mod_php4.c (particularly php_value_handler_ex() ) are being
properly freed by php_destroy_per_dir_info().  That's just a WAG, but
it might be something to look into as a possible cause.



[2005-01-22 06:48:32] jdw at nearlyfreespeech dot net

This test has been completed.  I believe this graph of the results
pretty much speaks for itself:

http://example.nfshost.com/ApacheGracefulMem.png

Results:
- With PHP enabled, "graceful" leak averages 903,000 bytes
- With PHP disabled, "graceful" leak averages 8,900 bytes
- "No PHP" test memory usage *converges* (leaks are front-loaded and
poorly represented by the linear fit -- hard to see because of the
scale of the graph)
- "PHP" test memory usage *diverges* (increases linearly until process
limits intervene)

Methodology:
- Apache 1.3.33
- PHP version php4-STABLE-200501210130
- same Apache binary, same server, same conditions
- same conf file (with "LoadModule php4_module" "php_admin_value" and
"php_value" lines removed for the "No HP" test)
- 200 consecutive "graceful" restarts of Apache process
- considering only "master" process
- no requests issued during test



[2005-01-21 01:04:16] jdw at nearlyfreespeech dot net

Keep in mind that this is happen in the "master" Apache process, a
context in which no PHP scripts are ever executed.  In fact, very
little happens other than parsing config files.  That should severely
constrain the influence of libraries & extensions.

Apache obviously won't parse its configs with PHP disabled, and our
customers will (justifiably) riot if we turn it off. 
There are quite a large number of PHP-specific conf lines in a
proportional number of files (the reason I suspect our setup is finding
this earlier than the general population), so I'm not sure how feasible
your suggestion is.  

But I'm happy to see if I can rig something up on a test server to
explore it.  More to follow.

It would be more direct if there were a means to instrument the amount
of memory allocated at start vs. the amount freed at restart.

It would also be handy if there's someone around who can point me in
the right direction as to where in the PHP Apache SAPI code to find the
relevant setup/cleanup code.

Also, I now have a second backtrace, but I am hestitant to post it here
because it's even larger than the first one.  It's similar: died on a
"php_admin_value open_basedir" instead of "php_admin_value
max_execution_time."



[2005-01-21 00:36:57] [EMAIL PROTECTED]

Disable PHP from Apache and see if the problem persists. It is possible
that one the libraries used by PHP is leaking etc... Right now all we
know is that your PHP is failing to allocate memory and you are
claiming that PHP leaks. Well, that does not say a whole lot.



[2005-01-20 23:41:47] jdw at nearlyfreespeech dot net

As previously indicated, the system limits are not in play.  Or rather,
if they are, they shouldn't be.  I've said that a couple of times now in
attempt to avoid a quick "you're out of memory" reaction. 
Unfortunately, that strategy does not appear to be a winner.

The per-process allocation limits are currently set to 512M.  
That is a very savvy observation that the process size grows to 512M
and then allocations fail.  I checked out the size of the core dump
file, and it confirms your theory.  Whatever random PHP script, large
or small, is running at that point gets hosed (obviously).  Good
catch!

But it is a little hasty to jump from that to "bogus."

The "steady state" size of Apache processes on this system should be
about 30M.  Where did the other 480M come from?

Further research today has shown that Apache leaks about 1mb of RAM on
every "graceful" (SIGUSR1) restart.  If it's something else leaking,
fine, but so far the stack trace says it's PHP.

Perhaps instead of rushing to "bogus," you could suggest some ways I
could prove or disprove the theory that PHP leaks memory when Apache is
reconfigured.  

That would be very helpful, and I would very much appreciate help

#31114 [Asn]: foreach modify array

2005-05-17 Thread sniper

 ID:   31114
 Updated by:   [EMAIL PROTECTED]
 Reported By:  clemens at gutweiler dot net
 Status:   Assigned
 Bug Type: Arrays related
 Operating System: Linux 2.4.27
 PHP Version:  4.3.10
 Assigned To:  andi
 New Comment:

Works fine in PHP 5..



Previous Comments:


[2004-12-16 22:32:14] [EMAIL PROTECTED]

I just tested this on PHP 4.3.1 and 4.3.2 and it behaves in the same
way, making this a non-critical bug and not related to the foreach
speed-up patch. Assigning to Andi, as he might have a clue why this
happens. The new foreach code is definitely not the problem here.



[2004-12-16 13:07:17] [EMAIL PROTECTED]

(The only bug here is that it doesn't give a warning, using $k for both
key and value is not supposed to work!)



[2004-12-16 11:41:54] [EMAIL PROTECTED]

I don't think this was ever supposed to work. 



[2004-12-16 10:44:05] clemens at gutweiler dot net

Description:

foreach modifies an array, if key and value are the same variable.

see reproduction code.

Reproduce code:
---
 'bar', 'dings' => 'dongs' );
foreach( $foo as $k => $k ) {}
var_dump( $foo );
?>
array(2) {
  ["foo"]=>
  string(5) "dings"
  ["dings"]=>
  NULL
}


Expected result:

array(2) {
  ["foo"]=>
  string(3) "bar"
  ["dings"]=>
  string(5) "dongs"
}







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

#33046 [NEW]: PHP has encountered an Access Violation at 01990AFD

2005-05-17 Thread a dot geets at ch-aurillac dot fr

From: a dot geets at ch-aurillac dot fr
Operating system: NT4 / IIS
PHP version:  4.3.9
PHP Bug Type: Unknown/Other Function
Bug description:  PHP has encountered an Access Violation at 01990AFD

Description:

Sometimes, this error occured at the bottom of all php's page.
But if i don't reboot IIS, this error seems to crash it.

Reproduce code:
---
Sorry, but i haven't any code to give 'cause this error occured with any
.php page.

Expected result:

PHP has encountered an Access Violation at 01990AFD


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

#28496 [Ver->Asn]: Fatal Error in the make install caused by broken egrep

2005-05-17 Thread sniper

 ID:   28496
 Updated by:   [EMAIL PROTECTED]
 Reported By:  rehanann at kfupm dot edu dot sa
-Status:   Verified
+Status:   Assigned
 Bug Type: Compile Failure
 Operating System: Aix 5.2
 PHP Version:  5CVS, 4CVS
-Assigned To:  
+Assigned To:  sniper


Previous Comments:


[2005-04-13 13:57:05] zahraoui at netcourrier dot com

i have the same pb with aix 5.1 and both php 4.3.11 and php 5.0.4 on
apache 2.0.53

bash-2.05b# ./configure --prefix=/usr/local/php
--with-apxs2=/usr/local/apache2/bin/apxs --with-mysql=/usr/mysql
--with-config-file-path=/usr/local/apache2/conf --with-ftp --with-zlib
--with-system-regex 
...
Configuring libtool
checking for Cygwin environment... no
checking for mingw32 environment... no
checking build system type... powerpc-ibm-aix5.1.0.0
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking for a sed that does not truncate output... /usr/bin/sed
checking how to recognise dependent libraries... pass_all
checking for object suffix... o
checking for executable suffix... no
checking command to parse /usr/bin/nm -B output... ok
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for gcc option to produce PIC... none
checking if gcc static flag -static -Wl,-lC works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/bin/ld) supports shared libraries...
yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking dynamic linker characteristics... aix5.1.0.0 ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
creating libtool
...
bash-2.05b# make
... 
Build complete.
(It is safe to ignore warnings about tempnam and tmpnam).
bash-2.05b# make install
Installing PHP SAPI module:   apache2handler
/usr/local/apache2/build/instdso.sh
SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp4.la
/usr/local/apache2/modules
rm -f /usr/local/apache2/modules/libphp4.so
/usr/local/apache2/build/libtool --mode=install cp libphp4.la
/usr/local/apache2/modules/
cp .libs/libphp4.a /usr/local/apache2/modules/libphp4.a
cp .libs/libphp4.lai /usr/local/apache2/modules/libphp4.la
libtool: install: warning: remember to run `libtool --finish
/usr/sys/inst.images/php-4.3.11/libs'
chmod 755 /usr/local/apache2/modules/libphp4.so
chmod: /usr/local/apache2/modules/libphp4.so: A file or directory in
the path name does not exist.
apxs:Error: Command failed with rc=65536
.
make: 1254-004 The error code from the last command is 1.


Stop.
bash-2.05b# if echo GNU | egrep '(GNU|BFD)' >/dev/null; then echo "Good
egrep"; else echo "Bad egrep"; fi
Good egrep



[2005-02-21 20:00:19] [EMAIL PROTECTED]

There is no check for broken grep in our configure yet..




[2004-11-27 05:43:30] sjungels at adelphia dot net

I tracked this bug down to a faulty version of GNU grep.  If you are
having problems where no libphp4.so is generated, this may be the cause
in your case also.

If you have this problem you will notice the following symptoms: during
the part of the php configure log that begins "performing libtool
configuration..." you will see the following (or similar) messages:
  checking if the linker (/usr/powerpc-hardhat-linux/bin/ld) is GNU
ld... no
  checking whether the linker (/usr/powerpc-hardhat-linux/bin/ld)
supports shared libraries... no
  checking if libtool supports shared libraries... no
  checking whether to build shared libraries... no
  checking whether to build static libraries... yes

These messages may be correct, but if you have the problem I am
describing, they are caused by a bad version of grep.  Check for this
by typing
  if echo GNU | egrep '(GNU|BFD)' >/dev/null; then echo "Good egrep";
else echo "Bad egrep"; fi 

If you get back "Bad egrep" you are running a version of egrep which
doesn't really support extended regular expressions, and this is
confusing the php configure script.  You can fix the problem by
installing GNU grep 2.5.

If you have this problem, it will have effected apache also (even
though it seems to work, it is statically compiled and probably won't
work with DSOs), so after installing the new grep you will have to
rebuild apache and PHP

Note to whoever wrote the configure script: this issue is verified on
only the Buffalo Linkstation, but indications are that it may apply to
all versions of GNU grep 2.4.2

#28671 [Asn->Fbk]: wrong serialNumber (-1) using openssl_x509_parse

2005-05-17 Thread sniper

 ID:   28671
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jgrillon at capgemini dot fr
-Status:   Assigned
+Status:   Feedback
 Bug Type: OpenSSL related
 Operating System: Linux 2.1
 PHP Version:  4.3.7
 Assigned To:  wez
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2004-06-08 09:51:07] [EMAIL PROTECTED]

Assigning to the maintainer, wez.



[2004-06-07 14:35:44] jgrillon at capgemini dot fr

Description:

I'm always getting "-1" as serialNumber for my certificate.

I can't see why the serial number is stored into a long in openssl.c :
add_assoc_long(return_value, "serialNumber",   
ASN1_INTEGER_get(X509_get_serialNumber(cert)));

I guess the serial number is too big for a long...
Can't we store it as string ?
add_assoc_asn1_string(return_value, "serialNumberAsString",
X509_get_serialNumber(cert));

Thanks.

Here is the certificate I used :
-BEGIN CERTIFICATE-
MIIC3DCCAkWgAwIBAgIQeqhtj1pzHCrTTq2AldV0ejANBgkqhkiG9w0BAQQFADAy
MRcwFQYDVQQKEw5FLUFDSEFUIE1JTkRFRjEXMBUGA1UEAxMORS1BQ0hBVCBNSU5E
RUYwHhcNMDQwMTA1MDAwMDAwWhcNMDYwMTA0MjM1OTU5WjCB5DEOMAwGA1UEBxQF
UEFSSVMxCzAJBgNVBAYTAkZSMRcwFQYDVQQKFA5FLUFDSEFUIE1JTkRFRjEtMCsG
A1UECxQkRW50LiAtIENhcCBHZW1pbmkgRXJuc3QgWW91bmcgRnJhbmNlMR8wHQYD
VQQLFBZTSVJFTiAtIDMyODc4MTc4NjAwMDUzMTQwMgYDVQQDEytDR0VZIEZyYW5j
ZSAtIENhcCBHZW1pbmkgRXJuc3QgWW91bmcgRnJhbmNlMSYwJAYJKoZIhvcNAQkB
FhdkZ2FlbWEtbWNvQGNhcGdlbWluaS5mcjCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEApFgcuVTuUe0z+iGTaPw7yVxhZsPq6aIqGHsCvU9fqUcymbmg9l4oTfAk
gR5bvDo+JTQb1/OPlQCKqyVa7wn6lPs97dMOZMobjCRcvw7z0jVphortA1NS8FRH
6LsWELZ13uC57IIakpW726Vz3tST9qHHbQoWbX/n8NjHcwL4zUECAwEAAaNAMD4w
CQYDVR0TBAIwADALBgNVHQ8EBAMCBaAwEQYJYIZIAYb4QgEBBAQDAgeAMBEGCmCG
SAGG+EUBBgkEAwEB/zANBgkqhkiG9w0BAQQFAAOBgQAWdmEu8TkFdgqA/xN6llo9
zZR3EUH0X5HstxJRYgofcQyfumJHhgvaNB8vkDhZ3iJORVVxcJ27W36TAJ6b4jcr
yWjO/nc42XdgknS8r9NIV7VKzmjY7Ip2+9N6JOAWFkjGrnF1G69nrerIJavJTzrb
PYlQnzJO6SHAoi5j6WsKPw==
-END CERTIFICATE-


Reproduce code:
---
 $fp = fopen("xxx.cer", "r");
 $cert = fread($fp, 8192);
 $r = @openssl_x509_read($cert);
 print_r(openssl_x509_parse($r));

Expected result:

Something like

[...]
 [serialNumber] => 7a a8 6d 8f 5a 73 1c 2a d3 4e ad 80 95 d5 74 7a
[...]


Actual result:
--
[...]
 [serialNumber] => -1
[...]





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

#33046 [Opn->Bgs]: PHP has encountered an Access Violation at 01990AFD

2005-05-17 Thread sniper

 ID:   33046
 Updated by:   [EMAIL PROTECTED]
 Reported By:  a dot geets at ch-aurillac dot fr
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: NT4 / IIS
 PHP Version:  4.3.9
 New Comment:

We are aware of PHP's problems with stability under IIS and are working

to rectify the problem. Unfortunatly your bug report does not contain
any
extra useful information and we already have enough bug reports open
about
this issue. If you can provide more detailed information such as a 
reproducable crash or a backtrace please do so and reopen this bug. 
Otherwise please keep trying new releases as we are working to resolve 
the problems on this platform
 
Thanks for your interest in PHP.




Previous Comments:


[2005-05-17 12:09:34] a dot geets at ch-aurillac dot fr

Description:

Sometimes, this error occured at the bottom of all php's page.
But if i don't reboot IIS, this error seems to crash it.

Reproduce code:
---
Sorry, but i haven't any code to give 'cause this error occured with
any .php page.

Expected result:

PHP has encountered an Access Violation at 01990AFD






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

#31971 [Fbk->Opn]: ftp_login fails on messsage from FTP+SSL server (234 Enabling SSL)

2005-05-17 Thread frantisek at augusztin dot com

 ID:   31971
 User updated by:  frantisek at augusztin dot com
 Reported By:  frantisek at augusztin dot com
-Status:   Feedback
+Status:   Open
 Bug Type: FTP related
 Operating System: Linux (Fedora Core 3)
 PHP Version:  4.3.11
 New Comment:

Nope, it doesn't work. Same error as in first submission. It doesn't
read any data after enabling SSL. As i said, enabling
special handling of non-conforming SSL servers using this line after
ctx variable initialization in both control and data connection helps
:

SSL_CTX_set_options(ctx,SSL_OP_ALL);


Previous Comments:


[2005-05-17 11:06:38] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-05-13 15:23:43] frantisek at augusztin dot com

The SSL_CTX_set_options must be called for both control and data
connection :

264a265
>   SSL_CTX_set_options(ctx,SSL_OP_ALL);
1405a1407,1408
>   SSL_CTX_set_options(ctx,SSL_OP_ALL);
>



[2005-05-05 12:57:00] frantisek at augusztin dot com

Here is the solution (now it works for me) .

Here is the diff (against 4.3.11) for file ext/ftp/ftp.c:

265c265,266
<
---
>   SSL_CTX_set_options(ctx,SSL_OP_ALL);
>

Yeah, it's one line at 265th line - here is how it looks in source code
:

ctx = SSL_CTX_new(SSLv23_client_method());
if (ctx == NULL) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, 
"ftp_login: failed to
create the SSL context");
return 0;
}
SSL_CTX_set_options(ctx,SSL_OP_ALL);

ftp->ssl_handle = SSL_new(ctx);



[2005-02-22 00:48:29] [EMAIL PROTECTED]

Please provide address of FTP/SSL server which can be used to replicate
the bug.



[2005-02-14 17:32:32] frantisek at augusztin dot com

After examining (and debuging PHP code) i found out, that the ftp_login
function exits after getting the response for PBSZ command (from
ext/ftp/ftp.c, lines 305-313) :

   if (!ftp->old_ssl) {

/* set protection buffersize to zero */
if (!ftp_putcmd(ftp, "PBSZ", "0")) {
return 0;
}
if (!ftp_getresp(ftp)) {
return 0; /* <<< here it exits
}

Why ? What can i do to make it work ? As i said, using regular FTP+SSL
client it works.



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

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

#32225 [Com]: Tokenizer fails after fatal error until timeout or apache restart

2005-05-17 Thread gary dot every at ingramentertainment dot com

 ID:   32225
 Comment by:   gary dot every at ingramentertainment dot com
 Reported By:  paul dot laughlin at ingramentertainment dot com
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Gentoo Linux 2.6.10
 PHP Version:  PHP 5.1.0-dev (built: Mar 22 2005 15:40:32)
 New Comment:

The token_get_all seems to still be broken. We are developing a site
that will be promoted into production in September. Is anyone else
experiencing this problem? 

Gary Every


Previous Comments:


[2005-04-12 20:29:59] gary dot every at ingramentertainment dot com

There has been no input on this bug for over a month. Is anyone looking
into it? 
We're depending heavily on the tokenizer to parse our template, and
this could easily cause serious issues with our next major release of
our B2B website.

Gary Every



[2005-03-22 22:55:29] paul dot laughlin at ingramentertainment dot com

Tested this problem with the snapshot as instructed.  This is still a
problem in the snapshot.

THank you



[2005-03-20 18:11:55] [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.





[2005-03-07 20:04:47] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-03-07 19:23:37] paul dot laughlin at ingramentertainment dot com

Description:

If you have a fatal error it breaks token_get_all until an apache
restart...

Reproduce code:
---
-- Sample Token file 
Some HTML

Some More HTML

More HTML
-- End Sample Token File

-- PHP Script --
';
print_r($token);
echo '';
}
?>
-- End PHP Script --

If you introduce a parse error as follows, fix the error and reload you
get broken output until apache restart.

';
print_r($token);
echo '';
}
?>


Expected result:

Array
(
[0] => 310
[1] => Some HTML

)

Array
(
[0] => 365
[1] => 

Array
(
[0] => 368
[1] =>  
)

Array
(
[0] => 306
[1] => TEST_TAG
)

Array
(
[0] => 368
[1] =>  
)

Array
(
[0] => 367
[1] => ?>

)

Array
(
[0] => 310
[1] => Some More HTML

)

Array
(
[0] => 365
[1] => 

Array
(
[0] => 368
[1] =>  
)

Array
(
[0] => 306
[1] => Another_TAG
)

Array
(
[0] => 368
[1] =>  
)

Array
(
[0] => 367
[1] => ?>

)

Array
(
[0] => 310
[1] => More HTML
)

Actual result:
--
Array
(
[0] => 306
[1] => Some
)

Array
(
[0] => 368
[1] =>  
)

Array
(
[0] => 306
[1] => HTML
)

Array
(
[0] => 368
[1] => 

)

<

?

Array
(
[0] => 368
[1] =>  
)

Array
(
[0] => 306
[1] => TEST_TAG
)

Array
(
[0] => 368
[1] =>  
)

Array
(
[0] => 367
[1] => ?>

)

Array
(
[0] => 310
[1] => Some More HTML

)

Array
(
[0] => 365
[1] => 

Array
(
[0] => 368
[1] =>  
)

Array
(
[0] => 306
[1] => Another_TAG
)

Array
(
[0] => 368
[1] =>  
)

Array
(
[0] => 367
[1] => ?>

)

Array
(
[0] => 310
[1] => More HTML
)







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

#33015 [Fbk->Opn]: ArrayObject: object- and array-access not interchangeable

2005-05-17 Thread pecoes at xs4all dot nl

 ID:   33015
 User updated by:  pecoes at xs4all dot nl
 Reported By:  pecoes at xs4all dot nl
-Status:   Feedback
+Status:   Open
 Bug Type: SPL related
 Operating System: *
 PHP Version:  5.*
 Assigned To:  helly
 New Comment:

Thanks for the offer, but I'm not in need of a work-around. IMHO it
would be great to have a "simple" solution - "simple" from a user's
perspective :)

You've created some pretty fascinating stuff with the SPL and from the
looks of it, you're doing this all alone right now, so I really don't
want to rush you... Just tell me how big the chances are in the long
run!


Previous Comments:


[2005-05-12 23:15:00] [EMAIL PROTECTED]

I could equip you with a special factory method or a derived class that
does this. But the way it works it is not possible to achieve what you
want with ArrayObject and its current constructor.



[2005-05-12 12:32:44] pecoes at xs4all dot nl

Description:

It's pretty counter-intuitive, that you can neither access an
ArrayObject's properties with the array-syntax, nor its array-values
with the object-syntax. I think these two should be interchangeable.
Preferably like in ECMAScript...

Reproduce code:
---
$a = new ArrayObject();

$a->one   = 1;
$a['two'] = 2;

echo "\$a->one: $a->one \$a->two: $a->two \n";
echo "\$a[one]: $a[one] \$a[two]: $a[two] \n";

Expected result:

$a->one: 1 $a->two: 2 
$a[one]: 1 $a[two]: 2 

Actual result:
--
$a->one: 1 $a->two:
$a[one]:  $a[two]: 2 





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

#31558 [Fbk->Opn]: "apachectl graceful" leaks

2005-05-17 Thread jdw at nearlyfreespeech dot net

 ID:   31558
 User updated by:  jdw at nearlyfreespeech dot net
 Reported By:  jdw at nearlyfreespeech dot net
-Status:   Feedback
+Status:   Open
 Bug Type: Apache related
 Operating System: FreeBSD
 PHP Version:  4CVS-2005-01-21
 New Comment:

Um, as this is a PHP 4 bug, trying a PHP 5 snapshot would not seem to
be appropriate.


Previous Comments:


[2005-05-17 12:02:53] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-01-22 06:55:13] jdw at nearlyfreespeech dot net

I also looked at the source code.  Without a detailed understanding of
zend_hash_*, it isn't clear that all the per_dir_info malloc() cases in
sapi/apache/mod_php4.c (particularly php_value_handler_ex() ) are being
properly freed by php_destroy_per_dir_info().  That's just a WAG, but
it might be something to look into as a possible cause.



[2005-01-22 06:48:32] jdw at nearlyfreespeech dot net

This test has been completed.  I believe this graph of the results
pretty much speaks for itself:

http://example.nfshost.com/ApacheGracefulMem.png

Results:
- With PHP enabled, "graceful" leak averages 903,000 bytes
- With PHP disabled, "graceful" leak averages 8,900 bytes
- "No PHP" test memory usage *converges* (leaks are front-loaded and
poorly represented by the linear fit -- hard to see because of the
scale of the graph)
- "PHP" test memory usage *diverges* (increases linearly until process
limits intervene)

Methodology:
- Apache 1.3.33
- PHP version php4-STABLE-200501210130
- same Apache binary, same server, same conditions
- same conf file (with "LoadModule php4_module" "php_admin_value" and
"php_value" lines removed for the "No HP" test)
- 200 consecutive "graceful" restarts of Apache process
- considering only "master" process
- no requests issued during test



[2005-01-21 01:04:16] jdw at nearlyfreespeech dot net

Keep in mind that this is happen in the "master" Apache process, a
context in which no PHP scripts are ever executed.  In fact, very
little happens other than parsing config files.  That should severely
constrain the influence of libraries & extensions.

Apache obviously won't parse its configs with PHP disabled, and our
customers will (justifiably) riot if we turn it off. 
There are quite a large number of PHP-specific conf lines in a
proportional number of files (the reason I suspect our setup is finding
this earlier than the general population), so I'm not sure how feasible
your suggestion is.  

But I'm happy to see if I can rig something up on a test server to
explore it.  More to follow.

It would be more direct if there were a means to instrument the amount
of memory allocated at start vs. the amount freed at restart.

It would also be handy if there's someone around who can point me in
the right direction as to where in the PHP Apache SAPI code to find the
relevant setup/cleanup code.

Also, I now have a second backtrace, but I am hestitant to post it here
because it's even larger than the first one.  It's similar: died on a
"php_admin_value open_basedir" instead of "php_admin_value
max_execution_time."



[2005-01-21 00:36:57] [EMAIL PROTECTED]

Disable PHP from Apache and see if the problem persists. It is possible
that one the libraries used by PHP is leaking etc... Right now all we
know is that your PHP is failing to allocate memory and you are
claiming that PHP leaks. Well, that does not say a whole lot.



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

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

#28054 [Asn]: debug_backtrace() bug

2005-05-17 Thread stas

 ID:   28054
 Updated by:   [EMAIL PROTECTED]
 Reported By:  misu200 at yahoo dot com
 Status:   Assigned
 Bug Type: Zend Engine 2 problem
 Operating System: *
 PHP Version:  5CVS-2005-02-14
 Assigned To:  andi
 New Comment:

The problem here is that error handler call does not provide necessary
information for recovering the arguments. This is because include does
not preserve the argument and backtrace bases on the fact that code
executed after include() is necessarily the included file - which is
not the case if include fails, of course. 


Previous Comments:


[2004-04-19 20:12:47] [EMAIL PROTECTED]

Assigning to the engine guru, Andi.



[2004-04-19 16:45:48] olivier dot bichler at laposte dot net

And there is an other problem : why the arguments $errNo, $errStr,
$errFile, $errLine are not present in the result of debug_backtrace()
?
I have the same problem...



[2004-04-19 09:05:28] misu200 at yahoo dot com

Description:

I set my own error handle function and then i try to include a
non-existent file (aga.php).The problem is when i make a
var_dump(debug_backtrace()) in my error handle function it shows me
wrong results.

Reproduce code:
---
";
var_dump(debug_backtrace());
echo "";
}


// set the user error handler to be the above 

$oldErrorHandler = set_error_handler("ourErrorHandler",
error_reporting());

require_once("aga.php");

?>

Expected result:

array(2) {
  [0]=>
  array(3) {
["file"]=>
string(28) "/var/www/html/dir1/file2.php"
["line"]=>
int(15)
["function"]=>
string(15) "ourErrorHandler"
  }
  [1]=>
  array(4) {
["file"]=>
string(28) "/var/www/html/dir1/file2.php"
["line"]=>
int(15)
["args"]=>
array(1) {
 [0]=>
 string(28) "aga.php" < - this should be here
}
["function"]=>
string(12) "require_once"
  }
}

Actual result:
--
array(2) {
  [0]=>
  array(3) {
["file"]=>
string(28) "/var/www/html/dir1/file2.php"
["line"]=>
int(15)
["function"]=>
string(15) "ourErrorHandler"
  }
  [1]=>
  array(4) {
["file"]=>
string(28) "/var/www/html/dir1/file2.php"
["line"]=>
int(15)
["args"]=>
array(1) {
 [0]=>
 string(28) "/var/www/html/dir1/file2.php" <- is wrong
}
["function"]=>
string(12) "require_once"
  }
}






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

#32954 [Fbk->Opn]: ifx_fetch_row() : SEGV if row has TEXT fields (PHP Apache Module only)

2005-05-17 Thread andreybl at matrix dot co dot il

 ID:   32954
 User updated by:  andreybl at matrix dot co dot il
 Reported By:  andreybl at matrix dot co dot il
-Status:   Feedback
+Status:   Open
 Bug Type: Informix related
 Operating System: Red Hat 3.0 ES
-PHP Version:  4.3.11
+PHP Version:  PHP 5.1.0-dev (cgi) (built: May 17 2005 15:15:13)
   (DEBUG)
 New Comment:

Well, well.
I don know even what to do: cry :( or laugh :)

The good news is that the SEGV problem did not appear. 
The bad news is that we  still DO HAVE a problem with TEXT fields. 

So. I have a table, called "registrars" with few rows. There is a field
in this table, called 'allowedips' and it is of type TEXT. It may have
NULL value. Here is a small test program run on PHP CGI (not Apache
module, but it does not matter):

$conn_id = ifx_connect(..);
$res_id  = ifx_query('SELECT * FROM registrars', $conn_id);

while ($row = ifx_fetch_row($res_id))
{
if (!empty($row['allowedips']))
echo ifx_get_blob($row['allowedips'])."\n";
}

ifx_free_result($res_id);
ifx_close($conn_id);

Instead of the values for the 'allowedips' field I see in the output
the following:
/tmp/blbGmDdPT
/tmp/blb214Nct
/tmp/blbQM8yM2
/tmp/blbuQGH1T

I ran this test several times. And as You can guess the /tmp directory
was full with blb** emty files.

If in the beginning of the program I put:
ifx_textasvarchar(1);

then:
echo $row['allowedips';
will produce the same output and there will be same emty files.

BTW:
$rc = ifx_get_blob('blabla'); // 'blabla' is not a valid id

produces the Segmentation fault !!! that we all LOVE :)


Previous Comments:


[2005-05-17 10:36:30] [EMAIL PROTECTED]

That does not matter. (1.3.33 is better though, IMO :)



[2005-05-17 10:29:54] andreybl at matrix dot co dot il

I see. Well. What Apache version do You want me to use: 1 or 2?



[2005-05-17 10:24:59] [EMAIL PROTECTED]

Yes, but we're focused on PHP 5 now. If you can check it happens with
PHP 5 too, there's much more interest in fixing it and backporting the
fix to PHP 4 too.




[2005-05-17 10:23:14] andreybl at matrix dot co dot il

Hi.
You propose me to check with the snapshot of the fifth (5)
version of PHP.
The problem, that I MUST use the fourth (4)



[2005-05-17 09:07:23] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





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

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

#33015 [Opn->Fbk]: ArrayObject: object- and array-access not interchangeable

2005-05-17 Thread helly

 ID:   33015
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pecoes at xs4all dot nl
-Status:   Open
+Status:   Feedback
 Bug Type: SPL related
 Operating System: *
 PHP Version:  5.*
 Assigned To:  helly
 New Comment:

Yep it's me alone. I'll do something as soon as i find ime then. How
about some exchangeArray() method that drops the current array and
replaces it with the given one. So the following would do what you
want:

class ArrayObjectEx extends ArrayObject
{
  function __construct()
  {
$this->exchangeArray($this);
  }
}

$obj = new ArrayObjectEx;



Previous Comments:


[2005-05-17 13:42:33] pecoes at xs4all dot nl

Thanks for the offer, but I'm not in need of a work-around. IMHO it
would be great to have a "simple" solution - "simple" from a user's
perspective :)

You've created some pretty fascinating stuff with the SPL and from the
looks of it, you're doing this all alone right now, so I really don't
want to rush you... Just tell me how big the chances are in the long
run!



[2005-05-12 23:15:00] [EMAIL PROTECTED]

I could equip you with a special factory method or a derived class that
does this. But the way it works it is not possible to achieve what you
want with ArrayObject and its current constructor.



[2005-05-12 12:32:44] pecoes at xs4all dot nl

Description:

It's pretty counter-intuitive, that you can neither access an
ArrayObject's properties with the array-syntax, nor its array-values
with the object-syntax. I think these two should be interchangeable.
Preferably like in ECMAScript...

Reproduce code:
---
$a = new ArrayObject();

$a->one   = 1;
$a['two'] = 2;

echo "\$a->one: $a->one \$a->two: $a->two \n";
echo "\$a[one]: $a[one] \$a[two]: $a[two] \n";

Expected result:

$a->one: 1 $a->two: 2 
$a[one]: 1 $a[two]: 2 

Actual result:
--
$a->one: 1 $a->two:
$a[one]:  $a[two]: 2 





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

#30140 [Asn->WFx]: Problem with array in static properties

2005-05-17 Thread stas

 ID:   30140
 Updated by:   [EMAIL PROTECTED]
 Reported By:  guth at fiifo dot u-psud dot fr
-Status:   Assigned
+Status:   Wont fix
 Bug Type: Zend Engine 2 problem
 Operating System: *
 PHP Version:  5CVS-2005-05-07
 Assigned To:  andi
 New Comment:

It's definitely duplicate for bug #30934.


Previous Comments:


[2005-05-09 11:34:31] [EMAIL PROTECTED]

This same thing happens with boolean too. All other types behave
correctly (or incorrectly, not sure anymore :)

Andi, (or Dmitry maybe?) can you look into this?




[2005-04-05 23:24:10] [EMAIL PROTECTED]

Yet another duplicate of bug #30934.



[2004-09-18 17:02:22] guth at fiifo dot u-psud dot fr

Description:

[ sorry for english ] 
 
There is a problem with static properties initialized as 
an array in classes. 
 
In the following code, if you replace "public static $test 
= array();" by "public static $test;" or if you initialize 
the property with not an array ("public static $test = 
12;" for example), it works as expected. 

Reproduce code:
---
set(array('key' => 'value'));

A::view();
B::view();
?>

Expected result:

array(1) { ["key"]=> string(5) "value" } 
array(1) { ["key"]=> string(5) "value" } 

Actual result:
--
array(1) { ["key"]=> string(5) "value" } 
array(0) { } 





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

#29689 [Asn]: default value of protected member overrides default value of private

2005-05-17 Thread stas

 ID:   29689
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php dot net at benjamin dot schulz dot name
 Status:   Assigned
 Bug Type: Zend Engine 2 problem
 Operating System: *
 PHP Version:  5CVS-2005-04-19
 Assigned To:  andi
 New Comment:

No, I think it should output foo, baz, baz. Private property is to
behave for external functions as if it did not exist at all. However,
protected property is shared by the whole inheritance chain, so
redefining it means redefining it everywhere. 


Previous Comments:


[2005-04-19 16:19:11] [EMAIL PROTECTED]

foo, "\n";
}
}

class bar extends foo {
protected $foo = 'bar';

function printFoo2()
{
echo __CLASS__, ': ', $this->foo, "\n";
}
}

class baz extends bar {
protected $foo = 'baz';

function printFoo3()
{
echo __CLASS__, ': ', $this->foo, "\n";
}
}
$bar = new baz;
$bar->printFoo1();
$bar->printFoo2();
$bar->printFoo3();
?>

Outputs:
foo: baz
bar: baz
baz: baz

When it should output:
foo: foo
bar: bar
baz: baz

Right?




[2004-08-31 19:00:41] php dot net at benjamin dot schulz dot name

you don't get the point, the problem is that baz's protected $foo
overrides foo's private $foo, that should not happen

using parent::foo() is a common technique, and there is a $this because
it get's the context of the calling point



[2004-08-31 18:32:35] [EMAIL PROTECTED]

Please, be more verbose next time if you want to get any help. Your
conciseness doesn't help very much.
The problem is that you're trying to access class members through $this
variable using static methods. As you can understand in this case there
is no $this and behavior seems to be undefined (shouldn't there be an
error, btw?).



[2004-08-31 17:48:56] php dot net at benjamin dot schulz dot name

yep tony, you're right, and now read the bug report



[2004-08-31 16:24:10] [EMAIL PROTECTED]

Private members belong only to the class where they were defined and
cannot be inherited.



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

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

#33015 [Fbk->Opn]: ArrayObject: object- and array-access not interchangeable

2005-05-17 Thread pecoes at xs4all dot nl

 ID:   33015
 User updated by:  pecoes at xs4all dot nl
 Reported By:  pecoes at xs4all dot nl
-Status:   Feedback
+Status:   Open
 Bug Type: SPL related
 Operating System: *
 PHP Version:  5.*
 Assigned To:  helly
 New Comment:

What would "exchangeArray" do?


Previous Comments:


[2005-05-17 15:37:43] [EMAIL PROTECTED]

Yep it's me alone. I'll do something as soon as i find ime then. How
about some exchangeArray() method that drops the current array and
replaces it with the given one. So the following would do what you
want:

class ArrayObjectEx extends ArrayObject
{
  function __construct()
  {
$this->exchangeArray($this);
  }
}

$obj = new ArrayObjectEx;




[2005-05-17 13:42:33] pecoes at xs4all dot nl

Thanks for the offer, but I'm not in need of a work-around. IMHO it
would be great to have a "simple" solution - "simple" from a user's
perspective :)

You've created some pretty fascinating stuff with the SPL and from the
looks of it, you're doing this all alone right now, so I really don't
want to rush you... Just tell me how big the chances are in the long
run!



[2005-05-12 23:15:00] [EMAIL PROTECTED]

I could equip you with a special factory method or a derived class that
does this. But the way it works it is not possible to achieve what you
want with ArrayObject and its current constructor.



[2005-05-12 12:32:44] pecoes at xs4all dot nl

Description:

It's pretty counter-intuitive, that you can neither access an
ArrayObject's properties with the array-syntax, nor its array-values
with the object-syntax. I think these two should be interchangeable.
Preferably like in ECMAScript...

Reproduce code:
---
$a = new ArrayObject();

$a->one   = 1;
$a['two'] = 2;

echo "\$a->one: $a->one \$a->two: $a->two \n";
echo "\$a[one]: $a[one] \$a[two]: $a[two] \n";

Expected result:

$a->one: 1 $a->two: 2 
$a[one]: 1 $a[two]: 2 

Actual result:
--
$a->one: 1 $a->two:
$a[one]:  $a[two]: 2 





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

#33015 [Opn]: ArrayObject: object- and array-access not interchangeable

2005-05-17 Thread pecoes at xs4all dot nl

 ID:   33015
 User updated by:  pecoes at xs4all dot nl
 Reported By:  pecoes at xs4all dot nl
 Status:   Open
 Bug Type: SPL related
 Operating System: *
 PHP Version:  5.*
 Assigned To:  helly
 New Comment:

The problem is not in the constructor, is it?  __get should return
array-values as well and every offsetGet should return property-values
as well.


Previous Comments:


[2005-05-17 15:54:43] pecoes at xs4all dot nl

What would "exchangeArray" do?



[2005-05-17 15:37:43] [EMAIL PROTECTED]

Yep it's me alone. I'll do something as soon as i find ime then. How
about some exchangeArray() method that drops the current array and
replaces it with the given one. So the following would do what you
want:

class ArrayObjectEx extends ArrayObject
{
  function __construct()
  {
$this->exchangeArray($this);
  }
}

$obj = new ArrayObjectEx;




[2005-05-17 13:42:33] pecoes at xs4all dot nl

Thanks for the offer, but I'm not in need of a work-around. IMHO it
would be great to have a "simple" solution - "simple" from a user's
perspective :)

You've created some pretty fascinating stuff with the SPL and from the
looks of it, you're doing this all alone right now, so I really don't
want to rush you... Just tell me how big the chances are in the long
run!



[2005-05-12 23:15:00] [EMAIL PROTECTED]

I could equip you with a special factory method or a derived class that
does this. But the way it works it is not possible to achieve what you
want with ArrayObject and its current constructor.



[2005-05-12 12:32:44] pecoes at xs4all dot nl

Description:

It's pretty counter-intuitive, that you can neither access an
ArrayObject's properties with the array-syntax, nor its array-values
with the object-syntax. I think these two should be interchangeable.
Preferably like in ECMAScript...

Reproduce code:
---
$a = new ArrayObject();

$a->one   = 1;
$a['two'] = 2;

echo "\$a->one: $a->one \$a->two: $a->two \n";
echo "\$a[one]: $a[one] \$a[two]: $a[two] \n";

Expected result:

$a->one: 1 $a->two: 2 
$a[one]: 1 $a[two]: 2 

Actual result:
--
$a->one: 1 $a->two:
$a[one]:  $a[two]: 2 





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

#27891 [Opn->Fbk]: Bad behavior of require() function

2005-05-17 Thread sniper

 ID:   27891
 Updated by:   [EMAIL PROTECTED]
 Reported By:  faraco dot phpbugs at mailnull dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Zend Engine 2 problem
 Operating System: Windows NT4 SP6
 PHP Version:  5.0.4
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2005-05-16 22:34:47] faraco dot phpbugs at mailnull dot com

Another way to explain the problem...

Following de example above:

1. when I require 'lib/functions.php', the file is first looked in my
domain document root ['docroot/lib/'] and then in my actual path
['subroot/lib'] because if I delete the first directory, the same
script finds the second directory;

2. Yes, my 'include_path' is set to '.';

3. Again, ISAPI Caching is disabled.



[2005-05-16 22:07:13] faraco dot phpbugs at mailnull dot com

I've disabled ISAPI cache and the problem persists.



[2005-01-10 15:11:38] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2004-09-24 18:35:46] kj at legalizer dot dk

What if you turn off ISAPI caching?



[2004-04-06 15:21:29] faraco dot phpbugs at mailnull dot com

Here is the confirmation of the bug. Changing index.php to:
";
echo realpath("lib/functions.php");
?>

Expected result is:
E:\docroot\lib\functions.php
E:\docroot\subroot\lib\functions.php

While actual result is:
E:\docroot\lib\functions.php
E:\docroot\lib\functions.php



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

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

#33015 [Opn->Asn]: ArrayObject: object- and array-access not interchangeable

2005-05-17 Thread sniper

 ID:   33015
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pecoes at xs4all dot nl
-Status:   Open
+Status:   Assigned
 Bug Type: SPL related
 Operating System: *
 PHP Version:  5.*
 Assigned To:  helly


Previous Comments:


[2005-05-17 15:58:41] pecoes at xs4all dot nl

The problem is not in the constructor, is it?  __get should return
array-values as well and every offsetGet should return property-values
as well.



[2005-05-17 15:54:43] pecoes at xs4all dot nl

What would "exchangeArray" do?



[2005-05-17 15:37:43] [EMAIL PROTECTED]

Yep it's me alone. I'll do something as soon as i find ime then. How
about some exchangeArray() method that drops the current array and
replaces it with the given one. So the following would do what you
want:

class ArrayObjectEx extends ArrayObject
{
  function __construct()
  {
$this->exchangeArray($this);
  }
}

$obj = new ArrayObjectEx;




[2005-05-17 13:42:33] pecoes at xs4all dot nl

Thanks for the offer, but I'm not in need of a work-around. IMHO it
would be great to have a "simple" solution - "simple" from a user's
perspective :)

You've created some pretty fascinating stuff with the SPL and from the
looks of it, you're doing this all alone right now, so I really don't
want to rush you... Just tell me how big the chances are in the long
run!



[2005-05-12 23:15:00] [EMAIL PROTECTED]

I could equip you with a special factory method or a derived class that
does this. But the way it works it is not possible to achieve what you
want with ArrayObject and its current constructor.



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

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

#32857 [Opn->Fbk]: Correct SoapFaults encoded in SOAP Body does work if Axis sends HTTP error 500

2005-05-17 Thread sniper

 ID:   32857
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: SOAP related
 Operating System: Solaris 9
 PHP Version:  5CVS-2005-04-27 (dev)
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2005-04-27 20:04:46] [EMAIL PROTECTED]

Description:

After updating our application server to a Axis 1.2 (before it was Axis
1.1), the handling of SOAP faults in PHP does not work correct.
Axis 1.2 sends a HTTP server error 500 together with the XML body
containing the SoapFault with its error message (in Axis the Message of
a java.rmi.RemoteException).
Instead of throwing a correct exception containing the FaultString of
the XML body, PHP displays a "Internal Server Error" fault (I think
because he gets the 500 HTTP Error).
PHP should also handle "500" as valid response from SOAP if it contains
a correct XML body with SOAP envelope and decode it. If there is some
HTML or other non-XML in it (a "real" HTTP error) it can throw the
exeption with the server error like before.






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

#31618 [Opn->Fbk]: is_readable() results based on ownership of calling script, not file

2005-05-17 Thread sniper

 ID:   31618
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kibab at icehouse dot net
-Status:   Open
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: redhat enterprise
 PHP Version:  5CVS-2005-03-14
 New Comment:

What are the permissions of all the directories in that path?
(/var/lib/php_packages/)


Previous Comments:


[2005-01-20 22:32:24] kibab at icehouse dot net

Maybe this isn't directly related, but  
fopen($myfilename,"r") also fails, even though  
include($myfilename) works.  Again, $myfilename is in the  
safe_mode_include_dir, so fopen should be able to open it.



[2005-01-19 23:05:35] kibab at icehouse dot net

Description:

is_readable($myfilename) in the repro code returns true if 
the script calling it is owned by root, but false if it is 
owned by someone else.

Permissions are:   
-rw-r--r--1 root root 5452 Jan 13  
13:02 /var/lib/php_packages/test_templ2.php   
drwxr-xr-x4 root root 4096 Jan 19  
08:19 /var/lib/php_packages   
drwxr-xr-x   27 root root 4096 Jan 12  
09:27 /var/lib   
drwxr-xr-x   24 root root 4096 Sep 22  
13:06 /var   
drwxr-xr-x   20 root root 4096 Oct 29 09:48 /   
  
Relevant Settings:  
include_path = 
".:/var/lib/php_packages:/var/lib/php_packages/pear"  
safe_mode = On  
safe_mode_gid = On  
safe_mode_include_dir = /var/lib/php_packages 

Reproduce code:
---
 test.php ###
$myfilename = '/var/lib/php_packages/test_templ2.php';
if (is_readable($myfilename)) {
echo "is_readable: $myfilename (true)";
} else {
echo "is_readable: $myfilename (false)";
}
include($myfilename);

### test_templ2.php ###
TESTING!


Expected result:

I would expect is_readable() to return true in both  
instances.  The uid/gid check shouldn't matter despite  
safe mode, as the file is in safe_mode_include_dir, and 
even if it wasn't, the is_readable documentation says that 
it does NOT take into account safe_mode restrictions. 

Actual result:
--
// When test.php has the following ownership:
$ ls -l test.php 
-rw-rw-r--1 root root  278 Jan 19 13:16
test.php

// I get the following output:
is_readable: /var/lib/php_packages/test_templ2.php (true)
TESTING!   
   
// When test.php has the following permissions:   
$ ls -l test.php
-rw-rw-r--1 dschlegel79 undergradadmiss  278 Jan   
19 13:16 test.php   
   
// I get the following output:   
is_readable: /var/lib/php_packages/test_templ2.php (false)
TESTING!  





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

#31678 [Opn->Fbk]: ODBC Connection fails on Multiprocessor System

2005-05-17 Thread sniper

 ID:   31678
 Updated by:   [EMAIL PROTECTED]
 Reported By:  zipf dot mailcom at boewe-systec dot nospam dot de
-Status:   Open
+Status:   Feedback
 Bug Type: ODBC related
 Operating System: Windows 2000
 PHP Version:  5CVS, 4CVS (2005-02-05)
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2005-03-03 08:51:22] zipf dot mailcom at boewe-systec dot nospam dot
de

I tried to isolate the problem with a single page to narrow down that
error. but unfortunately the bug only happens in real life. I tried to
creat different crash pages wich request the same sql queries that our
real application does but so far i have not been able to reproduce that
error by a single page.
I cannot change all the database code to the pdo classes as this would
take to long, thats why I wanted to create a single page version so i
could test it.



[2005-02-14 20:27:19] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

You could try the new database stuff in PHP 5.

http://snaps.php.net/win32/PECL_5_0/php_pdo.dll
http://snaps.php.net/win32/PECL_5_0/php_pdo_odbc.dll

Documentation at: http://www.php.net/pdo

PDO is to be bundled with the PHP 5.1 release; it's currently in beta,
and has proven to be quite stable so far.
I'd really appreciate your feedback to see if PDO has the same issues
that you've found with the older ODBC extension.

If you decide to try PDO and run into problems, ask for help on
[EMAIL PROTECTED]; we're currently in aggressive beta/QA mode and
aim to turnaround bug fixes next-day if possible.




[2005-02-04 10:26:54] zipf dot mailcom at boewe-systec dot nospam dot
de

Ok we tested today with this development snapshot. it took a very long
time to get that error but it still occured. 
But this time apache didn´t respond at all after the crash. usually
apache was still serving requests, but this time there was no answer
anymore. We tested with IIS as well and it is the same behavior, so
this isn´t just apache related.

testing a dbcheck php page with commandline still works after the
crash.



[2005-02-03 05:17:52] [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

And I ask again:
Does this work on command line? (using PHP CLI binary..)

Using PHP CLI binary means the executably file (is it php.exe or
php-cli.exe in windows?) found in PHP distros..

Get the snapshot first.




[2005-01-24 11:54:47] zipf dot mailcom at boewe-systec dot nospam dot
de

A normal ODBC Connection still works. Just Apache/PHP cannot connect to
the database anymore.



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

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

#32857 [Fbk->Csd]: Correct SoapFaults encoded in SOAP Body does work if Axis sends HTTP error 500

2005-05-17 Thread [EMAIL PROTECTED]

 ID:   32857
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Closed
 Bug Type: SOAP related
 Operating System: Solaris 9
 PHP Version:  5CVS-2005-04-27 (dev)
 New Comment:

Works since Dmitry's last change:
http://cvs.php.net/diff.php/php-src/ext/soap/php_http.c?r1=1.55.2.14&r2=1.55.2.15&ty=h
Tested this on Saturday but forgot to close this bug.


Previous Comments:


[2005-05-17 17:16:04] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-04-27 20:04:46] [EMAIL PROTECTED]

Description:

After updating our application server to a Axis 1.2 (before it was Axis
1.1), the handling of SOAP faults in PHP does not work correct.
Axis 1.2 sends a HTTP server error 500 together with the XML body
containing the SoapFault with its error message (in Axis the Message of
a java.rmi.RemoteException).
Instead of throwing a correct exception containing the FaultString of
the XML body, PHP displays a "Internal Server Error" fault (I think
because he gets the 500 HTTP Error).
PHP should also handle "500" as valid response from SOAP if it contains
a correct XML body with SOAP envelope and decode it. If there is some
HTML or other non-XML in it (a "real" HTTP error) it can throw the
exeption with the server error like before.






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

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

2005-05-17 Thread jspec at bellsouth dot net

 ID:   25876
 Comment by:   jspec at bellsouth dot net
 Reported By:  golden at riscom dot com
 Status:   No Feedback
 Bug Type: Session related
 Operating System: freebsd 4.8
 PHP Version:  4.3.9-4.3.10
 Assigned To:  sniper
 New Comment:

My hosting company is unable to fix the random "Failed to initialize
storage module" error and it is making my account unusable.  They
cannot seem to fix it.  What is the story with this!?


Previous Comments:


[2005-04-29 11:04:06] dmih at in-solve dot ru

Please kindly pay attention to this bug.
It is REAL bug, not fantasy of 100+ man. Random session handler error.

No Feedback status is surely lame for this, as you are getting
feedback.
There is no reproduce code because bug is "random bug under heavy load"
class.

We hope for you.
Thanks.



[2005-04-08 19:03:08] todd dot trann at palidar dot com

RedHat 9
PHP 4.3.9 from RPM (php-4.3.9-11.rh90.art)
Zend Engine 1.3.0, Optimizer 2.5.5

I am experiencing the same problem: the error indicates storage module
"user", yet php.ini has it set to "files", and nowhere in my code do I
change it to "user".

The problem comes and goes as the page is reloaded.  A PHP page with no
session code does not exhibit the problem.

My /tmp directory is world writable.

Todd



[2005-04-02 16:21:52] tj at tjshafer dot com

I am also having this problem

Freebsd 4.8
php 4.3.10



[2005-03-31 03:00:43] james at westcoastbmx dot com

i have this problem as well.

as long as:
   php_value session.save_handleruser
is in my .htaccess file

session_start(); 

will not work.



[2005-03-28 19:27:40] clix at theclixnetwork dot com

A client of mine is having the same problem. The script uses:

session_start();
session_register('susername');
session_register('spassword');
session_register('sreferer');
session_register('susecode');

No destroy or anything special. If $username is set, than it sets the
session $susername to $username. He tried accessing the page within a
short time period after me, both passing the same username. However
when I access it again it doesn't give me the 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/25876

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

#33047 [NEW]: glob() doesn't work inside directories with brackets [ ]

2005-05-17 Thread wiseman1024 at gmail dot com

From: wiseman1024 at gmail dot com
Operating system: Windows 2000
PHP version:  4.3.9
PHP Bug Type: Directory function related
Bug description:  glob() doesn't work inside directories with brackets [ ]

Description:

glob() won't work (with any pattern and options whatsoever) when one
directory in the current working path has matching brackets [ and ] with
characters between the brackets.

This means glob() will fail if the current working directory is one of:
C:\php\[hello]
C:\php\[hello]\hello
C:\php\xxx[hello]xxx
C:\php\[hello][

It will work, for example, if the current working directory is one of:
C:\php
C:\php\[hello
C:\php\hello]
C:\php\hello[]

This seems to be a problem when using regular expressions in the
implementation of glob.

Reproduce code:
---
/* Returns a list of files and directories, unless inside a directory with
something between brackets*/

print_r(glob('*',FALSE)); 

Expected result:

Should always return an array with the files (assuming there are files in
the current directory)

Actual result:
--
Nothing, because glob() returned false

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

#33040 [Fbk->Opn]: make test fails ( Array to string conversion ) - missing directory in 4.3.11

2005-05-17 Thread chronoton at directbox dot com

 ID:   33040
 User updated by:  chronoton at directbox dot com
 Reported By:  chronoton at directbox dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Warning
 Operating System: Gentoo ( 2.4 )
 PHP Version:  4.3.11
 New Comment:

./configure --with-apxs=/usr/local/apache/1.3.33/bin/apxs
--with-mysql=/usr --with-pgsql=/usr --with-pdflib=/usr
--with-zlib-dir=/usr --enable-versioning --enable-calendar
--with-freetype-dir=/usr --with-imap=/usr --with-jpeg=/usr
--with-zlib=/usr --with-gd --with-config-file-path=/etc
--with-openssl=/usr --with-ftp --enable-exif --with-mcrypt=/usr
--enable-url-includes --enable-track-vars=yes --enable-sysvshm=yes
--enable-sysvsem=yes --enable-bcmath


Previous Comments:


[2005-05-16 09:10:54] [EMAIL PROTECTED]

What was the configure line you used?




[2005-05-16 08:57:02] chronoton at directbox dot com

It is not an essential problem, but still a nice to have after building
from scratch.

thanks and keep up the spirits,

Kamil Wencel



[2005-05-16 08:51:07] chronoton at directbox dot com

Description:

make test fails due to a missing directory :

stargazer php-4.3.11 # make test

Notice: Array to string conversion in
/usr/local/src/apep/php-4.3.11/run-tests.php on line 851

[...]

Notice: Array to string conversion in
/usr/local/src/apep/php-4.3.11/run-tests.php on line 851

=
CWD : /usr/local/src/apep/php-4.3.11
PHP : /usr/local/src/apep/php-4.3.11/sapi/cli/php
PHP_SAPI: cli
PHP_VERSION : 4.3.11
ZEND_VERSION: 1.3.0
PHP_OS  : Linux - Linux stargazer.chronotech.org 2.4.19-gentoo-r9
#2 SMP Mon Oct 7 00:56:16 CEST 2002 i686
INI actual  : /usr/local/Zend/etc/php.ini
More .INIs  :
Extra dirs  :
=

Warning: opendir(/usr/local/src/apep/php-4.3.11/Array): failed to open
dir: No such file or directory in
/usr/local/src/apep/php-4.3.11/run-tests.php on line 238
ERROR: cannot open directory: /usr/local/src/apep/php-4.3.11/Array
make: [test] Error 1 (ignored)







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

#33040 [Opn]: make test fails ( Array to string conversion ) - missing directory in 4.3.11

2005-05-17 Thread chronoton at directbox dot com

 ID:   33040
 User updated by:  chronoton at directbox dot com
 Reported By:  chronoton at directbox dot com
 Status:   Open
 Bug Type: Compile Warning
 Operating System: Gentoo ( 2.4 )
 PHP Version:  4.3.11
 New Comment:

but I used that exact configure line for 4.3.x before...


Previous Comments:


[2005-05-17 20:19:52] chronoton at directbox dot com

./configure --with-apxs=/usr/local/apache/1.3.33/bin/apxs
--with-mysql=/usr --with-pgsql=/usr --with-pdflib=/usr
--with-zlib-dir=/usr --enable-versioning --enable-calendar
--with-freetype-dir=/usr --with-imap=/usr --with-jpeg=/usr
--with-zlib=/usr --with-gd --with-config-file-path=/etc
--with-openssl=/usr --with-ftp --enable-exif --with-mcrypt=/usr
--enable-url-includes --enable-track-vars=yes --enable-sysvshm=yes
--enable-sysvsem=yes --enable-bcmath



[2005-05-16 09:10:54] [EMAIL PROTECTED]

What was the configure line you used?




[2005-05-16 08:57:02] chronoton at directbox dot com

It is not an essential problem, but still a nice to have after building
from scratch.

thanks and keep up the spirits,

Kamil Wencel



[2005-05-16 08:51:07] chronoton at directbox dot com

Description:

make test fails due to a missing directory :

stargazer php-4.3.11 # make test

Notice: Array to string conversion in
/usr/local/src/apep/php-4.3.11/run-tests.php on line 851

[...]

Notice: Array to string conversion in
/usr/local/src/apep/php-4.3.11/run-tests.php on line 851

=
CWD : /usr/local/src/apep/php-4.3.11
PHP : /usr/local/src/apep/php-4.3.11/sapi/cli/php
PHP_SAPI: cli
PHP_VERSION : 4.3.11
ZEND_VERSION: 1.3.0
PHP_OS  : Linux - Linux stargazer.chronotech.org 2.4.19-gentoo-r9
#2 SMP Mon Oct 7 00:56:16 CEST 2002 i686
INI actual  : /usr/local/Zend/etc/php.ini
More .INIs  :
Extra dirs  :
=

Warning: opendir(/usr/local/src/apep/php-4.3.11/Array): failed to open
dir: No such file or directory in
/usr/local/src/apep/php-4.3.11/run-tests.php on line 238
ERROR: cannot open directory: /usr/local/src/apep/php-4.3.11/Array
make: [test] Error 1 (ignored)







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

#32802 [Asn->Csd]: General cookie overrides more specific cookie (path)

2005-05-17 Thread iliaa

 ID:   32802
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ast at gmx dot ch
-Status:   Assigned
+Status:   Closed
 Bug Type: HTTP related
 Operating System: *
 PHP Version:  4CVS-2005-05-17
 Assigned To:  ilia
 New Comment:

This bug has been fixed in CVS.

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




Previous Comments:


[2005-05-13 15:48:25] [EMAIL PROTECTED]

Ilia, I reverted the PHP4 version of your patch to fix this.It
seems to be fine in PHP5, but in PHP4 it is causing a segfault.  Could
you have another look?

See the backtrace in the commit message at:
http://cvs.php.net/php-src/main/php_variables.c?onb=1.45.2



[2005-04-24 20:50:45] [EMAIL PROTECTED]

This bug has been fixed in CVS.

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





[2005-04-24 16:25:15] ast at gmx dot ch

Your reproduce script does not describe this bug.
Your script describes a Server -> Browser issue.

This bug is about a Browser -> Server issue. The browser sends a Cookie
HTTP header with its request to the server.
The Cookie HTTP request header lists the cookies in the right order.
Cookies with more specific paths precede cookies with less specific
paths in the header string.

PHP populates the superglobal $_COOKIE with the wrong values when
reading/evaluating the Cookie HTTP header.

This The following reproduce script shows the PHP bug.
Please place it into document_root / test.

';
var_dump($_COOKIE);
echo '';
echo '$_SERVER[\'HTTP_COOKIE\'] lists the cookies in the correct order,
Value2 before Value1. It conforms to RFC 2965.';
var_dump($_SERVER['HTTP_COOKIE']);
echo '';

?>



[2005-04-24 14:01:21] [EMAIL PROTECTED]

Reproduce script:

';
var_dump($_COOKIE);
var_dump($_SERVER['HTTP_COOKIE']);  
echo '';

?>




[2005-04-24 03:21:37] ast at gmx dot ch

Here is a fix for my application. 

/**
 * Fix the superglobal $_COOKIE to conform with RFC 2965
 *
 * We don't use $_COOKIE[$cookiename], because it doesn't conform
to RFC 2965 (the
 * cookie standard), i.e. in $_COOKIE, we don't get the cookie with
the most specific path for
 * a given cookie name, we get the cookie with the least specific
cookie path.
 * This function does it exactly the other way around to conform
with the RFC.
 *
 * This function reevaluates the HTTP Cookie header and populates
$_COOKIE with the correct
 * cookies.
 *
 * @static
 */
function fixCookieVars() {
 if (isset($_SERVER['HTTP_COOKIE']) &&
!empty($_SERVER['HTTP_COOKIE'])) {
$allCookies = explode(';', $_SERVER['HTTP_COOKIE']);
/*
 * Get rid of less specific cookies if multiple cookies with 
the same
NAME
 * are present. Do this by going from left/first cookie to 
right/last
cookie.
 */
/* Reset the $_COOKIE array */
$_COOKIE = array();
/* Repopulate it, but now correctly */
foreach ($allCookies as $cookie) {
/* Split NAME [=VALUE], value is optional */
$cookie = explode('=', $cookie);
$key = preg_replace('|\s|', '', $cookie[0]);
$value = isset($cookie[1]) ? $cookie[1] : '';
if (!isset($_COOKIE[$key])) {
$_COOKIE[$key] = $value;
}
}
}
}
}



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/32802

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

#33047 [Opn->Fbk]: glob() doesn't work inside directories with brackets [ ]

2005-05-17 Thread iliaa

 ID:   33047
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wiseman1024 at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Directory function related
 Operating System: Windows 2000
 PHP Version:  4.3.9
 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:


[2005-05-17 18:09:30] wiseman1024 at gmail dot com

Description:

glob() won't work (with any pattern and options whatsoever) when one
directory in the current working path has matching brackets [ and ]
with characters between the brackets.

This means glob() will fail if the current working directory is one
of:
C:\php\[hello]
C:\php\[hello]\hello
C:\php\xxx[hello]xxx
C:\php\[hello][

It will work, for example, if the current working directory is one of:
C:\php
C:\php\[hello
C:\php\hello]
C:\php\hello[]

This seems to be a problem when using regular expressions in the
implementation of glob.

Reproduce code:
---
/* Returns a list of files and directories, unless inside a directory
with something between brackets*/

print_r(glob('*',FALSE)); 

Expected result:

Should always return an array with the files (assuming there are files
in the current directory)

Actual result:
--
Nothing, because glob() returned false





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

#32330 [Com]: session_destroy, "Failed to initialize storage module", custom session handler

2005-05-17 Thread semorales at segob dot gob dot mx

 ID:   32330
 Comment by:   semorales at segob dot gob dot mx
 Reported By:  [EMAIL PROTECTED]
 Status:   Assigned
 Bug Type: Session related
 Operating System: *
 PHP Version:  5CVS, 4CVS (2005-03-17)
 Assigned To:  sniper
 New Comment:

Any notice about this bug? I'm thinking about using the handler but I'm
afraid it will crash my server. Please let me know.


Previous Comments:


[2005-04-30 11:31:53] dmih at in-solve dot ru

I've added several notes as this bug (marked as bogus):

http://bugs.php.net/bug.php?id=32897

Please consider them, as it seems that it is about this bug really.
Thanks.



[2005-04-19 07:37:14] labsy at seznam dot org

Since this bug is non-persistent, it is very hard to reproduce.

Now, since I run PHP 5.0.2 as ISAPI module, I did a change and added
php5isapi.dll also as ISAPI FILTER under web site properties in IIS.
I don't have a slight idea what would that change, but it seems to
solve problem - I hope.



[2005-04-19 07:18:46] labsy at seznam dot org

I was experiencing this problem one year ago, but now it reoccured.
I run PHP 5.0.2 on Win 2000/IIS
I act as WebHosting provider, host about 170 domains.

Now, one thing that attracted my attention was, that one of my users
installed osCommerce portal few days ago. Since osCommerce handles
sessions its own way, it seems to corrupt session handling function in
PHP all over my server. Any file which has session_start() at the
beginning, needs to be loaded twice, first attempt to load page
produces the mentioned error, but after reload session initializes
normally.

I have
session.save_handler = files
session.save_path = "C:\PHP\sessiondata" ;this dir is world writeable
All my PHP files only use session_start() and $_SESSION[] variable
cals, no other session functions are used.

It worked fine, until one of my users installed osCommerce portal.



[2005-03-31 16:37:51] evenh+phpbug at pvv dot ntnu dot no

I experienced this one too, but only when using tavi.sourceforge.net.
This intrigued me, and I've developed a little script to give
information related to this issue.

The script at http://tavi.sourceforge.net/bug32330.php shows a counter
which jumps around at it own free will, seemingly. This due to the
changing host underneath, see changing $_SERVER['SERV_ADDR']. The
script always uses /tmp, and it's always writeable, but it's not on the
same computer!

This could be fixed by using a common path, as is done in
http://tavi.sourceforge.net/bug32330fix.php . And now the counter
works, and I don't get the "Failed to initialize..."-message either. 

The reason for not getting the message, I've experienced, could be
related to accidentially calling session_start() twice... Either in the
same script, or script running in concurrent time space. Or maybe the
lack of session_write_close()?

Note that both the supplied script would include phpinfo() if adding
"?a" (or anything at all) after the script name. The scripts will be
available for some weeks. Feel free to copy them if needed... ;-)

But the messages seems to have gone away, so I'm happy. For now.

Regards,
Even Holen



[2005-03-31 06:33:58] [EMAIL PROTECTED]

I don't see how this relates to my problem besides the error message. I
ask you guys kindly to open a new report about your specific problem.
Your problem has no relation to session handler loosing when calling
session_destroy.



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

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

#27891 [Fbk->Opn]: Bad behavior of require() function

2005-05-17 Thread faraco dot phpbugs at mailnull dot com

 ID:   27891
 User updated by:  faraco dot phpbugs at mailnull dot com
 Reported By:  faraco dot phpbugs at mailnull dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Zend Engine 2 problem
 Operating System: Windows NT4 SP6
-PHP Version:  5.0.4
+PHP Version:  5.1.0-dev
 New Comment:

The problem persists.


Previous Comments:


[2005-05-17 16:46:44] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-05-16 22:34:47] faraco dot phpbugs at mailnull dot com

Another way to explain the problem...

Following de example above:

1. when I require 'lib/functions.php', the file is first looked in my
domain document root ['docroot/lib/'] and then in my actual path
['subroot/lib'] because if I delete the first directory, the same
script finds the second directory;

2. Yes, my 'include_path' is set to '.';

3. Again, ISAPI Caching is disabled.



[2005-05-16 22:07:13] faraco dot phpbugs at mailnull dot com

I've disabled ISAPI cache and the problem persists.



[2004-09-24 18:35:46] kj at legalizer dot dk

What if you turn off ISAPI caching?



[2004-04-06 15:21:29] faraco dot phpbugs at mailnull dot com

Here is the confirmation of the bug. Changing index.php to:
";
echo realpath("lib/functions.php");
?>

Expected result is:
E:\docroot\lib\functions.php
E:\docroot\subroot\lib\functions.php

While actual result is:
E:\docroot\lib\functions.php
E:\docroot\lib\functions.php



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

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

#33015 [Asn]: ArrayObject: object- and array-access not interchangeable

2005-05-17 Thread pecoes at xs4all dot nl

 ID:   33015
 User updated by:  pecoes at xs4all dot nl
 Reported By:  pecoes at xs4all dot nl
 Status:   Assigned
 Bug Type: SPL related
 Operating System: *
 PHP Version:  5.*
 Assigned To:  helly
 New Comment:

Turns out the work-around is not terribly complicated:

class ArrayObject2 extends ArrayObject
{ 

function __set($prop, $val)
{
parent::offsetSet($prop, $val);
}

function __get($prop)
{
return parent::offsetGet($prop);
}
}

Could you turn that into the default behaviour?


Previous Comments:


[2005-05-17 15:58:41] pecoes at xs4all dot nl

The problem is not in the constructor, is it?  __get should return
array-values as well and every offsetGet should return property-values
as well.



[2005-05-17 15:54:43] pecoes at xs4all dot nl

What would "exchangeArray" do?



[2005-05-17 15:37:43] [EMAIL PROTECTED]

Yep it's me alone. I'll do something as soon as i find ime then. How
about some exchangeArray() method that drops the current array and
replaces it with the given one. So the following would do what you
want:

class ArrayObjectEx extends ArrayObject
{
  function __construct()
  {
$this->exchangeArray($this);
  }
}

$obj = new ArrayObjectEx;




[2005-05-17 13:42:33] pecoes at xs4all dot nl

Thanks for the offer, but I'm not in need of a work-around. IMHO it
would be great to have a "simple" solution - "simple" from a user's
perspective :)

You've created some pretty fascinating stuff with the SPL and from the
looks of it, you're doing this all alone right now, so I really don't
want to rush you... Just tell me how big the chances are in the long
run!



[2005-05-12 23:15:00] [EMAIL PROTECTED]

I could equip you with a special factory method or a derived class that
does this. But the way it works it is not possible to achieve what you
want with ArrayObject and its current constructor.



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

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

#33049 [NEW]: strval crashes php

2005-05-17 Thread Chronial at web dot de

From: Chronial at web dot de
Operating system: Windows XP/Windows 2003
PHP version:  4.3.11
PHP Bug Type: Reproducible crash
Bug description:  strval crashes php

Description:

This bug appeared on 2 machines running the same script:
WinXp php 4.3.7, apache 2.0.53
Win2003 php 4.3.7, apache 2.0.47
the win2k3 machine was then upgraded to apache 2.0.54 and afterwards to
php 4.3.11 - the bug appeared on all 3 setups.

Running some scripts from the db trought strval() made apache crash -
adding "\r\n" to the strings before using strval() fixed the problem.
(code was $text = strval($text); changed to $text =
strval($text."\r\n");)

No reproduce code, for I think the bug will only appear with the rest of
the script around it. It was definitely strval what caused the bug (dieing
before this line worked, dieing in the next line didn't stop apache from
crashing)

The apache log said something about m_alloc (not sure, happend at work, am
at home now)

Reproduce code:
---
$text = strval($text);

Expected result:

obvious

Actual result:
--
crash

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

#33050 [NEW]: Search Problem

2005-05-17 Thread admin at exesoftware dot com

From: admin at exesoftware dot com
Operating system: Irrelevant
PHP version:  5.0.4
PHP Bug Type: *General Issues
Bug description:  Search Problem

Description:

When you search for "move file" on php.net it doesn't come up with
rename() as a result. I think it should... I eventually found out about it
with a bunch of searching but that would make it alot easier for people in
the future. Thanks.


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

#33049 [Opn->Fbk]: strval crashes php

2005-05-17 Thread sniper

 ID:   33049
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Chronial at web dot de
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Windows XP/Windows 2003
 PHP Version:  4.3.11
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2005-05-17 23:05:11] Chronial at web dot de

Description:

This bug appeared on 2 machines running the same script:
WinXp php 4.3.7, apache 2.0.53
Win2003 php 4.3.7, apache 2.0.47
the win2k3 machine was then upgraded to apache 2.0.54 and afterwards to
php 4.3.11 - the bug appeared on all 3 setups.

Running some scripts from the db trought strval() made apache crash -
adding "\r\n" to the strings before using strval() fixed the problem.
(code was $text = strval($text); changed to $text =
strval($text."\r\n");)

No reproduce code, for I think the bug will only appear with the rest
of the script around it. It was definitely strval what caused the bug
(dieing before this line worked, dieing in the next line didn't stop
apache from crashing)

The apache log said something about m_alloc (not sure, happend at work,
am at home now)

Reproduce code:
---
$text = strval($text);

Expected result:

obvious

Actual result:
--
crash





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

#31222 [Opn->Fbk]: ocicommit not working

2005-05-17 Thread sniper

 ID:   31222
 Updated by:   [EMAIL PROTECTED]
 Reported By:  amonw at hotmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: OCI8 related
 Operating System: *
 PHP Version:  4CVS-2005-04-04
 Assigned To:  tony2001
 New Comment:

Please try using this CVS snapshot:

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

We really need to know if this is fixed in HEAD, so please try the
snapshot. Nobody is telling you should put it on PRODUCTION machine.
You do have some test/dev machines?!



Previous Comments:


[2005-05-17 07:09:52] amonw at hotmail dot com

I've tried the newest version of php4 but it can't solve my problem.
Please refer to my last 2 comments.



[2005-05-12 12:37:33] [EMAIL PROTECTED]

I'm not suggesting you to upgrade, I just want you to try newer
version.



[2005-04-29 05:15:01] amonw at hotmail dot com

Thank you for your suggestion. But I'm not ready to upgrade my system
to php5 because I don't have much time to modify the old codes to fit
in php5 yet.



[2005-04-28 12:56:06] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-04-26 04:20:18] amonw at hotmail dot com

I don't know why, but I upgrate my php again this morning to
php4-stable-200504260035, and the problem remains unchanged. I have
make the code as simple as possible, and as I mentioned in the first
comment, even some minor changes which seem not relevant may affect the
result, and I don't know why. I deeply appreciate your patiense and
please read my first post again. I can live with it if you are tired of
this because it takes so long.
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/31222

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

#33040 [Opn->Fbk]: make test fails ( Array to string conversion ) - missing directory in 4.3.11

2005-05-17 Thread sniper

 ID:   33040
 Updated by:   [EMAIL PROTECTED]
 Reported By:  chronoton at directbox dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Warning
 Operating System: Gentoo ( 2.4 )
 PHP Version:  4.3.11
 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

Need the current line number for the error.
Plus I must assume you know PHP? It's a PHP script, you should know how
to debug those.. :)



Previous Comments:


[2005-05-17 20:20:38] chronoton at directbox dot com

but I used that exact configure line for 4.3.x before...



[2005-05-17 20:19:52] chronoton at directbox dot com

./configure --with-apxs=/usr/local/apache/1.3.33/bin/apxs
--with-mysql=/usr --with-pgsql=/usr --with-pdflib=/usr
--with-zlib-dir=/usr --enable-versioning --enable-calendar
--with-freetype-dir=/usr --with-imap=/usr --with-jpeg=/usr
--with-zlib=/usr --with-gd --with-config-file-path=/etc
--with-openssl=/usr --with-ftp --enable-exif --with-mcrypt=/usr
--enable-url-includes --enable-track-vars=yes --enable-sysvshm=yes
--enable-sysvsem=yes --enable-bcmath



[2005-05-16 09:10:54] [EMAIL PROTECTED]

What was the configure line you used?




[2005-05-16 08:51:07] chronoton at directbox dot com

Description:

make test fails due to a missing directory :

stargazer php-4.3.11 # make test

Notice: Array to string conversion in
/usr/local/src/apep/php-4.3.11/run-tests.php on line 851

[...]

Notice: Array to string conversion in
/usr/local/src/apep/php-4.3.11/run-tests.php on line 851

=
CWD : /usr/local/src/apep/php-4.3.11
PHP : /usr/local/src/apep/php-4.3.11/sapi/cli/php
PHP_SAPI: cli
PHP_VERSION : 4.3.11
ZEND_VERSION: 1.3.0
PHP_OS  : Linux - Linux stargazer.chronotech.org 2.4.19-gentoo-r9
#2 SMP Mon Oct 7 00:56:16 CEST 2002 i686
INI actual  : /usr/local/Zend/etc/php.ini
More .INIs  :
Extra dirs  :
=

Warning: opendir(/usr/local/src/apep/php-4.3.11/Array): failed to open
dir: No such file or directory in
/usr/local/src/apep/php-4.3.11/run-tests.php on line 238
ERROR: cannot open directory: /usr/local/src/apep/php-4.3.11/Array
make: [test] Error 1 (ignored)







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

#31558 [Opn->Fbk]: "apachectl graceful" leaks

2005-05-17 Thread sniper

 ID:   31558
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jdw at nearlyfreespeech dot net
-Status:   Open
+Status:   Feedback
 Bug Type: Apache related
 Operating System: FreeBSD
 PHP Version:  4CVS-2005-01-21
 New Comment:

Yes it would. We're currently focused on PHP 5 development, and if you
really want stuff get fixed: Try the snapshot.
(if this happens in PHP 5.1-dev too, it's more likely to be fixed also
in the PHP_4_3 branch..)



Previous Comments:


[2005-05-17 14:11:36] jdw at nearlyfreespeech dot net

Um, as this is a PHP 4 bug, trying a PHP 5 snapshot would not seem to
be appropriate.



[2005-05-17 12:02:53] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-01-22 06:55:13] jdw at nearlyfreespeech dot net

I also looked at the source code.  Without a detailed understanding of
zend_hash_*, it isn't clear that all the per_dir_info malloc() cases in
sapi/apache/mod_php4.c (particularly php_value_handler_ex() ) are being
properly freed by php_destroy_per_dir_info().  That's just a WAG, but
it might be something to look into as a possible cause.



[2005-01-22 06:48:32] jdw at nearlyfreespeech dot net

This test has been completed.  I believe this graph of the results
pretty much speaks for itself:

http://example.nfshost.com/ApacheGracefulMem.png

Results:
- With PHP enabled, "graceful" leak averages 903,000 bytes
- With PHP disabled, "graceful" leak averages 8,900 bytes
- "No PHP" test memory usage *converges* (leaks are front-loaded and
poorly represented by the linear fit -- hard to see because of the
scale of the graph)
- "PHP" test memory usage *diverges* (increases linearly until process
limits intervene)

Methodology:
- Apache 1.3.33
- PHP version php4-STABLE-200501210130
- same Apache binary, same server, same conditions
- same conf file (with "LoadModule php4_module" "php_admin_value" and
"php_value" lines removed for the "No HP" test)
- 200 consecutive "graceful" restarts of Apache process
- considering only "master" process
- no requests issued during test



[2005-01-21 01:04:16] jdw at nearlyfreespeech dot net

Keep in mind that this is happen in the "master" Apache process, a
context in which no PHP scripts are ever executed.  In fact, very
little happens other than parsing config files.  That should severely
constrain the influence of libraries & extensions.

Apache obviously won't parse its configs with PHP disabled, and our
customers will (justifiably) riot if we turn it off. 
There are quite a large number of PHP-specific conf lines in a
proportional number of files (the reason I suspect our setup is finding
this earlier than the general population), so I'm not sure how feasible
your suggestion is.  

But I'm happy to see if I can rig something up on a test server to
explore it.  More to follow.

It would be more direct if there were a means to instrument the amount
of memory allocated at start vs. the amount freed at restart.

It would also be handy if there's someone around who can point me in
the right direction as to where in the PHP Apache SAPI code to find the
relevant setup/cleanup code.

Also, I now have a second backtrace, but I am hestitant to post it here
because it's even larger than the first one.  It's similar: died on a
"php_admin_value open_basedir" instead of "php_admin_value
max_execution_time."



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

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

#31558 [Fbk->Opn]: "apachectl graceful" leaks

2005-05-17 Thread jdw at nearlyfreespeech dot net

 ID:   31558
 User updated by:  jdw at nearlyfreespeech dot net
 Reported By:  jdw at nearlyfreespeech dot net
-Status:   Feedback
+Status:   Open
 Bug Type: Apache related
 Operating System: FreeBSD
 PHP Version:  4CVS-2005-01-21
 New Comment:

Interestingly, there is some evidence that this bug may be either
mitigated or fixed in 4.3.11.

We have also switched to using more shared modules, so it is also
possible that the leak still exists, but is related to a specific
extension that is now not being loaded by the "core" apache process
(causing the leak not to accrue across generations).  It may be
possible for us to investigate that possibility and provide more
information to rule it in or out.


Previous Comments:


[2005-05-18 00:16:04] [EMAIL PROTECTED]

Yes it would. We're currently focused on PHP 5 development, and if you
really want stuff get fixed: Try the snapshot.
(if this happens in PHP 5.1-dev too, it's more likely to be fixed also
in the PHP_4_3 branch..)




[2005-05-17 14:11:36] jdw at nearlyfreespeech dot net

Um, as this is a PHP 4 bug, trying a PHP 5 snapshot would not seem to
be appropriate.



[2005-05-17 12:02:53] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2005-01-22 06:55:13] jdw at nearlyfreespeech dot net

I also looked at the source code.  Without a detailed understanding of
zend_hash_*, it isn't clear that all the per_dir_info malloc() cases in
sapi/apache/mod_php4.c (particularly php_value_handler_ex() ) are being
properly freed by php_destroy_per_dir_info().  That's just a WAG, but
it might be something to look into as a possible cause.



[2005-01-22 06:48:32] jdw at nearlyfreespeech dot net

This test has been completed.  I believe this graph of the results
pretty much speaks for itself:

http://example.nfshost.com/ApacheGracefulMem.png

Results:
- With PHP enabled, "graceful" leak averages 903,000 bytes
- With PHP disabled, "graceful" leak averages 8,900 bytes
- "No PHP" test memory usage *converges* (leaks are front-loaded and
poorly represented by the linear fit -- hard to see because of the
scale of the graph)
- "PHP" test memory usage *diverges* (increases linearly until process
limits intervene)

Methodology:
- Apache 1.3.33
- PHP version php4-STABLE-200501210130
- same Apache binary, same server, same conditions
- same conf file (with "LoadModule php4_module" "php_admin_value" and
"php_value" lines removed for the "No HP" test)
- 200 consecutive "graceful" restarts of Apache process
- considering only "master" process
- no requests issued during test



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

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

#33051 [Opn]: display glitch for shmop test with firefox (weird returned ascii)

2005-05-17 Thread Trigunflame at gmail dot com

 ID:   33051
 User updated by:  Trigunflame at gmail dot com
 Reported By:  Trigunflame at gmail dot com
 Status:   Open
 Bug Type: Semaphore related
 Operating System: windows xp
 PHP Version:  5.0.4
 New Comment:

Should say [] are visible when viewing source.. which are appended
after the expected result string, yet cause a linebreak..


Previous Comments:


[2005-05-18 04:37:04] Trigunflame at gmail dot com

Description:

Using the code posted here:

http://us2.php.net/manual/en/ref.shmop.php

Generates a weird display glitch in firefox with [] brackets, and
causes linebreak.

Reproduce code:
---
 

Expected result:

SHM Block Size: 100 has been created. The data inside shared memory
was: my shared memory block

Actual result:
--
SHM Block Size: 100 has been created. The data inside shared memory
was: my shared memory 
block





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

#33051 [NEW]: display glitch for shmop test with firefox (weird returned ascii)

2005-05-17 Thread Trigunflame at gmail dot com

From: Trigunflame at gmail dot com
Operating system: windows xp
PHP version:  5.0.4
PHP Bug Type: Semaphore related
Bug description:  display glitch for shmop test with firefox (weird returned 
ascii)

Description:

Using the code posted here:

http://us2.php.net/manual/en/ref.shmop.php

Generates a weird display glitch in firefox with [] brackets, and causes
linebreak.

Reproduce code:
---
 

Expected result:

SHM Block Size: 100 has been created. The data inside shared memory was:
my shared memory block

Actual result:
--
SHM Block Size: 100 has been created. The data inside shared memory was:
my shared memory 
block

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

55 matches

Mail list logo