#22265 [NEW]: PHP fails to pass variables randomly

[andy at thegartsidegroup dot com]

From: andy at thegartsidegroup dot com
Operating system: Windows 2000
PHP version:  4.3.1
PHP Bug Type: IIS related
Bug description:  PHP fails to pass variables randomly

PHP 4.3.0 was working fine on W2kSP3 and IIS5 with latest security rollup
and with MySQL 3.23.50. It is a CGI installation.
Then I added a new user and changed some file permissions. These changes
were very careful and I made sure that IUSR_mymachine had read and execute
permissions to all required directories, as per the install.txt readme. My
IIS 5 web-development environment went crazy. Sometimes it worked,
sometimes it didn't.  works fine as a test file. Sometimes
I get a 404 message for files I know are there, other times I get a
complete failure to retrieve variables from the database (but not the
error message that I wrote if the DB connect failed) These files worked
perfectly just a few days ago. It no longer seems to support sessions
either. I spent days and days scouring the php sites, looking for a
solution - nothing. I am quite an expert at php and IIS 5 configuration
settings by now, so I have checked them repeatedly.
Eventually, I gave up. I repartitioned my hard-drive and re-installed
Windows 2000 SP3. This time, I added all the users I needed and set the
permissions before installing anything. I re-installed IIS and the rollup
package. I re-installed MySQL and tested it extensively. I went and got
the latest (4.3.1) php installer.exe and re-installed windows. SAME
PROBLEM!!! I reset all the permissions on all directories, sub-directories
and files on my entire machine to "full-control everyone" NO SUCCESS!
Random failures, mostly to do with variables disappearing in forms or in
queries to the databases.
I am desperate now. I NEED to do work, not chase this anymore. I'll see
how this goes today USA time, then I'll have to try rebuilding AGAIN with
no extra users and default file permissions. This is obviously not a very
good solution.
Thanks,
Andrew Gartside
(Canberra Australia)
-- 
Edit bug report at http://bugs.php.net/?id=22265&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22265&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22265&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22265&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22265&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22265&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22265&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22265&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22265&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22265&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22265&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22265&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22265&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22265&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22265&r=gnused

#22248 [Fbk->Opn]: Compile failed with php cgi / snmp

[simon at dnadogs dot com]

 ID:   22248
 User updated by:  simon at dnadogs dot com
 Reported By:  simon at dnadogs dot com
-Status:   Feedback
+Status:   Open
 Bug Type: SNMP related
 Operating System: Solaris 8
 PHP Version:  4CVS-2003-02-17 (stable)
 New Comment:

Hi,
I am running UCD-SNMP 5.07,  I have now compiled and installed snmp
from source and I still have the same problem.

The  apache php module will compile and work,  the cgi wont.
It looks like its compile everything ok then the final linking fails


Previous Comments:


[2003-02-17 10:50:01] [EMAIL PROTECTED]

What is the ucd snmp version?
And are you absolutely sure it's not some problem
with that binary? Have you tried compiling it yourself
from sources??




[2003-02-17 07:06:03] simon at dnadogs dot com

I have compiled php with snmp support as a apache module with no
problems but when I try to compile as cgi to be able to run scripts at
command line i get the following error.

/usr/local/sparc-sun-solaris2.8/bin/ld: bfd assertion fail
elflink.h:3542
I have cut down the configure command to just include snmp and mysql, 
if i remove snmp it works.

I have installed the binary UCD SNMP for solaris from the official
site.

All snmp functions work within the php / apache module.

Any help would be appreciated.




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

#22233 [Com]: "mod_gzip_on yes" makes force-cgi-redirect disabled and incorrect PHP_SELF

[thorsten at phpmyfaq dot de]

 ID:   22233
 Comment by:   thorsten at phpmyfaq dot de
 Reported By:  zlo at canada dot com
 Status:   Verified
 Bug Type: Apache related
 Operating System: RedHat 7.1, 7.2
 PHP Version:  4.3.1-dev
 New Comment:

reproduced with PHP 4.3.1 final with Debian Woody 3.0

My configure:
./configure --enable-track-vars=yes --enable-magic-quotes
--enable-versioning --disable-debug --enable-trans-sid
--enable-inline-optimization --enable-track-vars=yes
--enable-track-vars --with-db --with-gdbm --enable-force-cgi-redirect
--enable-mhash --with-openssl --with-iconv --with-mysql=/usr
-with-pgsql=/usr --with-ldap --enable-bcmath --enable-calendar
--enable-ftp --enable-memory-limit --enable-wddx --with-zlib
--with-zlib-dir=/usr/lib --with-ttf=/usr/lib --with-jpeg-dir=/usr/lib
--with-png-dir=/usr/lib --with-gd --with-freetype-dir=/usr
--enable-gd-native-ttf --enable-exif --enable-ctype --enable-shmop
--enable-sysvsem --enable-sysvshm --with-mcrypt --enable-discard-path
--enable-mbstring


Previous Comments:


[2003-02-16 14:05:03] [EMAIL PROTECTED]

reproducable with 4.2.3 and 4.0.6 on windows.



[2003-02-15 18:52:59] [EMAIL PROTECTED]

Reproduced with PHP 4.3.1-dev..




[2003-02-15 18:18:36] zlo at canada dot com

tried that, apparently it's not fixed.
just compiled php4-STABLE-200302152230, problem is still there.
when i turn on mod_gzip, its works like magic!



[2003-02-15 17:23:37] [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.




[2003-02-15 13:06:48] zlo at canada dot com

when "mod_gzip_on yes", PHP's force-cgi-redirect security mechanizm
becomes disabled (urls like /cgi-bin/php/test.php start working) and
PHP_SELF takes on a wrong value (/cgi-bin/php/test.php).
when "mod_gzip_on no", both aspects of the problem disappear.
problem has been observed on 2 different systems.
apache version: 1.3.26, 1.3.27
php version: latest snapshot
mod_gzip version: latest
php.ini does not exist.
php's configure:
./configure \
--with-config-file-path=/path/to/php \
--prefix=/path/to/php \
--enable-force-cgi-redirect \
--disable-cli \
--enable-bcmath \
--enable-trans-sid \
--with-zlib-dir=/build/zlib-1.1.4 \
--with-gd=/build/gd-1.8.4 \
--with-png-dir=/build/png-1.2.4 \
--with-jpeg-dir=/build/jpeg-6b \
--with-freetype \

apache's configure:
./configure \
--prefix=/path/to/apache \
--enable-module=so \
--enable-suexec \
--suexec-caller=www \
--suexec-docroot=/www \
no other modules loaded other than mod_gzip.
i thought this could well be PHP's problem. sorry if i'm wrong, then
please direct me to other possible sources of the problem.




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

#22072 [Ver]: connection_status() always returning 0

[neil at mpfreescene dot com]

 ID:   22072
 User updated by:  neil at mpfreescene dot com
 Reported By:  neil at mpfreescene dot com
 Status:   Verified
 Bug Type: Apache2 related
 Operating System: FREEBSD 4.7-STABLE
 PHP Version:  4.3.1-dev
 New Comment:

Just checking in with you guys, does it look like a problem that will
be fixed any time soon ?

Im guessing that Status : Verified does mean that you too can see the
error I speak of ? :)



Many thanks.


Previous Comments:


[2003-02-06 04:36:28] neil at mpfreescene dot com

To further assist you in your diagnosis, I have supplied you with
additional parameters to the script that is failing.


Firstly you can run the script

http://www.mpfreescene.com/test/

Secondly you can see the source

http://www.mpfreescene.com/test/?option=source

Thirdly you can see phpinfo

http://www.mpfreescene.com/test/?option=info

Forthly you can see the output.txt file, i.e. the result of the failing
script :-

http://www.mpfreescene.com/test/?option=data




Just to recap, this identical script works fine on apache 1,  I have
been to apache they are pushing it back as an php error [the error they
found in an apache2 specific library maybe ?].  And the problem is I
run the script, whenI press stop, it continues to run in the background
and completes normally, i.e. it doesnt recogonise the user abort.



Thanks for your help in this matteer.



[2003-02-06 01:55:15] neil at mpfreescene dot com

Installed this morning, fresh.

Absolutley no difference whatso ever, not even a little bit, still the
same 0's being reported via connection_status when the stop button is
pressed.



[2003-02-05 16:08:19] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2003-02-05 15:58:50] crockett at horizon dot bc dot ca

connection_status() always returns zero on Win32 4.3.0 running IIS.
Yes, ignore_user_abort(true) is set.

Bradley Crockett



[2003-02-05 09:05:27] neil at mpfreescene dot com

This bug is effecting the connection_status() function in apache 2.x

Okay, getting back to a long standing bug, which we kind of come to the
conclusion last time that it may be a bug in apache 2.x because it
works in apache 1.

Well time has come on, I have submitted the bug to apache after they
fixed the incorrect bytes logged bug, and this is what they have come
up with :-

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16426

ok, I've grabbed the current php source and looked into sapi_apache2.c.
It's
definitely a php bug. Line 90 shows:

if (ap_pass_brigade(f->next, bb) != APR_SUCCESS) {
php_handle_aborted_connection();
}

which won't match in most cases. Also Line 252 and 498.
AFAICS mod_php should (additionally) check connection->aborted.

(marking this bug invalid again)





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

#22250 [Fbk->Opn]: Sablotron version 0.96 or greater required

[phpbug at spambox dot dk]

 ID:   22250
 User updated by:  phpbug at spambox dot dk
 Reported By:  phpbug at spambox dot dk
-Status:   Feedback
+Status:   Open
 Bug Type: XSLT related
 Operating System: FreeBSD 4.7-stable
-PHP Version:  4CVS-2003-02-17 (stable)
+PHP Version:  4CVS-2003-02-18 (stable)
 Assigned To:  sniper
 New Comment:

Tried with php4-STABLE-200302180830.

Now I get a different error:
checking for SNMP support... yes
checking for default_store.h... yes
checking for OpenSSL support in SNMP libraries... yes
checking for kstat_read in -lkstat... no
checking for snmp_parse_oid... no
checking for init_snmp in -lsnmp... no
configure: error: SNMP sanity check failed. Please check config.log for
more information.

-- cut
%tail -n 25 config.log 

; return 0; }
configure:67088: checking for init_snmp in -lsnmp
configure:67107: gcc -o conftest -g -O2  -DMOD_SSL=208112 -DEAPI
-DUSE_EXPAT -DSHARED_CORE 

-R/usr/local/lib -L/usr/local/lib -R/usr/X11R6/lib -L/usr/X11R6/lib
-R/usr/local/mysql/lib/mysql -L/usr/local/mysql/lib/mysql -R/lib -L/lib
conftest.c -lsnmp  -lsnmp -lpdf -lz -ltiff -lpng -ljpeg -lmysqlclient
-lmcrypt -lltdl -lcrypt -lpam -lintl -lt1 -lfreetype -lX11 -lXpm -lpng
-lz -ljpeg -lz -lz -lssl -lcrypto -lm  -lxml2 -lz -lm -lssl -lcrypto
1>&5
/tmp/ccKXqjQR.s: Assembler messages:
/tmp/ccKXqjQR.s:30: Warning: .stabs: description field '1061e' too big,
try a different debug format
/tmp/ccKXqjQR.s:39: Warning: .stabn: description field '1061f' too big,
try a different debug format
/tmp/ccKXqjQR.s:42: Warning: .stabn: description field '10620' too big,
try a different debug format
/tmp/ccKXqjQR.s:49: Warning: .stabs: description field '1061e' too big,
try a different debug format
/usr/local/lib/libsnmp.so: undefined reference to `des_cbc_encrypt'
/usr/local/lib/libsnmp.so: undefined reference to `des_key_sched'
/usr/local/lib/libsnmp.so: undefined reference to `des_ncbc_encrypt'
configure: failed program was:
#line 67096 "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 init_snmp();

int main() {
init_snmp()
; return 0; }
-- cut

Im running OpenSSL 0.9.7

Could you move this to a relevant category?

Best regards Henrik


Previous Comments:


[2003-02-17 17:00:39] [EMAIL PROTECTED]

Please try the next stable snapshot from http://snaps.php.net/ in about
2 hours.




[2003-02-17 16:25:27] [EMAIL PROTECTED]

This actually is snmp problem, it doesn't have any test
that the selected libs actually work..I'm on it.





[2003-02-17 13:36:05] phpbug at spambox dot dk

Seems like youre on the right track.

%tail -n 25 config.log 
/tmp/cc4LD9kJ.s:250: Warning: .stabn: description field '12293' too
big, try a different debug format
/tmp/cc4LD9kJ.s:255: Warning: .stabn: description field '12294' too
big, try a different debug format
/tmp/cc4LD9kJ.s:260: Warning: .stabs: description field '1228c' too
big, try a different debug format
/tmp/cc4LD9kJ.s:261: Warning: .stabs: description field '1228d' too
big, try a different debug format
/usr/local/lib/libsnmp.so: undefined reference to `des_cbc_encrypt'
/usr/local/lib/libsnmp.so: undefined reference to `des_key_sched'
/usr/local/lib/libsnmp.so: undefined reference to `des_ncbc_encrypt'
configure: failed program was:
#line 74374 "configure"
#include "confdefs.h"

#include 
#include 

int main ()
{
double version;
version = atof(SAB_VERSION);

if (version >= 0.96) {
exit(0);
}
exit(255);
}


%./sablot-config --libs
-L/usr/local/lib -liconv -lexpat



[2003-02-17 12:29:25] [EMAIL PROTECTED]

Also the output of sablot-config --libs please. My guess is you have
iconv installed and Sablotron picked up on it. Could you confirm that?



[2003-02-17 12:01:40] [EMAIL PROTECTED]

Could you past the last 20 lines or so, from config.log?



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

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

#22266 [NEW]: Bug #21261 still left in 4.3.1

[ph at tripnet dot se]

From: ph at tripnet dot se
Operating system: Linux
PHP version:  4.3.1
PHP Bug Type: Scripting Engine problem
Bug description:  Bug #21261 still left in 4.3.1

Shouldn't this have been fixed in 4.3.1?


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

#22266 [Opn]: the bug #21261 still left in 4.3.1

[ph at tripnet dot se]

 ID:   22266
 User updated by:  ph at tripnet dot se
-Summary:  Bug #21261 still left in 4.3.1
 Reported By:  ph at tripnet dot se
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  4.3.1
 New Comment:

Shouldn't this have been fixed in 4.3.1?


Previous Comments:


[2003-02-18 03:14:47] ph at tripnet dot se

Shouldn't this have been fixed in 4.3.1?






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

#22267 [NEW]: Struts Validator

[markus dot schmitt at gzs dot de]

From: markus dot schmitt at gzs dot de
Operating system: WindowsXP
PHP version:  4.3.1
PHP Bug Type: Feature/Change Request
Bug description:  Struts Validator

Hallo.

The Struts Validator framework does not validate "required" if you define
a field property(that is defined as type: java.lang.Integer) of a form
which is declared in the struts-config.xml.

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

#22268 [NEW]: Struts Validator

[markus dot schmitt at gzs dot de]

From: markus dot schmitt at gzs dot de
Operating system: WindowsXP
PHP version:  4.3.1
PHP Bug Type: Feature/Change Request
Bug description:  Struts Validator

Hallo.

The Struts Validator framework does not validate "required" if you define
a field property(that is defined as type: java.lang.Integer) of a form
which is declared in the struts-config.xml.

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

#22248 [Opn]: Compile failed with php cgi / snmp

[simon at dnadogs dot com]

 ID:   22248
 User updated by:  simon at dnadogs dot com
 Reported By:  simon at dnadogs dot com
 Status:   Open
 Bug Type: SNMP related
 Operating System: Solaris 8
 PHP Version:  4CVS-2003-02-17 (stable)
 New Comment:

Further info.

A php binary is created in sapi/cgi/ and when i use it with a phpinfo()
it says that snmp is enabled but if I try to use snmp functions i get
they dont exist as follows -

php snmp.php 

Fatal error: Call to undefined function:  snmpget() in
/users/downloads/Apache/php4-STABLE-200302171030/sapi/cgi/snmp.php on
line 2
/users/downloads/Apache/php4-STABLE-200302171030/sapi/cgi/snmp.php(2) :
Fatal error - Call to undefined function:  snmpget()


Previous Comments:


[2003-02-18 02:31:10] simon at dnadogs dot com

Hi,
I am running UCD-SNMP 5.07,  I have now compiled and installed snmp
from source and I still have the same problem.

The  apache php module will compile and work,  the cgi wont.
It looks like its compile everything ok then the final linking fails



[2003-02-17 10:50:01] [EMAIL PROTECTED]

What is the ucd snmp version?
And are you absolutely sure it's not some problem
with that binary? Have you tried compiling it yourself
from sources??




[2003-02-17 07:06:03] simon at dnadogs dot com

I have compiled php with snmp support as a apache module with no
problems but when I try to compile as cgi to be able to run scripts at
command line i get the following error.

/usr/local/sparc-sun-solaris2.8/bin/ld: bfd assertion fail
elflink.h:3542
I have cut down the configure command to just include snmp and mysql, 
if i remove snmp it works.

I have installed the binary UCD SNMP for solaris from the official
site.

All snmp functions work within the php / apache module.

Any help would be appreciated.




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

#22266 [Com]: the bug #21261 still left in 4.3.1

[mail at phpguru dot dk]

 ID:   22266
 Comment by:   mail at phpguru dot dk
 Reported By:  ph at tripnet dot se
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  4.3.1
 New Comment:

If your read the release notice, you would see that the 4.3.1 release
only contains the security fix and no bugfixes at all.

/Christian


Previous Comments:


[2003-02-18 03:18:00] ph at tripnet dot se

Shouldn't this have been fixed in 4.3.1?



[2003-02-18 03:14:47] ph at tripnet dot se

Shouldn't this have been fixed in 4.3.1?






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

#22269 [NEW]: Inherited Classes ignore initalization-value of inherites Variables

[White_Angel at gmx dot de]

From: White_Angel at gmx dot de
Operating system: Linux;RedHat8.0;2.4.18-24
PHP version:  5CVS-2003-02-18 (dev)
PHP Bug Type: Class/Object related
Bug description:  Inherited Classes ignore initalization-value of inherites Variables

And Again:
Inherited Classes ignore initalization-value of inherites Variables

Clean CVS checkout.
default configure & make 
The Following Test Fail.
(Checked on 2 Systems. SMP & !SMP)
--TEST--
Classes inheritance test
--POST--
--GET--
--FILE--
a."\n";
  }
};

class bar extends foo {
  function display() {  /* alternative display function for class bar */
echo "This is class bar\n";
echo "a = ".$this->a."\n";
  }
};


$foo1 = new foo;
$foo1->display();
$bar1 = new bar;
$bar1->display();
--EXPECT--
This is class foo
a = Content A
This is class bar
a = Content A

--- Im getting
This is class foo
a = Content A
This is class bar
a = 


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

#19292 [Com]: random error: open_basedir restriction in effect. File is in wrong directory

[aw at mittwaldmedien dot de]

 ID:   19292
 Comment by:   aw at mittwaldmedien dot de
 Reported By:  tnowak at triger dot com dot pl
 Status:   Feedback
 Bug Type: Apache related
 Operating System: linux
 PHP Version:  4.2.3,4.3.0
 New Comment:

We have the same Problem, like described above.
On one of our system the Error comes up sometimes.
We deleted the source, untared it again and compiled it the 'different'
configure options.
Now it works 
Is it possible that there some problems with the configure options,
when they are not in the korrekt order or something like this.
This are the configure Options there it makes sometimes the error:
./configure --prefix=/usr/share --datadir=/usr/share/php
--bindir=/usr/bin --libdir=/usr/share --includedir=/usr/include
--with-_lib=lib --with-config-file-path=/etc --disable-debug
--enable-bcmath --enable-calendar --enable-ctype --enable-dbase
--enable-discard-path --enable-exif --enable-filepro
--enable-force-cgi-redirect --enable-ftp --enable-gd-imgstrttf
--enable-gd-native-ttf --enable-inline-optimization
--enable-magic-quotes --enable-shmop --enable-sigchild --enable-sysvsem
--enable-sysvshm --enable-trans-sid --enable-versioning --enable-wddx
--enable-yp --with-bz2 --with-dom=/usr/include/libxml2 --with-ftp
--with-gdbm --with-gettext --with-gmp --with-imap=yes
--with-jpeg-dir=/usr --with-ldap=yes --with-mcal=/usr --with-mcrypt
--with-ndbm --with-snmp --with-tiff-dir=/usr --with-xml
--with-xpm-dir=/usr/X11R6 --with-openssl --with-curl --with-imap-ssl
--with-mm --with-apxs=/usr/sbin/apxs --enable-discard-path
--enable-sockets --enable-track-vars=yes
--with-exec-dir=/usr/local/typo3sh/bin --with-gd=/usr/local/typo3sh
--with-gettext --with-jpeg-dir --with-mysql=/usr --with-png-dir
--with-tiff-dir --with-ttf=/usr/local/typo3sh --with-zlib=yes

and this is my 'working version.

./configure --prefix=/usr/share --datadir=/usr/share/php
--bindir=/usr/bin --libdir=/usr/share --includedir=/usr/include
--with-_lib=lib --with-config-file-path=/etc --disable-debug
--enable-bcmath --enable-calendar --enable-ctype --enable-dbase
--enable-discard-path --enable-exif --enable-filepro
--enable-force-cgi-redirect --enable-ftp --enable-gd-imgstrttf
--enable-gd-native-ttf --enable-inline-optimization
--enable-magic-quotes --enable-shmop --enable-sigchild --enable-sysvsem
--enable-sysvshm --enable-trans-sid --enable-versioning --enable-wddx
--enable-yp --with-bz2 --with-dom=/usr/include/libxml2 --with-ftp
--with-gdbm --with-gettext --with-gmp --with-imap=yes
--with-jpeg-dir=/usr --with-ldap=yes --with-mcal=/usr --with-mcrypt
--with-ndbm --with-qtdom=/usr/lib/qt2 --with-snmp --with-tiff-dir=/usr
--with-xml --with-xpm-dir=/usr/X11R6 --with-openssl --with-curl
--with-imap-ssl --with-mm --with-apxs=/usr/sbin/apxs
--enable-discard-path --enable-sockets --enable-track-vars=yes
--with-exec-dir=/usr/local/typo3sh/bin --with-gd=/usr/local/typo3sh
--with-gettext --with-jpeg-dir --with-mysql=/usr --with-png-dir
--with-tiff-dir --with-ttf=/usr/local/typo3sh --with-xml
--with-zlib=yes

maybe it helps to reproduce the problem and finding the bug.


Previous Comments:


[2003-02-15 17:10:45] [EMAIL PROTECTED]

Patch can be found here:
http://cvs.php.net/diff.php/php4/main/main.c?login=2&r1=1.512.2.9&r2=1.512.2.10&ty=u

(should apply to 4.3.0 sources too)




[2003-02-15 17:08:55] [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

I fixed a bug that prevented resetting the open_basedir
by using 'php_admin_value open_basedir none'. 

This most likely fixes this problem for at least some of
you who have added comments to this report.




[2003-02-05 11:25:59] birdman_ at _stones_ dot _com

Have/Had this problem on a Redhat7.1, Apache 1.3.27 and
- php 4.2.3
- php 4.3.0

Finally the solution was to include the '/usr/local/lib/php' to the
open_basedir ruleset, cause of PHP tries to look up the included files
there...somehow and although it's not there after all.

e.g. open_basedir = /wwwroot:/usr/local/lib/php



[2003-01-24 09:11:18] sanry at now dot net dot cn

I use redhat8.0   and upgrade from php4.12 to php4.2.3

and the file have open_basedir restriction,  and after
all the include file is inside the basedir not outside



[2003-01-20 13:16:28] mitch at karboneye dot com

Same problem FreeBSD 4.7p3 PHP 4.3.0 PHP 4.2.3 Apache 1.3.27 (bug
20190)



The remainder of the comments for this report are too long

#22266 [Opn]: the bug #21261 still left in 4.3.1

[ph at tripnet dot se]

 ID:   22266
 User updated by:  ph at tripnet dot se
 Reported By:  ph at tripnet dot se
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  4.3.1
 New Comment:

Ok, so were can i find the correct cgi_main.c (including security
fixes) in CVS that fixed the problem in 4.3.0?

I'm not really home in the CVS world ..


Previous Comments:


[2003-02-18 03:34:31] mail at phpguru dot dk

If your read the release notice, you would see that the 4.3.1 release
only contains the security fix and no bugfixes at all.

/Christian



[2003-02-18 03:18:00] ph at tripnet dot se

Shouldn't this have been fixed in 4.3.1?



[2003-02-18 03:14:47] ph at tripnet dot se

Shouldn't this have been fixed in 4.3.1?






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

#22184 [Fbk->Opn]: Compile fails looking for m4sugar

[marcus at synchromedia dot co dot uk]

 ID:   22184
 User updated by:  marcus at synchromedia dot co dot uk
 Reported By:  marcus at synchromedia dot co dot uk
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: OpenBSD 3.1-stable
 PHP Version:  4CVS-2003-02-12 (stable)
 New Comment:

After much frustration, I have now recompiled absolutely everything:
kernel, whole OS, all the appropriate dev tools (m4, autoconf etc),
pulled a fresh CVS copy of PHP, and now it finally compiles. I don't
know where the problem was, but wherever it was, it's now gone away. As
I don't know if the fix was done in PHP or my system, this should
probably be marked as bogus.


Previous Comments:


[2003-02-13 12:20:38] [EMAIL PROTECTED]

What is the EXACT output of 'm4 --version' ??
And did you get m4,libtool,autoconf from www.gnu.org ?
And compiled yourself? (m4 needs to be first..)




[2003-02-13 10:31:29] marcus at synchromedia dot co dot uk

I downgraded to autoconf 2.13 (and buildconf no longer complains about
it), but I'm still getting the same error.



[2003-02-13 09:14:41] [EMAIL PROTECTED]

Since the configure and the .h files are already built running
buildconf does nothing beyond checking that they exists and moving on.
Autoconf 2.53 is not recommended for building php configure, if
possible try upgrading to a later version (2.57 is the latest) or
downgrade to 2.13, which is known to work properly.



[2003-02-13 08:56:47] marcus at synchromedia dot co dot uk

>From my original posting: I'm using autoconf 2.53, automake 1.6.3,
libtool 1.4.3 and m4 1.4. Just for good measure, I recompiled and
reinstalled all of them. Any other programs I should check?

Is the release version built like a snapshot? It does do a buildconf
like the CVS version, but I don't get this error with it.



[2003-02-13 07:48:29] [EMAIL PROTECTED]

The difference betweent the snapshots & the CVS is that with snapshots
buildconf has already been run the the configure script has been built
using the individual m4 files. 
Since you are having problem with the CVS I must conclude that the
problem lies with one of the system utilities used during the buildconf
process.
What versions of autoconf & libtool are you using?



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

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

#22184 [Opn->Bgs]: Compile fails looking for m4sugar

[marcus at synchromedia dot co dot uk]

 ID:   22184
 User updated by:  marcus at synchromedia dot co dot uk
 Reported By:  marcus at synchromedia dot co dot uk
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: OpenBSD 3.1-stable
 PHP Version:  4CVS-2003-02-12 (stable)
 New Comment:

Marking as bogus.


Previous Comments:


[2003-02-18 04:17:50] marcus at synchromedia dot co dot uk

After much frustration, I have now recompiled absolutely everything:
kernel, whole OS, all the appropriate dev tools (m4, autoconf etc),
pulled a fresh CVS copy of PHP, and now it finally compiles. I don't
know where the problem was, but wherever it was, it's now gone away. As
I don't know if the fix was done in PHP or my system, this should
probably be marked as bogus.



[2003-02-13 12:20:38] [EMAIL PROTECTED]

What is the EXACT output of 'm4 --version' ??
And did you get m4,libtool,autoconf from www.gnu.org ?
And compiled yourself? (m4 needs to be first..)




[2003-02-13 10:31:29] marcus at synchromedia dot co dot uk

I downgraded to autoconf 2.13 (and buildconf no longer complains about
it), but I'm still getting the same error.



[2003-02-13 09:14:41] [EMAIL PROTECTED]

Since the configure and the .h files are already built running
buildconf does nothing beyond checking that they exists and moving on.
Autoconf 2.53 is not recommended for building php configure, if
possible try upgrading to a later version (2.57 is the latest) or
downgrade to 2.13, which is known to work properly.



[2003-02-13 08:56:47] marcus at synchromedia dot co dot uk

>From my original posting: I'm using autoconf 2.53, automake 1.6.3,
libtool 1.4.3 and m4 1.4. Just for good measure, I recompiled and
reinstalled all of them. Any other programs I should check?

Is the release version built like a snapshot? It does do a buildconf
like the CVS version, but I don't get this error with 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/22184

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

#22218 [Com]: COM function causes PHP crash

[lim at liones dot nl]

 ID:   22218
 Comment by:   lim at liones dot nl
 Reported By:  reedc at aap dot com dot au
 Status:   Feedback
 Bug Type: COM related
 Operating System: Windows 2000
 PHP Version:  4.3.0
 New Comment:

Same problem here with PHP 4.3.0

I've used the following code

$fso = new COM('Scripting.FileSystemObject');

and it crashes my script.
My browser receives some data but no ending.


Previous Comments:


[2003-02-17 23:21:11] [EMAIL PROTECTED]

Are you sure you updated all the files?
Especially php4ts.dll file? And that you don't 
have duplicates of the dlls anywhere?

And which snapshot did you get?




[2003-02-17 23:09:38] reedc at aap dot com dot au

COM functions continue to create an error that crashes php.exe. I have
downloaded the latest from CVS, but the problem persists.



[2003-02-14 16:27:00] [EMAIL PROTECTED]

This bug has been fixed in CVS.

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

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

there were sooo many reports regarding this, did you ever consider
reading the bugreports before filing your own ?



[2003-02-14 08:30:46] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2003-02-14 00:36:24] reedc at aap dot com dot au

