#21702 [Opn->WFx]: nested foreach on same array using reference fails

[derick]

 ID:   21702
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Wont fix
 Bug Type: Scripting Engine problem
 Operating System: Any
 PHP Version:  Any


Previous Comments:


[2003-01-22 00:21:28] [EMAIL PROTECTED]

I don't want to cause too much of a fuss about this -- but after
looking at it myself I do think it has some merit... There is no reason
why by simply adding a reference to the array in question the foreach()
statement should suddenly change it's behavior. I've seen "incorrect"
behaviors in ZE not be treated as bogus before (such as when working
with bit operations) -- this seems to fall under a simliar category. 

At the very least, it's a feature/change request. 





[2003-01-21 23:11:38] [EMAIL PROTECTED]

1. No
2. Yes
3. No




[2003-01-21 23:01:40] [EMAIL PROTECTED]

Reopening due to lack of evidence that this is not a bug. Derick has
not answered my email, he has not provided an explanation in his
bug-closing comment, I have not found any discussion about this in the
php-dev mailing list archive, and until recently, the behaviour has
been in direct contradiction with the manual (while now the manual is
unclear). Therefore, I have to assume that the statement "this is not a
bug" is unfounded. I thought that this was an open source project?

And even if the current behaviour was really intended, the
documentation needs to be clarified.

Let me ask three questions:
1) Is the current behaviour optimal?
2) If not, is it too late to correct it (because of backward
compatibility)?
3) If not, is it important enough to invest time in it?

My opinion: no, no, depends on who's time is in question. ;-)



[2003-01-17 12:12:19] [EMAIL PROTECTED]

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

not a bug



[2003-01-17 11:55:33] [EMAIL PROTECTED]

> No matter what you call this, as a convention of open-source
> projects, documentation is generally supposed to come up
> after coding stuff.

"Supposed to"? I hope not. It does, usually, that's true. But in this
case, there _was_ documentation, and the program doesn't conform to it.
And we're talking about language semantics, not something insignificant
like configuration options.

> the codes determine the design

Tell me which programming language interpreter or compiler was created
this way?

As for the other nastiness example that you provided, it certainly does
seem nasty. Should that mean "there is at least another one nastiness,
so that is a good enough excuse to make ad-hoc language design
decisions"? I don't get it.

And yes, a language design decision it is, and it must be made. Either
we correct the documentation (it's still not completely clear, though
at least it's not so undoubtedly incorrect as two months ago), or we
correct the implementation. Judging by the lack of interest so far
(this is only the second bug report that I know of, and the docs have
been incorrect for more than two years), not many people are relying on
the current (broken) behaviour. (Anyway, why would anyone rely on such
a thing?) Thus, we have a great opportunity to do the Right Thing!

Anyway, I'm leaving for the weekend right now, so don't close this bug
before I can have another round at it on Monday, ok? ;-)



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

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

#21702 [WFx->Opn]: nested foreach on same array using reference fails

[john]

 ID:   21702
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Wont fix
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Any
 PHP Version:  Any
 New Comment:

I don't want to cause too much of a fuss about this -- but after
looking at it myself I do think it has some merit... There is no reason
why by simply adding a reference to the array in question the foreach()
statement should suddenly change it's behavior. I've seen "incorrect"
behaviors in ZE not be treated as bogus before (such as when working
with bit operations) -- this seems to fall under a simliar category. 

At the very least, it's a feature/change request. 




Previous Comments:


[2003-01-21 23:11:38] [EMAIL PROTECTED]

1. No
2. Yes
3. No




[2003-01-21 23:01:40] [EMAIL PROTECTED]

Reopening due to lack of evidence that this is not a bug. Derick has
not answered my email, he has not provided an explanation in his
bug-closing comment, I have not found any discussion about this in the
php-dev mailing list archive, and until recently, the behaviour has
been in direct contradiction with the manual (while now the manual is
unclear). Therefore, I have to assume that the statement "this is not a
bug" is unfounded. I thought that this was an open source project?

And even if the current behaviour was really intended, the
documentation needs to be clarified.

Let me ask three questions:
1) Is the current behaviour optimal?
2) If not, is it too late to correct it (because of backward
compatibility)?
3) If not, is it important enough to invest time in it?

My opinion: no, no, depends on who's time is in question. ;-)



[2003-01-17 12:12:19] [EMAIL PROTECTED]

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

not a bug



[2003-01-17 11:55:33] [EMAIL PROTECTED]

> No matter what you call this, as a convention of open-source
> projects, documentation is generally supposed to come up
> after coding stuff.

"Supposed to"? I hope not. It does, usually, that's true. But in this
case, there _was_ documentation, and the program doesn't conform to it.
And we're talking about language semantics, not something insignificant
like configuration options.

> the codes determine the design

Tell me which programming language interpreter or compiler was created
this way?

As for the other nastiness example that you provided, it certainly does
seem nasty. Should that mean "there is at least another one nastiness,
so that is a good enough excuse to make ad-hoc language design
decisions"? I don't get it.

And yes, a language design decision it is, and it must be made. Either
we correct the documentation (it's still not completely clear, though
at least it's not so undoubtedly incorrect as two months ago), or we
correct the implementation. Judging by the lack of interest so far
(this is only the second bug report that I know of, and the docs have
been incorrect for more than two years), not many people are relying on
the current (broken) behaviour. (Anyway, why would anyone rely on such
a thing?) Thus, we have a great opportunity to do the Right Thing!

Anyway, I'm leaving for the weekend right now, so don't close this bug
before I can have another round at it on Monday, ok? ;-)



[2003-01-17 10:22:30] [EMAIL PROTECTED]

No matter what you call this, as a convention of open-source projects,
documentation is generally supposed to come up after coding stuff. In
other words, the codes determine the design, and the documents are
often elusive as there are some cases where they don't reflect the
actual behaviour.

Regarding the nastiness of references, it's special not only for
foreach, but also for the following case.



Surprisingly, this script results in
--
test
???
--
For more about this, see bug #20993 (this is also marked as a
doc-problem).




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

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

#21808 [Fbk->Bgs]: autoglobals won't work with a custom error page

[sniper]

 ID:   21808
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: linux apache 2.0.43
 PHP Version:  4.3.0
 New Comment:

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

Thank you for your interest in PHP.


This is normla behaviour wit Apache. Please read this:

http://httpd.apache.org/docs/custom-error.html

Not a bug.



Previous Comments:


[2003-01-21 18:57:22] [EMAIL PROTECTED]

Please provide the following pieces of information:

1) A link to a phpinfo(); page on your server.

2) The relevant source of the script which calls your error page.
(i.e.: header("Location: myerrorpage.php?arg=my+error+message"); )

3) The source to your error page.



[2003-01-21 16:01:02] [EMAIL PROTECTED]

Hiya

When i have an error page with php but requesting the error page with
an argument it won't show up in the scrip as $_REQUEST['arg'] or
something
The arg is however in the $_SERVER["REDIRECT_QUERY_STRING"] AND in the
$_SERVER["REQUEST_URI"]

Gr,

Wico




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

#21810 [Opn->Fbk]: Not able to start HP/Apache 2.0.43 php-4.2.2 with informix support

[sniper]

 ID:   21810
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Informix related
 Operating System: HP-UX 11.00
 PHP Version:  4.2.2
 New Comment:

Please try using this CVS snapshot:

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


Previous Comments:


[2003-01-21 18:19:33] [EMAIL PROTECTED]

Hi,

OS : HP-UX 11.00 32bit
Apache : HP Apache 2.0.43
 Server Built Oct 16 2002.
PHP: PHP-4.2.2
Informix: 7.2

 PHP-4.2.2 comes pre-complied with HP apache as dynamic module. 
When i tried to compile php with informix support, configure
and make goes fine. 

configured and compiled with following env. variables.

export IFX_LIBDIR="-L$INFORMIXDIR/lib -L$INFORMIXDIR/lib/esql"
export IFX_INCDIR="$INFORMIXDIR/incl/esql"
export IFX_LIBS="$INFORMIXDIR/lib/esql/libifsql.a \
$INFORMIXDIR/lib/libifasf.a \
$INFORMIXDIR/lib/esql/libifgen.a \
$INFORMIXDIR/lib/esql/libifos.a \
$INFORMIXDIR/lib/esql/libifgls.a \
-lgen -lgls -lm -ldl $INFORMIXDIR/lib/esql/checkapi.o \
$INFORMIXDIR/lib/esql/libifglx.a"
export
PATH=$PATH:.:/opt/bison/bin:/opt/binutils/bin:/opt/gcc/bin:/usr/local/bin



But when trying to start apache it gives following error.

# ./apachectl start
Syntax error on line 215 of /opt/hpapache2/conf/httpd.conf:
Cannot load /opt/hpapache2/modules/libphp4.so into server: Unresolved
symbol: ifx_checkAPI (code)  from /usr/informix/lib/esql/libthos.sl

I searched on this site for info and included the above libs in path
before configuring and making php. But still having same problem. Can
someone help me in solving this ?.

Thanks in advance.
Srini.







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

#21811 [Opn->Bgs]: Viewing files on disk

[sniper]

 ID:   21811
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Output Control
 Operating System: Linux
 PHP Version:  4.2.2
 New Comment:

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

Thank you for your interest in PHP.


You really need to ask this on some general mailing list..



Previous Comments:


[2003-01-21 18:44:11] [EMAIL PROTECTED]

Just to know if it correc to see /etc/passwd for example, I did a
simple script like this.

pag1.html



:-D







--
ensena.php
--

--
so you can put "/etc/passwd" and the it is showed, just wanna know if
this is correct..

Regards.




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

#21702 [Opn->WFx]: nested foreach on same array using reference fails

[sniper]

 ID:   21702
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Wont fix
 Bug Type: Scripting Engine problem
 Operating System: Any
 PHP Version:  Any
 New Comment:

1. No
2. Yes
3. No



Previous Comments:


[2003-01-21 23:01:40] [EMAIL PROTECTED]

Reopening due to lack of evidence that this is not a bug. Derick has
not answered my email, he has not provided an explanation in his
bug-closing comment, I have not found any discussion about this in the
php-dev mailing list archive, and until recently, the behaviour has
been in direct contradiction with the manual (while now the manual is
unclear). Therefore, I have to assume that the statement "this is not a
bug" is unfounded. I thought that this was an open source project?

And even if the current behaviour was really intended, the
documentation needs to be clarified.

Let me ask three questions:
1) Is the current behaviour optimal?
2) If not, is it too late to correct it (because of backward
compatibility)?
3) If not, is it important enough to invest time in it?

My opinion: no, no, depends on who's time is in question. ;-)



[2003-01-17 12:12:19] [EMAIL PROTECTED]

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

not a bug



[2003-01-17 11:55:33] [EMAIL PROTECTED]

> No matter what you call this, as a convention of open-source
> projects, documentation is generally supposed to come up
> after coding stuff.

"Supposed to"? I hope not. It does, usually, that's true. But in this
case, there _was_ documentation, and the program doesn't conform to it.
And we're talking about language semantics, not something insignificant
like configuration options.

> the codes determine the design

Tell me which programming language interpreter or compiler was created
this way?

As for the other nastiness example that you provided, it certainly does
seem nasty. Should that mean "there is at least another one nastiness,
so that is a good enough excuse to make ad-hoc language design
decisions"? I don't get it.

And yes, a language design decision it is, and it must be made. Either
we correct the documentation (it's still not completely clear, though
at least it's not so undoubtedly incorrect as two months ago), or we
correct the implementation. Judging by the lack of interest so far
(this is only the second bug report that I know of, and the docs have
been incorrect for more than two years), not many people are relying on
the current (broken) behaviour. (Anyway, why would anyone rely on such
a thing?) Thus, we have a great opportunity to do the Right Thing!

Anyway, I'm leaving for the weekend right now, so don't close this bug
before I can have another round at it on Monday, ok? ;-)



[2003-01-17 10:22:30] [EMAIL PROTECTED]

No matter what you call this, as a convention of open-source projects,
documentation is generally supposed to come up after coding stuff. In
other words, the codes determine the design, and the documents are
often elusive as there are some cases where they don't reflect the
actual behaviour.

Regarding the nastiness of references, it's special not only for
foreach, but also for the following case.



Surprisingly, this script results in
--
test
???
--
For more about this, see bug #20993 (this is also marked as a
doc-problem).




[2003-01-17 08:27:40] [EMAIL PROTECTED]

> Although I admit that the behaviour is quite inconsistent,
> we won't fix this anyway because the issue's all up to the
> language design.

Well, I dunno. In bug #8353, [EMAIL PROTECTED] says: "...the following
note exists in the foreach() entry of the manual and has for over two
years:

Note:  Also note that foreach operates on a copy of the specified
array, not the array itself, therefore the array pointer is not
modified as with the each()  construct and changes to the array element
returned are not reflected in the original array."

The documentation has been changed very recently.

To me, this seems like re-defining the language. (Or "changing the
rules in the middle of the game", if you prefer.) Instead of fixing the
bug, you say it's a feature and change the docs. That seems very
Microsoft-ish. Plus, such a language construct is inconsistent,
unintuitive and seriously limited in usability.

> foreach statement always makes use of a copy of the given
> array instead of the original itself unless the

#21702 [Bgs->Opn]: nested foreach on same array using reference fails

[vdvo]

 ID:   21702
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Any
 PHP Version:  Any
 New Comment:

Reopening due to lack of evidence that this is not a bug. Derick has
not answered my email, he has not provided an explanation in his
bug-closing comment, I have not found any discussion about this in the
php-dev mailing list archive, and until recently, the behaviour has
been in direct contradiction with the manual (while now the manual is
unclear). Therefore, I have to assume that the statement "this is not a
bug" is unfounded. I thought that this was an open source project?

And even if the current behaviour was really intended, the
documentation needs to be clarified.

Let me ask three questions:
1) Is the current behaviour optimal?
2) If not, is it too late to correct it (because of backward
compatibility)?
3) If not, is it important enough to invest time in it?

My opinion: no, no, depends on who's time is in question. ;-)


Previous Comments:


[2003-01-17 12:12:19] [EMAIL PROTECTED]

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

not a bug



[2003-01-17 11:55:33] [EMAIL PROTECTED]

> No matter what you call this, as a convention of open-source
> projects, documentation is generally supposed to come up
> after coding stuff.

"Supposed to"? I hope not. It does, usually, that's true. But in this
case, there _was_ documentation, and the program doesn't conform to it.
And we're talking about language semantics, not something insignificant
like configuration options.

> the codes determine the design

Tell me which programming language interpreter or compiler was created
this way?

As for the other nastiness example that you provided, it certainly does
seem nasty. Should that mean "there is at least another one nastiness,
so that is a good enough excuse to make ad-hoc language design
decisions"? I don't get it.

And yes, a language design decision it is, and it must be made. Either
we correct the documentation (it's still not completely clear, though
at least it's not so undoubtedly incorrect as two months ago), or we
correct the implementation. Judging by the lack of interest so far
(this is only the second bug report that I know of, and the docs have
been incorrect for more than two years), not many people are relying on
the current (broken) behaviour. (Anyway, why would anyone rely on such
a thing?) Thus, we have a great opportunity to do the Right Thing!

Anyway, I'm leaving for the weekend right now, so don't close this bug
before I can have another round at it on Monday, ok? ;-)



[2003-01-17 10:22:30] [EMAIL PROTECTED]

No matter what you call this, as a convention of open-source projects,
documentation is generally supposed to come up after coding stuff. In
other words, the codes determine the design, and the documents are
often elusive as there are some cases where they don't reflect the
actual behaviour.

Regarding the nastiness of references, it's special not only for
foreach, but also for the following case.



Surprisingly, this script results in
--
test
???
--
For more about this, see bug #20993 (this is also marked as a
doc-problem).




[2003-01-17 08:27:40] [EMAIL PROTECTED]

> Although I admit that the behaviour is quite inconsistent,
> we won't fix this anyway because the issue's all up to the
> language design.

Well, I dunno. In bug #8353, [EMAIL PROTECTED] says: "...the following
note exists in the foreach() entry of the manual and has for over two
years:

Note:  Also note that foreach operates on a copy of the specified
array, not the array itself, therefore the array pointer is not
modified as with the each()  construct and changes to the array element
returned are not reflected in the original array."

The documentation has been changed very recently.

To me, this seems like re-defining the language. (Or "changing the
rules in the middle of the game", if you prefer.) Instead of fixing the
bug, you say it's a feature and change the docs. That seems very
Microsoft-ish. Plus, such a language construct is inconsistent,
unintuitive and seriously limited in usability.

> foreach statement always makes use of a copy of the given
> array instead of the original itself unless the array is a
> reference or has a reference.

The "makes a copy" part is in the docs, and is what I expect. The
"unless..." part is (still) 

#21674 [Opn]: Warning: main(lang.php) [function.main]: failed to create stream: No such file

[moderator]

 ID:   21674
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: *URL Functions
 Operating System: Cobalt RAQ4 Apache/Linux
 PHP Version:  4.3.0
 New Comment:

Hello PHP.NET:

So is this bug a stream related 4.3.0 bug or not?


Previous Comments:


[2003-01-18 02:31:51] [EMAIL PROTECTED]

Did you try ? :

chown o+r / /home /home/sites \
   /home/sites/site2 \
   /home/sites/site2/web \
   /home/sites/site2/web/IV

Up to 4.2.3 "x" permission is need on ALL directories to the include.
Since 4.3.0 "rx" permissions are required.

Don't know why. 

Cordialy.



[2003-01-17 15:59:32] [EMAIL PROTECTED]

You did not ask me to place above line that include fails. You asked me
to place above require_once in the config.php file. That I can confirm.



[2003-01-17 14:23:11] [EMAIL PROTECTED]

and can you confirm that the var_dump(ini_get('include_path')) is on
the line immediately above the include that fails?

I'm asking because the line numbers in the report don't seem to have
changed, and I would have expected them to at least have increased by
1.





[2003-01-17 14:11:08] [EMAIL PROTECTED]

OK. At your request, here are my results.

string(14) ".:/usr/lib/php" string(14) ".:/usr/lib/php" 
Warning: main(lang.php) [function.main]: failed to create stream: No
such file or directory in /home/sites/site2/web/IV/config.php on line
97

Warning: main() [function.main]: Failed opening 'lang.php' for
inclusion (include_path='') in /home/sites/site2/web/IV/config.php on
line 97

Warning: main(extras.php) [function.main]: failed to create stream: No
such file or directory in /home/sites/site2/web/IV/config.php on line
98

Warning: main() [function.main]: Failed opening 'extras.php' for
inclusion (include_path='') in /home/sites/site2/web/IV/config.php on
line 98
Hello - Testing PHP 4.3.0 bug# 21674// End - Copy and Save this code as
phpbug21674.php



[2003-01-17 14:03:24] [EMAIL PROTECTED]

Please try what I asked :)
You say that the include path is ".:/usr/lib/php", but the error
message is indicating that it is "".
So we need to determine if this is a misconfiguration error, or if it
is some other error.
Printing out the value from the config.php file will help determine if
the problem is in streams itself or if it is perhaps a wider issue.



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

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

#21653 [Com]: Warning: fsockopen() [function.fsockopen]: php_hostconnect: connect failed

[dino]

 ID:   21653
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Sockets related
 Operating System: RedHat 7.2
 PHP Version:  4.3.0
 New Comment:

I update my Install Shell Script for the new version Redhat 8.0, I only
use Apache/ModSSL/OpenSSL and PHP with MySQL for start and enable
sockets but sockets don't work, previous version work great [Note I
make the Socket work great since Redhat 6.2 and early version of PHP
4.X.X]

Here is the Script:


#!/bin/sh
# Traigamos los archivos necesarios.

# Traigamos PHP
# Version: 4.3.0
wget http://us2.php.net/distributions/php-4.3.0.tar.gz

# Traigamos Apache
# Version: 1.3.27
wget http://mirrors.ccs.neu.edu/Apache/dist/httpd/apache_1.3.27.tar.gz

# Traigamos OpenSSL
# Version: 0.9.7
wget http://www.openssl.org/source/openssl-0.9.7.tar.gz

# Traigamos ModSSL
# Version: 2.8.9-1.3.27
wget http://www.modssl.org/source/mod_ssl-2.8.12-1.3.27.tar.gz

# Traigamos GD Boutell
# Version: gd-1.8.4
# Ya incluida en PHP 4.3.0 Pero si usas 4.2.3 baja la libreria
# wget http://www.boutell.com/gd/http/gd-1.8.4.tar.gz

# Traigamos PDF Lib
# Version: 4.0.2
# wget http://www.pdflib.com/pdflib/download/pdflib-4.0.2-Linux.tar.gz

# Traigamos SWF
# Version: 0.99
# ftp://ftp.sgi.com/sgi/graphics/grafica/flash/dist.99.linux.tar.Z
# Require swf.tar.gz .

# Traigamos Ming
# Version: 0.2a
# wget http://www.opaque.net/ming/ming-0.2a.tgz

# Descomprimimos todos los Archivos.
echo " =>   Extracting FILE PHP-APACHE-PHP-SSL";
tar -zxf php-4.3.0.tar.gz
echo " =>   Extracting PHP OK";
tar -zxf apache_1.3.27.tar.gz
echo " =>   Extracting APACHE OK";
tar -zxf openssl-0.9.7.tar.gz
echo " =>   Extracting OPENSSL OK";
tar -zxf mod_ssl-2.8.12-1.3.27.tar.gz
echo " =>   Extracting MODSSL OK";

# instalamos openssl
cd openssl-0.9.7
make clean
./config --prefix=/usr/local/openssl
make
make test
make install
cd ..
echo " => Install [ OPENSSL OK ] ";



# instalamos modssl
cd mod_ssl-2.8.12-1.3.27
make clean
./configure --with-apache=../apache_1.3.27
cd ..
echo " => Install [ MODSSL OK ] ";

# Configuracion Inicial de Apache
cd apache_1.3.27
make clean
./configure --prefix=/usr/local/apache
cd ..
echo " => Install [ APACHE INITIAL  OK ] ";


# Configuracion e Instalacion de PHP
cd php-4.3.0
make clean
CFLAGS='-O2 -I/usr/local/openssl/include' \
./configure \
--with-apache=../apache_1.3.27 \
--with-mysql \
--with-zlib  \
--enable-memory-limit=yes \
--enable-debug=no \
--enable-track-vars  \
--enable-snmp \
--enable-sockets \
--enable-ftp
make
make install
cd ..
echo " => Install [ PHP OK ] ";

# Instalacion de Apache
cd apache_1.3.27
SSL_BASE=/usr/local/openssl \
LIBS=-lpthread \
./configure \
--prefix=/usr/local/apache \
--enable-module=ssl \
--activate-module=src/modules/php4/libphp4.a \
--enable-module=php4 \
--enable-module=auth_dbm \
--enable-module=auth_db
make
make certificate
make install
cd ..
echo " => Install [ APACHE FINAL OK =) ] ";

cd php-4.3.0
cp php.ini-dist /usr/local/lib/php.ini
cd ..
echo " => [ THE END PHP/Apache/SSL/ModSSL Installed Successfully =)
D1n00z. ] ";


Best Regards Dino.
http://phpopenmonitor.sourceforge.net/


Previous Comments:


[2003-01-16 03:51:46] [EMAIL PROTECTED]

Yes there are always between 5 and 10 childs waiting for connections.



[2003-01-15 13:08:41] [EMAIL PROTECTED]

Doe your Webserver allow more then 1 Apache child to be running at any
one time?



[2003-01-15 04:30:31] [EMAIL PROTECTED]

Script:
-
\n";
}
fclose ($fp);
?>

Output:
-
Warning: fsockopen() [function.fsockopen]: php_hostconnect: connect
failed in /home/virtual/site1/fst/var/www/html/t5.php on line 2
Warning: fsockopen() [function.fsockopen]: unable to connect to
localhost:80 in /home/virtual/site1/fst/var/www/html/t5.php on line 2
Operation now in progress (115)
Warning: fclose(): supplied argument is not a valid stream resource in
/home/virtual/site1/fst/var/www/html/t5.php on line 6

Modules:
---
./configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib'
'--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--prefix=/usr'
'--with-config-file-path=/etc' '--enable-force-cgi-redirect'
'--disable-debug' '--enable-pic' '--disable-rpath'
'--enable-inline-optimization' '--with-bz2' '--with-db3'
'--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-png-dir=/usr'
'--with-gd' '--enable-gd-

#21813 [Opn]: OCIFetchInto() requires array result passed by reference

[philip]

 ID:   21813
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
-Bug Type: Documentation problem
+Bug Type: OCI8 related
 Operating System: Windows 2000 SP3
 PHP Version:  4.2.3
 New Comment:

Considering this function relies on a deprecated feature, this a bug in
OCIFetchInto() itself.  Reclassified->Oci8 related.

>From the docs for allow_call_time_pass_reference:

"This method is deprecated and is likely to be unsupported in future
versions of PHP/Zend."

Also does @ suppress these type of warnings?


Previous Comments:


[2003-01-21 20:34:54] [EMAIL PROTECTED]

Currently, as of 1/21/03, the documentation states that the result
array used with OCIFetchInto() must be passed by reference.  Since this
has changed after 4.2.0(?) and is not required (generating warnings),
the documentation should be updated to explain which particular
version(s) will see this phenomenon, especially for those who are
upgrading or testing against multiple versions.

I understand that a note has been included by a user about this
problem, but the note is not clear on the versions affected or when the
change was made.

I am using PHP Version 4.2.3 on System Windows NT 5.0 build 2195 in CGI
mode only loading the php_oci8.dll module.




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

