#21323 [Fbk->NoF]: Session not initialised or not destroyed

[php-bugs]

 ID:   21323
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Apache2 related
 Operating System: RedHat 8
 PHP Version:  4.3.0
 New Comment:

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


Previous Comments:


[2003-01-07 10:03:02] [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-01 22:50:14] [EMAIL PROTECTED]

i have the same problem.

i use php4.3, apache2.0.43, redhat7.1

i think it should be fix ASAP.

thanx.



[2003-01-01 20:11:27] [EMAIL PROTECTED]

I installed PHP 4.3.0 just after Apache 2.0.43
All was working except sessions.
The problem is the following : 

When I auth myself, it reloads the same page but some info change to
show I'm logged in. (in normal case)

With Apache2, PHP 4.3.0, the session wasn't initialized.
The problem has occured with XoopS 1.3.7

With the latest CVS files (4.4.0-dev), all's working well.

Hope this helps




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

#21342 [Fbk->NoF]: Compile error

[php-bugs]

 ID:   21342
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Compile Failure
 Operating System: Solaris 8/sparc
 PHP Version:  4.3.0
 New Comment:

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


Previous Comments:


[2003-01-07 09:42:56] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

Looks like this was fixed/changed in code already.  Give it a try and
let us know.



[2003-01-02 13:06:55] [EMAIL PROTECTED]

php-4.3.0/ext/gd/gd.c: In function `zif_imageloadfont':
php-4.3.0/ext/gd/gd.c:609: incompatible types in assignment
php-4.3.0/ext/gd/gd.c:610: incompatible type for argument 2 of
`_php_stream_seek'
php-4.3.0/ext/gd/gd.c:611: invalid operands to binary -
php-4.3.0/ext/gd/gd.c:612: incompatible type for argument 2 of
`_php_stream_seek'

OS - Solaris 8/sparc
GCC 3.1
GD 2.0.1 with gif support
freetype 2.1.0

Configure options:
'./configure' '--enable-rule=EAPI'
'--with-apxs=/usr/local/apache/bin/apxs' ... '--with-gd=/usr'
'--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local'
'--with-freetype-dir=/usr/local' '--enable-gd-native-ttf' 




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

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

[sniper]

 ID:   21284
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: *Configuration Issues
 Operating System: AIX 4.3.3
 PHP Version:  4.3.0
 New Comment:

Please try using this CVS snapshot:

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

I removed the part that most likely caused that error,
so please try new snapshot in about 2 hours from now.



Previous Comments:


[2003-01-23 00:27:15] [EMAIL PROTECTED]

i'm using php4-STABLE-200301220630
and following output appears end of configure process but PHP compiled
and works fine..
--- cut here ---
./config.status[1787]: 6: bad file unit number
./config.status[1788]: 6: bad file unit number
--- cut here ---



[2003-01-21 18:56: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

This should be fixed already..




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

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



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

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

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


and following output :
--- cut here 

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




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

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

[tolga]

 ID:   21284
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: *Configuration Issues
 Operating System: AIX 4.3.3
 PHP Version:  4.3.0
 New Comment:

i'm using php4-STABLE-200301220630
and following output appears end of configure process but PHP compiled
and works fine..
--- cut here ---
./config.status[1787]: 6: bad file unit number
./config.status[1788]: 6: bad file unit number
--- cut here ---


Previous Comments:


[2003-01-21 18:56: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

This should be fixed already..




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

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



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

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

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


and following output :
--- cut here 

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




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

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

[fishrunsrap]

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

ok, I will try this tomorrow in the AM, but I have to ask: what has
changed from 4.2.3 to 4.3.0 to make this type of implicit
pass-by-reference thing happen? why does it work perfectly normally in
4.2.3? I could find nothing in the changelog that referred to this
issue.


Previous Comments:


[2003-01-22 22:04:54] [EMAIL PROTECTED]

About this:

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

Have you tried adding 'error_reporting(E_ALL);' in the beginning of the
script? You propably get some warnings?

Try changing the call to:

return mssql_bind($stmt,$name,$outref,$type, true,false); 

ie. don't pass $outref by reference, it's done internally..




[2003-01-21 14:54:03] [EMAIL PROTECTED]

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



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

the following test script:

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

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

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

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

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


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



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

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




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

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

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


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


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

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

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

-fish





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

#21835 [Bgs]: Crashes with 6 slashes in URL and non-existant file

[info]

 ID:   21835
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: GetImageSize related
 Operating System: Win 2000 IIS (CGI)
 PHP Version:  4.3.0
 New Comment:

sorry - i wasn't sure, since the last report was changed to 'bogus' if
it's already part of history and also the new summary field is more
exact. i will follow with comments with previous report (21479)


Previous Comments:


[2003-01-22 23:24:51] [EMAIL PROTECTED]

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

Thank you for your interest in PHP.

don\'t submit two reports about same issue..




[2003-01-22 23:04:36] [EMAIL PROTECTED]

please read carefully. this crashes PHP. (i.e. PHP.exe causes a GPF) 

the code is:
http://domain/dir1/dir2/dir3/image.gif');
?>

make sure the path:
http://domain/dir1/dir2/dir3/
containts THREE directories after the domain (i.e. 6 forward-slashes
total), and that the PATH physically EXISTS.

AND make sure that the file (in code 'image.gif') DOES NOT exist.

You can test against:
http://economads.com/libaware/_font/title/image.gif

This crashes on my server - running PHP 4.3.0 as CGI with IIS Win2000.


Hope this helps.




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

#21829 [Opn]: fsockopen() crashes on 2 of 3 servers (w/ gdb trace)

[michael]

 ID:   21829
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Sockets related
 Operating System: mandrake 8.2, 2.4.18-8.1mdk
 PHP Version:  4.3.0
 New Comment:

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.


Previous Comments:


[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

#21479 [Opn]: function crashes when used with a URL

[sniper]

 ID:   21479
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: GetImageSize related
 Operating System: Windows 2000
 PHP Version:  4.3.0
 New Comment:

I can not reproduce this within Linux, I guess this is
yet another windows only bug..



Previous Comments:


[2003-01-22 22:58:12] [EMAIL PROTECTED]

HOLD IT - I just found out exactly how to reproduce it. please read
carefully.

the code is:
http://domain/dir1/dir2/dir3/image.gif');
?>

make sure the path:
http://domain/dir1/dir2/dir3/
containts THREE directories after the domain (i.e. 6 forward-slashes
total), and that the PATH physically EXISTS.

AND make sure that the file (in code 'image.gif') DOES NOT exist.

You can test against:
http://economads.com/libaware/_font/title/image.gif

This crashes on my server - running PHP 4.3.0 as CGI with IIS Win2000.


Hope this helps.



[2003-01-20 17:13:18] [EMAIL PROTECTED]

Ahha..so you had propably the old php4ts.dll there, from
previous version...




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

crashes means gpf .. a windows application error, and then error cgi
returned wrong headers, etc.

anyway, i have installed 4.3.0 once again (removed it after discovering
crash), and not like last time - rebooted the machine - and it seems to
fix the problem.



[2003-01-20 14:41:41] [EMAIL PROTECTED]

What do you mean with 'crashes' ? And does getimagesize()
work for local files?  
or something like that..?




[2003-01-20 12:43:30] [EMAIL PROTECTED]

OK - just checked, and php crashes regardless of the '@'  before
getimagesize



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

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

#19983 [Com]: Compile/Link failure w/Sablotron

[llaguno]

 ID:   19983
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Mac OS X 10.2
 PHP Version:  4.3.0-pre1
 New Comment:

Compile errors with Sablotron during php make on Redhat linux 8.0

I was just wondering if you can help me figure out the following errors

during php make.  


Note that environment is as follows:

expat-1.95.5-1

sablotron-0.97-1

php-4.2.2-8.0.5 (current, want to upgrade to 4.3.0)

httpd-2.0.40-8 (redhat linux 8.0)

The  problem occurs even after I erased the php-4.2 rpm.
-





 >  cd /usr/local/php/php-4.3.0

 > ./configure --enable-xslt --with-xslt-sablot --with-zlib

 

 > make

ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam':

/usr/local/php/php-4.3.0/ext/mysql/libmysql/my_tempnam.c:103: the use
of 

`tempnam' is dangerous, better use `mkstemp'

/usr/local/lib/libsablot.so: undefined reference to `operator 

new[](unsigned)'

/usr/local/lib/libsablot.so: undefined reference to `vtable for 

__cxxabiv1::__si_class_type_info'

/usr/local/lib/libsablot.so: undefined reference to `operator
delete(void*)'

/usr/local/lib/libsablot.so: undefined reference to
`__gxx_personality_v0'

/usr/local/lib/libsablot.so: undefined reference to
`__cxa_pure_virtual'

/usr/local/lib/libsablot.so: undefined reference to `vtable for 

__cxxabiv1::__class_type_info'

/usr/local/lib/libsablot.so: undefined reference to `operator 

delete[](void*)'

/usr/local/lib/libsablot.so: undefined reference to `vtable for 

__cxxabiv1::__vmi_class_type_info'

