#21688 [Fbk->Opn]: CGI Timeout

[cchrist]

 ID:   21688
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: IIS related
 Operating System: win2k advanced server
 PHP Version:  4.3.0
 New Comment:

I've installed the new stable WIN32 release on my production
environment, hopefully the bug is fixed. lets see how it behaves. Would
be glad. What has been changed? it looks good, any weird behaviour so
far. Should I also post the php.ini config file?


Previous Comments:


[2003-02-06 10:08:31] [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-02-06 10:05:18] [EMAIL PROTECTED]

ok, on my workstation I have Visual Studio and thus I know the
CGI-version of PHP actually crashed.

Here is the CGI-IIS-error:

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

Here the popup's:
Application popup: php.exe - Application Error : The instruction at
"0x1b00997b" referenced memory at "0x1b00997b". The memory could not be
"read".

Application popup: php.exe - Application Error : The instruction at
"0x10030727" referenced memory at "0x01790dd8". The memory could not be
"read".



[2003-02-06 09:43:29] [EMAIL PROTECTED]

It seems that when the buffer contents is very small (when using output
buffering ?? or under normal usage, still looking into that) doens't
return headers and/or body/wrong headers (don't know which one).

The CGI-interface of IIS doesn't know how to handle it anyway.

Hope this was usefull.



[2003-01-16 09:21:48] [EMAIL PROTECTED]

I'm using php 4.3.0 and IIS 5, Win2kadv

As already a couple of others found out, PHP misbehaves, when installed
as CGI under Win2k advanced server. the scripts more than often time
out and the server announces the following error message - sometimes
the server even hangs totally - but in any case there are a lot of
php.exe processes in the server's memory left after shutting IIS down:

The script /xxx/index.php with parameters '' has not responded within
the configured timeout. The HTTP server is terminating the script.
For additional information please visit micro$oft website bla bla
bla...

Who knows a cure for this IIS version? As I don't have any problem
under apache for windows 

Somebody posted a registry hack how to stop that. Could you repost
that?





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

#22105 [NEW]: mkdir changes the variable passed to it

[bram]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.2.2
PHP Bug Type: Directory function related
Bug description:  mkdir changes the variable passed to it

$tmp = "xx/yy";

$parts = explode("/",$tmp);

for($i=0;$i';
@mkdir($directory,0775);
echo 'after :: ' . $directory . '';
}

outputs:
before :: files/xx
after :: files/xx
before :: files/xx/yy
after :: files/xxyy

The last line has the error.
As you can see mkdir() changes the variable.
Even if the rest of the code is buggy ( ;) )
this shouldn't happen :)

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

#21333 [Com]: Nesting level too deep - recursive dependency?

[alex]

 ID:   21333
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Reproducible crash
 Operating System: RedHat Linux 8.0
 PHP Version:  4.3.0
 New Comment:

Me too, with Apache 1.3.27, y php 4.3.0 using php-nuke 6.0

My solution:

editing php.ini:

change this line:
extension_dir = /usr/lib/php4

for this:
extension_dir = /usr/lib/php

best regards from spain (barcelona)

bye
alex


Previous Comments:


[2003-01-03 16:48:38] [EMAIL PROTECTED]

Okay, I solved my own problem with a little help from a comment in bug
21206.  My /etc/php.ini file was pointing to the RedHat-supplied
modules in /usr/lib/php4.  I was able to fix the problem by changing
the line in /etc/php.ini that says:

extension_dir = /usr/lib/php4

to point to the new location of the modules.  This is where the
imap.so, ldap.so, mysql.so, etc are.  Alternatively, you could copy the
newly-compiled modules from the compile-directory/modules up to
/usr/lib/php4.

Now, mine works perfectly.



[2003-01-03 02:20:07] [EMAIL PROTECTED]

I'm seeing the same problem with a very similar config:
RH8.0, php4-STABLE-200301020430 even running the
command line tool gives this result, so I believe this is
independent of the apache version:

echo "" | ./php

Fatal error: Nesting level too deep - recursive dependency? in Unknown
on line 0

I did a make test and submitted it to QA.  I hope this helps.



[2003-01-02 06:08:49] [EMAIL PROTECTED]

Unfortunately I can not send the "make test" results because the
company where I work has too much restrictive firewall rules (paranoid
grade): Form upload limits, no pop3 clients, password protected proxy,
...

All that I can currently tell you is that I have the same problem even
with a much simpler PHP configuration:

./configure i386-redhat-linux \
  --with-apxs2=/usr/sbin/apxs \
  --with-config-file-path=/etc



[2003-01-02 04:54:17] [EMAIL PROTECTED]

Please run a "make test" after compiling PHP with "make" in the source
directory and press "y" if it asks to send the information to the QA
site.

Derick



[2003-01-02 04:47:34] [EMAIL PROTECTED]

This error message appears on every script, even in this one:



This is just as it looks at the end of ANY php page:

"Fatal error: Nesting level too deep - recursive dependency? in Unknown
on line 0"

Environment:

RedHat Linux8.0 Kernel 2.4.18-14 
Apache 2.0.40
PHP 4.3.0

And this is how I compiled PHP:

./configure i386-redhat-linux \
  --with-apxs2=/usr/sbin/apxs \
  --with-config-file-path=/etc \
  --with-gd \
  --with-zlib \
  --enable-ftp \
  --with-mysql \
  --with-informix=/opt/informix \
  --enable-sockets





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

#22106 [NEW]: Segmentation fault and IMAP

[maxim]

From: [EMAIL PROTECTED]
Operating system: RedHat Linux 7.2 
PHP version:  4.3.0
PHP Bug Type: IMAP related
Bug description:  Segmentation fault and IMAP

Hello! 

I can't run httpd with mod_php4/IMAP support. Config lines there are:

PHP - 
./configure' --with-zlib --with-pgsql=/usr/local/pgsql --with-layout=GNU
--with-dom=/usr/local/lib --without-mysql --with-imap=/usr/local
--with-kerberos=/usr/local --with-xslt-sablot --enable-xslt
--with-iconv=/usr/local/lib/ --with-curl=/usr/local/lib
--with-apache=../apache_1.3.27 --enable-calendar --with-gettext=/bin
--with-ming=/usr/lib --with-gd --enable-gd-native-ttf --with-png-dir=/usr
--with-jpeg-dir=/usr --with-freetype-dir=/usr/local --with-bz2
--enable-debug=yes

Apache - SSL_BASE="/usr/src/openssl-0.9.6b" ./configure
--with-layout=RedHat --enable-module=so --enable-module=auth
--enable-module=ssl --enable-module=proxy
--activate-module=src/modules/php4/libphp4.a

All things compiled successfully, but when I tried to run httpd with gdb,
I get the following message:

(gdb) run -X
Starting program: /usr/sbin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
0x084c8100 in ?? () at eval.c:41
41  eval.c: No such file or directory.
in eval.c

When I compiled this without IMAP support, all works perfectly.

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

#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:

Good, :-), php_image.h works fine on my platform.

Next problem I encounter is dl.c and zend_extensions.c
I suggest the following syntax fixes:

<<
diff dl.c dl.c.orig
141c141
   handle = DL_LOAD(libpath);

with dl.c is
/* $Id: dl.c,v 1.79.2.3 2003/01/29 15:40:24 edink Exp $ */

$ diff php-4.3.0/Zend/zend*ftu php-4.3.0-latest/Zend/zend_extensions.c
5c5
<| Copyright (c) 1998-2002 Zend Technologies Ltd.
(http://www.zend.com) |
---
>| Copyright (c) 1998-2003 Zend Technologies Ltd.
(http://www.zend.com) |
33c33
<   handle = (DL_HANDLE)DL_LOAD(path);  /* FTU */
---
>   handle = DL_LOAD(path);

No version for zend_extensions.c
>>

Make trace:
/bin/sh libtool --silent --mode=compile /usr/vac/bin/xlc 
-Iext/standard/ -I/s00/opendata/build/php-4.3.0-latest/ext/standar
d/
...
 -c /s00/opendata/build/php-4.3.0-latest/ext/standard/dl.c -o
ext/standard/dl.lo 
"/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/ext/standard/dl.c", line 141.16:
1506-068 (S) Operation between types "void*" and "int" is not
 allowed.
make: The error code from the last command is 1.

/bin/sh libtool --silent --mode=compile /usr/vac/bin/xlc  -IZend/
-I/s00/opendata/build/php-4.3.0-latest/Zend/ -DPHP_ATOM_INC 
 -c /s00/opendata/build/php-4.3.0-latest/Zend/zend_extensions.c -o
Zend/zend_extensions.lo 
"/s00/opendata/build/php-4.3.0-latest/Zend/zend_extensions.c", line
33.16: 1506-068 (S) Operation between types "void*" and "int" is
 not allowed.
make: The error code from the last command is 1.

<<<
Other errors mentioned earlier remains 
See [21 Jan 8:06am] paragraph for suggested fix.
(e.g.):
>>>
/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/ 
-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
2494.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
2494.9: 1506-358 (I) "zend_isnan" is defined on line 2500 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 2494.9:
1506-213 (S) Macro name zend_isnan cannot be redefined.
"/s00/opendata/build/php-4.3.0-latest/main/php_config.h", line 2494.9:
1506-358 (I) "zend_isnan" is defined on line 2500 of /s00/ope
ndata/build/php-4.3.0-latest/Zend/../main/php_config.h.
make: The error code from the last command is 1.


Previous Comments:


[2003-02-06 10:07:54] [EMAIL PROTECTED]

Please get new snapshot, I fixed that php_image.h issue
already, the revision in php_image.h should be 1.19.4.2

The other error has to be investigated..




[2003-02-06 05:30:37] [EMAIL PROTECTED]

The compilation still fails (using xlc).

I suggest the following fix for php_image.h because xlc is very picky
about comma left at the end of a structure:

diff  php-4.3.0-latest/ext/standard/php_image.h
php-4.3.0-latest/ext/standard/php_image.h.org
20c20
< /* $Id: php_image.h,v 1.19 2002/06/24 19:36:26 helly Exp $ */
---
> /* $Id: php_image.h,v 1.19.4.1 2002/12/31 16:35:33 sebastian Exp $
*/
48c48
<   IMAGE_FILETYPE_IFF
---
>   IMAGE_FILETYPE_IFF,

Sorry I don't have diff -u. Which option is the best ?

$ diff -u php-4.3.0-latest/ext/standard/php_image.h
php-4.3.0-latest/ext/standard/php_image.h.org
diff: illegal option -- u
Usage: diff [-bcitw] [[-C Lines|-D String|-e|-f|-n]|[-h]] File1 File2
   diff [-bcilrstw] [[-C Lines|-e|-f|-n]|[

#22099 [Opn->Fbk]: Strange freeze when EOF reached in socket.

[sniper]

 ID:   22099
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Sockets related
 Operating System: Redhat 7.3
-PHP Version:  4.3.0
+PHP Version:  4.3.1-dev
 New Comment:

Would it be possible to give us some complete (but short!) 
example script that we can use to test this ourselves? 

You've got some objects mixed there and I guess you're
also using some output buffering too?

If possible, try creating a script that only has the socket
stuff in it, without the ob_* and OO.




Previous Comments:


[2003-02-06 18:56:13] [EMAIL PROTECTED]

Nope, problem still exists.  As of right now, it's hanging on a piece
of code that looks like this:

 CODE 

print "Unresponsive server, closing connection... ";
ob_flush();

if (is_resource($this->m_rConn))
  fclose($this->m_rConn);

$this->m_rConn = NULL;
print "Done!\n";
ob_flush();

 CODE 

Note that it's not printing "Done!" in the spot where it is freezing. 
Meaning it's either is_resource, or fclose.  How's that for nasty?



[2003-02-06 17:37:38] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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


..and you'll know for sure if it's related to #21529 since
that was fixed in CVS..




[2003-02-06 17:17:34] [EMAIL PROTECTED]

I'm not sure this bug is related to bug #21529 or not; this is not a
segfault, but a simple program hang.  This is from a script I run from
a PHP CLI, and is intermittent.  I'd attach the script, but it's a 10k
class file...  I've used stream_set_timeout to set the limit to two
seconds, and the connect timeout is also two seconds.  From my
debugging output, there are no infinite loops, the freezes are
essentially random, and sometimes nonexistent - but always before a
single call to fclose after feof() returns true.  This leads me to
believe that a remote server I'm contacting isn't behaving properly
100% of the time

php -m returns:

[PHP Modules]
ctype
dio
ftp
mysql
overload
pcre
pgsql
posix
session
standard
tokenizer
wddx
xml
zlib

Backtrace:

#0  0x401c941e in select () from /lib/libc.so.6
#1  0x08199f44 in __DTOR_END__ ()
#2  0x08121d01 in _php_stream_free (stream=0x83079c4, close_options=3)
at /home/install/php-4.3.0/main/streams.c:327
#3  0x080acff7 in zif_fclose (ht=1, return_value=0x825e32c,
this_ptr=0x0, 
return_value_used=0) at
/home/install/php-4.3.0/ext/standard/file.c:1120
#4  0x0815b05c in execute (op_array=0x823a26c)
at /home/install/php-4.3.0/Zend/zend_execute.c:1596
#5  0x0815b234 in execute (op_array=0x822b5f0)
at /home/install/php-4.3.0/Zend/zend_execute.c:1640
#6  0x0815b234 in execute (op_array=0x8222518)
at /home/install/php-4.3.0/Zend/zend_execute.c:1640
#7  0x0815b234 in execute (op_array=0x81daaa4)
at /home/install/php-4.3.0/Zend/zend_execute.c:1640
#8  0x08145398 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/install/php-4.3.0/Zend/zend.c:864
#9  0x081188b5 in php_execute_script (primary_file=0xba40)
at /home/install/php-4.3.0/main/main.c:1573
#10 0x08163ecc in main (argc=2, argv=0xbae4)
at /home/install/php-4.3.0/sapi/cli/php_cli.c:746
#11 0x4010a1c4 in __libc_start_main () from /lib/libc.so.6

I did it three times to make sure, and aside from memory segments, the
trace is the same.




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

#22100 [Opn->Fbk]: Query failure when WHERE clause matches on column with value '0'

[sniper]

 ID:   22100
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: PostgreSQL related
 Operating System: FreeBSD 4.7
 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-02-06 18:05:51] [EMAIL PROTECTED]

I have a PostgreSQL db with the table 'news_article', which has its
primary index a serial column named 'art_id'. This table has a row
whose art_id is set to zero. Now I'll do the following:

1. Make a persistent connection.
2. Make query of the form: 
 SELECT * FROM news_article WHERE art_id = 0

Most of the time this query will work fine, but if I refresh the PHP
script multiple times, I'll eventually get an error with the following
error messages.

---
PHP error message:
---
Warning: pg_query() [function.pg-query]: Query failed: server closed
the connection unexpectedly This probably means the server terminated
abnormally before or while processing the request. .in [filename.php]
on line 21

--
PostgreSQL error message:
--
pq_recvbuf: recv() failed: Undefined error: 0


Some things I've noticed:

* This problem does not seem to appear when
  connecting with non-persistent connections.

* Although the PHP error message suggests the
  connection was closed prematurely, you can
  still issue successful queries using the same
  connection resource later on in the PHP page,
  so it appears that the connection is still
  open.






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

#22103 [Opn->Fbk]: imagefilledellipse() is incorrect with alpha blending

[sniper]

 ID:   22103
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: GD related
 Operating System: Linux
 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


There were couple of fixes in GD in CVS.
If it still fails, please provide a short example script.



Previous Comments:


[2003-02-06 22:18:03] [EMAIL PROTECTED]

(Using built-in GD 2.x in PHP 4.3.0)

imagefilledellipse() creates moire' patterns inside the filled ellipse
when alpha blending is enabled.

The problem seems to be that the fill algorithm strokes the same point
within the ellipse several times and due to the alpha blending of
single pixels creates several color shades within the ellipse.

This is fine as long as a solid fill is used but does not work together
with alpha blending. 






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

#22106 [Opn->Fbk]: Segmentation fault and IMAP

[sniper]

 ID:   22106
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: IMAP related
 Operating System: RedHat Linux 7.2
-PHP Version:  4.3.0
+PHP Version:  4.3.1-dev
 New Comment:

Using '/usr/local/lib' for any configure option is wrong.
Use '/usr/local' instead. (this can not cause the problem though)

And to get the backtrace for the crash:

(gdb) run -X

(gdb) bt

Please try minimizing the configure options and try this 
configure line for PHP:

./configure --disable-all --with-apache=../apache_1.3.27
--with-imap=/usr/local --with-kerberos




Previous Comments:


[2003-02-07 05:43:30] [EMAIL PROTECTED]

Hello! 

I can't run httpd with mod_php4/IMAP support. Config lines there are:

PHP - 
./configure' --with-zlib --with-pgsql=/usr/local/pgsql
--with-layout=GNU --with-dom=/usr/local/lib --without-mysql
--with-imap=/usr/local --with-kerberos=/usr/local --with-xslt-sablot
--enable-xslt --with-iconv=/usr/local/lib/ --with-curl=/usr/local/lib
--with-apache=../apache_1.3.27 --enable-calendar --with-gettext=/bin
--with-ming=/usr/lib --with-gd --enable-gd-native-ttf
--with-png-dir=/usr --with-jpeg-dir=/usr --with-freetype-dir=/usr/local
--with-bz2 --enable-debug=yes

Apache - SSL_BASE="/usr/src/openssl-0.9.6b" ./configure
--with-layout=RedHat --enable-module=so --enable-module=auth
--enable-module=ssl --enable-module=proxy
--activate-module=src/modules/php4/libphp4.a

All things compiled successfully, but when I tried to run httpd with
gdb, I get the following message:

(gdb) run -X
Starting program: /usr/sbin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
0x084c8100 in ?? () at eval.c:41
41  eval.c: No such file or directory.
in eval.c

When I compiled this without IMAP support, all works perfectly.

php4-STABLE-200302071030
apache 1.3.27
imap-2001a-10




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

#22107 [NEW]: file upload problem

[luca . mariano]

From: [EMAIL PROTECTED]
Operating system: OpenBSD
PHP version:  4.3.0
PHP Bug Type: Apache related
Bug description:  file upload problem

When calling a php script from a POST form like this:


Send file: 



the script upload.php have the $_FILES array empty.

The output of print_r($_FILES) is an empty array ().

HTML form and PHP pages are under https (Apache/1.3.26 (Unix) PHP/4.3.0
mod_ssl/2.8.10 OpenSSL/0.9.7-beta3).

Of course all works fine with a Linux Box (RH 7.2) and with windoz too
(using http).


Configure Options for php:
./configure --with-apxs=/usr/sbin/apxs --enable-ftp
--enable-inline-optimization --with-zlib --disable-cli --disable-cgi
--with-mysql 


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

#22107 [Opn->Fbk]: file upload problem

[andrey]

 ID:   22107
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Apache related
 Operating System: OpenBSD
 PHP Version:  4.3.0
 New Comment:

 Could you provide some link to a place where your results can be seen?


Previous Comments:


[2003-02-07 07:01:58] [EMAIL PROTECTED]

When calling a php script from a POST form like this:


Send file: 



the script upload.php have the $_FILES array empty.

The output of print_r($_FILES) is an empty array ().

HTML form and PHP pages are under https (Apache/1.3.26 (Unix) PHP/4.3.0
mod_ssl/2.8.10 OpenSSL/0.9.7-beta3).

Of course all works fine with a Linux Box (RH 7.2) and with windoz too
(using http).


Configure Options for php:
./configure --with-apxs=/usr/sbin/apxs --enable-ftp
--enable-inline-optimization --with-zlib --disable-cli --disable-cgi
--with-mysql 






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

#22104 [Opn->Fbk]: problem with adding value to multiplie dimensional arrays

[andrey]

 ID:   22104
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Arrays related
 Operating System: Windows
 PHP Version:  4.3.0
 New Comment:

 I cannot simulate what you say. Here is script that I wrote to test.
Test with it. Please provide good feedback as well as an example code
(as small as possible please).


 array(1=>"one",2=>"two", 3=>"three"),
"1" => array(1=>"One",2=>"Two", 3=>"Three"),
);
var_dump($array);
foreach($array[0] as $key => $value)
{
$array[1]=1;
}

var_dump($array);
?>


Previous Comments:


[2003-02-07 01:04:09] [EMAIL PROTECTED]

foreach($array[0] as $key => $value)
{
$array[1]=1;
}

This will change the value on $array[0] too, i can't explain it more. I
tested with serialize and the value on the variable gets very
strange...




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

#21956 [Opn->Bgs]: define constants not taking heredoc strings as value

[nicos]

 ID:   21956
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Strings related
 Operating System: Win2k
 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.

Please read http://www.php.net/manual/en/function.define.php it has
good nice examples on it.


Previous Comments:


[2003-01-29 19:52:03] [EMAIL PROTECTED]

when using define() to create constants, it all seems to work fine when
using standard strings.

However, under the definition for the arguments on define(), it says
that the define function can take string() as an argument.

looking at strings, heredoc is a valid string argument, however when
trying to define a constant as follows, the constant returns a null
string.

define($html_header, <

#22108 [NEW]: php doesn't ignore the utf-8 BOM

[bugzilla]

From: [EMAIL PROTECTED]
Operating system: windows 2000
PHP version:  4.2.3
PHP Bug Type: Output Control
Bug description:  php doesn't ignore the utf-8 BOM

Problem:
When a php file is saved in utf-8 format with the UTF-8 BOM as the first
three bytes of the file (EF BB BF), PHP doesn't ignore these bytes when
loading and compiling the file, but instead considers them output coming
prior to the http://bugs.php.net/?id=22108&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22108&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22108&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22108&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22108&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22108&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22108&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22108&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22108&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22108&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22108&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22108&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22108&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22108&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22108&r=gnused

#22108 [Opn->Fbk]: php doesn't ignore the utf-8 BOM

[derick]

 ID:   22108
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Output Control
 Operating System: windows 2000
 PHP Version:  4.2.3
 New Comment:

What is a BOM ?

Derick


Previous Comments:


[2003-02-07 08:46:36] [EMAIL PROTECTED]

Problem:
When a php file is saved in utf-8 format with the UTF-8 BOM as the
first three bytes of the file (EF BB BF), PHP doesn't ignore these
bytes when loading and compiling the file, but instead considers them
output coming prior to the http://bugs.php.net/?id=22108&edit=1

#22107 [Fbk]: file upload problem

[sniper]

 ID:   22107
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Apache related
 Operating System: OpenBSD
 PHP Version:  4.3.0
 New Comment:

Try removing this from your configure line:
 --enable-inline-optimization

Then 'rm config.cache' and run configure/make etc.
And also check your php.ini and that the correct
one is loaded by php.

Doing a 'diff -u php.ini php.ini-dist' would also help a bit.




Previous Comments:


[2003-02-07 07:08:52] [EMAIL PROTECTED]

 Could you provide some link to a place where your results can be seen?



[2003-02-07 07:01:58] [EMAIL PROTECTED]

When calling a php script from a POST form like this:


Send file: 



the script upload.php have the $_FILES array empty.

The output of print_r($_FILES) is an empty array ().

HTML form and PHP pages are under https (Apache/1.3.26 (Unix) PHP/4.3.0
mod_ssl/2.8.10 OpenSSL/0.9.7-beta3).

Of course all works fine with a Linux Box (RH 7.2) and with windoz too
(using http).


Configure Options for php:
./configure --with-apxs=/usr/sbin/apxs --enable-ftp
--enable-inline-optimization --with-zlib --disable-cli --disable-cgi
--with-mysql 






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

#22108 [Fbk]: php doesn't ignore the utf-8 BOM

[sniper]

 ID:   22108
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Output Control
 Operating System: windows 2000
 PHP Version:  4.2.3
 New Comment:

And why an earth would you save PHP files in any other
format than ascii?



Previous Comments:


[2003-02-07 08:53:10] [EMAIL PROTECTED]

What is a BOM ?

Derick



[2003-02-07 08:46:36] [EMAIL PROTECTED]

Problem:
When a php file is saved in utf-8 format with the UTF-8 BOM as the
first three bytes of the file (EF BB BF), PHP doesn't ignore these
bytes when loading and compiling the file, but instead considers them
output coming prior to the http://bugs.php.net/?id=22108&edit=1

#22109 [NEW]: With-flatfile compile option causes core dumps during make test

[dwkoehler]

From: [EMAIL PROTECTED]
Operating system: Solaris 2.7
PHP version:  4CVS-2003-02-07 (stable)
PHP Bug Type: DBM/DBA related
Bug description:  With-flatfile compile option causes core dumps during make test

Compiled with GCC 3.2.1 on Solaris 2.7 to work with Apache 2.0.40. Apache
compiled with same GCC.

Testing with CLI version in sapi/cli via make test.
The SISSEGV segmentation core dump occurs with the "tests/func/005a.phpt"
only when I include the --with-flatfile option in the configure script, by
itself or in combination with any other option. Absent this flatfile
setting, no core dump occurs.  I've confirmed this with numerous clean,
right from scratch reconfigures and compiles.

Within the failing test, the register_shutdown_function() call works ok. 
It appears that the dump is being triggered when the time limit set by
set_time_limit() expires within the infinite for loop.  I varied the time
value to set_time_limit(), but still got the core dumps.  Using GDB
4.1.18, I got this backtrace:

Program received signal SIGSEGV, Segmentation fault.
0xff165758 in aiosigcancelhndlr () from /usr/lib/libaio.so.1
(gdb) bt
#0  0xff165758 in aiosigcancelhndlr () from /usr/lib/libaio.so.1 #1 
0xfeffbdfc in __sighndlr () from /usr/lib/libthread.so.1 #2   
#3  execute (op_array=0x2890b0, tsrm_ls=0x1dbbd0)
at /opt/src/php/php4-STABLE-200302021630/Zend/zend_execute.c:1350
#4  0x1395fc in zend_execute_scripts (type=8, tsrm_ls=0x1dbbd0,
retval=0x0, 
file_count=3) at
/opt/src/php/php4-STABLE-200302021630/Zend/zend.c:864
#5  0x1078ac in php_execute_script (primary_file=0xffbef110,
tsrm_ls=0x1dbbd0)
at /opt/src/php/php4-STABLE-200302021630/main/main.c:1582
#6  0x14da14 in main (argc=2, argv=0xffbef19c)
at /opt/src/php/php4-STABLE-200302021630/sapi/cli/php_cli.c:753