One more bit of information... I found this in the event log:
The exception generated was c005 at address 10030727
(php_COM_release)



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

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

#22174 [Fbk->Csd]: php.ini being ignored - only in release version

[marcus at synchromedia dot co dot uk]

 ID:   22174
 User updated by:  marcus at synchromedia dot co dot uk
 Reported By:  marcus at synchromedia dot co dot uk
-Status:   Feedback
+Status:   Closed
 Bug Type: PHP options/info functions
 Operating System: OpenBSD 3.1-stable
-PHP Version:  4.3.1-dev
+PHP Version:  4.3.2-dev
 New Comment:

Now that I have finally got PHP-cvs compiling again, I'm happy to
report that it's picking up my php.ini from the compiled in location.
4.3.0-release still does not, so I guess whatever the probem is, it's
been fixed in CVS.


Previous Comments:


[2003-02-12 22:07:47] [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


(does anything work in openbsd? :)




[2003-02-12 04:24:24] marcus at synchromedia dot co dot uk

Unfortunately there doesn't seem to be a working strace for OpenBSD, I
can't get it to compile (reports unsupported OS) and it won't compile
as FreeBSD on my system.
PHP CLI works correctly if I specify -c and point to the ini file, but
it too does not pick up the ini from the compiled-in location (and as
noted elsewhere, it doesn't look in /php.ini either).
Probably best to leave this bug open/feedback until I can get the CVS
version working again (It's still broken for me today, so I'm reporting
it now).



[2003-02-11 20:37:27] [EMAIL PROTECTED]

Assuming you're using the PHP_4_3 branch, updated version.

Did you mean 'm4' outputs errors? Check your m4 version,
and if it's anything else than 1.4, update it.
If the error comes within configure, you might have
to rebuild your autoconf also with the new m4..




[2003-02-11 17:43:58] [EMAIL PROTECTED]

If you have an strace utility try to strace the cli binary and see if
it tries to open any ini files and if it successful openning any of
them.
This can be done using the following command:
strace php -h 2>&1 | grep ".ini"



[2003-02-11 16:46:59] marcus at synchromedia dot co dot uk

I'm already using libtool 1.4.3, so it's not that.

I last rebuilt PHP from CVS yesterday morning and it was all ok. Up
until switching to 4.3 release, I had never seen a problem with my ini
file. Very strange I know...

The compile problem seems to be something to do with gm4? It dumps lots
of pages relating to bison? I'll do a more accurate bug report if it's
still there tomorrow.



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

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

#22250 [Opn->Fbk]: Sablotron version 0.96 or greater required

[msopacua]

 ID:   22250
 Updated by:   [EMAIL PROTECTED]
 Reported By:  phpbug at spambox dot dk
-Status:   Open
+Status:   Feedback
-Bug Type: XSLT related
+Bug Type: SNMP related
 Operating System: FreeBSD 4.7-stable
 PHP Version:  4CVS-2003-02-18 (stable)
 Assigned To:  sniper
 New Comment:

Recategorizing.

Sniper's fix works: it points to the correct problem :)
>From the looks of this, you have a problem in your libsmnp library. Try
recompiling it and could you mention which snmp package this is? Is
this the ports version and if so, which exact version (ls -al
/var/db/pkg | grep snmp)?


Previous Comments:


[2003-02-18 02:47:37] phpbug at spambox dot dk

Tried with php4-STABLE-200302180830.

Now I get a different error:
checking for SNMP support... yes
checking for default_store.h... yes
checking for OpenSSL support in SNMP libraries... yes
checking for kstat_read in -lkstat... no
checking for snmp_parse_oid... no
checking for init_snmp in -lsnmp... no
configure: error: SNMP sanity check failed. Please check config.log for
more information.

-- cut
%tail -n 25 config.log 

; return 0; }
configure:67088: checking for init_snmp in -lsnmp
configure:67107: gcc -o conftest -g -O2  -DMOD_SSL=208112 -DEAPI
-DUSE_EXPAT -DSHARED_CORE 

-R/usr/local/lib -L/usr/local/lib -R/usr/X11R6/lib -L/usr/X11R6/lib
-R/usr/local/mysql/lib/mysql -L/usr/local/mysql/lib/mysql -R/lib -L/lib
conftest.c -lsnmp  -lsnmp -lpdf -lz -ltiff -lpng -ljpeg -lmysqlclient
-lmcrypt -lltdl -lcrypt -lpam -lintl -lt1 -lfreetype -lX11 -lXpm -lpng
-lz -ljpeg -lz -lz -lssl -lcrypto -lm  -lxml2 -lz -lm -lssl -lcrypto
1>&5
/tmp/ccKXqjQR.s: Assembler messages:
/tmp/ccKXqjQR.s:30: Warning: .stabs: description field '1061e' too big,
try a different debug format
/tmp/ccKXqjQR.s:39: Warning: .stabn: description field '1061f' too big,
try a different debug format
/tmp/ccKXqjQR.s:42: Warning: .stabn: description field '10620' too big,
try a different debug format
/tmp/ccKXqjQR.s:49: Warning: .stabs: description field '1061e' too big,
try a different debug format
/usr/local/lib/libsnmp.so: undefined reference to `des_cbc_encrypt'
/usr/local/lib/libsnmp.so: undefined reference to `des_key_sched'
/usr/local/lib/libsnmp.so: undefined reference to `des_ncbc_encrypt'
configure: failed program was:
#line 67096 "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 init_snmp();

int main() {
init_snmp()
; return 0; }
-- cut

Im running OpenSSL 0.9.7

Could you move this to a relevant category?

Best regards Henrik



[2003-02-17 17:00:39] [EMAIL PROTECTED]

Please try the next stable snapshot from http://snaps.php.net/ in about
2 hours.




[2003-02-17 16:25:27] [EMAIL PROTECTED]

This actually is snmp problem, it doesn't have any test
that the selected libs actually work..I'm on it.





[2003-02-17 13:36:05] phpbug at spambox dot dk

Seems like youre on the right track.

%tail -n 25 config.log 
/tmp/cc4LD9kJ.s:250: Warning: .stabn: description field '12293' too
big, try a different debug format
/tmp/cc4LD9kJ.s:255: Warning: .stabn: description field '12294' too
big, try a different debug format
/tmp/cc4LD9kJ.s:260: Warning: .stabs: description field '1228c' too
big, try a different debug format
/tmp/cc4LD9kJ.s:261: Warning: .stabs: description field '1228d' too
big, try a different debug format
/usr/local/lib/libsnmp.so: undefined reference to `des_cbc_encrypt'
/usr/local/lib/libsnmp.so: undefined reference to `des_key_sched'
/usr/local/lib/libsnmp.so: undefined reference to `des_ncbc_encrypt'
configure: failed program was:
#line 74374 "configure"
#include "confdefs.h"

#include 
#include 

int main ()
{
double version;
version = atof(SAB_VERSION);

if (version >= 0.96) {
exit(0);
}
exit(255);
}


%./sablot-config --libs
-L/usr/local/lib -liconv -lexpat



[2003-02-17 12:29:25] [EMAIL PROTECTED]

Also the output of sablot-config --libs please. My guess is you have
iconv installed and Sablotron picked up on it. Could you confirm that?



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

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

#22250 [Fbk->Opn]: Sablotron version 0.96 or greater required

[phpbug at spambox dot dk]

 ID:   22250
 User updated by:  phpbug at spambox dot dk
 Reported By:  phpbug at spambox dot dk
-Status:   Feedback
+Status:   Open
 Bug Type: SNMP related
 Operating System: FreeBSD 4.7-stable
 PHP Version:  4CVS-2003-02-18 (stable)
 Assigned To:  sniper
 New Comment:

The SNMP package is ucd-snmp-4.2.6.

I compiled this from source with the following:
./configure --prefix=/usr/local
--with-persistent-directory=/var/run/ucd-snmp
--with-sys-contact="[EMAIL PROTECTED]" --with-sys-location=Unknown
--with-logfile=/var/log/snmpd.log --with-openssl=/usr

I use this for my MRTG, without SSL though.


Previous Comments:


[2003-02-18 04:26:23] [EMAIL PROTECTED]

Recategorizing.

Sniper's fix works: it points to the correct problem :)
>From the looks of this, you have a problem in your libsmnp library. Try
recompiling it and could you mention which snmp package this is? Is
this the ports version and if so, which exact version (ls -al
/var/db/pkg | grep snmp)?



[2003-02-18 02:47:37] phpbug at spambox dot dk

Tried with php4-STABLE-200302180830.

Now I get a different error:
checking for SNMP support... yes
checking for default_store.h... yes
checking for OpenSSL support in SNMP libraries... yes
checking for kstat_read in -lkstat... no
checking for snmp_parse_oid... no
checking for init_snmp in -lsnmp... no
configure: error: SNMP sanity check failed. Please check config.log for
more information.

-- cut
%tail -n 25 config.log 

; return 0; }
configure:67088: checking for init_snmp in -lsnmp
configure:67107: gcc -o conftest -g -O2  -DMOD_SSL=208112 -DEAPI
-DUSE_EXPAT -DSHARED_CORE 

-R/usr/local/lib -L/usr/local/lib -R/usr/X11R6/lib -L/usr/X11R6/lib
-R/usr/local/mysql/lib/mysql -L/usr/local/mysql/lib/mysql -R/lib -L/lib
conftest.c -lsnmp  -lsnmp -lpdf -lz -ltiff -lpng -ljpeg -lmysqlclient
-lmcrypt -lltdl -lcrypt -lpam -lintl -lt1 -lfreetype -lX11 -lXpm -lpng
-lz -ljpeg -lz -lz -lssl -lcrypto -lm  -lxml2 -lz -lm -lssl -lcrypto
1>&5
/tmp/ccKXqjQR.s: Assembler messages:
/tmp/ccKXqjQR.s:30: Warning: .stabs: description field '1061e' too big,
try a different debug format
/tmp/ccKXqjQR.s:39: Warning: .stabn: description field '1061f' too big,
try a different debug format
/tmp/ccKXqjQR.s:42: Warning: .stabn: description field '10620' too big,
try a different debug format
/tmp/ccKXqjQR.s:49: Warning: .stabs: description field '1061e' too big,
try a different debug format
/usr/local/lib/libsnmp.so: undefined reference to `des_cbc_encrypt'
/usr/local/lib/libsnmp.so: undefined reference to `des_key_sched'
/usr/local/lib/libsnmp.so: undefined reference to `des_ncbc_encrypt'
configure: failed program was:
#line 67096 "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 init_snmp();

int main() {
init_snmp()
; return 0; }
-- cut

Im running OpenSSL 0.9.7

Could you move this to a relevant category?

Best regards Henrik



[2003-02-17 17:00:39] [EMAIL PROTECTED]

Please try the next stable snapshot from http://snaps.php.net/ in about
2 hours.




[2003-02-17 16:25:27] [EMAIL PROTECTED]

This actually is snmp problem, it doesn't have any test
that the selected libs actually work..I'm on it.





[2003-02-17 13:36:05] phpbug at spambox dot dk

Seems like youre on the right track.

%tail -n 25 config.log 
/tmp/cc4LD9kJ.s:250: Warning: .stabn: description field '12293' too
big, try a different debug format
/tmp/cc4LD9kJ.s:255: Warning: .stabn: description field '12294' too
big, try a different debug format
/tmp/cc4LD9kJ.s:260: Warning: .stabs: description field '1228c' too
big, try a different debug format
/tmp/cc4LD9kJ.s:261: Warning: .stabs: description field '1228d' too
big, try a different debug format
/usr/local/lib/libsnmp.so: undefined reference to `des_cbc_encrypt'
/usr/local/lib/libsnmp.so: undefined reference to `des_key_sched'
/usr/local/lib/libsnmp.so: undefined reference to `des_ncbc_encrypt'
configure: failed program was:
#line 74374 "configure"
#include "confdefs.h"

#include 
#include 

int main ()
{
double version;
version = atof(SAB_VERSION);

if (version >= 0.96) {
exit(0);
}
exit(255);
}


%./sablot-config --libs
-L/usr/local/lib -liconv -lexpat



The remainder of the comments for this report are too long. To view
th

#22233 [Com]: "mod_gzip_on yes" makes force-cgi-redirect disabled and incorrect PHP_SELF

[thorsten at phpmyfaq dot de]

 ID:   22233
 Comment by:   thorsten at phpmyfaq dot de
 Reported By:  zlo at canada dot com
 Status:   Verified
 Bug Type: Apache related
 Operating System: RedHat 7.1, 7.2
 PHP Version:  4.3.1-dev
 New Comment:

reproducable also _without_ mod_gzip on Debian Woody and the same
configure


Previous Comments:


[2003-02-18 02:40:09] thorsten at phpmyfaq dot de

reproduced with PHP 4.3.1 final with Debian Woody 3.0

My configure:
./configure --enable-track-vars=yes --enable-magic-quotes
--enable-versioning --disable-debug --enable-trans-sid
--enable-inline-optimization --enable-track-vars=yes
--enable-track-vars --with-db --with-gdbm --enable-force-cgi-redirect
--enable-mhash --with-openssl --with-iconv --with-mysql=/usr
-with-pgsql=/usr --with-ldap --enable-bcmath --enable-calendar
--enable-ftp --enable-memory-limit --enable-wddx --with-zlib
--with-zlib-dir=/usr/lib --with-ttf=/usr/lib --with-jpeg-dir=/usr/lib
--with-png-dir=/usr/lib --with-gd --with-freetype-dir=/usr
--enable-gd-native-ttf --enable-exif --enable-ctype --enable-shmop
--enable-sysvsem --enable-sysvshm --with-mcrypt --enable-discard-path
--enable-mbstring



[2003-02-16 14:05:03] [EMAIL PROTECTED]

reproducable with 4.2.3 and 4.0.6 on windows.



[2003-02-15 18:52:59] [EMAIL PROTECTED]

Reproduced with PHP 4.3.1-dev..




[2003-02-15 18:18:36] zlo at canada dot com

tried that, apparently it's not fixed.
just compiled php4-STABLE-200302152230, problem is still there.
when i turn on mod_gzip, its works like magic!