/usr/local/lib/libsablot.so: undefined reference to `operator
new(unsigned)'

collect2: ld returned 1 exit status

make: *** [sapi/cgi/php] Error 1




> make install  --> same results as above

I would really appreciate your help.  



Thanks in advance, Manny


Previous Comments:


[2002-12-27 15:07:38] [EMAIL PROTECTED]

Just got the first 4.3.0 release and cannot build
under Solaris due to "line too long" when attempting 
make.  That is followed, of course, with millions of
undefined symbols.

my configure:

./configure \
  --with-apache=/apa/ \
  --with-jpeg-dir=/usr/local \
  --with-zlib-dir=/usr/local \
  --with-jpeg-dir=/usr/local \
  --with-png-dir=/usr/local \
  --with-gd \
  --with-oci8=/export/home/orahome \
  --enable-ftp \
  --enable-sockets \
  --with-pdflib \
  --with-ming >configure.log 2>&1 &
all goes fine until attempt "make"
(both solaris and gnu makes same)

NO DICE.



[2002-12-18 11:55:34] [EMAIL PROTECTED]

The problem __really__ is, combining gcc3 and gcc2 suite, as outlined
in this document:
http://fink.sourceforge.net/doc/porting/preparing.php

Secondly - if any warnings/errors occur as mentioned in the document
above (libtool stuff), the links to patches for those are provided. PHP
already has this covered.

The following works:
1) configure expat, using gcc2 explicetely:
CC=gcc2 \
./configure \
--prefix=/your/prefix

2) configure libiconv, the same way:
CC=gcc2 \
./configure \
--prefix=/your/prefix

3) configure Sablotron (tested with 0.97RC2) using:
CC=gcc2 \
CXX=g++2 \
./configure \
--prefix=/your/prefix \
--with-expat-prefix=/your/prefix \
--with-iconv-prefix=/your/prefix

PHP can then be configured, using:
CC=gcc2 \
CXX=g++2 \
./configure \
--prefix=/your/prefix \
--disable-cgi \
--enable-xslt \
--with-xslt-sablot=/your/prefix \
--with-expat-dir=/your/prefix \
--with-iconv-dir=/your/prefix 

I guess the same applies to gcc3, but you have to make sure, that all
libs you include, are compiled with gcc3/g++3 then.



[2002-12-17 13:57:23] [EMAIL PROTECTED]

I don't think his workaround works... Putting the -lstdc++ 
on the end of the ZEND_EXTRA_LIBS variable enables 
everything to make, but I cannot make install and I 
certainly can't run with Apache... I get similar errors 
that [EMAIL PROTECTED] (above) gets.  I know this is kind 
of a 'me too' response, but I want to emphasize that there 
is NO workaround.  Thanks!

During make install:

Installing PHP CLI binary:/usr/local/bin/
Installing PEAR environment:  /usr/local/lib/php/
dyld: /usr/local/src/build-php-4.3.0RC3/php-4.3.0RC3/sapi/
cli/php Undefined symbols:
__ZTVN10__cxxabiv117__class_type_infoE
__ZTVN10__cxxabiv120__si_class_type_infoE
__ZdaPv
__ZdlPv
__Znwm
___gxx_personality_v0
__ZSt9terminatev
__Znam
__ZTVN10__cxxabiv121__vmi_class_type_infoE
___cxa_pure_virtual
make[1]: *** [install-pear-installer] Trace/BPT trap
make: *** [install-pear] Error 2

--

#21835 [Opn->Bgs]: Crashes with 6 slashes in URL and non-existant file

[sniper]

 ID:   21835
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: GetImageSize related
 Operating System: Win 2000 IIS (CGI)
 PHP Version:  4.3.0
 New Comment:

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

Thank you for your interest in PHP.

don't submit two reports about same issue..



Previous Comments:


[2003-01-22 23:04:36] [EMAIL PROTECTED]

please read carefully. this crashes PHP. (i.e. PHP.exe causes a GPF) 

the code is:
http://domain/dir1/dir2/dir3/image.gif');
?>

make sure the path:
http://domain/dir1/dir2/dir3/
containts THREE directories after the domain (i.e. 6 forward-slashes
total), and that the PATH physically EXISTS.

AND make sure that the file (in code 'image.gif') DOES NOT exist.

You can test against:
http://economads.com/libaware/_font/title/image.gif

This crashes on my server - running PHP 4.3.0 as CGI with IIS Win2000.


Hope this helps.




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

#14542 [Ver->Csd]: register_shutdown_function() timeout problem

[sniper]

 ID:   14542
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Verified
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: Linux 2.4.5
 PHP Version:  4.3.0
 New Comment:

This bug has been fixed in CVS.

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

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




Previous Comments:


[2003-01-10 22:23:58] [EMAIL PROTECTED]

Verified with latest CVS and 4.3.0.



[2002-12-08 10:38:04] [EMAIL PROTECTED]

Verified with 4.3.0-dev at this date.




[2002-06-16 00:11:57] [EMAIL PROTECTED]

reclassified.




[2002-04-27 19:09:27] [EMAIL PROTECTED]

It's not fixed..




[2002-04-27 10:08:11] [EMAIL PROTECTED]

Fixed in CVS



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

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

#21835 [NEW]: Crashes with 6 slashes in URL and non-existant file

[info]

From: [EMAIL PROTECTED]
Operating system: Win 2000 IIS (CGI)
PHP version:  4.3.0
PHP Bug Type: GetImageSize related
Bug description:  Crashes with 6 slashes in URL and non-existant file

please read carefully. this crashes PHP. (i.e. PHP.exe causes a GPF) 

the code is:
http://domain/dir1/dir2/dir3/image.gif');
?>

make sure the path:
http://domain/dir1/dir2/dir3/
containts THREE directories after the domain (i.e. 6 forward-slashes
total), and that the PATH physically EXISTS.

AND make sure that the file (in code 'image.gif') DOES NOT exist.

You can test against:
http://economads.com/libaware/_font/title/image.gif

This crashes on my server - running PHP 4.3.0 as CGI with IIS Win2000. 

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

#21479 [Bgs->Opn]: function crashes when used with a URL

[info]

 ID:   21479
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: GetImageSize related
 Operating System: Windows 2000
 PHP Version:  4.3.0
 New Comment:

HOLD IT - I just found out exactly how to reproduce it. please read
carefully.

the code is:
http://domain/dir1/dir2/dir3/image.gif');
?>

make sure the path:
http://domain/dir1/dir2/dir3/
containts THREE directories after the domain (i.e. 6 forward-slashes
total), and that the PATH physically EXISTS.

AND make sure that the file (in code 'image.gif') DOES NOT exist.

You can test against:
http://economads.com/libaware/_font/title/image.gif

This crashes on my server - running PHP 4.3.0 as CGI with IIS Win2000.


Hope this helps.


Previous Comments:


[2003-01-20 17:13:18] [EMAIL PROTECTED]

Ahha..so you had propably the old php4ts.dll there, from
previous version...




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

crashes means gpf .. a windows application error, and then error cgi
returned wrong headers, etc.

anyway, i have installed 4.3.0 once again (removed it after discovering
crash), and not like last time - rebooted the machine - and it seems to
fix the problem.



[2003-01-20 14:41:41] [EMAIL PROTECTED]

What do you mean with 'crashes' ? And does getimagesize()
work for local files?  
or something like that..?




[2003-01-20 12:43:30] [EMAIL PROTECTED]

OK - just checked, and php crashes regardless of the '@'  before
getimagesize



[2003-01-20 04:02:28] [EMAIL PROTECTED]

Please use the 'Edit Submission' link when adding
a comment to your own report.

And do you get any error with the getimagesize() ?
(remove that @ in front of it)




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

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

#21513 [Fbk->Ver]: shutdown functions not executed if timed out

[sniper]

 ID:   21513
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Verified
 Bug Type: Scripting Engine problem
-Operating System: WinXP
+Operating System: windows (only)
 PHP Version:  4.3.0
 New Comment:

I can not reproduce this with PHP CGI/CLI/Apache DSO,
but Steph tested the script under windows and
got the same results as [EMAIL PROTECTED] did so this is
definately a windows-only bug.



Previous Comments:


[2003-01-22 02:09:49] [EMAIL PROTECTED]

[EMAIL PROTECTED]:
> This script works just fine for me (using CLI):
> [skipped]

I tested your script. The output is:

PHP Fatal error:  Maximum execution time of 1 second exceeded in
c:\exp.php on line 16
PHP Fatal error:  Maximum execution time of 1 second exceeded in
c:\exp.php on line 7

"test.log" contains only one "Start" line.

I tried with both my own (pretty much cleaned up) php.ini and
"recommended" php.ini.
I suspect it is only Windows-related problem.



[2003-01-20 22:47:06] [EMAIL PROTECTED]

And this is related to http://bugs.php.net/bug.php?id=14542
(and maybe to http://bugs.php.net/bug.php?id=14251 ?)




[2003-01-20 22:44:38] [EMAIL PROTECTED]

This script works just fine for me (using CLI):



In test.log I have now:
cut
Start
Shutdown - function 'foo'
cut

Which is the expected output.
Can you try this script?




[2003-01-08 02:53:17] [EMAIL PROTECTED]

This problem is absolutely critical if you do DB cleanups, transactions
processing or other similar things in shutdown functions. Can be
especially bad if you need to commit/rollback transactions with
persistent DB connections.

--

--

Error message:

Fatal error: Maximum execution time of 3 seconds exceeded in c:\exp.php
on line 10

Fatal error: Maximum execution time of 3 seconds exceeded in c:\exp.php
on line 4

Does not depend on whether we run script as CGI/SAPI or CLI.

Report #14542 looks similar but is different IMHO.




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

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

[pmoulding]

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

http://snaps.php.net/win32/php4-win32-STABLE-latest.zip 20020123 is
working with just the default memory under Apache 2.0.44. Including
stacks of files, using Expat, XML, and creating gazillions of objects.
No errors so far.


Previous Comments:


[2003-01-22 21:55:40] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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


There was some memorylimit crash fixed recently
so please try the snapshot.

Anyway, about apache2..it's REALLY not ready for 
production at ALL, especially with PHP.
Apache 1.3.27 is the best choice.




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

When I opened the error report, I did not know the error could be
deferred by adding more memory. Now that I know the extra memory defers
the problem, I can allocate extra memory.

Allocating extra memory might not be practical for all people
especially those with hosted sites where the ISP restricts php.ini
changes.

Crashing Apache is also bad form. I know Apache 2 is considered new.
Anything newer than Apache release 1.0.1 is too new for some people. A
lot of people now use Apache 2 on production servers and PHP 4.3.0 must
be bullet proof in that environment by now. 

I will upgrade to Apache 2.0.44 then test using just 8 Mb and see if
the problem occurs. If someone out there knows of compatibility and
stability issues with Apache 2, they might like to suggest the best
release for use with PHP 4.3.0. I have downloads 2.0.39, 2.0.43, and
2.0.44.



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

So what's the bug here? If you run out of memory, how can
that be a PHP bug? :)




[2003-01-22 17:44:35] [EMAIL PROTECTED]

The require_once error has not occurred when using 80Mb.

The original require structure ended up including every component in
the system. I added a few if statements to include only those
components required for the script. The original mess might have used
up the default 8Mb of memory. My clean version probably uses less than
1 Mb for my code.

I am using the PHP binary compiled with all options. I think that comes
to about 4 Mb. If that 4 Mb is loaded in to the default 8Mb when
running PHP as a module then my original code would have easily used
the remaining 4 Mb. Changing the allocation to 80Mb may have, in
effect, increased available memory from 4 Mb to 76 Mb.



[2003-01-22 17:28:25] [EMAIL PROTECTED]

Has the change on memory_limit entry solved the require_once problem
too?




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

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

#21832 [Opn->Bgs]: GD only returns garbage characters

[sniper]

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


You really need to ask support questions on e.g.
[EMAIL PROTECTED]




Previous Comments:


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

Sorry... I meant There is NO error reported in any of my log files!!



[2003-01-22 22:07:31] [EMAIL PROTECTED]

All php exemples on using GD library returns no image but trash
characters like

returns 
‰PNG  IHDR2d
þ&ñPLTEÿÿÿé[‘˝£ 
there is error reported in my log.

I'm using Apache 1.3.26, PHP 4.3, GD 2 and windows 2000.
my php.ini is configured ok, the phpinfo() returns that GD is installed
and jpeg, png and stuff are supported.

Could this be just a misconfiguration? Or something else?




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

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

[philip]

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

The point of asking for var_dump(ini_get('include_path')); is so you'll
show the output of it.  This is a form of debugging.

The problem has to do with the include_path directive.  Now we're
trying to figure out why/where it gets set to '' before doing some of
these includes as this seems to be the case.

So, whenever you get this error:

Warning: main() [function.main]: Failed opening 'foo.php'...

Add this line above the include:

var_dump(array(ini_get('include_path'),__LINE__,__FILE));

This way we'll know some useful information.  Basically put this line
above EVERY one of these failed includes, such as the inclusion
config.php, extra.php, and lang.php.  

Please do this and show the output in your next reply.  Btw, I modified
Wez's debug dump a little so we can be a little more specific :)  Also,
be 100% sure you are not setting this directive in either httpd.conf or
.htaccess.


Previous Comments:


[2003-01-22 10:38:48] [EMAIL PROTECTED]

Hello Wez:

Not it does not look like that.  I was asked to include
var_dump(ini_get('include_path'));

before the require_once statement in the primary script,
phpbug21674.php

Remember there are two scripts located in different paths representing
two different virtual domains.

/home/site3/phpbug21674.php (contains a require_once
("/home/sites/site2/web/IV/config.php");

and /home/sites/site2/web/IV/config.php" ---> contains
include_once ('lang.php');
include ('extras.php'); 

However, I did go back and also added the var_dump to config.php to
reflect as follows:

var_dump(ini_get('include_path'));
include_once ('lang.php');
include ('extras.php'); 


Results: Same results = Failed to create stream:

Again, this script worked fine on PHP 4.1.2 Now it seems to get it to
work, I have to reference the absolute path.



[2003-01-22 05:00:55] [EMAIL PROTECTED]

Just to be extra sure:

in config.php, do lines 97 and 98 look like this:

var_dump(ini_get('include_path'));
include ('extras.php');

If not, please make sure they do and report back.
If they do, then something really strange is going on.



[2003-01-21 22:52:29] [EMAIL PROTECTED]

Hello PHP.NET:

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



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

Did you try ? :

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

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

Don't know why. 

Cordialy.



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

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



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

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

#21832 [Opn]: GD only returns garbage characters

[joaopaulo . margon]

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

Sorry... I meant There is NO error reported in any of my log files!!


Previous Comments:


[2003-01-22 22:07:31] [EMAIL PROTECTED]

All php exemples on using GD library returns no image but trash
characters like

returns 
‰PNG  IHDR2d
þ&ñPLTEÿÿÿé[‘˝£ 
there is error reported in my log.

I'm using Apache 1.3.26, PHP 4.3, GD 2 and windows 2000.
my php.ini is configured ok, the phpinfo() returns that GD is installed
and jpeg, png and stuff are supported.

Could this be just a misconfiguration? Or something else?




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

#21832 [NEW]: GD only returns garbage characters

[joaopaulo . margon]

From: [EMAIL PROTECTED]
Operating system: windows 2000
PHP version:  4.3.0
PHP Bug Type: GD related
Bug description:  GD only returns garbage characters

All php exemples on using GD library returns no image but trash characters
like

returns 
‰PNG  IHDR2d
þ&ñPLTEÿÿÿé[‘˝£ 
there is error reported in my log.

I'm using Apache 1.3.26, PHP 4.3, GD 2 and windows 2000.
my php.ini is configured ok, the phpinfo() returns that GD is installed
and jpeg, png and stuff are supported.

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

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

[sniper]

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

About this:

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

Have you tried adding 'error_reporting(E_ALL);' in the beginning of the
script? You propably get some warnings?

Try changing the call to:

return mssql_bind($stmt,$name,$outref,$type, true,false); 

ie. don't pass $outref by reference, it's done internally..



Previous Comments:


[2003-01-21 14:54:03] [EMAIL PROTECTED]

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



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

the following test script:

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

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

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

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

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


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



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

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




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

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

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


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


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

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

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

-fish





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

#21804 [Opn->Fbk]: php crashes iPlanet - php4_execute

[sniper]

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

Does the crash happen only with the provided script?
And btw. you should set those envinronment variables
in the system, NOT in the script..



Previous Comments:


[2003-01-21 13:29:00] [EMAIL PROTECTED]

Had the wrong email addr...



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

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

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

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

Finally, here are the two scripts:
---


PHP Operational Qualification Test

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


The classic announcement: 


PHP Info for this installation:







PHP Operational Qualification Test: Oracle Connectivity

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


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




Thanks,
David





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

#21803 [Opn->Fbk]: php4ts.dll crash with COM

[sniper]

 ID:   21803
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: COM related
 Operating System: Win Me
 PHP Version:  4.3.0
 New Comment:

Please try using this CVS snapshot:

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


Previous Comments:


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

hello,
while trying to run a script that opens a msaccess database, i get an
"access violation" error for php4ts.dll and php crashes.
this is the point where the error occurs:
$conn = new COM("ADODB.Connection");
I am using Windows Me, PHP 4.3.0 on an Apache 2.0
can someone please help?
thank u




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

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

[sniper]

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

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 was some memorylimit crash fixed recently
so please try the snapshot.

Anyway, about apache2..it's REALLY not ready for 
production at ALL, especially with PHP.
Apache 1.3.27 is the best choice.



Previous Comments:


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

When I opened the error report, I did not know the error could be
deferred by adding more memory. Now that I know the extra memory defers
the problem, I can allocate extra memory.

Allocating extra memory might not be practical for all people
especially those with hosted sites where the ISP restricts php.ini
changes.

Crashing Apache is also bad form. I know Apache 2 is considered new.
Anything newer than Apache release 1.0.1 is too new for some people. A
lot of people now use Apache 2 on production servers and PHP 4.3.0 must
be bullet proof in that environment by now. 

I will upgrade to Apache 2.0.44 then test using just 8 Mb and see if
the problem occurs. If someone out there knows of compatibility and
stability issues with Apache 2, they might like to suggest the best
release for use with PHP 4.3.0. I have downloads 2.0.39, 2.0.43, and
2.0.44.



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

So what's the bug here? If you run out of memory, how can
that be a PHP bug? :)




[2003-01-22 17:44:35] [EMAIL PROTECTED]

The require_once error has not occurred when using 80Mb.

The original require structure ended up including every component in
the system. I added a few if statements to include only those
components required for the script. The original mess might have used
up the default 8Mb of memory. My clean version probably uses less than
1 Mb for my code.

I am using the PHP binary compiled with all options. I think that comes
to about 4 Mb. If that 4 Mb is loaded in to the default 8Mb when
running PHP as a module then my original code would have easily used
the remaining 4 Mb. Changing the allocation to 80Mb may have, in
effect, increased available memory from 4 Mb to 76 Mb.



[2003-01-22 17:28:25] [EMAIL PROTECTED]

Has the change on memory_limit entry solved the require_once problem
too?




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

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



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

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

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

[pmoulding]

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

When I opened the error report, I did not know the error could be
deferred by adding more memory. Now that I know the extra memory defers
the problem, I can allocate extra memory.

Allocating extra memory might not be practical for all people
especially those with hosted sites where the ISP restricts php.ini
changes.

Crashing Apache is also bad form. I know Apache 2 is considered new.
Anything newer than Apache release 1.0.1 is too new for some people. A
lot of people now use Apache 2 on production servers and PHP 4.3.0 must
be bullet proof in that environment by now. 

I will upgrade to Apache 2.0.44 then test using just 8 Mb and see if
the problem occurs. If someone out there knows of compatibility and
stability issues with Apache 2, they might like to suggest the best
release for use with PHP 4.3.0. I have downloads 2.0.39, 2.0.43, and
2.0.44.


Previous Comments:


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

So what's the bug here? If you run out of memory, how can
that be a PHP bug? :)




[2003-01-22 17:44:35] [EMAIL PROTECTED]

The require_once error has not occurred when using 80Mb.

The original require structure ended up including every component in
the system. I added a few if statements to include only those
components required for the script. The original mess might have used
up the default 8Mb of memory. My clean version probably uses less than
1 Mb for my code.

I am using the PHP binary compiled with all options. I think that comes
to about 4 Mb. If that 4 Mb is loaded in to the default 8Mb when
running PHP as a module then my original code would have easily used
the remaining 4 Mb. Changing the allocation to 80Mb may have, in
effect, increased available memory from 4 Mb to 76 Mb.



[2003-01-22 17:28:25] [EMAIL PROTECTED]

Has the change on memory_limit entry solved the require_once problem
too?




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

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



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

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

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



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

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

#21831 [Opn->Fbk]: PHP fails to build on MySQL section

[sniper]

 ID:   21831
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
-Bug Type: *Compile Issues
+Bug Type: MySQL related
 Operating System: Linux/Redhat 8.0.92
 PHP Version:  4.3.0
 New Comment:

What gcc version?
And does this work:

# rm config.cache
# make clean
# ./configure
# make

??




Previous Comments:


[2003-01-22 21:40:55] [EMAIL PROTECTED]

Had marked in configuration as opposed to compile by accident.



[2003-01-22 21:37:07] [EMAIL PROTECTED]

  Not sure if this is a problem of my own making or not, but something
I've been profoundly frustrated with.  I'm running Redhat 8.0.92
(Phoebe - Beta) with Apache 2.0.44 (tried .43 as well) and MySQL.  I
run into what appears to be the same error whether I use
--with-mysql=/path/to/mysql or leave it built with the internal MySQL
access libraries.  

  When using the following build string:

./configure --with-apxs2=/opt/apache/bin/apxs --with-mysql=/opt/mysql/
--with-gettext --with-zlib --enable-track-vars
--enable-force-cgi-redirect

I get the following results:

checking for mysql_close in -lmysqlclient... no
checking for mysql_error in -lmysqlclient... no
configure: error: mysql configure failed. Please check config.log for
more information.

Inside config.log I see:

configure:47975: gcc -o conftest -g -O2
-L/opt/mysql//lib
conftest.c -lmysqlclient  -lz -lcrypt -lresolv -lm -ldl -lnsl 
-lcrypt 1>&5
/opt/mysql//lib/libmysqlclient.a(my_malloc.o)(.text+0x28): In function
`my_mallo
c':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_realloc.o)(.text+0x65): In function
`my_real
loc':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_lib.o)(.text+0x2e1): In function
`my_dir':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_lib.o)(.text+0x3d1): In function
`my_stat':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_getwd.o)(.text+0x44): In function
`my_getwd'
:
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_getwd.o)(.text+0xce): more
undefined referen
ces to `errno' follow
collect2: ld returned 1 exit status
configure: failed program was:
#line 47964 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char mysql_close();

int main() {
mysql_close()
; return 0; }
configure:48102: checking for mysql_error in -lmysqlclient
configure:48121: gcc -o conftest -g -O2
-L/usr/lib -L/opt/mysql//lib
-Wl,-rpath,/usr -L/usr conftest.c -lmysqlclient  -lz -lz
-lcrypt -lresol
v -lm -ldl -lnsl  -lcrypt 1>&5
/opt/mysql//lib/libmysqlclient.a(my_malloc.o)(.text+0x28): In function
`my_mallo
c':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_realloc.o)(.text+0x65): In function
`my_real
loc':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_lib.o)(.text+0x2e1): In function
`my_dir':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_lib.o)(.text+0x3d1): In function
`my_stat':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_getwd.o)(.text+0x44): In function
`my_getwd'
:
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_getwd.o)(.text+0xce): more
undefined referen
ces to `errno' follow
collect2: ld returned 1 exit status
configure: failed program was:
#line 48110 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char mysql_error();
int main() {
mysql_error()
; return 0; }

If I build without the --with-mysql=/opt/mysql, the configure script
completes correctly but during 'make' I get the following error:

ext/mysql/libmysql/my_tempnam.lo(.text+0x4c): In function
`my_tempnam':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_tempnam.c:103: the
use of `tempnam' is dangerous, better use `mkstemp'
ext/mysql/libmysql/my_lib.lo(.text+0x3d1): In function `my_dir':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_lib.c:169:
undefined reference to `errno'
ext/mysql/libmysql/my_lib.lo(.text+0x5ef): In function `my_stat':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_lib.c:588:
undefined reference to `errno'
ext/mysql/libmysql/my_malloc.lo(.text+0xde): In function `my_malloc':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_malloc.c:24:
undefined reference to `errno'
ext/mysql/libmysql/my_realloc.lo(.text+0xd5): In function
`my_realloc':
/home/downloads/web/php-4.3.

#21831 [Opn]: PHP fails to build on MySQL section

[jason]

 ID:   21831
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
-Bug Type: *Configuration Issues
+Bug Type: *Compile Issues
 Operating System: Linux/Redhat 8.0.92
 PHP Version:  4.3.0
 New Comment:

Had marked in configuration as opposed to compile by accident.


Previous Comments:


[2003-01-22 21:37:07] [EMAIL PROTECTED]

  Not sure if this is a problem of my own making or not, but something
I've been profoundly frustrated with.  I'm running Redhat 8.0.92
(Phoebe - Beta) with Apache 2.0.44 (tried .43 as well) and MySQL.  I
run into what appears to be the same error whether I use
--with-mysql=/path/to/mysql or leave it built with the internal MySQL
access libraries.  

  When using the following build string:

./configure --with-apxs2=/opt/apache/bin/apxs --with-mysql=/opt/mysql/
--with-gettext --with-zlib --enable-track-vars
--enable-force-cgi-redirect

I get the following results:

checking for mysql_close in -lmysqlclient... no
checking for mysql_error in -lmysqlclient... no
configure: error: mysql configure failed. Please check config.log for
more information.

Inside config.log I see:

configure:47975: gcc -o conftest -g -O2
-L/opt/mysql//lib
conftest.c -lmysqlclient  -lz -lcrypt -lresolv -lm -ldl -lnsl 
-lcrypt 1>&5
/opt/mysql//lib/libmysqlclient.a(my_malloc.o)(.text+0x28): In function
`my_mallo
c':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_realloc.o)(.text+0x65): In function
`my_real
loc':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_lib.o)(.text+0x2e1): In function
`my_dir':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_lib.o)(.text+0x3d1): In function
`my_stat':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_getwd.o)(.text+0x44): In function
`my_getwd'
:
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_getwd.o)(.text+0xce): more
undefined referen
ces to `errno' follow
collect2: ld returned 1 exit status
configure: failed program was:
#line 47964 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char mysql_close();

int main() {
mysql_close()
; return 0; }
configure:48102: checking for mysql_error in -lmysqlclient
configure:48121: gcc -o conftest -g -O2
-L/usr/lib -L/opt/mysql//lib
-Wl,-rpath,/usr -L/usr conftest.c -lmysqlclient  -lz -lz
-lcrypt -lresol
v -lm -ldl -lnsl  -lcrypt 1>&5
/opt/mysql//lib/libmysqlclient.a(my_malloc.o)(.text+0x28): In function
`my_mallo
c':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_realloc.o)(.text+0x65): In function
`my_real
loc':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_lib.o)(.text+0x2e1): In function
`my_dir':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_lib.o)(.text+0x3d1): In function
`my_stat':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_getwd.o)(.text+0x44): In function
`my_getwd'
:
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_getwd.o)(.text+0xce): more
undefined referen
ces to `errno' follow
collect2: ld returned 1 exit status
configure: failed program was:
#line 48110 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char mysql_error();
int main() {
mysql_error()
; return 0; }

If I build without the --with-mysql=/opt/mysql, the configure script
completes correctly but during 'make' I get the following error:

ext/mysql/libmysql/my_tempnam.lo(.text+0x4c): In function
`my_tempnam':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_tempnam.c:103: the
use of `tempnam' is dangerous, better use `mkstemp'
ext/mysql/libmysql/my_lib.lo(.text+0x3d1): In function `my_dir':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_lib.c:169:
undefined reference to `errno'
ext/mysql/libmysql/my_lib.lo(.text+0x5ef): In function `my_stat':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_lib.c:588:
undefined reference to `errno'
ext/mysql/libmysql/my_malloc.lo(.text+0xde): In function `my_malloc':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_malloc.c:24:
undefined reference to `errno'
ext/mysql/libmysql/my_realloc.lo(.text+0xd5): In function
`my_realloc':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_realloc.c:44:
undefined reference to `errno'
ext/mysql/libmysql/my_delete.lo(.text+0x86): In function `my_delete':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_delete.c:16:
undefined reference to `errno'
ext/m

#21830 [Bgs]: libphp4.so not created

[php . net]

 ID:   21830
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: RedHat 7.3
 PHP Version:  4.3.0
 New Comment:

I'll recompile Apache 2.0.44 again and try with the latest snapshot and
see what I get...

I appreciate you taking the time to confirm Apache 2.0.44 and PHP's
snapshot will work fine on RedHat 7.3

Thanks!


Previous Comments:


[2003-01-22 21:31:55] [EMAIL PROTECTED]

If it only happens with Apache2, I suggest you check your
apache2 installation and preferrably reinstall it anyway.
I just tried with latest Apache2 and it works just fine here.

In any case, this is not a PHP bug.




[2003-01-22 21:20:14] [EMAIL PROTECTED]

sapi/cli/php compiled successfully

I'll keep trying things to see if I can get libphp4.so created.



[2003-01-22 21:17:29] [EMAIL PROTECTED]

That is not an error..it's just a warning which can
safely be ignore. 




[2003-01-22 21:06:12] [EMAIL PROTECTED]

Results:
[snip]
ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam':
/bulk/jay/build/php4-STABLE-200301230230/ext/mysql/libmysql/my_tempnam.c:103:
the use of `tempnam' is dangerous, better use `mkstemp'


No libphp4.so created...

I will try your suggested configure options next



[2003-01-22 21:01:50] [EMAIL PROTECTED]

No, not -exactly- I have all current RPM's from RedHat via up2date
installed so I am sure gcc and glibc, for example, are the latest
version(s) and not what was installed last year.

Sorry about using the comment entry.



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

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

#21826 [Bgs->Csd]: variables dont return value even if they are seen in phpinfo()

[istankov]

 ID:   21826
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Closed
-Bug Type: *General Issues
+Bug Type: Output Control
 Operating System: windows 2000
 PHP Version:  4.2.3
 New Comment:

Problem solved, Thanks


Previous Comments:


[2003-01-22 19:23:56] [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.

[EMAIL PROTECTED]




[2003-01-22 17:05:19] [EMAIL PROTECTED]

My IIS5 crashes, and after reinstaling it, I can make any query to
MySQL base, or get any calculation on primary page, but when I want
some variable to PUT or GET to another script, I don't get it's value.
Another thing, when put on beggining of page command PHPINFO () i see
variables and it's values but scripts dont get them. 
Also I have been enabled REGISTER_GLOBALS in my Ini file. Please help
me to solve this problem. 





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

#21831 [NEW]: PHP fails to build on MySQL section

[jason]

From: [EMAIL PROTECTED]
Operating system: Linux/Redhat 8.0.92
PHP version:  4.3.0
PHP Bug Type: *Configuration Issues
Bug description:  PHP fails to build on MySQL section

  Not sure if this is a problem of my own making or not, but something I've
been profoundly frustrated with.  I'm running Redhat 8.0.92 (Phoebe -
Beta) with Apache 2.0.44 (tried .43 as well) and MySQL.  I run into what
appears to be the same error whether I use --with-mysql=/path/to/mysql or
leave it built with the internal MySQL access libraries.  

  When using the following build string:

./configure --with-apxs2=/opt/apache/bin/apxs --with-mysql=/opt/mysql/
--with-gettext --with-zlib --enable-track-vars
--enable-force-cgi-redirect

I get the following results:

checking for mysql_close in -lmysqlclient... no
checking for mysql_error in -lmysqlclient... no
configure: error: mysql configure failed. Please check config.log for more
information.

Inside config.log I see:

configure:47975: gcc -o conftest -g -O2
-L/opt/mysql//lib
conftest.c -lmysqlclient  -lz -lcrypt -lresolv -lm -ldl -lnsl  -lcrypt
1>&5
/opt/mysql//lib/libmysqlclient.a(my_malloc.o)(.text+0x28): In function
`my_mallo
c':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_realloc.o)(.text+0x65): In function
`my_real
loc':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_lib.o)(.text+0x2e1): In function
`my_dir':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_lib.o)(.text+0x3d1): In function
`my_stat':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_getwd.o)(.text+0x44): In function
`my_getwd'
:
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_getwd.o)(.text+0xce): more undefined
referen
ces to `errno' follow
collect2: ld returned 1 exit status
configure: failed program was:
#line 47964 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char mysql_close();

int main() {
mysql_close()
; return 0; }
configure:48102: checking for mysql_error in -lmysqlclient
configure:48121: gcc -o conftest -g -O2
-L/usr/lib -L/opt/mysql//lib
-Wl,-rpath,/usr -L/usr conftest.c -lmysqlclient  -lz -lz -lcrypt
-lresol
v -lm -ldl -lnsl  -lcrypt 1>&5
/opt/mysql//lib/libmysqlclient.a(my_malloc.o)(.text+0x28): In function
`my_mallo
c':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_realloc.o)(.text+0x65): In function
`my_real
loc':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_lib.o)(.text+0x2e1): In function
`my_dir':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_lib.o)(.text+0x3d1): In function
`my_stat':
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_getwd.o)(.text+0x44): In function
`my_getwd'
:
: undefined reference to `errno'
/opt/mysql//lib/libmysqlclient.a(my_getwd.o)(.text+0xce): more undefined
referen
ces to `errno' follow
collect2: ld returned 1 exit status
configure: failed program was:
#line 48110 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char mysql_error();
int main() {
mysql_error()
; return 0; }

If I build without the --with-mysql=/opt/mysql, the configure script
completes correctly but during 'make' I get the following error:

ext/mysql/libmysql/my_tempnam.lo(.text+0x4c): In function `my_tempnam':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_tempnam.c:103: the use
of `tempnam' is dangerous, better use `mkstemp'
ext/mysql/libmysql/my_lib.lo(.text+0x3d1): In function `my_dir':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_lib.c:169: undefined
reference to `errno'
ext/mysql/libmysql/my_lib.lo(.text+0x5ef): In function `my_stat':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_lib.c:588: undefined
reference to `errno'
ext/mysql/libmysql/my_malloc.lo(.text+0xde): In function `my_malloc':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_malloc.c:24: undefined
reference to `errno'
ext/mysql/libmysql/my_realloc.lo(.text+0xd5): In function `my_realloc':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_realloc.c:44:
undefined reference to `errno'
ext/mysql/libmysql/my_delete.lo(.text+0x86): In function `my_delete':
/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_delete.c:16: undefined
reference to `errno'
ext/mysql/libmysql/my_tempnam.lo(.text+0x89):/home/downloads/web/php-4.3.0/ext/mysql/libmysql/my_tempnam.c:108:
more undefined references to `errno' follow
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1


As I said, I'm not sure if this isn't a problem with RH 8

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

[sniper]

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

So what's the bug here? If you run out of memory, how can
that be a PHP bug? :)



Previous Comments:


[2003-01-22 17:44:35] [EMAIL PROTECTED]

The require_once error has not occurred when using 80Mb.

The original require structure ended up including every component in
the system. I added a few if statements to include only those
components required for the script. The original mess might have used
up the default 8Mb of memory. My clean version probably uses less than
1 Mb for my code.

I am using the PHP binary compiled with all options. I think that comes
to about 4 Mb. If that 4 Mb is loaded in to the default 8Mb when
running PHP as a module then my original code would have easily used
the remaining 4 Mb. Changing the allocation to 80Mb may have, in
effect, increased available memory from 4 Mb to 76 Mb.



[2003-01-22 17:28:25] [EMAIL PROTECTED]

Has the change on memory_limit entry solved the require_once problem
too?




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

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



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

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

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



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

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


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


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

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



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

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

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



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

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

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

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



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

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

#21830 [Opn->Bgs]: libphp4.so not created

[sniper]

 ID:   21830
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: RedHat 7.3
 PHP Version:  4.3.0
 New Comment:

If it only happens with Apache2, I suggest you check your
apache2 installation and preferrably reinstall it anyway.
I just tried with latest Apache2 and it works just fine here.

In any case, this is not a PHP bug.



Previous Comments:


[2003-01-22 21:20:14] [EMAIL PROTECTED]

sapi/cli/php compiled successfully

I'll keep trying things to see if I can get libphp4.so created.



[2003-01-22 21:17:29] [EMAIL PROTECTED]

That is not an error..it's just a warning which can
safely be ignore. 




[2003-01-22 21:06:12] [EMAIL PROTECTED]

Results:
[snip]
ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam':
/bulk/jay/build/php4-STABLE-200301230230/ext/mysql/libmysql/my_tempnam.c:103:
the use of `tempnam' is dangerous, better use `mkstemp'


No libphp4.so created...

I will try your suggested configure options next



[2003-01-22 21:01:50] [EMAIL PROTECTED]

No, not -exactly- I have all current RPM's from RedHat via up2date
installed so I am sure gcc and glibc, for example, are the latest
version(s) and not what was installed last year.

Sorry about using the comment entry.



[2003-01-22 20:56:33] [EMAIL PROTECTED]

And please don't use the 'Add Comment' when you add comments to your
_own_ report. 

Anyway, can you try this configure line if the snapshot fails too:

./configure --disable-all --disable-cgi




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

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

#21830 [Fbk->Opn]: libphp4.so not created

[php . net]

 ID:   21830
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: RedHat 7.3
 PHP Version:  4.3.0
 New Comment:

sapi/cli/php compiled successfully

I'll keep trying things to see if I can get libphp4.so created.


Previous Comments:


[2003-01-22 21:17:29] [EMAIL PROTECTED]

That is not an error..it's just a warning which can
safely be ignore. 




[2003-01-22 21:06:12] [EMAIL PROTECTED]

Results:
[snip]
ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam':
/bulk/jay/build/php4-STABLE-200301230230/ext/mysql/libmysql/my_tempnam.c:103:
the use of `tempnam' is dangerous, better use `mkstemp'


No libphp4.so created...

I will try your suggested configure options next



[2003-01-22 21:01:50] [EMAIL PROTECTED]

No, not -exactly- I have all current RPM's from RedHat via up2date
installed so I am sure gcc and glibc, for example, are the latest
version(s) and not what was installed last year.

Sorry about using the comment entry.



[2003-01-22 20:56:33] [EMAIL PROTECTED]

And please don't use the 'Add Comment' when you add comments to your
_own_ report. 

Anyway, can you try this configure line if the snapshot fails too:

./configure --disable-all --disable-cgi




[2003-01-22 20:54:18] [EMAIL PROTECTED]

So you compiled 4.2.3 with the EXACTLY same environment?
Same compiler version, same kernel, etc?




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

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

#21830 [Opn->Fbk]: libphp4.so not created

[sniper]

 ID:   21830
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: RedHat 7.3
 PHP Version:  4.3.0
 New Comment:

That is not an error..it's just a warning which can
safely be ignore. 



Previous Comments:


[2003-01-22 21:06:12] [EMAIL PROTECTED]

Results:
[snip]
ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam':
/bulk/jay/build/php4-STABLE-200301230230/ext/mysql/libmysql/my_tempnam.c:103:
the use of `tempnam' is dangerous, better use `mkstemp'


No libphp4.so created...

I will try your suggested configure options next



[2003-01-22 21:01:50] [EMAIL PROTECTED]

No, not -exactly- I have all current RPM's from RedHat via up2date
installed so I am sure gcc and glibc, for example, are the latest
version(s) and not what was installed last year.

Sorry about using the comment entry.



[2003-01-22 20:56:33] [EMAIL PROTECTED]

And please don't use the 'Add Comment' when you add comments to your
_own_ report. 

Anyway, can you try this configure line if the snapshot fails too:

./configure --disable-all --disable-cgi




[2003-01-22 20:54:18] [EMAIL PROTECTED]

So you compiled 4.2.3 with the EXACTLY same environment?
Same compiler version, same kernel, etc?




[2003-01-22 20:49:02] [EMAIL PROTECTED]

Yes.  I still have a working copy of php-4.2.3 from last year that I
compiled, installed, and have been running... but I wanted to tempt
fate tonight... :)

I am pulling back the snap and will report results.

Thanks!



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

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

#21649 [Opn]: This this problem with fopen() function for windows

[lipinski7722]

 ID:   21649
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Filesystem function related
 Operating System: win2000 server
 PHP Version:  4.3.0
 New Comment:

Hi

So does anybody had problem the same like mine with
fopen?

Best Regards
W.J.Lipinski


Previous Comments:


[2003-01-18 11:52:39] [EMAIL PROTECTED]

User is administrator this is on localhost
where PHP4 is configured as Apache 1.3 module
What else I have to do in hppdcon for apache ?

Best Regards
W.J.Lipinski



[2003-01-17 21:15:33] [EMAIL PROTECTED]

Are you sure the webserver user has rights to access that path even?




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

Hi 

I just try your solution.It doesn't work.
This is my path from

include_path c:\php4\pear;c:\ c:\php4\pear;c:\ 
Could You SEE IT!

This is a code I'm tring to run 
';

if(!$fp = fopen("authenticate.txt","r",1))
{ die("could not open password file"); }
//$fp = fopen('C:\php4\pear\authenticate.txt','r',1);
$auth_file = fread ($fp, filesize($fp));
fclose($fp);

This is an error I'm getting

c:\php4\pear;c:\

Warning: fopen(authenticate.txt) [function.fopen]: failed to create
stream: No such file or directory in c:\program files\apache
group\apache\htdocs\authfile.php on line 5

could not open password file

Best Regards
W.J.Lipinski



[2003-01-16 13:25:44] [EMAIL PROTECTED]

Your include_path is wrong:

include_path c:\php4\pear;c:\ c:\php4\pear;c:\
should read
include_path="c:\php4\pear;c:\"

an then you should fopen "c:\authenticate.txt" like this:
$fp= fopen("autenticate.txt","r",1);
because c:\ is already in your include path and you use 1 as your 3rd
parameter.

Christoph

Christoph



[2003-01-16 10:44:02] [EMAIL PROTECTED]

Hi
So anybody have idea what to do with fopen(windows env)
or should I go back to Unix which snapshots are more
stable

Best Regards
W.J.Lipinski



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

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

#21830 [Opn]: libphp4.so not created

[php . net]

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

Results:
[snip]
ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam':
/bulk/jay/build/php4-STABLE-200301230230/ext/mysql/libmysql/my_tempnam.c:103:
the use of `tempnam' is dangerous, better use `mkstemp'


No libphp4.so created...

I will try your suggested configure options next


Previous Comments:


[2003-01-22 21:01:50] [EMAIL PROTECTED]

No, not -exactly- I have all current RPM's from RedHat via up2date
installed so I am sure gcc and glibc, for example, are the latest
version(s) and not what was installed last year.

Sorry about using the comment entry.



[2003-01-22 20:56:33] [EMAIL PROTECTED]

And please don't use the 'Add Comment' when you add comments to your
_own_ report. 

Anyway, can you try this configure line if the snapshot fails too:

./configure --disable-all --disable-cgi




[2003-01-22 20:54:18] [EMAIL PROTECTED]

So you compiled 4.2.3 with the EXACTLY same environment?
Same compiler version, same kernel, etc?




[2003-01-22 20:49:02] [EMAIL PROTECTED]

Yes.  I still have a working copy of php-4.2.3 from last year that I
compiled, installed, and have been running... but I wanted to tempt
fate tonight... :)

I am pulling back the snap and will report results.

Thanks!



[2003-01-22 20:44:34] [EMAIL PROTECTED]

btw. Were you able to compile any previous PHP versions??
Like 4.2.3 ??




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

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

#21830 [Fbk->Opn]: libphp4.so not created

[php . net]

 ID:   21830
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: RedHat 7.3
 PHP Version:  4.3.0
 New Comment:

No, not -exactly- I have all current RPM's from RedHat via up2date
installed so I am sure gcc and glibc, for example, are the latest
version(s) and not what was installed last year.

Sorry about using the comment entry.


Previous Comments:


[2003-01-22 20:56:33] [EMAIL PROTECTED]

And please don't use the 'Add Comment' when you add comments to your
_own_ report. 

Anyway, can you try this configure line if the snapshot fails too:

./configure --disable-all --disable-cgi




[2003-01-22 20:54:18] [EMAIL PROTECTED]

So you compiled 4.2.3 with the EXACTLY same environment?
Same compiler version, same kernel, etc?




[2003-01-22 20:49:02] [EMAIL PROTECTED]

Yes.  I still have a working copy of php-4.2.3 from last year that I
compiled, installed, and have been running... but I wanted to tempt
fate tonight... :)

I am pulling back the snap and will report results.

Thanks!



[2003-01-22 20:44:34] [EMAIL PROTECTED]

btw. Were you able to compile any previous PHP versions??
Like 4.2.3 ??




[2003-01-22 20:43:57] [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

That libs/libphp4.bundle is NOT meant for Linux, it's for MacOSX so
using it does not help.

Please try the snapshot.




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

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

#20970 [Opn->Csd]: make fails (gcc: regex/r: No such file or directory)

[sniper]

 ID:   20970
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: Sun2.7
 PHP Version:  4.3.1-dev
 New Comment:

Closing this one then, thanks for testing.


Previous Comments:


[2003-01-22 19:49:12] [EMAIL PROTECTED]

Preliminary test completed 
Following error is not displayed ANY MORE
Fatal error: Nesting level too deep - recursive dependency? in Unknown
on line



[2003-01-22 19:29:32] [EMAIL PROTECTED]

Following points:

- Make step got resolved by applying the suggestion as mentioned in
Bug#19533 that is installing GNU SED 4.0 in /usr/local/bin and giving
it the precedence.
- Make install finished 
- Webserver bounced 
- Testing in Progess



[2003-01-22 19:12:13] [EMAIL PROTECTED]

Can you send me the Makefile that is generated with that
configure line?? (using the latest stable CVS snapshot)




[2003-01-20 11:35:23] [EMAIL PROTECTED]

If compiled without --with-nsapi option, Following error message
displayed during Make:

gcc: regex/r: No such file or directory
make: *** [sapi/cgi/php] Error 1



[2003-01-17 21:07:49] [EMAIL PROTECTED]

If you drop the --with-nsapi option from the configure line, does it
compile succesfully then?




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

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

#21830 [Fbk]: libphp4.so not created

[sniper]

 ID:   21830
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: RedHat 7.3
 PHP Version:  4.3.0
 New Comment:

And please don't use the 'Add Comment' when you add comments to your
_own_ report. 

Anyway, can you try this configure line if the snapshot fails too:

./configure --disable-all --disable-cgi



Previous Comments:


[2003-01-22 20:54:18] [EMAIL PROTECTED]

So you compiled 4.2.3 with the EXACTLY same environment?
Same compiler version, same kernel, etc?




[2003-01-22 20:49:02] [EMAIL PROTECTED]

Yes.  I still have a working copy of php-4.2.3 from last year that I
compiled, installed, and have been running... but I wanted to tempt
fate tonight... :)

I am pulling back the snap and will report results.

Thanks!



[2003-01-22 20:44:34] [EMAIL PROTECTED]

btw. Were you able to compile any previous PHP versions??
Like 4.2.3 ??




[2003-01-22 20:43:57] [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

That libs/libphp4.bundle is NOT meant for Linux, it's for MacOSX so
using it does not help.

Please try the snapshot.




[2003-01-22 20:39:25] [EMAIL PROTECTED]

$ make libphp4.la
[snip]
ext/ctype/ctype.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1

$ cat ext/ctype/ctype.lo
[one blank line]

$ make libs/libphp4.bundle
[snip]
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function
`_start':
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18):
undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [libs/libphp4.bundle] Error 1

$ rpm -qf /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o
glibc-devel-2.2.5-42

Should I be using gcc3 perhaps?



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

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

#21830 [Fbk]: libphp4.so not created

[sniper]

 ID:   21830
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: RedHat 7.3
 PHP Version:  4.3.0
 New Comment:

So you compiled 4.2.3 with the EXACTLY same environment?
Same compiler version, same kernel, etc?



Previous Comments:


[2003-01-22 20:49:02] [EMAIL PROTECTED]

Yes.  I still have a working copy of php-4.2.3 from last year that I
compiled, installed, and have been running... but I wanted to tempt
fate tonight... :)

I am pulling back the snap and will report results.

Thanks!



[2003-01-22 20:44:34] [EMAIL PROTECTED]

btw. Were you able to compile any previous PHP versions??
Like 4.2.3 ??




[2003-01-22 20:43:57] [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

That libs/libphp4.bundle is NOT meant for Linux, it's for MacOSX so
using it does not help.

Please try the snapshot.




[2003-01-22 20:39:25] [EMAIL PROTECTED]

$ make libphp4.la
[snip]
ext/ctype/ctype.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1

$ cat ext/ctype/ctype.lo
[one blank line]

$ make libs/libphp4.bundle
[snip]
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function
`_start':
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18):
undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [libs/libphp4.bundle] Error 1

$ rpm -qf /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o
glibc-devel-2.2.5-42

Should I be using gcc3 perhaps?



[2003-01-22 20:23:14] [EMAIL PROTECTED]

Ok.  I just removed config.cache and did make clean.

Running make again...

I will report results shortly.



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

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

#21830 [Com]: libphp4.so not created

[php . net]

 ID:   21830
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: RedHat 7.3
 PHP Version:  4.3.0
 New Comment:

Yes.  I still have a working copy of php-4.2.3 from last year that I
compiled, installed, and have been running... but I wanted to tempt
fate tonight... :)

I am pulling back the snap and will report results.

Thanks!


Previous Comments:


[2003-01-22 20:44:34] [EMAIL PROTECTED]

btw. Were you able to compile any previous PHP versions??
Like 4.2.3 ??




[2003-01-22 20:43:57] [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

That libs/libphp4.bundle is NOT meant for Linux, it's for MacOSX so
using it does not help.

Please try the snapshot.




[2003-01-22 20:39:25] [EMAIL PROTECTED]

$ make libphp4.la
[snip]
ext/ctype/ctype.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1

$ cat ext/ctype/ctype.lo
[one blank line]

$ make libs/libphp4.bundle
[snip]
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function
`_start':
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18):
undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [libs/libphp4.bundle] Error 1

$ rpm -qf /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o
glibc-devel-2.2.5-42

Should I be using gcc3 perhaps?



[2003-01-22 20:23:14] [EMAIL PROTECTED]

Ok.  I just removed config.cache and did make clean.

Running make again...

I will report results shortly.



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

Please check this report, and the last comment in it:

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

This really isn't any PHP bug but something done wrong.
(rm config.cache / make clean usually helps.)




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

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

#21830 [Fbk]: libphp4.so not created

[sniper]

 ID:   21830
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: RedHat 7.3
 PHP Version:  4.3.0
 New Comment:

btw. Were you able to compile any previous PHP versions??
Like 4.2.3 ??



Previous Comments:


[2003-01-22 20:43:57] [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

That libs/libphp4.bundle is NOT meant for Linux, it's for MacOSX so
using it does not help.

Please try the snapshot.




[2003-01-22 20:39:25] [EMAIL PROTECTED]

$ make libphp4.la
[snip]
ext/ctype/ctype.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1

$ cat ext/ctype/ctype.lo
[one blank line]

$ make libs/libphp4.bundle
[snip]
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function
`_start':
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18):
undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [libs/libphp4.bundle] Error 1

$ rpm -qf /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o
glibc-devel-2.2.5-42

Should I be using gcc3 perhaps?



[2003-01-22 20:23:14] [EMAIL PROTECTED]

Ok.  I just removed config.cache and did make clean.

Running make again...

I will report results shortly.



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

Please check this report, and the last comment in it:

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