#21812 [Opn]: Apache crashes when require_once has array in directory name

[pmoulding]

 ID:   21812
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Win2000
 PHP Version:  4.3.0
 New Comment:

memory_limit = 80M
in php.ini fixed the XML process error. It can now read the full XML
file without blowing up Apache.


Previous Comments:


[2003-01-21 21:07:24] [EMAIL PROTECTED]

I found a new error causing the same error message from Apache 2. This
error is from an XML processing loop. I think the Apache 2 error
message must be issued any time Apache runs out of memory. Perhaps PHP
is trampling over the end of it's memory allocation or something
similar.

I will try a few more tests then increase PHP's memory allocation in
php.ini and see if that fixes the problem.



[2003-01-21 20:26:06] [EMAIL PROTECTED]

require_once();
Parse error: parse error, unexpected ')' in C:\webapps\display.php on
line 10


require_once('');
Fatal error: main() [function.main]: Failed opening required ''
(include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10


require_once('cc');
Warning: main(cc) [function.main]: failed to create stream: No such
file or directory in C:\webapps\display.php on line 10

Fatal error: main() [function.main]: Failed opening required 'cc'
(include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10



require_once(array('cc'));
Notice: Array to string conversion in C:\webapps\display.php on line
10

Warning: main(Array) [function.main]: failed to create stream: No such
file or directory in C:\webapps\display.php on line 10

Fatal error: main() [function.main]: Failed opening required 'Array'
(include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10



The error does not occur when require_once() receives a simple non
string. The error occured when the non string was an array of varied
elements including other arrays and possibly objects. The error occured
repeatedly until I found the offending assignment statement.

I tried to reproduce the error on the first require_once in the script
but did not succeed. The original error was deep in a script with
several requires and some requires including scripts containing
requires. I have now changed the script to a less complicated set of
requires and may not be able to reproduce the depth.

It is possible the crash was caused by the requires looping on
themselves but that type of error usually requires a second or two
before Apache runs out of memory (currently over 500 Mb free). The
crashes were instant.

php.ini has nothing set to increase available memory or change safe
mode or anything else. It runs as a module.



[2003-01-21 19:38:21] [EMAIL PROTECTED]

Sorry, I just mistook the platform is *nix.
As I can't reproduce this on my Linux box, this problem is likely to
be Windows specific.

Does Apache segfault when giving a non-existent file name to
require_once()
rather than an array?




[2003-01-21 19:24:28] [EMAIL PROTECTED]

I looked at the instructions for backtrace. They do not translate to
Win2000. I will install Cygwin and see if the instructions work with
Win2000 Cygwin.

Our Unix systems have old releases of PHP and Apache so it might be a
while before I can reproduce the test on Unix.



[2003-01-21 19:10:21] [EMAIL PROTECTED]

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

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





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

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

#21812 [Opn]: Apache crashes when require_once has array in directory name

[pmoulding]

 ID:   21812
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Win2000
 PHP Version:  4.3.0
 New Comment:

I found a new error causing the same error message from Apache 2. This
error is from an XML processing loop. I think the Apache 2 error
message must be issued any time Apache runs out of memory. Perhaps PHP
is trampling over the end of it's memory allocation or something
similar.

I will try a few more tests then increase PHP's memory allocation in
php.ini and see if that fixes the problem.


Previous Comments:


[2003-01-21 20:26:06] [EMAIL PROTECTED]

require_once();
Parse error: parse error, unexpected ')' in C:\webapps\display.php on
line 10


require_once('');
Fatal error: main() [function.main]: Failed opening required ''
(include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10


require_once('cc');
Warning: main(cc) [function.main]: failed to create stream: No such
file or directory in C:\webapps\display.php on line 10

Fatal error: main() [function.main]: Failed opening required 'cc'
(include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10



require_once(array('cc'));
Notice: Array to string conversion in C:\webapps\display.php on line
10

Warning: main(Array) [function.main]: failed to create stream: No such
file or directory in C:\webapps\display.php on line 10

Fatal error: main() [function.main]: Failed opening required 'Array'
(include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10



The error does not occur when require_once() receives a simple non
string. The error occured when the non string was an array of varied
elements including other arrays and possibly objects. The error occured
repeatedly until I found the offending assignment statement.

I tried to reproduce the error on the first require_once in the script
but did not succeed. The original error was deep in a script with
several requires and some requires including scripts containing
requires. I have now changed the script to a less complicated set of
requires and may not be able to reproduce the depth.

It is possible the crash was caused by the requires looping on
themselves but that type of error usually requires a second or two
before Apache runs out of memory (currently over 500 Mb free). The
crashes were instant.

php.ini has nothing set to increase available memory or change safe
mode or anything else. It runs as a module.



[2003-01-21 19:38:21] [EMAIL PROTECTED]

Sorry, I just mistook the platform is *nix.
As I can't reproduce this on my Linux box, this problem is likely to
be Windows specific.

Does Apache segfault when giving a non-existent file name to
require_once()
rather than an array?




[2003-01-21 19:24:28] [EMAIL PROTECTED]

I looked at the instructions for backtrace. They do not translate to
Win2000. I will install Cygwin and see if the instructions work with
Win2000 Cygwin.

Our Unix systems have old releases of PHP and Apache so it might be a
while before I can reproduce the test on Unix.



[2003-01-21 19:10:21] [EMAIL PROTECTED]

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

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





[2003-01-21 19:03:46] [EMAIL PROTECTED]

I had
$common = 'common/';
at the top of the script and
require_once($common . 'x.html');
in the middle of the script and it worked.

Later I accidentally set $common to a multidimentinal array prior to
it's use in require_once. Apache 2.0.43 crashed when I used the script.
PHP did not produce an error message.

Apache is not producing any other errors. Everything else in my scripts
work including Sablotron. 4.3.0 is stable with Apache 2 on both my NT
and Win2000 systems. I have not tried this script error on Apache 1.

A search of the bug database found some old entries from the year 2000
marked "Fixed in CVS" so I guess they are not refering to PHP 4.3.0.

The Apache log contained the following entry. The status code of
3221225477 is listed on web pages against a dozen different errors.

[Wed Jan 22 11:31:36 2003] [notice] Parent: Created child process 2128
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Child process is
running
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Acq

#21812 [Fbk->Opn]: Apache crashes when require_once has array in directory name

[pmoulding]

 ID:   21812
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Win2000
 PHP Version:  4.3.0
 New Comment:

require_once();
Parse error: parse error, unexpected ')' in C:\webapps\display.php on
line 10


require_once('');
Fatal error: main() [function.main]: Failed opening required ''
(include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10


require_once('cc');
Warning: main(cc) [function.main]: failed to create stream: No such
file or directory in C:\webapps\display.php on line 10

Fatal error: main() [function.main]: Failed opening required 'cc'
(include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10



require_once(array('cc'));
Notice: Array to string conversion in C:\webapps\display.php on line
10

Warning: main(Array) [function.main]: failed to create stream: No such
file or directory in C:\webapps\display.php on line 10

Fatal error: main() [function.main]: Failed opening required 'Array'
(include_path='.;c:/include;c:/') in C:\webapps\display.php on line 10



The error does not occur when require_once() receives a simple non
string. The error occured when the non string was an array of varied
elements including other arrays and possibly objects. The error occured
repeatedly until I found the offending assignment statement.

I tried to reproduce the error on the first require_once in the script
but did not succeed. The original error was deep in a script with
several requires and some requires including scripts containing
requires. I have now changed the script to a less complicated set of
requires and may not be able to reproduce the depth.

It is possible the crash was caused by the requires looping on
themselves but that type of error usually requires a second or two
before Apache runs out of memory (currently over 500 Mb free). The
crashes were instant.

php.ini has nothing set to increase available memory or change safe
mode or anything else. It runs as a module.


Previous Comments:


[2003-01-21 19:38:21] [EMAIL PROTECTED]

Sorry, I just mistook the platform is *nix.
As I can't reproduce this on my Linux box, this problem is likely to
be Windows specific.

Does Apache segfault when giving a non-existent file name to
require_once()
rather than an array?




[2003-01-21 19:24:28] [EMAIL PROTECTED]

I looked at the instructions for backtrace. They do not translate to
Win2000. I will install Cygwin and see if the instructions work with
Win2000 Cygwin.

Our Unix systems have old releases of PHP and Apache so it might be a
while before I can reproduce the test on Unix.



[2003-01-21 19:10:21] [EMAIL PROTECTED]

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

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





[2003-01-21 19:03:46] [EMAIL PROTECTED]

I had
$common = 'common/';
at the top of the script and
require_once($common . 'x.html');
in the middle of the script and it worked.

Later I accidentally set $common to a multidimentinal array prior to
it's use in require_once. Apache 2.0.43 crashed when I used the script.
PHP did not produce an error message.

Apache is not producing any other errors. Everything else in my scripts
work including Sablotron. 4.3.0 is stable with Apache 2 on both my NT
and Win2000 systems. I have not tried this script error on Apache 1.

A search of the bug database found some old entries from the year 2000
marked "Fixed in CVS" so I guess they are not refering to PHP 4.3.0.

The Apache log contained the following entry. The status code of
3221225477 is listed on web pages against a dozen different errors.

[Wed Jan 22 11:31:36 2003] [notice] Parent: Created child process 2128
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Child process is
running
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Acquired the start
mutex.
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Starting 250 worker
threads.
[Wed Jan 22 11:32:02 2003] [notice] Parent: child process exited with
status 3221225477 -- Restarting.






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

#18271 [Opn]: Problems reading MSSQL data of type "real"

[Brendan]

 ID:   18271
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: MSSQL related
 Operating System: Win2000
 PHP Version:  4.3.0
 New Comment:

I just looked up the manual page for MSSQL, and it mentions using the
ntwdblib.dll file (which exists in the PHP archive under dlls/).  I've
never concerned myself with that file because when I originally
installed PHP, the MSSQL connection worked as soon as I copied across
php_mssql.dll.

Do I need to replace ntwdblib.dll as well to test your fix?


Previous Comments:


[2003-01-21 19:48:19] [EMAIL PROTECTED]

I've tried replacing the extension file, but there was no change.

You said "related dlls from the dlls/ folder", AFAIK nothing in the
dlls/ folder is related to mssql.  So all I did was copy
extensions/php_mssql.dll into c:\php, restarted my browser session and
observed that I'm still getting the same data from real columns.

If I need to restart IIS to test this properly, tell me.



[2003-01-20 00:32:18] [EMAIL PROTECTED]

Yes, replace the php_mssql.dll and related dlls from the dlls/ folder.




[2003-01-19 21:07:24] [EMAIL PROTECTED]

Nope, unfortunately I haven't been able to do anything yet, because my
local sysadmin has been difficult to contact, and I need his approval
to log on to the server.

In the meantime, I've worked around the problem by changing all my real
type columns to decimal.  When I get a chance, I'll test your snapshot
and post my results here.

My previous question still stands.  I downloaded the archive you
pointed me to, but all you said was "try it".  I'm assuming that you
mean to try the php_mssql.dll file.  Am I correct?



[2003-01-17 21:16:19] [EMAIL PROTECTED]

Did you try it or not?




[2003-01-15 19:19:12] [EMAIL PROTECTED]

And it's just a case of overwriting my current php_mssql.dll with the
one in this archive?



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

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

#21812 [Opn->Fbk]: Apache crashes when require_once has array in directory name

[moriyoshi]

 ID:   21812
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Win2000
 PHP Version:  4.3.0


Previous Comments:


[2003-01-21 19:38:21] [EMAIL PROTECTED]

Sorry, I just mistook the platform is *nix.
As I can't reproduce this on my Linux box, this problem is likely to
be Windows specific.

Does Apache segfault when giving a non-existent file name to
require_once()
rather than an array?




[2003-01-21 19:24:28] [EMAIL PROTECTED]

I looked at the instructions for backtrace. They do not translate to
Win2000. I will install Cygwin and see if the instructions work with
Win2000 Cygwin.

Our Unix systems have old releases of PHP and Apache so it might be a
while before I can reproduce the test on Unix.



[2003-01-21 19:10:21] [EMAIL PROTECTED]

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

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





[2003-01-21 19:03:46] [EMAIL PROTECTED]

I had
$common = 'common/';
at the top of the script and
require_once($common . 'x.html');
in the middle of the script and it worked.

Later I accidentally set $common to a multidimentinal array prior to
it's use in require_once. Apache 2.0.43 crashed when I used the script.
PHP did not produce an error message.

Apache is not producing any other errors. Everything else in my scripts
work including Sablotron. 4.3.0 is stable with Apache 2 on both my NT
and Win2000 systems. I have not tried this script error on Apache 1.

A search of the bug database found some old entries from the year 2000
marked "Fixed in CVS" so I guess they are not refering to PHP 4.3.0.

The Apache log contained the following entry. The status code of
3221225477 is listed on web pages against a dozen different errors.

[Wed Jan 22 11:31:36 2003] [notice] Parent: Created child process 2128
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Child process is
running
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Acquired the start
mutex.
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Starting 250 worker
threads.
[Wed Jan 22 11:32:02 2003] [notice] Parent: child process exited with
status 3221225477 -- Restarting.






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

#18271 [Fbk->Opn]: Problems reading MSSQL data of type "real"

[Brendan]

 ID:   18271
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: MSSQL related
 Operating System: Win2000
 PHP Version:  4.3.0
 New Comment:

I've tried replacing the extension file, but there was no change.

You said "related dlls from the dlls/ folder", AFAIK nothing in the
dlls/ folder is related to mssql.  So all I did was copy
extensions/php_mssql.dll into c:\php, restarted my browser session and
observed that I'm still getting the same data from real columns.

If I need to restart IIS to test this properly, tell me.


Previous Comments:


[2003-01-20 00:32:18] [EMAIL PROTECTED]

Yes, replace the php_mssql.dll and related dlls from the dlls/ folder.




[2003-01-19 21:07:24] [EMAIL PROTECTED]

Nope, unfortunately I haven't been able to do anything yet, because my
local sysadmin has been difficult to contact, and I need his approval
to log on to the server.

In the meantime, I've worked around the problem by changing all my real
type columns to decimal.  When I get a chance, I'll test your snapshot
and post my results here.

My previous question still stands.  I downloaded the archive you
pointed me to, but all you said was "try it".  I'm assuming that you
mean to try the php_mssql.dll file.  Am I correct?



[2003-01-17 21:16:19] [EMAIL PROTECTED]

Did you try it or not?




[2003-01-15 19:19:12] [EMAIL PROTECTED]

And it's just a case of overwriting my current php_mssql.dll with the
one in this archive?



[2003-01-15 03:56:40] [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


There were some mssql fixes committed recently.



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

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

#21812 [Opn]: Apache crashes when require_once has array in directory name

[moriyoshi]

 ID:   21812
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Win2000
 PHP Version:  4.3.0
 New Comment:

Sorry, I just mistook the platform is *nix.
As I can't reproduce this on my Linux box, this problem is likely to
be Windows specific.

Does Apache segfault when giving a non-existent file name to
require_once()
rather than an array?



Previous Comments:


[2003-01-21 19:24:28] [EMAIL PROTECTED]

I looked at the instructions for backtrace. They do not translate to
Win2000. I will install Cygwin and see if the instructions work with
Win2000 Cygwin.

Our Unix systems have old releases of PHP and Apache so it might be a
while before I can reproduce the test on Unix.



[2003-01-21 19:10:21] [EMAIL PROTECTED]

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

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





[2003-01-21 19:03:46] [EMAIL PROTECTED]

I had
$common = 'common/';
at the top of the script and
require_once($common . 'x.html');
in the middle of the script and it worked.

Later I accidentally set $common to a multidimentinal array prior to
it's use in require_once. Apache 2.0.43 crashed when I used the script.
PHP did not produce an error message.

Apache is not producing any other errors. Everything else in my scripts
work including Sablotron. 4.3.0 is stable with Apache 2 on both my NT
and Win2000 systems. I have not tried this script error on Apache 1.

A search of the bug database found some old entries from the year 2000
marked "Fixed in CVS" so I guess they are not refering to PHP 4.3.0.

The Apache log contained the following entry. The status code of
3221225477 is listed on web pages against a dozen different errors.

[Wed Jan 22 11:31:36 2003] [notice] Parent: Created child process 2128
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Child process is
running
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Acquired the start
mutex.
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Starting 250 worker
threads.
[Wed Jan 22 11:32:02 2003] [notice] Parent: child process exited with
status 3221225477 -- Restarting.






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

#21812 [Fbk->Opn]: Apache crashes when require_once has array in directory name

[pmoulding]

 ID:   21812
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Win2000
 PHP Version:  4.3.0
 New Comment:

I looked at the instructions for backtrace. They do not translate to
Win2000. I will install Cygwin and see if the instructions work with
Win2000 Cygwin.

Our Unix systems have old releases of PHP and Apache so it might be a
while before I can reproduce the test on Unix.


Previous Comments:


[2003-01-21 19:10:21] [EMAIL PROTECTED]

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

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





[2003-01-21 19:03:46] [EMAIL PROTECTED]

I had
$common = 'common/';
at the top of the script and
require_once($common . 'x.html');
in the middle of the script and it worked.

Later I accidentally set $common to a multidimentinal array prior to
it's use in require_once. Apache 2.0.43 crashed when I used the script.
PHP did not produce an error message.

Apache is not producing any other errors. Everything else in my scripts
work including Sablotron. 4.3.0 is stable with Apache 2 on both my NT
and Win2000 systems. I have not tried this script error on Apache 1.

A search of the bug database found some old entries from the year 2000
marked "Fixed in CVS" so I guess they are not refering to PHP 4.3.0.

The Apache log contained the following entry. The status code of
3221225477 is listed on web pages against a dozen different errors.

[Wed Jan 22 11:31:36 2003] [notice] Parent: Created child process 2128
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Child process is
running
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Acquired the start
mutex.
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Starting 250 worker
threads.
[Wed Jan 22 11:32:02 2003] [notice] Parent: child process exited with
status 3221225477 -- Restarting.






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

#20274 [NoF->Opn]: failed to create stream: Too many open files in Unknown on line

[fowler]

 ID:   20274
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   No Feedback
+Status:   Open
 Bug Type: iPlanet related
 Operating System: Solaris 8
 PHP Version:  4CVS-2002-11-06
 New Comment:

Increasing file descriptors only delays the problem.

Our script to monitor the problem reports the following:
Monitoring http://our.site.com
Attempting to contact instance, try # 0
Web server successfully contacted
Too many open files being reported. Likely PHP problem ... 
=-=-=-=-=-=-=-=-=-=-= HTML RETURNED =-=-=-=-=-=-=-=-
HTTP/1.1 200 OK
Connection: close
Date: Wed, 22 Jan 2003 00:50:00 GMT
Server: Netscape-Enterprise/6.0
Content-Type: text/html
Client-Date: Wed, 22 Jan 2003 00:50:01 GMT
Client-Peer: 192.10.1.2:80
X-Powered-By: PHP/4.3.0


Warning:  Unknown(/site/web/index.php): failed to create stream:
Too many open files in Unknown on
line 0

Warning:  Unknown(): Failed opening '/site/web/index.php' for
inclusion
(include_path='.:/usr/local/lib/php') in Unknown on line
0


Shutting down server with script: /web/https-web-server/stop
Restarting server with script: /web/https-web-server/start
done.
Attempting to contact instance, try # 1
Web server successfully contacted
PHP problems resolved by restarting web server


Where can I go from here?


Previous Comments:


[2002-12-27 01:00:04] [EMAIL PROTECTED]

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



[2002-12-11 17:12:32] [EMAIL PROTECTED]

Please try increasing your kernel file descriptor limit



[2002-12-11 13:57:32] [EMAIL PROTECTED]

I get the same error message "failed to create stream: Too many open
files in Unknown on line 0" and "for inclusion
(include_path='.:/usr/local/lib/php') in Unknown on line 0"

I have php4.3.0RC2 and iplanet6 SP5. I opened the bug #20653. I was
told to compile the latest php on my system and you send me
php4.4.0-Dev. But I did not wanted to put Dev on the production box so
I downloaded php4.3.0rc2 off of php.net site and installed it on my
test box. I tested it for 10 days it worked fine. But now that I
compiled the same thing on the production box I get the above error
messages. 
What should I do?



[2002-12-01 04:43:02] [EMAIL PROTECTED]

[EMAIL PROTECTED]:
Can you try increasing your kernel file descriptor limit
(Try doubling it)?
(Don't ask me how; I don't have Solaris).

It's possible that PHP just uses more files concurrently than it used
to, however, it could also be a leak.




[2002-11-30 18:04:12] [EMAIL PROTECTED]

P.S.  was able to correct the make issue with 4.2.3 with correct nsapi
include path.



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

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

#21771 [Fbk]: variable names changing in turkish locale

[sniper]

 ID:   21771
 Updated by:   [EMAIL PROTECTED]
-Summary:  Header('Location: ... ') problem
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Variables related
-Operating System: Windows 2000
+Operating System: linux kernel 2.4.18
 PHP Version:  4.3.0
 New Comment:

restore mangled summary and OS entries.



Previous Comments:


[2003-01-21 11:26:21] [EMAIL PROTECTED]

strange ... this was fixed for functions constants
but should not affect variables, as these are 
case insensitive (so no conversions take place
while resolving them)
or is there something different going on with
the super-globals?

does this affect $_SESSION only? what if you have
register_globals enabled and try to pass something
like "...script.php?ID=test"? do you have $ID or
$ÝD set in your script then?



[2003-01-21 06:27:16] [EMAIL PROTECTED]

by the way, it's turkish locale
tr_TR
iso8859-9



[2003-01-21 06:24:08] [EMAIL PROTECTED]

no code works. even the example in the php session documentation...
:)





[2003-01-20 16:03:17] [EMAIL PROTECTED]

Can you provide some short example script?
And what locale causes this?




[2003-01-20 06:39:44] [EMAIL PROTECTED]

Oops... This may not be related to php. It may be resulting from the
turkish locale system itself. Let me investigate...



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

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

#21812 [Opn->Fbk]: Apache crashes when require_once has array in directory name

[moriyoshi]

 ID:   21812
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Win2000
 PHP Version:  4.3.0
 New Comment:

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

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




Previous Comments:


[2003-01-21 19:03:46] [EMAIL PROTECTED]

I had
$common = 'common/';
at the top of the script and
require_once($common . 'x.html');
in the middle of the script and it worked.

Later I accidentally set $common to a multidimentinal array prior to
it's use in require_once. Apache 2.0.43 crashed when I used the script.
PHP did not produce an error message.

Apache is not producing any other errors. Everything else in my scripts
work including Sablotron. 4.3.0 is stable with Apache 2 on both my NT
and Win2000 systems. I have not tried this script error on Apache 1.

A search of the bug database found some old entries from the year 2000
marked "Fixed in CVS" so I guess they are not refering to PHP 4.3.0.

The Apache log contained the following entry. The status code of
3221225477 is listed on web pages against a dozen different errors.

[Wed Jan 22 11:31:36 2003] [notice] Parent: Created child process 2128
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Child process is
running
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Acquired the start
mutex.
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Starting 250 worker
threads.
[Wed Jan 22 11:32:02 2003] [notice] Parent: child process exited with
status 3221225477 -- Restarting.






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

#21812 [NEW]: Apache crashes when require_once has array in directory name

[pmoulding]

From: [EMAIL PROTECTED]
Operating system: Win2000
PHP version:  4.3.0
PHP Bug Type: Reproducible crash
Bug description:  Apache crashes when require_once has array in directory name

I had
$common = 'common/';
at the top of the script and
require_once($common . 'x.html');
in the middle of the script and it worked.

Later I accidentally set $common to a multidimentinal array prior to it's
use in require_once. Apache 2.0.43 crashed when I used the script. PHP did
not produce an error message.

Apache is not producing any other errors. Everything else in my scripts
work including Sablotron. 4.3.0 is stable with Apache 2 on both my NT and
Win2000 systems. I have not tried this script error on Apache 1.

A search of the bug database found some old entries from the year 2000
marked "Fixed in CVS" so I guess they are not refering to PHP 4.3.0.

The Apache log contained the following entry. The status code of
3221225477 is listed on web pages against a dozen different errors.

[Wed Jan 22 11:31:36 2003] [notice] Parent: Created child process 2128
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Child process is running
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Acquired the start mutex.
[Wed Jan 22 11:31:36 2003] [notice] Child 2128: Starting 250 worker
threads.
[Wed Jan 22 11:32:02 2003] [notice] Parent: child process exited with
status 3221225477 -- Restarting.


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

#21809 [Fbk->Opn]: fgets() does not time-out if connection is lost

[syntheticrage]

 ID:   21809
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Sockets related
 Operating System: RedHat 7.3
-PHP Version:  4CVS-2003-01-21 (stable)
+PHP Version:  4CVS-2003-01-22 (stable)
 New Comment:

I was using 4.3.0 on the machine running the "server" test script (but
since that script is merely to aid in testing the bug in the "client"
script, I didnt think it mattered).  The machine running the "client"
script - the one experiencing the bug - was running a stable snapshot
compiled last night.  Nontheless, I just re-compiled with the latest
stable today, ran again, and managed to generate a bt in the process:

#0  0x420e19ee in select () from /lib/i686/libc.so.6
#1  0x08204844 in __DTOR_END__ ()
#2  0x08147689 in _php_stream_free (stream=0x82598fc, close_options=3)
at /usr/local/src/php4-STABLE-200301220030/main/streams.c:327
#3  0x080c4f85 in zif_fclose (ht=1, return_value=0x8256f2c,
this_ptr=0x0,
return_value_used=0)
at
/usr/local/src/php4-STABLE-200301220030/ext/standard/file.c:1120
#4  0x08185c8b in execute (op_array=0x8254ac4)
at
/usr/local/src/php4-STABLE-200301220030/Zend/zend_execute.c:1596
#5  0x08173dcc in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/local/src/php4-STABLE-200301220030/Zend/zend.c:864
#6  0x0813c983 in php_execute_script (primary_file=0xbb10)
at /usr/local/src/php4-STABLE-200301220030/main/main.c:1573
#7  0x0818c0a2 in main (argc=2, argv=0xbbb4)
at /usr/local/src/php4-STABLE-200301220030/sapi/cli/php_cli.c:753
#8  0x42017589 in __libc_start_main () from /lib/i686/libc.so.6

Hope it helps :)


Previous Comments:


[2003-01-21 17:58:55] [EMAIL PROTECTED]

Are you using the 4.3.0 release or the latest stable snapshot? (the
version field above and the version you mention in your comment don't
seem to match up).

If you're using the released 4.3.0, please try the latest stable
snapshot from snaps.php.net first.



[2003-01-21 17:56:05] [EMAIL PROTECTED]

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

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

Run the cli under gdb (see instructions above),
and when it hangs press CTRL-C.
You can then type "bt" to generate the backtrace.



[2003-01-21 17:50:32] [EMAIL PROTECTED]

I've been writing a CLI-based script that connects to an xml wirefeed
and continually reads the data with fgets() and parses it accordingly. 
The script works fine, but occasionally the feed server goes down for
maintenance, etc.  That in itself isnt a problem, but when the
connection to the feed is lost, fgets() stalls and never times out
regardless of the stream_set_timeout() usage.  I have written the
following scripts to verify the problem (note that the "server" script
is only to help test the fgets() bug in the "client" script).

I run this script (the "server" script) on my workstation (running XP
w/ PHP 4.3.0 in CLI mode) to listen on a socket:



Then I run this script (the "client" script) on my linux box (running
RH7.3 w/ PHP 4CVS-2003-01-20 (stable) in CLI mode) to connect to the
socket:



The client script will time-out properly when I leave the server script
running.  But if I run the client script, then CTRL-C my server script,
the client script never times out.  It sits at the fgets() forever,
even though I've set_time_limit(30) as well as stream_set_timeout(10).

Since the script just sits there and never "crashes" to generate a
corefile, I haven't been able to perform a backtrace.  Even though i've
compiled PHP with --enable-debug, killing the script with CTRL-C
doesn't generate a corefile (should it?).  If a bt would help, please
let me know how I can generate a corefile with the CLI version of PHP.

I've configured PHP as as follows:

'./configure' '--with-apxs' '--with-config-file-path=/etc'
'--with-mysql=/usr' '--with-gzip' '--with-xml' '--with-gd'
'--with-zlib' '--with-freetype' '--with-ttf' '--enable-debug' 

Note that I have also verified this problem on a second linux box
running RH8 w/ PHP4.3.0.  

Any help would be appreciated!





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

#21643 [Csd]: ldap_search same criteria no results

[sniper]

 ID:   21643
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: LDAP related
 Operating System: windows 2000
 PHP Version:  4.3.0
 New Comment:

It's propably due some change in the openldap library version which is
used when the win32 binaries are build.
(it now also has sasl support so..)



Previous Comments:


[2003-01-21 13:55:43] [EMAIL PROTECTED]

Ok, I'll close this. Basically the functionality has been changed a
bit, it seems that the new version of php_ldap.dll now requires escape
characters on special characters including '(' & ')' ... the old
version for win32 did not. It appears that this has been the case on
the unix based versions for some time now.



[2003-01-20 16:52:26] [EMAIL PROTECTED]

Sorry, I was counting the wrong thing... the single quotes are not
required, but the parens are a problem. Anyway, that seems to be what
it boils down to.



[2003-01-20 16:40:00] [EMAIL PROTECTED]

Aha... it doesn't like the parens ... also, it seems to not like the
single quote. The problem with that is if i don't use the single quotes
I get back 2 records. :-\



[2003-01-20 16:33:14] [EMAIL PROTECTED]

Ok, I give up. After I actually found one of those servers that worked
I couldn't find a single valid attribute to search on. I tried cn,
name, ... and other common attribute types. All returned invalid
attribute type. So here's a simpler sample of the problem:




PHP 4.2.3 extension returns: 1 records returned.
PHP 4.3.0 extension returns:
Warning: ldap_search(): Search: Bad search filter in
R:\WebApps\api\ldapSearcherTest.php on line 9

Warning: ldap_get_entries(): supplied argument is not a valid ldap
result resource in R:\WebApps\api\ldapSearcherTest.php on line 10
0 records returned.



[2003-01-19 17:57:16] [EMAIL PROTECTED]

leaving as feedback until a response comes in...



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

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

#21808 [Opn->Fbk]: autoglobals won't work with a custom error page

[pollita]

 ID:   21808
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: linux apache 2.0.43
 PHP Version:  4.3.0
 New Comment:

Please provide the following pieces of information:

1) A link to a phpinfo(); page on your server.

2) The relevant source of the script which calls your error page.
(i.e.: header("Location: myerrorpage.php?arg=my+error+message"); )

3) The source to your error page.


Previous Comments:


[2003-01-21 16:01:02] [EMAIL PROTECTED]

Hiya

When i have an error page with php but requesting the error page with
an argument it won't show up in the scrip as $_REQUEST['arg'] or
something
The arg is however in the $_SERVER["REDIRECT_QUERY_STRING"] AND in the
$_SERVER["REQUEST_URI"]

Gr,

Wico




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

#21284 [Opn->Fbk]: don't configure on AIX 4.3.3

[sniper]

 ID:   21284
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: *Configuration Issues
 Operating System: AIX 4.3.3
 PHP Version:  4.3.0
 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

This should be fixed already..



Previous Comments:


[2002-12-30 04:07:36] [EMAIL PROTECTED]

a little addition
- cut here---
/opt/freeware/php-4.3.0 > autoconf --version
Autoconf version 2.13
- cut here---



[2002-12-30 02:38:12] [EMAIL PROTECTED]

System : IBM RS/6000 7044-270
OS : AIX 4.3.3 (Maintenance Level 10 applied)
./configure --with-apxs=blablabla
after License and register global warnings displayed an error message
appears

Olders versions (4.0.6,4.2.1,4.2.2,4.2.3) configured and compiled good
but 4.3.0 don't configuring...Maybe an autoconf issue i don't know...


and following output :
--- cut here 

./config.status[1814]: 6: bad file unit number
./config.status[1815]: 6: bad file unit number
 cut here ---




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

#21811 [NEW]: Viewing files on disk

[kuk]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.2.2
PHP Bug Type: Output Control
Bug description:  Viewing files on disk

Just to know if it correc to see /etc/passwd for example, I did a simple
script like this.

pag1.html



:-D







--
ensena.php
--

--
so you can put "/etc/passwd" and the it is showed, just wanna know if this
is correct..

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

#21810 [NEW]: Not able to start HP/Apache 2.0.43 php-4.2.2 with informix support

[sappusam]

From: [EMAIL PROTECTED]
Operating system: HP-UX 11.00
PHP version:  4.2.2
PHP Bug Type: Informix related
Bug description:  Not able to start HP/Apache 2.0.43 php-4.2.2 with informix support

Hi,

OS : HP-UX 11.00 32bit
Apache : HP Apache 2.0.43
 Server Built Oct 16 2002.
PHP: PHP-4.2.2
Informix: 7.2

 PHP-4.2.2 comes pre-complied with HP apache as dynamic module. 
When i tried to compile php with informix support, configure
and make goes fine. 

configured and compiled with following env. variables.

export IFX_LIBDIR="-L$INFORMIXDIR/lib -L$INFORMIXDIR/lib/esql"
export IFX_INCDIR="$INFORMIXDIR/incl/esql"
export IFX_LIBS="$INFORMIXDIR/lib/esql/libifsql.a \
$INFORMIXDIR/lib/libifasf.a \
$INFORMIXDIR/lib/esql/libifgen.a \
$INFORMIXDIR/lib/esql/libifos.a \
$INFORMIXDIR/lib/esql/libifgls.a \
-lgen -lgls -lm -ldl $INFORMIXDIR/lib/esql/checkapi.o \
$INFORMIXDIR/lib/esql/libifglx.a"
export
PATH=$PATH:.:/opt/bison/bin:/opt/binutils/bin:/opt/gcc/bin:/usr/local/bin



But when trying to start apache it gives following error.

# ./apachectl start
Syntax error on line 215 of /opt/hpapache2/conf/httpd.conf:
Cannot load /opt/hpapache2/modules/libphp4.so into server: Unresolved
symbol: ifx_checkAPI (code)  from /usr/informix/lib/esql/libthos.sl

I searched on this site for info and included the above libs in path
before configuring and making php. But still having same problem. Can
someone help me in solving this ?.

Thanks in advance.
Srini.



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

#21809 [Fbk]: fgets() does not time-out if connection is lost

[wez]

 ID:   21809
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Sockets related
 Operating System: RedHat 7.3
 PHP Version:  4CVS-2003-01-21 (stable)
 New Comment:

Are you using the 4.3.0 release or the latest stable snapshot? (the
version field above and the version you mention in your comment don't
seem to match up).

If you're using the released 4.3.0, please try the latest stable
snapshot from snaps.php.net first.


Previous Comments:


[2003-01-21 17:56:05] [EMAIL PROTECTED]

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

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

Run the cli under gdb (see instructions above),
and when it hangs press CTRL-C.
You can then type "bt" to generate the backtrace.



[2003-01-21 17:50:32] [EMAIL PROTECTED]

I've been writing a CLI-based script that connects to an xml wirefeed
and continually reads the data with fgets() and parses it accordingly. 
The script works fine, but occasionally the feed server goes down for
maintenance, etc.  That in itself isnt a problem, but when the
connection to the feed is lost, fgets() stalls and never times out
regardless of the stream_set_timeout() usage.  I have written the
following scripts to verify the problem (note that the "server" script
is only to help test the fgets() bug in the "client" script).

I run this script (the "server" script) on my workstation (running XP
w/ PHP 4.3.0 in CLI mode) to listen on a socket:



Then I run this script (the "client" script) on my linux box (running
RH7.3 w/ PHP 4CVS-2003-01-20 (stable) in CLI mode) to connect to the
socket:



The client script will time-out properly when I leave the server script
running.  But if I run the client script, then CTRL-C my server script,
the client script never times out.  It sits at the fgets() forever,
even though I've set_time_limit(30) as well as stream_set_timeout(10).

Since the script just sits there and never "crashes" to generate a
corefile, I haven't been able to perform a backtrace.  Even though i've
compiled PHP with --enable-debug, killing the script with CTRL-C
doesn't generate a corefile (should it?).  If a bt would help, please
let me know how I can generate a corefile with the CLI version of PHP.

I've configured PHP as as follows:

'./configure' '--with-apxs' '--with-config-file-path=/etc'
'--with-mysql=/usr' '--with-gzip' '--with-xml' '--with-gd'
'--with-zlib' '--with-freetype' '--with-ttf' '--enable-debug' 

Note that I have also verified this problem on a second linux box
running RH8 w/ PHP4.3.0.  

Any help would be appreciated!





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

#21809 [Opn->Fbk]: fgets() does not time-out if connection is lost

[wez]

 ID:   21809
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Sockets related
 Operating System: RedHat 7.3
 PHP Version:  4CVS-2003-01-21 (stable)
 New Comment:

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

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

Run the cli under gdb (see instructions above),
and when it hangs press CTRL-C.
You can then type "bt" to generate the backtrace.


Previous Comments:


[2003-01-21 17:50:32] [EMAIL PROTECTED]

I've been writing a CLI-based script that connects to an xml wirefeed
and continually reads the data with fgets() and parses it accordingly. 
The script works fine, but occasionally the feed server goes down for
maintenance, etc.  That in itself isnt a problem, but when the
connection to the feed is lost, fgets() stalls and never times out
regardless of the stream_set_timeout() usage.  I have written the
following scripts to verify the problem (note that the "server" script
is only to help test the fgets() bug in the "client" script).

I run this script (the "server" script) on my workstation (running XP
w/ PHP 4.3.0 in CLI mode) to listen on a socket:



Then I run this script (the "client" script) on my linux box (running
RH7.3 w/ PHP 4CVS-2003-01-20 (stable) in CLI mode) to connect to the
socket:



The client script will time-out properly when I leave the server script
running.  But if I run the client script, then CTRL-C my server script,
the client script never times out.  It sits at the fgets() forever,
even though I've set_time_limit(30) as well as stream_set_timeout(10).

Since the script just sits there and never "crashes" to generate a
corefile, I haven't been able to perform a backtrace.  Even though i've
compiled PHP with --enable-debug, killing the script with CTRL-C
doesn't generate a corefile (should it?).  If a bt would help, please
let me know how I can generate a corefile with the CLI version of PHP.

I've configured PHP as as follows:

'./configure' '--with-apxs' '--with-config-file-path=/etc'
'--with-mysql=/usr' '--with-gzip' '--with-xml' '--with-gd'
'--with-zlib' '--with-freetype' '--with-ttf' '--enable-debug' 

Note that I have also verified this problem on a second linux box
running RH8 w/ PHP4.3.0.  

Any help would be appreciated!





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

#21809 [NEW]: fgets() does not time-out if connection is lost

[syntheticrage]

From: [EMAIL PROTECTED]
Operating system: RedHat 7.3
PHP version:  4CVS-2003-01-21 (stable)
PHP Bug Type: Sockets related
Bug description:  fgets() does not time-out if connection is lost

I've been writing a CLI-based script that connects to an xml wirefeed and
continually reads the data with fgets() and parses it accordingly.  The
script works fine, but occasionally the feed server goes down for
maintenance, etc.  That in itself isnt a problem, but when the connection
to the feed is lost, fgets() stalls and never times out regardless of the
stream_set_timeout() usage.  I have written the following scripts to
verify the problem (note that the "server" script is only to help test the
fgets() bug in the "client" script).

I run this script (the "server" script) on my workstation (running XP w/
PHP 4.3.0 in CLI mode) to listen on a socket:



Then I run this script (the "client" script) on my linux box (running
RH7.3 w/ PHP 4CVS-2003-01-20 (stable) in CLI mode) to connect to the
socket:



The client script will time-out properly when I leave the server script
running.  But if I run the client script, then CTRL-C my server script,
the client script never times out.  It sits at the fgets() forever, even
though I've set_time_limit(30) as well as stream_set_timeout(10).

Since the script just sits there and never "crashes" to generate a
corefile, I haven't been able to perform a backtrace.  Even though i've
compiled PHP with --enable-debug, killing the script with CTRL-C doesn't
generate a corefile (should it?).  If a bt would help, please let me know
how I can generate a corefile with the CLI version of PHP.

I've configured PHP as as follows:

'./configure' '--with-apxs' '--with-config-file-path=/etc'
'--with-mysql=/usr' '--with-gzip' '--with-xml' '--with-gd' '--with-zlib'
'--with-freetype' '--with-ttf' '--enable-debug' 

Note that I have also verified this problem on a second linux box running
RH8 w/ PHP4.3.0.  

Any help would be appreciated!

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

#21773 [Com]: The process is killed after OCIFetch()

[michael . mauch]

 ID:   21773
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: OCI8 related
 Operating System: Solaris 2.8
 PHP Version:  4.3.0
 New Comment:

Can you please try without these @ signs? If you don't like the
errors/warnings being displayed on your webpages, you can turn
display_errors off and log_errors on, so you can find the
errors/warnings in your log file.

ini_set('display_errors','0');
ini_set('log_errors','1');


Previous Comments:


[2003-01-21 03:19:26] [EMAIL PROTECTED]

I don't receive any error or I don't perhaps succeed in capturing it.



[2003-01-20 14:52:10] [EMAIL PROTECTED]

Do you see "OCI8 Recursive call!" such an error message?



[2003-01-20 10:51:56] [EMAIL PROTECTED]

Before the connection to the db it is present the following statement:

//Set max execution time to infinite

set_time_limit(0);

The loop is stopped when there is an error, in this case the variable
$error=1.

Thanks



[2003-01-20 10:51:54] [EMAIL PROTECTED]

Before the connection to the db it is present the following statement:

//Set max execution time to infinite

set_time_limit(0);

The loop is stopped when there is an error, in this case the variable
$error=1.

Thanks



[2003-01-20 10:19:01] [EMAIL PROTECTED]

This is not an infinite loop, it runs only while ($error==0).

And then there's a time limit for every PHP script, see
.

Better ask such questions in the php.db mailing list, see
.



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

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

#21808 [NEW]: autoglobals won't work with a custom error page

[wdl]

From: [EMAIL PROTECTED]
Operating system: linux apache 2.0.43
PHP version:  4.3.0
PHP Bug Type: Scripting Engine problem
Bug description:  autoglobals won't work with a custom error page

Hiya

When i have an error page with php but requesting the error page with an
argument it won't show up in the scrip as $_REQUEST['arg'] or something
The arg is however in the $_SERVER["REDIRECT_QUERY_STRING"] AND in the
$_SERVER["REQUEST_URI"]

Gr,

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

#6893 [Asn]: feature request - makelinks() function

[philip]

 ID:   6893
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Assigned
 Bug Type: Feature/Change Request
 Operating System: N/A
 PHP Version:  4.0.2
 Assigned To:  tal
 New Comment:

How about posting a link to this source online?


Previous Comments:


[2003-01-21 14:23:19] [EMAIL PROTECTED]

I developed such a function in php with extensive exceptions checking,
some months ago.

If it would help you, you might like to eyeball it. It may give you
valuable and time-saving clues to coding it as a C++ function.

Please send me an email address to deliver you part of my script
library as an attachment.



[2002-04-28 13:35:01] [EMAIL PROTECTED]

dealing with trailing periods and commas on urls is pretty easy -- just
ignore them if they're followed by a whitespace character. (it's not
100% reliable, of course, but in my experience is more often correct
than including the trailing period or comma in that case.)



[2002-04-28 06:57:19] [EMAIL PROTECTED]

In playing with this kind of thing in the past I've come up against the
following problem: How do you handle URLs embedded in sentences which
have contact with a full stop or commas?

"Have a look at www.examples.com/hi.html, it might help you out"

Baring in mind that some sites DO include a comma in the URL, for
example any site powered by the Vignette content managment system -
example:

http://www.vignette.com/CDA/Site/0,2097,1-1-1489,00.html

The same goes for sentences where the URL is followed directly by a
full stop.

The other thing that might be worth taking in to consideration is that
many site designs will "break" if suitably long URLs are added (this is
especially true for forums, which will be a major use for this
function). The  best solution I have seen is vBulletin's, where long
URLs are shortened to look like this:

http://example.com/lon...blah.html

Where the full URL (to which the above text is linked) looks like
this:

http://example.com/long-url-here/blah/blah/blah.html

Obviously different sites would need different lengths of URL, so
whether or not URLs were shortened like this (and to what extent they
were shortened) should probably be specified by an optional second
paramater of some sort.

Hope that helps,

Simon



[2002-04-28 02:24:17] [EMAIL PROTECTED]

I'm planning to write a String_Manipulation (or something similiar,
we'll probably fight about that... ;-)). Assigned to myself.

-Tal



[2002-01-06 10:02:06] [EMAIL PROTECTED]

sounds if PEAR has another task ;). reclassified.



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

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

#14409 [Com]: request for nonexistent file does not return 404 error

[brian]

 ID:   14409
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Apache related
 Operating System: IRIX64 vega 6.5 04191225 IP27
 PHP Version:  4.2.2
 New Comment:

I've duplicated this on Linux/Apache w/ PHP 4.3.0 running PHP via CGI.
Documents that don't return "No input file specified." and the apache
logs show a 200 (succesful page retrieval). Nothing is sent to the
error log.

The problem is that there's no way to track or log bad page requests.
This is very very bad.


Previous Comments:


[2002-10-22 02:05:57] [EMAIL PROTECTED]

Small addendum.  PHP does exit 255 if its target does not exist, but
since it has already sent a complete CGI/1.1 HTTP header back to Apache
("Content-type: text/html\n\n"), including the blank line that
indicates end of headers,
Apache has already parsed and sent a complete 200 OK set
of HTTP headers back to the client.  No, this is not an
Apache bug.

Running PHP 4.2.2 as a CGI via an Action directive under Apache 1.3.23
(RedHat patched).  From httpd.conf:

## PHP run as a CGI without everyone needing ExecCGI privs
AddType application/x-httpd-php .php .php4 .php3 .phtml
AddHandler php-script .php .php4 .php3 .phtml
Action php-script /lcgi/php



[2002-10-21 20:40:02] [EMAIL PROTECTED]

By default, the PHP executable runs in CGI mode and produces
an HTTP header "Content-type: text/html"

Since PHP runs in CGI mode, it should follow the CGI/1.1 specification,
which has not changed in so long that it might even pre-date PHP!  I
refer you to:
  http://hoohoo.ncsa.uiuc.edu/cgi/out.html

If PHP is going to leave something like the following in my Apache
error log:
  PHP Fatal error:  Unable to open /pub/a/b/acb.com/index3.html in
Unknown on line 0
when it is unable to find a target file, then I would expect it to
either return an error page 404 Not Found, or exit non-zero, at which
point Apache will return 500 Server Error.  Under NO circumstance
should a PHP Fatal error return a 200 OK to the client, which is
implicitly done by Apache as per the CGI/1.1 spec when Apache receives
pieces of a valid HTTP header without "Status: xxx" specified.

Incorrect PHP behavior confirmed on PHP 4.2.2 on Linux 2.4.18, RedHat
7.2.  PHP custom compiled with:
 './configure' '--prefix=/usr/local/php' '--enable-memory-limit'
'--enable-force-cgi-redirect' '--enable-safe-mode' '--disable-rpath'
'--with-mysql' '--with-db3'

-Glenn



[2002-09-23 14:59:17] [EMAIL PROTECTED]

Re-opening bug report.



[2002-09-23 13:46:12] [EMAIL PROTECTED]

Dear Kalowsky,

I've just reproduced it on php4-20020920 on Apache.
It said php-4.3.0 in phpinfo(), and it is more recent than 
your post.

You should understand that it is Apache-related bug, so IIS 
testing does not apply here, and it is stated in original 
bug report.
Probably you also used php module in your testing on 
FreeBSD, while original bug report says that PHP was 
installed as CGI.

The trouble looks to me as follows: if php CGI meets 
nonexistent php file, it does not output anything, 
while it should output error page, and I would really 
appreciate if I'd be able to tune that page via php.ini 
or whatever.

Unfortunately, I can't reopen this bug, so someone please 
reopen it.

Thank you.



[2002-08-13 00:49:48] [EMAIL PROTECTED]

Duplicated again with PHP 4.2.2 on Apache 1.3.23 under Windows XP.  I
don't have access to 3.0.



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

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

#21806 [NEW]: sybase_unbuffered_query eats memory

[mayc]

From: [EMAIL PROTECTED]
Operating system: Solaris 7
PHP version:  4.3.0
PHP Bug Type: Sybase-ct (ctlib) related
Bug description:  sybase_unbuffered_query eats memory

Large selection sets using sybase_query use too much memory, since it pulls
the entire result set into memory.  In my example, the memory of the httpd
daemon quickly builds to about 155MB before the 30 second timeout.  I had
figured that sybase_unbuffered_query would solved that problem. 
Unfortunately, it also bleeds memory, however not as bad.  It raises the
memory usage of the httpd daemon to 53MB before the 30 second timeout.

I believe this is either a memory leak, or unbuffered query is actually
still buffering something.

Below is a simplified example that shows the memory leak.  I am using
Solaris 7, Sybase 11.9.2, and PHP 4.3.0.

Chuck

---

sybase_min_server_severity(11);

$con = sybase_connect('peach5026d', 'may', '');
sybase_select_db('db_dev', $con);

$fp = fopen('test.csv', "w");   // open the output file

$query = sybase_unbuffered_query("SELECT * FROM vial v WHERE v.study_id =
'ACC'", $con);

$max = sybase_num_fields($query);
while($row = sybase_fetch_row($query)) {
$elements = array();
for ($j = 0; $j < $max; $j++)
$elements[] = $row[$j];

fwrite($fp, implode(',', $elements) . "\r\n");
}
@sybase_free_result($query);
   
fclose($fp);   // close the file

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

#21791 [Fbk->Opn]: problems with reference passing through layers of functions in windows/IIS/sapi

[fishrunsrap]

 ID:   21791
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
-Bug Type: Scripting Engine problem
+Bug Type: MSSQL related
 Operating System: windows
 PHP Version:  4.3.0
 New Comment:

under PHP 4.3.0 in IIS5/sapi, the mssql_bind() function does not modify
variables passed in for output parameters.


Previous Comments:


[2003-01-21 14:52:37] [EMAIL PROTECTED]

the following test script:

function inner2(&$val) {
$val = "Changed!";
}

function inner(&$val) {
inner2(&$val);
}

function outer(&$val) {
inner(&$val);
}

$val = "The same.";
outer(&$val);

echo("val = ".$val."\n");


... actually executes as it should on both 4.2.3 and 4.3.0 in my
environment. I therefore would like to reopen the bug as one in the
MSSQL extension on windows.



[2003-01-21 00:58:49] [EMAIL PROTECTED]

Please provide a _SHORT_ and _COMPLETE_ example script
which can be used to reproduce this.




[2003-01-21 00:55:10] [EMAIL PROTECTED]

I upgraded PHP to 4.3.0, from 4.2.3, running in IIS5 as a SAPI module.
I had hacked stored procedure support for MSSQL into the PEAR DB class
with a function like: 

function spBindOutputParam($stmt, $name, &$outref, $type) { 
return mssql_bind($stmt, $name, &$outref, $type, true, false); 
} 


... right? then, in my own DBAbstraction classes, I had something like:


function bindOutputParam($name, &$outref, $type) { 
/// debugger 
global $debug; 

//$debug->println("DBStoredProcedure::bindOutputParam() called, outref
= ".$outref."", 5); 
return $this->db_connection->spBindOutputParam($this->db_stmt, $name,
&$outref, $type); 
} 

... and so on, up through the layers of abstraction in my application
framework, always passing the output parameter $outref by value. I
upgraded to PHP 4.3.0 and it BROKE. the functions all completely failed
to modify $outref. it works fine, I stress, in PHP 4.2.3. I desperately
tried a bunch of stuff like removing the '&' from ONLY the function
signatures, or ONLY the subsequent calls, or what have you. totally
busted. has anyone run into anything like this? I'm guessing it's a PHP
4.2.3->4.3.0 thing but who knows? maybe also with MSSQL in PHP. let me
know. thanks! 

-fish





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

#21791 [Com]: problems with reference passing through layers of functions in windows/IIS/sapi

[fishrunsrap]

 ID:   21791
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: windows
 PHP Version:  4.3.0
 New Comment:

the following test script:

function inner2(&$val) {
$val = "Changed!";
}

function inner(&$val) {
inner2(&$val);
}

function outer(&$val) {
inner(&$val);
}

$val = "The same.";
outer(&$val);

echo("val = ".$val."\n");


... actually executes as it should on both 4.2.3 and 4.3.0 in my
environment. I therefore would like to reopen the bug as one in the
MSSQL extension on windows.


Previous Comments:


[2003-01-21 00:58:49] [EMAIL PROTECTED]

Please provide a _SHORT_ and _COMPLETE_ example script
which can be used to reproduce this.




[2003-01-21 00:55:10] [EMAIL PROTECTED]

I upgraded PHP to 4.3.0, from 4.2.3, running in IIS5 as a SAPI module.
I had hacked stored procedure support for MSSQL into the PEAR DB class
with a function like: 

function spBindOutputParam($stmt, $name, &$outref, $type) { 
return mssql_bind($stmt, $name, &$outref, $type, true, false); 
} 


... right? then, in my own DBAbstraction classes, I had something like:


function bindOutputParam($name, &$outref, $type) { 
/// debugger 
global $debug; 

//$debug->println("DBStoredProcedure::bindOutputParam() called, outref
= ".$outref."", 5); 
return $this->db_connection->spBindOutputParam($this->db_stmt, $name,
&$outref, $type); 
} 

... and so on, up through the layers of abstraction in my application
framework, always passing the output parameter $outref by value. I
upgraded to PHP 4.3.0 and it BROKE. the functions all completely failed
to modify $outref. it works fine, I stress, in PHP 4.2.3. I desperately
tried a bunch of stuff like removing the '&' from ONLY the function
signatures, or ONLY the subsequent calls, or what have you. totally
busted. has anyone run into anything like this? I'm guessing it's a PHP
4.2.3->4.3.0 thing but who knows? maybe also with MSSQL in PHP. let me
know. thanks! 

-fish





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

#21796 [Opn->Bgs]: Compile fails on AIX 4.3.3

[iliaa]

 ID:   21796
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: AIX 4.3.3
 PHP Version:  4.3.0
 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. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.

Dup of bug #21284.


Previous Comments:


[2003-01-21 10:16:53] [EMAIL PROTECTED]

Same problem, same line number.



[2003-01-21 09:35:13] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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



[2003-01-21 09:32:54] [EMAIL PROTECTED]

A few minor warnings with configure, then configure ends with:

| about the implications of having register_globals set to on, and   |
| avoid using it if possible.|
++

./config.status[1739]: 6: bad file unit number
./config.status[1740]: 6: bad file unit number

Didnt seem too bad, so I went with the compile, and it fails with:

cc -I/root/php/php-4.3.0/ext/mysql/libmysql -Iext/mysql/
-I/root/php/php-4.3.0/ext/mysql/ -DPHP_ATOM_INC
-I/root/php/php-4.3.0/include -I/root/php/php-4.3.0/main
-I/root/php/php-4.3.0 -I/root/php/php-4.3.0/Zend
-I/root/php/php-4.3.0/ext/xml/expat  -I/root/php/php-4.3.0/TSRM  -g  -c
/root/php/php-4.3.0/ext/mysql/libmysql/my_tempnam.c -o
ext/mysql/libmysql/my_tempnam.o  && echo >
ext/mysql/libmysql/my_tempnam.lo
"/root/php/php-4.3.0/ext/mysql/libmysql/my_tempnam.c", line 99.5:
1506-025 (S) Operand must be a modifiable lvalue.
"/root/php/php-4.3.0/ext/mysql/libmysql/my_tempnam.c", line 105.3:
1506-025 (S) Operand must be a modifiable lvalue.
make: 1254-004 The error code from the last command is 1.

I saw another bug here with the same exact compile failure, but in a
different file, and it was fixed. Hopefully this will be as easy.




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

#6893 [Com]: feature request - makelinks() function

[alan]

 ID:   6893
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Assigned
 Bug Type: Feature/Change Request
 Operating System: N/A
 PHP Version:  4.0.2
 Assigned To:  tal
 New Comment:

I developed such a function in php with extensive exceptions checking,
some months ago.

If it would help you, you might like to eyeball it. It may give you
valuable and time-saving clues to coding it as a C++ function.

Please send me an email address to deliver you part of my script
library as an attachment.


Previous Comments:


[2002-04-28 13:35:01] [EMAIL PROTECTED]

dealing with trailing periods and commas on urls is pretty easy -- just
ignore them if they're followed by a whitespace character. (it's not
100% reliable, of course, but in my experience is more often correct
than including the trailing period or comma in that case.)



[2002-04-28 06:57:19] [EMAIL PROTECTED]

In playing with this kind of thing in the past I've come up against the
following problem: How do you handle URLs embedded in sentences which
have contact with a full stop or commas?

"Have a look at www.examples.com/hi.html, it might help you out"

Baring in mind that some sites DO include a comma in the URL, for
example any site powered by the Vignette content managment system -
example:

http://www.vignette.com/CDA/Site/0,2097,1-1-1489,00.html

The same goes for sentences where the URL is followed directly by a
full stop.

The other thing that might be worth taking in to consideration is that
many site designs will "break" if suitably long URLs are added (this is
especially true for forums, which will be a major use for this
function). The  best solution I have seen is vBulletin's, where long
URLs are shortened to look like this:

http://example.com/lon...blah.html

Where the full URL (to which the above text is linked) looks like
this:

http://example.com/long-url-here/blah/blah/blah.html

Obviously different sites would need different lengths of URL, so
whether or not URLs were shortened like this (and to what extent they
were shortened) should probably be specified by an optional second
paramater of some sort.

Hope that helps,

Simon



[2002-04-28 02:24:17] [EMAIL PROTECTED]

I'm planning to write a String_Manipulation (or something similiar,
we'll probably fight about that... ;-)). Assigned to myself.

-Tal



[2002-01-06 10:02:06] [EMAIL PROTECTED]

sounds if PEAR has another task ;). reclassified.