[2003-02-15 17:23:37] [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.




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

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

#13595 [Com]: Solution for "PHP Fatal error: Unable to start session mm module in Unknown on

[wjblack at yahoo dot com]

 ID:   13595
 Comment by:   wjblack at yahoo dot com
 Reported By:  plafundum at yahoo dot com
 Status:   Closed
 Bug Type: Session related
 Operating System: Debian Sid
 PHP Version:  4.0.6
 New Comment:

Boy, did I feel silly once I got this working.

libmm seems to puke heavily if you have no swap enabled, claiming no
memory.  I was getting ENOMEM errors, despite upping shmmax (to 64MB,
just to be sure) and having 120MB free core.  As soon as I ran swapon
/dev/hda2 and retried, everything was fine.

My setup was Debian Woody on a Cobalt Raq 3 (kernel 2.4.18).


Previous Comments:


[2003-02-04 09:06:25] stevenbalthazor at hotmail dot com

This bug has been fixed in the php-4.1.2-7.3.6 distributed by redhat in
rpm form, sort of.  When php is run from the commandline (e.g.
/usr/bin/php -q something.php) php creates a file:
/tmp/session_mm_cgi###.sem where ### is the uid of the user running the
script.  This bug was fixed by making each individual user get their
own .sem file.

The problem I have and which others may have is if you run multiple
scripts at the same time from a cron job with the same user you will
get the error: "PHP Fatal error:  Unable to start session mm module in
Unknown on line 0".  This is basically the same problem that was
causing this bug but slightly different.  This bug was fixed by giving
each user its own .sem file; however the case where a user would need
more than 1 .sem file was not fixed.  My primative understanding of how
this works is that the first script creates the session_mm_cgi###.sem
file; then when the second script comes along it can't create the file
because the file is already created.  It would appear that the path
used for the session_mm_cgi###.sem is the session.save_path specified
in the php.ini file; however changing this value in the script using
either ini_set or session_save_path has no impact on the location of
the session_mm_cgi###.sem file.  

Two workarounds exist that I have figured out if you must run multiple
php commandline scripts at the same time:
1.  run the scripts as different users; that way you will get different
session_mm_cgi###.sem files
2.  use a custom php.ini file for each script and specify a different
session.save_path in each php.ini file

It would be nice if the path where the mm_cgi###.sem file was saved
could be set at run time but there are probably dynamics at work which
prevent this.

You can see what session_mm_cgi###.sem file is created by running your
script:
strace -e trace=file -o output /usr/bin/php -q something.php
then open the created output file and do a search for sem



[2003-01-27 15:26:56] wouter at nucleus dot be

Hello,

I'm still having problems with this. 

PHP 4.1.2
Redhat 7.2
latest updates and fixes from Redhat are installed

Already checkec everything mentioned above, nothing works for me. I
don't get it all the time. It happens only when PHP is used at the
command line or in cronjobs...

Already searched google etc, no solution found so far.

Thanks.



[2002-08-09 14:24:32] kasper at 303 dot nu

I'm also using debian sid, and the same happens. PHP 4.2.1, nothing in
/tmp. The first time it happened I removed php4, and re-installed it,
and the problem was gone. And when it occured 15 minutes ago I tried
removing php4-cgi, which I also had installed, and the problem is gone
now. So there might be a kind of clash between php4 and php4-cgi?

But anyway, it would be very nice to have a more descriptive output
from php4...



[2002-07-30 22:49:50] jal at jal dot org

So, following this thread, I'm still not having any luck. 

I'm running debian-woodie, and upgraded to the 4.2.1 package for it. I
checked my php.ini for weird paths, checked /tmp and (because someone
mentioned it) /etc for session_mm files, and the problem still
persists. Here's what I get out of strace: 

open("/usr/lib/apache/1.3/libphp4.so", O_RDONLY) = 4
[...]
open("/usr/lib/libmm.so.11", O_RDONLY)  = 4
[...]
open("./php.ini", O_RDONLY|O_LARGEFILE) = 5
getcwd("/etc/php4/apache", 4096)= 17
lstat("/etc/php4/apache/php.ini", {st_mode=S_IFREG|0644, st_size=26777,
...}) = 0
open("/etc/ld.so.cache", O_RDONLY)  = 5
open("/lib/libnss_db.so.2", O_RDONLY)   = 5
open("/lib/libnss_files.so.2", O_RDONLY) = 5
open("/usr/lib/libdb3.so.3", O_RDONLY)  = 5
open("/var/lib/misc/protocols.db", O_RDWR|O_LARGEFILE) = -1 ENOENT (No
such file or directory)
open("/var/lib/misc/protocols.db", O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
open("/etc/protocols", O_RDONLY)= 5
open("/var/lib/misc/protocols.db", O_RDWR|O_LARGEFILE) = -1 ENOENT (No
such file or director

#22250 [Opn->Fbk]: Problem compiling snmp with openssl support

[msopacua]

 ID:   22250
 Updated by:   [EMAIL PROTECTED]
-Summary:  Sablotron version 0.96 or greater required
 Reported By:  phpbug at spambox dot dk
-Status:   Open
+Status:   Feedback
 Bug Type: SNMP related
 Operating System: FreeBSD 4.7-stable
 PHP Version:  4CVS-2003-02-18 (stable)
 Assigned To:  sniper
 New Comment:

Updated description.

The des* interfaces are from openssl. Is 4.7-stable using openssl 0.9.7
already, or did you compile that yourself?
If it is, I'll cvsup my box and try to replicate your problem - unable
to reproduce it, with system supplied openssl 0.9.6g and
ucd-snmp-4.2.5_2 port.

It looks like a problem outside of php though (snmp/openssl linking),
but I'd like to replicate this first to be sure.


Previous Comments:


[2003-02-18 04:33:11] phpbug at spambox dot dk

The SNMP package is ucd-snmp-4.2.6.

I compiled this from source with the following:
./configure --prefix=/usr/local
--with-persistent-directory=/var/run/ucd-snmp
--with-sys-contact="[EMAIL PROTECTED]" --with-sys-location=Unknown
--with-logfile=/var/log/snmpd.log --with-openssl=/usr

I use this for my MRTG, without SSL though.



[2003-02-18 04:26:23] [EMAIL PROTECTED]

Recategorizing.

Sniper's fix works: it points to the correct problem :)
>From the looks of this, you have a problem in your libsmnp library. Try
recompiling it and could you mention which snmp package this is? Is
this the ports version and if so, which exact version (ls -al
/var/db/pkg | grep snmp)?



[2003-02-18 02:47:37] phpbug at spambox dot dk

Tried with php4-STABLE-200302180830.

Now I get a different error:
checking for SNMP support... yes
checking for default_store.h... yes
checking for OpenSSL support in SNMP libraries... yes
checking for kstat_read in -lkstat... no
checking for snmp_parse_oid... no
checking for init_snmp in -lsnmp... no
configure: error: SNMP sanity check failed. Please check config.log for
more information.

-- cut
%tail -n 25 config.log 

; return 0; }
configure:67088: checking for init_snmp in -lsnmp
configure:67107: gcc -o conftest -g -O2  -DMOD_SSL=208112 -DEAPI
-DUSE_EXPAT -DSHARED_CORE 

-R/usr/local/lib -L/usr/local/lib -R/usr/X11R6/lib -L/usr/X11R6/lib
-R/usr/local/mysql/lib/mysql -L/usr/local/mysql/lib/mysql -R/lib -L/lib
conftest.c -lsnmp  -lsnmp -lpdf -lz -ltiff -lpng -ljpeg -lmysqlclient
-lmcrypt -lltdl -lcrypt -lpam -lintl -lt1 -lfreetype -lX11 -lXpm -lpng
-lz -ljpeg -lz -lz -lssl -lcrypto -lm  -lxml2 -lz -lm -lssl -lcrypto
1>&5
/tmp/ccKXqjQR.s: Assembler messages:
/tmp/ccKXqjQR.s:30: Warning: .stabs: description field '1061e' too big,
try a different debug format
/tmp/ccKXqjQR.s:39: Warning: .stabn: description field '1061f' too big,
try a different debug format
/tmp/ccKXqjQR.s:42: Warning: .stabn: description field '10620' too big,
try a different debug format
/tmp/ccKXqjQR.s:49: Warning: .stabs: description field '1061e' too big,
try a different debug format
/usr/local/lib/libsnmp.so: undefined reference to `des_cbc_encrypt'
/usr/local/lib/libsnmp.so: undefined reference to `des_key_sched'
/usr/local/lib/libsnmp.so: undefined reference to `des_ncbc_encrypt'
configure: failed program was:
#line 67096 "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 init_snmp();

int main() {
init_snmp()
; return 0; }
-- cut

Im running OpenSSL 0.9.7

Could you move this to a relevant category?

Best regards Henrik



[2003-02-17 17:00:39] [EMAIL PROTECTED]

Please try the next stable snapshot from http://snaps.php.net/ in about
2 hours.




[2003-02-17 16:25:27] [EMAIL PROTECTED]

This actually is snmp problem, it doesn't have any test
that the selected libs actually work..I'm on 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/22250

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

#9852 [Com]: Header redirect and db connection cause "CGI misbehaved"

[dragel at elelog dot es]

 ID:   9852
 Comment by:   dragel at elelog dot es
 Reported By:  ron dot baldwin at sourceprose dot com
 Status:   Closed
 Bug Type: IIS related
 Operating System: Windows 2000
 PHP Version:  4.2.1
 New Comment:

I solve the error replacing:

$q=odbc_do($conex,"selec");

for a calling to a function:

function ODBC($conex,$sql){
 return odbc_do($conex,$sql);
}

...

$q=ODBC($conex,"select ...");

the use of a function make spend time and solve the problem. It works
for me!


Previous Comments:


[2003-01-28 05:11:57] mlaukast1 at hotmail dot com

There's an interesting solution to 502 CGI Error in bug report #21681
by [EMAIL PROTECTED] Altough I wasn't able to get rid of the error
entirely, the solution dramatically reduced the appearance of it.



[2003-01-12 15:16:09] theo dot schoeberl at tssystems dot de

We have chanced our PHP-Script from using ODBC to native MSSQL (using
the MSSQL library). The same error (incl. 502 Bad Gateway).

The next try was to change the server name to its IP address within the
connect statement - and it works!

No error since the change, running now over 14 days!

May be there is a problem (known under Windows systems) resolving the
server name?

Hope this helps a lot of PHP developers running Windows systems!

Theo



[2003-01-07 17:29:12] vincent at sunlight dot tmfweb dot nl

Just an idea: does it help to close the database connection right
before calling the header('Location: URL') function? I understand that
putting in a timer helps (most of the time), but I think that's a bit
of an ugly solution. I mean: how long should you wait? The ideal number
of microseconds to sleep depends on the server, the load on the server,
and so on. As the problem occurs when there is a database connection, I
wonder if it goes away if this connection is closed, before doing the
real redirecting. Sadly enough I can't test this myself, because I
don't have access to a server that's fast enough. Anyone?



[2002-12-28 19:08:25] theo dot schoeberl at tssystems dot de

We have posted this problem first at 2001-06-28 (ID# 11788). This
request was closed (Bogus) with the following comment:

Once and for all: It's not the lack of interest, it's the lack of good
developers with knowledge about it. Historically, OpenSource projects
operating in cross-platform environments have a stronger unix
developer
community. It's a fact.

I think, the best way for IIS-Users is, to develope there page under
ASP!

And for PHP you should say: running under all unix plattforms - but not
under IIS!



[2002-12-27 07:00:54] nicolas at colbert dot ws

Good Afternoon,

I have seen many comments regarding PHP should be compliant with
enterprise software.  I would suggest that it is - UNIX and Apache are
enterprise level solutions and PHP is a ROCK star on those platforms. 
Just because we are no forcing it to do things on an AXX Backward
platform like MS W2k and XP is not a reason to complain.  

I have run into the issue, because I am having to rewrite our
authentication scripts because the IIS CGI cannont handle a simple
authentication redirect.  Before you blame PHP, try looking at all the
garbage hoops that IIS puts you through.

Nicolas



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

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

#22240 [Fbk->Opn]: number_format problem with numbers > 999

[shadlej at iwakuni dot usmc dot mil]

 ID:   22240
 User updated by:  shadlej at iwakuni dot usmc dot mil
 Reported By:  shadlej at iwakuni dot usmc dot mil
-Status:   Feedback
+Status:   Open
 Bug Type: Math related
 Operating System: Windows
 PHP Version:  4.3.0
 New Comment:

Well, it sort-of worked. I had to move the number_format function off
the $var and into the echo in BOTH areas. (follows) I don't know why it
works the other way up until a total of 999 and anything after that is
incorrect. I guess it doesn't matter. Lesson learned.  ThanX for
following up. 


// $totalamount = number_format($totalamount, 2);
  echo "\n";
  echo "Items Ordered:  ".$totalqty."\n";
  echo "Subtotal:   $".number_format($totalamount,
2)."\n";
  $taxrate = 0.10;
  $totalamount = $totalamount * (1 + $taxrate);
//  $totalamount = number_format($totalamount, 2);
  echo "Total including tax: $".number_format($totalamount,
2)."\n";


Previous Comments:


[2003-02-17 17:44:59] [EMAIL PROTECTED]



Does this work?




[2003-02-17 02:58:54] shadlej at iwakuni dot usmc dot mil

Same results. ( I used the Windows build ) Anything over 999 as a total
gets an incorrect result. BTW number_function should read
number_format. Sorry for the mistake.



[2003-02-16 10:28:20] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2003-02-16 03:44:07] shadlej at iwakuni dot usmc dot mil

I got this code from a book. It works as long as the total is less than
999. when it exceeds 999, it can't calculate the total properly. I
think it has something to do with the number_function.  


+index.html ++





  Item
  Quantity



  Tires
  



  Oil
  



  Spark Plugs
  



  





 preprocess.php ++



  Jim's Auto Parts - Order Results


Jim's Auto Parts
Order Results

Order Processed at ";
  echo date("H:i, jS F");
  echo "";
  echo "Your order is as follows:";
  echo "";
  echo $tireqty." tires";
  echo $oilqty." bottles of oil";
  echo $sparkqty." spark plugs";
  
  $totalqty = $tireqty + $oilqty + $sparkqty;
  $totalamount = $tireqty  * TIREPRICE
   + $oilqty   * OILPRICE
   + $sparkqty * SPARKPRICE;
  $totalamount = number_format($totalamount,2);
  echo "\n";
  echo "Items Ordered:  ".$totalqty."\n";
  echo "Subtotal:   $".$totalamount."\n";
  $taxrate = 0.10;
  $totalamount = $totalamount * (1 + $taxrate);
  $totalamount = number_format($totalamount, 2);
  echo "Total including tax: $".$totalamount."\n";

?>







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

#22267 [Opn->Bgs]: Struts Validator

[nicos]

 ID:   22267
 Updated by:   [EMAIL PROTECTED]
 Reported By:  markus dot schmitt at gzs dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: WindowsXP
 PHP Version:  4.3.1
 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.

Duplicate of #22268


Previous Comments:


[2003-02-18 03:24:05] markus dot schmitt at gzs dot de

Hallo.

The Struts Validator framework does not validate "required" if you
define a field property(that is defined as type: java.lang.Integer) of
a form which is declared in the struts-config.xml.





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

#22250 [Fbk->Opn]: Problem compiling snmp with openssl support

[phpbug at spambox dot dk]

 ID:   22250
 User updated by:  phpbug at spambox dot dk
 Reported By:  phpbug at spambox dot dk
-Status:   Feedback
+Status:   Open
 Bug Type: SNMP related
 Operating System: FreeBSD 4.7-stable
 PHP Version:  4CVS-2003-02-18 (stable)
 Assigned To:  sniper
 New Comment:

OpenSSL 0.9.7 is in FreeBSD 4.7-stable

>From /usr/src/UPDATEING:
20030214: OpenSSL 0.97 has been imported, and the libcrypto/libssl
library versions have been bumped.


Previous Comments:


[2003-02-18 04:55:58] [EMAIL PROTECTED]

Updated description.

The des* interfaces are from openssl. Is 4.7-stable using openssl 0.9.7
already, or did you compile that yourself?
If it is, I'll cvsup my box and try to replicate your problem - unable
to reproduce it, with system supplied openssl 0.9.6g and
ucd-snmp-4.2.5_2 port.

It looks like a problem outside of php though (snmp/openssl linking),
but I'd like to replicate this first to be sure.



[2003-02-18 04:33:11] phpbug at spambox dot dk

The SNMP package is ucd-snmp-4.2.6.

I compiled this from source with the following:
./configure --prefix=/usr/local
--with-persistent-directory=/var/run/ucd-snmp
--with-sys-contact="[EMAIL PROTECTED]" --with-sys-location=Unknown
--with-logfile=/var/log/snmpd.log --with-openssl=/usr

I use this for my MRTG, without SSL though.



[2003-02-18 04:26:23] [EMAIL PROTECTED]

Recategorizing.

Sniper's fix works: it points to the correct problem :)
>From the looks of this, you have a problem in your libsmnp library. Try
recompiling it and could you mention which snmp package this is? Is
this the ports version and if so, which exact version (ls -al
/var/db/pkg | grep snmp)?



[2003-02-18 02:47:37] phpbug at spambox dot dk

Tried with php4-STABLE-200302180830.

Now I get a different error:
checking for SNMP support... yes
checking for default_store.h... yes
checking for OpenSSL support in SNMP libraries... yes
checking for kstat_read in -lkstat... no
checking for snmp_parse_oid... no
checking for init_snmp in -lsnmp... no
configure: error: SNMP sanity check failed. Please check config.log for
more information.

-- cut
%tail -n 25 config.log 

; return 0; }
configure:67088: checking for init_snmp in -lsnmp
configure:67107: gcc -o conftest -g -O2  -DMOD_SSL=208112 -DEAPI
-DUSE_EXPAT -DSHARED_CORE 

-R/usr/local/lib -L/usr/local/lib -R/usr/X11R6/lib -L/usr/X11R6/lib
-R/usr/local/mysql/lib/mysql -L/usr/local/mysql/lib/mysql -R/lib -L/lib
conftest.c -lsnmp  -lsnmp -lpdf -lz -ltiff -lpng -ljpeg -lmysqlclient
-lmcrypt -lltdl -lcrypt -lpam -lintl -lt1 -lfreetype -lX11 -lXpm -lpng
-lz -ljpeg -lz -lz -lssl -lcrypto -lm  -lxml2 -lz -lm -lssl -lcrypto
1>&5
/tmp/ccKXqjQR.s: Assembler messages:
/tmp/ccKXqjQR.s:30: Warning: .stabs: description field '1061e' too big,
try a different debug format
/tmp/ccKXqjQR.s:39: Warning: .stabn: description field '1061f' too big,
try a different debug format
/tmp/ccKXqjQR.s:42: Warning: .stabn: description field '10620' too big,
try a different debug format
/tmp/ccKXqjQR.s:49: Warning: .stabs: description field '1061e' too big,
try a different debug format
/usr/local/lib/libsnmp.so: undefined reference to `des_cbc_encrypt'
/usr/local/lib/libsnmp.so: undefined reference to `des_key_sched'
/usr/local/lib/libsnmp.so: undefined reference to `des_ncbc_encrypt'
configure: failed program was:
#line 67096 "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 init_snmp();

int main() {
init_snmp()
; return 0; }
-- cut

Im running OpenSSL 0.9.7

Could you move this to a relevant category?

Best regards Henrik



[2003-02-17 17:00:39] [EMAIL PROTECTED]

Please try the next stable snapshot from http://snaps.php.net/ in about
2 hours.




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

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

#22233 [Ver]: "mod_gzip_on yes" makes force-cgi-redirect disabled and incorrect PHP_SELF

[zlo at canada dot com]

 ID:   22233
 User updated by:  zlo at canada dot com
 Reported By:  zlo at canada dot com
 Status:   Verified
 Bug Type: Apache related
 Operating System: RedHat 7.1, 7.2
 PHP Version:  4.3.1-dev
 New Comment:

Also reproducable with PHP Version 4.3.2-dev on RH7.2 with bare
configure (only --prefix specified).


Previous Comments:


[2003-02-18 04:42:19] thorsten at phpmyfaq dot de

reproducable also _without_ mod_gzip on Debian Woody and the same
configure



[2003-02-18 02:40:09] thorsten at phpmyfaq dot de

reproduced with PHP 4.3.1 final with Debian Woody 3.0

My configure:
./configure --enable-track-vars=yes --enable-magic-quotes
--enable-versioning --disable-debug --enable-trans-sid
--enable-inline-optimization --enable-track-vars=yes
--enable-track-vars --with-db --with-gdbm --enable-force-cgi-redirect
--enable-mhash --with-openssl --with-iconv --with-mysql=/usr
-with-pgsql=/usr --with-ldap --enable-bcmath --enable-calendar
--enable-ftp --enable-memory-limit --enable-wddx --with-zlib
--with-zlib-dir=/usr/lib --with-ttf=/usr/lib --with-jpeg-dir=/usr/lib
--with-png-dir=/usr/lib --with-gd --with-freetype-dir=/usr
--enable-gd-native-ttf --enable-exif --enable-ctype --enable-shmop
--enable-sysvsem --enable-sysvshm --with-mcrypt --enable-discard-path
--enable-mbstring



[2003-02-16 14:05:03] [EMAIL PROTECTED]

reproducable with 4.2.3 and 4.0.6 on windows.



[2003-02-15 18:52:59] [EMAIL PROTECTED]

Reproduced with PHP 4.3.1-dev..




[2003-02-15 18:18:36] zlo at canada dot com

tried that, apparently it's not fixed.
just compiled php4-STABLE-200302152230, problem is still there.
when i turn on mod_gzip, its works like magic!



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

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

#22065 [Fbk->Opn]: file() function

[paul dot d dot rowlands at delphi dot com]

 ID:   22065
 User updated by:  paul dot d dot rowlands at delphi dot com
 Reported By:  paul dot d dot rowlands at delphi dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: Windows 2000 server
 PHP Version:  4.3.0
 New Comment:

The warnings have reduced with the stable release. 
6 warnings in 48 hours.


Previous Comments:


[2003-02-13 20:37:20] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2003-02-06 09:43:01] paul dot d dot rowlands at delphi dot com

The file must exist to continue in the code:-
if(file_exists($file1)==FALSE) die("File1 does not exist");
The file is everybody full control.

What would have if the file was in use by another server (updating) ?
Can php detect this condition ?



[2003-02-06 08:45:38] [EMAIL PROTECTED]

Does the file exist?
What are the permissions for it?

(I think it's is_readable() that does not work correctly
on windows)




[2003-02-06 01:52:50] paul dot d dot rowlands at delphi dot com

safe_mode = Off
;open_basedir =



[2003-02-05 10:41:21] [EMAIL PROTECTED]

Do you have open_basedir or safe_mode enabled?



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

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

#22065 [Opn]: file() function

[paul dot d dot rowlands at delphi dot com]

 ID:   22065
 User updated by:  paul dot d dot rowlands at delphi dot com
 Reported By:  paul dot d dot rowlands at delphi dot com
 Status:   Open
 Bug Type: Filesystem function related
 Operating System: Windows 2000 server
 PHP Version:  4.3.0
 New Comment:

[18-Feb-2003 06:47:42] PHP Warning:  file(d:/temp/ht1/180203.ht1) [function.file]: failed to
open stream: Permission denied in d:\Apache
Group\Apache2\htdocs\fa_tools_ht.php on line 103


Previous Comments:


[2003-02-18 06:26:15] paul dot d dot rowlands at delphi dot com

The warnings have reduced with the stable release. 
6 warnings in 48 hours.



[2003-02-13 20:37:20] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2003-02-06 09:43:01] paul dot d dot rowlands at delphi dot com

The file must exist to continue in the code:-
if(file_exists($file1)==FALSE) die("File1 does not exist");
The file is everybody full control.

What would have if the file was in use by another server (updating) ?
Can php detect this condition ?



[2003-02-06 08:45:38] [EMAIL PROTECTED]

Does the file exist?
What are the permissions for it?

(I think it's is_readable() that does not work correctly
on windows)




[2003-02-06 01:52:50] paul dot d dot rowlands at delphi dot com

safe_mode = Off
;open_basedir =



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

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

#22002 [Com]: empty mask with regulary expression

[gmeakin at btinternet dot com]

 ID:   22002
 Comment by:   gmeakin at btinternet dot com
 Reported By:  benjch at cybercable dot fr
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: winXP
 PHP Version:  4.3.0
 New Comment:

Looks like the same effects reported and solved in bug #21262.

The problem was due to loading pages with IE under WinXP and was fixed
by installing Microsoft's service pack-1.


Previous Comments:


[2003-02-13 12:42:05] [EMAIL PROTECTED]

Please make sure you're upgrading PHP correctly and
ALL the dlls, especially php4ts.dll ! (sometimes a reboot is needed..)




[2003-02-13 08:47:54] [EMAIL PROTECTED]

dont know the status on this but i tried on winXP with php 4.3.0 and
couldnt reproduce it 



[2003-02-01 20:04:26] benjch at cybercable dot fr

I tried both version STABLE and Latest CVS (Win32 Package)but the bug
stay. It look like that happend on windows OS and not on linux...



[2003-02-01 17:01:44] [EMAIL PROTECTED]

Could you please try STABLE and Latest CVS from 
http://snaps.php.net and report ? 
 
I could not reproduce this on Linux with HEAD. 



[2003-02-01 16:32:27] [EMAIL PROTECTED]

Can't reproduce it with FreeBSD/Linux and PHP4.3.0/PHP5.0.0



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

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

#22251 [Bgs]: wrong parameters in $_GET/$_PUT tables

[mgf]

 ID:   22251
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kr at bpm dot pl
 Status:   Bogus
 Bug Type: *Programming Data Structures
 Operating System: RH8.0
 PHP Version:  4.2.3
 New Comment:

No, we understand you perfectly.  However, this is a choice that PHP
has made, and it's not going to change.

 is correct for PHP oly if you
wish to return a single result; if you want multiple results, PHP
requires you to use multiple  elements, *with* the [] array-designator on the names.



Previous Comments:


[2003-02-18 01:30:14] kr at bpm dot pl

I understand you Sniper :-) but you don't understand me.
Is this line correct?  Yes!!! It
is correct! I can call checkbox "par"
and I don't must call it "par[]". If "it is correct", the result of PHP
action ($_GET/$_PUT['par']) should be correct to!
When I call chackbox "par[]" it is simple crossing over the problem but
not founding real solution.



[2003-02-17 11:47:16] [EMAIL PROTECTED]

Again, append that [] in the name:



And no, we will not change this.




[2003-02-17 11:33:36] kr at bpm dot pl

This path: file.php?par[]=1&par[]=2&par[]=3 is correct for  my PHP.
Thanks.
But my opinion url: file.php?par=1&par=2&par=3 is correct too. 
Submit form with e.g.






[2003-02-17 11:04:57] [EMAIL PROTECTED]

A correct url of file.php?par[]=1&par[]=2&par[]=3
would give you the expected result..




[2003-02-17 09:56:44] kr at bpm dot pl

apache 2.0.40
web browser: file.php?par=1&par=2&par=3

echo count($_GET); // 1 
echo $_GET["par"]; // 3(string) not table with values:1,2,3




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

#22240 [Opn->Bgs]: number_format problem with numbers > 999

[mgf]

 ID:   22240
 Updated by:   [EMAIL PROTECTED]
 Reported By:  shadlej at iwakuni dot usmc dot mil
-Status:   Open
+Status:   Bogus
 Bug Type: Math related
 Operating System: Windows
 PHP Version:  4.3.0
 New Comment:

Just for the record, this was complete user-error.  The relevant lines
from the originally posted script are:

  $totalamount = number_format($totalamount,2);
  ...
  $taxrate = 0.10;
  $totalamount = $totalamount * (1 + $taxrate);

The first quoted line will set $totalamount to a string representation
of the dollar amount: "0.00" to "999.99" for numbers under 1000 (which
is fine), but then "1,000.00" and so on for greater values.  This is
then fed back into the calculation on the last quoted line, but as PHP
doesn't recognize commas as a valid part of a number, you just get the
digits before the first comma converted and used in your with-tax
calculation.  This is why moving the number_format() into the echos is,
in fact, the expected and correct solution.


Previous Comments:


[2003-02-18 05:27:35] shadlej at iwakuni dot usmc dot mil

Well, it sort-of worked. I had to move the number_format function off
the $var and into the echo in BOTH areas. (follows) I don't know why it
works the other way up until a total of 999 and anything after that is
incorrect. I guess it doesn't matter. Lesson learned.  ThanX for
following up. 


// $totalamount = number_format($totalamount, 2);
  echo "\n";
  echo "Items Ordered:  ".$totalqty."\n";
  echo "Subtotal:   $".number_format($totalamount,
2)."\n";
  $taxrate = 0.10;
  $totalamount = $totalamount * (1 + $taxrate);
//  $totalamount = number_format($totalamount, 2);
  echo "Total including tax: $".number_format($totalamount,
2)."\n";



[2003-02-17 17:44:59] [EMAIL PROTECTED]



Does this work?




[2003-02-17 02:58:54] shadlej at iwakuni dot usmc dot mil

Same results. ( I used the Windows build ) Anything over 999 as a total
gets an incorrect result. BTW number_function should read
number_format. Sorry for the mistake.



[2003-02-16 10:28:20] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2003-02-16 03:44:07] shadlej at iwakuni dot usmc dot mil

I got this code from a book. It works as long as the total is less than
999. when it exceeds 999, it can't calculate the total properly. I
think it has something to do with the number_function.  


+index.html ++





  Item
  Quantity



  Tires
  



  Oil
  



  Spark Plugs
  



  





 preprocess.php ++



  Jim's Auto Parts - Order Results


Jim's Auto Parts
Order Results

Order Processed at ";
  echo date("H:i, jS F");
  echo "";
  echo "Your order is as follows:";
  echo "";
  echo $tireqty." tires";
  echo $oilqty." bottles of oil";
  echo $sparkqty." spark plugs";
  
  $totalqty = $tireqty + $oilqty + $sparkqty;
  $totalamount = $tireqty  * TIREPRICE
   + $oilqty   * OILPRICE
   + $sparkqty * SPARKPRICE;
  $totalamount = number_format($totalamount,2);
  echo "\n";
  echo "Items Ordered:  ".$totalqty."\n";
  echo "Subtotal:   $".$totalamount."\n";
  $taxrate = 0.10;
  $totalamount = $totalamount * (1 + $taxrate);
  $totalamount = number_format($totalamount, 2);
  echo "Total including tax: $".$totalamount."\n";

?>







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

#22270 [NEW]: cgi binary parses itself when called directly

[zlo at canada dot com]

From: zlo at canada dot com
Operating system: RedHat 7.2
PHP version:  4CVS-2003-02-18 (stable)
PHP Bug Type: Apache related
Bug description:  cgi binary parses itself when called directly

when PHP cgi binary is called from cgi-bin without cgi-redirect, it parses
itself (argv[0] of the binary, whatever that happens to be)! i don't think
it represents much of a security problem (it still does to some extent,
because it reveals path to php and default settings), and no sane person
will run the cgi binary without cgi-redirect, but i don't think its the
way its supposed to be either..

here is a simple example; this also works with the php binary itself in
place of this binary. 
this results in some binary output and the typical phpinfo() page in the
middle:
# cat php.c

#include 
#include 
#include 

const char *PHP_BINARY="/path/to/php/bin/php";
const char * dummy="";

int main(int argc, char *argv[]){
  execl(PHP_BINARY,argv[0],0);
  return 1;
};

p.s. btw this simple wrapper (without the phpinfo() part, or course) can
be used as a workaround for the vulnerability with cgi-redirect that
resulted in the release of 4.3.1 since it removes parameters before
exec'ing php itself..

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

#22271 [NEW]: sybase_fetch_array / sybase_fetch_object returns wrong datatype

[aheckmann at m-s dot de]

From: aheckmann at m-s dot de
Operating system: SuseLinux
PHP version:  4.3.0
PHP Bug Type: Sybase-ct (ctlib) related
Bug description:  sybase_fetch_array / sybase_fetch_object returns wrong datatype

if you have in your database in field double 1.1, 2.2, 3.3, 4.4

while($robj=sybase_fetch_object($rs))
{
  echo $robj->double ."\n";
}

output is:

1.1
2
3
4

Only the first value is correct ...



The error seems to be in ext/sybase_ct/php_sybase_ct.c in line 1062:


switch (result->numerics[j]) {
case 1:
convert_to_long(&result->data[i][j]);
break;
case 2: 
convert_to_double(&result->data[i][j]); result->numerics[j]= 
1; 
break;
}



why "result->numerics[j]= 1"; //Debugging stuff?



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

#22272 [NEW]: Segmentation Fault (11)

[webmaster at cryptpad dot com]

From: webmaster at cryptpad dot com
Operating system: RedHat 7.2
PHP version:  4.3.1
PHP Bug Type: Reproducible crash
Bug description:  Segmentation Fault (11)

Installed PHP as a DSO Module in Apache. Install went fine. Modified
httpd.conf file to include LoadModule & AddType declarations, then stopped
and started Apache.

Whenever I go to access a PHP page, it returns no data and puts the
following into the apache error log:

[Tue Feb 18 14:13:34 2003] [notice] child pid 9320 exit signal
Segmentation fault (11)

Doing a backtrace reveals the following:

(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
0x4040c5e6 in send_php (r=0x83fa594, display_source_mode=0, filename=0x0)
at /install/php-4.3.1/sapi/apache/mod_php4.c:498
498 per_dir_conf = (HashTable *) 
get_module_config(r->per_dir_config, 
&php4_module);
(gdb) bt
#0  0x4040c5e6 in send_php (r=0x83fa594, display_source_mode=0,
filename=0x0)
at /install/php-4.3.1/sapi/apache/mod_php4.c:498
#1  0x4040c80e in send_parsed_php (r=0x83fa594) at
/install/php-4.3.1/sapi/apache/mod_php4.c:571
#2  0x080afea3 in ap_invoke_handler ()
#3  0x080c4f03 in ap_some_auth_required ()
#4  0x080c4f64 in ap_process_request ()
#5  0x080bbda1 in ap_child_terminate ()
#6  0x080bbf4c in ap_child_terminate ()
#7  0x080bc0c0 in ap_child_terminate ()
#8  0x080bc738 in ap_child_terminate ()
#9  0x080bcf9b in main ()
#10 0x40087657 in __libc_start_main (main=0x80bcbf4 , argc=2,
ubp_av=0xb9b4, 
init=0x8065630 <_init>, fini=0x8172b40 <_fini>, rtld_fini=0x4000dcd4
<_dl_fini>, 
stack_end=0xb9ac)
at ../sysdeps/generic/libc-start.c:129


/install/php-4.3.1/ is where I installed PHP from. Should it really be
running the mod_php4.c file from there?

Can anyone help?

P.S. I also have a separate copy of apache running which is my ssl server.
I tried to install PHP into that copy in the same way, and it worked
fine!!

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

#22213 [Opn]: Apache mod_ssl + PHP + cURL SSL segfault

[alan at pair dot com]

 ID:   22213
 User updated by:  alan at pair dot com
 Reported By:  alan at pair dot com
 Status:   Open
 Bug Type: cURL related
 Operating System: FreeBSD 4.6-STABLE
 PHP Version:  4CVS-2003-02-13 (stable)
 New Comment:

Here's a stack dump when it segfaults:

Program received signal SIGSEGV, Segmentation fault.
0x81df50c in SSL_CTX_ctrl ()
(gdb) bt
#0  0x81df50c in SSL_CTX_ctrl ()
#1  0x81793f4 in ssl_init_Module (s=0x830b038, p=0x830b010)
#2  0x8179741 in ssl_init_Module (s=0x830b038, p=0x830b010)
at ssl_engine_init.c:304
#3  0x8195dd0 in ap_init_modules (p=0x830b010, s=0x830b038)
at http_config.c:1703
#4  0x81a059e in standalone_main (argc=5, argv=0xbfbffa54) at
http_main.c:5172
#5  0x81a0ec0 in main (argc=5, argv=0xbfbffa54) at http_main.c:5566
#6  0x807f72d in _start ()
(gdb) 

However, as I mentioned before, that's not completely accurate. 
Stepping through the code, here's a bit more detail as to where it's
crashing:

(gdb)n
585 ctx = SSL_CTX_new(SSLv23_server_method()); /* be more
flexible */
(gdb) bt
#0  ssl_init_ConfigureServer (s=0x830b038, p=0x830b010, sc=0x830b3e0)
at ssl_engine_init.c:585
#1  0x8179741 in ssl_init_Module (s=0x830b038, p=0x830b010)
at ssl_engine_init.c:304
#2  0x8195dd0 in ap_init_modules (p=0x830b010, s=0x830b038)
at http_config.c:1703
#3  0x81a059e in standalone_main (argc=5, argv=0xbfbffa54) at
http_main.c:5172
#4  0x81a0ec0 in main (argc=5, argv=0xbfbffa54) at http_main.c:5566
#5  0x807f72d in _start ()
(gdb) n
586 SSL_CTX_set_options(ctx, SSL_OP_ALL);
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0x81df50c in SSL_CTX_ctrl ()
(gdb) bt
#0  0x81df50c in SSL_CTX_ctrl ()
#1  0x81793f4 in ssl_init_Module (s=0x830b038, p=0x830b010)
#2  0x8179741 in ssl_init_Module (s=0x830b038, p=0x830b010)
at ssl_engine_init.c:304
#3  0x8195dd0 in ap_init_modules (p=0x830b010, s=0x830b038)
at http_config.c:1703
#4  0x81a059e in standalone_main (argc=5, argv=0xbfbffa54) at
http_main.c:5172
#5  0x81a0ec0 in main (argc=5, argv=0xbfbffa54) at http_main.c:5566
#6  0x807f72d in _start ()
(gdb) 


This particular version is compiled with PHP 4.3.0, Apache 1.3.27,
mod_ssl 2.8.12, and curl 7.10.3.  But I've been able to reproduce it
with different versions of curl and PHP.

If I run the same compiled executable without SSL turned on, it does
not segfault when it receives HUP.
If I compile curl --without-ssl, and compile php against this version
of curl, apache does not segfault when it receives SIGHUP even when
modssl is turned on.
If I compile PHP without curl, apache does not segfault when it
receives SIGHUP.

I don't know that it's curl's fault.  I just know that the problem goes
away when PHP isn't using curl, or when curl isn't using SSL.

Thanks,
Alan


Previous Comments:


[2003-02-14 17:16:26] daniel at haxx dot se

How about providing a stack trace or something that shows us what was
going on when it crashed?

For information, libcurl calls only two functions to initialize the
OpenSSL library:

SSL_load_error_strings();
SSLeay_add_ssl_algorithms(); (a define for SSL_library_init)