This really isn't any PHP bug but something done wrong.
(rm config.cache / make clean usually helps.)




[2003-01-22 20:08:09] [EMAIL PROTECTED]

I am trying to create the DSO version for Apache 2.0.44

$ ./configure --with-mysql --with-axps2=/web/bin/apxs

Normal output.

$ make all
(does not complete)

$ make libphp4.la
[snip]
ext/ctype/ctype.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1

$ make libs/libphp4.bundle
[snip]...
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function
`_start':
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18):
undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [libs/libphp4.bundle] Error 1


There is nothing in libs and there is nothing in .libs

I have also tried this with php4-STABLE-200301220430 and I get the same
results.






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

#21830 [Fbk]: libphp4.so not created

[sniper]

 ID:   21830
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: RedHat 7.3
 PHP Version:  4.3.0
 New Comment:

Please try using this CVS snapshot:

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

That libs/libphp4.bundle is NOT meant for Linux, it's for MacOSX so
using it does not help.

Please try the snapshot.



Previous Comments:


[2003-01-22 20:39:25] [EMAIL PROTECTED]

$ make libphp4.la
[snip]
ext/ctype/ctype.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1

$ cat ext/ctype/ctype.lo
[one blank line]

$ make libs/libphp4.bundle
[snip]
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function
`_start':
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18):
undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [libs/libphp4.bundle] Error 1

$ rpm -qf /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o
glibc-devel-2.2.5-42

Should I be using gcc3 perhaps?



[2003-01-22 20:23:14] [EMAIL PROTECTED]

Ok.  I just removed config.cache and did make clean.

Running make again...

I will report results shortly.



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

Please check this report, and the last comment in it:

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

This really isn't any PHP bug but something done wrong.
(rm config.cache / make clean usually helps.)




[2003-01-22 20:08:09] [EMAIL PROTECTED]

I am trying to create the DSO version for Apache 2.0.44

$ ./configure --with-mysql --with-axps2=/web/bin/apxs

Normal output.

$ make all
(does not complete)

$ make libphp4.la
[snip]
ext/ctype/ctype.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1

$ make libs/libphp4.bundle
[snip]...
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function
`_start':
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18):
undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [libs/libphp4.bundle] Error 1


There is nothing in libs and there is nothing in .libs

I have also tried this with php4-STABLE-200301220430 and I get the same
results.






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

#21830 [Com]: libphp4.so not created

[php . net]

 ID:   21830
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: RedHat 7.3
 PHP Version:  4.3.0
 New Comment:

$ make libphp4.la
[snip]
ext/ctype/ctype.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1

$ cat ext/ctype/ctype.lo
[one blank line]

$ make libs/libphp4.bundle
[snip]
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function
`_start':
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18):
undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [libs/libphp4.bundle] Error 1

$ rpm -qf /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o
glibc-devel-2.2.5-42

Should I be using gcc3 perhaps?


Previous Comments:


[2003-01-22 20:23:14] [EMAIL PROTECTED]

Ok.  I just removed config.cache and did make clean.

Running make again...

I will report results shortly.



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

Please check this report, and the last comment in it:

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

This really isn't any PHP bug but something done wrong.
(rm config.cache / make clean usually helps.)




[2003-01-22 20:08:09] [EMAIL PROTECTED]

I am trying to create the DSO version for Apache 2.0.44

$ ./configure --with-mysql --with-axps2=/web/bin/apxs

Normal output.

$ make all
(does not complete)

$ make libphp4.la
[snip]
ext/ctype/ctype.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1

$ make libs/libphp4.bundle
[snip]...
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function
`_start':
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18):
undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [libs/libphp4.bundle] Error 1


There is nothing in libs and there is nothing in .libs

I have also tried this with php4-STABLE-200301220430 and I get the same
results.






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

#21820 [Ver]: bc break in parser

[george]

 ID:  21820
 User updated by: [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
 Status:  Verified
 Bug Type:Scripting Engine problem
 PHP Version: 4.3.0
 New Comment:

This bug appeared in 4.3.0 as a result of the lexer changes 
added to ZE1 and ZE2 in november to speed up 
variableinterpolation in strings.  

Previous to 4.3 this was valid:

echo "$a[b]";
but 
echo "$a['b']"; generated a parse error.

The bug manifests itself by turning this parse error into a 
non-sensical E_NOTICE error.

The patch 'fixes' the bug by making 

echo "$a['b']";

work, which has been a pending feature request and seems 
nice (to me), or at least harmless.


Previous Comments:


[2003-01-22 19:53:20] [EMAIL PROTECTED]

Anyone remember in what version of PHP this did work? :)
Correct (?) way to do this is:

 'bar');
 print "{$arr['foo']}";

?>

Or at least I've started to use that just because of this bug.





[2003-01-22 13:56:01] [EMAIL PROTECTED]

Point was, maybe there is a reason this was not implemented.

And btw, this is a bug as 'foo' is defined yet the error says it's
not.




[2003-01-22 13:45:54] [EMAIL PROTECTED]

this patch fixes that feature request/bug as well



[2003-01-22 13:43:05] [EMAIL PROTECTED]

Allowing it would be nice but this topic has come up many times.  Not
sure why it's not been implemented though, maybe there are reasons?  I
forget them.

One feature request for this:
http://bugs.php.net/bug.php?id=15677




[2003-01-22 13:25:11] [EMAIL PROTECTED]

patch up at http://www2.omniti.com/~george/
zend.patch.2002012101

patch allows for "$arr['foo']" to be parsed correctly (this 
seems better than disallowing it)



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

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

#21830 [Com]: libphp4.so not created

[php . net]

 ID:   21830
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: RedHat 7.3
 PHP Version:  4.3.0
 New Comment:

Ok.  I just removed config.cache and did make clean.

Running make again...

I will report results shortly.


Previous Comments:


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

Please check this report, and the last comment in it:

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

This really isn't any PHP bug but something done wrong.
(rm config.cache / make clean usually helps.)




[2003-01-22 20:08:09] [EMAIL PROTECTED]

I am trying to create the DSO version for Apache 2.0.44

$ ./configure --with-mysql --with-axps2=/web/bin/apxs

Normal output.

$ make all
(does not complete)

$ make libphp4.la
[snip]
ext/ctype/ctype.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1

$ make libs/libphp4.bundle
[snip]...
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function
`_start':
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18):
undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [libs/libphp4.bundle] Error 1


There is nothing in libs and there is nothing in .libs

I have also tried this with php4-STABLE-200301220430 and I get the same
results.






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

#21830 [Opn->Fbk]: libphp4.so not created

[sniper]

 ID:   21830
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: RedHat 7.3
 PHP Version:  4.3.0
 New Comment:

Please check this report, and the last comment in it:

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

This really isn't any PHP bug but something done wrong.
(rm config.cache / make clean usually helps.)



Previous Comments:


[2003-01-22 20:08:09] [EMAIL PROTECTED]

I am trying to create the DSO version for Apache 2.0.44

$ ./configure --with-mysql --with-axps2=/web/bin/apxs

Normal output.

$ make all
(does not complete)

$ make libphp4.la
[snip]
ext/ctype/ctype.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1

$ make libs/libphp4.bundle
[snip]...
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function
`_start':
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18):
undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [libs/libphp4.bundle] Error 1


There is nothing in libs and there is nothing in .libs

I have also tried this with php4-STABLE-200301220430 and I get the same
results.






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

#21262 [Opn]: crash or fail when outputting large amounts of text quickly

[spagmoid]

 ID:   21262
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Performance problem
 Operating System: WinXP
 PHP Version:  4.3.0
 New Comment:

My attitude is a result of iliaa's disrespect for MY time and work on
this.  I have nothing but respect for people that volunteer to improve
PHP.  Like I am doing myself by trying to point out bugs.  I don't get
paid to try OVER AND OVER to get people to recognize problems, and it
is less fun than just fixing them myself would be, I assure you.  But I
have other projects I am committed to.  The most I can do is keep
pushing through the bureaucratic atmosphere created by people more
interesting in closing bugs than fixing them.  

As I mentioned before, it's very much like trying to get bugs fixed at
Microsoft.  I don't know why, but this open source project has managed
to duplicate the beauracracy aspect of large corporations very well. 
Perhaps its a lack of accountability from the lack of personal code
ownership.

Anyway, I submit to you that in NO CASE should PHP exit in an error
condition without showing an error message.  If this is INTENDED
behavior then let me see the words "memory exceeded, quitting".  Until
I see them, this is a bug.

In fact, I very much doubt that this is intended behavior.  When the
buffer is full, PHP waits for it to be transmitted then continues.  It
does not simply crash.  

To state that crashing is "not a bug" shows a fundamental
misunderstanding of programming, and indeed of the difference between
all that is good and evil.


Previous Comments:


[2003-01-22 19:55:14] [EMAIL PROTECTED]

You really need to correct your attitude first.
We're all volunteers here and don't get paid for
this shit..




[2003-01-22 19:49:33] [EMAIL PROTECTED]

This is not always reproducible, this is as good as we can come up
with.  It appears to only reproduce for people unwilling to do anything
about it.



[2003-01-22 19:47:57] [EMAIL PROTECTED]

Please provide a SHORT but complete example script that
can be used to reproduce this. (the one you provided doesn't cause any
crashes)




[2003-01-22 19:41:51] [EMAIL PROTECTED]

You are wrong.
If it was a memory error, PHP should display the standard out of memory
message.

AS I EXPLAINED, this also happens with very SMALL amounts of data.  The
use of large blocks of data is just an easy way to REPRO.  Surely there
must be more people working on PHP than you?



[2003-01-22 17:12:39] [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

I've explained before and I will attempt to explain once again. When
output buffering is turned on the system does not output the text right
away but rather fills up a memory buffer that is displayed in one large
block. If the text you are trying to output exceeds the avaliable
system memory then the error you are seeing will occur. This cannot be
helped, the solution is to either disable output buffering or not use
things like gz_handler, which cause ALL of the output to be buffered in
memory rather then output the data in chunks (default chunk size 4096
bytes).



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

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

#21830 [NEW]: libphp4.so not created

[php . net]

From: [EMAIL PROTECTED]
Operating system: RedHat 7.3
PHP version:  4.3.0
PHP Bug Type: Compile Failure
Bug description:  libphp4.so not created 

I am trying to create the DSO version for Apache 2.0.44

$ ./configure --with-mysql --with-axps2=/web/bin/apxs

Normal output.

$ make all
(does not complete)

$ make libphp4.la
[snip]
ext/ctype/ctype.lo: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1

$ make libs/libphp4.bundle
[snip]...
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o: In function
`_start':
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../crt1.o(.text+0x18):
undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [libs/libphp4.bundle] Error 1


There is nothing in libs and there is nothing in .libs

I have also tried this with php4-STABLE-200301220430 and I get the same
results.


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

#21819 [Opn]: Corrupted uploaded binary files

[sniper]

 ID:   21819
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
-Bug Type: HTTP related
+Bug Type: Apache2 related
 Operating System: Linux RedHar 8.0
-PHP Version:  4.3.0
+PHP Version:  4.3.1
 New Comment:

I guess the problem (again) is apache2. It's really not ready for
production yet, so you should consider using
Apache 1.3.27 which really works..

Reclassified.



Previous Comments:


[2003-01-22 16:07:04] [EMAIL PROTECTED]

The script goes like this:
















When I upload a 11463 byte image, it grows to 22575 bytes and corrutps.



[2003-01-22 15:44:58] [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.


Please provide the script you are using to upload the files and the
script used to handle the actual files uploads.



[2003-01-22 08:59:41] [EMAIL PROTECTED]

When uploading binary files (about 5kB and up), they get corrupted, not
the whole file but some way from the beginning. The size is increased
about 90%, actual number of bytes varies with different browsers.

PHP versions tried: 4.3.0 and 4.3.1-dev (200301211230).

Configured with './configure' '--with-apxs2' '--with-openssl'
'--enable-calendar' '--with-curl' '--with-gd'
'--with-jpeg-dir=/usr/lib' '--with-png-dir=/usr/lib'
'--enable-mime-magic' '--with-mysql' '--enable-magic-quotes'
'--with-zlib-dir=/usr/lib' '--with-config-file-path=/etc'

Apache version: 2.0.43




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

#21262 [Opn]: crash or fail when outputting large amounts of text quickly

[sniper]

 ID:   21262
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Performance problem
 Operating System: WinXP
 PHP Version:  4.3.0
 New Comment:

You really need to correct your attitude first.
We're all volunteers here and don't get paid for
this shit..



Previous Comments:


[2003-01-22 19:49:33] [EMAIL PROTECTED]

This is not always reproducible, this is as good as we can come up
with.  It appears to only reproduce for people unwilling to do anything
about it.



[2003-01-22 19:47:57] [EMAIL PROTECTED]

Please provide a SHORT but complete example script that
can be used to reproduce this. (the one you provided doesn't cause any
crashes)




[2003-01-22 19:41:51] [EMAIL PROTECTED]

You are wrong.
If it was a memory error, PHP should display the standard out of memory
message.

AS I EXPLAINED, this also happens with very SMALL amounts of data.  The
use of large blocks of data is just an easy way to REPRO.  Surely there
must be more people working on PHP than you?



[2003-01-22 17:12:39] [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

I've explained before and I will attempt to explain once again. When
output buffering is turned on the system does not output the text right
away but rather fills up a memory buffer that is displayed in one large
block. If the text you are trying to output exceeds the avaliable
system memory then the error you are seeing will occur. This cannot be
helped, the solution is to either disable output buffering or not use
things like gz_handler, which cause ALL of the output to be buffered in
memory rather then output the data in chunks (default chunk size 4096
bytes).



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

This bug has been present for over a year, maybe since the beginning of
PHP.  We're still getting people passing the buck..



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

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

#21820 [Opn->Ver]: bc break in parser

[sniper]

 ID:  21820
 Updated by:  [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
-Status:  Open
+Status:  Verified
 Bug Type:Scripting Engine problem
 PHP Version: 4.3.0
 New Comment:

Anyone remember in what version of PHP this did work? :)
Correct (?) way to do this is:

 'bar');
 print "{$arr['foo']}";

?>

Or at least I've started to use that just because of this bug.




Previous Comments:


[2003-01-22 13:56:01] [EMAIL PROTECTED]

Point was, maybe there is a reason this was not implemented.

And btw, this is a bug as 'foo' is defined yet the error says it's
not.




[2003-01-22 13:45:54] [EMAIL PROTECTED]

this patch fixes that feature request/bug as well



[2003-01-22 13:43:05] [EMAIL PROTECTED]

Allowing it would be nice but this topic has come up many times.  Not
sure why it's not been implemented though, maybe there are reasons?  I
forget them.

One feature request for this:
http://bugs.php.net/bug.php?id=15677




[2003-01-22 13:25:11] [EMAIL PROTECTED]

patch up at http://www2.omniti.com/~george/
zend.patch.2002012101

patch allows for "$arr['foo']" to be parsed correctly (this 
seems better than disallowing it)



[2003-01-22 09:19:20] [EMAIL PROTECTED]

I don't think this is a bug, but someone sent it to me via 
email, so I'm proxy-submitting:

Hello George-

I stumbled upon a serious bug in the string parser and it
goes something like this:

  $arr = array('foo' => 'bar');
  print "$arr['foo']";

This used to provide a parse error but now instead we get
this one of level E_NOTICE:

Notice: Undefined index:  'foo' in /tmp/a.php on line 4
/tmp/a.php(4) : Notice - Undefined index:  'foo'

This is a serious problem as it moved an error from
parse to E_NOTICE, fails silently as most have error
reporting turned down, shows a misleading error as foo
is defined, and breaks BC.

Tested latest 4_3 HEAD (4.3.1-dev).  I would try php5
but I get segfault when trying to compile/use it :)

Have a nice day,
Philip Olson

cc: derick




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

#21262 [Fbk->Opn]: crash or fail when outputting large amounts of text quickly

[spagmoid]

 ID:   21262
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Performance problem
 Operating System: WinXP
 PHP Version:  4.3.0
 New Comment:

This is not always reproducible, this is as good as we can come up
with.  It appears to only reproduce for people unwilling to do anything
about it.


Previous Comments:


[2003-01-22 19:47:57] [EMAIL PROTECTED]

Please provide a SHORT but complete example script that
can be used to reproduce this. (the one you provided doesn't cause any
crashes)




[2003-01-22 19:41:51] [EMAIL PROTECTED]

You are wrong.
If it was a memory error, PHP should display the standard out of memory
message.

AS I EXPLAINED, this also happens with very SMALL amounts of data.  The
use of large blocks of data is just an easy way to REPRO.  Surely there
must be more people working on PHP than you?



