#20756 [Fbk-Csd]: configure fails detecting flex on Sun's version of lex
ID: 20756
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Closed
Bug Type: Compile Failure
Operating System: Solaris 2.8
PHP Version: 4.3.0RC2
Assigned To: iliaa
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
The fix just didn't make it into the snapshot yet, but the same thing
was added as your patch is.
Previous Comments:
[2002-12-02 01:34:45] [EMAIL PROTECTED]
Same thing.
-
pwd ./configure --enable-trans-sid --with-mysql=/usr/local/mysql
--with-apxs2=/usr/local/apache2/bin/apxs --with-gd=/usr/local
--with-jpeg-dir=/usr/local --with-png-dir=/usr/local
--with-zlib-dir=/usr
/usr/home/evan/php4-200212020630
loading cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for working sed... sed
checking host system type... sparc-sun-solaris2.8
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking whether gcc and cc understand -c and -o together... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking if compiler supports -R... yes
checking for ranlib... ranlib
checking whether ln -s works... yes
checking for gawk... gawk
checking for bison... no
checking for byacc... no
configure: warning: You will need bison if you want to regenerate the
PHP parsers.
checking for flex... lex
checking for yywrap in -ll... yes
checking lex output file root... lex.yy
checking whether yytext is a pointer... no
checking for working const... yes
checking flex version... lex: Software Generation Utilities (SGU)
Solaris-ELF (4.0)
And it justs hangs again. The solaris version of lex prints it's
version on standard err and then enters processing mode, so like most
solaris things you just need to cater to the way it works. Echoing
nothing to $LEX -V, while dumping a lot of garbage on the screen,
allows configure to continue and still works with GNU flex install as
well.
Here's a unified diff.
--- configure.bak Mon Dec 2 02:16:42 2002
+++ configure Mon Dec 2 02:32:16 2002
@@ -2632,7 +2632,7 @@
echo $ac_n checking flex version... $ac_c 16
echo configure:2635: checking flex version 5
-set `$LEX -V | grep 'version' | cut -d ' ' -f 3 | sed -e 's/\./ /g' |
sed -e 's/^0-9 //g'`
+set `echo '' | $LEX -V | grep 'version' | cut -d ' ' -f 3 | sed -e
's/\./ /g' | sed -e 's/^0-9 //g'`
if test ${1} != 2 -o ${2} != 5 -o ${3} -lt 4; then
echo configure: warning: You will need flex 2.5.4 or later if
you want to regenerate Zend/PHP lexical parsers. 12
fi
[2002-12-02 01:03:44] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-12-02 00:07:02] [EMAIL PROTECTED]
Configure command:
./configure --enable-trans-sid --with-mysql=/usr/local/mysql
--with-apxs2=/usr/local/apache2/bin/apxs --with-gd=/usr/local
--with-jpeg-dir=/usr/local --with-png-dir=/usr/local
--with-zlib-dir=/usr
Configure output:
checking for working sed... sed
checking build system type... sparc-sun-solaris2.8
checking host system type... sparc-sun-solaris2.8
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking whether gcc and cc understand -c and -o together... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking if compiler supports -R... yes
checking for ranlib... ranlib
checking whether ln -s works... yes
checking for gawk... gawk
checking for bison... no
checking for byacc... no
configure: WARNING: You will need bison if you want to regenerate the
PHP parsers.
checking for flex... no
checking for lex... lex
checking for yywrap in -lfl... no
checking for yywrap in -ll... yes
#20750 [Opn-Bgs]: Serious security hole when accessing phpinfo() in a .htaccess protected dir.
ID: 20750
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Apache related
Operating System: all
PHP Version: 4.2.3
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
If you do not want that your users can see this information then do not
give them the ability to view phpinfo().
Previous Comments:
[2002-12-01 13:37:15] [EMAIL PROTECTED]
On all Servers we administrate, we always install an 'info.php' file
which only contains the phpinfo() function.
Now I found that PHP returns the transmitted password in clear text to
the browser. The page is stored in the browsers cache or someone could
just have a look on my screen. :-((
I think this is a serious security hole.
The password should not be returned to the browser in any way, best
would be to show some asterisks ('***'), to show that the variable
exists.
Ulrich Kapp
--
Edit this bug report at http://bugs.php.net/?id=20750edit=1
#20751 [Com]: Mail: undefined function
ID: 20751 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Mail related Operating System: Linux Redhat 7.2 PHP Version: 4.3.0RC2 New Comment: Yes, it works. Previous Comments: [2002-12-01 17:00:38] [EMAIL PROTECTED] Try this on your cmd line: # test -f /sbin/sendmail echo works (it should print 'works') [2002-12-01 16:45:53] [EMAIL PROTECTED] Qmail is configured with virtual links from: /sbin/sendmail /usr/sbin/sendmail /usr/lib/sendmail to /var/qmail/bin/sendmail as suggested in qmail documentation [2002-12-01 16:42:46] [EMAIL PROTECTED] Yes. The user is root. [2002-12-01 16:28:41] [EMAIL PROTECTED] Does the user you're compiling PHP as have rights to access the sendmail binary on your system? (qmail does add some wrapper binary for sendmail, and it works fine here..) [2002-12-01 16:25:35] [EMAIL PROTECTED] The same problem is also on an other server with a similar configuration (but with redhat 7.0): The the servers config.log says: configure:10743: checking for sendmail configure:10776: result: no Why? Qmail is installed, seems that the new php version doesn't find it but 4.2.3 did! 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/20751 -- Edit this bug report at http://bugs.php.net/?id=20751edit=1
#20282 [Opn]: COM memory leak
ID: 20282 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: COM related Operating System: Win2000/XP PHP Version: 4.2.3 New Comment: Hi, how about bugfixing? Is it possible to get a solution soon? We are developing for DaimlerChrysler germany. Our project stagnate. We have a lot of data to transport across COM-mechanism. It's very urgent to get a bugfixing. Can you help us? Previous Comments: [2002-11-18 11:54:36] [EMAIL PROTECTED] Yes, i tryed. Using php-cgi.exe instead of php.exe i got php working. Here my measuring depending on repetitions for version 4.3.0 : 0 10002000 1 excel.exe7.500K 9.708K 11.600K 26.516K php-cgi.exe 5.688K 8.084K 10.612K 29.716K [2002-11-17 05:47:00] [EMAIL PROTECTED] could you at least try one of the php-4.3.0 release candidates ? [2002-11-11 12:05:38] [EMAIL PROTECTED] hi, i have problems installing CVS snapshot for windows. I go same way installing the CVS, as i did for php version 4.22/4.23. If I try executing a php script, apache detects an internal server error. I'm using apache version 1.1. Apache error log shows follwing message: [Mon Nov 11 18:35:07 2002] [error] [client 127.0.0.1] Premature end of script headers: c:/programme/php/php.exe. Can you help me? What's wrong? [2002-11-07 16:34:38] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-07 03:17:11] [EMAIL PROTECTED] hi, here my measuring depending on repetitions: 0 10002000 1 excel.exe 7.528K 9.712K 11.600K 26.416K php.exe 5.260K 7.668K 10.148K 30.556K do you need further information? 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/20282 -- Edit this bug report at http://bugs.php.net/?id=20282edit=1
#20707 [Fbk-Opn]: incorrect behavior of mail() with Bcc:
ID: 20707
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Mail related
Operating System: win 2000
PHP Version: 4.3.0RC2
New Comment:
Works perfectly now here using
http://snaps.php.net/win32/php4-win32-latest.zip
Thanks for the fix.
Previous Comments:
[2002-12-01 23:04:34] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-11-29 07:09:21] [EMAIL PROTECTED]
The loop may introduce other troubles if someone adds user-defined
header with ...cc: string. Thus it'll be safer to use
if((posheaders_lc)(!iscntrl(*(pos-1 { ...some other header, skip
it... } else { ...correct one, proceed...}
Another problem might arise if there is not PCRE support in the
function php_win32_mail_trim_header() and so we have unmodified headers
string (line 178). Then it can't be granted that the test for CRLF
if (NULL == (pos2 = strstr(pos1, \r\n)))
on the lines 423 and 477 gives correct results.
[2002-11-28 17:33:43] [EMAIL PROTECTED]
A bug in the SendText() function in php-4.3.0RC2\win32\sendmail.c
module can cause incorrect sending of messages to addresses in Cc: and
Bcc: fields in the additional headers string.
mail($recipient, $subject, $message, $headers);
Example:
assume $recipient, adr1, adr2 etc represent valid addresses, and XX any
other headers
$headers = Cc: adr1, adr2\nXX
sends messages for recipient, adr1 and adr2, ie. OK
$headers = Bcc: adr1, adr2\nXX
sends messages for recipient, and two copies for both adr1 and adr2.
$headers = Cc: adr1\nBcc: adr2\nXX
sends messages for recipient, adr1 and two copies for adr2.
$headers = BCc: adr1\nCc: adr2\nXX
sends messages for recipient, two copies for adr1 and none for adr2.
The cause is in the SendText() parsing headers string for cc and bcc
fields (from line 418 on). The code:
if (headers (pos1 = strstr(headers_lc, cc:))) {
recognize cc: substring in the bcc: resulting in duplicating messages
for bcc: addresses
more robust code could look like:
char *pos;
if (headers) {
pos=headers_lc;
while ((pos=strstr(pos,cc:))) {
if((posheaders_lc)(*(pos-1)=='b')) {
pos+=3; //bcc: found, skip it now
} else {
pos+=3;
pos1=headers+(pos-headers_lc);
... the rest of the routine lines 423 to 444
}
} // in case of more cc lines or bcc prior to cc
}
... lines 447 to 471
// similar loop for bcc ie.
pos=headers_lc;
while ((pos=strstr(pos,bcc:))) {
pos +=4;
pos1=headers+(pos-headers_lc);
... the rest of the routine lines 477 to 519 with respective
modifications to generating the stripped_header string.
zbynek
--
Edit this bug report at http://bugs.php.net/?id=20707edit=1
#17405 [Opn-Csd]: Support netsnmp (http://www.netsnmp.org/), Previously known as ucd-snmp.
ID: 17405 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.2.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip NET-SNMP is supported now. It will be in the general release from 4.3. Previous Comments: [2002-05-27 17:15:28] [EMAIL PROTECTED] Changed summary/category. [2002-05-27 13:03:38] [EMAIL PROTECTED] Ah, I changed VersionInfo to NetSnmpVersionInfo in ext/snmp/snmp.c too. [2002-05-27 13:00:57] [EMAIL PROTECTED] I change directory from snmp.c, so it take files correctly and modify configure script to use -lnetsnmp and not -lsnmp [2002-05-24 05:16:03] [EMAIL PROTECTED] Hmm, looking at things a bit more in detail and basing myself on what I see in the configure script... A detail to mention, the snmp.h file is located in /usr/local/include/net-snmp/library/ while the files that it fails to find at compilation time are located either in /usr/local/include/net-snmp/ (version.h) or /usr/local/include/net-snmp/library/ (asn.h, snmp_api.h, snmp_client.h, snmp_impl.h, snmp.h, parse.h, mib.h)... [2002-05-24 05:01:53] [EMAIL PROTECTED] With the net-snmp package replacing ucd-snmp (well, simply a new name), is there any possibility to add support for this package? I've tried to make it work, but I basically run into issues when compiling as it seems it just can't find the include files which are located in /usr/local/include/net-snmp by default. Looking around, I see the configure script has some paths specified where to look for snmp include files, and the paths in there relate to ucd-snmp but there's no mention of net-snmp. Any chance of getting this added? This is loosely the same issue as bug #13821, as far as the type goes. Thanks! -- Edit this bug report at http://bugs.php.net/?id=17405edit=1
#20282 [Opn]: COM memory leak
ID: 20282 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: COM related Operating System: Win2000/XP PHP Version: 4.2.3 New Comment: Well, you can always hire a PHP developer to do it if it is so urgent for your project. Please don't forget that PHP is an Open Source project, totally run by volunteers which dedicate their spare time to develop on PHP. Derick Previous Comments: [2002-12-02 03:21:25] [EMAIL PROTECTED] Hi, how about bugfixing? Is it possible to get a solution soon? We are developing for DaimlerChrysler germany. Our project stagnate. We have a lot of data to transport across COM-mechanism. It's very urgent to get a bugfixing. Can you help us? [2002-11-18 11:54:36] [EMAIL PROTECTED] Yes, i tryed. Using php-cgi.exe instead of php.exe i got php working. Here my measuring depending on repetitions for version 4.3.0 : 0 10002000 1 excel.exe7.500K 9.708K 11.600K 26.516K php-cgi.exe 5.688K 8.084K 10.612K 29.716K [2002-11-17 05:47:00] [EMAIL PROTECTED] could you at least try one of the php-4.3.0 release candidates ? [2002-11-11 12:05:38] [EMAIL PROTECTED] hi, i have problems installing CVS snapshot for windows. I go same way installing the CVS, as i did for php version 4.22/4.23. If I try executing a php script, apache detects an internal server error. I'm using apache version 1.1. Apache error log shows follwing message: [Mon Nov 11 18:35:07 2002] [error] [client 127.0.0.1] Premature end of script headers: c:/programme/php/php.exe. Can you help me? What's wrong? [2002-11-07 16:34:38] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20282 -- Edit this bug report at http://bugs.php.net/?id=20282edit=1
#20707 [Opn-Csd]: incorrect behavior of mail() with Bcc:
ID: 20707
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Mail related
Operating System: win 2000
PHP Version: 4.3.0RC2
New Comment:
Reported as fixed by the user
Previous Comments:
[2002-12-02 03:21:38] [EMAIL PROTECTED]
Works perfectly now here using
http://snaps.php.net/win32/php4-win32-latest.zip
Thanks for the fix.
[2002-12-01 23:04:34] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-11-29 07:09:21] [EMAIL PROTECTED]
The loop may introduce other troubles if someone adds user-defined
header with ...cc: string. Thus it'll be safer to use
if((posheaders_lc)(!iscntrl(*(pos-1 { ...some other header, skip
it... } else { ...correct one, proceed...}
Another problem might arise if there is not PCRE support in the
function php_win32_mail_trim_header() and so we have unmodified headers
string (line 178). Then it can't be granted that the test for CRLF
if (NULL == (pos2 = strstr(pos1, \r\n)))
on the lines 423 and 477 gives correct results.
[2002-11-28 17:33:43] [EMAIL PROTECTED]
A bug in the SendText() function in php-4.3.0RC2\win32\sendmail.c
module can cause incorrect sending of messages to addresses in Cc: and
Bcc: fields in the additional headers string.
mail($recipient, $subject, $message, $headers);
Example:
assume $recipient, adr1, adr2 etc represent valid addresses, and XX any
other headers
$headers = Cc: adr1, adr2\nXX
sends messages for recipient, adr1 and adr2, ie. OK
$headers = Bcc: adr1, adr2\nXX
sends messages for recipient, and two copies for both adr1 and adr2.
$headers = Cc: adr1\nBcc: adr2\nXX
sends messages for recipient, adr1 and two copies for adr2.
$headers = BCc: adr1\nCc: adr2\nXX
sends messages for recipient, two copies for adr1 and none for adr2.
The cause is in the SendText() parsing headers string for cc and bcc
fields (from line 418 on). The code:
if (headers (pos1 = strstr(headers_lc, cc:))) {
recognize cc: substring in the bcc: resulting in duplicating messages
for bcc: addresses
more robust code could look like:
char *pos;
if (headers) {
pos=headers_lc;
while ((pos=strstr(pos,cc:))) {
if((posheaders_lc)(*(pos-1)=='b')) {
pos+=3; //bcc: found, skip it now
} else {
pos+=3;
pos1=headers+(pos-headers_lc);
... the rest of the routine lines 423 to 444
}
} // in case of more cc lines or bcc prior to cc
}
... lines 447 to 471
// similar loop for bcc ie.
pos=headers_lc;
while ((pos=strstr(pos,bcc:))) {
pos +=4;
pos1=headers+(pos-headers_lc);
... the rest of the routine lines 477 to 519 with respective
modifications to generating the stripped_header string.
zbynek
--
Edit this bug report at http://bugs.php.net/?id=20707edit=1
#17405 [Csd-Fbk]: Support netsnmp (http://www.netsnmp.org/), Previously known as ucd-snmp.
ID: 17405 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Feedback Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.2.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip NET-SNMP is supported now. It will be in the general release from 4.3. Previous Comments: [2002-12-02 04:01:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip NET-SNMP is supported now. It will be in the general release from 4.3. [2002-05-27 17:15:28] [EMAIL PROTECTED] Changed summary/category. [2002-05-27 13:03:38] [EMAIL PROTECTED] Ah, I changed VersionInfo to NetSnmpVersionInfo in ext/snmp/snmp.c too. [2002-05-27 13:00:57] [EMAIL PROTECTED] I change directory from snmp.c, so it take files correctly and modify configure script to use -lnetsnmp and not -lsnmp [2002-05-24 05:16:03] [EMAIL PROTECTED] Hmm, looking at things a bit more in detail and basing myself on what I see in the configure script... A detail to mention, the snmp.h file is located in /usr/local/include/net-snmp/library/ while the files that it fails to find at compilation time are located either in /usr/local/include/net-snmp/ (version.h) or /usr/local/include/net-snmp/library/ (asn.h, snmp_api.h, snmp_client.h, snmp_impl.h, snmp.h, parse.h, mib.h)... 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/17405 -- Edit this bug report at http://bugs.php.net/?id=17405edit=1
#1441 [Com]: PHP doesn't handle persistent connections that has been killed properly
ID: 1441 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Sybase-ct (ctlib) related Operating System: Linux Redhat 5.2 PHP Version: 4.0 New Comment: ver 4.2.2 this behavior is still there Previous Comments: [2001-02-10 13:20:30] [EMAIL PROTECTED] looks to me like 4.0 should handle this correctly. [1999-12-13 16:12:20] [EMAIL PROTECTED] While I can confirm that the behavior is still there, I am moving it to a feature/change request. It'd be nice, though [1999-05-23 20:56:11] [EMAIL PROTECTED] Follow this procedure to reproduce the problem: - Use sybase_pconnect() a few times to start up a few persistent connections. - Start Sybase Central and kill off the PHP3 connections. - Rerun the script that uses sybase_pconnect(). sybase_pconnect() will NOT fail, however any following sybase_query() will return 0, but no other error message. Looks like PHP3 tries to run the query on a persistent connection that has disappeared, but doesn't fail in sybase_pconnect() as it should. Ideally, it should check if a persistant connection is gone and not fail at all, but if it have to fail it should do it in the right function :-) -- Edit this bug report at http://bugs.php.net/?id=1441edit=1
#20758 [NEW]: php_value without value causes apache to crash
From: [EMAIL PROTECTED] Operating system: any PHP version: 4.2.3 PHP Bug Type: Reproducible crash Bug description: php_value without value causes apache to crash i found out that if I pass php_value mysql.default_password without given password, it causes apache to crash Of course, the input is incorrect, but it should be ignored probably (or used as empty) and should not cause apache to crash. -- Edit bug report at http://bugs.php.net/?id=20758edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20758r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20758r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20758r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20758r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20758r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20758r=support Expected behavior: http://bugs.php.net/fix.php?id=20758r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20758r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20758r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20758r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20758r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20758r=dst IIS Stability: http://bugs.php.net/fix.php?id=20758r=isapi
#20759 [NEW]: fopen sometimes hangs
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.3 PHP Bug Type: HTTP related Bug description: fopen sometimes hangs Sometimes fopen of an http URL just sits there - no error, no results, typically when it does this PHP refuses to output ANY output for that page. FOr example fopen(http://anyurl.com,r;) works fine but fopen(http://reptile.peerfear.org/reptile/servlet/sitefilter/http/www.cnn.com/WORLD,r;) Just sits there for ever. Its possible that reptile is misbehaving, although this URL works fine in a browser, and in any case fopen shouldn't just sit there. -- Edit bug report at http://bugs.php.net/?id=20759edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20759r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20759r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20759r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20759r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20759r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20759r=support Expected behavior: http://bugs.php.net/fix.php?id=20759r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20759r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20759r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20759r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20759r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20759r=dst IIS Stability: http://bugs.php.net/fix.php?id=20759r=isapi
#20760 [NEW]: strange behaviour regarding $this
From: [EMAIL PROTECTED]
Operating system: RedHat 8.0
PHP version: 4.2.2
PHP Bug Type: Zend Engine 2 problem
Bug description: strange behaviour regarding $this
We have found a strange behaviour regarding $this. One of our programmers
made a mistake during programming, which led to Heisenbugs, which were
not quite easy to find and fix. We could reduce the problem to a simple
program to present it:
?
class Foo {
var $bla;
function quux() {
$this-bla = 5;
}
}
class Bar {
var $bla;
function do_stuff() {
$this-bla = 10;
Foo::quux();
echo $this-bla;
}
}
$blabla = new Bar;
$blabla-do_stuff();
?
The output is: 5
Obviously, Bar::do_stuff() is not allowed to call Foo::quux() since
Foo::quux() is using $this. Now the strange thing comes: instead of
casting an error, PHP happily accepts the code. But the $this in Foo::quux
is the same $this as in Bar::do_stuff(), i.e. $blabla, and that's why the
output is 5. Is this behaviour intended? At least I couldn't find it
documented anywhere. IMO the user should be warned when $this is used in a
static function.
--
Edit bug report at http://bugs.php.net/?id=20760edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20760r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20760r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20760r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20760r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20760r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20760r=support
Expected behavior: http://bugs.php.net/fix.php?id=20760r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20760r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20760r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20760r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20760r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20760r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20760r=isapi
#20759 [Opn-Fbk]: fopen sometimes hangs
ID: 20759 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: HTTP related Operating System: Linux PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip In PHP 4.3, there is a new ini setting which allows setting a default timeout. Please try PHP-4.3.0RC2 from http://qa.php.net. Be sure to read the NEWS file for info about the timeout option. (the default is 60 seconds). Previous Comments: [2002-12-02 04:21:55] [EMAIL PROTECTED] Sometimes fopen of an http URL just sits there - no error, no results, typically when it does this PHP refuses to output ANY output for that page. FOr example fopen(http://anyurl.com,r;) works fine but fopen(http://reptile.peerfear.org/reptile/servlet/sitefilter/http/www.cnn.com/WORLD,r;) Just sits there for ever. Its possible that reptile is misbehaving, although this URL works fine in a browser, and in any case fopen shouldn't just sit there. -- Edit this bug report at http://bugs.php.net/?id=20759edit=1
#20758 [Opn-Fbk]: php_value without value causes apache to crash
ID: 20758 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: any PHP Version: 4.2.3 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Previous Comments: [2002-12-02 04:20:10] [EMAIL PROTECTED] i found out that if I pass php_value mysql.default_password without given password, it causes apache to crash Of course, the input is incorrect, but it should be ignored probably (or used as empty) and should not cause apache to crash. -- Edit this bug report at http://bugs.php.net/?id=20758edit=1
#20758 [Fbk-Opn]: php_value without value causes apache to crash
ID: 20758 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: any PHP Version: 4.2.3 New Comment: Hopsa, maybe i usd wrong words. as 'crash' I meaned that apache exits: [Mon Dec 2 08:40:21 2002] [notice] SIGHUP received. Attempting to restart Syntax error on line 270 of /usr/local/etc/apache/httpd.conf: php_value takes two arguments, PHP Value Modifier No core is dumped. Previous Comments: [2002-12-02 04:27:03] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2002-12-02 04:20:10] [EMAIL PROTECTED] i found out that if I pass php_value mysql.default_password without given password, it causes apache to crash Of course, the input is incorrect, but it should be ignored probably (or used as empty) and should not cause apache to crash. -- Edit this bug report at http://bugs.php.net/?id=20758edit=1
#20758 [Opn-Bgs]: php_value without value causes apache to crash
ID: 20758 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: any PHP Version: 4.2.3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Not a bug, use: php_value mysql.default_password none Derick Previous Comments: [2002-12-02 04:37:22] [EMAIL PROTECTED] Hopsa, maybe i usd wrong words. as 'crash' I meaned that apache exits: [Mon Dec 2 08:40:21 2002] [notice] SIGHUP received. Attempting to restart Syntax error on line 270 of /usr/local/etc/apache/httpd.conf: php_value takes two arguments, PHP Value Modifier No core is dumped. [2002-12-02 04:27:03] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2002-12-02 04:20:10] [EMAIL PROTECTED] i found out that if I pass php_value mysql.default_password without given password, it causes apache to crash Of course, the input is incorrect, but it should be ignored probably (or used as empty) and should not cause apache to crash. -- Edit this bug report at http://bugs.php.net/?id=20758edit=1
#20758 [Bgs-Opn]: php_value without value causes apache to crash
ID: 20758 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open -Bug Type: Reproducible crash +Bug Type: Feature/Change Request Operating System: any PHP Version: 4.2.3 New Comment: The reason why I asked is php not to exit if no password is given for any reason. Let's say it different way - It would be nice if PHP would continue operations even if someone forgots to fill value. The directive should be ignored in that case. Previous Comments: [2002-12-02 04:44:42] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Not a bug, use: php_value mysql.default_password none Derick [2002-12-02 04:37:22] [EMAIL PROTECTED] Hopsa, maybe i usd wrong words. as 'crash' I meaned that apache exits: [Mon Dec 2 08:40:21 2002] [notice] SIGHUP received. Attempting to restart Syntax error on line 270 of /usr/local/etc/apache/httpd.conf: php_value takes two arguments, PHP Value Modifier No core is dumped. [2002-12-02 04:27:03] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2002-12-02 04:20:10] [EMAIL PROTECTED] i found out that if I pass php_value mysql.default_password without given password, it causes apache to crash Of course, the input is incorrect, but it should be ignored probably (or used as empty) and should not cause apache to crash. -- Edit this bug report at http://bugs.php.net/?id=20758edit=1
#20758 [Opn-Bgs]: php_value without value causes apache to crash
ID: 20758 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type:Feature/Change Request PHP Version: 4.2.3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. It's not a PHP thing, but an Apache requirement. Please leave the status to bogus, as it is not a bug. Previous Comments: [2002-12-02 04:50:51] [EMAIL PROTECTED] The reason why I asked is php not to exit if no password is given for any reason. Let's say it different way - It would be nice if PHP would continue operations even if someone forgots to fill value. The directive should be ignored in that case. [2002-12-02 04:44:42] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Not a bug, use: php_value mysql.default_password none Derick [2002-12-02 04:37:22] [EMAIL PROTECTED] Hopsa, maybe i usd wrong words. as 'crash' I meaned that apache exits: [Mon Dec 2 08:40:21 2002] [notice] SIGHUP received. Attempting to restart Syntax error on line 270 of /usr/local/etc/apache/httpd.conf: php_value takes two arguments, PHP Value Modifier No core is dumped. [2002-12-02 04:27:03] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2002-12-02 04:20:10] [EMAIL PROTECTED] i found out that if I pass php_value mysql.default_password without given password, it causes apache to crash Of course, the input is incorrect, but it should be ignored probably (or used as empty) and should not cause apache to crash. -- Edit this bug report at http://bugs.php.net/?id=20758edit=1
#18152 [Opn-Csd]: Feature Request SNMP V3
ID: 18152 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Any PHP Version: 4.2.1 New Comment: SNMPv3 is supported from the next version to be released, version 4.3.0. Previous Comments: [2002-07-03 18:31:09] [EMAIL PROTECTED] Just a Feature Request... It will be nice to have SNMP V3 Support on PHP. -- Edit this bug report at http://bugs.php.net/?id=18152edit=1
#20759 [Fbk-Opn]: fopen sometimes hangs
ID: 20759 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: HTTP related Operating System: Linux PHP Version: 4.2.3 New Comment: Thanks for the suggestion, but the PHP timeout isn't the problem - its fopen that is hanging. It should fail allowing the script to handle the error gracefully (in my case moving on to the next URL). The PHP timeout only fails the whole PHP script if nothing happens in 60 seconds. Previous Comments: [2002-12-02 04:24:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip In PHP 4.3, there is a new ini setting which allows setting a default timeout. Please try PHP-4.3.0RC2 from http://qa.php.net. Be sure to read the NEWS file for info about the timeout option. (the default is 60 seconds). [2002-12-02 04:21:55] [EMAIL PROTECTED] Sometimes fopen of an http URL just sits there - no error, no results, typically when it does this PHP refuses to output ANY output for that page. FOr example fopen(http://anyurl.com,r;) works fine but fopen(http://reptile.peerfear.org/reptile/servlet/sitefilter/http/www.cnn.com/WORLD,r;) Just sits there for ever. Its possible that reptile is misbehaving, although this URL works fine in a browser, and in any case fopen shouldn't just sit there. -- Edit this bug report at http://bugs.php.net/?id=20759edit=1
#20759 [Opn-Fbk]: fopen sometimes hangs
ID: 20759 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: HTTP related Operating System: Linux PHP Version: 4.2.3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Try the PHP 4.3.0RC2 and check php.ini-dist, you will find this: ; Default timeout for socket based streams (seconds) default_socket_timeout = 60 Previous Comments: [2002-12-02 05:07:54] [EMAIL PROTECTED] Thanks for the suggestion, but the PHP timeout isn't the problem - its fopen that is hanging. It should fail allowing the script to handle the error gracefully (in my case moving on to the next URL). The PHP timeout only fails the whole PHP script if nothing happens in 60 seconds. [2002-12-02 04:24:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip In PHP 4.3, there is a new ini setting which allows setting a default timeout. Please try PHP-4.3.0RC2 from http://qa.php.net. Be sure to read the NEWS file for info about the timeout option. (the default is 60 seconds). [2002-12-02 04:21:55] [EMAIL PROTECTED] Sometimes fopen of an http URL just sits there - no error, no results, typically when it does this PHP refuses to output ANY output for that page. FOr example fopen(http://anyurl.com,r;) works fine but fopen(http://reptile.peerfear.org/reptile/servlet/sitefilter/http/www.cnn.com/WORLD,r;) Just sits there for ever. Its possible that reptile is misbehaving, although this URL works fine in a browser, and in any case fopen shouldn't just sit there. -- Edit this bug report at http://bugs.php.net/?id=20759edit=1
#18600 [Com]: Unable to create Java Virtual Machine
ID: 18600 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Java related Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: Hi, I'm reporting the same error using: Win2k Server apache_2.0.36-win32-x86-no_ssl.msi php4-win32-latest.zip (PHP Version 4.2.3) j2sdk-1_4_1_01-windows-i586.exe or (jdk-1_2_2_014-windows-i586.exe) ... I've got periods of errors and periods of success when instantiating $system = new Java(java.lang.System); from within PHP. Error message is: Fatal error: Unable to create Java Virtual Machine in ... I see a lot of such bug reports around but still no solution ;-(. Any ideas? Thanx Alberto Previous Comments: [2002-11-28 07:19:46] [EMAIL PROTECTED] Hi I'm asking it again: Is anyone using sablotron (ext/xslt) together with the java extension, then you're in bad luck, because: sablotron 0.97 and jdk = 1.3 does not work together. Sablotron 0.97 is not out yet, but there is an RC1 in their CVS (didn't find a link to download it), which should solve the problem.. try not loading the sablotron extension and see if it solves the problem unix people which have problem with even starting up, should try the symlink trick: make a symlink from java.so to libphp_java.so and see if that works. chregu [2002-11-05 05:43:54] [EMAIL PROTECTED] I am also seeing this bug, unfortunatly I'm running apache 1.x on Solaris 8. Works fine for a little while, then stops working after a number of requests. I can stop the symtoms by turning off keep-alive in apache or by reducing the requests per child to a very low number. Of course, none of these solutions are acceptable. I am trying to test 4.3.0pre2 just now but having compilation errors. More later. [2002-10-31 08:51:16] [EMAIL PROTECTED] Yeah the only real issue I can see here is that this is a Windows specific issue. I've looked through the the DSP file, and read up on specific linking issues in Windows... everything looks right from the end of PHP. I'm guessing this can be one of (or possibly all of) these things: A) specific to a JVM version - in which case we'd need to find out which one works, and then update the specific hooks into PHP to use the newer versions. B) Windows not liking Java at all - not much we can do about that. C) specific to PHP alone - in which case someone with more Windows dev experience will have to take a look at this. As I don't see any real issue with the way we're linking and calling things (beyond the really resource intensive comments). [2002-10-31 07:44:50] [EMAIL PROTECTED] I found this problem using Apache 1.x on Win2k. PHP 4.2.3 causes the JVM create failure (although I couldn't get any access violations). Under IIS4 , the access violation causes some serious problems, albeit intermittently. I found that starting small with Java-inclusive scripts allowed some java work to be done (such as retrieving JVM versions, etc). However, when I started some more serious Java work with some custom classes I got both the JVM create failure and an access violation which crashed IIS. A reboot was necessary to bring IIS back up (Win2k wouldn't even let me force kill the process!!). I took a look at the latest snapshot posted below, but this caused an immediate crash in Apache upon starting the service. Any other suggestions? [2002-09-27 12:00:04] [EMAIL PROTECTED] just to add to the list of symptoms. First time I run a script, I get Warning: Unknown list entry type in request shutdown (0) in Unknown on line 0 when the script is ending. The next time I try to load the same script, I get Fatal error: Unable to create Java Virtual Machine in c:\web\qvc\reports\test.php on line 2 win2k, j2sdk1.4, php 4.2.3. Does that help? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18600 -- Edit this bug report at http://bugs.php.net/?id=18600edit=1
#20761 [NEW]: undefined funcion mail()
From: [EMAIL PROTECTED]
Operating system: Linux 2.4.19
PHP version: 4.3.0RC2
PHP Bug Type: Mail related
Bug description: undefined funcion mail()
I'm using php on apache2.0.43 and
i've upgraded from php-4.4-dev to php-4.3RC2 and i get this error on a
formmail based on php:
PHP Fatal error: Call to undefined function: mail() in
/web/htdocs//home/mail_guest.php on line 15
Here it's the html that do the post:
--
html
head
meta http-equiv=Content-Language content=it
meta http-equiv=Content-Type content=text/html;
charset=windows-1252
meta name=GENERATOR content=Microsoft FrontPage 4.0
meta name=ProgId content=FrontPage.Editor.Document
titlemail in php/title
/head
body
div align=center
center
table border=0 cellpadding=0 cellspacing=0 width=90%
tr
td width=100% align=center
form method=POST action=mail_guest.php
pfont face=Verdana
size=1nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;/font/p
p/centerfont face=Verdana size=1input type=text
name=titolo size=20
titolo della mail/font/p
center
pfont face=Verdana size=1textarea rows=4
name=messaggio cols=28/textareatesto
della mail/font/p
pfont face=Verdana size=1input type=submit
value=Invia name=B1input type=reset value=Reimposta
name=B2/font/p
input type=hidden name=indirizzo
value=[EMAIL PROTECTED]
/form
pnbsp;/center/td
/tr
/table
/div
/body
/html
-
and here it's the mail_guest.php
html
head
titleinvio_mail_php_ricezione/title
/head
body bgcolor=#ffcb8c
pfont face=Verdana size=1
?
{
mail($indirizzo, $titolo, $messaggio);
echo Messaggio spedito a: . $indirizzo .br;
echo Oggetto: . $titolo .br;
echo Body: . $messaggio .br;
}
?
/font/p
/body
/html
--
Before upgrade to php-4.3RC2 this script works.
I've compiled with this options:
'./configure' '--with-mysql=/usr' '--with-jpeg-dir=/usr/lib/'
'--with-zlib' '--with-png-dir=/usr/lib'
'--with-config-file-path=/web/conf/' '--with-apxs2=/web/bin/apxs'
'--with-gd' '--disable-debug' '--enable-inline-optimization'
'--enable-memory-limit'
Regards.
--
Edit bug report at http://bugs.php.net/?id=20761edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20761r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20761r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20761r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20761r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20761r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20761r=support
Expected behavior: http://bugs.php.net/fix.php?id=20761r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20761r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20761r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20761r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20761r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20761r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20761r=isapi
#20761 [Opn-Fbk]: undefined funcion mail()
ID: 20761
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Mail related
Operating System: Linux 2.4.19
PHP Version: 4.3.0RC2
New Comment:
Please issue the following commands in your shell (and make sure you
have autoconf version 2.13 installed):
cd php-4.3.0rc2
rm configure
./buildconf
and rerun configure/make
Derick
Previous Comments:
[2002-12-02 05:36:22] [EMAIL PROTECTED]
I'm using php on apache2.0.43 and
i've upgraded from php-4.4-dev to php-4.3RC2 and i get this error on a
formmail based on php:
PHP Fatal error: Call to undefined function: mail() in
/web/htdocs//home/mail_guest.php on line 15
Here it's the html that do the post:
--
html
head
meta http-equiv=Content-Language content=it
meta http-equiv=Content-Type content=text/html;
charset=windows-1252
meta name=GENERATOR content=Microsoft FrontPage 4.0
meta name=ProgId content=FrontPage.Editor.Document
titlemail in php/title
/head
body
div align=center
center
table border=0 cellpadding=0 cellspacing=0 width=90%
tr
td width=100% align=center
form method=POST action=mail_guest.php
pfont face=Verdana
size=1nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;/font/p
p/centerfont face=Verdana size=1input type=text
name=titolo size=20
titolo della mail/font/p
center
pfont face=Verdana size=1textarea rows=4
name=messaggio cols=28/textareatesto
della mail/font/p
pfont face=Verdana size=1input type=submit
value=Invia name=B1input type=reset value=Reimposta
name=B2/font/p
input type=hidden name=indirizzo
value=[EMAIL PROTECTED]
/form
pnbsp;/center/td
/tr
/table
/div
/body
/html
-
and here it's the mail_guest.php
html
head
titleinvio_mail_php_ricezione/title
/head
body bgcolor=#ffcb8c
pfont face=Verdana size=1
?
{
mail($indirizzo, $titolo, $messaggio);
echo Messaggio spedito a: . $indirizzo .br;
echo Oggetto: . $titolo .br;
echo Body: . $messaggio .br;
}
?
/font/p
/body
/html
--
Before upgrade to php-4.3RC2 this script works.
I've compiled with this options:
'./configure' '--with-mysql=/usr' '--with-jpeg-dir=/usr/lib/'
'--with-zlib' '--with-png-dir=/usr/lib'
'--with-config-file-path=/web/conf/' '--with-apxs2=/web/bin/apxs'
'--with-gd' '--disable-debug' '--enable-inline-optimization'
'--enable-memory-limit'
Regards.
--
Edit this bug report at http://bugs.php.net/?id=20761edit=1
#18476 [Com]: imap + kerberos + lgssapi_krb5
ID: 18476 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: openbsd 3.1 PHP Version: 4.2.1 New Comment: Hello, It seems that openbsd put the required asn1 stuff in libasn1, not k5crypto for now sed s/-lk5crypto/-lasn1/ configure configure should do the trick Previous Comments: [2002-07-22 21:05:17] [EMAIL PROTECTED] It really isn't our fault if your system doesn't have the necessary libs..just install them and make sure the header files are under same prefix. [2002-07-22 16:59:25] [EMAIL PROTECTED] ./configure --with-mysql --with-gettext --with-xml --with-apxs=/usr/local/apache/bin/apxs --with-imap --with-kerberos --with-imap-ssl imap says kerberos and imap-ssl are required bc the openbsd 3.1 package for c-client has them compiled in gcc -o conftest -g -O2 -DMOD_SSL=208110 -DEAPI -DUSE_EXPAT -R/usr/local/lib -L/usr/local/lib conftest.c -lintl -lresolv -lm -lresolv -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err 15 ld: -lgssapi_krb5: no match collect2: ld returned 1 exit status it would appear i'm missing some kerberos libs. There are no other kerberos packages in the ports collection. If I indeed need this lib it's apparantly not required by a kerberos install as openbsd does this by default. -- Edit this bug report at http://bugs.php.net/?id=18476edit=1
#20449 [Com]: sessions randomly fail
ID: 20449 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.4.0-dev New Comment: [General Message - Not Bug Specific] In the past 12 months, I've raised a number of bugs relating to session problems that could not be reproduced consistently with the standard reply of 'its been fixed in CVS/Try CVS version'. I've tried the new CVS version and problems still continue (but still erratically). Over time, I've noticed a lot of developers problems (bugs) seem to be related to the global $_SESSION variable and I personally feel that the most stable session module is still in PHP version 4.0.6 before introduction in the 4.1 series. I'm not a hardened programmer, so this is a call to the current and previous developers/maintainers to consider a complete design and code walkthrough of the 'session related' code. Personally, I feel sessions is one of the key feature areas of PHP and something that needs to be highlighted to both Zend and the community to be made 'rock-solid'. Thanks Nick Previous Comments: [2002-11-25 18:22:39] [EMAIL PROTECTED] After a good weekend we are having an incredible Monday. My code in place now uses serialize/unserialize. I also convert my arrays to strings with implode/explode before the serialization/unserialization process. I don't see any missing information anymore in my session table. I really think the session serialize code is at fault for this bug. Specifically I think it simply doesn't handle arrays. (perhaps objects but my object simply had the array in it. Removing the array from the object and not using objects did not work) This is an extremely serious bug that was costing us on average of about 30-50 orders a day. I am honestly not exaggerating on this figure. I tried the CVS version as late as 11-15-2002 and it still had the bug in it. Before that I was using the latest 4.2.3 version. I'd like a little feedback from the developers to at least say they are looking into it. I will try to assist in any way I can. However, as I have said before, it was very random and I myself never saw my session disappear. Also important to note is that I do not rely on Session Cookies so it is not related to cookies. Also, I tried doing the reset(arrayvar) after each session restoration as suggested on one of the session man pages. That too did not work. I hesitate to say but I really think it would be important to make note to people that the session code is not reliable. Perhaps in the man pages. I won't go to such length though as to warn them myself though I feel some duty to do so. Perhaps the bug only comes into play on high traffic servers. Either which way, not relying on the internal session code has made a huge difference. That in itself should prove something. [2002-11-25 11:46:34] [EMAIL PROTECTED] This seems to be exactly the same problem we are having with one particular visitor to one of my websites. He always has this problem, every time he logs in his session expires. I have gone through his client PC configuration very carefully, and cannot find anything unusual. What's more odd is that he used to be able to use my site without problems. Would this problem manifest itself at random, or would it affect specific PCs? I had assumed the problem was at his end until I read this message thread, and it looked strangely familiar. Jolyon [2002-11-22 16:20:08] [EMAIL PROTECTED] Just thought I'd add that we are having what - seems to be - the same problem. We are running on Solaris 8 and our sessions are being held in a tmpfs mount that's balanced across 4 sun 220's. PHP Version 4.2.2 and Apache 1.3.26 compiled staticly. We've been moving the session store method around thinking I/O was the issue but it hasn't helped. We've done NFS mounted share, local-only share on 1 220 (limiting the load-balancing for one site to only that box) and now tmpfs. Our sessions are rather large (at least for me) normally around 11,316 bytes with objects and arrays w/ members that are serialized objects. It's probably important to note that we are avoiding automatic serialize/deserialize of objects by doing $_SESSION['someName'] = serialize($Object) type stuff. In almost all cases the sessions are there, but a couple values are simply missing. If you need anyother info please let me know. [2002-11-21 21:52:36] [EMAIL PROTECTED] Ok. I think I have a really good idea as to what the bug is. I am pretty sure there is a bug in the session serialization functions. (and perhaps the normal
#18648 [Com]: Single entry form POST gives incorrect variable content
ID: 18648 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: HTTP related Operating System: Tru64 PHP Version: 4.2.2 New Comment: I can't reproduce this problem using identical RPMs on Red Hat Linux 8.0 - this bug seems hard to trigger. [EMAIL PROTECTED] - any further insight would be appreciated. I can't find anything on the CVS logs about fixes for Tru64. There is one fix to main/php_variables.c: 2002-09-07 Yasuo Ohgaki [EMAIL PROTECTED] ... * main/php_variables.c: Fixed POST/GET/COOKIE var handling but this seems to concern NUL-terminated strings in field values, unles I'm mistaken. Previous Comments: [2002-11-18 13:16:23] [EMAIL PROTECTED] I also get the same problem with Linux RH8.0 I'm running apache 2.0.40-8 and php-4.2.2-8.0.5 form action=test.php method=post Test: input type=text name=id value=bar input type=submit /form I tested this workaround by inserting into one of my forms and it works: input type=hidden name=spoof [2002-10-23 08:30:10] [EMAIL PROTECTED] Hi, I get the same problem with Linux RH8.0 using the default RPMs (which includes apache part deux). As a workaround I am adding: input type=hidden name=spoof into my one field forms. thanks, josh. [2002-09-11 11:49:02] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2002-08-15 23:09:06] [EMAIL PROTECTED] Tested this with latest snapshot and Apache 1.3.26 on Tru64, seems to work fine. So Jani might be right with his Apache2-Guess. [2002-08-15 07:15:47] [EMAIL PROTECTED] Common for both cases seems to be Apache2..please try with Apache 1.3.26 (and the latest snapshot from today, url above). Apache2 support is experimental btw. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18648 -- Edit this bug report at http://bugs.php.net/?id=18648edit=1
#20762 [NEW]: Warning compiling with mailparse
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.3.0RC2 PHP Bug Type: Compile Warning Bug description: Warning compiling with mailparse output: [...] /home/wez/src/php/PHPDEV/ext/mailparse/php_mailparse_rfc822.re: In function `tokenize': /home/wez/src/php/PHPDEV/ext/mailparse/php_mailparse_rfc822.re:191: warning: deprecated use of label at end of compound statement [...] I don't have that kind of directories ;) -- Edit bug report at http://bugs.php.net/?id=20762edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20762r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20762r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20762r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20762r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20762r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20762r=support Expected behavior: http://bugs.php.net/fix.php?id=20762r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20762r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20762r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20762r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20762r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20762r=dst IIS Stability: http://bugs.php.net/fix.php?id=20762r=isapi
#20763 [NEW]: PHP crashes with signal 11 while trying to parse message with uncommon headers
From: [EMAIL PROTECTED] Operating system: RH Linux 7.3 PHP version: 4.2.3 PHP Bug Type: IMAP related Bug description: PHP crashes with signal 11 while trying to parse message with uncommon headers Hi, I found two bugs on the imap handling functions in PHP 4.2.3: - If a message contains a header with empty contents (like Reply-to: or Sender: ), the web server running php crashes whenever a script tries to parse this message. I ran Apache 1.3.26 compiled agains ElectricFence and found out that the bug is on _php_make_header_object: if thethe header contents are empty, _php_imap_parse_address won't allocate memory for fulladdress, but the function will call free() on fulladdress nevertheless.This leads to heap corruption and subsequent segmentation fault. - It seems like _php_imap_address_size doesn't compute the header size correctly. If the number of addresses in a field is very large, this leads to a buffer overflow in c-client's rfc822_address. My setup is: Apache 1.3.26 PHP 4.2.3 compiled as a DSO with the following options: /configure --prefix=/data/www/consumer/conf --enable-track-vars --with-imap=/usr/local/app/imap-2002 --with-ldap=/usr/local/app/openldap --with-oracle=/usr/local/app/oracle_client --with-oci8=/usr/local/app/oracle_client --with-apxs=/data/www/consumer/bin/apxs --with-msession=/usr/local/app/phoenix --with-mysql --with-openssl=/usr/local/app/openssl --with-xml --with-curl=/usr/local/app/curl Test messages: - For the first bug: any message with a header field with empty contents (like Sender: ) - For the second bug: any message with a large(In my test there were 500) number of recipients on the To: or Cc: fields. Backtrace for the first bug: 0x4009fa01 in __kill () at __kill:-1 #1 0x0809a69d in EF_Abort (pattern=0x80aa540 free(%a): address not from malloc().) at print.c:137 #2 0x08099f2a in free (address=0x4eacabcc) at efence.c:632 #3 0x404cc5b3 in _php_make_header_object (myzvalue=0x4ec6ffec, en=0x4ee32fbc) at php_imap.c:3724 #4 0x404c186b in zif_imap_headerinfo (ht=2, return_value=0x4ec6ffec, this_ptr=0x0, return_value_used=1) at php_imap.c:1631 #5 0x40482e39 in execute (op_array=0x463affa4) at ./zend_execute.c:1598 #6 0x40493b2c in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:812 #7 0x404a63b6 in php_execute_script (primary_file=0xb6b0) at main.c:1383 #8 0x404a0dbe in apache_php_module_main (r=0x445b9028, display_source_mode=0) at sapi_apache.c:90 #9 0x404a1c2c in send_php (r=0x445b9028, display_source_mode=0, filename=0x445bacc8 /data/www/consumer/htdocs/memail/mailbox.php3) at mod_php4.c:575 #10 0x404a1c99 in send_parsed_php (r=0x445b9028) at mod_php4.c:590 #11 0x08055287 in ap_invoke_handler () #12 0x0806a307 in process_request_internal () #13 0x0806a368 in ap_process_request () #14 0x08061289 in child_main () #15 0x08061458 in make_child () #16 0x080615cc in startup_children () #17 0x08061c44 in standalone_main () #18 0x080624c3 in main () #19 0x4008d507 in __libc_start_main (main=0x8062100 main, argc=2, ubp_av=0xbae4, init=0x804f718 _init, fini=0x809a8f0 _fini, rtld_fini=0x4000dc14 _dl_fini, stack_end=0xbadc) at ../sysdeps/generic/libc-start.c:129 Backtrace for the second bug: #0 0x400f68f7 in strcat () at strcat:-1 #1 0x4f5e7fe8 in ?? () #2 0x405b74b9 in rfc822_write_address_full ( dest=0x4faa36a8 \[EMAIL PROTECTED]\ [EMAIL PROTECTED], \[EMAIL PROTECTED]\ [EMAIL PROTECTED], \[EMAIL PROTECTED]\ [EMAIL PROTECTED], \[EMAIL PROTECTED]\ agre..., adr=0x4eea7fe8, base=0x0) at rfc822.c:193 #3 0x404cbce6 in _php_imap_parse_address (addresslist=0x4eea7fe8, fulladdress=0xbfff472c, paddress=0x4f6eafec) at php_imap.c:3626 #4 0x404cc173 in _php_make_header_object (myzvalue=0x4f6adfec, en=0x4eba5fbc) at php_imap.c:3667 #5 0x404c186b in zif_imap_headerinfo (ht=2, return_value=0x4f6adfec, this_ptr=0x0, return_value_used=1) at php_imap.c:1631 #6 0x40482e39 in execute (op_array=0x446b1fa4) at ./zend_execute.c:1598 #7 0x40493b2c in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:812 #8 0x404a63b6 in php_execute_script (primary_file=0xb6d0) at main.c:1383 #9 0x404a0dbe in apache_php_module_main (r=0x445b9028, display_source_mode=0) at sapi_apache.c:90 #10 0x404a1c2c in send_php (r=0x445b9028, display_source_mode=0, filename=0x445bace8 /data/www/consumer/htdocs/memail/mailbox.php3) at mod_php4.c:575 #11 0x404a1c99 in send_parsed_php (r=0x445b9028) at mod_php4.c:590 #12 0x08055287 in ap_invoke_handler () #13 0x0806a307 in process_request_internal () #14 0x0806a368 in ap_process_request () #15 0x08061289 in child_main () #16 0x08061458 in make_child () #17 0x080615cc in startup_children () #18 0x08061c44 in standalone_main () #19 0x080624c3 in main () #20 0x4008d507 in __libc_start_main (main=0x8062100 main, argc=2, ubp_av=0xbb04, init=0x804f718 _init, fini=0x809a8f0 _fini,
#20763 [Opn-Fbk]: PHP crashes with signal 11 while trying to parse message with uncommon headers
ID: 20763 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: IMAP related Operating System: RH Linux 7.3 PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip I do believe this was recently delt with Previous Comments: [2002-12-02 09:17:23] [EMAIL PROTECTED] Hi, I found two bugs on the imap handling functions in PHP 4.2.3: - If a message contains a header with empty contents (like Reply-to: or Sender: ), the web server running php crashes whenever a script tries to parse this message. I ran Apache 1.3.26 compiled agains ElectricFence and found out that the bug is on _php_make_header_object: if thethe header contents are empty, _php_imap_parse_address won't allocate memory for fulladdress, but the function will call free() on fulladdress nevertheless.This leads to heap corruption and subsequent segmentation fault. - It seems like _php_imap_address_size doesn't compute the header size correctly. If the number of addresses in a field is very large, this leads to a buffer overflow in c-client's rfc822_address. My setup is: Apache 1.3.26 PHP 4.2.3 compiled as a DSO with the following options: /configure --prefix=/data/www/consumer/conf --enable-track-vars --with-imap=/usr/local/app/imap-2002 --with-ldap=/usr/local/app/openldap --with-oracle=/usr/local/app/oracle_client --with-oci8=/usr/local/app/oracle_client --with-apxs=/data/www/consumer/bin/apxs --with-msession=/usr/local/app/phoenix --with-mysql --with-openssl=/usr/local/app/openssl --with-xml --with-curl=/usr/local/app/curl Test messages: - For the first bug: any message with a header field with empty contents (like Sender: ) - For the second bug: any message with a large(In my test there were 500) number of recipients on the To: or Cc: fields. Backtrace for the first bug: 0x4009fa01 in __kill () at __kill:-1 #1 0x0809a69d in EF_Abort (pattern=0x80aa540 free(%a): address not from malloc().) at print.c:137 #2 0x08099f2a in free (address=0x4eacabcc) at efence.c:632 #3 0x404cc5b3 in _php_make_header_object (myzvalue=0x4ec6ffec, en=0x4ee32fbc) at php_imap.c:3724 #4 0x404c186b in zif_imap_headerinfo (ht=2, return_value=0x4ec6ffec, this_ptr=0x0, return_value_used=1) at php_imap.c:1631 #5 0x40482e39 in execute (op_array=0x463affa4) at ./zend_execute.c:1598 #6 0x40493b2c in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:812 #7 0x404a63b6 in php_execute_script (primary_file=0xb6b0) at main.c:1383 #8 0x404a0dbe in apache_php_module_main (r=0x445b9028, display_source_mode=0) at sapi_apache.c:90 #9 0x404a1c2c in send_php (r=0x445b9028, display_source_mode=0, filename=0x445bacc8 /data/www/consumer/htdocs/memail/mailbox.php3) at mod_php4.c:575 #10 0x404a1c99 in send_parsed_php (r=0x445b9028) at mod_php4.c:590 #11 0x08055287 in ap_invoke_handler () #12 0x0806a307 in process_request_internal () #13 0x0806a368 in ap_process_request () #14 0x08061289 in child_main () #15 0x08061458 in make_child () #16 0x080615cc in startup_children () #17 0x08061c44 in standalone_main () #18 0x080624c3 in main () #19 0x4008d507 in __libc_start_main (main=0x8062100 main, argc=2, ubp_av=0xbae4, init=0x804f718 _init, fini=0x809a8f0 _fini, rtld_fini=0x4000dc14 _dl_fini, stack_end=0xbadc) at ../sysdeps/generic/libc-start.c:129 Backtrace for the second bug: #0 0x400f68f7 in strcat () at strcat:-1 #1 0x4f5e7fe8 in ?? () #2 0x405b74b9 in rfc822_write_address_full ( dest=0x4faa36a8 \[EMAIL PROTECTED]\ [EMAIL PROTECTED], \[EMAIL PROTECTED]\ [EMAIL PROTECTED], \[EMAIL PROTECTED]\ [EMAIL PROTECTED], \[EMAIL PROTECTED]\ agre..., adr=0x4eea7fe8, base=0x0) at rfc822.c:193 #3 0x404cbce6 in _php_imap_parse_address (addresslist=0x4eea7fe8, fulladdress=0xbfff472c, paddress=0x4f6eafec) at php_imap.c:3626 #4 0x404cc173 in _php_make_header_object (myzvalue=0x4f6adfec, en=0x4eba5fbc) at php_imap.c:3667 #5 0x404c186b in zif_imap_headerinfo (ht=2, return_value=0x4f6adfec, this_ptr=0x0, return_value_used=1) at php_imap.c:1631 #6 0x40482e39 in execute (op_array=0x446b1fa4) at ./zend_execute.c:1598 #7 0x40493b2c in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:812 #8 0x404a63b6 in php_execute_script (primary_file=0xb6d0) at main.c:1383 #9 0x404a0dbe in apache_php_module_main (r=0x445b9028, display_source_mode=0) at sapi_apache.c:90 #10 0x404a1c2c in send_php (r=0x445b9028, display_source_mode=0, filename=0x445bace8 /data/www/consumer/htdocs/memail/mailbox.php3) at mod_php4.c:575 #11 0x404a1c99 in send_parsed_php (r=0x445b9028) at mod_php4.c:590 #12 0x08055287 in ap_invoke_handler () #13 0x0806a307 in process_request_internal
#13053 [Com]: oci8 error, this kill oracle-prosseces in the oracle-instance.
ID: 13053 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: OCI8 related Operating System: sun solaris 64 bits PHP Version: 4.0.6 New Comment: Hi, The last news about our ORA-24327 error We changed the version of php into 4.2.3 and it seems that the connection failed problem has disappeared. Thanx for your advice, Caroline :o) Previous Comments: [2002-11-26 10:37:00] [EMAIL PROTECTED] Yes. Try the lastest CVS from snaps.php.net and, if this still happens, give us some more details. [2002-11-26 04:22:55] [EMAIL PROTECTED] I have exactly the same problem with PHP 4.1.1 Do I need to change the php version to solve this bug ? [2002-04-13 08:51:25] [EMAIL PROTECTED] The version of PHP that this bug was reported in is too old. Please try to reproduce this bug in the latest version of PHP (available from http://www.php.net/downloads.php If you are still able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. [2001-08-30 05:34:29] [EMAIL PROTECTED] Oci statement faild: My error is: Warning: OCISessionBegin: ORA-24327: need explicit attach before authenticating a user and Supplied argument is not a valid OCI8-Connection resource and some rollback error as well. regards Jan Arve -- Edit this bug report at http://bugs.php.net/?id=13053edit=1
#20753 [Fbk-Bgs]: php.ini not read
ID: 20753 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Bogus Bug Type: PHP options/info functions Operating System: WinXP PHP Version: 4.2.3 New Comment: This *is* bug (for MS), but also a support issue (for PHP). Turns out that WinXP refuses to display the final .ini extension, even in the properties display, the file-rename box, or the details list; my file had actually been named php.ini.ini, and all I could ever see at all in any GUI was php.ini (except when I finally used the command line prompt). Sorry for taking your time, but this is an extremely subtle problem: perhaps the documentation could mention that the renaming and name-checking must happen in the command prompt (DOS), because otherwise there will be no error that the file wasn't found. Take care! Previous Comments: [2002-12-01 23:12:43] [EMAIL PROTECTED] OK, finally got it working: here's the top of phpinfo(): PHP Version 4.4.0-dev System Windows NT localhost 5.1 build 2600 Build Date Dec 2 2002 04:12:18 Server API Apache Virtual Directory Support enabled Configuration File (php.ini) Path C:\WINDOWS PHP API 20020918 Right below, it shows: Directive Local Value Master Value allow_call_time_pass_reference On On allow_url_fopen On On The file c:\windows\php.ini still has these entries: allow_call_time_pass_reference = Off allow_url_fopen = Off So it looks like even the CVS snapshot is ignoring the php.ini file it expects to see. Glad it doesn't want c:\winnt any more; that's an improvement. But the bug (or support issue) remains... [2002-12-01 22:07:30] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-01 21:55:37] [EMAIL PROTECTED] I assume you mean what phpinfo() prints out in the table at the top (I've clipped it here): System Windows NT 5.1 build 2600 Build Date Sep 6 2002 10:38:51 Server API Apache Virtual Directory Support enabled Configuration File (php.ini) Path c:\winnt Debug Build no Thread Safety enabled I'd be happy to try changing c:\winnt to some other directory, but I have no idea how to, or where that is configured. [2002-12-01 19:49:43] [EMAIL PROTECTED] This is most likely another support question, but let's try help you anyway: What is said by phpinfo() for where it's trying to read php.ini from? [2002-12-01 18:53:36] [EMAIL PROTECTED] This is nearly identical to bug #20540, except I've got today's PHP version (and I'm someone else!). I've got php on apache working, phpinfo() says the configuration file path is c:\winnt (although everything else on this system is in c:\windows, and I had to create c:\winnt just to try and satisfy php). But the php.ini in c:\winnt still isn't being read, as judged by a couple changes (allow_call_time_pass_referece and url_fopen which I've set to non-default values). Yes, I'm restarting Apache; yes, I'm force-refreshing my browser; yes, I've verified there are no other php.ini files on the machine. I've even tried inserting syntax errors into php.ini, and moving it to the system32 directory or the c:\windows directory... no luck. I can't make that file have any effect at all. I've built and installed php a zillion times on Linux, and never had this problem. And I *hate* Windows. But I have to make this work to be able to use the gd extensions and image functions, and I'm pretty sure this bug is NOT bogus, since two of us are independently reporting the same thing in the same week. Any suggestions? -- Edit this bug report at http://bugs.php.net/?id=20753edit=1
#20764 [NEW]: session_handler=mm complais about mm_malloc
From: [EMAIL PROTECTED] Operating system: RH7.2 PHP version: 4.2.3 PHP Bug Type: Session related Bug description: session_handler=mm complais about mm_malloc I saw another thread about this bug: http://bugs.php.net/bug.php?id=19039 I've compiled PHP-4.2.3 to apache 1.3.27 including --with-mm (mm-1.1.3-8 devel packages installed). When using sessions (save_handler=mm) in PHP, it complains: Warning: mm_malloc failed, avail 0, err mm:core: Failed to lock (Permission denied) in Unknown on line 0 Seems to be some kind of permission problem in SHM. Not sure though what is wrong. -- Edit bug report at http://bugs.php.net/?id=20764edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20764r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20764r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20764r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20764r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20764r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20764r=support Expected behavior: http://bugs.php.net/fix.php?id=20764r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20764r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20764r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20764r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20764r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20764r=dst IIS Stability: http://bugs.php.net/fix.php?id=20764r=isapi
#20751 [Com]: Mail: undefined function
ID: 20751 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Mail related Operating System: Linux Redhat 7.2 PHP Version: 4.3.0RC2 New Comment: I have resolved the problem adding a symbolic link from /var/qmail/bin/sendmail to /usr/bin/sendmail and now it works. The configure script doesn't search in /usr/sbin but only in /usr/bin. Please correct this problem Previous Comments: [2002-12-02 03:04:30] [EMAIL PROTECTED] Yes, it works. [2002-12-01 17:00:38] [EMAIL PROTECTED] Try this on your cmd line: # test -f /sbin/sendmail echo works (it should print 'works') [2002-12-01 16:45:53] [EMAIL PROTECTED] Qmail is configured with virtual links from: /sbin/sendmail /usr/sbin/sendmail /usr/lib/sendmail to /var/qmail/bin/sendmail as suggested in qmail documentation [2002-12-01 16:42:46] [EMAIL PROTECTED] Yes. The user is root. [2002-12-01 16:28:41] [EMAIL PROTECTED] Does the user you're compiling PHP as have rights to access the sendmail binary on your system? (qmail does add some wrapper binary for sendmail, and it works fine here..) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20751 -- Edit this bug report at http://bugs.php.net/?id=20751edit=1
#20765 [NEW]: problem with array_search function
From: [EMAIL PROTECTED] Operating system: Windows XP PHP version: 4.2.3 PHP Bug Type: Scripting Engine problem Bug description: problem with array_search function array_search will return THE POSITION of the NEEDLE when a needle is found in an array and return FALSE when not found. The problem will occur when the NEEDLE is found to be at the first position of an array which will return a 0, a value that is equipvalent to FALSE though the NEEDLE has been successfully found. -- Edit bug report at http://bugs.php.net/?id=20765edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20765r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20765r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20765r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20765r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20765r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20765r=support Expected behavior: http://bugs.php.net/fix.php?id=20765r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20765r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20765r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20765r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20765r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20765r=dst IIS Stability: http://bugs.php.net/fix.php?id=20765r=isapi
#20765 [Opn-Bgs]: problem with array_search function
ID: 20765 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 4.2.3 New Comment: There is a warning in the docs, I'll quote it here: This function may return Boolean FALSE, but may also return a non-Boolean value which evaluates to FALSE, such as 0 or . Please read the section on Booleans for more information. Use the === operator for testing the return value of this function. This comes from the return.falseproblem; entity in the docs. Previous Comments: [2002-12-02 11:10:15] [EMAIL PROTECTED] array_search will return THE POSITION of the NEEDLE when a needle is found in an array and return FALSE when not found. The problem will occur when the NEEDLE is found to be at the first position of an array which will return a 0, a value that is equipvalent to FALSE though the NEEDLE has been successfully found. -- Edit this bug report at http://bugs.php.net/?id=20765edit=1
#14822 [Com]: Premature end of script headers: C:/php/php.exe
ID: 14822 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: windows xp professional PHP Version: 4.1.0 New Comment: I had this problem as well on XP. I changed the line Action application/x-httpd-php /php/php.exe to Action application/x-httpd-php /php/php-cgi.exe in httpd.conf and this seemed to work. I don't know why. Hope this helps. Previous Comments: [2002-10-04 08:31:04] [EMAIL PROTECTED] well, same thing is here... OS winXP, the problem is not just related to Apache2 according to my understanding, since i've uninstalled it, and installed the apache 1.3... and the same 500 internal error, Premature end of script headers: D:/php/core/php.exe now the thing is that as long as i try to run php files in the root directory, it works, but the same file, containging ? echo hello ? and nothing else wont work in any sub folder it will only be executed by the php.exe (ver 2 and i tried more than one... always the same). Now everything worked a week ago, and stoped working, the minute i added a user in the XP pro. priviously i had only one user who was the administrator and no login to XP was needed. Then i've added a new user, gave that new user administrators premissions and gave the old user limited permissions. the next time i tried to do somthing in a sub folder of localhost/Any_Sub_Folder/phpFile.php, won't work and gives the error. hope that helps a bit. Shanor. [2002-05-11 07:57:19] [EMAIL PROTECTED] I get this when I try to use a .htaccess file like the following: Files view ForceType application/x-httpd-pshp /Files Hope this helps [2002-04-06 11:09:22] [EMAIL PROTECTED] You need latest CVS versions of both PHP and Apache2 for it to work. And Apache2 is still beta and a moving target, so it's not really possible to have stable releases of it. [2002-03-11 02:48:05] [EMAIL PROTECTED] I run Windows 2000, Apache 1320R2 and PHP 4.0.1 (upgrading to 4.1.1 as we speak). I allso have the same problem with: Premature end of script headers: C:/php/php.exe Though... Only in Internet Explorer 6.0. Netscape 6.2 works fine. [2002-01-24 13:39:12] [EMAIL PROTECTED] same as me with php4.1.1 for windows and apache 2.0.28 for windows 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/14822 -- Edit this bug report at http://bugs.php.net/?id=14822edit=1
#20156 [Opn-Csd]: main/internal_functions.c
ID: 20156 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Zend Engine 2 problem Operating System: Linux PHP Version: 4CVS-2002-10-29 Assigned To: helly New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-10-30 01:35:58] [EMAIL PROTECTED] at least it let you compile it (after disabling xmlrpc-support bug #20155). [2002-10-30 00:39:51] [EMAIL PROTECTED] Hmm, wouldn't be that easy to fix unless somebody comes up with some good autoconf magic. For now you can compile with --disable-overload AFAIK. Derick [2002-10-29 17:11:42] [EMAIL PROTECTED] gcc -Imain/ -I/home/weigon/projects/in-cvs/php4/main/ -DPHP_ATOM_INC -I/home/weigon/projects/in-cvs/php4/include -I/home/weigon/projects/in-cvs/php4/main -I/home/weigon/projects/in-cvs/php4 -I/home/weigon/projects/in-cvs/php4/Zend -I/usr/include/freetype2 -I/usr//include -I/home/weigon/projects/in-cvs/php4/TSRM -g -O2 -c main/internal_functions.c -o main/internal_functions.o echo main/internal_functions.lo main/internal_functions.c:61: `phpext_overload_ptr' undeclared here (not in a function) main/internal_functions.c:61: initializer element is not constant main/internal_functions.c:61: (near initialization for `php_builtin_extensions[7]') phpext_overload_ptr isn't defined with ZendEngine2 enabled. -- Edit this bug report at http://bugs.php.net/?id=20156edit=1
#20751 [Fbk]: Mail: undefined function
ID: 20751 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Mail related Operating System: Linux Redhat 7.2 PHP Version: 4.3.0RC2 New Comment: It does already search there: AC_PATH_PROG(PROG_SENDMAIL, sendmail,[], $PATH:/usr/bin:/usr/sbin:/usr/etc:/etc:/usr/ucblib:/usr/lib) What does config.log say about sendmail when you remove that link again? Previous Comments: [2002-12-02 10:55:18] [EMAIL PROTECTED] I have resolved the problem adding a symbolic link from /var/qmail/bin/sendmail to /usr/bin/sendmail and now it works. The configure script doesn't search in /usr/sbin but only in /usr/bin. Please correct this problem [2002-12-02 03:04:30] [EMAIL PROTECTED] Yes, it works. [2002-12-01 17:00:38] [EMAIL PROTECTED] Try this on your cmd line: # test -f /sbin/sendmail echo works (it should print 'works') [2002-12-01 16:45:53] [EMAIL PROTECTED] Qmail is configured with virtual links from: /sbin/sendmail /usr/sbin/sendmail /usr/lib/sendmail to /var/qmail/bin/sendmail as suggested in qmail documentation [2002-12-01 16:42:46] [EMAIL PROTECTED] Yes. The user is root. 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/20751 -- Edit this bug report at http://bugs.php.net/?id=20751edit=1
#20766 [NEW]: array_search doesn't return value with array as needle
From: [EMAIL PROTECTED] Operating system: Linux 2.2.20 PHP version: 4.2.3 PHP Bug Type: Arrays related Bug description: array_search doesn't return value with array as needle $t1[] = banana; $t1[] = orange; $t1[] = kiwi; $t2[] = car; $t2[] = kiwi; $t2[] = cat; print Kiwi key: .array_search($t1,$t2); print Car key: .array_search(car,$t2); this code print: Kiwi key: Car key: 0 Should print: Kiwi key: 1 Car key: 0 Apache: 1.3.26 rh 6.2 -- Edit bug report at http://bugs.php.net/?id=20766edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20766r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20766r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20766r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20766r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20766r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20766r=support Expected behavior: http://bugs.php.net/fix.php?id=20766r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20766r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20766r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20766r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20766r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20766r=dst IIS Stability: http://bugs.php.net/fix.php?id=20766r=isapi
#20768 [NEW]: MySql temp file error
From: [EMAIL PROTECTED] Operating system: Debian 3.0 Stable / Sparc PHP version: 4.3.0RC2 PHP Bug Type: Compile Failure Bug description: MySql temp file error When building 4.3.0RC2 against apache 1.3.26 DSO I get an error stating that usage of tempnam() is insecure - line 103 of ext/mysql/libmysql/my_tempnam.c I replaced line 103 with the following code, which builds and should function identically. /* filespec will be dir + '/' + pfx + 'XX' + null */ res = malloc(strlen(dir) + strlen(pfx) + 8); res[0] = '\0'; strcat(res, dir); strcat(res, /); strcat(res, pfx); strcat(res, XX); mkstemp(res); /* res=tempnam((char *)dir, (my_string) pfx); */ Someone who knows the mysql code should check this if it's not a local build problem on my end. Other details: Linux Kernel 2.4.18 / sparc64 libc6 2.2.5-11.2 gcc 2.95.4 20011002 (Debian prerelease) ./configure --with-mysql --with-apxs --prefix=/usr --sysconfdir=/etc --localstatedir=/var/php --with-zlib --with-dom --with-gd --with-mysql --enable-sockets --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-xpm-dir=/usr/X11R6/lib --with-freetype-dir=/usr/lib -- Edit bug report at http://bugs.php.net/?id=20768edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20768r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20768r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20768r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20768r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20768r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20768r=support Expected behavior: http://bugs.php.net/fix.php?id=20768r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20768r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20768r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20768r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20768r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20768r=dst IIS Stability: http://bugs.php.net/fix.php?id=20768r=isapi
#20768 [Opn-]: MySql temp file error
ID: 20768 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Won\'t fix Bug Type: Compile Failure Operating System: Debian 3.0 Stable / Sparc PHP Version: 4.3.0RC2 New Comment: It's harmless; just ignore it. The MySQL library uses it in a safe way anyway. Derick Previous Comments: [2002-12-02 13:19:49] [EMAIL PROTECTED] When building 4.3.0RC2 against apache 1.3.26 DSO I get an error stating that usage of tempnam() is insecure - line 103 of ext/mysql/libmysql/my_tempnam.c I replaced line 103 with the following code, which builds and should function identically. /* filespec will be dir + '/' + pfx + 'XX' + null */ res = malloc(strlen(dir) + strlen(pfx) + 8); res[0] = '\0'; strcat(res, dir); strcat(res, /); strcat(res, pfx); strcat(res, XX); mkstemp(res); /* res=tempnam((char *)dir, (my_string) pfx); */ Someone who knows the mysql code should check this if it's not a local build problem on my end. Other details: Linux Kernel 2.4.18 / sparc64 libc6 2.2.5-11.2 gcc 2.95.4 20011002 (Debian prerelease) ./configure --with-mysql --with-apxs --prefix=/usr --sysconfdir=/etc --localstatedir=/var/php --with-zlib --with-dom --with-gd --with-mysql --enable-sockets --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-xpm-dir=/usr/X11R6/lib --with-freetype-dir=/usr/lib -- Edit this bug report at http://bugs.php.net/?id=20768edit=1
#20769 [NEW]: regex hangs php if --with-system-regex turned on
From: [EMAIL PROTECTED] Operating system: linux debian-woody PHP version: 4.2.3 PHP Bug Type: Regexps related Bug description: regex hangs php if --with-system-regex turned on ereg( '^[a-z0-9_\-\.]+@[a-z0-9_\-\.]+\.[a-z0-9]+', '[EMAIL PROTECTED]', $bla); does hang with 100% cpumem so the kernel kills it Dec 2 17:49:51 whitestar kernel: Out of Memory: Killed process 6176 (apache). it happens only if I compile with --with-system-regex after I figured that out, I stopped investigating deeper .. I don't know if its a debian or php problem ... but I though I report it anyway. -- Edit bug report at http://bugs.php.net/?id=20769edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20769r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20769r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20769r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20769r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20769r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20769r=support Expected behavior: http://bugs.php.net/fix.php?id=20769r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20769r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20769r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20769r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20769r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20769r=dst IIS Stability: http://bugs.php.net/fix.php?id=20769r=isapi
#20768 [Com]: MySql temp file error
ID: 20768 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Won\'t fix Bug Type: Compile Failure Operating System: Debian 3.0 Stable / Sparc PHP Version: 4.3.0RC2 New Comment: It may be safe, but it stops the compile. I can't build with the code as is. Previous Comments: [2002-12-02 13:23:31] [EMAIL PROTECTED] It's harmless; just ignore it. The MySQL library uses it in a safe way anyway. Derick [2002-12-02 13:19:49] [EMAIL PROTECTED] When building 4.3.0RC2 against apache 1.3.26 DSO I get an error stating that usage of tempnam() is insecure - line 103 of ext/mysql/libmysql/my_tempnam.c I replaced line 103 with the following code, which builds and should function identically. /* filespec will be dir + '/' + pfx + 'XX' + null */ res = malloc(strlen(dir) + strlen(pfx) + 8); res[0] = '\0'; strcat(res, dir); strcat(res, /); strcat(res, pfx); strcat(res, XX); mkstemp(res); /* res=tempnam((char *)dir, (my_string) pfx); */ Someone who knows the mysql code should check this if it's not a local build problem on my end. Other details: Linux Kernel 2.4.18 / sparc64 libc6 2.2.5-11.2 gcc 2.95.4 20011002 (Debian prerelease) ./configure --with-mysql --with-apxs --prefix=/usr --sysconfdir=/etc --localstatedir=/var/php --with-zlib --with-dom --with-gd --with-mysql --enable-sockets --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-xpm-dir=/usr/X11R6/lib --with-freetype-dir=/usr/lib -- Edit this bug report at http://bugs.php.net/?id=20768edit=1
#20769 [Opn-Bgs]: regex hangs php if --with-system-regex turned on
ID: 20769 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Regexps related Operating System: linux debian-woody PHP Version: 4.2.3 New Comment: That configure option doesn't exist; in case you mean --with-regex=system, read ./configure --help: --with-regex=TYPE regex library type: system, apache, php. Default: php WARNING: Do NOT use unless you know what you are doing! You should not touch this unless you know what you're doing, and my guess is that you have clue what this is for. Not a bug - bogus Previous Comments: [2002-12-02 13:23:34] [EMAIL PROTECTED] ereg( '^[a-z0-9_\-\.]+@[a-z0-9_\-\.]+\.[a-z0-9]+', '[EMAIL PROTECTED]', $bla); does hang with 100% cpumem so the kernel kills it Dec 2 17:49:51 whitestar kernel: Out of Memory: Killed process 6176 (apache). it happens only if I compile with --with-system-regex after I figured that out, I stopped investigating deeper .. I don't know if its a debian or php problem ... but I though I report it anyway. -- Edit this bug report at http://bugs.php.net/?id=20769edit=1
#20768 [WFx-]: MySql temp file error
ID: 20768 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Won\'t fix Bug Type: Compile Failure Operating System: Debian 3.0 Stable / Sparc PHP Version: 4.3.0RC2 New Comment: It's a warning, not an error. Previous Comments: [2002-12-02 13:25:30] [EMAIL PROTECTED] It may be safe, but it stops the compile. I can't build with the code as is. [2002-12-02 13:23:31] [EMAIL PROTECTED] It's harmless; just ignore it. The MySQL library uses it in a safe way anyway. Derick [2002-12-02 13:19:49] [EMAIL PROTECTED] When building 4.3.0RC2 against apache 1.3.26 DSO I get an error stating that usage of tempnam() is insecure - line 103 of ext/mysql/libmysql/my_tempnam.c I replaced line 103 with the following code, which builds and should function identically. /* filespec will be dir + '/' + pfx + 'XX' + null */ res = malloc(strlen(dir) + strlen(pfx) + 8); res[0] = '\0'; strcat(res, dir); strcat(res, /); strcat(res, pfx); strcat(res, XX); mkstemp(res); /* res=tempnam((char *)dir, (my_string) pfx); */ Someone who knows the mysql code should check this if it's not a local build problem on my end. Other details: Linux Kernel 2.4.18 / sparc64 libc6 2.2.5-11.2 gcc 2.95.4 20011002 (Debian prerelease) ./configure --with-mysql --with-apxs --prefix=/usr --sysconfdir=/etc --localstatedir=/var/php --with-zlib --with-dom --with-gd --with-mysql --enable-sockets --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-xpm-dir=/usr/X11R6/lib --with-freetype-dir=/usr/lib -- Edit this bug report at http://bugs.php.net/?id=20768edit=1
#20769 [Bgs]: regex hangs php if --with-system-regex turned on
ID: 20769 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Regexps related Operating System: linux debian-woody PHP Version: 4.2.3 New Comment: i used that for compiling and I didn't get an error message, and it hangs. ./configure --with-gmp --enable-ftp --with-zlib\ --enable-bcmath --enable-sysvsem --enable-sysvshm --enable-calendar\ --enable-trans-sid --enable-versioning --enable-track-vars\ --enable-inline-optimization --with-config-file-path=/etc/php4\ --enable-readline --with-pam --with-gettext\ --with-gdbm --with-mysql --with-apxs\ --with-xml --with-sablot --with-xslt-sablot\ --enable-xslt --enable-force-cgi-redirect --with-system-regex\ --with-dom --enable-mcrypt --with-mhash I changed it to ./configure --with-gmp --enable-ftp --with-zlib\ --enable-bcmath --enable-sysvsem --enable-sysvshm --enable-calendar\ --enable-trans-sid --enable-versioning --enable-track-vars\ --enable-inline-optimization --with-config-file-path=/etc/php4\ --with-gdbm --with-mysql --with-apxs\ --with-xml --with-sablot --with-xslt-sablot\ --enable-xslt --enable-force-cgi-redirect \ --with-dom --enable-mcrypt --with-mhash and now it works Previous Comments: [2002-12-02 13:25:57] [EMAIL PROTECTED] That configure option doesn't exist; in case you mean --with-regex=system, read ./configure --help: --with-regex=TYPE regex library type: system, apache, php. Default: php WARNING: Do NOT use unless you know what you are doing! You should not touch this unless you know what you're doing, and my guess is that you have clue what this is for. Not a bug - bogus [2002-12-02 13:23:34] [EMAIL PROTECTED] ereg( '^[a-z0-9_\-\.]+@[a-z0-9_\-\.]+\.[a-z0-9]+', '[EMAIL PROTECTED]', $bla); does hang with 100% cpumem so the kernel kills it Dec 2 17:49:51 whitestar kernel: Out of Memory: Killed process 6176 (apache). it happens only if I compile with --with-system-regex after I figured that out, I stopped investigating deeper .. I don't know if its a debian or php problem ... but I though I report it anyway. -- Edit this bug report at http://bugs.php.net/?id=20769edit=1
#20254 [Com]: imap_header() crash with bad Reply-To
ID: 20254
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IMAP related
Operating System: Linux (2.4.18)
PHP Version: 4.3.0-dev
New Comment:
hello.
similar problem, imap_header() crash, but with other condition - long
To: header
php 4.2.3 as CLI,libc-client: 4.7-c2
bug can be reproduced with message containing following header:
To: Someone [EMAIL PROTECTED],
Someone2 [EMAIL PROTECTED],
...
Someone144 email144@somehost
I didn't test actual threshold, it could be smaller then 144.
test script:
$imap=imap_open({localhost:143}INBOX,user,pass);
if (!$imap)
echo connect failed\n;
$header=imap_header($imap,1);
backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x3d0f86 in malloc () from /lib/libc.so.6
(gdb) bt
#0 0x3d0f86 in malloc () from /lib/libc.so.6
#1 0x3d0ca4 in malloc () from /lib/libc.so.6
#2 0x80c723c in _emalloc (size=12) at zend_alloc.c:165
#3 0x53e39e in _php_imap_parse_address (addresslist=0x817bfe0,
fulladdress=0xbd870ec8, paddress=0x818476c) at php_imap.c:3632
#4 0x53e62e in _php_make_header_object (myzvalue=0x8178c3c,
en=0x817ce58)
at php_imap.c:3666
#5 0x536dbd in zif_imap_headerinfo (ht=2, return_value=0x8178c3c,
this_ptr=0x0, return_value_used=1) at php_imap.c:1631
#6 0x497d99 in zend_assign_to_variable_reference ()
from /usr/local/Zend/lib/ZendOptimizer.so
#7 0x4a1144 in zend_oe () from /usr/local/Zend/lib/ZendOptimizer.so
#8 0x80d3fb8 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at zend.c:812
#9 0x805f81d in php_execute_script (primary_file=0xbd873388) at
main.c:1383
#10 0x805d6e3 in main (argc=2, argv=0xbd873404) at cgi_main.c:778
#11 0x37c0bf in __libc_start_main () from /lib/libc.so.6
Previous Comments:
[2002-11-14 22:39:24] [EMAIL PROTECTED]
I'm in another situation.
I configured php with uw-imap c-client, but
courier-imap server is running.
Stopping courier-imap server and, Test with uw-iamp server, there was
no crash.
Test with courier-imap server again, here backtrace report.
(gdb) bt
#0 0x403b480e in _zval_ptr_dtor (zval_ptr=0x0,
__zend_filename=0x4046de00
/usr/local/src/php4-200211030600/Zend/zend_variables.c,
__zend_lineno=167)
at /usr/local/src/php4-200211030600/Zend/zend_execute_API.c:291
#1 0x403be4d2 in _zval_ptr_dtor_wrapper (zval_ptr=0x0) at
/usr/local/src/php4-200211030600/Zend/zend_variables.c:167
#2 0x403c5a01 in zend_hash_destroy (ht=0x812eacc) at
/usr/local/src/php4-200211030600/Zend/zend_hash.c:543
#3 0x403be19a in _zval_dtor (zvalue=0x812ea8c,
__zend_filename=0x4046d6a0
/usr/local/src/php4-200211030600/Zend/zend_execute_API.c,
__zend_lineno=293)
at /usr/local/src/php4-200211030600/Zend/zend_variables.c:60
#4 0x403b4839 in _zval_ptr_dtor (zval_ptr=0x811c820,
__zend_filename=0x4046de00
/usr/local/src/php4-200211030600/Zend/zend_variables.c,
__zend_lineno=167)
at /usr/local/src/php4-200211030600/Zend/zend_execute_API.c:293
#5 0x403be4d2 in _zval_ptr_dtor_wrapper (zval_ptr=0x811c820) at
/usr/local/src/php4-200211030600/Zend/zend_variables.c:167
#6 0x403c5a01 in zend_hash_destroy (ht=0x404da80c) at
/usr/local/src/php4-200211030600/Zend/zend_hash.c:543
#7 0x403b433e in shutdown_executor () at
/usr/local/src/php4-200211030600/Zend/zend_execute_API.c:186
#8 0x403bf70f in zend_deactivate () at
/usr/local/src/php4-200211030600/Zend/zend.c:625
#9 0x40387bd3 in php_request_shutdown (dummy=0x0) at
/usr/local/src/php4-200211030600/main/main.c:913
#10 0x403d6dfa in apache_php_module_main (r=0x8114ad4,
display_source_mode=0)
at /usr/local/src/php4-200211030600/sapi/apache/sapi_apache.c:61
#11 0x403d7c48 in send_php (r=0x8114ad4, display_source_mode=0,
filename=0x8116614 /home/www/test.php)
at /usr/local/src/php4-200211030600/sapi/apache/mod_php4.c:556
#12 0x403d7cb5 in send_parsed_php (r=0x8114ad4) at
/usr/local/src/php4-200211030600/sapi/apache/mod_php4.c:571
#13 0x08054823 in ap_invoke_handler ()
#14 0x08069ca7 in process_request_internal ()
#15 0x08069d08 in ap_process_request ()
#16 0x08060a79 in child_main ()
#17 0x08060c48 in make_child ()
#18 0x08060dbc in startup_children ()
#19 0x08061434 in standalone_main ()
#20 0x08061cb3 in main ()
#21 0x400ad1c4 in __libc_start_main () from /lib/libc.so.6
(gdb)
[2002-11-13 12:41:38] [EMAIL PROTECTED]
Can you provide a backtrace using the latest CVS snapshot
and compiled with Apache 1.3 ?
[2002-11-12 23:34:51] [EMAIL PROTECTED]
apache2 crashes more frequently(?) than apach1.
if i try 10-20 times, one time crashes with apache2.
on apache1, try 20-30 times, one time crash.
#20770 [NEW]: tring to download php file
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.2.3 PHP Bug Type: Apache2 related Bug description: tring to download php file I installed Apache2.0.43/Tomcat 4.1.12 and PHP4.2.3. And configured apache httpd.conf for PHP. But when browser trys to access php file it just try to download php file always. Thanks, Duksun -- Edit bug report at http://bugs.php.net/?id=20770edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20770r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20770r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20770r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20770r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20770r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20770r=support Expected behavior: http://bugs.php.net/fix.php?id=20770r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20770r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20770r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20770r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20770r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20770r=dst IIS Stability: http://bugs.php.net/fix.php?id=20770r=isapi
#20770 [Opn-Fbk]: tring to download php file
ID: 20770 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Previous Comments: [2002-12-02 14:00:22] [EMAIL PROTECTED] I installed Apache2.0.43/Tomcat 4.1.12 and PHP4.2.3. And configured apache httpd.conf for PHP. But when browser trys to access php file it just try to download php file always. Thanks, Duksun -- Edit this bug report at http://bugs.php.net/?id=20770edit=1
#20771 [NEW]: imagettftext() fails without errors
From: [EMAIL PROTECTED] Operating system: RH 8.0 PHP version: 4.2.2 PHP Bug Type: GD related Bug description: imagettftext() fails without errors This works on 4.0.4pl1 and 4.0.5 but not on my new RH 8.0 build with 4.4.2: phpinfo() is at http://www.resiteit.com/phpinfo.php $im = imagecreate (400, 30); $black = imagecolorallocate ($im, 0, 0, 0); $white = imagecolorallocate ($im, 255, 255, 255); imagettftext ($im, 20, 0, 10, 20, $white, ../fonts/arialbd.ttf, Testing...Omega: #937;); imagepng ($im); imagedestroy ($im); On the new build, I just get the black bar. Unfortunately no errors. Interesting to note that the function doesn't return the bounding box array either. Any ideas? -- Thanks! -- Edit bug report at http://bugs.php.net/?id=20771edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20771r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20771r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20771r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20771r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20771r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20771r=support Expected behavior: http://bugs.php.net/fix.php?id=20771r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20771r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20771r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20771r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20771r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20771r=dst IIS Stability: http://bugs.php.net/fix.php?id=20771r=isapi
#20771 [Opn-Fbk]: imagettftext() fails without errors
ID: 20771 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: GD related Operating System: RH 8.0 PHP Version: 4.2.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-02 14:48:45] [EMAIL PROTECTED] This works on 4.0.4pl1 and 4.0.5 but not on my new RH 8.0 build with 4.4.2: phpinfo() is at http://www.resiteit.com/phpinfo.php $im = imagecreate (400, 30); $black = imagecolorallocate ($im, 0, 0, 0); $white = imagecolorallocate ($im, 255, 255, 255); imagettftext ($im, 20, 0, 10, 20, $white, ../fonts/arialbd.ttf, Testing...Omega: #937;); imagepng ($im); imagedestroy ($im); On the new build, I just get the black bar. Unfortunately no errors. Interesting to note that the function doesn't return the bounding box array either. Any ideas? -- Thanks! -- Edit this bug report at http://bugs.php.net/?id=20771edit=1
#20751 [Com]: Mail: undefined function
ID: 20751 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Mail related Operating System: Linux Redhat 7.2 PHP Version: 4.3.0RC2 New Comment: If I remove the link the config doesn't find sendmail. Previous Comments: [2002-12-02 12:19:22] [EMAIL PROTECTED] It does already search there: AC_PATH_PROG(PROG_SENDMAIL, sendmail,[], $PATH:/usr/bin:/usr/sbin:/usr/etc:/etc:/usr/ucblib:/usr/lib) What does config.log say about sendmail when you remove that link again? [2002-12-02 10:55:18] [EMAIL PROTECTED] I have resolved the problem adding a symbolic link from /var/qmail/bin/sendmail to /usr/bin/sendmail and now it works. The configure script doesn't search in /usr/sbin but only in /usr/bin. Please correct this problem [2002-12-02 03:04:30] [EMAIL PROTECTED] Yes, it works. [2002-12-01 17:00:38] [EMAIL PROTECTED] Try this on your cmd line: # test -f /sbin/sendmail echo works (it should print 'works') [2002-12-01 16:45:53] [EMAIL PROTECTED] Qmail is configured with virtual links from: /sbin/sendmail /usr/sbin/sendmail /usr/lib/sendmail to /var/qmail/bin/sendmail as suggested in qmail documentation 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/20751 -- Edit this bug report at http://bugs.php.net/?id=20751edit=1
#20751 [Fbk]: Mail: undefined function
ID: 20751 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Mail related Operating System: Linux Redhat 7.2 PHP Version: 4.3.0RC2 New Comment: What does config.log say about sendmail when you remove that link again? Previous Comments: [2002-12-02 15:48:27] [EMAIL PROTECTED] If I remove the link the config doesn't find sendmail. [2002-12-02 12:19:22] [EMAIL PROTECTED] It does already search there: AC_PATH_PROG(PROG_SENDMAIL, sendmail,[], $PATH:/usr/bin:/usr/sbin:/usr/etc:/etc:/usr/ucblib:/usr/lib) What does config.log say about sendmail when you remove that link again? [2002-12-02 10:55:18] [EMAIL PROTECTED] I have resolved the problem adding a symbolic link from /var/qmail/bin/sendmail to /usr/bin/sendmail and now it works. The configure script doesn't search in /usr/sbin but only in /usr/bin. Please correct this problem [2002-12-02 03:04:30] [EMAIL PROTECTED] Yes, it works. [2002-12-01 17:00:38] [EMAIL PROTECTED] Try this on your cmd line: # test -f /sbin/sendmail echo works (it should print 'works') The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20751 -- Edit this bug report at http://bugs.php.net/?id=20751edit=1
#20613 [Fbk-Csd]: PHP Crashes SIGSEGV under iPlanet
ID: 20613 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: iPlanet related Operating System: Solaris 8 PHP Version: 4.2.2 New Comment: We've been running for 20+ hours with the snapshot build and haven't had a crash yet. So this seems to have fixed it thanks!!! Previous Comments: [2002-11-28 22:07:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-24 21:39:46] [EMAIL PROTECTED] Sorry forgot the configure line: ./configure --with-ldap=/usr/local/ --enable-thread-safety --enable-libgcc --ena ble-ftp --with-mysql=/usr/local/mysql --with-custom-odbc=/opt/odbc --with-curl=/ opt --with-openssl=/usr/local/ssl --enable-discard-path --enable-wddx --enable-x slt --with-xslt-sablot --enable-track-vars --enable-sysvsem --with-oci8=/oracle/ home/product/8.1.7 --with-nsapi=/db/www/netscape/server4 --enable-debug=yes --wi th-msession [2002-11-24 21:06:57] [EMAIL PROTECTED] This seems similar to 15439 and 20109 but it is on iPlanet Web Server 4.1SP10 on Solaris 8. PHP crashes the webserver SIGSEGV, I have so far been unable to find the exact script that causes the problem, as it seems fairly random. I do however have a backtrace reproduced below: #0 0xfec33344 in strlen () from /usr/lib/libc.so.1 #1 0xfdd96a9c in php_register_variable () from /db/www/netscape/bin/libphp4.so #2 0xfdd794b8 in sapi_nsapi_register_server_variables () from /db/www/netscape/bin/libphp4.so #3 0xfdd7f1cc in php_register_server_variables () from /db/www/netscape/bin/libphp4.so #4 0xfdd7f938 in php_hash_environment () from /db/www/netscape/bin/libphp4.so #5 0xfdd7d75c in php_request_startup () from /db/www/netscape/bin/libphp4.so #6 0xfdd79d98 in nsapi_module_main () from /db/www/netscape/bin/libphp4.so #7 0xfdd7a0e8 in php4_execute () from /db/www/netscape/bin/libphp4.so #8 0xff256ccc in __0Fafunc_native_pool_wait_workPFP6GpblockP6HSessionP6HRequest_iUiP6GpblockP6HSessionP6HRequest () from /db/www/netscape/bin/https/lib/libns-httpd40.so #9 0xff2562ec in __0FNfunc_exec_strP6KFuncStructP6GpblockP6HSessionP6HRequest () from /db/www/netscape/bin/https/lib/libns-httpd40.so #10 0xff257284 in INTobject_execute () from /db/www/netscape/bin/https/lib/libns-httpd40.so #11 0xff25bec8 in __0FQ_perform_serviceP6HSessionP6HRequestP6Mhttpd_object () from /db/www/netscape/bin/https/lib/libns-httpd40.so #12 0xff25bf84 in INTservact_service () from /db/www/netscape/bin/https/lib/libns-httpd40.so #13 0xff25c29c in INTservact_handle_processed () from /db/www/netscape/bin/https/lib/libns-httpd40.so ---Type return to continue, or q return to quit--- #14 0xff28a8a4 in __0fLHttpRequestUUnacceleratedRespondPCcPcTC () from /db/www/netscape/bin/https/lib/libns-httpd40.so #15 0xff289680 in __0fLHttpRequestNHandleRequestP6Gnetbuf () from /db/www/netscape/bin/https/lib/libns-httpd40.so #16 0xff285e9c in __0fNDaemonSessionHRespondv () from /db/www/netscape/bin/https/lib/libns-httpd40.so #17 0xff285d28 in __0fNDaemonSessionKThreadMainv () from /db/www/netscape/bin/https/lib/libns-httpd40.so #18 0xff2857b4 in CThreadMain () from /db/www/netscape/bin/https/lib/libns-httpd40.so #19 0xfef42ad8 in _pt_root () from /db/www/netscape/bin/https/lib/libnspr3.so -- Edit this bug report at http://bugs.php.net/?id=20613edit=1
#20773 [NEW]: will not compile with iplant ldap
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.3.0RC2 PHP Bug Type: LDAP related Bug description: will not compile with iplant ldap Tried to compile with iplanet ldap 5.0.sp1 server. Config runs OK Compile does not. (config command line entries ) ./configure --with-apxs2=/www2/bin/apxs --with-gettext --with-xml --enable-ftp --with-mhash --with-gdbm --enable-bcmath --with-mysql --with-ldap=/usr/iplanet/servers/plugins/slapd/slapi --with-zlib --with-ndbm --enable-calendar --with-imap=/export/home/imiller/imap-2002 --with-openssl=/usr/local/ssl --with-mcrypt (Config section of ldap) checking for iconv support... no checking for IMAP support... yes checking for pam_start in -lpam... yes checking for crypt in -lcrypt... (cached) yes checking whether SSL libraries are needed for c-client... no checking whether IMAP works... yes checking for Informix support... no checking for Ingres II support... no checking for InterBase support... no checking for IRCG support... no checking for Java support... no checking for LDAP support... yes checking for 3 arg ldap_set_rebind_proc... yes checking for ldap_parse_reference... no checking for ldap_start_tls_s... no checking whether to enable multibyte string support... no checking whether to enable multibyte regex support... no checking for MCAL support... no checking for mcrypt support... yes checking for mcrypt_module_open in -lmcrypt... yes checking for mcrypt_generic_deinit in -lmcrypt... yes checking for MCVE support... no checking for mhash support... yes checking whether to enable mime_magic support... no (Compile section) cc1: warning: changing search order for system directory /usr/local/include cc1: warning: as it has already been specified as a non-system directory /bin/ksh libtool --silent --mode=compile gcc -Iext/imap/ -I/export/home/imiller/php-4.3.0RC2/ext/imap/ -DPHP_ATOM_INC -I/export/home/imiller/php-4.3.0RC2/include -I/export/home/imiller/php-4.3.0RC2/main -I/export/home/imiller/php-4.3.0RC2 -I/www2/include -I/export/home/imiller/php-4.3.0RC2/Zend -I/usr/local/ssl/include -I/usr/local/include -I/export/home/imiller/imap-2002/c-client -I/usr/iplanet/servers/plugins/slapd/slapi/include -I/export/home/imiller/php-4.3.0RC2/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -I/export/home/imiller/php-4.3.0RC2/TSRM -g -O2 -prefer-pic -c /export/home/imiller/php-4.3.0RC2/ext/imap/php_imap.c -o ext/imap/php_imap.lo cc1: warning: changing search order for system directory /usr/local/include cc1: warning: as it has already been specified as a non-system directory /bin/ksh libtool --silent --mode=compile gcc -Iext/ldap/ -I/export/home/imiller/php-4.3.0RC2/ext/ldap/ -DPHP_ATOM_INC -I/export/home/imiller/php-4.3.0RC2/include -I/export/home/imiller/php-4.3.0RC2/main -I/export/home/imiller/php-4.3.0RC2 -I/www2/include -I/export/home/imiller/php-4.3.0RC2/Zend -I/usr/local/ssl/include -I/usr/local/include -I/export/home/imiller/imap-2002/c-client -I/usr/iplanet/servers/plugins/slapd/slapi/include -I/export/home/imiller/php-4.3.0RC2/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -I/export/home/imiller/php-4.3.0RC2/TSRM -g -O2 -prefer-pic -c /export/home/imiller/php-4.3.0RC2/ext/ldap/ldap.c -o ext/ldap/ldap.lo cc1: warning: changing search order for system directory /usr/local/include cc1: warning: as it has already been specified as a non-system directory /export/home/imiller/php-4.3.0RC2/ext/ldap/ldap.c: In function `zif_ldap_set_rebind_proc': /export/home/imiller/php-4.3.0RC2/ext/ldap/ldap.c:2062: too many arguments to function `ldap_set_rebind_proc' /export/home/imiller/php-4.3.0RC2/ext/ldap/ldap.c:2077: warning: passing arg 2 of `ldap_set_rebind_proc' from incompatible pointer type /export/home/imiller/php-4.3.0RC2/ext/ldap/ldap.c:2077: too many arguments to function `ldap_set_rebind_proc' make: *** [ext/ldap/ldap.lo] Error 1 bash-2.05# -- Edit bug report at http://bugs.php.net/?id=20773edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20773r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20773r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20773r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20773r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20773r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20773r=support Expected behavior: http://bugs.php.net/fix.php?id=20773r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20773r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20773r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20773r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20773r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20773r=dst IIS Stability: http://bugs.php.net/fix.php?id=20773r=isapi
#20772 [Com]: Output control + memory limit + big file read
ID: 20772 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Output Control Operating System: redhat 7.0 PHP Version: 4.3.0RC2 New Comment: In the script the last } is to delete. Previous Comments: [2002-12-02 16:43:37] [EMAIL PROTECTED] If I try to run this script the server simply exit without giving me anything. ? echo A; $fd=fopen(aaa/temp, wb); fpassthru($fd); echo B; } ? The server is configured with output buffering activated (gz_handler), memory limit enabled (8MB) and the temp file is bigger than 8MByte I have understand that the problem that the script excedeed the memory limit and adding, as first line, ob_end_clean(); the script works, but in the error log there isn't a fatal error or a warning, nothing; also the access log doesn't log the hit. It's possible to add a fatal error to let the programmer know what is the problem. -- Edit this bug report at http://bugs.php.net/?id=20772edit=1
#20751 [Com]: Mail: undefined function
ID: 20751 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Mail related Operating System: Linux Redhat 7.2 PHP Version: 4.3.0RC2 New Comment: I'm also experiencing this problem, same version, same os. I'll try the symbolic link workaround. Previous Comments: [2002-12-02 16:24:32] [EMAIL PROTECTED] What does config.log say about sendmail when you remove that link again? [2002-12-02 15:48:27] [EMAIL PROTECTED] If I remove the link the config doesn't find sendmail. [2002-12-02 12:19:22] [EMAIL PROTECTED] It does already search there: AC_PATH_PROG(PROG_SENDMAIL, sendmail,[], $PATH:/usr/bin:/usr/sbin:/usr/etc:/etc:/usr/ucblib:/usr/lib) What does config.log say about sendmail when you remove that link again? [2002-12-02 10:55:18] [EMAIL PROTECTED] I have resolved the problem adding a symbolic link from /var/qmail/bin/sendmail to /usr/bin/sendmail and now it works. The configure script doesn't search in /usr/sbin but only in /usr/bin. Please correct this problem [2002-12-02 03:04:30] [EMAIL PROTECTED] Yes, it works. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20751 -- Edit this bug report at http://bugs.php.net/?id=20751edit=1
#20774 [NEW]: will not compile
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.3.0RC2 PHP Bug Type: Compile Failure Bug description: will not compile Solaris 8 gcc 3.1 apache 2.0.43 config /configure --with-apxs2=/www2/bin/apxs --with-gettext --with-xml --enable-ftp --with-mhash --with-gdbm --enable-bcmath --with-mysql --with-ldap=/usr/local --with-zlib --with-ndbm --enable-calendar --with-imap=/export/home/imiller/imap-2002 --with-openssl=/usr/local/ssl --with-mcrypt ( compile ) cc1: warning: changing search order for system directory /usr/local/include cc1: warning: as it has already been specified as a non-system directory /bin/ksh libtool --silent --mode=link gcc -g -O2 -prefer-pic -rpath /export/home/imiller/php-4.3.0RC2/libs -avoid-version -module -L/usr/ucblib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.1 -L/usr/local/ssl/lib -L/usr/local/lib -L/export/home/imiller/imap-2002/c-client -R /usr/ucblib -R /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.1 -R /usr/local/ssl/lib -R /usr/local/lib -R /export/home/imiller/imap-2002/c-client ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bcmath/bcmath.lo ext/bcmath/number.lo ext/bcmath/libbcmath/src/add.lo ext/bcmath/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src/neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/libbcmath/src/raisemod.lo ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/src/sub.lo ext/bcmath/libbcmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src/int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcmath/libbcmath/src/output.lo ext/bcmath/libbcmath/src/recmul.lo ext/bcmath/libbcmath/src/sqrt.lo ext/bcmath/libbcmath/src/zero.lo ext/bcmath/libbcmath/src/debug.lo ext/bcmath/libbcmath/src/doaddsub.lo ext/bcmath/libbcmath/src/nearzero.lo ext/bcmath/libbcmath/src/num2str.lo ext/bcmath/libbcmath/src/raise.lo ext/bcmath/libbcmath/src/rmzero.lo ext/bcmath/libbcmath/src/str2num.lo ext/calendar/calendar.lo ext/calendar/dow.lo ext/calendar/french.lo ext/calendar/gregor.lo ext/calendar/jewish.lo ext/calendar/julian.lo ext/calendar/easter.lo ext/calendar/cal_unix.lo ext/ctype/ctype.lo ext/dba/dba.lo ext/dba/dba_cdb.lo ext/dba/dba_db2.lo ext/dba/dba_dbm.lo ext/dba/dba_gdbm.lo ext/dba/dba_ndbm.lo ext/dba/dba_db3.lo ext/ftp/php_ftp.lo ext/ftp/ftp.lo ext/gettext/gettext.lo ext/imap/php_imap.lo ext/ldap/ldap.lo ext/mcrypt/mcrypt.lo ext/mhash/mhash.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql/libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_alloc.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/libmysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo ext/mysql/libmysql/thr_mutex.lo ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/string.lo ext/mysql/libmysql/default.lo ext/mysql/libmysql/my_compress.lo ext/mysql/libmysql/array.lo ext/mysql/libmysql/my_once.lo ext/mysql/libmysql/list.lo ext/mysql/libmysql/my_net.lo ext/mysql/libmysql/dbug.lo ext/mysql/libmysql/strmov.lo ext/mysql/libmysql/strxmov.lo ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/strmake.lo ext/mysql/libmysql/strend.lo ext/mysql/libmysql/strfill.lo ext/mysql/libmysql/is_prefix.lo ext/mysql/libmysql/int2str.lo ext/mysql/libmysql/str2int.lo ext/mysql/libmysql/strinstr.lo ext/mysql/libmysql/strcont.lo ext/mysql/libmysql/strcend.lo ext/mysql/libmysql/bchange.lo ext/mysql/libmysql/bmove.lo ext/mysql/libmysql/bmove_upp.lo ext/mysql/libmysql/longlong2str.lo ext/mysql/libmysql/strtoull.lo ext/mysql/libmysql/strtoll.lo ext/mysql/libmysql/charset.lo ext/mysql/libmysql/ctype.lo ext/openssl/openssl.lo ext/overload/overload.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo
#20751 [Com]: Mail: undefined function
ID: 20751 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Mail related Operating System: Linux Redhat 7.2 PHP Version: 4.3.0RC2 New Comment: Yup, looks like that solved the problem for me, just waiting for the build to finish. Build finished, all ok. So it seems to not check /usr/sbin for sendmail, only /usr/bin. Previous Comments: [2002-12-02 16:56:24] [EMAIL PROTECTED] I'm also experiencing this problem, same version, same os. I'll try the symbolic link workaround. [2002-12-02 16:24:32] [EMAIL PROTECTED] What does config.log say about sendmail when you remove that link again? [2002-12-02 15:48:27] [EMAIL PROTECTED] If I remove the link the config doesn't find sendmail. [2002-12-02 12:19:22] [EMAIL PROTECTED] It does already search there: AC_PATH_PROG(PROG_SENDMAIL, sendmail,[], $PATH:/usr/bin:/usr/sbin:/usr/etc:/etc:/usr/ucblib:/usr/lib) What does config.log say about sendmail when you remove that link again? [2002-12-02 10:55:18] [EMAIL PROTECTED] I have resolved the problem adding a symbolic link from /var/qmail/bin/sendmail to /usr/bin/sendmail and now it works. The configure script doesn't search in /usr/sbin but only in /usr/bin. Please correct this problem The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20751 -- Edit this bug report at http://bugs.php.net/?id=20751edit=1
#20775 [NEW]: Silent install (/s) does not work
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4.2.3 PHP Bug Type: Unknown/Other Function Bug description: Silent install (/s) does not work The Win32 installer php-4.2.3-installer.exe accepts the /s switch which should perform a silent installation, but it still pops up a dialog box. To reproduce, just run: php-4.2.3-installer.exe /s -- Edit bug report at http://bugs.php.net/?id=20775edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20775r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20775r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20775r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20775r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20775r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20775r=support Expected behavior: http://bugs.php.net/fix.php?id=20775r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20775r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20775r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20775r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20775r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20775r=dst IIS Stability: http://bugs.php.net/fix.php?id=20775r=isapi
#745 [Ana]: input type=image and array variables
ID: 745 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Scripting Engine problem Operating System: * PHP Version: 4.3.0-dev New Comment: Given raw post data of: foo%5B123%5D.x=5foo%5B123%5D.y=10 I disagree with having the script engine turn that into: [foo] = Array ( [123] = Array ( [x] = 5 [y] = 10 ) ) as this would break backward compatability (though I doubt many scripts are using this to be honest). There are two sensical solution that pop into my head: #1) [foo] = Array ( [123] = 10// For BC [123.x] = 5 [123.y] = 10 ) From an engine stand point all this says is if the ] is not at the end of the varname, move it there. However, I don't like this idea either. While it makes the data accessable without breaking anything, it's just plain ugly. #2) [foo] = Array ( [123] = 10// For BC ) [foo_x] = Array ( [123] = 5 ) [foo_y] = Array ( [123] = 10 ) From an engine stand point all this says is if there is a [] block which is not at the end of the varname, make one copy of the var with the end truncated, then move the [] block to the end and export that varname as well. i.e.: foo[123]bar = foo[123] foobar[123] And come to that it would want to include cases where there is non [] text between [] blocks: i.e.: foo[123]bar[456] = foo[123][456] foobar[123][456] or possibly... foo[123]bar[456] = foo[123][456] foo[123][bar][456] I can get behind this approach... At least in principal... But I don't believe in its need enough to work on it unless it gets a several +1s. It also has the disadvantage of allowing scripters to get used to naming their form elements incorrectly. (Not that the image example is incorrect, per se, but it's a special case as the browser modifies the name beyond the control of the designer). Previous Comments: [2002-07-01 08:49:43] [EMAIL PROTECTED] Raw post data and resulting variables: foo%5B123%5D.x=5foo%5B123%5D.y=10 Array ( [foo] = Array ( [123] = 10 ) ) bar%5B%5D.x=5bar%5B%5D.y=10 Array ( [bar] = Array ( [0] = 5 [1] = 10 ) ) foobar.x=5foobar.y=10 Array ( [foobar_x] = 5 [foobar_y] = 10 ) Not very consistent.. [2002-01-14 05:57:40] [EMAIL PROTECTED] what a load of wank [2001-12-12 15:02:08] [EMAIL PROTECTED] Personally, I would rather avoid adding configuration directives for something as small as this! :) [2001-12-12 14:45:10] [EMAIL PROTECTED] i'd like to have $whatever[...][...][x] and $whatever[...][...][y] in all cases, maybe with ini switches for old, new or both ... [2001-12-12 14:33:25] [EMAIL PROTECTED] Maybe we should just make $foo_x[123] and $foo_y[123] available in addition to $foo[123]? That should keep BC and still do things right, though we might want to change the value of $foo[123] to something like 'x,y' instead of just y??? 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/745 -- Edit this bug report at http://bugs.php.net/?id=745edit=1
#20774 [Opn-Bgs]: will not compile
ID: 20774 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.0RC2 New Comment: See this bug report: http://bugs.php.net/bug.php?id=16931edit=1 This is not a PHP bug - bogus. Previous Comments: [2002-12-02 17:05:38] [EMAIL PROTECTED] Solaris 8 gcc 3.1 apache 2.0.43 config /configure --with-apxs2=/www2/bin/apxs --with-gettext --with-xml --enable-ftp --with-mhash --with-gdbm --enable-bcmath --with-mysql --with-ldap=/usr/local --with-zlib --with-ndbm --enable-calendar --with-imap=/export/home/imiller/imap-2002 --with-openssl=/usr/local/ssl --with-mcrypt ( compile ) cc1: warning: changing search order for system directory /usr/local/include cc1: warning: as it has already been specified as a non-system directory /bin/ksh libtool --silent --mode=link gcc -g -O2 -prefer-pic -rpath /export/home/imiller/php-4.3.0RC2/libs -avoid-version -module -L/usr/ucblib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.1 -L/usr/local/ssl/lib -L/usr/local/lib -L/export/home/imiller/imap-2002/c-client -R /usr/ucblib -R /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.1 -R /usr/local/ssl/lib -R /usr/local/lib -R /export/home/imiller/imap-2002/c-client ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bcmath/bcmath.lo ext/bcmath/number.lo ext/bcmath/libbcmath/src/add.lo ext/bcmath/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src/neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/libbcmath/src/raisemod.lo ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/src/sub.lo ext/bcmath/libbcmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src/int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcmath/libbcmath/src/output.lo ext/bcmath/libbcmath/src/recmul.lo ext/bcmath/libbcmath/src/sqrt.lo ext/bcmath/libbcmath/src/zero.lo ext/bcmath/libbcmath/src/debug.lo ext/bcmath/libbcmath/src/doaddsub.lo ext/bcmath/libbcmath/src/nearzero.lo ext/bcmath/libbcmath/src/num2str.lo ext/bcmath/libbcmath/src/raise.lo ext/bcmath/libbcmath/src/rmzero.lo ext/bcmath/libbcmath/src/str2num.lo ext/calendar/calendar.lo ext/calendar/dow.lo ext/calendar/french.lo ext/calendar/gregor.lo ext/calendar/jewish.lo ext/calendar/julian.lo ext/calendar/easter.lo ext/calendar/cal_unix.lo ext/ctype/ctype.lo ext/dba/dba.lo ext/dba/dba_cdb.lo ext/dba/dba_db2.lo ext/dba/dba_dbm.lo ext/dba/dba_gdbm.lo ext/dba/dba_ndbm.lo ext/dba/dba_db3.lo ext/ftp/php_ftp.lo ext/ftp/ftp.lo ext/gettext/gettext.lo ext/imap/php_imap.lo ext/ldap/ldap.lo ext/mcrypt/mcrypt.lo ext/mhash/mhash.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql/libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_alloc.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/libmysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo ext/mysql/libmysql/thr_mutex.lo ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/string.lo ext/mysql/libmysql/default.lo ext/mysql/libmysql/my_compress.lo ext/mysql/libmysql/array.lo ext/mysql/libmysql/my_once.lo ext/mysql/libmysql/list.lo ext/mysql/libmysql/my_net.lo ext/mysql/libmysql/dbug.lo ext/mysql/libmysql/strmov.lo ext/mysql/libmysql/strxmov.lo ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/strmake.lo ext/mysql/libmysql/strend.lo ext/mysql/libmysql/strfill.lo ext/mysql/libmysql/is_prefix.lo ext/mysql/libmysql/int2str.lo ext/mysql/libmysql/str2int.lo ext/mysql/libmysql/strinstr.lo ext/mysql/libmysql/strcont.lo ext/mysql/libmysql/strcend.lo ext/mysql/libmysql/bchange.lo ext/mysql/libmysql/bmove.lo ext/mysql/libmysql/bmove_upp.lo ext/mysql/libmysql/longlong2str.lo ext/mysql/libmysql/strtoull.lo ext/mysql/libmysql/strtoll.lo ext/mysql/libmysql/charset.lo ext/mysql/libmysql/ctype.lo ext/openssl/openssl.lo ext/overload/overload.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo
#20764 [Opn-Fbk]: session_handler=mm complais about mm_malloc
ID: 20764 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related Operating System: RH7.2 PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-02 10:54:53] [EMAIL PROTECTED] I saw another thread about this bug: http://bugs.php.net/bug.php?id=19039 I've compiled PHP-4.2.3 to apache 1.3.27 including --with-mm (mm-1.1.3-8 devel packages installed). When using sessions (save_handler=mm) in PHP, it complains: Warning: mm_malloc failed, avail 0, err mm:core: Failed to lock (Permission denied) in Unknown on line 0 Seems to be some kind of permission problem in SHM. Not sure though what is wrong. -- Edit this bug report at http://bugs.php.net/?id=20764edit=1
#20777 [NEW]: will not find apache2 apxs
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.3.0RC2 PHP Bug Type: *Configuration Issues Bug description: will not find apache2 apxs ./configure --with-apxs2=/www/bin/apxs just testing Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking for mod_charset compatibility option... no checking for Apache 2.0 module support via DSO through APXS... Sorry, I cannot run apxs. Possible reasons follow: 1. Perl is not installed 2. apxs was not found. Try to pass the path using --with-apxs2=/path/to/apxs 3. Apache was not built using --enable-so (the apxs usage page is displayed) The output of /www2/bin/apxs follows: Usage: apxs -g [-S var=val] -n modname apxs -q [-S var=val] query ... apxs -c [-S var=val] [-o dsofile] [-D name[=value]] [-I incdir] [-L libdir] [-l libname] [-Wc,flags] [-Wl,flags] files ... apxs -i [-S var=val] [-a] [-A] [-n modname] dsofile ... apxs -e [-S var=val] [-a] [-A] [-n modname] dsofile ... configure: error: Aborting bash-2.05# perl asdf ^C bash-2.05# perl -v This is perl, v5.6.1 built for sun4-solaris Copyright 1987-2001, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.com/, the Perl Home Page. bash-2.05# -- Edit bug report at http://bugs.php.net/?id=20777edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20777r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20777r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20777r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20777r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20777r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20777r=support Expected behavior: http://bugs.php.net/fix.php?id=20777r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20777r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20777r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20777r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20777r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20777r=dst IIS Stability: http://bugs.php.net/fix.php?id=20777r=isapi
#20777 [Opn-Fbk]: will not find apache2 apxs
ID: 20777 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback -Bug Type: *Configuration Issues +Bug Type: Apache2 related Operating System: Solaris 8 PHP Version: 4.3.0RC2 New Comment: You're using /www/bin/apxs but showing the output of /www2/bin/apxs, so which one is the right one? Previous Comments: [2002-12-02 18:49:52] [EMAIL PROTECTED] ./configure --with-apxs2=/www/bin/apxs just testing Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking for mod_charset compatibility option... no checking for Apache 2.0 module support via DSO through APXS... Sorry, I cannot run apxs. Possible reasons follow: 1. Perl is not installed 2. apxs was not found. Try to pass the path using --with-apxs2=/path/to/apxs 3. Apache was not built using --enable-so (the apxs usage page is displayed) The output of /www2/bin/apxs follows: Usage: apxs -g [-S var=val] -n modname apxs -q [-S var=val] query ... apxs -c [-S var=val] [-o dsofile] [-D name[=value]] [-I incdir] [-L libdir] [-l libname] [-Wc,flags] [-Wl,flags] files ... apxs -i [-S var=val] [-a] [-A] [-n modname] dsofile ... apxs -e [-S var=val] [-a] [-A] [-n modname] dsofile ... configure: error: Aborting bash-2.05# perl asdf ^C bash-2.05# perl -v This is perl, v5.6.1 built for sun4-solaris Copyright 1987-2001, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.com/, the Perl Home Page. bash-2.05# -- Edit this bug report at http://bugs.php.net/?id=20777edit=1
#20766 [Opn-Bgs]: array_search doesn't return value with array as needle
ID: 20766 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Linux 2.2.20 PHP Version: 4.2.3 New Comment: It's printing just the correct values. Your $t2 array does not contain same array as $t1 is.. (try adding this: $t2[] = $t1; and you'll see..) Previous Comments: [2002-12-02 12:41:23] [EMAIL PROTECTED] $t1[] = banana; $t1[] = orange; $t1[] = kiwi; $t2[] = car; $t2[] = kiwi; $t2[] = cat; print Kiwi key: .array_search($t1,$t2); print Car key: .array_search(car,$t2); this code print: Kiwi key: Car key: 0 Should print: Kiwi key: 1 Car key: 0 Apache: 1.3.26 rh 6.2 -- Edit this bug report at http://bugs.php.net/?id=20766edit=1
#20677 [Opn]: Compile fail w/DB2 on AIX: Macro cannot be redefined
ID: 20677 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Compile Failure +Bug Type: ODBC related Operating System: AIX 5.1L PHP Version: 4CVS-2002-11-27 (dev) New Comment: Reclassified as ODBC related problem since that's where the bug is.. Previous Comments: [2002-12-02 09:30:05] [EMAIL PROTECTED] removing -ma from CCFLAGS gets rid of the incorrect pragma errors. No effect on the other problems. Reset problem type to Compile Failure (original intent) [2002-11-27 09:50:24] [EMAIL PROTECTED] AIX 5.1L , ibm VAC 6.0 compiler xlc_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192 DB2 7.1 11-27 CVS packaged configure deleted, rebuilt using buildconf Configured as: ./configure --with-apxs=/usr/sbin/apxs \ --enable-track-vars --enable-versioning \ --with-ibm-db2=/home/db2inst1/sqllib --sysconfdir=/etc \ --enable-force-cgi-redirect --enable-c9x-inline\ --with-mysql=/opt/freeware/ Configure works fine (no warnings or errors), make fails with: # make /bin/sh libtool --silent --mode=compile xlc_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192 -qnolm -Iext/ctype/ -I/usr/purerory/php4cvs/ext/ctype/ -DPHP_ATOM_INC -I/usr/purerory/php4cvs/include -I/usr/purerory/php4cvs/main -I/usr/purerory/php4cvs -I/usr/purerory/php4cvs/Zend -I/opt/freeware//include/mysql -I/usr/purerory/php4cvs/ext/xml/expat -I /usr/local/include -DAIX=43 -DUSE_PTHREAD_SERIALIZED_ACCEPT -DAIX_BIND_PROCESSOR -DUSE_HSREGEX -I/usr/purerory/php4cvs/TSRM -I /usr/local/include -prefer-pic -c /usr/purerory/php4cvs/ext/ctype/ctype.c -o ext/ctype/ctype.lo /usr/include/alloca.h, line 20.1: 1506-224 (I) Incorrect pragma ignored. /bin/sh libtool --silent --mode=compile xlc_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192 -qnolm -Iext/mysql/ -I/usr/purerory/php4cvs/ext/mysql/ -DPHP_ATOM_INC -I/usr/purerory/php4cvs/include -I/usr/purerory/php4cvs/main -I/usr/purerory/php4cvs -I/usr/purerory/php4cvs/Zend -I/opt/freeware//include/mysql -I/usr/purerory/php4cvs/ext/xml/expat -I /usr/local/include -DAIX=43 -DUSE_PTHREAD_SERIALIZED_ACCEPT -DAIX_BIND_PROCESSOR -DUSE_HSREGEX -I/usr/purerory/php4cvs/TSRM -I /usr/local/include -prefer-pic -c /usr/purerory/php4cvs/ext/mysql/php_mysql.c -o ext/mysql/php_mysql.lo /usr/include/alloca.h, line 20.1: 1506-224 (I) Incorrect pragma ignored. /bin/sh libtool --silent --mode=compile xlc_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192 -qnolm -I/home/db2inst1/sqllib/include -Iext/odbc/ -I/usr/purerory/php4cvs/ext/odbc/ -DPHP_ATOM_INC -I/usr/purerory/php4cvs/include -I/usr/purerory/php4cvs/main -I/usr/purerory/php4cvs -I/usr/purerory/php4cvs/Zend -I/opt/freeware//include/mysql -I/usr/purerory/php4cvs/ext/xml/expat -I /usr/local/include -DAIX=43 -DUSE_PTHREAD_SERIALIZED_ACCEPT -DAIX_BIND_PROCESSOR -DUSE_HSREGEX -I/usr/purerory/php4cvs/TSRM -I /usr/local/include -prefer-pic -c /usr/purerory/php4cvs/ext/odbc/php_odbc.c -o ext/odbc/php_odbc.lo /usr/include/alloca.h, line 20.1: 1506-224 (I) Incorrect pragma ignored. /usr/purerory/php4cvs/ext/standard/php_image.h, line 48.21: 1506-275 (S) Unexpected text ',' encountered. /home/db2inst1/sqllib/include/sqlcli.h, line 718.9: 1506-213 (S) Macro name ODBCVER cannot be redefined. /home/db2inst1/sqllib/include/sqlcli.h, line 718.9: 1506-358 (I) ODBCVER is defined on line 27 of /usr/purerory/php4cvs/ext/odbc/php_odbc.h. /home/db2inst1/sqllib/include/sqlcli1.h, line 126.10: 1506-213 (S) Macro name SQL_EXT_API_LAST cannot be redefined. /home/db2inst1/sqllib/include/sqlcli1.h, line 126.10: 1506-358 (I) SQL_EXT_API_LAST is defined on line 621 of /home/db2inst1/sqllib/include/sqlext.h. /home/db2inst1/sqllib/include/sqlcli1.h, line 207.10: 1506-213 (S) Macro name SQL_OJ_CAPABILITIES cannot be redefined. /home/db2inst1/sqllib/include/sqlcli1.h, line 207.10: 1506-358 (I) SQL_OJ_CAPABILITIES is defined on line 764 of /home/db2inst1/sqllib/include/sqlext.h. /home/db2inst1/sqllib/include/sqlcli1.h, line 219.9: 1506-213 (S) Macro name SQL_INFO_LAST cannot be redefined. /home/db2inst1/sqllib/include/sqlcli1.h, line 219.9: 1506-358 (I) SQL_INFO_LAST is defined on line 776 of /home/db2inst1/sqllib/include/sqlext.h. /usr/purerory/php4cvs/ext/odbc/php_odbc.c, line 199.30: 1506-280 (S) Function argument assignment between types long and void* is not allowed. ... last item repeats 55 times on different lines of php_odbc.c, as above Same compile error on PHP 4.2.3 and 11-27 Stable Problem is similar to bug #13695, which was closed as no feedback -- Edit this bug report at http://bugs.php.net/?id=20677edit=1
#20762 [Opn]: Warning compiling with mailparse
ID: 20762 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Warning Operating System: Linux PHP Version: 4.3.0RC2 New Comment: You can ignore those paths. Previous Comments: [2002-12-02 08:44:35] [EMAIL PROTECTED] output: [...] /home/wez/src/php/PHPDEV/ext/mailparse/php_mailparse_rfc822.re: In function `tokenize': /home/wez/src/php/PHPDEV/ext/mailparse/php_mailparse_rfc822.re:191: warning: deprecated use of label at end of compound statement [...] I don't have that kind of directories ;) -- Edit this bug report at http://bugs.php.net/?id=20762edit=1
#20776 [Bgs]: Login only possible from page where login is required.
ID: 20776
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Win2K Server
PHP Version: 4.2.3
New Comment:
I would have thought that code with two results depending on the how
the return path is acquired would definitely imply a bug, or am I
missing something obvious here? I have a ton of programming experience
(including proprietary systems similar to but more complex than PHP)
but I'm very new at PHP itself so you may be right.
Previous Comments:
[2002-12-02 18:44:38] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
[2002-12-02 18:38:24] [EMAIL PROTECTED]
The login script I am using ( part of a tutorial by Ying Zhang, see
http://zope1.devshed.com/zope.devshed.com/Server_Side/PHP/Commerce ) is
only working when entered from a page requiring login. If login is
voluntary by clicking on a login link, then login does not occur.
The only difference is the execution of the following code from the
MyMarket.php library:
function is_logged_in() {
/* this function will return true if the user has logged in. a user is
logged
* in if the $SESSION[user] is set (by the login.php page) and also
if the
* remote IP address matches what we saved in the session
($SESSION[ip])
* from login.php -- this is not a robust or secure check by any means,
but it
* will do for now */
global $SESSION, $REMOTE_ADDR;
return isset($SESSION)
isset($SESSION[user])
isset($SESSION[ip])
$SESSION[ip] == $REMOTE_ADDR;
}
function require_login() {
/* this function checks to see if the user is logged in. if not, it
will show
* the login screen before allowing the user to continue */
global $CFG, $SESSION;
if (! is_logged_in()) {
$SESSION[wantsurl] = qualified_me();
redirect($CFG-wwwroot/login.php);
}
}
This code was developed in and is known to have worked in PHP4 beta.
Note that the tutorial requires register_globals=On also, in case you
decide to test it.
qualified_me() returns the name of the current script without the
querystring portion. As delivered it didn't work, I'm using a stripped
$_SERVER['SCRIPT_NAME'].
wantsurl is used later by the following code:
/* if wantsurl is set, that means we came from a page that required
* log in, so let's go back there. otherwise go back to the main
page */
$goto = empty($SESSION[wantsurl]) ? $CFG-wwwroot . /index.php :
$SESSION[wantsurl];
header(Location: $goto);
die;
The error only occurs if $CFG-wwwroot/index.php is called. Hope this
is enough information to nail the sucker.
--
Edit this bug report at http://bugs.php.net/?id=20776edit=1
#20766 [Bgs]: array_search doesn't return value with array as needle
ID: 20766 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Arrays related Operating System: Linux 2.2.20 PHP Version: 4.2.3 New Comment: It does work with $t1[] = $t2[]; But it's inneficient. Previous Comments: [2002-12-02 18:56:18] [EMAIL PROTECTED] It's printing just the correct values. Your $t2 array does not contain same array as $t1 is.. (try adding this: $t2[] = $t1; and you'll see..) [2002-12-02 12:41:23] [EMAIL PROTECTED] $t1[] = banana; $t1[] = orange; $t1[] = kiwi; $t2[] = car; $t2[] = kiwi; $t2[] = cat; print Kiwi key: .array_search($t1,$t2); print Car key: .array_search(car,$t2); this code print: Kiwi key: Car key: 0 Should print: Kiwi key: 1 Car key: 0 Apache: 1.3.26 rh 6.2 -- Edit this bug report at http://bugs.php.net/?id=20766edit=1
#20778 [NEW]: cannot configure with pfpro
From: [EMAIL PROTECTED] Operating system: Sun sparc solaris 9 PHP version: 4.2.3 PHP Bug Type: *Configuration Issues Bug description: cannot configure with pfpro ./configure --prefix=/usr/local/php-4.2.3 --with-apxs=/usr/local/apache-1.3.26/bin/apxs --with-pfpro=shared,/web/order/verisign/payflowpro/sunsparc/lib The pfpro SDK version I used is the latest 3.06 Here is part of the output of the configuration that shows the failure: Configuring extensions checking if the location of ZLIB install directory is defined... no checking for ZLIB support... no checking for ASPELL support... no checking whether to enable bc style precision math functions... no checking for BZip2 support... no checking whether to enable calendar conversion support... no checking for CCVS support... no checking for cpdflib support... no checking for CRACKlib support... no checking whether to enable ctype functions... yes checking for CURL support... no checking for CyberCash support... no checking for cybermut support... no checking for cyrus imap support... no checking for xDBM support... no checking whether to enable DBA... no checking for GDBM support... no checking for NDBM support... no checking for Berkeley DB2 support... no checking for Berkeley DB3 support... no checking for DBM support... no checking for CDB support... no checking whether to enable DBA interface... no checking whether to enable dbase support... no checking for dbplus support... no checking whether to enable dbx support... no checking whether to enable direct I/O support... no checking for DOM support... no checking for DOM XSLT support... no checking for DOM EXSLT support... no checking whether to enable EXIF support... no checking for FrontBase SQL92 (fbsql) support... no checking for FDF support... no checking whether to enable the bundled filePro support... no checking for FriBidi support... no checking whether to enable FTP support... no checking for GD support... no checking for GNU gettext support... no checking for GNU MP support... no checking for Hyperwave support... no checking for ICAP support... no checking for iconv support... no checking for IMAP support... no checking for Informix support... no checking for Ingres II support... no checking for InterBase support... no checking for IRCG support... no checking for Java support... no checking for LDAP support... no checking whether to enable multibyte string support... no checking whether to enable japanese encoding translation... no checking whether to enable multibyte regex support... no checking for MCAL support... no checking for mcrypt support... no checking for MCVE support... no checking for mhash support... no checking for MING support... no checking for mnoGoSearch support... no checking for msession support... no checking for mSQL support... no checking for Muscat support... no checking for MySQL support... yes checking for MySQL UNIX socket... /tmp/mysql.sock checking for inline... inline checking return type of signal handlers... void checking for ANSI C header files... (cached) yes checking for sgtty.h... yes checking for sys/ioctl.h... yes checking for fcntl.h... (cached) yes checking for float.h... yes checking for floatingpoint.h... yes checking for ieeefp.h... (cached) yes checking for limits.h... (cached) yes checking for memory.h... yes checking for pwd.h... (cached) yes checking for select.h... no checking for stdlib.h... (cached) yes checking for stddef.h... yes checking for strings.h... yes checking for string.h... (cached) yes checking for synch.h... yes checking for sys/mman.h... (cached) yes checking for sys/socket.h... (cached) yes checking for sys/timeb.h... yes checking for sys/types.h... (cached) yes checking for sys/un.h... yes checking for sys/vadvise.h... no checking for sys/wait.h... (cached) yes checking for term.h... yes checking for unistd.h... (cached) yes checking for utime.h... (cached) yes checking for sys/utime.h... yes checking for termio.h... yes checking for termios.h... yes checking for sched.h... yes checking for crypt.h... (cached) yes checking for alloca.h... (cached) yes checking size of char... 1 checking size of int... (cached) 4 checking size of long... (cached) 4 checking size of long long... 8 checking for size_t... (cached) yes checking whether time.h and sys/time.h may both be included... yes checking for uid_t in sys/types.h... (cached) yes checking for type ulong... yes checking for type uchar... no checking for type uint... yes checking for type ushort... yes checking for int8... no checking base type of last arg to accept... socklen_t checking return type of qsort... void checking for alarm... yes checking for bmove... no checking for chsize... no checking for ftruncate... yes checking for rint... yes checking for finite... yes checking for fpsetmask... yes checking for fpresetsticky... no
#20778 [Opn-Fbk]: cannot configure with pfpro
ID: 20778 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Configuration Issues Operating System: Sun sparc solaris 9 PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-02 19:30:34] [EMAIL PROTECTED] ./configure --prefix=/usr/local/php-4.2.3 --with-apxs=/usr/local/apache-1.3.26/bin/apxs --with-pfpro=shared,/web/order/verisign/payflowpro/sunsparc/lib The pfpro SDK version I used is the latest 3.06 Here is part of the output of the configuration that shows the failure: Configuring extensions checking if the location of ZLIB install directory is defined... no checking for ZLIB support... no checking for ASPELL support... no checking whether to enable bc style precision math functions... no checking for BZip2 support... no checking whether to enable calendar conversion support... no checking for CCVS support... no checking for cpdflib support... no checking for CRACKlib support... no checking whether to enable ctype functions... yes checking for CURL support... no checking for CyberCash support... no checking for cybermut support... no checking for cyrus imap support... no checking for xDBM support... no checking whether to enable DBA... no checking for GDBM support... no checking for NDBM support... no checking for Berkeley DB2 support... no checking for Berkeley DB3 support... no checking for DBM support... no checking for CDB support... no checking whether to enable DBA interface... no checking whether to enable dbase support... no checking for dbplus support... no checking whether to enable dbx support... no checking whether to enable direct I/O support... no checking for DOM support... no checking for DOM XSLT support... no checking for DOM EXSLT support... no checking whether to enable EXIF support... no checking for FrontBase SQL92 (fbsql) support... no checking for FDF support... no checking whether to enable the bundled filePro support... no checking for FriBidi support... no checking whether to enable FTP support... no checking for GD support... no checking for GNU gettext support... no checking for GNU MP support... no checking for Hyperwave support... no checking for ICAP support... no checking for iconv support... no checking for IMAP support... no checking for Informix support... no checking for Ingres II support... no checking for InterBase support... no checking for IRCG support... no checking for Java support... no checking for LDAP support... no checking whether to enable multibyte string support... no checking whether to enable japanese encoding translation... no checking whether to enable multibyte regex support... no checking for MCAL support... no checking for mcrypt support... no checking for MCVE support... no checking for mhash support... no checking for MING support... no checking for mnoGoSearch support... no checking for msession support... no checking for mSQL support... no checking for Muscat support... no checking for MySQL support... yes checking for MySQL UNIX socket... /tmp/mysql.sock checking for inline... inline checking return type of signal handlers... void checking for ANSI C header files... (cached) yes checking for sgtty.h... yes checking for sys/ioctl.h... yes checking for fcntl.h... (cached) yes checking for float.h... yes checking for floatingpoint.h... yes checking for ieeefp.h... (cached) yes checking for limits.h... (cached) yes checking for memory.h... yes checking for pwd.h... (cached) yes checking for select.h... no checking for stdlib.h... (cached) yes checking for stddef.h... yes checking for strings.h... yes checking for string.h... (cached) yes checking for synch.h... yes checking for sys/mman.h... (cached) yes checking for sys/socket.h... (cached) yes checking for sys/timeb.h... yes checking for sys/types.h... (cached) yes checking for sys/un.h... yes checking for sys/vadvise.h... no checking for sys/wait.h... (cached) yes checking for term.h... yes checking for unistd.h... (cached) yes checking for utime.h... (cached) yes checking for sys/utime.h... yes checking for termio.h... yes checking for termios.h... yes checking for sched.h... yes checking for crypt.h... (cached) yes checking for alloca.h... (cached) yes checking size of char... 1 checking size of int... (cached) 4 checking size of long... (cached) 4 checking size of long long... 8 checking for size_t... (cached) yes checking whether time.h and sys/time.h may both be included... yes checking for uid_t in sys/types.h... (cached) yes checking for type ulong... yes checking for type uchar... no checking for type uint... yes checking
#16411 [Opn]: CGI application misbehaved by not returning a complete set of
ID: 16411 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: Database connections are all transient. In the original code, I did not close the connections because php would do that at the end of script. But as I was in doubt, I later made a close right before calling the function header() but the same problem happened. I also made another test: in the script I just opened and immediately right after colsed it. The same bug happened. When I removed that tiny chunk of code, every thing worked just fine. Previous Comments: [2002-11-30 20:36:38] [EMAIL PROTECTED] What are you doing with your database connections? Are they persistant (mssql_pconnect) or transient (mssql_connect)? Do you close your connections explicitly (mssql_close) before the end of your script? vielina, your connections will be closed each time as you are running under the CGI. [2002-11-21 03:29:36] [EMAIL PROTECTED] I have this problem too. [2002-06-20 15:19:45] [EMAIL PROTECTED] Same problem, slightly different case... win2000 running php.exe 4.2.1 (and mssql 2000) seems to happen mostly during redrects like... header(Method: GET); header(Status: 302 Moved); header(Location: . $ABSOLUTE_URL); some claim they solved this problem by applying the workaround by microsoft (Q160422). others say they have fixed this by blanking out the doc_root in php.ini I still have this problem [2002-06-02 22:14:18] [EMAIL PROTECTED] I did that but it still did not work. I further tested another way: I left every thing as it was, except that I did not open an MSSQL connection. The script worked pretty well. When I changed it back, the same type of bug happened. When looking at phpinfo, even with the latest php version (4.2.1) I saw that in the MSSQL support section, the MSSQL library version was 7.0. Is this a potential source of that bug? Loi Le V. [2002-06-02 17:53:17] [EMAIL PROTECTED] Please try it again with a right header like Location: http://www.domain.tld/some.php. Location header needs a complete absolute URI. Regards, Kai 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/16411 -- Edit this bug report at http://bugs.php.net/?id=16411edit=1
#16411 [Opn]: CGI application misbehaved by not returning a complete set of
ID: 16411 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: Database connections are all transient. In the original code, I did not close the connections because php would do that at the end of script. But as I was in doubt, I later made a close right before calling the function header() but the same problem happened. I also made another test: in the script I just opened and immediately right after colsed it. The same bug happened. When I removed that tiny chunk of code, every thing worked just fine. Previous Comments: [2002-12-02 19:57:52] [EMAIL PROTECTED] Database connections are all transient. In the original code, I did not close the connections because php would do that at the end of script. But as I was in doubt, I later made a close right before calling the function header() but the same problem happened. I also made another test: in the script I just opened and immediately right after colsed it. The same bug happened. When I removed that tiny chunk of code, every thing worked just fine. [2002-11-30 20:36:38] [EMAIL PROTECTED] What are you doing with your database connections? Are they persistant (mssql_pconnect) or transient (mssql_connect)? Do you close your connections explicitly (mssql_close) before the end of your script? vielina, your connections will be closed each time as you are running under the CGI. [2002-11-21 03:29:36] [EMAIL PROTECTED] I have this problem too. [2002-06-20 15:19:45] [EMAIL PROTECTED] Same problem, slightly different case... win2000 running php.exe 4.2.1 (and mssql 2000) seems to happen mostly during redrects like... header(Method: GET); header(Status: 302 Moved); header(Location: . $ABSOLUTE_URL); some claim they solved this problem by applying the workaround by microsoft (Q160422). others say they have fixed this by blanking out the doc_root in php.ini I still have this problem [2002-06-02 22:14:18] [EMAIL PROTECTED] I did that but it still did not work. I further tested another way: I left every thing as it was, except that I did not open an MSSQL connection. The script worked pretty well. When I changed it back, the same type of bug happened. When looking at phpinfo, even with the latest php version (4.2.1) I saw that in the MSSQL support section, the MSSQL library version was 7.0. Is this a potential source of that bug? Loi Le V. 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/16411 -- Edit this bug report at http://bugs.php.net/?id=16411edit=1
#20776 [Bgs-Opn]: Login only possible from page where login is required.
ID: 20776
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Unknown/Other Function
Operating System: Win2K Server
PHP Version: 4.2.3
New Comment:
At top of login page:
session_start();
session_register(SESSION);
if (! isset($SESSION)) { echo(Dead session!!br); }
From a direct a href style link I get Dead session!! at the top of
the page. From a redirect via require_login() (see below) it works.
Sure looks like a bug to me.
Previous Comments:
[2002-12-02 19:23:14] [EMAIL PROTECTED]
I would have thought that code with two results depending on the how
the return path is acquired would definitely imply a bug, or am I
missing something obvious here? I have a ton of programming experience
(including proprietary systems similar to but more complex than PHP)
but I'm very new at PHP itself so you may be right.
[2002-12-02 18:44:38] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
[2002-12-02 18:38:24] [EMAIL PROTECTED]
The login script I am using ( part of a tutorial by Ying Zhang, see
http://zope1.devshed.com/zope.devshed.com/Server_Side/PHP/Commerce ) is
only working when entered from a page requiring login. If login is
voluntary by clicking on a login link, then login does not occur.
The only difference is the execution of the following code from the
MyMarket.php library:
function is_logged_in() {
/* this function will return true if the user has logged in. a user is
logged
* in if the $SESSION[user] is set (by the login.php page) and also
if the
* remote IP address matches what we saved in the session
($SESSION[ip])
* from login.php -- this is not a robust or secure check by any means,
but it
* will do for now */
global $SESSION, $REMOTE_ADDR;
return isset($SESSION)
isset($SESSION[user])
isset($SESSION[ip])
$SESSION[ip] == $REMOTE_ADDR;
}
function require_login() {
/* this function checks to see if the user is logged in. if not, it
will show
* the login screen before allowing the user to continue */
global $CFG, $SESSION;
if (! is_logged_in()) {
$SESSION[wantsurl] = qualified_me();
redirect($CFG-wwwroot/login.php);
}
}
This code was developed in and is known to have worked in PHP4 beta.
Note that the tutorial requires register_globals=On also, in case you
decide to test it.
qualified_me() returns the name of the current script without the
querystring portion. As delivered it didn't work, I'm using a stripped
$_SERVER['SCRIPT_NAME'].
wantsurl is used later by the following code:
/* if wantsurl is set, that means we came from a page that required
* log in, so let's go back there. otherwise go back to the main
page */
$goto = empty($SESSION[wantsurl]) ? $CFG-wwwroot . /index.php :
$SESSION[wantsurl];
header(Location: $goto);
die;
The error only occurs if $CFG-wwwroot/index.php is called. Hope this
is enough information to nail the sucker.
--
Edit this bug report at http://bugs.php.net/?id=20776edit=1
#20779 [NEW]: Several dll entry points not found in php4ts.dll
From: [EMAIL PROTECTED] Operating system: Win2k Pro PHP version: 4.3.0RC2 PHP Bug Type: Dynamic loading Bug description: Several dll entry points not found in php4ts.dll I have installed Apache 2.0.43 as a service on Win 2k with PHP 4.2.3. These are upgrades from Apache 2.0.39 and PHP 4.2.2. Now I had previuosly enabled the following php extensions and they worked fine in the older setup. Now, after the upgrade, they don't. They are bz2, ctypye, curl, ming, pdf, zlib. The errors are: php_bz2.dll Apache.exe - Entry Point Not Found The procedure entry point php_file_le_fpoen could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_bz.dll' - The procedure could not be found' php_ctype functions: Warning Function registration failed - duplicate name - ctype_alnum Warning Function registration failed - duplicate name - ctype_alpha Warning Function registration failed - duplicate name - ctype_cntrl Warning Function registration failed - duplicate name - ctype_digit Warning FunctioWarning Function registration failed - duplicate name - ctype_print Warning Function registration failed - duplicate name - ctype_space Warning Function registration failed - duplicate name - ctype_upper Warning Function registration failed - duplicate name - ctype_xdigit Warning ctype: unable to register function, unable to load php_curl.dll: Apache.exe - Entry Point Not Found The procedure entry point php_file_le_fpoen could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_bz.dll' - The procedure could not be found' php_ming.dll Apache.exe - Entry Point Not Found The procedure entry point php_fsock_fread could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_ming.dll' - The procedure could not be found' php_pdf.dll Apache.exe - Entry Point Not Found The procedure entry point zif_warn_not_available could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_pdf.dll' - The procedure could not be found' php_zlib.dll Apache.exe - Entry Point Not Found The procedure entry point php_fopen_wrapper could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_zlib.dll' - The procedure could not be found' End of errors details. --- The workaround works by disabling these extension in the php.ini file but this is not pratical for me long term. The extension folder is located under :c:/php/extensions. This problems occured after the upgrade to the latest versions of php and apache. Please assist, as it would be much appreciated. Charlie -- Edit bug report at http://bugs.php.net/?id=20779edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20779r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20779r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20779r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20779r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20779r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20779r=support Expected behavior: http://bugs.php.net/fix.php?id=20779r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20779r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20779r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20779r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20779r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20779r=dst IIS Stability: http://bugs.php.net/fix.php?id=20779r=isapi
#20779 [Com]: Several dll entry points not found in php4ts.dll
ID: 20779 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Dynamic loading Operating System: Win2k Pro PHP Version: 4.3.0RC2 New Comment: Please excuse the spelling mistake : dynamic link librart should be dynamic link library. Previous Comments: [2002-12-02 21:26:21] [EMAIL PROTECTED] I have installed Apache 2.0.43 as a service on Win 2k with PHP 4.2.3. These are upgrades from Apache 2.0.39 and PHP 4.2.2. Now I had previuosly enabled the following php extensions and they worked fine in the older setup. Now, after the upgrade, they don't. They are bz2, ctypye, curl, ming, pdf, zlib. The errors are: php_bz2.dll Apache.exe - Entry Point Not Found The procedure entry point php_file_le_fpoen could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_bz.dll' - The procedure could not be found' php_ctype functions: Warning Function registration failed - duplicate name - ctype_alnum Warning Function registration failed - duplicate name - ctype_alpha Warning Function registration failed - duplicate name - ctype_cntrl Warning Function registration failed - duplicate name - ctype_digit Warning FunctioWarning Function registration failed - duplicate name - ctype_print Warning Function registration failed - duplicate name - ctype_space Warning Function registration failed - duplicate name - ctype_upper Warning Function registration failed - duplicate name - ctype_xdigit Warning ctype: unable to register function, unable to load php_curl.dll: Apache.exe - Entry Point Not Found The procedure entry point php_file_le_fpoen could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_bz.dll' - The procedure could not be found' php_ming.dll Apache.exe - Entry Point Not Found The procedure entry point php_fsock_fread could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_ming.dll' - The procedure could not be found' php_pdf.dll Apache.exe - Entry Point Not Found The procedure entry point zif_warn_not_available could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_pdf.dll' - The procedure could not be found' php_zlib.dll Apache.exe - Entry Point Not Found The procedure entry point php_fopen_wrapper could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_zlib.dll' - The procedure could not be found' End of errors details. --- The workaround works by disabling these extension in the php.ini file but this is not pratical for me long term. The extension folder is located under :c:/php/extensions. This problems occured after the upgrade to the latest versions of php and apache. Please assist, as it would be much appreciated. Charlie -- Edit this bug report at http://bugs.php.net/?id=20779edit=1
#20779 [Opn]: Several dll entry points not found in php4ts.dll
ID: 20779 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Dynamic loading Operating System: Win2k Pro PHP Version: 4.3.0RC2 New Comment: From the docs: http://www.php.net/manual/en/printwn/install.apache2.php Note: Apache 2.0 SAPI-support started with PHP 4.2.0. PHP 4.2.3 its known to work in conjunction with Apache 2.0.39. Don't try to use this version of PHP with any other version of Apache. We do not recommend to use PHP 4.2.3 along with Apache 2.0.39. And btw, are you trying 4.2.3 or 4.3.0RC2, you list both in this bug report. This looks like an Apache2 related bug so the category may want to reflect that but I personally have no idea so won't touch it :) Previous Comments: [2002-12-02 21:28:38] [EMAIL PROTECTED] Please excuse the spelling mistake : dynamic link librart should be dynamic link library. [2002-12-02 21:26:21] [EMAIL PROTECTED] I have installed Apache 2.0.43 as a service on Win 2k with PHP 4.2.3. These are upgrades from Apache 2.0.39 and PHP 4.2.2. Now I had previuosly enabled the following php extensions and they worked fine in the older setup. Now, after the upgrade, they don't. They are bz2, ctypye, curl, ming, pdf, zlib. The errors are: php_bz2.dll Apache.exe - Entry Point Not Found The procedure entry point php_file_le_fpoen could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_bz.dll' - The procedure could not be found' php_ctype functions: Warning Function registration failed - duplicate name - ctype_alnum Warning Function registration failed - duplicate name - ctype_alpha Warning Function registration failed - duplicate name - ctype_cntrl Warning Function registration failed - duplicate name - ctype_digit Warning FunctioWarning Function registration failed - duplicate name - ctype_print Warning Function registration failed - duplicate name - ctype_space Warning Function registration failed - duplicate name - ctype_upper Warning Function registration failed - duplicate name - ctype_xdigit Warning ctype: unable to register function, unable to load php_curl.dll: Apache.exe - Entry Point Not Found The procedure entry point php_file_le_fpoen could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_bz.dll' - The procedure could not be found' php_ming.dll Apache.exe - Entry Point Not Found The procedure entry point php_fsock_fread could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_ming.dll' - The procedure could not be found' php_pdf.dll Apache.exe - Entry Point Not Found The procedure entry point zif_warn_not_available could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_pdf.dll' - The procedure could not be found' php_zlib.dll Apache.exe - Entry Point Not Found The procedure entry point php_fopen_wrapper could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_zlib.dll' - The procedure could not be found' End of errors details. --- The workaround works by disabling these extension in the php.ini file but this is not pratical for me long term. The extension folder is located under :c:/php/extensions. This problems occured after the upgrade to the latest versions of php and apache. Please assist, as it would be much appreciated. Charlie -- Edit this bug report at http://bugs.php.net/?id=20779edit=1
#20495 [Opn-Csd]: BC Math is not Thread Safe, but is in Win32 TS distribution
ID: 20495 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: BC math related Operating System: Windows 2000 PHP Version: 4.3.0RC1 New Comment: Fixed in CVS for 4.3.0RC2. Previous Comments: [2002-11-19 09:14:10] [EMAIL PROTECTED] I'm adding this bug report to make sure it doesn't get lost. I would ask that this be marked critial for 4.3.0 release. The current thread safe Win32 build is _not_ thread safe because it includes BC Math as a built-in extension, but BC Math is not thread safe. Here is what I said on the php-dev list: I'm seeing a memory overrun under PHP 4.3.0pre2 (debug) running under Windows 2000 ISAPI. [ . . . ] --- C:\Work\php-source\php-4.3.0pre2\ext\bcmath\libbcmath\src\init.c(72): Freeing 0x01B85050 (1 bytes), script=c:\inetpub\wwwroot\test.php Last leak repeated 2 times C:\Work\php-source\php-4.3.0pre2\ext\bcmath\libbcmath\src\init.c(57): Freeing 0x01B84FF8 (29 bytes), script=c:\inetpub\wwwroot\test.php Last leak repeated 2 times Based on seeing these leaks I disabled BCMath and recompiled PHP. Without BCMath active I do not have any of the memory overruns that I reported in my previous message. Looking in the CVS logs for php4/ext/bcmath/bcmath.c I believe there may be an issue with the changes introduced in version 1.37 (by Andi, who is CCed also). This patch moved the allocation and freeing of the static BC numbers _zero_, _one_, and _two_ to a per-request basis instead of at module initilzation and shutdown. It looks like the storage locations for those values are global externs, however, which multiple threads are now allocating and deallocating at the same time. Is there somewhere that I'm not understanding in the code that would keep multiple threads from smashing each other here? And these were Andi's responses: You are right. I screwed up. I have to make these TSRM globals. I'll try and do it tomorrow. Adding a BCMATH_G() TSRM macro around all instances of _one_, _two_ and _zero_ seems to be quite a pain because it means that libbcmath needs to understand TSRM now. On the other hand these three variables need to be per-request because emalloc()'ed memory can't survive in between requests. Does anyone have any interesting solutions? If not I guess we can start hacking at the libbcmath sources. -- Edit this bug report at http://bugs.php.net/?id=20495edit=1
#17552 [Com]: PHP Apache DSO Compile Failure: Unresolved Symbol: pthread_getspecific
ID: 17552 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Compile Failure Operating System: Linux 2.4.18 Glibc PHP Version: 4.2.1 New Comment: This occurs using apache-2.0.43 and php-4.2.3 on FreeBSD4.7 Compiled with the following options: ./configure --with-mysql --with-apxs When I run apache I get the following error: Syntax error on line 230 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/apache/modules/libphp4.so into server: /usr/local/apache/modules/libphp4.so: Undefined symbol pthread_getspecific Previous Comments: [2002-11-21 06:33:36] [EMAIL PROTECTED] The same error with me when I try to start Apache service. the configure options that I used for PHP: --with-mysql --with-apxs2 SO: FreeBSD 4.7 Apache: 2.0.43 PHP: 4.2.3 [2002-11-15 10:33:11] [EMAIL PROTECTED] This occurs using apache-1.3.26 and php-4.2.3 on SuSE7.1 when using --with-apxs. I've tried adding LDFLAGS=-lpthread just to persuade it to link against that library, but it still doesn't like me - ldd on libphp4.so makes no difference that way. Am reverting to --with-apache instead on the off-chance it works... [2002-09-11 11:14:10] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2002-06-17 21:25:09] [EMAIL PROTECTED] Can not reproduce this with. Please try this snapshot: http://snaps.php.net/php4-latest.tar.gz [2002-06-01 07:00:04] [EMAIL PROTECTED] ah, ok, static module. I'm reopening this since it still should work as a true DSO though. 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/17552 -- Edit this bug report at http://bugs.php.net/?id=17552edit=1
#20677 [Opn-Fbk]: Compile fail w/DB2 on AIX: Macro cannot be redefined
ID: 20677 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: ODBC related Operating System: AIX 5.1L PHP Version: 4CVS-2002-11-27 (dev) New Comment: Well the CCFLAG isn't set inside of the ODBC config.m4. Does this happen with only the --with-ibm-db2 option choosen? Aka whats the minimal amount of configure options that causes this to not happen. I don't see anything glaringly wrong... the only thing that comes to mind is the ODBCVER issue which hasn't been a problem in the past. Previous Comments: [2002-12-02 18:57:36] [EMAIL PROTECTED] Reclassified as ODBC related problem since that's where the bug is.. [2002-12-02 09:30:05] [EMAIL PROTECTED] removing -ma from CCFLAGS gets rid of the incorrect pragma errors. No effect on the other problems. Reset problem type to Compile Failure (original intent) [2002-11-27 09:50:24] [EMAIL PROTECTED] AIX 5.1L , ibm VAC 6.0 compiler xlc_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192 DB2 7.1 11-27 CVS packaged configure deleted, rebuilt using buildconf Configured as: ./configure --with-apxs=/usr/sbin/apxs \ --enable-track-vars --enable-versioning \ --with-ibm-db2=/home/db2inst1/sqllib --sysconfdir=/etc \ --enable-force-cgi-redirect --enable-c9x-inline\ --with-mysql=/opt/freeware/ Configure works fine (no warnings or errors), make fails with: # make /bin/sh libtool --silent --mode=compile xlc_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192 -qnolm -Iext/ctype/ -I/usr/purerory/php4cvs/ext/ctype/ -DPHP_ATOM_INC -I/usr/purerory/php4cvs/include -I/usr/purerory/php4cvs/main -I/usr/purerory/php4cvs -I/usr/purerory/php4cvs/Zend -I/opt/freeware//include/mysql -I/usr/purerory/php4cvs/ext/xml/expat -I /usr/local/include -DAIX=43 -DUSE_PTHREAD_SERIALIZED_ACCEPT -DAIX_BIND_PROCESSOR -DUSE_HSREGEX -I/usr/purerory/php4cvs/TSRM -I /usr/local/include -prefer-pic -c /usr/purerory/php4cvs/ext/ctype/ctype.c -o ext/ctype/ctype.lo /usr/include/alloca.h, line 20.1: 1506-224 (I) Incorrect pragma ignored. /bin/sh libtool --silent --mode=compile xlc_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192 -qnolm -Iext/mysql/ -I/usr/purerory/php4cvs/ext/mysql/ -DPHP_ATOM_INC -I/usr/purerory/php4cvs/include -I/usr/purerory/php4cvs/main -I/usr/purerory/php4cvs -I/usr/purerory/php4cvs/Zend -I/opt/freeware//include/mysql -I/usr/purerory/php4cvs/ext/xml/expat -I /usr/local/include -DAIX=43 -DUSE_PTHREAD_SERIALIZED_ACCEPT -DAIX_BIND_PROCESSOR -DUSE_HSREGEX -I/usr/purerory/php4cvs/TSRM -I /usr/local/include -prefer-pic -c /usr/purerory/php4cvs/ext/mysql/php_mysql.c -o ext/mysql/php_mysql.lo /usr/include/alloca.h, line 20.1: 1506-224 (I) Incorrect pragma ignored. /bin/sh libtool --silent --mode=compile xlc_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192 -qnolm -I/home/db2inst1/sqllib/include -Iext/odbc/ -I/usr/purerory/php4cvs/ext/odbc/ -DPHP_ATOM_INC -I/usr/purerory/php4cvs/include -I/usr/purerory/php4cvs/main -I/usr/purerory/php4cvs -I/usr/purerory/php4cvs/Zend -I/opt/freeware//include/mysql -I/usr/purerory/php4cvs/ext/xml/expat -I /usr/local/include -DAIX=43 -DUSE_PTHREAD_SERIALIZED_ACCEPT -DAIX_BIND_PROCESSOR -DUSE_HSREGEX -I/usr/purerory/php4cvs/TSRM -I /usr/local/include -prefer-pic -c /usr/purerory/php4cvs/ext/odbc/php_odbc.c -o ext/odbc/php_odbc.lo /usr/include/alloca.h, line 20.1: 1506-224 (I) Incorrect pragma ignored. /usr/purerory/php4cvs/ext/standard/php_image.h, line 48.21: 1506-275 (S) Unexpected text ',' encountered. /home/db2inst1/sqllib/include/sqlcli.h, line 718.9: 1506-213 (S) Macro name ODBCVER cannot be redefined. /home/db2inst1/sqllib/include/sqlcli.h, line 718.9: 1506-358 (I) ODBCVER is defined on line 27 of /usr/purerory/php4cvs/ext/odbc/php_odbc.h. /home/db2inst1/sqllib/include/sqlcli1.h, line 126.10: 1506-213 (S) Macro name SQL_EXT_API_LAST cannot be redefined. /home/db2inst1/sqllib/include/sqlcli1.h, line 126.10: 1506-358 (I) SQL_EXT_API_LAST is defined on line 621 of /home/db2inst1/sqllib/include/sqlext.h. /home/db2inst1/sqllib/include/sqlcli1.h, line 207.10: 1506-213 (S) Macro name SQL_OJ_CAPABILITIES cannot be redefined. /home/db2inst1/sqllib/include/sqlcli1.h, line 207.10: 1506-358 (I) SQL_OJ_CAPABILITIES is defined on line 764 of /home/db2inst1/sqllib/include/sqlext.h. /home/db2inst1/sqllib/include/sqlcli1.h, line 219.9: 1506-213 (S) Macro name SQL_INFO_LAST cannot be redefined. /home/db2inst1/sqllib/include/sqlcli1.h, line 219.9: 1506-358 (I) SQL_INFO_LAST is defined on line 776 of /home/db2inst1/sqllib/include/sqlext.h. /usr/purerory/php4cvs/ext/odbc/php_odbc.c, line 199.30: 1506-280 (S) Function argument assignment between types long and
#20780 [NEW]: switch ... case ... statement cannot distinguish a string with integer 0
From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version: 4.2.3
PHP Bug Type: Scripting Engine problem
Bug description: switch ... case ... statement cannot distinguish a string with
integer 0
?php
$a = 'center';
switch ($a) {
case 'left':
case 0: echo 'left';break;
case 'right':
case 2: echo 'right';break;
default:echo 'center';
}
?
The script should generate 'center',yet generate 'left';what's more,any
string assigned to variable $a will generate the same error. The reason is
the PHP scripting engine cannot distinguish a string with integer 0. I
wonder if the switch statement can only be applied on integers.
--
Edit bug report at http://bugs.php.net/?id=20780edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20780r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20780r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20780r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20780r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20780r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20780r=support
Expected behavior: http://bugs.php.net/fix.php?id=20780r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20780r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20780r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20780r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20780r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20780r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20780r=isapi
#20779 [Opn]: Several dll entry points not found in php4ts.dll
ID: 20779 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Dynamic loading +Bug Type: *Configuration Issues Operating System: Win2k Pro PHP Version: 4.3.0RC2 New Comment: Hi there Additional Category: Apache Just to clarify some points, i am using Apache 2.0.43 not Apache 2.0.39. So does the warning (below), of which I was aware of apply to newer versions of Apache (ie 2.0.40 and later). If its a known issue, then what measure have been taken to fix it. I believe its a PHP error. Apache runs everything else okay. The apache server environment is only for local development (i.e desktop). Secondly, I am using 4.2.3, which I downloaded on Saturday, Australian DST. Charlie PS The documentated warning about PHP and apache on windows for sapi seem to contradictory comapre these two sentences: PHP 4.2.3 its known to work in conjunction with Apache 2.0.39. --- so PHP 4.2.3 works. We do not recommend to use PHP 4.2.3 along with Apache 2.0.39. --- so as it works, it is not recommened. Eh? Don't try to use this version of PHP with any other version of Apache. --- Is that earlier (older) or later (newer) versions of apache i.e before/after v.2.0.39. A fuller explaination would be preferable. I know that a the PHP 4.2.2 sapi worked with Apache 2.0.39, via console set up (not as a service) - although it was fiddley and a manual start up - but no errors. Previous Comments: [2002-12-02 21:41:43] [EMAIL PROTECTED] From the docs: http://www.php.net/manual/en/printwn/install.apache2.php Note: Apache 2.0 SAPI-support started with PHP 4.2.0. PHP 4.2.3 its known to work in conjunction with Apache 2.0.39. Don't try to use this version of PHP with any other version of Apache. We do not recommend to use PHP 4.2.3 along with Apache 2.0.39. And btw, are you trying 4.2.3 or 4.3.0RC2, you list both in this bug report. This looks like an Apache2 related bug so the category may want to reflect that but I personally have no idea so won't touch it :) [2002-12-02 21:28:38] [EMAIL PROTECTED] Please excuse the spelling mistake : dynamic link librart should be dynamic link library. [2002-12-02 21:26:21] [EMAIL PROTECTED] I have installed Apache 2.0.43 as a service on Win 2k with PHP 4.2.3. These are upgrades from Apache 2.0.39 and PHP 4.2.2. Now I had previuosly enabled the following php extensions and they worked fine in the older setup. Now, after the upgrade, they don't. They are bz2, ctypye, curl, ming, pdf, zlib. The errors are: php_bz2.dll Apache.exe - Entry Point Not Found The procedure entry point php_file_le_fpoen could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_bz.dll' - The procedure could not be found' php_ctype functions: Warning Function registration failed - duplicate name - ctype_alnum Warning Function registration failed - duplicate name - ctype_alpha Warning Function registration failed - duplicate name - ctype_cntrl Warning Function registration failed - duplicate name - ctype_digit Warning FunctioWarning Function registration failed - duplicate name - ctype_print Warning Function registration failed - duplicate name - ctype_space Warning Function registration failed - duplicate name - ctype_upper Warning Function registration failed - duplicate name - ctype_xdigit Warning ctype: unable to register function, unable to load php_curl.dll: Apache.exe - Entry Point Not Found The procedure entry point php_file_le_fpoen could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_bz.dll' - The procedure could not be found' php_ming.dll Apache.exe - Entry Point Not Found The procedure entry point php_fsock_fread could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_ming.dll' - The procedure could not be found' php_pdf.dll Apache.exe - Entry Point Not Found The procedure entry point zif_warn_not_available could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_pdf.dll' - The procedure could not be found' php_zlib.dll Apache.exe - Entry Point Not Found The procedure entry point php_fopen_wrapper could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_zlib.dll' - The procedure could not be found' End of errors details. --- The workaround works by disabling these extension in the php.ini file but this is not
#20779 [Opn-Dup]: Several dll entry points not found in php4ts.dll
ID: 20779 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate -Bug Type: *Configuration Issues +Bug Type: Apache related Operating System: Win2k Pro PHP Version: 4.3.0RC2 New Comment: Hi there Additional Category: Apache Just to clarify some points, i am using Apache 2.0.43 not Apache 2.0.39. So does the warning (below), of which I was aware of apply to newer versions of Apache (ie 2.0.40 and later). If its a known issue, then what measure have been taken to fix it. I believe its a PHP error. Apache runs everything else okay. The apache server environment is only for local development (i.e desktop). Secondly, I am using 4.2.3, which I downloaded on Saturday, Australian DST. Charlie PS The documentated warning about PHP and apache on windows for sapi seem to contradictory comapre these two sentences: PHP 4.2.3 its known to work in conjunction with Apache 2.0.39. --- so PHP 4.2.3 works. We do not recommend to use PHP 4.2.3 along with Apache 2.0.39. --- so as it works, it is not recommened. Eh? Don't try to use this version of PHP with any other version of Apache. --- Is that earlier (older) or later (newer) versions of apache i.e before/after v.2.0.39. A fuller explaination would be preferable. I know that a the PHP 4.2.2 sapi worked with Apache 2.0.39, via console set up (not as a service) - although it was fiddley and a manual start up - but no errors. Previous Comments: [2002-12-02 23:55:34] [EMAIL PROTECTED] Hi there Additional Category: Apache Just to clarify some points, i am using Apache 2.0.43 not Apache 2.0.39. So does the warning (below), of which I was aware of apply to newer versions of Apache (ie 2.0.40 and later). If its a known issue, then what measure have been taken to fix it. I believe its a PHP error. Apache runs everything else okay. The apache server environment is only for local development (i.e desktop). Secondly, I am using 4.2.3, which I downloaded on Saturday, Australian DST. Charlie PS The documentated warning about PHP and apache on windows for sapi seem to contradictory comapre these two sentences: PHP 4.2.3 its known to work in conjunction with Apache 2.0.39. --- so PHP 4.2.3 works. We do not recommend to use PHP 4.2.3 along with Apache 2.0.39. --- so as it works, it is not recommened. Eh? Don't try to use this version of PHP with any other version of Apache. --- Is that earlier (older) or later (newer) versions of apache i.e before/after v.2.0.39. A fuller explaination would be preferable. I know that a the PHP 4.2.2 sapi worked with Apache 2.0.39, via console set up (not as a service) - although it was fiddley and a manual start up - but no errors. [2002-12-02 21:41:43] [EMAIL PROTECTED] From the docs: http://www.php.net/manual/en/printwn/install.apache2.php Note: Apache 2.0 SAPI-support started with PHP 4.2.0. PHP 4.2.3 its known to work in conjunction with Apache 2.0.39. Don't try to use this version of PHP with any other version of Apache. We do not recommend to use PHP 4.2.3 along with Apache 2.0.39. And btw, are you trying 4.2.3 or 4.3.0RC2, you list both in this bug report. This looks like an Apache2 related bug so the category may want to reflect that but I personally have no idea so won't touch it :) [2002-12-02 21:28:38] [EMAIL PROTECTED] Please excuse the spelling mistake : dynamic link librart should be dynamic link library. [2002-12-02 21:26:21] [EMAIL PROTECTED] I have installed Apache 2.0.43 as a service on Win 2k with PHP 4.2.3. These are upgrades from Apache 2.0.39 and PHP 4.2.2. Now I had previuosly enabled the following php extensions and they worked fine in the older setup. Now, after the upgrade, they don't. They are bz2, ctypye, curl, ming, pdf, zlib. The errors are: php_bz2.dll Apache.exe - Entry Point Not Found The procedure entry point php_file_le_fpoen could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_bz.dll' - The procedure could not be found' php_ctype functions: Warning Function registration failed - duplicate name - ctype_alnum Warning Function registration failed - duplicate name - ctype_alpha Warning Function registration failed - duplicate name - ctype_cntrl Warning Function registration failed - duplicate name - ctype_digit Warning FunctioWarning Function registration failed - duplicate name - ctype_print Warning Function registration failed - duplicate name - ctype_space Warning
#20779 [Dup]: Several dll entry points not found in php4ts.dll
ID: 20779 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Duplicate Bug Type: Apache related Operating System: Win2k Pro -PHP Version: 4.3.0RC2 +PHP Version: 4.2.3 New Comment: Error with Version in header of posting ... Version of PHP is 4.2.3. Previous Comments: [2002-12-02 23:56:10] [EMAIL PROTECTED] Hi there Additional Category: Apache Just to clarify some points, i am using Apache 2.0.43 not Apache 2.0.39. So does the warning (below), of which I was aware of apply to newer versions of Apache (ie 2.0.40 and later). If its a known issue, then what measure have been taken to fix it. I believe its a PHP error. Apache runs everything else okay. The apache server environment is only for local development (i.e desktop). Secondly, I am using 4.2.3, which I downloaded on Saturday, Australian DST. Charlie PS The documentated warning about PHP and apache on windows for sapi seem to contradictory comapre these two sentences: PHP 4.2.3 its known to work in conjunction with Apache 2.0.39. --- so PHP 4.2.3 works. We do not recommend to use PHP 4.2.3 along with Apache 2.0.39. --- so as it works, it is not recommened. Eh? Don't try to use this version of PHP with any other version of Apache. --- Is that earlier (older) or later (newer) versions of apache i.e before/after v.2.0.39. A fuller explaination would be preferable. I know that a the PHP 4.2.2 sapi worked with Apache 2.0.39, via console set up (not as a service) - although it was fiddley and a manual start up - but no errors. [2002-12-02 23:55:34] [EMAIL PROTECTED] Hi there Additional Category: Apache Just to clarify some points, i am using Apache 2.0.43 not Apache 2.0.39. So does the warning (below), of which I was aware of apply to newer versions of Apache (ie 2.0.40 and later). If its a known issue, then what measure have been taken to fix it. I believe its a PHP error. Apache runs everything else okay. The apache server environment is only for local development (i.e desktop). Secondly, I am using 4.2.3, which I downloaded on Saturday, Australian DST. Charlie PS The documentated warning about PHP and apache on windows for sapi seem to contradictory comapre these two sentences: PHP 4.2.3 its known to work in conjunction with Apache 2.0.39. --- so PHP 4.2.3 works. We do not recommend to use PHP 4.2.3 along with Apache 2.0.39. --- so as it works, it is not recommened. Eh? Don't try to use this version of PHP with any other version of Apache. --- Is that earlier (older) or later (newer) versions of apache i.e before/after v.2.0.39. A fuller explaination would be preferable. I know that a the PHP 4.2.2 sapi worked with Apache 2.0.39, via console set up (not as a service) - although it was fiddley and a manual start up - but no errors. [2002-12-02 21:41:43] [EMAIL PROTECTED] From the docs: http://www.php.net/manual/en/printwn/install.apache2.php Note: Apache 2.0 SAPI-support started with PHP 4.2.0. PHP 4.2.3 its known to work in conjunction with Apache 2.0.39. Don't try to use this version of PHP with any other version of Apache. We do not recommend to use PHP 4.2.3 along with Apache 2.0.39. And btw, are you trying 4.2.3 or 4.3.0RC2, you list both in this bug report. This looks like an Apache2 related bug so the category may want to reflect that but I personally have no idea so won't touch it :) [2002-12-02 21:28:38] [EMAIL PROTECTED] Please excuse the spelling mistake : dynamic link librart should be dynamic link library. [2002-12-02 21:26:21] [EMAIL PROTECTED] I have installed Apache 2.0.43 as a service on Win 2k with PHP 4.2.3. These are upgrades from Apache 2.0.39 and PHP 4.2.2. Now I had previuosly enabled the following php extensions and they worked fine in the older setup. Now, after the upgrade, they don't. They are bz2, ctypye, curl, ming, pdf, zlib. The errors are: php_bz2.dll Apache.exe - Entry Point Not Found The procedure entry point php_file_le_fpoen could not be loacted in the dynamice link librart php4ts.dll Unkown(): Unable to load dynamic library './php_bz.dll' - The procedure could not be found' php_ctype functions: Warning Function registration failed - duplicate name - ctype_alnum Warning Function registration failed - duplicate name - ctype_alpha Warning Function registration failed - duplicate name - ctype_cntrl Warning Function registration failed - duplicate name - ctype_digit Warning FunctioWarning
#20773 [Opn-Ctl]: will not compile with iplant ldap
ID: 20773 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: LDAP related Operating System: Solaris 8 PHP Version: 4.3.0RC2 Previous Comments: [2002-12-02 16:49:06] [EMAIL PROTECTED] Tried to compile with iplanet ldap 5.0.sp1 server. Config runs OK Compile does not. (config command line entries ) ./configure --with-apxs2=/www2/bin/apxs --with-gettext --with-xml --enable-ftp --with-mhash --with-gdbm --enable-bcmath --with-mysql --with-ldap=/usr/iplanet/servers/plugins/slapd/slapi --with-zlib --with-ndbm --enable-calendar --with-imap=/export/home/imiller/imap-2002 --with-openssl=/usr/local/ssl --with-mcrypt (Config section of ldap) checking for iconv support... no checking for IMAP support... yes checking for pam_start in -lpam... yes checking for crypt in -lcrypt... (cached) yes checking whether SSL libraries are needed for c-client... no checking whether IMAP works... yes checking for Informix support... no checking for Ingres II support... no checking for InterBase support... no checking for IRCG support... no checking for Java support... no checking for LDAP support... yes checking for 3 arg ldap_set_rebind_proc... yes checking for ldap_parse_reference... no checking for ldap_start_tls_s... no checking whether to enable multibyte string support... no checking whether to enable multibyte regex support... no checking for MCAL support... no checking for mcrypt support... yes checking for mcrypt_module_open in -lmcrypt... yes checking for mcrypt_generic_deinit in -lmcrypt... yes checking for MCVE support... no checking for mhash support... yes checking whether to enable mime_magic support... no (Compile section) cc1: warning: changing search order for system directory /usr/local/include cc1: warning: as it has already been specified as a non-system directory /bin/ksh libtool --silent --mode=compile gcc -Iext/imap/ -I/export/home/imiller/php-4.3.0RC2/ext/imap/ -DPHP_ATOM_INC -I/export/home/imiller/php-4.3.0RC2/include -I/export/home/imiller/php-4.3.0RC2/main -I/export/home/imiller/php-4.3.0RC2 -I/www2/include -I/export/home/imiller/php-4.3.0RC2/Zend -I/usr/local/ssl/include -I/usr/local/include -I/export/home/imiller/imap-2002/c-client -I/usr/iplanet/servers/plugins/slapd/slapi/include -I/export/home/imiller/php-4.3.0RC2/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -I/export/home/imiller/php-4.3.0RC2/TSRM -g -O2 -prefer-pic -c /export/home/imiller/php-4.3.0RC2/ext/imap/php_imap.c -o ext/imap/php_imap.lo cc1: warning: changing search order for system directory /usr/local/include cc1: warning: as it has already been specified as a non-system directory /bin/ksh libtool --silent --mode=compile gcc -Iext/ldap/ -I/export/home/imiller/php-4.3.0RC2/ext/ldap/ -DPHP_ATOM_INC -I/export/home/imiller/php-4.3.0RC2/include -I/export/home/imiller/php-4.3.0RC2/main -I/export/home/imiller/php-4.3.0RC2 -I/www2/include -I/export/home/imiller/php-4.3.0RC2/Zend -I/usr/local/ssl/include -I/usr/local/include -I/export/home/imiller/imap-2002/c-client -I/usr/iplanet/servers/plugins/slapd/slapi/include -I/export/home/imiller/php-4.3.0RC2/ext/xml/expat -D_POSIX_PTHREAD_SEMANTICS -I/export/home/imiller/php-4.3.0RC2/TSRM -g -O2 -prefer-pic -c /export/home/imiller/php-4.3.0RC2/ext/ldap/ldap.c -o ext/ldap/ldap.lo cc1: warning: changing search order for system directory /usr/local/include cc1: warning: as it has already been specified as a non-system directory /export/home/imiller/php-4.3.0RC2/ext/ldap/ldap.c: In function `zif_ldap_set_rebind_proc': /export/home/imiller/php-4.3.0RC2/ext/ldap/ldap.c:2062: too many arguments to function `ldap_set_rebind_proc' /export/home/imiller/php-4.3.0RC2/ext/ldap/ldap.c:2077: warning: passing arg 2 of `ldap_set_rebind_proc' from incompatible pointer type /export/home/imiller/php-4.3.0RC2/ext/ldap/ldap.c:2077: too many arguments to function `ldap_set_rebind_proc' make: *** [ext/ldap/ldap.lo] Error 1 bash-2.05# -- Edit this bug report at http://bugs.php.net/?id=20773edit=1
#19378 [Opn-Csd]: Parse error in PHP executable as Apache CGI
ID: 19378 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Apache related Operating System: FreeBSD 4.5-STABLE PHP Version: 4.2.3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. fixed in CVS as of today. Previous Comments: [2002-11-10 19:07:33] [EMAIL PROTECTED] I think the message No feedback was provided for this bug for over 2 weeks,... is absurd and may represent a bug in bug-track. I provided the feedback as requested. [2002-11-09 01:00:08] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-10-24 19:27:09] [EMAIL PROTECTED] Recompiled using the same script and now get the following when the page is shown in Apache. Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. apache_error_log shows: [Thu Oct 24 20:20:45 2002] [error] [client 192.168.1.140] Premature end of script headers: /www/kyler.com/cgi/php nothing else was changed. Ken [2002-10-24 15:35:28] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-09-17 01:10:04] [EMAIL PROTECTED] As usual, it seems that nobody is interessted in these problems with PHP as CGI, its the same like this: http://bugs.php.net/bug.php?id=18371 , its a general issue. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19378 -- Edit this bug report at http://bugs.php.net/?id=19378edit=1
#20053 [Opn]: apachesuexecphp-cgiignore_user_abort - problem with cancelled connections
ID: 20053 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: linux 2.4.18 PHP Version: 4.3.0-dev New Comment: Please try the latest cvs as of today. Several significant cgi fixes have been commited. Previous Comments: [2002-10-24 12:26:56] [EMAIL PROTECTED] updated version. [2002-10-24 04:27:26] [EMAIL PROTECTED] Exactly the same behaviour as in 4.2.3 :( [2002-10-24 02:42:11] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-23 19:40:25] [EMAIL PROTECTED] Under very specific circumstances, php goes in tight infinite loop eating all cpu after request is cancelled. Configuration: php 4.2.3 as cgi apache 1.3.27 php configured with Action directive, (important) using suexec. Conditions for problem to occur in script: 1.ignore_user_abort(true) 2.sending any http header 3.sending any body content AFTER http header 4. connection is aborted before all data are sent to client. Script to reproduce problem: CUT ? ignore_user_abort(true); header(X-Whatever: whatever); ? whatever CUT Problem doesn't exist with mod_php or php-cgi without suexec. It appears that after apache has closed connection php is still trying to write output and loops for unknown reason. I'm not sure if this is fault of php, apache or suexec, but I think it could be fixed in php. -- Edit this bug report at http://bugs.php.net/?id=20053edit=1
#20780 [Opn-Bgs]: switch ... case ... statement cannot distinguish a string with integer 0
ID: 20780
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows 2000
PHP Version: 4.2.3
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
See
http://ch.php.net/manual/en/language.types.string.php#language.types.string.conversion
Previous Comments:
[2002-12-02 23:54:45] [EMAIL PROTECTED]
?php
$a = 'center';
switch ($a) {
case 'left':
case 0: echo 'left';break;
case 'right':
case 2: echo 'right';break;
default:echo 'center';
}
?
The script should generate 'center',yet generate 'left';what's more,any
string assigned to variable $a will generate the same error. The reason
is the PHP scripting engine cannot distinguish a string with integer 0.
I wonder if the switch statement can only be applied on integers.
--
Edit this bug report at http://bugs.php.net/?id=20780edit=1
#17314 [NoF]: CGI error with doc_root as in php.ini_dist
ID: 17314 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: IIS related Operating System: Win XP Pro PHP Version: 4.3.0 dev New Comment: Please try a snapshot dated after today. Previous Comments: [2002-11-16 01:00:01] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-10-31 11:55:53] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-07-01 16:08:43] [EMAIL PROTECTED] Veryfied with 4.3.0 snapshot of yesterday. Still the same phenomen. [2002-06-03 14:26:47] [EMAIL PROTECTED] No, I'm sure it's not cgi.force-redirect. The behaviour is changing when commenting out doc_root. Have verified it again. However, I didn't have the problem on a NT 4.0 Server SP6a with IIS 4. Christoph [2002-06-03 12:32:58] [EMAIL PROTECTED] Can't reproduce. Are you sure this is not actually the problem with having cgi.force_redirect set to 1 ? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/17314 -- Edit this bug report at http://bugs.php.net/?id=17314edit=1
#18942 [WFx-Csd]: $PHP_SELF is set to HTTP_SERVER_VARS[PATH_INFO] if available
ID: 18942 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Won't fix +Status: Closed Bug Type: Other web server Operating System: Debian PHP Version: 4.2.2 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. It's fixed in cvs as of today. Previous Comments: [2002-08-17 10:01:52] [EMAIL PROTECTED] The manual states why this shouldn't used, and the fact that it's populated at all is interesting. [2002-08-17 09:41:56] [EMAIL PROTECTED] I believe it should be fixed ... Or at least the apache SAPI should be modified too. With the current code, PATH_INFO has different meanings (and values) in the Apache and CGI SAPIs, not good at all for applications portability IMHO. [2002-08-17 00:58:09] [EMAIL PROTECTED] I believe this is a documented issue, and won't be fixed. [2002-08-16 15:56:02] [EMAIL PROTECTED] There is a very fast way of testing, create a script called phpinfo.php with juste ?phpinfo()? in it. Then call it like http://yourserver.com/phpinfo.php/this/is/a/test if the two images (zend and php logos) are broken, then $PHP_SELF is not set as it should be. again, this problem only happens with the CGI sapi [2002-08-16 15:44:07] [EMAIL PROTECTED] Okay can we have a sample script just to ensure that we may or may not have fixed your issue? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18942 -- Edit this bug report at http://bugs.php.net/?id=18942edit=1
#12264 [Bgs-Csd]: PATH_INFO and PATH_TRANSLATED not being correctly set
ID: 12264 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Closed Bug Type: IIS related Operating System: Win2K Server PHP Version: 4.0.6 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-06-03 12:12:36] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately your version of PHP is too old -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. [2001-07-20 03:20:19] [EMAIL PROTECTED] Hmm, looks like my patch thing didn't quite work [for one, PATH_INFO isn't being set right, then I think there are also some memory leaks]) ... I had an old very hacky patch around here that I ended up reverting to for now. A proper fix for this problem would be great :) [2001-07-19 14:29:07] [EMAIL PROTECTED] Hello, The scripts that we are running use PATH_INFO to determine where a user is trying to access, and this became a problem when we switched over from using Apache to using IIS. Once we made the switch from Apache to IIS we were getting continual CGI Errors (like virtually every single hit was a CGI Error) [ and this was not because of permissions ] As it turns out, the only pages where we would not get a CGI error was the root page, which had an empty PATH_INFO. Here's an example: Our root script is /test.php. If I requested /test.php everything would work fine; However if I requested /test.php/hello/world I would get a CGI Error (under IIS). Under Apache I would get the proper results -- it would run /test.php and PATH_INFO would be /hello/world. But anyways - after spending some time poking around the PHP source I found that PHP was trying to execute the wrong file! In the above example, it was attempting to run /test.php/hello/world instead of /test.php (SCRIPT_NAME was being to /test.php). To me it looked like IIS was setting PATH_INFO and PATH_TRANSLATED differently than PHP was expecting, so I made a change the the source so that it would modify those two until they were in working order. I'm not sure if my change is correct - but it did fix the problem). (Note: The problem is independent of the actual script - any script where you put stuff on the URL in this manner will have this problem) = What follows now is the output that I had PHP give on what it was trying to run. The first is the original version that didn't work, followed by the version with the changes that I made, and the proper results: In both of the cases, the requested URL was: http://192.168.1.2/test.php/hello/world Original (non-working) version -- PHP Output follows SG(request_info).path_translated: (null) PATH_INFO : /test.php/hello/world SCRIPT_NAME: /test.php SG(request_info).request_uri = /test.php/hello/world php_fopen_primary_script(): filename = C:\web\fcsweb\test.php\hello\world php_fopen_primary_script(): path_info = /test.php/hello/world = So you can see that in the original request it is trying to run the wrong script. With the changes I made, I now get the following: New (working) version - PHP Output follows SG(request_info).path_translated: C:\web\fcsweb\test.php PATH_INFO : /hello/world SCRIPT_NAME: /test.php SG(request_info).request_uri = /hello/world php_fopen_primary_script(): filename = C:\web\fcsweb\test.php php_fopen_primary_script(): path_info = /hello/world = Some more information on our system: OS: Win2k Server SP1 Webserver: IIS4 PHP: 4.0.6 CGI mode And finally, the patch for the changes I made to cgi_main.c are at: http://div.dyndns.org/jah/php/iis_cgi_path_fix.patch I've never submitted a patch before, so I don't know if it's done in the right manner... Hopefully I've analyzed this whole issue somewhat correctly... :) Thanks! -Jah
#19592 [Opn-Csd]: PHP_SELF is not correct with --enable-discard-path
ID: 19592 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: URL related Operating System: GNU/Linux PHP Version: 4.2.3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-10-03 07:36:20] [EMAIL PROTECTED] You can find my patch proposition for this PHP Bug at: http://groups.google.com/groups?selm=amelb7%24297k%241%40FreeBSD.csie.NCTU.edu.tw (I have sent this to php-dev list, but there was no response from php core developers)... Maybe updating this bug report would make any change. [2002-09-25 12:38:24] [EMAIL PROTECTED] In absence of a PATH_INFO PHP_SELF is correct ( it is set to the value of SCRIPT_NAME ) But when a PATH_INFO is given PHP_SELF is set to its value. For example: URI: /php4info.cgi --- PHP_SELF: /php4info.cgi URI: /php4info.cgi/test --- PHP_SELF: /test Of course the scripts themself start with #!/path/to/php4 And the interpreter was compiled with --enable-discard-path [2002-09-25 10:42:57] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. [2002-09-25 08:57:43] [EMAIL PROTECTED] When compiled with --enable-discrd-path PHP does not provide a valid PHP_SELF. It seems to me as simple as concatenating SCRIPT_NAME with PATH_INFO, do I miss something ? -- Edit this bug report at http://bugs.php.net/?id=19592edit=1
#20781 [NEW]: PHP doesn't work with iPlanet SDK 5.08
From: [EMAIL PROTECTED] Operating system: Linux, Mandrake 8.2 PHP version: 4.2.3 PHP Bug Type: LDAP related Bug description: PHP doesn't work with iPlanet SDK 5.08 I'm trying to get PHP to work with iPlanet LDAP SDK 5.08 that I've got in /opt/Netscape-LDAP-5.08 ./configure --with-apxs=/usr/sbin/apxs --enable-debug=no --prefix=/opt/php-4.2.3 --with-config-file-path=/etc/php --enable-shmop --enable-sysvshm --enable-versioning --with-jpeg-dir=/usr/local --with-gd --enable-gd-native-tt --disable-static --disable-debug --disable-rpath --with-png-dir=/usr --with-zlib-dir=/usr -with-freetype-dir=/usr --with-t1lib=/usr --enable-track-vars --enable-trans-sid --with-mysql --with-ldap=/opt/Netscape-LDAP-5.08 looks OK, saying: checking for LDAP support... yes checking for 3 arg ldap_set_rebind_proc... yes checking for ldap_parse_reference... no Everything compiles fine, but I see no sign of linking the iPlanet libraries and a 'ldd libphp4.so' gives libdl.so.2 = /lib/libdl.so.2 (0x4016d000) libpam.so.0 = /lib/libpam.so.0 (0x4017) libgd.so.2 = /opt/gd-2.0.8/lib/libgd.so.2 (0x40178000) libt1.so.1 = /usr/lib/libt1.so.1 (0x401b1000) libfreetype.so.6 =/usr/lib/libfreetype.so.6 (0x401fc000) libpng12.so.0 = /usr/lib/libpng12.so.0 (0x4023d000) libz.so.1 = /lib/libz.so.1 (0x40266000) libjpeg.so.62 = /usr/lib/libjpeg.so.62 (0x40275000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x40296000) libresolv.so.2 = /lib/libresolv.so.2 (0x402c4000) libm.so.6 = /lib/libm.so.6 (0x402d6000) libnsl.so.1 = /lib/libnsl.so.1 (0x402f8000) libgcc_s.so.1 = /usr/local/lib/libgcc_s.so.1 (0x4030e000) libc.so.6 = /lib/libc.so.6 (0x40316000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) When I start httpd I get a libphp4.so: undefined symbol: ldap_value_free I've heard that it should work with 4.x of the SDK but I can't find it anywhere so I make libldapssl41.so a link to my libldap50.so, modify the configure script to look for my versions of the other libs and get a configure output that says checking for LDAP support... yes checking for 3 arg ldap_set_rebind_proc... yes checking for ldap_parse_reference... yes and an ldd gives libdl.so.2 = /lib/libdl.so.2 (0x40172000) libpam.so.0 = /lib/libpam.so.0 (0x40175000) libldapssl41.so = /usr/local/lib/libldapssl41.so (0x4017d000) libplds4.so = /usr/local/lib/libplds4.so (0x401a4000) libssl3.so = /usr/local/lib/libssl3.so (0x401a7000) libprldap50.so = /usr/local/lib/libprldap50.so (0x401c4000) libnss3.so = /usr/local/lib/libnss3.so (0x401c8000) libplc4.so = /usr/local/lib/libplc4.so (0x40257000) libnspr4.so = /usr/local/lib/libnspr4.so (0x4025b000) libgd.so = /usr/local/lib/libgd.so (0x40286000) libt1.so.1 = /usr/lib/libt1.so.1 (0x402be000) libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0x40309000) libpng12.so.0 = /usr/lib/libpng12.so.0 (0x4034a000) libz.so.1 = /lib/libz.so.1 (0x40373000) libjpeg.so.62 = /usr/lib/libjpeg.so.62 (0x40382000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x403a4000) libresolv.so.2 = /lib/libresolv.so.2 (0x403d1000) libm.so.6 = /lib/libm.so.6 (0x403e3000) libnsl.so.1 = /lib/libnsl.so.1 (0x40405000) libgcc_s.so.1 = /usr/local/lib/libgcc_s.so.1 (0x4041b000) libc.so.6 = /lib/libc.so.6 (0x40423000) libpthread.so.0 = /lib/libpthread.so.0 (0x4056) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) This time I get the ldap_start_tls_s error. Are there any plans of supporting the iPlanet 5.x SDK or are there any workarounds that I've missed? Regards, Peder -- Edit bug report at http://bugs.php.net/?id=20781edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20781r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20781r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20781r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20781r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20781r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20781r=support Expected behavior: http://bugs.php.net/fix.php?id=20781r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20781r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20781r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20781r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20781r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20781r=dst IIS Stability: http://bugs.php.net/fix.php?id=20781r=isapi
#20781 [Opn]: PHP doesn't work with iPlanet SDK 5.08
ID: 20781 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: LDAP related Operating System: Linux, Mandrake 8.2 PHP Version: 4.2.3 New Comment: Oh, the iPlanet SDK is actually called Sun ONE Directory SDK for C 5.08 nowadays, available at http://wwws.sun.com/software/download/developer/5176.html /Peder Previous Comments: [2002-12-03 01:44:23] [EMAIL PROTECTED] I'm trying to get PHP to work with iPlanet LDAP SDK 5.08 that I've got in /opt/Netscape-LDAP-5.08 ./configure --with-apxs=/usr/sbin/apxs --enable-debug=no --prefix=/opt/php-4.2.3 --with-config-file-path=/etc/php --enable-shmop --enable-sysvshm --enable-versioning --with-jpeg-dir=/usr/local --with-gd --enable-gd-native-tt --disable-static --disable-debug --disable-rpath --with-png-dir=/usr --with-zlib-dir=/usr -with-freetype-dir=/usr --with-t1lib=/usr --enable-track-vars --enable-trans-sid --with-mysql --with-ldap=/opt/Netscape-LDAP-5.08 looks OK, saying: checking for LDAP support... yes checking for 3 arg ldap_set_rebind_proc... yes checking for ldap_parse_reference... no Everything compiles fine, but I see no sign of linking the iPlanet libraries and a 'ldd libphp4.so' gives libdl.so.2 = /lib/libdl.so.2 (0x4016d000) libpam.so.0 = /lib/libpam.so.0 (0x4017) libgd.so.2 = /opt/gd-2.0.8/lib/libgd.so.2 (0x40178000) libt1.so.1 = /usr/lib/libt1.so.1 (0x401b1000) libfreetype.so.6 =/usr/lib/libfreetype.so.6 (0x401fc000) libpng12.so.0 = /usr/lib/libpng12.so.0 (0x4023d000) libz.so.1 = /lib/libz.so.1 (0x40266000) libjpeg.so.62 = /usr/lib/libjpeg.so.62 (0x40275000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x40296000) libresolv.so.2 = /lib/libresolv.so.2 (0x402c4000) libm.so.6 = /lib/libm.so.6 (0x402d6000) libnsl.so.1 = /lib/libnsl.so.1 (0x402f8000) libgcc_s.so.1 = /usr/local/lib/libgcc_s.so.1 (0x4030e000) libc.so.6 = /lib/libc.so.6 (0x40316000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) When I start httpd I get a libphp4.so: undefined symbol: ldap_value_free I've heard that it should work with 4.x of the SDK but I can't find it anywhere so I make libldapssl41.so a link to my libldap50.so, modify the configure script to look for my versions of the other libs and get a configure output that says checking for LDAP support... yes checking for 3 arg ldap_set_rebind_proc... yes checking for ldap_parse_reference... yes and an ldd gives libdl.so.2 = /lib/libdl.so.2 (0x40172000) libpam.so.0 = /lib/libpam.so.0 (0x40175000) libldapssl41.so = /usr/local/lib/libldapssl41.so (0x4017d000) libplds4.so = /usr/local/lib/libplds4.so (0x401a4000) libssl3.so = /usr/local/lib/libssl3.so (0x401a7000) libprldap50.so = /usr/local/lib/libprldap50.so (0x401c4000) libnss3.so = /usr/local/lib/libnss3.so (0x401c8000) libplc4.so = /usr/local/lib/libplc4.so (0x40257000) libnspr4.so = /usr/local/lib/libnspr4.so (0x4025b000) libgd.so = /usr/local/lib/libgd.so (0x40286000) libt1.so.1 = /usr/lib/libt1.so.1 (0x402be000) libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0x40309000) libpng12.so.0 = /usr/lib/libpng12.so.0 (0x4034a000) libz.so.1 = /lib/libz.so.1 (0x40373000) libjpeg.so.62 = /usr/lib/libjpeg.so.62 (0x40382000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x403a4000) libresolv.so.2 = /lib/libresolv.so.2 (0x403d1000) libm.so.6 = /lib/libm.so.6 (0x403e3000) libnsl.so.1 = /lib/libnsl.so.1 (0x40405000) libgcc_s.so.1 = /usr/local/lib/libgcc_s.so.1 (0x4041b000) libc.so.6 = /lib/libc.so.6 (0x40423000) libpthread.so.0 = /lib/libpthread.so.0 (0x4056) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) This time I get the ldap_start_tls_s error. Are there any plans of supporting the iPlanet 5.x SDK or are there any workarounds that I've missed? Regards, Peder -- Edit this bug report at http://bugs.php.net/?id=20781edit=1