(The rest is done when some action is called for, and this report says
that isn't required for this problem to occur.)

I honestly can't see how this can be wrong from a libcurl point of
view.



[2003-02-14 08:41:39] alan at pair dot com

Regarding notes/issues raised on bug #22112:
I made sure that apache is linking against only one copy of libssl and
libcrypto.  

We have a global ErrorLog directive in the httpd.conf we're testing
with, but no VirtualHost blocks at all: it's a base conf file, and the
server doesn't even need to serve any pages for this to be a problem
for us.

Our httpd.conf conditionally turns on SSL only when the "-DSSL" flag is
present.  When apache is run without that flag, it works without any
problems.  It crashes only when SSL is running.

("SSLEngine on" only happens with -DSSL)

Thanks.



[2003-02-14 08:33:47] alan at pair dot com

The configure command:

./configure --with-apache=/usr/pair/sw/apachessl_1.3.27
--with-config-file-path=/usr/local/etc --enable-magic-quotes
--enable-bcmath --without-cdb --with-zlib-dir=/usr/local --with-gd
--without-ttf --without-msql --with-mysql=/usr/local --with-iodbc
--with-pdflib --enable-inline-optimization --disable-memory-limit
--with-db --without-gdbm --with-ndbm --without-db2 --without-dbm
--with-gettext --without-readline --with-recode
--with-openssl=/usr/local/ssl --with-mcrypt --without-db3 --enable-dba
--with-curl=/usr/local/lib --with-png-dir=/usr/local/lib

Compiling without "--with-curl" fixes the bug.  Compiling curl
"--without-ssl" also does the trick.

#6509 [Com]: Parsing HTTP GET values (with apache)

[lewisluk at hotmail dot com]

 ID:   6509
 Comment by:   lewisluk at hotmail dot com
 Reported By:  nicod at inwind dot it
 Status:   Closed
 Bug Type: Installation problem
 Operating System: Linux Mandrake 7.1
 PHP Version:  4.0.2
 New Comment:

Is there any way to get parsing working WITHOUT turning on
register_globals?

Thank you!


Previous Comments:


[2000-09-03 03:47:26] [EMAIL PROTECTED]

Turn register_globals on in your php.ini file



[2000-09-03 03:41:07] nicod at inwind dot it

Every thing was working fine with v.4.0.1pl2, but when I upgraded PHP
to v.4.0.2 , the engine doesn't seem to be parsing HTTP GET and POST
values anymore.  

Configure line: 
./configure --with-pgsql --with-apxs --with-java

php.ini file the same as the php.ini-optimized featured in php 4.0.2

apache ver. 1.3.12

php compiled in dynamic module mode

===
file put.php :






==
file get.php :

";  
// prints unexpectectly:  pms is =#
// while expecting:  pms is =12#

$QUERY_STRING = getenv("QUERY_STRING");
echo "Query string is $QUERY_STRING ";
// prints Query string is 12  *4_strange_chars* =vai

phpinfo();
// the field HTTP_GET_VARS["pms"]  seems to be correct: 12
// the field HTTP_GET_VARS["submit"]  seems to be correct: vai
// the field HTTP_SERVERVARS["QUERY_STRING"]  seems to be INcorrect:
pms=12 *4_strange_chars*=vai
?>

==
Thank you!




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

#22273 [NEW]: Cannot load libphp4.so into server: Unresolved external

[germano60 at yahoo dot it]

From: germano60 at yahoo dot it
Operating system: HP-UX 11.00
PHP version:  4.3.0
PHP Bug Type: Apache2 related
Bug description:  Cannot load libphp4.so into server: Unresolved external

Hello

I already looked in the support resources and in the bug lists but could
not find a suitable clue.

I compiled apache and php then when I tried to start the web server, but
this is the error message I got:
Syntax error on line 233 of /usr/local/apache2/conf/httpd.conf:
Cannot load /usr/local/apache2/modules/libphp4.so into server: Unresolved
external

The error line did not return any further indications about which
"external" did not resolve.

Configuration:
hp-ux 11.00
php 4.3.0
apache 2.0.44
gcc 3.2

Apache was generated with:
./configure \
  --prefix=/usr/local/apache2 \
  --enable-so

Php4.3.0 was configured with:
./configure \
  --with-mysql \
  --with-apxs2=/usr/local/apache2/bin/apxs

I modified the configure script for PHP by replacing invokes of "-lcrypt"
with "-lc" and of "-ltermcap" with "-lcurses" to get libphp4.so generated
by php's "make install" under the hp-ux 11 platform.
php's "make" and "make install" succeeded.

DSO modules were installed in the Apache2's default location 
/usr/local/apache2/modules and this is also where PHP's make install
stored the library libphp4.so. In httpd.conf I added the following line:
LoadModule  php4_module  modules/libphp4.so

I'm not sure whether this is really a bug or due to my minimal
configuration - I tried some of the hints I found in the support/bugs but
without success.

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

#22274 [NEW]: Parsing variable from FLASH/HTML without turning on register_globals?

[lewisluk at hotmail dot com]

From: lewisluk at hotmail dot com
Operating system: Redhat Linux 8.1
PHP version:  4.3.1
PHP Bug Type: Variables related
Bug description:  Parsing variable from FLASH/HTML without turning on 
register_globals? 

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

#21689 [NoF->Csd]: fgetcsv suppresses some characters before a separator

[moriyoshi]

 ID:   21689
 Updated by:   [EMAIL PROTECTED]
 Reported By:  alpes at softhome dot net
-Status:   No Feedback
+Status:   Closed
 Bug Type: Filesystem function related
 Operating System: OS/2
 PHP Version:  4.2.3
 New Comment:

This bug has been fixed in CVS.

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

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




Previous Comments:


[2003-02-04 16:49:51] [EMAIL PROTECTED]

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





[2003-01-21 04:14:32] [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


Your example works just fine here (linux), using 4.3.1-dev.





[2003-01-21 04:04:38] alpes at softhome dot net

Has refreshed soft:
PHP Version 4.3.0
Apache/1.3.27
But the error in operation of the function has remained



[2003-01-16 12:19:26] [EMAIL PROTECTED]

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

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





[2003-01-16 10:41:56] alpes at softhome dot net

fgetcsv suppresses some characters before a separator
[OS/2 kheldar 1 2.45 i386, PHP Version 4.2.3, Apache/1.3.22]
For example if the csv file has following content:

âàø|âåø|âàøå|àø|ø|øø

the comand $date = fgetcsv($f, 1000, "|");

gets the array('âà','âå','âàøå','à','','').
instead of
array('âàø','âåø','âàøå','àø','ø','øø').

Is installed, that Example works correctly with:
1.FreeBSD 4.1, PHP Version 4.1.2, Apache/1.3.19
2.Windows 98 4.10, PHP Version 4.1.1, Apache/1.3.6




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

#19292 [Com]: random error: open_basedir restriction in effect. File is in wrong directory

[aw at mittwaldmedien dot de]

 ID:   19292
 Comment by:   aw at mittwaldmedien dot de
 Reported By:  tnowak at triger dot com dot pl
 Status:   Feedback
 Bug Type: Apache related
 Operating System: linux
 PHP Version:  4.2.3,4.3.0
 New Comment:

after one hour the same problem comes up.

the funny thing is, that we have a second machine with suse 8.1, same
apache version and there it works.

so i copied the libphp.so from one machine to the other.

it doesn't help.
Has someone found a working workaround ?


Previous Comments:


[2003-02-18 04:08:21] aw at mittwaldmedien dot de

We have the same Problem, like described above.
On one of our system the Error comes up sometimes.
We deleted the source, untared it again and compiled it the 'different'
configure options.
Now it works 
Is it possible that there some problems with the configure options,
when they are not in the korrekt order or something like this.
This are the configure Options there it makes sometimes the error:
./configure --prefix=/usr/share --datadir=/usr/share/php
--bindir=/usr/bin --libdir=/usr/share --includedir=/usr/include
--with-_lib=lib --with-config-file-path=/etc --disable-debug
--enable-bcmath --enable-calendar --enable-ctype --enable-dbase
--enable-discard-path --enable-exif --enable-filepro
--enable-force-cgi-redirect --enable-ftp --enable-gd-imgstrttf
--enable-gd-native-ttf --enable-inline-optimization
--enable-magic-quotes --enable-shmop --enable-sigchild --enable-sysvsem
--enable-sysvshm --enable-trans-sid --enable-versioning --enable-wddx
--enable-yp --with-bz2 --with-dom=/usr/include/libxml2 --with-ftp
--with-gdbm --with-gettext --with-gmp --with-imap=yes
--with-jpeg-dir=/usr --with-ldap=yes --with-mcal=/usr --with-mcrypt
--with-ndbm --with-snmp --with-tiff-dir=/usr --with-xml
--with-xpm-dir=/usr/X11R6 --with-openssl --with-curl --with-imap-ssl
--with-mm --with-apxs=/usr/sbin/apxs --enable-discard-path
--enable-sockets --enable-track-vars=yes
--with-exec-dir=/usr/local/typo3sh/bin --with-gd=/usr/local/typo3sh
--with-gettext --with-jpeg-dir --with-mysql=/usr --with-png-dir
--with-tiff-dir --with-ttf=/usr/local/typo3sh --with-zlib=yes

and this is my 'working version.

./configure --prefix=/usr/share --datadir=/usr/share/php
--bindir=/usr/bin --libdir=/usr/share --includedir=/usr/include
--with-_lib=lib --with-config-file-path=/etc --disable-debug
--enable-bcmath --enable-calendar --enable-ctype --enable-dbase
--enable-discard-path --enable-exif --enable-filepro
--enable-force-cgi-redirect --enable-ftp --enable-gd-imgstrttf
--enable-gd-native-ttf --enable-inline-optimization
--enable-magic-quotes --enable-shmop --enable-sigchild --enable-sysvsem
--enable-sysvshm --enable-trans-sid --enable-versioning --enable-wddx
--enable-yp --with-bz2 --with-dom=/usr/include/libxml2 --with-ftp
--with-gdbm --with-gettext --with-gmp --with-imap=yes
--with-jpeg-dir=/usr --with-ldap=yes --with-mcal=/usr --with-mcrypt
--with-ndbm --with-qtdom=/usr/lib/qt2 --with-snmp --with-tiff-dir=/usr
--with-xml --with-xpm-dir=/usr/X11R6 --with-openssl --with-curl
--with-imap-ssl --with-mm --with-apxs=/usr/sbin/apxs
--enable-discard-path --enable-sockets --enable-track-vars=yes
--with-exec-dir=/usr/local/typo3sh/bin --with-gd=/usr/local/typo3sh
--with-gettext --with-jpeg-dir --with-mysql=/usr --with-png-dir
--with-tiff-dir --with-ttf=/usr/local/typo3sh --with-xml
--with-zlib=yes

maybe it helps to reproduce the problem and finding the bug.



[2003-02-15 17:10:45] [EMAIL PROTECTED]

Patch can be found here:
http://cvs.php.net/diff.php/php4/main/main.c?login=2&r1=1.512.2.9&r2=1.512.2.10&ty=u

(should apply to 4.3.0 sources too)




[2003-02-15 17:08:55] [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

I fixed a bug that prevented resetting the open_basedir
by using 'php_admin_value open_basedir none'. 

This most likely fixes this problem for at least some of
you who have added comments to this report.




[2003-02-05 11:25:59] birdman_ at _stones_ dot _com

Have/Had this problem on a Redhat7.1, Apache 1.3.27 and
- php 4.2.3
- php 4.3.0

Finally the solution was to include the '/usr/local/lib/php' to the
open_basedir ruleset, cause of PHP tries to look up the included files
there...somehow and although it's not there after all.

e.g. open_basedir = /wwwroot:/usr/local/lib/php



[2003-01-24 09:11:18] sanry at now dot net dot cn

I use redhat8.0   and upgrade from php4.12 to php4.2.3

and the file have open_basedir restricti

#21495 [Com]: strlen, substr and so on bug

[public at hverdag dot dk]

 ID:   21495
 Comment by:   public at hverdag dot dk
 Reported By:  roger4a45 at yahoo dot es
 Status:   Bogus
 Bug Type: Strings related
 Operating System: windows 2000 server sp3
 PHP Version:  4.2.3
 New Comment:

Excuse me roger4a45, but isn't that exactly what the problem is?! That
it returns another output than expected?!
It returns 0 where it SHOULD return something around 50!

I probably have the same problem with strlen. When I use this:

if (strlen($mydateformat) < 4)

...and I _KNOW_ that $mydateformat is longer than 0, it often returns
the length 0! But then when I reload the page the error doesn't occur
again - usually only the first time I run this page in a new browser
window!

To me this really sounds like a bug...


Previous Comments:


[2003-01-07 12:26:55] roger4a45 at yahoo dot es

A bug is when a function don't work properly... so, if I make
strlen("") i wait that output will be 6. if strlen produce
another result is a bug. Ok. I will try to comment it to support forum.
Thanks.



[2003-01-07 12:22:30] [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.



[2003-01-07 12:17:59] roger4a45 at yahoo dot es

whe we use strlen or substr there is a bug if parameter string is
something like this: 

$a =
"somethinghi!";
$b = strlen($a);
echo $b;

output is 0 rather real length of string Substr don't work right if
we use same $a... 

any idea?

Is use a PHP 4.2.3 (ZIP file)







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

#22275 [NEW]: CLI and --enable-mime-magic Spews Warnings

[hans at nyu dot edu]

From: hans at nyu dot edu
Operating system: RedHat 6.2 (2.2.14)
PHP version:  4.3.1
PHP Bug Type: Unknown/Other Function
Bug description:  CLI and --enable-mime-magic Spews Warnings

Hopefully I'm not missing something obvious.  After downloading PHP 4.3.1
to a RedHat 6.2 box, I configured and compiled like so for use as a CLI
bin:

./configure
--prefix=/usr/local/psh --disable-cgi
--disable-ipv6 --with-openssl=/usr/local/ssl
--with-zlib --enable-bcmath
--with-bz2 --enable-dio
--enable-ftp --enable-mime-magic
--with-mysql=/usr/local/mysql --with-ncurses
--enable-pcntl --with-readline
--enable-shmop --enable-sockets
--enable-sysvmsg --enable-sysvsem
--enable-sysvshm

Everything happily compiles and installs, but when finally running the
binary as /usr/local/psh/bin/php -v the following is spewed out:

HTTP/1.0 0 X
Content-type: text/html

PHP Warning:  mime_magic: (line 3859) offset `&0string  >\0
 %s  '
invalid in Unknown on line 0
PHP Warning:  mime_magic: type &0   string  >\0 %s 
  invalid in Unknown
on line 0
PHP Warning:  mime_magic: (line 3860) offset `&0string  >\0
 %s  '
invalid in Unknown on line 0
PHP Warning:  mime_magic: type &0   string  >\0 %s 
  invalid in Unknown
on line 0
PHP Warning:  mime_magic: (line 3861) offset `&0string  >\0
 %s  '
invalid in Unknown on line 0
PHP Warning:  mime_magic: type &0   string  >\0 %s 
  invalid in Unknown on
line 0
PHP Warning:  mime_magic: (line 3862) offset `&0string  >\0
 %s  '
invalid in Unknown on line 0
PHP Warning:  mime_magic: type &0   string  >\0 %s 
  invalid in Unknown on
line 0
PHP 4.3.1 (cli) (built: Feb 17 2003 22:13:02)
Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies

The same type of output occurs whether I use php -h or just plain php with
no arguments.  Looking at /usr/share/magic I've excerpted the lines as
noted:

3848# HP Printer Job Language
38490   string  \033%-12345X@PJLHP Printer Job Language data
3850# HP Printer Job Language
3851# The header found on Win95 HP plot files is the "Silliest Thing
possible" 
3852# (TM)
3853# Every driver puts the language at some random position, with random
case
3854# (LANGUAGE and Language)
3855# For example the LaserJet 5L driver puts the "PJL ENTER LANGUAGE" in
line 10
3856# From: Uwe Bonnes <[EMAIL PROTECTED]>
3857# 
38580   string  \033%-12345X@PJLHP Printer Job Language data
3859>&0 string  >\0 %s
3860>>&0string  >\0 %s
3861>>>&0   string  >\0 %s  3862&0  string 
 >\0 %s 
3863#>15string  \ ENTER\ LANGUAGE\ =
3864#>31string  PostScript  PostScript

If I then make distclean and ./configure just as above, but without
--enable-mime-magic everything looks as it should.  Should CLI and
--enable-mime-magic not be used together?  Hopefully this all makes sense
to someone and this message comes out readable.

Thanks,

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

#21390 [Com]: php.exe does not work - needs Kernel32.dll::CancelIo

[joku1935 at yahoo dot com]

 ID:   21390
 Comment by:   joku1935 at yahoo dot com
 Reported By:  dmitry at koteroff dot ru
 Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Windows 95
 PHP Version:  4.3.0
 New Comment:

I don't understand.

1) If I download 
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
will it work in win95A (OSR1) ?

2) where is the report about this ?

sniper mentioned it here:
[31 Jan 1:46pm] [EMAIL PROTECTED] 
Oops..we don't support win95 anymore since 4.3.0..
(there's another report about this too..in "Documentation problem"
category)

Thanks - Joseph


Previous Comments:


[2003-01-31 13:46:04] [EMAIL PROTECTED]

Oops..we don't support win95 anymore since 4.3.0..
(there's another report about this too..in "Documentation problem"
category)




[2003-01-31 13:45:07] [EMAIL PROTECTED]

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





[2003-01-16 03:56:01] [EMAIL PROTECTED]

Try:

http://snaps.php.net/win32/php4-win32-STABLE-latest.zip



[2003-01-16 02:08:25] system at codeworks dot gen dot nz

I get 'permission denied' when I try to access the Windows snapshot.



[2003-01-07 19:43:24] [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/21390

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

#20274 [Com]: failed to create stream: Too many open files in Unknown on line

[webmaster at telearmenia dot net dot co]

 ID:   20274
 Comment by:   webmaster at telearmenia dot net dot co
 Reported By:  fowler at csufresno dot edu
 Status:   Open
 Bug Type: iPlanet related
 Operating System: Solaris 8
 PHP Version:  4CVS-2002-11-06
 New Comment:

We are running php4.3.0 with Sun One Web Server 6.0sp5 on
Solaris 8. It was compiled with gcc 2.95.3 using './configure' \
'--with-nsapi=/path/to/iplanet/web/server' \

It compiled successfully and runs fine for a few hours or minutes but
accessing
pages soon reports the following:

==
Warning: Unknown(/path/to/doc-root/index.php): failed to create
stream:
Too many open files in Unknown on line 0

Warning: Failed opening '/path/to/doc-root/index.php' for inclusion
(include_path='.:/usr/local/lib/php') in Unknown on line 0
==
We increased our kernel file descriptor limit, but shows the same
mistake 
A quick fix is to setup a cron job to restart the web server hourly,
but
this is not desired.

Please if someone can provide information with since this problem
solves

Thanks


Previous Comments:


[2003-01-31 12:51:22] coneill at mpctc dot net

I have the same problem. I am running iPlanet 6sp3 Enterprise, Solaris
9, PHP 4.3.0.  I get this error after 
php executes some scripts a few times. I did not have this problem
yesterday with PHP 4.2.3. I don't have any output at this moment. I
just thought i would let you know the problem seems to be widespread.



[2003-01-30 02:38:09] thetas at obs-nancay dot fr

with solaris 8 iplanet6.0sp5 php4.3.0
I have the same error
before, with solaris 8 iplanet 6.0sp4 php4.2.3, it works fine
but now if i install php4.2.1 or 4.2.3 i have "SIGSEGV 11 segmentation
violation" on my web server.

My configuration is : 
gcc 3.2.1
bison 1.875
make 3.80
GNU m4 1.4
autoconf 2.57
automake 1.7.2
binutils 2.11.2
GNU sed 4.0
libtool 1.4
flex 2.5.4a

my configure option is :
./configure --with-nsapi=/path/to/iplanet/web/server'
--with-ldap=/path/to/ldap/ --with-mysql=/path/to/mysql -enable-libgcc



[2003-01-29 11:16:28] diltsj at ae dot com

iPlanet 6sp4 Enterprise, Solaris 8, PHP 4.3.0.  I get this error after

php executes a script a few times.  This doesn't seem to reproduce 
under any certain conditions, typically within a few hits though.  I 
have 4 other configurations running flawlessly.  2x Solaris 2.6 
iPlanet Enterprise 6sp1 and 2x Solaris 8 iPlanet Enterprise 6sp3.

Could this be something with iPlanet's changes with sp4?

Warning:
Unknown(/local/home/cxadmin/content/Sites/Site01/
DocumentRoot/phpinfo.php):
failed to create stream: Too many open files in Unknown on line 0

Warning: Unknown(): Failed opening
'/local/home/cxadmin/content/Sites/Site01/DocumentRoot/
phpinfo.php' for
inclusion (include_path='.:/usr/local/lib/php') in Unknown on line 0

MEASURES ALREADY TAKEN:
recompile of the php module ('./configure' '--without-mysql'
'--with-nsapi=/local/Netscape/iplanet/www6.0sp4' '--enable-track-
vars'
'--enable-libgcc' )
Upped the Hard File Descriptor to 7554
explicitly set include path, session.save path, and safe_mode
ENVIRONMENT:
We have this running with out a hitch on two other boxes, under a 
similar config, with the exception of there are two instances of 
iPlanet running on the box that keeps crashing.
CODE:
// Logic To Decide Which Image To Include
$DESIGN;
if ($SEL == 1) {
$DESIGN="design_1.jpg";
}
else if ($SEL == 2) {
$DESIGN="design_2.jpg";
}
else if ($SEL == 3) {
$DESIGN="design_3.jpg";
}
else if ($SEL == 4) {
$DESIGN="design_4.jpg";
}
else if ($SEL == 5 ) {
$DESIGN="design_5.jpg";
}
else {
$DESIGN="design_6.jpg";
}

//Email Headers
$headers .= "From: ".$FNAME."<".$FEML.">\n";
$headers .= "X-Sender: <".$FEML.">\n";
$headers .= "X-Mailer: <".$FNAME.">\n";
$headers .= "Return-Path: <".$FEML.">\n";
$headers .= "Content-Type: text/html";
// Display Header Content
$Message ="\n";
$Message .="\n";
...Other $Message Code Ommitted  to save space

//Mail function (variables are passed from the from on the previous 
page)
Globals are set to on
mail($TEML, $TNAME.", You Have An Message From ".$FNAME, 
$Message,
$headers);



[2003-01-21 19:14:06] fowler at csufresno dot edu

Increasing file descriptors only delays the problem.

Our script to monitor the problem reports the following:
Monitoring http://our.site.com
Attempting to contact instance, try # 0
Web server successfully contacted
Too many open files being reported. Likely PHP problem ... 
=-=-=-=-=-=-=-=-=-=-= HTML RETURNED =-=-=-=-=-=-=-=-
HTTP/1.1 200 OK
C

#22266 [Opn->Bgs]: the bug #21261 still left in 4.3.1

[moriyoshi]

 ID:   22266
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ph at tripnet dot se
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  4.3.1
 New Comment:

Please forward further comments to the page for bug #21261.

Check out http://snaps.php.net/ for the latest cvs snapshots.



Previous Comments:


[2003-02-18 04:16:55] ph at tripnet dot se

Ok, so were can i find the correct cgi_main.c (including security
fixes) in CVS that fixed the problem in 4.3.0?

I'm not really home in the CVS world ..



[2003-02-18 03:34:31] mail at phpguru dot dk

If your read the release notice, you would see that the 4.3.1 release
only contains the security fix and no bugfixes at all.

/Christian



[2003-02-18 03:18:00] ph at tripnet dot se

Shouldn't this have been fixed in 4.3.1?



[2003-02-18 03:14:47] ph at tripnet dot se

Shouldn't this have been fixed in 4.3.1?






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

#21495 [Bgs]: strlen, substr and so on bug

[roger4a45 at yahoo dot es]

 ID:   21495
 User updated by:  roger4a45 at yahoo dot es
 Reported By:  roger4a45 at yahoo dot es
 Status:   Bogus
 Bug Type: Strings related
 Operating System: windows 2000 server sp3
 PHP Version:  4.2.3
 New Comment:

I think my problem is when I use strlen inside a class with HTML TAGS
delimiters ('<' and '>'). Behavior of strlen is bad. if $a = ""
it says that strlen($a) is 0 rather than 6. I used substr to change '<'
and '>' for '¬' and '&' and then use strlen. but of course is
dirty-dirty.


Previous Comments:


[2003-02-18 09:43:15] public at hverdag dot dk

Excuse me roger4a45, but isn't that exactly what the problem is?! That
it returns another output than expected?!
It returns 0 where it SHOULD return something around 50!

I probably have the same problem with strlen. When I use this:

if (strlen($mydateformat) < 4)

...and I _KNOW_ that $mydateformat is longer than 0, it often returns
the length 0! But then when I reload the page the error doesn't occur
again - usually only the first time I run this page in a new browser
window!

To me this really sounds like a bug...



[2003-01-07 12:26:55] roger4a45 at yahoo dot es

A bug is when a function don't work properly... so, if I make
strlen("") i wait that output will be 6. if strlen produce
another result is a bug. Ok. I will try to comment it to support forum.
Thanks.



[2003-01-07 12:22:30] [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.



[2003-01-07 12:17:59] roger4a45 at yahoo dot es

whe we use strlen or substr there is a bug if parameter string is
something like this: 

$a =
"somethinghi!";
$b = strlen($a);
echo $b;

output is 0 rather real length of string Substr don't work right if
we use same $a... 

any idea?

Is use a PHP 4.2.3 (ZIP file)







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

#22276 [NEW]: Loading Extensions

[msanders at primary dot net]

From: msanders at primary dot net
Operating system: Windows 2000
PHP version:  4.3.1
PHP Bug Type: Dynamic loading
Bug description:  Loading Extensions

We have upgraded from 4.2.3 to 4.3.1 for the recent CGI vulnerability. PHP
runs fine until we attempt to load an extension. Then we recieve the
following Application Popup:

Application popup: php.exe - Entry Point Not Found : The procedure entry
point php_file_le_fopen could not be located in the dynamic link library
php4ts.dll.  
-- 
Edit bug report at http://bugs.php.net/?id=22276&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22276&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22276&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22276&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22276&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22276&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22276&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22276&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22276&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22276&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22276&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22276&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22276&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22276&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22276&r=gnused

#21390 [Bgs]: php.exe does not work - needs Kernel32.dll::CancelIo

[mgf]

 ID:   21390
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dmitry at koteroff dot ru
 Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Windows 95
 PHP Version:  4.3.0
 New Comment:

> 1) If I download 
> http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
> will it work in win95A (OSR1) ?

No.

> 2) where is the report about this ?

(a) here!
(b) bug #21927



Previous Comments:


[2003-02-18 10:00:34] joku1935 at yahoo dot com

I don't understand.

1) If I download 
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
will it work in win95A (OSR1) ?

2) where is the report about this ?

sniper mentioned it here:
[31 Jan 1:46pm] [EMAIL PROTECTED] 
Oops..we don't support win95 anymore since 4.3.0..
(there's another report about this too..in "Documentation problem"
category)

Thanks - Joseph



[2003-01-31 13:46:04] [EMAIL PROTECTED]

Oops..we don't support win95 anymore since 4.3.0..
(there's another report about this too..in "Documentation problem"
category)




[2003-01-31 13:45:07] [EMAIL PROTECTED]

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





[2003-01-16 03:56:01] [EMAIL PROTECTED]

Try:

http://snaps.php.net/win32/php4-win32-STABLE-latest.zip



[2003-01-16 02:08:25] system at codeworks dot gen dot nz

I get 'permission denied' when I try to access the Windows 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/21390

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

#22268 [Opn->Bgs]: Struts Validator

[moriyoshi]

 ID:   22268
 Updated by:   [EMAIL PROTECTED]
 Reported By:  markus dot schmitt at gzs dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: WindowsXP
 PHP Version:  4.3.1
 New Comment:

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

Thank you for your interest in PHP.

How on earth does it concern PHP?


Previous Comments:


[2003-02-18 03:24:17] markus dot schmitt at gzs dot de

Hallo.

The Struts Validator framework does not validate "required" if you
define a field property(that is defined as type: java.lang.Integer) of
a form which is declared in the struts-config.xml.





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