Due to the infinite for loop in the failing test, subseqent core dumps
will backtrace differently depending on just where in the loop cycle the
dump occurs at.  Inother words, don't expect execute in frame 3 to look
the same from trace to trace. Though its a bit of a chameleon to chase
down, I'm still on the prowl to locate exact where this is happening at.

---dave

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

#22099 [Fbk->Opn]: Strange freeze when EOF reached in socket.

[sthomas]

 ID:   22099
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Sockets related
 Operating System: Redhat 7.3
 PHP Version:  4.3.1-dev
 New Comment:

Well, originally I had the ob_flush in there because flush and
ob_implicit_flush didn't work, but that seems to be fixed now.  Making
this test script was *not* easy; tracking this bug down has been
driving me nuts.  If you want my list of hosts, you're welcome to it,
but it froze on mail.uu.net last time I ran it.  Here you go:



And here's a new backtrace for the php4-STABLE tarball I downloaded
last night.

#0  0x401c941e in select () from /lib/libc.so.6
#1  0x08199a44 in __DTOR_END__ ()
#2  0x08122165 in _php_stream_free (stream=0x81eb54c, close_options=3)
at /home/install/php4-STABLE-200302062230/main/streams.c:327
#3  0x080ad01f in zif_fclose (ht=1, return_value=0x81e7c2c,
this_ptr=0x0, 
return_value_used=0)
at /home/install/php4-STABLE-200302062230/ext/standard/file.c:1120
#4  0x0815b2d0 in execute (op_array=0x81d8c44)
at /home/install/php4-STABLE-200302062230/Zend/zend_execute.c:1596
#5  0x0814560c in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/install/php4-STABLE-200302062230/Zend/zend.c:864
#6  0x08118b39 in php_execute_script (primary_file=0xba50)
at /home/install/php4-STABLE-200302062230/main/main.c:1582
#7  0x08164180 in main (argc=2, argv=0xbaf4)
at /home/install/php4-STABLE-200302062230/sapi/cli/php_cli.c:753
#8  0x4010a1c4 in __libc_start_main () from /lib/libc.so.6


Previous Comments:


[2003-02-07 06:30:32] [EMAIL PROTECTED]

Would it be possible to give us some complete (but short!) 
example script that we can use to test this ourselves? 

You've got some objects mixed there and I guess you're
also using some output buffering too?

If possible, try creating a script that only has the socket
stuff in it, without the ob_* and OO.





[2003-02-06 18:56:13] [EMAIL PROTECTED]

Nope, problem still exists.  As of right now, it's hanging on a piece
of code that looks like this:

 CODE 

print "Unresponsive server, closing connection... ";
ob_flush();

if (is_resource($this->m_rConn))
  fclose($this->m_rConn);

$this->m_rConn = NULL;
print "Done!\n";
ob_flush();

 CODE 

Note that it's not printing "Done!" in the spot where it is freezing. 
Meaning it's either is_resource, or fclose.  How's that for nasty?



[2003-02-06 17:37:38] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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


..and you'll know for sure if it's related to #21529 since
that was fixed in CVS..




[2003-02-06 17:17:34] [EMAIL PROTECTED]

I'm not sure this bug is related to bug #21529 or not; this is not a
segfault, but a simple program hang.  This is from a script I run from
a PHP CLI, and is intermittent.  I'd attach the script, but it's a 10k
class file...  I've used stream_set_timeout to set the limit to two
seconds, and the connect timeout is also two seconds.  From my
debugging output, there are no infinite loops, the freezes are
essentially random, and sometimes nonexistent - but always before a
single call to fclose after feof() returns true.  This leads me to
believe that a remote server I'm contacting isn't behaving properly
100% of the time

php -m returns:

[PHP Modules]
ctype
dio
ftp
mysql
overload
pcre
pgsql
posix
session
standard
tokenizer
wddx
xml
zlib

Backtrace:

#0  0x401c941e in select () from /lib/libc.so.6
#1  0x08199f44 in __DTOR_END__ ()
#2  0x08121d01 in _php_stream_free (stream=0x83079c4, close_options=3)
at /home/install/php-4.3.0/main/streams.c:327
#3  0x080acff7 in zif_fclose (ht=1, return_value=0x825e32c,
this_ptr=0x0, 
return_value_used=0) at
/home/install/php-4.3.0/ext/standard/file.c:1120
#4  0x0815b05c in execute (op_array=0x823a26c)
at /home/install/php-4.3.0/Zend/zend_execute.c:1596
#5  0x0815b234 in execute (op_array=0x822b5f0)
at /home/install/php-4.3.0/Zend/zend_execute.c:1640
#6  0x0815b234 in execute (op_array=0x8222518)
at /home/install/php-4.3.0/Zend/zend_execute.c:1640
#7  0x0815b234 in execute (op_array=0x81daaa4)
at /home/install/php-4.3.0/Zend/zend_execute.c:1640
#8  0x08145398 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/install/php-4.3.0/Zend/zend.c:864
#9  0x081188b5 in php_execute_script (primary_file=0xba40)
at /home/install/php-4.3.0/main/main.c:1573
#10 0x081

#22107 [Fbk->Opn]: file upload problem

[luca . mariano]

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

Thaks, I'll try soon to re-configure without-inline-optimization.
I cannot provide any link to the real installation because it's in the
LAN of a customer...


Previous Comments:


[2003-02-07 08:56:59] [EMAIL PROTECTED]

Try removing this from your configure line:
 --enable-inline-optimization

Then 'rm config.cache' and run configure/make etc.
And also check your php.ini and that the correct
one is loaded by php.

Doing a 'diff -u php.ini php.ini-dist' would also help a bit.





[2003-02-07 07:08:52] [EMAIL PROTECTED]

 Could you provide some link to a place where your results can be seen?



[2003-02-07 07:01:58] [EMAIL PROTECTED]

When calling a php script from a POST form like this:


Send file: 



the script upload.php have the $_FILES array empty.

The output of print_r($_FILES) is an empty array ().

HTML form and PHP pages are under https (Apache/1.3.26 (Unix) PHP/4.3.0
mod_ssl/2.8.10 OpenSSL/0.9.7-beta3).

Of course all works fine with a Linux Box (RH 7.2) and with windoz too
(using http).


Configure Options for php:
./configure --with-apxs=/usr/sbin/apxs --enable-ftp
--enable-inline-optimization --with-zlib --disable-cli --disable-cgi
--with-mysql 






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

#15874 [Com]: can't send mail using the mail function

[flattop21]

 ID:   15874
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: *General Issues
 Operating System: nt 4.0 terminal server client
 PHP Version:  4.1.2
 New Comment:

I'm having the same problem it looks like php does noe use the
%systemroot% variable correctly. Even if you install NT4 to c:\wtsrv
php will not function. using iis 4.0. This is a bug and yes I have set
cgi.force_redirect = 0


Previous Comments:


[2002-03-05 09:03:07] [EMAIL PROTECTED]

this is a bug!!



[2002-03-05 08:39:23] [EMAIL PROTECTED]

The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php



[2002-03-05 08:37:24] [EMAIL PROTECTED]

i have a problme when trying to send mail on a windows nt 4.0 terminal
edition. I looked at the problme and it seems as if it can't find the
ini file. no matter what i do i can't fix the problem. i have tried
installing everything several times. 
thanks
itay




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

#21956 [Bgs->Opn]: define constants not taking heredoc strings as value

[moptop69]

 ID:   21956
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: Strings related
 Operating System: Win2k
 PHP Version:  4.3.0
 New Comment:

if this is not a bug, then it would therefore be the same across all
platforms?  which would then I surmise be a documentation problem.

Since http://www.php.net/manual/en/language.constants.php defines
thus:

"Syntax
You can define a constant by using the define()-function. Once a
constant is defined, it can never be changed or undefined. 

Only scalar data (boolean, integer, float and string) can be contained
in constants."

which then links to the string defintion page here,
http://www.php.net/manual/en/language.types.string.php, where the
Syntax for string is outlines as below.

"Syntax
A string literal can be specified in three different ways. 

single quoted 
double quoted 
heredoc syntax 
"

so according to the documentation, define can take heredoc syntax as a
valid string, since heredoc is defined as a valid string syntax.

if this is incorrect, then please change this to a documentation issue
by all means, but this is not a bugus bug, it happens.


Previous Comments:


[2003-02-07 07:26:48] [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.

Please read http://www.php.net/manual/en/function.define.php it has
good nice examples on it.



[2003-01-29 19:52:03] [EMAIL PROTECTED]

when using define() to create constants, it all seems to work fine when
using standard strings.

However, under the definition for the arguments on define(), it says
that the define function can take string() as an argument.

looking at strings, heredoc is a valid string argument, however when
trying to define a constant as follows, the constant returns a null
string.

define($html_header, <

#22103 [Fbk->Opn]: imagefilledellipse() is incorrect with alpha blending

[ljpersson]

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

The problem still exist in snapshot 200302071430. 

I haven't had time to look at the GD code but this is most likely a
design flaw and not a straight bug. Fixing this will probably require a
new fill algorithm for ellipses that can guarantee that the same pixel
inside the ellipse will only be painted exactly one time.

The script below demonstrates this bug
and the resulting image can also be viewed at
http://www.aditus.nu/jpgraph/bbimages/filledellipsebug.png





Previous Comments:


[2003-02-07 06:36:22] [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 couple of fixes in GD in CVS.
If it still fails, please provide a short example script.




[2003-02-06 22:18:03] [EMAIL PROTECTED]

(Using built-in GD 2.x in PHP 4.3.0)

imagefilledellipse() creates moire' patterns inside the filled ellipse
when alpha blending is enabled.

The problem seems to be that the fill algorithm strokes the same point
within the ellipse several times and due to the alpha blending of
single pixels creates several color shades within the ellipse.

This is fine as long as a solid fill is used but does not work together
with alpha blending. 






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

#21560 [NoF->Opn]: imagettfbbox() returns different values in 4.3.0 and 4.2.1

[ljpersson]

 ID:   21560
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   No Feedback
+Status:   Open
 Bug Type: GD related
 Operating System: SusE 8.0
 PHP Version:  4.3.0
 New Comment:

The problem still exists in snapshot 200302071430

for the _exact_ same text string imagettfbbox() (and the _exact_ same
test script) returns the following (different) values depending on
version of PHP and GD

Snapshot 200302071430
Array ( [0] => -1 [1] => 14 [2] => -1 [3] => -226 [4] => -16 [5] =>
-226 [6] => -16 [7] => 14 )

PHP 4.3 (official release)
Array ( [0] => -1 [1] => 13 [2] => -1 [3] => -226 [4] => -16 [5] =>
-226 [6] => -16 [7] => 13 )

PHP 4.2.3 (with GD 2.01)
Array ( [0] => 3 [1] => -1 [2] => 3 [3] => -234 [4] => -16 [5] => -234
[6] => -16 [7] => -2 )

The only correct values are with GD 2.01 for both PHP 4.3 and snapshot
the bounding box is incorrect since it starts 14 (in snapshot) or 13
(in 4.3) pixels in into the text.


Previous Comments:


[2003-01-27 22:39:59] [EMAIL PROTECTED]

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





[2003-01-09 20:11:36] [EMAIL PROTECTED]

Try non-bundled gd 2.0.9 and see if you get the same results as the
ones you've got with bundled GD library. I suspect that the behaviour
of GD between 2.0.1 and later versions had changed.



[2003-01-09 18:59:27] [EMAIL PROTECTED]

For the given string string

"Demonstration of different\ntext of two lines"

(ArialTTF font  font 90 degrees rotation containing two lines
separated
by a single "\n".)

The imagettfbbox() returns different value arrays in PHP 4.2.1 using
GD
2.01 and
PHP 4.3.0 using builtin GD 2.08+

(You get the same difference for 4.2.1 by using GD 2.08 so the problem
must be in GD 2.08)

For GD 2.01  it returns (29,-1,29,-279,-20,-279,-20,-1)
For GD 2.08+ it returns (29,18,29,-277,-21,-277,-21,18)



[2003-01-09 18:49:49] [EMAIL PROTECTED]

For the given string string 

"Demonstration of different\ntext of two lines"

(ArialTTF font  font 90 degrees rotation containing two lines separated
by a single "\n".)

The imagettfbbox() returns different value arrays in PHP 4.2.1 using GD
2.01 and
PHP 4.3.0 using builtin GD 2.08+

(You get the same difference for 4.2.1 by using GD 2.08 so the problem
must be in GD 2.08)

For GD 2.01  it returns (-29,18,29,-277,-21,-277,-21,18)
For GD 2.08+ it returns (-29,18,29,-279,-20,-279,-20,-1)






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

#22097 [Com]: Eval fails to process this gem.

[tdrake]

 ID:   22097
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Linux x86 2.4.18
 PHP Version:  4.3.0
 New Comment:

This doesn't work as expected.  ($errormessage never actually gets set
for some reason.)  But the double eval appears to work like it should.

I also tried:
eval("\$errormessage .= eval(\"echo \\\"$$errortype\\\";\";"); and it
still didn't work.


Previous Comments:


[2003-02-06 17:30:53] [EMAIL PROTECTED]

CAUTION: The input field scrambled my input!

You have to use 
- 3 slashes where it shows 7
- 1 slash where it shows 3
- 0 slash where it shows 1



[2003-02-06 17:28:24] [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

You need to double evaluate.
$$errortype resolves to $invalid
evaluating resolves to the string containing $number.
That has to be evaluated as well.

Also why not use foreach and you can use eval()\'s
return value. See below:

$errortype) {
$errormessage .= eval(\"echo eval(\\\"echo
\\\"$$errortype\\\";\\\");\");
}

echo $errormessage;
?

Send further questions please [EMAIL PROTECTED]



[2003-02-06 16:43:28] [EMAIL PROTECTED]

$error["1231"] = "invalid";
$error["1255"] = "invalid_max";

$invalid = 'You did not choose a valid quantity for item number
$item.\n';
$invalid_min = 'You did not order the minimum amount for item
$item.\n';
$invalid_max = 'You ordered more than you were permitted for item
$item.\n';

while (list($item, $errortype) = each($error)) {
eval("\$errormessage .= \"$$errortype\";");
}

print $errormessage;

Eval prints the following:
You did not choose a valid quantity for item number $item.
You ordered more than you were permitted for item $item.

It should print this:
You did not choose a valid quantity for item number 1231.
You ordered more than you were permitted for item 1255.




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

#22110 [NEW]: ini_get ("memory_limit"); not working

[ek]

From: [EMAIL PROTECTED]
Operating system: freeBSD 4.7
PHP version:  4.3.0
PHP Bug Type: PHP options/info functions
Bug description:  ini_get ("memory_limit"); not working

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

#22097 [Com]: Eval fails to process this gem.

[tdrake]

 ID:   22097
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Linux x86 2.4.18
 PHP Version:  4.3.0
 New Comment:

meant to type:
eval("\$errormessage .= eval(\"echo \\\"$$errortype\\\";\");");
in the above example.


Previous Comments:


[2003-02-07 10:26:38] [EMAIL PROTECTED]

This doesn't work as expected.  ($errormessage never actually gets set
for some reason.)  But the double eval appears to work like it should.

I also tried:
eval("\$errormessage .= eval(\"echo \\\"$$errortype\\\";\";"); and it
still didn't work.



[2003-02-06 17:30:53] [EMAIL PROTECTED]

CAUTION: The input field scrambled my input!

You have to use 
- 3 slashes where it shows 7
- 1 slash where it shows 3
- 0 slash where it shows 1



[2003-02-06 17:28:24] [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

You need to double evaluate.
$$errortype resolves to $invalid
evaluating resolves to the string containing $number.
That has to be evaluated as well.

Also why not use foreach and you can use eval()\'s
return value. See below:

$errortype) {
$errormessage .= eval(\"echo eval(\\\"echo
\\\"$$errortype\\\";\\\");\");
}

echo $errormessage;
?

Send further questions please [EMAIL PROTECTED]



[2003-02-06 16:43:28] [EMAIL PROTECTED]

$error["1231"] = "invalid";
$error["1255"] = "invalid_max";

$invalid = 'You did not choose a valid quantity for item number
$item.\n';
$invalid_min = 'You did not order the minimum amount for item
$item.\n';
$invalid_max = 'You ordered more than you were permitted for item
$item.\n';

while (list($item, $errortype) = each($error)) {
eval("\$errormessage .= \"$$errortype\";");
}

print $errormessage;

Eval prints the following:
You did not choose a valid quantity for item number $item.
You ordered more than you were permitted for item $item.

It should print this:
You did not choose a valid quantity for item number 1231.
You ordered more than you were permitted for item 1255.




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

#22108 [Fbk]: php doesn't ignore the utf-8 BOM

[tularis]

 ID:   22108
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Output Control
 Operating System: windows 2000
 PHP Version:  4.2.3
 New Comment:

sniper,

imagine someone would want to echo some text in eg. French.
In that case, if you'd save it as ascii, you would get corrupted
output. So instead you'd have to save as utf-8. Which seems to cause
problems (or so [EMAIL PROTECTED] tells us)


Previous Comments:


[2003-02-07 08:58:21] [EMAIL PROTECTED]

And why an earth would you save PHP files in any other
format than ascii?




[2003-02-07 08:53:10] [EMAIL PROTECTED]

What is a BOM ?

Derick



[2003-02-07 08:46:36] [EMAIL PROTECTED]

Problem:
When a php file is saved in utf-8 format with the UTF-8 BOM as the
first three bytes of the file (EF BB BF), PHP doesn't ignore these
bytes when loading and compiling the file, but instead considers them
output coming prior to the http://bugs.php.net/?id=22108&edit=1

#22110 [Opn]: ini_get ("memory_limit"); not working

[philip]

 ID:   22110
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: PHP options/info functions
 Operating System: freeBSD 4.7
 PHP Version:  4.3.0
 New Comment:

Here's how I see it.  You must have used --enable-memory-limit to use
this directive at all so it essentially isn't being used so it returns
an empty string.  I believe this is intentional but ideally a php-dev
person will answer:

Why doesn't it return the default value?  Whether that be 8M or -1 (not
sure which it is :) ... when not compiled in.  An empty string seems
misleading.


Previous Comments:


[2003-02-07 10:29:28] [EMAIL PROTECTED]

ini_get ("memory_limit"); does not return anything.




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

#22103 [Opn]: imagefilledellipse() is incorrect with alpha blending

[ljpersson]

 ID:   22103
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: GD related
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

I had a look in the source in GD. 
The problem is the way the gdImageFilledArc() is implemented. 

The algorithm there is flawed for alpha-blending. It fills the arc by
drawing a series of filled polygons (triangles) centerd in the middle
of the ellipse and out to the edge of the ellipse with 1 degree
separation between the end points. This will make the interior points
overlap and create the moire pattern.

Unfortunately there isn't a simple solution to this. Doing a floodfill
to a specific color wan't work since we don't know the canvas we are
drawing on.

Since I'm doing a lot of graphic stuff I'll see if I can come up with a
new algorithm to do this. I'm afraid however that any correct algortihm
will be quite CPU expensive.


Previous Comments:


[2003-02-07 09:44:44] [EMAIL PROTECTED]

The problem still exist in snapshot 200302071430. 

I haven't had time to look at the GD code but this is most likely a
design flaw and not a straight bug. Fixing this will probably require a
new fill algorithm for ellipses that can guarantee that the same pixel
inside the ellipse will only be painted exactly one time.

The script below demonstrates this bug
and the resulting image can also be viewed at
http://www.aditus.nu/jpgraph/bbimages/filledellipsebug.png






[2003-02-07 06:36:22] [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 couple of fixes in GD in CVS.
If it still fails, please provide a short example script.




[2003-02-06 22:18:03] [EMAIL PROTECTED]

(Using built-in GD 2.x in PHP 4.3.0)

imagefilledellipse() creates moire' patterns inside the filled ellipse
when alpha blending is enabled.

The problem seems to be that the fill algorithm strokes the same point
within the ellipse several times and due to the alpha blending of
single pixels creates several color shades within the ellipse.

This is fine as long as a solid fill is used but does not work together
with alpha blending. 






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

#22104 [Fbk->Opn]: problem with adding value to multiplie dimensional arrays

[canholms]

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

you will see what i mean if you do following:



 array(1=>"one",2=>"two", 3=>"three"),
"1" => array(1=>"One",2=>"Two", 3=>"Three"),
);
var_dump($array);
foreach($array[0] as $key => $value)
{
$array[1][]=1;
}

var_dump($array);
?>


Previous Comments:


[2003-02-07 07:16:53] [EMAIL PROTECTED]

 I cannot simulate what you say. Here is script that I wrote to test.
Test with it. Please provide good feedback as well as an example code
(as small as possible please).


 array(1=>"one",2=>"two", 3=>"three"),
"1" => array(1=>"One",2=>"Two", 3=>"Three"),
);
var_dump($array);
foreach($array[0] as $key => $value)
{
$array[1]=1;
}

var_dump($array);
?>



[2003-02-07 01:04:09] [EMAIL PROTECTED]

foreach($array[0] as $key => $value)
{
$array[1]=1;
}

This will change the value on $array[0] too, i can't explain it more. I
tested with serialize and the value on the variable gets very
strange...




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

#22095 [Csd]: Won't configure correctly with libmcrypt enabled

[Nicolas . Ross]

 ID:   22095
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: *Configuration Issues
 Operating System: Mac OS X darwin
 PHP Version:  4.3.0
 New Comment:

Just a quick note, I took the config.m4 from ext/mcrypt/ of 4.2.3 and
copied it into 4.3.0 tree, ran buildconf and now I get :

/usr/bin/ld: Undefined symbols:
_mcrypt_module_entry
/usr/bin/ld: warning unused multiple definitions of symbol _regerror
/usr/local/apache/bin/httpd definition of _regerror
/usr/lib/libm.dylib(regerror.o) unused definition of _regerror
make: *** [libs/libphp4.bundle] Error 1

And that even with all gd/tiff/png removed...


Previous Comments:


[2003-02-06 14:40:16] [EMAIL PROTECTED]

Copy ext/mcrypt/config.m4 to the php-4.2.3 directory (in ext/mcrypt),
go to the php-4.2.3 directory and execute:
rm configure
rm config.cache
./buildconf

(and make sure you have autoconf 2.13)

then you can run configure with the options of your liking.

Derick



[2003-02-06 14:38:02] [EMAIL PROTECTED]

It works in deed. But I had to remove all gd/png/jpeg/zlib stuff
because of configure errors regarding png or zlib.

Is there a way to back-port the fix to distro php-4.3.0 ?



[2003-02-06 13:49:33] [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-02-06 13:35:23] [EMAIL PROTECTED]

On our Mac OS X (Darwin) server, I used to compile php with some twists
and tricks, but 4.2.3 configured and compiled correctly width mcrypt
enabled. Now I can't configure 4.3.0 with libmcrypt enabled.

Configure line :

./configure --with-apxs=/usr/local/apache/bin/apxs \
--with-mysql \
--with-fbsql \
--with-xml \
--enable-ftp \
--with-zlib \
--with-zlib-dir=../zlib \
--with-png \
--with-png-dir=../libpng-1.2.0 \
--with-jpeg \
--with-jpeg-dir=../jpeg-6b \
--with-gd \
--with-mcrypt \
--enable-track-vars \
--enable-trans-id

I get :

checking for mcrypt support... yes
checking for mcrypt_module_open in -lmcrypt... no
checking for init_mcrypt in -lmcrypt... no
configure: error: Sorry, I was not able to diagnose which libmcrypt
version you have installed.

Here's the tail of config.log
char init_mcrypt();

int main() {
init_mcrypt()
; return 0; }

This configure line works perfectly without the mcrypt part, and
results in a working php installation.

libmcrypt 2.5.5 is install in /usr/local and other php version (4.2.3)
configure and compile againts it successfully.

I tried every combinaison of

--with-mcrypt=../libmcrypt-2.5.5
--with-mcrypt=/usr/local

and so on.

So any hints ?




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

#15208 [Csd->Opn]: .phps file additional feature

[philip]

 ID:   15208
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Linux
 PHP Version:  4.1.1
 New Comment:

This was never implemented/committed.  Here's a thread:
http://marc.theaimsgroup.com/?l=php-dev&m=103239898231495

And here's a patch:
http://www.dapond.net/code/zend_highlight.patch



Previous Comments:


[2003-02-06 21:09:12] [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.

There is no ini settings, however as of PHP 4.3.0 you can passd a
string via GET that will enable the display of line numbers.



[2002-01-24 12:32:54] [EMAIL PROTECTED]

It would be very helpful if you had a php.ini directive like:

php_source_view_linenum = 0/1

 If it is set to '1', a .phps file would print the line number in front
of the colorized syntax. It's not a huge feature, but would be very
nice to help debug some code, or help others see the logic of code.




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

#14222 [Com]: PHP Crashes with weird output often

[m_s]

 ID:   14222
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Apache related
 Operating System: Windows XP Pro
 PHP Version:  4.1.1
 New Comment:

Apache -X worked for me as well. I'm using Apache 2.0.43 and PHP 4.3.0,
and without the -X switch it didn't work.

I got corrupted output (as described above), but there wasn't any
problems with small amounts of data. When a given query (to an Access
database) returned many results (about >70), the page reloaded several
times and either resulted in partially corrupted output or a 404.


Previous Comments:


[2002-07-24 02:43:38] [EMAIL PROTECTED]

i try Apache 1.3.26 and PHP 4.2.1
it's work fine :)



[2002-06-18 19:01:29] [EMAIL PROTECTED]

Try Apache 1.3.24 and PHP 4.2.1.
Reopen if problem persists.




[2002-03-21 07:07:37] [EMAIL PROTECTED]

Sounds like it is related to Bugs #15613 and #15245.
This really needs sorting out for PHP 4.2



[2002-03-21 04:56:34] [EMAIL PROTECTED]

no, you have found a workaround that hides the actual problem for now,
maybe due to reduced output buffer sizes ...



[2002-03-20 14:25:41] [EMAIL PROTECTED]

I have find a ""solution"" :
I have activates gzip compression (see php.ini) and it works.



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

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

#22111 [NEW]: URL rewriter and Javascript

[xanthor]

From: [EMAIL PROTECTED]
Operating system: All
PHP version:  4.3.0
PHP Bug Type: Session related
Bug description:  URL rewriter and Javascript

The URL rewriter for transparent session ID propagation read also the
javascripts and add PHPSESSID, sometimes with errors

For exemple :
If I write :





I obtain : 




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

#22102 [Opn]: Link fails with modified mysql path

[allen012]

 ID:   22102
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Solaris 8
 PHP Version:  4.3.0
 New Comment:

Exact output is:
ld: fatal: file /opt/sfw/mysql/lib/mysql/.libs/libmysqlclient.so: open
failed: No such file or directory
ld: fatal: File processing errors. No output written to
.libs/libphp4.so

Again, why is it lokking for the MySQL client library in ".libs" ?


Previous Comments:


[2003-02-06 21:15:54] [EMAIL PROTECTED]

Environment:  Gnu installation (GCC, MySQL, etc) from Solaris 8
Companion CD, Apache 2.0.44, PHP 4.3.0, MySQL 3.23
Apache compiled and runs fine in the environment.  

PHP:  ./configure --with-mysql=/opt/sfw/mysql
--with-apxs2=/usr/local/apache2/bin/apxs

PHP configure runs fine, and the build works up to link.  It then fails
with:
Cannot find /opt/sfw/mysql/lib/mysql/.lib/libmysqlclient.so

Where is the ".lib" coming from?  
The link also indicates that it has failed to create .lib/libphp4.so
Again - what gives with the ".lib"?




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

#22112 [NEW]: When Php compiled with support for openssl it broke the SIHUP of apache

[sysadmin]

From: [EMAIL PROTECTED]
Operating system: Linux Redhat 6.2
PHP version:  4.3.0
PHP Bug Type: Apache related
Bug description:  When Php compiled with support for openssl it broke the SIHUP of 
apache

Hi,

My setup :
Apache/1.3.27 (Unix) PHP/4.3.0 mod_ssl/2.8.12 OpenSSL/0.9.6g

PHP compiled without openssl or anyother app that need openssl compiled in
php
apachectl startssl
killall -1 httpd - Apache reload configuration and all is fine
killall -1 httpd - Apache reload configuration and all is fine
killall -1 httpd - Apache reload configuration and all is fine
killall -1 httpd - Apache reload configuration and all is fine
killall -1 httpd - Apache reload configuration and all is fine
killall -1 httpd - Apache reload configuration and all is fine
etc 
the httpd deamon reload is config and never die

PHP compiled with --with-openssl=/usr/local/ssl ( tested 4 time with
different delay between SIGHUP )
apachectl startssl
killall -1 httpd - Apache reload configuration and all is fine
killall -1 httpd - Apache reload configuration and all is fine
killall -1 httpd - Apache reload configuration and all is fine
killall -1 httpd - SIGHUP received.  Attempting to restart -- and apache
never restart

PHP compiled with --with-openssl=/usr/local/ssl --with-imap
--with-imap-ssl=/usr/local/ssl
apachectl startssl
killall -1 httpd - SIGHUP received.  Attempting to restart -- and apache
never restart
I can't even SIGHUP one time the http server

Ok i know that the bug is between apache-mod_ssl and php-openssl

But i would like to know how i can correct that problem.

Thanks in advance for any help.

Regards.



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

#22108 [Fbk->Bgs]: php doesn't ignore the utf-8 BOM

[helly]

 ID:   22108
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Bogus
 Bug Type: Output Control
 Operating System: windows 2000
 PHP Version:  4.2.3
 New Comment:

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

BOM = Byte Order Mark for UCS-2 encoding
This value sould not be used in UTF-8 since the only
reason besides detecting the byte order of UCS-2 was a 
special non breaking space. And newer Unicode versions 
have another representation for the same thing.

Anyhow BOM = FE FF
That makes depending on the byte order:
UCS-2BE <-> "\xFE\xFF"
UCS-2LE <-> "\xFF\xFE"

Therefore a sequence of "EF BB" is another character and 
must not be ignored.



Previous Comments:


[2003-02-07 10:42:16] [EMAIL PROTECTED]

sniper,

imagine someone would want to echo some text in eg. French.
In that case, if you'd save it as ascii, you would get corrupted
output. So instead you'd have to save as utf-8. Which seems to cause
problems (or so [EMAIL PROTECTED] tells us)



[2003-02-07 08:58:21] [EMAIL PROTECTED]

And why an earth would you save PHP files in any other
format than ascii?




[2003-02-07 08:53:10] [EMAIL PROTECTED]

What is a BOM ?

Derick



[2003-02-07 08:46:36] [EMAIL PROTECTED]

Problem:
When a php file is saved in utf-8 format with the UTF-8 BOM as the
first three bytes of the file (EF BB BF), PHP doesn't ignore these
bytes when loading and compiling the file, but instead considers them
output coming prior to the http://bugs.php.net/?id=22108&edit=1

#15208 [Opn]: .phps file additional feature

[philip]

 ID:   15208
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
-Operating System: Linux
+Operating System: all
-PHP Version:  4.1.1
+PHP Version:  5.0.0
-Assigned To:  
+Assigned To:  zeev
 New Comment:

To add.  That looong thread ends with this comment by Zeev as certain
conditions with that patch cause a segfault:

"I'll try to find some time to look at it.  I need to
re-familiarize myself with the output buffering code at 
some point anyway..."

So, I suppose this should be assigned to Zeev.  And it is, now.


Previous Comments:


[2003-02-07 11:59:42] [EMAIL PROTECTED]

This was never implemented/committed.  Here's a thread:
http://marc.theaimsgroup.com/?l=php-dev&m=103239898231495

And here's a patch:
http://www.dapond.net/code/zend_highlight.patch




[2003-02-06 21:09:12] [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.

There is no ini settings, however as of PHP 4.3.0 you can passd a
string via GET that will enable the display of line numbers.



[2002-01-24 12:32:54] [EMAIL PROTECTED]

It would be very helpful if you had a php.ini directive like:

php_source_view_linenum = 0/1

 If it is set to '1', a .phps file would print the line number in front
of the colorized syntax. It's not a huge feature, but would be very
nice to help debug some code, or help others see the logic of code.




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

#22109 [Opn]: With-flatfile compile option causes core dumps during make test

[helly]

 ID:   22109
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: DBM/DBA related
 Operating System: Solaris 2.7
 PHP Version:  4CVS-2003-02-07 (stable)
 New Comment:

Could you please send the outputs of "ldd php" and if
you used shared builds then the ldd output of any loaded
php module, too. And then i'd like to see the ouput of
"php -r 'print_r(dba_handlers(1));'" if you did not use 
a cvs version then you must omit the parameter "1".



Previous Comments:


[2003-02-07 09:01:33] [EMAIL PROTECTED]

Compiled with GCC 3.2.1 on Solaris 2.7 to work with Apache 2.0.40.
Apache compiled with same GCC.

Testing with CLI version in sapi/cli via make test.
The SISSEGV segmentation core dump occurs with the
"tests/func/005a.phpt" only when I include the --with-flatfile option
in the configure script, by itself or in combination with any other
option. Absent this flatfile setting, no core dump occurs.  I've
confirmed this with numerous clean, right from scratch reconfigures and
compiles.

Within the failing test, the register_shutdown_function() call works
ok.  It appears that the dump is being triggered when the time limit
set by set_time_limit() expires within the infinite for loop.  I varied
the time value to set_time_limit(), but still got the core dumps. 
Using GDB 4.1.18, I got this backtrace:

Program received signal SIGSEGV, Segmentation fault.
0xff165758 in aiosigcancelhndlr () from /usr/lib/libaio.so.1
(gdb) bt
#0  0xff165758 in aiosigcancelhndlr () from /usr/lib/libaio.so.1 #1 
0xfeffbdfc in __sighndlr () from /usr/lib/libthread.so.1 #2   
#3  execute (op_array=0x2890b0, tsrm_ls=0x1dbbd0)
at /opt/src/php/php4-STABLE-200302021630/Zend/zend_execute.c:1350
#4  0x1395fc in zend_execute_scripts (type=8, tsrm_ls=0x1dbbd0,
retval=0x0, 
file_count=3) at
/opt/src/php/php4-STABLE-200302021630/Zend/zend.c:864
#5  0x1078ac in php_execute_script (primary_file=0xffbef110,
tsrm_ls=0x1dbbd0)
at /opt/src/php/php4-STABLE-200302021630/main/main.c:1582
#6  0x14da14 in main (argc=2, argv=0xffbef19c)
at /opt/src/php/php4-STABLE-200302021630/sapi/cli/php_cli.c:753

Due to the infinite for loop in the failing test, subseqent core dumps
will backtrace differently depending on just where in the loop cycle
the dump occurs at.  Inother words, don't expect execute in frame 3 to
look the same from trace to trace. Though its a bit of a chameleon to
chase down, I'm still on the prowl to locate exact where this is
happening at.

---dave





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

#22114 [NEW]: @echo not working

[helly]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  5CVS-2003-02-07 (dev)
PHP Bug Type: Scripting Engine problem
Bug description:  @echo not working

One cannot use '@' to hide warnings inside 'echo'.

Example: 
[marcus@zaphod php-HEAD]$ php -r '@echo "<$x>";'
Command line code(1) : Parse error - parse error, unexpected T_ECHO
-- 
Edit bug report at http://bugs.php.net/?id=22114&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22114&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22114&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22114&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22114&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22114&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22114&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22114&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22114&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22114&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22114&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22114&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22114&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22114&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22114&r=gnused

#22114 [Opn->Bgs]: @echo not working

[derick]

 ID:  22114
 Updated by:  [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
-Status:  Open
+Status:  Bogus
 Bug Type:Scripting Engine problem
 PHP Version: 5CVS-2003-02-07 (dev)
 New Comment:

echo is not a function, but a language construct. Not a bug -> bogus.


Previous Comments:


[2003-02-07 14:57:35] [EMAIL PROTECTED]

One cannot use '@' to hide warnings inside 'echo'.

Example: 
[marcus@zaphod php-HEAD]$ php -r '@echo "<$x>";'
Command line code(1) : Parse error - parse error, unexpected T_ECHO




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

#22114 [Bgs]: @echo not working

[helly]

 ID:  22114
 Updated by:  [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
 Status:  Bogus
 Bug Type:Scripting Engine problem
 PHP Version: 5CVS-2003-02-07 (dev)
 New Comment:

I know of corse but shouldn't it be allowed for echo, too?


Previous Comments:


[2003-02-07 15:04:43] [EMAIL PROTECTED]

echo is not a function, but a language construct. Not a bug -> bogus.



[2003-02-07 14:57:35] [EMAIL PROTECTED]

One cannot use '@' to hide warnings inside 'echo'.

Example: 
[marcus@zaphod php-HEAD]$ php -r '@echo "<$x>";'
Command line code(1) : Parse error - parse error, unexpected T_ECHO




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

#22114 [Bgs]: @echo not working

[helly]

 ID:  22114
 Updated by:  [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
 Status:  Bogus
 Bug Type:Scripting Engine problem
 PHP Version: 5CVS-2003-02-07 (dev)
 New Comment:

The following patch *is* not the beautiful way to solve it but is shows
its working. Anyway it works when using print instead of echo which is
handled as an expression.

Index: Zend/zend_language_parser.y
===
RCS file: /repository/ZendEngine2/zend_language_parser.y,v
retrieving revision 1.86
diff -u -r1.86 zend_language_parser.y
--- Zend/zend_language_parser.y 1 Feb 2003 01:49:14 -   1.86
+++ Zend/zend_language_parser.y 7 Feb 2003 21:25:05 -
@@ -202,6 +202,7 @@
|   T_GLOBAL global_var_list ';'
|   T_STATIC static_var_list ';'
|   T_ECHO echo_expr_list ';'
+   |   '@' { zend_do_begin_silence(&$1 TSRMLS_CC); } T_ECHO
echo_expr_list ';' { zend_do_end_silence(&$1 TSRMLS_CC); $$ = $3; }
|   T_INLINE_HTML   { zend_do_echo(&$1
TSRMLS_CC); }
|   expr ';'{
zend_do_free(&$1 TSRMLS_CC); }
|   T_USE use_filename ';'  {
zend_error(E_COMPILE_ERROR,"use: Not yet supported. Please use
include_once() or require_once()");  zval_dtor(&$2.u.constant); }



Previous Comments:


[2003-02-07 15:08:43] [EMAIL PROTECTED]

I know of corse but shouldn't it be allowed for echo, too?



[2003-02-07 15:04:43] [EMAIL PROTECTED]

echo is not a function, but a language construct. Not a bug -> bogus.



[2003-02-07 14:57:35] [EMAIL PROTECTED]

One cannot use '@' to hide warnings inside 'echo'.

Example: 
[marcus@zaphod php-HEAD]$ php -r '@echo "<$x>";'
Command line code(1) : Parse error - parse error, unexpected T_ECHO




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

#20893 [Opn->Csd]: Strings as Arrays...

[iliaa]

 ID:   20893
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: All
 PHP Version:  4.3.0RC2
 New Comment:

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php

In PHP there will be a function, str_split(), this function can be used
to break down a string into an array, allowing you to quickly traverse
the said array and apply any mods on it.


Previous Comments:


[2002-12-08 20:57:52] [EMAIL PROTECTED]

small code correction:

$string = "foo";
foreach ($string as $i) {
  echo $i ."\n";
}



[2002-12-08 20:56:13] [EMAIL PROTECTED]

This is probably a strange feature request, but I think it should be
given a lot of thought, if it has not done so already.

The request is this:

strings should be treated as arrays of characters (which they are) when
given as the arguement for functions which work on arrays.

so for example:
function foo ($chr) {
  echo $chr . "\n";
}
$string = "bar";
array_walk($string,foo); would give the result:
b
a
r

Also, to be able to do this with strings:

$string = "fo";
$string{} = "o";
so that
$string == "foo" == TRUE

Also, another thing that comes up often, is when trying to do this:

$string = "foo";
foreach ($string as $i) {
  echo $string ."\n";
}

does not work, and you have to do:

$string = "foo";
for($i = 0;$i <= strlen($string);$i++) {
  echo $string{$i} ."\n";
}

like I said, give this some thought, perhaps toss it around on php-dev
etc..

- Davey




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

#21261 [Com]: $_SERVER['PHP_SELF'] gives wrong info

[russ]

 ID:   21261
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: linux 2.4.18 - slack 8.1
 PHP Version:  4.3.0
 Assigned To:  shane
 New Comment:

Tilde expansion in URL has same problem on Solaris.

I was able to use the provided workaround:
$_SERVER['SCRIPT_NAME'] =
substr($_SERVER['PATH_TRANSLATED'],
   strlen($_SERVER['DOCUMENT_ROOT']));
if (substr($_SERVER['SCRIPT_NAME'], 0, 2) == '//') {
   $_SERVER['SCRIPT_NAME'] =
substr($_SERVER['SCRIPT_NAME'], 1);
}
to fix the same problem (invalid PHP_SELF) on Solaris 2.7
Sparc, PHP 4.3.0 (fresh).

Simply doing phpinfo(); and then appending the value of
PHP_SELF onto an 'ls ' statement yielded "no such file".

The file did not exist:
$ ls /~russ/tryseed/showSeed.phtml
/~russ/tryseed/showSeed.phtml: No such file or directory

What I can contribute here is this: I was running out
of a "pubic_html" subdirectory off of ~russ (above), and 
the URL typed into IE 5.2 (Mac OS X) was:

"http://hostname/~russ/tryseed/showSeed.html";

--Thank you to whoever came up with that workaround above.


Previous Comments:


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

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

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

This is now fixed in cvs:
4.3: http://cvs.php.net/co.php/php4/sapi/cgi/cgi_main.c?r=1.190.2.12
5.0: http://cvs.php.net/co.php/php4/sapi/cgi/cgi_main.c?r=1.208



[2003-01-17 06:36:29] [EMAIL PROTECTED]

Sorry, my PHP-Based Workaround seems to be buggy in some cases, too...
Here is a quick & dirty bugfix for the quick & dirty workaround :-)

Btw, it would be nice if the bug is fixed in PHP 4.3.1...

-snip
// Small Workaround for a bug in PHP 4.3.0/cgi
// See http://bugs.php.net/bug.php?id=21261 for details

$_SERVER['SCRIPT_NAME'] = substr($_SERVER['PATH_TRANSLATED'],
 strlen($_SERVER['DOCUMENT_ROOT']));
if (substr($_SERVER['SCRIPT_NAME'], 0, 2) == '//') {
$_SERVER['SCRIPT_NAME'] = substr($_SERVER['SCRIPT_NAME'], 1);
}

$PHP_SELF =
$SCRIPT_NAME =
$_SERVER['PHP_SELF'] =
$_SERVER['SCRIPT_NAME'];
-snip



[2003-01-13 11:41:12] [EMAIL PROTECTED]

That (or similar) urgent problem occurs here too. PHP versions before
mid december were not affected IMO.

At first today I've checked out the "php4" and "php5" modules from CVS,
configured, and build them. After installation of the CGI binaries I
detected a problem with $_SERVER['PHP_SELF']:

a) the PHP4 version shows "no value"
b) the PHP5 version shows illegal characters, cut off strings with low
ASCII values etc. Depending on the namebased vhost name the value of
PHP_SELF looks like "ind##" instead of "index.php" ("#" should
represent low ASCII chars, which are shown as boxes here) of just "5"
which is definitely the last char of "index.php5". Short: looks like a
pointer on a string array is bent somewhere.

The problem insist with and without '--enable-force-cgi-redirect' in
both versions. As an example you may want to take a look at

  http://daniel-gorski.de/index.php4  (PHP4 CGI)
  http://daniel-gorski.de/index.php5  (PHP5 CGI)

and compare the values of $_SERVER['PHP_SELF']. Additionally the PHP5
version has a strange "Zend Extension" date: 90021012. OTOH this value
seems to be correct in the PHP4 version.

The operating system is Linux (RedHat 6.2).

I would appreciate to see this bug solved as soon as possible, because
this is a dramatic show stopper for a few ZE2 applications I am
developing & running.

What required information can I provide to help to solve this problem?

regards dtg



[2003-01-09 14:57:05] [EMAIL PROTECTED]

Quick & Dirty PHP-Based workaround:

Put this code in a file and add it to auto_prepend_file-directive in
php.ini:
-snip
// Small Workaround for a bug in PHP 4.3.0/cgi
// See http://bugs.php.net/bug.php?id=21261 for details

$_SERVER['SCRIPT_NAME'] = substr($_SERVER['PATH_TRANSLATED'],
 strlen($_SERVER['DOCUMENT_ROOT']));

$PHP_SELF =
$SCRIPT_NA

#22116 [NEW]: PHP_SELF gives wrong info

[russ]

From: [EMAIL PROTECTED]
Operating system: Solaris 2.7 sparc
PHP version:  4.3.0
PHP Bug Type: Variables related
Bug description:  PHP_SELF gives wrong info

I was able to use this workaround:
$_SERVER['SCRIPT_NAME'] =
substr($_SERVER['PATH_TRANSLATED'],
   strlen($_SERVER['DOCUMENT_ROOT']));
if (substr($_SERVER['SCRIPT_NAME'], 0, 2) == '//') {
   $_SERVER['SCRIPT_NAME'] =
substr($_SERVER['SCRIPT_NAME'], 1);
}
to fix an invalid PHP_SELF on Solaris 2.7
Sparc, PHP 4.3.0 .

Simply doing phpinfo(); and then appending the value of
PHP_SELF onto an 'ls ' statement yielded "no such file".

The file did not exist:

$ ls /~russ/tryseed/showSeed.phtml
/~russ/tryseed/showSeed.phtml: No such file or directory

The clue here is this: I was running out
of a "pubic_html" subdirectory off of ~russ (see above).
The URL typed into IE 5.2 (Mac OS X) was:

"http://hostname/~russ/tryseed/showSeed.html";

** I have other pages on same web server, same PHP which
are hosted out of the server's normal root directory
and they don't have this problem. **

--Thank you to whoever came up with that workaround above.
I just put similar text as a COMMENT on a CLOSED linux 
Bug #21261.  This needs to be considered OPEN AFAIK.


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

#21540 [Com]: include_path problem

[georgep]

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

Hello,

Using linux and the php 4.3.0 causes the same problems. For some reason
php seems to ingore the path_info set in php.ini.


Previous Comments:


[2003-01-31 13:47:00] [EMAIL PROTECTED]

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





[2003-01-15 03:08:25] [EMAIL PROTECTED]

But your include_path definition is different than the one
mentioned in the error message..are you sure your php.ini
is used by PHP ?




[2003-01-12 06:13:01] [EMAIL PROTECTED]

Yes, I have the following line in php.ini

include_path=   .:./:/usr/local/src/php-4.1.1/php-4.1.1/pear



[2003-01-10 16:37:59] [EMAIL PROTECTED]

Do you have include_path specified in your php.ini?



[2003-01-10 01:53:50] [EMAIL PROTECTED]

I'm running Apache 1.3.27. I tried include_path both in httpd.conf and
.htaccess. Problem existed in both cases.



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

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

#21306 [Com]: warnning about "cannot change the session settings"

[rob]

 ID:   21306
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Session related
 Operating System: linux
 PHP Version:  4.3.0
 New Comment:

This appears (in our case anyway) to be triggered by the use of an
"exit" statement in the session_set_save_handler session_write
function.  We had a benign error in our custom session_write function
(caused by the session data not changing when it was writing out)..
this caused an error message to be written to a log file, and then the
"exit;" statement.  In PHP 4.2, this exit apparently caused no problems
but now it generates this seemingly unrelated error message.

Incidently, because this message is generated at the time of
session_write (rather than during actual content generation) it also
caused an interaction with ob_gzhandler (gzip compression) such that
blank pages were being served up.. we had to disable ob_gzhandler to
even see the "A session is active..." messages..  This seems buggy to
me.


Previous Comments:


[2003-01-27 20:12:46] [EMAIL PROTECTED]

I upgraded to 4.3.0 from 4.2.3 a couple weeks ago.  I did not see this
problem at all until today, when I uploaded two minor changes to my web
site.  We get several hundred thousand page views per day, and since
this upload we're getting 3-4 of this error per minute.  So for most
page views it doesn't happen, but it's definitely happening frequently
and regularly.

The first change was to our error handler.  We specifically trigger
errors using $php_errormsg if it exists (after the session is started),
so that we can catch stupid users who try to upload humongous images to
our site (we limit them to 40KB).  Some bright young individual
uploaded a 476MB file ten times this morning, so we added some code
(three lines) to log the date, time, username, and file size.  Here is
the code we added:

$fp = fopen("/tmp/big_images.log", 'a');
fwrite($fp, sprintf("%s: %s (%s KB)\n", date("Y-m-d H:i:s"),
$_SESSION['auth']->auth['username'], $kb));
fclose($fp);

While typing this, I made a change which seems to have fixed the
problem.  I have a function called session_setup() which makes sure the
session id is unique, and call session_set_save_handler() or whatever
the name of that function is.  The trigger_error mentioned above used
to be called after calling session_setup() in my authentication include
file.  I moved it to inside the session_setup() function, after setting
the save_handler.  For some reason, this fixed the problem.

Odd.

Perhaps this can help someone else somehow?



[2003-01-05 16:03:24] [EMAIL PROTECTED]

Have a working installation of os-commerce in 4.2.3. Upgraded to 4.3.0,
and now I get the same error listed here.

All I want to do is confirm that this is NOT a script error. I'm not
going to dig through some code I didn't write to track this down.

Thanks



[2003-01-01 10:11:39] [EMAIL PROTECTED]

note that, i don't even use one ini_set()
and the script is impossible to session_set_save_handler() twice;

seems php don't re-initize correctly, same as
http://bugs.php.net/bug.php?id=19292
but i'm just guessing



[2002-12-31 02:52:19] [EMAIL PROTECTED]

i forgot to note that, this issue is random happend
i can't reproduce it, but my user trigger it and i saw errors in log
and my script is in production, it's too complex
i am not able to give full script
but my function look like:
function mysessionstart() {
if (session_id()) return
session_set_save_handler(
'_sess_open',
'_sess_close',
'_sess_read',
'_sess_write',
'_sess_destroy',
'_sess_gc'
);
session_start();
}
it works fine until get warnning in php-4.3.0

here the config is:
session.save_handler = files
session.save_path = /tmp
session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.serialize_handler = php
session.gc_probability = 1
session.gc_maxlifetime = 1440
containing ids.
session.referer_check =
session.entropy_length = 0
session.entropy_file =
;session.entropy_length = 16
;session.entropy_file = /dev/urandom
session.cache_limiter = nocache

session.cache_expire = 180

session.use_trans_sid = 1
url_rewriter.tags =
"a=href,area=href,frame=src,input=src,form=fakeentry"



[2002-12-31 02:27:43] [EMAIL PROTECTED]

THis is most likely not a bug, can you show us the script, and the
session.* settings in php.ini?

Derick



The remainder of the comments 

#22117 [NEW]: Session vars inappropriately created as references

[phpbugs]

From: [EMAIL PROTECTED]
Operating system: Win NT 4
PHP version:  4.3.0
PHP Bug Type: Session related
Bug description:  Session vars inappropriately created as references

It took me a while to track this down...
we noticed that when we upgraded a develpment box
from 4.2.3 to 4.3.0, that one of our session vars
was being over-written by another.

It turns out that one was being serialized 
to the session as a reference to the other,
but only if the vars were intialized like this:

 $var1 = $var2 = "some value";

Consider two scripts, test_bug1.php and test_bug2.php

If you run test_bug1, and then test_bug2, surprisingly,
the output of test_bug2 will be:

BEFORE:
var1 = 'INITIALIZED'
var2 = 'INITIALIZED'

AFTER:
var1 = 'CHANGED'
var2 = 'CHANGED'

\n";
echo "var1 = '$var1'";
echo "var2 = '$var2'";

echo "test_bug2.php";

?>

\n";
echo "var1 = '$var1'\n";
echo "var2 = '$var2'\n";

$var2 = "CHANGED";

echo "AFTER:\n";
echo "var1 = '$var1'\n";
echo "var2 = '$var2'\n";

$var2 = "EXIT";

?>


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

#21973 [Com]: 'configure' script can't find libpng.(a|so), openldap...

[colin . madere]

 ID:   21973
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: *Configuration Issues
 Operating System: Solaris 8
 PHP Version:  4.3.0
 New Comment:

I've run into a similar problem with --with-java switch.

Assuming $PHP_JAVA is set to "/usr/java" with the --with-java=/usr/java
switch...

The "libjava.so" library is looked for in $PHP_JAVA/lib/ but the file
is not there (j2se 1.4.1_01).

This may however be a different/new bug, since the file being looked
for by configure isn't even in that part of the java tree.  It resides
in:

$PHP_JAVA/jre/lib/sparc/
and
$PHP_JAVA/jre/lib/sparcv9/

The rest of the files looked for by configure are found by using:
--with-java=/usr/java

For it to find this library file, even if there weren't separate
architectures, it would have to be:
--with-java=/usr/java/jre

which would make it so the other java files looked for are not found.

Off to sym-link...


Previous Comments:


[2003-02-04 11:52:45] [EMAIL PROTECTED]

Yes, you have to install libpng if you don't have it. The download URL
is in the manual, .



[2003-02-04 06:23:30] [EMAIL PROTECTED]

Hello there,

I'm having a similar problem as this one. I'm using a Sun Cobalt Qube 3
server on which I try to install PHP 4.3
I have searched for libpng on the harddisk but can't find it anywhere.
So how can I install GD when I don't have libpng on the server ??

Do I have to install libpng first, if yes then where can I get it?? I
guess this is the only problem I'm having right now, first I had a
problem because the qube requires php 4.0.6. for it's admin
functionality, but I managed to create a workaround for that problem.
When I finally have installed php 4.3 I can write a how-to so other
Qube users can update their php too. Sun doesn't support updating PHP
on a Qube just because they don't want to.



[2003-02-02 18:50:10] [EMAIL PROTECTED]

Back to dba:

I tried several combinations and having problems with
shared dba earlier than 3.3. I did some fixes and 
disallowed buildng shared dba with those versions for now.
However i got a short reply from sleepycat that they do
not have any idea how to explain what is happening.

Back to general linking:
I made a configure function which allows me to
handle all libraries required by gd and dba extension.
Since those are the most complicated cases i suppose we
could easily expand that function to handle all external
libraries. If that is done we may even add automatic
detection support for your directory structure.
I will post that function here and as a diff on php-dev
during the week 



[2003-02-01 01:08:15] [EMAIL PROTECTED]

> Anyway, in what version of PHP did LDAP configure
> work without any patches? 

The CVS tag is php_4_3_0pre2. I've done a fresh checkout
with that tag and can verify that the 'configure' script
generated by my copies of autoconf, etc, works. I tried
the following successful combinations:

 - autoconf 2.52, automake 1.5, libtool 1.4
 - autoconf 2.57, automake 1.7.2, libtool 1.4.3
 - flex 2.5.4 and bison 1.75 were used in all cases.

Compiler was gcc 3.2.1 for Sun UltraSPARC v9 using
Sun's CCS assembler Sun's CCS linker (typical scenario).

Notes:
 - first, I applied my int/long correctness patches
   (fortunately, these do not influence the configure step).
 - ldap configures and compiles with no warnings or
   errors. BUT I have to induce -lldap myself (other modules,
   such as database modules, seem to pick up their libraries
   okay, though). So really, ldap configuration wasn't
   entirely working in pre2 but the fault had a different
   manifestation than in the release, and had obvious
   output/cause/workaround.
 - the gd module configures with errors but I commented out
   the 'exit' commands and configure completes.
 - the ldap and gd modules then appear work fine with Apache.
 - I had to comment out _LT_AC_TRY_DLOPEN_SELF when using
   the second lot of auto tools.

But when I do a buildconf, configure, make with php_4_3_0, I
get the problem "Cannot find ldap libraries in $LDAP_LIBDIR."

Notes:
 - first, I applied my int/long correctness patches
   (fortunately, these do not influence the configure step).
 - I can work around the gd & ldap problems by manually
   deleting the 'exit' commands in the configure
   script or inserting the sparcv9 path element into the
   configure script, in which case the ldap module then
   picks up -lldap by itself.
 - the _LT_AC_TRY_DLOPEN_SELF problem has disappeared
   in 4.3.0 release.
 - the ldap and gd modules

#21551 [NoF->Opn]: is_readable() & is_writable() returns wrong values on related pathes

[xdl]

 ID:   21551
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   No Feedback
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: SuSe Linux 7.2
 PHP Version:  4.2.3
 New Comment:

Yes, in PHP 4.3.0 the bug is fixed.
Thank you!
-

-
$ whoami
nobody

$ pwd
/usr/local/httpd/web/phpbt

$ ls -ld attachments
drwxrwxrwx4 nobody   nogroup  4096 Feb  8 03:43 attachments

PHP version = 4.3.0
getcwd() = /usr/local/httpd/web/phpbt
attachments is writable.
attachments is readable.
attachments/test is writable.
attachments/test is readable.
/usr/local/httpd/web/phpbt/attachments is writable.
/usr/local/httpd/web/phpbt/attachments is readable.
-


Previous Comments:


[2003-01-27 22:39:29] [EMAIL PROTECTED]

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





[2003-01-09 19:00:47] [EMAIL PROTECTED]

First of all, update to PHP 4.3.0. Then if this still
misbehaves, try adding 'echo getcwd();' in your script to see what PHP
thinks the current working directory is.




[2003-01-09 10:26:45] [EMAIL PROTECTED]

$f is writable.\n";
} else {
echo "$f is NOT writable.\n";
}

if(is_readable($f)) {
echo "$f is readable.\n";
} else {
echo "$f is NOT readable.\n";
}
}

$dir = "attachments";

s("whoami");
s("pwd");
s("ls -ld $dir");

wr($dir);

$dir2 = "$dir/test";
mkdir("$dir2");

wr($dir2);

//$dir3 = `pwd`;
$dir3 = $DOCUMENT_ROOT . "/phpbt/" . $dir;

wr($dir3);

?>

Output is:
--
$ whoami
nobody

$ pwd
/usr/local/httpd/web/phpbt

$ ls -ld attachments
drwxrwxrwx4 nobody   nogroup  4096 Jan  9 18:50 attachments

attachments is NOT writable.
attachments is NOT readable.
attachments/test is NOT writable.
attachments/test is NOT readable.
/usr/local/httpd/web/phpbt/attachments is writable.
/usr/local/httpd/web/phpbt/attachments is readable.
--



[2003-01-09 10:21:25] [EMAIL PROTECTED]

$f is writable.\n";
} else {
echo "$f is NOT writable.\n";
}

