Bug #15745 Updated: DSO module can't load on apache _1.3.23 ( can't open shared object file )
ID: 15745 Updated by: [EMAIL PROTECTED] -Summary: DSO module can't load on apache _1.3.23 ( can't open shared object file ) Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache related Operating System: Linux ( Slackware 8 ) PHP Version: 4.1.1 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". Previous Comments: [2002-02-26 21:44:01] [EMAIL PROTECTED] success to compile as DSO with apache_1.3.23 But when I try to start the apache: it says : Syntax error on line 205 of /opt/web/conf/httpd.conf in httpd.conf line 205 LoadModule php4_module libexec/libphp4.so can't load /opt/web/apache/libexec/libphp4.so into server: can't open shared object fuke: can't load shared object file: no such file or directory -- Edit this bug report at http://bugs.php.net/?id=15745&edit=1
Bug #15753 Updated: not find php_oci8.dll
ID: 15753 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: OCI8 related Operating System: win2000 PHP Version: 4.1.1 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-02-27 03:10:52] [EMAIL PROTECTED] my computor is iis5.0,php4.1.1 and windows2000 professional where is php.ini extendtion_dir = c:/php/extensions extension=php_oci8.dll after... iis restart error message print out "Unable to load dynamic libary c:/php/extensions/php_oci8.dll - not found module" -- Edit this bug report at http://bugs.php.net/?id=15753&edit=1
Bug #15749 Updated: PHP (binary) or Apache (module) crashes when session_start() called
ID: 15749 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Session related Operating System: Windows XP Prof Build 2600 PHP Version: 4.1.1 New Comment: Very likely to be caused by an incorrect session.save_path. This has already been reported and will be fixed in the next release. Reopen if this is not the case. Previous Comments: [2002-02-27 01:07:08] [EMAIL PROTECTED] I am running Windows XP Build 2600 with Apache 1.3.23 When I call session_start(), PHP (if configured as CGI) or Apache( if configured as module) crashes. This will crash the server: -- Edit this bug report at http://bugs.php.net/?id=15749&edit=1
Bug #15743 Updated: On attempted opening of Session, browser gives me HTTP 500 error
ID: 15743 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: Windows 2000 Advanced Server PHP Version: 4.1.1 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-02-26 19:47:02] [EMAIL PROTECTED] PHP works great except for sessions. Whenever I put session_start(); or session_register(); i get an HTTP 500 error. Nothing will work either. I have tried evry Session script and every possible way of registering a PHP session but absoutely nothing works -- Edit this bug report at http://bugs.php.net/?id=15743&edit=1
Bug #15754: dead link
From: [EMAIL PROTECTED] Operating system: PHP version: 4.1.1 PHP Bug Type: Unknown/Other Function Bug description: dead link Well... i'm not sure that this is the right place for this kind of info, but I thought you wanted to know about it: Your link to: http://www.doe-mbi.ucla.edu/manual/en/function.fopen.php is dead-end. Regards Steen Manniche steen[at]paakant[puncta]dk -- Edit bug report at http://bugs.php.net/?id=15754&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15754&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15754&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15754&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15754&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15754&r=support Expected behavior: http://bugs.php.net/fix.php?id=15754&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15754&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15754&r=submittedtwice
Bug #12868 Updated: Appendix G Descrepancies..
ID: 12868 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: win32 PHP Version: 4.0.6 Assigned To: jeroen Previous Comments: [2001-12-11 16:50:39] [EMAIL PROTECTED] This seems okay now. But, maybe the alias appendix should be auto-generated via something like "genaliasindex" ? [2001-08-21 13:35:12] [EMAIL PROTECTED] It doesn't matter at all indeed. For chop/rtrim: chop used to be main function, but since it's in perl and behaving differently over there, _and_ rtrim is consistent with trim and ltrim, I decided to document chop as the alias. Will update aliases.xml too. I recently suggested a better indication to aliases (in phpdoc/README -> CONVENTIONS), but that hasn't been implemented yet -> be patient. Btw: is_float will be master now, is_double the alias... PHP doesn't have double-precision floats, there's only one flavour. [2001-08-21 01:28:38] [EMAIL PROTECTED] Update status... [2001-08-21 01:28:13] [EMAIL PROTECTED] I don't understand why it matters which is the 'master' and which is the alias? I would guess that the reason for the inconsistency in the documentation is that it really doesn't matter which is which, so the doc team is not all that careful about it. But that's just a guess...this wouldn't be all that hard to clear up. FWIW, rtrim() is an alias to chop() and fputs() is an alias to fwrite(). [2001-08-21 00:12:18] [EMAIL PROTECTED] This is truly a followup to my previous post - message about what appears to be "descrepancies" in Appendix G.. which has further some confusion as to "which" functions are "truly" an alias and which is the "master function".. I guess I need to "understand" what the master function is supposed to be, and what an alias is supposed to be. Perhaps I have these backwards, and thus the confusion, but some of this doesn't quite set right.. The first function in the list (chop) is labeled as the master function, and it's alias as (rtrim).. but when you go to the master function, (chop) it's documentation indicates it's the alias. and to see rtrim for details. There are some functions in this list like - fwrite() and fputs() - where fwrite is labled as the master and fputs the alias.. while the documentaion for both functions do not indicate either as an alias.. This goes on.. naturally some of these make perfect sense, if you looke at is_double() marked as a master - having aliases of is_float() and is_real().. the documentation corresponds perfectly.. i.e. if you call up is_float() or is_real() it directs you to is_double().. which brings "some" understanding back. and jives with what "I" would preceive as the relationship between a "master function" and an alias. Input on this matter would "greatly" be appreciated.. thanks a bunch. -- Edit this bug report at http://bugs.php.net/?id=12868&edit=1
Bug #15754 Updated: dead link
ID: 15754 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type:Unknown/Other Function PHP Version: 4.1.1 New Comment: Where did you find that link? If it's somewhere on www.php.net please tell us where exactly and we can fix it. If it's not, then it's not our responsibility. Previous Comments: [2002-02-27 03:54:05] [EMAIL PROTECTED] Well... i'm not sure that this is the right place for this kind of info, but I thought you wanted to know about it: Your link to: http://www.doe-mbi.ucla.edu/manual/en/function.fopen.php is dead-end. Regards Steen Manniche steen[at]paakant[puncta]dk -- Edit this bug report at http://bugs.php.net/?id=15754&edit=1
Bug #15755: Can't send MAIL
From: [EMAIL PROTECTED] Operating system: Windows 98 PHP version: 4.1.0 PHP Bug Type: Mail related Bug description: Can't send MAIL The mail() function does not seem to work I am using PHP 4.1.0 under apache. This type of script not function: but if i change in this No problem append.. In php 4.0.6 no problem! This problem is tested only on Windows Platform -- Edit bug report at http://bugs.php.net/?id=15755&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15755&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15755&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15755&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15755&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15755&r=support Expected behavior: http://bugs.php.net/fix.php?id=15755&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15755&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15755&r=submittedtwice
Bug #15221 Updated: Mail function does not work
ID: 15221 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Mail related Operating System: Windows XP Pro. PHP Version: 4.1.1 New Comment: Try change \n with \r\n Previous Comments: [2002-01-25 11:50:23] [EMAIL PROTECTED] Check your SMTP settings. Probably the mailserver refuses your message. Check if authentication is needed and more like that. [2002-01-25 07:20:27] [EMAIL PROTECTED] The mail() function does not seem to work. I am getting this error: Warning: Unknown error in c:\apache\htdocs\auctions\mailtest.php on line 2 Mailtest.php contains the following: My PHP.ini mail function settings seem to be ok too: SMTP: mail.keyworld.net sendmail_from = [EMAIL PROTECTED] I am using PHP 4.1.1 under apache. Other PHP scripts work fine but this mail function does not work. Please help me fix this problem -- Edit this bug report at http://bugs.php.net/?id=15221&edit=1
Bug #15756: bad Subtraction
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.0.6 PHP Bug Type: *General Issues Bug description: bad Subtraction When i use this code: or with variables...results was: 0.91 0.8 0.7 0.59 0.5 0.41 0.3 0.2 0.094 Is it correct or no? How can i get correct results without using round()??? -- Edit bug report at http://bugs.php.net/?id=15756&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15756&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15756&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15756&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15756&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15756&r=support Expected behavior: http://bugs.php.net/fix.php?id=15756&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15756&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15756&r=submittedtwice
Bug #15757: php4apache.dll not found/valid
From: [EMAIL PROTECTED] Operating system: Win2000 PHP version: 4.1.1 PHP Bug Type: Apache2 related Bug description: php4apache.dll not found/valid Hi, I just installed PHP 4.1.1 on my Win2000 which already holds Apache 2.0.32b3. I want to use the DLL provided by the PHP-zip-file from within Apache. Though if I check my httpd.conf with Apache it says that it can't find php4apache.dll in the given path even though it's there. I tried various things like copying the DLLs which came with PHP into system directories but the problem is still there. Btw, I followed the instructions in the install.txt so this should have worked in the first place. On www.apache.org I found a post that the problem is that that very DLL is probably not supposed to work with the new Apache but with the old one (before 2.0). So my question is when will there be a working php4apache.dll which works with the new Apache-server? I know this is not really a bug more a question but the problem arose from a bug-like situation and I assume I'm not the only one who'd like to know this. And others may think this is a bug, too, but will find this question here. :) Regards, Stefan -- Edit bug report at http://bugs.php.net/?id=15757&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15757&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15757&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15757&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15757&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15757&r=support Expected behavior: http://bugs.php.net/fix.php?id=15757&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15757&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15757&r=submittedtwice
Bug #15756 Updated: bad Subtraction
ID: 15756
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: linux
PHP Version: 4.0.6
New Comment:
Please don't ask support questions in the bug database.
Computers can only approximate floating point numbers to a certain
level of precision. Simply set the precision you want. Try adding
this line before your echo lines:
ini_set('precision',4);
Previous Comments:
[2002-02-27 04:47:38] [EMAIL PROTECTED]
When i use this code:
or with variables...results was:
0.91
0.8
0.7
0.59
0.5
0.41
0.3
0.2
0.094
Is it correct or no?
How can i get correct results without using round()???
--
Edit this bug report at http://bugs.php.net/?id=15756&edit=1
Bug #15756 Updated: bad Subtraction
ID: 15756
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *General Issues
Operating System: linux
PHP Version: 4.0.6
New Comment:
ok, sorry
Previous Comments:
[2002-02-27 04:52:04] [EMAIL PROTECTED]
Please don't ask support questions in the bug database.
Computers can only approximate floating point numbers to a certain
level of precision. Simply set the precision you want. Try adding
this line before your echo lines:
ini_set('precision',4);
[2002-02-27 04:47:38] [EMAIL PROTECTED]
When i use this code:
or with variables...results was:
0.91
0.8
0.7
0.59
0.5
0.41
0.3
0.2
0.094
Is it correct or no?
How can i get correct results without using round()???
--
Edit this bug report at http://bugs.php.net/?id=15756&edit=1
Bug #15758: PHP odbc_connect() doesn't work on IIS 5.0
From: [EMAIL PROTECTED] Operating system: Windows 2000 Advanced Server PHP version: 4.1.1 PHP Bug Type: ODBC related Bug description: PHP odbc_connect() doesn't work on IIS 5.0 ODBC System DSN: DBTest - points to DBTest.mdb (Access 2000) using Microsoft Access driver (*.mdb) for Access 2000. No username, no password, no "exclusive" access checked! TestFile.php content "; } ?> Result (running IIS 5.0): "Warning: SQL error: [Microsoft][ODBC Microsoft Access Driver] The Microsoft Jet database engine cannot open the file '(unknown)'. It is already opened exclusively by another user, or you need permission to view its data., SQL state S1000 in SQLConnect in C:\inetpub\wwwroot\directory\Test.php on line 3 Connecting error!" I stopped IIS and started Apache (on the same server and port). Then the connection was established perfectly fine and the result was the content of Table1: 1 Text1 2 Text2 3 Text3 4 Text4 -- Edit bug report at http://bugs.php.net/?id=15758&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15758&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15758&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15758&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15758&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15758&r=support Expected behavior: http://bugs.php.net/fix.php?id=15758&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15758&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15758&r=submittedtwice
Bug #14991 Updated: ini_set scrambles output
ID: 14991
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: Free BSD 4.4
PHP Version: 4.1.1
New Comment:
On Windows platforms (windows2000/php4.1.1 - isapi app on IIS 5.0)
ini_set not workink properly too. Output is also scrambled.
Previous Comments:
[2002-01-24 15:14:18] [EMAIL PROTECTED]
I fix this Problem now by reading the incorrect output into a
output-buffer using ob_get_contents and tweak it with preg_replace,
duh!
Works, but is, ehh, not very smart #-)
But, surprise surprise, i then come over the error described in PHP-Bug
#14080(which is still not fixed in 4.1.1).
funny, eh?
[2002-01-11 04:36:17] [EMAIL PROTECTED]
The following Code shows some strange behaviour:
Galerie
read())
{
[...snipped some echo "blabla";lines]
}
$d->close();
ini_set("session.use_trans_sid","1");
?>
The following Output is produced:
Galerie
[...snipped the list]
valign="top" nowrap>
watch the
http://bugs.php.net/?id=14991&edit=1
Bug #15759: pgsql.c void value not ignored as it ought to be
From: [EMAIL PROTECTED] Operating system: Solaris 2.8 PHP version: 4.1.1 PHP Bug Type: Compile Failure Bug description: pgsql.c void value not ignored as it ought to be Downloaded Apache_1.3.23, PHP_4.1.1 (=matest versions) Env. vars set: INFORMDIR=/home/informix2000 PATH=/home/informix2000/bin:$PATH LD_LIBRARY_PATH=/home/informix2000/lib/esql:$LD_LIBRARY_PATH LIBRARY_PATH=/home/informix2000/lib/esql:$LIBRARY_PATH SQLEXEC= export INFORMIXDIR PATH LD_LIBRARY_PATH LIBRARY_PATH SQLEXEC Unpacked apache-1.3.23, did a # ./configure --prefix=/usr/local/apache_1323 Unpacked php_4.1.1, did a # ./configure --with-apache=/home/wins/cosslocal/src/other/apache_1.3.23 \ --with=pgsql \ --with-informix=/home/informix2000 \ --enable-yp (we have PGSQL in /usr/local/pgsql and INFORMIX2000 up and running) then did a # make ... at the gcc compile of pgsql.c I get: pgsql.c: In function 'zif_pg_put_line': pgsql.c:849: void value not ignored as it ought to be make[3]: *** [pgsql.lo] Error 1 ... I didn't have that error with our previous apache_1.3.14 and PHP4.0.4pl1 compilation (with the same PGSQL and INFORMIX2000) At line 849 in pgsql.c I don't find zif_pg_put_line, substring 'zif' is nowhere in pgsql.c ... Pieter -- Edit bug report at http://bugs.php.net/?id=15759&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15759&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15759&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15759&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15759&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15759&r=support Expected behavior: http://bugs.php.net/fix.php?id=15759&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15759&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15759&r=submittedtwice
Bug #15760: GetImageSize: Read Error!
From: [EMAIL PROTECTED]
Operating system: Linux/Slackware 7.0
PHP version: 4.1.1
PHP Bug Type: GetImageSize related
Bug description: GetImageSize: Read Error!
$x=GetImageSize("/some/dir");
In versions of PHP 4.0 and lower if the object of GetImageSize it would
not report an error.
Just upgraded to 4.1.1 and now GetImageSize reports an
error if the object is just a directory and not a file.
Adding @GetImageSize takes care of the error.
The reason I am bothering to write this bug report is that
when I was trying to solve the problem I did a search at
Google and saw that hundreds of pages on the net have
this same problem, most likely many of them as a result
of upgrading.
In fact, this is not a bug. GetImageSize is reporting
an error if it can't find the file. Unfortunately it's earlier
behavior allowed people to be lazy using this function.
They could use an object composed of variables, one
being a directory and another a file. If both are met,
the size array is returned, if not, nothing. But now, if
not mean big "Read Error".
Russ McClay
--
Edit bug report at http://bugs.php.net/?id=15760&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15760&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15760&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15760&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15760&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15760&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15760&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15760&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15760&r=submittedtwice
Bug #15761: IMAP-SSL Bug
From: [EMAIL PROTECTED] Operating system: RedHat 7.2 PHP version: 4.1.1 PHP Bug Type: IMAP related Bug description: IMAP-SSL Bug Hi, If I PHP with --with-imap-ssl=/usr/local/openssl install comes with apache start of the errors: Syntax error on line 240 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/libexec/libphp4.so: undefined symbol: ssl_onceonlyinit /usr/local/apache/bin/apachectl start: httpd could not be started OpenSSL Version is: OpenSSL 0.9.6c -- Edit bug report at http://bugs.php.net/?id=15761&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15761&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15761&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15761&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15761&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15761&r=support Expected behavior: http://bugs.php.net/fix.php?id=15761&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15761&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15761&r=submittedtwice
Bug #15761 Updated: IMAP-SSL Bug
ID: 15761 Updated by: [EMAIL PROTECTED] -Reported By: [EMAIL PROTECTED] +Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IMAP related Operating System: RedHat 7.2 PHP Version: 4.1.1 New Comment: sorry my eMail is: [EMAIL PROTECTED] Previous Comments: [2002-02-27 06:28:59] [EMAIL PROTECTED] Hi, If I PHP with --with-imap-ssl=/usr/local/openssl install comes with apache start of the errors: Syntax error on line 240 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/libexec/libphp4.so: undefined symbol: ssl_onceonlyinit /usr/local/apache/bin/apachectl start: httpd could not be started OpenSSL Version is: OpenSSL 0.9.6c -- Edit this bug report at http://bugs.php.net/?id=15761&edit=1
Bug #15757 Updated: php4apache.dll not found/valid
ID: 15757 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Apache2 related Operating System: Win2000 PHP Version: 4.1.1 New Comment: php4apache.dll is for Apache 1.3.x php4apache2.dll (IIRC) is for Apache 2.x, but it only works for some versions. If you really need it, you should build it yourself from source. As long as Apache 2.x is not stable, we can't provide you with a reliable php4apache2.dll Previous Comments: [2002-02-27 04:51:31] [EMAIL PROTECTED] Hi, I just installed PHP 4.1.1 on my Win2000 which already holds Apache 2.0.32b3. I want to use the DLL provided by the PHP-zip-file from within Apache. Though if I check my httpd.conf with Apache it says that it can't find php4apache.dll in the given path even though it's there. I tried various things like copying the DLLs which came with PHP into system directories but the problem is still there. Btw, I followed the instructions in the install.txt so this should have worked in the first place. On www.apache.org I found a post that the problem is that that very DLL is probably not supposed to work with the new Apache but with the old one (before 2.0). So my question is when will there be a working php4apache.dll which works with the new Apache-server? I know this is not really a bug more a question but the problem arose from a bug-like situation and I assume I'm not the only one who'd like to know this. And others may think this is a bug, too, but will find this question here. :) Regards, Stefan -- Edit this bug report at http://bugs.php.net/?id=15757&edit=1
Bug #15762: OCIExecute result not described (and other minor errors)
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 4.1.1 PHP Bug Type: Documentation problem Bug description: OCIExecute result not described (and other minor errors) The manual entry for the OCIExecute function defines it as "int OCIExecute ( int statement [, int mode])", but there is no description of the returned result. Additionally, there is a missing close parenthesis after "(see OCIParse()", and the full stop preceding that should not be there; and "automaticly" in the last sentence should be "automatically". Cheers! -- Edit bug report at http://bugs.php.net/?id=15762&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15762&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15762&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15762&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15762&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15762&r=support Expected behavior: http://bugs.php.net/fix.php?id=15762&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15762&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15762&r=submittedtwice
Bug #14909 Updated: Allows access to ANY file
ID: 14909 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Open Bug Type: Apache related Operating System: Windows PHP Version: 4.1.1 Assigned To: imajes Previous Comments: [2002-02-24 03:56:30] [EMAIL PROTECTED] For emmergency, a simple check at "auto_prepend_file" whould help: [2002-01-09 09:56:39] [EMAIL PROTECTED] I have windows xp + apache + php 4.1 installed and the /php/ alias is also definied in my httpd.conf and therefor I am also affected by this exploit. but how can I use php WITHOUT this alias in apache conf? I tried several things but it doesn't work. chris, 15 =) [2002-01-09 02:17:17] [EMAIL PROTECTED] so do we have to read the documentation again on how to install PHP?? have u added a fix? [2002-01-08 08:03:10] [EMAIL PROTECTED] the documentation is fixed, i committed this morning/last night. there is however a bug in the way apache handles the binary -- or the way php acts when called as a binary (you can get premature end of script headers). What i would like to do is leave this open, and noticeable for some of the apache guys to take a look at and comment on it. The docs are fixed we just need to wait to see if this is a thing to hand off to apache. [2002-01-08 07:16:40] [EMAIL PROTECTED] As said by others, this is NOT a bug, but a documentation problem. (btw: assigned to only needs your username) 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/14909 -- Edit this bug report at http://bugs.php.net/?id=14909&edit=1
Bug #15678 Updated: isset fails for 4.1.1 and CVS version
ID: 15678 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Open Bug Type: Variables related Operating System: i686-pc-linux-gnu PHP Version: 4.0CVS-2002-02-2 New Comment: not critical Previous Comments: [2002-02-23 22:59:43] [EMAIL PROTECTED] It should be fixed before 4.2.0 at least. Hopefully before 4.1.2 :) [2002-02-22 11:41:57] [EMAIL PROTECTED] Btw, this has nothing to do with current CVS. This applies to at least 4.1.0 I tested (so there's nothing broken since current stable and CVS; if it's broken, it is for a long time) [2002-02-22 11:17:03] [EMAIL PROTECTED] Andrey Hristov wrote: >The answer to your question: > var_dump((int) 'y'); >?> ??? this is not the answer of the second question and also not to the first one, because results: "Notice: Undefined offset: 0 in foo.php on line 2" [2002-02-22 11:03:55] [EMAIL PROTECTED] hi, the declaration of a second dimension in a normal array results a strange array content. results: Array ( [c] => boo ) is this a normal behavior? i think this ist completely wrong, because 'd' is not string position 1. Also a normal condition like results true ... but it is absolutely not true i have test it on linux with the lastest cvs tree php version. regards, Steve -- Edit this bug report at http://bugs.php.net/?id=15678&edit=1
Bug #14909 Updated: Allows access to ANY file
ID: 14909 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Apache related Operating System: Windows PHP Version: 4.1.1 Assigned To: imajes New Comment: we have a manual chapter for securing the cgi-bin installation. http://www.php.net/manual/en/security.cgi-bin.php Previous Comments: [2002-02-24 03:56:30] [EMAIL PROTECTED] For emmergency, a simple check at "auto_prepend_file" whould help: [2002-01-09 09:56:39] [EMAIL PROTECTED] I have windows xp + apache + php 4.1 installed and the /php/ alias is also definied in my httpd.conf and therefor I am also affected by this exploit. but how can I use php WITHOUT this alias in apache conf? I tried several things but it doesn't work. chris, 15 =) [2002-01-09 02:17:17] [EMAIL PROTECTED] so do we have to read the documentation again on how to install PHP?? have u added a fix? [2002-01-08 08:03:10] [EMAIL PROTECTED] the documentation is fixed, i committed this morning/last night. there is however a bug in the way apache handles the binary -- or the way php acts when called as a binary (you can get premature end of script headers). What i would like to do is leave this open, and noticeable for some of the apache guys to take a look at and comment on it. The docs are fixed we just need to wait to see if this is a thing to hand off to apache. [2002-01-08 07:16:40] [EMAIL PROTECTED] As said by others, this is NOT a bug, but a documentation problem. (btw: assigned to only needs your username) 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/14909 -- Edit this bug report at http://bugs.php.net/?id=14909&edit=1
Bug #14136 Updated: Segfaults when forget xslt_free()
ID: 14136
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: Debian/Linux
PHP Version: 4.0CVS-2001-11-20
-Assigned To:
+Assigned To: sterling
New Comment:
Assinging this to you sterling, have fun with it!
Previous Comments:
[2001-11-20 15:21:51] [EMAIL PROTECTED]
Doesn't look like a Zend problem to me. Apparently the table ends up
containing the wrong entries (i.e., the same entry more than once) or,
if the analysis is accurate, then the dependencies aren't properly
implemented, and a resource (the parser) is freed prematurely.
[2001-11-20 07:34:40] [EMAIL PROTECTED]
Seems a Zend problem...
[2001-11-20 03:59:03] [EMAIL PROTECTED]
Tested this with php compiled as cgi.
Everything works ok when after doing transformation
you use xslt_free() in your script.
When you forget to do so php may segfault.
This happens when there were a scheme/sax handler defined
with object reference:
xslt_set_sax_handlers($xslt, array("characters" =>
array(&$this, "func")));
Now when php shuts down it calls free_processor() which
after some recursive *_ptr_dtor() and alike calls reaches
again free_processor() with same zval handle. Since
sablotron processor is already destroyed it eventually
comes to segfault.
This doesn't happen when ordinary function is used as
callback handler.
Backtrace:
#0 0x in ?? ()
#1 0x400d8432 in Situation::generateMessage
(this=0x81c4bb8, type=MT_WARN, code=W1_HLR_NOT_REGISTERED,
arg1=@0xbfffee08,
arg2=@0xbfffedfc, theMessage=@0xbfffed70) at
situa.cpp:267
#2 0x400d8ae2 in Situation::message (this=0x81c4bb8,
type=MT_WARN, code=W1_HLR_NOT_REGISTERED,
arg1=@0xbfffee08, arg2=@0xbfffedfc)
at situa.cpp:348
#3 0x400cfb63 in Processor::report (this=0x81c4c58,
S=@0x81c4bb8, type=MT_WARN, code=W1_HLR_NOT_REGISTERED,
arg1=@0xbfffee08,
arg2=@0xbfffedfc) at proc.cpp:991
#4 0x400ce583 in Processor::setHandler (this=0x81c4c58,
S=@0x81c4bb8, type=HLR_MESSAGE, handler=0x0, userData=0x0)
at proc.cpp:741
#5 0x400d1a8c in SablotUnregHandler
(processor_=0x81c4c58, type=HLR_MESSAGE, handler=0x0,
userData=0x0) at sablot.cpp:728
#6 0x0811adc1 in free_processor (rsrc=0x81c0a8c) at
sablot.c:613
#7 0x080c3a2a in list_entry_destructor (ptr=0x81c0a8c) at
zend_list.c:177
#8 0x080c128e in zend_hash_del_key_or_index
(ht=0x818dc44, arKey=0x0, nKeyLength=0, h=1, flag=1) at
zend_hash.c:512
#9 0x080c378b in _zend_list_delete (id=1) at
zend_list.c:56
#10 0x080d9581 in _zval_dtor (zvalue=0x81c4574,
__zend_filename=0x813d01c "zend_execute_API.c",
__zend_lineno=274)
at zend_variables.c:64
#11 0x080c66ab in _zval_ptr_dtor (zval_ptr=0x81c0ad8,
__zend_filename=0x8149313 "zend_variables.c",
__zend_lineno=189)
at zend_execute_API.c:274
#12 0x080d98b4 in _zval_ptr_dtor_wrapper
(zval_ptr=0x81c0ad8) at zend_variables.c:189
#13 0x080c13ba in zend_hash_destroy (ht=0x81c101c) at
zend_hash.c:541
#14 0x080d9551 in _zval_dtor (zvalue=0x81c4a34,
__zend_filename=0x813d01c "zend_execute_API.c",
__zend_lineno=274)
at zend_variables.c:57
#15 0x080c66ab in _zval_ptr_dtor (zval_ptr=0x81c0b90,
__zend_filename=0x8149313 "zend_variables.c",
__zend_lineno=189)
at zend_execute_API.c:274
#16 0x080d98b4 in _zval_ptr_dtor_wrapper
(zval_ptr=0x81c0b90) at zend_variables.c:189
#17 0x080c13ba in zend_hash_destroy (ht=0x81c0b24) at
zend_hash.c:541
#18 0x080d9521 in _zval_dtor (zvalue=0x81c0c5c,
__zend_filename=0x813d01c "zend_execute_API.c",
__zend_lineno=274)
at zend_variables.c:51
#19 0x080c66ab in _zval_ptr_dtor (zval_ptr=0x81c4b9c,
__zend_filename=0x81672fb "sablot.c", __zend_lineno=633)
at zend_execute_API.c:274
#20 0x0811b00e in free_processor (rsrc=0x81c0a8c) at
sablot.c:633
#21 0x080c3a2a in list_entry_destructor (ptr=0x81c0a8c) at
zend_list.c:177
#22 0x080c3c15 in zend_destroy_rsrc_list (ht=0x818dc44) at
zend_list.c:248
#23 0x080c64a7 in shutdown_executor () at
zend_execute_API.c:196
#24 0x080c8e36 in zend_deactivate () at zend.c:600
#25 0x080637cf in php_request_shutdown (dummy=0x0) at
main.c:736
#26 0x0805f023 in main (argc=2, argv=0xbb34) at
cgi_main.c:785
#27 0x401e965f in __libc_start_main () from /lib/libc.so.6
--
Edit this bug report at http://bugs.php.net/?id=14136&edit=1
Bug #14066 Updated: Can't suppress warnigns on accessing invalid string offset
ID: 14066 Updated by: [EMAIL PROTECTED] -Summary: Can't suppress warnigns on accessing invalid string offset Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Scripting Engine problem Operating System: Any PHP Version: 4.0CVS-2001-11-15 -Assigned To: +Assigned To: derick Previous Comments: [2001-12-02 17:06:21] [EMAIL PROTECTED] One more, this change happened in Zend/zend_execute.c line 103. [2001-12-02 17:04:40] [EMAIL PROTECTED] Btw, this breaks BC: [chroot] mfischer@ficken:~/isrc/cvs/php4/Zend$ php -v 4.0.6-dev [chroot] mfischer@ficken:~/isrc/cvs/php4/Zend$ php -q [chroot] mfischer@ficken:~/isrc/cvs/php4/Zend$ and with RC4: mfischer@ficken:~/isrc/cvs/php4/Zend$ php -v 4.1.0RC4 mfischer@ficken:~/isrc/cvs/php4/Zend$ php -q Warning: Uninitialized string offset: 2 in - on line 1 -(1) : Warning - Uninitialized string offset: 2 mfischer@ficken:~/isrc/cvs/php4/Zend$ Marking as critical. [2001-12-02 17:01:01] [EMAIL PROTECTED] 'isset($foo[0])' issues a warning too if $foo is an emtpy string. [2001-11-15 02:33:34] [EMAIL PROTECTED] When setting error_reporting(E_ALL) the following occurs: The last line should not emit a warning. -- Edit this bug report at http://bugs.php.net/?id=14066&edit=1
Bug #15251 Updated: Cannot upload one file but two files
ID: 15251 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Critical +Status: Feedback Bug Type: HTTP related Operating System: Linux PHP Version: 4.2.0 2002-02-07 Assigned To: yohgaki New Comment: Can you provide me with script for me to reproduce it? Derick Previous Comments: [2002-02-07 20:10:23] [EMAIL PROTECTED] I forgot to memtion apache error log with a single file upload Unknown(0) : Warning - No file uploaded BTW, I usually test both IE and Mozilla(Linux) latest The same result. Assign to me for now. [2002-02-07 08:25:39] [EMAIL PROTECTED] Status -> Feedback [2002-02-07 07:17:02] [EMAIL PROTECTED] Hmmm tjo, you know the procedure... 1) Can you try it with IE5.5? 2) Is this exact the script you used? (remember the ;) 3) what is your config.nice (cause i wasnt able to reproduce) with my plain installation [2002-02-07 05:52:31] [EMAIL PROTECTED] Oops. Problem still exists :( [2002-02-07 05:50:30] [EMAIL PROTECTED] I tested again. It works for me now :) I don't actually change configuration. I upgraded to apache 1.3.23/mod 2.8.6, 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/15251 -- Edit this bug report at http://bugs.php.net/?id=15251&edit=1
Bug #15380 Updated: Invalid Type Conversion In XOR Operand
ID: 15380
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Critical
+Status: Assigned
Bug Type: Scripting Engine problem
Operating System: ANY
PHP Version: 4.2.0-dev
-Assigned To:
+Assigned To: derick
New Comment:
Not critical, assinging to me to check it out.
Previous Comments:
[2002-02-05 10:52:10] [EMAIL PROTECTED]
Some results (exactly the same with ZE1 and 2):
echo "12" ^ "9"; // output: nothing
echo "hello"."12" ^ "9"; // output: Q
echo "hello12" ^ "9"; // output: Q
echo "hello".("12" ^ "9"); // output: hell
Yes, that's hell and not hello!
[2002-02-05 05:38:12] [EMAIL PROTECTED]
Verified with 4.2.0-dev. (ZE1)
This bug can make nasty bug in script that is really hard to find.
status = Critical
[2002-02-05 04:54:00] [EMAIL PROTECTED]
Invalid Calculation when you make XOR operation between strings like:
"12" ^ "9".
It needs to change type from "String" => "Double"
--
Edit this bug report at http://bugs.php.net/?id=15380&edit=1
Bug #15380 Updated: Invalid Type Conversion In XOR Operand
ID: 15380
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: ANY
PHP Version: 4.2.0-dev
Assigned To: derick
New Comment:
Actually, it's not a bug, but an undocumented feature.
What hapens is this:
When both operands are strings, the characters in those strings are
XORed like this:
result[0] = string1[0] ^ string2[0]
result[1] = string1[1] ^ string2[1]
For your example this is:
result[0] = '1' ^ '9'
which is:
#8 (the backspace character).
I'm fixing the documentation now.
Derick
Previous Comments:
[2002-02-27 07:49:25] [EMAIL PROTECTED]
Not critical, assinging to me to check it out.
[2002-02-05 10:52:10] [EMAIL PROTECTED]
Some results (exactly the same with ZE1 and 2):
echo "12" ^ "9"; // output: nothing
echo "hello"."12" ^ "9"; // output: Q
echo "hello12" ^ "9"; // output: Q
echo "hello".("12" ^ "9"); // output: hell
Yes, that's hell and not hello!
[2002-02-05 05:38:12] [EMAIL PROTECTED]
Verified with 4.2.0-dev. (ZE1)
This bug can make nasty bug in script that is really hard to find.
status = Critical
[2002-02-05 04:54:00] [EMAIL PROTECTED]
Invalid Calculation when you make XOR operation between strings like:
"12" ^ "9".
It needs to change type from "String" => "Double"
--
Edit this bug report at http://bugs.php.net/?id=15380&edit=1
Bug #15762 Updated: OCIExecute result not described (and other minor errors)
ID: 15762 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: n/a PHP Version: 4.1.1 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-02-27 07:20:07] [EMAIL PROTECTED] The manual entry for the OCIExecute function defines it as "int OCIExecute ( int statement [, int mode])", but there is no description of the returned result. Additionally, there is a missing close parenthesis after "(see OCIParse()", and the full stop preceding that should not be there; and "automaticly" in the last sentence should be "automatically". Cheers! -- Edit this bug report at http://bugs.php.net/?id=15762&edit=1
Bug #15650 Updated: function highlight_string() returns string
ID: 15650 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type:Documentation problem PHP Version: 4.1.1 New Comment: This bug has been fixed in CVS. Previous Comments: [2002-02-20 18:57:19] [EMAIL PROTECTED] Not so fast, Derick actually did this already in CVS: ChangeLog: - Added optional parameter to highlight_string and highlight_file which makes these functions return a highlighted string instead of dumping to standard output. It's just not documented at all. --Jani [2002-02-20 18:04:35] [EMAIL PROTECTED] ob_start(); highlight_string($str); $ob = ob_get_contents(); ob_end_clean(); wrap this in a function. [2002-02-20 17:57:54] [EMAIL PROTECTED] At this moment (php4.1.1) the function "highlight_string" has the following syntax: [quote] bool highlight_string ( string str) This function prints out a syntax highlighted version of str using the colors defined in the built-in syntax highlighter for PHP. Returns TRUE or FALSE. [/quote] The function will be more flexible if it returns a string (with highlights) and nothing is printed directly. str highlight_string ( string str) This function returns a string containing a syntax highted version of str using the colors defined in the built-in syntax highlighter for PHP. Returnes a string with syntax-highlighted html Reference: http://lxr.php.net/source/ZendEngine2/zend_highlight.c#84 -- Edit this bug report at http://bugs.php.net/?id=15650&edit=1
Bug #9983 Updated: Operator Precedence Clarification/Additions
ID: 9983
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: Linux/W2K
PHP Version: 4.0.4pl1
New Comment:
=== from #15368 ===
The operators seciot of the online PHP Manual omits mention of:
{} -- used to extarct a particular character from a string (with an
aside about using {} to embed variable values in strings);
[] -- the array subscriptor (which is actually listed inthe operator
precedence table, though mentioned nowhere else);
-> -- the object property/method accessor;
& -- the reference operator (also listed in the precendence table,
though never explained elsewhere);
=> -- the array key-to-value keyword (not techniclly an operator, I
know, but because it's so "punctuation-y", probably a good thing to
comment on in this section).
Also, the operators precendence table at
http://www.php.net/manual/en/language.operators.precedence.php should
probably hyperlink each operator to the appropriate page describing
it.
And finally, it might make more sense to put the operator precendence
information (including the new and improved table with hyperlinks)
right on the first page of the operators section (rather than the
arithmentic
operators information).
Previous Comments:
[2002-02-07 09:37:02] [EMAIL PROTECTED]
This is substantially the same as Bug#15368.
[2001-06-27 03:37:24] [EMAIL PROTECTED]
This is a suggestion for improving the manual.
(I don't mind at all if you close this :)
Reference is for PHP programmers, so I think precidence section is
better to include more operators.
For example, it does not matter if unary '+/-', array '[]', member
selecter '->', etc are treated by parser or internal function for
programmers. Programmers don't cares about it when they are programming
in some language, right?
Important thing for programmers is the precedence itself in some
expression.
How about add more description for precedence just like other books or
references for programming languages?
I feel precedence is not described fully in current manual and it's
worth the effort.
Another Releated Suggestion
I see confusion occasionally in mail lists for variables in string.
Since parser behaives differently when parsing variables in strings.
This may be one of the reason why '->','[]',unary'+/-' is not in the
precedence section. They wouldn't work when they are in a string. (Some
of them work with newer PHP, not recommended(?) syntax, though)
How about describe these differences in the manual also?
[2001-06-27 01:49:36] [EMAIL PROTECTED]
Changing description to be more meaningful for someone who wants to
tackle this.
[2001-03-26 05:10:50] [EMAIL PROTECTED]
I read precedence list again. There is "." operator listed and has
higher precedence than "?:" operator. So PHP is working as expected. I
didn't see "." It was hard to see on my browser. Thanks.
Anyway, I have suggestion for the manual page, so I changed status to
open as "Documentation Problem".
I think the manual page better to have relevant language constructs in
the precedence list even if it is not a actually a operator in PHP.
(Such as "()", "{}", "::", "->", unary "-","+". It seems these are not
a operator in PHP, since they are not listed. Not sure though.) Only
"()" is described in the section. All of them affects how expressions
are evaluated in script and I think precedence for these is important
as operator precedence because programmers want expressions are
evaluated as expected.
How about change the section title from "Operator Precedence" to
"Precedence"? Then documentation can include anything that can affects
expression and still have consistency with section title.
It also would be nice to have a little explaination for each operator
in the precedence list. Since it is ambigous if listed operator is
unary or binary. For example, unary "-" should have higher precedence
than binary "-". It would be obvious for most users, but it may be
usuful for someone.
[2001-03-26 03:46:52] [EMAIL PROTECTED]
Please read this manual page:
http://www.php.net/manual/en/language.operators.precedence.php
--Jani
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/9983
--
Edit this bug report at http://bugs.php.net/?id=9983&edit=1
Bug #15368 Updated: Should document {}, [], ->, and & in Operators section of the manual
ID: 15368
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Documentation problem
Operating System: N/A
PHP Version: 4.1.1
New Comment:
I moved the stuff to 9983.
Previous Comments:
[2002-02-07 09:37:19] [EMAIL PROTECTED]
This is substantially the same as Bug#9983.
[2002-02-04 11:14:47] [EMAIL PROTECTED]
The operators seciot of the online PHP Manual omits mention of:
{} -- used to extarct a particular character from a string (with an
aside about using {} to embed variable values in strings);
[] -- the array subscriptor (which is actually listed inthe operator
precedence table, though mentioned nowhere else);
-> -- the object property/method accessor;
& -- the reference operator (also listed in the precendence table,
though never explained elsewhere);
=> -- the array key-to-value keyword (not techniclly an operator, I
know, but because it's so "punctuation-y", probably a good thing to
comment on in this section).
Also, the operators precendence table at
http://www.php.net/manual/en/language.operators.precedence.php should
probably hyperlink each operator to the appropriate page describing
it.
And finally, it might make more sense to put the operator precendence
information (including the new and improved table with hyperlinks)
right on the first page of the operators section (rather than the
arithmentic operators information).
--
Edit this bug report at http://bugs.php.net/?id=15368&edit=1
Bug #14765 Updated: Compile Failure
ID: 14765 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: FreeBSD 4.4 PHP Version: 4.1.0 New Comment: I'm experiencing the same problem on a Cobalt raQ (Linux Redhat) with 4.1.1 I can install php as a static module without any problem. I use Apache 1.3.19. It even happens with ./configure --with-apxs Jef Previous Comments: [2001-12-30 05:50:48] [EMAIL PROTECTED] I can not compile apache 1.3.19 with PHP(DSO) . éHelp me ! I use command "./configure --with-apxs=/home/httpd/bin/apxs --enable-versioning --with-mysql --enable-track-vars" . and "make" result is " /bin/sh /usr/home/httpd/src/php-4.1.0/libtool --silent --mode=compile gcc -I. -I/usr/home/httpd/src/php-4.1.0/sapi/apache -I/usr/home/httpd/src/php-4.1.0/main -I/usr/home/httpd/src/php-4.1.0 -I/usr/home/httpd/include -I/usr/home/httpd/src/php-4.1.0/Zend -I/usr/home/httpd/src/php-4.1.0/ext/mysql/libmysql -I/usr/home/httpd/src/php-4.1.0/ext/xml/expat -DLINUX=22 -DMOD_SSL=208103 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I/usr/home/httpd/src/php-4.1.0/TSRM -g -O2 -prefer-pic -c sapi_apache.c In file included from /usr/home/httpd/include/httpd.h:72, from sapi_apache.c:32: /usr/home/httpd/include/ap_config.h:490: features.h: No such file or directory In file included from /usr/home/httpd/include/httpd.h:72, from sapi_apache.c:32: /usr/home/httpd/include/ap_config.h:1338: warning: `XtOffsetOf' redefined /usr/home/httpd/src/php-4.1.0/main/php.h:342: warning: this is the location of the previous definition *** Error code 1 Stop in /usr/home/httpd/src/php-4.1.0/sapi/apache. *** Error code 1 Stop in /usr/home/httpd/src/php-4.1.0/sapi/apache. *** Error code 1 Stop in /usr/home/httpd/src/php-4.1.0/sapi. *** Error code 1 Stop in /usr/home/httpd/src/php-4.1.0. " çHelp me ! Thank you. -- Edit this bug report at http://bugs.php.net/?id=14765&edit=1
Bug #15763: Compile failure
From: [EMAIL PROTECTED] Operating system: Linux Debian 2.2 PHP version: 4.1.1 PHP Bug Type: Compile Failure Bug description: Compile failure Note: This is 4.1.2 bug not 4.1.1 Note: Make on the same system, same config works fine with 4.0.6 Note: Make without any flags in configure works fine with 4.1.1 Now the issue: Configure: ./configure --with-mysql --with-xml --with-apache=../apache_1.3.19 --enable-track-vars --with-gd --with-mnogosearch Make: srv1:/usr/local/src/php-4.1.2# make Making all in Zend make[1]: Entering directory `/usr/local/src/php-4.1.2/Zend' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/src/php-4.1.2/Zend' Making all in main make[1]: Entering directory `/usr/local/src/php-4.1.2/main' make[2]: Entering directory `/usr/local/src/php-4.1.2/main' gcc -I. -I/usr/local/src/php-4.1.2/main -I/usr/local/src/php-4.1.2/main -I/usr/local/src/php-4.1.2 -I/usr/local/src/apache_1.3.19/src/include -I/usr/local/src/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.1.2/Zend -I/usr/local/mnogosearch/include -I/usr/local/src/php-4.1.2/ext/mysql/libmysql -I/usr/local/src/php-4.1.2/ext/xml/expat -I/usr/local/src/php-4.1.2/TSRM -g -O2 -c main.c && touch main.lo In file included from php.h:163, from main.c:26: fopen_wrappers.h:69: parse error before `TSRMLS_DC' fopen_wrappers.h:71: parse error before `TSRMLS_DC' fopen_wrappers.h:72: parse error before `TSRMLS_DC' fopen_wrappers.h:74: parse error before `TSRMLS_DC' fopen_wrappers.h:75: parse error before `TSRMLS_DC' fopen_wrappers.h:77: parse error before `TSRMLS_DC' fopen_wrappers.h:83: warning: parameter names (without types) in function declaration fopen_wrappers.h:84: warning: parameter names (without types) in function declaration fopen_wrappers.h:85: parse error before `TSRMLS_DC' fopen_wrappers.h:86: parse error before `TSRMLS_DC' In file included from main.c:26: php.h:226: parse error before `TSRMLS_DC' php.h:228: parse error before `TSRMLS_DC' In file included from php.h:290, from main.c:26: /usr/local/src/php-4.1.2/main/php_output.h:26: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:29: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/main/php_output.h:30: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:31: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/main/php_output.h:32: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:33: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:34: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:35: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:36: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:37: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:38: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:39: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/main/php_output.h:40: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/main/php_output.h:41: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/main/php_output.h:42: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/main/php_output.h:43: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:66: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:67: parse error before `TSRMLS_DC' In file included from /usr/local/src/php-4.1.2/ext/standard/php_standard.h:21, from main.c:52: /usr/local/src/php-4.1.2/ext/standard/basic_functions.h:37: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/ext/standard/basic_functions.h:37: warning: data definition has no type or storage class /usr/local/src/php-4.1.2/ext/standard/basic_functions.h:38: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/ext/standard/basic_functions.h:38: warning: data definition has no type or storage class /usr/local/src/php-4.1.2/ext/standard/basic_functions.h:39: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/ext/standard/basic_functions.h:39: warning: data definition has no type or storage class /usr/local/src/php-4.1.2/ext/standard/basic_functions.h:40: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/ext/standard/basic_functions.h:40: warning: data definition has no type or storage class /usr/local/src/php-4.1.2/ext/standard/basic_functions.h:41: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/ext/standard/basic_functions.h:41
Bug #15568 Updated: ImageTTFText doesn't work in 4.1.1
ID: 15568 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: GD related Operating System: Linux PHP Version: 4.1.1 New Comment: Tried with PHP 4.1.2. It still doesn't work. Previous Comments: [2002-02-24 19:12:57] [EMAIL PROTECTED] I have come across the same issue on Win2K running PHP4.1.1. The code worked in 4.0.6 though. The error message I am getting (if I comment out the ImagePNG line) is a strange one: Warning: óO in (file) on line 6 Those funny characters (if you can see them) are what PHP outputs - they seem to be fairly random though - sometimes I get different funny characters. [2002-02-21 17:25:15] [EMAIL PROTECTED] Remove the header line and take a look at the output. You will probably see the error now [2002-02-15 09:50:55] [EMAIL PROTECTED] No errors. Just a black square. [2002-02-15 09:37:36] [EMAIL PROTECTED] What error message do you get when running this code? [2002-02-15 09:21:14] [EMAIL PROTECTED] The following code works in 4.0.6 but doesn't in 4.1.1 Both are compiled with the same flags: --with-freetype --with-gd --with-ttf For 4.1.1 I added: --enable-gd-native-ttf --with-freetype-dir=/usr ( you need a font to test this. In this case - shelley.ttf ) -- Edit this bug report at http://bugs.php.net/?id=15568&edit=1
Bug #13936 Updated: Magical Constant __FILE__ contains wrong information on included files
ID: 13936
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Variables related
Operating System: Solaris
PHP Version: 4.0.6
New Comment:
I was having problems with this same thing on Solaris under PHP 4.1.1,
so I tried the 4.2 version, and it seems to me that the problem is
still there.
I create a file called "test.php" containing:
When I:
php test.php
I get:
file test.php
I expect to get:
file /cs/home/jas/test.php
Shouldn't __FILE__ always return a full path to a file?
Jason.
Previous Comments:
[2001-11-05 17:24:49] [EMAIL PROTECTED]
Yeah, ok, but that was far from apparent in your original report. So
you mean that the bug is that not the full path is given?
I agree, that's a bug. __FILE__ should give the full path of the script
in which the __FILE__ is.
I reproduce it with 4.0.6, but it apparently is fixed in 4.2.0, since
with the exact same env and script etc I get the correct result now.
So closing.
--Jeroen
[2001-11-05 17:05:30] [EMAIL PROTECTED]
Another good argument in favor of __FILE__ returning the full path is
the actual purpose of this variable. People usually use __FILE__ and
__LINE__ to develop routines to report problems or even events on their
applications.
As the manual says, one could write something like this:
To get a report of eventual errors on some library file. Can you tell
me how would I know _which_ library file or script the error occurred
without __FILE__ returning me the full path of the offending script ?
We could have several 'index.php' files running this 'report_error'
function, and if __FILE__ returns only 'index.php', then we wouldn't
know exactly which file it is.
Anyway, I think it is pretty clear __FILE__ should return the full
path.
--Joao
[2001-11-05 16:58:46] [EMAIL PROTECTED]
Well, I expect PHP to give me the full path of the script
(/usr/home/jpm/boohoo/test.php for instance) and not just 'test.php'.
What would be the purpose of __FILE__ if the full path was not returned
? We already have $PHP_SELF / $SCRIPT_NAME for the real name of the
script.
Don't you think it is a bit strange that your own test gave you
'../test.php' on the original script and then the full path for the
included one ?
To go down to the real problem - I need a portable way to find the real
location of the script on the server, being the server Apache, IIS, PWS
or whatever you want to use. Using __FILE__ until now was the only way
to get what I want, and now this problems is cropping up on me.
One more time, if __FILE__ is meant to be the way it is now (as you
said, we probably have a misconception of what __FILE__ should return),
then I need some other way to get the full path for a script in a
portable way.
I'm putting this bug as open again so someone with a real answer can
update this (no more 'probably' please ;)
--Joao
[2001-11-05 16:10:20] [EMAIL PROTECTED]
You say that it doesn't work correctly, but what did you expect then,
and what did PHP return?
I expect: (see the manual)
orig file: test.php
included file: test2.php
anothyer try: test2.php
And indeed:
[jjawolff@abeel]/tmp/php/php-4.0.6> uname -a
SunOS abeel.students.cs.uu.nl 5.6 Generic_105181-26 sun4u sparc
SUNW,Ultra-5_10
[jjawolff@abeel]/tmp/php/php-4.0.6> ./php ../test.php
X-Powered-By: PHP/4.0.6
Content-type: text/html
original file is: ../test.phpincluded file is:
/tmp/php/test2.phpanother try:
/tmp/php/test2.php[jjawolff@abeel]/tmp/php/php-4.0.6>
So this probably not a bug, but a misunderstanding of __FILE__
(note: __FILE__ being '../test.php' is not what i'd expect, I expected
an absolute path name)
[2001-11-05 11:34:13] [EMAIL PROTECTED]
[jpm@mercury: Mon Nov 5 11:27:56]
[~]$ uname -a
SunOS mercury 5.8 Generic_108529-10 i86pc i386 i86pc
This is a very strange bug, as I have a similar piece of code running
on the same server and it gives me the expected information (i.e. the
full server related path for the script being run).
However, this simple set of scripts gives me the wrong information:
contents of test.php:
";
include("test2.php");
?>
contents of test2.php:
";
$boo = "another try: " . __FILE__;
echo $boo;
?>
As described above, a similar piece of code works perfectly on the same
server but using a different virtual host. This similar code is
actually a bunch of classes that use a specialized Error handler class
to report any problems, and the error is mailed to me. On these emails,
I get the correct __FILE__ output and ever
Bug #13686 Updated: move_uploaded_file() and Safe Mode
ID: 13686 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: UNIX PHP Version: 4.0.4pl1 New Comment: This bug has been fixed in CVS. Previous Comments: [2001-10-16 05:07:50] [EMAIL PROTECTED] I have been constructing a site on a webspace with Safe Mode On, and am able to successfully use move_uploaded_file with a posted file. The documentation on this function implies that UIDs must match between a script and the file it reads. In my case, the script's UID is 605, and the temporary file's is 0 and yet the function behaves perfectly. Perhaps the documentation should be revised accordingly? This is excellent in the sense that I needed some way of retrieving this data with safe mode on, but (to my limited understanding) seems to undermine the safe mode principle of UID restriction. -- Edit this bug report at http://bugs.php.net/?id=13686&edit=1
Bug #14083 Updated: missing yp documentation for some functions
ID: 14083 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: n/a PHP Version: 4.0.6 New Comment: They are documented now. Previous Comments: [2001-11-16 10:02:12] [EMAIL PROTECTED] The current documentation at php.net lists the following functions for the NIS/YP function set as: yp_get_default_domain yp_order yp_master yp_match yp_first yp_next However in /ext/yp/php_yp.h the following addtional functions have beed defined and there is code in yp.c to make them work (atm I don't know if they work...). Descriptions from source code accompany function names yp_all - Traverse map and call a function on each enrty yp_cat - Return an array containing the entire map yp_errno - Return the error code from the last call or 0 if no error occured yp_err_string - Returns corresponding error string fro the given code Can you please add thess functions to the documentation and maybe add an example or two? I'll be working on some yp stuff soon with php, so I'd be happy to send in some examples when I have them. -- Edit this bug report at http://bugs.php.net/?id=14083&edit=1
Bug #14257 Updated: iptcembed is missing from online function reference
ID: 14257 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: 4.0.6 New Comment: Well, it's no longer missing but it's still not completely documented. Anyway, I'm closing this bug. Previous Comments: [2001-11-27 14:34:11] [EMAIL PROTECTED] The function reference for iptcembed is missing from the online function reference. iptcparse is in the function reference but not iptcembed. -- Edit this bug report at http://bugs.php.net/?id=14257&edit=1
Bug #15763 Updated: Compile failure
ID: 15763 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Linux Debian 2.2 -PHP Version: 4.1.1 +PHP Version: 4.1.2 New Comment: Anybody able to reproduce this compile failure? It builds cleanly for me here with the same configure flags except for the --with-mnogosearch one since I don't have that installed here. And there were no mnogosearch changes between 4.1.1 and 4.1.2 so you'd have to assume that wouldn't cause this. Previous Comments: [2002-02-27 12:08:50] [EMAIL PROTECTED] Note: This is 4.1.2 bug not 4.1.1 Note: Make on the same system, same config works fine with 4.0.6 Note: Make without any flags in configure works fine with 4.1.1 Now the issue: Configure: ./configure --with-mysql --with-xml --with-apache=../apache_1.3.19 --enable-track-vars --with-gd --with-mnogosearch Make: srv1:/usr/local/src/php-4.1.2# make Making all in Zend make[1]: Entering directory `/usr/local/src/php-4.1.2/Zend' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/src/php-4.1.2/Zend' Making all in main make[1]: Entering directory `/usr/local/src/php-4.1.2/main' make[2]: Entering directory `/usr/local/src/php-4.1.2/main' gcc -I. -I/usr/local/src/php-4.1.2/main -I/usr/local/src/php-4.1.2/main -I/usr/local/src/php-4.1.2 -I/usr/local/src/apache_1.3.19/src/include -I/usr/local/src/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.1.2/Zend -I/usr/local/mnogosearch/include -I/usr/local/src/php-4.1.2/ext/mysql/libmysql -I/usr/local/src/php-4.1.2/ext/xml/expat -I/usr/local/src/php-4.1.2/TSRM -g -O2 -c main.c && touch main.lo In file included from php.h:163, from main.c:26: fopen_wrappers.h:69: parse error before `TSRMLS_DC' fopen_wrappers.h:71: parse error before `TSRMLS_DC' fopen_wrappers.h:72: parse error before `TSRMLS_DC' fopen_wrappers.h:74: parse error before `TSRMLS_DC' fopen_wrappers.h:75: parse error before `TSRMLS_DC' fopen_wrappers.h:77: parse error before `TSRMLS_DC' fopen_wrappers.h:83: warning: parameter names (without types) in function declaration fopen_wrappers.h:84: warning: parameter names (without types) in function declaration fopen_wrappers.h:85: parse error before `TSRMLS_DC' fopen_wrappers.h:86: parse error before `TSRMLS_DC' In file included from main.c:26: php.h:226: parse error before `TSRMLS_DC' php.h:228: parse error before `TSRMLS_DC' In file included from php.h:290, from main.c:26: /usr/local/src/php-4.1.2/main/php_output.h:26: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:29: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/main/php_output.h:30: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:31: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/main/php_output.h:32: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:33: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:34: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:35: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:36: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:37: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:38: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:39: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/main/php_output.h:40: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/main/php_output.h:41: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/main/php_output.h:42: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/main/php_output.h:43: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:66: parse error before `TSRMLS_DC' /usr/local/src/php-4.1.2/main/php_output.h:67: parse error before `TSRMLS_DC' In file included from /usr/local/src/php-4.1.2/ext/standard/php_standard.h:21, from main.c:52: /usr/local/src/php-4.1.2/ext/standard/basic_functions.h:37: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/ext/standard/basic_functions.h:37: warning: data definition has no type or storage class /usr/local/src/php-4.1.2/ext/standard/basic_functions.h:38: warning: parameter names (without types) in function declaration /usr/local/src/php-4.1.2/ext/standard/basic_functions.h:38: warning: data definition has no type or storage class /usr/local/src/php-4.1.2/ext/standard/basic_functions.h:39: warning: parameter names (without types) in function declaration /usr/loca
Bug #13936 Updated: Magical Constant __FILE__ contains wrong information on included files
ID: 13936 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Variables related Operating System: Solaris PHP Version: 4.0.6 New Comment: Re-opening since this bug appear to be still going on. I didn't really test the fixes on 4.1.1 since I'm using a similar routine to report errors, but it would be nice to catch some attention. --Joao Previous Comments: [2002-02-27 12:40:44] [EMAIL PROTECTED] I was having problems with this same thing on Solaris under PHP 4.1.1, so I tried the 4.2 version, and it seems to me that the problem is still there. I create a file called "test.php" containing: When I: php test.php I get: file test.php I expect to get: file /cs/home/jas/test.php Shouldn't __FILE__ always return a full path to a file? Jason. [2001-11-05 17:24:49] [EMAIL PROTECTED] Yeah, ok, but that was far from apparent in your original report. So you mean that the bug is that not the full path is given? I agree, that's a bug. __FILE__ should give the full path of the script in which the __FILE__ is. I reproduce it with 4.0.6, but it apparently is fixed in 4.2.0, since with the exact same env and script etc I get the correct result now. So closing. --Jeroen [2001-11-05 17:05:30] [EMAIL PROTECTED] Another good argument in favor of __FILE__ returning the full path is the actual purpose of this variable. People usually use __FILE__ and __LINE__ to develop routines to report problems or even events on their applications. As the manual says, one could write something like this: To get a report of eventual errors on some library file. Can you tell me how would I know _which_ library file or script the error occurred without __FILE__ returning me the full path of the offending script ? We could have several 'index.php' files running this 'report_error' function, and if __FILE__ returns only 'index.php', then we wouldn't know exactly which file it is. Anyway, I think it is pretty clear __FILE__ should return the full path. --Joao [2001-11-05 16:58:46] [EMAIL PROTECTED] Well, I expect PHP to give me the full path of the script (/usr/home/jpm/boohoo/test.php for instance) and not just 'test.php'. What would be the purpose of __FILE__ if the full path was not returned ? We already have $PHP_SELF / $SCRIPT_NAME for the real name of the script. Don't you think it is a bit strange that your own test gave you '../test.php' on the original script and then the full path for the included one ? To go down to the real problem - I need a portable way to find the real location of the script on the server, being the server Apache, IIS, PWS or whatever you want to use. Using __FILE__ until now was the only way to get what I want, and now this problems is cropping up on me. One more time, if __FILE__ is meant to be the way it is now (as you said, we probably have a misconception of what __FILE__ should return), then I need some other way to get the full path for a script in a portable way. I'm putting this bug as open again so someone with a real answer can update this (no more 'probably' please ;) --Joao [2001-11-05 16:10:20] [EMAIL PROTECTED] You say that it doesn't work correctly, but what did you expect then, and what did PHP return? I expect: (see the manual) orig file: test.php included file: test2.php anothyer try: test2.php And indeed: [jjawolff@abeel]/tmp/php/php-4.0.6> uname -a SunOS abeel.students.cs.uu.nl 5.6 Generic_105181-26 sun4u sparc SUNW,Ultra-5_10 [jjawolff@abeel]/tmp/php/php-4.0.6> ./php ../test.php X-Powered-By: PHP/4.0.6 Content-type: text/html original file is: ../test.phpincluded file is: /tmp/php/test2.phpanother try: /tmp/php/test2.php[jjawolff@abeel]/tmp/php/php-4.0.6> So this probably not a bug, but a misunderstanding of __FILE__ (note: __FILE__ being '../test.php' is not what i'd expect, I expected an absolute path name) 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/13936 -- Edit this bug report at http://bugs.php.net/?id=13936&edit=1
Bug #15760 Updated: GetImageSize: Read Error!
ID: 15760
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: GetImageSize related
Operating System: Linux/Slackware 7.0
PHP Version: 4.1.1
New Comment:
Known behaviour, clearly documented at
http://www.php.net/manual/en/function.getimagesize.php
"If accessing the filename image is impossible, or if it isn't a valid
picture, getimagesize() will return NULL and generate a warning."
Previous Comments:
[2002-02-27 06:13:36] [EMAIL PROTECTED]
$x=GetImageSize("/some/dir");
In versions of PHP 4.0 and lower if the object of GetImageSize it
would
not report an error.
Just upgraded to 4.1.1 and now GetImageSize reports an
error if the object is just a directory and not a file.
Adding @GetImageSize takes care of the error.
The reason I am bothering to write this bug report is that
when I was trying to solve the problem I did a search at
Google and saw that hundreds of pages on the net have
this same problem, most likely many of them as a result
of upgrading.
In fact, this is not a bug. GetImageSize is reporting
an error if it can't find the file. Unfortunately it's earlier
behavior allowed people to be lazy using this function.
They could use an object composed of variables, one
being a directory and another a file. If both are met,
the size array is returned, if not, nothing. But now, if
not mean big "Read Error".
Russ McClay
--
Edit this bug report at http://bugs.php.net/?id=15760&edit=1
Bug #15764: mysql_real_connect client flags: compression & SSL
From: [EMAIL PROTECTED] Operating system: all PHP version: 4.0CVS-2002-02-27 PHP Bug Type: Feature/Change Request Bug description: mysql_real_connect client flags: compression & SSL mysql with a VERSION_ID > 40001 (maybe 4) supports the following clientflags CLIENT_COMPRESS Use compression protocol. CLIENT_FOUND_ROWS Return the number of found (matched) rows, not the number of affected rows. CLIENT_IGNORE_SPACE Allow spaces after function names. Makes all functions names reserved words. CLIENT_INTERACTIVE Allow interactive_timeout seconds (instead of wait_timeout seconds) of inactivity before closing the connection. CLIENT_NO_SCHEMA Don't allow the db_name.tbl_name.col_name syntax. This is for ODBC. It causes the parser to generate an error if you use that syntax, which is useful for trapping bugs in some ODBC programs. CLIENT_ODBC The client is an ODBC client. This changes mysqld to be more ODBC-friendly. CLIENT_SSL Use SSL (encrypted protocol). It would be nice to add CLIENT_SSL and CLIENT_COMPRESS options to the php_mysql_do_connect() ... -- Edit bug report at http://bugs.php.net/?id=15764&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15764&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15764&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15764&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15764&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15764&r=support Expected behavior: http://bugs.php.net/fix.php?id=15764&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15764&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15764&r=submittedtwice
Bug #15765: mssql_query (and mssql_select_db) crashes php.exe
From: [EMAIL PROTECTED] Operating system: Windows 2000 Server PHP version: 4.1.1 PHP Bug Type: MSSQL related Bug description: mssql_query (and mssql_select_db) crashes php.exe I am able to connect to SQL Server v7.0 over the network, but after I am connected (with either _connect or _pconnect), mssql_select_db with a valid db crashes php.exe. If I remove mssql_select_db call, mssql_query crashes. When I removed mssql_select_db call, I added a login to the server which used my db as the default db (so I wouldnt need to select it obviously). I changed my mssql_connect call to reflect the new username and password. I forgot to add select permissions for the table I created, and when I tried to run the code, it actually printed out an error stating that the MSSQL driver couldn't select on the table because of the lack of permissions. When I added permissions to the server and re-ran the code, it then crashed php.exe. All crashes are 'instruction at "0x" tried to reference "0x"' so that is not really helpful. -- Edit bug report at http://bugs.php.net/?id=15765&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15765&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15765&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15765&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15765&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15765&r=support Expected behavior: http://bugs.php.net/fix.php?id=15765&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15765&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15765&r=submittedtwice
Bug #15703 Updated: Segmentation fault with apache2 php pages not served
ID: 15703 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Red Hat Linux 7.1 PHP Version: 4.1.1 New Comment: I did read the README file in sapi/apache2filter directory. But I think it wasn't mentioned there that we should use Apache 2_0_31. Anyway, I started from scratch again and tried each step one by one. I forgot to generate back trace but I will generate it next time. But this time I tried various configurations which are given below. In some cases php 4.1.1 and apache 2_0_28 did work. FIRST CONFIGURATION -- -Apache 2.0-- ./configure --prefix=/wwwroot --enable-so -PHP 4.1.1- ./configure --prefix=/wwwroot/php --with-mysql --with-java=/usr/java/j2sdk1.4.0 php did work and phpinfo() displayed information java library was loaded. But when jver.php was accessed lynx exited with following error: Looking up localhost Making HTTP connection to localhost Sending HTTP request. HTTP request sent; waiting for response. Alert!: Unexpected network read error; connection aborted. Can't Access `http://localhost/jver.php' Alert!: Unable to access document. nothing was added to logs/error_log or to php error log file (php error logging was enabled and a file name was specified) no segmentation fault etc was entered in error log. Then I did this: export LD_LIBRARY_PATH=/usr/java/j2sdk1.4.0/jre/lib/i386/native_threads:/usr/java/j2sdk1.4.0/jre/lib/i386/client:/usr/java/j2sdk1.4.0/jre/lib/i386; Every thing worked and when jver.php (sample file provided with java ext) was accessed java version etc. was displayed. extension directory created was: /wwwroot/php/lib/php/extensions/no-debug-zts-20010901/ Second Time --- ---Apache 2.0 Configure Options--- ./configure --prefix=/wwwroot --enable-auth-anon --enable-auth-db --enable-auth-dbm --enable-auth-digest --enable-file-cache --enable-echo --enable-cache --enable-mem-cache --enable-example --enable-ext-filter --enable-case-filter --enable-case-filter-in --enable-mime-magic --enable-cern-meta --enable-expires --enable-usertrack --enable-unique-id --enable-ssl --enable-optional-hook-export --enable-optional-hook-import --enable-optional-fn-import --enable-optional-fn-export --enable-http --enable-dav --enable-cgi --enable-info --enable-cgid --enable-dav-fs --enable-vhost-alias --enable-speling --enable-actions --enable-rewrite --enable-so --PHP 4.1.1 -- ./configure --prefix=/wwwroot/php --with-mysql --with-java=/usr/java/j2sdk1.4.0 --with-apxs2=/wwwroot/bin/apxs --with-config-file-path=/wwwroot/php phpinfo() worked and java library was loaded. Java (jver.php) worked after exporting this: export LD_LIBRARY_PATH=/usr/java/j2sdk1.4.0/jre/lib/i386/native_threads:/usr/java/j2sdk1.4.0/jre/lib/i386/client:/usr/java/j2sdk1.4.0/jre/lib/i386; and displayed this: Java version=1.4.0-beta Java vendor=Sun Microsystems Inc. OS=Linux 2.4.3-12 on i386 Wednesday, February 27, 2002 at 3:29:02 AM India Standard Time But following was added to apache 2.0 error_log: [Wed Feb 27 03:28:22 2002] [notice] Apache/2.0.28 (Unix) mod_ssl/3.0a0 OpenSSL/0.9.6 DAV/2 configured -- resuming normal operations [Wed Feb 27 03:29:03 2002] [error] Optional hook test said: GET /jver.php HTTP/1.0 [Wed Feb 27 03:29:03 2002] [error] Optional function test said: GET /jver.php HTTP/1.0 [Wed Feb 27 03:31:00 2002] [error] Optional hook test said: GET /jver.php HTTP/1.0 [Wed Feb 27 03:31:00 2002] [error] Optional function test said: GET /jver.php HTTP/1.0 THIRD TIME Then I made a distclean in php-4.1.1 directory. stopped apache 2.0. Removed directory /wwwroot/php. And configured and installed php with following options.. --PHP 4.1.1 Configure- ./configure --prefix=/wwwroot/php --with-apxs2=/wwwroot/bin/apxs --with-mod_charset --with-config-file-path=/wwwroot/php/ --with-openssl --with-zlib --enable-bcmath --with-bz2 --enable-calendar --with-cpdflib --with-png-dir --with-jpeg-dir --with-tiff-dir --enable-ctype --with-curl --with-db3 --with-dom --enable-exif --enable-filepro --enable-ftp --with-gd --enable-gd-native-ttf --with-xpm-dir --with-freetype-dir=/usr --with-ttf --with-t1lib --with-gettext --with-gmp --with-hyperwave --with-iconv --with-imap --with-kerberos --with-imap-ssl --with-ircg --with-ldap --enable-mbstring --enable-mbstr-enc-trans --with-mcal=/usr/src/libmcal --with-mhash --with-mnogosearch=/usr/local/mnogosearch --with-mysql --with-pgsql --with-pspell --with-qtdom --enable-trans-sid --enable-shmop --with-snmp -enable-ucd-snmp-hack --enable-sockets --with-regex=
Bug #15765 Updated: mssql_query (and mssql_select_db) crashes php.exe
ID: 15765 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MSSQL related Operating System: Windows 2000 Server PHP Version: 4.1.1 New Comment: as of this time, I have tested this with ISAPI plugin and php.exe CGI method and it happens using both. Previous Comments: [2002-02-27 14:48:57] [EMAIL PROTECTED] I am able to connect to SQL Server v7.0 over the network, but after I am connected (with either _connect or _pconnect), mssql_select_db with a valid db crashes php.exe. If I remove mssql_select_db call, mssql_query crashes. When I removed mssql_select_db call, I added a login to the server which used my db as the default db (so I wouldnt need to select it obviously). I changed my mssql_connect call to reflect the new username and password. I forgot to add select permissions for the table I created, and when I tried to run the code, it actually printed out an error stating that the MSSQL driver couldn't select on the table because of the lack of permissions. When I added permissions to the server and re-ran the code, it then crashed php.exe. All crashes are 'instruction at "0x" tried to reference "0x"' so that is not really helpful. -- Edit this bug report at http://bugs.php.net/?id=15765&edit=1
Bug #15766: Apache/2.0.32 (Unix) PHP/4.3.0-dev crashes during output
From: [EMAIL PROTECTED]
Operating system: Linux 2.4.2 - RedHat 7.1
PHP version: 4.0CVS-2002-02-27
PHP Bug Type: Reproducible crash
Bug description: Apache/2.0.32 (Unix) PHP/4.3.0-dev crashes during output
The first few requests are handled fine, then suddenly Apache children
start segfaulting. The following script reproduces this crash, backtrace
is included after script:
Test crash
\n";
for ($i = 0; $i < $rows; ++$i) {
echo "";
for ($j = 0; $j < $cols; ++$j) {
echo "Hello World";
}
echo "\n";
}
echo "";
?>
backtrace follows ---
[root@auth bin]# gdb httpd
GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run -X
Starting program: /usr/local/apache2/bin/httpd -X
[New Thread 1024 (LWP 9570)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 9570)]
0x08082b38 in ap_pass_brigade (next=0x4001d3dc, bb=0x81a5000) at
util_filter.c:445
445 return next->frec->filter_func.out_func(next, bb);
(gdb) bt
#0 0x08082b38 in ap_pass_brigade (next=0x4001d3dc, bb=0x81a5000) at
util_filter.c:445
#1 0x40307e40 in php_apache_sapi_ub_write (str=0x81a01b7 "",
str_length=0, tsrm_ls=0x8136dd0) at sapi_apache2.c:66
#2 0x403131ff in php_ub_body_write_no_header (str=0x81a01ac
"\n", str_length=11, tsrm_ls=0x8136dd0)
at output.c:440
#3 0x403127b8 in php_body_write (str=0x81a01ac "\n",
str_length=11, tsrm_ls=0x8136dd0) at output.c:99
#4 0x4030a59a in php_body_write_wrapper (str=0x81a01ac "\n",
str_length=11) at main.c:762
#5 0x402fd24d in zend_print_zval_ex (write_func=0x4030a568
, expr=0x819ee7c, indent=0)
at zend.c:187
#6 0x402fd1ed in zend_print_zval (expr=0x819ee7c, indent=0) at
zend.c:168
#7 0x402fce9e in zend_print_variable (var=0x819ee7c) at
zend_variables.c:169
#8 0x402ed960 in execute (op_array=0x817e228, tsrm_ls=0x8136dd0) at
./zend_execute.c:1231
#9 0x402efc28 in execute (op_array=0x8175ca4, tsrm_ls=0x8136dd0) at
./zend_execute.c:1638
#10 0x402fe6a2 in zend_execute_scripts (type=8, tsrm_ls=0x8136dd0,
retval=0x0, file_count=3) at zend.c:810
#11 0x4030b976 in php_execute_script (primary_file=0xb840,
tsrm_ls=0x8136dd0) at main.c:1333
#12 0x40308686 in php_output_filter (f=0x81a4a48, bb=0x81a4b90) at
sapi_apache2.c:381
#13 0x08082b3b in ap_pass_brigade (next=0x81a4a48, bb=0x81a4b90) at
util_filter.c:445
#14 0x08088898 in default_handler (r=0x81a3790) at core.c:2995
#15 0x080796d6 in ap_run_handler (r=0x81a3790) at config.c:185
#16 0x08079b41 in ap_invoke_handler (r=0x81a3790) at config.c:359
#17 0x0806a6e2 in ap_process_request (r=0x81a3790) at http_request.c:290
#18 0x08066ff1 in ap_process_http_connection (c=0x8167de0) at
http_core.c:287
#19 0x0808143e in ap_run_process_connection (c=0x8167de0) at
connection.c:85
#20 0x08078467 in child_main (child_num_arg=0) at prefork.c:717
#21 0x08078510 in make_child (s=0x81311c8, slot=0) at prefork.c:753
#22 0x080785fa in startup_children (number_to_start=2) at prefork.c:830
#23 0x0807888f in ap_mpm_run (_pconf=0x80aec98, plog=0x80e6d78,
s=0x81311c8) at prefork.c:1021
#24 0x0807d2cd in main (argc=2, argv=0xbb3c) at main.c:501
#25 0x40185177 in __libc_start_main (main=0x807cc20 , argc=2,
ubp_av=0xbb3c, init=0x805e00c <_init>,
fini=0x8091dc0 <_fini>, rtld_fini=0x4000e184 <_dl_fini>,
stack_end=0xbb2c)
at ../sysdeps/generic/libc-start.c:129
--
Edit bug report at http://bugs.php.net/?id=15766&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15766&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15766&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15766&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15766&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15766&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15766&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15766&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15766&r=submittedtwice
Bug #15766 Updated: Apache/2.0.32 (Unix) PHP/4.3.0-dev crashes during output
ID: 15766
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: Linux 2.4.2 - RedHat 7.1
PHP Version: 4.0CVS-2002-02-27
New Comment:
Here is my apache configuration:
./configure --prefix=/usr/local/apache2 --enable-so
And my PHP configuration:
./configure --with-xml \
--enable-ftp \
--with-imap=/usr/local/imap/imap-2001a \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-config-file-path=/usr/local/php/cvs/conf \
--with-mysql=/usr/local/mysql
Previous Comments:
[2002-02-27 18:20:11] [EMAIL PROTECTED]
The first few requests are handled fine, then suddenly Apache children
start segfaulting. The following script reproduces this crash,
backtrace is included after script:
Test crash
\n";
for ($i = 0; $i < $rows; ++$i) {
echo "";
for ($j = 0; $j < $cols; ++$j) {
echo "Hello World";
}
echo "\n";
}
echo "";
?>
backtrace follows ---
[root@auth bin]# gdb httpd
GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run -X
Starting program: /usr/local/apache2/bin/httpd -X
[New Thread 1024 (LWP 9570)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 9570)]
0x08082b38 in ap_pass_brigade (next=0x4001d3dc, bb=0x81a5000) at
util_filter.c:445
445 return next->frec->filter_func.out_func(next, bb);
(gdb) bt
#0 0x08082b38 in ap_pass_brigade (next=0x4001d3dc, bb=0x81a5000) at
util_filter.c:445
#1 0x40307e40 in php_apache_sapi_ub_write (str=0x81a01b7 "",
str_length=0, tsrm_ls=0x8136dd0) at sapi_apache2.c:66
#2 0x403131ff in php_ub_body_write_no_header (str=0x81a01ac
"\n", str_length=11, tsrm_ls=0x8136dd0)
at output.c:440
#3 0x403127b8 in php_body_write (str=0x81a01ac "\n",
str_length=11, tsrm_ls=0x8136dd0) at output.c:99
#4 0x4030a59a in php_body_write_wrapper (str=0x81a01ac "\n",
str_length=11) at main.c:762
#5 0x402fd24d in zend_print_zval_ex (write_func=0x4030a568
, expr=0x819ee7c, indent=0)
at zend.c:187
#6 0x402fd1ed in zend_print_zval (expr=0x819ee7c, indent=0) at
zend.c:168
#7 0x402fce9e in zend_print_variable (var=0x819ee7c) at
zend_variables.c:169
#8 0x402ed960 in execute (op_array=0x817e228, tsrm_ls=0x8136dd0) at
./zend_execute.c:1231
#9 0x402efc28 in execute (op_array=0x8175ca4, tsrm_ls=0x8136dd0) at
./zend_execute.c:1638
#10 0x402fe6a2 in zend_execute_scripts (type=8, tsrm_ls=0x8136dd0,
retval=0x0, file_count=3) at zend.c:810
#11 0x4030b976 in php_execute_script (primary_file=0xb840,
tsrm_ls=0x8136dd0) at main.c:1333
#12 0x40308686 in php_output_filter (f=0x81a4a48, bb=0x81a4b90) at
sapi_apache2.c:381
#13 0x08082b3b in ap_pass_brigade (next=0x81a4a48, bb=0x81a4b90) at
util_filter.c:445
#14 0x08088898 in default_handler (r=0x81a3790) at core.c:2995
#15 0x080796d6 in ap_run_handler (r=0x81a3790) at config.c:185
#16 0x08079b41 in ap_invoke_handler (r=0x81a3790) at config.c:359
#17 0x0806a6e2 in ap_process_request (r=0x81a3790) at
http_request.c:290
#18 0x08066ff1 in ap_process_http_connection (c=0x8167de0) at
http_core.c:287
#19 0x0808143e in ap_run_process_connection (c=0x8167de0) at
connection.c:85
#20 0x08078467 in child_main (child_num_arg=0) at prefork.c:717
#21 0x08078510 in make_child (s=0x81311c8, slot=0) at prefork.c:753
#22 0x080785fa in startup_children (number_to_start=2) at
prefork.c:830
#23 0x0807888f in ap_mpm_run (_pconf=0x80aec98, plog=0x80e6d78,
s=0x81311c8) at prefork.c:1021
#24 0x0807d2cd in main (argc=2, argv=0xbb3c) at main.c:501
#25 0x40185177 in __libc_start_main (main=0x807cc20 , argc=2,
ubp_av=0xbb3c, init=0x805e00c <_init>,
fini=0x8091dc0 <_fini>, rtld_fini=0x4000e184 <_dl_fini>,
stack_end=0xbb2c)
at ../sysdeps/generic/libc-start.c:129
--
Edit this bug report at http://bugs.php.net/?id=15766&edit=1
Bug #15767: Build instructions for Win32 incomplete
From: [EMAIL PROTECTED] Operating system: Win32 PHP version: 4.0CVS-2002-02-27 PHP Bug Type: Documentation problem Bug description: Build instructions for Win32 incomplete The documentation for building PHP on Win32 is good, except for the Cygwin part. By default, Cygwin doesn't install bison and flex, which are needed to build php. Bison and flex have to be added explicitly to the default Cygwin installation. Because the resulting errors are quite confusing, this info should be added to the documentation. One more point: PHP also compiles with vc++7. Christoph -- Edit bug report at http://bugs.php.net/?id=15767&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15767&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15767&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15767&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15767&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15767&r=support Expected behavior: http://bugs.php.net/fix.php?id=15767&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15767&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15767&r=submittedtwice
Bug #15768: FastCgi not picking up envrionemnt variables
From: [EMAIL PROTECTED]
Operating system: Linux 2.2.20
PHP version: 4.1.1
PHP Bug Type: PHP options/info functions
Bug description: FastCgi not picking up envrionemnt variables
The following script:
$value) {
echo $key.":".$value."";
}
?>
Produces the following output:
PHP_SELF=/dump_globals.php4
Same script of PHP 4.0.x works fine.
Seems to be consistent with the 4.1.x branch.
Server: Zeus 3.4r2
Compile Options:
./configure --prefix=/usr/local/php4 --with-regex=system --enable-calendar
--with-iodbc --with-dom --with-curl --with-openssl --with-db2 --with-iconv
--enable-filepro --enable-ftp --with-gettext --enable-sysvsem
--enable-sysvshm --enable-track-vars --enable-trans-sid --disable-debug
--with-gd=/usr --with-imap=/usr --with-ldap=/usr --with-mm=/usr
--with-mysql=/usr --with-regex=system --with-pcre-regex=/usr
--with-pgsql=/usr --enable-sockets --with-ttf
--enable-freetype-4bit-antialias-hack --with-t1lib --with-zlib
--enable-memory-limit --with-fastcgi=/usr/local/fcgi/ --with-pear
--enable-mbstring --enable-shmop --enable-exif --enable-bcmath
--enable-safemode --with-jpeg-dir=/usr --with-png-dir=/usr
--with-xpm-dir=/usr --with-xslt --with-xslt-sablot --with-mhash
--with-mcrypt=/usr/local
--with-tsrm-pth --enable-wddx --enable-shared=false
Thx
--
Edit bug report at http://bugs.php.net/?id=15768&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15768&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15768&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15768&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15768&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15768&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15768&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15768&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15768&r=submittedtwice
Bug #15769: php-4.0 crypt("abc") != php-4.1 crypt("abc")
From: [EMAIL PROTECTED]
Operating system: linux
PHP version: 4.1.1
PHP Bug Type: *Encryption and hash functions
Bug description: php-4.0 crypt("abc") != php-4.1 crypt("abc")
On the same system after upgrade, the result of crypt with only one
arguments has another format: before (php 4.0.6) it was the standard 13
chars string, and now this md5-like hash is comming:
"$1$ngOfu9A.$AoUUzzXjwxQiqKq7c2wDt1"...
Shouldn't the default behaviour of crypt() stay the same on a specific
system ? This way it breaks a lots of customers scripts on the web server
on upgrade, and this is *very* annoying. (no, I can't tell all people:
rewrite all your scripts and use 2 args with the crypt command).
Isn't there a way to tell at compliation time: crypt() defaults to DES?
Regards,
Olivier
--
Edit bug report at http://bugs.php.net/?id=15769&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15769&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15769&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15769&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15769&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15769&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15769&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15769&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15769&r=submittedtwice
Bug #15770: phe.exe unknown error
From: [EMAIL PROTECTED] Operating system: xp PHP version: 4.1.1 PHP Bug Type: IIS related Bug description: phe.exe unknown error hi, i've installed your packadge 4.1.1 for windows, cool! but a problem was reported when i run my php website the error is "php.exe error, would you send a bug to microsoft?" i think is a problem about compatibility with php 4.1.1 lenguage and IIS 5.1 Have you some news? Regards Rupert -- Edit bug report at http://bugs.php.net/?id=15770&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15770&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15770&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15770&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15770&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15770&r=support Expected behavior: http://bugs.php.net/fix.php?id=15770&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15770&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15770&r=submittedtwice
Bug #15736 Updated: Security Exploit
ID: 15736 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Unknown/Other Function Operating System: All UNIX PHP Version: 4.1.1 New Comment: The patch for file rfc1867.c applied to php 4.0.6 seems to not work when trying to upload from Opera 6.01 (on Windows). Uploading in Internet Explorer (6.0) seems to work allright, whereas uploading with Opera simply either times out or just fails (without any errors). Previous Comments: [2002-02-26 13:41:58] [EMAIL PROTECTED] Well, the part of doing this before Apache demotes its priviledges doesn't sound feasible to me. Apache forks child processes as a non-privileged user. You can't get it to serve up a PHP request as root. And if you could, then why use a "high port" as you mentioned? We will however have a fix for the file upload buffer overflow shortly. In the meantime, simply turn off file uploads in your php.ini file to protect yourself against this. [2002-02-26 13:34:46] [EMAIL PROTECTED] I am trying to get the source code, or at least an strace of the binary used for this exploit. [2002-02-26 13:31:53] [EMAIL PROTECTED] There's a security exploit for php that gives you remote root by binding a rootshell to a high port. Exploits php before apache demotes its privledges. Looks like it uses the POST method. Buffer overflow. I don't have the program (binary) available as a friend of mine had limited access to it. BUt it affect ALL versions of php. -- Edit this bug report at http://bugs.php.net/?id=15736&edit=1
Bug #15771: cannot pass value to image field by ado
From: [EMAIL PROTECTED]
Operating system: windows
PHP version: 4.0.6
PHP Bug Type: COM related
Bug description: cannot pass value to image field by ado
Since PHP can support COM and I usually use php in windows,
I try to use database like mssql through ado.
All things work properly but the image datatype of mysql cannot be set
correctly.
I use it just like this
Open("Provider=sqloledb;Data Source=ndht;Initial
Catalog=printers;User Id=printers;Password=printers;");
$fp=fopen("5.gif","r") or die ("file opening error");
$content = fread ($fp, filesize ("5.gif"));
fclose ($fp);
echo filesize ("5.gif");
$rec=new COM("ADODB.recordset");
$rec->open("select * from sav",$dbconn);
$rec->addnew();
$rec->fields["datas"]->AppendChunk($content);
$rec->update();
$rec->close();
$rec=null;
$dbconn->close();
$dbconn=null;
?>
I think that windows use two type text for strings and binary for the 8bit
chars, but in php string are both of
these.
So when trans the data to mssql,the variables be string of
window first, and the information were lost.
--
Edit bug report at http://bugs.php.net/?id=15771&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15771&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15771&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15771&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15771&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15771&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15771&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15771&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15771&r=submittedtwice
Bug #15772: PHP is developed and maintained by morons
From: [EMAIL PROTECTED]
Operating system: all
PHP version: 4.0.6
PHP Bug Type: *General Issues
Bug description: PHP is developed and maintained by morons
Dear morons,
Please observe the following two lines from the 'fix' you have posted for
your file-upload incompetence:
loc = (char *) memchr(ptr, '\n', rem)+1;
if (!loc) {
There's a bug in this code. Can you see what it is? Hint: the 'if'
expression will never evaluate true. Well, that's assuming the first line
doesn't crash since it invokes undefined behaviour.
Hint #2: the whole routine (not just those 2 lines) is still completely
and utterly broken as of revision 1.71.2.2. It is riddled with code that
reads beyond the end of the buffer.
Hint #3: yet again, you need to follow-up to your Bugtraq posting with a
message saying 'Not only were we too stupid to write the code right in the
first place, we were too stupid to fix it right too. Please ignore our
previous patch. Please use this new one, which will probably be wrong
also.'
HTH, HAND.
--
Edit bug report at http://bugs.php.net/?id=15772&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15772&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15772&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15772&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15772&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15772&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15772&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15772&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15772&r=submittedtwice
Bug #15757 Updated: php4apache.dll not found/valid
ID: 15757 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: Win2000 PHP Version: 4.1.1 New Comment: I built it myself and it STILL doesn't work. If i load just phpinfo();, it load fine once. But, the second time Apache crashes. Previous Comments: [2002-02-27 07:00:06] [EMAIL PROTECTED] php4apache.dll is for Apache 1.3.x php4apache2.dll (IIRC) is for Apache 2.x, but it only works for some versions. If you really need it, you should build it yourself from source. As long as Apache 2.x is not stable, we can't provide you with a reliable php4apache2.dll [2002-02-27 04:51:31] [EMAIL PROTECTED] Hi, I just installed PHP 4.1.1 on my Win2000 which already holds Apache 2.0.32b3. I want to use the DLL provided by the PHP-zip-file from within Apache. Though if I check my httpd.conf with Apache it says that it can't find php4apache.dll in the given path even though it's there. I tried various things like copying the DLLs which came with PHP into system directories but the problem is still there. Btw, I followed the instructions in the install.txt so this should have worked in the first place. On www.apache.org I found a post that the problem is that that very DLL is probably not supposed to work with the new Apache but with the old one (before 2.0). So my question is when will there be a working php4apache.dll which works with the new Apache-server? I know this is not really a bug more a question but the problem arose from a bug-like situation and I assume I'm not the only one who'd like to know this. And others may think this is a bug, too, but will find this question here. :) Regards, Stefan -- Edit this bug report at http://bugs.php.net/?id=15757&edit=1
Bug #15772 Updated: PHP is developed and maintained by morons
ID: 15772
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: *General Issues
Operating System: all
PHP Version: 4.0.6
New Comment:
True, that bit of code made no sense and has been fixed. The entire
thing has been reworked for the 4.2 tree, but if you could expand on
the muriad of buffer overflows aside from the memchr()+1 mixup, and
submit a useful bug report it would be appreciated.
Previous Comments:
[2002-02-27 21:40:17] [EMAIL PROTECTED]
Dear morons,
Please observe the following two lines from the 'fix' you have posted
for your file-upload incompetence:
loc = (char *) memchr(ptr, '\n', rem)+1;
if (!loc) {
There's a bug in this code. Can you see what it is? Hint: the 'if'
expression will never evaluate true. Well, that's assuming the first
line doesn't crash since it invokes undefined behaviour.
Hint #2: the whole routine (not just those 2 lines) is still completely
and utterly broken as of revision 1.71.2.2. It is riddled with code
that reads beyond the end of the buffer.
Hint #3: yet again, you need to follow-up to your Bugtraq posting with
a message saying 'Not only were we too stupid to write the code right
in the first place, we were too stupid to fix it right too. Please
ignore our previous patch. Please use this new one, which will probably
be wrong also.'
HTH, HAND.
--
Edit this bug report at http://bugs.php.net/?id=15772&edit=1
Bug #15772 Updated: PHP is developed and maintained by morons
ID: 15772
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: *General Issues
Operating System: all
PHP Version: 4.0.6
New Comment:
It what way is it "fixed"? Every PHP user in the entire world is going
to have to download the patches from www.php.net to fix the security
hole, and those patches contain this bug. I know that it is fixed in
CVS in that the entire file has been replaced, but as I understand it
there is no fixed release version.
As to the other bugs, just look at the main while() loop in
php_mime_split(). Pretty much every call to str* functions (including
the very first one) are reading beyond the end of the buffer. If this
happens, 'rem' may become negative and even more excitement ensues.
Previous Comments:
[2002-02-27 22:55:48] [EMAIL PROTECTED]
True, that bit of code made no sense and has been fixed. The entire
thing has been reworked for the 4.2 tree, but if you could expand on
the muriad of buffer overflows aside from the memchr()+1 mixup, and
submit a useful bug report it would be appreciated.
[2002-02-27 21:40:17] [EMAIL PROTECTED]
Dear morons,
Please observe the following two lines from the 'fix' you have posted
for your file-upload incompetence:
loc = (char *) memchr(ptr, '\n', rem)+1;
if (!loc) {
There's a bug in this code. Can you see what it is? Hint: the 'if'
expression will never evaluate true. Well, that's assuming the first
line doesn't crash since it invokes undefined behaviour.
Hint #2: the whole routine (not just those 2 lines) is still completely
and utterly broken as of revision 1.71.2.2. It is riddled with code
that reads beyond the end of the buffer.
Hint #3: yet again, you need to follow-up to your Bugtraq posting with
a message saying 'Not only were we too stupid to write the code right
in the first place, we were too stupid to fix it right too. Please
ignore our previous patch. Please use this new one, which will probably
be wrong also.'
HTH, HAND.
--
Edit this bug report at http://bugs.php.net/?id=15772&edit=1
Bug #15215 Updated: Wrong path for php.ini under Windows XP (Home and Professional)
ID: 15215 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: *Configuration Issues Operating System: Windows NT 5.1 (XP) PHP Version: 4.1.1 New Comment: No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-01-27 15:11:58] [EMAIL PROTECTED] Do you mean the PHP installer? Anyway, Christoph is right, it doesn't look at the version string but it just tries your Windows-directory. phpinfo() reports where it has found php.ini. Look at that path. It should really work if you place it in c:\windows. [2002-01-27 15:05:09] [EMAIL PROTECTED] This has never happened to me. My php.ini gets parsed whether it resides in windows directory (for sapi-version) or in php-directory for cgi. I'm using XP Pro, but it also works with NT 4 and non-standard windir-name (winntw). Christoph [2002-01-24 19:14:40] [EMAIL PROTECTED] If you install the Windows binaries on Systems running Windows XP, PHP assumes that there is a system directory 'C:\winnt\' because of the version string reported by Windows (Windows NT 5.x). As there is no such Dir (under Win XP the System Dir is named 'C:\Windows\' by default), php.ini is not found. I couldn't find help in creating this dir and put the .ini file in. Also the 'php.ini' is not found if simply put in the path. -- Edit this bug report at http://bugs.php.net/?id=15215&edit=1
Bug #14895 Updated: Error when trying to load the php4 module
ID: 14895 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Duplicate Bug Type: OpenSSL related Operating System: FreeBSD 4.3-RELEASE PHP Version: 4.1.1 New Comment: Any answers to this problem yet? #!/bin/bash rm config.cache; export LIBS="-ljpeg -lpng" LDFLAGS="-L/usr/local/ssl/lib -L/usr/X11R6/lib -L/usr/local/lib" \ CFLAGS="$CFLAGS -I/usr/local/include" CPPFLAGS="$CFLAGS" ./configure \ --with-apxs=/usr/local/apache/bin/apxs --enable-track-vars \ --enable-magic-quotes --enable-trans-sid --enable-memory-limit \ --enable-force-cgi-redirect --enable-discard-path --with-openssl \ --enable-sigchild --enable-bcmath --with-bz2 \ --enable-calendar --enable-ftp \ --with-imap=/usr/src/imap-2002.DEV.SNAP-0202261726/ --with-imap-ssl=/usr/local/ssl/lib \ --with-pgsql --enable-trans-sid --with-zlib \ --with-mysql=no \ --enable-sysvshm --x-libraries=/usr/X11R6/lib \ --with-freetype-dir=/usr/local/include/freetype1/ \ --with-jpeg-dir=shared \ --with-png-dir=shared --with-xpm-dir=shared --with-gd-dir=shared --with-gd ... Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/libexec/libphp4.so: undefined symbol: ssl_onceonlyinit imapd is compiled as: make install SSLTYPE=nopwd ssl_onceonlyinit is located in imapd/src/osdep/unix/ssl_unix.c Previous Comments: [2002-02-22 02:32:27] [EMAIL PROTECTED] Sorry, this actually WAS imap-ssl related. [2002-01-19 14:33:23] [EMAIL PROTECTED] I've searched the bugdb per your suggestion, Derick. All I found were two old IMAP-SSL related issues when I searched for the function name (ssl_onceonlyinit). I can download a copy of the CVS source if you like and retry my compile to see if it is fixed. Something to note, is on a fresh FreeBSD install (4.4-RELEASE), I installed apache and mod_php from a cvsup'ed ports collection, and I get the same error, so you may start to get more wide spread reports of this error. Let me know. [2002-01-19 13:08:40] [EMAIL PROTECTED] You need to provide a little more information, read bugs.php.net/how-to-report.php Derick [2002-01-06 18:37:15] [EMAIL PROTECTED] Here is my configuration when compiling php ./configure --with-mysql --enable-track-vars --with-snmp --with-imap --with-apxs=/usr/local/apache/bin/apxs --enable-ucd-snmp-hack --with-imap-ssl --with-openssl=/usr --enable-sockets --enable-ftp --with-bz2 --with-zlib My apache version is 1.3.20 (I tried with 1.3.22 as well and had the same issue. The error I get when attempting to start the apache server (compiles fine) is: Cannot load /usr/local/libexec/apache/libphp4.so into server: /usr/local/libexec/apache/libphp4.so: Undefined symbol "ssl_onceonlyinit" libssl exists: (root@warped) [/usr/lib]$ ls -ld /usr/lib/libssl.so lrwxrwxrwx 1 root wheel 11 Sep 7 17:59 /usr/lib/libssl.so -> libssl.so.2 (root@warped) [/usr/lib]$ ls -ld /usr/lib/libssl.so.2 -r--r--r-- 1 root wheel 176348 Apr 21 2001 /usr/lib/libssl.so.2 I can post a list of apache modules if nessicary, but that doesn't seem to matter, I do use mod_ssl though. -- Edit this bug report at http://bugs.php.net/?id=14895&edit=1
Bug #15772 Updated: PHP is developed and maintained by morons
ID: 15772
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: *General Issues
Operating System: all
PHP Version: 4.0.6
New Comment:
The specific memchr()+1 issue is fixed in CVS which was the only useful
part of this bug report. We close bugs when they are fixed in CVS, not
when we ship releases.
Previous Comments:
[2002-02-27 23:20:44] [EMAIL PROTECTED]
It what way is it "fixed"? Every PHP user in the entire world is going
to have to download the patches from www.php.net to fix the security
hole, and those patches contain this bug. I know that it is fixed in
CVS in that the entire file has been replaced, but as I understand it
there is no fixed release version.
As to the other bugs, just look at the main while() loop in
php_mime_split(). Pretty much every call to str* functions (including
the very first one) are reading beyond the end of the buffer. If this
happens, 'rem' may become negative and even more excitement ensues.
[2002-02-27 22:55:48] [EMAIL PROTECTED]
True, that bit of code made no sense and has been fixed. The entire
thing has been reworked for the 4.2 tree, but if you could expand on
the muriad of buffer overflows aside from the memchr()+1 mixup, and
submit a useful bug report it would be appreciated.
[2002-02-27 21:40:17] [EMAIL PROTECTED]
Dear morons,
Please observe the following two lines from the 'fix' you have posted
for your file-upload incompetence:
loc = (char *) memchr(ptr, '\n', rem)+1;
if (!loc) {
There's a bug in this code. Can you see what it is? Hint: the 'if'
expression will never evaluate true. Well, that's assuming the first
line doesn't crash since it invokes undefined behaviour.
Hint #2: the whole routine (not just those 2 lines) is still completely
and utterly broken as of revision 1.71.2.2. It is riddled with code
that reads beyond the end of the buffer.
Hint #3: yet again, you need to follow-up to your Bugtraq posting with
a message saying 'Not only were we too stupid to write the code right
in the first place, we were too stupid to fix it right too. Please
ignore our previous patch. Please use this new one, which will probably
be wrong also.'
HTH, HAND.
--
Edit this bug report at http://bugs.php.net/?id=15772&edit=1
Bug #15772 Updated: PHP is developed and maintained by morons
ID: 15772
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: *General Issues
Operating System: all
PHP Version: 4.0.6
New Comment:
Fine by me, but the problems are not fixed in CVS. You asked me for
more specifics, I gave them to you.
Previous Comments:
[2002-02-27 23:34:49] [EMAIL PROTECTED]
The specific memchr()+1 issue is fixed in CVS which was the only useful
part of this bug report. We close bugs when they are fixed in CVS, not
when we ship releases.
[2002-02-27 23:20:44] [EMAIL PROTECTED]
It what way is it "fixed"? Every PHP user in the entire world is going
to have to download the patches from www.php.net to fix the security
hole, and those patches contain this bug. I know that it is fixed in
CVS in that the entire file has been replaced, but as I understand it
there is no fixed release version.
As to the other bugs, just look at the main while() loop in
php_mime_split(). Pretty much every call to str* functions (including
the very first one) are reading beyond the end of the buffer. If this
happens, 'rem' may become negative and even more excitement ensues.
[2002-02-27 22:55:48] [EMAIL PROTECTED]
True, that bit of code made no sense and has been fixed. The entire
thing has been reworked for the 4.2 tree, but if you could expand on
the muriad of buffer overflows aside from the memchr()+1 mixup, and
submit a useful bug report it would be appreciated.
[2002-02-27 21:40:17] [EMAIL PROTECTED]
Dear morons,
Please observe the following two lines from the 'fix' you have posted
for your file-upload incompetence:
loc = (char *) memchr(ptr, '\n', rem)+1;
if (!loc) {
There's a bug in this code. Can you see what it is? Hint: the 'if'
expression will never evaluate true. Well, that's assuming the first
line doesn't crash since it invokes undefined behaviour.
Hint #2: the whole routine (not just those 2 lines) is still completely
and utterly broken as of revision 1.71.2.2. It is riddled with code
that reads beyond the end of the buffer.
Hint #3: yet again, you need to follow-up to your Bugtraq posting with
a message saying 'Not only were we too stupid to write the code right
in the first place, we were too stupid to fix it right too. Please
ignore our previous patch. Please use this new one, which will probably
be wrong also.'
HTH, HAND.
--
Edit this bug report at http://bugs.php.net/?id=15772&edit=1
Bug #14895 Updated: Error when trying to load the php4 module
ID: 14895 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Duplicate Bug Type: OpenSSL related Operating System: FreeBSD 4.3-RELEASE PHP Version: 4.1.1 New Comment: The answer is: Find and remove any old [lib]c-client.a|so on your system, then install the new uw c-client library or let php find it in your --with-imap directory. David Previous Comments: [2002-02-27 23:28:46] [EMAIL PROTECTED] Any answers to this problem yet? #!/bin/bash rm config.cache; export LIBS="-ljpeg -lpng" LDFLAGS="-L/usr/local/ssl/lib -L/usr/X11R6/lib -L/usr/local/lib" \ CFLAGS="$CFLAGS -I/usr/local/include" CPPFLAGS="$CFLAGS" ./configure \ --with-apxs=/usr/local/apache/bin/apxs --enable-track-vars \ --enable-magic-quotes --enable-trans-sid --enable-memory-limit \ --enable-force-cgi-redirect --enable-discard-path --with-openssl \ --enable-sigchild --enable-bcmath --with-bz2 \ --enable-calendar --enable-ftp \ --with-imap=/usr/src/imap-2002.DEV.SNAP-0202261726/ --with-imap-ssl=/usr/local/ssl/lib \ --with-pgsql --enable-trans-sid --with-zlib \ --with-mysql=no \ --enable-sysvshm --x-libraries=/usr/X11R6/lib \ --with-freetype-dir=/usr/local/include/freetype1/ \ --with-jpeg-dir=shared \ --with-png-dir=shared --with-xpm-dir=shared --with-gd-dir=shared --with-gd ... Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/libexec/libphp4.so: undefined symbol: ssl_onceonlyinit imapd is compiled as: make install SSLTYPE=nopwd ssl_onceonlyinit is located in imapd/src/osdep/unix/ssl_unix.c [2002-02-22 02:32:27] [EMAIL PROTECTED] Sorry, this actually WAS imap-ssl related. [2002-01-19 14:33:23] [EMAIL PROTECTED] I've searched the bugdb per your suggestion, Derick. All I found were two old IMAP-SSL related issues when I searched for the function name (ssl_onceonlyinit). I can download a copy of the CVS source if you like and retry my compile to see if it is fixed. Something to note, is on a fresh FreeBSD install (4.4-RELEASE), I installed apache and mod_php from a cvsup'ed ports collection, and I get the same error, so you may start to get more wide spread reports of this error. Let me know. [2002-01-19 13:08:40] [EMAIL PROTECTED] You need to provide a little more information, read bugs.php.net/how-to-report.php Derick [2002-01-06 18:37:15] [EMAIL PROTECTED] Here is my configuration when compiling php ./configure --with-mysql --enable-track-vars --with-snmp --with-imap --with-apxs=/usr/local/apache/bin/apxs --enable-ucd-snmp-hack --with-imap-ssl --with-openssl=/usr --enable-sockets --enable-ftp --with-bz2 --with-zlib My apache version is 1.3.20 (I tried with 1.3.22 as well and had the same issue. The error I get when attempting to start the apache server (compiles fine) is: Cannot load /usr/local/libexec/apache/libphp4.so into server: /usr/local/libexec/apache/libphp4.so: Undefined symbol "ssl_onceonlyinit" libssl exists: (root@warped) [/usr/lib]$ ls -ld /usr/lib/libssl.so lrwxrwxrwx 1 root wheel 11 Sep 7 17:59 /usr/lib/libssl.so -> libssl.so.2 (root@warped) [/usr/lib]$ ls -ld /usr/lib/libssl.so.2 -r--r--r-- 1 root wheel 176348 Apr 21 2001 /usr/lib/libssl.so.2 I can post a list of apache modules if nessicary, but that doesn't seem to matter, I do use mod_ssl though. -- Edit this bug report at http://bugs.php.net/?id=14895&edit=1
Bug #11668 Updated: Oracle and MS-SQL cannot co-exist
ID: 11668 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Dynamic loading Operating System: Windows NT 4.0 Sp 6 PHP Version: 4.0.4pl1 New Comment: No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-01-14 02:35:43] [EMAIL PROTECTED] Can you reproduce this with 4.1.1? [2001-06-25 11:09:24] [EMAIL PROTECTED] Using WIn NT 4.0 SP 6 - Oracle client 8.0.6 and MS-SQL Client 7 SP 3. IIS from the NT Option Pack - php.exe CGI I am able to use Oracle extensions in PHP. When I enable the MS-SQL extension the Oracle extensions fail. Dr. Watson does not come up due to the compaq debugger that replaced Dr. Watson's debugger fails to initialize USER32.dll (I have to fix that.) But regardless the behavior exists. I have tried to go to 4.0.6 but when doing so Oracle still fails to connect...this time with a Oracle error but then the SQL Server extension fails to be found (yes I know put the dll in the system directory...I'll try that) I can't switch to Apache at this time. -- Edit this bug report at http://bugs.php.net/?id=11668&edit=1
Bug #15205 Updated: ADODB.Recordset PropPut() failed:
ID: 15205
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: COM related
Operating System: WIN2000 SP2 German
PHP Version: 4.1.1
New Comment:
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-01-27 10:24:13] [EMAIL PROTECTED]
could you add '()' to all of your method calls. your script seems very
odd this.
[2002-01-24 09:19:41] [EMAIL PROTECTED]
Provider = "Microsoft.Jet.OLEDB.4.0";
$conn->ConnectionString = "Data Source=$Source";
$conn->Mode=3;
$conn->Open();
$SQL2="select * from FILES where FILE_ID=2";
$record->Open($SQL2,$conn,3);
$record->MoveLast;
$test=$record->Fields("FILE_NAME");
$test->Value="test";
/**
Warning: PropPut() failed: Ausnahmefehler aufgetreten. Source:
ADODB.Field Description: Das Objekt oder der Provider kann den
angeforderten Vorgang nicht ausführen. in D:\Linux\neu.php on line 20
**/
$record->Update;
$record->Requery;
$record->Close;
?>
WHY ??
-_Th.Weisbach
--
Edit this bug report at http://bugs.php.net/?id=15205&edit=1
Bug #15773: LoadModule directive incorrectly added to httpd.conf when mod_ssl is used
From: [EMAIL PROTECTED] Operating system: SunOS 5.8 PHP version: 4.1.1 PHP Bug Type: Apache related Bug description: LoadModule directive incorrectly added to httpd.conf when mod_ssl is used (This actually applies to PHP 4.1.2, but the pulldown box on the bug reporting page hasn't been updated to reflect that yet). When Apache (1.3.23) is compiled with mod_ssl (2.8.7) as a DSO module, mod_ssl automatically adds this to httpd.conf: ... LoadModule ssl_module libexec/libssl.so Later, when building a DSO version of PHP (4.1.2), using the --with-apxs option, PHP helpfully tries to add the appropriate LoadModule/AddModule directives to httpd.conf. However, it appears to guess incorrectly where the LoadModule directive should go, so httpd.conf now contains this: ... LoadModule ssl_module libexec/libssl.so LoadModule php4_modulelibexec/libphp4.so which will cause PHP not to load (and httpd to not start) unless SSL is also running. The solution, of course, is for httpd.conf to look like this: LoadModule ssl_module libexec/libssl.so LoadModule php4_modulelibexec/libphp4.so (actually, as I dig into the PHP code, I'm beginning to wonder if it's an apxs problem rather than a PHP problem. Still, even if it is, perhaps PHP's installer can work around it?) Thanks. -- Edit bug report at http://bugs.php.net/?id=15773&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15773&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15773&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15773&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15773&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15773&r=support Expected behavior: http://bugs.php.net/fix.php?id=15773&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15773&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15773&r=submittedtwice
Bug #15768 Updated: FastCgi not picking up envrionemnt variables
ID: 15768
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: PHP options/info functions
Operating System: Linux 2.2.20
PHP Version: 4.1.1
New Comment:
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
Previous Comments:
[2002-02-27 19:03:17] [EMAIL PROTECTED]
The following script:
$value) {
echo $key.":".$value."";
}
?>
Produces the following output:
PHP_SELF=/dump_globals.php4
Same script of PHP 4.0.x works fine.
Seems to be consistent with the 4.1.x branch.
Server: Zeus 3.4r2
Compile Options:
./configure --prefix=/usr/local/php4 --with-regex=system
--enable-calendar --with-iodbc --with-dom --with-curl --with-openssl
--with-db2 --with-iconv --enable-filepro --enable-ftp --with-gettext
--enable-sysvsem --enable-sysvshm --enable-track-vars
--enable-trans-sid --disable-debug --with-gd=/usr --with-imap=/usr
--with-ldap=/usr --with-mm=/usr --with-mysql=/usr --with-regex=system
--with-pcre-regex=/usr --with-pgsql=/usr --enable-sockets --with-ttf
--enable-freetype-4bit-antialias-hack --with-t1lib --with-zlib
--enable-memory-limit --with-fastcgi=/usr/local/fcgi/ --with-pear
--enable-mbstring --enable-shmop --enable-exif --enable-bcmath
--enable-safemode --with-jpeg-dir=/usr --with-png-dir=/usr
--with-xpm-dir=/usr --with-xslt --with-xslt-sablot --with-mhash
--with-mcrypt=/usr/local
--with-tsrm-pth --enable-wddx --enable-shared=false
Thx
--
Edit this bug report at http://bugs.php.net/?id=15768&edit=1
Bug #15773 Updated: LoadModule directive incorrectly added to httpd.conf when mod_ssl is used
ID: 15773 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type: Apache related Operating System: SunOS 5.8 PHP Version: 4.1.1 New Comment: Yes, this httpd.conf file mangling is done by apxs which is outside the domain of PHP. I suppose we could try to work around it somehow, but it would be rather non-trivial. The most we might be able to do is detect the situation and tell apxs not to try to mangle the httpd.conf file. Previous Comments: [2002-02-28 02:00:32] [EMAIL PROTECTED] (This actually applies to PHP 4.1.2, but the pulldown box on the bug reporting page hasn't been updated to reflect that yet). When Apache (1.3.23) is compiled with mod_ssl (2.8.7) as a DSO module, mod_ssl automatically adds this to httpd.conf: ... LoadModule ssl_module libexec/libssl.so Later, when building a DSO version of PHP (4.1.2), using the --with-apxs option, PHP helpfully tries to add the appropriate LoadModule/AddModule directives to httpd.conf. However, it appears to guess incorrectly where the LoadModule directive should go, so httpd.conf now contains this: ... LoadModule ssl_module libexec/libssl.so LoadModule php4_modulelibexec/libphp4.so which will cause PHP not to load (and httpd to not start) unless SSL is also running. The solution, of course, is for httpd.conf to look like this: LoadModule ssl_module libexec/libssl.so LoadModule php4_modulelibexec/libphp4.so (actually, as I dig into the PHP code, I'm beginning to wonder if it's an apxs problem rather than a PHP problem. Still, even if it is, perhaps PHP's installer can work around it?) Thanks. -- Edit this bug report at http://bugs.php.net/?id=15773&edit=1
Bug #15768 Updated: FastCgi not picking up envrionemnt variables
ID: 15768
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Feedback
Bug Type: PHP options/info functions
Operating System: Linux 2.2.20
PHP Version: 4.1.1
New Comment:
oops..I clicked wrong link. Anyways, your example script
is pretty much bogus. There is no such variable as HTTP_SERV_VARS. Try
this instead:
$value) {
echo $key.":".$value."";
}
?>
Previous Comments:
[2002-02-28 02:04:01] [EMAIL PROTECTED]
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
[2002-02-27 19:03:17] [EMAIL PROTECTED]
The following script:
$value) {
echo $key.":".$value."";
}
?>
Produces the following output:
PHP_SELF=/dump_globals.php4
Same script of PHP 4.0.x works fine.
Seems to be consistent with the 4.1.x branch.
Server: Zeus 3.4r2
Compile Options:
./configure --prefix=/usr/local/php4 --with-regex=system
--enable-calendar --with-iodbc --with-dom --with-curl --with-openssl
--with-db2 --with-iconv --enable-filepro --enable-ftp --with-gettext
--enable-sysvsem --enable-sysvshm --enable-track-vars
--enable-trans-sid --disable-debug --with-gd=/usr --with-imap=/usr
--with-ldap=/usr --with-mm=/usr --with-mysql=/usr --with-regex=system
--with-pcre-regex=/usr --with-pgsql=/usr --enable-sockets --with-ttf
--enable-freetype-4bit-antialias-hack --with-t1lib --with-zlib
--enable-memory-limit --with-fastcgi=/usr/local/fcgi/ --with-pear
--enable-mbstring --enable-shmop --enable-exif --enable-bcmath
--enable-safemode --with-jpeg-dir=/usr --with-png-dir=/usr
--with-xpm-dir=/usr --with-xslt --with-xslt-sablot --with-mhash
--with-mcrypt=/usr/local
--with-tsrm-pth --enable-wddx --enable-shared=false
Thx
--
Edit this bug report at http://bugs.php.net/?id=15768&edit=1
Bug #15768 Updated: FastCgi not picking up envrionemnt variables
ID: 15768
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: PHP options/info functions
Operating System: Linux 2.2.20
PHP Version: 4.1.1
New Comment:
I don't see how this is a support question. In fact, there is no
question at all in this report. Granted, his example code should
probably use $HTTP_SERVER_VARS, but if it actually behaves like he says
then it appears to be a bug.
Previous Comments:
[2002-02-28 02:06:32] [EMAIL PROTECTED]
oops..I clicked wrong link. Anyways, your example script
is pretty much bogus. There is no such variable as HTTP_SERV_VARS. Try
this instead:
$value) {
echo $key.":".$value."";
}
?>
[2002-02-28 02:04:01] [EMAIL PROTECTED]
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
[2002-02-27 19:03:17] [EMAIL PROTECTED]
The following script:
$value) {
echo $key.":".$value."";
}
?>
Produces the following output:
PHP_SELF=/dump_globals.php4
Same script of PHP 4.0.x works fine.
Seems to be consistent with the 4.1.x branch.
Server: Zeus 3.4r2
Compile Options:
./configure --prefix=/usr/local/php4 --with-regex=system
--enable-calendar --with-iodbc --with-dom --with-curl --with-openssl
--with-db2 --with-iconv --enable-filepro --enable-ftp --with-gettext
--enable-sysvsem --enable-sysvshm --enable-track-vars
--enable-trans-sid --disable-debug --with-gd=/usr --with-imap=/usr
--with-ldap=/usr --with-mm=/usr --with-mysql=/usr --with-regex=system
--with-pcre-regex=/usr --with-pgsql=/usr --enable-sockets --with-ttf
--enable-freetype-4bit-antialias-hack --with-t1lib --with-zlib
--enable-memory-limit --with-fastcgi=/usr/local/fcgi/ --with-pear
--enable-mbstring --enable-shmop --enable-exif --enable-bcmath
--enable-safemode --with-jpeg-dir=/usr --with-png-dir=/usr
--with-xpm-dir=/usr --with-xslt --with-xslt-sablot --with-mhash
--with-mcrypt=/usr/local
--with-tsrm-pth --enable-wddx --enable-shared=false
Thx
--
Edit this bug report at http://bugs.php.net/?id=15768&edit=1
Bug #15769 Updated: php-4.0 crypt("abc") != php-4.1 crypt("abc")
ID: 15769
Updated by: [EMAIL PROTECTED]
-Summary: php-4.0 crypt("abc") != php-4.1 crypt("abc")
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: *Encryption and hash functions
Operating System: linux
PHP Version: 4.1.1
New Comment:
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
Previous Comments:
[2002-02-27 19:53:56] [EMAIL PROTECTED]
On the same system after upgrade, the result of crypt with only one
arguments has another format: before (php 4.0.6) it was the standard 13
chars string, and now this md5-like hash is comming:
"$1$ngOfu9A.$AoUUzzXjwxQiqKq7c2wDt1"...
Shouldn't the default behaviour of crypt() stay the same on a specific
system ? This way it breaks a lots of customers scripts on the web
server on upgrade, and this is *very* annoying. (no, I can't tell all
people: rewrite all your scripts and use 2 args with the crypt
command).
Isn't there a way to tell at compliation time: crypt() defaults to DES?
Regards,
Olivier
--
Edit this bug report at http://bugs.php.net/?id=15769&edit=1
Bug #15769 Updated: php-4.0 crypt("abc") != php-4.1 crypt("abc")
ID: 15769
Updated by: [EMAIL PROTECTED]
-Summary: php-4.0 crypt("abc") != php-4.1 crypt("abc")
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Encryption and hash functions
Operating System: linux
PHP Version: 4.1.1
New Comment:
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
http://www.php.net/manual/en/function.crypt.php
Previous Comments:
[2002-02-28 02:08:38] [EMAIL PROTECTED]
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
[2002-02-27 19:53:56] [EMAIL PROTECTED]
On the same system after upgrade, the result of crypt with only one
arguments has another format: before (php 4.0.6) it was the standard 13
chars string, and now this md5-like hash is comming:
"$1$ngOfu9A.$AoUUzzXjwxQiqKq7c2wDt1"...
Shouldn't the default behaviour of crypt() stay the same on a specific
system ? This way it breaks a lots of customers scripts on the web
server on upgrade, and this is *very* annoying. (no, I can't tell all
people: rewrite all your scripts and use 2 args with the crypt
command).
Isn't there a way to tell at compliation time: crypt() defaults to DES?
Regards,
Olivier
--
Edit this bug report at http://bugs.php.net/?id=15769&edit=1
Bug #15770 Updated: phe.exe unknown error
ID: 15770 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: IIS related Operating System: xp PHP Version: 4.1.1 New Comment: The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php Previous Comments: [2002-02-27 20:16:24] [EMAIL PROTECTED] hi, i've installed your packadge 4.1.1 for windows, cool! but a problem was reported when i run my php website the error is "php.exe error, would you send a bug to microsoft?" i think is a problem about compatibility with php 4.1.1 lenguage and IIS 5.1 Have you some news? Regards Rupert -- Edit this bug report at http://bugs.php.net/?id=15770&edit=1
Bug #15736 Updated: Security Exploit
ID: 15736 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: All UNIX PHP Version: 4.1.1 New Comment: This bug has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2002-02-27 20:54:47] [EMAIL PROTECTED] The patch for file rfc1867.c applied to php 4.0.6 seems to not work when trying to upload from Opera 6.01 (on Windows). Uploading in Internet Explorer (6.0) seems to work allright, whereas uploading with Opera simply either times out or just fails (without any errors). [2002-02-26 13:41:58] [EMAIL PROTECTED] Well, the part of doing this before Apache demotes its priviledges doesn't sound feasible to me. Apache forks child processes as a non-privileged user. You can't get it to serve up a PHP request as root. And if you could, then why use a "high port" as you mentioned? We will however have a fix for the file upload buffer overflow shortly. In the meantime, simply turn off file uploads in your php.ini file to protect yourself against this. [2002-02-26 13:34:46] [EMAIL PROTECTED] I am trying to get the source code, or at least an strace of the binary used for this exploit. [2002-02-26 13:31:53] [EMAIL PROTECTED] There's a security exploit for php that gives you remote root by binding a rootshell to a high port. Exploits php before apache demotes its privledges. Looks like it uses the POST method. Buffer overflow. I don't have the program (binary) available as a friend of mine had limited access to it. BUt it affect ALL versions of php. -- Edit this bug report at http://bugs.php.net/?id=15736&edit=1
Bug #15774: apache dies immediately after starting
From: [EMAIL PROTECTED] Operating system: GNU/Linux Debian Potato PHP version: 4.1.1 PHP Bug Type: Reproducible crash Bug description: apache dies immediately after starting This is actually php version 4.1.2 (there is no selection for that in this form). I've compiled a new version of apache 1.2.23 and PHP 4.1.2 and when I try to start apache it dies immediately without any errors in the error_log or anywhere else. I tried to strace the binary, but nothing showed up, with --enable-debug on, I get the following: zend_hash.c(532) : ht=0x081d8860 is already destroyed zend_hash.c(98) : Bailed out without a bailout address! in my error log. If I try to do a gdb back trace I get the following: (gdb) run -X Starting program: /usr/local/apache/bin/httpd_new -X Program exited with code 0377. (gdb) bt No stack. When I didn't have --enable-debug compiled in and I attempted to do a backtrace, I got the following: F10 key ==> File Edit Search Buffers Windows System Help Program received signal SIGSEGV, Segmentation fault. 0x28893e in malloc () from /lib/libc.so.6 crap, hold on exited gdb already :) I dont like having our webserver down for so long ok did the bt #0 0x28893e in malloc () from /lib/libc.so.6 #1 0x28987d in calloc () from /lib/libc.so.6 #2 0x11888e in _dl_new_object () from /lib/ld-linux.so.2 #3 0x1152e4 in _dl_map_object_from_fd () from /lib/ld-linux.so.2 #4 0x116d7b in _dl_map_object () from /lib/ld-linux.so.2 #5 0x1196ac in _dl_map_object_deps () from /lib/ld-linux.so.2 #6 0x2ff6e3 in getutmpx () from /lib/libc.so.6 #7 0x11a365 in _dl_catch_error () from /lib/ld-linux.so.2 #8 0x2ff900 in _dl_open () from /lib/libc.so.6 #9 0x13135e in _pam_token_returns () from /lib/libdl.so.2 #10 0x11a365 in _dl_catch_error () from /lib/ld-linux.so.2 #11 0x13194e in dlerror () from /lib/libdl.so.2 #12 0x13139b in dlopen () from /lib/libdl.so.2 #13 0x8148c67 in ap_os_dso_load () #14 0x8085f58 in load_module () #15 0x812b69e in invoke_cmd () #16 0x812c001 in ap_handle_command () #17 0x812c09d in ap_srm_command_loop () #18 0x812c769 in ap_process_resource_config () #19 0x812d0b0 in ap_read_config () #20 0x81378f3 in standalone_main () #21 0x813826c in main () #22 0x251a42 in __libc_start_main () from /lib/libc.so.6 Until I can get this working, I am running with the remote root exploit! Please help, thanks... -- Edit bug report at http://bugs.php.net/?id=15774&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15774&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15774&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15774&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15774&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15774&r=support Expected behavior: http://bugs.php.net/fix.php?id=15774&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15774&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15774&r=submittedtwice
Bug #15774 Updated: apache dies immediately after starting
ID: 15774 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: GNU/Linux Debian Potato PHP Version: 4.1.1 New Comment: There is nothing here to go on. If you could compile and run 4.1.1 you can compile and run 4.1.2. Nothing was changed that would cause this sort of problem. Your strace doesn't even touch anything in PHP. Check your build options for 4.1.1, compare them to what you are doing for 4.1.2. I suspect user-error here. Previous Comments: [2002-02-28 02:21:06] [EMAIL PROTECTED] This is actually php version 4.1.2 (there is no selection for that in this form). I've compiled a new version of apache 1.2.23 and PHP 4.1.2 and when I try to start apache it dies immediately without any errors in the error_log or anywhere else. I tried to strace the binary, but nothing showed up, with --enable-debug on, I get the following: zend_hash.c(532) : ht=0x081d8860 is already destroyed zend_hash.c(98) : Bailed out without a bailout address! in my error log. If I try to do a gdb back trace I get the following: (gdb) run -X Starting program: /usr/local/apache/bin/httpd_new -X Program exited with code 0377. (gdb) bt No stack. When I didn't have --enable-debug compiled in and I attempted to do a backtrace, I got the following: F10 key ==> File Edit Search Buffers Windows System Help Program received signal SIGSEGV, Segmentation fault. 0x28893e in malloc () from /lib/libc.so.6 crap, hold on exited gdb already :) I dont like having our webserver down for so long ok did the bt #0 0x28893e in malloc () from /lib/libc.so.6 #1 0x28987d in calloc () from /lib/libc.so.6 #2 0x11888e in _dl_new_object () from /lib/ld-linux.so.2 #3 0x1152e4 in _dl_map_object_from_fd () from /lib/ld-linux.so.2 #4 0x116d7b in _dl_map_object () from /lib/ld-linux.so.2 #5 0x1196ac in _dl_map_object_deps () from /lib/ld-linux.so.2 #6 0x2ff6e3 in getutmpx () from /lib/libc.so.6 #7 0x11a365 in _dl_catch_error () from /lib/ld-linux.so.2 #8 0x2ff900 in _dl_open () from /lib/libc.so.6 #9 0x13135e in _pam_token_returns () from /lib/libdl.so.2 #10 0x11a365 in _dl_catch_error () from /lib/ld-linux.so.2 #11 0x13194e in dlerror () from /lib/libdl.so.2 #12 0x13139b in dlopen () from /lib/libdl.so.2 #13 0x8148c67 in ap_os_dso_load () #14 0x8085f58 in load_module () #15 0x812b69e in invoke_cmd () #16 0x812c001 in ap_handle_command () #17 0x812c09d in ap_srm_command_loop () #18 0x812c769 in ap_process_resource_config () #19 0x812d0b0 in ap_read_config () #20 0x81378f3 in standalone_main () #21 0x813826c in main () #22 0x251a42 in __libc_start_main () from /lib/libc.so.6 Until I can get this working, I am running with the remote root exploit! Please help, thanks... -- Edit this bug report at http://bugs.php.net/?id=15774&edit=1
Bug #15736 Updated: Security Exploit
ID: 15736 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Unknown/Other Function Operating System: All UNIX PHP Version: 4.1.1 New Comment: ..and I take this back, it's fixed in CVS but not in any release. Previous Comments: [2002-02-28 02:11:04] [EMAIL PROTECTED] This bug has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php [2002-02-27 20:54:47] [EMAIL PROTECTED] The patch for file rfc1867.c applied to php 4.0.6 seems to not work when trying to upload from Opera 6.01 (on Windows). Uploading in Internet Explorer (6.0) seems to work allright, whereas uploading with Opera simply either times out or just fails (without any errors). [2002-02-26 13:41:58] [EMAIL PROTECTED] Well, the part of doing this before Apache demotes its priviledges doesn't sound feasible to me. Apache forks child processes as a non-privileged user. You can't get it to serve up a PHP request as root. And if you could, then why use a "high port" as you mentioned? We will however have a fix for the file upload buffer overflow shortly. In the meantime, simply turn off file uploads in your php.ini file to protect yourself against this. [2002-02-26 13:34:46] [EMAIL PROTECTED] I am trying to get the source code, or at least an strace of the binary used for this exploit. [2002-02-26 13:31:53] [EMAIL PROTECTED] There's a security exploit for php that gives you remote root by binding a rootshell to a high port. Exploits php before apache demotes its privledges. Looks like it uses the POST method. Buffer overflow. I don't have the program (binary) available as a friend of mine had limited access to it. BUt it affect ALL versions of php. -- Edit this bug report at http://bugs.php.net/?id=15736&edit=1
Bug #15774 Updated: apache dies immediately after starting
ID: 15774 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Reproducible crash Operating System: GNU/Linux Debian Potato PHP Version: 4.1.1 New Comment: This is what I am using for my apache configuration: ./configure \ --prefix=/usr/local/apache \ --enable-module=unique_id \ --enable-module=rewrite \ --enable-module=speling \ --enable-module=expires \ --enable-module=info \ --enable-module=log_agent \ --enable-module=log_referer \ --enable-module=so \ --logfiledir=/var/log/apache \ --activate-module=src/modules/php4/libphp4.a \ --enable-module=vhost_alias This is what I am using for my php configuration: ./configure \ --prefix=/usr/local/php \ --with-apache=../apache_1.3.23 \ --enable-ftp \ --with-xml \ --enable-track-vars \ --with-mysql=/usr/local/mysql \ --with-pgsql=/usr/local/pgsql/ \ --enable-debug \--with-config-file-path=/usr/local/php/lib also, ran gdb and did a little poking around: (gdb) br zend_hash_destroy Breakpoint 1 at 0x813a7c3: file zend_hash.c, line 532. (gdb) r -X Starting program: /usr/local/apache/bin/httpd_new -X Breakpoint 1, zend_hash_destroy (ht=0x81e8ce0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81edb20) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81e9c9c) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81d8c60) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea7b4) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea788) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) d Delete all breakpoints? (y or n) n (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059b8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059e8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) watch 0x081d8860 Watchpoint 2: 136153184 (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d58) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d84) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x820e8b0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) clear zend_hash_destroy Deleted breakpoint 1 (gdb) c Continuing. Program exited with code 0377. (gdb) quit Previous Comments: [2002-02-28 02:24:48] [EMAIL PROTECTED] There is nothing here to go on. If you could compile and run 4.1.1 you can compile and run 4.1.2. Nothing was changed that would cause this sort of problem. Your strace doesn't even touch anything in PHP. Check your build options for 4.1.1, compare them to what you are doing for 4.1.2. I suspect user-error here. [2002-02-28 02:21:06] [EMAIL PROTECTED] This is actually php version 4.1.2 (there is no selection for that in this form). I've compiled a new version of apache 1.2.23 and PHP 4.1.2 and when I try to start apache it dies immediately without any errors in the error_log or anywhere else. I tried to strace the binary, but nothing showed up, with --enable-debug on, I get the following: zend_hash.c(532) : ht=0x081d8860 is already destroyed zend_hash.c(98) : Bailed out without a bailout address! in my error log. If I try to do a gdb back trace I get the following: (gdb) run -X Starting program: /usr/local/apache/bin/httpd_new -X Program exited with code 0377. (gdb) bt No stack. When I didn't have --enable-debug compiled in and I attempted to do a backtrace, I got the following: F10 key ==> File Edit Search Buffers Windows System Help Program received signal SIGSEGV, Segmentation fault. 0x28893e in malloc () from /lib/libc.so.6 crap, hold on exited gdb already :) I dont like having our webserver down for so long ok did the bt #0 0x28893e in malloc () from /lib/libc.so.6 #1 0x28987d in calloc () from /lib/libc.so.6 #2 0x11888e in _dl_new_object () from /lib/ld-linux.so.2 #3 0x1152e4 in _dl_map_object_from_fd () from /lib/ld-linux.so.2 #4 0x116d7b in _dl_map_object () from /lib/ld-linux.so.2 #5 0x1196ac in _dl_map_object_deps () from /lib/ld-linux.so.2 #6 0x2ff6e3 in getutmpx ()
Bug #15774 Updated: apache dies immediately after starting
ID: 15774 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Reproducible crash Operating System: GNU/Linux Debian Potato -PHP Version: 4.1.1 +PHP Version: 4.1.2 New Comment: Actually, I was running 4.0.6 before this upgrade, not 4.1.1, but I did use the same configuration options that I used from 4.0.6 (I always save my ./configure options so that I can recreate them). Previous Comments: [2002-02-28 02:43:31] [EMAIL PROTECTED] This is what I am using for my apache configuration: ./configure \ --prefix=/usr/local/apache \ --enable-module=unique_id \ --enable-module=rewrite \ --enable-module=speling \ --enable-module=expires \ --enable-module=info \ --enable-module=log_agent \ --enable-module=log_referer \ --enable-module=so \ --logfiledir=/var/log/apache \ --activate-module=src/modules/php4/libphp4.a \ --enable-module=vhost_alias This is what I am using for my php configuration: ./configure \ --prefix=/usr/local/php \ --with-apache=../apache_1.3.23 \ --enable-ftp \ --with-xml \ --enable-track-vars \ --with-mysql=/usr/local/mysql \ --with-pgsql=/usr/local/pgsql/ \ --enable-debug \--with-config-file-path=/usr/local/php/lib also, ran gdb and did a little poking around: (gdb) br zend_hash_destroy Breakpoint 1 at 0x813a7c3: file zend_hash.c, line 532. (gdb) r -X Starting program: /usr/local/apache/bin/httpd_new -X Breakpoint 1, zend_hash_destroy (ht=0x81e8ce0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81edb20) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81e9c9c) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81d8c60) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea7b4) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea788) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) d Delete all breakpoints? (y or n) n (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059b8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059e8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) watch 0x081d8860 Watchpoint 2: 136153184 (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d58) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d84) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x820e8b0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) clear zend_hash_destroy Deleted breakpoint 1 (gdb) c Continuing. Program exited with code 0377. (gdb) quit [2002-02-28 02:24:48] [EMAIL PROTECTED] There is nothing here to go on. If you could compile and run 4.1.1 you can compile and run 4.1.2. Nothing was changed that would cause this sort of problem. Your strace doesn't even touch anything in PHP. Check your build options for 4.1.1, compare them to what you are doing for 4.1.2. I suspect user-error here. [2002-02-28 02:21:06] [EMAIL PROTECTED] This is actually php version 4.1.2 (there is no selection for that in this form). I've compiled a new version of apache 1.2.23 and PHP 4.1.2 and when I try to start apache it dies immediately without any errors in the error_log or anywhere else. I tried to strace the binary, but nothing showed up, with --enable-debug on, I get the following: zend_hash.c(532) : ht=0x081d8860 is already destroyed zend_hash.c(98) : Bailed out without a bailout address! in my error log. If I try to do a gdb back trace I get the following: (gdb) run -X Starting program: /usr/local/apache/bin/httpd_new -X Program exited with code 0377. (gdb) bt No stack. When I didn't have --enable-debug compiled in and I attempted to do a backtrace, I got the following: F10 key ==> File Edit Search Buffers Windows System Help Program received signal SIGSEGV, Segmentation fault. 0x28893e in malloc () from /lib/libc.so.6 crap, hold on exited gdb already :) I dont like having our webserver down for so long ok did the bt #0 0x28893e in malloc () from /lib/libc.so.6 #1 0x
Bug #15774 Updated: apache dies immediately after starting
ID: 15774 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Reproducible crash Operating System: GNU/Linux Debian Potato PHP Version: 4.1.2 New Comment: Did some more poking in gdb: (gdb) br zend_hash_destroy Breakpoint 1 at 0x813a7c3: file zend_hash.c, line 532. (gdb) r -X Starting program: /usr/local/apache/bin/httpd_new -X Breakpoint 1, zend_hash_destroy (ht=0x81e8ce0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81edb20) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81e9c9c) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81d8c60) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea7b4) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea788) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) d Delete all breakpoints? (y or n) n (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059b8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059e8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) watch 0x081d8860 Watchpoint 2: 136153184 (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d58) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d84) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x820e8b0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) clear zend_hash_destroy Deleted breakpoint 1 (gdb) c Continuing. Program exited with code 0377. (gdb) quit Not a very useful error... if this is user error, it isn't very obvious what is wrong. Previous Comments: [2002-02-28 02:50:07] [EMAIL PROTECTED] Actually, I was running 4.0.6 before this upgrade, not 4.1.1, but I did use the same configuration options that I used from 4.0.6 (I always save my ./configure options so that I can recreate them). [2002-02-28 02:43:31] [EMAIL PROTECTED] This is what I am using for my apache configuration: ./configure \ --prefix=/usr/local/apache \ --enable-module=unique_id \ --enable-module=rewrite \ --enable-module=speling \ --enable-module=expires \ --enable-module=info \ --enable-module=log_agent \ --enable-module=log_referer \ --enable-module=so \ --logfiledir=/var/log/apache \ --activate-module=src/modules/php4/libphp4.a \ --enable-module=vhost_alias This is what I am using for my php configuration: ./configure \ --prefix=/usr/local/php \ --with-apache=../apache_1.3.23 \ --enable-ftp \ --with-xml \ --enable-track-vars \ --with-mysql=/usr/local/mysql \ --with-pgsql=/usr/local/pgsql/ \ --enable-debug \--with-config-file-path=/usr/local/php/lib also, ran gdb and did a little poking around: (gdb) br zend_hash_destroy Breakpoint 1 at 0x813a7c3: file zend_hash.c, line 532. (gdb) r -X Starting program: /usr/local/apache/bin/httpd_new -X Breakpoint 1, zend_hash_destroy (ht=0x81e8ce0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81edb20) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81e9c9c) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81d8c60) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea7b4) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea788) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) d Delete all breakpoints? (y or n) n (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059b8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059e8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) watch 0x081d8860 Watchpoint 2: 13615
Bug #15772 Updated: PHP is developed and maintained by morons
ID: 15772
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: *General Issues
Operating System: all
PHP Version: 4.0.6
New Comment:
Your claims are simply wrong.
Not a single str* function is able to read beyond the
buffer, cause the buffer is '\0' terminated and
strcmp/strcasecmp whatever will stop there.
Previous Comments:
[2002-02-27 23:42:47] [EMAIL PROTECTED]
Fine by me, but the problems are not fixed in CVS. You asked me for
more specifics, I gave them to you.
[2002-02-27 23:34:49] [EMAIL PROTECTED]
The specific memchr()+1 issue is fixed in CVS which was the only useful
part of this bug report. We close bugs when they are fixed in CVS, not
when we ship releases.
[2002-02-27 23:20:44] [EMAIL PROTECTED]
It what way is it "fixed"? Every PHP user in the entire world is going
to have to download the patches from www.php.net to fix the security
hole, and those patches contain this bug. I know that it is fixed in
CVS in that the entire file has been replaced, but as I understand it
there is no fixed release version.
As to the other bugs, just look at the main while() loop in
php_mime_split(). Pretty much every call to str* functions (including
the very first one) are reading beyond the end of the buffer. If this
happens, 'rem' may become negative and even more excitement ensues.
[2002-02-27 22:55:48] [EMAIL PROTECTED]
True, that bit of code made no sense and has been fixed. The entire
thing has been reworked for the 4.2 tree, but if you could expand on
the muriad of buffer overflows aside from the memchr()+1 mixup, and
submit a useful bug report it would be appreciated.
[2002-02-27 21:40:17] [EMAIL PROTECTED]
Dear morons,
Please observe the following two lines from the 'fix' you have posted
for your file-upload incompetence:
loc = (char *) memchr(ptr, '\n', rem)+1;
if (!loc) {
There's a bug in this code. Can you see what it is? Hint: the 'if'
expression will never evaluate true. Well, that's assuming the first
line doesn't crash since it invokes undefined behaviour.
Hint #2: the whole routine (not just those 2 lines) is still completely
and utterly broken as of revision 1.71.2.2. It is riddled with code
that reads beyond the end of the buffer.
Hint #3: yet again, you need to follow-up to your Bugtraq posting with
a message saying 'Not only were we too stupid to write the code right
in the first place, we were too stupid to fix it right too. Please
ignore our previous patch. Please use this new one, which will probably
be wrong also.'
HTH, HAND.
--
Edit this bug report at http://bugs.php.net/?id=15772&edit=1
Bug #15774 Updated: apache dies immediately after starting
ID: 15774 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Feedback Bug Type: Reproducible crash Operating System: GNU/Linux Debian Potato PHP Version: 4.1.2 New Comment: Reopened. You have something wrong. Exit code 0377 is actually a 255(or -1). Apache is exiting without proper exit code set, most likely. I suggest to get rid of module one by one and locate which module is offending module and let us know. Previous Comments: [2002-02-28 02:52:35] [EMAIL PROTECTED] Did some more poking in gdb: (gdb) br zend_hash_destroy Breakpoint 1 at 0x813a7c3: file zend_hash.c, line 532. (gdb) r -X Starting program: /usr/local/apache/bin/httpd_new -X Breakpoint 1, zend_hash_destroy (ht=0x81e8ce0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81edb20) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81e9c9c) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81d8c60) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea7b4) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea788) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) d Delete all breakpoints? (y or n) n (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059b8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x82059e8) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) watch 0x081d8860 Watchpoint 2: 136153184 (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d58) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x8205d84) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x820e8b0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) clear zend_hash_destroy Deleted breakpoint 1 (gdb) c Continuing. Program exited with code 0377. (gdb) quit Not a very useful error... if this is user error, it isn't very obvious what is wrong. [2002-02-28 02:50:07] [EMAIL PROTECTED] Actually, I was running 4.0.6 before this upgrade, not 4.1.1, but I did use the same configuration options that I used from 4.0.6 (I always save my ./configure options so that I can recreate them). [2002-02-28 02:43:31] [EMAIL PROTECTED] This is what I am using for my apache configuration: ./configure \ --prefix=/usr/local/apache \ --enable-module=unique_id \ --enable-module=rewrite \ --enable-module=speling \ --enable-module=expires \ --enable-module=info \ --enable-module=log_agent \ --enable-module=log_referer \ --enable-module=so \ --logfiledir=/var/log/apache \ --activate-module=src/modules/php4/libphp4.a \ --enable-module=vhost_alias This is what I am using for my php configuration: ./configure \ --prefix=/usr/local/php \ --with-apache=../apache_1.3.23 \ --enable-ftp \ --with-xml \ --enable-track-vars \ --with-mysql=/usr/local/mysql \ --with-pgsql=/usr/local/pgsql/ \ --enable-debug \--with-config-file-path=/usr/local/php/lib also, ran gdb and did a little poking around: (gdb) br zend_hash_destroy Breakpoint 1 at 0x813a7c3: file zend_hash.c, line 532. (gdb) r -X Starting program: /usr/local/apache/bin/httpd_new -X Breakpoint 1, zend_hash_destroy (ht=0x81e8ce0) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81edb20) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) n 534 SET_INCONSISTENT(HT_IS_DESTROYING); (gdb) 536 p = ht->pListHead; (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81e9c9c) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81d8c60) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea7b4) at zend_hash.c:532 532 IS_CONSISTENT(ht); (gdb) c Continuing. Breakpoint 1, zend_hash_destroy (ht=0x81ea788)