#22276 [Opn->Fbk]: Loading Extensions

[moriyoshi]

 ID:   22276
 Updated by:   [EMAIL PROTECTED]
 Reported By:  msanders at primary dot net
-Status:   Open
+Status:   Feedback
 Bug Type: Dynamic loading
 Operating System: Windows 2000
 PHP Version:  4.3.1
 New Comment:

Are you sure that all the dlls that came with the previous version were
uninstalled before the installation of 4.3.1?



Previous Comments:


[2003-02-18 10:47:48] msanders at primary dot net

We have upgraded from 4.2.3 to 4.3.1 for the recent CGI vulnerability.
PHP runs fine until we attempt to load an extension. Then we recieve
the following Application Popup:

Application popup: php.exe - Entry Point Not Found : The procedure
entry point php_file_le_fopen could not be located in the dynamic link
library php4ts.dll.  




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

#22274 [Opn->Bgs]: Parsing variable from FLASH/HTML without turning on register_globals?

[moriyoshi]

 ID:   22274
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lewisluk at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Variables related
 Operating System: Redhat Linux 8.1
 PHP Version:  4.3.1
 New Comment:

This bug data base is not intended to be a forum for user questions.
Please ask that at [EMAIL PROTECTED]



Previous Comments:


[2003-02-18 09:15:04] lewisluk at hotmail dot com

Is there any way to parse variable from FLASH/HTML WITHOUT
register_globals being turned on?




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

#22277 [NEW]: utf8_encode and EURO sign

[mail2rk at gmx dot de]

From: mail2rk at gmx dot de
Operating system: any
PHP version:  4.3.0
PHP Bug Type: Strings related
Bug description:  utf8_encode and EURO sign

Try following:

";
$xml .= "my € sign";
echo utf8_encode($xml);

?>

in the output the EURO sign won't show up.

While if you save the php file as utf8 and drop the 
utf8_encode method, the xml string will be shown properly.

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

#22277 [Opn->WFx]: utf8_encode and EURO sign

[moriyoshi]

 ID:   22277
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mail2rk at gmx dot de
-Status:   Open
+Status:   Wont fix
 Bug Type: Strings related
 Operating System: any
 PHP Version:  4.3.0
 New Comment:

utf8_encode() only supports iso-8859-1 to UTF-8 conversion, whilst the
charset that covers euro sign is iso-8859-15.
Try iconv extension instead.




Previous Comments:


[2003-02-18 11:20:33] mail2rk at gmx dot de

Try following:

";
$xml .= "my € sign";
echo utf8_encode($xml);

?>

in the output the EURO sign won't show up.

While if you save the php file as utf8 and drop the 
utf8_encode method, the xml string will be shown properly.





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

#22262 [Opn->Fbk]: CRLF incorrectly converted to CRCRLF

[moriyoshi]

 ID:   22262
 Updated by:   [EMAIL PROTECTED]
 Reported By:  adamness at yahoo dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Mail related
 Operating System: FreeBSD 4.3
 PHP Version:  4.3.0
 New Comment:

That seems to be a qmail issue to me, not a php one.

Did you try to send by qmail-inject some plain text every line of which
ends with "\r\n" and confirm if the received mail is the right one?



Previous Comments:


[2003-02-17 19:32:47] adamness at yahoo dot com

The RFC's require lines in the email header to end in "\r\n".  However,
when using the mail function in PHP 4.3, and qmail-inject as the
external mail program, the mail function was silently replacing my \n's
with \r\n's, leaving me with "\r\r\n", which actually ends up violating
the RFC, in a way that can cause buffer overflows in some mailreaders,
and has been identified as a possible virus exploit by several virus
scanners.

For a solution, the mail function, before replacing a \n with \r\n
should check if the previous character is already a \r.




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

#22278 [NEW]: Improvement of foreach function(?)

[mazanek at abeo dot cz]

From: mazanek at abeo dot cz
Operating system: windows
PHP version:  4.2.3
PHP Bug Type: Feature/Change Request
Bug description:  Improvement of foreach function(?)

this is old issue #3074 - do you support foreach by reference?

I'm using PHP Version 4.2.2.
Having multidimensional array - $multi_array.
I would like to change the $multi_array from place marked **HERE**

foreach($multi_array AS $multi_key=>$multi_array_item)
{   foreach($multi_array_item["another_array"] AS $key=>$value)
{   if($value=="asdfg")
{   **HERE**
}
...
}
}

I have to do it using:
$multi_array[$multi_key]["another_array"][$key]=$new_value

- - - - - - - - 

It would be nice to use "&" to change the $multi_array:

foreach($multi_array AS $multi_key=>&$multi_array_item)
{   foreach($multi_array_item["another_array"] AS &$value)
{   if($value=="asdfg")
{   $value=$new_value;
$multi_array_item["value_have_changed"]=true;
}else
{   $multi_array_item["value_have_changed"]=false;
}
...
}
}


Is it possible to implement this to new version of PHP?

Thanks,

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

#22232 [Opn->Bgs]: Problem with method call

[moriyoshi]

 ID:   22232
 Updated by:   [EMAIL PROTECTED]
 Reported By:  henrik dot gebauer at web dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Class/Object related
 Operating System: Windows 2000
 PHP Version:  4.3.0 / 4.3.1-dev
 New Comment:

Duplicate of bug #22231 (fixed in cvs)



Previous Comments:


[2003-02-15 15:24:29] henrik dot gebauer at web dot de

I get the same warning and fatal error with the latest CVS snapshot.

Warning: Problem with method call - please report this bug in
E:\hosts\tests\test.php on line 17

Fatal error: Call to a member function on a non-object in
E:\hosts\tests\test.php on line 33



[2003-02-15 10:34:53] [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


I get only this fatal error:

Fatal error: Call to a member function on a non-object in
/home/jani/t.php on line 17





[2003-02-15 09:26:45] henrik dot gebauer at web dot de

I don't know if it is the same bug as this one:
http://bugs.php.net/bug.php?id=22231&edit=2

bar('value');
unset($foo);

/*
A method call without a value does not cause the warning.
*/
$foo =& foo();
$foo->bar(/* no value */);
unset($foo);

/*
But the two lines together cause a fatal error:
Call to a member function on a non-object
*/
$foo =& foo();
$foo->bar(/* no value */);
$foo->bar('value');// the error occurs in this line!
unset($foo);

?>




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

#22228 [Fbk->Opn]: ob_get_status with bool_argument crashes with Apache 1.3.22

[wloske at yahoo dot de]

 ID:   8
 User updated by:  wloske at yahoo dot de
 Reported By:  wloske at yahoo dot de
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Win2K SP3
 PHP Version:  4.2.3
 New Comment:

With PHP 4.3.1 this error does not occur anymore. Also
the 4KB memory change in Apache has gone.


Previous Comments:


[2003-02-15 08:21:55] [EMAIL PROTECTED]

I can reproduce this problem with 4.2.3 but not with 4.3.0 or later
version. So this may be fixed in the latest released version (4.3.0).
Could try that one?




[2003-02-15 04:57:16] wloske at yahoo dot de

I monitored the memory behaviour of Apache. You could
say I gave myself a hint ;-)))

When I reload the script, whether compression is on or
of, and make Apache crash, it restarts itself again
and shows the output.

When I wait a couple of seconds I can see a change of
4K in the memory usage of Apache. When I reload then
it always crashes. When I reload before this memory
change occurs, it does not crash.



[2003-02-15 04:48:11] wloske at yahoo dot de

The following code is a short form of what I have
in the production environment. Switching back and
forth between buffercompression on and off makes
it crash. It seems only to happen when compression
is on. Unfortunately it does not happen all the time.
I could not find out under which condition it crashes
but it happens very frequently. Around every third 
or fourth reload. Sometimes with the tenths ;-). If
you wait a longer time between reloads it seems to
happen every time. Could it be something with the
cache or the buffer in memory itself?

The output of the variable which contains the
status seems not to have something to do with it.
When I remove the var_dump it also crashes.

HTH

wolfgang

 8< Snip ---
$outputbuffering = true;
$buffercompression = false;

function start_buffering(){
global $outputbuffering,$buffercompression;
if ($outputbuffering == true AND $buffercompression == true){
ob_start("ob_gzhandler");
}elseif ($outputbuffering == true AND $buffercompression == false){
ob_start();
}
}

function stop_buffering(){
global $outputbuffering;
if ($outputbuffering == true){
$obstat=ob_get_status(true);
var_dump($obstat);
ob_end_flush();
}
}
start_buffering();
print "Hello World";
stop_buffering();



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

Wrong status...

Could you provide us a short and self-contained example script to
reproduce this problem?




[2003-02-15 01:47:40] [EMAIL PROTECTED]

verified



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

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

#22215 [Opn->Sus]: PHP dies while loading php.ini

[moriyoshi]

 ID:   22215
 Updated by:   [EMAIL PROTECTED]
 Reported By:  phpbug-130203-2 at smayw dot nask dot com
-Status:   Open
+Status:   Suspended
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  4CVS-2003-02-13 (stable) / 5CVS-2003-02-13 (dev)
 New Comment:

Then let's wait for a new bison release that solves this issue.



Previous Comments:


[2003-02-14 17:00:27] phpbug-130203-2 at smayw dot nask dot com

This should make it into http://www.php.net/anoncvs.php for others to
know, unless the PHP/Zend team is planning a workaround.  The page now
says "bison (1.28+)"

Thanks



[2003-02-14 16:47:34] [EMAIL PROTECTED]

That version is know to cause the crash in PHP. Please downgrade to
1.75 or all the way down to 1.28.



[2003-02-14 14:50:23] phpbug-130203-2 at smayw dot nask dot com

not quite 1.875a, but close

$ bison --version  
  bison (GNU Bison) 1.875



[2003-02-14 13:31:37] [EMAIL PROTECTED]

Sorry, I forgot that I live in a far east area.
Correcting version info.




[2003-02-14 13:27:21] [EMAIL PROTECTED]

This bug appears to be yet another bison oddity.
I managed to reproduce with bison 1.875a

Which version of bison are you using?

$ bison --version




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

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

#22276 [Fbk->Bgs]: Loading Extensions

[sniper]

 ID:   22276
 Updated by:   [EMAIL PROTECTED]
 Reported By:  msanders at primary dot net
-Status:   Feedback
+Status:   Bogus
 Bug Type: Dynamic loading
 Operating System: Windows 2000
 PHP Version:  4.3.1
 New Comment:

Just another install failure. You need to replace ALL
the existing dlls/ from the new package.
And make sure you don't have duplicates of them anywhere
in your system.



Previous Comments:


[2003-02-18 11:18:16] [EMAIL PROTECTED]

Are you sure that all the dlls that came with the previous version were
uninstalled before the installation of 4.3.1?




[2003-02-18 10:47:48] msanders at primary dot net

We have upgraded from 4.2.3 to 4.3.1 for the recent CGI vulnerability.
PHP runs fine until we attempt to load an extension. Then we recieve
the following Application Popup:

Application popup: php.exe - Entry Point Not Found : The procedure
entry point php_file_le_fopen could not be located in the dynamic link
library php4ts.dll.  




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

#22278 [Opn->Bgs]: Improvement of foreach function(?)

[sniper]

 ID:   22278
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mazanek at abeo dot cz
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: windows
 PHP Version:  4.2.3
 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.

bug #15663


Previous Comments:


[2003-02-18 11:37:59] mazanek at abeo dot cz

this is old issue #3074 - do you support foreach by reference?

I'm using PHP Version 4.2.2.
Having multidimensional array - $multi_array.
I would like to change the $multi_array from place marked **HERE**

foreach($multi_array AS $multi_key=>$multi_array_item)
{   foreach($multi_array_item["another_array"] AS $key=>$value)
{   if($value=="asdfg")
{   **HERE**
}
...
}
}

I have to do it using:
$multi_array[$multi_key]["another_array"][$key]=$new_value

- - - - - - - - 

It would be nice to use "&" to change the $multi_array:

foreach($multi_array AS $multi_key=>&$multi_array_item)
{   foreach($multi_array_item["another_array"] AS &$value)
{   if($value=="asdfg")
{   $value=$new_value;
$multi_array_item["value_have_changed"]=true;
}else
{   $multi_array_item["value_have_changed"]=false;
}
...
}
}


Is it possible to implement this to new version of PHP?

Thanks,

Jan Mazánek
[EMAIL PROTECTED]




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

#3074 [Dup->Bgs]: allow: foreach ($array as $key => &$val) in zend (byref)

[sniper]

 ID:   3074
 Updated by:   [EMAIL PROTECTED]
 Reported By:  thies at digicol dot de
-Status:   Duplicate
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: all
 PHP Version:  4.0 Latest CVS (
 New Comment:

Place any comments to bug #15663



Previous Comments:


[2002-02-24 07:26:45] [EMAIL PROTECTED]

Dupe of 15663... 



[2001-05-19 17:40:56] [EMAIL PROTECTED]

>From line 117 of zend_operators.c it says: If the string is nor an
exact double, nor an exact long, do strtol on it.

There you should first try strtod, see if it parses more chars that
strtol...

And I don't know anything about C!



[2001-05-19 17:25:32] [EMAIL PROTECTED]

Just a reminder... seems to be forgotten again :)

Come on... this can't be that hard? Or is it?



[2000-07-31 22:23:32] [EMAIL PROTECTED]

I think it happend. You did forget! ;)
Results in a parse error.



[1999-12-31 08:36:27] thies at digicol dot de

as discussed on the ML - just that so that we don't forget.






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

#22228 [Opn->Csd]: ob_get_status with bool_argument crashes with Apache 1.3.22

[moriyoshi]

 ID:   8
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wloske at yahoo dot de
-Status:   Open
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Win2K SP3
 PHP Version:  4.2.3
 New Comment:

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




Previous Comments:


[2003-02-18 11:39:27] wloske at yahoo dot de

With PHP 4.3.1 this error does not occur anymore. Also
the 4KB memory change in Apache has gone.



[2003-02-15 08:21:55] [EMAIL PROTECTED]

I can reproduce this problem with 4.2.3 but not with 4.3.0 or later
version. So this may be fixed in the latest released version (4.3.0).
Could try that one?




[2003-02-15 04:57:16] wloske at yahoo dot de

I monitored the memory behaviour of Apache. You could
say I gave myself a hint ;-)))

When I reload the script, whether compression is on or
of, and make Apache crash, it restarts itself again
and shows the output.

When I wait a couple of seconds I can see a change of
4K in the memory usage of Apache. When I reload then
it always crashes. When I reload before this memory
change occurs, it does not crash.



[2003-02-15 04:48:11] wloske at yahoo dot de

The following code is a short form of what I have
in the production environment. Switching back and
forth between buffercompression on and off makes
it crash. It seems only to happen when compression
is on. Unfortunately it does not happen all the time.
I could not find out under which condition it crashes
but it happens very frequently. Around every third 
or fourth reload. Sometimes with the tenths ;-). If
you wait a longer time between reloads it seems to
happen every time. Could it be something with the
cache or the buffer in memory itself?

The output of the variable which contains the
status seems not to have something to do with it.
When I remove the var_dump it also crashes.

HTH

wolfgang

 8< Snip ---
$outputbuffering = true;
$buffercompression = false;

function start_buffering(){
global $outputbuffering,$buffercompression;
if ($outputbuffering == true AND $buffercompression == true){
ob_start("ob_gzhandler");
}elseif ($outputbuffering == true AND $buffercompression == false){
ob_start();
}
}

function stop_buffering(){
global $outputbuffering;
if ($outputbuffering == true){
$obstat=ob_get_status(true);
var_dump($obstat);
ob_end_flush();
}
}
start_buffering();
print "Hello World";
stop_buffering();



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

Wrong status...

Could you provide us a short and self-contained example script to
reproduce this 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/8

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

#22215 [Sus->Bgs]: PHP dies while loading php.ini

[sniper]

 ID:   22215
 Updated by:   [EMAIL PROTECTED]
 Reported By:  phpbug-130203-2 at smayw dot nask dot com
-Status:   Suspended
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  4CVS-2003-02-13 (stable) / 5CVS-2003-02-13 (dev)
 New Comment:

Using the old bison 1.28 fixes this. And it's not really
PHP bug. 



Previous Comments:


[2003-02-18 11:44:30] [EMAIL PROTECTED]

Then let's wait for a new bison release that solves this issue.




[2003-02-14 17:00:27] phpbug-130203-2 at smayw dot nask dot com

This should make it into http://www.php.net/anoncvs.php for others to
know, unless the PHP/Zend team is planning a workaround.  The page now
says "bison (1.28+)"

Thanks



[2003-02-14 16:47:34] [EMAIL PROTECTED]

That version is know to cause the crash in PHP. Please downgrade to
1.75 or all the way down to 1.28.



[2003-02-14 14:50:23] phpbug-130203-2 at smayw dot nask dot com

not quite 1.875a, but close

$ bison --version  
  bison (GNU Bison) 1.875



[2003-02-14 13:31:37] [EMAIL PROTECTED]

Sorry, I forgot that I live in a far east area.
Correcting version info.




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

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

#22273 [Opn->Fbk]: Cannot load libphp4.so into server: Unresolved external

[sniper]

 ID:   22273
 Updated by:   [EMAIL PROTECTED]
 Reported By:  germano60 at yahoo dot it
-Status:   Open
+Status:   Feedback
 Bug Type: Apache2 related
 Operating System: HP-UX 11.00
 PHP Version:  4.3.0
 New Comment:

Please try using this CVS snapshot:

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


Previous Comments:


[2003-02-18 09:12:56] germano60 at yahoo dot it

Hello

I already looked in the support resources and in the bug lists but
could not find a suitable clue.

I compiled apache and php then when I tried to start the web server,
but this is the error message I got:
Syntax error on line 233 of /usr/local/apache2/conf/httpd.conf:
Cannot load /usr/local/apache2/modules/libphp4.so into server:
Unresolved external

The error line did not return any further indications about which
"external" did not resolve.

Configuration:
hp-ux 11.00
php 4.3.0
apache 2.0.44
gcc 3.2

Apache was generated with:
./configure \
  --prefix=/usr/local/apache2 \
  --enable-so

Php4.3.0 was configured with:
./configure \
  --with-mysql \
  --with-apxs2=/usr/local/apache2/bin/apxs

I modified the configure script for PHP by replacing invokes of
"-lcrypt" with "-lc" and of "-ltermcap" with "-lcurses" to get
libphp4.so generated by php's "make install" under the hp-ux 11
platform.
php's "make" and "make install" succeeded.

DSO modules were installed in the Apache2's default location 
/usr/local/apache2/modules and this is also where PHP's make install
stored the library libphp4.so. In httpd.conf I added the following
line:
LoadModule  php4_module  modules/libphp4.so

I'm not sure whether this is really a bug or due to my minimal
configuration - I tried some of the hints I found in the support/bugs
but without success.

Thanks in advance.
Germano Gasparini - germano60 at yahoo dot it




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

#22273 [Fbk]: Cannot load libphp4.so into server: Unresolved external

[sniper]

 ID:   22273
 Updated by:   [EMAIL PROTECTED]
 Reported By:  germano60 at yahoo dot it
 Status:   Feedback
 Bug Type: Apache2 related
 Operating System: HP-UX 11.00
 PHP Version:  4.3.0
 New Comment:

The latest snapshot should fix the crypt issue..
Try this configure line:

./configure --disable-all --with-mysql --with-pcre-regex
--with-apxs2=/usr/local/apache2/bin/apxs

(--disable-all disables every 'by-default' extension)




Previous Comments:


[2003-02-18 11:53:22] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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



[2003-02-18 09:12:56] germano60 at yahoo dot it

Hello

I already looked in the support resources and in the bug lists but
could not find a suitable clue.

I compiled apache and php then when I tried to start the web server,
but this is the error message I got:
Syntax error on line 233 of /usr/local/apache2/conf/httpd.conf:
Cannot load /usr/local/apache2/modules/libphp4.so into server:
Unresolved external

The error line did not return any further indications about which
"external" did not resolve.

Configuration:
hp-ux 11.00
php 4.3.0
apache 2.0.44
gcc 3.2

Apache was generated with:
./configure \
  --prefix=/usr/local/apache2 \
  --enable-so

Php4.3.0 was configured with:
./configure \
  --with-mysql \
  --with-apxs2=/usr/local/apache2/bin/apxs

I modified the configure script for PHP by replacing invokes of
"-lcrypt" with "-lc" and of "-ltermcap" with "-lcurses" to get
libphp4.so generated by php's "make install" under the hp-ux 11
platform.
php's "make" and "make install" succeeded.

DSO modules were installed in the Apache2's default location 
/usr/local/apache2/modules and this is also where PHP's make install
stored the library libphp4.so. In httpd.conf I added the following
line:
LoadModule  php4_module  modules/libphp4.so

I'm not sure whether this is really a bug or due to my minimal
configuration - I tried some of the hints I found in the support/bugs
but without success.

Thanks in advance.
Germano Gasparini - germano60 at yahoo dot it




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

#22275 [Opn->Ana]: CLI and --enable-mime-magic Spews Warnings

[moriyoshi]

 ID:   22275
 Updated by:   [EMAIL PROTECTED]
 Reported By:  hans at nyu dot edu
-Status:   Open
+Status:   Analyzed
 Bug Type: Unknown/Other Function
 Operating System: RedHat 6.2 (2.2.14)
 PHP Version:  4.3.1
 New Comment:

mime magic extension only supports simplified magic files that come
with Apache distribution for now, as most part of its code is taken
from mod_mime_magic.



Previous Comments:


[2003-02-18 09:46:40] hans at nyu dot edu

Hopefully I'm not missing something obvious.  After downloading PHP
4.3.1 to a RedHat 6.2 box, I configured and compiled like so for use as
a CLI bin:

./configure
--prefix=/usr/local/psh --disable-cgi
--disable-ipv6 --with-openssl=/usr/local/ssl
--with-zlib --enable-bcmath
--with-bz2 --enable-dio
--enable-ftp --enable-mime-magic
--with-mysql=/usr/local/mysql --with-ncurses
--enable-pcntl --with-readline
--enable-shmop --enable-sockets
--enable-sysvmsg --enable-sysvsem
--enable-sysvshm

Everything happily compiles and installs, but when finally running the
binary as /usr/local/psh/bin/php -v the following is spewed out:

HTTP/1.0 0 X
Content-type: text/html

PHP Warning:  mime_magic: (line 3859) offset `&0string  >\0
 %s  '
invalid in Unknown on line 0
PHP Warning:  mime_magic: type &0   string  >\0 %s 
  invalid in
Unknown on line 0
PHP Warning:  mime_magic: (line 3860) offset `&0string  >\0
 %s  '
invalid in Unknown on line 0
PHP Warning:  mime_magic: type &0   string  >\0 %s 
  invalid in
Unknown on line 0
PHP Warning:  mime_magic: (line 3861) offset `&0string  >\0
 %s  '
invalid in Unknown on line 0
PHP Warning:  mime_magic: type &0   string  >\0 %s 
  invalid in Unknown
on line 0
PHP Warning:  mime_magic: (line 3862) offset `&0string  >\0
 %s  '
invalid in Unknown on line 0
PHP Warning:  mime_magic: type &0   string  >\0 %s 
  invalid in Unknown
on line 0
PHP 4.3.1 (cli) (built: Feb 17 2003 22:13:02)
Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies

The same type of output occurs whether I use php -h or just plain php
with no arguments.  Looking at /usr/share/magic I've excerpted the
lines as noted:

3848# HP Printer Job Language
38490   string  \033%-12345X@PJLHP Printer Job Language data
3850# HP Printer Job Language
3851# The header found on Win95 HP plot files is the "Silliest Thing
possible" 
3852# (TM)
3853# Every driver puts the language at some random position, with
random case
3854# (LANGUAGE and Language)
3855# For example the LaserJet 5L driver puts the "PJL ENTER LANGUAGE"
in line 10
3856# From: Uwe Bonnes <[EMAIL PROTECTED]>
3857# 
38580   string  \033%-12345X@PJLHP Printer Job Language data
3859>&0 string  >\0 %s
3860>>&0string  >\0 %s
3861>>>&0   string  >\0 %s  3862&0  string 
 >\0 %s 
3863#>15string  \ ENTER\ LANGUAGE\ =
3864#>31string  PostScript  PostScript

If I then make distclean and ./configure just as above, but without
--enable-mime-magic everything looks as it should.  Should CLI and
--enable-mime-magic not be used together?  Hopefully this all makes
sense to someone and this message comes out readable.

Thanks,

Hans




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

#20298 [Opn->Fbk]: odbc.check_persistent not working

[kalowsky]

 ID:   20298
 Updated by:   [EMAIL PROTECTED]
 Reported By:  t_o_m_ at yahoo dot com
-Status:   Open
+Status:   Feedback
 Bug Type: ODBC related
 Operating System: Windows 2000 Server SP2
 PHP Version:  4.3.0
 New Comment:

Well the nature of CGI doesn't really lend itself to supporting
persistant connections.  It's run when requested and then exited after
that.  So no data can really presist between pages that exists solely
in the CGI.  

So this behavior only exists when odbc.check_persistent is turned on?


Previous Comments:


[2003-02-17 10:08:22] t_o_m_ at yahoo dot com

Yes still a problem under 4.3.0 I am using the ISAPI module. I don't
believe that persistent connections are supported at all under CGI. So
odbc_pconnect == odbc_connect which would give the illusion of working,
although the connection would not actually be persisting.

The first time you reload the page after killing the database
connection you get:

Warning:  SQL error: No response from the backend;

Subsequent reloads give:

Warning:  SQL error: Could not send Query(connection dead);



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

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

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

Not saying this is bogus but can you try the release version just to
make sure?  

I did test this on a win2k build recently and found it to work under
CGI.  how are you running this?



[2002-12-18 13:59:45] [EMAIL PROTECTED]

I'm unable to reproduce this on the UNIX end of things.  Anyone with a
Windows boxen working that can test this?



[2002-11-07 07:41:49] t_o_m_ at yahoo dot com

Make sure the odbc.check_persistent is on and that
odbc.allow_persistent is on. Set up a database connection called
dsnname
Run the script below (substituting [tabname] for a valid table name in
your database).
Check that you have persistent connections, ie with the webserver idle
make sure your database shows connections from the webserver.

Restart the database or kill the session belonging to the web server.

Re-run the script below and the odbc_exec fails with an error: 
"connection not open"  or smililar depending on your odbc driver.
I have found this effect to be the same with the Postgres odbc driver
and the Informix 3.30 odbc driver.

I presume that odbc.check_persistent is supposed to check that the
connection is still attached to the database before pconnect gives it
to the script?






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

#22213 [Opn->Fbk]: Apache mod_ssl + PHP + cURL SSL segfault

[sniper]

 ID:   22213
 Updated by:   [EMAIL PROTECTED]
 Reported By:  alan at pair dot com
-Status:   Open
+Status:   Feedback
 Bug Type: cURL related
 Operating System: FreeBSD 4.6-STABLE
 PHP Version:  4CVS-2003-02-13 (stable)
 New Comment:

Is mod_ssl compiled as DSO? Or static module?

I have both PHP and mod_ssl as DSOs and I can not
reproduce this..



Previous Comments:


[2003-02-18 08:54:05] alan at pair dot com

Here's a stack dump when it segfaults:

Program received signal SIGSEGV, Segmentation fault.
0x81df50c in SSL_CTX_ctrl ()
(gdb) bt
#0  0x81df50c in SSL_CTX_ctrl ()
#1  0x81793f4 in ssl_init_Module (s=0x830b038, p=0x830b010)
#2  0x8179741 in ssl_init_Module (s=0x830b038, p=0x830b010)
at ssl_engine_init.c:304
#3  0x8195dd0 in ap_init_modules (p=0x830b010, s=0x830b038)
at http_config.c:1703
#4  0x81a059e in standalone_main (argc=5, argv=0xbfbffa54) at
http_main.c:5172
#5  0x81a0ec0 in main (argc=5, argv=0xbfbffa54) at http_main.c:5566
#6  0x807f72d in _start ()
(gdb) 