if(is_readable($f)) {
echo "$f is readable.\n";
} else {
echo "$f is NOT readable.\n";
}
}

$dir = "attachments";

s("whoami");
s("pwd");
s("ls -ld $dir");

wr($dir);

$dir2 = "$dir/test";
mkdir("$dir2");

wr($dir2);

//$dir3 = `pwd`;
$dir3 = $DOCUMENT_ROOT . "/phpbt/" . $dir;

wr($dir3);

?>

Output is:
--
$ whoami
nobody

$ pwd
/usr/local/httpd/web/phpbt

$ ls -ld attachments
drwxrwxrwx4 nobody   nogroup  4096 Jan  9 18:50 attachments

attachments is NOT writable.
attachments is NOT readable.
attachments/test is NOT writable.
attachments/test is NOT readable.
/usr/local/httpd/web/phpbt/attachments is writable.
/usr/local/httpd/web/phpbt/attachments is readable.
--




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

#18648 [Com]: Single entry form POST gives incorrect variable content

[j-blion]

 ID:   18648
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Apache2 related
 Operating System: All
 PHP Version:  5CVS-2003-01-29 (dev) / 4CVS-20020121 (stable)
 New Comment:

Apache 2.0.44 / PHP 4.3.1-dev (php4-STABLE-200302071830)

No more problem.
Neither sessions, neither forms

Good job !


Previous Comments:


[2003-02-06 03:57:54] [EMAIL PROTECTED]

That's it.



[2003-02-04 20:49:40] [EMAIL PROTECTED]

Thanks... It works ok.



[2003-02-04 15:05:45] [EMAIL PROTECTED]

[To anyone who experiences this trouble]

Are you sure that your httpd.conf has just A SINGLE KIND OF PHP RELATED
DIRECTIVE?

Then try grep "\(OutputFilter\|InputFilter\|AddType\)" < httpd.conf or
whatsoever.

# bad example (a)
AddInputFilter PHP php
AddOutputFilter PHP php

...

AddType x-httpd-php .php

# bad example (b)
SetInputFilter PHP
SetOutputFilter PHP

...

AddType x-httpd-php .php

# not bad (c)
AddInputFilter PHP php
AddOutputFilter PHP php

# good (d)
AddType x-httpd-php .php




[2003-02-04 09:16:42] [EMAIL PROTECTED]

Tested in RH8.0 + PHP 4.2.2 + Apache 2.

- Is ok when you add the 'enctype="multipart/form-data"' propety to the
form tag.
- Is ok when you send using GET method instead POST.
- Is ok when you send more than one field: if you have a text and a
button, if you send it pressing enter only the text send and the
problem occurs. When you press the button, text and button are send and
the problem not occur.
ciao.



[2003-02-03 12:36:09] [EMAIL PROTECTED]

I can _NOT_ reproduce this with Apache 2.0.44 and PHP 4.3.1-dev..




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

#14820 [Opn->Bgs]: GD: ImageColorLeastUsed

[iliaa]

 ID:   14820
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: Any
 PHP Version:  4.1.1
 New Comment:

To implement such a function would require PHP to go through every
single pixel of the image, which would be tremendously slow. There is
just no practical way to implement this feature, sorry.


Previous Comments:


[2002-06-28 05:42:59] [EMAIL PROTECTED]

reclassified.



[2002-01-03 04:05:32] [EMAIL PROTECTED]

ImageColorResolve et al are really cool, but SOMETIMES you 
*need* the color you want, and they just won't cut it.

So you want to deallocate the least-used color, and then 
allocate the one you really want.

Alas, the only way to do that (as far as I can figger) is 
this:

$colorcount = array();
for ($x = 0; $x < $width; $x++){
for ($y = 0; $y < $height; $y++){
$colorindex = imagecolorat($jpg, $x, $y);
if (!isset($colorcount[$colorindex])){
$colorcount[$colorindex] = 1;
}
else{
$colorcount[$colorindex]++;
}
}
}
asort($colorcount);
reset($colorcount);

$black = imagecolorexact($jpg, 0, 0, 0);
if ($black == -1){
$goner = key($colorcount);
$rgb = imagecolorsforindex($jpg, $goner);
#error_log("Need black: About to kill $goner ($rgb[red], 
$rgb[green], $rgb[blue]) which was only used in 
$colorcount[$goner] pixels", 0);
unset($colorcount[$goner]);
imagecolordeallocate($jpg, $goner);
$black = imagecolorallocate($jpg, 0, 0, 0);
}
if ($black == -1){
$black = imagecolorresolve($jpg, 0, 0, 0);
#error_log("Damn!  STILL couldn't allocate the color!", 
0);
}


Ugly, ain't it :-)

Anyway, if GD has any internal structures of a histogram 
nature, that one could use for a function matching this 
documentation:

int ImageColorLeastUsed(int img)
Returns a color index of the least-used color in the image.
Suitable for ImageDeallocate() when you really need a color 
that is not in the image.

Also handy would be something like:
array ImageColorMostContrasty(int img)
Returns an a array of 'red', 'green', 'blue' at a maxium 
distance from all other colors currently in the image.

I have no clue which color-distance algorithm I would 
actually want here.  But it would be nice for adding 
overlays to existing images that come from a random source.

If you want some idea of what I'm talking about:
http://chatmusic.com/maplocater.htm

The latitude/longitude lines and the red circles are being 
pulled from a database and overlaid in real-time.  However, 
somebody might upload a map with lots of red and black in 
it, and then I've got un-usable images.





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

#22105 [Opn->Fbk]: mkdir changes the variable passed to it

[iliaa]

 ID:   22105
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Directory function related
 Operating System: Linux
 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-02-07 04:39:47] [EMAIL PROTECTED]

$tmp = "xx/yy";

$parts = explode("/",$tmp);

for($i=0;$i';
@mkdir($directory,0775);
echo 'after :: ' . $directory . '';
}

outputs:
before :: files/xx
after :: files/xx
before :: files/xx/yy
after :: files/xxyy

The last line has the error.
As you can see mkdir() changes the variable.
Even if the rest of the code is buggy ( ;) )
this shouldn't happen :)

 - bram




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

#21551 [Opn->Csd]: is_readable() & is_writable() returns wrong values on related pathes

[magnus]

 ID:   21551
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Filesystem function related
 Operating System: SuSe Linux 7.2
 PHP Version:  4.2.3
 New Comment:

User reports the problem is fixed in release 4.3.0. 


Previous Comments:


[2003-02-07 18:55:59] [EMAIL PROTECTED]

Yes, in PHP 4.3.0 the bug is fixed.
Thank you!
-

-
$ whoami
nobody

$ pwd
/usr/local/httpd/web/phpbt

$ ls -ld attachments
drwxrwxrwx4 nobody   nogroup  4096 Feb  8 03:43 attachments

PHP version = 4.3.0
getcwd() = /usr/local/httpd/web/phpbt
attachments is writable.
attachments is readable.
attachments/test is writable.
attachments/test is readable.
/usr/local/httpd/web/phpbt/attachments is writable.
/usr/local/httpd/web/phpbt/attachments is readable.
-



[2003-01-27 22:39:29] [EMAIL PROTECTED]

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





[2003-01-09 19:00:47] [EMAIL PROTECTED]

First of all, update to PHP 4.3.0. Then if this still
misbehaves, try adding 'echo getcwd();' in your script to see what PHP
thinks the current working directory is.




[2003-01-09 10:26:45] [EMAIL PROTECTED]

$f is writable.\n";
} else {
echo "$f is NOT writable.\n";
}

if(is_readable($f)) {
echo "$f is readable.\n";
} else {
echo "$f is NOT readable.\n";
}
}

$dir = "attachments";

s("whoami");
s("pwd");
s("ls -ld $dir");

wr($dir);

$dir2 = "$dir/test";
mkdir("$dir2");

wr($dir2);

//$dir3 = `pwd`;
$dir3 = $DOCUMENT_ROOT . "/phpbt/" . $dir;

wr($dir3);

?>

Output is:
--
$ whoami
nobody

$ pwd
/usr/local/httpd/web/phpbt

$ ls -ld attachments
drwxrwxrwx4 nobody   nogroup  4096 Jan  9 18:50 attachments

attachments is NOT writable.
attachments is NOT readable.
attachments/test is NOT writable.
attachments/test is NOT readable.
/usr/local/httpd/web/phpbt/attachments is writable.
/usr/local/httpd/web/phpbt/attachments is readable.
--



[2003-01-09 10:21:25] [EMAIL PROTECTED]

$f is writable.\n";
} else {
echo "$f is NOT writable.\n";
}

if(is_readable($f)) {
echo "$f is readable.\n";
} else {
echo "$f is NOT readable.\n";
}
}

$dir = "attachments";

s("whoami");
s("pwd");
s("ls -ld $dir");

wr($dir);

$dir2 = "$dir/test";
mkdir("$dir2");

wr($dir2);

//$dir3 = `pwd`;
$dir3 = $DOCUMENT_ROOT . "/phpbt/" . $dir;