[2000-09-26 19:36:44] [EMAIL PROTECTED]

I don't know if this is the best way to submit a feature request, but I
think it would be handy to have a builtin makelinks() function, to
change all urls in a piece of text to actual links. eg, changing "my
homepage is at http://www.arse.net/"; to "my homepage is at http://www.arse.net/>http://www.arse.net/". 'course, it's
pretty easy to code this yourself, but then so is nl2br(), and having
it as part of the source would (maybe?) make it faster.




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

#21452 [Opn->Fbk]: Apache dumps core inside php code

[iliaa]

 ID:   21452
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Apache2 related
 Operating System: Linux - Sparc64
 PHP Version:  4.3.0
 New Comment:

Did this happen on a particular script and if so could you provide the
smallest possible version of the script with which the error can be
replicated.


Previous Comments:


[2003-01-06 00:35:26] [EMAIL PROTECTED]

Not sure why it dumped core, however I do have a backtrace to go with
this coredump.  Apache was running in prefork mode when this happened. 
I'm using Apache 2.0.43 as packaged by Debian.  PHP 4.3.0 was compiled
by hand.

(gdb) bt
#0  0x705e1794 in sapi_initialize_empty_request (tsrm_ls=0x101240) at
/tmp/php/php-4.3.0/main/SAPI.c:399
#1  0x705db460 in php_module_startup (sf=0x706742ac,
additional_modules=0x7067, num_additional_modules=1)
at /tmp/php/php-4.3.0/main/main.c:1035
#2  0x7062cfc0 in php_apache2_startup (sapi_module=0x706742ac) at
/tmp/php/php-4.3.0/sapi/apache2filter/sapi_apache2.c:269
#3  0x7062d85c in php_apache_server_startup (pconf=0xbb688,
plog=0xf3768, ptemp=0xf9780, s=0xbdcf0)
at /tmp/php/php-4.3.0/sapi/apache2filter/sapi_apache2.c:556
#4  0x00055fa0 in ap_run_post_config ()
#5  0x0005e9b8 in main ()
#6  0x703b08f0 in __libc_start_main () from /lib/libc.so.6





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