However, as I mentioned before, that's not completely accurate. 
Stepping through the code, here's a bit more detail as to where it's
crashing:

(gdb)n
585 ctx = SSL_CTX_new(SSLv23_server_method()); /* be more
flexible */
(gdb) bt
#0  ssl_init_ConfigureServer (s=0x830b038, p=0x830b010, sc=0x830b3e0)
at ssl_engine_init.c:585
#1  0x8179741 in ssl_init_Module (s=0x830b038, p=0x830b010)
at ssl_engine_init.c:304
#2  0x8195dd0 in ap_init_modules (p=0x830b010, s=0x830b038)
at http_config.c:1703
#3  0x81a059e in standalone_main (argc=5, argv=0xbfbffa54) at
http_main.c:5172
#4  0x81a0ec0 in main (argc=5, argv=0xbfbffa54) at http_main.c:5566
#5  0x807f72d in _start ()
(gdb) n
586 SSL_CTX_set_options(ctx, SSL_OP_ALL);
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0x81df50c in SSL_CTX_ctrl ()
(gdb) bt
#0  0x81df50c in SSL_CTX_ctrl ()
#1  0x81793f4 in ssl_init_Module (s=0x830b038, p=0x830b010)
#2  0x8179741 in ssl_init_Module (s=0x830b038, p=0x830b010)
at ssl_engine_init.c:304
#3  0x8195dd0 in ap_init_modules (p=0x830b010, s=0x830b038)
at http_config.c:1703
#4  0x81a059e in standalone_main (argc=5, argv=0xbfbffa54) at
http_main.c:5172
#5  0x81a0ec0 in main (argc=5, argv=0xbfbffa54) at http_main.c:5566
#6  0x807f72d in _start ()
(gdb) 


This particular version is compiled with PHP 4.3.0, Apache 1.3.27,
mod_ssl 2.8.12, and curl 7.10.3.  But I've been able to reproduce it
with different versions of curl and PHP.

If I run the same compiled executable without SSL turned on, it does
not segfault when it receives HUP.
If I compile curl --without-ssl, and compile php against this version
of curl, apache does not segfault when it receives SIGHUP even when
modssl is turned on.
If I compile PHP without curl, apache does not segfault when it
receives SIGHUP.

I don't know that it's curl's fault.  I just know that the problem goes
away when PHP isn't using curl, or when curl isn't using SSL.

Thanks,
Alan



[2003-02-14 17:16:26] daniel at haxx dot se

How about providing a stack trace or something that shows us what was
going on when it crashed?

For information, libcurl calls only two functions to initialize the
OpenSSL library:

SSL_load_error_strings();
SSLeay_add_ssl_algorithms(); (a define for SSL_library_init)

(The rest is done when some action is called for, and this report says
that isn't required for this problem to occur.)

I honestly can't see how this can be wrong from a libcurl point of
view.



[2003-02-14 08:41:39] alan at pair dot com

Regarding notes/issues raised on bug #22112:
I made sure that apache is linking against only one copy of libssl and
libcrypto.  

We have a global ErrorLog directive in the httpd.conf we're testing
with, but no VirtualHost blocks at all: it's a base conf file, and the
server doesn't even need to serve any pages for this to be a problem
for us.

Our httpd.conf conditionally turns on SSL only when the "-DSSL" flag is
present.  When apache is run without that flag, it works without any
problems.  It crashes only when SSL is running.

("SSLEngine on" only happens with -DSSL)

Thanks.



[2003-02-14 08:33:47] alan at pair dot com

The configure command:

./configure --with-apache=/usr/pair/sw/apachessl_1.3.27
--with-config-file-path=/usr/local/etc --enable-magic-quotes
--enable-bcmath --without-cdb --with-zlib-dir=/usr/local --with-gd
--without-ttf --without-msql --with-mysql=/usr/local --with-iodbc
--with-pdflib --enable-inline-optimization --disable-memory-limit
--with-db --without-gdbm --with-ndbm --without-db2 --without-dbm
--with-gettext -

#22250 [Opn->Bgs]: Problem compiling snmp with openssl support

[msopacua]

 ID:   22250
 Updated by:   [EMAIL PROTECTED]
 Reported By:  phpbug at spambox dot dk
-Status:   Open
+Status:   Bogus
 Bug Type: SNMP related
 Operating System: FreeBSD 4.7-stable
 PHP Version:  4CVS-2003-02-18 (stable)
 Assigned To:  sniper
 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.

Confirmed that this is not a bug in PHP. With today's  
cvsup'd system, you cannot even compile the ports version  
of ucd-snmp anymore. Version 2.4.6 you can compile, simply  
because it ignores the error, but it doesn't create a 
library. I guess you installed 2.4.6 version before 
upgrading your system? 
  
This issue is with openssl 0.9.7, which changed the des  
interfaces. Compiling the ports version (cvsup'd as well)  
ends with the following error:  
===  
cc -DINET6 -O -pipe -g -Dfreebsd4 -I. -I.. -I. -I./.. -c  
scapi.c  -fPIC -DPIC -o .libs/scapi.lo  
scapi.c: In function `sc_encrypt':  
scapi.c:612: incompatible type for argument 1 of `memset'  
scapi.c: In function `sc_decrypt':  
scapi.c:725: incompatible type for argument 1 of `memset'  
*** Error code 1  
  
Stop in  
/sql/usr/ports/net/net-snmp4/work/ucd-snmp-4.2.5/snmplib.  
*** Error code 1  
  
Stop in /sql/usr/ports/net/net-snmp4/work/ucd-snmp-4.2.5.  
*** Error code 1  
  
Stop in /usr/ports/net/net-snmp4.  
===  
  
I'm afraid you'll have to wait until somebody fixes the  
openssl issues in the ports collection :(. 


Previous Comments:


[2003-02-18 05:58:31] phpbug at spambox dot dk

OpenSSL 0.9.7 is in FreeBSD 4.7-stable

>From /usr/src/UPDATEING:
20030214: OpenSSL 0.97 has been imported, and the libcrypto/libssl
library versions have been bumped.



[2003-02-18 04:55:58] [EMAIL PROTECTED]

Updated description.

The des* interfaces are from openssl. Is 4.7-stable using openssl 0.9.7
already, or did you compile that yourself?
If it is, I'll cvsup my box and try to replicate your problem - unable
to reproduce it, with system supplied openssl 0.9.6g and
ucd-snmp-4.2.5_2 port.

It looks like a problem outside of php though (snmp/openssl linking),
but I'd like to replicate this first to be sure.



[2003-02-18 04:33:11] phpbug at spambox dot dk

The SNMP package is ucd-snmp-4.2.6.

I compiled this from source with the following:
./configure --prefix=/usr/local
--with-persistent-directory=/var/run/ucd-snmp
--with-sys-contact="[EMAIL PROTECTED]" --with-sys-location=Unknown
--with-logfile=/var/log/snmpd.log --with-openssl=/usr

I use this for my MRTG, without SSL though.



[2003-02-18 04:26:23] [EMAIL PROTECTED]

Recategorizing.

Sniper's fix works: it points to the correct problem :)
>From the looks of this, you have a problem in your libsmnp library. Try
recompiling it and could you mention which snmp package this is? Is
this the ports version and if so, which exact version (ls -al
/var/db/pkg | grep snmp)?



[2003-02-18 02:47:37] phpbug at spambox dot dk

Tried with php4-STABLE-200302180830.

Now I get a different error:
checking for SNMP support... yes
checking for default_store.h... yes
checking for OpenSSL support in SNMP libraries... yes
checking for kstat_read in -lkstat... no
checking for snmp_parse_oid... no
checking for init_snmp in -lsnmp... no
configure: error: SNMP sanity check failed. Please check config.log for
more information.

-- cut
%tail -n 25 config.log 

; return 0; }
configure:67088: checking for init_snmp in -lsnmp
configure:67107: gcc -o conftest -g -O2  -DMOD_SSL=208112 -DEAPI
-DUSE_EXPAT -DSHARED_CORE 

-R/usr/local/lib -L/usr/local/lib -R/usr/X11R6/lib -L/usr/X11R6/lib
-R/usr/local/mysql/lib/mysql -L/usr/local/mysql/lib/mysql -R/lib -L/lib
conftest.c -lsnmp  -lsnmp -lpdf -lz -ltiff -lpng -ljpeg -lmysqlclient
-lmcrypt -lltdl -lcrypt -lpam -lintl -lt1 -lfreetype -lX11 -lXpm -lpng
-lz -ljpeg -lz -lz -lssl -lcrypto -lm  -lxml2 -lz -lm -lssl -lcrypto
1>&5
/tmp/ccKXqjQR.s: Assembler messages:
/tmp/ccKXqjQR.s:30: Warning: .stabs: description field '1061e' too big,
try a different debug format
/tmp/ccKXqjQR.s:39: Warning: .stabn: description field '1061f' too big,
try a different debug format
/tmp/ccKXqjQR.s:42: Warning: .stabn: description field '10620' too big,
try a different debug format

#21076 [Opn->Fbk]: ODBC_TABLES and ODBC_COLUMNS cannot be called together

[kalowsky]

 ID:   21076
 Updated by:   [EMAIL PROTECTED]
 Reported By:  heyjohnlim at yahoo dot com
-Status:   Open
+Status:   Feedback
 Bug Type: ODBC related
 Operating System: Win2000, IIS-CGI
 PHP Version:  4.3.0
 New Comment:

I looked into this a but more this past week... I still don't see
anything outrageously wrong.  Very odd... any chance I can get you to
try this script with a lame DB like MS Access?  

I still am unable to reproduce this locally.


Previous Comments:


[2003-02-15 23:00:03] heyjohnlim at yahoo dot com

I have updated to MDAC 2.7 and it still happens. Perhaps it is due to
mssql driver issues.

Regards, John



[2003-02-07 23:44: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.





[2003-01-26 16:10:10] [EMAIL PROTECTED]

Update your MDAC to 2.7 it's the latest and from what I can tell works
fine.  I have no SQL-Server to test on though unfortunately.  



[2003-01-25 09:39:36] heyjohnlim at yahoo dot com

Hi

Thanks for testing. I just retested.


When i test with MS Access driver the problem does not occur. 

In the original report, I tested on microsoft sql server 2000, with SQL
Server ODBC Driver version 2000.81.9001.00 (MDAC 2.6 installed).  I
just retested and still get the problem. I set the "Use ANSI quoted
identifiers" and "Use ANSI nulls" in the odbc driver.

- John



[2003-01-24 16:18:40] [EMAIL PROTECTED]

Marking as bogus.  

Using Win2k, and the CGI build I cannot reproduce this at all.  My
attempts to showed nothing wrong with the code base that I could find. 




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

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

#21708 [Opn->Csd]: ucfirst() trouble again

[moriyoshi]

 ID:   21708
 Updated by:   [EMAIL PROTECTED]
 Reported By:  overseas at mtu-net dot ru
-Status:   Open
+Status:   Closed
 Bug Type: Strings related
 Operating System: Win 2000 Pro Russian + SP2
 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.

note: The fix will be available there in 8 hours.


Previous Comments:


[2003-02-09 11:52:51] overseas at mtu-net dot ru

FYI: MySQL (3.23.xx) under Win32 with 
character_set == cp1251
also have problem with LCASE, UCASE.



[2003-02-09 11:48:55] overseas at mtu-net dot ru

Yes. I tried to do it after reading your comment dated 17 Jan 4:50am
(with link to MSDN). Output is wrong, but...
Every time starting of script containing 
setlocale (LC_CTYPE, "Russian_Russia.1251") I  have different (!!!)
results... Interest, isn't it?



[2003-02-09 10:45:14] [EMAIL PROTECTED]

To [EMAIL PROTECTED]:

Could you also try
setlocale(LC_CTYPE, "Russian_Russia.1251"?




[2003-01-28 04:43:28] richard dot cooling at coastdigital dot co dot uk

$text = '
alert ("this shouldnt be here");
';

$text =strip_tags($text, $allowed_tags);

$text =ucfirst($text);
print $text;

PHP version 4.3 on win 32.

doesnt uppercase output

alert ("this shouldnt be here");



[2003-01-17 16:00:29] [EMAIL PROTECTED]

Hmm, you can use mb_convert_case() instead if mbstring extension is
enabled.

http://www.php.net/mb_convert_case




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

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

#22276 [Bgs]: Loading Extensions

[msanders at primary dot net]

 ID:   22276
 User updated by:  msanders at primary dot net
 Reported By:  msanders at primary dot net
 Status:   Bogus
 Bug Type: Dynamic loading
 Operating System: Windows 2000
 PHP Version:  4.3.1
 New Comment:

This problem only occurs when loading php_curl.dll

I did not replace the extensions from 4.2.3. I only used the installer
program.

After replacing the extensions with 4.3.1 extensions the problem is
resolved.


Previous Comments:


[2003-02-18 11:45:47] [EMAIL PROTECTED]

Just another install failure. You need to replace ALL
the existing dlls/ from the new package.
And make sure you don't have duplicates of them anywhere
in your system.




[2003-02-18 11:18:16] [EMAIL PROTECTED]

Are you sure that all the dlls that came with the previous version were
uninstalled before the installation of 4.3.1?




[2003-02-18 10:47:48] msanders at primary dot net

We have upgraded from 4.2.3 to 4.3.1 for the recent CGI vulnerability.
PHP runs fine until we attempt to load an extension. Then we recieve
the following Application Popup:

Application popup: php.exe - Entry Point Not Found : The procedure
entry point php_file_le_fopen could not be located in the dynamic link
library php4ts.dll.  




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

#22213 [Fbk->Opn]: Apache mod_ssl + PHP + cURL SSL segfault

[alan at pair dot com]

 ID:   22213
 User updated by:  alan at pair dot com
 Reported By:  alan at pair dot com
-Status:   Feedback
+Status:   Open
 Bug Type: cURL related
 Operating System: FreeBSD 4.6-STABLE
 PHP Version:  4CVS-2003-02-13 (stable)
 New Comment:

It looks like both mod_php and mod_ssl are being compiled in
statically, along with a static core.

I'm going to try doing this DSO and see if it helps; but that may not
be an option for us depending on why things were compiled statically in
the first place.  Thanks.


Previous Comments:


[2003-02-18 12:02:32] [EMAIL PROTECTED]

Is mod_ssl compiled as DSO? Or static module?

I have both PHP and mod_ssl as DSOs and I can not
reproduce this..




[2003-02-18 08:54:05] alan at pair dot com

Here's a stack dump when it segfaults:

Program received signal SIGSEGV, Segmentation fault.
0x81df50c in SSL_CTX_ctrl ()
(gdb) bt
#0  0x81df50c in SSL_CTX_ctrl ()
#1  0x81793f4 in ssl_init_Module (s=0x830b038, p=0x830b010)
#2  0x8179741 in ssl_init_Module (s=0x830b038, p=0x830b010)
at ssl_engine_init.c:304
#3  0x8195dd0 in ap_init_modules (p=0x830b010, s=0x830b038)
at http_config.c:1703
#4  0x81a059e in standalone_main (argc=5, argv=0xbfbffa54) at
http_main.c:5172
#5  0x81a0ec0 in main (argc=5, argv=0xbfbffa54) at http_main.c:5566
#6  0x807f72d in _start ()
(gdb) 

However, as I mentioned before, that's not completely accurate. 
Stepping through the code, here's a bit more detail as to where it's
crashing:

(gdb)n
585 ctx = SSL_CTX_new(SSLv23_server_method()); /* be more
flexible */
(gdb) bt
#0  ssl_init_ConfigureServer (s=0x830b038, p=0x830b010, sc=0x830b3e0)
at ssl_engine_init.c:585
#1  0x8179741 in ssl_init_Module (s=0x830b038, p=0x830b010)
at ssl_engine_init.c:304
#2  0x8195dd0 in ap_init_modules (p=0x830b010, s=0x830b038)
at http_config.c:1703
#3  0x81a059e in standalone_main (argc=5, argv=0xbfbffa54) at
http_main.c:5172
#4  0x81a0ec0 in main (argc=5, argv=0xbfbffa54) at http_main.c:5566
#5  0x807f72d in _start ()
(gdb) n
586 SSL_CTX_set_options(ctx, SSL_OP_ALL);
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0x81df50c in SSL_CTX_ctrl ()
(gdb) bt
#0  0x81df50c in SSL_CTX_ctrl ()
#1  0x81793f4 in ssl_init_Module (s=0x830b038, p=0x830b010)
#2  0x8179741 in ssl_init_Module (s=0x830b038, p=0x830b010)
at ssl_engine_init.c:304
#3  0x8195dd0 in ap_init_modules (p=0x830b010, s=0x830b038)
at http_config.c:1703
#4  0x81a059e in standalone_main (argc=5, argv=0xbfbffa54) at
http_main.c:5172
#5  0x81a0ec0 in main (argc=5, argv=0xbfbffa54) at http_main.c:5566
#6  0x807f72d in _start ()
(gdb) 


This particular version is compiled with PHP 4.3.0, Apache 1.3.27,
mod_ssl 2.8.12, and curl 7.10.3.  But I've been able to reproduce it
with different versions of curl and PHP.

If I run the same compiled executable without SSL turned on, it does
not segfault when it receives HUP.
If I compile curl --without-ssl, and compile php against this version
of curl, apache does not segfault when it receives SIGHUP even when
modssl is turned on.
If I compile PHP without curl, apache does not segfault when it
receives SIGHUP.

I don't know that it's curl's fault.  I just know that the problem goes
away when PHP isn't using curl, or when curl isn't using SSL.

Thanks,
Alan



[2003-02-14 17:16:26] daniel at haxx dot se

How about providing a stack trace or something that shows us what was
going on when it crashed?

For information, libcurl calls only two functions to initialize the
OpenSSL library:

SSL_load_error_strings();
SSLeay_add_ssl_algorithms(); (a define for SSL_library_init)

(The rest is done when some action is called for, and this report says
that isn't required for this problem to occur.)

I honestly can't see how this can be wrong from a libcurl point of
view.



[2003-02-14 08:41:39] alan at pair dot com

Regarding notes/issues raised on bug #22112:
I made sure that apache is linking against only one copy of libssl and
libcrypto.  

We have a global ErrorLog directive in the httpd.conf we're testing
with, but no VirtualHost blocks at all: it's a base conf file, and the
server doesn't even need to serve any pages for this to be a problem
for us.

Our httpd.conf conditionally turns on SSL only when the "-DSSL" flag is
present.  When apache is run without that flag, it works without any
problems.  It crashes only when SSL is running.

("SSLEngine on" only happens with -DSSL)

Thanks.



[2003-02-14 08:33:47] alan at pair dot com

The configure command:

./config

#21669 [Com]: "$obj = new $this->var;" doesn't work

[yoglets at hotmail dot com]

 ID:   21669
 Comment by:   yoglets at hotmail dot com
 Reported By:  slowbyte at hot dot ee
 Status:   Open
 Bug Type: Zend Engine 2 problem
 Operating System: Debian Linux 3.0r0
 PHP Version:  5CVS-2003-01-15 (dev)
 New Comment:

FWIW, this problem is still present in a post-nested-class ZE2 build:




Previous Comments:


[2003-01-28 19:55:58] yoglets at hotmail dot com

Don't know if this is the same issue or not, but it's certainly
related. You can't use $obj = new $name for nested classes either. For
example:





[2003-01-15 11:56:13] slowbyte at hot dot ee

The following snippet is a parse error in PHP5-ZE2 (used to work on
earlier versions). This feature is also used in Smarty templates.

name; /* Parse error */
return $obj;
}
}
$factory = new Factory;
$test = $factory->create();
$test->say_hello();
?>





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

#21985 [Ver->Csd]: mb_send_mail() doesn't encode the message body into MIME base64

[moriyoshi]

 ID:   21985
 Updated by:   [EMAIL PROTECTED]
 Reported By:  hayk at softerra dot com
-Status:   Verified
+Status:   Closed
 Bug Type: mbstring related
 Operating System: Windows 2000
 PHP Version:  4.3.0
 New Comment:

This bug has been really fixed in CVS.

Now you can override the hard-coded headers such as Content-Type and
Content-Transfer-Encoding by the additional header parameter.

example: 

mb_send_mail("[EMAIL PROTECTED]", "subject", "any contents",
"Content-Type: text/html; charset=utf-8");

I'm afraid the fix won't be available in the next release, but in
php5.

You can try the latest CVS snapshot (unstable) which you can fetch at
http://snaps.php.net/ .

Thank you for the report and for helping us make PHP better.



Previous Comments:


[2003-02-01 03:02:55] [EMAIL PROTECTED]

Thanks for the report.

Changing status [Open => Verified]






[2003-01-31 11:36:44] hayk at softerra dot com

I'm trying to send a UTF-8 encoded e-mail using mb_send_mail() under
PHP 4.3.0 with the MBString extension. 

mb_send_mail() adds the following lines to the e-mail header:
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: BASE64

But it doesn't encode the message body into MIME base64 and I'm forced
to use 
mb_send_mail($address, $subject, chunk_split(base64_encode($msg)),
$extra_headers);

instead of

mb_send_mail($address, $subject, $msg, $extra_headers);





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

#22064 [Opn->Csd]: mb_send_mail hard-coded to send text/plain

[moriyoshi]

 ID:   22064
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jc at mega-bucks dot co dot jp
-Status:   Open
+Status:   Closed
 Bug Type: mbstring related
 Operating System: Red Hat Linux 7.2
 PHP Version:  4.3.0
 Assigned To:  moriyoshi
 New Comment:

This bug has been really fixed in CVS.

Now you can override the hard-coded headers such as Content-Type and
Content-Transfer-Encoding by the additional header parameter.

example: 

mb_send_mail("[EMAIL PROTECTED]", "subject", "any contents",
"Content-Type: text/html; charset=utf-8");

I'm afraid the fix won't be available in the next release, but in
php5.

You can try the latest CVS snapshot (unstable) which you can fetch at
http://snaps.php.net/ .

Thank you for the report and for helping us make PHP better.



Previous Comments:


[2003-02-05 07:23:36] jc at mega-bucks dot co dot jp

Great. You can closed the report then =)



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

This work is in progress.
Stay tuned!






[2003-02-05 01:06:20] jc at mega-bucks dot co dot jp

Feature request:

Currently mb_send_mail() is hard-coded to send a Content-type of
text/plain. Would it be possible to add a way to change this (being
able to set it to text/html would be very useful).

Either a parameter to mb_send_email or a function such as
mb_send_mail_set_content_type(string)?

Thanks!

Jc




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

#22279 [NEW]: Would like tar/tar.gz/tar.bz2 files in include_path

[carl at carldunham dot com]

From: carl at carldunham dot com
Operating system: 
PHP version:  4.3.0
PHP Bug Type: Feature/Change Request
Bug description:  Would like tar/tar.gz/tar.bz2 files in include_path

>From a configuration management point of view, it would be 
convenient to package up a library of files in a .tar file 
(optionally compressed) to include in an application. Of 
course, this can be done by untaring into a directory in 
the include_path, but being able to skip that step is 
preferred. 
 
This would be a similar feature Java's ".jar" file 
concept. 
 
Thanks! Love PHP to death! 
 
-- 
Edit bug report at http://bugs.php.net/?id=22279&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22279&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22279&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22279&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22279&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22279&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22279&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22279&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22279&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22279&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22279&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22279&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22279&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22279&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22279&r=gnused

#22275 [Ana]: CLI and --enable-mime-magic Spews Warnings

[hans at nyu dot edu]

 ID:   22275
 User updated by:  hans at nyu dot edu
 Reported By:  hans at nyu dot edu
 Status:   Analyzed
 Bug Type: Unknown/Other Function
 Operating System: RedHat 6.2 (2.2.14)
 PHP Version:  4.3.1
 New Comment:

OK, this makes sense then.  If I set the following in php.ini:

mime_magic.magicfile = "/usr/local/apache/conf/magic"

everything appears fine.  If I also set that directive to a
non-existent file, I don't get the Warning either.  However, if I set
it to my system's magicfile, /usr/share/magic, I get the warnings.

With your clarification this makes sense, however maybe this is a
documentation issue.  While
http://www.php.net/manual/en/ref.mime-magic.php says this extension is
derived from Apache mod_mime_magic, the Installation and Runtime
Configuration sections are misleading, in my opinion.

In Installation:

"The extension needs a copy of the magic.mime as distributed with the
file command. This file also part of most recent Linux distributions
and usually stored in the /usr/share/misc directory."

And in Runtime Configuration the default value
"/usr/share/misc/magic.mime" seems that it would never be a correct
value.

Oddly enough, the default /usr/share/misc/magic.mime file doesn't exist
on my system, and without the mime_magic.magicfile directive set, I
still receive the Warnings.  I mention this as odd because when setting
the directive explicitly to a non-existent file I don't get any
warnings.

Anyway, thanks for the clarification,

Hans


Previous Comments:


[2003-02-18 11:57:42] [EMAIL PROTECTED]

mime magic extension only supports simplified magic files that come
with Apache distribution for now, as most part of its code is taken
from mod_mime_magic.




[2003-02-18 09:46:40] hans at nyu dot edu

Hopefully I'm not missing something obvious.  After downloading PHP
4.3.1 to a RedHat 6.2 box, I configured and compiled like so for use as
a CLI bin:

./configure
--prefix=/usr/local/psh --disable-cgi
--disable-ipv6 --with-openssl=/usr/local/ssl
--with-zlib --enable-bcmath
--with-bz2 --enable-dio
--enable-ftp --enable-mime-magic
--with-mysql=/usr/local/mysql --with-ncurses
--enable-pcntl --with-readline
--enable-shmop --enable-sockets
--enable-sysvmsg --enable-sysvsem
--enable-sysvshm

Everything happily compiles and installs, but when finally running the
binary as /usr/local/psh/bin/php -v the following is spewed out:

HTTP/1.0 0 X
Content-type: text/html

PHP Warning:  mime_magic: (line 3859) offset `&0string  >\0
 %s  '
invalid in Unknown on line 0
PHP Warning:  mime_magic: type &0   string  >\0 %s 
  invalid in
Unknown on line 0
PHP Warning:  mime_magic: (line 3860) offset `&0string  >\0
 %s  '
invalid in Unknown on line 0
PHP Warning:  mime_magic: type &0   string  >\0 %s 
  invalid in
Unknown on line 0
PHP Warning:  mime_magic: (line 3861) offset `&0string  >\0
 %s  '
invalid in Unknown on line 0
PHP Warning:  mime_magic: type &0   string  >\0 %s 
  invalid in Unknown
on line 0
PHP Warning:  mime_magic: (line 3862) offset `&0string  >\0
 %s  '
invalid in Unknown on line 0
PHP Warning:  mime_magic: type &0   string  >\0 %s 
  invalid in Unknown
on line 0
PHP 4.3.1 (cli) (built: Feb 17 2003 22:13:02)
Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies

The same type of output occurs whether I use php -h or just plain php
with no arguments.  Looking at /usr/share/magic I've excerpted the
lines as noted:

3848# HP Printer Job Language
38490   string  \033%-12345X@PJLHP Printer Job Language data
3850# HP Printer Job Language
3851# The header found on Win95 HP plot files is the "Silliest Thing
possible" 
3852# (TM)
3853# Every driver puts the language at some random position, with
random case
3854# (LANGUAGE and Language)
3855# For example the LaserJet 5L driver puts the "PJL ENTER LANGUAGE"
in line 10
3856# From: Uwe Bonnes <[EMAIL PROTECTED]>
3857# 
38580   string  \033%-12345X@PJLHP Printer Job Language data
3859>&0 string  >\0 %s
3860>>&0string  >\0 %s
3861>>>&0   string  >\0 %s  3862&0  string 
 >\0 %s 
3863#>15string  \ ENTER\ LANGUAGE\ =
3864#>31string 

#22213 [Opn]: Apache mod_ssl + PHP + cURL SSL segfault

[alan at pair dot com]

 ID:   22213
 User updated by:  alan at pair dot com
 Reported By:  alan at pair dot com
 Status:   Open
 Bug Type: cURL related
 Operating System: FreeBSD 4.6-STABLE
 PHP Version:  4CVS-2003-02-13 (stable)
 New Comment:

Building apache with mod_so, SHARED_CORE=yes, and mod_ssl as a
SharedModule prevents this bug from showing its head.  However, we're
still interested in getting this working in the statically compiled
version, so if you can reproduce it in that environment, we'd
appreciate any insight on what's causing it there.  Thanks!

Alan


Previous Comments:


[2003-02-18 12:43:06] alan at pair dot com

It looks like both mod_php and mod_ssl are being compiled in
statically, along with a static core.

I'm going to try doing this DSO and see if it helps; but that may not
be an option for us depending on why things were compiled statically in
the first place.  Thanks.



[2003-02-18 12:02:32] [EMAIL PROTECTED]

Is mod_ssl compiled as DSO? Or static module?

I have both PHP and mod_ssl as DSOs and I can not
reproduce this..




[2003-02-18 08:54:05] alan at pair dot com

Here's a stack dump when it segfaults:

Program received signal SIGSEGV, Segmentation fault.
0x81df50c in SSL_CTX_ctrl ()
(gdb) bt
#0  0x81df50c in SSL_CTX_ctrl ()
#1  0x81793f4 in ssl_init_Module (s=0x830b038, p=0x830b010)
#2  0x8179741 in ssl_init_Module (s=0x830b038, p=0x830b010)
at ssl_engine_init.c:304
#3  0x8195dd0 in ap_init_modules (p=0x830b010, s=0x830b038)
at http_config.c:1703
#4  0x81a059e in standalone_main (argc=5, argv=0xbfbffa54) at
http_main.c:5172
#5  0x81a0ec0 in main (argc=5, argv=0xbfbffa54) at http_main.c:5566
#6  0x807f72d in _start ()
(gdb) 

However, as I mentioned before, that's not completely accurate. 
Stepping through the code, here's a bit more detail as to where it's
crashing:

(gdb)n
585 ctx = SSL_CTX_new(SSLv23_server_method()); /* be more
flexible */
(gdb) bt
#0  ssl_init_ConfigureServer (s=0x830b038, p=0x830b010, sc=0x830b3e0)
at ssl_engine_init.c:585
#1  0x8179741 in ssl_init_Module (s=0x830b038, p=0x830b010)
at ssl_engine_init.c:304
#2  0x8195dd0 in ap_init_modules (p=0x830b010, s=0x830b038)
at http_config.c:1703
#3  0x81a059e in standalone_main (argc=5, argv=0xbfbffa54) at
http_main.c:5172
#4  0x81a0ec0 in main (argc=5, argv=0xbfbffa54) at http_main.c:5566
#5  0x807f72d in _start ()
(gdb) n
586 SSL_CTX_set_options(ctx, SSL_OP_ALL);
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0x81df50c in SSL_CTX_ctrl ()
(gdb) bt
#0  0x81df50c in SSL_CTX_ctrl ()
#1  0x81793f4 in ssl_init_Module (s=0x830b038, p=0x830b010)
#2  0x8179741 in ssl_init_Module (s=0x830b038, p=0x830b010)
at ssl_engine_init.c:304
#3  0x8195dd0 in ap_init_modules (p=0x830b010, s=0x830b038)
at http_config.c:1703
#4  0x81a059e in standalone_main (argc=5, argv=0xbfbffa54) at
http_main.c:5172
#5  0x81a0ec0 in main (argc=5, argv=0xbfbffa54) at http_main.c:5566
#6  0x807f72d in _start ()
(gdb) 


This particular version is compiled with PHP 4.3.0, Apache 1.3.27,
mod_ssl 2.8.12, and curl 7.10.3.  But I've been able to reproduce it
with different versions of curl and PHP.

If I run the same compiled executable without SSL turned on, it does
not segfault when it receives HUP.
If I compile curl --without-ssl, and compile php against this version
of curl, apache does not segfault when it receives SIGHUP even when
modssl is turned on.
If I compile PHP without curl, apache does not segfault when it
receives SIGHUP.

I don't know that it's curl's fault.  I just know that the problem goes
away when PHP isn't using curl, or when curl isn't using SSL.

Thanks,
Alan



[2003-02-14 17:16:26] daniel at haxx dot se

How about providing a stack trace or something that shows us what was
going on when it crashed?

For information, libcurl calls only two functions to initialize the
OpenSSL library:

SSL_load_error_strings();
SSLeay_add_ssl_algorithms(); (a define for SSL_library_init)

(The rest is done when some action is called for, and this report says
that isn't required for this problem to occur.)

I honestly can't see how this can be wrong from a libcurl point of
view.



[2003-02-14 08:41:39] alan at pair dot com

Regarding notes/issues raised on bug #22112:
I made sure that apache is linking against only one copy of libssl and
libcrypto.  

We have a global ErrorLog directive in the httpd.conf we're testing
with, but no VirtualHost blocks at all: it's a base conf file, and the
server doesn't even need to serve any pages for this to

#19292 [Com]: random error: open_basedir restriction in effect. File is in wrong directory

[aw at mittwaldmedien dot de]

 ID:   19292
 Comment by:   aw at mittwaldmedien dot de
 Reported By:  tnowak at triger dot com dot pl
 Status:   Feedback
 Bug Type: Apache related
 Operating System: linux
 PHP Version:  4.2.3,4.3.0
 New Comment:

Now i tested the http://snaps.php.net/php4-STABLE-latest.tar.gz
from today.

same problem like before.
i call the vhost 'www.domain1.de', after that i call a second vhost
from the same server with 'www.domain2.de'.
Now i get the error:
Warning: Unknown(): open_basedir restriction in effect.
File(/home/www/web8/typo3_src-3.5.0/typo3/index.php) is not within the
allowed path(s): (/home/www/confixx/) in Unknown on line 0
www.domain1.de has the base dir: /home/www/confixx/
www.domain2.de hast the base dir: /home/www/web8/

the funny thing for me is, that i have servers with php 4.2.3 witch i
selfcompiled and they work without that problem.


Previous Comments:


[2003-02-18 09:31:41] aw at mittwaldmedien dot de

after one hour the same problem comes up.

the funny thing is, that we have a second machine with suse 8.1, same
apache version and there it works.

so i copied the libphp.so from one machine to the other.

it doesn't help.
Has someone found a working workaround ?



[2003-02-18 04:08:21] aw at mittwaldmedien dot de

We have the same Problem, like described above.
On one of our system the Error comes up sometimes.
We deleted the source, untared it again and compiled it the 'different'
configure options.
Now it works 
Is it possible that there some problems with the configure options,
when they are not in the korrekt order or something like this.
This are the configure Options there it makes sometimes the error:
./configure --prefix=/usr/share --datadir=/usr/share/php
--bindir=/usr/bin --libdir=/usr/share --includedir=/usr/include
--with-_lib=lib --with-config-file-path=/etc --disable-debug
--enable-bcmath --enable-calendar --enable-ctype --enable-dbase
--enable-discard-path --enable-exif --enable-filepro
--enable-force-cgi-redirect --enable-ftp --enable-gd-imgstrttf
--enable-gd-native-ttf --enable-inline-optimization
--enable-magic-quotes --enable-shmop --enable-sigchild --enable-sysvsem
--enable-sysvshm --enable-trans-sid --enable-versioning --enable-wddx
--enable-yp --with-bz2 --with-dom=/usr/include/libxml2 --with-ftp
--with-gdbm --with-gettext --with-gmp --with-imap=yes
--with-jpeg-dir=/usr --with-ldap=yes --with-mcal=/usr --with-mcrypt
--with-ndbm --with-snmp --with-tiff-dir=/usr --with-xml
--with-xpm-dir=/usr/X11R6 --with-openssl --with-curl --with-imap-ssl
--with-mm --with-apxs=/usr/sbin/apxs --enable-discard-path
--enable-sockets --enable-track-vars=yes
--with-exec-dir=/usr/local/typo3sh/bin --with-gd=/usr/local/typo3sh
--with-gettext --with-jpeg-dir --with-mysql=/usr --with-png-dir
--with-tiff-dir --with-ttf=/usr/local/typo3sh --with-zlib=yes

and this is my 'working version.

./configure --prefix=/usr/share --datadir=/usr/share/php
--bindir=/usr/bin --libdir=/usr/share --includedir=/usr/include
--with-_lib=lib --with-config-file-path=/etc --disable-debug
--enable-bcmath --enable-calendar --enable-ctype --enable-dbase
--enable-discard-path --enable-exif --enable-filepro
--enable-force-cgi-redirect --enable-ftp --enable-gd-imgstrttf
--enable-gd-native-ttf --enable-inline-optimization
--enable-magic-quotes --enable-shmop --enable-sigchild --enable-sysvsem
--enable-sysvshm --enable-trans-sid --enable-versioning --enable-wddx
--enable-yp --with-bz2 --with-dom=/usr/include/libxml2 --with-ftp
--with-gdbm --with-gettext --with-gmp --with-imap=yes
--with-jpeg-dir=/usr --with-ldap=yes --with-mcal=/usr --with-mcrypt
--with-ndbm --with-qtdom=/usr/lib/qt2 --with-snmp --with-tiff-dir=/usr
--with-xml --with-xpm-dir=/usr/X11R6 --with-openssl --with-curl
--with-imap-ssl --with-mm --with-apxs=/usr/sbin/apxs
--enable-discard-path --enable-sockets --enable-track-vars=yes
--with-exec-dir=/usr/local/typo3sh/bin --with-gd=/usr/local/typo3sh
--with-gettext --with-jpeg-dir --with-mysql=/usr --with-png-dir
--with-tiff-dir --with-ttf=/usr/local/typo3sh --with-xml
--with-zlib=yes

maybe it helps to reproduce the problem and finding the bug.



[2003-02-15 17:10:45] [EMAIL PROTECTED]

Patch can be found here:
http://cvs.php.net/diff.php/php4/main/main.c?login=2&r1=1.512.2.9&r2=1.512.2.10&ty=u

(should apply to 4.3.0 sources too)




[2003-02-15 17:08:55] [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

I fixed a bug that prevented resetting the open_basedir
by using 'php_admin_value open_basedir none'. 

This most 

#22280 [NEW]: Stat failed for known file using filesize() and filemtime()

[stdbmt12 at shsu dot edu]

From: stdbmt12 at shsu dot edu
Operating system: linux red hat 7.3
PHP version:  4.3.1
PHP Bug Type: Filesystem function related
Bug description:  Stat failed for known file using filesize() and filemtime()

When working with files of the form:

@@@80@@[EMAIL PROTECTED]

filesize() and filemtime() return an error of:

Warning: filesize() Stat failed for FILENAME (errno=2 - No such file or
directory) in /path/to/program.name.php on line 100

The same error occurs with PHP 4.2.X. Using PHP 4.3.1 with Apache 2.X on a
windows system does not reproduce the error.

If the filename is changed to:

@P@@80@@[EMAIL PROTECTED]

the error does not occur.  The list of files in the directory was obtained
using the PHP readdir() function, so i know PHP is finding the file at
sometime, just not for filemtime() or filesize().
-- 
Edit bug report at http://bugs.php.net/?id=22280&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22280&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22280&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22280&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22280&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22280&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22280&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22280&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22280&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22280&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22280&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22280&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22280&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22280&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22280&r=gnused

#22250 [Bgs]: Problem compiling snmp with openssl support

[phpbug at spambox dot dk]

 ID:   22250
 User updated by:  phpbug at spambox dot dk
 Reported By:  phpbug at spambox dot dk
 Status:   Bogus
 Bug Type: SNMP related
 Operating System: FreeBSD 4.7-stable
 PHP Version:  4CVS-2003-02-18 (stable)
 Assigned To:  sniper
 New Comment:

Just a little side note.

I upgraded to NET-SNMP 5.0.7, and all semed to work.


Previous Comments:


[2003-02-18 12:05:29] [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.

Confirmed that this is not a bug in PHP. With today's  
cvsup'd system, you cannot even compile the ports version  
of ucd-snmp anymore. Version 2.4.6 you can compile, simply  
because it ignores the error, but it doesn't create a 
library. I guess you installed 2.4.6 version before 
upgrading your system? 
  
This issue is with openssl 0.9.7, which changed the des  
interfaces. Compiling the ports version (cvsup'd as well)  
ends with the following error:  
===  
cc -DINET6 -O -pipe -g -Dfreebsd4 -I. -I.. -I. -I./.. -c  
scapi.c  -fPIC -DPIC -o .libs/scapi.lo  
scapi.c: In function `sc_encrypt':  
scapi.c:612: incompatible type for argument 1 of `memset'  
scapi.c: In function `sc_decrypt':  
scapi.c:725: incompatible type for argument 1 of `memset'  
*** Error code 1  
  
Stop in  
/sql/usr/ports/net/net-snmp4/work/ucd-snmp-4.2.5/snmplib.  
*** Error code 1  
  
Stop in /sql/usr/ports/net/net-snmp4/work/ucd-snmp-4.2.5.  
*** Error code 1  
  
Stop in /usr/ports/net/net-snmp4.  
===  
  
I'm afraid you'll have to wait until somebody fixes the  
openssl issues in the ports collection :(. 



[2003-02-18 05:58:31] phpbug at spambox dot dk

OpenSSL 0.9.7 is in FreeBSD 4.7-stable

>From /usr/src/UPDATEING:
20030214: OpenSSL 0.97 has been imported, and the libcrypto/libssl
library versions have been bumped.



[2003-02-18 04:55:58] [EMAIL PROTECTED]

Updated description.

The des* interfaces are from openssl. Is 4.7-stable using openssl 0.9.7
already, or did you compile that yourself?
If it is, I'll cvsup my box and try to replicate your problem - unable
to reproduce it, with system supplied openssl 0.9.6g and
ucd-snmp-4.2.5_2 port.

It looks like a problem outside of php though (snmp/openssl linking),
but I'd like to replicate this first to be sure.



[2003-02-18 04:33:11] phpbug at spambox dot dk

The SNMP package is ucd-snmp-4.2.6.

I compiled this from source with the following:
./configure --prefix=/usr/local
--with-persistent-directory=/var/run/ucd-snmp
--with-sys-contact="[EMAIL PROTECTED]" --with-sys-location=Unknown
--with-logfile=/var/log/snmpd.log --with-openssl=/usr

I use this for my MRTG, without SSL though.



[2003-02-18 04:26:23] [EMAIL PROTECTED]

Recategorizing.

Sniper's fix works: it points to the correct problem :)
>From the looks of this, you have a problem in your libsmnp library. Try
recompiling it and could you mention which snmp package this is? Is
this the ports version and if so, which exact version (ls -al
/var/db/pkg | grep snmp)?



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

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

#22281 [NEW]: -liconv missing from EXTRA_LIBS in Makefile

[michael at epimorphic dot com]

From: michael at epimorphic dot com
Operating system: Linux Red Hat 7.3
PHP version:  4.3.0
PHP Bug Type: Compile Failure
Bug description:  -liconv missing from EXTRA_LIBS in Makefile

PROBLEM

With PHP 4.3.0 and libiconv-1.8, ./configure ... succeeds, but compile
fails right at the end, complaining that various references related to
iconv are undefined.

FIX (hack)

Add -liconv to EXTRA_LIBS in the Makefile.

PHP CONFIGURE:

./configure --with-pear --with-curl --with-gettext --with-iconv
--with-mcrypt --with-mhash --with-openssl --with-pspell --with-zlib
--with-imap --with-imap-ssl --with-mm --with-xslt-sablot=/usr/local
--with-sablot-js=/usr/local --enable-mime-magic --enable-sockets
--enable-wddx --enable-xslt --with-java --with-expat-dir=/usr/local/
--with-xmlrpc --with-config-file-path=/etc --enable-magic-quotes 
--with-apxs=/usr/sbin/apxs --with-mysql=/usr/local/mysql
-- 
Edit bug report at http://bugs.php.net/?id=22281&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22281&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22281&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22281&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22281&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22281&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22281&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22281&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22281&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22281&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22281&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22281&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22281&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22281&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22281&r=gnused

#22281 [Opn->Fbk]: -liconv missing from EXTRA_LIBS in Makefile

[moriyoshi]

 ID:   22281
 Updated by:   [EMAIL PROTECTED]
 Reported By:  michael at epimorphic dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: Linux Red Hat 7.3
 PHP Version:  4.3.0
 New Comment:

Where did you install libiconv? --prefix=??



Previous Comments:


[2003-02-18 13:32:56] michael at epimorphic dot com

PROBLEM

With PHP 4.3.0 and libiconv-1.8, ./configure ... succeeds, but compile
fails right at the end, complaining that various references related to
iconv are undefined.

FIX (hack)

Add -liconv to EXTRA_LIBS in the Makefile.

PHP CONFIGURE:

./configure --with-pear --with-curl --with-gettext --with-iconv
--with-mcrypt --with-mhash --with-openssl --with-pspell --with-zlib
--with-imap --with-imap-ssl --with-mm --with-xslt-sablot=/usr/local
--with-sablot-js=/usr/local --enable-mime-magic --enable-sockets
--enable-wddx --enable-xslt --with-java --with-expat-dir=/usr/local/
--with-xmlrpc --with-config-file-path=/etc --enable-magic-quotes 
--with-apxs=/usr/sbin/apxs --with-mysql=/usr/local/mysql




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

#19918 [Opn]: no libphp4.so produced

[mad at dactar dot ch]

 ID:   19918
 User updated by:  mad at dactar dot ch
 Reported By:  mad at dactar dot ch
 Status:   Open
 Bug Type: Compile Failure
 Operating System: HP-UX 11.00
-PHP Version:  4.3.0
+PHP Version:  4.3.1
 New Comment:

This workarround (replace -lcrypt by -lc).
Someone of php's staff can analyse this problem and correct it please
?

Thanks
@++
JC

PS 4 kbrott : thanks very very much :))


Previous Comments:


[2003-02-05 18:15:34] kbrott at eli dot net

Reproduced bug on patched-to-current HP-UX 11.00 system trying to 
build php-4.3.0 against apache httpd 2.0.43 (as well as the 
php-200301290030.tar.gz snapshot).

Have determined cause and offer working solution (well - it worked on 
my systems anyway).

Here's the config.nice that I used for this instance:
#! /bin/sh
#
# Created by configure

CFLAGS='-O3' \
LDFLAGS='-L/opt/admin/lib -L/opt/tools/lib' \
CC='gcc' \
'./configure' \
'--prefix=/opt/php4' \
'--with-apxs2=/opt/apache/sbin/apxs' \
'--enable-shared' \
'--enable-force-cgi-redirect' \
'--with-openssl=/opt/tools' \
'--with-zlib=/opt/tools' \
'--enable-bcmath' \
'--with-bz2=/opt/tools' \
'--enable-calendar' \
'--enable-dba' \
'--with-gdbm=/opt/tools' \
'--with-db3=/opt/tools' \
'--with-flatfile' \
'--enable-dbase' \
'--enable-dbx' \
'--enable-ftp' \
'--with-gmp=/opt/tools' \
'--with-mysql=/opt/mysql' \
'--enable-mime-magic' \
'--with-ldap=/opt/tools' \
'--enable-mbstring' \
'--enable-mbregex' \
'--with-readline=/opt/tools' \
"$@" 

HP's linker via libtool (apache2 or otherwise) cannot seem to use a 
lib(anything).a to make a shared library file (at least not in this 
instance - I gave up on it after a couple of months) - so the trick is

to make sure not to call any static libraries.

HP moved all of the shared crpyt functions into libc ( as of HP-UX 
10.20 see 

).
So all calls in ./configure for HP-UX 11.00 should use -lc instead of 
-lcrypt for the crypt_r/ calls (tested - it works).

HP has completely deprecated termcap usage ( see 
, 
, and more 
specifically

)
so you have to use libcurses instead if you want to access a shared 
library with those functions.  So all calls in ./configure when 
OS=hpux11 should use -lcurses instead of -ltermcap for the tgetent 
calls (tested - it works).

Making these changes to ./configure, executing ./config.nice, then 
doing make, make install allowed compilation and installation with 
no problems (well, once I rebuilt bzip2 with a shared libbz2 that is).

Feel free to ping me with questions - I have a working php 4.3.0
install running on HP-UX 11.00 as a shared install under apache 2.0.43
now so I must have done something right. :)



[2003-02-05 11:54:39] benoit dot bruckert at uniporc-ouest dot com

oups ! it was with-apxs2 and not with-apxs...



[2003-02-05 11:29:07] benoit dot bruckert at uniporc-ouest dot com

OS : HP-UX11.00 (32 bits)
gcc 2.95.2
PHP 4.3.0.
apache 2.0.44

php config :
./configure --with-apxs=/home/apache2/bin/apxs
--without-mysql
--enable-track-vars
make
I have crypt warning about share libs !!
Then I changed the Make file and removed -lcrypt
make
--> OK no more warning
make install
--> OK
apachectl start 
--> no errors
I started then it works, (I got the phpinfo page),
What the lib crypt is made for ??? what functions are using it ?



[2003-01-22 12:44:34] mathieu dot carbonneaux at free dot Fr

i have the same probleme with PHP 4.3 + SAPI NSAPI on HP-UX 11!

/bin/sh libtool --silent --mode=link gcc -g -O2 -DZTS -prefer-pic 
-rpath /opt/php43/php-4.3.0/libs -avoid-version -module -L/usr/lo
cal/lib -L/opt/bzip2/lib -L/opt/jpeg-6/lib -L/opt/libpng/lib
-L/opt/xpm/lib -L/opt/freetype/lib -L/opt/T1/lib -L/opt/gd/lib  -R
/usr
/local/lib -R /opt/bzip2/lib -R /opt/jpeg-6/lib -R /opt/libpng/lib -R
/opt/xpm/lib -R /opt/freetype/lib -R /opt/T1/lib -R /opt/gd/li
b ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bz2/bz2.lo
ext/ctype/ctype.lo ext/gd/gd.lo ext/gd/gdttf.lo ext/gd/gdcache.lo e
xt/overload/overload.lo ext/pcre/pcrelib/maketables.lo
ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo
ext/pcre/pcrelib/pcre.lo ex
t/pcre/php_pcre.lo ext/session/session.lo ext/session/mod_files.lo
ext/session/mod_mm.lo ext/session/mod_user.lo ext/standard/array.
lo ext/standard/base64.lo ext/standard/basic_functions.lo
ext/standard/browscap.l

#19918 [Opn]: no libphp4.so produced

[mad at dactar dot ch]

 ID:   19918
 User updated by:  mad at dactar dot ch
 Reported By:  mad at dactar dot ch
 Status:   Open
 Bug Type: Compile Failure
 Operating System: HP-UX 11.00
 PHP Version:  4.3.1
 New Comment:

This workarround (replace -lcrypt by -lc) works.
Someone of php's staff can analyse this problem and correct it please
?

Thanks
@++
JC

PS 4 kbrott : thanks very very much :))


Previous Comments:


[2003-02-18 13:57:18] mad at dactar dot ch

This workarround (replace -lcrypt by -lc).
Someone of php's staff can analyse this problem and correct it please
?

Thanks
@++
JC

PS 4 kbrott : thanks very very much :))