wr($dir3);

?>

Output is:
--
$ whoami
nobody

$ pwd
/usr/local/httpd/web/phpbt

$ ls -ld attachments
drwxrwxrwx4 nobody   nogroup  4096 Jan  9 18:50 attachments

attachments is NOT writable.
attachments is NOT readable.
attachments/test is NOT writable.
attachments/test is NOT readable.
/usr/local/httpd/web/phpbt/attachments is writable.
/usr/local/httpd/web/phpbt/attachments is readable.
--




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

#22109 [Com]: With-flatfile compile option causes core dumps during make test

[dwkoehler]

 ID:   22109
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: DBM/DBA related
 Operating System: Solaris 2.7
 PHP Version:  4CVS-2003-02-07 (stable)
 New Comment:

Here is the ldd output you asked for:

libcrypt_i.so.1 =>   /usr/lib/libcrypt_i.so.1
libresolv.so.2 =>/usr/lib/libresolv.so.2
libm.so.1 => /usr/lib/libm.so.1
libdl.so.1 =>/usr/lib/libdl.so.1
libnsl.so.1 =>   /usr/lib/libnsl.so.1
libsocket.so.1 =>/usr/lib/libsocket.so.1
libpthread.so.1 =>   /usr/lib/libpthread.so.1
libc.so.1 => /usr/lib/libc.so.1
libgen.so.1 =>   /usr/lib/libgen.so.1
libmp.so.2 =>/usr/lib/libmp.so.2
libthread.so.1 =>/usr/lib/libthread.so.1
/usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1

I tried to run your print_r( dba_handlers() ) but I got an undefined
function error.  That only shows up in the code with the --enable-dba
option, an option not used in my configure script.  I included it, then
re-configured and did a full re-compile.  Still had the core dump
afterwards.

The output from the print_r command is:

Array
( [flatfile] => 1.0, $Revision: 1.5.2.3 $ ) )

Side question:  is there a configure reference or rule that states if
one option is present, these other options should be as well.  As in
the above, is the enable-dba option required in the presence of the
--with-dbXX or --with-flatfile options. Without the --enable-dba
present, I saw the message "checking whether DBA interface is
enabled=yes" in the config output.  This led me to believe that DBA was
enabled.  That was not the case based on your email and the subsequent
config output "checking whether DBA is enabled=yes" showed up right
before the earlier mentioned one.  I'm new to PHP so this seems
ambiguous to me!


Previous Comments:


[2003-02-07 14:03:25] [EMAIL PROTECTED]

Could you please send the outputs of "ldd php" and if
you used shared builds then the ldd output of any loaded
php module, too. And then i'd like to see the ouput of
"php -r 'print_r(dba_handlers(1));'" if you did not use 
a cvs version then you must omit the parameter "1".




[2003-02-07 09:01:33] [EMAIL PROTECTED]

Compiled with GCC 3.2.1 on Solaris 2.7 to work with Apache 2.0.40.
Apache compiled with same GCC.

Testing with CLI version in sapi/cli via make test.
The SISSEGV segmentation core dump occurs with the
"tests/func/005a.phpt" only when I include the --with-flatfile option
in the configure script, by itself or in combination with any other
option. Absent this flatfile setting, no core dump occurs.  I've
confirmed this with numerous clean, right from scratch reconfigures and
compiles.

Within the failing test, the register_shutdown_function() call works
ok.  It appears that the dump is being triggered when the time limit
set by set_time_limit() expires within the infinite for loop.  I varied
the time value to set_time_limit(), but still got the core dumps. 
Using GDB 4.1.18, I got this backtrace:

Program received signal SIGSEGV, Segmentation fault.
0xff165758 in aiosigcancelhndlr () from /usr/lib/libaio.so.1
(gdb) bt
#0  0xff165758 in aiosigcancelhndlr () from /usr/lib/libaio.so.1 #1 
0xfeffbdfc in __sighndlr () from /usr/lib/libthread.so.1 #2   
#3  execute (op_array=0x2890b0, tsrm_ls=0x1dbbd0)
at /opt/src/php/php4-STABLE-200302021630/Zend/zend_execute.c:1350
#4  0x1395fc in zend_execute_scripts (type=8, tsrm_ls=0x1dbbd0,
retval=0x0, 
file_count=3) at
/opt/src/php/php4-STABLE-200302021630/Zend/zend.c:864
#5  0x1078ac in php_execute_script (primary_file=0xffbef110,
tsrm_ls=0x1dbbd0)
at /opt/src/php/php4-STABLE-200302021630/main/main.c:1582
#6  0x14da14 in main (argc=2, argv=0xffbef19c)
at /opt/src/php/php4-STABLE-200302021630/sapi/cli/php_cli.c:753

Due to the infinite for loop in the failing test, subseqent core dumps
will backtrace differently depending on just where in the loop cycle
the dump occurs at.  Inother words, don't expect execute in frame 3 to
look the same from trace to trace. Though its a bit of a chameleon to
chase down, I'm still on the prowl to locate exact where this is
happening at.

---dave





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

#22103 [Opn->Ver]: imagefilledellipse() is incorrect with alpha blending

[pajoye]

 ID:   22103
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Verified
 Bug Type: GD related
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

Hello,

Thank's for the report.



I have already solved this problem with a quit nice and fast algorithm.
I have to check if I can add it to the current 4_3 HEAD.

Doing something better with ellipse then what GD currently does is not
very difficult (actually it's nothing else than a filled polygon with
many connected lines, kind of ugly things to draw a simple ellipse).

pierre



Previous Comments:


[2003-02-07 11:06:00] [EMAIL PROTECTED]

I had a look in the source in GD. 
The problem is the way the gdImageFilledArc() is implemented. 

The algorithm there is flawed for alpha-blending. It fills the arc by
drawing a series of filled polygons (triangles) centerd in the middle
of the ellipse and out to the edge of the ellipse with 1 degree
separation between the end points. This will make the interior points
overlap and create the moire pattern.

Unfortunately there isn't a simple solution to this. Doing a floodfill
to a specific color wan't work since we don't know the canvas we are
drawing on.

Since I'm doing a lot of graphic stuff I'll see if I can come up with a
new algorithm to do this. I'm afraid however that any correct algortihm
will be quite CPU expensive.



[2003-02-07 09:44:44] [EMAIL PROTECTED]

The problem still exist in snapshot 200302071430. 

I haven't had time to look at the GD code but this is most likely a
design flaw and not a straight bug. Fixing this will probably require a
new fill algorithm for ellipses that can guarantee that the same pixel
inside the ellipse will only be painted exactly one time.

The script below demonstrates this bug
and the resulting image can also be viewed at
http://www.aditus.nu/jpgraph/bbimages/filledellipsebug.png






[2003-02-07 06:36:22] [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 couple of fixes in GD in CVS.
If it still fails, please provide a short example script.




[2003-02-06 22:18:03] [EMAIL PROTECTED]

(Using built-in GD 2.x in PHP 4.3.0)

imagefilledellipse() creates moire' patterns inside the filled ellipse
when alpha blending is enabled.

The problem seems to be that the fill algorithm strokes the same point
within the ellipse several times and due to the alpha blending of
single pixels creates several color shades within the ellipse.

This is fine as long as a solid fill is used but does not work together
with alpha blending. 






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

#22103 [Ver]: imagefilledellipse() is incorrect with alpha blending

[ljpersson]

 ID:   22103
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Verified
 Bug Type: GD related
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

I wrote a drop in replacement for the GD gdImageFilledArc() which works
with alpha-blending. Replace the gdImageFilledArc() in gd.c with the
following function. Which is reasonable fast.


void 
gdImageFilledArc (gdImagePtr im, int cx, int cy, int w, int h, int s,
int e, int color, int style)
{
/* 
   This replacement for the original gdImageFilledArc() completely
mimics
   the original behavior. This includes the behaviour I would
consider a bug 
   where a style of IMG_ARC_CHORD is the same as IMG_ARC_PIE for
filled arcs. 

   The benefit of this implementation is that this will also work
for
   colors where alpha-blending is used.
   
   This algorithm uses GD standard sin & cos tables for quick
lookup. 
   However, this also limits the accuracy to 1 degree. This means
that
   very very large arc's will look "squarish". However for any
normal
   sizes, say < 2000 pixels, this is not really a problem in
practice.
*/

gdPoint p[362];

/* Sanity check */
if( w < 0 || h < 0 ) return;

/* Make sure angles are positive and e > s */
while( s < 0 ) s += 360;
while( e < 0 ) e += 360;
while( e < s ) e += 360;

s %= 360; 

if( e > 360 ) 
e %= 360;

/* In the algorithm we need to ue the radius */
w /= 2;
h /= 2;

/* We handle the chord and pie cases separately */
if( style & gdChord ) {
int x1,y1,x2,y2;
x1 = cx + ((long) gdCosT[s] * (long) w / 1024 );
y1 = cy + ((long) gdSinT[s] * (long) h / 1024 );
x2 = cx + ((long) gdCosT[e] * (long) w / 1024 );
y2 = cy + ((long) gdSinT[e] * (long) h / 1024 );
if( style & gdNoFill ) {
if( style & gdEdged ) {
p[0].x = cx; p[0].y = cy;
p[1].x = x1; p[1].y = y1;
p[2].x = x2; p[2].y = y2;
p[3].x = cx; p[3].y = cy;
gdImagePolygon (im, p, 4, color);   
}
else {
gdImageLine (im, x1, y1, x2, y2, color);
}
}
else {
p[0].x = cx; p[0].y = cy;
p[1].x = x1; p[1].y = y1;
p[2].x = x2; p[2].y = y2;
p[3].x = cx; p[3].y = cy;
gdImageFilledPolygon (im, p, 4, color); 
}
}
else {
/* style must be gdPie */
int i=0, a=s;
if( style & gdEdged || ! (style & gdNoFill) ) {
p[0].x = cx; p[0].y = cy;
i=1;
}

while( a <= e ) {
p[i].x = cx + ((long) gdCosT[a] * (long) w / 1024 );
p[i].y = cy + ((long) gdSinT[a] * (long) h / 1024 );
++i;
++a;
}

if( style & gdEdged || ! (style & gdNoFill) ) {
p[i].x = cx; p[i].y = cy;
++i;
}

if( style & gdNoFill ) {
gdImagePolygon (im, p, i, color);   
}
else {
gdImageFilledPolygon (im, p,i , color); 
}
}
}


Previous Comments:


[2003-02-07 20:16:15] [EMAIL PROTECTED]

Hello,

Thank's for the report.



I have already solved this problem with a quit nice and fast algorithm.
I have to check if I can add it to the current 4_3 HEAD.

Doing something better with ellipse then what GD currently does is not
very difficult (actually it's nothing else than a filled polygon with
many connected lines, kind of ugly things to draw a simple ellipse).

pierre




[2003-02-07 11:06:00] [EMAIL PROTECTED]

I had a look in the source in GD. 
The problem is the way the gdImageFilledArc() is implemented. 

The algorithm there is flawed for alpha-blending. It fills the arc by
drawing a series of filled polygons (triangles) centerd in the middle
of the ellipse and out to the edge of the ellipse with 1 degree
separation between the end points. This will make the interior points
overlap and create the moire pattern.

Unfortunately there isn't a simple solution to this. Doing a floodfill
to a specific color wan't work since we don't know the canvas we are
drawing on.

Since I'm doing a lot of graphic stuff I'll see if I can come up with a
new algorithm to do this. I'm afraid however that any correct algortihm
will be quite CPU expensive.



[2003-02-07 09:44:44] [EMAIL PROTECTED]

The problem still exist in snapshot 200302071430. 

I haven't had time to look at the GD code but this is most likely a
design flaw and not 

#22103 [Ver]: imagefilledellipse() is incorrect with alpha blending

[ljpersson]

 ID:   22103
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Verified
 Bug Type: GD related
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:

Hm.. I didn't see that ou already had made a fix in the head for this.
I haven't looked at your solution but I guess it's probably the same as
mine. When I turned on my brain the solution is of course obvious once
you know that FilledPolygon() actually does a correct fill.

BTW Do you agree with me that the behavior that
a filled style with IMG_ARC_CHORD should be the same as
IMG_ARC_PIE ? (The current behaviour.) I cosider this a bug since if
you set the CHORD style it should fill just the CHORD and not complete
the slice to the center. Just a minor detail.


I would rather consider this a bug


Previous Comments:


[2003-02-07 20:36:05] [EMAIL PROTECTED]

I wrote a drop in replacement for the GD gdImageFilledArc() which works
with alpha-blending. Replace the gdImageFilledArc() in gd.c with the
following function. Which is reasonable fast.


void 
gdImageFilledArc (gdImagePtr im, int cx, int cy, int w, int h, int s,
int e, int color, int style)
{
/* 
   This replacement for the original gdImageFilledArc() completely
mimics
   the original behavior. This includes the behaviour I would
consider a bug 
   where a style of IMG_ARC_CHORD is the same as IMG_ARC_PIE for
filled arcs. 

   The benefit of this implementation is that this will also work
for
   colors where alpha-blending is used.
   
   This algorithm uses GD standard sin & cos tables for quick
lookup. 
   However, this also limits the accuracy to 1 degree. This means
that
   very very large arc's will look "squarish". However for any
normal
   sizes, say < 2000 pixels, this is not really a problem in
practice.
*/

gdPoint p[362];

/* Sanity check */
if( w < 0 || h < 0 ) return;

/* Make sure angles are positive and e > s */
while( s < 0 ) s += 360;
while( e < 0 ) e += 360;
while( e < s ) e += 360;

s %= 360; 

if( e > 360 ) 
e %= 360;

/* In the algorithm we need to ue the radius */
w /= 2;
h /= 2;

/* We handle the chord and pie cases separately */
if( style & gdChord ) {
int x1,y1,x2,y2;
x1 = cx + ((long) gdCosT[s] * (long) w / 1024 );
y1 = cy + ((long) gdSinT[s] * (long) h / 1024 );
x2 = cx + ((long) gdCosT[e] * (long) w / 1024 );
y2 = cy + ((long) gdSinT[e] * (long) h / 1024 );
if( style & gdNoFill ) {
if( style & gdEdged ) {
p[0].x = cx; p[0].y = cy;
p[1].x = x1; p[1].y = y1;
p[2].x = x2; p[2].y = y2;
p[3].x = cx; p[3].y = cy;
gdImagePolygon (im, p, 4, color);   
}
else {
gdImageLine (im, x1, y1, x2, y2, color);
}
}
else {
p[0].x = cx; p[0].y = cy;
p[1].x = x1; p[1].y = y1;
p[2].x = x2; p[2].y = y2;
p[3].x = cx; p[3].y = cy;
gdImageFilledPolygon (im, p, 4, color); 
}
}
else {
/* style must be gdPie */
int i=0, a=s;
if( style & gdEdged || ! (style & gdNoFill) ) {
p[0].x = cx; p[0].y = cy;
i=1;
}

while( a <= e ) {
p[i].x = cx + ((long) gdCosT[a] * (long) w / 1024 );
p[i].y = cy + ((long) gdSinT[a] * (long) h / 1024 );
++i;
++a;
}

if( style & gdEdged || ! (style & gdNoFill) ) {
p[i].x = cx; p[i].y = cy;
++i;
}

if( style & gdNoFill ) {
gdImagePolygon (im, p, i, color);   
}
else {
gdImageFilledPolygon (im, p,i , color); 
}
}
}



[2003-02-07 20:16:15] [EMAIL PROTECTED]

Hello,

Thank's for the report.



I have already solved this problem with a quit nice and fast algorithm.
I have to check if I can add it to the current 4_3 HEAD.

Doing something better with ellipse then what GD currently does is not
very difficult (actually it's nothing else than a filled polygon with
many connected lines, kind of ugly things to draw a simple ellipse).

pierre




[2003-02-07 11:06:00] [EMAIL PROTECTED]

I had a look in the source in GD. 
The problem is the way the gdImageFilledArc() is implemented. 

The algorithm there is flawed for alpha-blending. It fills the arc by
drawing a series of filled polygons (triangles) centerd in the middle
of the ellipse and out to the edge o

#22118 [NEW]: Sablotron segfaults

[pete+php]

From: [EMAIL PROTECTED]
Operating system: AIX 4.3
PHP version:  4.3.0
PHP Bug Type: Reproducible crash
Bug description:  Sablotron segfaults

SCRIPT:

==
% cat config.nice
#! /bin/sh
#
# Created by configure

'./configure' \
'--with-apxs=/usr/local/apache/bin/apxs' \
'--with-mysql=/usr/local' \
'--enable-libgcc' \
'--enable-xslt' \
'--with-xslt-sablot=/usr/local' \
'--with-expat-dir=/usr/local' \
'--enable-debug' \
'--without-sablot-js' \
"$@"
=== 
% gcc -v
Reading specs from
/usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/2.95.3/specs
gcc version 2.95.3 20010315 (release)

% httpd -V
Server version: Apache/1.3.27 (Unix)
...

EXPAT Version expat_1.95.5
Sablotron Version 0.97 
Sablotron Information Cflags: -g -O2 Libs: -L/usr/local/lib -liconv
-lexpat Prefix: /usr/local



gdb backtrace:
(gdb) bt
#0  0x10003f88 in sig_coredump ()
#1  
#2  0xd10e5030 in XML_ParserCreateNS () at lib/xmlparse.c:630
#3  0xd10db1a4 in TreeConstructer::parseDataLineUsingExpat
(this=0x60013fe1, 
S=@0x0, t=0x60032019, d=0x7f, 
base_=0x7f ) at parser.cpp:106
#4  0xd10678d8 in Tree::parse (this=0x20161ee8, S=@0x20160708,
d=0x7f)
at tree.cpp:1375
#5  0xd101a89c in Processor::addLineParse (this=0x201617c8, S=@0x20160708,

newTree=@0x201617cc, absolute=@0x2ff206b8, isXSL=1, ignoreErr=0)
at proc.cpp:597
#6  0xd101b054 in Processor::readTreeFromURI (this=0x201617c8,
S=@0x20160708, 
newTree=@0x201617cc, location=@0x20161bf8, base=@0x2ff20758, isXSL=1,

ignoreErr=0) at proc.cpp:645
#7  0xd1017d7c in Processor::open (this=0x201617c8, S=@0x20160708, 
sheetURI=0x20161d70 , 
inputURI=0x20161cd0 ) at
proc.cpp:314
#8  0xd10d48d0 in SablotRunProcessorGen (S=0x20160708,
processor_=0x201617c8, 
sheetURI=0x20161d70 , 
inputURI=0x20161cd0 , 
resultURI=0xd1581850 "arg:/_result") at sablot.cpp:374
#9  0xd151e9cc in zif_xslt_process (ht=3, return_value=0x20161dc0, 
this_ptr=0x, return_value_used=-1)
at /home/pete/tmp/php-4.3.0/ext/xslt/sablot.c:590
#10 0xd14792f4 in execute (op_array=0x20160390)
at /home/pete/tmp/php-4.3.0/Zend/zend_execute.c:1596
#11 0xd145e900 in zend_execute_scripts (type=0, retval=0x0, file_count=3)
at /home/pete/tmp/php-4.3.0/Zend/zend.c:864
#12 0xd1459cb8 in php_execute_script (primary_file=0x2ff22310)
at /home/pete/tmp/php-4.3.0/main/main.c:1573
#13 0xd155e54c in apache_php_module_main (r=0x0, display_source_mode=0)
at /home/pete/tmp/php-4.3.0/sapi/apache/sapi_apache.c:55
#14 0xd15610ac in send_php (r=0x20156990, display_source_mode=0,
filename=0x0)
at /home/pete/tmp/php-4.3.0/sapi/apache/mod_php4.c:556
#15 0xd156113c in send_parsed_php (r=0x0)
at /home/pete/tmp/php-4.3.0/sapi/apache/mod_php4.c:571
#16 0x100164ac in ap_invoke_handler ()
#17 0x10044924 in process_request_internal ()
#18 0x100449e8 in ap_process_request ()
#19 0x10006088 in child_main ()
#20 0x10006400 in make_child ()
---Type  to continue, or q  to quit---
#21 0x1000690c in perform_idle_server_maintenance ()
#22 0x100070a8 in standalone_main ()
#23 0x100078fc in main ()
#24 0x11dc in __start ()
(gdb) frame 10
#10 0xd14792f4 in execute (op_array=0x20160390)
at /home/pete/tmp/php-4.3.0/Zend/zend_execute.c:1596
1596   
((zend_internal_function *)
EX(function_state).function)->handler(EX(opline)->extended_value,
EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr,
return_value_used TSRMLS_CC);

===

i tried the more complex forms of calling xslt_process, it does not make a
difference.

everything else works fine.
let me know if there is any other information which would
be useful or anything that i screwed up or should try.

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

#22103 [Ver]: imagefilledellipse() is incorrect with alpha blending

[pajoye]

 ID:   22103
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Verified
 Bug Type: GD related
 Operating System: Linux
 PHP Version:  4.3.0
 New Comment:



I thank you for your function, but hopefully there is a far better way
to draw ellipse or circle.

As I said, I have to check if I can commit new functions to the head.
As far as it's OK, I'll commit.

hth

pierre


Previous Comments:


[2003-02-07 20:42:06] [EMAIL PROTECTED]

Hm.. I didn't see that ou already had made a fix in the head for this.
I haven't looked at your solution but I guess it's probably the same as
mine. When I turned on my brain the solution is of course obvious once
you know that FilledPolygon() actually does a correct fill.

BTW Do you agree with me that the behavior that
a filled style with IMG_ARC_CHORD should be the same as
IMG_ARC_PIE ? (The current behaviour.) I cosider this a bug since if
you set the CHORD style it should fill just the CHORD and not complete
the slice to the center. Just a minor detail.


I would rather consider this a bug



[2003-02-07 20:36:05] [EMAIL PROTECTED]

I wrote a drop in replacement for the GD gdImageFilledArc() which works
with alpha-blending. Replace the gdImageFilledArc() in gd.c with the
following function. Which is reasonable fast.


void 
gdImageFilledArc (gdImagePtr im, int cx, int cy, int w, int h, int s,
int e, int color, int style)
{
/* 
   This replacement for the original gdImageFilledArc() completely
mimics
   the original behavior. This includes the behaviour I would
consider a bug 
   where a style of IMG_ARC_CHORD is the same as IMG_ARC_PIE for
filled arcs. 

   The benefit of this implementation is that this will also work
for
   colors where alpha-blending is used.
   
   This algorithm uses GD standard sin & cos tables for quick
lookup. 
   However, this also limits the accuracy to 1 degree. This means
that
   very very large arc's will look "squarish". However for any
normal
   sizes, say < 2000 pixels, this is not really a problem in
practice.
*/

gdPoint p[362];

/* Sanity check */
if( w < 0 || h < 0 ) return;

/* Make sure angles are positive and e > s */
while( s < 0 ) s += 360;
while( e < 0 ) e += 360;
while( e < s ) e += 360;

s %= 360; 

if( e > 360 ) 
e %= 360;

/* In the algorithm we need to ue the radius */
w /= 2;
h /= 2;

/* We handle the chord and pie cases separately */
if( style & gdChord ) {
int x1,y1,x2,y2;
x1 = cx + ((long) gdCosT[s] * (long) w / 1024 );
y1 = cy + ((long) gdSinT[s] * (long) h / 1024 );
x2 = cx + ((long) gdCosT[e] * (long) w / 1024 );
y2 = cy + ((long) gdSinT[e] * (long) h / 1024 );
if( style & gdNoFill ) {
if( style & gdEdged ) {
p[0].x = cx; p[0].y = cy;
p[1].x = x1; p[1].y = y1;
p[2].x = x2; p[2].y = y2;
p[3].x = cx; p[3].y = cy;
gdImagePolygon (im, p, 4, color);   
}
else {
gdImageLine (im, x1, y1, x2, y2, color);
}
}
else {
p[0].x = cx; p[0].y = cy;
p[1].x = x1; p[1].y = y1;
p[2].x = x2; p[2].y = y2;
p[3].x = cx; p[3].y = cy;
gdImageFilledPolygon (im, p, 4, color); 
}
}
else {
/* style must be gdPie */
int i=0, a=s;
if( style & gdEdged || ! (style & gdNoFill) ) {
p[0].x = cx; p[0].y = cy;
i=1;
}

while( a <= e ) {
p[i].x = cx + ((long) gdCosT[a] * (long) w / 1024 );
p[i].y = cy + ((long) gdSinT[a] * (long) h / 1024 );
++i;
++a;
}

if( style & gdEdged || ! (style & gdNoFill) ) {
p[i].x = cx; p[i].y = cy;
++i;
}

if( style & gdNoFill ) {
gdImagePolygon (im, p, i, color);   
}
else {
gdImageFilledPolygon (im, p,i , color); 
}
}
}