#21533 [Opn]: Trouble building PHP w/ GD and including ImageTTFxxx functions

[iliaa]

 ID:   21533
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: GD related
 Operating System: RH 7.2
 PHP Version:  4.3.0
 New Comment:

The ifdef is correct, because no matter what the value will be assigned
to error. There is another ifdef surrounding this code which has an
else condition that is used to set a value to error. So the crash you
are seeing comes from elsewhere.


Previous Comments:


[2003-01-21 09:28:38] [EMAIL PROTECTED]

PHP build:
configure --with-apxs=/usr/local/apache/bin/apxs
--with-mysql=/usr/local/mysql --enable-track-vars
--with-imap=/usr/local/imap --with-gd --enable-ftp --enable-sysvsem
--enable-sysvshm --enable-sockets --with-gettext
--with-mm=/usr/local/lib/mm --with-jpeg-dir=/usr/lib
--with-zlib-dir=/usr/local --with-openssl=/usr/local/ssl --with-ttf
--enable-gd-native-ttf --enable-gd-imgstrttf
--with-freetype-dir=/usr/local --with-dom

FreeType:
freetype-1.3.1.tar.gz was untarred and built and installed with:
configure
make
make install



[2003-01-20 17:11:22] [EMAIL PROTECTED]

What was the configure line ? And exactly what freetype 1.x
version was installed? And how?




[2003-01-20 16:48:08] [EMAIL PROTECTED]

I'm really not a Linux developer, and although what you are asking for
sounds easy enough, I don't know how to give you what you want.

I would like to reiterate that there are 2 issues here:
1. Configure incorrectly reporting my support for FreeType2
2. gd.c has code that given certain #if conditions, leaves the variable
'error' undefined. The crash is occuring because of the reference to
this floating pointer. I assume you want a backtrace to determine the
line of code that is crashing, but I'm *giving* you the line of code
that is crashing.



[2003-01-09 19:44:35] [EMAIL PROTECTED]

Can you generate a backtrace from the core file and please provide the
shortest possible version of the script that can be used to duplicate
the crash.



[2003-01-09 09:24:09] [EMAIL PROTECTED]

I am using the bundled GD library.



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

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

#21801 [Opn->Csd]: number_format do not round correctly

[iliaa]

 ID:   21801
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: *Math Functions
 Operating System: Linux
 PHP Version:  4.2.2
 New Comment:

In 4.3 both round() and number_format() round 0.5 to 1. Keep in mind
that this may also depend on your libc, which is what doing the
rounding.


Previous Comments:


[2003-01-21 12:38:38] [EMAIL PROTECTED]

";
echo number_format(0.50)."";
echo number_format(0.51)."";

echo round(0.49)."";
echo round(0.50)."";
echo round(0.51)."";
?>

returns

0
0
1

0
1
1

number_format do not round correctly while round does.





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

#21805 [Opn->Bgs]: NO file.php?something=x

[iliaa]

 ID:   21805
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Dynamic loading
 Operating System: Windows
 PHP Version:  4.2.3
 New Comment:

In PHP 4.2.0, the 'register_globals' setting default changed to
'off'. See http://www.php.net/release_4_2_0.php for more info.
We are sorry about the inconvenience, but this change was a necessary
part of our efforts to make PHP scripting more secure and portable.

turn on register_globals if you want to access GET/POST/COOKIE
variables like you did in your example.


Previous Comments:


[2003-01-21 13:52:13] [EMAIL PROTECTED]

I tried all web servers for windows but all the have the same problem:
The php quees are not avilable 
I've made a test file :

and name it test.php and run it (localhost/test.php?name=something) and
it gaves me an error i cant sent the values for the variables to the
script!!! 




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

#21643 [Opn->Csd]: ldap_search same criteria no results

[ryanphp]

 ID:   21643
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: LDAP related
 Operating System: windows 2000
 PHP Version:  4.3.0
 New Comment:

Ok, I'll close this. Basically the functionality has been changed a
bit, it seems that the new version of php_ldap.dll now requires escape
characters on special characters including '(' & ')' ... the old
version for win32 did not. It appears that this has been the case on
the unix based versions for some time now.


Previous Comments:


[2003-01-20 16:52:26] [EMAIL PROTECTED]

Sorry, I was counting the wrong thing... the single quotes are not
required, but the parens are a problem. Anyway, that seems to be what
it boils down to.



[2003-01-20 16:40:00] [EMAIL PROTECTED]

Aha... it doesn't like the parens ... also, it seems to not like the
single quote. The problem with that is if i don't use the single quotes
I get back 2 records. :-\



[2003-01-20 16:33:14] [EMAIL PROTECTED]

Ok, I give up. After I actually found one of those servers that worked
I couldn't find a single valid attribute to search on. I tried cn,
name, ... and other common attribute types. All returned invalid
attribute type. So here's a simpler sample of the problem:




PHP 4.2.3 extension returns: 1 records returned.
PHP 4.3.0 extension returns:
Warning: ldap_search(): Search: Bad search filter in
R:\WebApps\api\ldapSearcherTest.php on line 9

Warning: ldap_get_entries(): supplied argument is not a valid ldap
result resource in R:\WebApps\api\ldapSearcherTest.php on line 10
0 records returned.



[2003-01-19 17:57:16] [EMAIL PROTECTED]

leaving as feedback until a response comes in...



[2003-01-18 08:18:39] [EMAIL PROTECTED]

I'm on the edit submission tab but it still says "New Comment" I hope
this is the right way to respond to this. Anyway, I will try to build a
simple sample on Monday. Thanks!



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

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

#21805 [NEW]: NO file.php?something=x

[nasty_psycho]

From: [EMAIL PROTECTED]
Operating system: Windows
PHP version:  4.2.3
PHP Bug Type: Dynamic loading
Bug description:  NO file.php?something=x

I tried all web servers for windows but all the have the same problem:
The php quees are not avilable 
I've made a test file :

and name it test.php and run it (localhost/test.php?name=something) and it
gaves me an error i cant sent the values for the variables to the
script!!! 
-- 
Edit bug report at http://bugs.php.net/?id=21805&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21805&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21805&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21805&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21805&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21805&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21805&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21805&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21805&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21805&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21805&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21805&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21805&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21805&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21805&r=gnused

#21804 [Opn]: php crashes iPlanet - php4_execute

[dwells]

 ID:   21804
 User updated by:  [EMAIL PROTECTED]
-Reported By:  [EMAIL PROTECTED]
+Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Solaris 8
 PHP Version:  4.3.0
 New Comment:

Had the wrong email addr...


Previous Comments:


[2003-01-21 13:25:04] [EMAIL PROTECTED]

I can reliably crash iPlanet by running "http_load 
-parallel 5" by concurrently using both of the two scripts below. This
is like 20613, but that was fixed in Nov and I have this problem now
with a current version of php. I have found no resolution except to run
php single-threaded - stable, but hardly an option for a 100-user app
that makes Oracle queries... 

I have reproduced this with iPlanet 6.0sp2 and 6.0sp5, php4.2.3, php
4.3.0, and php4-STABLE-200301140030, running on a 280R and an Ultra 2.
I built php using gcc 2.95.3 with these options:
  --prefix=/shared/gnu \
  --with-config-file-path=$prefix/../lib \
  --enable-discard-path --enable-tracking  \
  --enable-libgcc --with-ndbm \
  --with-ldap= \
  --with-oracle= \
  --without-mysql --with-nsapi=
The error I see is:
 catastrophe (1625): Server crash detected (signal SIGSEGV)
 info (1625): Crash occurred in NSAPI SAF php4_execute
 info (1625): Crash occurred in function strlen from  module
/usr/lib/libc.so.1

Here is the back trace:
(gdb) bt
#0  0xfea33344 in strlen () from /usr/lib/libc.so.1
#1  0xfd6b3e90 in _estrdup (s=0xb8 )
at /shared/gnu/src/php-4.2.3/Zend/zend_alloc.c:322
#2  0xfd738948 in php_print_info (flag=32, tsrm_ls=0x8600e8)
at /shared/gnu/src/php-4.2.3/ext/standard/info.c:273
#3  0xfd73935c in zif_phpinfo (ht=0, return_value=0x8d6c18,
this_ptr=0x0, 
return_value_used=0, tsrm_ls=0x8600e8)
at /shared/gnu/src/php-4.2.3/ext/standard/info.c:471
#4  0xfd6c2740 in execute () from /opt/local/php/lib/nsapi/libphp4.so
#5  0xfd6d50d0 in zend_execute_scripts (type=8, tsrm_ls=0x8600e8,
retval=0x0, 
file_count=3) at /shared/gnu/src/php-4.2.3/Zend/zend.c:812
#6  0xfd6e4368 in php_execute_script (primary_file=0xfaef1b48, 
tsrm_ls=0x8600e8) at /shared/gnu/src/php-4.2.3/main/main.c:1383
#7  0xfd6e0b90 in nsapi_module_main (request_context=0x0,
tsrm_ls=0x8600e8)
at /shared/gnu/src/php-4.2.3/sapi/nsapi/nsapi.c:462
#8  0xfd6e0d1c in php4_execute (pb=0x3d47f8, sn=0x6e3a90, rq=0x6e3ad8)
at /shared/gnu/src/php-4.2.3/sapi/nsapi/nsapi.c:513
#9  0xff239b14 in __0Fcfunc_native_pool_thread_mainP6NNSTPWorkArg_s ()
   from
/opt/local/netscape/dev/iws60sp5/bin/https/lib/libns-httpd40.so
#10 0xfe8e16cc in NSTP_ThreadMain ()
   from /opt/local/netscape/dev/iws60sp5/bin/https/lib/libnstp.so
#11 0xfed676a0 in _pt_root ()
   from /opt/local/netscape/dev/iws60sp5/bin/https/lib/libnspr4.so
(gdb) 

Finally, here are the two scripts:
---


PHP Operational Qualification Test

This test displays a "Hello, world." announcment, then a series
of tables describing the PHP environment.


The classic announcement: 


PHP Info for this installation:







PHP Operational Qualification Test: Oracle Connectivity

This test connects to an Oracle database and displays some stuff.


Result size is ".$ncols." cols by ".$nrows."
rows.\n");
  print "\n\n";
  for ($i=0; $i<$ncols; $i++) {
printf("col[%s] = %stype[%d] = %s\n",
$i, "cursor", $i, "hisur");
  }
  print "\n";
  for ($j=0; $j<$nrows; $j++) {
for ($i=0; $i<$ncols; $i++) {
  printf("val[%d, %d] ='%s'", $j, $i, 'howdy');
}
printf("\n");
  }
  print "\n";
 ?>
 




Thanks,
David





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

#21804 [NEW]: php crashes iPlanet - php4_execute

[david]

From: [EMAIL PROTECTED]
Operating system: Solaris 8
PHP version:  4.3.0
PHP Bug Type: Reproducible crash
Bug description:  php crashes iPlanet - php4_execute

I can reliably crash iPlanet by running "http_load 
-parallel 5" by concurrently using both of the two scripts below. This is
like 20613, but that was fixed in Nov and I have this problem now with a
current version of php. I have found no resolution except to run php
single-threaded - stable, but hardly an option for a 100-user app that
makes Oracle queries... 

I have reproduced this with iPlanet 6.0sp2 and 6.0sp5, php4.2.3, php
4.3.0, and php4-STABLE-200301140030, running on a 280R and an Ultra 2. I
built php using gcc 2.95.3 with these options:
  --prefix=/shared/gnu \
  --with-config-file-path=$prefix/../lib \
  --enable-discard-path --enable-tracking  \
  --enable-libgcc --with-ndbm \
  --with-ldap= \
  --with-oracle= \
  --without-mysql --with-nsapi=
The error I see is:
 catastrophe (1625): Server crash detected (signal SIGSEGV)
 info (1625): Crash occurred in NSAPI SAF php4_execute
 info (1625): Crash occurred in function strlen from  module
/usr/lib/libc.so.1

Here is the back trace:
(gdb) bt
#0  0xfea33344 in strlen () from /usr/lib/libc.so.1
#1  0xfd6b3e90 in _estrdup (s=0xb8 )
at /shared/gnu/src/php-4.2.3/Zend/zend_alloc.c:322
#2  0xfd738948 in php_print_info (flag=32, tsrm_ls=0x8600e8)
at /shared/gnu/src/php-4.2.3/ext/standard/info.c:273
#3  0xfd73935c in zif_phpinfo (ht=0, return_value=0x8d6c18, this_ptr=0x0,

return_value_used=0, tsrm_ls=0x8600e8)
at /shared/gnu/src/php-4.2.3/ext/standard/info.c:471
#4  0xfd6c2740 in execute () from /opt/local/php/lib/nsapi/libphp4.so
#5  0xfd6d50d0 in zend_execute_scripts (type=8, tsrm_ls=0x8600e8,
retval=0x0, 
file_count=3) at /shared/gnu/src/php-4.2.3/Zend/zend.c:812
#6  0xfd6e4368 in php_execute_script (primary_file=0xfaef1b48, 
tsrm_ls=0x8600e8) at /shared/gnu/src/php-4.2.3/main/main.c:1383
#7  0xfd6e0b90 in nsapi_module_main (request_context=0x0,
tsrm_ls=0x8600e8)
at /shared/gnu/src/php-4.2.3/sapi/nsapi/nsapi.c:462
#8  0xfd6e0d1c in php4_execute (pb=0x3d47f8, sn=0x6e3a90, rq=0x6e3ad8)
at /shared/gnu/src/php-4.2.3/sapi/nsapi/nsapi.c:513
#9  0xff239b14 in __0Fcfunc_native_pool_thread_mainP6NNSTPWorkArg_s ()
   from /opt/local/netscape/dev/iws60sp5/bin/https/lib/libns-httpd40.so
#10 0xfe8e16cc in NSTP_ThreadMain ()
   from /opt/local/netscape/dev/iws60sp5/bin/https/lib/libnstp.so
#11 0xfed676a0 in _pt_root ()
   from /opt/local/netscape/dev/iws60sp5/bin/https/lib/libnspr4.so
(gdb) 

Finally, here are the two scripts:
---


PHP Operational Qualification Test

This test displays a "Hello, world." announcment, then a series
of tables describing the PHP environment.


The classic announcement: 


PHP Info for this installation:







PHP Operational Qualification Test: Oracle Connectivity

This test connects to an Oracle database and displays some stuff.


Result size is ".$ncols." cols by ".$nrows." rows.\n");
  print "\n\n";
  for ($i=0; $i<$ncols; $i++) {
printf("col[%s] = %stype[%d] = %s\n",
$i, "cursor", $i, "hisur");
  }
  print "\n";
  for ($j=0; $j<$nrows; $j++) {
for ($i=0; $i<$ncols; $i++) {
  printf("val[%d, %d] ='%s'", $j, $i, 'howdy');
}
printf("\n");
  }
  print "\n";
 ?>
 




Thanks,
David

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

#21803 [NEW]: php4ts.dll crash with COM

[cubo23]

From: [EMAIL PROTECTED]
Operating system: Win Me
PHP version:  4.3.0
PHP Bug Type: COM related
Bug description:  php4ts.dll crash with COM

hello,
while trying to run a script that opens a msaccess database, i get an
"access violation" error for php4ts.dll and php crashes.
this is the point where the error occurs:
$conn = new COM("ADODB.Connection");
I am using Windows Me, PHP 4.3.0 on an Apache 2.0
can someone please help?
thank u
-- 
Edit bug report at http://bugs.php.net/?id=21803&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21803&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21803&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21803&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21803&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21803&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21803&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21803&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21803&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21803&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21803&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21803&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21803&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21803&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21803&r=gnused

#17868 [Com]: Doesn't work two and more directives of PHP code on different OS

[mike_tharp]

 ID:   17868
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Verified
 Bug Type: Apache2 related
 Operating System: *
 PHP Version:  4.3.0-dev
 New Comment:

I have run accross this as well on IIS5 and Win2k so it isn't limited
to just Apache. 

Going back to PHP 4.2.3 resolves the issue but 4.3.0 will only
acknowledge the first include and then page halts loading when the
second is encountered.


Previous Comments:


[2003-01-17 08:13:29] [EMAIL PROTECTED]

reproduced with
apache 2.0.39 php 4.2.2 and php 4.3.0
apache 2.0.43 php 4.2.2 and php 4.3.0

linux kernel 2.4.19
gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-81)