[2003-02-05 18:15:34] kbrott at eli dot net

Reproduced bug on patched-to-current HP-UX 11.00 system trying to 
build php-4.3.0 against apache httpd 2.0.43 (as well as the 
php-200301290030.tar.gz snapshot).

Have determined cause and offer working solution (well - it worked on 
my systems anyway).

Here's the config.nice that I used for this instance:
#! /bin/sh
#
# Created by configure

CFLAGS='-O3' \
LDFLAGS='-L/opt/admin/lib -L/opt/tools/lib' \
CC='gcc' \
'./configure' \
'--prefix=/opt/php4' \
'--with-apxs2=/opt/apache/sbin/apxs' \
'--enable-shared' \
'--enable-force-cgi-redirect' \
'--with-openssl=/opt/tools' \
'--with-zlib=/opt/tools' \
'--enable-bcmath' \
'--with-bz2=/opt/tools' \
'--enable-calendar' \
'--enable-dba' \
'--with-gdbm=/opt/tools' \
'--with-db3=/opt/tools' \
'--with-flatfile' \
'--enable-dbase' \
'--enable-dbx' \
'--enable-ftp' \
'--with-gmp=/opt/tools' \
'--with-mysql=/opt/mysql' \
'--enable-mime-magic' \
'--with-ldap=/opt/tools' \
'--enable-mbstring' \
'--enable-mbregex' \
'--with-readline=/opt/tools' \
"$@" 

HP's linker via libtool (apache2 or otherwise) cannot seem to use a 
lib(anything).a to make a shared library file (at least not in this 
instance - I gave up on it after a couple of months) - so the trick is

to make sure not to call any static libraries.

HP moved all of the shared crpyt functions into libc ( as of HP-UX 
10.20 see 

).
So all calls in ./configure for HP-UX 11.00 should use -lc instead of 
-lcrypt for the crypt_r/ calls (tested - it works).

HP has completely deprecated termcap usage ( see 
, 
, and more 
specifically

)
so you have to use libcurses instead if you want to access a shared 
library with those functions.  So all calls in ./configure when 
OS=hpux11 should use -lcurses instead of -ltermcap for the tgetent 
calls (tested - it works).

Making these changes to ./configure, executing ./config.nice, then 
doing make, make install allowed compilation and installation with 
no problems (well, once I rebuilt bzip2 with a shared libbz2 that is).

Feel free to ping me with questions - I have a working php 4.3.0
install running on HP-UX 11.00 as a shared install under apache 2.0.43
now so I must have done something right. :)



[2003-02-05 11:54:39] benoit dot bruckert at uniporc-ouest dot com

oups ! it was with-apxs2 and not with-apxs...



[2003-02-05 11:29:07] benoit dot bruckert at uniporc-ouest dot com

OS : HP-UX11.00 (32 bits)
gcc 2.95.2
PHP 4.3.0.
apache 2.0.44

php config :
./configure --with-apxs=/home/apache2/bin/apxs
--without-mysql
--enable-track-vars
make
I have crypt warning about share libs !!
Then I changed the Make file and removed -lcrypt
make
--> OK no more warning
make install
--> OK
apachectl start 
--> no errors
I started then it works, (I got the phpinfo page),
What the lib crypt is made for ??? what functions are using it ?



[2003-01-22 12:44:34] mathieu dot carbonneaux at free dot Fr

i have the same probleme with PHP 4.3 + SAPI NSAPI on HP-UX 11!

/bin/sh libtool --silent --mode=link gcc -g -O2 -DZTS -prefer-pic 
-rpath /opt/php43/php-4.3.0/libs -avoid-version -module -L/usr/lo
cal/lib -L/opt/bzip2/lib -L/opt/jpeg-6/lib -L/opt/libpng/lib
-L/opt/xpm/lib -L/opt/freetype/lib -L/opt/T1/lib -L/opt/gd/lib  -R
/usr
/local/lib -R /opt/bzip2/lib -R /opt/jpeg-6/lib -R /opt/libpng/lib -R
/opt/xpm/lib -R /opt/freetype/lib -R /opt/T1/lib -R /opt/gd/li
b ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bz2/bz2.lo
ext/ctype/ctype.lo ext/gd/gd.lo ext/gd/gdttf.lo ext/gd/gdcache.lo e
xt/overload/overload.lo ext/pcre/pcrelib/maketables.lo
ext/pcre/pcrelib