[2003-01-22 17:12:39] [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

I've explained before and I will attempt to explain once again. When
output buffering is turned on the system does not output the text right
away but rather fills up a memory buffer that is displayed in one large
block. If the text you are trying to output exceeds the avaliable
system memory then the error you are seeing will occur. This cannot be
helped, the solution is to either disable output buffering or not use
things like gz_handler, which cause ALL of the output to be buffered in
memory rather then output the data in chunks (default chunk size 4096
bytes).



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

This bug has been present for over a year, maybe since the beginning of
PHP.  We're still getting people passing the buck..



[2003-01-15 16:44:33] [EMAIL PROTECTED]

I am using Apache version 2.0.43 with the sapi php module.

I downloaded the latest stable snapshot of php (4.3.1) but it still
reproduced the same orignial problem discussed.

Regards



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

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

#20970 [Opn]: make fails (gcc: regex/r: No such file or directory)

[joydeep_ghosh]

 ID:   20970
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Sun2.7
 PHP Version:  4.3.1-dev
 New Comment:

Preliminary test completed 
Following error is not displayed ANY MORE
Fatal error: Nesting level too deep - recursive dependency? in Unknown
on line


Previous Comments:


[2003-01-22 19:29:32] [EMAIL PROTECTED]

Following points:

- Make step got resolved by applying the suggestion as mentioned in
Bug#19533 that is installing GNU SED 4.0 in /usr/local/bin and giving
it the precedence.
- Make install finished 
- Webserver bounced 
- Testing in Progess



[2003-01-22 19:12:13] [EMAIL PROTECTED]

Can you send me the Makefile that is generated with that
configure line?? (using the latest stable CVS snapshot)




[2003-01-20 11:35:23] [EMAIL PROTECTED]

If compiled without --with-nsapi option, Following error message
displayed during Make:

gcc: regex/r: No such file or directory
make: *** [sapi/cgi/php] Error 1



[2003-01-17 21:07:49] [EMAIL PROTECTED]

If you drop the --with-nsapi option from the configure line, does it
compile succesfully then?




[2003-01-15 17:46:52] [EMAIL PROTECTED]

Following error encountered while executing Make command:

/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In
function `sapi_
nsapi_read_post':
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:211:
warning: unuse
d variable `content_length_str'
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In
function `nsapi
_request_ctor':
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:409:
warning: unuse
d variable `path_info'
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In
function `nsapi
_request_dtor':
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:450:
warning: passi
ng arg 1 of `nsapi_free' discards qualifiers from pointer target type
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:452:
warning: passi
ng arg 1 of `nsapi_free' discards qualifiers from pointer target type
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:545:63:
warning: "/
*" within comment
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:547:1:
warning: "/*
" within comment
.

gcc: ext/standard/a: No such file or directory
make: *** [sapi/cli/php] Error 1



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

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

#21262 [Opn->Fbk]: crash or fail when outputting large amounts of text quickly

[sniper]

 ID:   21262
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Performance problem
 Operating System: WinXP
 PHP Version:  4.3.0
 New Comment:

Please provide a SHORT but complete example script that
can be used to reproduce this. (the one you provided doesn't cause any
crashes)



Previous Comments:


[2003-01-22 19:41:51] [EMAIL PROTECTED]

You are wrong.
If it was a memory error, PHP should display the standard out of memory
message.

AS I EXPLAINED, this also happens with very SMALL amounts of data.  The
use of large blocks of data is just an easy way to REPRO.  Surely there
must be more people working on PHP than you?



[2003-01-22 17:12:39] [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

I've explained before and I will attempt to explain once again. When
output buffering is turned on the system does not output the text right
away but rather fills up a memory buffer that is displayed in one large
block. If the text you are trying to output exceeds the avaliable
system memory then the error you are seeing will occur. This cannot be
helped, the solution is to either disable output buffering or not use
things like gz_handler, which cause ALL of the output to be buffered in
memory rather then output the data in chunks (default chunk size 4096
bytes).



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

This bug has been present for over a year, maybe since the beginning of
PHP.  We're still getting people passing the buck..



[2003-01-15 16:44:33] [EMAIL PROTECTED]

I am using Apache version 2.0.43 with the sapi php module.

I downloaded the latest stable snapshot of php (4.3.1) but it still
reproduced the same orignial problem discussed.

Regards



[2003-01-14 19:25:17] [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 what apache version is it?)




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

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

#21817 [Fbk]: Error to compile php 4.2.3 in make phase

[sniper]

 ID:   21817
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
-Bug Type: Compile Failure
+Bug Type: IMAP related
 Operating System: Linux Conectiva 8
-PHP Version:  4.2.3
+PHP Version:  4.3.1-dev
 New Comment:

And what configure line did you use?
And is HAVE_IMAP_AUTH_GSS defined in main/php_config.h ??



Previous Comments:


[2003-01-22 15:59:40] [EMAIL PROTECTED]

What version of c-client are you using?



[2003-01-22 10:28:04] [EMAIL PROTECTED]

I get the latest version and try to compile and get the following
error:

gcc  -Iext/imap/ -I/usr/src/php/ext/imap/ -DPHP_ATOM_INC
-I/usr/src/php/include -I/usr/src/php/main -I/usr/src/php
-I/usr/src/php/Zend -I/usr/include/imap -I/usr/local/include
-I/usr/src/mysql-3.23.54a/include -I/usr/src/php/ext/xml/expat 
-I/usr/src/php/TSRM  -g -O2  -c /usr/src/php/ext/imap/php_imap.c -o
ext/imap/php_imap.o  && echo > ext/imap/php_imap.lo
/usr/src/php/ext/imap/php_imap.c: In function `zm_startup_imap':
/usr/src/php/ext/imap/php_imap.c:424: `auth_gss' undeclared (first use
in this function)
/usr/src/php/ext/imap/php_imap.c:424: (Each undeclared identifier is
reported only once
/usr/src/php/ext/imap/php_imap.c:424: for each function it appears
in.)
make: *** [ext/imap/php_imap.lo] Error 1



[2003-01-22 08:08:11] [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-22 07:45:52] [EMAIL PROTECTED]

I do ./configure with this parameters:

'--prefix=/usr/bin' \
'--disable-debug' \
'--enable-pic' \
'--enable-inline-optimization' \
'--enable-shared' \
'--disable-static' \
'--with-config-file-path=/etc/php4/apache' \
'--with-exec-dir=/usr/bin' \
'--with-regex=system' \
'--with-gettext' \
'--with-png' \
'--with-zlib' \
'--enable-magic-quotes' \
'--enable-safe-mode' \
'--enable-sockets' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-track-vars' \
'--enable-wddx' \
'--enable-snmp' \
'--enable-ftp' \
'--enable-bcmath' \
'--with-mysql=/usr/src/mysql-3.23.54a' \
'--without-unixODBC' \
'--with-xml' \
'--with-imap' \
'--with-mcrypt=/usr/lib/libmcrypt' \
'--with-readline=/usr/src/readline-4.3'

all it´s ok until now, but when I run 'make' this error occurs:

root@ php-4.2.3]# make
Making all in Zend
/bin/sh: cd: Zend: File or directory not found
make: *** [all-recursive] Error 1

But Zend directory is there ...

Thanks in advance





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

#21829 [NEW]: fsockopen() crashes on 2 of 3 servers (w/ gdb trace)

[michael]

From: [EMAIL PROTECTED]
Operating system: mandrake 8.2, 2.4.18-8.1mdk
PHP version:  4.3.0
PHP Bug Type: Reproducible crash
Bug description:  fsockopen() crashes on 2 of 3 servers (w/ gdb trace)

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

#21262 [Bgs->Opn]: crash or fail when outputting large amounts of text quickly

[spagmoid]

 ID:   21262
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
-Bug Type: Reproducible crash
+Bug Type: Performance problem
 Operating System: WinXP
 PHP Version:  4.3.0
 New Comment:

You are wrong.
If it was a memory error, PHP should display the standard out of memory
message.

AS I EXPLAINED, this also happens with very SMALL amounts of data.  The
use of large blocks of data is just an easy way to REPRO.  Surely there
must be more people working on PHP than you?


Previous Comments:


[2003-01-22 17:12:39] [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

I've explained before and I will attempt to explain once again. When
output buffering is turned on the system does not output the text right
away but rather fills up a memory buffer that is displayed in one large
block. If the text you are trying to output exceeds the avaliable
system memory then the error you are seeing will occur. This cannot be
helped, the solution is to either disable output buffering or not use
things like gz_handler, which cause ALL of the output to be buffered in
memory rather then output the data in chunks (default chunk size 4096
bytes).



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

This bug has been present for over a year, maybe since the beginning of
PHP.  We're still getting people passing the buck..



[2003-01-15 16:44:33] [EMAIL PROTECTED]

I am using Apache version 2.0.43 with the sapi php module.

I downloaded the latest stable snapshot of php (4.3.1) but it still
reproduced the same orignial problem discussed.

Regards



[2003-01-14 19:25:17] [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 what apache version is it?)




[2003-01-14 13:34:57] [EMAIL PROTECTED]

I can confirm this bug including the for loop provided earlier in this
bug thread.

I am using php 4.3.0 with Apache 2.0.43 with Windows XP Home Edition.

I found this bug report after noticing the same effect with a large
piece of php that I have been writing. I have found that turning off
error reporting in php.ini helps but does not solve the problem
totally. I found that using the flush() function helped but was not a
reliable solution.

This seems a blatant problem which is making debugging and development
almost impossible and very frustrating. Is there any update on
confirming the bug?

Regards



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

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

#21757 [Opn->Bgs]: session_register (); does not do it's job!

[sniper]

 ID:   21757
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Session related
 Operating System: Windows XP Pro
 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.

[EMAIL PROTECTED]



Previous Comments:


[2003-01-22 10:11:35] [EMAIL PROTECTED]

I don't know. I haven't changed any values but some paths so I could
make ir work. everything other is left unchanged (default).



[2003-01-20 13:54:17] [EMAIL PROTECTED]

Does your php.ini allow PHP to set cookie session?



[2003-01-20 10:40:38] [EMAIL PROTECTED]

Well, Previous version of PHP I used was 4.23 and everything went well.
Now in PHP 4.3 session_register ('string'); or $_SESSION ["string"];
does not register these 'string' variables when going from one page to
another. And by the way, echoing session_id (); in every new page you
go to (using hyperlinks, not opening new IE window) it gives you
different session ID and as far as I know that should not be changhing
unless you open another browser window. Why don't you try registering
variable and in another page writing if (session_is_registered
('string')) echo 'success';

I bet you won't see success though you should!



[2003-01-19 17:52:30] [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.


A) updating category.

B) Not enough info, and from what I can tell so far this is probably
Bogus.  



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

Here is the simple peace of code with the link to the page itself.
Session ID has to stay the same all the time as it is assigned to the
browser window (this conclusion is made by my own experiance :) ).
Tested with IE 6.0

//Start here



  


';
?>
Test_Link






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

#20970 [Fbk->Opn]: make fails (gcc: regex/r: No such file or directory)

[joydeep_ghosh]

 ID:   20970
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Sun2.7
 PHP Version:  4.3.1-dev
 New Comment:

Following points:

- Make step got resolved by applying the suggestion as mentioned in
Bug#19533 that is installing GNU SED 4.0 in /usr/local/bin and giving
it the precedence.
- Make install finished 
- Webserver bounced 
- Testing in Progess


Previous Comments:


[2003-01-22 19:12:13] [EMAIL PROTECTED]

Can you send me the Makefile that is generated with that
configure line?? (using the latest stable CVS snapshot)




[2003-01-20 11:35:23] [EMAIL PROTECTED]

If compiled without --with-nsapi option, Following error message
displayed during Make:

gcc: regex/r: No such file or directory
make: *** [sapi/cgi/php] Error 1



[2003-01-17 21:07:49] [EMAIL PROTECTED]

If you drop the --with-nsapi option from the configure line, does it
compile succesfully then?




[2003-01-15 17:46:52] [EMAIL PROTECTED]

Following error encountered while executing Make command:

/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In
function `sapi_
nsapi_read_post':
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:211:
warning: unuse
d variable `content_length_str'
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In
function `nsapi
_request_ctor':
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:409:
warning: unuse
d variable `path_info'
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In
function `nsapi
_request_dtor':
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:450:
warning: passi
ng arg 1 of `nsapi_free' discards qualifiers from pointer target type
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:452:
warning: passi
ng arg 1 of `nsapi_free' discards qualifiers from pointer target type
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:545:63:
warning: "/
*" within comment
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:547:1:
warning: "/*
" within comment
.

gcc: ext/standard/a: No such file or directory
make: *** [sapi/cli/php] Error 1



[2003-01-15 17:40:35] [EMAIL PROTECTED]

Directory php4-STABLE-200301150030 created 
PHP_VERSION "4.3.1-dev"

Configuration is OK

./configure --enable-debug --enable-libgcc --enable-dbx \
--enable-ftp --enable-inline-optimization \
--with-nsapi=/export/webtools/netscape/server4 \
--with-pgsql=/usr/local/pgsql \
--with-oracle=/export/webtools/app/oracle/product/8.1.7



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

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

#21821 [Bgs]: Unsetting $_COOKIE[session_name()] shouldn't warn, but send new cookie

[sniper]

 ID:   21821
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Session related
 Operating System: BSD/OS 4.2
 PHP Version:  4.3.0
 New Comment:

And this really doesn't work like that..
You can't set/unset cookies by mangling the $_COOKIE[] array anyway.

Please ask support questions elsewhere.



Previous Comments:


[2003-01-22 11:49:29] [EMAIL PROTECTED]

Ahum - NULL (inserted for readibility) apparently is '' not, void.



[2003-01-22 11:43:11] [EMAIL PROTECTED]

The following script:



refresh








Creates warnings about illegal chars in the session id. However - there
is no valid session here, as there is no valid cookie. It should send a
new cookie instead, with a new generated session id. However - it sets
an empty id:
Set-Cookie: PHPSESSID=; expires=Wed, 29-Jan-2003 17:37:42 GMT; path=/

If I also unset $_SESSION, it doesn't change anything.




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

#21826 [Opn->Bgs]: variables dont return value even if they are seen in phpinfo()

[sniper]

 ID:   21826
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: windows 2000
 PHP Version:  4.2.3
 New Comment:

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

Thank you for your interest in PHP.

[EMAIL PROTECTED]



Previous Comments:


[2003-01-22 17:05:19] [EMAIL PROTECTED]

My IIS5 crashes, and after reinstaling it, I can make any query to
MySQL base, or get any calculation on primary page, but when I want
some variable to PUT or GET to another script, I don't get it's value.
Another thing, when put on beggining of page command PHPINFO () i see
variables and it's values but scripts dont get them. 
Also I have been enabled REGISTER_GLOBALS in my Ini file. Please help
me to solve this problem. 





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

#21823 [Csd->Bgs]: improperly detecting gcc as cross compiler

[sniper]

 ID:   21823
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Gentoo Linux 1.4
 PHP Version:  4.3.0
 New Comment:

not php bug -> bogus



Previous Comments:


[2003-01-22 17:31:53] [EMAIL PROTECTED]

I just did some more testing, and building PHP outside of the Gentoo
build system works fine, so this bug is with their build system, not
with PHP itself. I'll take it up with them.



[2003-01-22 16:28:38] [EMAIL PROTECTED]

Okay, I tried that first. Here's the interesting parts of the configure
output:

<>
checking for gcc... gcc
checking whether the C compiler (gcc -march=i686 -O3 ) works... yes
checking whether the C compiler (gcc -march=i686 -O3 ) is a
cross-compiler... yes
<>
checking for fopencookie... yes
configure: error: can not run test program while cross compiling

!!! ERROR: dev-php/php-4.3.0-r2 failed.
!!! Function src_compile, Line 137, Exitcode 1
!!! bad ./configure

That failing, I decided to try stripping of the -O3 as well, just in
case. Here's the interesting output from that:

<>
checking for gcc... gcc
checking whether the C compiler (gcc -march=i686 ) works... yes
checking whether the C compiler (gcc -march=i686 ) is a
cross-compiler... yes
<>
checking for fopencookie... yes
configure: error: can not run test program while cross compiling

!!! ERROR: dev-php/php-4.3.0-r2 failed.
!!! Function src_compile, Line 137, Exitcode 1
!!! bad ./configure

As you can see, there is absolutely no change happening here.

The only thing I can think of that /might/ have caused this, although I
have no idea how, is that I did just install MySQL 4 on my box. When I
went to reinstall PHP to link it to the new libs, I noticed this
problem.



[2003-01-22 16:22:28] [EMAIL PROTECTED]

In that case remove -pipe and try again.



[2003-01-22 16:16:35] [EMAIL PROTECTED]

Ack. I'm running too many servers.

I was wrong about this one running GCC 3.2.1. It's still running 2.95
version. I've included the output of gcc -v below. Sorry for the
confusion!

Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs
gcc version 2.95.3 20010315 (release)



[2003-01-22 15:47:57] [EMAIL PROTECTED]

Change -march=i686 to -march=pentium2 and try again.



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

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

#21828 [Opn]: printer_list doesn't list any printers

[p . williams]

 ID:   21828
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Win/XP
 PHP Version:  4.3.0
 New Comment:

should read printer_list(PRINTER_ENUM_LOCAL)


Previous Comments:


[2003-01-22 19:12:16] [EMAIL PROTECTED]

printer_list(PRINTER_NUM_LOCAL) does not return any printers. We have
successfully used this function on a Win98/PWS configuration, but fails
on Win/XP with IIS. I noted the advice in bug 14301 to install 4.3 but
still no go. Any advice would be appreciated.




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

#21518 [Com]: ImageCreateFromString() causes segmentation fault

[groh]

 ID:   21518
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Redhat Linux 7.2
 PHP Version:  4.3.0
 Assigned To:  iliaa
 New Comment:

I've downloaded the Stable (4.3.x-dev Built On: Jan 23, 2003 00:30 GMT)
and the same script pointed by [EMAIL PROTECTED] still
happens.

CONFIGS:
-My configure file is like:
'./configure' '--with-apxs' '--with-sybase=shared,/usr/local/ftds'
'--with-mssql=shared,/usr/local/ftds' '--disable-ctype'
'--with-gd=/usr' '--with-jpeg=/usr' '--with-png=/usr'

-My HTTP server version is Apache/1.3.23 
-Apache loaded modules are:
mod_php4, mod_ssl, mod_gzip, mod_bandwidth, mod_setenvif, mod_so,
mod_usertrack, mod_headers, mod_expires, mod_digest, mod_auth_mysql,
mod_auth_db, mod_auth_anon, mod_auth, mod_access, mod_rewrite,
mod_alias, mod_proxy, mod_userdir, mod_actions, mod_imap, mod_asis,
mod_cgi, mod_dir, mod_autoindex, mod_include, mod_info, mod_status,
mod_negotiation, mod_mime, mod_log_referer, mod_log_agent,
mod_log_config, mod_define, mod_env, http_core 

-Error message is (note that the child pid refers to "httpd -DSSL
-DGZIP"):
[Wed Jan 22 23:08:54 2003] [notice] child pid 22099 exit signal
Segmentation fault (11)


Previous Comments:


[2003-01-08 12:12:14] [EMAIL PROTECTED]

This bug has been fixed in CVS.

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

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





[2003-01-08 12:04:10] [EMAIL PROTECTED]

Information about the PHP build is also available at:
http://www.kis.fotodom.com/phpinfo.php



[2003-01-08 12:02:03] [EMAIL PROTECTED]

Try with this one:

http://www.kis.fotodom.com/gfx/test.psd



[2003-01-08 11:53:46] [EMAIL PROTECTED]

Could you please a provide a sample file that always causes a
segmentation fault?



[2003-01-08 11:11:23] [EMAIL PROTECTED]

Update: In occasions (twice) I have received a Warning message about an
unsupported image type, which is what I wanted in the first place.
However, in the other 50+ occasions, the script simply crashes.



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

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

#21828 [NEW]: printer_list doesn't list any printers

[p . williams]

From: [EMAIL PROTECTED]
Operating system: Win/XP
PHP version:  4.3.0
PHP Bug Type: Unknown/Other Function
Bug description:  printer_list doesn't list any printers

printer_list(PRINTER_NUM_LOCAL) does not return any printers. We have
successfully used this function on a Win98/PWS configuration, but fails on
Win/XP with IIS. I noted the advice in bug 14301 to install 4.3 but still
no go. Any advice would be appreciated.
-- 
Edit bug report at http://bugs.php.net/?id=21828&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21828&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21828&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21828&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21828&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21828&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21828&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21828&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21828&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21828&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21828&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21828&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21828&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21828&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21828&r=gnused

#20970 [Opn->Fbk]: make fails (gcc: regex/r: No such file or directory)

[sniper]

 ID:   20970
 Updated by:   [EMAIL PROTECTED]
-Summary:  Fatal error: Nesting level too deep - recursive
   dependency? in Unknown on line
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: Sun2.7
 PHP Version:  4.3.1-dev
 New Comment:

Can you send me the Makefile that is generated with that
configure line?? (using the latest stable CVS snapshot)



Previous Comments:


[2003-01-20 11:35:23] [EMAIL PROTECTED]

If compiled without --with-nsapi option, Following error message
displayed during Make:

gcc: regex/r: No such file or directory
make: *** [sapi/cgi/php] Error 1



[2003-01-17 21:07:49] [EMAIL PROTECTED]

If you drop the --with-nsapi option from the configure line, does it
compile succesfully then?




[2003-01-15 17:46:52] [EMAIL PROTECTED]

Following error encountered while executing Make command:

/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In
function `sapi_
nsapi_read_post':
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:211:
warning: unuse
d variable `content_length_str'
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In
function `nsapi
_request_ctor':
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:409:
warning: unuse
d variable `path_info'
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c: In
function `nsapi
_request_dtor':
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:450:
warning: passi
ng arg 1 of `nsapi_free' discards qualifiers from pointer target type
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:452:
warning: passi
ng arg 1 of `nsapi_free' discards qualifiers from pointer target type
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:545:63:
warning: "/
*" within comment
/home/ghoshj/PHP/php4-STABLE-200301150030/sapi/nsapi/nsapi.c:547:1:
warning: "/*
" within comment
.

gcc: ext/standard/a: No such file or directory
make: *** [sapi/cli/php] Error 1



[2003-01-15 17:40:35] [EMAIL PROTECTED]

Directory php4-STABLE-200301150030 created 
PHP_VERSION "4.3.1-dev"

Configuration is OK

./configure --enable-debug --enable-libgcc --enable-dbx \
--enable-ftp --enable-inline-optimization \
--with-nsapi=/export/webtools/netscape/server4 \
--with-pgsql=/usr/local/pgsql \
--with-oracle=/export/webtools/app/oracle/product/8.1.7



[2003-01-14 19:23:12] [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





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

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

#20142 [Bgs]: Session and EscapeShellCmd problem

[glenn]

 ID:   20142
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Session related
 Operating System: Win 2K
 PHP Version:  4.2.3
 New Comment:

The EscapeShellCmd was not the problem.  The issue was with how
sessions are stored.  Please read the post for Oct 28, 2002 for a full
explanation.  In a nutshell: The session is saved with a number
indicating the length of the variable, however it does not count the /
as a character and is thus one less than the actual number of
characters in the string, thus confusing the session information and
reporting an error.


Previous Comments:


[2003-01-22 17:48:57] [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

EscapeShellCmd adds \ to the variable, which changes $test from b'lah
to b\'lah nothing buggy or unusual about that.



[2002-11-25 16:08:21] [EMAIL PROTECTED]

I have installed the win32 version listed above and still get the same
problem.

The session count of characters is still off.



[2002-11-15 01:37:51] [EMAIL PROTECTED]

let's keep this in feedback status then until we get the real
feedback.




[2002-11-14 20:41:55] [EMAIL PROTECTED]

I tried using the http://snaps.php.net/win32/php4-win32-latest.zip
download, but it crashed my system.  I don't think it was the software.
 It was more likely the hardware.  I am currently rebuilding the server
and will try again when it is up.  Thank you.



[2002-11-14 01:47:41] [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/20142

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

#21626 [NEW]: gdfgfdg

[dfgdfg]

From: [EMAIL PROTECTED]
Operating system: ffgh
PHP version:  4.3.0
PHP Bug Type: Variables related
Bug description:  gdfgfdg


Notice:  Undefined variable:  in in
/usr/src/web/php/php-bugs-web/report.php on line 263

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

#21827 [Com]: form post magic variables clumped together

[sol]

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

Here's how to stop the clumps (workaround)
1. Always have the first form variable have a name 5 or more letters
2. Don't have a name on the submit button
3. Have the value of any hidden field 4 or more letters or numbers

-Sol


Previous Comments:


[2003-01-22 18:18:35] [EMAIL PROTECTED]

Hello,
When I post a html form with 3 hidden fields, with 3 or less
alphanumerics as the values, and 4 or less alphanumerics as the NAME of
the first field, and a submit button having a name value, the first
field variable has clumped all the other post data in it, instead of
just the magic variable for field 1 like it should.

Using phpinfo, there is _ENV["+"] after _ENV["REMOTE_PORT"] that shows
the telltale clump, or a line and a square when the form does not meet
the above situation. I do not know what this _ENV["+"] is but think
it's a clue. There's also _SERVER["+"] and in the Environment a plain +
after REMOTE_PORT that will be the name of my hidden field 1 with the
clump data. 

I have seen many other complaints in the bug section about variables
missing or broken, but noone tracked down the cause as well as this. It
takes 3 simultaneous conditions.
You can see this in action at
http://www.zewy.com/phpclump.php

I'm going to put a hidden field with 1000 as the value on every page as
my work-around. 999 didn't work, it's only 3 alphanumerics.

If you could find a fix it would be appreciated. BTW, one day, it's my
dream to have millions of $$$ and donate it to open source developers..
You make the world a better place.

Thanks




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

#21827 [NEW]: form post magic variables clumped together

[sol]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.3.0
PHP Bug Type: Scripting Engine problem
Bug description:  form post magic variables clumped together

Hello,
When I post a html form with 3 hidden fields, with 3 or less alphanumerics
as the values, and 4 or less alphanumerics as the NAME of the first field,
and a submit button having a name value, the first field variable has
clumped all the other post data in it, instead of just the magic variable
for field 1 like it should.

Using phpinfo, there is _ENV["+"] after _ENV["REMOTE_PORT"] that shows the
telltale clump, or a line and a square when the form does not meet the
above situation. I do not know what this _ENV["+"] is but think it's a
clue. There's also _SERVER["+"] and in the Environment a plain + after
REMOTE_PORT that will be the name of my hidden field 1 with the clump
data. 

I have seen many other complaints in the bug section about variables
missing or broken, but noone tracked down the cause as well as this. It
takes 3 simultaneous conditions.
You can see this in action at
http://www.zewy.com/phpclump.php

I'm going to put a hidden field with 1000 as the value on every page as my
work-around. 999 didn't work, it's only 3 alphanumerics.

If you could find a fix it would be appreciated. BTW, one day, it's my
dream to have millions of $$$ and donate it to open source developers..
You make the world a better place.

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

#20320 [Opn->Fbk]: _call() crashes with bus error in some circumstances

[iliaa]

 ID:   20320
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Zend Engine 2 problem
 Operating System: OS X 10.1.5
 PHP Version:  4CVS-2002-11-08
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2002-11-08 16:52:04] [EMAIL PROTECTED]

some kind of hashtable problem, looks like. variations on a simple
command-line class definition crash with a bus error, trying to catch
undefined method call with a __call() method.
here is backtrace showing some things that work and some that don't:

(gdb) r -r 'class foo { function __call($m,$a) { echo "abcdefg\n";
return; } } $x = new foo; $x->nothere();'
Starting program: /usr/local/book/php4-ze2/sapi/cli/php -r 'class foo {
function __call($m,$a) { echo "abcdefg\n"; return; } } $x = new foo;
$x->nothere();'
[Switching to process 21057 thread 0x3413]
abcdefg

Program exited normally.
(gdb) r -r 'class foo { function __call($m,$a) { echo "abcdef\n";
return; } } $x = new foo; $x->nothere();'
Starting program: /usr/local/book/php4-ze2/sapi/cli/php -r 'class foo {
function __call($m,$a) { echo "abcdef\n"; return; } } $x = new foo;
$x->nothere();'
[Switching to process 21062 thread 0x3713]

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x001c06e0 in _zend_is_inconsistent (ht=0x0, file=0x208d38
"/Users/tater/book/php4-ze2/Zend/zend_hash.c", line=871) at
/Users/tater/book/php4-ze2/Zend/zend_hash.c:78
78  if (ht->inconsistent==HT_OK) {
(gdb) bt
#0  0x001c06e0 in _zend_is_inconsistent (ht=0x0, file=0x208d38
"/Users/tater/book/php4-ze2/Zend/zend_hash.c", line=871) at
/Users/tater/book/php4-ze2/Zend/zend_hash.c:78
#1  0x001c3a9c in zend_hash_find (ht=0x0, arKey=0x6eda60 "__call",
nKeyLength=7, pData=0xb284) at
/Users/tater/book/php4-ze2/Zend/zend_hash.c:871
#2  0x001aab38 in call_user_function_ex (function_table=0x0,
object_pp=0x0, function_name=0xb340, retval_ptr_ptr=0xb360,
param_count=2, params=0xb358, no_separation=0, symbol_table=0x0) at
/Users/tater/book/php4-ze2/Zend/zend_execute_API.c:558
#3  0x001cfb54 in zend_std_call_user_call (ht=0, return_value=0x6ed958,
this_ptr=0x0, return_value_used=0) at
/Users/tater/book/php4-ze2/Zend/zend_object_handlers.c:353
#4  0x001da1f0 in zend_do_fcall_common_helper (execute_data=0xb5c8,
op_array=0x6ed1b8) at
/Users/tater/book/php4-ze2/Zend/zend_execute.c:2422
#5  0x001da900 in zend_do_fcall_by_name_handler
(execute_data=0xb5c8, op_array=0x6ed1b8) at
/Users/tater/book/php4-ze2/Zend/zend_execute.c:2514
#6  0x001d3adc in execute (op_array=0x6ed1b8) at
/Users/tater/book/php4-ze2/Zend/zend_execute.c:1194
#7  0x001ab8b0 in zend_eval_string (str=0xbbf1 "class foo {
function __call($m,$a) { echo \"abcdef\\n\"; return; } } $x = new foo;
$x->nothere();", retval_ptr=0x0, string_name=0x20a790 "Command line
code") at /Users/tater/book/php4-ze2/Zend/zend_execute_API.c:757
#8  0x001e47c0 in main (argc=3, argv=0xbb1c) at
/Users/tater/book/php4-ze2/sapi/cli/php_cli.c:743
#9  0x1a44 in _start ()
#10 0x1874 in start ()
(gdb) r -r 'class foo { function __call($m,$a) { echo "abcdefg\n";  } }
$x = new foo; $x->nothere();'
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/book/php4-ze2/sapi/cli/php -r 'class foo {
function __call($m,$a) { echo "abcdefg\n";  } } $x = new foo;
$x->nothere();'
[Switching to process 21067 thread 0x3d0f]

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x001c06e0 in _zend_is_inconsistent (ht=0x0, file=0x208d38
"/Users/tater/book/php4-ze2/Zend/zend_hash.c", line=871) at
/Users/tater/book/php4-ze2/Zend/zend_hash.c:78
78  if (ht->inconsistent==HT_OK) {
(gdb) r -r 'class foo { function __call($m,$a) { echo "abcdef\n";  } }
$x = new foo; $x->nothere();'
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/book/php4-ze2/sapi/cli/php -r 'class foo {
function __call($m,$a) { echo "abcdef\n";  } } $x = new foo;
$x->nothere();'
[Switching to process 21072 thread 0x400b]

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x001c06e0 in _zend_is_inconsistent (ht=0x0, file=0x208d38
"/Users/tater/book/php4-ze2/Zend/zend_hash.c", line=871) at
/Users/tater/book/php4-ze2/Zend/zend_hash.c:78
78  if (ht->inconsistent==HT_OK) {
(gdb) r -r 'class foo { function __call($m,$a) { echo "abcde\n";  } }
$x = new foo; $x->nothere();'
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/book/php4-ze2/sapi/cli/php -r 'class foo {
function __call($m,$a) { 

#20142 [Opn->Bgs]: Session and EscapeShellCmd problem

[iliaa]

 ID:   20142
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Session related
 Operating System: Win 2K
 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

EscapeShellCmd adds \ to the variable, which changes $test from b'lah
to b\'lah nothing buggy or unusual about that.


Previous Comments:


[2002-11-25 16:08:21] [EMAIL PROTECTED]

I have installed the win32 version listed above and still get the same
problem.

The session count of characters is still off.



[2002-11-15 01:37:51] [EMAIL PROTECTED]

let's keep this in feedback status then until we get the real
feedback.




[2002-11-14 20:41:55] [EMAIL PROTECTED]

I tried using the http://snaps.php.net/win32/php4-win32-latest.zip
download, but it crashed my system.  I don't think it was the software.
 It was more likely the hardware.  I am currently rebuilding the server
and will try again when it is up.  Thank you.



[2002-11-14 01:47:41] [EMAIL PROTECTED]

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





[2002-10-28 17:46:17] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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



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

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

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

[pmoulding]

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

The require_once error has not occurred when using 80Mb.

The original require structure ended up including every component in
the system. I added a few if statements to include only those
components required for the script. The original mess might have used
up the default 8Mb of memory. My clean version probably uses less than
1 Mb for my code.

I am using the PHP binary compiled with all options. I think that comes
to about 4 Mb. If that 4 Mb is loaded in to the default 8Mb when
running PHP as a module then my original code would have easily used
the remaining 4 Mb. Changing the allocation to 80Mb may have, in
effect, increased available memory from 4 Mb to 76 Mb.


Previous Comments:


[2003-01-22 17:28:25] [EMAIL PROTECTED]

Has the change on memory_limit entry solved the require_once problem
too?




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

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



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

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

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



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

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


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


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

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



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

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

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



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

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

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

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



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

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

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




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

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

#21823 [Opn->Csd]: improperly detecting gcc as cross compiler

[mwalker]

 ID:   21823
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: Gentoo Linux 1.4
 PHP Version:  4.3.0
 New Comment:

I just did some more testing, and building PHP outside of the Gentoo
build system works fine, so this bug is with their build system, not
with PHP itself. I'll take it up with them.


Previous Comments:


[2003-01-22 16:28:38] [EMAIL PROTECTED]

Okay, I tried that first. Here's the interesting parts of the configure
output:

<>
checking for gcc... gcc
checking whether the C compiler (gcc -march=i686 -O3 ) works... yes
checking whether the C compiler (gcc -march=i686 -O3 ) is a
cross-compiler... yes
<>
checking for fopencookie... yes
configure: error: can not run test program while cross compiling

!!! ERROR: dev-php/php-4.3.0-r2 failed.
!!! Function src_compile, Line 137, Exitcode 1
!!! bad ./configure

That failing, I decided to try stripping of the -O3 as well, just in
case. Here's the interesting output from that:

<>
checking for gcc... gcc
checking whether the C compiler (gcc -march=i686 ) works... yes
checking whether the C compiler (gcc -march=i686 ) is a
cross-compiler... yes
<>
checking for fopencookie... yes
configure: error: can not run test program while cross compiling

!!! ERROR: dev-php/php-4.3.0-r2 failed.
!!! Function src_compile, Line 137, Exitcode 1
!!! bad ./configure

As you can see, there is absolutely no change happening here.

The only thing I can think of that /might/ have caused this, although I
have no idea how, is that I did just install MySQL 4 on my box. When I
went to reinstall PHP to link it to the new libs, I noticed this
problem.



[2003-01-22 16:22:28] [EMAIL PROTECTED]

In that case remove -pipe and try again.



[2003-01-22 16:16:35] [EMAIL PROTECTED]

Ack. I'm running too many servers.

I was wrong about this one running GCC 3.2.1. It's still running 2.95
version. I've included the output of gcc -v below. Sorry for the
confusion!

Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs
gcc version 2.95.3 20010315 (release)



[2003-01-22 15:47:57] [EMAIL PROTECTED]

Change -march=i686 to -march=pentium2 and try again.



[2003-01-22 12:54:58] [EMAIL PROTECTED]

When installing PHP 4.3 on my system running GCC 3.2.1, I get the
following output. This is obviously incorrect.

If you need any further info, please ask. 

arsenic root # emerge php
Calculating dependencies ...done!
>>> emerge (1 of 1) dev-php/php-4.3.0-r2 to /
>>> md5 ;-) php-4.3.0.tar.bz2
>>> Unpacking source...
>>> Unpacking php-4.3.0.tar.bz2
>>> Source unpacked.
ssl
gdbm
mysql
truetype
jpeg
Compiling imap with SSL support
libwww
flash
xml2
crypt
creating cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for working sed... sed
checking host system type... i686-pc-linux-gnu
Updated php_version.h
checking for gcc... gcc
checking whether the C compiler (gcc -march=i686 -O3 -pipe ) works...
yes
checking whether the C compiler (gcc -march=i686 -O3 -pipe ) is a
cross-compiler... yes
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking whether gcc and cc understand -c and -o together... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
checking for ranlib... ranlib
checking whether ln -s works... yes
checking for gawk... gawk
checking for bison... bison -y
checking bison version... 1.35 (ok)
checking for flex... flex
checking for yywrap in -lfl... yes
checking lex output file root... lex.yy
checking whether yytext is a pointer... yes
checking for working const... yes
checking flex version... 2.5.4 (ok)
checking for pthreads_cflags...
checking for pthreads_lib...

Configuring SAPI modules
checking for AOLserver support... no
checking for Apache 1.x module support via DSO through APXS... no
checking for Apache 1.x module support... no
checking for mod_charset compatibility option... no
checking for Apache 2.0 module support via DSO through APXS... no
checking for Caudium support... no
checking for CLI build... yes
checking for embedded SAPI library support... no
checking for Zeus ISAPI support... no
checking for NSAPI support... no
checking for PHTTPD support... no
checking for Pi3Web support... no
checking for Roxen/Pike support... no
checking for Servlet support... no
checking for thttpd...

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

[jeffabruce]

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

I would like to help you, but it would take some time to get my server
back in the state where the error was occurring. I have since installed
FreeType 2.x so that now things do build and work correctly.

So, I can't confirm the fact that the crash would go away. But, since
variable "error" is undefined, it easily could cause a crash. Certainly
initializing it to NULL would improve the "random" nature of undefined
variables.

My original post was meant to help out the development of PHP by
relaying my experience and pointing to specific lines of code that seem
problematic. There is clearly a mistake in the gd.c code. You may
choose not to do anything about it. And, it may not affect too many
installations, but any decent software engineer would say that the code
is risky at best.


Previous Comments:


[2003-01-22 17:08:34] [EMAIL PROTECTED]

If you change char *error; to char *error = NULL; does the segmentation
fault you are seeing go away?



[2003-01-22 13:57:11] [EMAIL PROTECTED]

The version of gd.c that I have is supposed to be 4.3.0. I still
believe it is incorrect.

If you are referring to the statement:

Line 2951:   #else /* !USE_GD_IMGSTRTTF */

that 'else' is related to a "USE_GD_IMGSTRTTF" and is not the same as
any "HAVE_GD_STRINGxxx" defines.

I'm saying that if USE_GD_IMGSTRTTF *is* defined, but neither
HAVE_GD_STRINGFT nor HAVE_GD_STRINGTTF is defined, it will leave the
variable 'error' undefined, and then try to use it (resulting in the
possibility of a crash).

Do you still disagree?



[2003-01-21 14:20:13] [EMAIL PROTECTED]

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



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

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

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



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

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




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

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

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

[moriyoshi]

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

Has the change on memory_limit entry solved the require_once problem
too?



Previous Comments:


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

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



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

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

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



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

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


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


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

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



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

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

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



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

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

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

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



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

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

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




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

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

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



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

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

#21262 [Opn->Bgs]: crash or fail when outputting large amounts of text quickly

[iliaa]

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

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

I've explained before and I will attempt to explain once again. When
output buffering is turned on the system does not output the text right
away but rather fills up a memory buffer that is displayed in one large
block. If the text you are trying to output exceeds the avaliable
system memory then the error you are seeing will occur. This cannot be
helped, the solution is to either disable output buffering or not use
things like gz_handler, which cause ALL of the output to be buffered in
memory rather then output the data in chunks (default chunk size 4096
bytes).


Previous Comments:


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

This bug has been present for over a year, maybe since the beginning of
PHP.  We're still getting people passing the buck..



[2003-01-15 16:44:33] [EMAIL PROTECTED]

I am using Apache version 2.0.43 with the sapi php module.

I downloaded the latest stable snapshot of php (4.3.1) but it still
reproduced the same orignial problem discussed.

Regards



[2003-01-14 19:25:17] [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 what apache version is it?)




[2003-01-14 13:34:57] [EMAIL PROTECTED]

I can confirm this bug including the for loop provided earlier in this
bug thread.

I am using php 4.3.0 with Apache 2.0.43 with Windows XP Home Edition.

I found this bug report after noticing the same effect with a large
piece of php that I have been writing. I have found that turning off
error reporting in php.ini helps but does not solve the problem
totally. I found that using the flush() function helped but was not a
reliable solution.

This seems a blatant problem which is making debugging and development
almost impossible and very frustrating. Is there any update on
confirming the bug?

Regards



[2003-01-10 23:42:44] [EMAIL PROTECTED]

Ridiculous.. how on earth can they look at this:

PHP Fatal error:  Allowed memory size of 8388608
bytes exhausted (tried to allocate 10240 bytes)

And say its a bug in IE?
I agree with the first assesment - this is a likely a CRITICAL bug.  I
have seen pages fail for no reason on linux too, who knows if this
problem could be responsible.  This needs to be looked at by someone at
the top.



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

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

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

[iliaa]

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

If you change char *error; to char *error = NULL; does the segmentation
fault you are seeing go away?


Previous Comments:


[2003-01-22 13:57:11] [EMAIL PROTECTED]

The version of gd.c that I have is supposed to be 4.3.0. I still
believe it is incorrect.

If you are referring to the statement:

Line 2951:   #else /* !USE_GD_IMGSTRTTF */

that 'else' is related to a "USE_GD_IMGSTRTTF" and is not the same as
any "HAVE_GD_STRINGxxx" defines.

I'm saying that if USE_GD_IMGSTRTTF *is* defined, but neither
HAVE_GD_STRINGFT nor HAVE_GD_STRINGTTF is defined, it will leave the
variable 'error' undefined, and then try to use it (resulting in the
possibility of a crash).

Do you still disagree?



[2003-01-21 14:20:13] [EMAIL PROTECTED]

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



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

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

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



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

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




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

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

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



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

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

#21826 [NEW]: variables dont return value even if they are seen in phpinfo()

[istankov]

From: [EMAIL PROTECTED]
Operating system: windows 2000
PHP version:  4.2.3
PHP Bug Type: *General Issues
Bug description:  variables dont return value even if they are seen in phpinfo()

My IIS5 crashes, and after reinstaling it, I can make any query to MySQL
base, or get any calculation on primary page, but when I want some
variable to PUT or GET to another script, I don't get it's value. Another
thing, when put on beggining of page command PHPINFO () i see variables
and it's values but scripts dont get them. 
Also I have been enabled REGISTER_GLOBALS in my Ini file. Please help me
to solve this problem. 

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

#21823 [Fbk->Opn]: improperly detecting gcc as cross compiler

[mwalker]

 ID:   21823
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Gentoo Linux 1.4
 PHP Version:  4.3.0
 New Comment:

Okay, I tried that first. Here's the interesting parts of the configure
output:

<>
checking for gcc... gcc
checking whether the C compiler (gcc -march=i686 -O3 ) works... yes
checking whether the C compiler (gcc -march=i686 -O3 ) is a
cross-compiler... yes
<>
checking for fopencookie... yes
configure: error: can not run test program while cross compiling

!!! ERROR: dev-php/php-4.3.0-r2 failed.
!!! Function src_compile, Line 137, Exitcode 1
!!! bad ./configure

That failing, I decided to try stripping of the -O3 as well, just in
case. Here's the interesting output from that:

<>
checking for gcc... gcc
checking whether the C compiler (gcc -march=i686 ) works... yes
checking whether the C compiler (gcc -march=i686 ) is a
cross-compiler... yes
<>
checking for fopencookie... yes
configure: error: can not run test program while cross compiling

!!! ERROR: dev-php/php-4.3.0-r2 failed.
!!! Function src_compile, Line 137, Exitcode 1
!!! bad ./configure

As you can see, there is absolutely no change happening here.

The only thing I can think of that /might/ have caused this, although I
have no idea how, is that I did just install MySQL 4 on my box. When I
went to reinstall PHP to link it to the new libs, I noticed this
problem.


Previous Comments:


[2003-01-22 16:22:28] [EMAIL PROTECTED]

In that case remove -pipe and try again.



[2003-01-22 16:16:35] [EMAIL PROTECTED]

Ack. I'm running too many servers.

I was wrong about this one running GCC 3.2.1. It's still running 2.95
version. I've included the output of gcc -v below. Sorry for the
confusion!

Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs
gcc version 2.95.3 20010315 (release)



[2003-01-22 15:47:57] [EMAIL PROTECTED]

Change -march=i686 to -march=pentium2 and try again.



[2003-01-22 12:54:58] [EMAIL PROTECTED]

When installing PHP 4.3 on my system running GCC 3.2.1, I get the
following output. This is obviously incorrect.

If you need any further info, please ask. 

arsenic root # emerge php
Calculating dependencies ...done!
>>> emerge (1 of 1) dev-php/php-4.3.0-r2 to /
>>> md5 ;-) php-4.3.0.tar.bz2
>>> Unpacking source...
>>> Unpacking php-4.3.0.tar.bz2
>>> Source unpacked.
ssl
gdbm
mysql
truetype
jpeg
Compiling imap with SSL support
libwww
flash
xml2
crypt
creating cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for working sed... sed
checking host system type... i686-pc-linux-gnu
Updated php_version.h
checking for gcc... gcc
checking whether the C compiler (gcc -march=i686 -O3 -pipe ) works...
yes
checking whether the C compiler (gcc -march=i686 -O3 -pipe ) is a
cross-compiler... yes
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking whether gcc and cc understand -c and -o together... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
checking for ranlib... ranlib
checking whether ln -s works... yes
checking for gawk... gawk
checking for bison... bison -y
checking bison version... 1.35 (ok)
checking for flex... flex
checking for yywrap in -lfl... yes
checking lex output file root... lex.yy
checking whether yytext is a pointer... yes
checking for working const... yes
checking flex version... 2.5.4 (ok)
checking for pthreads_cflags...
checking for pthreads_lib...

Configuring SAPI modules
checking for AOLserver support... no
checking for Apache 1.x module support via DSO through APXS... no
checking for Apache 1.x module support... no
checking for mod_charset compatibility option... no
checking for Apache 2.0 module support via DSO through APXS... no
checking for Caudium support... no
checking for CLI build... yes
checking for embedded SAPI library support... no
checking for Zeus ISAPI support... no
checking for NSAPI support... no
checking for PHTTPD support... no
checking for Pi3Web support... no
checking for Roxen/Pike support... no
checking for Servlet support... no
checking for thttpd... no
checking for TUX... no
checking for webjames... no
checking for CGI build... no
checking for chosen SAPI module... cli

Running system checks
checking for missing declarations of reentrant functions... done
checking for sendmail... /usr/sbin/sendmail
checking whether system uses EBC

#21823 [Opn->Fbk]: improperly detecting gcc as cross compiler

[iliaa]

 ID:   21823
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: Gentoo Linux 1.4
 PHP Version:  4.3.0
 New Comment:

In that case remove -pipe and try again.


Previous Comments:


[2003-01-22 16:16:35] [EMAIL PROTECTED]

Ack. I'm running too many servers.

I was wrong about this one running GCC 3.2.1. It's still running 2.95
version. I've included the output of gcc -v below. Sorry for the
confusion!

Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs
gcc version 2.95.3 20010315 (release)



[2003-01-22 15:47:57] [EMAIL PROTECTED]

Change -march=i686 to -march=pentium2 and try again.



[2003-01-22 12:54:58] [EMAIL PROTECTED]

When installing PHP 4.3 on my system running GCC 3.2.1, I get the
following output. This is obviously incorrect.

If you need any further info, please ask. 

arsenic root # emerge php
Calculating dependencies ...done!
>>> emerge (1 of 1) dev-php/php-4.3.0-r2 to /
>>> md5 ;-) php-4.3.0.tar.bz2
>>> Unpacking source...
>>> Unpacking php-4.3.0.tar.bz2
>>> Source unpacked.
ssl
gdbm
mysql
truetype
jpeg
Compiling imap with SSL support
libwww
flash
xml2
crypt
creating cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for working sed... sed
checking host system type... i686-pc-linux-gnu
Updated php_version.h
checking for gcc... gcc
checking whether the C compiler (gcc -march=i686 -O3 -pipe ) works...
yes
checking whether the C compiler (gcc -march=i686 -O3 -pipe ) is a
cross-compiler... yes
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking whether gcc and cc understand -c and -o together... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
checking for ranlib... ranlib
checking whether ln -s works... yes
checking for gawk... gawk
checking for bison... bison -y
checking bison version... 1.35 (ok)
checking for flex... flex
checking for yywrap in -lfl... yes
checking lex output file root... lex.yy
checking whether yytext is a pointer... yes
checking for working const... yes
checking flex version... 2.5.4 (ok)
checking for pthreads_cflags...
checking for pthreads_lib...

Configuring SAPI modules
checking for AOLserver support... no
checking for Apache 1.x module support via DSO through APXS... no
checking for Apache 1.x module support... no
checking for mod_charset compatibility option... no
checking for Apache 2.0 module support via DSO through APXS... no
checking for Caudium support... no
checking for CLI build... yes
checking for embedded SAPI library support... no
checking for Zeus ISAPI support... no
checking for NSAPI support... no
checking for PHTTPD support... no
checking for Pi3Web support... no
checking for Roxen/Pike support... no
checking for Servlet support... no
checking for thttpd... no
checking for TUX... no
checking for webjames... no
checking for CGI build... no
checking for chosen SAPI module... cli

Running system checks
checking for missing declarations of reentrant functions... done
checking for sendmail... /usr/sbin/sendmail
checking whether system uses EBCDIC... no
checking for socket... yes
checking for htonl... yes
checking for gethostname... yes
checking for gethostbyaddr... yes
checking for yp_get_default_domain... no
checking for __yp_get_default_domain... no
checking for yp_get_default_domain in -lnsl... yes
checking for dlopen... yes
checking for sin in -lm... yes
checking for res_search... no
checking for __res_search... no
checking for res_search in -lresolv... yes
checking for res_search in -lbind... no
checking for __res_search in -lbind... no
checking for res_search in -lsocket... no
checking for __res_search in -lsocket... no
checking for inet_aton... yes
checking for dn_skipname... no
checking for __dn_skipname... no
checking for dn_skipname in -lresolv... no
checking for __dn_skipname in -lresolv... yes
checking for dn_skipname in -lbind... no
checking for __dn_skipname in -lbind... no
checking for ANSI C header files... yes
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for fclose declaration... ok
checking for ApplicationServices/ApplicationServices.h... no
checking for sys/types.h... yes
checking for sys/time.h... yes
checking for netinet/in.h... yes
checking for alloca.h... yes
checking for arpa/inet.h... yes
checking for arpa/nameser.h... yes
checking for assert.h... yes
checking for crypt.h... yes
checking for fcntl.

#21824 [Opn->Csd]: PHP-Based AIM Bot

[gschlossnagle]

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

This is not a bug system for suggestions for new PEAR 
classes.  Try your concerns on the pear-dev list.

And there should be nothing stopping you from being a PEAR 
developer.  They don't bite.




Previous Comments:


[2003-01-22 16:03:01] [EMAIL PROTECTED]

heh, well, I'm no PEAR developer so I guess I'll need to wait for
someone else.



[2003-01-22 14:26:01] [EMAIL PROTECTED]

Speak of the devil, I was just thinking of this on my way home last
night (well, ICQ technically, but the idea is the same).

The conclusion I came to, and others may feel free to disagree with me,
is that such modules are best built as PEAR classes rather than PHP
extensions.  The fact that you're now mentioning that Perl has it as a
PEAR-equivalent style module just bolsters that position.

If you feel adventurous, I'd recommend working on the conversion
yourself.  You've got the basic framework to start from in Perl's
Net::AIM module, it simply needs to be built into a PHP class.



[2003-01-22 14:12:35] [EMAIL PROTECTED]

Any thoughts on converting the Perl Net::AIM module to PHP?

I think it would be great to be able to code an AIM bot in PHP.  has
this been discussed regarding the possibility of converting the AIM
protocols and make it an option for compiling into PHP?




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

#21823 [Fbk->Opn]: improperly detecting gcc as cross compiler

[mwalker]

 ID:   21823
 User updated by:  [EMAIL PROTECTED]
-Summary:  improperly detecting gcc3 as cross compiler
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Gentoo Linux 1.4
 PHP Version:  4.3.0
 New Comment:

Ack. I'm running too many servers.

I was wrong about this one running GCC 3.2.1. It's still running 2.95
version. I've included the output of gcc -v below. Sorry for the
confusion!

Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs
gcc version 2.95.3 20010315 (release)


Previous Comments:


[2003-01-22 15:47:57] [EMAIL PROTECTED]

Change -march=i686 to -march=pentium2 and try again.



[2003-01-22 12:54:58] [EMAIL PROTECTED]

When installing PHP 4.3 on my system running GCC 3.2.1, I get the
following output. This is obviously incorrect.

If you need any further info, please ask. 

arsenic root # emerge php
Calculating dependencies ...done!
>>> emerge (1 of 1) dev-php/php-4.3.0-r2 to /
>>> md5 ;-) php-4.3.0.tar.bz2
>>> Unpacking source...
>>> Unpacking php-4.3.0.tar.bz2
>>> Source unpacked.
ssl
gdbm
mysql
truetype
jpeg
Compiling imap with SSL support
libwww
flash
xml2
crypt
creating cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for working sed... sed
checking host system type... i686-pc-linux-gnu
Updated php_version.h
checking for gcc... gcc
checking whether the C compiler (gcc -march=i686 -O3 -pipe ) works...
yes
checking whether the C compiler (gcc -march=i686 -O3 -pipe ) is a
cross-compiler... yes
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking whether gcc and cc understand -c and -o together... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
checking for ranlib... ranlib
checking whether ln -s works... yes
checking for gawk... gawk
checking for bison... bison -y
checking bison version... 1.35 (ok)
checking for flex... flex
checking for yywrap in -lfl... yes
checking lex output file root... lex.yy
checking whether yytext is a pointer... yes
checking for working const... yes
checking flex version... 2.5.4 (ok)
checking for pthreads_cflags...
checking for pthreads_lib...

Configuring SAPI modules
checking for AOLserver support... no
checking for Apache 1.x module support via DSO through APXS... no
checking for Apache 1.x module support... no
checking for mod_charset compatibility option... no
checking for Apache 2.0 module support via DSO through APXS... no
checking for Caudium support... no
checking for CLI build... yes
checking for embedded SAPI library support... no
checking for Zeus ISAPI support... no
checking for NSAPI support... no
checking for PHTTPD support... no
checking for Pi3Web support... no
checking for Roxen/Pike support... no
checking for Servlet support... no
checking for thttpd... no
checking for TUX... no
checking for webjames... no
checking for CGI build... no
checking for chosen SAPI module... cli

Running system checks
checking for missing declarations of reentrant functions... done
checking for sendmail... /usr/sbin/sendmail
checking whether system uses EBCDIC... no
checking for socket... yes
checking for htonl... yes
checking for gethostname... yes
checking for gethostbyaddr... yes
checking for yp_get_default_domain... no
checking for __yp_get_default_domain... no
checking for yp_get_default_domain in -lnsl... yes
checking for dlopen... yes
checking for sin in -lm... yes
checking for res_search... no
checking for __res_search... no
checking for res_search in -lresolv... yes
checking for res_search in -lbind... no
checking for __res_search in -lbind... no
checking for res_search in -lsocket... no
checking for __res_search in -lsocket... no
checking for inet_aton... yes
checking for dn_skipname... no
checking for __dn_skipname... no
checking for dn_skipname in -lresolv... no
checking for __dn_skipname in -lresolv... yes
checking for dn_skipname in -lbind... no
checking for __dn_skipname in -lbind... no
checking for ANSI C header files... yes
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for fclose declaration... ok
checking for ApplicationServices/ApplicationServices.h... no
checking for sys/types.h... yes
checking for sys/time.h... yes
checking for netinet/in.h... yes
checking for alloca.h... yes
checking for arpa/inet.h... yes
checking for arpa/nameser.h... yes
checking for assert.h... yes
checking for crypt.h... yes
checking for fcntl.h... yes
checking for grp.h... yes
checking for ieeefp.h... no
checking for langinfo.h... y

#21819 [Fbk->Opn]: Corrupted uploaded binary files

[ele]

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

The script goes like this:
















When I upload a 11463 byte image, it grows to 22575 bytes and corrutps.


Previous Comments:


[2003-01-22 15:44:58] [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.


Please provide the script you are using to upload the files and the
script used to handle the actual files uploads.



[2003-01-22 08:59:41] [EMAIL PROTECTED]

When uploading binary files (about 5kB and up), they get corrupted, not
the whole file but some way from the beginning. The size is increased
about 90%, actual number of bytes varies with different browsers.

PHP versions tried: 4.3.0 and 4.3.1-dev (200301211230).

Configured with './configure' '--with-apxs2' '--with-openssl'
'--enable-calendar' '--with-curl' '--with-gd'
'--with-jpeg-dir=/usr/lib' '--with-png-dir=/usr/lib'
'--enable-mime-magic' '--with-mysql' '--enable-magic-quotes'
'--with-zlib-dir=/usr/lib' '--with-config-file-path=/etc'

Apache version: 2.0.43




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

#21824 [Opn]: PHP-Based AIM Bot

[thomas]

 ID:   21824
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: all
 PHP Version:  4.3.0
 New Comment:

heh, well, I'm no PEAR developer so I guess I'll need to wait for
someone else.


Previous Comments:


[2003-01-22 14:26:01] [EMAIL PROTECTED]

Speak of the devil, I was just thinking of this on my way home last
night (well, ICQ technically, but the idea is the same).

The conclusion I came to, and others may feel free to disagree with me,
is that such modules are best built as PEAR classes rather than PHP
extensions.  The fact that you're now mentioning that Perl has it as a
PEAR-equivalent style module just bolsters that position.

If you feel adventurous, I'd recommend working on the conversion
yourself.  You've got the basic framework to start from in Perl's
Net::AIM module, it simply needs to be built into a PHP class.



[2003-01-22 14:12:35] [EMAIL PROTECTED]

Any thoughts on converting the Perl Net::AIM module to PHP?

I think it would be great to be able to code an AIM bot in PHP.  has
this been discussed regarding the possibility of converting the AIM
protocols and make it an option for compiling into PHP?




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

#21817 [Opn->Fbk]: Error to compile php 4.2.3 in make phase

[iliaa]

 ID:   21817
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: Linux Conectiva 8
 PHP Version:  4.2.3
 New Comment:

What version of c-client are you using?


Previous Comments:


[2003-01-22 10:28:04] [EMAIL PROTECTED]

I get the latest version and try to compile and get the following
error:

gcc  -Iext/imap/ -I/usr/src/php/ext/imap/ -DPHP_ATOM_INC
-I/usr/src/php/include -I/usr/src/php/main -I/usr/src/php
-I/usr/src/php/Zend -I/usr/include/imap -I/usr/local/include
-I/usr/src/mysql-3.23.54a/include -I/usr/src/php/ext/xml/expat 
-I/usr/src/php/TSRM  -g -O2  -c /usr/src/php/ext/imap/php_imap.c -o
ext/imap/php_imap.o  && echo > ext/imap/php_imap.lo
/usr/src/php/ext/imap/php_imap.c: In function `zm_startup_imap':
/usr/src/php/ext/imap/php_imap.c:424: `auth_gss' undeclared (first use
in this function)
/usr/src/php/ext/imap/php_imap.c:424: (Each undeclared identifier is
reported only once
/usr/src/php/ext/imap/php_imap.c:424: for each function it appears
in.)
make: *** [ext/imap/php_imap.lo] Error 1



[2003-01-22 08:08:11] [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-22 07:45:52] [EMAIL PROTECTED]

I do ./configure with this parameters:

'--prefix=/usr/bin' \
'--disable-debug' \
'--enable-pic' \
'--enable-inline-optimization' \
'--enable-shared' \
'--disable-static' \
'--with-config-file-path=/etc/php4/apache' \
'--with-exec-dir=/usr/bin' \
'--with-regex=system' \
'--with-gettext' \
'--with-png' \
'--with-zlib' \
'--enable-magic-quotes' \
'--enable-safe-mode' \
'--enable-sockets' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-track-vars' \
'--enable-wddx' \
'--enable-snmp' \
'--enable-ftp' \
'--enable-bcmath' \
'--with-mysql=/usr/src/mysql-3.23.54a' \
'--without-unixODBC' \
'--with-xml' \
'--with-imap' \
'--with-mcrypt=/usr/lib/libmcrypt' \
'--with-readline=/usr/src/readline-4.3'

all it´s ok until now, but when I run 'make' this error occurs:

root@ php-4.2.3]# make
Making all in Zend
/bin/sh: cd: Zend: File or directory not found
make: *** [all-recursive] Error 1

But Zend directory is there ...

Thanks in advance





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

#21823 [Opn->Fbk]: improperly detecting gcc3 as cross compiler

[iliaa]

 ID:   21823
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: Gentoo Linux 1.4
 PHP Version:  4.3.0
 New Comment:

Change -march=i686 to -march=pentium2 and try again.


Previous Comments:


[2003-01-22 12:54:58] [EMAIL PROTECTED]

When installing PHP 4.3 on my system running GCC 3.2.1, I get the
following output. This is obviously incorrect.

If you need any further info, please ask. 

arsenic root # emerge php
Calculating dependencies ...done!
>>> emerge (1 of 1) dev-php/php-4.3.0-r2 to /
>>> md5 ;-) php-4.3.0.tar.bz2
>>> Unpacking source...
>>> Unpacking php-4.3.0.tar.bz2
>>> Source unpacked.
ssl
gdbm
mysql
truetype
jpeg
Compiling imap with SSL support
libwww
flash
xml2
crypt
creating cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for working sed... sed
checking host system type... i686-pc-linux-gnu
Updated php_version.h
checking for gcc... gcc
checking whether the C compiler (gcc -march=i686 -O3 -pipe ) works...
yes
checking whether the C compiler (gcc -march=i686 -O3 -pipe ) is a
cross-compiler... yes
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking whether gcc and cc understand -c and -o together... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
checking for ranlib... ranlib
checking whether ln -s works... yes
checking for gawk... gawk
checking for bison... bison -y
checking bison version... 1.35 (ok)
checking for flex... flex
checking for yywrap in -lfl... yes
checking lex output file root... lex.yy
checking whether yytext is a pointer... yes
checking for working const... yes
checking flex version... 2.5.4 (ok)
checking for pthreads_cflags...
checking for pthreads_lib...

Configuring SAPI modules
checking for AOLserver support... no
checking for Apache 1.x module support via DSO through APXS... no
checking for Apache 1.x module support... no
checking for mod_charset compatibility option... no
checking for Apache 2.0 module support via DSO through APXS... no
checking for Caudium support... no
checking for CLI build... yes
checking for embedded SAPI library support... no
checking for Zeus ISAPI support... no
checking for NSAPI support... no
checking for PHTTPD support... no
checking for Pi3Web support... no
checking for Roxen/Pike support... no
checking for Servlet support... no
checking for thttpd... no
checking for TUX... no
checking for webjames... no
checking for CGI build... no
checking for chosen SAPI module... cli

Running system checks
checking for missing declarations of reentrant functions... done
checking for sendmail... /usr/sbin/sendmail
checking whether system uses EBCDIC... no
checking for socket... yes
checking for htonl... yes
checking for gethostname... yes
checking for gethostbyaddr... yes
checking for yp_get_default_domain... no
checking for __yp_get_default_domain... no
checking for yp_get_default_domain in -lnsl... yes
checking for dlopen... yes
checking for sin in -lm... yes
checking for res_search... no
checking for __res_search... no
checking for res_search in -lresolv... yes
checking for res_search in -lbind... no
checking for __res_search in -lbind... no
checking for res_search in -lsocket... no
checking for __res_search in -lsocket... no
checking for inet_aton... yes
checking for dn_skipname... no
checking for __dn_skipname... no
checking for dn_skipname in -lresolv... no
checking for __dn_skipname in -lresolv... yes
checking for dn_skipname in -lbind... no
checking for __dn_skipname in -lbind... no
checking for ANSI C header files... yes
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for fclose declaration... ok
checking for ApplicationServices/ApplicationServices.h... no
checking for sys/types.h... yes
checking for sys/time.h... yes
checking for netinet/in.h... yes
checking for alloca.h... yes
checking for arpa/inet.h... yes
checking for arpa/nameser.h... yes
checking for assert.h... yes
checking for crypt.h... yes
checking for fcntl.h... yes
checking for grp.h... yes
checking for ieeefp.h... no
checking for langinfo.h... yes
checking for limits.h... yes
checking for locale.h... yes
checking for monetary.h... yes
checking for mach-o/dyld.h... no
checking for netdb.h... yes
checking for pwd.h... yes
checking for resolv.h... yes
checking for signal.h... yes
checking for stdarg.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for syslog.h... yes
checking for sysexits.h... yes
checking for sys/file.h... yes
checking for sys/mman.h... yes
checking f

#21825 [Opn->Csd]: Fatal error: Nesting level too deep

[rhornsby]

 ID:   21825
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Linux 2.4.19
 PHP Version:  4.3.0
 New Comment:

Strange, but pointing extension_dir to /usr/local/lib/php/extension
(which doesn't seem to contain anything useful) as opposed to
/usr/lib/php/extensions seems to have fixed the issue.

I saw those other reports, but had compiled (or I thought) 4.3.0
successfully before.


Previous Comments:


[2003-01-22 15:04:01] [EMAIL PROTECTED]

Can you please find the extension_dir setting in your php.ini and make
sure that it points to the directory with your newly built modules?
There have been reports where this "Nesting level too deep" was caused
by an extension_dir that pointed to the modules of a previous PHP
installation.



[2003-01-22 14:31:54] [EMAIL PROTECTED]

This error occurs at the bottom of every PHP-parsed page:

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

The pages seem to render okay, but the error appears to end each page. 
It even spit out the same error dozens of times on make test, and after
sending in the test results.

./configure  --with-apxs=/usr/local/apache/bin/apxs  
 --enable-trans-sid
 --enable-track-vars
 --with-gd
 --with-pdflib
 --with-jpeg-dir  
 --with-tiff-dir
 --with-pspell
 --with-freetype-dir
 --enable-gd-native-ttf
 --with-png-dir 
 --with-zlib-dir
 --with-ttf
 --with-mysql=/usr/local/mysql

The system is MDK9 and Apache 1.3.26




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

#21819 [Opn->Fbk]: Corrupted uploaded binary files

[iliaa]

 ID:   21819
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: HTTP related
 Operating System: Linux RedHar 8.0
 PHP Version:  4.3.0
 New Comment:

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


Please provide the script you are using to upload the files and the
script used to handle the actual files uploads.


Previous Comments:


[2003-01-22 08:59:41] [EMAIL PROTECTED]

When uploading binary files (about 5kB and up), they get corrupted, not
the whole file but some way from the beginning. The size is increased
about 90%, actual number of bytes varies with different browsers.

PHP versions tried: 4.3.0 and 4.3.1-dev (200301211230).

Configured with './configure' '--with-apxs2' '--with-openssl'
'--enable-calendar' '--with-curl' '--with-gd'
'--with-jpeg-dir=/usr/lib' '--with-png-dir=/usr/lib'
'--enable-mime-magic' '--with-mysql' '--enable-magic-quotes'
'--with-zlib-dir=/usr/lib' '--with-config-file-path=/etc'

Apache version: 2.0.43




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

#10108 [Com]: cc 1501:218 file XXX contains an incorrect file suffix

[brandon]

 ID:   10108
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: AIX V4.3.3
 PHP Version:  4.3.0-dev
 New Comment:

This does not look like quite the same bug to me as #14245,
and I suggest the following might resolve this bug:

Our PHP 4.3.0 build failed to compile sapi/cli/php on our AIX machine,
with over one hundred error messages like:

cc: 1501-218 file ext/ctype/ctype.lo contains an incorrect file suffix

The causes of this are rather subtle:

1. GNU libtool will usually not create static objects under AIX.

2. But the PHP developers want libtool to create static objects.

3. So the PHP developers provide their own ./libtool in the source
   tree which will create them, which they run with "/bin/sh libtool".

4. Unfortunately, while "/bin/sh " usually looks for  in
   the current directory before searching through $PATH, on AIX it
   looks through $PATH first; thus the PHP Makefile winds up running
   /usr/local/bin/libtool (or wherever you have it installed) instead.

Thus the solution is to modify the PHP Makefile so that the line

   LIBTOOL = $(SHELL) libtool --silent

instead reads

   LIBTOOL = $(SHELL) ./libtool --silent

Technical notes: When you compile and install libtool, it runs a
script called libtool.m4 which, around line 2363 in the libtool-1.4.3
source, disables AIX static linking with the explanation that:

   "On AIX, shared libraries and static libraries use the same
   namespace, and are all built from PIC."

It disables static linking by setting enable_static=no when it writes
your libtool script; the ./libtool script in the PHP build directory
works precisely because this variable is set to "yes" instead.


Previous Comments:


[2003-01-20 16:56:24] [EMAIL PROTECTED]

I'm bogusing this since this is again the same bug
as is reported in http://bugs.php.net/bug.php?id=14245

Please add any useful comments with extra info to that
report instead. Thank you.




[2002-08-03 01:00:10] [EMAIL PROTECTED]

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



[2002-07-08 10:22:34] [EMAIL PROTECTED]

Sorry,

don't checked the right directory.

.libs/ directory contains :
libphp4.a
libphp4.exp
libphp4.la->../libphp4.la
libphp4.lai
libphp4.so.0



[2002-07-08 10:20:14] [EMAIL PROTECTED]

The ./libs directory is empty at this end of the compilation.



[2002-07-02 20:29:31] [EMAIL PROTECTED]

After compile..do you have anything in .libs/ ?




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

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

#21825 [Com]: Fatal error: Nesting level too deep

[michael . mauch]

 ID:   21825
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Linux 2.4.19
 PHP Version:  4.3.0
 New Comment:

Can you please find the extension_dir setting in your php.ini and make
sure that it points to the directory with your newly built modules?
There have been reports where this "Nesting level too deep" was caused
by an extension_dir that pointed to the modules of a previous PHP
installation.


Previous Comments:


[2003-01-22 14:31:54] [EMAIL PROTECTED]

This error occurs at the bottom of every PHP-parsed page:

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

The pages seem to render okay, but the error appears to end each page. 
It even spit out the same error dozens of times on make test, and after
sending in the test results.

./configure  --with-apxs=/usr/local/apache/bin/apxs  
 --enable-trans-sid
 --enable-track-vars
 --with-gd
 --with-pdflib
 --with-jpeg-dir  
 --with-tiff-dir
 --with-pspell
 --with-freetype-dir
 --enable-gd-native-ttf
 --with-png-dir 
 --with-zlib-dir
 --with-ttf
 --with-mysql=/usr/local/mysql

The system is MDK9 and Apache 1.3.26




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

#16692 [Com]: Cannot find or read import file: /usr/local/apache2/bin/httpd.exp

[brandon]

 ID:   16692
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: Apache2 related
 Operating System: AIX
 PHP Version:  4.2.0
 New Comment:

Our PHP 4.3.0 build failed to compile sapi/cli/php on our AIX machine,
with over one hundred error messages like:

cc: 1501-218 file ext/ctype/ctype.lo contains an incorrect file suffix

The causes of this are rather subtle:

1. GNU libtool will usually not create static objects under AIX.

2. But the PHP developers want libtool to create static objects.

3. So the PHP developers provide their own ./libtool in the source
   tree which will create them, which they run with "/bin/sh libtool".

4. Unfortunately, while "/bin/sh " usually looks for  in
   the current directory before searching through $PATH, on AIX it
   looks through $PATH first; thus the PHP Makefile winds up running
   /usr/local/bin/libtool (or wherever you have it installed) instead.

Thus the solution is to modify the PHP Makefile so that the line

   LIBTOOL = $(SHELL) libtool --silent

instead reads

   LIBTOOL = $(SHELL) ./libtool --silent

Technical notes: When you compile and install libtool, it runs a
script called libtool.m4 which, around line 2363 in the libtool-1.4.3
source, disables AIX static linking with the explanation that:

   "On AIX, shared libraries and static libraries use the same
   namespace, and are all built from PIC."

It disables static linking by setting enable_static=no when it writes
your libtool script; the ./libtool script in the PHP build directory
works precisely because this variable is set to "yes" instead.


Previous Comments:


[2002-10-27 01:00:02] [EMAIL PROTECTED]

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



[2002-10-09 14:36:16] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

Could you please see if the problem persists with Apache 2.0.43 and PHP
4.3-dev.



[2002-05-22 03:51:59] [EMAIL PROTECTED]

This also happens with Apache 2.0.36 apxs-script.
After running ./configure you have to edit the config_vars.mk.
Search for httpd.exp and change it to $prefix/modules/httpd.exp (as
Aaron wrote). Then run "make" - without problems.



[2002-05-07 19:29:23] [EMAIL PROTECTED]

Did you use a special Apache layout? Does the httpd.exp
file exist anywhere in your apache install tree?
(I would expect it to be in $prefix/modules/httpd.exp)
I won't mark this closed yet, but it seems likely to be
a problem with Apache 2.0.35's apxs, and you might want
to try using 2.0.36.



[2002-04-23 00:11:11] [EMAIL PROTECTED]

Reclassified. (and changed the summary)
Those 'incorrect file..' warnings can be ignored.




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

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

#17996 [Com]: make fails with "image.c" , line 439.23: 1506-334 (S) Identifier uchar has

[brandon]

 ID:   17996
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Compile Failure
 Operating System: AIX 4.3.3
 PHP Version:  4.3.0-dev
 New Comment:

Our PHP 4.3.0 build failed to compile sapi/cli/php on our AIX machine,
with over one hundred error messages like:

cc: 1501-218 file ext/ctype/ctype.lo contains an incorrect file suffix

The causes of this are rather subtle:

1. GNU libtool will usually not create static objects under AIX.

2. But the PHP developers want libtool to create static objects.

3. So the PHP developers provide their own ./libtool in the source
   tree which will create them, which they run with "/bin/sh libtool".

4. Unfortunately, while "/bin/sh " usually looks for  in
   the current directory before searching through $PATH, on AIX it
   looks through $PATH first; thus the PHP Makefile winds up running
   /usr/local/bin/libtool (or wherever you have it installed) instead.

Thus the solution is to modify the PHP Makefile so that the line

   LIBTOOL = $(SHELL) libtool --silent

instead reads

   LIBTOOL = $(SHELL) ./libtool --silent

Technical notes: When you compile and install libtool, it runs a
script called libtool.m4 which, around line 2363 in the libtool-1.4.3
source, disables AIX static linking with the explanation that:

   "On AIX, shared libraries and static libraries use the same
   namespace, and are all built from PIC."

It disables static linking by setting enable_static=no when it writes
your libtool script; the ./libtool script in the PHP build directory
works precisely because this variable is set to "yes" instead.


Previous Comments:


[2002-12-12 06:39:33] [EMAIL PROTECTED]

Ignore that last post, being a bit of a muppet, using the wrong
version.



[2002-12-12 04:25:10] [EMAIL PROTECTED]

I've exactly the same problem, same version of AIX etc.  I have apache
2.0.43 installed and am using php 4.2.3.  Is this a compiler issue? Or
is it worth while trying 4.3.0RC3

I need to get this working fairly desperately.  So any help is
welcome.

Thanks

Julian



[2002-08-08 13:07:58] [EMAIL PROTECTED]

This is not a problem in PHP, but a problem with your (configuration of
your) system. Please ask support questions on the appropriate
mailinglist.



[2002-08-08 12:54:33] [EMAIL PROTECTED]

I would like to believe you but although it says "Target all is up to
date" the file it is looking for (libs/libphp4.so) hasn't been created.



[2002-08-08 11:58:16] [EMAIL PROTECTED]

Glad to hear the bug is fixed, but your new problem is an end user
problem, not a PHP bug.  Please figure out your installation, and where
you want things to go.  If you still have trouble with that, ask on the
php-general list for help.  



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

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

#21816 [Opn->Bgs]: preg_replace has problem with arrays

[iliaa]

 ID:   21816
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: *Regular Expressions
 Operating System: Windows XP
 PHP Version:  4.3.0
 New Comment:

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

The replacment is done in the order the array was created, if you want
it to be done based on array keys that run an appropriate sorting
function before executing the preg_replace function.


Previous Comments:


[2003-01-22 12:14:45] [EMAIL PROTECTED]

The search strings used in the preg_replace() function are regular
expressions. "[abc]" is a regular expression which matches any of the
characters "a", "b" or "c".

Either use str_replace() to replace your strings, or learn to use
regular expressions
.



[2003-01-22 08:41:20] [EMAIL PROTECTED]

" . $string2;
echo "Result should be: Say a [betterWord0] about
[betterWord1] and [betterWord2]";

// result should be:
//Say a [betterWord0] about [betterWord1] and [betterWord2]
//
// but produces: 
//Say a [betterWord0] about [betterWord2] and [betterWord1]
//
// Seems like the order in which i build my array
// is the order for replacing...and not the index
// of $array[$index]
//
// if you add a ksort it works fine:

ksort($search,SORT_NUMERIC);
ksort($replace,SORT_NUMERIC);   
reset($search);
reset($replace);

$string3 = preg_replace($search,$replace,$string);
echo "Corrected (ksort) Result is:" . $string3;

//
// Has someone an idea, about what's happening here?
//
// just a guy addicted to php ;-)
?>



[2003-01-22 07:43:39] [EMAIL PROTECTED]

" . $string;
echo "Result should be: Say a [betterWord0] about
[betterWord1] and [betterWord2]";

// result should be:
//Say a [betterWord0] about [betterWord1] and [betterWord2]
//
// but produces: 
//Say a [betterWord0] about [betterWord2] and [betterWord1]
//
// Seems like the order in which i build my array
// is the order for replacing...and not the index
// of $array[$index]
//
//
// Has someone an idea, about what's happening here?
//
// just a guy addicted to php ;-)
?>




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

#21818 [Opn->Bgs]: strange result with strtr()

[iliaa]

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

You are not specifying the array correctly.
it should be array('#' => '\#');

Otherwise it uses numeric keys for each array element 0 for # and 1 for
\#. Meaning that all 0s will be replaced with '#' and all 1s will be
replaced with \#.


Previous Comments:


[2003-01-22 08:56:55] [EMAIL PROTECTED]

on freeBSD I observed the same issue



[2003-01-22 08:53:49] [EMAIL PROTECTED]

when i execute this expression,

echo $val=strtr('1',array('"','\"'));

i obtain the following result :

\"

infact of 1

i try to make this operation with some other number but the problème
seems appear only with the string '1'

PS: sorry for my poor english




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

#21825 [NEW]: Fatal error: Nesting level too deep

[rhornsby]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4.19
PHP version:  4.3.0
PHP Bug Type: Reproducible crash
Bug description:  Fatal error: Nesting level too deep

This error occurs at the bottom of every PHP-parsed page:

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

The pages seem to render okay, but the error appears to end each page.  It
even spit out the same error dozens of times on make test, and after
sending in the test results.

./configure  --with-apxs=/usr/local/apache/bin/apxs  
 --enable-trans-sid
 --enable-track-vars
 --with-gd
 --with-pdflib
 --with-jpeg-dir  
 --with-tiff-dir
 --with-pspell
 --with-freetype-dir
 --enable-gd-native-ttf
 --with-png-dir 
 --with-zlib-dir
 --with-ttf
 --with-mysql=/usr/local/mysql

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

#21824 [Opn]: PHP-Based AIM Bot

[pollita]

 ID:   21824
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: all
 PHP Version:  4.3.0
 New Comment:

Speak of the devil, I was just thinking of this on my way home last
night (well, ICQ technically, but the idea is the same).

The conclusion I came to, and others may feel free to disagree with me,
is that such modules are best built as PEAR classes rather than PHP
extensions.  The fact that you're now mentioning that Perl has it as a
PEAR-equivalent style module just bolsters that position.

If you feel adventurous, I'd recommend working on the conversion
yourself.  You've got the basic framework to start from in Perl's
Net::AIM module, it simply needs to be built into a PHP class.


Previous Comments:


[2003-01-22 14:12:35] [EMAIL PROTECTED]

Any thoughts on converting the Perl Net::AIM module to PHP?

I think it would be great to be able to code an AIM bot in PHP.  has
this been discussed regarding the possibility of converting the AIM
protocols and make it an option for compiling into PHP?




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

#21824 [NEW]: PHP-Based AIM Bot

[thomas]

From: [EMAIL PROTECTED]
Operating system: all
PHP version:  4.3.0
PHP Bug Type: Feature/Change Request
Bug description:  PHP-Based AIM Bot

Any thoughts on converting the Perl Net::AIM module to PHP?

I think it would be great to be able to code an AIM bot in PHP.  has this
been discussed regarding the possibility of converting the AIM protocols
and make it an option for compiling into PHP?
-- 
Edit bug report at http://bugs.php.net/?id=21824&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21824&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=21824&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=21824&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21824&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=21824&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21824&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=21824&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21824&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21824&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=21824&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21824&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=21824&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=21824&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21824&r=gnused

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

[jeffabruce]

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

The version of gd.c that I have is supposed to be 4.3.0. I still
believe it is incorrect.

If you are referring to the statement:

Line 2951:   #else /* !USE_GD_IMGSTRTTF */

that 'else' is related to a "USE_GD_IMGSTRTTF" and is not the same as
any "HAVE_GD_STRINGxxx" defines.

I'm saying that if USE_GD_IMGSTRTTF *is* defined, but neither
HAVE_GD_STRINGFT nor HAVE_GD_STRINGTTF is defined, it will leave the
variable 'error' undefined, and then try to use it (resulting in the
possibility of a crash).

Do you still disagree?


Previous Comments:


[2003-01-21 14:20:13] [EMAIL PROTECTED]

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



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

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

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



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

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




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

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

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



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

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



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

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

#21820 [Opn]: bc break in parser

[philip]

 ID:  21820
 Updated by:  [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
 Status:  Open
 Bug Type:Scripting Engine problem
 PHP Version: 4.3.0
 New Comment:

Point was, maybe there is a reason this was not implemented.

And btw, this is a bug as 'foo' is defined yet the error says it's
not.



Previous Comments:


[2003-01-22 13:45:54] [EMAIL PROTECTED]

this patch fixes that feature request/bug as well



[2003-01-22 13:43:05] [EMAIL PROTECTED]

Allowing it would be nice but this topic has come up many times.  Not
sure why it's not been implemented though, maybe there are reasons?  I
forget them.

One feature request for this:
http://bugs.php.net/bug.php?id=15677




[2003-01-22 13:25:11] [EMAIL PROTECTED]

patch up at http://www2.omniti.com/~george/
zend.patch.2002012101

patch allows for "$arr['foo']" to be parsed correctly (this 
seems better than disallowing it)



[2003-01-22 09:19:20] [EMAIL PROTECTED]

I don't think this is a bug, but someone sent it to me via 
email, so I'm proxy-submitting:

Hello George-

I stumbled upon a serious bug in the string parser and it
goes something like this:

  $arr = array('foo' => 'bar');
  print "$arr['foo']";

This used to provide a parse error but now instead we get
this one of level E_NOTICE:

Notice: Undefined index:  'foo' in /tmp/a.php on line 4
/tmp/a.php(4) : Notice - Undefined index:  'foo'

This is a serious problem as it moved an error from
parse to E_NOTICE, fails silently as most have error
reporting turned down, shows a misleading error as foo
is defined, and breaks BC.

Tested latest 4_3 HEAD (4.3.1-dev).  I would try php5
but I get segfault when trying to compile/use it :)

Have a nice day,
Philip Olson

cc: derick




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