if php is built as module, the rest of includes output php's code
without interpretation



[2003-01-14 14:32:43] [EMAIL PROTECTED]

I've reproduced this bug using Apache 2.0.43 and PHP 4.3.0 on RedHat
Linux 7.3

I suggest that people start voting to get this bug fixed in Apache!
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10041
and
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15356

Now, back to Apache 1.3.27 :(



[2002-12-23 16:17:51] [EMAIL PROTECTED]

The Apache folks are well aware that the current filter code is a mess
and needs a rewrite.  



[2002-12-23 15:23:07] [EMAIL PROTECTED]

Yey! 

Why do you keep pushing things from side to an another ? Would it be
just plain nice of both sides would work this thing out ? If you php
guys know that the problem is somewhere in specific code, then why dont
go to the a2 bugzilla and point out the real issue about this bug
and/or otherway around ?



[2002-12-14 04:42:11] [EMAIL PROTECTED]

Apache 2's filters are basically broken.  This is not going to be fixed
anytime soon.  Nobody is working on it and I doubt anybody will until
someone sits down and rewrites the Apache2 filter API from scratch. 
Perhaps in Apache 2.2.



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

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

#21800 [Ver]: Segfault in CLI

[iliaa]

 ID:   21800
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Verified
 Bug Type: Zend Engine 2 problem
 Operating System: RH 8.0
 PHP Version:  5CVS-2003-01-21 (dev)
 New Comment:

The bug occurs due to the handler in execute_data.opline->handler not
being set. 


Previous Comments:


[2003-01-21 12:47:55] [EMAIL PROTECTED]

not reproduced with ZE1 => reclassfying as ZE2 problem




[2003-01-21 12:45:08] [EMAIL PROTECTED]

verified




[2003-01-21 12:36:38] [EMAIL PROTECTED]

the following produces a coredump:

root@numenor-19:30 [~]:php -ea
Interactive mode enabled



Segmentation fault (core dumped)

Backtrace gives
(gdb) bt
#0  0x in ?? ()
#1  0x081f3a4f in execute (op_array=0x0) at
/usr/local/src/cvs/php5/Zend/zend_execute.c:1218
#2  0x081d78b9 in execute_new_code () at
/usr/local/src/cvs/php5/Zend/zend_execute_API.c:827
#3  0x081be693 in zendparse () at
/usr/local/src/cvs/php5/Zend/zend_language_parser.y:148
#4  0x081c272d in compile_file (file_handle=0xb930, type=2) at
/usr/local/src/cvs/php5/Zend/zend_language_scanner.l:297
#5  0x081e14ad in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/cvs/php5/Zend/zend.c:992
#6  0x081a84c7 in php_execute_script (primary_file=0xb930) at
/usr/local/src/cvs/php5/main/main.c:1691
#7  0x0820966f in main (argc=2, argv=0xb9c4) at
/usr/local/src/cvs/php5/sapi/cli/php_cli.c:753
#8  0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6





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

#21800 [Ver]: Segfault in CLI

[moriyoshi]

 ID:   21800
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Verified
-Bug Type: Reproducible crash
+Bug Type: Zend Engine 2 problem
 Operating System: RH 8.0
 PHP Version:  5CVS-2003-01-21 (dev)
 New Comment:

not reproduced with ZE1 => reclassfying as ZE2 problem



Previous Comments:


[2003-01-21 12:45:08] [EMAIL PROTECTED]

verified




[2003-01-21 12:36:38] [EMAIL PROTECTED]

the following produces a coredump:

root@numenor-19:30 [~]:php -ea
Interactive mode enabled



Segmentation fault (core dumped)

Backtrace gives
(gdb) bt
#0  0x in ?? ()
#1  0x081f3a4f in execute (op_array=0x0) at
/usr/local/src/cvs/php5/Zend/zend_execute.c:1218
#2  0x081d78b9 in execute_new_code () at
/usr/local/src/cvs/php5/Zend/zend_execute_API.c:827
#3  0x081be693 in zendparse () at
/usr/local/src/cvs/php5/Zend/zend_language_parser.y:148
#4  0x081c272d in compile_file (file_handle=0xb930, type=2) at
/usr/local/src/cvs/php5/Zend/zend_language_scanner.l:297
#5  0x081e14ad in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/cvs/php5/Zend/zend.c:992
#6  0x081a84c7 in php_execute_script (primary_file=0xb930) at
/usr/local/src/cvs/php5/main/main.c:1691
#7  0x0820966f in main (argc=2, argv=0xb9c4) at
/usr/local/src/cvs/php5/sapi/cli/php_cli.c:753
#8  0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6





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

#21800 [Opn->Ver]: Segfault in CLI

[moriyoshi]

 ID:   21800
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Verified
 Bug Type: Reproducible crash
 Operating System: RH 8.0
 PHP Version:  5CVS-2003-01-21 (dev)
 New Comment:

verified



Previous Comments:


[2003-01-21 12:36:38] [EMAIL PROTECTED]

the following produces a coredump:

root@numenor-19:30 [~]:php -ea
Interactive mode enabled



Segmentation fault (core dumped)

Backtrace gives
(gdb) bt
#0  0x in ?? ()
#1  0x081f3a4f in execute (op_array=0x0) at
/usr/local/src/cvs/php5/Zend/zend_execute.c:1218
#2  0x081d78b9 in execute_new_code () at
/usr/local/src/cvs/php5/Zend/zend_execute_API.c:827
#3  0x081be693 in zendparse () at
/usr/local/src/cvs/php5/Zend/zend_language_parser.y:148
#4  0x081c272d in compile_file (file_handle=0xb930, type=2) at
/usr/local/src/cvs/php5/Zend/zend_language_scanner.l:297
#5  0x081e14ad in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/local/src/cvs/php5/Zend/zend.c:992
#6  0x081a84c7 in php_execute_script (primary_file=0xb930) at
/usr/local/src/cvs/php5/main/main.c:1691
#7  0x0820966f in main (argc=2, argv=0xb9c4) at
/usr/local/src/cvs/php5/sapi/cli/php_cli.c:753
#8  0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6





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

#21801 [NEW]: number_format do not round correctly

[supad]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.2.2
PHP Bug Type: *Math Functions
Bug description:  number_format do not round correctly

";
echo number_format(0.50)."";
echo number_format(0.51)."";

echo round(0.49)."";
echo round(0.50)."";
echo round(0.51)."";
?>

returns

0
0
1

0
1
1

number_format do not round correctly while round does.

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

#21800 [NEW]: Segfault in CLI

[eru]

From: [EMAIL PROTECTED]
Operating system: RH 8.0
PHP version:  5CVS-2003-01-21 (dev)
PHP Bug Type: Reproducible crash
Bug description:  Segfault in CLI

the following produces a coredump:

root@numenor-19:30 [~]:php -ea
Interactive mode enabled



Segmentation fault (core dumped)

Backtrace gives
(gdb) bt
#0  0x in ?? ()
#1  0x081f3a4f in execute (op_array=0x0) at
/usr/local/src/cvs/php5/Zend/zend_execute.c:1218
#2  0x081d78b9 in execute_new_code () at
/usr/local/src/cvs/php5/Zend/zend_execute_API.c:827
#3  0x081be693 in zendparse () at
/usr/local/src/cvs/php5/Zend/zend_language_parser.y:148
#4  0x081c272d in compile_file (file_handle=0xb930, type=2) at
/usr/local/src/cvs/php5/Zend/zend_language_scanner.l:297
#5  0x081e14ad in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /usr/local/src/cvs/php5/Zend/zend.c:992
#6  0x081a84c7 in php_execute_script (primary_file=0xb930) at
/usr/local/src/cvs/php5/main/main.c:1691
#7  0x0820966f in main (argc=2, argv=0xb9c4) at
/usr/local/src/cvs/php5/sapi/cli/php_cli.c:753
#8  0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

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

#21772 [Opn->Bgs]: mssql speed when using remote server

[iliaa]

 ID:   21772
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: MSSQL related
 Operating System: windows 2000/sp3
 PHP Version:  4.2.3
 New Comment:

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

Thank you for your interest in PHP.

There are some networking issues when Linux & Win32 machines
communicate. For example a stock 100mbit lan only operates at 1/3 - 1/2
speed while if both machines run the same OS all 100mbit are
avaliable.
Since this appears to be a networking issue, I am marking this a bogus
(not a php bug).


Previous Comments:


[2003-01-21 11:24:59] [EMAIL PROTECTED]

Hi,

I'm unable to reproduce these diferences on my systems.

I have tested the speed on a SQL Server 7.0 and I get almost the same
response times on local and remote connections. In my case the local
connects are slower due to the fact that both PHP and MSSQL server is
competing on the CPU.

If there is a diference from Linux to Windows this must be caused by
old versions of DBLIB used on Windows. I'm working on using FreeTDS on
Windows.

Other factors can be how you configure your MSSQL Server and Clients.
If you don't do anything MSSQL defaults to named pipes (approx 8 times
slover on a network but faster on a local connection compared to
TCP/IP).
You should use the Client Network Configuration tool to specify default
libraries and configure aliases for your local and remote servers. Then
use this alias when connecting to the server.

When you compare PHP and MS Queary Tool you compare apples and oranges.
PHP is build on an old database protocol and MS Query Tool uses the
most modern technology available.

- Frank



[2003-01-21 03:51:35] [EMAIL PROTECTED]

Thank you Joey!
Good work!



[2003-01-21 03:49:56] [EMAIL PROTECTED]

We've been using PHP hosted on a win32 machine to connect 
to SQL Server 2000.  When the PHP host and the MSSQL host
are the same machine, everything is fine. But when we try
to use seperate hosts for PHP and MSSQL, query times become
unbearably slow.

The odd thing is that I can run the same scripts on the
same network connecting to the same MSSQL server from a Linux box, and
see acceptable response times.

As an example, I did a script that does 1000 iterations
of 'sp_sproc_columns @procudure_name = "some_proc"' in three
different setups.


Setup 1:
  MSSQL and PHP on the Win2k host, call it machine 'A'
  Average Response time over 5 iterations of script: 18s

Setup 2:
  MSSQL on host 'A', PHP on Linux host ('B')
  Average Response time over 5 iterations of script: 41s
  (Given the size of the result set, this is an acceptable
   response time.)

Setup 3:
  MSSQL on host 'A', PHP on seperate Win2k host ('C')
  Average Response time over 5 iterations: 3 minutes, 20s

Clearly, there is something wrong here. I had a different admin set up
a similar network without looking at my php.ini, etc., and he had
similar results.



[2003-01-21 03:47:22] [EMAIL PROTECTED]

Actually, we have done extensive testing on this bug.

If I write a C++ program to run the same query results, it operates as
expected.

If I run the query in 'Query Analyzer', a Microsoft tool, it operates
as expected.

If I run the query via PHP from a LINUX box (compiled with MSSQL
support via the FreeTDS drivers), it operates as expected.

If I run the query via PHP from a Windows box, LO AND BEHOLD, 500-600%
longer to run the query!

This is most definitely something wrong between PHP and the MSSQL
libraries on Win32 machines. I'll add my post from php-db that has
better details in a moment.



[2003-01-20 13:52:49] [EMAIL PROTECTED]

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

Thank you for your interest in PHP.

When dealing with i-net connections even if they are local there is a
lot more additional work that needs to be done. I wouldn't think this
would amount to 3.5 times speed difference, but with Win32 you never
know.
PHP does not initiate the connection to the SQL server itself, it does
it by using the appropriate libraries. So, I do not believe that PHP
could be at fault here.

#21799 [Opn->Bgs]: ZEND_INI_PARSER_POP_ENTRY symbol undefined

[iliaa]

 ID:   21799
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Tru64
 PHP Version:  4CVS-2003-01-21 (stable)
 New Comment:

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

Somehow you are using ZE1 and not ZE2 with head, hence the problem you
are seing. Grab a snapshot from the snapshot server at
http://snaps.php.net/ it should work fine.


Previous Comments:


[2003-01-21 11:30:34] [EMAIL PROTECTED]

The macro ZEND_INI_PARSER_POP_ENTRY are used twice :

ext/standard/basic_functions.c:2827: 
  case ZEND_INI_PARSER_POP_ENTRY:

and

main/php_ini.c:199: 
  case ZEND_INI_PARSER_POP_ENTRY: {


But ZEND_INI_PARSER_POP_ENTRY is defined nowhere in source.






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

#21799 [NEW]: ZEND_INI_PARSER_POP_ENTRY symbol undefined

[soula]

From: [EMAIL PROTECTED]
Operating system: Tru64
PHP version:  4CVS-2003-01-21 (stable)
PHP Bug Type: Compile Failure
Bug description:  ZEND_INI_PARSER_POP_ENTRY symbol undefined

The macro ZEND_INI_PARSER_POP_ENTRY are used twice :

ext/standard/basic_functions.c:2827: 
  case ZEND_INI_PARSER_POP_ENTRY:

and

main/php_ini.c:199: 
  case ZEND_INI_PARSER_POP_ENTRY: {


But ZEND_INI_PARSER_POP_ENTRY is defined nowhere in source.


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

#21771 [Opn->Fbk]: Header('Location: ... ') problem

[hholzgra]

 ID:   21771
 Updated by:   [EMAIL PROTECTED]
-Summary:  variable names changing in turkish locale
-Reported By:  [EMAIL PROTECTED]
+Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Variables related
-Operating System: linux kernel 2.4.18
+Operating System: Windows 2000
 PHP Version:  4.3.0
 New Comment:

strange ... this was fixed for functions constants
but should not affect variables, as these are 
case insensitive (so no conversions take place
while resolving them)
or is there something different going on with
the super-globals?

does this affect $_SESSION only? what if you have
register_globals enabled and try to pass something
like "...script.php?ID=test"? do you have $ID or
$ÝD set in your script then?


Previous Comments:


[2003-01-21 06:27:16] [EMAIL PROTECTED]

by the way, it's turkish locale
tr_TR
iso8859-9



[2003-01-21 06:24:08] [EMAIL PROTECTED]

no code works. even the example in the php session documentation...
:)





[2003-01-20 16:03:17] [EMAIL PROTECTED]

Can you provide some short example script?
And what locale causes this?




[2003-01-20 06:39:44] [EMAIL PROTECTED]

Oops... This may not be related to php. It may be resulting from the
turkish locale system itself. Let me investigate...



[2003-01-20 06:24:33] [EMAIL PROTECTED]

I thought this bug was submitted for an earlier version of php (maybe
4.1.2 or so), but it seems to be not corrected.

The main problem is, the lowercase of "I" in Turkish is not "i". it is
an "i" without a dot on top of it: "ý".

Something in php affects all variables including the letter "I". So
$_SESSION, SID, or PHPSESSID doesn't work.

I think some code in php first changes all variables names to lowercase
(and for turkish locale, incorrectly lowercases I to i), and then
changes all variable names to uppercase (and correctly uppercases i to
Ý).

So, $_SESSION becomes $_SESSÝON, and since php couldn't find a variable
named $_SESSION, it regenerates a new PHPSESSID.

The correct uppercase - lowercase of this letter is:

I - ý
Ý - i

A workaround for this is making sure apache server starts in en_US
locale.




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

#21772 [Opn]: mssql speed when using remote server

[fmk]

 ID:   21772
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: MSSQL related
 Operating System: windows 2000/sp3
 PHP Version:  4.2.3
 New Comment:

Hi,

I'm unable to reproduce these diferences on my systems.

I have tested the speed on a SQL Server 7.0 and I get almost the same
response times on local and remote connections. In my case the local
connects are slower due to the fact that both PHP and MSSQL server is
competing on the CPU.

If there is a diference from Linux to Windows this must be caused by
old versions of DBLIB used on Windows. I'm working on using FreeTDS on
Windows.

Other factors can be how you configure your MSSQL Server and Clients.
If you don't do anything MSSQL defaults to named pipes (approx 8 times
slover on a network but faster on a local connection compared to
TCP/IP).
You should use the Client Network Configuration tool to specify default
libraries and configure aliases for your local and remote servers. Then
use this alias when connecting to the server.

When you compare PHP and MS Queary Tool you compare apples and oranges.
PHP is build on an old database protocol and MS Query Tool uses the
most modern technology available.

- Frank


Previous Comments:


[2003-01-21 03:51:35] [EMAIL PROTECTED]

Thank you Joey!
Good work!



[2003-01-21 03:49:56] [EMAIL PROTECTED]

We've been using PHP hosted on a win32 machine to connect 
to SQL Server 2000.  When the PHP host and the MSSQL host
are the same machine, everything is fine. But when we try
to use seperate hosts for PHP and MSSQL, query times become
unbearably slow.

The odd thing is that I can run the same scripts on the
same network connecting to the same MSSQL server from a Linux box, and
see acceptable response times.

As an example, I did a script that does 1000 iterations
of 'sp_sproc_columns @procudure_name = "some_proc"' in three
different setups.


Setup 1:
  MSSQL and PHP on the Win2k host, call it machine 'A'
  Average Response time over 5 iterations of script: 18s

Setup 2:
  MSSQL on host 'A', PHP on Linux host ('B')
  Average Response time over 5 iterations of script: 41s
  (Given the size of the result set, this is an acceptable
   response time.)

Setup 3:
  MSSQL on host 'A', PHP on seperate Win2k host ('C')
  Average Response time over 5 iterations: 3 minutes, 20s

Clearly, there is something wrong here. I had a different admin set up
a similar network without looking at my php.ini, etc., and he had
similar results.



[2003-01-21 03:47:22] [EMAIL PROTECTED]

Actually, we have done extensive testing on this bug.

If I write a C++ program to run the same query results, it operates as
expected.

If I run the query in 'Query Analyzer', a Microsoft tool, it operates
as expected.

If I run the query via PHP from a LINUX box (compiled with MSSQL
support via the FreeTDS drivers), it operates as expected.

If I run the query via PHP from a Windows box, LO AND BEHOLD, 500-600%
longer to run the query!

This is most definitely something wrong between PHP and the MSSQL
libraries on Win32 machines. I'll add my post from php-db that has
better details in a moment.



[2003-01-20 13:52:49] [EMAIL PROTECTED]

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

Thank you for your interest in PHP.

When dealing with i-net connections even if they are local there is a
lot more additional work that needs to be done. I wouldn't think this
would amount to 3.5 times speed difference, but with Win32 you never
know.
PHP does not initiate the connection to the SQL server itself, it does
it by using the appropriate libraries. So, I do not believe that PHP
could be at fault here.



[2003-01-20 08:01:06] [EMAIL PROTECTED]

I forgot one detail:
I test both MSSQL 7 and MSSQL 2K with latest services packs, 
supplied from MS.



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

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

#21798 [NEW]: New mail() function disable some functionalities

[webmaster]

From: [EMAIL PROTECTED]
Operating system: Windows XP
PHP version:  4.3.0
PHP Bug Type: *Mail Related
Bug description:  New mail() function disable some functionalities

We use a small php script to sent multipart/mime mails with text/html and
pics included in the same mail.

People are reading these mails mostly with Outlook Express.

Outlook Express seems to require some mime sections separated by \r\n\r\n,
and maybe other mail readers need it too (no test made for now).

but since 4.3.0 a part of code in the win32\sendmail.c file replaces every
 double \r\n by a single one.

I don't know why these changes have been done, but please disable them or
give us a way to disable this feature by the php.ini file, without having
to change and compile the whole project (we don't have a C compiler)

**
  Code mentioned above.
**

/* This pattern removes \r\n from the start of the string,
 * \r\n from the end of the string and also makes sure every line
 * is only wrapped with a single \r\n (thus reduces multiple
 * occurences of \r\n between lines to a single \r\n) */
#define PHP_WIN32_MAIL_RMVDBL_PATTERN   "/^\r\n|(\r\n)+$/m"
#define PHP_WIN32_MAIL_RMVDBL_REPLACE   ""


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

#20935 [Opn]: mssql_query causes segfault

[fmk]

 ID:   20935
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: MSSQL related
 Operating System: RedHat Linux 7.2 / Apache 1.3.27
 PHP Version:  4.3.0
 New Comment:

Can you test the same code under Win32 ?

This could be a bug in FreeTDS. To my knowledge the latest version of
that is 0.60!

- Frank


Previous Comments:


[2003-01-21 07:56:03] [EMAIL PROTECTED]

recompiled as cgi but still generates the same error.

(gdb) bt
#0  0x in ?? ()
#1  0x08094c14 in _mssql_fetch_batch (mssql_ptr=0x82658f4,
result=0x82682d4, retvalue=-1)
at /home/jonas/devel/php-4.3.0/ext/mssql/php_mssql.c:1020
#2  0x08095267 in zif_mssql_query (ht=2, return_value=0x827731c,
this_ptr=0x0, return_value_used=1)
at /home/jonas/devel/php-4.3.0/ext/mssql/php_mssql.c:1143
#3  0x08194083 in execute (op_array=0x8264864) at
/home/jonas/devel/php-4.3.0/Zend/zend_execute.c:1596
#4  0x0818406a in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/jonas/devel/php-4.3.0/Zend/zend.c:864
#5  0x08153e05 in php_execute_script (primary_file=0xbfffe780) at
/home/jonas/devel/php-4.3.0/main/main.c:1573
#6  0x0819a234 in main (argc=3, argv=0xbfffe834) at
/home/jonas/devel/php-4.3.0/sapi/cgi/cgi_main.c:1424
#7  0x40238657 in __libc_start_main (main=0x8199878 , argc=3,
ubp_av=0xbfffe834, init=0x8067d2c <_init>,
fini=0x819aa40 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>,
stack_end=0xbfffe82c) at ../sysdeps/generic/libc-start.c:129



[2003-01-02 18:45:35] [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.





[2002-12-11 08:42:28] [EMAIL PROTECTED]

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

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



[2002-12-11 08:40:15] [EMAIL PROTECTED]

(FreeTDS 1.5 2002/08/24, MSSQL 7 (remote))

mssql_query causes when using the following SQLSTATEMENT

"SELECT a.*, b.* FROM dbo.psl AS b LEFT JOIN dbo.prc AS a ON (a.idPSL =
b.idPSL) WHERE b.OrderNo LIKE '%123169%' AND a.idPSL > '0'"

while simple queries like "SELECT * FROM dbo.psl" works just fine.

The problem appears only if the query tries to return
information.




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

#21796 [Fbk->Opn]: Compile fails on AIX 4.3.3

[ed]

 ID:   21796
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: AIX 4.3.3
 PHP Version:  4.3.0
 New Comment:

Same problem, same line number.


Previous Comments:


[2003-01-21 09:35:13] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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



[2003-01-21 09:32:54] [EMAIL PROTECTED]

A few minor warnings with configure, then configure ends with:

| about the implications of having register_globals set to on, and   |
| avoid using it if possible.|
++

./config.status[1739]: 6: bad file unit number
./config.status[1740]: 6: bad file unit number

Didnt seem too bad, so I went with the compile, and it fails with:

cc -I/root/php/php-4.3.0/ext/mysql/libmysql -Iext/mysql/
-I/root/php/php-4.3.0/ext/mysql/ -DPHP_ATOM_INC
-I/root/php/php-4.3.0/include -I/root/php/php-4.3.0/main
-I/root/php/php-4.3.0 -I/root/php/php-4.3.0/Zend
-I/root/php/php-4.3.0/ext/xml/expat  -I/root/php/php-4.3.0/TSRM  -g  -c
/root/php/php-4.3.0/ext/mysql/libmysql/my_tempnam.c -o
ext/mysql/libmysql/my_tempnam.o  && echo >
ext/mysql/libmysql/my_tempnam.lo
"/root/php/php-4.3.0/ext/mysql/libmysql/my_tempnam.c", line 99.5:
1506-025 (S) Operand must be a modifiable lvalue.
"/root/php/php-4.3.0/ext/mysql/libmysql/my_tempnam.c", line 105.3:
1506-025 (S) Operand must be a modifiable lvalue.
make: 1254-004 The error code from the last command is 1.

I saw another bug here with the same exact compile failure, but in a
different file, and it was fixed. Hopefully this will be as easy.




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

#21790 [Bgs]: 0-Byte-Problem

[phanto]

 ID:   21790
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: *General Issues
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

what would adding a \0 in a string buy you ?
if you can come up with a *real* exploit we consider reopening this
report, but after a short discussion we weren't able find a sample
where this exploit would enable you to access a file which you can't
access without it (or whatever else you want to achive with that null
byte in a string).

and btw yes, we _can_ read c code.

harald


Previous Comments:


[2003-01-21 09:55:21] [EMAIL PROTECTED]

Please read carefully. It is defintiv a problem of PHP! If you cannot
read a C-code or dont understand the null-byte-problem, please let me
know.



[2003-01-21 08:29:07] [EMAIL PROTECTED]

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

Thank you for your interest in PHP.

In many cases the files opened by PHP are are not specified via user
input. When they are, it is up to the user to be aware of such things
and handle them appropriately. In many cases your patch would simply
add unnecessary overhead.



[2003-01-21 00:35:51] [EMAIL PROTECTED]

I read this Mail from Ian Clelland on [EMAIL PROTECTED] And I
think, this is a problem, that should be fixed.

On Thu, Jan 16, 2003 at 12:07:12AM +0100, Nicob wrote:

>> On Sun, 2003-01-12 at 16:03, [EMAIL PROTECTED] wrote:
>
>>> > index.php :
>>> >$cfg_file = "${cfg_dir}/${bn}.${ext}";
>>> >
>>> >
http://www.w-agora.net/current/index.php?site=demos&bn=../../../../../../../../../../etc/passwd%00

>>> >
http://www.w-agora.net/current/modules.php?mod=fm&file=../../../../../../../../../../etc/passwd%00&bn=fm_d1