[2003-02-07 20:16:15] [EMAIL PROTECTED]

Hello,

Thank's for the report.



I have already solved this problem with a quit nice and fast algorithm.
I have to check if I can add it to the current 4_3 HEAD.

Doing something better with ellipse then what GD currently does is not
very difficult (actually it's nothing else than a filled polygon with
many connected lines, kind of ugly things to draw a simple ellipse).

pierre


-

#22108 [Bgs->Opn]: php doesn't ignore the utf-8 BOM

[moriyoshi]

 ID:   22108
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
-Bug Type: Output Control
+Bug Type: Feature/Change Request
 Operating System: windows 2000
 PHP Version:  4.2.3
 New Comment:

Because BOM issue has been referenced repeatedly as a header output
preventer and we should be more aware of this, I don't see any reason
we have to mark this report as bogus.

Changing category from "output control" to a kind of "feature
request".



Previous Comments:


[2003-02-07 13:57:22] [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

BOM = Byte Order Mark for UCS-2 encoding
This value sould not be used in UTF-8 since the only
reason besides detecting the byte order of UCS-2 was a 
special non breaking space. And newer Unicode versions 
have another representation for the same thing.

Anyhow BOM = FE FF
That makes depending on the byte order:
UCS-2BE <-> "\xFE\xFF"
UCS-2LE <-> "\xFF\xFE"

Therefore a sequence of "EF BB" is another character and 
must not be ignored.




[2003-02-07 10:42:16] [EMAIL PROTECTED]

sniper,

imagine someone would want to echo some text in eg. French.
In that case, if you'd save it as ascii, you would get corrupted
output. So instead you'd have to save as utf-8. Which seems to cause
problems (or so [EMAIL PROTECTED] tells us)



[2003-02-07 08:58:21] [EMAIL PROTECTED]

And why an earth would you save PHP files in any other
format than ascii?




[2003-02-07 08:53:10] [EMAIL PROTECTED]

What is a BOM ?

Derick



[2003-02-07 08:46:36] [EMAIL PROTECTED]

Problem:
When a php file is saved in utf-8 format with the UTF-8 BOM as the
first three bytes of the file (EF BB BF), PHP doesn't ignore these
bytes when loading and compiling the file, but instead considers them
output coming prior to the http://bugs.php.net/?id=22108&edit=1

#18648 [Fbk->Bgs]: Single entry form POST gives incorrect variable content

[moriyoshi]

 ID:   18648
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Bogus
 Bug Type: Apache2 related
 Operating System: All
 PHP Version:  5CVS-2003-01-29 (dev) / 4CVS-20020121 (stable)
 New Comment:

First I made a typo in my previous comment.

I mean "application/x-httpd-php" everywhere I wrote "x-http-php".

Anyway let me mark this as bogus...
(The problem turned out to be a user fault.)



Previous Comments:


[2003-02-07 19:33:06] [EMAIL PROTECTED]

Apache 2.0.44 / PHP 4.3.1-dev (php4-STABLE-200302071830)

No more problem.
Neither sessions, neither forms

Good job !



[2003-02-06 03:57:54] [EMAIL PROTECTED]

That's it.



[2003-02-04 20:49:40] [EMAIL PROTECTED]

Thanks... It works ok.



[2003-02-04 15:05:45] [EMAIL PROTECTED]

[To anyone who experiences this trouble]

Are you sure that your httpd.conf has just A SINGLE KIND OF PHP RELATED
DIRECTIVE?

Then try grep "\(OutputFilter\|InputFilter\|AddType\)" < httpd.conf or
whatsoever.

# bad example (a)
AddInputFilter PHP php
AddOutputFilter PHP php

...

AddType x-httpd-php .php

# bad example (b)
SetInputFilter PHP
SetOutputFilter PHP

...

AddType x-httpd-php .php

# not bad (c)
AddInputFilter PHP php
AddOutputFilter PHP php

# good (d)
AddType x-httpd-php .php




[2003-02-04 09:16:42] [EMAIL PROTECTED]

Tested in RH8.0 + PHP 4.2.2 + Apache 2.

- Is ok when you add the 'enctype="multipart/form-data"' propety to the
form tag.
- Is ok when you send using GET method instead POST.
- Is ok when you send more than one field: if you have a text and a
button, if you send it pressing enter only the text send and the
problem occurs. When you press the button, text and button are send and
the problem not occur.
ciao.



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

#21596 [Com]: Bundled GD-Lib 2.1 won't let JPGraph start up

[ljpersson]

 ID:   21596
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: GD related
 Operating System: Linux 7.3
 PHP Version:  4.3.0
 New Comment:

I'm a little but surprised (I'm the developer of JpGraph) since I'm
using 4.3.0 myself with no apperant problem (apart from a bug in
imagettfbbox in GD > 2.01 whcih causes text at an angle > 0 to be a few
pixels off)

I used both SuSE 8.0, 8.1 as well as Debian with the bundled GD in
4.3.0 with no problem.

This sounds more like Red Hat have some problem in their specific
setup. I don't have any guesses to what it could be though.

If you don't get any errors back this basically must mean that the PHP
process have crashed.


Previous Comments:


[2003-01-12 07:15:51] [EMAIL PROTECTED]

- compile PHP 4.3.0 on Linux 7.3 with GD-Lib 2.7 installed via APXS
against Apache 1.3.27 with the GD-option set, not specifying any
directory
-> installs the GD-Lib bundled with PHP 4.3.0
-> JPGraph doesn't give any output anymore (plainly won't start up at
all, so no error messsage is generated)

workaround:
- compile PHP 4.3.0 on Linux 7.3 with GD-Lib 2.7 installed via APXS
against Apache 1.3.27 with the GD-option set, specifying the GD-Lib 2.7
directory
-> PHP 4.3.0 refers to GD-Lib 2.7
-> JPGraph works as usual

Note: I use the GD 2.7 with the GIF-patch, but I don't think this would
make any difference, since JPGraph won't start up at all with the
bundled GD-Lib, and it is set to use png anyway.




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

#22119 [NEW]: Variables in Working in Apache

[bozthepcnerd]

From: [EMAIL PROTECTED]
Operating system: Win2k
PHP version:  4.3.0
PHP Bug Type: *General Issues
Bug description:  Variables in Working in Apache

When I pass variables, the variable That was just entered gets lost and the
error that I program in pops up meaning that PHP doesn't work. Please HELP
:( .
-- 
Edit bug report at http://bugs.php.net/?id=22119&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22119&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22119&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22119&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22119&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22119&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22119&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22119&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22119&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22119&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22119&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22119&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22119&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22119&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22119&r=gnused

#22119 [Opn]: Variables (in Apache 2.0.43)

[bozthepcnerd]

 ID:   22119
 User updated by:  [EMAIL PROTECTED]
-Summary:  Variables in Working in Apache
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: *General Issues
 Operating System: Win2k
 PHP Version:  4.3.0
 New Comment:

Forgot to add:

Using PHP 4.3.0, Apache 2.0.43 and have Windows 2000.


Previous Comments:


[2003-02-07 22:50:25] [EMAIL PROTECTED]

When I pass variables, the variable That was just entered gets lost and
the error that I program in pops up meaning that PHP doesn't work.
Please HELP :( .




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

#21596 [Opn->Bgs]: Bundled GD-Lib 2.1 won't let JPGraph start up

[sniper]

 ID:   21596
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: GD related
 Operating System: Linux 7.3
 PHP Version:  4.3.0
 New Comment:

Not enough information and most likely user error / broken system.



Previous Comments:


[2003-02-07 22:35:36] [EMAIL PROTECTED]

I'm a little but surprised (I'm the developer of JpGraph) since I'm
using 4.3.0 myself with no apperant problem (apart from a bug in
imagettfbbox in GD > 2.01 whcih causes text at an angle > 0 to be a few
pixels off)

I used both SuSE 8.0, 8.1 as well as Debian with the bundled GD in
4.3.0 with no problem.

This sounds more like Red Hat have some problem in their specific
setup. I don't have any guesses to what it could be though.

If you don't get any errors back this basically must mean that the PHP
process have crashed.



[2003-01-12 07:15:51] [EMAIL PROTECTED]

- compile PHP 4.3.0 on Linux 7.3 with GD-Lib 2.7 installed via APXS
against Apache 1.3.27 with the GD-option set, not specifying any
directory
-> installs the GD-Lib bundled with PHP 4.3.0
-> JPGraph doesn't give any output anymore (plainly won't start up at
all, so no error messsage is generated)

workaround:
- compile PHP 4.3.0 on Linux 7.3 with GD-Lib 2.7 installed via APXS
against Apache 1.3.27 with the GD-option set, specifying the GD-Lib 2.7
directory
-> PHP 4.3.0 refers to GD-Lib 2.7
-> JPGraph works as usual

Note: I use the GD 2.7 with the GIF-patch, but I don't think this would
make any difference, since JPGraph won't start up at all with the
bundled GD-Lib, and it is set to use png anyway.




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

#22119 [Opn->Bgs]: Variables (in Apache 2.0.43)

[sniper]

 ID:   22119
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: Win2k
 PHP Version:  4.3.0
 New Comment:

Not enough information and most likely user error.
Please ask further support questions on the appropriate
mailing list, for example [EMAIL PROTECTED]



Previous Comments:


[2003-02-07 22:55:39] [EMAIL PROTECTED]

Forgot to add:

Using PHP 4.3.0, Apache 2.0.43 and have Windows 2000.



[2003-02-07 22:50:25] [EMAIL PROTECTED]

When I pass variables, the variable That was just entered gets lost and
the error that I program in pops up meaning that PHP doesn't work.
Please HELP :( .




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

#22116 [Opn->Fbk]: PHP_SELF gives wrong info

[sniper]

 ID:   22116
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Variables related
 Operating System: Solaris 2.7 sparc
 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-02-07 16:33:24] [EMAIL PROTECTED]

I was able to use this workaround:
$_SERVER['SCRIPT_NAME'] =
substr($_SERVER['PATH_TRANSLATED'],
   strlen($_SERVER['DOCUMENT_ROOT']));
if (substr($_SERVER['SCRIPT_NAME'], 0, 2) == '//') {
   $_SERVER['SCRIPT_NAME'] =
substr($_SERVER['SCRIPT_NAME'], 1);
}
to fix an invalid PHP_SELF on Solaris 2.7
Sparc, PHP 4.3.0 .

Simply doing phpinfo(); and then appending the value of
PHP_SELF onto an 'ls ' statement yielded "no such file".

The file did not exist:

$ ls /~russ/tryseed/showSeed.phtml
/~russ/tryseed/showSeed.phtml: No such file or directory

The clue here is this: I was running out
of a "pubic_html" subdirectory off of ~russ (see above).
The URL typed into IE 5.2 (Mac OS X) was:

"http://hostname/~russ/tryseed/showSeed.html";

** I have other pages on same web server, same PHP which
are hosted out of the server's normal root directory
and they don't have this problem. **

--Thank you to whoever came up with that workaround above.
I just put similar text as a COMMENT on a CLOSED linux 
Bug #21261.  This needs to be considered OPEN AFAIK.






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

#22110 [Opn->Bgs]: ini_get ("memory_limit"); not working

[sniper]

 ID:   22110
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: freeBSD 4.7
 PHP Version:  4.3.0
 New Comment:

empty string is returned for any ini setting that isn't set.
Not bug.



Previous Comments:


[2003-02-07 10:48:23] [EMAIL PROTECTED]

Here's how I see it.  You must have used --enable-memory-limit to use
this directive at all so it essentially isn't being used so it returns
an empty string.  I believe this is intentional but ideally a php-dev
person will answer:

Why doesn't it return the default value?  Whether that be 8M or -1 (not
sure which it is :) ... when not compiled in.  An empty string seems
misleading.



[2003-02-07 10:29:28] [EMAIL PROTECTED]

ini_get ("memory_limit"); does not return anything.




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

#22104 [Opn->Fbk]: problem with adding value to multiplie dimensional arrays

[sniper]

 ID:   22104
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Arrays related
 Operating System: Windows
 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

I can not reproduce this with latest stable CVS snapshot.



Previous Comments:


[2003-02-07 11:20:19] [EMAIL PROTECTED]

you will see what i mean if you do following:



 array(1=>"one",2=>"two", 3=>"three"),
"1" => array(1=>"One",2=>"Two", 3=>"Three"),
);
var_dump($array);
foreach($array[0] as $key => $value)
{
$array[1][]=1;
}

var_dump($array);
?>



[2003-02-07 07:16:53] [EMAIL PROTECTED]

 I cannot simulate what you say. Here is script that I wrote to test.
Test with it. Please provide good feedback as well as an example code
(as small as possible please).


 array(1=>"one",2=>"two", 3=>"three"),
"1" => array(1=>"One",2=>"Two", 3=>"Three"),
);
var_dump($array);
foreach($array[0] as $key => $value)
{
$array[1]=1;
}

var_dump($array);
?>



[2003-02-07 01:04:09] [EMAIL PROTECTED]

foreach($array[0] as $key => $value)
{
$array[1]=1;
}

This will change the value on $array[0] too, i can't explain it more. I
tested with serialize and the value on the variable gets very
strange...




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

#22108 [Opn]: php doesn't ignore the utf-8 BOM

[bugzilla]

 ID:   22108
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: windows 2000
 PHP Version:  4.2.3
 New Comment:

The BOM (byte order mark) is a few bytes at the very front of a file
that act as a signature denoting what type of encoding has been used,
and in UTF16/32 it also makes the byte order (LE or BE). Although utf-8
is byte order independent, it has become popular on windows (perhaps
not so on unix) to make use of the BOM encoded in UTF-8 to flag the
file as being in UTF-8 format. This allows editors to determine the
type of the file from the first few characters instead of trying to
guess what type the file is. Ref: Textpad 4.6 (http://textpad.com)

See the Unicode FAQ for details of the utf-8 BOM...
http://www.unicode.org/unicode/faq/utf_bom.html#25

The use of this should be obvious, you have to leave the
my-language-only mindset that afflicts too many programmers (myself
included before this job) and think about the growing multiplicity of
languages on the web. I am writing web applications in Japan, with
European language and CJK (Chinese/Japanese/Korean) language processing
and interfaces. Thus I have php files where variable values are strings
of all sorts of languages - hence utf-8 encoding.

I feel that this is definitely a bug in php. Considering that:
* php is slowly growing into a language-neutral (i18n/l10n possible)
language
* php is designed such that php commands can be liberally sprinkled
through html, and html is increasing encoded in utf-8 these days
* the utf-8 bom is becoming increasingly popular for reasons of
indentifying the file character format
* if the utf-8 bom exists php actually outputs it incorrectly and in
doing so prevents header output

I request that you don't see this as a feature request, but as a bug in
the handling of utf-8 files. Whether the output generator is the
correct characterization of this bug or not I leave up to you.

Regards,
Brodie.


Previous Comments:


[2003-02-07 21:41:23] [EMAIL PROTECTED]

Because BOM issue has been referenced repeatedly as a header output
preventer and we should be more aware of this, I don't see any reason
we have to mark this report as bogus.

Changing category from "output control" to a kind of "feature
request".




[2003-02-07 13:57:22] [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

BOM = Byte Order Mark for UCS-2 encoding
This value sould not be used in UTF-8 since the only
reason besides detecting the byte order of UCS-2 was a 
special non breaking space. And newer Unicode versions 
have another representation for the same thing.

Anyhow BOM = FE FF
That makes depending on the byte order:
UCS-2BE <-> "\xFE\xFF"
UCS-2LE <-> "\xFF\xFE"

Therefore a sequence of "EF BB" is another character and 
must not be ignored.




[2003-02-07 10:42:16] [EMAIL PROTECTED]

sniper,

imagine someone would want to echo some text in eg. French.
In that case, if you'd save it as ascii, you would get corrupted
output. So instead you'd have to save as utf-8. Which seems to cause
problems (or so [EMAIL PROTECTED] tells us)



[2003-02-07 08:58:21] [EMAIL PROTECTED]

And why an earth would you save PHP files in any other
format than ascii?




[2003-02-07 08:53:10] [EMAIL PROTECTED]

What is a BOM ?

Derick



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

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

#22111 [Opn->Bgs]: URL rewriter and Javascript

[sniper]

 ID:   22111
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Session related
 Operating System: All
 PHP Version:  4.3.0
 New Comment:

There's no need to quote "'s in your example.
Not bug.



Previous Comments:


[2003-02-07 13:00:57] [EMAIL PROTECTED]

The URL rewriter for transparent session ID propagation read also the
javascripts and add PHPSESSID, sometimes with errors

For exemple :
If I write :





I obtain : 




(Tested on servers with PHP4.3, runing with Apache 1.3.27 and Linux...)




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

#22009 [Opn->Bgs]: Passing function arguments as arrays

[pollita]

 ID:   22009
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: Windows 2000
 PHP Version:  4.3.0
 New Comment:

This functionality already exists:

http://www.php.net/manual/en/function.call-user-func-array.php


Previous Comments:


[2003-02-02 04:46:25] [EMAIL PROTECTED]

This is not really a bug. I would like to be able to pass the arguments
of a function as arrays. I've come upon problems like not knowing the
number of arguments that I'll be sending to a function and I get stuck
because I can't use that function and I have to go way around it (for
example array_multisort()).

Thanks




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

#22107 [Opn->Fbk]: file upload problem

[sniper]

 ID:   22107
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Apache related
 Operating System: OpenBSD
 PHP Version:  4.3.0
 New Comment:

Set to open only when you give the actual feedback.



Previous Comments:


[2003-02-07 09:20:42] [EMAIL PROTECTED]

Thaks, I'll try soon to re-configure without-inline-optimization.
I cannot provide any link to the real installation because it's in the
LAN of a customer...



[2003-02-07 08:56:59] [EMAIL PROTECTED]

Try removing this from your configure line:
 --enable-inline-optimization

Then 'rm config.cache' and run configure/make etc.
And also check your php.ini and that the correct
one is loaded by php.

Doing a 'diff -u php.ini php.ini-dist' would also help a bit.





[2003-02-07 07:08:52] [EMAIL PROTECTED]

 Could you provide some link to a place where your results can be seen?



[2003-02-07 07:01:58] [EMAIL PROTECTED]

When calling a php script from a POST form like this:


Send file: 



the script upload.php have the $_FILES array empty.

The output of print_r($_FILES) is an empty array ().

HTML form and PHP pages are under https (Apache/1.3.26 (Unix) PHP/4.3.0
mod_ssl/2.8.10 OpenSSL/0.9.7-beta3).

Of course all works fine with a Linux Box (RH 7.2) and with windoz too
(using http).


Configure Options for php:
./configure --with-apxs=/usr/sbin/apxs --enable-ftp
--enable-inline-optimization --with-zlib --disable-cli --disable-cgi
--with-mysql 






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

#21688 [Opn->Fbk]: CGI Timeout

[sniper]

 ID:   21688
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: IIS related
 Operating System: win2k advanced server
 PHP Version:  4.3.0
 New Comment:

Please let us know if it works or not.



Previous Comments:


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

I've installed the new stable WIN32 release on my production
environment, hopefully the bug is fixed. lets see how it behaves. Would
be glad. What has been changed? it looks good, any weird behaviour so
far. Should I also post the php.ini config file?



[2003-02-06 10:08:31] [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-02-06 10:05:18] [EMAIL PROTECTED]

ok, on my workstation I have Visual Studio and thus I know the
CGI-version of PHP actually crashed.

Here is the CGI-IIS-error:

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

Here the popup's:
Application popup: php.exe - Application Error : The instruction at
"0x1b00997b" referenced memory at "0x1b00997b". The memory could not be
"read".

Application popup: php.exe - Application Error : The instruction at
"0x10030727" referenced memory at "0x01790dd8". The memory could not be
"read".



[2003-02-06 09:43:29] [EMAIL PROTECTED]

It seems that when the buffer contents is very small (when using output
buffering ?? or under normal usage, still looking into that) doens't
return headers and/or body/wrong headers (don't know which one).

The CGI-interface of IIS doesn't know how to handle it anyway.

Hope this was usefull.



[2003-01-16 09:21:48] [EMAIL PROTECTED]

I'm using php 4.3.0 and IIS 5, Win2kadv

As already a couple of others found out, PHP misbehaves, when installed
as CGI under Win2k advanced server. the scripts more than often time
out and the server announces the following error message - sometimes
the server even hangs totally - but in any case there are a lot of
php.exe processes in the server's memory left after shutting IIS down:

The script /xxx/index.php with parameters '' has not responded within
the configured timeout. The HTTP server is terminating the script.
For additional information please visit micro$oft website bla bla
bla...

Who knows a cure for this IIS version? As I don't have any problem
under apache for windows 

Somebody posted a registry hack how to stop that. Could you repost
that?





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

#22102 [Opn->Fbk]: Link fails with modified mysql path

[sniper]

 ID:   22102
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
-Bug Type: Compile Failure
+Bug Type: MySQL related
 Operating System: Solaris 8
 PHP Version:  4.3.0
 New Comment:

Looks like broken mysql installation. How was it installed?
Compiled from sources or from Mysql AB provided binaries?

In /opt/sfw/mysql/lib/mysql/ check if there is libmysqlclient.la file
and paste it's content here.



Previous Comments:


[2003-02-07 13:20:06] [EMAIL PROTECTED]

Exact output is:
ld: fatal: file /opt/sfw/mysql/lib/mysql/.libs/libmysqlclient.so: open
failed: No such file or directory
ld: fatal: File processing errors. No output written to
.libs/libphp4.so

Again, why is it lokking for the MySQL client library in ".libs" ?



[2003-02-06 21:15:54] [EMAIL PROTECTED]

Environment:  Gnu installation (GCC, MySQL, etc) from Solaris 8
Companion CD, Apache 2.0.44, PHP 4.3.0, MySQL 3.23
Apache compiled and runs fine in the environment.  

PHP:  ./configure --with-mysql=/opt/sfw/mysql
--with-apxs2=/usr/local/apache2/bin/apxs

PHP configure runs fine, and the build works up to link.  It then fails
with:
Cannot find /opt/sfw/mysql/lib/mysql/.lib/libmysqlclient.so

Where is the ".lib" coming from?  
The link also indicates that it has failed to create .lib/libphp4.so
Again - what gives with the ".lib"?




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

#21956 [Opn->Bgs]: define constants not taking heredoc strings as value

[sniper]

 ID:   21956
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Strings related
 Operating System: Win2k
 PHP Version:  4.3.0
 New Comment:

There's nothing wrong/broken in it:



outputs 'the string goes here' so it works fine.

You're just doing something wrong, most likely you
have some empty space before the heredoc end tag..
Not bug.



Previous Comments:


[2003-02-07 09:38:03] [EMAIL PROTECTED]

if this is not a bug, then it would therefore be the same across all
platforms?  which would then I surmise be a documentation problem.

Since http://www.php.net/manual/en/language.constants.php defines
thus:

"Syntax
You can define a constant by using the define()-function. Once a
constant is defined, it can never be changed or undefined. 

Only scalar data (boolean, integer, float and string) can be contained
in constants."

which then links to the string defintion page here,
http://www.php.net/manual/en/language.types.string.php, where the
Syntax for string is outlines as below.

"Syntax
A string literal can be specified in three different ways. 

single quoted 
double quoted 
heredoc syntax 
"

so according to the documentation, define can take heredoc syntax as a
valid string, since heredoc is defined as a valid string syntax.

if this is incorrect, then please change this to a documentation issue
by all means, but this is not a bugus bug, it happens.



[2003-02-07 07:26:48] [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.

Please read http://www.php.net/manual/en/function.define.php it has
good nice examples on it.



[2003-01-29 19:52:03] [EMAIL PROTECTED]

when using define() to create constants, it all seems to work fine when
using standard strings.

However, under the definition for the arguments on define(), it says
that the define function can take string() as an argument.

looking at strings, heredoc is a valid string argument, however when
trying to define a constant as follows, the constant returns a null
string.

define($html_header, <

#20935 [Fbk->NoF]: mssql_query causes segfault

[sniper]

 ID:   20935
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: MSSQL related
 Operating System: RedHat Linux 7.2 / Apache 1.3.27
 PHP Version:  4.3.0
 New Comment:

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




Previous Comments:


[2003-01-27 12:29:54] [EMAIL PROTECTED]

Well, I finally make it work using the FreeTDS 0.60 with the
--with-sybase=/path_to_freetds instead of --with-mssql=/path_to_freetds
as metioned on the manual.

I'm using the MSSQL function anyway.

Greettings.
Ernesto



[2003-01-27 09:46:09] [EMAIL PROTECTED]

It doesn't seemd to be a FreeTDS bug. I tested the tarball and CVS
version of FreeTDS with sqsh (a command line client that use FreeTDS
library, www.sqsh.org) and it worked fine.

But, when I do a remote connect with PHP using the same FreeTDS
library, it segfault when I do a simple:

$res = mssql_query("select * from Test");

The connection and selection of the database works fine.

That's all that I can say for now.
Thanks for all.

Ernesto



[2003-01-21 11:03:02] [EMAIL PROTECTED]

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



[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.





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

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

#21076 [Fbk->NoF]: ODBC_TABLES and ODBC_COLUMNS cannot be called together

[sniper]

 ID:   21076
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: ODBC related
 Operating System: Win2000, IIS-CGI
 PHP Version:  4.3.0
 New Comment:

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




Previous Comments:


[2003-01-26 16:10:10] [EMAIL PROTECTED]

Update your MDAC to 2.7 it's the latest and from what I can tell works
fine.  I have no SQL-Server to test on though unfortunately.  



[2003-01-25 09:39:36] [EMAIL PROTECTED]

Hi

Thanks for testing. I just retested.


When i test with MS Access driver the problem does not occur. 

In the original report, I tested on microsoft sql server 2000, with SQL
Server ODBC Driver version 2000.81.9001.00 (MDAC 2.6 installed).  I
just retested and still get the problem. I set the "Use ANSI quoted
identifiers" and "Use ANSI nulls" in the odbc driver.

- John



[2003-01-24 16:18:40] [EMAIL PROTECTED]

Marking as bogus.  

Using Win2k, and the CGI build I cannot reproduce this at all.  My
attempts to showed nothing wrong with the code base that I could find. 




[2002-12-22 00:56:28] [EMAIL PROTECTED]

Updating version.



[2002-12-19 05:57:03] [EMAIL PROTECTED]

yes it still happens with 4.3.0 rc3.

Regards, John



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

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

#21548 [Fbk->NoF]: make install breaks with core dump

[sniper]

 ID:   21548
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Compile Failure
 Operating System: Solaris 2.7
 PHP Version:  4.3.0
 New Comment:

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




Previous Comments:


[2003-01-23 10:33:06] [EMAIL PROTECTED]

Are you sure you're using same openssl libs as are
used for Curl?



[2003-01-09 09:14:27] [EMAIL PROTECTED]

I did: 
gdb php core
bt full

Below is the output:

#0  0xfebb6a7c in strcmp () from /usr/lib/libc.so.1
No symbol table info available.
#1  0xfef6a5e0 in obj_name_cmp () from /usr/local/pgsql/lib/libpq.so.2
No symbol table info available.
#2  0xfef687f8 in getrn () from /usr/local/pgsql/lib/libpq.so.2
No symbol table info available.
#3  0xfef68460 in lh_insert () from /usr/local/pgsql/lib/libpq.so.2
No symbol table info available.
#4  0xfef6a188 in OBJ_NAME_add () from /usr/local/pgsql/lib/libpq.so.2
No symbol table info available.
#5  0xfef6d35c in EVP_add_digest () from
/usr/local/pgsql/lib/libpq.so.2
No symbol table info available.
#6  0xfed764a8 in OpenSSL_add_all_digests () from
/usr/local/lib/libcrypto.so.0.9.6
No symbol table info available.
#7  0x0005e2c4 in zm_startup_openssl (type=1, module_number=9) at
/opt/install/source/php-4.3.0/ext/openssl/openssl.c:538
config_filename = 0x1c9f18 ""
#8  0x00130ee4 in zend_startup_module (module=0x1adc04) at
/opt/install/source/php-4.3.0/Zend/zend_API.c:1008
No locals.
#9  0x00100668 in php_startup_extensions (ptr=0x1b9424, count=1807420)
at /opt/install/source/php-4.3.0/main/main.c:986
end = (zend_module_entry **) 0x1b943c
#10 0x0014a03c in php_startup_internal_extensions () at
main/internal_functions_cli.c:79
No locals.
#11 0x00100c30 in php_module_startup (sf=0xffbefb88,
additional_modules=0x0, num_additional_modules=0)
at /opt/install/source/php-4.3.0/main/main.c:1151
zuf = {error_function = 0xff3e4 , printf_function
= 0xfee94 ,
  write_function = 0x100620 , fopen_function =
0xffa3c ,
  message_handler = 0xffaac ,
block_interruptions = 0, unblock_interruptions = 0,
  get_configuration_directive = 0xffa70
,
  ticks_function = 0x10abd8 , on_timeout = 0xffc68
}
zuv = {import_use_extension = 0x161e28 ".php",
import_use_extension_length = 0, html_errors = 0 '\0'}
php_os = 0x161da8 "SunOS"
i = 1449632
#12 0x00148f20 in main (argc=2, argv=0xffbefd4c) at
/opt/install/source/php-4.3.0/sapi/cli/php_cli.c:481
exit_status = 0
c = -4260984
file_handle = {type = 255 'ÿ', filename = 0x2dd90
"@\004pï\001", opened_path = 0x3 ,
  handle = {fd = -4260532, fp = 0xffbefd4c}, free_filename = 0 '\0'}
behavior = 1
orig_optind = 1
orig_optarg = 0x0
arg_free = 0x1 
script_file = 0x0
global_vars = {head = 0x0, tail = 0x0, size = 0, count =
1352040, dtor = 0xfec382b8 ,
  persistent = 254 'þ', traverse_ptr = 0x0}
interactive = 0
module_started = 0
exec_direct = 0x0
param_error = 0x0



[2003-01-09 08:29:45] [EMAIL PROTECTED]

please run :
gdb sapi/cli/php core

then under gdb type:

bt full

Don't forget the gdb at the beginning please.

Thank you.



[2003-01-09 08:21:50] [EMAIL PROTECTED]

nippur:/opt/install/source/php-4.3.0/sapi/cli # ./php core
Segmentation Fault (core dumped)

What is the second command?



[2003-01-09 08:09:14] [EMAIL PROTECTED]

Can you run the following commands:

$gdb sapi/cli/php core

$bt full

and add the output here?



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

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

#21675 [Fbk->NoF]: Relative includes and Apache Alias problem

[sniper]

 ID:   21675
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Apache related
 Operating System: BSDI 4.1
 PHP Version:  4.3.0
 New Comment:

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




Previous Comments:


[2003-01-25 16:12:54] [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

Try the following patched file and see if your problem is fixed

http://cvs.php.net/co.php/php4/sapi/cgi/cgi_main.c?r=1.190.2.12




[2003-01-15 22:37:23] [EMAIL PROTECTED]

Here's a post that pretty much sums-up the problem.

http://groups.google.com.au/groups?q=php+4.3.0+%22failed+to+create+stream%22&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=501021782.1042219035023.JavaMail.luser%40dubb11h05-0.dplanet.ch&rnum=10


This is not my post, but it is exactly the same issue we are having.
Here's my PHP entries in httpd.conf:

AddType application/x-httpd-php4 .php .php4
AddType application/x-httpd-php4-source .phps .php4s
AddHandler php4-script .phtml .p4html

Action application/x-httpd-php4 /cgi-bin/php4
Action application/x-httpd-php4-source /cgi-bin/php4
Action php4-script /cgi-bin/php4

Please note we were previously using 4.1.2 and
did not have this problem.

I appologize if my report is not extremly detailed.
if you need more info, please let me know.

Thank you,
Chris





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

#21776 [Fbk->NoF]: Heisenbug after database code changes.

[sniper]

 ID:   21776
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Unknown/Other Function
 Operating System: Windows and Linux
 PHP Version:  4.2.3
 New Comment:

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




Previous Comments:


[2003-01-24 11:13:45] [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-23 14:07:28] [EMAIL PROTECTED]

Cannot get a backtrace from the instructions on bug submission. The PHP
session does not actually crash, generating a core dump, but exits with
a fatal error. The text of the error is gibberish, but nevertheless it
does not die.

How can we stop or investigate the process at the point of the error.

It looks like PHP's symbol table gets corrupted during an earler part
of the code. Is there anyway we can investigate this further.

yours, Marcus.



[2003-01-20 10:46:44] [EMAIL PROTECTED]

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

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

Thank you for your interest in PHP.




[2003-01-20 10:31:29] [EMAIL PROTECTED]

This is the bug from hell.

It is random crashing in a section of our unit tests. On Windows the
crash manifests itself as...

The instruction "(1)" referenced memory at "(2)" which is not writable
where (1) is :0x77fcb9b1 (once), 0x77fcb892 (twice), 0x77fcb9fb (once)
on a random attempt of two dozen tries.

There is too much code to post here and we cannot yet isolate it - our
individual unit tests all pass. We are working on a backtrace from a
Linux machine and will add to this bug soon.

The code that was changed that started generating these problems was
mysql related. There are a lot of references in that code (it is a
persistent object library).

The problem manifests itself in Linux with random fatal errors such as
unknown function where the function name is simply "<()" !? It also
happens both with version 3 and 4 of  MySQL and versions 4.2.3 and
4.3.0 of PHP.

It is a complete show stopper.

yours, Marcus.





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

#21829 [Fbk->NoF]: fsockopen() crashes on 2 of 3 servers (w/ gdb trace)

[sniper]

 ID:   21829
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Sockets related
 Operating System: mandrake 8.2, 2.4.18-8.1mdk
 PHP Version:  4.3.0
 New Comment:

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




Previous Comments:


[2003-01-23 03:52:19] [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 fsockopen fixes recently; please try a snapshot.



[2003-01-22 23:37:19] [EMAIL PROTECTED]

I found the cause of this.  Somehow in my exported INCLUDE
-I/usr/include had come before -I/usr/local/bind/include, and the DNS
structures were taken from the wrong header files.  After setting the
BIND include files to be searched first and recompiling, this appears
to be resolved.



[2003-01-22 19:42:25] [EMAIL PROTECTED]

Compiling 4.3.0 and php4-STABLE-200301222030 on 3 servers, one works
and two segfault.  The simple script below illustrates the problem; on
one server it runs, on two it faults.  The three servers are
essentially identical; php.ini on all are identical.

Build details and gdb backtrace are below.  I also have
fopen("http://";) failing the same way, not surprising.  The failure
appears to be in DNS resolution.  Glad to supply more info as needed.



=

php was built with the following options:

./configure \
 --with-gd \
 --with-mysql=/usr \
 --with-exec-dir=/var/lib/php \
 --with-java=/usr/local/jdk \
 --enable-unified-odbc \
 --enable-safe-mode=yes \
 --enable-track-vars \
 --enable-ftp \
 --with-expat-dir=/usr \
 --with-xml \
 --with-dom=/usr \
 --with-dom-xslt=/usr \
 --with-dom-exslt=/usr \
 --enable-xslt \
 --with-xslt-sablot=/usr \
 --with-sablot-js=/usr \
 --with-zlib \
 --with-ldap \
 --with-openssl \
 --disable-debug \
 --disable-debugger \
 --with-config-file-path=/etc/httpd/conf

The bind version on all servers is 8.3.3, patched with ISC patches
prior to 8.3.4 release from recent bugs.

=

gdb run commands:

gdb stacktrace:(gdb) set args fsock_yahoo.php
(gdb) run
Starting program: /usr/local/bin/php fsock_yahoo.php
[New Thread 1024 (LWP 3639)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 3639)]
0x081335d5 in php_network_getaddresses (host=0x831c59c "www.yahoo.com",

sal=0xbfffc634) at /usr/local/php4/main/network.c:215
215 *(struct sockaddr_in *)*sap =


#0  0x081335d5 in php_network_getaddresses (host=0x831c59c
"www.yahoo.com", 
sal=0xbfffc634) at /usr/local/php4/main/network.c:215
#1  0x08133810 in php_hostconnect (host=0x831c59c "www.yahoo.com",
port=80, 
socktype=1, timeout=0xbfffc6b0) at
/usr/local/php4/main/network.c:410
#2  0x08133b5f in _php_stream_sock_open_host (host=0x831c59c
"www.yahoo.com", 
port=80, socktype=1, timeout=0xbfffc6b0, persistent_id=0x0)
at /usr/local/php4/main/network.c:619
#3  0x080ee025 in php_fsockopen_stream (ht=4, return_value=0x831c5dc, 
this_ptr=0x0, return_value_used=1, persistent=0)
at /usr/local/php4/ext/standard/fsock.c:218
#4  0x080ee1ed in zif_fsockopen (ht=4, return_value=0x831c5dc,
this_ptr=0x0, 
return_value_used=1) at /usr/local/php4/ext/standard/fsock.c:278
#5  0x0815d2d2 in execute (op_array=0x8322504)
at /usr/local/php4/Zend/zend_execute.c:1596
#6  0x0814cdf3 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/local/php4/Zend/zend.c:864
#7  0x0812992b in php_execute_script (primary_file=0xb560)
at /usr/local/php4/main/main.c:1573
#8  0x08164488 in main (argc=2, argv=0xb604)
at /usr/local/php4/sapi/cli/php_cli.c:746
#9  0x405be280 in __libc_start_main () from /lib/libc.so.6





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

#21839 [Fbk->Bgs]: Php non compile libphp4.la

[sniper]

 ID:   21839
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Mandrake Linux 9.0
 PHP Version:  4.3.0
 New Comment:

user error.



Previous Comments:


[2003-01-23 06:29:44] [EMAIL PROTECTED]

You have probably run configure and make several times which has
created some stale objects. Please try:

make clean
make




[2003-01-23 05:10:23] [EMAIL PROTECTED]

Configuration line:

./configure --with-pgsql=/usr/local/pgsql
--with-apxs=/usr/local/web/apache/bin/apxs

Make result:
ext/ctype/ctype.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1


apache compiled so:
./configure --prefix=/usr/local/web/apache --enable-module=so




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

#21843 [Fbk->NoF]: return_path in imap_header function returns null

[sniper]

 ID:   21843
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: IMAP related
 Operating System: Linux/FreeBSD
 PHP Version:  4.2.3
 New Comment:

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




Previous Comments:


[2003-01-23 09:04:41] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2003-01-23 09:03:03] [EMAIL PROTECTED]

Reading the return_path array from the imap_headers object.
$obj= imap_header($this->stream,1);

gettype($obj->return_path) should return Array but returns NULL.

Ed Hofrichter




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

#21846 [Fbk->NoF]: CVS configure fails

[sniper]

 ID:   21846
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Compile Failure
 Operating System: W2K / Cygwin latest
 PHP Version:  4CVS-2003-01-23 (stable)
 New Comment:

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




Previous Comments:


[2003-01-23 10:40:45] [EMAIL PROTECTED]

And PLEASE don't put such long useless pieces of text
in your comments!!




[2003-01-23 10:39:55] [EMAIL PROTECTED]

Is this with some snapshot? Or did you pull it from
directly from CVS? And if so, how?





[2003-01-23 10:28:32] [EMAIL PROTECTED]

The Latest CVS does not build under cygwin:

  root@W2KPICASSO:/usr/src/cvs-source/php4$ cat CVS/R* 
  php4
  :pserver:[EMAIL PROTECTED]:/repository


root@W2KPICASSO:/usr/src/cvs-source/php4$ ./configure 