#22279 [Opn->Csd]: Would like tar/tar.gz/tar.bz2 files in include_path

[wez]

 ID:  22279
 Updated by:  [EMAIL PROTECTED]
 Reported By: carl at carldunham dot com
-Status:  Open
+Status:  Closed
 Bug Type:Feature/Change Request
 PHP Version: 4.3.0
 New Comment:

This is not something we plan to have in the core of PHP (too much
bloat, and not as fast as regular files), but starting in PHP 4.3.0, it
is possible to implement a virtual filesystem based on a tar archive
using PHP code itself by registering your own wrapper with the streams
subsystem.

However, the performance will not be so good on some platforms. (this
will be addressed in PHP 5).


Previous Comments:


[2003-02-18 12:58:30] carl at carldunham dot com

>From a configuration management point of view, it would be 
convenient to package up a library of files in a .tar file 
(optionally compressed) to include in an application. Of 
course, this can be done by untaring into a directory in 
the include_path, but being able to skip that step is 
preferred. 
 
This would be a similar feature Java's ".jar" file 
concept. 
 
Thanks! Love PHP to death! 
 




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

#22279 [Csd]: Would like tar/tar.gz/tar.bz2 files in include_path

[carl at carldunham dot com]

 ID:  22279
 User updated by: carl at carldunham dot com
 Reported By: carl at carldunham dot com
 Status:  Closed
 Bug Type:Feature/Change Request
 PHP Version: 4.3.0
 New Comment:

Ah, so something like: 
 
$libdir = "zlib://mylib.tgz/"; 
 
require("${libdir}myfile.inc.php"); 
 
would work? Is it smart enough find mylib.tgz in the 
include_path?


Previous Comments:


[2003-02-18 14:24:26] [EMAIL PROTECTED]

This is not something we plan to have in the core of PHP (too much
bloat, and not as fast as regular files), but starting in PHP 4.3.0, it
is possible to implement a virtual filesystem based on a tar archive
using PHP code itself by registering your own wrapper with the streams
subsystem.

However, the performance will not be so good on some platforms. (this
will be addressed in PHP 5).



[2003-02-18 12:58:30] carl at carldunham dot com

>From a configuration management point of view, it would be 
convenient to package up a library of files in a .tar file 
(optionally compressed) to include in an application. Of 
course, this can be done by untaring into a directory in 
the include_path, but being able to skip that step is 
preferred. 
 
This would be a similar feature Java's ".jar" file 
concept. 
 
Thanks! Love PHP to death! 
 




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

#20190 [Com]: Random mem corruption: zend_get_executed_filename() mismatch

[mitch at karboneye dot com]

 ID:   20190
 Comment by:   mitch at karboneye dot com
 Reported By:  mbr at freebsd dot org
 Status:   Critical
 Bug Type: Apache related
 Operating System: FreeBSD
 PHP Version:  4.3.0-dev
 New Comment:

*sigh*

STILL happening with 4.3.1 FreeBSD 4.7 - 5.0


Previous Comments:


[2003-01-21 08:42:27] r at orcafat dot com

Have this problem on 4.3.0 RELEASE! and 4.2.3

upgrade Version on this bug please.



[2003-01-16 17:22:32] mitch at karboneye dot com

I upgraded to 4.3 the other day and ran into this problem big time.
Today I went back to 4.2.3 and am still running into the error(s)
occasionally... I've made sure that PHP 4.2.3 is installed and running
and (according to phpinfo()) it is.

Apache 1.3.27 FreeeBSD 4.7p-1 PHP 4.2.3 and PHP 4.3.0 

Ack!



[2002-11-14 15:45:26] mbr at freebsd dot org

Hi,

>when this bug occurs, to confirm the wrong ini values?

Ok, i'll do that.

>1) there are 2 vhosts, where vhost A has open_basedir >restriction in
effect, via php_admin_value in > context and vhost B
>doesn't

Nope. Both virtal servers have a open basedir restriction
turned on here.

>2) vhost B includes a file and subsequently vhost A >includes one.

That's correct.

For some strange reason, the bug does not happen on
a test setup with the same apache config. Of course
I was not able to copy all web-stuff over and simulate
true load.

So it is very difficult to reproduce.

Martin



[2002-11-14 11:39:16] [EMAIL PROTECTED]

Could you test the values:
registered_zend_ini_directives
and
EG(ini_directives)

when this bug occurs, to confirm the wrong ini values?

I'm trying to reproduce this, can you confirm, that this bug happens
when:
1) there are 2 vhosts, where vhost A has open_basedir restriction in
effect, via php_admin_value in  context and vhost B
doesn't
2) vhost B includes a file and subsequently vhost A includes one.

So in order to increase the chances of hitting this bug, one could:
set Max and MinSpareServers to 1 and request the different vhosts?



[2002-11-14 03:09:27] mbr at freebsd dot org

I can confirm that it still happens with the latest cvs 4.3 snapshot
from yesterday (2002-11-13).

If I get some pointers, I could add some debug code.

Funny thing is that the webserver runs about 30min to
2 hours ok, and then I hit begin to hit the bug. Always
after the same files:

It's always the same, you can see it because the filename
has two slashes /www/doc/customer2/html/visions/php//

This path really exists. The thing that does not exist,
is the file wrapper.php. It exists in the customer1 path
so we really really should not end here.

Nov 14 05:37:24 server-bsl1 httpd: open_basedir: Used openbasedir
/www/doc/custermer1, file
/www/doc/customer2/html/visions/php//wrapper.php executed_filename
(/www/doc/customer1/index.php)

It looks to me that this case only happens after the apache
child has processed a include as last thing and then preceeds again a
different webserver.

Anyone knows more ?
Martin



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

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

#22283 [NEW]: fopen causes core dump

[pprocacci at datapipe dot com]

From: pprocacci at datapipe dot com
Operating system: FreeBSD4.7-Stable
PHP version:  4.3.0
PHP Bug Type: Reproducible crash
Bug description:  fopen causes core dump

PHP Version => 4.3.0

System => FreeBSD lucky 4.7-RELEASE-p4 FreeBSD 4.7-RELEASE-p4 #0: Mon 
i386
Build Date => Feb 17 2003 01:29:45
Configure Command =>  './configure' '--with-apxs=/usr/local/sbin/apxs'
'--with-config-file-path=/usr/local/etc' '--enable-versioning'
'--with-regex=system' '--without-gd' '--without-mysql'
'--with-gd=/usr/local' '--enable-gd-native-ttf'
'--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr/local' '--with-zlib' '--with-bz2=/usr' '--with
-mcrypt=/usr/local' '--with-mhash=/usr/local' '--with-pdflib=/usr/local'
'--with-zlib-dir=/usr' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr/local' '--with-tiff-dir=/usr/local' '
--with-imap=/usr/local' '--with-mysql=/usr/local'
'--with-pgsql=/usr/local' '--with-dbase' '--with-gdbm=/usr/local'
'--with-ldap=/usr/local' '--with-openssl=/usr' '--with-snmp=/usr/lo
cal' '--enable-ucd-snmp-hack' '--with-openssl=/usr'
'--with-expat-dir=/usr/local' '--with-xmlrpc' '--enable-xslt'
'--with-xslt-sablot=/usr/local' '--enable-wddx' '--with-dom=/usr/loca
l' '--enable-ftp' '--with-curl=/usr/local' '--with-gettext=/usr/local'
'--with-iconv=/usr/local' '--with-pspell=/usr/local' '--enable-mbregex'
'--enable-mbstring' '--enable-yp' '--ena
ble-bcmath' '--with-hyperwave=yes' '--with-mcve=/usr/local'
'--with-ming=/usr/local' '--with-mcal=/usr/local' '--enable-sockets'
'--enable-sysvsem' '--enable-sysvshm' '--enable-trans-sid'
'--with-yaz=/usr/local/bin' '--prefix=/usr/local'
'i386-portbld-freebsd4.7'
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /usr/local/etc
PHP API => 20020918
PHP Extension => 20020429
Zend Extension => 20021010
Debug Build => no
Thread Safety => disabled
Registered PHP Streams => php, http, ftp, https, ftps, compress.bzip2,
compress.zlib  


I know this sounds rediculous, but  the following dumps core:

#!/usr/local/bin/php
http://xanthus.net";, "r");

if(!is_resource($fp))
die("Couldn't open xanthus.net\n");


fclose($fp);

?>

###
while this one doesn't
###

#!/usr/local/bin/php
http://php.net";, "r");

if(!is_resource($fp))
die("Couldn't open php.net\n");


fclose($fp);

?>


There seems to be a problem with the way php handles redirects.  That page
"xanthus.net" gets redirected to elsewhere, while php.net doesn't (or at
least I think this is the reason.)
-- 
Edit bug report at http://bugs.php.net/?id=22283&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22283&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22283&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22283&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22283&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22283&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22283&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22283&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22283&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22283&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22283&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22283&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22283&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22283&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22283&r=gnused

#22281 [Fbk->Opn]: -liconv missing from EXTRA_LIBS in Makefile

[michael at epimorphic dot com]

 ID:   22281
 User updated by:  michael at epimorphic dot com
 Reported By:  michael at epimorphic dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Linux Red Hat 7.3
 PHP Version:  4.3.0
 New Comment:

libiconv is in /usr/local/lib.


Previous Comments:


[2003-02-18 13:36:31] [EMAIL PROTECTED]

Where did you install libiconv? --prefix=??




[2003-02-18 13:32:56] michael at epimorphic dot com

PROBLEM

With PHP 4.3.0 and libiconv-1.8, ./configure ... succeeds, but compile
fails right at the end, complaining that various references related to
iconv are undefined.

FIX (hack)

Add -liconv to EXTRA_LIBS in the Makefile.

PHP CONFIGURE:

./configure --with-pear --with-curl --with-gettext --with-iconv
--with-mcrypt --with-mhash --with-openssl --with-pspell --with-zlib
--with-imap --with-imap-ssl --with-mm --with-xslt-sablot=/usr/local
--with-sablot-js=/usr/local --enable-mime-magic --enable-sockets
--enable-wddx --enable-xslt --with-java --with-expat-dir=/usr/local/
--with-xmlrpc --with-config-file-path=/etc --enable-magic-quotes 
--with-apxs=/usr/sbin/apxs --with-mysql=/usr/local/mysql




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

#22281 [Opn]: -liconv missing from EXTRA_LIBS in Makefile

[michael at epimorphic dot com]

 ID:   22281
 User updated by:  michael at epimorphic dot com
 Reported By:  michael at epimorphic dot com
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Linux Red Hat 7.3
 PHP Version:  4.3.0
 New Comment:

Sorry -- to be clearer:

/usr/local/lib/libiconv.so.2.1.0
/usr/local/lib/libiconv.so.2
/usr/local/lib/libiconv.so
/usr/local/lib/libiconv.la
/usr/local/lib/libiconv_plug.so


Previous Comments:


[2003-02-18 15:52:04] michael at epimorphic dot com

libiconv is in /usr/local/lib.



[2003-02-18 13:36:31] [EMAIL PROTECTED]

Where did you install libiconv? --prefix=??




[2003-02-18 13:32:56] michael at epimorphic dot com

PROBLEM

With PHP 4.3.0 and libiconv-1.8, ./configure ... succeeds, but compile
fails right at the end, complaining that various references related to
iconv are undefined.

FIX (hack)

Add -liconv to EXTRA_LIBS in the Makefile.

PHP CONFIGURE:

./configure --with-pear --with-curl --with-gettext --with-iconv
--with-mcrypt --with-mhash --with-openssl --with-pspell --with-zlib
--with-imap --with-imap-ssl --with-mm --with-xslt-sablot=/usr/local
--with-sablot-js=/usr/local --enable-mime-magic --enable-sockets
--enable-wddx --enable-xslt --with-java --with-expat-dir=/usr/local/
--with-xmlrpc --with-config-file-path=/etc --enable-magic-quotes 
--with-apxs=/usr/sbin/apxs --with-mysql=/usr/local/mysql




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

#22283 [Opn]: fopen causes core dump

[pprocacci at datapipe dot com]

 ID:   22283
 User updated by:  pprocacci at datapipe dot com
 Reported By:  pprocacci at datapipe dot com
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: FreeBSD4.7-Stable
 PHP Version:  4.3.0
 New Comment:

My Knowledge of gdb is very limited, but I can get this far.  ;(

Program received signal SIGSEGV, Segmentation fault.
0x819f13d in php_stream_url_wrap_http ()


Previous Comments:


[2003-02-18 15:51:39] pprocacci at datapipe dot com

PHP Version => 4.3.0

System => FreeBSD lucky 4.7-RELEASE-p4 FreeBSD 4.7-RELEASE-p4 #0: Mon 
i386
Build Date => Feb 17 2003 01:29:45
Configure Command =>  './configure' '--with-apxs=/usr/local/sbin/apxs'
'--with-config-file-path=/usr/local/etc' '--enable-versioning'
'--with-regex=system' '--without-gd' '--without-mysql'
'--with-gd=/usr/local' '--enable-gd-native-ttf'
'--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr/local' '--with-zlib' '--with-bz2=/usr' '--with
-mcrypt=/usr/local' '--with-mhash=/usr/local'
'--with-pdflib=/usr/local' '--with-zlib-dir=/usr'
'--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local'
'--with-tiff-dir=/usr/local' '
--with-imap=/usr/local' '--with-mysql=/usr/local'
'--with-pgsql=/usr/local' '--with-dbase' '--with-gdbm=/usr/local'
'--with-ldap=/usr/local' '--with-openssl=/usr' '--with-snmp=/usr/lo
cal' '--enable-ucd-snmp-hack' '--with-openssl=/usr'
'--with-expat-dir=/usr/local' '--with-xmlrpc' '--enable-xslt'
'--with-xslt-sablot=/usr/local' '--enable-wddx' '--with-dom=/usr/loca
l' '--enable-ftp' '--with-curl=/usr/local' '--with-gettext=/usr/local'
'--with-iconv=/usr/local' '--with-pspell=/usr/local' '--enable-mbregex'
'--enable-mbstring' '--enable-yp' '--ena
ble-bcmath' '--with-hyperwave=yes' '--with-mcve=/usr/local'
'--with-ming=/usr/local' '--with-mcal=/usr/local' '--enable-sockets'
'--enable-sysvsem' '--enable-sysvshm' '--enable-trans-sid'
'--with-yaz=/usr/local/bin' '--prefix=/usr/local'
'i386-portbld-freebsd4.7'
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /usr/local/etc
PHP API => 20020918
PHP Extension => 20020429
Zend Extension => 20021010
Debug Build => no
Thread Safety => disabled
Registered PHP Streams => php, http, ftp, https, ftps, compress.bzip2,
compress.zlib  


I know this sounds rediculous, but  the following dumps core:

#!/usr/local/bin/php
http://xanthus.net";, "r");

if(!is_resource($fp))
die("Couldn't open xanthus.net\n");


fclose($fp);

?>

###
while this one doesn't
###

#!/usr/local/bin/php
http://php.net";, "r");

if(!is_resource($fp))
die("Couldn't open php.net\n");


fclose($fp);

?>


There seems to be a problem with the way php handles redirects.  That
page "xanthus.net" gets redirected to elsewhere, while php.net doesn't
(or at least I think this is the reason.)




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

#22283 [Opn->Fbk]: fopen causes core dump

[magnus]

 ID:   22283
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pprocacci at datapipe dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: FreeBSD4.7-Stable
 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

And if it still is crashing, please provide a backtrace.


Previous Comments:


[2003-02-18 16:03:17] pprocacci at datapipe dot com

My Knowledge of gdb is very limited, but I can get this far.  ;(

Program received signal SIGSEGV, Segmentation fault.
0x819f13d in php_stream_url_wrap_http ()



[2003-02-18 15:51:39] pprocacci at datapipe dot com

PHP Version => 4.3.0

System => FreeBSD lucky 4.7-RELEASE-p4 FreeBSD 4.7-RELEASE-p4 #0: Mon 
i386
Build Date => Feb 17 2003 01:29:45
Configure Command =>  './configure' '--with-apxs=/usr/local/sbin/apxs'
'--with-config-file-path=/usr/local/etc' '--enable-versioning'
'--with-regex=system' '--without-gd' '--without-mysql'
'--with-gd=/usr/local' '--enable-gd-native-ttf'
'--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr/local' '--with-zlib' '--with-bz2=/usr' '--with
-mcrypt=/usr/local' '--with-mhash=/usr/local'
'--with-pdflib=/usr/local' '--with-zlib-dir=/usr'
'--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local'
'--with-tiff-dir=/usr/local' '
--with-imap=/usr/local' '--with-mysql=/usr/local'
'--with-pgsql=/usr/local' '--with-dbase' '--with-gdbm=/usr/local'
'--with-ldap=/usr/local' '--with-openssl=/usr' '--with-snmp=/usr/lo
cal' '--enable-ucd-snmp-hack' '--with-openssl=/usr'
'--with-expat-dir=/usr/local' '--with-xmlrpc' '--enable-xslt'
'--with-xslt-sablot=/usr/local' '--enable-wddx' '--with-dom=/usr/loca
l' '--enable-ftp' '--with-curl=/usr/local' '--with-gettext=/usr/local'
'--with-iconv=/usr/local' '--with-pspell=/usr/local' '--enable-mbregex'
'--enable-mbstring' '--enable-yp' '--ena
ble-bcmath' '--with-hyperwave=yes' '--with-mcve=/usr/local'
'--with-ming=/usr/local' '--with-mcal=/usr/local' '--enable-sockets'
'--enable-sysvsem' '--enable-sysvshm' '--enable-trans-sid'
'--with-yaz=/usr/local/bin' '--prefix=/usr/local'
'i386-portbld-freebsd4.7'
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /usr/local/etc
PHP API => 20020918
PHP Extension => 20020429
Zend Extension => 20021010
Debug Build => no
Thread Safety => disabled
Registered PHP Streams => php, http, ftp, https, ftps, compress.bzip2,
compress.zlib  


I know this sounds rediculous, but  the following dumps core:

#!/usr/local/bin/php
http://xanthus.net";, "r");

if(!is_resource($fp))
die("Couldn't open xanthus.net\n");


fclose($fp);

?>

###
while this one doesn't
###

#!/usr/local/bin/php
http://php.net";, "r");

if(!is_resource($fp))
die("Couldn't open php.net\n");


fclose($fp);

?>


There seems to be a problem with the way php handles redirects.  That
page "xanthus.net" gets redirected to elsewhere, while php.net doesn't
(or at least I think this is the reason.)




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

#22283 [Fbk->Ver]: fopen causes core dump

[magnus]

 ID:   22283
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pprocacci at datapipe dot com
-Status:   Feedback
+Status:   Verified
 Bug Type: Reproducible crash
 Operating System: FreeBSD4.7-Stable
-PHP Version:  4.3.0
+PHP Version:  4.3.0 5.0-dev
 New Comment:

Backtrace with current head using Linux:

#0  0x40118543 in strlen () from /lib/libc.so.6
No symbol table info available.
#1  0x08100482 in php_stream_url_wrap_http (wrapper=0x401e2c6c,
path=0x401e2d98 "r", 
mode=0xc , options=0, opened_path=0x0,
context=0x0, 
__php_stream_call_depth=135947776, __zend_filename=0x565 , 
__zend_lineno=0, __zend_orig_filename=0x0,
__zend_orig_lineno=3221213880)
at /php/php/php5/ext/standard/http_fopen_wrapper.c:352
entry = (struct _zval_struct *) 0x0
entryp = (struct _zval_struct **) 0x0
new_path = '\0' , "\016ì\020@\220Óÿ¿\202
\035@\035", '\0' ,
"T\224\034@\0\0\0\0ÐÑÿ¿\230Ñÿ¿Á\211\016@ÐÑÿ¿¨v\e\b", '\0' , "ÀÌÿ¿\0\0\0\0xÑÿ¿µ³\016@", '\0' , "s
\0\0\0\0ùÿÿÿ", '\0' , "\226w\e\b", '\0' ,
"£v\e\bÈÌÿ¿\002\0\0\0\002\0\0\0üÒÿ¿xÑÿ¿\0\0\0\0¨v\e\b%\0\0\0", '\0'
, "¨v\e\b", '\0' , "\027"...
loc_path = '\0' 
stream = (struct _php_stream *) 0x81f86d0
resource = (struct php_url *) 0x401e2c6c
use_ssl = 0
scratch = 0x 
tmp = 0x8177bba
"\211Eø\213EøÉÃU\211å\203ì(\213E\020\211Eô\203}\f"
ua_str = 0xbfffd258 "¸Òÿ¿-Å\v\bl,\036@\230-\036@\f"
ua_zval = (struct _zval_struct **) 0x81daf8c
scratch_len = 1381
body = 135947776
location = '\0' ,
"Ç\206\0@\025í\n@\025í\n@\0\0\0\0\0\0\0\0
\0\0\0Z\b\0@¸\005\0@\030\002\0@è1\001@\b\0\0\0\024\034\005@´4\001@Ô\032\005@g«\n@°Ñÿ¿vv\0@g«\n@õ(Ü\0p.\n@`Ñÿ¿p8\001@T\224\034@
à\034@\0\0\0\0\001\0\0\0\0\0\0\0SÏ\026\b\0\0\0\024\030{\f@\0\0\0\004",
'\0' ,
"±\207\0@\nv\005\b\0\031\005@\0\0\0\0´4\001@`Ñÿ¿\024ª\b@\200Ñÿ¿Ç\206\0@\0\0\0\0Ñê\020@ðÑÿ¿Å\023\230|
0\001@"...
response_header = (struct _zval_struct *) 0x72
reqok = 2
http_header_line = 0x2 
tmp_line =
"¼û\034@TÒÿ¿DÒÿ¿\0\0\0\0\0\0\0\0\0\035\036@\001\0\0\0\030\e\036@nuke/\0ÿ¿8Òÿ¿){\027\b\002\0\0\0¼û\034@TÒÿ¿DÒÿ¿",
'\0' , "Q", '\0' ,
"\002\0\0\0Àû\034@¼û\034@"
chunk_size = 135755752
file_size = 3221212600
eol_detect = -1073753232
#2  0x0814d5c5 in _php_stream_open_wrapper_ex (path=0x401e2c6c
"http://xanthus.net";, 
mode=0x401e2d98 "r", options=12, opened_path=0x0, context=0x0,
__php_stream_call_depth=0, 
__zend_filename=0x81a6600 "/php/php/php5/ext/standard/file.c",
__zend_lineno=1381, 
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/php/php/php5/main/streams/streams.c:1500
stream = (struct _php_stream *) 0x0
wrapper = (struct _php_stream_wrapper *) 0x81f86d0
path_to_open = 0x401e2c6c "http://xanthus.net";
copy_of_path = 0x0
#3  0x080bc52d in php_if_fopen (ht=2, return_value=0x401e2cfc,
this_ptr=0x0, return_value_used=1)
at /php/php/php5/ext/standard/file.c:1379
filename = 0x401e2c6c "http://xanthus.net";
mode = 0x401e2d98 "r"
filename_len = 18
mode_len = 1
use_include_path = 0 '\0'
zcontext = (struct _zval_struct *) 0x0
stream = (struct _php_stream *) 0x81ced60
context = (struct _php_stream_context *) 0x0
#4  0x0818f298 in zend_do_fcall_common_helper (execute_data=0xbfffd3c0,
op_array=0x401e1454)
at /php/php/php5/Zend/zend_execute.c:2609
original_return_value = (struct _zval_struct **) 0x31d
current_scope = (struct _zend_class_entry *) 0x0
current_this = (struct _zval_struct *) 0x0
return_value_used = 1
active_namespace = (struct _zend_class_entry *) 0x81e6e4c
#5  0x0818f8ef in zend_do_fcall_handler (execute_data=0xbfffd3c0,
op_array=0x401e1454)
at /php/php/php5/Zend/zend_execute.c:2737
fname = (struct _zval_struct *) 0x401e16d0
#6  0x0818ab8a in execute (op_array=0x401e1454) at
/php/php/php5/Zend/zend_execute.c:1231
execute_data = {opline = 0x401e16ac, function_state =
{function_symbol_table = 0x0, 
function = 0x8203990, reserved = {0x0, 0x0, 0x401e1454, 0x0}}, fbc
= 0x0, fbc_constructor = 0x0, 
  op_array = 0x401e1454, object = 0x0, Ts = 0xbfffd34c,
original_in_execution = 0 '\0', 
  calling_scope = 0x0, prev_execute_data = 0x0}
#7  0x08176716 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /php/php/php5/Zend/zend.c:985
files = 0xbfffd474 ""
i = 1
file_handle = (struct _zend_file_handle *) 0xb740
orig_op_array = (struct _zend_op_array *) 0x0
local_retval = (struct _zval_struct *) 0x0
#8  0x0813cb43 in php_execute_script (primary_file=0xb740) at
/php/php/php5/main/main.c:1729
orig_bailout = {{__jmpbuf = {1075614804, 1073819680,
-1073743900, -1073743992, -107378, 
  135887336}, __mask_

#22284 [NEW]: Dynamic Var Accessin Classes crashes PHP

[White_Angel at gmx dot de]

From: White_Angel at gmx dot de
Operating system: Linux;RedHat8.0;2.4.18-24
PHP version:  5CVS-2003-02-18 (dev)
PHP Bug Type: Reproducible crash
Bug description:  Dynamic Var Accessin Classes crashes PHP

On testing how to solve Bug #22269 I noticed the following:

class foo {
  var $a="dummyyy";

  function bar() {
 $name="a";
 echo $this->$name; or $this->$name;
  }
}

Will generate nen Segmetnation Vault if the $this->$name line is parsed.

If this Acces is depricated HOW CAN i access this Variable Now ?
(class_get_vars is only reading)
Is this a Bug or a feature ?
-- 
Edit bug report at http://bugs.php.net/?id=22284&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22284&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22284&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22284&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22284&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22284&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22284&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22284&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22284&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22284&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22284&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22284&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22284&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22284&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22284&r=gnused

#22284 [Opn]: Dynamic Var Accessing Classes crashes PHP

[White_Angel at gmx dot de]

 ID:   22284
 User updated by:  White_Angel at gmx dot de
-Summary:  Dynamic Var Accessin Classes crashes PHP
 Reported By:  White_Angel at gmx dot de
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Linux;RedHat8.0;2.4.18-24
 PHP Version:  5CVS-2003-02-18 (dev)
 New Comment:

ups.


Previous Comments:


[2003-02-18 16:28:57] White_Angel at gmx dot de

On testing how to solve Bug #22269 I noticed the following:

class foo {
  var $a="dummyyy";

  function bar() {
 $name="a";
 echo $this->$name; or $this->$name;
  }
}

Will generate nen Segmetnation Vault if the $this->$name line is
parsed.

If this Acces is depricated HOW CAN i access this Variable Now ?
(class_get_vars is only reading)
Is this a Bug or a feature ?




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

#22284 [Opn]: Dynamic Var Accessing Classes crashes PHP

[White_Angel at gmx dot de]

 ID:   22284
 User updated by:  White_Angel at gmx dot de
 Reported By:  White_Angel at gmx dot de
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Linux;RedHat8.0;2.4.18-24
 PHP Version:  5CVS-2003-02-18 (dev)
 New Comment:

Added:
Must be a Problem in the Syntax Check because
php -l in syntax check only crashes also.


Previous Comments:


[2003-02-18 16:29:33] White_Angel at gmx dot de

ups.



[2003-02-18 16:28:57] White_Angel at gmx dot de

On testing how to solve Bug #22269 I noticed the following:

class foo {
  var $a="dummyyy";

  function bar() {
 $name="a";
 echo $this->$name; or $this->$name;
  }
}

Will generate nen Segmetnation Vault if the $this->$name line is
parsed.

If this Acces is depricated HOW CAN i access this Variable Now ?
(class_get_vars is only reading)
Is this a Bug or a feature ?




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