>
>> 
>> AFAIK, the Null-byte attack doesn't work with PHP. It works with
Perl
>> and some Java apps, yes, but not PHP ...


PHP strings in general are stored with their lengths, and can contain
arbitrary binary data (unlike, say, C). Within PHP, strings containing
null bytes are safe to use.

The problem here is that PHP will often pass PHP-function-parameters
unchecked directly to the lower-level C library functions.

PHP may handle a filename like '/etc/passwd\x00.ext' just fine, but if
it passes the address of that string to fopen(), then the C function
will treat the argument as a null-terminated string, and open
/etc/passwd.


As a quick proof-of-concept, try this code under your favourite PHP
interpreter (I've tested it on a 4.0-series platform, and a quick
perusal of the the relevant files in the 4.3.0 source doesn't show any
protection against this):




Output:
/etc/passwd .ext
root:x:0:0:root:/root:/bin/bash



You can see by the output of the echo statement that PHP deals with
null
bytes very well within strings, but that fopen stopped reading the
filename at the null.

This looks to be quite difficult to guard against -- the application
level solution would have to involve scanning all strings for null
bytes
before passing them to any of a very large number of PHP functions. A
better solution would be to have PHP itself do a libc string length
check before passing arguments to lower-level functions.

Adding just a few lines to ext/standard/file.c should prevent an
attack
like this on fopen:

***
*** 1086,1092 
--- 1086,1095 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss|br",
&mode, &mode_len, &use_include_path,
&zcontext) == FAILURE) {
RETURN_FALSE;
}
+   if (strlen(filename) != filename_len) {
+   RETURN_FALSE;
+   }
if (zcontext) {
ZEND_FETCH_RESOURCE(context, php_stream_context*,
&zcontext, -1, "stream-context", le_stream_context);
}


There is almost certainly a better place to check this; I'm not that
familiar with the code. And, of course, there are probably at least a
hundred other points in the code where a patch like this needs to be
applied.


Ian Clelland
<[EMAIL PROTECTED]>




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

#21797 [Opn->Bgs]: compile stops, commad-line too long

[derick]

 ID:   21797
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Solaris 6
 PHP Version:  4.3.0
 New Comment:

Due to a bug in the installed sed on your system the build
fails. Install GNU sed and it should be okay.
 
Thank you for your interest in PHP.

 


Previous Comments:


[2003-01-21 09:54:35] [EMAIL PROTECTED]

Hi,
I have a problem compiling php on my sun workstation. The make stops
with the error message:

/bin/sh libtool ..
Command line too long
Command line too long
Command line too long
gcc: main/php_ini: No such file or directory

I replaced the very long list of arguments with .. Its more than
3kb long.

The problem was reported prior and solved in earlier versions  but It
appeared again.




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

#21790 [Com]: 0-Byte-Problem

[ritze]

 ID:   21790
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: *General Issues
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

Please read carefully. It is defintiv a problem of PHP! If you cannot
read a C-code or dont understand the null-byte-problem, please let me
know.


Previous Comments:


[2003-01-21 08:29:07] [EMAIL PROTECTED]

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

Thank you for your interest in PHP.

In many cases the files opened by PHP are are not specified via user
input. When they are, it is up to the user to be aware of such things
and handle them appropriately. In many cases your patch would simply
add unnecessary overhead.



[2003-01-21 00:35:51] [EMAIL PROTECTED]

I read this Mail from Ian Clelland on [EMAIL PROTECTED] And I
think, this is a problem, that should be fixed.

On Thu, Jan 16, 2003 at 12:07:12AM +0100, Nicob wrote:

>> On Sun, 2003-01-12 at 16:03, [EMAIL PROTECTED] wrote:
>
>>> > index.php :
>>> >$cfg_file = "${cfg_dir}/${bn}.${ext}";
>>> >
>>> >
http://www.w-agora.net/current/index.php?site=demos&bn=../../../../../../../../../../etc/passwd%00

>>> >
http://www.w-agora.net/current/modules.php?mod=fm&file=../../../../../../../../../../etc/passwd%00&bn=fm_d1

>
>> 
>> AFAIK, the Null-byte attack doesn't work with PHP. It works with
Perl
>> and some Java apps, yes, but not PHP ...


PHP strings in general are stored with their lengths, and can contain
arbitrary binary data (unlike, say, C). Within PHP, strings containing
null bytes are safe to use.

The problem here is that PHP will often pass PHP-function-parameters
unchecked directly to the lower-level C library functions.

PHP may handle a filename like '/etc/passwd\x00.ext' just fine, but if
it passes the address of that string to fopen(), then the C function
will treat the argument as a null-terminated string, and open
/etc/passwd.


As a quick proof-of-concept, try this code under your favourite PHP
interpreter (I've tested it on a 4.0-series platform, and a quick
perusal of the the relevant files in the 4.3.0 source doesn't show any
protection against this):




Output:
/etc/passwd .ext
root:x:0:0:root:/root:/bin/bash



You can see by the output of the echo statement that PHP deals with
null
bytes very well within strings, but that fopen stopped reading the
filename at the null.

This looks to be quite difficult to guard against -- the application
level solution would have to involve scanning all strings for null
bytes
before passing them to any of a very large number of PHP functions. A
better solution would be to have PHP itself do a libc string length
check before passing arguments to lower-level functions.

Adding just a few lines to ext/standard/file.c should prevent an
attack
like this on fopen:

***
*** 1086,1092 
--- 1086,1095 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss|br",
&mode, &mode_len, &use_include_path,
&zcontext) == FAILURE) {
RETURN_FALSE;
}
+   if (strlen(filename) != filename_len) {
+   RETURN_FALSE;
+   }
if (zcontext) {
ZEND_FETCH_RESOURCE(context, php_stream_context*,
&zcontext, -1, "stream-context", le_stream_context);
}


There is almost certainly a better place to check this; I'm not that
familiar with the code. And, of course, there are probably at least a
hundred other points in the code where a patch like this needs to be
applied.


Ian Clelland
<[EMAIL PROTECTED]>




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

#21797 [NEW]: compile stops, commad-line too long

[s . frings]

From: [EMAIL PROTECTED]
Operating system: Solaris 6
PHP version:  4.3.0
PHP Bug Type: Compile Failure
Bug description:  compile stops, commad-line too long

Hi,
I have a problem compiling php on my sun workstation. The make stops with
the error message:

/bin/sh libtool ..
Command line too long
Command line too long
Command line too long
gcc: main/php_ini: No such file or directory

I replaced the very long list of arguments with .. Its more than 3kb
long.

The problem was reported prior and solved in earlier versions  but It
appeared again.
-- 
Edit bug report at http://bugs.php.net/?id=21797&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21797&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21797&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21797&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21797&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21797&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21797&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21797&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21797&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21797&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21797&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21797&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21797&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21797&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21797&r=gnused

#21775 [Fbk]: memory leak: emalloc(): Unable to alllocate 32 bytes

[moriyoshi]

 ID:   21775
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: SuSE Linux 7.3
 PHP Version:  4.3.0
 New Comment:

The PHP scripting engine (ZendEngine) doesn't perform conservative GC,
and 
any referenced object are marked as alive. Therefore there are some
cases
where the objects such as mutually-referenced ones remains undestroyed
even
though they are unreachable from the root set of variables. Your
bi-directional
linked list example is just one of such cases.



Previous Comments:


[2003-01-21 08:26:23] [EMAIL PROTECTED]

The memory limit option will not take effect unless you've compiled
your PHP with --enable-memory-limit.




[2003-01-21 07:26:32] [EMAIL PROTECTED]

Sorry, my bad. I missed "unset" statement.

As for the memory-limit problem it was a bug indeed. See bug #20802.




[2003-01-21 06:03:28] [EMAIL PROTECTED]

my http process rund out of memory after it blowed up
to 320 MB (have 256 MB RAM). in php.ini memory_limit = 8M.
IMHO this is not bogus!



[2003-01-20 11:38:05] [EMAIL PROTECTED]

PHP does not reclaim any memory no longer referenced?
No garbage collection?



[2003-01-20 11:12:37] [EMAIL PROTECTED]

PHP is designed to bail out (to stop executing) when the memory has
been
run out. So it's natural that the runtime end up segfaulting.




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

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

#21796 [Opn->Fbk]: Compile fails on AIX 4.3.3

[derick]

 ID:   21796
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: AIX 4.3.3
 PHP Version:  4.3.0
 New Comment:

Please try using this CVS snapshot:

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


Previous Comments:


[2003-01-21 09:32:54] [EMAIL PROTECTED]

A few minor warnings with configure, then configure ends with:

| about the implications of having register_globals set to on, and   |
| avoid using it if possible.|
++

./config.status[1739]: 6: bad file unit number
./config.status[1740]: 6: bad file unit number

Didnt seem too bad, so I went with the compile, and it fails with:

cc -I/root/php/php-4.3.0/ext/mysql/libmysql -Iext/mysql/
-I/root/php/php-4.3.0/ext/mysql/ -DPHP_ATOM_INC
-I/root/php/php-4.3.0/include -I/root/php/php-4.3.0/main
-I/root/php/php-4.3.0 -I/root/php/php-4.3.0/Zend
-I/root/php/php-4.3.0/ext/xml/expat  -I/root/php/php-4.3.0/TSRM  -g  -c
/root/php/php-4.3.0/ext/mysql/libmysql/my_tempnam.c -o
ext/mysql/libmysql/my_tempnam.o  && echo >
ext/mysql/libmysql/my_tempnam.lo
"/root/php/php-4.3.0/ext/mysql/libmysql/my_tempnam.c", line 99.5:
1506-025 (S) Operand must be a modifiable lvalue.
"/root/php/php-4.3.0/ext/mysql/libmysql/my_tempnam.c", line 105.3:
1506-025 (S) Operand must be a modifiable lvalue.
make: 1254-004 The error code from the last command is 1.

I saw another bug here with the same exact compile failure, but in a
different file, and it was fixed. Hopefully this will be as easy.




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

#21796 [NEW]: Compile fails on AIX 4.3.3

[ed]

From: [EMAIL PROTECTED]
Operating system: AIX 4.3.3
PHP version:  4.3.0
PHP Bug Type: Compile Failure
Bug description:  Compile fails on AIX 4.3.3

A few minor warnings with configure, then configure ends with:

| about the implications of having register_globals set to on, and   |
| avoid using it if possible.|
++

./config.status[1739]: 6: bad file unit number
./config.status[1740]: 6: bad file unit number

Didnt seem too bad, so I went with the compile, and it fails with:

cc -I/root/php/php-4.3.0/ext/mysql/libmysql -Iext/mysql/
-I/root/php/php-4.3.0/ext/mysql/ -DPHP_ATOM_INC
-I/root/php/php-4.3.0/include -I/root/php/php-4.3.0/main
-I/root/php/php-4.3.0 -I/root/php/php-4.3.0/Zend
-I/root/php/php-4.3.0/ext/xml/expat  -I/root/php/php-4.3.0/TSRM  -g  -c
/root/php/php-4.3.0/ext/mysql/libmysql/my_tempnam.c -o
ext/mysql/libmysql/my_tempnam.o  && echo >
ext/mysql/libmysql/my_tempnam.lo
"/root/php/php-4.3.0/ext/mysql/libmysql/my_tempnam.c", line 99.5: 1506-025
(S) Operand must be a modifiable lvalue.
"/root/php/php-4.3.0/ext/mysql/libmysql/my_tempnam.c", line 105.3:
1506-025 (S) Operand must be a modifiable lvalue.
make: 1254-004 The error code from the last command is 1.

I saw another bug here with the same exact compile failure, but in a
different file, and it was fixed. Hopefully this will be as easy.
-- 
Edit bug report at http://bugs.php.net/?id=21796&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21796&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21796&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21796&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21796&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21796&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21796&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21796&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21796&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21796&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21796&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21796&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21796&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21796&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21796&r=gnused

#21533 [Fbk->Opn]: Trouble building PHP w/ GD and including ImageTTFxxx functions

[jeffabruce]

 ID:   21533
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: GD related
 Operating System: RH 7.2
 PHP Version:  4.3.0
 New Comment:

PHP build:
configure --with-apxs=/usr/local/apache/bin/apxs
--with-mysql=/usr/local/mysql --enable-track-vars
--with-imap=/usr/local/imap --with-gd --enable-ftp --enable-sysvsem
--enable-sysvshm --enable-sockets --with-gettext
--with-mm=/usr/local/lib/mm --with-jpeg-dir=/usr/lib
--with-zlib-dir=/usr/local --with-openssl=/usr/local/ssl --with-ttf
--enable-gd-native-ttf --enable-gd-imgstrttf
--with-freetype-dir=/usr/local --with-dom

FreeType:
freetype-1.3.1.tar.gz was untarred and built and installed with:
configure
make
make install


Previous Comments:


[2003-01-20 17:11:22] [EMAIL PROTECTED]

What was the configure line ? And exactly what freetype 1.x
version was installed? And how?




[2003-01-20 16:48:08] [EMAIL PROTECTED]

I'm really not a Linux developer, and although what you are asking for
sounds easy enough, I don't know how to give you what you want.

I would like to reiterate that there are 2 issues here:
1. Configure incorrectly reporting my support for FreeType2
2. gd.c has code that given certain #if conditions, leaves the variable
'error' undefined. The crash is occuring because of the reference to
this floating pointer. I assume you want a backtrace to determine the
line of code that is crashing, but I'm *giving* you the line of code
that is crashing.



[2003-01-09 19:44:35] [EMAIL PROTECTED]

Can you generate a backtrace from the core file and please provide the
shortest possible version of the script that can be used to duplicate
the crash.



[2003-01-09 09:24:09] [EMAIL PROTECTED]

I am using the bundled GD library.



[2003-01-08 21:19:00] [EMAIL PROTECTED]

Are you using bundled or non-bundled GD library?



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

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

#20190 [Com]: Random mem corruption: zend_get_executed_filename() mismatch

[r]

 ID:   20190
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Apache related
 Operating System: FreeBSD
 PHP Version:  4.3.0-dev
 New Comment:

Have this problem on 4.3.0 RELEASE! and 4.2.3

upgrade Version on this bug please.


Previous Comments:


[2003-01-16 17:22:32] [EMAIL PROTECTED]

I upgraded to 4.3 the other day and ran into this problem big time.
Today I went back to 4.2.3 and am still running into the error(s)
occasionally... I've made sure that PHP 4.2.3 is installed and running
and (according to phpinfo()) it is.

Apache 1.3.27 FreeeBSD 4.7p-1 PHP 4.2.3 and PHP 4.3.0 

Ack!



[2002-11-14 15:45:26] [EMAIL PROTECTED]

Hi,

>when this bug occurs, to confirm the wrong ini values?

Ok, i'll do that.

>1) there are 2 vhosts, where vhost A has open_basedir >restriction in
effect, via php_admin_value in > context and vhost B
>doesn't

Nope. Both virtal servers have a open basedir restriction
turned on here.

>2) vhost B includes a file and subsequently vhost A >includes one.

That's correct.

For some strange reason, the bug does not happen on
a test setup with the same apache config. Of course
I was not able to copy all web-stuff over and simulate
true load.

So it is very difficult to reproduce.

Martin



[2002-11-14 11:39:16] [EMAIL PROTECTED]

Could you test the values:
registered_zend_ini_directives
and
EG(ini_directives)

when this bug occurs, to confirm the wrong ini values?

I'm trying to reproduce this, can you confirm, that this bug happens
when:
1) there are 2 vhosts, where vhost A has open_basedir restriction in
effect, via php_admin_value in  context and vhost B
doesn't
2) vhost B includes a file and subsequently vhost A includes one.

So in order to increase the chances of hitting this bug, one could:
set Max and MinSpareServers to 1 and request the different vhosts?



[2002-11-14 03:09:27] [EMAIL PROTECTED]

I can confirm that it still happens with the latest cvs 4.3 snapshot
from yesterday (2002-11-13).

If I get some pointers, I could add some debug code.

Funny thing is that the webserver runs about 30min to
2 hours ok, and then I hit begin to hit the bug. Always
after the same files:

It's always the same, you can see it because the filename
has two slashes /www/doc/customer2/html/visions/php//

This path really exists. The thing that does not exist,
is the file wrapper.php. It exists in the customer1 path
so we really really should not end here.

Nov 14 05:37:24 server-bsl1 httpd: open_basedir: Used openbasedir
/www/doc/custermer1, file
/www/doc/customer2/html/visions/php//wrapper.php executed_filename
(/www/doc/customer1/index.php)

It looks to me that this case only happens after the apache
child has processed a include as last thing and then preceeds again a
different webserver.

Anyone knows more ?
Martin



[2002-11-02 14:27:04] [EMAIL PROTECTED]

I'd like to jump this upto a critical standing.  Mainly because it will
get someone else to review the patch.  Hopefully that someone else will
be a bit more intimately knowledgable with the whole Zend memory system
than I. 



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

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

#21795 [NEW]: Undeclared statement in oci8.c

[chris]

From: [EMAIL PROTECTED]
Operating system: Redhat 7.1
PHP version:  4.3.0
PHP Bug Type: Compile Failure
Bug description:  Undeclared statement in oci8.c

When building php4.3.0 with option --with-oci8 I get the following error
message when running 'make'

/bin/sh libtool --silent --mode=compile gcc  -Iext/oci8/
-I/usr/src/php-4.3.0/ext/oci8/ -DPHP_ATOM_INC -I/usr/src/php-4.3.0/include
-I/usr/src/php-4.3.0/main -I/usr/src/php-4.3.0 -I/usr/src/php-4.3.0/Zend
-I/usr/local/include/libxml2 -I/usr/local/include -I/usr/oracle/rdbms/demo
-I/usr/oracle/network/public -I/usr/oracle/plsql/public
-I/usr/src/php-4.3.0/ext/xml/expat  -DLINUX=22 -DEAPI -DEAPI_MM
-DEAPI_MM_CORE_PATH=/var/run/httpd.mm -I/usr/src/php-4.3.0/TSRM  -g -O2 
-prefer-pic -c /usr/src/php-4.3.0/ext/oci8/oci8.c -o ext/oci8/oci8.lo 
/usr/src/php-4.3.0/ext/oci8/oci8.c: In function `zif_ocierror':
/usr/src/php-4.3.0/ext/oci8/oci8.c:4266: `OCI_ATTR_STATEMENT' undeclared
(first use in this function)
/usr/src/php-4.3.0/ext/oci8/oci8.c:4266: (Each undeclared identifier is
reported only once
/usr/src/php-4.3.0/ext/oci8/oci8.c:4266: for each function it appears
in.)
make: *** [ext/oci8/oci8.lo] Error 1

PHP 4.2.3 works fine with the same configure options.

(./configure --prefix=/usr --with-config-file-path=/etc --enable-pic
--enable-shared --enable-inline-optimization --with-apxs=/usr/sbin/apxs
--with-exec-dir=/usr/bin --with-regex=system --with-gettext --with-gd
--with-jpeg=/usr --with-png --with-zlib --with-gdbm --enable-debugger
--enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem
--enable-sysvshm --enable-track-vars --enable-yp --enable-ftp
--enable-wddx --with-mysql --with-oci8 --with-xml --enable-sigchild
--with-ldap --with-expat --enable-xslt --with-xslt-sablot --with-dom
--with-pear)
-- 
Edit bug report at http://bugs.php.net/?id=21795&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21795&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21795&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21795&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21795&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21795&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21795&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21795&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21795&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21795&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21795&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21795&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21795&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21795&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21795&r=gnused

#21790 [Opn->Bgs]: 0-Byte-Problem

[iliaa]

 ID:   21790
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

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

Thank you for your interest in PHP.

In many cases the files opened by PHP are are not specified via user
input. When they are, it is up to the user to be aware of such things
and handle them appropriately. In many cases your patch would simply
add unnecessary overhead.


Previous Comments:


[2003-01-21 00:35:51] [EMAIL PROTECTED]

I read this Mail from Ian Clelland on [EMAIL PROTECTED] And I
think, this is a problem, that should be fixed.

On Thu, Jan 16, 2003 at 12:07:12AM +0100, Nicob wrote:

>> On Sun, 2003-01-12 at 16:03, [EMAIL PROTECTED] wrote:
>
>>> > index.php :
>>> >$cfg_file = "${cfg_dir}/${bn}.${ext}";
>>> >
>>> >
http://www.w-agora.net/current/index.php?site=demos&bn=../../../../../../../../../../etc/passwd%00

>>> >
http://www.w-agora.net/current/modules.php?mod=fm&file=../../../../../../../../../../etc/passwd%00&bn=fm_d1

>
>> 
>> AFAIK, the Null-byte attack doesn't work with PHP. It works with
Perl
>> and some Java apps, yes, but not PHP ...


PHP strings in general are stored with their lengths, and can contain
arbitrary binary data (unlike, say, C). Within PHP, strings containing
null bytes are safe to use.

The problem here is that PHP will often pass PHP-function-parameters
unchecked directly to the lower-level C library functions.

PHP may handle a filename like '/etc/passwd\x00.ext' just fine, but if
it passes the address of that string to fopen(), then the C function
will treat the argument as a null-terminated string, and open
/etc/passwd.


As a quick proof-of-concept, try this code under your favourite PHP
interpreter (I've tested it on a 4.0-series platform, and a quick
perusal of the the relevant files in the 4.3.0 source doesn't show any
protection against this):




Output:
/etc/passwd .ext
root:x:0:0:root:/root:/bin/bash



You can see by the output of the echo statement that PHP deals with
null
bytes very well within strings, but that fopen stopped reading the
filename at the null.

This looks to be quite difficult to guard against -- the application
level solution would have to involve scanning all strings for null
bytes
before passing them to any of a very large number of PHP functions. A
better solution would be to have PHP itself do a libc string length
check before passing arguments to lower-level functions.

Adding just a few lines to ext/standard/file.c should prevent an
attack
like this on fopen:

***
*** 1086,1092 
--- 1086,1095 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss|br",
&mode, &mode_len, &use_include_path,
&zcontext) == FAILURE) {
RETURN_FALSE;
}
+   if (strlen(filename) != filename_len) {
+   RETURN_FALSE;
+   }
if (zcontext) {
ZEND_FETCH_RESOURCE(context, php_stream_context*,
&zcontext, -1, "stream-context", le_stream_context);
}


There is almost certainly a better place to check this; I'm not that
familiar with the code. And, of course, there are probably at least a
hundred other points in the code where a patch like this needs to be
applied.


Ian Clelland
<[EMAIL PROTECTED]>




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

#21775 [Opn->Fbk]: memory leak: emalloc(): Unable to alllocate 32 bytes

[iliaa]

 ID:   21775
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: SuSE Linux 7.3
 PHP Version:  4.3.0


Previous Comments:


[2003-01-21 08:26:23] [EMAIL PROTECTED]

The memory limit option will not take effect unless you've compiled
your PHP with --enable-memory-limit.




[2003-01-21 07:26:32] [EMAIL PROTECTED]

Sorry, my bad. I missed "unset" statement.

As for the memory-limit problem it was a bug indeed. See bug #20802.




[2003-01-21 06:03:28] [EMAIL PROTECTED]

my http process rund out of memory after it blowed up
to 320 MB (have 256 MB RAM). in php.ini memory_limit = 8M.
IMHO this is not bogus!



[2003-01-20 11:38:05] [EMAIL PROTECTED]

PHP does not reclaim any memory no longer referenced?
No garbage collection?



[2003-01-20 11:12:37] [EMAIL PROTECTED]

PHP is designed to bail out (to stop executing) when the memory has
been
run out. So it's natural that the runtime end up segfaulting.




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

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

#21775 [Opn]: memory leak: emalloc(): Unable to alllocate 32 bytes

[iliaa]

 ID:   21775
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: SuSE Linux 7.3
 PHP Version:  4.3.0
 New Comment:

The memory limit option will not take effect unless you've compiled
your PHP with --enable-memory-limit.



Previous Comments:


[2003-01-21 07:26:32] [EMAIL PROTECTED]

Sorry, my bad. I missed "unset" statement.

As for the memory-limit problem it was a bug indeed. See bug #20802.




[2003-01-21 06:03:28] [EMAIL PROTECTED]

my http process rund out of memory after it blowed up
to 320 MB (have 256 MB RAM). in php.ini memory_limit = 8M.
IMHO this is not bogus!



[2003-01-20 11:38:05] [EMAIL PROTECTED]

PHP does not reclaim any memory no longer referenced?
No garbage collection?



[2003-01-20 11:12:37] [EMAIL PROTECTED]

PHP is designed to bail out (to stop executing) when the memory has
been
run out. So it's natural that the runtime end up segfaulting.




[2003-01-20 10:30:58] [EMAIL PROTECTED]

The following code:

<%
   class Object {
  var $prev;
  var $next;
  function unter (&$ref)
  {
 $ref->prev = &$this;
 $this->next = &$ref;
  }
   };

   while (true)
   {
  print "NEW ROUND\n";
  {
 $o = &new Object;
 for ($i = 0; $i < 1; ++$i) {
$o->unter (new Object);
$o = &$o->next;
 }
 unset ($o);
  }
   }
%>

consumes as much memory it can get. I would expect that
PHP garbage-collects the memory.






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

#21792 [Opn]: dclfn.h macros as XtOffsetOf,sockopen & zend_isnan macro redifinition

[francois . turi]

 ID:   21792
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Compile Failure
 Operating System: AIX 4.3.2
 PHP Version:  4CVS-2003-01-20 (stable)
 New Comment:

In fact the fix I suggested was the origin of the failure to compile
php_apache.c and should be disregarded.