...
Generating files
checking for working mkdir -p... yes
configure: creating ./config.status
creating main/internal_functions.c
awk: ./build/print_include.awk:7: (FILENAME=ext/mysql/php_mysql.h
FNR=125) fatal: cannot open file `ext/overload/*.h' for reading (No
such file or directory)
creating main/internal_functions_cli.c
awk: ./build/print_include.awk:7: (FILENAME=ext/mysql/php_mysql.h
FNR=125) fatal: cannot open file `ext/overload/*.h' for reading (No
such file or directory)

root@W2KPICASSO:/usr/src/cvs-source/php4$ ls -la ext/overload/
total 0
drwxr-xr-x2 root None0 Jan 23 11:55 .
drwxr-xr-x   93 root None0 Oct 11  2001 ..






me = W2KPICASSO
uname -m = i686
uname -r = 1.3.18(0.69/3/2)
uname -s = CYGWIN_NT-5.0
uname -v = 2002-12-25 15:37

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
hostinfo   = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH =
/usr/local/bin:/cygdrive/e/home/jaalto/bin/perl:/cygdrive/e/home/jaalto/bin:/cygdrive/e/home/jaalto/exe:/bin:/usr/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/cygdrive/e/home/jaalto/bin/bat/picasso/bin:/cygdrive/e/home/jaalto/tmp/sforge/perl-text2html/bin:/cygdrive/e/home/jaalto/tmp/sforge/perl-webget/bin:/cygdrive/e/home/jaalto/bin/perl/my:/cygdrive/h/bin/dos:/cygdrive/h/bin/dos/misc:/cygdrive/h/bin/dos/other:/cygdrive/h/bin/dos/zip:/cygdrive/e/home/jaalto/bin/shell:/cygdrive/e/home/jaalto/elisp/tiny/bin:/cygdrive/h/bin/dos/expat:/cygdrive/h/bin/dos/expat/Libs:/cygdrive/g/Program
Files/commercial/Perforce:/cygdrive/d/wbin/server/sql/mysql/bin:/cygdrive/d/wbin/server/apache:/cygdrive/h/bin/lang/php/php4:/cygdrive/h/bin/lang/php/php4/dlls:/cygdrive/d/java/sun/jdk-1.4.1/bin:/cygdrive/h/bin/oracle/ora81/bin:/cygdrive/g/Program
Files/Oracle/jre/1.1.7/bin:/cygdrive/g/WINNT/system32:/cygdrive/g/WINNT:/cygdrive/g/WINNT/System32/Wbem:/cygdrive/g/Program
Files/Resource Pro
Kit/:/usr/share/site-perl/script/misc:/cygdrive/e/home/jaalto/tmp/sforge/perl-dyndns/bin:/cygdrive/e/home/jaalto/tmp/sforge/pm-doc/bin:/cygdrive/e/home/jaalto/tmp/sforge/pm-lib/bin:/cygdrive/e/home/jaalto/tmp/sforge/cvs-tools/bin:/cygdrive/e/home/jaalto/tmp/sforge/tiny-tools/bin:/cygdrive/e/home/jaalto/tmp/sforge/js-tools/bin:/cygdrive/d/java/apache/jakarta-ant-cvsbuild/bin:/cygdrive/d/java/apache/cvs/xml-xindice/bin:/cygdrive/h/bin/emacs/gnu-emacs/emacs-21.2/bin:/cygdrive/h/bin/emacs/XEmacs/bin/i686-pc-cygwin:/usr/local/BerkeleyDB.3.3/bin:/usr/share/site-perl/script:/cygdrive/d/wbin/server/apache/bin


##  ##
## Core tests.  ##
##  ##

configure:1450: PATH=".;."; conftest.sh
conftest.sh: not found
configure:1453: $? = 127
configure:1536: checking build system type
configure:1554: result: i686-pc-cygwin
configure:1562: checking host system type
configure:1576: result: i686-pc-cygwin
configure:1703: checking for gcc
configure:1726: result: gcc
configure:1955: checking for C compiler version
configure:1958: gcc --version &5
gcc (GCC) 3.2 20020927 (prerelease)
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.

configure:1961: $? = 0
configure:1963: gcc -v &5
Reading specs from /bin/../lib/gcc-lib/i686-pc-cygwin/3.2/specs
Configured with: /netrel/src/gcc-3.2-3/configure
--enable-languages=

#21847 [Fbk->NoF]: php core dumps whilst retrieving images from url

[sniper]

 ID:   21847
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Reproducible crash
 Operating System: linux-2.4.20
 PHP Version:  4.3.0
 New Comment:

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




Previous Comments:


[2003-01-24 10:07:00] [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

Cannot replicate the crash with latest CVS.



[2003-01-24 03:16:03] [EMAIL PROTECTED]

Still crashes with optmiser disabled but no core dump now, last string
printed is corrupt.



[2003-01-24 02:28:50] [EMAIL PROTECTED]

This is the URL for the file, I will try switching off the optimiser
and run again.

http://www.draper.co.uk/files/United%20Kingdom2002.txt



[2003-01-23 19:18:36] [EMAIL PROTECTED]

Could you please provide the draper.txt so that the bug can be
replicated. As is I cannot replicate the crash, merely get an error
opening the specified image URL.
Also, does the crash occur if you disable ZendOptimizer?



[2003-01-23 13:02:30] [EMAIL PROTECTED]

When running the following code php core dumps.

http://www.drapertools.com/draper/images/details/".trim($fields[1])."_".trim($fields[2]).".jpg";

   
$outfile="draper_images/draper_".trim($fields[1])."_".trim($fields[2]).".jpg";
print("opening $url\n");
ob_flush();
if($urlfp=fopen($url,"rb"))
{
print("Outputing to $outfile\n");
if($imagefp=fopen($outfile,"wb"))
{
print($url." -> ".$outfile."\n");
ob_flush();
fputs($good,$url." -> ".$outfile."\n");
$size=0;
while(!feof($urlfp))
{
$block=fread($urlfp,4096);
fputs($imagefp,$block);
$size+=4096;
print($url." -> ".$outfile." :
$size\n");
};
fclose($imagefp);
};
fclose($urlfp);
}
else
{
fputs($bad,$url."\n");
};
};
fclose($fp);
fclose($good);
fclose($bad);
?>

The input file is a comma delimited list, we are interested in the
filename which we then retrieve from the site (you can find the names
by going to the site or by downloading the text file from the site).

Just recompiled with debug, here is the backtrace:
#0  0x08153650 in php_hostconnect (host=0x82ef62c
"www.drapertools.com", port=80, socktype=1, timeout=0x0)
at /usr/src/php-4.3.0/main/network.c:435
#1  0x08153900 in _php_stream_sock_open_host (host=0x82ef62c
"www.drapertools.com", port=80, socktype=1, timeout=0x0, 
persistent_id=0x0) at /usr/src/php-4.3.0/main/network.c:619
#2  0x0811a497 in php_stream_url_wrap_http (wrapper=0x82491f0, 
path=0x82ed5c4
"http://www.drapertools.com/draper/images/details/002_770-SA.jpg";,
mode=0x82e97cc "rb", options=4, 
opened_path=0x0, context=0x0) at
/usr/src/php-4.3.0/ext/standard/http_fopen_wrapper.c:121
#3  0x08152d2c in _php_stream_open_wrapper_ex (path=0x82ed5c4
"http://www.drapertools.com/draper/images/details/002_770-SA.jpg";, 
mode=0x82e97cc "rb", options=12, opened_path=0x0, context=0x0) at
/usr/src/php-4.3.0/main/streams.c:2378
#4  0x080e915a in php_if_fopen (ht=2, return_value=0x82ee5ac,
this_ptr=0x0, return_value_used=1)
at /usr/src/php-4.3.0/ext/standard/file.c:1094
#5  0x404f78f0 in zend_oe () from /usr/local/Zend/lib/ZendOptimizer.so
#6  0x404f43a0 in zend_oe () from /usr/local/Zend/lib/ZendOptimizer.so
#7  0x0816f14c in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php-4.3.0/Zend/zend.c:864
#8  0x08148909 in php_execute_script (primary_file=0xbb40) at
/usr/src/php-4.3.0/main/main.c:1573
#9  0x08190f48 in main (argc=2, argv=0xbbe4) at
/usr/src/php-4.3.0/sapi/cli/php_cli.c:746
#10 0x40342657 in __libc_start_main (main=0x81905c8 , argc=2,
ubp_av=0xbbe4, init=0x806fe60 <_init>, 
fini=0x8196790 <_fini>, rtld_fini

#21858 [Fbk->NoF]: apache uses %100 prosessor

[sniper]

 ID:   21858
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Apache2 related
 Operating System: win2k pro
 PHP Version:  4.3.0
 New Comment:

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




Previous Comments:


[2003-01-24 03:21:59] [EMAIL PROTECTED]

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

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

Thank you for your interest in PHP.




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

I've been using php 4.1.1 ever sence it came out. I just upgraded to
4.3.0. phpmyadmin works fine with it, but when I try viewing a web page
I made, it doesn't load it. it just keeps trying to load forever. it
makes apache use 100% of my prosessor, until I hit the stop button on
ie.




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

#21861 [Fbk->NoF]: set_time_limit does not Limit the maximum execution time with safe_mode off

[sniper]

 ID:   21861
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: *General Issues
 Operating System: SunOS sirius 5.8 Generic_
 PHP Version:  4.3.0
 New Comment:

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




Previous Comments:


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

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

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

Thank you for your interest in PHP.






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

--- 
I also try init_set (max_execution_time,1000) for overwriting the
default value. The function returns the previous value but does not
change the timeout problem.



[2003-01-24 06:27:34] [EMAIL PROTECTED]

--- problem in php 4.3.0
set_time_limit() does not change the maximum execution time with
safe_mode=off.

When the default maximum execution time (30 seconds in php.ini), the
result HTML page contains no data (NS) and vannot be displayed (IE)


Note: The application is completely written in PHP and does not use
system(). 


--- configure line
'./configure' '--with-apxs=/local/etc/apache/bin/apxs'
'--with-config-file-path=/local/lib/php'
'--with-oci8=/u01/app/product/932' 




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

#21887 [Fbk->Bgs]: Problem with zlib or something like that

[sniper]

 ID:   21887
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Linux Mandrake 9.0 2.4.19
 PHP Version:  4.3.0
 New Comment:

Compiling zlib as shared is not supported at the moment.
There's another report about that.
Also, you should check what configure options actually
exist in current PHP configure..

(And you don't really need --enable-versioning )



Previous Comments:


[2003-01-26 10:09:26] [EMAIL PROTECTED]

Try compiling zlib as a non-shared module (removed the =shared behind
--with-zlib).

Derick



[2003-01-26 09:03:29] [EMAIL PROTECTED]

Well, I tried to compile PHP 4.3.0 RC3 and RC4 and also 4.3.0 final,
but I couldn't. I tried to compile with the folowing console
commands:./configure --with-apxs2=/usr/local/apache2/bin/apxs
--with-zlib=shared,/usr/local --with-gd=shared,/usr/local
--with-gd-native-ttf  --with-jpeg-dir=/usr/local  --enable-ftp=shared
--with-png-dir=/usr/local --enable-sockets=shared
--with-freetype-dir=/usr/local --with-mysql=shared,/usr/local
--with-mysql-sock=/tmp/mysql.sock  --with-tsrm-pthreads
--with-bz2=shared,/usr/local  --enable-versioning --enable-magic-quotes
--enable-shared --enable-pic --disable-static
--enable-inline-optimization --with-config-file-path=/etc
--enable-debugger --enable-track-vars --with-mod_charset
--with-regex=php --enable-cgi-force-redirect --enable-trans-sid
--with-ctype=shared --enable-sysvsem --enable-mime-magic
--with-gettext=shared --without-aspell --without-kerberos
--with-cpdflib=shared,/usr/local --with-gmp=shared,/usr/local
--enable-yp=shared

The error message was the following: 
ext/standard/image.lo: In function `php_handle_swc':
/a/php-4.3.0/ext/standard/image.c:195: undefined reference to
`uncompress'
/a/php-4.3.0/ext/standard/image.c:217: undefined reference to
`uncompress'
main/SAPI.lo: In function `sapi_header_op':
/a/php-4.3.0/main/SAPI.c:526: undefined reference to `zlib_globals'
main/SAPI.lo: In function `sapi_send_headers':
/a/php-4.3.0/main/SAPI.c:675: undefined reference to `zlib_globals'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1
 
Well, I thought that it was zlibs's fault (i tried with 1.1.3) and I
recompiled everything with a new one (1.1.4), (including libpng, gd,
etc..), but it still doesn't works.
Yes, I ran ldconfig several times...
But everíthing works with PHP 4.2.3, also with zlib 1.1.3, and 1.1.4,
so I have no idea, perhaps you have...





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

#20871 [Fbk->NoF]: Apache restarts with no output

[sniper]

 ID:   20871
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: IMAP related
 Operating System: win2K
 PHP Version:  4.3.0-dev
 New Comment:

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




Previous Comments:


[2003-01-27 02:53:27] [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-26 12:34:10] [EMAIL PROTECTED]

Yes. The crash happens with any e-mail. Does not depend on the e-mail
encoding or charset or whatever. It happens, I suppose, in
imap_fetchbody, the function I use to get the raw e-mail headers (the
used to fall into section #0 of the e-mail body, no matter if mail had
any parts). 
As to the script - the PHP-file I use to test the bug is constantly
growing as I add more debug output to find the exact point where the
'crash' occurs.

As to the servers - there are many if them. WinRoute's internal pop3
server (my local), and some other servers on the net (mail.ru,
goals.ru, valuehost.ru) - these are the servers I tried. 

Local testing reports that the mails get transferred to PHP. Even twice
(so if the mailbox occupies 100Kbytes of mail for user, the total
session traffic would be 200K).

Here is the script I use now (still crashiong with fetchbody):

$value)
   { 
echo "$prefix [$key] = $value ";
fputs($f, "$prefix [$key] = $value \n");


if (is_array($value))desc_arr($value, "$prefix [$key]");
if (is_object($value))desc_obj($value,"$prefix [$key]");
   }
  }

function desc_obj($obj, $prefix)
 { 
  global $f;
  foreach($obj as $key=>$value)
   { 
echo "$prefix -> $key = $value ";
fputs($f, "$prefix -> $key = $value \n");

if (is_array($value))desc_arr($value, "$prefix -> $key");
if (is_object($value))desc_obj($value,"$prefix -> $key");
   }
  }
   

fputs($f, "connecting to $server\n");
echo "connecting to $server";

$mbox = imap_open ("{".$server.":".$port."/pop3}INBOX", "$uname",
"$passw");



echo imap_last_error()."";
fputs($f,imap_last_error()."\n");

echo "Retrieving messages...";
fputs($f, "Retrieving messages...");

$totmsg=imap_num_msg($mbox);

 $check = imap_mailboxmsginfo($mbox);
 
if($check) {
print "Date: ". $check->Date."\n" ;
fputs($f, "Date: ". $check->Date."\n" );
print "Driver: "  . $check->Driver  ."\n" ;
print "Mailbox: " . $check->Mailbox ."\n" ;
print "Messages: ". $check->Nmsgs   ."\n" ;
print "Recent: "  . $check->Recent  ."\n" ;
print "Unread: "  . $check->Unread  ."\n" ;
print "Deleted: " . $check->Deleted ."\n" ;
print "Size: ". $check->Size."\n" ;
} else {
print "imap_check() failed: ".imap_last_error(). "\n";
fputs($f,"imap_check() failed: ".imap_last_error(). "\n");
}


if ($totmsg>0) {echo "some messages found";fputs($f,"some messages
found\n");}
if ($totmsg>0) echo "some messages found";
if ($totmsg>0) echo "some messages found line 3";
$headers=imap_search($mbox, "FROM @", 0);//


if (is_array($headers))
 {echo "Total messages found: ".count($headers)."/$totmsg";
  fputs($f,"Total messages found: ".count($headers)."/$totmsg\n");
  desc_arr($headers, "headers");

  }

while (list ($key,$val) = each ($headers)) {
 

unset($hdr);
$hdr=imap_headerinfo($mbox, ($val));
desc_obj($hdr, "HDR:");

echo "Plaintext is:".nl2br(imap_body($mbox,
($val)))."";
fputs($f,"Plaintext is:".nl2br(imap_body($mbox,
($val)))."\n");



echo "...Fetching structure";
fputs($f,"...Fetching structure\n");


unset($struc);
$struc=imap_fetchstructure($mbox,($val));

echo "struc assigned";
fputs($f, "struc assigned\n");

desc_obj($struc, "structure");
   

   if (isset($struc->parts))//There are some parts
{ 
 echo "there are ".count($struc->parts)." parts in the
message";
 fputs($f, "there are ".count($struc->parts)." parts in the
message\n");


  foreach($struc->parts as $num=>$part)
   { 
echo "foreach struc-parts started";
fputs($f, "foreach struc-parts started\n");

echo "Part $num";
fputs ($f, "Part $num\n");

if ($part->subtype=='PLAIN')
{
  echo "part subtype=PLAIN";
  fputs($f, "part subtype=PLAIN\n");

 

#21549 [Fbk->NoF]: problem with INGRES II permanent connexions

[sniper]

 ID:   21549
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: *Database Functions
 Operating System: HP-UX 11.00
 PHP Version:  4.2.1
 New Comment:

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




Previous Comments:


[2003-01-27 22:39:09] [EMAIL PROTECTED]

Any news about the patch to fix this?




[2003-01-09 08:45:10] [EMAIL PROTECTED]

Please send this patch to [EMAIL PROTECTED] (make sure you  have a
patch against either PHP 4.3.0 or the latest non-stable cvs version).

Derick



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

We use permanent connections to the Database INGRES II.  Connections
are not usable any more when the Database is offline.  When the base is
again available, open connections are not accessible any more.  the
only solution to purge connections is stop the Web server APACHE and
start . 
Also we modified the PHP INGRES II module in order to fix the problem. 
It's run in our company for several weeks without problem.  We can send
you the modify sources codes.  We have several hundreds of users access
INGRES database with PHP.
Sorry for the enghish.
Best Regards 
Pierre-Marie MOULIERE
ARC-INTERNATIONAL
41 Avenue du général de GAULLE
62510 ARQUES 
FRANCE
Web site : http://www.arc-international.com
email : [EMAIL PROTECTED]





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

#21863 [Fbk->Bgs]: PHP as SAPI under IIS brings down all web services trying to find php_mhash.dll

[sniper]

 ID:   21863
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Bogus
 Bug Type: IIS related
 Operating System: windows
 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.

Apparently an user error.



Previous Comments:


[2003-01-28 12:10:54] [EMAIL PROTECTED]

This is most likely an installation error..
Are you 100% sure you've replaced _all_ the
old dlls with the new ones from the PHP 4.3.0 release
package? Also the ones in dlls/ folder? And php4ts.dll?

(some people have said they had to reboot too...)




[2003-01-28 10:40:16] [EMAIL PROTECTED]

no error with cli: mhash loads ok, everything is fine.



[2003-01-24 11:15:43] [EMAIL PROTECTED]

Do you get an error loading php_mhash.dll with the CLI sapi?



[2003-01-24 11:05:34] [EMAIL PROTECTED]

IIS hangs when starting up with PHP 4.3.0 running as a SAPI module if I
try to load php_mhash.dll as an extension. The event viewer gives the
following message, classified as 'Information':

Application popup: Warning : Unknown(): Unable to load dynamic library
'D:\php-4.3.0-Win32\extensions\php_mhash.dll' - The specified module
could not be found.

... the World Wide Web Publishing Service then freezes, saying it's
'starting'. it does not respond to control messages from either 'net
stop' on the command line or other GUI controls. 

this is a bug because no other extensions fail in this manner, and
they're all in the same place, and everything works just fine with
exactly the same setup with PHP 4.2.3, also running in IIS as a SAPI. 

-fish 




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

#21872 [Fbk->NoF]: MSSQL/ODBC produce CGI Error:

[sniper]

 ID:   21872
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: MSSQL related
 Operating System: Windows 2000
 PHP Version:  4.3.0
 New Comment:

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




Previous Comments:


[2003-01-27 02:12:51] [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 related fixes which didn't make it to 4.3.0..so
please give the snapshot a go.




[2003-01-25 20:36:52] [EMAIL PROTECTED]

I have also made a test script on a dev box available to the outside
world.  If a PHP developer was interested in seeing the error I will
provide the link through e-mail.  Thanks.



[2003-01-25 20:19:32] [EMAIL PROTECTED]

Unfortunately, applying the aforementioned patches to my production
server does not eliminate the problem.  That box is a Dual Xeon of some
speed, as opposed to my single P4 testing box.  In order to exhibit the
error there, I re-create the test script above to hold 50 iframes.  I
see the error approximately one out of 400 requests in conjunction with
a MSSQL/ODBC call.  
I appologize for making you read all this.



[2003-01-25 18:21:01] [EMAIL PROTECTED]

As of this morning, I cannot duplicate the error on my test box
(Win2000 professional).  While I await the return of the CGI error, and
if anyone is curious, they could ponder the following changes I made to
my system.  I am not asking for this bug's state to be changed to BOGUS
or CLOSED, I just want to continue providing as much information as I
can.  I know there are a lot of people experiencing similar problems.
 
1)  I restarted my system, which I do every few weeks.  However, this
hasn't solved anything in the past, but I wanted to include it just
because it could offer a clue if the problem doesn't present itself
until X hours after a reboot.  (Probably not a good clue, but a clue
none-the-less).
 
2)  In restarting my system, I also applied the latest patches
recommended by Microsoft's Windows Update.  These patches were from the
last two weeks, and did not look to imply a fix for this issue.  Again,
these were the DEFAULT patches recommended.
 
3)  I picked two additional patches from Windows Update that were not
defaults.  If anyone savvy with the Win32 programming of PHP is
reading, I'd be curious if you could check out these two KB articles
and see if they could possibly relate.  The second one seems
particularly interesting, as it relates specifically to timing.
http://support.microsoft.com/default.aspx?scid=KB;en-us;Q322842
http://support.microsoft.com/default.aspx?scid=KB;en-us;Q322913
 
I think that is it.  I understand it is extremely poor troubleshooting
practice to attempt multiple 'fixes' at once, but when you've been
struggling with something for months you tend to get to the point where
you don't think any more changes will actually help anything.  At least
I can pinpoint the two added patches which might shed light on
something.
 
Again, I'll keep you posted and continue to test this issue, and would
be happy to respond with any information requested.



[2003-01-24 22:02:29] [EMAIL PROTECTED]

Additionally, I can offer the test script.  Here is a bare-bones
example.  Testing this just now, it will error on at least one of the 6
iframes EVERY refresh.  1/6 requests is an error.  Sorry the actual DSN
and SQL query does no good, but if you really wanted to try this it
will save a little hassle.
 
x";
  exit();
}

$sql_params = array(
  'DSN' => 'myDSN',
  'user' => 'user',
  'pass' => 'pass',
  'query' => 'SELECT DISTINCT field1 FROM table1',
);


$conn = odbc_connect($sql_params['DSN'], $sql_params['user'],
$sql_params['pass']) or die("Couldn't connect to SQL Server on
{$sql_params['DSN']}");
$conn_id = odbc_exec($conn, $sql_params['query']);
print odbc_num_fields($conn_id);
odbc_free_result($conn_id);
?>











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

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

#21874 [Fbk->NoF]: ini_get returns values from other vservers

[sniper]

 ID:   21874
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: PHP options/info functions
 Operating System: FreeBSD
 PHP Version:  4.2.2
 New Comment:

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




Previous Comments:


[2003-01-28 11:36:39] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





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

I have a file:

';
?>

And I have multiple virtual host specifications like:

{Domain names and file paths have been changed to protech the
innocent...}


ServerName myapp.site1.com
ServerAdmin [EMAIL PROTECTED]
DocumentRoot /home/mainapplication
php_admin_value upload_tmp_dir /home/client1/tmp
php_admin_value error_log /home/client1/log
php_value error_reporting 7
php_flag display_errors On
php_flag log_errors On
php_flag register_globals on
php_flag display_errors off



ServerName myapp.site2.com
ServerAdmin [EMAIL PROTECTED]
DocumentRoot /home/mainapplication
php_admin_value upload_tmp_dir /home/client2/tmp
php_admin_value error_log /home/client2/log
php_value error_reporting 7
php_flag display_errors On
php_flag log_errors On
php_flag register_globals on
php_flag display_errors off


N.B. When using PHPA, the problem is incredibly obvious (changes
continuously), however with it removed, and reloading the page HUNDREDS
of times, I saw this happen twice.

The only values displayed are those of ACTIVE virtual servers... at
least that is what seems to be happening.






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

#21910 [Fbk->NoF]: Can't authenticate if a '+' is in the password

[sniper]

 ID:   21910
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: PostgreSQL related
 Operating System: Linux 2.4
 PHP Version:  4.2.2
 New Comment:

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




Previous Comments:


[2003-01-27 14:56:09] [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

If it still does not work, please indicate how you are specifying the
connection string (separate arguments or a single connection string).



[2003-01-27 13:11:41] [EMAIL PROTECTED]

Attempts to authenticate against a postgres DB (v 7.2) if there's a '+'
in the password fails. If the password is "f00+f3ti5h", the error is:

[27-Jan-2003 10:33:42] PHP Warning:  pg_connect() unable to connect to
PostgreSQL server: missing "=" after "f3ti5h" in connection info
string

This error does not occur when accessing the same DB with the same
user/pass in a perl CGI running on the same server, and it goes away if
the '+' is removed from the password.




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

#21914 [Fbk->NoF]: imap_open() fails with iMail POP3 server

[sniper]

 ID:   21914
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: IMAP related
 Operating System: RedHat 7.2
 PHP Version:  4.2.3
 New Comment:

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




Previous Comments:


[2003-01-27 23:03:11] [EMAIL PROTECTED]

Yes, this is most likely a c-client problem.
But do try this call:

imap_open("{mail.imailserver.com:110/pop3/notls}INBOX", ..

(notice the 'notls' there..)

And what versions of c-client did you use to build
4.0.6 and 4.2.3? And what were the configure lines used?
It also depends a lot on how the c-client was build
and with what options..




[2003-01-27 22:20:15] [EMAIL PROTECTED]

I am to open a connection to an ipSwitch iMail ver 6.06 POP3 server
using imap_open(). I have tried this under RedHat 7.2 and FreeBSD with
PHP versions 4.2.3, 4.1.2 with the same results. Under FreeBSD ver
4.0.6 it works.

[jaime@lizard test]$ php -q test.php 

Warning:  Couldn't open stream
{mail.seismicom2.com:110/pop3}INBOX
 in .../test/test.php on line 3
Array
(
[0] => Retrying CRAM-MD5 authentication after 
[1] => Retrying CRAM-MD5 authentication after Invalid
userid/password
[2] => Retrying CRAM-MD5 authentication after illegal command
[3] => Retrying CRAM-MD5 authentication after authentication
exchange failed
[4] => Can not authenticate to POP3 server: authentication exchange
failed
)

[jaime@lizard test]$ cat test.php 


Is this a c-client problem?

Thanks,
Jaime





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

#22120 [NEW]: GetImageSize seems confused on certain JPGs from certain hosts

[1413]

From: [EMAIL PROTECTED]
Operating system: Linux 2.2.19 (Debian)
PHP version:  4.3.0
PHP Bug Type: GetImageSize related
Bug description:  GetImageSize seems confused on certain JPGs from certain hosts

GetImageSize() seems confused on certain JPGs from freeservers.  The JPG is
valid (you can load it from your web-browser).

Script to reproduce:
http://guildprime.8m.net/bug.jpg";);
if($res == FALSE)
{
  print("Erk! GetImageSize returned FALSE!");
} else {
  print_r($res);
}

print("");

$res = GetImageSize("http://guildprime.8m.net/notbug.jpg";);
if($res == FALSE)
{
  print("Erk! GetImageSize returned FALSE!");
} else {
  print_r($res);
}

?>

The script SHOULD report:
Array ( [0] => 396 [1] => 178 [2] => 2 [3] => width="396" height="178"
[bits] => 8 [channels] => 3 ) 
Array ( [0] => 800 [1] => 600 [2] => 2 [3] => width="800" height="600"
[bits] => 8 [channels] => 3 ) 

And it does when I copy the file to my local Apache web server and change
the script to point there instead.  It also works on a second server I
have running PHP 4.1.2.

However, with the URL listed, under PHP 4.3.0, it reports:
Erk! GetImageSize returned FALSE!
Array ( [0] => 800 [1] => 600 [2] => 2 [3] => width="800" height="600"
[bits] => 8 [channels] => 3 [mime] => image/jpeg ) 

Configuration options:
./configure  --with-apxs --with-zlib --with-bz2 --with-gd=/usr
--enable-gd-native-ttf --with-mysql=/usr --enable-sockets --prefix=/usr
--with-ttf --enable-ftp

Troubleshooting steps already taken:
- I tried copying the image to my local web server, changed the script to
look there, and it works.
- Dozens of other JPGs on freeservers work as well.
- It seems this combination of server and image file is causing
GetImageSize() to fail.  When I point my web browser at the same URL, the
picture comes up. 
- I tried putting the picture into GIMP and resaving out - the re-saved
image also has the same problems.  (This file is bug2.jpg at the same
site.)
- Running 'identify -verbose' on the files shows perhaps the difference of
Resolution (notbug.jpg is 300x300 pixels/inch, as are most of the other
pictures, while bug.jpg and bug2.jpg are at72x72 pixels/inch) may be part
of what's triggering it.
- I have re-downloaded the source, re-compiled and re-installed with the
above options, with no change in results.
- Running the script from the command line has no change in results.

All-in-all, quite strange...

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