[PHP-DEV] Bug #14533: snmp seg fault
From: [EMAIL PROTECTED] Operating system: RH Linux 7.2 PHP version: 4.1.0 PHP Bug Type: SNMP related Bug description: snmp seg fault I'm using RH Linux 7.2 php 4.1.0 with ucd-snmp that comes along with the linux distribution. My configure parameter is as follows ./configure --with-apxs=/usr/sbin/apxs --enable-calendar --with-pgsql --with-snmp --enable-ucd-snmp-hack --enable-wddx --enable-sysvsem --with-sysvshm --enable-inline-optimization --enable-ftp --with-gd --enable-gd-native-ttf --with-openssl The compilation is smooth, but when i execute any snmp related functions i get segmentation fault. I had got same problem with php 4.0.6 as well and i changed to 4.1.0 but the problem persists. gdb out is as follows: Core was generated by `php snmp.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libssl.so.2...done. Loaded symbols for /lib/libssl.so.2 Reading symbols from /lib/libcrypto.so.2...done. Loaded symbols for /lib/libcrypto.so.2 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libpam.so.0...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /usr/lib/libsnmp-0.4.2.1.so...done. Loaded symbols for /usr/lib/libsnmp-0.4.2.1.so Reading symbols from /usr/lib/libpq.so.2...done. Loaded symbols for /usr/lib/libpq.so.2 Reading symbols from /usr/lib/libgd.so.1.8...done. Loaded symbols for /usr/lib/libgd.so.1.8 Reading symbols from /lib/i686/libm.so.6...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /usr/kerberos/lib/libkrb5.so.3...done. Loaded symbols for /usr/kerberos/lib/libkrb5.so.3 Reading symbols from /usr/kerberos/lib/libk5crypto.so.3...done. Loaded symbols for /usr/kerberos/lib/libk5crypto.so.3 ---Type return to continue, or q return to quit--- Reading symbols from /usr/kerberos/lib/libcom_err.so.3...done. Loaded symbols for /usr/kerberos/lib/libcom_err.so.3 Reading symbols from /usr/lib/libfreetype.so.6...done. Loaded symbols for /usr/lib/libfreetype.so.6 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/lib/libpng.so.2...done. Loaded symbols for /usr/lib/libpng.so.2 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 #0 0x402c8c71 in strlen () from /lib/i686/libc.so.6 (gdb) bt #0 0x402c8c71 in strlen () from /lib/i686/libc.so.6 #1 0x4017969f in bprintf () from /usr/lib/libsnmp-0.4.2.1.so #2 0x4017a453 in sprint_object_identifier () from /usr/lib/libsnmp-0.4.2.1.so #3 0x4017ce3a in sprint_value () from /usr/lib/libsnmp-0.4.2.1.so #4 0x080a1ab5 in php_snmp (ht=3, return_value=0x81e358c, this_ptr=0x0, return_value_used=1, st=2) at snmp.c:318 #5 0x080a1dbb in zif_snmpwalk (ht=3, return_value=0x81e358c, this_ptr=0x0, return_value_used=1) at snmp.c:397 #6 0x08134376 in execute (op_array=0x81e368c) at ./zend_execute.c:1590 #7 0x08111788 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814 #8 0x08067255 in php_execute_script (primary_file=0xb980) at main.c:1309 #9 0x08064e38 in main (argc=2, argv=0xba24) at cgi_main.c:738 #10 0x4025e507 in __libc_start_main (main=0x8064648 main, argc=2, ubp_av=0xba24, init=0x8062760 _init, fini=0x813c500 _fini, rtld_fini=0x4000dc14 _dl_fini, stack_end=0xba1c) at ../sysdeps/generic/libc-start.c:129 (gdb) Seems like the problem is with ucd-snmp that comes along RH linux. I'm tring with fresh source of ucd-snmp. -- Edit bug report at: http://bugs.php.net/?id=14533edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14533 Updated: snmp seg fault
ID: 14533 Updated by: mfischer Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: SNMP related Operating System: RH Linux 7.2 PHP Version: 4.1.0 New Comment: Hmm, seems so. Can you recompile the RH package with debug symbols enabled (or installed a version with debug symbols?) Or grab the latest ucd-snmp from source. Btw, please paste a small, self-contained, reproducea easy copy paste script too. Feedback. Previous Comments: [2001-12-15 04:05:17] [EMAIL PROTECTED] I'm using RH Linux 7.2 php 4.1.0 with ucd-snmp that comes along with the linux distribution. My configure parameter is as follows ./configure --with-apxs=/usr/sbin/apxs --enable-calendar --with-pgsql --with-snmp --enable-ucd-snmp-hack --enable-wddx --enable-sysvsem --with-sysvshm --enable-inline-optimization --enable-ftp --with-gd --enable-gd-native-ttf --with-openssl The compilation is smooth, but when i execute any snmp related functions i get segmentation fault. I had got same problem with php 4.0.6 as well and i changed to 4.1.0 but the problem persists. gdb out is as follows: Core was generated by `php snmp.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libssl.so.2...done. Loaded symbols for /lib/libssl.so.2 Reading symbols from /lib/libcrypto.so.2...done. Loaded symbols for /lib/libcrypto.so.2 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libpam.so.0...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /usr/lib/libsnmp-0.4.2.1.so...done. Loaded symbols for /usr/lib/libsnmp-0.4.2.1.so Reading symbols from /usr/lib/libpq.so.2...done. Loaded symbols for /usr/lib/libpq.so.2 Reading symbols from /usr/lib/libgd.so.1.8...done. Loaded symbols for /usr/lib/libgd.so.1.8 Reading symbols from /lib/i686/libm.so.6...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /usr/kerberos/lib/libkrb5.so.3...done. Loaded symbols for /usr/kerberos/lib/libkrb5.so.3 Reading symbols from /usr/kerberos/lib/libk5crypto.so.3...done. Loaded symbols for /usr/kerberos/lib/libk5crypto.so.3 ---Type return to continue, or q return to quit--- Reading symbols from /usr/kerberos/lib/libcom_err.so.3...done. Loaded symbols for /usr/kerberos/lib/libcom_err.so.3 Reading symbols from /usr/lib/libfreetype.so.6...done. Loaded symbols for /usr/lib/libfreetype.so.6 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/lib/libpng.so.2...done. Loaded symbols for /usr/lib/libpng.so.2 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 #0 0x402c8c71 in strlen () from /lib/i686/libc.so.6 (gdb) bt #0 0x402c8c71 in strlen () from /lib/i686/libc.so.6 #1 0x4017969f in bprintf () from /usr/lib/libsnmp-0.4.2.1.so #2 0x4017a453 in sprint_object_identifier () from /usr/lib/libsnmp-0.4.2.1.so #3 0x4017ce3a in sprint_value () from /usr/lib/libsnmp-0.4.2.1.so #4 0x080a1ab5 in php_snmp (ht=3, return_value=0x81e358c, this_ptr=0x0, return_value_used=1, st=2) at snmp.c:318 #5 0x080a1dbb in zif_snmpwalk (ht=3, return_value=0x81e358c, this_ptr=0x0, return_value_used=1) at snmp.c:397 #6 0x08134376 in execute (op_array=0x81e368c) at ./zend_execute.c:1590 #7 0x08111788 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814 #8 0x08067255 in php_execute_script (primary_file=0xb980) at main.c:1309 #9 0x08064e38 in main (argc=2, argv=0xba24) at cgi_main.c:738 #10 0x4025e507 in __libc_start_main (main=0x8064648 main, argc=2, ubp_av=0xba24, init=0x8062760 _init, fini=0x813c500 _fini, rtld_fini=0x4000dc14 _dl_fini, stack_end=0xba1c) at ../sysdeps/generic/libc-start.c:129 (gdb) Seems like the problem is with ucd-snmp that comes along RH linux. I'm tring with fresh source of ucd-snmp. Edit this bug report at http://bugs.php.net/?id=14533edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13292 Updated: file_exists works with UNC names
ID: 13292
Updated by: sander
Reported By: [EMAIL PROTECTED]
Old Summary: file_exists not working with UNC names
Status: Open
Old Bug Type: Filesystem function related
Bug Type: Documentation problem
Operating System: Windows NT/2000
PHP Version: 4.0.6
New Comment:
Actually, it does work!!!
Use //computername/share/filename or computername\share\filename
Thanks to Christph Grottolo for the tip.
Now it's only a documentation problem.
Previous Comments:
[2001-12-14 14:38:09] [EMAIL PROTECTED]
Doesn't work with 4.1.0 nor with 4.2.0-dev.
[2001-12-14 14:29:39] [EMAIL PROTECTED]
This is not a Scripting Engine Problem, but a FIle System function report.
[2001-12-14 14:28:20] [EMAIL PROTECTED]
Any updates for this? This is a known issue for a long time.
To reporter: I don't use windows. Could you try 4.1.0 and report the result?
[2001-09-13 15:55:36] [EMAIL PROTECTED]
On a Windows 2000 box with PHP and IIS5.0, create a page the calls the file_exists
function on a
known machine\share\file
You will need to create a share on that machine or another.
For example :
if (file_exists(machine\\share\\test.txt) {
echo ExistsBR;
} else {
echo Does not ExistBR;
}
The file_exists function will always return false.
The function works fine with drive letter associations, but not for UNC notation on
win32.
You have closed this bug with id #6554.
But this bug is not fixed in 4.0.6
Edit this bug report at http://bugs.php.net/?id=13292edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14534: Variables $PHP_AUTH_* is set, when use a traditional external auth mechanism
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.0 PHP Bug Type: Apache related Bug description: Variables $PHP_AUTH_* is set, when use a traditional external auth mechanism .htaccess AuthUserFile.htpasswd AuthNameWARNING! ENTER ACCESS KEY! AuthTypeBasic Require valid-user index.php pre $PHP_AUTH_USER ? var_dump($PHP_AUTH_USER); ? $PHP_AUTH_PW ? var_dump($PHP_AUTH_PW); ? pre http://www.php.net/manual/en/features.http-auth.php cut In order to prevent someone from writing a script which reveals the password for a page that was authenticated through a traditional external mechanism, the PHP_AUTH variables will not be set if external authentication is enabled for that particular page. In this case, the $REMOTE_USER variable can be used to identify the externally-authenticated user. /cut -- Edit bug report at: http://bugs.php.net/?id=14534edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14050 Updated: problems with eregi and setlocale (apache module only)
ID: 14050
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Regexps related
Operating System: Linix
PHP Version: 4.0.5
New Comment:
Does not reproduce in php4.1.0.
Previous Comments:
[2001-11-14 04:29:30] [EMAIL PROTECTED]
This script work OK with cgi version php and randomly fail with apache module
(preg_match It is used for comparison and it works always correctly):
?
$LOCALE = 'ru_RU.KOI8-R';
setlocale('LC_ALL' ,$LOCALE);
$str = ÐòÉ÷ÅÔ;
echo $str.br\n;
if (eregi(ðÒÉ×åÔ,$str))
echo eregi: OKbr\n;
if (preg_match(/ðÒÉ×åÔ/i,$str))
echo preg_match: OKbr\n;
?
Edit this bug report at http://bugs.php.net/?id=14050edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #13292 Updated: file_exists works with UNC names
On Sat, Dec 15, 2001 at 10:25:34AM -, [EMAIL PROTECTED] wrote : ID: 13292 Updated by: sander Reported By: [EMAIL PROTECTED] Old Summary: file_exists not working with UNC names Status: Open Old Bug Type: Filesystem function related Bug Type: Documentation problem Operating System: Windows NT/2000 PHP Version: 4.0.6 New Comment: Actually, it does work!!! Use //computername/share/filename or computername\share\filename ^^^^ Wouldn't it require \\ there ? ---+-+ - Markus -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-DOC] Please read. session.xml
Does anyone mind if I update session.xml? I would like to prevent flood of bug reports. Thank you. Update as you see fit. Goba -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13292 Updated: file_exists works with UNC names
ID: 13292
Updated by: sander
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Windows NT/2000
PHP Version: 4.0.6
New Comment:
Markus noted that you should always use double backslashes (or single slashes):
computername\\share\\filename
BTW: sorry for the typo Christoph... ;)
Previous Comments:
[2001-12-15 05:25:33] [EMAIL PROTECTED]
Actually, it does work!!!
Use //computername/share/filename or computername\share\filename
Thanks to Christph Grottolo for the tip.
Now it's only a documentation problem.
[2001-12-14 14:38:09] [EMAIL PROTECTED]
Doesn't work with 4.1.0 nor with 4.2.0-dev.
[2001-12-14 14:29:39] [EMAIL PROTECTED]
This is not a Scripting Engine Problem, but a FIle System function report.
[2001-12-14 14:28:20] [EMAIL PROTECTED]
Any updates for this? This is a known issue for a long time.
To reporter: I don't use windows. Could you try 4.1.0 and report the result?
[2001-09-13 15:55:36] [EMAIL PROTECTED]
On a Windows 2000 box with PHP and IIS5.0, create a page the calls the file_exists
function on a
known machine\share\file
You will need to create a share on that machine or another.
For example :
if (file_exists(machine\\share\\test.txt) {
echo ExistsBR;
} else {
echo Does not ExistBR;
}
The file_exists function will always return false.
The function works fine with drive letter associations, but not for UNC notation on
win32.
You have closed this bug with id #6554.
But this bug is not fixed in 4.0.6
Edit this bug report at http://bugs.php.net/?id=13292edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.1.0 New Comment: Can you please try a snapshot from snaps.php.net, and see if it's fixed in the 4.2.0dev version? Thanx, Derick Previous Comments: [2001-12-14 20:16:49] [EMAIL PROTECTED] Having a problem like in bug ID# 9836 but was unable to submit comments to that thread. scripts sometimes stops outputing part ways through. (No errors just an uncompleted page displayed). Regardless of how many refreshes it stops at exact same place. Some pages have very little code others have a lot so length doesn't seem to be the issue. I tried setting a session variable after an echo statement that did not fully display and on a reload it had taken the new value. This would suggest the script doesn't really stop, just the output of HTML being returned stops. As a side note the time the setting of a session variable was added below the lines not displaying, upon a refresh it not only showed me the variable was set but it displayed the whole page. Sure enough if I pulled the session variable out (nothing relative to the page at all), restart the session it's back to stopping at the exact same spot before - right in the middle of an echo statement such as: echo This is a sample; would only output: Thi (and that would be the last of the page) It is not timing out (runs in less than a second). But I have discovered if I set the following in php.ini it works perfectly: output_buffering = On (formally set to 'Off') You would think that with it set to On you'd have more chances of a cut off than with it Off Here is my config line (same as when I run PHP4.0.6 which doesn't repeat this problem). ./configure --with-apxs --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --prefix=/u sr --with-config-file-path=/etc --disable-debug --enable-pic --disable-rpath --enable-inline-optimization --with-bz2 --with-curf --with-db3 --with-exec-dir=/usr/bin --with-gd --with-gdbm --with-gettext -with-jpeg-dir=/usr --enable-trans-sid --with-openssl --with-png --with-regex=system --with-ttl --with-zlib --with-layout=GNU --enable-debugger --enable-ftp --enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-yp --enable-wddx --with-mysql --with-pgsql --without-unixODBC --without-oracle --without-oci8 --with-pspell --with-xml --with-pdf --with-cybercash I also am using Zend Optimizer (for 4.1.0) I should also point out that with PHP4.1.0 I can not use 'user' session handling (used MySQL to handle sessions in PHP4.0.6), now unless I turn it back to default 'files' it will not let me use old (session_register) or the new ($_SESSION['name']=)...though no errors occur the session just doesn't retrieve or store data anymore. I don't know if these two would be linked but I thought I'd bring it up Edit this bug report at http://bugs.php.net/?id=14529edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14532 Updated: streams.c:285: warning: initialization from incompatible
ID: 14532 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Analyzed Status: Feedback Bug Type: Compile Failure Operating System: RedHat 7.2 PHP Version: 4.1.0 New Comment: What is your configure line, so that we can try to reproduce this? regards, Derick Previous Comments: [2001-12-15 02:04:05] [EMAIL PROTECTED] strearms is highly experimental, but thank you for reporting. Wez? are you around? IIRC it's yours ;) [2001-12-15 01:53:28] [EMAIL PROTECTED] Making all in main make[1]: Entering directory `/data/sw/.zip/php-4.1.0/main' make[2]: Entering directory `/data/sw/.zip/php-4.1.0/main' /bin/sh /data/sw/.zip/php-4.1.0/libtool --silent --mode=compile gcc -I. -I/data/sw/.zip/php-4.1.0/main -I/data/sw/.zip/php-4.1.0/main -I/data/sw/.zip/php-4.1.0 -I/opt/apache/include -I/data/sw/.zip/php-4.1.0/Zend -I/usr/include/freetype2/freetype -I/usr/include/imap -I/usr/local/mcal/include -I/opt/mysql/include/mysql -I/usr/include/pspell -I/usr/include/ucd-snmp -DLINUX=22 -DUSE_HSREGEX -I/data/sw/.zip/php-4.1.0/TSRM -g -O2 -prefer-pic -c streams.c streams.c:285: warning: initialization from incompatible pointer type streams.c: In function `php_stream_cast': streams.c:340: parse error before `static' streams.c:346: `cast_names' undeclared (first use in this function) streams.c:346: (Each undeclared identifier is reported only once streams.c:346: for each function it appears in.) make[2]: *** [streams.lo] Error 1 make[2]: Leaving directory `/data/sw/.zip/php-4.1.0/main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/data/sw/.zip/php-4.1.0/main' make: *** [all-recursive] Error 1 Edit this bug report at http://bugs.php.net/?id=14532edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14048 Updated: Configure issues
ID: 14048 Updated by: derick Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: BSD/OS 4.x PHP Version: 4.1.0 New Comment: Those yacc warnings are harmless. Previous Comments: [2001-12-15 05:37:28] [EMAIL PROTECTED] Ok, working on it. 2 notes on this build: I get a lot of yacc warnings like these: /usr/src/web/php/php4/ext/standard/var_unserializer.re:273: warning: label `yy1' defined but not used And the XtOffsetOf is redefined: In file included from /apbeta/include/httpd.h:72, from sapi_apache.c:32: /apbeta/include/ap_config.h:1367: warning: `XtOffsetOf' redefined [2001-12-14 21:23:50] [EMAIL PROTECTED] So with the minimum options everything works just fine? If so, then please try adding some more options and see when it starts to fail. --Jani [2001-12-14 15:40:06] [EMAIL PROTECTED] Ok, you can rule that out. Compiles outof the box. Build php4-200112140600. [2001-12-13 21:41:38] [EMAIL PROTECTED] Please try the latest CVS snapshot with this configure line: --with-apxs=/apache/bin/apxs --without-mysql --disable-pear --disable-xml --disable-session --enable-debug As I first want to rule out any extension being the reason for the segfault. --Jani [2001-12-13 00:26:11] [EMAIL PROTECTED] needcoffeeoops - sorry about the double posts - I'm not quite awake yet - can you delete that?/needcoffee Indeed I compiled the snapshot from 11120600 and that compiled outof the box - same problem though - core dumps and httpd won't start up. Independant of that - HAVE_RES_SEARCH is still not recognized correctly in both buildtypes. 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/?id=14048 Edit this bug report at http://bugs.php.net/?id=14048edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-DOC] Please read. session.xml
Gabor Hojtsy wrote: Does anyone mind if I update session.xml? I would like to prevent flood of bug reports. Thank you. Update as you see fit. Goba Ok. I'll edit session.xml after I finish pgsql related work :) -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14048 Updated: Configure issues
Markus Fischer said at 12:16 15-12-2001: ok, working on it. 2 notes on this build: i get a lot of yacc warnings like these: /usr/src/web/php/php4/ext/standard/var_unserializer.re:273: warning: label `yy1' defined but not used that's ok . Ok. and the xtoffsetof is redefined: in file included from /apbeta/include/httpd.h:72, from sapi_apache.c:32: /apbeta/include/ap_config.h:1367: warning: `xtoffsetof' redefined that shouldn't be... These are the lines in ap_config.h: #ifdef offsetof #define XtOffsetOf(s_type,field) offsetof(s_type,field) #else #define XtOffsetOf(s_type,field) XtOffset(s_type*,field) #endif And this in sapi_apache.c: #ifndef XtOffsetOf #ifdef offsetof #define XtOffsetOf(s_type, field) offsetof(s_type, field) #else #define XtOffsetOf(s_type, field) XtOffset(s_type*, field) #endif #endif /* !XtOffsetOf */ From the looks of the warning, the include order is wrong: In file included from php_apache_http.h:6, from php_apache.c:45: /apbeta/include/ap_config.h:1367: warning: `XtOffsetOf' redefined /home/mdev/_src/php4-200112140600/main/php.h:345: warning: this is the location of the previous definition Note the __previous__ definition. I changed the order in sapi_apache.c, but that broke it: In file included from /home/mdev/_src/php4-200112140600/main/php_regex.h:13, from /home/mdev/_src/php4-200112140600/main/php.h:60, from sapi_apache.c:33: /home/mdev/_src/php4-200112140600/regex/regex.h:17: redefinition of `regoff_t' /apbeta/include/hsregex.h:27: `regoff_t' previously declared here /home/mdev/_src/php4-200112140600/regex/regex.h:23: conflicting types for `regex_t' /apbeta/include/hsregex.h:33: previous declaration of `regex_t' /home/mdev/_src/php4-200112140600/regex/regex.h:27: conflicting types for `regmatch_t' /apbeta/include/hsregex.h:37: previous declaration of `regmatch_t' make[3]: *** [sapi_apache.lo] Error 1 make[3]: Leaving directory `/home/mdev/_src/php4-200112140600/sapi/apache' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/mdev/_src/php4-200112140600/sapi/apache' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/mdev/_src/php4-200112140600/sapi' make: *** [all-recursive] Error 1 diff is: *** sapi_apache.c.dist Tue Dec 11 16:45:27 2001 --- sapi_apache.c Sat Dec 15 13:21:36 2001 *** *** 27,36 #include stddef.h #endif - #include php.h - #include httpd.h #include http_config.h #if MODULE_MAGIC_NUMBER 19980712 # include ap_compat.h #else --- 27,37 #include stddef.h #endif #include httpd.h #include http_config.h + + #include php.h + #if MODULE_MAGIC_NUMBER 19980712 # include ap_compat.h #else Met vriendelijke groeten / With kind regards, IDG.nl Melvyn Sopacua Webmaster -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14483 Updated: -twolevel_namespace and multiple definitions errors
ID: 14483 Updated by: derick Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.1 PHP Version: 4.2.0-dev New Comment: That commenting out should not be nessecairy, I have the same on my system. The problem is something else... Derick Previous Comments: [2001-12-14 17:26:57] [EMAIL PROTECTED] It's friday niiigghttt... Doing: grep -nrH \*yytext Zend/* Yields: - zend_ini_scanner.c:310:extern char *yytext; zend_ini_scanner.c:496:char *yytext; zend_language_scanner.c:305:extern char *yytext; zend_language_scanner.c:2725:char *yytext; - So: pico -b -e -w +2725 zend_language_scanner.c Comment out: /* char *yytext; */ We are money because this is already declared as a extern in zend_ini_scanner or whatever. Now the compile completes, but everything is still hosed, because make install gives: Making install in . apxs -i -a -n php4 libs/libphp4.so [activating module `php4' in /private/etc/httpd/httpd.conf] cp libs/libphp4.so /usr/libexec/httpd/libphp4.so cp: libs/libphp4.so: No such file or directory apxs:Break: Command failed with rc=1 make[1]: *** [install-sapi] Error 1 make: *** [install-recursive] Error 1 Arg... [2001-12-14 16:59:25] [EMAIL PROTECTED] Progress: [Just downloaded and compiled the latest GNU autoconf, automake, and libtool] After some further web research, most of it comes down to being a libtool issue, which is covered here: http://savannah.gnu.org/support/?func=detailsupportsupport_id=100049group_id=25 It all begins with replacing all instances of: deplibs=$lib $deplibs with if test $libdir; then deplibs=$lib $deplibs fi in ltmain.sh, and if configure has already been run, in libtool. There three occurrences in ltmain.sh. The reason sh!t is multiply defined is because it's multiply loaded. The above helps. This gets rid of the all of the multiple defined error messages except: - ld: multiple definitions of symbol _yytext Zend/.libs/libZend.al(zend_language_scanner.lo) definition of _yytext in section (__DATA,__common) Zend/.libs/libZend.al(zend_ini_scanner.lo) definition of _yytext in section (__DATA,__common) /usr/bin/libtool: internal link edit command failed make[1]: *** [libphp4.la] Error 1 make: *** [all-recursive] Error 1 - This is being attacked... more later... hopefully. Also, I noticed main/php_config.h defines 'uint' even though /usr/include/sys/types.h already has 'uint'. sys/types.h does't define ulong, thought. In php_config.h 'uint' is defined twice, once right at the top and again on line 1836. 'ulong' is also defined, but that's OK. This does not hose anything, only it doesn't allow use of the precompiled version of the system's unistd.p. Changing php_config.h, starting at line 1836 (or near there): from - /* Define to `unsigned int ' if sys/types.h does not define. */ #define uint unsigned int /* Define to `unsigned long ' if sys/types.h does not define. */ #define ulong unsigned long to - /* Define to `unsigned int ' if sys/types.h does not define. */ /* #define uint unsigned int */ /* Define to `unsigned long ' if sys/types.h does not define. */ #define ulong unsigned long - and commenting out these two lines near the top, on line 9, so they appear as follows: - /* #define uint unsigned int */ /* #define ulong unsigned long */ - Fixes this stuff. That leaves me with only the _yytext multiple defined errors, and two or three cpp smart preprocessing warnings. Almost there... [2001-12-14 16:37:55] [EMAIL PROTECTED] [2001-12-13 07:18:30] [EMAIL PROTECTED] Also a duplicate of bug 14154, which is a freakin' struggle of a bug. [2001-12-13 07:08:12] [EMAIL PROTECTED] (NOTE: Duplicate of BUG 14256) PHP 4.1.0 fails to compile on Mac OS X 10.1 (you probably already know this). This is while building the Apache Module. Notes: - First scenario: attempting the run-of-the-mill compile fails once it gets to ld, which throws out -twolevel_namespace warnings. - Second scenario: Modifying (by adding -flat_namespace) any presence of anything that may seem like a compiler flag or linker flag in config_vars.mk, php_config.h, libtool, etc., leads to a LARGE number of multiple definition errors that look like this: --- TSRM/.libs/libtsrm.al(tsrm_virtual_cwd.lo) definition of _virtual_utime in section (__TEXT,__text) TSRM/.libs/libtsrm.al(tsrm_virtual_cwd.lo) definition of _virtual_utime in section (__TEXT,__text)
[PHP-DEV] Bug #14381 Updated: xlst_error causes error with valid XSLT processor instance
ID: 14381 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Bogus Status: Closed Bug Type: XSLT related Operating System: Linux-2.4.14 glibc-2.2.3 PHP Version: 4.1.0 New Comment: It was already fixed in the php 4.2.0 branch, I MFHed it to the PHP_4_0_7 branch. Derick Previous Comments: [2001-12-14 12:03:57] [EMAIL PROTECTED] RTFM, the syntax for the xslt extension has changed... [2001-12-07 12:07:06] [EMAIL PROTECTED] the following code causes Apache processes to segfault: $xsl_handle = xslt_create(); echo $xsl_handle; // returns a valid xslt processor handle // $xslData and $xmlData contain valid information xslt_process($xslData, $xmlData, $result); echo xslt_error($xsl_handle); xslt_free($xsl_handle); This piece of code also returns a Warning: Supplied argument is not a valid XSLT Processor resource in *** on line 27, where line 27 is xslt_process($xslData, $xmlData, $result); Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x404b251b in strlen (str=0x0) at ../sysdeps/i386/strlen.c:27 27 ../sysdeps/i386/strlen.c: No such file or directory. (gdb) bt #0 0x404b251b in strlen (str=0x0) at ../sysdeps/i386/strlen.c:27 #1 0x8114a6d in zif_xslt_error (ht=1, return_value=0x8367dfc, this_ptr=0x0, return_value_used=1) at sablot.c:584 #2 0x8155e2a in execute (op_array=0x835694c) at ./zend_execute.c:1590 #3 0x8131419 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814 #4 0x8073ae1 in php_execute_script (primary_file=0xb358) at main.c:1309 #5 0x813cc6c in apache_php_module_main (r=0x8337ba8, display_source_mode=0) at sapi_apache.c:90 #6 0x80700e6 in send_php () at eval.c:88 #7 0x8070142 in send_parsed_php () at eval.c:88 #8 0x81a4819 in ap_invoke_handler () at eval.c:88 #9 0x81b9b6f in process_request_internal () at eval.c:88 #10 0x81b9fd6 in ap_internal_redirect () at eval.c:88 #11 0x8196a2d in mod_gzip_redir1_handler () at eval.c:88 #12 0x81952c2 in mod_gzip_handler () at eval.c:88 #13 0x81a4819 in ap_invoke_handler () at eval.c:88 #14 0x81b9b6f in process_request_internal () at eval.c:88 #15 0x81b9bd6 in ap_process_request () at eval.c:88 #16 0x81b09f6 in child_main () at eval.c:88 #17 0x81b0bd5 in make_child () at eval.c:88 #18 0x81b0d4c in startup_children () at eval.c:88 #19 0x81b13dd in standalone_main () at eval.c:88 #20 0x81b1c5c in main () at eval.c:88 #21 0x4045a2eb in __libc_start_main (main=0x81b18a8 main, argc=2, ubp_av=0xbb34, init=0x806cdec _init, fini=0x81d83ac _fini, rtld_fini=0x4000c130 _dl_fini, stack_end=0xbb2c) at ../sysdeps/generic/libc-start.c:129 Specs: Slackware-8.0 glibc-2.2.3 (Linux osiris 2.4.14 #1 Thu Nov 8 15:02:47 CET 2001 i686 unknown) apache_1.3.22 php-4.1.0RC5 expat-1.95.2 Sablot-0.71 PHP config: ./configure \ --with-apache=../apache_1.3.22 \ --with-mysql=/usr/local/mysql \ --with-gd=/usr/local \ --with-freetype-dir=/usr/local \ --with-jpeg-dir=/usr \ --with-png-dir=/usr \ --with-zlib \ --with-openssl \ --with-curl \ --enable-xslt \ --with-xslt-sablot \ --enable-sysvsem \ --enable-sysvshm \ --enable-track-vars \ --enable-memory-limit \ --enable-debug=yes Apache config: EAPI_MM=../mm-1.1.3 \ SSL_BASE=/usr \ ./configure \ --with-layout=Apache \ --prefix=/usr/local/apache \ --enable-module=rewrite \ --enable-module=ssl \ --add-module=/root/downloads/mod_gzip.c \ --activate-module=src/modules/php4/libphp4.a Edit this bug report at http://bugs.php.net/?id=14381edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13620 Updated: bzip2 extension seems to be broken
ID: 13620
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Bzip2 Related
Operating System: Win98 SE
Old PHP Version: 4.0CVS-2001-10-09
PHP Version: 4.0.1
New Comment:
Just a version update.
Loïc
Previous Comments:
[2001-11-27 15:17:09] [EMAIL PROTECTED]
Hi all!
I've justed the php 4.0.1 build from Daniel at the bug is still here.
In case you ask for a confirmation ;)
Loïc
[2001-11-11 06:42:17] [EMAIL PROTECTED]
4.0.6 works fine for me on Windows.
4.0.8 (the build from php4win) prints out:
-8
-5
A self-built 4.2.0-dev (200111080300) gives these errors:
bzcompress failed in script.php on line 2
bzdecompress failed in script.php on line 4
Reopening.
[2001-10-21 02:12:58] [EMAIL PROTECTED]
I can not reproduce this with PHP 4.1.0RC1 on Linux.
Could this be windows specific problem?
--Jani
[2001-10-09 19:22:14] [EMAIL PROTECTED]
Hi All!
Here is a little script to reproduce the bug:
?php
$var = bzcompress('abcdef123');
echo $var . 'br /' . \n;
echo bzdecompress($var);
?
It returns:
-8
-5
My config:
- Apache 1.3.20 on Win98-SE;
- php-4.0.7-rc3 or php-4.0.8-dev (latest build from php4win.de) loaded as an Apache
module;
- php.ini is the recommended one except pathes and two extensions loaded: php_bz2.dll
and php_zlib.dll.
Kind regards,
Loïc
Edit this bug report at http://bugs.php.net/?id=13620edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14515 Updated: child pid XXX exit signal Segmentation fault (11)
ID: 14515
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Operating System: linux 2.4.16
PHP Version: 4.1.0
New Comment:
sorry, forgot the stacktrace:
(gdb) bt
#0 0x40a0e333 in php_pcre_replace (regex=0x40ab8b11 /realm=\(.*?)\/i,
regex_len=16,
subject=0x8184455 Basic realm=\DB-RW-Access\, subject_len=27,
replace_val=0x81844a4,
is_callable_replace=0, result_len=0xbfffc19c, limit=-1) at php_pcre.c:768
#1 0x409bf494 in sapi_add_header_ex (header_line=0x818 WWW-Authenticate,
header_line_len=44, duplicate=1 '\001', replace=1 '\001') at SAPI.c:467
#2 0x40a4b7af in zif_header (ht=1, return_value=0x8184404, this_ptr=0x0,
return_value_used=0)
at head.c:56
#3 0x40996697 in execute (op_array=0x81840e4) at ./zend_execute.c:1590
#4 0x409a8364 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
zend.c:814
#5 0x409bb8e1 in php_execute_script (primary_file=0xb268) at main.c:1309
#6 0x409b6220 in apache_php_module_main (r=0x816a250, display_source_mode=0) at
sapi_apache.c:90
#7 0x409b71a0 in send_php (r=0x816a250, display_source_mode=0,
filename=0x816bdc8
/usr/local/WWW/marticole/htdocs/PRIVATE/Hausverwaltung/resthof.php)
at mod_php4.c:575
#8 0x409b7223 in send_parsed_php (r=0x816a250) at mod_php4.c:590
#9 0x806e019 in ap_invoke_handler ()
#10 0x8083aef in process_request_internal ()
#11 0x8083b62 in ap_process_request ()
#12 0x807a696 in child_main ()
#13 0x807a875 in make_child ()
#14 0x807a9f6 in startup_children ()
#15 0x807b07c in standalone_main ()
#16 0x807b8cc in main ()
#17 0x40620c6f in __libc_start_main () from /lib/libc.so.6
(gdb)
Previous Comments:
[2001-12-15 08:23:37] [EMAIL PROTECTED]
The only way to get some output was starting the apache inside gdb. I got the
following:
(gdb) run -X -f /usr/local/apache/conf/httpd.conf
Starting program: /usr/local/apache/bin/httpd -X -f /usr/local/apache/conf/httpd.conf
[New Thread 1024 (LWP 7109)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 7109)]
0x40a0e333 in php_pcre_replace (regex=0x40ab8b11 /realm=\(.*?)\/i, regex_len=16,
subject=0x8184455 Basic realm=\DB-RW-Access\, subject_len=27,
replace_val=0x81844a4,
is_callable_replace=0, result_len=0xbfffc19c, limit=-1) at php_pcre.c:768
768 if ('\\' == *walk || '$' == *walk) {
(gdb)
[2001-12-14 18:41:15] [EMAIL PROTECTED]
Could you provide backtrace?
http://bugs.php.net/bugs-generating-backtrace.php
Please read how to report bug link also.
[2001-12-14 09:23:20] [EMAIL PROTECTED]
Hi, when i try to run the following code, my apache goes banana (child pid XXX exit
signal Segmentation fault (11) in the error_log)
?php
if(!isset($PHP_AUTH_USER)) {
Header(WWW-Authenticate: Basic realm=\DB-RW-Access\);
Header(HTTP/1.0 401 Unauthorized);
echo Get lost\n;
exit;
}
else {
$dbid = $PHP_AUTH_USER;
$dbpw = $PHP_AUTH_PW;
}
phpinfo();
exit;
php-compile-time-options:
'./configure' '--prefix=/usr/local/php-4.1.0'
'--with-apxs=/usr/local/apache/bin/apxs'
'--enable-force-cgi-redirect'
'--with-config-file-path=/usr/local/apache/conf' '--with-openssl'
'--with-bz2'
'--with-imap'
'--with-gdbm'
'--enable-ftp'
'--with-gd'
'--enable-gd-native-ttf' '--with-oci8=/opt/oracle/app/oracle/product/8.1.7'
'--with-mysql=/usr'
'--enable-sigchild'
'--with-mm'
'--enable-rule=EAPI'
apache-version: 1.3.20
Any clue?
Regards,
Martin
Edit this bug report at http://bugs.php.net/?id=14515edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #5480 Updated: set_socket_blocking($fp, False) don't work !
ID: 5480
Updated by: sander
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Sockets related
Operating System: Win32
PHP Version: 4.0.0
New Comment:
No feedback. Closing.
Previous Comments:
[2001-11-21 12:11:21] [EMAIL PROTECTED]
Uh, 4.0.0 .. quite old ;)
Can you try with latest RC and see if it works
http://www.php.net/~zeev/php-4.1.0RC3.tar.gz
Feedback.
[2000-08-04 12:13:58] [EMAIL PROTECTED]
reclassify
[2000-07-09 06:54:14] [EMAIL PROTECTED]
$fp = fsockopen(localhost, 8000, $errno, $errstring, 3);
if(!$fp) {
echo $errstr ($errno)br\n;
}
else {
set_socket_blocking($fp, False);
fputs($fp, $message);
//while (!feof($fp)) {
//$string .= fread($fp, 20);
$string .= fgets($fp, 60);
//print(MESSAGE FGETS: $messageBR\n);
print(MESSAGE : $string\n);
//}
//fpassthru($fp);
print(MESSAGE FINISHED : $string\n);
fclose($fp);
//print(Message Received : $loginReceivedBR);
}
Edit this bug report at http://bugs.php.net/?id=5480edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9846 Updated: fopen() fails and gives Error 0 on NoContent URLs
ID: 9846 Updated by: sander Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Filesystem function related Operating System: linux,irix,tru64 PHP Version: 4.0.4pl1 New Comment: No feedback. Closing. Previous Comments: [2001-11-23 18:03:19] [EMAIL PROTECTED] Doesn't the contents of $http_response_header tell you what you need? $http_response_header should be an array of the HTTP response fopen() got [2001-10-29 02:35:13] [EMAIL PROTECTED] Taken from #9847, these are basically the same problem: When fopen()-ing an URL that responds with an HTTP 403 Forbidden, fopen() fails with an Error 0. There is no way to distinguish this error from a 'Not Found' type of error. --- [2001-03-19 16:56:02] [EMAIL PROTECTED] This bug might belong in the URL-related section. I believe it to be a generic problem. If you fopen() an URL that returns with an HTTP Header of NoContent (204), fopen() will fail with Error 0. Failure would be ok if there was a specific error code for NoContent URLs. Either that or returning a handle that was already at eof would suffice. As it is now, there's no way to tell the difference between a bad (NotFound) URL and a NoContent URL. Work-around it to use cURL to a temporary file and check the HTTP_CODE with the undocumented curl_getinfo() function. Of course, it seems a little weird to require the temporary file for a NoContent URL. But it works fine. -Eric Bloch [EMAIL PROTECTED] Edit this bug report at http://bugs.php.net/?id=9846edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12291 Updated: Apparent memory leak, possibly in session code
ID: 12291 Updated by: sander Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Session related Operating System: FreeBSD 3.x,4.x PHP Version: 4.0.6 New Comment: No feedback. Closing. Previous Comments: [2001-11-24 19:42:09] [EMAIL PROTECTED] Does this happen with PHP 4.1.0RC3: http://www.php.net/~zeev/php-4.1.0RC3.tar.gz [2001-07-20 15:27:11] [EMAIL PROTECTED] In http error log: httpd in free(): warning: page is already free. Displayed to browser: Fatal error: Allowed memory size of 9437184 bytes exhausted (tried to allocate 1144 bytes) One or more apache server processes become unstable and unable to handle more requests. Result is a page that contains no data being sent to the client. The problem seems to appear on machines that serve w/session usage. Not repeatable in a predictable manner. I am certain it is a problem with PHP because If I change the max-memory value in PHP.INI the value produced in the error (above) increases. Apache version .1.3.20, with mysql support, imap support and ldap support. Both compiled statically and as a dynamic module. We are actively using Mysql and sessions on both affected machines. Edit this bug report at http://bugs.php.net/?id=12291edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14197 Updated: please read example...
ID: 14197
Updated by: sander
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Session related
Operating System: Win32 (w2k)
PHP Version: 4.0.6
New Comment:
No feedback. Closing.
Previous Comments:
[2001-11-24 18:09:25] [EMAIL PROTECTED]
Does this happen with latest RC:
http://phpuk.org/~james/php-4.1.0RC3-win32.zip
[2001-11-23 09:04:12] [EMAIL PROTECTED]
1. standart php.ini, cookie disable, bug:
---php
? session_start(); ?
a a=\a\
a a=\'a\'
---output-
a a=\a\
a a=\'a\'
--
2. set [url_rewriter.tags=] in php.ini - no problem
3. Real example in my program (bug in html+js code):
---php--
document.writeln('frame name=\kbd\ src=
---output---
document.writeln('frame name=\kbd\ src=
Edit this bug report at http://bugs.php.net/?id=14197edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #6914 Updated: persistent socket connection failure
ID: 6914 Updated by: sander Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Sockets related Operating System: Linux 2.2.17 PHP Version: 4.0.2 New Comment: No feedback. Closing. Previous Comments: [2001-11-21 12:06:14] [EMAIL PROTECTED] pfsockopen() works for me with latest RC Can you try with latest RC and see if it works http://www.php.net/~zeev/php-4.1.0RC3.tar.gz Feedback. [2000-09-27 22:17:24] [EMAIL PROTECTED] A UNIX socket connection is made using pfsockopen(). On the initial script entry, a message is sent to our server and the reply is correctly received by the script. On subsequent script entries, messages to the server are still sent successfully, but upon attempting to reply a SIGPIPE is received by server, and the php script receives a 0-length reply to its fgets() read. We traced the problem to ext/standard/file.c, in the routine _file_socket_dtor(). In that routine, the macro SOCK_FCLOSE is used, which calls php_sock_close() in fsock.c. This routine correctly handles the persistent socket. However, after that call, _file_socket_dtor() then incorrectly calls the C routine shutdown(), which is what caused the problem. In fact, php_sock_close() already completely takes care of the shutdown() (for the non-persistent case), so in any event the shutdown() call in _file_socket_dtor() is not necessary. Edit this bug report at http://bugs.php.net/?id=6914edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14531 Updated: Reference to bug #14496
On Sat, Dec 15, 2001 at 02:05:39PM +0100, Christoph Grottolo wrote : But it would be cool to be at least able to add comments to bug reports of other users - like in the manual. Sometimes a non-dev member can reproduce a bug, give a hint or even an answer. Now, a common user who wants to comment a bug has to post to the dev list. The dev members usually take care of this and copy paste the appropriate mails. -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14162 Updated: wrong init with mcrypt_generic_init crashes php
ID: 14162
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Assigned
Status: Closed
Bug Type: mcrypt related
Operating System: i686-pc-linux-gnu
PHP Version: 4.0CVS-2001-11-21
Old Assigned To: derick
Assigned To:
New Comment:
Fixed in CVS. Please note that the return value as noted in the PHP Manual was not
correct. This function returns a negative value on error.
BTW, encrypting without password is not very smart, so speicifying FALSE there makes
no sense.
You can try a snapshot from snaps.php.net later toda, to see if it is really fixed
(ie, it doesn't crash anymore).
Derick
Previous Comments:
[2001-11-21 11:23:17] [EMAIL PROTECTED]
Hi,
php crashes with libmcrypt (ive test it with 2.4.17) with the follow
php script.
The problem is the complete wrong initalising with mcrypt_generic_init.
The mcrypt_generic_init results -3 and mcrypt_generic crashes.
?php
$stream='Hello World!';
$td = @mcrypt_module_open (MCRYPT_ARCFOUR , '', MCRYPT_MODE_STREAM, '');
if ($td!=false){
$result=@mcrypt_generic_init ($td, false, false);
if ($result!=-1){
$stream = mcrypt_generic ($td, $stream);
mcrypt_generic_deinit ($td);
}
}
echo $stream;
?
Edit this bug report at http://bugs.php.net/?id=14162edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14531 Updated: Reference to bug #14496
But it would be cool to be at least able to add comments to bug reports of other users - like in the manual. Sometimes a non-dev member can reproduce a bug, give a hint or even an answer. Now, a common user who wants to comment a bug has to post to the dev list. Christoph Rasmus Lerdorf [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]... Users can update bug reports just fine if they bother to remember the passwords they set On 15 Dec 2001 [EMAIL PROTECTED] wrote: I hope we can have new bug tracking system, so that users can update bug reports :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14290 Updated: SMP PHP/apache process appears to be in infinite loop 100% CPU Utilization
ID: 14290 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Scripting Engine problem Operating System: RH 7.2 PHP Version: 4.0.6 New Comment: Excellent! PROBLEM IS FIXED by upgrading to 4.1.0 :)! I should have put an entry in here a day so ago, but I wanted to give it enough time to see for sure if the bug would surface. Your current release is a great Holiday gift! YEA! Thanks SO MUCH to the whole team, and Happy Holidays! Previous Comments: [2001-12-14 13:04:41] [EMAIL PROTECTED] Could you try 4.1.0, if you still have problem, could you take backtrace when you have problem? (You know how to attach running process to gdb, rihgt?) You should also seach/ask RedHat if there is fix for this. AFAIK, there are many people have this problem. It is less likely to be fixed by changing PHP code.. But batcktrace may help. [2001-11-29 15:40:50] [EMAIL PROTECTED] Hello- Seems to be identical to bug #8446, which was closed, it appears, since the bug reporter did not reply after 4.0.5 was released. Using php 4.0.6 on RH 7.1 SMP. At random times (maybe once a day), a process will be found taking 99.9 %CPU. Wonder if other SMP servers are seeing the same issue... Thanks for any help. Edit this bug report at http://bugs.php.net/?id=14290edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14290 Updated: SMP PHP/apache process appears to be in infinite loop 100% CPU Utilization
ID: 14290 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Scripting Engine problem Operating System: RH 7.2 PHP Version: 4.0.6 New Comment: Closing then... Previous Comments: [2001-12-15 08:55:59] [EMAIL PROTECTED] Excellent! PROBLEM IS FIXED by upgrading to 4.1.0 :)! I should have put an entry in here a day so ago, but I wanted to give it enough time to see for sure if the bug would surface. Your current release is a great Holiday gift! YEA! Thanks SO MUCH to the whole team, and Happy Holidays! [2001-12-14 13:04:41] [EMAIL PROTECTED] Could you try 4.1.0, if you still have problem, could you take backtrace when you have problem? (You know how to attach running process to gdb, rihgt?) You should also seach/ask RedHat if there is fix for this. AFAIK, there are many people have this problem. It is less likely to be fixed by changing PHP code.. But batcktrace may help. [2001-11-29 15:40:50] [EMAIL PROTECTED] Hello- Seems to be identical to bug #8446, which was closed, it appears, since the bug reporter did not reply after 4.0.5 was released. Using php 4.0.6 on RH 7.1 SMP. At random times (maybe once a day), a process will be found taking 99.9 %CPU. Wonder if other SMP servers are seeing the same issue... Thanks for any help. Edit this bug report at http://bugs.php.net/?id=14290edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14381 Updated: xlst_error causes error with valid XSLT processor instance
Hello, I MFH'ed the fix to the brach 4.1.0 was released from. It's now fixed in every branch. Derick On Fri, 14 Dec 2001, Hans Rakers wrote: That still doesnt explain the segfault. Somebody else already pointed out the arguments to xslt_process changed. I changed this in the script according to the manual. But still the xslt_error() function should not segfault. -- Hans Rakers At 17:03 14-12-2001 +, you wrote: ID: 14381 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: XSLT related Operating System: Linux-2.4.14 glibc-2.2.3 PHP Version: 4.1.0 New Comment: RTFM, the syntax for the xslt extension has changed... Previous Comments: [2001-12-07 12:07:06] [EMAIL PROTECTED] the following code causes Apache processes to segfault: $xsl_handle = xslt_create(); echo $xsl_handle; // returns a valid xslt processor handle // $xslData and $xmlData contain valid information xslt_process($xslData, $xmlData, $result); echo xslt_error($xsl_handle); xslt_free($xsl_handle); This piece of code also returns a Warning: Supplied argument is not a valid XSLT Processor resource in *** on line 27, where line 27 is xslt_process($xslData, $xmlData, $result); Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x404b251b in strlen (str=0x0) at ../sysdeps/i386/strlen.c:27 27 ../sysdeps/i386/strlen.c: No such file or directory. (gdb) bt #0 0x404b251b in strlen (str=0x0) at ../sysdeps/i386/strlen.c:27 #1 0x8114a6d in zif_xslt_error (ht=1, return_value=0x8367dfc, this_ptr=0x0, return_value_used=1) at sablot.c:584 #2 0x8155e2a in execute (op_array=0x835694c) at ./zend_execute.c:1590 #3 0x8131419 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814 #4 0x8073ae1 in php_execute_script (primary_file=0xb358) at main.c:1309 #5 0x813cc6c in apache_php_module_main (r=0x8337ba8, display_source_mode=0) at sapi_apache.c:90 #6 0x80700e6 in send_php () at eval.c:88 #7 0x8070142 in send_parsed_php () at eval.c:88 #8 0x81a4819 in ap_invoke_handler () at eval.c:88 #9 0x81b9b6f in process_request_internal () at eval.c:88 #10 0x81b9fd6 in ap_internal_redirect () at eval.c:88 #11 0x8196a2d in mod_gzip_redir1_handler () at eval.c:88 #12 0x81952c2 in mod_gzip_handler () at eval.c:88 #13 0x81a4819 in ap_invoke_handler () at eval.c:88 #14 0x81b9b6f in process_request_internal () at eval.c:88 #15 0x81b9bd6 in ap_process_request () at eval.c:88 #16 0x81b09f6 in child_main () at eval.c:88 #17 0x81b0bd5 in make_child () at eval.c:88 #18 0x81b0d4c in startup_children () at eval.c:88 #19 0x81b13dd in standalone_main () at eval.c:88 #20 0x81b1c5c in main () at eval.c:88 #21 0x4045a2eb in __libc_start_main (main=0x81b18a8 main, argc=2, ubp_av=0xbb34, init=0x806cdec _init, fini=0x81d83ac _fini, rtld_fini=0x4000c130 _dl_fini, stack_end=0xbb2c) at ../sysdeps/generic/libc-start.c:129 Specs: Slackware-8.0 glibc-2.2.3 (Linux osiris 2.4.14 #1 Thu Nov 8 15:02:47 CET 2001 i686 unknown) apache_1.3.22 php-4.1.0RC5 expat-1.95.2 Sablot-0.71 PHP config: ./configure \ --with-apache=../apache_1.3.22 \ --with-mysql=/usr/local/mysql \ --with-gd=/usr/local \ --with-freetype-dir=/usr/local \ --with-jpeg-dir=/usr \ --with-png-dir=/usr \ --with-zlib \ --with-openssl \ --with-curl \ --enable-xslt \ --with-xslt-sablot \ --enable-sysvsem \ --enable-sysvshm \ --enable-track-vars \ --enable-memory-limit \ --enable-debug=yes Apache config: EAPI_MM=../mm-1.1.3 \ SSL_BASE=/usr \ ./configure \ --with-layout=Apache \ --prefix=/usr/local/apache \ --enable-module=rewrite \ --enable-module=ssl \ --add-module=/root/downloads/mod_gzip.c \ --activate-module=src/modules/php4/libphp4.a Edit this bug report at http://bugs.php.net/?id=14381edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail:
[PHP-DEV] PCRE 3.7
Just learned on www.pcre.org that PCRE 3.7 is out. PHP comes bundled with PCRE 3.4, so we might want to upgrade, won't we? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] location of ext/phpdoc
Can someone please make decision where the phpdoc extension should be located at ? I just wanted to apply some patches to make it work with the latest php and failed I have only karma for php4/ext/phpdoc which has been moved to pear/PECL/phpdoc. But I don't have enough karma for pear/PECL/phpdoc. Jan -- mailto: [EMAIL PROTECTED] weigon @ #php.de (IRCnet) http://jan.kneschke.de weigon @ #modlogan (openprojects) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14474 Updated: Apache PHP Module cannot seem to handle large amounts of output
ID: 14474
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: Windows XP Pro/Linux
PHP Version: 4.1.0
New Comment:
I don't think that our current analysis is correct. Take a look at the access log -
I'm pretty sure you'd see that the page is being repeatedly requested by IE, and not
requested only once.
Something about the way the server disconnects may cause IE to think that the page was
not properly fetched, and make it try to reload it. That would be my guess...
Previous Comments:
[2001-12-14 12:57:09] [EMAIL PROTECTED]
I think this is critical
[2001-12-12 20:33:45] [EMAIL PROTECTED]
This problem reveals a memory limit bailout problem.
Even if PHP exhsusted memory, script does not exit.
PHP logs following logs many times. (Linux/PHP4.1.0, without output buffering)
[13-Dec-2001 10:27:52] PHP Fatal error: Allowed memory size of 8388608 bytes
exhausted (tried to allocate 10240 bytes) in
/home/yohgaki/public_html/bugs/14474/bug.php on line 4
Type is changed to Scripting Engine Problem.
[2001-12-12 19:28:49] [EMAIL PROTECTED]
Note: this seems to be the same problem as #14222, but I can't seem to append stuff to
someone elses bug so...
This is something I first noticed when I upgraded from XP RC1 to WinXP Final, when
using PHP 4.0.6. I upgraded to 4.1.0 today, and it doesn't solve the problem.
The php apache module doesn't seem able to handle outputting moderate to large sized
pages.
I have been able to reliably reproduce the problem with the following script:
?PHP
set_time_limit(900);
for ($i = 0; $i100; $i++){
print This is line number . ($i+1) . br;
}
?
Viewing this page with internet explorer causes it to go into an almost endless loop
of relaoding the page. It will display the first few 'this line is number...' and
then will reload the page over and over. On some sessions IE will eventually show
it's 'The page cannot be displayed' page, and sometimes it will just reload
indefinitly.
Viewing this page with Mozilla/Netscape doesn't have the same effect. Mozilla doesn't
go through the reload loop, but will not show the page as it should either. There
will be unexplained (no errors) jumps in numbers/missing output such as:
This is line number 2368
This is line number 2369This is line number 2517
This is line number 2518
But the errors in output don't occur in the same spot each time. And evenutally (well
short of 1,000,000 lines) the output will just stop with no error, often in mid line.
I have found that adding 'flush();' just after the 'print This is line...' seems to
fix the problem.
Edit this bug report at http://bugs.php.net/?id=14474edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14489 Updated: DSO PHP module compiling with gettext support is blocking Apache start
ID: 14489 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: Cobalt Raq 3 PHP Version: 4.1.0 New Comment: Strace with working libphp4.so http://michal.no-ip.com/~michal/ok.txt Strace with NO working libphp4.so http://michal.no-ip.com/~michal/bad.txt Previous Comments: [2001-12-14 10:52:00] [EMAIL PROTECTED] Of course Apache is working. It's RPM version from original Cobalt distribution. Simply: just Apache IS working Apache + PHP 4.1.0 as DSO IS working Apache + PHP 4.1.0 as DSO --with-gettext IS NOT working (see previous comment) Strange is that I can't see any error report. From console it seems Apache is running , but it's NOT. Even more strange it is printing slightly other messages during APache 'Start'. Thank You [2001-12-13 23:06:19] [EMAIL PROTECTED] Does you apache work without PHP ? --Jani [2001-12-13 12:27:33] [EMAIL PROTECTED] I forgot this : Apache/1.3.6 (Unix) And I used RPM of gettext-0.10.35 and I've also tried to compile version 0.10.40 with same result [2001-12-13 11:55:19] [EMAIL PROTECTED] Hello When I configure PHP with these options (including gettext support): ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/sbin/apxs --with-gd=/usr/local --with-jpeg-dir=/usr/local/src/jpeg-6b --with-png-dir=/usr/local --with-zlib=/usr/local --enable-ftp --enable-trans-sid --with-imap=/usr/local --enable-safe-mode --with-gettext=/usr Everything is fine (including configuration output and no errors or warnings on compiling) until I try to copy libphp4.so over old one and restart Apache. Usualy when I'm restarting apache I can see this: Shutting down Web Service: httpd Setting up Web Service: Site home has invalid certificate: 4999 Certificate files do not exist. Site site7 has invalid certificate: 4999 Certificate files do not exist. /usr/sbin/httpd but whe I try to restart Apache after module changing I can see this: Shutting down Web Service: httpd Setting up Web Service: Site home has invalid certificate: 4999 ssl_cant_files_missing Site site7 has invalid certificate: 4999 ssl_cant_files_missing /usr/sbin/httpd You can see some messages changed and Apache is NOT running. But When I don't include --with-gettext option evrything is running fine and Apache is running too, whith messages as in the first case. Edit this bug report at http://bugs.php.net/?id=14489edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14485 Updated: Please help me.
ID: 14485 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows 2000 Server Old PHP Version: 4.1.0 PHP Version: 4.0.2 New Comment: What is bc_num? Previous Comments: [2001-12-13 09:11:51] [EMAIL PROTECTED] Those file are available from a zip names win32build.zip and its mentioned somewhere int eh PHP FAQ (or install). There's no spoon - Bogus. [2001-12-13 07:49:47] [EMAIL PROTECTED] I want to rebuild PHP 4.1.0 with VC++, but I need some C++ head files(.h), for example: arpa/*.h and netinet/*.h and other head files. Can you help me? Edit this bug report at http://bugs.php.net/?id=14485edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14518 Updated: --enable-trans-id doesn't work
ID: 14518 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Session related Operating System: LInux 2.4.16 (RH7.2 based) PHP Version: 4.1.0 New Comment: Can anybody else reproduce this on *4.1.0*? Previous Comments: [2001-12-14 20:38:46] [EMAIL PROTECTED] Just note: I can not reproduce this with latest CVS. [2001-12-14 12:48:23] [EMAIL PROTECTED] I suppose you've verified problem ;) Type = Critical [2001-12-14 11:35:41] [EMAIL PROTECTED] I compiled php4.1.0 with --enable-trans-id, configured to use no cookies for sessions. Verifiying with phpinfo() shows the correct settings for cookies and enable-trans-id but php fails to add the session-id to any tag. Passing a session-id manually works though. Edit this bug report at http://bugs.php.net/?id=14518edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14485 Updated: Please help me.
ID: 14485 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows 2000 Server PHP Version: 4.0.2 New Comment: What is bc_num? Previous Comments: [2001-12-15 11:38:58] [EMAIL PROTECTED] What is bc_num? [2001-12-13 09:11:51] [EMAIL PROTECTED] Those file are available from a zip names win32build.zip and its mentioned somewhere int eh PHP FAQ (or install). There's no spoon - Bogus. [2001-12-13 07:49:47] [EMAIL PROTECTED] I want to rebuild PHP 4.1.0 with VC++, but I need some C++ head files(.h), for example: arpa/*.h and netinet/*.h and other head files. Can you help me? Edit this bug report at http://bugs.php.net/?id=14485edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13078 Updated: register_globals = off session.save_handler = user
ID: 13078
Updated by: derick
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Session related
Operating System: FreeBSD 4.x
PHP Version: 4.0.6, 4.1.0
New Comment:
This is fixed in php 4.2.0dev.
Derick
Previous Comments:
[2001-12-14 03:40:27] [EMAIL PROTECTED]
Closing. (I don't mean warning message patch is committed ;)
If anyone who has karma for session module liked it, it will be committed.
[2001-12-14 02:56:04] [EMAIL PROTECTED]
It is bug in your session handler, but PHP should not behave that way.
[2001-12-14 02:52:59] [EMAIL PROTECTED]
Closing then...
[2001-12-14 01:45:54] [EMAIL PROTECTED]
Sorry, but further testing revealed when sess_read
return NULL;
for when nothing was found caused problems sometimes, not always!
However
return '';
seems to work all of the time!
Looks like sess_write has to return a '' (null string) It cannot return NULL, nor it
return false;
Otherise sess_write will never be called!
---ends---
[2001-12-14 00:19:21] [EMAIL PROTECTED]
Problem solved in 4.1.0 (release).
All thanks to [EMAIL PROTECTED] for pointing me to his very well written code!
I found the reason my sess_write was never called with register_globals = off was
because my sess_read function was something like this:
sess_read( $key)
...
if I find stuff for $key from PostgreSQL {
return $valuesfound;
}
else {
return false;
}
The problem was with return false;
After changing:
return false;
to
return NULL;
things worked.
Don't know why the return false worked with register_globals=on and
register_global=off requires sess_read to return NULL if nothing was found...
THANKS again to [EMAIL PROTECTED] for his code and my apologise for wasting people's
time.
Please feel free to close this bug report. I am not closing it because [EMAIL PROTECTED]
brought up something which I don't know about nor can I duplicate.
---ends---
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/?id=13078
Edit this bug report at http://bugs.php.net/?id=13078edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 3.0 Bug Summary Report
PHP 3.0 Bug Database summary - http://bugs.php.net Num Status Summary (539 total including feature requests) ===[*General Issues]== 4180 Open is_link returns false when target doesnt exist (should return true) 9610 Bogus Dead link 9820 Open File upload with any input tag 10101 Bogus apache + mysqld + php3 == libphp3.so incorrect symbol... 10457 Bogus ALKHOBAR ===[*Install and Config]== 7386 Feedback referenced symbol not found when starting Apache ===[Compile Failure]== 1145 Open Ypu cannot compile with --with-ldap using the Solaris7 bundled ldap-libs/header 1298 Open need to use -taso with Netscape LDAP libs 1461 Open won't compile with Stronghold 2.2 or 2.3 1933 Open Unable to compile PHP3 with Oracle8 support 1997 Open Compilation Problems 2225 Open Compile error in ldap.c 2282 Open Compile failure with Stronghold 2.4.1 2490 Open Perl regular expression functions not available in windows binary 2585 Open Error linking Oracle 7.3.2 libraries on SCO OpenServer 5.0.4 2658 Open error while compiling PHP as apache module 2729 Open Fatal error: Unable to open ??? in - on line 0 2751 Open Storage size of buf isn't known 2823 Open undefined symbol: SQLParamData 2824 Open Inconsistent parameter list declaration for... 2903 Open fails to compile ifx.ec, report a syntax-error 3033 Open Fatal compile error on functions/ldap.c 3185 Open Undefined symbol 3217 Open ld error when compiling as Apache DSO and --with-mysql 3218 Open Can't compile php_ftp.dll 3426 Open make with iodbc failed and I've found the problem 3501 Open Compiling errors with Oracle-Funktions 3528 Open Can't compile php 3.0.14 with Oracle support 3677 Open files not found 3766 Open configure doesn't allow for the Oracle N32 client SDK to be used 3776 Open functions/db.c:107: parse error before '*' 4028 Open wrong directories included for oracle 8.1.6 4217 Open IBM DB2 will not compile. 4233 Open The Interbase module won't compile. 4266 Open Undeclared variables in function/imap.c starting ar line 435 4392 Open Compile failure with GD 1.7, possibly others 4412 Open xml failure 4417 Open Informix specific parse error in functions/ifx.ec 4544 Open Incompatiblility with latest (3.0) version of PDFlib 4899 Open PHP Core Dumps With Apache 1.3.12 7734 Open missing php3_ifx.h ===[Compile Warning]== 3151 Open php.exe compile warnings because of arpa/inet.h 6942 Open php sockets unusable with irix-OS ===[dBase related] 3091 Open dbase_replace_record miscounts number of fields 3429 Open Warning: Unable to open database... 4802 Open php.exe crashes while trying to execute the get_record function ===[DBM/DBA related]== 2890 Open DBM extension on win32 does not valid database identifier error 3371 Open dbmfetch reurns an empty string 3423 Open dbmopen() not thread-safe 3809 Duplicate DBM extension for Win32 PHP3 is malfunctioning and/or has a flaw 3862 Open dbmReplace dbmDelete return inverse value 6720 Open persistent Warning: driver initialization failed on db_open db2 2.7.7 ===[Documentation problem] 11155 Bogus bogus report ===[Dynamic loading related]== 1188 Open Configuration not work 1586 Open In the compiled Win32 package, the php3_ldap doesn't load. 1993 Open Startup failure of liphp3.so 2027 Open Can't dynamicly load any extension dll file 2250 Open nt-service problem 2414 Open php3_vmailmgr.so refuses to load 2862 Open LDAP in Win32 Bin dist is linked to MSVCRTD.DLL 3168 Open cannot start apache 1.3.9 if mysql is compiled in, but can RESTART successfully 3292 Open MySQL module causes DSO to fail. 3321 Open Apache Complaining about undefined symbol: dlst_first 3659 Open mod_php + apache w/mod_so hangs in sched_yield 3680 Open Apache won't start after install php3 3752 Open Apache configtest dumps core with DSO versioning 3781 Open Cannot load /libexec/libphp3.so 3861 Open php as a dyn. mod. configured with IBM db2 support prevents svr startup 9565 Open php3_ldap.dll is compiled as DEBUG ===[Feature/Change Request]=== 2393 Open Can't use parse_url for url validation ===[IMAP related]= 2816 Open
[PHP-DEV] PHP 4.0 Bug Summary Report
PHP 4.0 Bug Database summary - http://bugs.php.net
Num Status Summary (1582 total including feature requests)
===[*Configuration Issues]
13561 Suspended --without-pear prevent install of php-config,phpize,...
14048 Open Configure issues
14120 Open libtool needs help.
14230 Open configure fail cross-compiler check with gcc 3.0.1
14401 Open Wrong include_path from Apache Directory config
14452 Open libphp4.so is not linking with *.la files
===[*Database Functions]==
12384 Open Can't connect to Ingres II
===[*Directory/Filesystem functions]
12004 Analyzed problem with fopen over ftp and a related fgets
12783 Open xmlDocFile needs absolute path
13764 Open No error in filename.phtml
14049 Open Inconsistent return in realpath
14076 Open fopen() and touch() fail to create file under safe mode
14100 Open Unicode Filenames
===[*General Issues]==
8506 Duplicate CGI PHP doesn't erase the #!/path/to/php
8782 Duplicate scripts run from CGI output #!/usr/local/bin/php line
8898 Duplicate #!/path/php at top of CGI script appears in output (Netscape
Enterprise Server)
9041 Analyzed Extra #! at top of web output.
9096 Duplicate #! line in a script is outputed in script
10062 Duplicate CGI version displays '#!/usr/local/bin/php' line
11471 Duplicate #!/usr/local/bin/php on top of all PHP pages
11503 Duplicate display #!/usr/local/bin/php on first line with boa webserver
13729 Duplicate PHP Outputs #! line
13737 Duplicate #!/usr/local/bin/php shell script line is shown first at the result
page
13818 Open safe mode wrong uid -1
14170 Duplicate #!/path/to/php shows up on every php script
14200 Open remote navigation problem
===[*Graphics related]
13508 Open read exif data not working on large thumbnails
14026 Open read_exif_data cannot read Ricoh DC jpg
===[*Languages/Translation]===
11244 Open Reversed '[]{}' in hebrev, hebrevc
11975 Open mix of hebrew english
13014 Open hebrevc ()
14235 Open serialize and setlocale: inconsistent behavior
===[*Mail Related]
14292 Open Bare LF Issue - This time with DETAIL!
===[*Web Server problem]==
7641 Open cgi binary with enable-discard-path fails with empty doc_root value
===[*XML functions]===
14521 Open XMLRPC extension: wrong results?
===[Apache related]===
8865 Open App launching with hotkeys delayed
8866 Open Frozen applications with apache module running
9280 Open HTTP/1.1 Expect: header not honoured
9422 Open Apache hangs when Win goes to standby
10060 Open startup error msg format
10075 Open Exta path information beyond the PHP script won't work with CGI
11690 Duplicate apxs does not support -S
11716 Open Segmentation fault(coredump) in Apache(DSO-enabled) startup
12210 Open DirectoryMatch/php_value/.htaccess
12683 Open Safe mode (apache with mod_perl) uses incorrect uid
12992 Open php ignores Accept: text/vnd.wap.wml
13035 Open 404 on a .php results in SERVER ERROR when using php as a cgi
13178 Duplicate make install fails on cobalt RAQIII.
13420 Open open_basedir breaks Apache SSI xbithack
13421 Open Problematic MIME-Type application/x-httpd-php
13925 Analyzed SCRIPT_NAME in Apache 1.3.22 wrong (or at least different)
13956 Open improve robustness against bad signal(2) et al. calls from third
party libs
13961 Assigned some characters in incomonig variable names are silently changed
13964 Open core dump on AIX 4.3.2
13982 Open set_time_limit (ref #13711) and ignore_user_abort affects later
requests
14222 Open PHP Crashes with weird output often
14229 Open function virtual
14245 Assigned make install fails on apxs
14265 Open Make does not create php4lib.so. Apxs fails to copy it to apache dir
14333 Feedback Apache processes consume all CPU
14348 Open Major PHP memory corruption? (with testcase)
14351 Open problems installing PHP as a DSO
14358 Open crash with large numbers of ouput blocks
14370 Open PHP_AUTH_PW being improperly set
14409 Open request for nonexistent file does not return 404 error
14489 Open DSO PHP module compiling with gettext support is blocking Apache start
14504 Feedback core dump in session handling
14515 Open child pid XXX exit signal Segmentation fault (11)
14534 Open Variables $PHP_AUTH_* is set, when use
[PHP-DEV] Bug #14518 Updated: --enable-trans-id doesn't work
ID: 14518 Updated by: cmk Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Session related Operating System: LInux 2.4.16 (RH7.2 based) PHP Version: 4.1.0 New Comment: I can not reproduce this with 4.1.0 Previous Comments: [2001-12-15 11:46:59] [EMAIL PROTECTED] Can anybody else reproduce this on *4.1.0*? [2001-12-14 20:38:46] [EMAIL PROTECTED] Just note: I can not reproduce this with latest CVS. [2001-12-14 12:48:23] [EMAIL PROTECTED] I suppose you've verified problem ;) Type = Critical [2001-12-14 11:35:41] [EMAIL PROTECTED] I compiled php4.1.0 with --enable-trans-id, configured to use no cookies for sessions. Verifiying with phpinfo() shows the correct settings for cookies and enable-trans-id but php fails to add the session-id to any tag. Passing a session-id manually works though. Edit this bug report at http://bugs.php.net/?id=14518edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14256 Updated: libphp4.la Won't Compile on OS X v10.1
ID: 14256 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Duplicate Bug Type: Compile Failure Operating System: Mac OS X PHP Version: 4.1.0 New Comment: Dup of #14483 Previous Comments: [2001-11-27 13:13:19] [EMAIL PROTECTED] Mac OS X 10.1 development tools default to a two-level namespace, whereas 10.0 tools defaulted to a flat namespace. A discussion of this problem (and one solution, maybe) is posted on Mark Liyanage's site at http://www.entropy.ch/software/macosx/php/. I used the trick explained here to get around a problem building where I got complaints that the -undefined flag used in the configure script was incorrect for two-level namespace. However, when I try to use the --with-apxs flag with the configure script I still can't compile. I have been trying to build a shared object version of RC3 and I only get a little farther in the process until I get another error about multiply-defined symbols when linking libphp4.la. Edit this bug report at http://bugs.php.net/?id=14256edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14358 Updated: crash with large numbers of ouput blocks
ID: 14358 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Critical Bug Type: Apache related Operating System: win32 (2k/xp) PHP Version: 4.0CVS-2001-12-06 Edit this bug report at http://bugs.php.net/?id=14358edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14453 Updated: session_start() provokes a crash of php/apache
ID: 14453 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Critical Bug Type: Session related Operating System: win2k PHP Version: 4.1.0 Previous Comments: [2001-12-12 08:37:28] [EMAIL PROTECTED] ? session_start(); ? this script will cause php/apache to crash. used configuration: php 4.10 / win32 as SAPI apache 1.3.20 / win32 unfortunately, I don't have the time now to further investigate the problem... please contact me if there are any workarounds / solutions for this problem! regards n. fankhauser Edit this bug report at http://bugs.php.net/?id=14453edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14483 Updated: -twolevel_namespace and multiple definitions errors
ID: 14483 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Critical Bug Type: Compile Failure Operating System: Mac OS X 10.1 PHP Version: 4.2.0-dev Previous Comments: [2001-12-14 17:26:57] [EMAIL PROTECTED] It's friday niiigghttt... Doing: grep -nrH \*yytext Zend/* Yields: - zend_ini_scanner.c:310:extern char *yytext; zend_ini_scanner.c:496:char *yytext; zend_language_scanner.c:305:extern char *yytext; zend_language_scanner.c:2725:char *yytext; - So: pico -b -e -w +2725 zend_language_scanner.c Comment out: /* char *yytext; */ We are money because this is already declared as a extern in zend_ini_scanner or whatever. Now the compile completes, but everything is still hosed, because make install gives: Making install in . apxs -i -a -n php4 libs/libphp4.so [activating module `php4' in /private/etc/httpd/httpd.conf] cp libs/libphp4.so /usr/libexec/httpd/libphp4.so cp: libs/libphp4.so: No such file or directory apxs:Break: Command failed with rc=1 make[1]: *** [install-sapi] Error 1 make: *** [install-recursive] Error 1 Arg... [2001-12-14 16:59:25] [EMAIL PROTECTED] Progress: [Just downloaded and compiled the latest GNU autoconf, automake, and libtool] After some further web research, most of it comes down to being a libtool issue, which is covered here: http://savannah.gnu.org/support/?func=detailsupportsupport_id=100049group_id=25 It all begins with replacing all instances of: deplibs=$lib $deplibs with if test $libdir; then deplibs=$lib $deplibs fi in ltmain.sh, and if configure has already been run, in libtool. There three occurrences in ltmain.sh. The reason sh!t is multiply defined is because it's multiply loaded. The above helps. This gets rid of the all of the multiple defined error messages except: - ld: multiple definitions of symbol _yytext Zend/.libs/libZend.al(zend_language_scanner.lo) definition of _yytext in section (__DATA,__common) Zend/.libs/libZend.al(zend_ini_scanner.lo) definition of _yytext in section (__DATA,__common) /usr/bin/libtool: internal link edit command failed make[1]: *** [libphp4.la] Error 1 make: *** [all-recursive] Error 1 - This is being attacked... more later... hopefully. Also, I noticed main/php_config.h defines 'uint' even though /usr/include/sys/types.h already has 'uint'. sys/types.h does't define ulong, thought. In php_config.h 'uint' is defined twice, once right at the top and again on line 1836. 'ulong' is also defined, but that's OK. This does not hose anything, only it doesn't allow use of the precompiled version of the system's unistd.p. Changing php_config.h, starting at line 1836 (or near there): from - /* Define to `unsigned int ' if sys/types.h does not define. */ #define uint unsigned int /* Define to `unsigned long ' if sys/types.h does not define. */ #define ulong unsigned long to - /* Define to `unsigned int ' if sys/types.h does not define. */ /* #define uint unsigned int */ /* Define to `unsigned long ' if sys/types.h does not define. */ #define ulong unsigned long - and commenting out these two lines near the top, on line 9, so they appear as follows: - /* #define uint unsigned int */ /* #define ulong unsigned long */ - Fixes this stuff. That leaves me with only the _yytext multiple defined errors, and two or three cpp smart preprocessing warnings. Almost there... [2001-12-14 16:37:55] [EMAIL PROTECTED] [2001-12-13 07:18:30] [EMAIL PROTECTED] Also a duplicate of bug 14154, which is a freakin' struggle of a bug. [2001-12-13 07:08:12] [EMAIL PROTECTED] (NOTE: Duplicate of BUG 14256) PHP 4.1.0 fails to compile on Mac OS X 10.1 (you probably already know this). This is while building the Apache Module. Notes: - First scenario: attempting the run-of-the-mill compile fails once it gets to ld, which throws out -twolevel_namespace warnings. - Second scenario: Modifying (by adding -flat_namespace) any presence of anything that may seem like a compiler flag or linker flag in config_vars.mk, php_config.h, libtool, etc., leads to a LARGE number of multiple definition errors that look like this: --- TSRM/.libs/libtsrm.al(tsrm_virtual_cwd.lo) definition of _virtual_utime in section (__TEXT,__text) TSRM/.libs/libtsrm.al(tsrm_virtual_cwd.lo) definition of _virtual_utime in section (__TEXT,__text) These errors flow in large quantities (in pairs like above), right at the end of the compile. The section
[PHP-DEV] Bug #14515 Updated: child pid XXX exit signal Segmentation fault (11)
ID: 14515
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Critical
Bug Type: Apache related
Operating System: linux 2.4.16
PHP Version: 4.1.0
Previous Comments:
[2001-12-15 08:23:37] [EMAIL PROTECTED]
The only way to get some output was starting the apache inside gdb. I got the
following:
(gdb) run -X -f /usr/local/apache/conf/httpd.conf
Starting program: /usr/local/apache/bin/httpd -X -f /usr/local/apache/conf/httpd.conf
[New Thread 1024 (LWP 7109)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 7109)]
0x40a0e333 in php_pcre_replace (regex=0x40ab8b11 /realm=\(.*?)\/i, regex_len=16,
subject=0x8184455 Basic realm=\DB-RW-Access\, subject_len=27,
replace_val=0x81844a4,
is_callable_replace=0, result_len=0xbfffc19c, limit=-1) at php_pcre.c:768
768 if ('\\' == *walk || '$' == *walk) {
(gdb)
[2001-12-14 18:41:15] [EMAIL PROTECTED]
Could you provide backtrace?
http://bugs.php.net/bugs-generating-backtrace.php
Please read how to report bug link also.
[2001-12-14 09:23:20] [EMAIL PROTECTED]
Hi, when i try to run the following code, my apache goes banana (child pid XXX exit
signal Segmentation fault (11) in the error_log)
?php
if(!isset($PHP_AUTH_USER)) {
Header(WWW-Authenticate: Basic realm=\DB-RW-Access\);
Header(HTTP/1.0 401 Unauthorized);
echo Get lost\n;
exit;
}
else {
$dbid = $PHP_AUTH_USER;
$dbpw = $PHP_AUTH_PW;
}
phpinfo();
exit;
php-compile-time-options:
'./configure' '--prefix=/usr/local/php-4.1.0'
'--with-apxs=/usr/local/apache/bin/apxs'
'--enable-force-cgi-redirect'
'--with-config-file-path=/usr/local/apache/conf' '--with-openssl'
'--with-bz2'
'--with-imap'
'--with-gdbm'
'--enable-ftp'
'--with-gd'
'--enable-gd-native-ttf' '--with-oci8=/opt/oracle/app/oracle/product/8.1.7'
'--with-mysql=/usr'
'--enable-sigchild'
'--with-mm'
'--enable-rule=EAPI'
apache-version: 1.3.20
Any clue?
Regards,
Martin
Edit this bug report at http://bugs.php.net/?id=14515edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14048 Updated: Configure issues
ID: 14048 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: BSD/OS 4.x PHP Version: 4.1.0 New Comment: Of course it was the last extension - in this case GD. BSDi 4.2 now comes with both a shared zlib as a shared Jpeg. The zlib is ok, but I've made a jpeg 6.2 of my own. There are a number of issues now surfacing, so should I open a new report on GD/BSDi 4.2 for these (HUP signal doesn't work anymore, linking with 2 libraries installed, makes it core dump)? Remaining for this report: 1) incorrect detection of HAVE_RES_SEARCH braking getmxrr and other DNS related functions, work-around: $ diff -c php_config.h.in php_config.h.in.dist *** php_config.h.in Fri Dec 14 21:13:55 2001 --- php_config.h.in.distFri Dec 14 15:06:29 2001 *** *** 1894,1903 #define zend_finite(a) (zend_isnan(a) ? 0 : zend_isinf(a) ? 0 : 1) #endif - #ifdef __bsdi__ - #define HAVE_RES_SEARCH 1 - #endif - /* * Local variables: * tab-width: 4 --- 1894,1899 I have provided an example of how bind-9.x detects this function. 2) Release versions need a fix of the include statements in various files, since the old make syntax is used, for BSDi's system provided make, instead of the make preferred in the PATH and/or specified by $MAKE. This does not apply to snapshots. Previous Comments: [2001-12-15 06:43:11] [EMAIL PROTECTED] Those yacc warnings are harmless. [2001-12-15 05:37:28] [EMAIL PROTECTED] Ok, working on it. 2 notes on this build: I get a lot of yacc warnings like these: /usr/src/web/php/php4/ext/standard/var_unserializer.re:273: warning: label `yy1' defined but not used And the XtOffsetOf is redefined: In file included from /apbeta/include/httpd.h:72, from sapi_apache.c:32: /apbeta/include/ap_config.h:1367: warning: `XtOffsetOf' redefined [2001-12-14 21:23:50] [EMAIL PROTECTED] So with the minimum options everything works just fine? If so, then please try adding some more options and see when it starts to fail. --Jani [2001-12-14 15:40:06] [EMAIL PROTECTED] Ok, you can rule that out. Compiles outof the box. Build php4-200112140600. [2001-12-13 21:41:38] [EMAIL PROTECTED] Please try the latest CVS snapshot with this configure line: --with-apxs=/apache/bin/apxs --without-mysql --disable-pear --disable-xml --disable-session --enable-debug As I first want to rule out any extension being the reason for the segfault. --Jani 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/?id=14048 Edit this bug report at http://bugs.php.net/?id=14048edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14535: Mail function always returns false
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.1-RELEASE i386 PHP version: 4.0.6 PHP Bug Type: Mail related Bug description: Mail function always returns false This is to confirm the bug reported in Bug ID #14032 PHP Apache Module Versions 4.0.4, 4.0.6 FreeBSD 4.1 Installed on a virtual server at Verio The script below runs fine on my WinNT/IIS development server running PHP 4.0.4 as a CGI module. On the FreeBSD virtual server, the same script always returns false, even though the mail message has been sent successfully. Could it be a problem with how sendmail running on FreeBSD is responding (or not responding) to the mail() function? === ?php error_reporting(E_ALL); $mail_to = '[EMAIL PROTECTED]'; $mail_subject = 'Test Email'; $mail_message = 'This is a test'; $mail_headers = From:[EMAIL PROTECTED]\nReply-To:[EMAIL PROTECTED]\n; $sent = TRUE; $sent = mail($mail_to,$mail_subject,$mail_message,$mail_headers); if ( $sent == TRUE ) print(Mail sent successfully); else print(Mail was not sent); ? -- Edit bug report at: http://bugs.php.net/?id=14535edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14536: session_unregister not unregistering sessions
From: [EMAIL PROTECTED]
Operating system: debian 2.2.19pre17
PHP version: 4.1.0
PHP Bug Type: Session related
Bug description: session_unregister not unregistering sessions
starting session with session_register..
The session variable will display.. but after calling the
session_unregister command... the session variable still remains...
?
session_start();
if($page == ){
$test = hello;
session_register(test);
}
elseif($page==u){
session_unregister(test);
}
else
{
echo $test;
}
?
--
Edit bug report at: http://bugs.php.net/?id=14536edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14536 Updated: session_unregister not unregistering sessions
ID: 14536
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Session related
Operating System: debian 2.2.19pre17
PHP Version: 4.1.0
New Comment:
ZEND_DEBUG = disabled
This program makes use of the Zend Scripting Language Engine:
Zend Engine v1.1.0, Copyright (c) 1998-2001 Zend Technologies
Previous Comments:
[2001-12-15 13:11:06] [EMAIL PROTECTED]
What is the version of the Zend Engine, as shown by the output of phpinfo(); ?
Derick
[2001-12-15 13:08:46] [EMAIL PROTECTED]
starting session with session_register..
The session variable will display.. but after calling the session_unregister
command... the session variable still remains...
?
session_start();
if($page == ){
$test = hello;
session_register(test);
}
elseif($page==u){
session_unregister(test);
}
else
{
echo $test;
}
?
Edit this bug report at http://bugs.php.net/?id=14536edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14489 Updated: DSO PHP module compiling with gettext support is blocking Apache start
ID: 14489 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Apache related Operating System: Cobalt Raq 3 PHP Version: 4.1.0 New Comment: What if you 'stop' and 'start' it instead of 'restart' ? Previous Comments: [2001-12-15 11:31:35] [EMAIL PROTECTED] These Straces are for command /httpd restart [2001-12-15 11:29:36] [EMAIL PROTECTED] Strace with working libphp4.so http://michal.no-ip.com/~michal/ok.txt Strace with NO working libphp4.so http://michal.no-ip.com/~michal/bad.txt [2001-12-14 10:52:00] [EMAIL PROTECTED] Of course Apache is working. It's RPM version from original Cobalt distribution. Simply: just Apache IS working Apache + PHP 4.1.0 as DSO IS working Apache + PHP 4.1.0 as DSO --with-gettext IS NOT working (see previous comment) Strange is that I can't see any error report. From console it seems Apache is running , but it's NOT. Even more strange it is printing slightly other messages during APache 'Start'. Thank You [2001-12-13 23:06:19] [EMAIL PROTECTED] Does you apache work without PHP ? --Jani [2001-12-13 12:27:33] [EMAIL PROTECTED] I forgot this : Apache/1.3.6 (Unix) And I used RPM of gettext-0.10.35 and I've also tried to compile version 0.10.40 with same result 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/?id=14489 Edit this bug report at http://bugs.php.net/?id=14489edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] change to cvs access control
in the continuing effort to make things a little easier for those of us who have to deal with administering things for the php project, i've rejiggered the way the cvs access control works a little bit. nobody should have lost access to anything they had access to before, but if you find yourself getting the old 'insufficient karma' message, just drop a note to [EMAIL PROTECTED] and we'll sort things out post-haste. apologies in advance for any inconvenience. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14483 Updated: -twolevel_namespace and multiple definitions errors
ID: 14483 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Compile Failure Operating System: Mac OS X 10.1 PHP Version: 4.2.0-dev New Comment: Are you talking about commenting out the yytext... Is this a libtool bug? Seems like somebody on AIX is having a similar problem. http://bugs.php.net/bug.php?id=14245 In the Mac OS X situation, though... it seems to be a threefold problem... 1. ltmain.sh (due to multiple symbol errors) 2. yytext issue 3. apxs issue Previous Comments: [2001-12-15 07:33:10] [EMAIL PROTECTED] That commenting out should not be nessecairy, I have the same on my system. The problem is something else... Derick [2001-12-14 17:26:57] [EMAIL PROTECTED] It's friday niiigghttt... Doing: grep -nrH \*yytext Zend/* Yields: - zend_ini_scanner.c:310:extern char *yytext; zend_ini_scanner.c:496:char *yytext; zend_language_scanner.c:305:extern char *yytext; zend_language_scanner.c:2725:char *yytext; - So: pico -b -e -w +2725 zend_language_scanner.c Comment out: /* char *yytext; */ We are money because this is already declared as a extern in zend_ini_scanner or whatever. Now the compile completes, but everything is still hosed, because make install gives: Making install in . apxs -i -a -n php4 libs/libphp4.so [activating module `php4' in /private/etc/httpd/httpd.conf] cp libs/libphp4.so /usr/libexec/httpd/libphp4.so cp: libs/libphp4.so: No such file or directory apxs:Break: Command failed with rc=1 make[1]: *** [install-sapi] Error 1 make: *** [install-recursive] Error 1 Arg... [2001-12-14 16:59:25] [EMAIL PROTECTED] Progress: [Just downloaded and compiled the latest GNU autoconf, automake, and libtool] After some further web research, most of it comes down to being a libtool issue, which is covered here: http://savannah.gnu.org/support/?func=detailsupportsupport_id=100049group_id=25 It all begins with replacing all instances of: deplibs=$lib $deplibs with if test $libdir; then deplibs=$lib $deplibs fi in ltmain.sh, and if configure has already been run, in libtool. There three occurrences in ltmain.sh. The reason sh!t is multiply defined is because it's multiply loaded. The above helps. This gets rid of the all of the multiple defined error messages except: - ld: multiple definitions of symbol _yytext Zend/.libs/libZend.al(zend_language_scanner.lo) definition of _yytext in section (__DATA,__common) Zend/.libs/libZend.al(zend_ini_scanner.lo) definition of _yytext in section (__DATA,__common) /usr/bin/libtool: internal link edit command failed make[1]: *** [libphp4.la] Error 1 make: *** [all-recursive] Error 1 - This is being attacked... more later... hopefully. Also, I noticed main/php_config.h defines 'uint' even though /usr/include/sys/types.h already has 'uint'. sys/types.h does't define ulong, thought. In php_config.h 'uint' is defined twice, once right at the top and again on line 1836. 'ulong' is also defined, but that's OK. This does not hose anything, only it doesn't allow use of the precompiled version of the system's unistd.p. Changing php_config.h, starting at line 1836 (or near there): from - /* Define to `unsigned int ' if sys/types.h does not define. */ #define uint unsigned int /* Define to `unsigned long ' if sys/types.h does not define. */ #define ulong unsigned long to - /* Define to `unsigned int ' if sys/types.h does not define. */ /* #define uint unsigned int */ /* Define to `unsigned long ' if sys/types.h does not define. */ #define ulong unsigned long - and commenting out these two lines near the top, on line 9, so they appear as follows: - /* #define uint unsigned int */ /* #define ulong unsigned long */ - Fixes this stuff. That leaves me with only the _yytext multiple defined errors, and two or three cpp smart preprocessing warnings. Almost there... [2001-12-14 16:37:55] [EMAIL PROTECTED] [2001-12-13 07:18:30] [EMAIL PROTECTED] Also a duplicate of bug 14154, which is a freakin' struggle of a bug. 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/?id=14483 Edit this bug report at http://bugs.php.net/?id=14483edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:
[PHP-DEV] Unbuffered fgetc needed for stdin
I've really run into a wall trying to get single charachters from stdin. Something similar to the getchar macro or a real fgetc would be nice. The current behavior is that more than a signle charachter can be typed and fgetc only returns when it sees a \n. I'd like it to return immediatly after the first charachter. fscanf with a format string something like %c requires a \n before returning as well, though I suppose that is more understandable. various things like fread with length of 1 also don't work. This is missing functionality for which there is no workaround that would certainly make shell scripting easier. It should be relativly trivial to implement, either an unbuffered fgetc option or a new function or something. -AZ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14529 Updated: script doesn't always finish output
ID: 14529 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Output Control Operating System: Linux RH 7.2 Old PHP Version: 4.1.0 PHP Version: 4.2.0-dev New Comment: Tried using the snap shot and it will no longer let me connect to my MySQL database so I couldn't run the page I've been doing the testing on. Did the format for mysql_connect change in this version? I can still connect to it from the Linux prompt itself so it's still running. In phpinfo() the section on mysql looks exactly the same except MYSQL_MODULE_TYPE (4.1.0 reports 'none' the 4.2.0-dev reports 'builtin') yet I used the same configure line (both used built in - I've never figured out how to get it to use the installed MySQL perhaps because it's installed from rpm files and library file just don't exist - but not too sure what I am supposed to be looking for there). Previous Comments: [2001-12-15 06:35:00] [EMAIL PROTECTED] Can you please try a snapshot from snaps.php.net, and see if it's fixed in the 4.2.0dev version? Thanx, Derick [2001-12-14 20:16:49] [EMAIL PROTECTED] Having a problem like in bug ID# 9836 but was unable to submit comments to that thread. scripts sometimes stops outputing part ways through. (No errors just an uncompleted page displayed). Regardless of how many refreshes it stops at exact same place. Some pages have very little code others have a lot so length doesn't seem to be the issue. I tried setting a session variable after an echo statement that did not fully display and on a reload it had taken the new value. This would suggest the script doesn't really stop, just the output of HTML being returned stops. As a side note the time the setting of a session variable was added below the lines not displaying, upon a refresh it not only showed me the variable was set but it displayed the whole page. Sure enough if I pulled the session variable out (nothing relative to the page at all), restart the session it's back to stopping at the exact same spot before - right in the middle of an echo statement such as: echo This is a sample; would only output: Thi (and that would be the last of the page) It is not timing out (runs in less than a second). But I have discovered if I set the following in php.ini it works perfectly: output_buffering = On (formally set to 'Off') You would think that with it set to On you'd have more chances of a cut off than with it Off Here is my config line (same as when I run PHP4.0.6 which doesn't repeat this problem). ./configure --with-apxs --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --prefix=/u sr --with-config-file-path=/etc --disable-debug --enable-pic --disable-rpath --enable-inline-optimization --with-bz2 --with-curf --with-db3 --with-exec-dir=/usr/bin --with-gd --with-gdbm --with-gettext -with-jpeg-dir=/usr --enable-trans-sid --with-openssl --with-png --with-regex=system --with-ttl --with-zlib --with-layout=GNU --enable-debugger --enable-ftp --enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-yp --enable-wddx --with-mysql --with-pgsql --without-unixODBC --without-oracle --without-oci8 --with-pspell --with-xml --with-pdf --with-cybercash I also am using Zend Optimizer (for 4.1.0) I should also point out that with PHP4.1.0 I can not use 'user' session handling (used MySQL to handle sessions in PHP4.0.6), now unless I turn it back to default 'files' it will not let me use old (session_register) or the new ($_SESSION['name']=)...though no errors occur the session just doesn't retrieve or store data anymore. I don't know if these two would be linked but I thought I'd bring it up Edit this bug report at http://bugs.php.net/?id=14529edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14537: fgetc fails to return single charachter immediatly
From: [EMAIL PROTECTED] Operating system: Linux 2.4.7-10smp i686 PHP version: 4.1.0 PHP Bug Type: Filesystem function related Bug description: fgetc fails to return single charachter immediatly fgetc should have at least the option of returning a single charachter immediatly upon its entry, or another function should be defined (such as getchar()) that achieves similar functionality to fgetc(stdin) which return a single charachter immediatly. The following script allows the user to type more than a single charachter and only returns when the user hits enter. fgetc should simply block until a single charachter is entered and then return. This is missing functionality that can not be worked around easily as far as I can tell. Script: $fp = fopen(php://stdin, r); $char = fgetc($fp); echo $char; -- Edit bug report at: http://bugs.php.net/?id=14537edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14474 Updated: Apache PHP Module cannot seem to handle large amounts of output
ID: 14474
Updated by: yohgaki
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: Windows XP Pro/Linux
PHP Version: 4.1.0
New Comment:
Probably, Zeev is right about regarding
[2001-12-12 20:33:45] [EMAIL PROTECTED]
update. Since I didn't see active httpd process.
httpd should close connection when PHP cannot execute script, anyway ;)
(I suppose httpd is not closing connection. With my IE under w2k, networks may become
ususable. Mozilla under linux halts. This is critical :)
More detailed analysys is required. Any volanteers?
Previous Comments:
[2001-12-15 11:20:23] [EMAIL PROTECTED]
I don't think that our current analysis is correct. Take a look at the access log -
I'm pretty sure you'd see that the page is being repeatedly requested by IE, and not
requested only once.
Something about the way the server disconnects may cause IE to think that the page was
not properly fetched, and make it try to reload it. That would be my guess...
[2001-12-14 12:57:09] [EMAIL PROTECTED]
I think this is critical
[2001-12-12 20:33:45] [EMAIL PROTECTED]
This problem reveals a memory limit bailout problem.
Even if PHP exhsusted memory, script does not exit.
PHP logs following logs many times. (Linux/PHP4.1.0, without output buffering)
[13-Dec-2001 10:27:52] PHP Fatal error: Allowed memory size of 8388608 bytes
exhausted (tried to allocate 10240 bytes) in
/home/yohgaki/public_html/bugs/14474/bug.php on line 4
Type is changed to Scripting Engine Problem.
[2001-12-12 19:28:49] [EMAIL PROTECTED]
Note: this seems to be the same problem as #14222, but I can't seem to append stuff to
someone elses bug so...
This is something I first noticed when I upgraded from XP RC1 to WinXP Final, when
using PHP 4.0.6. I upgraded to 4.1.0 today, and it doesn't solve the problem.
The php apache module doesn't seem able to handle outputting moderate to large sized
pages.
I have been able to reliably reproduce the problem with the following script:
?PHP
set_time_limit(900);
for ($i = 0; $i100; $i++){
print This is line number . ($i+1) . br;
}
?
Viewing this page with internet explorer causes it to go into an almost endless loop
of relaoding the page. It will display the first few 'this line is number...' and
then will reload the page over and over. On some sessions IE will eventually show
it's 'The page cannot be displayed' page, and sometimes it will just reload
indefinitly.
Viewing this page with Mozilla/Netscape doesn't have the same effect. Mozilla doesn't
go through the reload loop, but will not show the page as it should either. There
will be unexplained (no errors) jumps in numbers/missing output such as:
This is line number 2368
This is line number 2369This is line number 2517
This is line number 2518
But the errors in output don't occur in the same spot each time. And evenutally (well
short of 1,000,000 lines) the output will just stop with no error, often in mid line.
I have found that adding 'flush();' just after the 'print This is line...' seems to
fix the problem.
Edit this bug report at http://bugs.php.net/?id=14474edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Unbuffered fgetc needed for stdin
Doh... That's right. Stream input is usually buffered. Futzing with tty is pretty ugly I think (stty/ioctl)... On further reflection it seems that the getting a wrapper for ncurses or cdk would be a real nice win for PHP. Perl's got a cdk module, think Python has a ncurses wrapper. If they have reasonable license terms might be easy to use those as a starting point for a php wrapper. Wrapping these ncurses / cdk would be a nice add for PHP on the commandline. Unfortunatly don't have the time to attempt something like this. -AZ -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 15, 2001 1:34 PM To: August Zajonc; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Unbuffered fgetc needed for stdin This usually depends on how you configured your tty. I think by default it is buffered by the OS until a newline so it's probably not PHP which needs changing but your settings. Andi At 12:30 PM 12/15/2001 -0800, August Zajonc wrote: I've really run into a wall trying to get single charachters from stdin. Something similar to the getchar macro or a real fgetc would be nice. The current behavior is that more than a signle charachter can be typed and fgetc only returns when it sees a \n. I'd like it to return immediatly after the first charachter. fscanf with a format string something like %c requires a \n before returning as well, though I suppose that is more understandable. various things like fread with length of 1 also don't work. This is missing functionality for which there is no workaround that would certainly make shell scripting easier. It should be relativly trivial to implement, either an unbuffered fgetc option or a new function or something. -AZ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] php 4.1 can't compile (fwd)
-- Forwarded message -- Date: Sat, 15 Dec 2001 18:13:15 -0500 From: Charlie Romero [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED], Charlie Romero [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: php 4.1 can't compile Anyone seeing the same errors I'm seeing? I can't get mnogosearch to compile w/ php 4.1. I'm using mnogosearch 3.2.3. MnoGoSearch compiled fine w/out any errors. Below are the errors from the php make. Any hints??? Charlie make[3]: Entering directory `/usr/local/src/php-4.1.0/ext/mnogosearch' /bin/sh /usr/local/src/php-4.1.0/libtool --silent --mode=compile gcc -I. -I/usr/local/src/php-4.1.0/ext/mnogosearch -I/usr/local/src/php-4.1.0/main -I/usr/local/src/php-4.1.0 -I/usr/local/apache/include -I/usr/local/src/php-4.1.0/Zend -I/usr/local/mnogosearch/include -I/usr/local/mysql/include -I/usr/local/src/php-4.1.0/ext/xml/expat -DLINUX=22 -DUSE_HSREGEX -I/usr/local/src/php-4.1.0/TSRM -g -O2 -prefer-pic -c php_mnogo.c php_mnogo.c: In function `zm_startup_mnogosearch': php_mnogo.c:261: `UDM_CACHE_ENABLED' undeclared (first use in this function) php_mnogo.c:261: (Each undeclared identifier is reported only once php_mnogo.c:261: for each function it appears in.) php_mnogo.c:262: `UDM_CACHE_DISABLED' undeclared (first use in this function) php_mnogo.c:296: `UDM_MATCH_WORD' undeclared (first use in this function) php_mnogo.c: In function `zif_udm_set_agent_param': php_mnogo.c:457: `UDM_MATCH_WORD' undeclared (first use in this function) php_mnogo.c:459: warning: unreachable code at beginning of switch statement php_mnogo.c:483: `UDM_CACHE_ENABLED' undeclared (first use in this function) php_mnogo.c:484: structure has no member named `cache_mode' php_mnogo.c:487: `UDM_CACHE_DISABLED' undeclared (first use in this function) php_mnogo.c:488: structure has no member named `cache_mode' php_mnogo.c:485: warning: unreachable code at beginning of switch statement php_mnogo.c:492: structure has no member named `cache_mode' php_mnogo.c:503: structure has no member named `track_mode' php_mnogo.c:503: `UDM_TRACK_QUERIES' undeclared (first use in this function) php_mnogo.c:507: structure has no member named `track_mode' php_mnogo.c:521: structure has no member named `use_phrases' php_mnogo.c:525: structure has no member named `use_phrases' php_mnogo.c:539: structure has no member named `ispell_mode' php_mnogo.c:543: structure has no member named `ispell_mode' php_mnogo.c:555: warning: assignment makes pointer from integer without a cast php_mnogo.c:556: structure has no member named `charset' php_mnogo.c:561: structure has no member named `stop_tables' php_mnogo.c:562: structure has no member named `stop_tables' php_mnogo.c:575: structure has no member named `weight_factor' php_mnogo.c: In function `zif_udm_load_ispell_data': php_mnogo.c:663: structure has no member named `ispell_mode' php_mnogo.c:665: structure has no member named `charset' php_mnogo.c:673: structure has no member named `ispell_mode' php_mnogo.c:676: structure has no member named `ispell_mode' php_mnogo.c:679: too many arguments to function `UdmImportAffixes' php_mnogo.c:687: structure has no member named `ispell_mode' php_mnogo.c:690: structure has no member named `ispell_mode' php_mnogo.c:693: warning: passing arg 4 of `UdmImportDictionary' makes pointer from integer without a cast php_mnogo.c:693: warning: passing arg 5 of `UdmImportDictionary' makes integer from pointer without a cast php_mnogo.c:693: too few arguments to function `UdmImportDictionary' php_mnogo.c:703: structure has no member named `ispell_mode' php_mnogo.c:704: structure has no member named `ispell_mode' php_mnogo.c:706: structure has no member named `spellhost' php_mnogo.c: In function `zif_udm_find': php_mnogo.c:879: structure has no member named `charset' php_mnogo.c:879: warning: passing arg 2 of `UdmFind' makes pointer from integer without a cast php_mnogo.c: In function `zif_udm_cat_list': php_mnogo.c:1164: `UDMSTRSIZ' undeclared (first use in this function) php_mnogo.c: In function `zif_udm_cat_path': php_mnogo.c:1213: `UDMSTRSIZ' undeclared (first use in this function) make[3]: *** [php_mnogo.lo] Error 1 make[3]: Leaving directory `/usr/local/src/php-4.1.0/ext/mnogosearch' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/php-4.1.0/ext/mnogosearch' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/php-4.1.0/ext' make: *** [all-recursive] Error 1 ___ If you want to unsubscribe send unsubscribe general to [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14535 Updated: Mail function always returns false
ID: 14535 Updated by: yohgaki Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Mail related Operating System: FreeBSD 4.1-RELEASE i386 PHP Version: 4.0.6 New Comment: Could you try 4.10 and/or snapshot and report the result? http://snaps.php.net/ Previous Comments: [2001-12-15 12:45:27] [EMAIL PROTECTED] This is to confirm the bug reported in Bug ID #14032 PHP Apache Module Versions 4.0.4, 4.0.6 FreeBSD 4.1 Installed on a virtual server at Verio The script below runs fine on my WinNT/IIS development server running PHP 4.0.4 as a CGI module. On the FreeBSD virtual server, the same script always returns false, even though the mail message has been sent successfully. Could it be a problem with how sendmail running on FreeBSD is responding (or not responding) to the mail() function? === ?php error_reporting(E_ALL); $mail_to = '[EMAIL PROTECTED]'; $mail_subject = 'Test Email'; $mail_message = 'This is a test'; $mail_headers = From:[EMAIL PROTECTED]\nReply-To:[EMAIL PROTECTED]\n; $sent = TRUE; $sent = mail($mail_to,$mail_subject,$mail_message,$mail_headers); if ( $sent == TRUE ) print(Mail sent successfully); else print(Mail was not sent); ? Edit this bug report at http://bugs.php.net/?id=14535edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14538 Updated: dirname fix broke behaviour that it had since PHP 3
ID: 14538 Updated by: daniel Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Unknown/Other Function Operating System: Any PHP Version: 4.1.0 New Comment: Actually, you both (Zeev and Manuel) are demanding the same thing, in case you didn't recognize. You both want a high backwards compatibility, but whereas Manuel is proposing a switch in php.ini for every little thing, Zeev rather prefers to have this compatibility out of the box (i.e. every script should run with the same behaviour on every PHP installation - which isn't 100% possible, what he accepts). providing seperate switches for every little thing would extremely complexify PHP programming, as you have to take care of every additional switch in PHP, therefore I agree with Zeev. The best thing would be to never change a language behaviour, but sometimes it seems to be unavoidable. Previous Comments: [2001-12-15 19:06:47] [EMAIL PROTECTED] Zeev, As always I am trying to be constructive here. I am trying to bring the attention to the fact that as in the past, many ISPs did not upgrade from old PHP versions because they have bad experiences of having their clients code broken in new PHP versions. In this case, an old PHP version is 4.0.0 which is the previous major version. If you decide to not be sensitive to this point , I am afraid you will be leaving a lot of people annoyed and loosing business. As to the eventual accusation of being unprofessional, I mean that I am afraid that it will be what other people will think about who made these backward incompatible changes. Forget that I am the person reporting here. I am not relying on that you ever make a wise decision regarding this. I'll have to make my code work similarly to what you suggested because I am well aware of the problem, but I am afraid that most people isn't. I was just trying to help you avoid any future problems of credibility and professionalism before other people that may arise from these backward incompatible incidents (I am afraid there are more issues than just dirname). I am just trying to help here, I regret the fact that my report is just being discarded as if I never made it to help you release PHP with a more professional attitude. Anyway, I am used to this systematic ignore Manuel Lemos atitude of yours. So, do whatever you think is best for your business and keep not caring about me spending time to help you. :-( [2001-12-15 18:47:57] [EMAIL PROTECTED] Manuel, This behavior is not going to change, and we're not going to introduce a new headache-causing INI option to toggle this behavior. If you really can't fix the code, you can create my_dirname() that wraps around dirname, and returns if the result is . Then, all you have to do is a searchreplace of dirname - my_dirname. You use this 'threat' of being accused in unprofessionalism a bit too often, in my humble opinion :) [2001-12-15 18:41:16] [EMAIL PROTECTED] I was trying to test PHP 4.1.0 in a production site that I have that is made of large code base and realized that dirname original behaviour was broken severely. The site exists for more than 2 years and always relied on the behaviour that dirname(/index.php) would return as it has been since PHP 3. The site has 4.0.0 and was never upgraded since because I have this policy of not installing minor versions to avoid spending a lot of time maintaining changes that are caused by bugs that may have been introduced. I investigated and it seems that in PHP 4.0.3, Andi fixed dirname so that dirname(/index.php) now returns / instead of as before. Although this should have been probably the original behaviour of the function, the fact is that it wasn't not even in PHP 3 days. My site heavily relies on this feature to let scripts realize in which directory they are relatively to the server document root using dirname(GetEnv(SCRIPT_NAME)) . So, my site is seriously broken because I use this everywhere in the site. I talked with Andi and he is not willing to restore the original behaviour because the fix was done more than 1 year ago. So, I propose that some option be added to php.ini that lets developers restore the original behaviour so that their sites don't break because of this change. I also would like to recommend PHP developers to take more care when making these changes that break the existing PHP code base of PHP users because many ISP are refusing to upgrade to more recent versions because it breaks their clients PHP code and they would be loosing business if they would upgrade to a newer version. Please consider this proposal carefully to avoid being accused of unprofessionalism of not assuring backwards compatibility of PHP
[PHP-DEV] Bug #14540: sessions and register_globals
From: [EMAIL PROTECTED]
Operating system: linux 2.2.18 - glibc 2.1.3
PHP version: 4.1.0
PHP Bug Type: Session related
Bug description: sessions and register_globals
There is something I don't understand.
I've updated to v4.1.0 and noticed that the recommended
configuration defaults register_globals to *Off*. I
understand the security reasons behind this choice. I've
tried to run one of my projects with the new interpreter
and the recommended settings (register_globals=Off). After
resolving a plenty of warnings, I noticed that things were
not working as I expected.
This is a sample code:
?
session_register('PIPPO');
if (empty($PIPPO)) {
$PIPPO = ONE;
} else {
$PIPPO = TWO;
}
$sidfile = /tmp/sess_ . $_COOKIE['PHPSESSID'];
echo Session file $sidfile contains: pre;
readfile($sidfile);
echo /pre;
echo The value is: $PIPPObr;
?
When I run and reload the script I get:
Session file /tmp/sess_87...blahblah...3e contains:
PIPPO|s:3:ONE;maxrating|N;
The value is: ONE
Why the first run sets the session variable to ONE and
the second run can't get it's value? In the latter case I
guess the answer is: because you have to access it through
$HTTP_SESSION_VARS, but ... shouldn't it had to be the
same in the former case?
--
Edit bug report at: http://bugs.php.net/?id=14540edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14518 Updated: --enable-trans-id doesn't work
ID: 14518 Updated by: yohgaki Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Session related Operating System: LInux 2.4.16 (RH7.2 based) PHP Version: 4.1.0 New Comment: theseer, do you use ob_end_*() in your script? Could you add more details? -- Yasuo Previous Comments: [2001-12-15 12:05:11] [EMAIL PROTECTED] I can not reproduce this with 4.1.0 [2001-12-15 11:46:59] [EMAIL PROTECTED] Can anybody else reproduce this on *4.1.0*? [2001-12-14 20:38:46] [EMAIL PROTECTED] Just note: I can not reproduce this with latest CVS. [2001-12-14 12:48:23] [EMAIL PROTECTED] I suppose you've verified problem ;) Type = Critical [2001-12-14 11:35:41] [EMAIL PROTECTED] I compiled php4.1.0 with --enable-trans-id, configured to use no cookies for sessions. Verifiying with phpinfo() shows the correct settings for cookies and enable-trans-id but php fails to add the session-id to any tag. Passing a session-id manually works though. Edit this bug report at http://bugs.php.net/?id=14518edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14538 Updated: dirname fix broke behaviourthat it had since PHP 3
On Sat, Dec 15, 2001 at 11:43:07PM -0200, Manuel Lemos wrote : Sure but they way it seems to me is that reporting the problem did not make any difference. So why bother reporting? Just because yours was rejected doesn't mean all were or will be rejected. Globalising something from a subjective expirience isn't a very good idea ;) I am afraid that a lot of people simply do not bother to report problems, even when it affects their businesses, because they just get this kind of response and they certainly can use the time they spend making a useful report in things that can really result in something that the need. .. and many people are actually reporting bugs (as we obviously can see :). You'll just have to realize that the dev team can't please everybody. That the particular problem missbehaved in the past for so long is a pitty. That it's not documented is a pitty. Changing this behaviour BACK AGAIN is IMHO the worst thing one can think of. IMHO the best thing we can and should do at the moment is to proper document this change down and from that point of view your report was very valueable. - Markus -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14538 Updated: dirname fix broke behaviour that it had since PHP 3
ID: 14538 Updated by: mfischer Reported By: [EMAIL PROTECTED] Old Status: Closed Status: Open Old Bug Type: Unknown/Other Function Bug Type: Documentation problem Operating System: Any PHP Version: 4.1.0 New Comment: Reclassifying as a documentation problem (and reopened). Manuel did a good job tracking down when the behaviour of dirname() has changed and it won't hurt us putting this information into the documentation. Previous Comments: [2001-12-15 20:19:58] [EMAIL PROTECTED] Daniel, I don't think you are realizing how serious this is! dirname was added to PHP 3.0a3 which was released more than 4 years ago. Until a year ago it had a behaviour that Andi thought it was not correct, so he fixed it for PHP 4.0.3 eventually breaking the code of people that did not realize it then because they don't upgrade PHP on every minor release. So, the point is that what he thought was just a fix, was rather a behaviour change but he really didn't realize it until I reported today. I am not proposing a php.ini option. What I am saying is: 1) Admit that Andi did not make a wise decision then and so avoid any future decisions like this. 2) Decisions like this break end users code and prevents them from upgrading. 3) Everytime a developer faces a decision like this, always provide a backwards compatible solution to not cause harm to people code base and not hurt their applications or even their businesses. I think PHP developers were wise enough to avoid backwards compatibily problems of registering global by having a php.ini switch. I don't see why that could be bad for dirname. I am not even saying that you should always add a php.ini switch, but at least is a solution that does not leave people out there in the cold. [2001-12-15 19:50:54] [EMAIL PROTECTED] Actually, you both (Zeev and Manuel) are demanding the same thing, in case you didn't recognize. You both want a high backwards compatibility, but whereas Manuel is proposing a switch in php.ini for every little thing, Zeev rather prefers to have this compatibility out of the box (i.e. every script should run with the same behaviour on every PHP installation - which isn't 100% possible, what he accepts). providing seperate switches for every little thing would extremely complexify PHP programming, as you have to take care of every additional switch in PHP, therefore I agree with Zeev. The best thing would be to never change a language behaviour, but sometimes it seems to be unavoidable. [2001-12-15 19:06:47] [EMAIL PROTECTED] Zeev, As always I am trying to be constructive here. I am trying to bring the attention to the fact that as in the past, many ISPs did not upgrade from old PHP versions because they have bad experiences of having their clients code broken in new PHP versions. In this case, an old PHP version is 4.0.0 which is the previous major version. If you decide to not be sensitive to this point , I am afraid you will be leaving a lot of people annoyed and loosing business. As to the eventual accusation of being unprofessional, I mean that I am afraid that it will be what other people will think about who made these backward incompatible changes. Forget that I am the person reporting here. I am not relying on that you ever make a wise decision regarding this. I'll have to make my code work similarly to what you suggested because I am well aware of the problem, but I am afraid that most people isn't. I was just trying to help you avoid any future problems of credibility and professionalism before other people that may arise from these backward incompatible incidents (I am afraid there are more issues than just dirname). I am just trying to help here, I regret the fact that my report is just being discarded as if I never made it to help you release PHP with a more professional attitude. Anyway, I am used to this systematic ignore Manuel Lemos atitude of yours. So, do whatever you think is best for your business and keep not caring about me spending time to help you. :-( [2001-12-15 18:47:57] [EMAIL PROTECTED] Manuel, This behavior is not going to change, and we're not going to introduce a new headache-causing INI option to toggle this behavior. If you really can't fix the code, you can create my_dirname() that wraps around dirname, and returns if the result is . Then, all you have to do is a searchreplace of dirname - my_dirname. You use this 'threat' of being accused in unprofessionalism a bit too often, in my humble opinion :) [2001-12-15 18:41:16] [EMAIL PROTECTED] I was trying
[PHP-DEV] Bug #14535 Updated: Mail function always returns false
ID: 14535 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Mail related Operating System: FreeBSD 4.1-RELEASE i386 PHP Version: 4.0.6 New Comment: I don't have 4.1.0 loaded on the FreeBSD machine yet, but I received an email this morning from Ross ([EMAIL PROTECTED] ) who had reported this problem in Bug ID #14032. He tested 4.1.0 yesterday and had the same result as in previous 4.x versions. By the way, my test script runs fine in PHP3 on the FreeBSD machine, so this appears to be limited to PHP 4.x Previous Comments: [2001-12-15 22:26:52] [EMAIL PROTECTED] Could you try 4.10 and/or snapshot and report the result? http://snaps.php.net/ [2001-12-15 12:45:27] [EMAIL PROTECTED] This is to confirm the bug reported in Bug ID #14032 PHP Apache Module Versions 4.0.4, 4.0.6 FreeBSD 4.1 Installed on a virtual server at Verio The script below runs fine on my WinNT/IIS development server running PHP 4.0.4 as a CGI module. On the FreeBSD virtual server, the same script always returns false, even though the mail message has been sent successfully. Could it be a problem with how sendmail running on FreeBSD is responding (or not responding) to the mail() function? === ?php error_reporting(E_ALL); $mail_to = '[EMAIL PROTECTED]'; $mail_subject = 'Test Email'; $mail_message = 'This is a test'; $mail_headers = From:[EMAIL PROTECTED]\nReply-To:[EMAIL PROTECTED]\n; $sent = TRUE; $sent = mail($mail_to,$mail_subject,$mail_message,$mail_headers); if ( $sent == TRUE ) print(Mail sent successfully); else print(Mail was not sent); ? Edit this bug report at http://bugs.php.net/?id=14535edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] [defacementmonitor@hotmail.com: Win ME, Apache/1.3.20 and PHP/4.0.4pl1 Source disclosure Vulnerability]
Hi, This mail just poppep up buqtrag. Although PHP 4.0.4pl1 is old and it is unlikely someone is running it on a production machine on Win ME I'ld like someone with access to Win ME and standard Apache/PHP installation can verify this is true or not. Not only PHP 4.0.4pl1 but also 4.1.0 would be interesting. - Markus -- Please always Cc to me when replying to me on the lists. ---BeginMessage--- It appears as if PHP/4.0.4 installed on Win ME running Apache/1.3.20 will disclose php source if the url is entered with pounds surrounding the dot. http://server.com/phpfile#.#php I have tested this on: Apache/1.3.22 (Win32) PHP/4.0.6 (Win2K pro) And it is not vulnerable. This may be a Win ME thing.. I would be curious if Apache/1.3.22 on Win ME is vulnerable Now WHY someone would have a webserver on MEis another question ---End Message--- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Unbuffered fgetc needed for stdin
This usually depends on how you configured your tty. I think by default it is buffered by the OS until a newline so it's probably not PHP which needs changing but your settings. Andi At 12:30 PM 12/15/2001 -0800, August Zajonc wrote: I've really run into a wall trying to get single charachters from stdin. Something similar to the getchar macro or a real fgetc would be nice. The current behavior is that more than a signle charachter can be typed and fgetc only returns when it sees a \n. I'd like it to return immediatly after the first charachter. fscanf with a format string something like %c requires a \n before returning as well, though I suppose that is more understandable. various things like fread with length of 1 also don't work. This is missing functionality for which there is no workaround that would certainly make shell scripting easier. It should be relativly trivial to implement, either an unbuffered fgetc option or a new function or something. -AZ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #14538 Updated: dirname fix broke behaviour that it had since PHP 3
I really would like have consistency and new error levels as I proposed. It may not be a good idea for 4.2.0, but I think it is good for 4.3.0 or 5.0, if we annouce it early enough. E_ERROR: Fatal error. E_WARNING: Bug in script. Runtime error should not be ignored. E_NOTICE: Possible bug in script. Runtime error can be ignored. E_DEBUG: Error messages useful for debugging. Errors safe to ignore. E_INFO: Not really a error but just a info. Useful for API change notice, etc. There are only 2300 php_error/zend_error in current source ;) -- Yasuo Ohgaki [EMAIL PROTECTED] wrote: ID: 14538 Updated by: mfischer Reported By: [EMAIL PROTECTED] Old Status: Closed Status: Open Old Bug Type: Unknown/Other Function Bug Type: Documentation problem Operating System: Any PHP Version: 4.1.0 New Comment: Reclassifying as a documentation problem (and reopened). Manuel did a good job tracking down when the behaviour of dirname() has changed and it won't hurt us putting this information into the documentation. Previous Comments: [2001-12-15 20:19:58] [EMAIL PROTECTED] Daniel, I don't think you are realizing how serious this is! dirname was added to PHP 3.0a3 which was released more than 4 years ago. Until a year ago it had a behaviour that Andi thought it was not correct, so he fixed it for PHP 4.0.3 eventually breaking the code of people that did not realize it then because they don't upgrade PHP on every minor release. So, the point is that what he thought was just a fix, was rather a behaviour change but he really didn't realize it until I reported today. I am not proposing a php.ini option. What I am saying is: 1) Admit that Andi did not make a wise decision then and so avoid any future decisions like this. 2) Decisions like this break end users code and prevents them from upgrading. 3) Everytime a developer faces a decision like this, always provide a backwards compatible solution to not cause harm to people code base and not hurt their applications or even their businesses. I think PHP developers were wise enough to avoid backwards compatibily problems of registering global by having a php.ini switch. I don't see why that could be bad for dirname. I am not even saying that you should always add a php.ini switch, but at least is a solution that does not leave people out there in the cold. [2001-12-15 19:50:54] [EMAIL PROTECTED] Actually, you both (Zeev and Manuel) are demanding the same thing, in case you didn't recognize. You both want a high backwards compatibility, but whereas Manuel is proposing a switch in php.ini for every little thing, Zeev rather prefers to have this compatibility out of the box (i.e. every script should run with the same behaviour on every PHP installation - which isn't 100% possible, what he accepts). providing seperate switches for every little thing would extremely complexify PHP programming, as you have to take care of every additional switch in PHP, therefore I agree with Zeev. The best thing would be to never change a language behaviour, but sometimes it seems to be unavoidable. [2001-12-15 19:06:47] [EMAIL PROTECTED] Zeev, As always I am trying to be constructive here. I am trying to bring the attention to the fact that as in the past, many ISPs did not upgrade from old PHP versions because they have bad experiences of having their clients code broken in new PHP versions. In this case, an old PHP version is 4.0.0 which is the previous major version. If you decide to not be sensitive to this point , I am afraid you will be leaving a lot of people annoyed and loosing business. As to the eventual accusation of being unprofessional, I mean that I am afraid that it will be what other people will think about who made these backward incompatible changes. Forget that I am the person reporting here. I am not relying on that you ever make a wise decision regarding this. I'll have to make my code work similarly to what you suggested because I am well aware of the problem, but I am afraid that most people isn't. I was just trying to help you avoid any future problems of credibility and professionalism before other people that may arise from these backward incompatible incidents (I am afraid there are more issues than just dirname). I am just trying to help here, I regret the fact that my report is just being discarded as if I never made it to help you release PHP with a more professional attitude. Anyway, I am used to this systematic ignore Manuel Lemos atitude of yours. So, do whatever you think is best for your business and keep not caring about me spending time to help you. :-(
Re: [PHP-DEV] Linking PHP with static Libtool libraries
This patch makes Zend includes its own set of libraries, so that external support libs used by PHP extensions are linked once when building PHP lib. I simply define ZEND_LIBS. I cannot tell what impact this would otherwise have. I'm not that familiar with the PHP code. I guess, AC_SUBST(ZEND_LIBS) has to be used in PHP's configure.in as well. Index: Makefile.am === RCS file: /repository/Zend/Makefile.am,v retrieving revision 1.43 diff -u -r1.43 Makefile.am --- Makefile.am 2001/09/19 08:26:11 1.43 +++ Makefile.am 2001/12/16 02:15:47 @@ -15,7 +15,7 @@ zend_list.c zend_indent.c zend_builtin_functions.c zend_sprintf.c \ zend_ini.c zend_qsort.c -libZend_la_LDFLAGS = @EXTRA_LIBS@ +libZend_la_LDFLAGS = @ZEND_LIBS@ # automake isn't too clever about non-standard use of lex and yacc Index: configure.in === RCS file: /repository/Zend/configure.in,v retrieving revision 1.31 diff -u -r1.31 configure.in --- configure.in2000/12/02 13:26:41 1.31 +++ configure.in2001/12/16 02:15:47 @@ -35,9 +35,9 @@ LIBZEND_ENABLE_DEBUG LIBZEND_OTHER_CHECKS -EXTRA_LIBS=$LIBS +ZEND_LIBS=$LIBS LIBS= -AC_SUBST(EXTRA_LIBS) +AC_SUBST(ZEND_LIBS) AC_OUTPUT(Makefile) # Local Variables: --- -- Adam not On Fri, Dec 14, 2001 at 07:44:28PM +0200, Jani Taskinen wrote: Does this happen with latest CVS? --Jani On Fri, 14 Dec 2001, Adam Dickmeiss wrote: I have the following problem. On UNIX, PHP fails to link with a static library generated by Libtool. Problem occurs with PHP 4.1.0 but not PHP 4.0.6. The YAZ extension, for example, which I maintain generates by default a static Libtool library only. So After doing cd yaz-1.8.3 ./configure --prefix=/usr make make install two files are created, namely /usr/lib/libyaz.a and /lib/lib/libyaz.la. For PHP I do : ./configure --with-yaz [other options] and get the folloing make output: .. /bin/sh ../libtool --silent --mode=link gcc -g -O2 -prefer-pic -o libZend.la -ldl -lyaz -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt zend_language_parser.lo zend_language_scanner.lo zend_ini_parser.lo zend_ini_scanner.lo zend_alloc.lo zend_compile.lo zend_c onstants.lo zend_dynamic_array.lo zend_execute.lo zend_execute_API.lo zend_highlight.lo zend_llist.lo zend_opcode.lo zend_operators.l o zend_ptr_stack.lo zend_stack.lo zend_variables.lo zend.lo zend_API.lo zend_extensions.lo zend_hash.lo zend_list.lo zend_indent.lo z end_builtin_functions.lo zend_sprintf.lo zend_ini.lo make[1]: Leaving directory `/home/adam/proj/php-4.1.0/Zend' ... /bin/sh /home/adam/proj/php-4.1.0/libtool --silent --mode=link gcc -I. -I/home/adam/proj/php-4.1.0/ -I/home/adam/proj/php-4.1.0/main -I/home/adam/proj/php-4.1.0 -I/home/adam/proj/apache/include -I/home/adam/proj/php-4.1.0/Zend -I/home/adam/proj/php-4.1.0/ext/mysql/ libmysql -I/home/adam/proj/php-4.1.0/ext/xml/expat -DLINUX=22 -DUSE_HSREGEX -DUSE_EXPAT -I/home/adam/proj/php-4.1.0/TSRM -g -O2 -pre fer-pic -o libphp4.la -rpath /home/adam/proj/php-4.1.0/libs -avoid-version stub.lo Zend/libZend.la sapi/apache/libsapi.la main/l ibmain.la regex/libregex.la ext/mysql/libmysql.la ext/pcre/libpcre.la ext/posix/libposix.la ext/session/libsession.la ext/standard/li bstandard.la ext/xml/libxml.la ext/yaz/libyaz.la TSRM/libtsrm.la -ldl -lyaz -lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt /usr/lib/libyaz.a(odr_bool.o): In function `odr_bool': /home/adam/proj/yaz/odr/odr_bool.c(.text+0x0): multiple definition of `odr_bool' Zend/.libs/libZend.al(odr_bool.o)(.text+0x0):/home/adam/proj/yaz/odr/odr_bool.c: first defined here /usr/lib/libyaz.a(ber_bool.o): In function `ber_boolean': [many more multiple symbols] The log indicates that all YAZ symbols are included twice. Apparenly the Zend link step includes YAZ verbatim even though NO symbols should be needed to built that. Solutions / work-arounds: 1) removing /usr/lib/libyaz.la makes it work. Suddenly, the Zend link step doesn't include YAZ so everything is fine. Libtool bug? 2) removing the linkage of yaz from the Zend link step obviously makes it work too. 3) build shared YAZ objects is a fix too. (./configure --enabled-shared for YAZ). The problem doesn't occur with PHP 4.0.6. Probably due to the fact that it uses libtool 1.3.5. The problem currently only exists with YAZ (I guess most other packages are shared objects ONLY). But it would really be convenient if extensions could use static libraries as well. If this is a libtool bug and there's no easy fix for that, my suggestion would be that Zend doesn't link with YAZ or other extension libraries. Fix 2) above. -- Adam -- Adam Dickmeiss mailto:[EMAIL PROTECTED] http://www.indexdata.dk Index Data T: +45 33410100 Mob.: 212 212 66 -- PHP Development Mailing List
[PHP-DEV] Bug #14538 Updated: dirname fix broke behaviour that it had since PHP 3
ID: 14538 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Unknown/Other Function Operating System: Any PHP Version: 4.1.0 New Comment: Daniel, I don't think you are realizing how serious this is! dirname was added to PHP 3.0a3 which was released more than 4 years ago. Until a year ago it had a behaviour that Andi thought it was not correct, so he fixed it for PHP 4.0.3 eventually breaking the code of people that did not realize it then because they don't upgrade PHP on every minor release. So, the point is that what he thought was just a fix, was rather a behaviour change but he really didn't realize it until I reported today. I am not proposing a php.ini option. What I am saying is: 1) Admit that Andi did not make a wise decision then and so avoid any future decisions like this. 2) Decisions like this break end users code and prevents them from upgrading. 3) Everytime a developer faces a decision like this, always provide a backwards compatible solution to not cause harm to people code base and not hurt their applications or even their businesses. I think PHP developers were wise enough to avoid backwards compatibily problems of registering global by having a php.ini switch. I don't see why that could be bad for dirname. I am not even saying that you should always add a php.ini switch, but at least is a solution that does not leave people out there in the cold. Previous Comments: [2001-12-15 19:50:54] [EMAIL PROTECTED] Actually, you both (Zeev and Manuel) are demanding the same thing, in case you didn't recognize. You both want a high backwards compatibility, but whereas Manuel is proposing a switch in php.ini for every little thing, Zeev rather prefers to have this compatibility out of the box (i.e. every script should run with the same behaviour on every PHP installation - which isn't 100% possible, what he accepts). providing seperate switches for every little thing would extremely complexify PHP programming, as you have to take care of every additional switch in PHP, therefore I agree with Zeev. The best thing would be to never change a language behaviour, but sometimes it seems to be unavoidable. [2001-12-15 19:06:47] [EMAIL PROTECTED] Zeev, As always I am trying to be constructive here. I am trying to bring the attention to the fact that as in the past, many ISPs did not upgrade from old PHP versions because they have bad experiences of having their clients code broken in new PHP versions. In this case, an old PHP version is 4.0.0 which is the previous major version. If you decide to not be sensitive to this point , I am afraid you will be leaving a lot of people annoyed and loosing business. As to the eventual accusation of being unprofessional, I mean that I am afraid that it will be what other people will think about who made these backward incompatible changes. Forget that I am the person reporting here. I am not relying on that you ever make a wise decision regarding this. I'll have to make my code work similarly to what you suggested because I am well aware of the problem, but I am afraid that most people isn't. I was just trying to help you avoid any future problems of credibility and professionalism before other people that may arise from these backward incompatible incidents (I am afraid there are more issues than just dirname). I am just trying to help here, I regret the fact that my report is just being discarded as if I never made it to help you release PHP with a more professional attitude. Anyway, I am used to this systematic ignore Manuel Lemos atitude of yours. So, do whatever you think is best for your business and keep not caring about me spending time to help you. :-( [2001-12-15 18:47:57] [EMAIL PROTECTED] Manuel, This behavior is not going to change, and we're not going to introduce a new headache-causing INI option to toggle this behavior. If you really can't fix the code, you can create my_dirname() that wraps around dirname, and returns if the result is . Then, all you have to do is a searchreplace of dirname - my_dirname. You use this 'threat' of being accused in unprofessionalism a bit too often, in my humble opinion :) [2001-12-15 18:41:16] [EMAIL PROTECTED] I was trying to test PHP 4.1.0 in a production site that I have that is made of large code base and realized that dirname original behaviour was broken severely. The site exists for more than 2 years and always relied on the behaviour that dirname(/index.php) would return as it has been since PHP 3. The site has 4.0.0 and was never upgraded since because I have this
Re: [PHP-DEV] [defacementmonitor@hotmail.com: Win ME, Apache/1.3.20 and PHP/4.0.4pl1 Source disclosure Vulnerability]
As I responded on Bugtraq, this is, if anything, an Apache bug, not a PHP bug. It could be a configuration bug too, but the bottom line is the Apache doesn't determine that the file is a PHP file when requested in that way, and doesn't even invoke PHP on it. Zeev At 02:42 16/12/2001, Markus Fischer wrote: Hi, This mail just poppep up buqtrag. Although PHP 4.0.4pl1 is old and it is unlikely someone is running it on a production machine on Win ME I'ld like someone with access to Win ME and standard Apache/PHP installation can verify this is true or not. Not only PHP 4.0.4pl1 but also 4.1.0 would be interesting. - Markus -- Please always Cc to me when replying to me on the lists. Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: (qmail 18662 invoked from network); 15 Dec 2001 19:43:00 - Received: from outgoing2.securityfocus.com (HELO outgoing.securityfocus.com) (66.38.151.26) by chello213047128070.15.vie.surfer.at with SMTP; 15 Dec 2001 19:43:00 - Received: from lists.securityfocus.com (lists.securityfocus.com [66.38.151.19]) by outgoing.securityfocus.com (Postfix) with QMQP id 7F25B8F2AF; Sat, 15 Dec 2001 12:27:16 -0700 (MST) Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk List-Id: bugtraq.list-id.securityfocus.com List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Delivered-To: moderator for [EMAIL PROTECTED] Received: (qmail 29165 invoked from network); 15 Dec 2001 02:52:16 - Date: 15 Dec 2001 01:26:49 - Message-ID: [EMAIL PROTECTED] Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) From: Bill Q [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Win ME, Apache/1.3.20 and PHP/4.0.4pl1 Source disclosure Vulnerability It appears as if PHP/4.0.4 installed on Win ME running Apache/1.3.20 will disclose php source if the url is entered with pounds surrounding the dot. http://server.com/phpfile#.#php I have tested this on: Apache/1.3.22 (Win32) PHP/4.0.6 (Win2K pro) And it is not vulnerable. This may be a Win ME thing.. I would be curious if Apache/1.3.22 on Win ME is vulnerable Now WHY someone would have a webserver on MEis another question -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14538: dirname fix broke behaviour that it had since PHP 3
From: [EMAIL PROTECTED] Operating system: Any PHP version: 4.1.0 PHP Bug Type: Unknown/Other Function Bug description: dirname fix broke behaviour that it had since PHP 3 I was trying to test PHP 4.1.0 in a production site that I have that is made of large code base and realized that dirname original behaviour was broken severely. The site exists for more than 2 years and always relied on the behaviour that dirname(/index.php) would return as it has been since PHP 3. The site has 4.0.0 and was never upgraded since because I have this policy of not installing minor versions to avoid spending a lot of time maintaining changes that are caused by bugs that may have been introduced. I investigated and it seems that in PHP 4.0.3, Andi fixed dirname so that dirname(/index.php) now returns / instead of as before. Although this should have been probably the original behaviour of the function, the fact is that it wasn't not even in PHP 3 days. My site heavily relies on this feature to let scripts realize in which directory they are relatively to the server document root using dirname(GetEnv(SCRIPT_NAME)) . So, my site is seriously broken because I use this everywhere in the site. I talked with Andi and he is not willing to restore the original behaviour because the fix was done more than 1 year ago. So, I propose that some option be added to php.ini that lets developers restore the original behaviour so that their sites don't break because of this change. I also would like to recommend PHP developers to take more care when making these changes that break the existing PHP code base of PHP users because many ISP are refusing to upgrade to more recent versions because it breaks their clients PHP code and they would be loosing business if they would upgrade to a newer version. Please consider this proposal carefully to avoid being accused of unprofessionalism of not assuring backwards compatibility of PHP functions behaviour. -- Edit bug report at: http://bugs.php.net/?id=14538edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14538 Updated: dirname fix broke behaviour that it had since PHP 3
ID: 14538 Updated by: zeev Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Unknown/Other Function Operating System: Any PHP Version: 4.1.0 New Comment: Manuel, This behavior is not going to change, and we're not going to introduce a new headache-causing INI option to toggle this behavior. If you really can't fix the code, you can create my_dirname() that wraps around dirname, and returns if the result is . Then, all you have to do is a searchreplace of dirname - my_dirname. You use this 'threat' of being accused in unprofessionalism a bit too often, in my humble opinion :) Previous Comments: [2001-12-15 18:41:16] [EMAIL PROTECTED] I was trying to test PHP 4.1.0 in a production site that I have that is made of large code base and realized that dirname original behaviour was broken severely. The site exists for more than 2 years and always relied on the behaviour that dirname(/index.php) would return as it has been since PHP 3. The site has 4.0.0 and was never upgraded since because I have this policy of not installing minor versions to avoid spending a lot of time maintaining changes that are caused by bugs that may have been introduced. I investigated and it seems that in PHP 4.0.3, Andi fixed dirname so that dirname(/index.php) now returns / instead of as before. Although this should have been probably the original behaviour of the function, the fact is that it wasn't not even in PHP 3 days. My site heavily relies on this feature to let scripts realize in which directory they are relatively to the server document root using dirname(GetEnv(SCRIPT_NAME)) . So, my site is seriously broken because I use this everywhere in the site. I talked with Andi and he is not willing to restore the original behaviour because the fix was done more than 1 year ago. So, I propose that some option be added to php.ini that lets developers restore the original behaviour so that their sites don't break because of this change. I also would like to recommend PHP developers to take more care when making these changes that break the existing PHP code base of PHP users because many ISP are refusing to upgrade to more recent versions because it breaks their clients PHP code and they would be loosing business if they would upgrade to a newer version. Please consider this proposal carefully to avoid being accused of unprofessionalism of not assuring backwards compatibility of PHP functions behaviour. Edit this bug report at http://bugs.php.net/?id=14538edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14538 Updated: dirname fix broke behaviourthat it had since PHP 3
Hello, Zeev Suraski wrote: I am trying to bring the attention to the fact that as in the past, many ISPs did not upgrade from old PHP versions because they have bad experiences of having their clients code broken in new PHP versions. In this case, an old PHP version is 4.0.0 which is the previous major version. I think we're all well aware of this fact. I definitely am. I can also understand their reasons - updating to the last version is not suitable for everyone. So, there why keep giving more reasons to not upgrade? If you decide to not be sensitive to this point , I am afraid you will be leaving a lot of people annoyed and loosing business. Being aware or even sensitive to this point has very little to do with the specific issue at hand (dirname()). We do try to minimize incompatibilities in released, documented code, but sometimes they do occur. You'd find that's the case with virtually any large scale piece of software, including commercial software. Admit it, you were not aware and not even documented the change that Andi made to the behaviour of a function that worked like that for 3 years. As to the eventual accusation of being unprofessional, I mean that I am afraid that it will be what other people will think about who made these backward incompatible changes. I know, I'm just pointing out that I'm hearing that mostly from you and nobody else :) I can assure you that I'm not in 'ignore mlemos' mode, and you would have gotten a very similar answer (well, except for the 'Manuel,' in the beginning) if you were somebody else. You're more than welcome to send us what you think is constructive criticism. Sure but they way it seems to me is that reporting the problem did not make any difference. So why bother reporting? I am afraid that a lot of people simply do not bother to report problems, even when it affects their businesses, because they just get this kind of response and they certainly can use the time they spend making a useful report in things that can really result in something that the need. Regards, Manuel Lemos -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14538 Updated: dirname fix broke behaviour that it had since PHP 3
At 02:06 16/12/2001, [EMAIL PROTECTED] wrote: As always I am trying to be constructive here. Me too! I am trying to bring the attention to the fact that as in the past, many ISPs did not upgrade from old PHP versions because they have bad experiences of having their clients code broken in new PHP versions. In this case, an old PHP version is 4.0.0 which is the previous major version. I think we're all well aware of this fact. I definitely am. I can also understand their reasons - updating to the last version is not suitable for everyone. If you decide to not be sensitive to this point , I am afraid you will be leaving a lot of people annoyed and loosing business. Being aware or even sensitive to this point has very little to do with the specific issue at hand (dirname()). We do try to minimize incompatibilities in released, documented code, but sometimes they do occur. You'd find that's the case with virtually any large scale piece of software, including commercial software. As to the eventual accusation of being unprofessional, I mean that I am afraid that it will be what other people will think about who made these backward incompatible changes. I know, I'm just pointing out that I'm hearing that mostly from you and nobody else :) I can assure you that I'm not in 'ignore mlemos' mode, and you would have gotten a very similar answer (well, except for the 'Manuel,' in the beginning) if you were somebody else. You're more than welcome to send us what you think is constructive criticism. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14538 Updated: dirname fix broke behaviour that it had since PHP 3
ID: 14538 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Unknown/Other Function Operating System: Any PHP Version: 4.1.0 New Comment: Zeev, As always I am trying to be constructive here. I am trying to bring the attention to the fact that as in the past, many ISPs did not upgrade from old PHP versions because they have bad experiences of having their clients code broken in new PHP versions. In this case, an old PHP version is 4.0.0 which is the previous major version. If you decide to not be sensitive to this point , I am afraid you will be leaving a lot of people annoyed and loosing business. As to the eventual accusation of being unprofessional, I mean that I am afraid that it will be what other people will think about who made these backward incompatible changes. Forget that I am the person reporting here. I am not relying on that you ever make a wise decision regarding this. I'll have to make my code work similarly to what you suggested because I am well aware of the problem, but I am afraid that most people isn't. I was just trying to help you avoid any future problems of credibility and professionalism before other people that may arise from these backward incompatible incidents (I am afraid there are more issues than just dirname). I am just trying to help here, I regret the fact that my report is just being discarded as if I never made it to help you release PHP with a more professional attitude. Anyway, I am used to this systematic ignore Manuel Lemos atitude of yours. So, do whatever you think is best for your business and keep not caring about me spending time to help you. :-( Previous Comments: [2001-12-15 18:47:57] [EMAIL PROTECTED] Manuel, This behavior is not going to change, and we're not going to introduce a new headache-causing INI option to toggle this behavior. If you really can't fix the code, you can create my_dirname() that wraps around dirname, and returns if the result is . Then, all you have to do is a searchreplace of dirname - my_dirname. You use this 'threat' of being accused in unprofessionalism a bit too often, in my humble opinion :) [2001-12-15 18:41:16] [EMAIL PROTECTED] I was trying to test PHP 4.1.0 in a production site that I have that is made of large code base and realized that dirname original behaviour was broken severely. The site exists for more than 2 years and always relied on the behaviour that dirname(/index.php) would return as it has been since PHP 3. The site has 4.0.0 and was never upgraded since because I have this policy of not installing minor versions to avoid spending a lot of time maintaining changes that are caused by bugs that may have been introduced. I investigated and it seems that in PHP 4.0.3, Andi fixed dirname so that dirname(/index.php) now returns / instead of as before. Although this should have been probably the original behaviour of the function, the fact is that it wasn't not even in PHP 3 days. My site heavily relies on this feature to let scripts realize in which directory they are relatively to the server document root using dirname(GetEnv(SCRIPT_NAME)) . So, my site is seriously broken because I use this everywhere in the site. I talked with Andi and he is not willing to restore the original behaviour because the fix was done more than 1 year ago. So, I propose that some option be added to php.ini that lets developers restore the original behaviour so that their sites don't break because of this change. I also would like to recommend PHP developers to take more care when making these changes that break the existing PHP code base of PHP users because many ISP are refusing to upgrade to more recent versions because it breaks their clients PHP code and they would be loosing business if they would upgrade to a newer version. Please consider this proposal carefully to avoid being accused of unprofessionalism of not assuring backwards compatibility of PHP functions behaviour. Edit this bug report at http://bugs.php.net/?id=14538edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14541: strtok broken again
From: [EMAIL PROTECTED] Operating system: Any PHP version: 4.1.0 PHP Bug Type: Unknown/Other Function Bug description: strtok broken again It seems that strtok function is broken again. The following script returns: ? $first_token=strtok(/something,/); $second_token=strtok(/); var_dump($first_token,$second_token); ? Should output as always (at least until PHP 4.0.6 it does): string(0) string(9) something But it outputs: string(9) something bool(false) It seems that jmoore broken in when he tried to fix this bug: http://bugs.php.net/bug.php?id=13866 I think that no developer should be allowed to fix bugs before: 1) submit a test case to leave in the tests directory 2) Verify that his fixes do not make his and others tests fail. Until this procedure becomes mandatory, we'll keep seeing a history of illness in functions like strtok that seems to never end. This is what regressive tests are for. Zak, please help here! :-) -- Edit bug report at: http://bugs.php.net/?id=14541edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14542: connection_status() does not return 2 on timeout
From: [EMAIL PROTECTED]
Operating system: Solaris 7
PHP version: 4.1.0
PHP Bug Type: Unknown/Other Function
Bug description: connection_status() does not return 2 on timeout
It seems that when a script terminates due to a
timeout connection_status() returns 0 (and
connection_timeout() no longer exists).
When aborted by a user connection_status() does return 1.
Sample script:
?PHP
set_time_limit(1);
register_shutdown_function(shutdown);
function shutdown(){
$status = connection_status();
$err = Connection status ($status).\n;
error_log($err, 3, /tmp/phpstatus.log);
}
while(true){
echo .;
}
?
--
Edit bug report at: http://bugs.php.net/?id=14542edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14541 Updated: strtok broken again
ID: 14541 Updated by: zak Reported By: [EMAIL PROTECTED] Status: Open Old Bug Type: Unknown/Other Function Bug Type: Strings related Operating System: Any PHP Version: 4.1.0 New Comment: While we could try to force developers to write tests before they commit code (heck, MySQL does it), but we might not have much luck. :) I think that we should look to the QA team (and interested individuals such as yourself) to start writing tests. I am working on tests for the array functions right now (coincidentally, before I commit a whack of changes to the array functions. :) In Frankfurt, Rasmus suggested that we develop a web-based interface for developing tests as a way to lower the barrier for writing tests. We could look at doing this. Previous Comments: [2001-12-16 02:15:52] [EMAIL PROTECTED] It seems that strtok function is broken again. The following script returns: ? $first_token=strtok(/something,/); $second_token=strtok(/); var_dump($first_token,$second_token); ? Should output as always (at least until PHP 4.0.6 it does): string(0) string(9) something But it outputs: string(9) something bool(false) It seems that jmoore broken in when he tried to fix this bug: http://bugs.php.net/bug.php?id=13866 I think that no developer should be allowed to fix bugs before: 1) submit a test case to leave in the tests directory 2) Verify that his fixes do not make his and others tests fail. Until this procedure becomes mandatory, we'll keep seeing a history of illness in functions like strtok that seems to never end. This is what regressive tests are for. Zak, please help here! :-) Edit this bug report at http://bugs.php.net/?id=14541edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14538 Updated: dirname fix broke behaviourthat it had since PHP 3
Hello, Markus Fischer wrote: On Sat, Dec 15, 2001 at 11:43:07PM -0200, Manuel Lemos wrote : Sure but they way it seems to me is that reporting the problem did not make any difference. So why bother reporting? Just because yours was rejected doesn't mean all were or will be rejected. Globalising something from a subjective expirience isn't a very good idea ;) Gee, Markus, have you just arrived to php-dev? :-) PHP developers have a very long track record of neglecting my bug reports and quality improvement suggestions, some times making a very hard effort to deny that what I am reporting it is a bug! I could tell you about at least of handful of never address cases, but I just leave to do a search in the bug database for bug reports submitted by [EMAIL PROTECTED] . I am afraid that a lot of people simply do not bother to report problems, even when it affects their businesses, because they just get this kind of response and they certainly can use the time they spend making a useful report in things that can really result in something that the need. .. and many people are actually reporting bugs (as we obviously can see :). You'll just have to realize that the dev team can't please everybody. My point is that many of those people will give up reporting after they realize than many of their reports are simply not being properly addressed! That the particular problem missbehaved in the past for so long is a pitty. That it's not documented is a pitty. Changing this behaviour BACK AGAIN is IMHO the worst thing one can think of. What I suggested was not to change to the original behaviour, but rather have a switch in php.ini to enable the original behaviour. IMHO the best thing we can and should do at the moment is to proper document this change down and from that point of view your report was very valueable. Never mind, functions like dirname and strtok are in my blacklist, meaning I will ban them from my PHP programs because I can't afford using or distribute code that does not provide reliable behaviour as I can't assure if my code will run with a PHP version that will provide a reliable behaviour. strtok for instance had a long track record of bugs. Not a very long time ago, I banned strtok from Metabase because a user complained that Metabase could not be used in PHP session handlers. It turned out that it was a bug in strtok. As you know many thousands of use Metabase, so I can't be responsible for strtok bugs that affect Metabase. I completely removed all calls to strtok in Metabase. The same story with dirname. I just realized that strtok has a new bug caused by somebody that tried to fix a previous report. Now it affects the whole PHP Classes site. So, now I will ban strtok from all my PHP software. I used to say as a joke that I don't use Microsoft software because it is already hard to keep my software bug free so it would be harder if it dependended on Microsoft software. Too bad that is not a joke with PHP. :-( This is just my view of what it means to be professional when you develop software that many others use. Too bad that not everybody agrees. :-( Regards, Manuel Lemos -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14541 Updated: strtok broken again
ID: 14541 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Strings related Operating System: Any PHP Version: 4.1.0 New Comment: I understand that it is very hard to make developers write tests for new software, but at least those that commit bug fixes should be required to submit test scripts that reproduce the bugs if they do not exist yet. As for myself, I always present test cases when they are possible in the bug report itself, just like I did for this. So, developers have at least half of the job done. I think that is a matter of making it a rule by adding to the CODING_STANDARDS. Previous Comments: [2001-12-16 02:25:53] [EMAIL PROTECTED] While we could try to force developers to write tests before they commit code (heck, MySQL does it), but we might not have much luck. :) I think that we should look to the QA team (and interested individuals such as yourself) to start writing tests. I am working on tests for the array functions right now (coincidentally, before I commit a whack of changes to the array functions. :) In Frankfurt, Rasmus suggested that we develop a web-based interface for developing tests as a way to lower the barrier for writing tests. We could look at doing this. [2001-12-16 02:15:52] [EMAIL PROTECTED] It seems that strtok function is broken again. The following script returns: ? $first_token=strtok(/something,/); $second_token=strtok(/); var_dump($first_token,$second_token); ? Should output as always (at least until PHP 4.0.6 it does): string(0) string(9) something But it outputs: string(9) something bool(false) It seems that jmoore broken in when he tried to fix this bug: http://bugs.php.net/bug.php?id=13866 I think that no developer should be allowed to fix bugs before: 1) submit a test case to leave in the tests directory 2) Verify that his fixes do not make his and others tests fail. Until this procedure becomes mandatory, we'll keep seeing a history of illness in functions like strtok that seems to never end. This is what regressive tests are for. Zak, please help here! :-) Edit this bug report at http://bugs.php.net/?id=14541edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