So I manage to compile everything on regular version 4.3.0 but with the
following fix:

diff ext/standard/php_image.h.orig ext/standard/php_image.h 
48c48
<   IMAGE_FILETYPE_IFF,
---
>   IMAGE_FILETYPE_IFF

diff ext/standard/dl.c.orig ext/standard/dl.c  
139c139
<   handle = DL_LOAD(libpath);
---
>   handle = (void *)DL_LOAD(libpath); /* FTU */

but maybe it will be even better to declare handle as DL_HANDLE and to
cast:
handle = (DL_HANDLE)DL_LOAD(path);
like for zend_extensions.c

diff Zend/zend_extensions.c.orig Zend/zend_extensions.c
33c33
<   handle = DL_LOAD(path);
---
>   handle = (DL_HANDLE)DL_LOAD(path);  /* FTU */



diff ext/standard/file.c.orig ext/standard/file.c
29a30
> #include "dlfcn.h"/* FTU */
105a107,108
> #undef XtOffsetOf   /* FTU */
> #undef closesocket/* FTU */

diff sapi/apache/php_apache_http.h.orig  sapi/apache/php_apache_http.h
11a12
> #include "dlfcn.h"  /* FTU */
12a14
>


Previous Comments:


[2003-01-21 03:30:21] [EMAIL PROTECTED]

Looks similar to bug 16117 but the "offender" is dlcfn.h here.

Compile failure on php 4.3.0 and latest dev version

Compiler Aix xlc
configure 
--with-config-file-path=/s00/app/sso/admin/SSOD/conf 
--with-prefix=/s00/app/php/product/SSOD 
--with-apxs=/s00/app/apache/product/1.3.22/bin/apxs
--enable-static 
--with-ldap=/opt/freeware 
--with-mhash=/s00/app/mhash/product/0.8.16 
--with-oci8=/s00/app/oracle/product/8.1.7
--with-mysql=/opt/freeware

module sapi/apache/sapi_apache.c

/bin/sh libtool --silent --mode=compile /usr/vac/bin/xlc
-I/s00/app/apache/product/1.3.22/include -Isapi/apache/ -I/s00/open
data/build/php-4.3.0-latest/sapi/apache/ -DPHP_ATOM_INC
-I/s00/opendata/build/php-4.3.0-latest/include
-I/s00/opendata/build/php-4.3
.0-latest/main -I/s00/opendata/build/php-4.3.0-latest
-I/s00/opendata/build/php-4.3.0-latest/Zend -I/opt/freeware/include
-I/usr/loc
al/include -I/opt/freeware/include/mysql
-I/s00/app/oracle/product/8.1.7/rdbms/public
-I/s00/app/oracle/product/8.1.7/rdbms/demo -I/
s00/opendata/build/php-4.3.0-latest/ext/xml/expat 
-I/s00/app/apache/product/1.3.22/include
-I/s00/app/mhash/product/0.8.16/include 
-I/opt/freeware/include -DAIX=43 -DEAPI -DEAPI_MM
-DUSE_PTHREAD_SERIALIZED_ACCEPT -DAIX_BIND_PROCESSOR -DUSE_HSREGEX
-DUSE_EXPAT -I/
s00/opendata/build/php-4.3.0-latest/TSRM 
-I/s00/app/apache/product/1.3.22/include
-I/s00/app/mhash/product/0.8.16/include -I/opt/fr
eeware/include  -prefer-pic -c
/s00/opendata/build/php-4.3.0-latest/sapi/apache/sapi_apache.c -o
sapi/apache/sapi_apache.lo 
"/usr/include/dlfcn.h", line 67.9: 1506-213 (S) Macro name RTLD_LAZY
cannot be redefined.
"/usr/include/dlfcn.h", line 67.9: 1506-358 (I) "RTLD_LAZY" is defined
on line 85 of /s00/opendata/build/php-4.3.0-latest/Zend/zend.
h.
"/usr/include/dlfcn.h", line 71.9: 1506-213 (S) Macro name RTLD_GLOBAL
cannot be redefined.
"/usr/include/dlfcn.h", line 71.9: 1506-358 (I) "RTLD_GLOBAL" is
defined on line 89 of /s00/opendata/build/php-4.3.0-latest/Zend/zen
d.h.
"/s00/opendata/build/php-4.3.0-latest/TSRM/../main/php_config.h", line
2449.9: 1506-213 (S) Macro name zend_isnan cannot be redefine
d.
"/s00/opendata/build/php-4.3.0-latest/TSRM/../main/php_config.h", line
2449.9: 1506-358 (I) "zend_isnan" is defined on line 2455 of 
/s00/opendata/build/php-4.3.0-latest/Zend/../main/php_config.h.
"/s00/opendata/build/php-4.3.0-latest/TSRM/tsrm_config_common.h", line
25.2: 1506-224 (I) Incorrect #pragma ignored.
"/s00/opendata/build/php-4.3.0-latest/main/php_config.h", line 2449.9:
1506-213 (S) Macro name zend_isnan cannot be redefined.
"/s00/opendata/build/php-4.3.0-latest/main/php_config.h", line 2449.9:
1506-358 (I) "zend_isnan" is defined on line 2455 of /s00/ope
ndata/build/php-4.3.0-latest/Zend/../main/php_config.h.
make: 1254-004 The error code from the last command is 1.

works with the following quick fix

$ diff php-4.3.0/sapi/apache/php_apache_http.h.ftu
php-4.3.0-latest/sapi/apache/php_apache_http.h
12,13d11
< #include "dlfcn.h"  /* FTU */
< #define HAVE_ISNAN/* FTU */
15d12
< #undef xHAVE_ISNAN/* FTU */
46,47d42
< #undef XtOffsetOf   /* FTU */
< #undef zend_isnan /* FTU */
$ cp -p php-4.3.0/sapi/apache/php_apache_http.h.ftu
php-4.3.0-latest/sapi/apache/php_apache_http.h

/bin/sh libtool --silent --mode=compile /usr/vac/bin/xlc
-I/s00/app/apache/product/1.3.22/include -Isapi/apache/ -I/s00/open
data/build/php-4.3.0-lates

#21794 [NEW]: Error Output for sanity check

[jacques]

From: [EMAIL PROTECTED]
Operating system: RedHat 8.0
PHP version:  4.3.0
PHP Bug Type: Compile Failure
Bug description:  Error Output for sanity check

[root@babe ~/work/apache_1.3.27]# ./configure --prefix=/usr/local/etc/httpd
--activate-module=src/modules/php4/libphp4.a
Configuring for Apache, Version 1.3.27
 + using installation path layout: Apache (config.layout)
 + activated php4 module (modules/php4/libphp4.a)
Creating Makefile
Creating Configuration.apaci in src
Creating Makefile in src
 + configured for Linux platform
 + setting C compiler to gcc
 + setting C pre-processor to gcc -E
 + checking for system header files
 + adding selected modules
o php4_module uses ConfigStart/End
 + using builtin Expat
 + checking sizeof various data types
 + doing sanity check on compiler and options
** A test compilation with your Makefile configuration
** failed.  The below error output from the compilation
** test will give you an idea what is failing. Note that
** Apache requires an ANSI C Compiler, such as gcc.

 Error Output for sanity check 
cd ..; gcc  -DLINUX=22 -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED
`./apaci` -o helpers/dummy helpers/dummy.c   -Wl,-rpath,/usr/X11R6/lib
-Wl,-rpath,/root/work/swf/lib  -rdynamic -L/usr/X11R6/lib
-L/root/work/swf/lib -Lmodules/php4 -L../modules/php4 -L../../modules/php4
-lmodphp4 -export-symbols /root/work/php-4.3.0/sapi/apache/php.sym  
-rdynamic -L/usr/X11R6/lib -L/root/work/swf/lib   -lswf -lt1 -lfreetype
-lX11 -lXpm -lpng -lz -ljpeg -lbz2 -lz -lcrypt -lresolv -lm -ldl -lnsl 
-lcrypt   -lm -lcrypt
/usr/bin/ld:/root/work/php-4.3.0/sapi/apache/php.sym: file format not
recognized; treating as linker script
/usr/bin/ld:/root/work/php-4.3.0/sapi/apache/php.sym:2: parse error
collect2: ld returned 1 exit status
make: *** [dummy] Error 1
= End of Error Report =

OBS: I used the next comand line to compile php:
[root@babe ~/work/apache_1.3.27]# ./configure
--with-apache=../apache_1.3.27 --with-gd --with-mysql --enable-versioning
--enable-track-vars --enable-force-cgi-redirect --enable-discard-path
--disable-short-tags --disable-display-source --enable-safe-mode
--with-swf=../swf --enable-trans-sid --enable-calendar --enable-ftp
--with-bz2 --enable-sockets --enable-inline-optimization
--enable-memory-limit --with-xpm-dir=/usr/X11R6 --with-jpeg-dir=/usr
--with-png-dir=/usr --with-ttf --with-zlib --with-zlib-dir=/usr
--with-freetype-dir=/usr/include/freetype2 --with-t1lib

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

#20935 [NoF->Opn]: mssql_query causes segfault

[jonas]

 ID:   20935
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   No Feedback
+Status:   Open
 Bug Type: MSSQL related
 Operating System: RedHat Linux 7.2 / Apache 1.3.27
-PHP Version:  4.2.3
+PHP Version:  4.3.0
 New Comment:

recompiled as cgi but still generates the same error.

(gdb) bt
#0  0x in ?? ()
#1  0x08094c14 in _mssql_fetch_batch (mssql_ptr=0x82658f4,
result=0x82682d4, retvalue=-1)
at /home/jonas/devel/php-4.3.0/ext/mssql/php_mssql.c:1020
#2  0x08095267 in zif_mssql_query (ht=2, return_value=0x827731c,
this_ptr=0x0, return_value_used=1)
at /home/jonas/devel/php-4.3.0/ext/mssql/php_mssql.c:1143
#3  0x08194083 in execute (op_array=0x8264864) at
/home/jonas/devel/php-4.3.0/Zend/zend_execute.c:1596
#4  0x0818406a in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/jonas/devel/php-4.3.0/Zend/zend.c:864
#5  0x08153e05 in php_execute_script (primary_file=0xbfffe780) at
/home/jonas/devel/php-4.3.0/main/main.c:1573
#6  0x0819a234 in main (argc=3, argv=0xbfffe834) at
/home/jonas/devel/php-4.3.0/sapi/cgi/cgi_main.c:1424
#7  0x40238657 in __libc_start_main (main=0x8199878 , argc=3,
ubp_av=0xbfffe834, init=0x8067d2c <_init>,
fini=0x819aa40 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>,
stack_end=0xbfffe82c) at ../sysdeps/generic/libc-start.c:129


Previous Comments:


[2003-01-02 18:45:35] [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.





[2002-12-11 08:42:28] [EMAIL PROTECTED]

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

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



[2002-12-11 08:40:15] [EMAIL PROTECTED]

(FreeTDS 1.5 2002/08/24, MSSQL 7 (remote))

mssql_query causes when using the following SQLSTATEMENT

"SELECT a.*, b.* FROM dbo.psl AS b LEFT JOIN dbo.prc AS a ON (a.idPSL =
b.idPSL) WHERE b.OrderNo LIKE '%123169%' AND a.idPSL > '0'"

while simple queries like "SELECT * FROM dbo.psl" works just fine.

The problem appears only if the query tries to return
information.




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

#21789 [Fbk->Opn]: GCC 3.2.1 needs stdc++ linked

[ron]

 ID:   21789
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Solaris 8
 PHP Version:  4.3.0
 New Comment:

Yes, Sablotron was compiled with the same version of GCC.


Previous Comments:


[2003-01-21 01:15:41] [EMAIL PROTECTED]

Was the sablot compiled also with that same GCC version?




[2003-01-20 23:43:57] [EMAIL PROTECTED]

With GCC 3.2.1 these symbols can be found in libstdc++. When php 4.3.0
is linked with -lsablot, there is no easy way to link it to stdc++, to
account for the changes of the locations of these functions in the new
GCC API. I would recommend a configure option like --enable-stdc++ to
allow the user to link this manually like --enable-libgcc. 

excerpt from compile :

.lo main/internal_functions_cli.lo -lsablot -liconv -lexpat -liconv
-lcurl -lcrypt -lresolv -lm -ldl -lnsl -lsocket -lgcc -lcrypt -lcurl
-lz -lssl -lcrypto -ldl -lsocket -lnsl -lz  -o sapi/cli/php
Undefined   first referenced
 symbol in file
__cxa_pure_virtual  /usr/local/lib/libsablot.so
vtable for __cxxabiv1::__si_class_type_info/usr/local/lib/libsablot.so
vtable for
__cxxabiv1::__vmi_class_type_info/usr/local/lib/libsablot.so
operator new[](unsigned)/usr/local/lib/libsablot.so
vtable for __cxxabiv1::__class_type_info/usr/local/lib/libsablot.so
operator delete(void*)  /usr/local/lib/libsablot.so
operator new(unsigned)  /usr/local/lib/libsablot.so
__gxx_personality_v0/usr/local/lib/libsablot.so
operator delete[](void*)/usr/local/lib/libsablot.so
ld: fatal: Symbol referencing errors. No output written to
sapi/cli/php
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1
bash-2.03# gcc --version
gcc (GCC) 3.2.1
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

bash-2.03# 






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

#21775 [Opn]: memory leak: emalloc(): Unable to alllocate 32 bytes

[moriyoshi]

 ID:   21775
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: SuSE Linux 7.3
 PHP Version:  4.3.0
 New Comment:

Sorry, my bad. I missed "unset" statement.

As for the memory-limit problem it was a bug indeed. See bug #20802.



Previous Comments:


[2003-01-21 06:03:28] [EMAIL PROTECTED]

my http process rund out of memory after it blowed up
to 320 MB (have 256 MB RAM). in php.ini memory_limit = 8M.
IMHO this is not bogus!



[2003-01-20 11:38:05] [EMAIL PROTECTED]

PHP does not reclaim any memory no longer referenced?
No garbage collection?



[2003-01-20 11:12:37] [EMAIL PROTECTED]

PHP is designed to bail out (to stop executing) when the memory has
been
run out. So it's natural that the runtime end up segfaulting.




[2003-01-20 10:30:58] [EMAIL PROTECTED]

The following code:

<%
   class Object {
  var $prev;
  var $next;
  function unter (&$ref)
  {
 $ref->prev = &$this;
 $this->next = &$ref;
  }
   };

   while (true)
   {
  print "NEW ROUND\n";
  {
 $o = &new Object;
 for ($i = 0; $i < 1; ++$i) {
$o->unter (new Object);
$o = &$o->next;
 }
 unset ($o);
  }
   }
%>

consumes as much memory it can get. I would expect that
PHP garbage-collects the memory.






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

#21683 [Fbk->Opn]: Creation of libphp4.so not possible

[fabian . paganotto]

 ID:   21683
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: Solaris 9
 PHP Version:  4.3.0
 New Comment:

Ths worked fine


Previous Comments:


[2003-01-20 04:45:20] [EMAIL PROTECTED]

Can you please try with this simple configure for PHP:

./configure --with-apxs2=/usr/local/apache2/bin/apxs





[2003-01-20 03:49:14] [EMAIL PROTECTED]

Yes there are

drwxr-xr-x   2 root other512 Jan 16 11:00 .
drwxr-xr-x  18 apache   apache  2048 Jan 16 11:00 ..
lrwxrwxrwx   1 root other 13 Jan 16 11:00 libphp4.la ->
../libphp4.la
-rw-r--r--   1 root other908 Jan 16 11:00 libphp4.lai


(BTW I had compiled as root this is not a mistake)

The ../libphp4.la is existent also



[2003-01-17 20:48:13] [EMAIL PROTECTED]

Is there any files in .libs/ ??




[2003-01-16 04:13:56] [EMAIL PROTECTED]

Install failed

Installing PHP SAPI module
*** Error code 2 (ignored)
/usr/local/apache2/build/instdso.sh
SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp4.la
/usr/local/apache2/modules
/usr/local/apache2/build/libtool --mode=install cp libphp4.la
/usr/local/apache2/modules/
cp .libs/libphp4.so /usr/local/apache2/modules/libphp4.so
cp: cannot access .libs/libphp4.so
apxs:Error: Command failed with rc=131072
.
*** Error code 1
make: Fatal error: Command failed for target `install-sapi'

config from php
--with-mod-dav=/usr/local/apache2/modules/mod_dav.so  \
--with-apxs2=/usr/local/apache2/bin/apxs \
--prefix=/usr/local/php \
--enable-versioning  \
--with-pgsql=/usr/local/pgsql \
--enable-bcmath \
--enable-calendar \
--enable-dbx \
--enable-ftp \
--enable-mbstring \
--enable-mbstr-enc-trans \
--enable--mbregex \
--enable-shmop \
--enable-sockets \
--enable-sysvsem \
--enable-sysvshm \
--enable-tokenizer \
--enable-wddx \
--enable-yp \
--enable-versioning \
--with-mod-charset \
--with-openssl \
--with-zlib-dir \
--with-zlib \
--with-bz2 \
--with-tiff-dir \
--with-png-dir \
--with-xpm-dir \
--with-freetype-dir \
--with-ttf \
--with-t1lib \
--with-gettext \
--with-regex=php \
--with-xslt-sablot \
--with-sablot-js \
--with-iconv \
--enable-track-vars \
--enable-trans-sid 


config from apache httpd-2.0.43
./configure \
--prefix=/usr/local/apache2  \
--enable-mods-shared=all \
--disable-info   \
--enable-so


Maybe someone may have a solution for this problem

Thanks a lot 

Fabian Paganotto




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

#21698 [Com]: httpd.conf not modified when creating dso module

[bugs]

 ID:   21698
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Apache2 related
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

I don't know if anyone will get to read this now this issue is closed.
But if you do, thank you for fixing this so quickly. Shame other
software companies aren't as quick! ;-)


Previous Comments:


[2003-01-21 00:03:25] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

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





[2003-01-18 11:39:44] [EMAIL PROTECTED]

No upgrade of Apache has taken place. All I have done is removed the
dso module and any configuration lines in httpd.conf and then
re-installed PHP.



[2003-01-17 08:13:57] [EMAIL PROTECTED]

Did you happen upgrade Apache2 since 4.2.3 ??
Or are you using same version for both PHP 4.2.3 and 4.3.0 ?





[2003-01-16 17:46:00] [EMAIL PROTECTED]

I have upgraded from v4.2.3 to v4.3.0

When compiling PHP v4.2.3 the "make install" command updates my
httpd.conf file and adds:
LoadModule php4_module modules/libphp4.so

I have noticed that this does not happen with the latest release of
4.3.0. I have tried the laetst CVS (php4-STABLE-200301162230) and it
still does this :-(

I thought it was me at first, but I have tried it several times and
each time the same thing happens.

Please could someone check this out for the PHP community.

Many thanks,

Richard.




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

#21771 [Opn]: variable names changing in turkish locale

[tufan]

 ID:   21771
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Variables related
 Operating System: linux kernel 2.4.18
 PHP Version:  4.3.0
 New Comment:

by the way, it's turkish locale
tr_TR
iso8859-9


Previous Comments:


[2003-01-21 06:24:08] [EMAIL PROTECTED]

no code works. even the example in the php session documentation...
:)





[2003-01-20 16:03:17] [EMAIL PROTECTED]

Can you provide some short example script?
And what locale causes this?




[2003-01-20 06:39:44] [EMAIL PROTECTED]

Oops... This may not be related to php. It may be resulting from the
turkish locale system itself. Let me investigate...



[2003-01-20 06:24:33] [EMAIL PROTECTED]

I thought this bug was submitted for an earlier version of php (maybe
4.1.2 or so), but it seems to be not corrected.

The main problem is, the lowercase of "I" in Turkish is not "i". it is
an "i" without a dot on top of it: "ý".

Something in php affects all variables including the letter "I". So
$_SESSION, SID, or PHPSESSID doesn't work.

I think some code in php first changes all variables names to lowercase
(and for turkish locale, incorrectly lowercases I to i), and then
changes all variable names to uppercase (and correctly uppercases i to
Ý).

So, $_SESSION becomes $_SESSÝON, and since php couldn't find a variable
named $_SESSION, it regenerates a new PHPSESSID.

The correct uppercase - lowercase of this letter is:

I - ý
Ý - i

A workaround for this is making sure apache server starts in en_US
locale.




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

#21771 [Fbk->Opn]: variable names changing in turkish locale

[tufan]

 ID:   21771
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Variables related
 Operating System: linux kernel 2.4.18
 PHP Version:  4.3.0
 New Comment:

no code works. even the example in the php session documentation...
:)




Previous Comments:


[2003-01-20 16:03:17] [EMAIL PROTECTED]

Can you provide some short example script?
And what locale causes this?




[2003-01-20 06:39:44] [EMAIL PROTECTED]

Oops... This may not be related to php. It may be resulting from the
turkish locale system itself. Let me investigate...



[2003-01-20 06:24:33] [EMAIL PROTECTED]

I thought this bug was submitted for an earlier version of php (maybe
4.1.2 or so), but it seems to be not corrected.

The main problem is, the lowercase of "I" in Turkish is not "i". it is
an "i" without a dot on top of it: "ý".

Something in php affects all variables including the letter "I". So
$_SESSION, SID, or PHPSESSID doesn't work.

I think some code in php first changes all variables names to lowercase
(and for turkish locale, incorrectly lowercases I to i), and then
changes all variable names to uppercase (and correctly uppercases i to
Ý).

So, $_SESSION becomes $_SESSÝON, and since php couldn't find a variable
named $_SESSION, it regenerates a new PHPSESSID.

The correct uppercase - lowercase of this letter is:

I - ý
Ý - i

A workaround for this is making sure apache server starts in en_US
locale.




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

#21793 [Opn->Bgs]: building php 4.3 on solaris 8 gcc 3.1 fails

[derick]

 ID:   21793
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: solaris 8
 PHP Version:  4.3.0
 New Comment:

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

Thank you for your interest in PHP.

Not a PHP problem, but an APC one.


Previous Comments:


[2003-01-21 06:08:59] [EMAIL PROTECTED]

Undefined   first referenced
 symbol in file
apc_module_entry  main/internal_functions_cli.o
ld: fatal: Symbol referencing errors. No output written to
sapi/cli/php
collect2: ld returned 1 exit status
gmake: *** [sapi/cli/php] Error 1





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

#21793 [NEW]: building php 4.3 on solaris 8 gcc 3.1 fails

[richard . bragg]

From: [EMAIL PROTECTED]
Operating system: solaris 8
PHP version:  4.3.0
PHP Bug Type: Compile Failure
Bug description:  building php 4.3 on solaris 8 gcc 3.1 fails

Undefined   first referenced
 symbol in file
apc_module_entry  main/internal_functions_cli.o
ld: fatal: Symbol referencing errors. No output written to sapi/cli/php
collect2: ld returned 1 exit status
gmake: *** [sapi/cli/php] Error 1

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

#21775 [Bgs->Opn]: memory leak: emalloc(): Unable to alllocate 32 bytes

[peter . karl . mueller]

 ID:   21775
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: SuSE Linux 7.3
 PHP Version:  4.3.0
 New Comment:

my http process rund out of memory after it blowed up
to 320 MB (have 256 MB RAM). in php.ini memory_limit = 8M.
IMHO this is not bogus!


Previous Comments:


[2003-01-20 11:38:05] [EMAIL PROTECTED]

PHP does not reclaim any memory no longer referenced?
No garbage collection?



[2003-01-20 11:12:37] [EMAIL PROTECTED]

PHP is designed to bail out (to stop executing) when the memory has
been
run out. So it's natural that the runtime end up segfaulting.




[2003-01-20 10:30:58] [EMAIL PROTECTED]

The following code:

<%
   class Object {
  var $prev;
  var $next;
  function unter (&$ref)
  {
 $ref->prev = &$this;
 $this->next = &$ref;
  }
   };

   while (true)
   {
  print "NEW ROUND\n";
  {
 $o = &new Object;
 for ($i = 0; $i < 1; ++$i) {
$o->unter (new Object);
$o = &$o->next;
 }
 unset ($o);
  }
   }
%>

consumes as much memory it can get. I would expect that
PHP garbage-collects the memory.






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

#21444 [Com]: Asort output not fully sorted in mixed type array with BOOLEANs

[m . ford]

 ID:   21444
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Arrays related
 Operating System: Windows XP Pro Build 2600
 PHP Version:  4.3.0
 New Comment:

Following on from my comments in Bug #21728, I've analysed this sort
tooo and, believe it or not, this is actually a correct sort for the
default SORT_REGULAR sort type!!  This is because of the non-sequential
order that comparisons are done, and the automatic type-conversion that
occurs for those comparisons.

In this case, all non-null strings are cast to (bool)true when
comparing with a bool, so that true=="a" and true=="b" and true=="c"
and  This gives you the strange result you see, where your genuine
Boolean true values can be distributed anywhere within your otherwise
correctly sorted strings.

Producing the same breakdown for (a slightly shortened version of) this
array as I did for the arrays in #21728 gives:

  'a'  : 'a'   ==>  (string) 'a'  == 'a'
  'a'  : true  ==>  (bool)   true == true
  true : 'a'   ==>  (bool)   true == true
  'a'  : true  ==>  (bool)   true == true
  true : 'a'   ==>  (bool)   true == true
  'a'  : 'a'   ==>  (string) 'a'  == 'a'
  'a'  : true  ==>  (bool)   true == true
  true : 'b'   ==>  (bool)   true == true
  'b'  : 'b'   ==>  (string) 'b'  == 'b'
  'b'  : true  ==>  (bool)   true == true
  true : 'b'   ==>  (bool)   true == true
  'b'  : true  ==>  (bool)   true == true
  true : true  ==>  (bool)   true == true
  true : 'b'   ==>  (bool)   true == true
  'b'  : 'b'   ==>  (string) 'b'  == 'b'

And yet another surprise -- every comparison of neighbouring elements
in that sorted array is an equality -- no single comparison yields a
less-than result, even though the 'a's are all correctly sorted before
the 'b's!!

I think the moral here is not to use the SORT_REGULAR sort type when
you have mixed-type elements in the array.  In this case, you might
possibly get an acceptable result by specifying the SORT_STRING sort
type, as false would compare as "" and true as "1" -- only a problem if
those values also occur naturally (either as strings or numbers) in the
array.  The other option would be to use usort() with a callback that
checks types before doing a value comparison.

But anyway, I agree, not a PHP bug -- more a curiosity of its design!

Cheers!

Mike


Previous Comments:


[2003-01-18 12:07:14] [EMAIL PROTECTED]

I have to disagree with you. Indeed, if it is the array you tested,
these results are correct. Fill an array with multiple instances of
identical values like the ones in the original example, and the boolean
trues (output as '1') are distributed in a unpredictable way across
some -not all- of the subsets of other values. Example:
a a a a 1 a a 1 a a a 1 b b b b b b 1 b 1 1 b b b  and so on.

I agree with you using multiple types in an array can be tricky, but
the results I got just should not occur. Another (unrealistic imho)
option would be to just say: don't use mixed type arrays, but I would
expect this is not the way PHP should be heading.



[2003-01-18 10:15:10] [EMAIL PROTECTED]

  IMO this is not PHP problem but the way the compares are done. You
have to master the type juggling to see that the result is correct. I
have reduced your testcase to this :


The output is :
array(10) {
  [0]=>
  bool(true)
  [1]=>
  int(4)
  [2]=>
  string(1) "4"
  [3]=>
  string(4) "TRUE"
  [4]=>
  string(1) "a"
  [5]=>
  string(1) "b"
  [6]=>
  string(1) "c"
  [7]=>
  string(1) "d"
  [8]=>
  string(4) "true"
  [9]=>
  int(5)
}
It may look strange - why (int)5 is after all the strings. This is
because "4" is lower than (int) 5, "4" is before "true" and "true" is
before 5. The first 2 are obvious, the third one is not. But it is ok.
It's better not to mix types in the array. If 5 is changed to "5" then
"5" goes right after "4".

Bogusifying




[2003-01-05 16:44:32] [EMAIL PROTECTED]

Last addition: I meant sort() where I used asort(), but the result is
the same



[2003-01-05 16:32:32] [EMAIL PROTECTED]

Well, it appears to be only related to the BOOLEAN array item. Removing
that from the original array leaves a perfectly sorted array as far as
I can see now.



[2003-01-05 16:26:51] [EMAIL PROTECTED]

I use PHP4.0.3 on Apache 1.3.27, both standard binaries as supplied on
the download site. Freshly installed yesterday. No modifications. I
used the php.ini-recommended file as php.ini
Installed exactly as prescribed in install.txt, only instead of c:/php
I use d:/program files/php and changed the ini according

#21681 [Com]: Isapi/mssql crashes under high load !!!!

[dipsy_9001]

 ID:   21681
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: IIS related
 Operating System: Windows 2000
 PHP Version:  4.3.0
 New Comment:

I already had random "CGI Error" (HTTP 502 error) with IIS5+W2K+CGI
under heavy load.
I solved the pb by turning on the "Allow interaction with desktop"
option for IIS Admin service.
I guess there was sthg that needed to access desktop in my CGI
initialization phase (in some external libs?). Maybe it is the same
case with php.exe
I don't know if it can tamper with web server security.


Previous Comments:


[2003-01-20 17:56:44] [EMAIL PROTECTED]

I have tried Microsoft sevral times but without luck. The DBLIB API we
are using for the MSSQL extensions has not been updated since SQL
Server 6.0, though Microsoft has released at least 3 versions since
then.

My best hope right now is to use FreeTDS on Win32 (as it is done on
*nix) but the Win32 port is, to my best knowledge, not stable at this
point. As soon as I have a FreeTDS version of DBLIB I'll make the MSSQL
extension work with it.



[2003-01-20 03:59:59] [EMAIL PROTECTED]

A question for [EMAIL PROTECTED]:

can you give me please a tip to the CGI processes? Where must i set
this? Is this on IIS oder direct on Windows 2000 to set? 
Or have you a more information about it? 

Thanks and best regards,
Andi



[2003-01-19 19:02:11] [EMAIL PROTECTED]

A question for [EMAIL PROTECTED]:

Is there anything you can do for this problem? If it isn't a piece of
code, perhaps a nice email to Microsoft or something like
that...Please. Microsoft won't come to PHP guys asking if there's
something they could do. It's you who must go to them. Furthermore,
your email would be a lot more powerful than an email from some
ordinary PHP developer. I mean, practically, this "bug" prevents me
from using ISAPI at all and as you may have noted I'm not the only one.
You've got to face the facts, because this "bug" might prevent ISAPI
from ever becoming for production use. So please, do something about
it. Hit the home run, because ISAPI is nearly there!



[2003-01-18 18:48:32] [EMAIL PROTECTED]

Hi,

thanks for your tip, I will test it and return a feedback.



[2003-01-18 18:38:02] [EMAIL PROTECTED]

This is a problem with missing thread safety in the Microsoft libraries
used to build the MSSQL extension. It can be used with ISAPI but you
can only get a stable system when using cgi or fastcgi.

The CGI error is not caused by either PHP or the MSSQL extension, but
rather a problem with IIS. CGI processes are launched in forground, but
the default setting for Windows NT/2000 is to optimize performence for
background processes. If you switch this the CGI errors will go away.




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

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

#18648 [Com]: Single entry form POST gives incorrect variable content

[szabo_a]

 ID:   18648
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Apache2 related
 Operating System: All
 PHP Version:  4CVS-2003-01-20 (stable) / 5.0.0-dev (date
   unknown)(dev)
 New Comment:

Same problem with the latest version of PHP (4.3.1-dev). The hidden
variable helps, but sometimes the variables get corrupted this way,
too. So this is not a reliable solution at all.

apache 2.


Previous Comments:


[2003-01-20 20:24:03] [EMAIL PROTECTED]

It works fine with 





[2003-01-20 12:44:48] [EMAIL PROTECTED]

and for some reason, that at the moment escapes me completely, the
 thing worked for me too.



[2003-01-20 12:40:58] [EMAIL PROTECTED]

apache 2 / PHP 4.3.0

it seems on my system that if you fill in a field and hit RETURN you
get the bug, however if you use a submit button instead it works
normally.



[2003-01-11 03:18:41] [EMAIL PROTECTED]

Exactly the same problem was reported recently by other users.
Reopening.




[2003-01-05 16:48:15] [EMAIL PROTECTED]

Related bug: http://bugs.php.net/21441




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

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

#21689 [Bgs->Fbk]: fgetcsv suppresses some characters before a separator

[sniper]

 ID:   21689
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: OS/2
 PHP Version:  4.2.3
 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


Your example works just fine here (linux), using 4.3.1-dev.




Previous Comments:


[2003-01-21 04:04:38] [EMAIL PROTECTED]

Has refreshed soft:
PHP Version 4.3.0
Apache/1.3.27
But the error in operation of the function has remained



[2003-01-16 12:19:26] [EMAIL PROTECTED]

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

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





[2003-01-16 10:41:56] [EMAIL PROTECTED]

fgetcsv suppresses some characters before a separator
[OS/2 kheldar 1 2.45 i386, PHP Version 4.2.3, Apache/1.3.22]
For example if the csv file has following content:

âàø|âåø|âàøå|àø|ø|øø

the comand $date = fgetcsv($f, 1000, "|");

gets the array('âà','âå','âàøå','à','','').
instead of
array('âàø','âåø','âàøå','àø','ø','øø').

Is installed, that Example works correctly with:
1.FreeBSD 4.1, PHP Version 4.1.2, Apache/1.3.19
2.Windows 98 4.10, PHP Version 4.1.1, Apache/1.3.6




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

#19442 [Com]: In a loop of gzopen gzclose the server stops

[bosman]

 ID:   19442
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: Zlib Related
 Operating System: windows/?
 PHP Version:  4.2.3
 New Comment:

I've the same problem with fresh instalation of php 4.3.0 under Windows
2000 Server SP3, both under Apache 2.0.44 as module and with plain
php.exe (CLI version).

This code works similar:
for ($i = 1; $i < 200; $i++) {
  $gz = fopen("compress.zlib://C:/Temp/$i.gz", "wb");
  fwrite($gz, "Test");
  fclose($gz);
}


Previous Comments:


[2002-10-27 19:06:38] [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.





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

Please try using this CVS snapshot:

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





[2002-09-17 00:15:30] [EMAIL PROTECTED]

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

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



[2002-09-16 15:42:02] [EMAIL PROTECTED]

This script will make the setver to crash down


   window.location='$_SERVER[REQUEST_URI]';
   ";

?>
At my apache web server this crash after 508 loops.




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

#21689 [Bgs]: fgetcsv suppresses some characters before a separator

[alpes]

 ID:   21689
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: OS/2
 PHP Version:  4.2.3
 New Comment:

Has refreshed soft:
PHP Version 4.3.0
Apache/1.3.27
But the error in operation of the function has remained


Previous Comments:


[2003-01-16 12:19:26] [EMAIL PROTECTED]

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

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





[2003-01-16 10:41:56] [EMAIL PROTECTED]

fgetcsv suppresses some characters before a separator
[OS/2 kheldar 1 2.45 i386, PHP Version 4.2.3, Apache/1.3.22]
For example if the csv file has following content:

âàø|âåø|âàøå|àø|ø|øø

the comand $date = fgetcsv($f, 1000, "|");

gets the array('âà','âå','âàøå','à','','').
instead of
array('âàø','âåø','âàøå','àø','ø','øø').

Is installed, that Example works correctly with:
1.FreeBSD 4.1, PHP Version 4.1.2, Apache/1.3.19
2.Windows 98 4.10, PHP Version 4.1.1, Apache/1.3.6




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

#19506 [Opn]: some functions are not visble from "get_extension_funcs"

[sniper]

 ID:   19506
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
-Bug Type: Unknown/Other Function
+Bug Type: Feature/Change Request
 Operating System: Linux 2.4.19
 PHP Version:  4.2.3
 New Comment:

reclassified as feature request.



Previous Comments:


[2003-01-21 02:59:33] [EMAIL PROTECTED]

This isn't a documentation problem.  Either 'standard' should list said
functions or they need to be listed/grouped under an additional
'extension'.  As betz said, 'standard' is misleading.

Reclassified -> Other Function.



[2002-09-20 10:55:24] [EMAIL PROTECTED]

get_defined_funcs works well, but get_extension_funcs does not returm
any of the zend_builtin_functions.
This may not be only a documentation problem, maybe it should be fixed
in the source, because get_extensions_funcs
could not be "trusted". The module name standard is misleading, as long
as zend_builtin_functions are standard functions
(zend_builtin_functions.c), but not treated as those by
get_extension_funcs.



[2002-09-20 07:02:30] [EMAIL PROTECTED]

This is just documentation issue. (I didn't remember
get_defined_functions() at all)




[2002-09-20 02:56:02] [EMAIL PROTECTED]

There is nothing wrong with get_defined_functions(), 
except that functions like:
 - extension_loaded
 - get_extension_funcs
 - get_loaded_extensions

are not returned by the script I submit.
Problem in the function or the definition of the function...

For you to decide.

Gilles



[2002-09-20 02:53:29] [EMAIL PROTECTED]

What's wrong with get_defined_functions()?



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

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

#21772 [Opn]: mssql speed when using remote server

[pvy]

 ID:   21772
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: MSSQL related
 Operating System: windows 2000/sp3
 PHP Version:  4.2.3
 New Comment:

Thank you Joey!
Good work!


Previous Comments:


[2003-01-21 03:49:56] [EMAIL PROTECTED]

We've been using PHP hosted on a win32 machine to connect 
to SQL Server 2000.  When the PHP host and the MSSQL host
are the same machine, everything is fine. But when we try
to use seperate hosts for PHP and MSSQL, query times become
unbearably slow.

The odd thing is that I can run the same scripts on the
same network connecting to the same MSSQL server from a Linux box, and
see acceptable response times.

As an example, I did a script that does 1000 iterations
of 'sp_sproc_columns @procudure_name = "some_proc"' in three
different setups.


Setup 1:
  MSSQL and PHP on the Win2k host, call it machine 'A'
  Average Response time over 5 iterations of script: 18s

Setup 2:
  MSSQL on host 'A', PHP on Linux host ('B')
  Average Response time over 5 iterations of script: 41s
  (Given the size of the result set, this is an acceptable
   response time.)

Setup 3:
  MSSQL on host 'A', PHP on seperate Win2k host ('C')
  Average Response time over 5 iterations: 3 minutes, 20s

Clearly, there is something wrong here. I had a different admin set up
a similar network without looking at my php.ini, etc., and he had
similar results.



[2003-01-21 03:47:22] [EMAIL PROTECTED]

Actually, we have done extensive testing on this bug.

If I write a C++ program to run the same query results, it operates as
expected.

If I run the query in 'Query Analyzer', a Microsoft tool, it operates
as expected.

If I run the query via PHP from a LINUX box (compiled with MSSQL
support via the FreeTDS drivers), it operates as expected.

If I run the query via PHP from a Windows box, LO AND BEHOLD, 500-600%
longer to run the query!

This is most definitely something wrong between PHP and the MSSQL
libraries on Win32 machines. I'll add my post from php-db that has
better details in a moment.



[2003-01-20 13:52:49] [EMAIL PROTECTED]

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

Thank you for your interest in PHP.

When dealing with i-net connections even if they are local there is a
lot more additional work that needs to be done. I wouldn't think this
would amount to 3.5 times speed difference, but with Win32 you never
know.
PHP does not initiate the connection to the SQL server itself, it does
it by using the appropriate libraries. So, I do not believe that PHP
could be at fault here.



[2003-01-20 08:01:06] [EMAIL PROTECTED]

I forgot one detail:
I test both MSSQL 7 and MSSQL 2K with latest services packs, 
supplied from MS.



[2003-01-20 07:51:09] [EMAIL PROTECTED]

Hello!

I made small script for determine difference between remote and local
MSSQL server use.
I don't put this script (it is very simple: 1000 loops of db_connect,
1000 loops of mssql_select_db, 1000 loops of mssql_query with load 1000
records rowset, 1000 loops of call stored procedure)
Results of my research:
1. Local DB Server - Local Apache Web server - working about 1000
secounds
2. Remote DB Server - Local Apache Web server - working about 3500
secounds

Remote server connected over TCP/IP network via one 100Mb switch (3com
office connect) -network utilization is low when I made test.
Ping to DB server less than 10ms and no packets lost detected when I
ping 100 times with block size 65500

Same tests, using MSSQL Query Analyser got same results for remote and
local server. So, as far as I understand, there is PHP problem, occurs
with remote DB server using.

I want hear any opinion, exept use snap version of php (I tested also
in SNAP version two days ago)


Your, 
vladimir,
Novosibirsk,
Russia.




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

#21772 [Opn]: mssql speed when using remote server

[joey]

 ID:   21772
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: MSSQL related
 Operating System: windows 2000/sp3
 PHP Version:  4.2.3
 New Comment:

We've been using PHP hosted on a win32 machine to connect 
to SQL Server 2000.  When the PHP host and the MSSQL host
are the same machine, everything is fine. But when we try
to use seperate hosts for PHP and MSSQL, query times become
unbearably slow.

The odd thing is that I can run the same scripts on the
same network connecting to the same MSSQL server from a Linux box, and
see acceptable response times.

As an example, I did a script that does 1000 iterations
of 'sp_sproc_columns @procudure_name = "some_proc"' in three
different setups.


Setup 1:
  MSSQL and PHP on the Win2k host, call it machine 'A'
  Average Response time over 5 iterations of script: 18s

Setup 2:
  MSSQL on host 'A', PHP on Linux host ('B')
  Average Response time over 5 iterations of script: 41s
  (Given the size of the result set, this is an acceptable
   response time.)

Setup 3:
  MSSQL on host 'A', PHP on seperate Win2k host ('C')
  Average Response time over 5 iterations: 3 minutes, 20s

Clearly, there is something wrong here. I had a different admin set up
a similar network without looking at my php.ini, etc., and he had
similar results.


Previous Comments:


[2003-01-21 03:47:22] [EMAIL PROTECTED]

Actually, we have done extensive testing on this bug.

If I write a C++ program to run the same query results, it operates as
expected.

If I run the query in 'Query Analyzer', a Microsoft tool, it operates
as expected.

If I run the query via PHP from a LINUX box (compiled with MSSQL
support via the FreeTDS drivers), it operates as expected.

If I run the query via PHP from a Windows box, LO AND BEHOLD, 500-600%
longer to run the query!

This is most definitely something wrong between PHP and the MSSQL
libraries on Win32 machines. I'll add my post from php-db that has
better details in a moment.



[2003-01-20 13:52:49] [EMAIL PROTECTED]

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

Thank you for your interest in PHP.

When dealing with i-net connections even if they are local there is a
lot more additional work that needs to be done. I wouldn't think this
would amount to 3.5 times speed difference, but with Win32 you never
know.
PHP does not initiate the connection to the SQL server itself, it does
it by using the appropriate libraries. So, I do not believe that PHP
could be at fault here.



[2003-01-20 08:01:06] [EMAIL PROTECTED]

I forgot one detail:
I test both MSSQL 7 and MSSQL 2K with latest services packs, 
supplied from MS.



[2003-01-20 07:51:09] [EMAIL PROTECTED]

Hello!

I made small script for determine difference between remote and local
MSSQL server use.
I don't put this script (it is very simple: 1000 loops of db_connect,
1000 loops of mssql_select_db, 1000 loops of mssql_query with load 1000
records rowset, 1000 loops of call stored procedure)
Results of my research:
1. Local DB Server - Local Apache Web server - working about 1000
secounds
2. Remote DB Server - Local Apache Web server - working about 3500
secounds

Remote server connected over TCP/IP network via one 100Mb switch (3com
office connect) -network utilization is low when I made test.
Ping to DB server less than 10ms and no packets lost detected when I
ping 100 times with block size 65500

Same tests, using MSSQL Query Analyser got same results for remote and
local server. So, as far as I understand, there is PHP problem, occurs
with remote DB server using.

I want hear any opinion, exept use snap version of php (I tested also
in SNAP version two days ago)


Your, 
vladimir,
Novosibirsk,
Russia.




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

#21236 [Opn->Bgs]: debug_backtrace() doesn't give function args within the same file

[sniper]

 ID:   21236
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

Definately optimizer bug. You need to report that to Zend..



Previous Comments:


[2003-01-21 01:58:38] [EMAIL PROTECTED]

Aha!

Trying it with the CLI inspired me.  I tried it myself and still had
problems, but that eliminated apache2 as the problem.  Then I realized
I had Zend Optimizer enabled and that proved to be the problem
-disabling Optimizer makes it work properly.  I guess that makes a
certain amount of sense.

Do you have any idea if that would be considered a bug in Optimizer or
if it's just an unavoidable problem?



[2003-01-21 00:27:21] [EMAIL PROTECTED]

This worked for me with both PHP/CLI and under Apache2 just fine..

How did you configure PHP and Apache2?
What MPM is Apache2 running as?
Which Apache2 version?




[2003-01-20 21:36:19] [EMAIL PROTECTED]

Ok... you need 2 files.

--file1.php---

--end file1.php---

--file2.php---
';

$backtrace = debug_backtrace();

foreach ( $backtrace as $frame ) {
echo
"$frame[file]$frame[line]$frame[function]";
print_r($frame['args']);
echo "\n";
}

echo '';
}
?>
-end file2.php---

On my server (apache2, php4.3) I get:
/home/julian/public_html/file1.php 5 f3 Array ( [0] => foo )  
/home/julian/public_html/file1.php 9 f2  
/home/julian/public_html/file1.php 12 f1  

But on my friend's server (apache1.3, php4.3) - though there are surely
plenty of other differences as well - I get:
/web/sites/Julian/docs/file1.php 5 f3 Array ( [0] => foo )  
/web/sites/Julian/docs/file1.php 9 f2 Array ( [0] => foo )  
/web/sites/Julian/docs/file1.php 12 f1 Array ( [0] => foo )



[2003-01-20 21:02:27] [EMAIL PROTECTED]

Please add a short example script which shows the problem
clearly.




[2003-01-20 18:31:47] [EMAIL PROTECTED]

A friend tried this and doesn't seem to see the problem.  The main
difference is that he is testing with Apache 1.3 whereas I was testing
with Apache 2... perhaps that is the key somehow?  I will try to test
it myself when I have time but I thought it might click for someone so
I'm noting it now.



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

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

#21772 [Bgs->Opn]: mssql speed when using remote server

[joey]

 ID:   21772
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: MSSQL related
 Operating System: windows 2000/sp3
 PHP Version:  4.2.3
 New Comment:

Actually, we have done extensive testing on this bug.

If I write a C++ program to run the same query results, it operates as
expected.

If I run the query in 'Query Analyzer', a Microsoft tool, it operates
as expected.

If I run the query via PHP from a LINUX box (compiled with MSSQL
support via the FreeTDS drivers), it operates as expected.

If I run the query via PHP from a Windows box, LO AND BEHOLD, 500-600%
longer to run the query!

This is most definitely something wrong between PHP and the MSSQL
libraries on Win32 machines. I'll add my post from php-db that has
better details in a moment.


Previous Comments:


[2003-01-20 13:52:49] [EMAIL PROTECTED]

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

Thank you for your interest in PHP.

When dealing with i-net connections even if they are local there is a
lot more additional work that needs to be done. I wouldn't think this
would amount to 3.5 times speed difference, but with Win32 you never
know.
PHP does not initiate the connection to the SQL server itself, it does
it by using the appropriate libraries. So, I do not believe that PHP
could be at fault here.



[2003-01-20 08:01:06] [EMAIL PROTECTED]

I forgot one detail:
I test both MSSQL 7 and MSSQL 2K with latest services packs, 
supplied from MS.



[2003-01-20 07:51:09] [EMAIL PROTECTED]

Hello!

I made small script for determine difference between remote and local
MSSQL server use.
I don't put this script (it is very simple: 1000 loops of db_connect,
1000 loops of mssql_select_db, 1000 loops of mssql_query with load 1000
records rowset, 1000 loops of call stored procedure)
Results of my research:
1. Local DB Server - Local Apache Web server - working about 1000
secounds
2. Remote DB Server - Local Apache Web server - working about 3500
secounds

Remote server connected over TCP/IP network via one 100Mb switch (3com
office connect) -network utilization is low when I made test.
Ping to DB server less than 10ms and no packets lost detected when I
ping 100 times with block size 65500

Same tests, using MSSQL Query Analyser got same results for remote and
local server. So, as far as I understand, there is PHP problem, occurs
with remote DB server using.

I want hear any opinion, exept use snap version of php (I tested also
in SNAP version two days ago)


Your, 
vladimir,
Novosibirsk,
Russia.




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

#21441 [Csd->Bgs]: POST-ed array repeats itself

[moriyoshi]

 ID:   21441
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Bogus
 Bug Type: Apache2 related
 Operating System: RH 8.0 Apache 2.0
-PHP Version:  4.2.2
+PHP Version:  4CVS-2003-01-20 (stable)
 New Comment:

To avoid confusions, let me mark this one as bogus.
Thanks for you cooperation.



Previous Comments:


[2003-01-21 03:34:04] [EMAIL PROTECTED]

Excuse me, but this report is actually the dupe of bug #18648.
Could you report the further info at that page?
We're investigating this issue now.

Moriyoshi




[2003-01-21 03:01:07] [EMAIL PROTECTED]

The problem is that since then I upgraded to the latest CVS version
(4.3.1-dev), and the problem still exists:

Example:
http://www.parbanszep.hu/aa.php
Enter some text and submit. You will see what comes back. And the php
source is:










If I use GET instead of POST it seams to be OK. So this is not an
array, but rather a POST related bug.

Further info:
http://www.parbanszep.hu/info.php



[2003-01-21 02:50:22] [EMAIL PROTECTED]

i use the current releas version -> 4.3.0 on redhat-8.0 with apache
2.0.43 and get the same error.

-

-
input string>tralalala

$HTTP_POST_VARS['szuk']  tralalalaszuk=tralalalala



[2003-01-06 12:11:11] [EMAIL PROTECTED]

Hi,

i use the current releas version -> 4.3.0 on redhat-8.0 with apache
2.0.43 and get the same error.

here is another example

\$_POST ";  

print_r($_POST);   

echo "\n\$_GET ";  

print_r($_GET);

echo ""; 

   

?> 

   

   


chbox 1  

chbox 2  

chbox 3  

chbox 4  

chbox 5 
 




output (all checkboxes selected):
$_POST Array
(
[chkTest] => Array
(
[0] => chbox 1
[1] => chbox 2
[2] => chbox 3
[3] => chbox 4
[4] => chbox 5
[5] => chbox 2
[6] => chbox 3
[7] => chbox 4
[8] => chbox 5
)

[submit] => submit
)

$_GET Array
(
)


When I replace the POST wit GET it works fine.

cya later
/Stephan



[2003-01-05 16:44:45] [EMAIL PROTECTED]

Reclassified




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

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