#17302 [Fbk->NoF]: can't pass result sets between functions
ID: 17302
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: MSSQL related
Operating System: W2K
PHP Version: 4.2.1
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-12-03 13:53:44] [EMAIL PROTECTED]
Two lines from your sample code indicates that you are calling
'get_company_list' but the function is named 'get_company_db'. Could
this be the problem ?
[2002-05-17 23:08:42] [EMAIL PROTECTED]
Using PHP 4.2.1 on Apache in W2K, connecting to MSSQL7 also on W2K. The
db connection seems to work fine and I get data returned. The problem
is when I try to split the data retrieval in one function, and then
pass the result set back to another script. No data gets returned and
my script hangs for a while. If I run the retrieval in-line with the
display script, things are fine.
//* Does work *//
$conn = db_connect_user();
if ($conn==false)
return false;
$result = mssql_query("select id, name, db_name
from rm_company", $conn);
//Loop through and gather the info about the orders for this customer
$count = mssql_num_rows($result);
for($i = 0; $i < $count; $i++) {
$company_list[$i][0]=mssql_result($result,$i,0);
$company_list[$i][1]=mssql_result($result,$i,1);
$company_list[$i][2]=mssql_result($result,$i,2);
}
if(!($company_list==false))
{
$list_count = count($company_list);
// etc.
**
//*Does not work*//
..top of script..
$company_list = get_company_list();
if(!($company_list==false))
{
$list_count = count($company_list);
..further down script/in another script (have tried both)..
function get_company_db()
{ $conn = db_connect_user();
if ($conn==false)
return false;
$result = mssql_query("select id, name, db_name
from rm_company", $conn);
if (!$result)
return false; // not found
else if (mssql_num_rows($result)==0)
return false; // no orders found
else
{
//Loop through and gather the info about the orders for this
customer
{
$count = mssql_num_rows($result);
for($i = 0; $i < $count; $i++) {
$company_list[$i][0]=mssql_result($result,$i,0);
$company_list[$i][1]=mssql_result($result,$i,1);
$company_list[$i][2]=mssql_result($result,$i,2);
}
}
return $company_list;
}
}
--
Edit this bug report at http://bugs.php.net/?id=17302&edit=1
#21091 [Opn]: undefined reference to `ssl_onceonlyinit'
ID: 21091 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IMAP related Operating System: Debian Woody PHP Version: 4.3.0RC3 New Comment: Configuring PHP with: ./configure --prefix=/usr --sysconfdir=/etc --with-apxs2 --with-config-file-path=/etc --with-pear=/usr/share/pear --with-openssl --with-zlib --with-bz2 --with-dom --with-dom-xslt --enable-exif --enable-ftp --with-gd --with-gettext --with-iconv --with-imap --with-imap-ssl --with-mcrypt --with-mysql --with-pcntl --with-pgsql --with-pspell --enable-trans-sid The compilation fails when it tries to compile the IMAP support, complaining about: ext/imap/php_imap.lo: In function `zm_startup_imap': /home/users/jon/src/php4/ext/imap/php_imap.c:424: undefined reference to `ssl_onceonlyinit' collect2: ld returned 1 exit status I can get it to compile by going into the file and commenting out that line, but I don't know what effect that's going to have on stability. Previous Comments: [2002-12-18 23:17:12] [EMAIL PROTECTED] Configuring PHP with: ./configure --prefix=/usr --sysconfdir=/etc --with-apxs2 --with-config-file-path=/etc --with-pear=/usr/share/pear --with-openssl --with-zlib --with-bz2 --with-dom --with-dom-xslt --enable-exif --enable-ftp --with-gd --with-gettext --with-iconv --with-imap --with-imap-ssl --with-mcrypt --with-mysql --with-pcntl --with-pgsql --with-pspell --enable-trans-sid The compilation fails when it tries to compile the IMAP support, complaining about: ext/imap/php_imap.lo: In function `zm_startup_imap': /home/users/jon/src/php4/ext/imap/php_imap.c:424: undefined reference to `ssl_onceonlyinit' collect2: ld returned 1 exit status I have installed the version of c-client using apt-get, so I assume I'm using a fairly recent version of c-client. -- Edit this bug report at http://bugs.php.net/?id=21091&edit=1
#21091 [NEW]: undefined reference to `ssl_onceonlyinit'
From: [EMAIL PROTECTED] Operating system: Debian Woody PHP version: 4.3.0RC3 PHP Bug Type: IMAP related Bug description: undefined reference to `ssl_onceonlyinit' Configuring PHP with: ./configure --prefix=/usr --sysconfdir=/etc --with-apxs2 --with-config-file-path=/etc --with-pear=/usr/share/pear --with-openssl --with-zlib --with-bz2 --with-dom --with-dom-xslt --enable-exif --enable-ftp --with-gd --with-gettext --with-iconv --with-imap --with-imap-ssl --with-mcrypt --with-mysql --with-pcntl --with-pgsql --with-pspell --enable-trans-sid The compilation fails when it tries to compile the IMAP support, complaining about: ext/imap/php_imap.lo: In function `zm_startup_imap': /home/users/jon/src/php4/ext/imap/php_imap.c:424: undefined reference to `ssl_onceonlyinit' collect2: ld returned 1 exit status I have installed the version of c-client using apt-get, so I assume I'm using a fairly recent version of c-client. -- Edit bug report at http://bugs.php.net/?id=21091&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21091&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21091&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21091&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21091&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21091&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21091&r=support Expected behavior: http://bugs.php.net/fix.php?id=21091&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21091&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21091&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21091&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21091&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21091&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21091&r=isapi
#21072 [Com]: php not working for other folders other than the root
ID: 21072 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache2 related Operating System: win2k + SP3 PHP Version: 4.2.3 New Comment: lol, it was from php actually , I changed in php.ini doc_root="C:/program files/apche group/apache2/htdocs/" to blanc doc_root= and php start to work on my gallery folder, but I am concerned about security Previous Comments: [2002-12-18 03:34:41] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. [2002-12-17 23:48:24] [EMAIL PROTECTED] i create an alias for gallery folder in htpdconf like this Alias /gallery "C:/gallery" AllowOverride Options FileInfo Order allow,deny Allow from all and when I am trying to access phpinfo.php (http://IP/gallery/setup/phpinfo.php) which is in c:/gallery/setup/phpinfo.php it ggives me this error in error log file PHP Fatal error: Unable to open C:/Program Files/Apache Group/Apache2/htdocs/gallery/setup/phpinfo.php in Unknown on line 0 if i try to access the same file from htdocs everything works perfect, I dont understand why its not workin for the gallery folder! -- Edit this bug report at http://bugs.php.net/?id=21072&edit=1
#16521 [Com]: file() - incorrect behavior (line endings ignored) on files with Mac EOLN (CR)
ID: 16521 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Filesystem function related Operating System: FreeBSD 4.5-Stable PHP Version: 4.1.2 New Comment: is there a work around for this? just some way to go through the array containing the file, line by line. Im using PHP 4.2.2 Previous Comments: [2002-09-23 13:36:48] [EMAIL PROTECTED] Fixed in HEAD. Please try a non-stable snapshot and set the new ini option auto_detect_line_endings=on in your php.ini/apache.conf. The fix will be in 4.3. --Wez. PS: You might have to wait a couple of hours for this change to appear on http://snaps.php.net [2002-06-14 13:46:42] [EMAIL PROTECTED] This seems critical as this is such a commonly used function. (and Derick promised it would be fixed by 4.3.0 :) [2002-04-09 23:13:59] [EMAIL PROTECTED] In PHP 4.1.2 (and 4.2.0-dev) Calling file() on a 4-line text file with Macintosh line endings (CR) results in a 1-element array: file: (file.txt) blah test three four Code: $array = file( 'file.txt. ); echo count( $array ); >> Returns '1' (Verified by print_r) file() is ignoring the line endings, but the correct result happens for files with Windows (CRLF) and Unix (LF) line endings. -- Edit this bug report at http://bugs.php.net/?id=16521&edit=1
#21089 [NEW]: mssql_bind not returning output parameters from stored procedure call
From: [EMAIL PROTECTED] Operating system: Windows 2000 Server SP3 PHP version: 4.3.0RC3 PHP Bug Type: MSSQL related Bug description: mssql_bind not returning output parameters from stored procedure call Making use of mssql_bind to retrieve output parameters from a stored procedure in MSSQL7 always return 0 when PHP operates in ISAPI or CGI mode under IIS5. It was noted that although it didn't return the parameter, however it is able to accept input parameters. It is also returning the query result. Just not the output parameter. It work fine in PHP4.23 when it is run on CGI mode. Did not test if ISAPI works though. -- Edit bug report at http://bugs.php.net/?id=21089&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21089&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21089&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21089&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21089&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21089&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21089&r=support Expected behavior: http://bugs.php.net/fix.php?id=21089&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21089&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21089&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21089&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21089&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21089&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21089&r=isapi
#21085 [Bgs]: allow_url_fopen is on be default.
ID: 21085 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: ALL PHP Version: 4.3.0RC3 New Comment: Agreed. However we live in a world where people aren't reading every single piece of every single package they install. Sure, anyone can shoot themselves in the foot. Sure, you can code poorly. But should this particular "feature" be on by default instead of turned on? If they turn it on, they know what they're doing. If they just drop the packages in...well, why make it easy to exploit? (Case in point - friend of mine who's not a total newbie got hacked this way.) IMHO, the default package should be as "dummy proof" as possible and able to be opened up from there. However, it's not up to me.. -Mike Previous Comments: [2002-12-18 15:41:09] [EMAIL PROTECTED] It's really up to the user to validate input from the outside. You can always shoot yourself in the foot if you want to. There is no valid reason to change this default. [2002-12-18 15:34:31] [EMAIL PROTECTED] PHP by default allows include() calls which contain URL/URI strings. register_globals=on include($somevar/file.php); // real site code exploit by overriding $somevar to http://badsite.evilcode.com where file.php is This causes the "real site" to execute the $cmd command passed in on the URL/URI string. Requesting that allow_url_fopen be set to "Off" for future releases and a documentation note made about the caveat. -Mike -- Edit this bug report at http://bugs.php.net/?id=21085&edit=1
#21088 [Opn]: Pspell breaks connecting to mysql using localhost
ID: 21088
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Pspell related
Operating System: Linux 2.4
PHP Version: 4.3.0RC3
New Comment:
// Where it says:
On the other hand if I change the line to:
mysql_connect("66.139.73.7", "root", "x");
The error message is:
// it should say:
On the other hand if I change the line to:
mysql_connect("66.139.73.7", "root", "x");
I can connect to the database successfully...
The error message when using "localhost" is:
// Sorry for the mixup
Previous Comments:
[2002-12-18 19:22:26] [EMAIL PROTECTED]
Here is my configure line:
./configure --with-mysql=/usr/local/mysql \
--with-pspell \
--with-xml \
--with-apxs2=/usr/local/apache2/bin/apxs \
--enable-track-vars \
--with-gd \
--with-freetype-dir=/usr \
--enable-gd-native-ttf \
--enable-gd-imgstrttf \
--with-jpeg-dir=/usr \
--with-png-dir=/usr \
--with-zlib
The perpetrating line is :
mysql_connect("localhost", "root", "x");
// this is NOT my server password
On the other hand if I change the line to:
mysql_connect("66.139.73.7", "root", "x");
The error message is:
Warning: mysql_connect() [function.mysql-connect]: Can't connect to
local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) in
/home/melwakil/web/QueryClass.php on line 9
After doing a make distclean and reinstalling php without with-pspell
on the command line, it connects fine.
--
Edit this bug report at http://bugs.php.net/?id=21088&edit=1
#21088 [NEW]: Pspell breaks connecting to mysql using localhost
From: [EMAIL PROTECTED]
Operating system: Linux 2.4
PHP version: 4.3.0RC3
PHP Bug Type: Pspell related
Bug description: Pspell breaks connecting to mysql using localhost
Here is my configure line:
./configure --with-mysql=/usr/local/mysql \
--with-pspell \
--with-xml \
--with-apxs2=/usr/local/apache2/bin/apxs \
--enable-track-vars \
--with-gd \
--with-freetype-dir=/usr \
--enable-gd-native-ttf \
--enable-gd-imgstrttf \
--with-jpeg-dir=/usr \
--with-png-dir=/usr \
--with-zlib
The perpetrating line is :
mysql_connect("localhost", "root", "x");
// this is NOT my server password
On the other hand if I change the line to:
mysql_connect("66.139.73.7", "root", "x");
The error message is:
Warning: mysql_connect() [function.mysql-connect]: Can't connect to local
MySQL server through socket '/var/lib/mysql/mysql.sock' (2) in
/home/melwakil/web/QueryClass.php on line 9
After doing a make distclean and reinstalling php without with-pspell on
the command line, it connects fine.
--
Edit bug report at http://bugs.php.net/?id=21088&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21088&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21088&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21088&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21088&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21088&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21088&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21088&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21088&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21088&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21088&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21088&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21088&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21088&r=isapi
#21087 [NEW]: Rewriting file no longer works
From: [EMAIL PROTECTED] Operating system: XP PHP version: 4.3.0RC3 PHP Bug Type: Filesystem function related Bug description: Rewriting file no longer works This is just a heads up. I can reproduce it but can't figure out why. I have a guestbook script that I wrote (KISGB) and it works perfectly under all prior to 4.3.x versions. However, 4.3.0RC3 (don't know about previous RC's) will not recreate the file. Basically the script is trying to rewrite a configuration file. It fails every time (writing out a file of zero length) but I can't find anything on the logs. As soon as I restore a previous non 4.2.3x release, it works flawlessly. I will continue to try to produce a smaller script to replicate it, but it will fail 100% of the time under 4.3.0. I will also add that the script is a phpNUKE module, so it is operating within that framework. It is a flat file, not a MySQL table. -- Edit bug report at http://bugs.php.net/?id=21087&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21087&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21087&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21087&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21087&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21087&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21087&r=support Expected behavior: http://bugs.php.net/fix.php?id=21087&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21087&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21087&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21087&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21087&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21087&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21087&r=isapi
#18169 [Com]: Driver cannot deliver UCS-2 unicode to SQL Server
ID: 18169
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: MSSQL related
Operating System: Windows 2000 Server
PHP Version: 4.1.2
New Comment:
If you're using PHP on a Windows platform you can use the PHP COM
extension to communicate with SQL Server via ADO. The PHP COM
extension is capable of translating UTF-8 to UCS-2 and back if you
specify so as the third parameter:
$oDb = new COM('ADODB.Connection', NULL, CP_UTF8);
This way you can use Unicode UTF-8 within PHP and Unicode UCS-2 within
SQL Server with all the translations done for you automatically.
HTH, Freddy Vulto
Previous Comments:
[2002-07-06 07:08:48] [EMAIL PROTECTED]
Thanks Marko
-I guess this means that if you are to use binary (ie. unicode) data,
then COM/ADO is your only option, if SQL Server is the database of your
choice.
>From yohgaki's answer, I guess also the multibyte encoding
functionality lacks proper Unicode support -am I correct in assuming
that we will have to move to PHP4.2.x and do our own encoding/decoding
through the Win32 API then?
[2002-07-05 05:34:22] [EMAIL PROTECTED]
PHP's mssql extension uses the Microsoft SQL Server's C
API, the "DB-Library for C". Specifically, SQL queries are
sent to the server using the dbcmd() function. This
function is not binary safe, so inserting UCS2 text or
images or any binary data is likely to fail.
The DB-Library for C has separate, binary-safe APIs for
entering text and images, but they are complicated and
difficult to seamlessly integrate to the current mssql
extension. Look up the documentation for dbwritetext() if
you feel like implementing this change.
UTF-8 and UTF-7 are, IIRC, the only Unicode encoding that
are guaranteed not to include null characters. They are,
therefore, the only encodings that can be reliably used
with PHP's mssql extension at this time.
[2002-07-05 04:21:52] [EMAIL PROTECTED]
You are probably right. However, Unicode is central to making
world-wide web applications, and all major database vendors have this
posibility.
I find it to be a hindrance to wider deployment of large-scale,
worldwide php applications.
Does anyone know if it is only the MSSQL module? -are there any plans
to look into this issue?
What are the future directions for PHP and Unicode support?
[2002-07-05 04:14:38] [EMAIL PROTECTED]
Wide char encoding, UCS2/UCS4/UTF16/UTF32, don't work well with current
PHP. I guess SQL Server module is using strlen() or like, that cannot
be used with wide char...
Fixing this is not simple at all.
[2002-07-04 18:10:24] [EMAIL PROTECTED]
I have a problem converting UTF-8 (web character encoding) to UCS2
(Microsoft Windows character encoding) using PHP, and storing this in
the Microsoft SQL Server 2000 database.
My setup is:
Windows 2000 Server, with Apache 1.3.24/PHP 4.1.1 and Microsoft SQL
Server 2000
Now, as a result of Microsofts Q232580, I will have to do conversion
between UTF-8 and UCS-2. For this, I thought I would use the Multibyte
String functions.
However, this does not seem to work.
I am absolutely sure, that I input UTF-8 encoded data into my string,
and then I do:
$ucs2string=mb_convert_encoding($string,"UCS2","UTF-8");
$sqlStmt="insert into testtbl (tekst) values(N'".($ucs2string)."')";
$rs=$DBCon->Execute($sqlStmt);
When I access the database, then I will see something stored, that does
not resemble the input at all (most times, I see Japanese/Chinese
characters?!??). Furthermore, the insert sometimes comes up with an
error, and consequently stores nothing.
To me, it seems like either one of these (or both) are flawed:
1. the Multibyte String encoding funtion does not work properly (ie.
encoding from UTF-8 to UCS-2 does not happen correctly).
2. The PHP MSSQL driver does not handle unicode data properly, even
though the target column in the database is specified as Unicode and N
is prepended to the string before insert.
This leads me to use ADO (as in the example above), storing UTF-8
encoded data into SQL Server -this is a very short term solution, as
data are not sortable in the database (some of it looks like garbage
because of the
missing encoding).
--
Edit this bug report at http://bugs.php.net/?id=18169&edit=1
#20539 [Csd->Opn]: PHP CLI Segmentation Fault
ID: 20539 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4CVS-2002-11-21 (stable) New Comment: The patch was reverted. Reopening until a better fix is devised. Previous Comments: [2002-12-11 04:25:48] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-09 06:09:00] [EMAIL PROTECTED] Date: Thu, 28 Nov 2002 19:38:38 +0100 (CET) From: Sascha Schumann <[EMAIL PROTECTED]> To: Edin Kadribasic <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Patch for bug #20539 On Thu, 28 Nov 2002, Edin Kadribasic wrote: > Forget the patch, its not working well. The problem is that with > session autostart SID constant gets defined in rinit and gets > destroyed twice. Yes, that's why I don't like to rely on internals of something which should be a black box. The constants API needs an interface for deleting entries. - Sascha [2002-11-28 03:55:05] [EMAIL PROTECTED] This crash happens when php.ini (or php-cli.ini :) contains 'session.auto_start = 1' AND 'magic_quotes_gpc = On' [2002-11-28 02:46:31] [EMAIL PROTECTED] I can't tell. Is php.ini loaded if php-cli.ini doesn't exists by default ? [2002-11-28 02:32:59] [EMAIL PROTECTED] Is that php.ini loaded by php then when this crash happens? 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/20539 -- Edit this bug report at http://bugs.php.net/?id=20539&edit=1
#21085 [Opn->Bgs]: allow_url_fopen is on be default.
ID: 21085 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: ALL PHP Version: 4.3.0RC3 New Comment: It's really up to the user to validate input from the outside. You can always shoot yourself in the foot if you want to. There is no valid reason to change this default. Previous Comments: [2002-12-18 15:34:31] [EMAIL PROTECTED] PHP by default allows include() calls which contain URL/URI strings. register_globals=on include($somevar/file.php); // real site code exploit by overriding $somevar to http://badsite.evilcode.com where file.php is This causes the "real site" to execute the $cmd command passed in on the URL/URI string. Requesting that allow_url_fopen be set to "Off" for future releases and a documentation note made about the caveat. -Mike -- Edit this bug report at http://bugs.php.net/?id=21085&edit=1
#21085 [NEW]: allow_url_fopen is on be default.
From: [EMAIL PROTECTED] Operating system: ALL PHP version: 4.3.0RC3 PHP Bug Type: Unknown/Other Function Bug description: allow_url_fopen is on be default. PHP by default allows include() calls which contain URL/URI strings. register_globals=on include($somevar/file.php); // real site code exploit by overriding $somevar to http://badsite.evilcode.com where file.php is This causes the "real site" to execute the $cmd command passed in on the URL/URI string. Requesting that allow_url_fopen be set to "Off" for future releases and a documentation note made about the caveat. -Mike -- Edit bug report at http://bugs.php.net/?id=21085&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21085&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21085&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21085&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21085&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21085&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21085&r=support Expected behavior: http://bugs.php.net/fix.php?id=21085&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21085&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21085&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21085&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21085&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21085&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21085&r=isapi
#20441 [Bgs->Ctl]: PHP_AUTH_USER isn't set
ID: 20441 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Critical Bug Type: Apache related Operating System: all PHP Version: 4.3.0-pre2 New Comment: This needs to be fixed before 4.3 goes out. While it is of course important to improve the code and iron out long standing errors, we must not forget that our users rely on the old behaviour. The default behaviour of 4.3 should be the same as in old versions. Previous Comments: [2002-12-18 13:29:19] [EMAIL PROTECTED] This problem has just caused me a big headache - a customer has been relying on the fact that both .htaccess and PHP_AUTH_USER have been available in parallel since at least PHP 4. They've asked me to fix their scripts, but it would be a massive rewrite to sort out. I only have two customers who do their own scripting, and 50% of them are bitten by this. I think that 4.3.0 may well annoy lots of people with this. I can see from the documentation of bug #19251 why the change has been made, and I understand that that the manual documents the new behaviour, but I suspect this misbehaviour is widely relied upon, and perhaps we should consider an php.ini switch. The only economic solution I can suggest for my customer in the meanwhile is for me to patch php back to its old behaviour. [2002-12-11 10:58:19] [EMAIL PROTECTED] We fixed a bug, period. Derick [2002-12-11 10:53:53] [EMAIL PROTECTED] Can someone explain this? Apparently some external auth systems did not populate PHP_AUTH_USER while others did... Was this BC break discussed? It has been documented forever but this behavior changed so please explain it. [2002-12-11 10:39:14] [EMAIL PROTECTED] I agree with the previous poster that this is a serious bug. When we upgraded to 4.3.0RC2 our development application broke. [2002-11-22 02:40:55] [EMAIL PROTECTED] This is not bogus!! This is a genuine bug. PHP_AUTH_USER was set in 4.2.3 why has the functionality been changed without warning? This will break so many peoples scripts it is not true. This *HAS TO BE FIXED* os that it works as it did before. Please stop trying to pretend that this is not a bug. It is, and a serious one at that. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20441 -- Edit this bug report at http://bugs.php.net/?id=20441&edit=1
#21084 [NEW]: Undefined symbol "___guard" in libphp4.so
From: [EMAIL PROTECTED] Operating system: OpenBSD PHP version: 4.3.0RC3 PHP Bug Type: Apache2 related Bug description: Undefined symbol "___guard" in libphp4.so OS : OpenBSD-current Platform : i386 gcc : gcc version 2.95.3 20010125 (prerelease, propolice) Webserver : Apache 2.0.43 Datbabse : MySQL 4.23.54a PHP Version : 4.3.0RC3 and php4-STABLE-200211230430 PHP Configure Line: ./configure --enable-sockets --with-mysql=/opt/db/mysql --with-apxs2=/opt/apache2/bin/apxs MySQL Configure Line: (./configure --prefix=location). Updated MySQL from 4.23.53 to 4.23.54a to address recently announced bugs. Recompiled PHP and tried to restart Apache. I get this: Undefined symbol "___guard" in httpd:/opt/apache2/modules/libphp4.so On checking out the file... # nm /opt/apache2/modules/libphp4.so 000e9c34 T _OnUpdateBool 000e9c64 T _OnUpdateInt 000e9c98 T _OnUpdateReal 000e9ccc T _OnUpdateString 000e9ce0 T _OnUpdateStringUnempty 0005640c T _PHP_MD5Final 00056308 T _PHP_MD5Init 0005633c T _PHP_MD5Update 0007e19c T _PHP_SHA1Final 0007e090 T _PHP_SHA1Init 0007e0c8 T _PHP_SHA1Update 00069018 T _ValidateFormat 0011c000 d __DYNAMIC 0011c060 D __GLOBAL_OFFSET_TABLE_ 000fa6b4 T ___cmpdi2 000fa7ec T ___divdi3 000e0de8 T __array_init 00122b04 D __codes 000d976c T __convert_to_string 000cfe4c T __ecalloc 000cfd44 T __efree 000cfc28 T __emalloc 000cff08 T __erealloc 000d0040 T __estrdup 000d00c0 T __estrndup 000e0e30 T __object_and_properties_init 000e0ef4 T __object_init 000e0ecc T __object_init_ex 00033254 T __php_error_log 000ad0bc T __php_import_environment_variables 00054b50 T __php_math_basetolong 00054c10 T __php_math_basetozval 00054d14 T __php_math_longtobase 000557a4 T __php_math_number_format 00054de8 T __php_math_zvaltobase 000ad5ec T __php_stream_alloc I tried 4.3.0RC3 to see if it was something fixed, however it does not seem that way. Yesterday I installed MySQL 4.23.53 and php4-STABLE-200211230430 on a different OpenBSD machine with the same -current src tree with no problems. (going to start testing this on it, but will take time as it is only a slow p2...) Any ideas? ~CH -- Edit bug report at http://bugs.php.net/?id=21084&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21084&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21084&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21084&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21084&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21084&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21084&r=support Expected behavior: http://bugs.php.net/fix.php?id=21084&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21084&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21084&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21084&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21084&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21084&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21084&r=isapi
#21083 [Com]: Table variable not correctly working as session cookie
ID: 21083
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: Win98SE
PHP Version: 4.2.3
New Comment:
Here's the script that works both Linux&Win98SE
session_start();
if(!session_is_registered('ind'))
{
$ind = 0;
session_register('ind');
session_register("table[$ind]");
$_SESSION["table[$ind]"] = 1;
}
else
{
$ind = $_SESSION['ind'];
//Lisätään alkio tauluun
session_register("table[$ind]");
$_SESSION["table[$ind]"] = 1;
}
//increases the index
$ind++;
$_SESSION['ind'] = $ind;
$i= 0 ;
//prints all the data in $table
while ($i < $ind)
{
print($_SESSION["table[$i]"] . "");
$i++;
}
Previous Comments:
[2002-12-18 13:40:16] [EMAIL PROTECTED]
First here's the whole script:
");
$i++;
}
?>
I have tested this script both Linux(script works perfectly) and
Win98SE(doesn't work). Both have Apache and PHP 4.2.3.
So I'm using session cookie $table where to store number 1 in each
index. Index increases every time i press refresh. Script should print
(after three refresh):
1
1
1
1
But with my Windows scripts prints (after three refresh):
Notice: Undefined offset: 0 in c:\www\sessio_taulu_testi.php on line
32
Notice: Undefined offset: 1 in c:\www\sessio_taulu_testi.php on line
32
Notice: Undefined offset: 2 in c:\www\sessio_taulu_testi.php on line
32
1
When entering the script for the first time scripts prints correctly:
1
I have deleted the session file after each time I've executed the
script, so that shouldn't be the problem.
I would like to know what's the problem in here :)
--
Edit this bug report at http://bugs.php.net/?id=21083&edit=1
#20852 [Opn->Fbk]: Why Can't insert chinese into MS-ACCESS by COM
ID: 20852
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: COM related
Operating System: win2000
PHP Version: 4.2.2
New Comment:
marking as feedback as per Wez's suggestion
Previous Comments:
[2002-12-18 14:03:48] [EMAIL PROTECTED]
Sounds like a bogus COM problem to me:
Try this:
$conn = new COM("ADODB.Connection", null, $codepage);
where $codepage is the code page number that will be used when
converting strings to unicode.
[2002-12-18 13:56:31] [EMAIL PROTECTED]
COM != ODBC. Re-classifying.
[2002-12-05 21:42:08] [EMAIL PROTECTED]
Why Can't insert chinese into MS-ACCESS by COM ??
--
Example:
$conn = new COM("ADODB.Connection") or die("ADO connect failed!");
$rs = new COM("ADODB.RecordSet") or die("ADO recordset failed£¡");
$conn->open("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=test.mdb");
$str="This is a bug!"
$rs = $conn->Execute("insert into [Table_A](Contents)
values('".$str."');");
-
When i use COM insert the variable $str to column [Contents] of the
[Table_A].
I found it only support insert English.
When $str is a English string it success.
But when $str is a Chinese string it abnormal.
--
Edit this bug report at http://bugs.php.net/?id=20852&edit=1
#20852 [Opn]: Why Can't insert chinese into MS-ACCESS by COM
ID: 20852
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: COM related
Operating System: win2000
PHP Version: 4.2.2
New Comment:
Sounds like a bogus COM problem to me:
Try this:
$conn = new COM("ADODB.Connection", null, $codepage);
where $codepage is the code page number that will be used when
converting strings to unicode.
Previous Comments:
[2002-12-18 13:56:31] [EMAIL PROTECTED]
COM != ODBC. Re-classifying.
[2002-12-05 21:42:08] [EMAIL PROTECTED]
Why Can't insert chinese into MS-ACCESS by COM ??
--
Example:
$conn = new COM("ADODB.Connection") or die("ADO connect failed!");
$rs = new COM("ADODB.RecordSet") or die("ADO recordset failed£¡");
$conn->open("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=test.mdb");
$str="This is a bug!"
$rs = $conn->Execute("insert into [Table_A](Contents)
values('".$str."');");
-
When i use COM insert the variable $str to column [Contents] of the
[Table_A].
I found it only support insert English.
When $str is a English string it success.
But when $str is a Chinese string it abnormal.
--
Edit this bug report at http://bugs.php.net/?id=20852&edit=1
#21076 [Opn->Fbk]: ODBC_TABLES and ODBC_COLUMNS cannot be called together
ID: 21076 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: ODBC related Operating System: Win2000, IIS-CGI PHP Version: 4.2.3 New Comment: Can you please try one of the RCs? Previous Comments: [2002-12-18 07:54:50] [EMAIL PROTECTED] The following code: "; print "ODBC_Tables"; $trs = odbc_tables($conn); odbc_free_result($trs); print "ODBC_Columns"; $colrs = odbc_columns($conn); odbc_free_result($colrs); print "Done"; ?> Will generate the output: Connected ODBC_Tables ODBC_Columns Warning: SQL error: , SQL state 0 in SQLColumns in d:\inetpub\wwwroot\php\hs~a.php on line 10 Warning: odbc_free_result(): supplied argument is not a valid ODBC result resource in d:\inetpub\wwwroot\php\hs~a.php on line 11 Done However, the following code with odbc_tables commented out: "; /*print "ODBC_Tables"; $trs = odbc_tables($conn); odbc_free_result($trs);*/ print "ODBC_Columns"; $colrs = odbc_columns($conn); odbc_free_result($colrs); print "Done"; ?> Works fine with the output: Connected ODBC_Columns Done Hope this was clear. Regards, John Lim -- Edit this bug report at http://bugs.php.net/?id=21076&edit=1
#20298 [Opn->Ana]: odbc.check_persistent not working
ID: 20298 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type: ODBC related Operating System: Windows 2000 Server SP2 PHP Version: 4.3.0-pre2 New Comment: I'm unable to reproduce this on the UNIX end of things. Anyone with a Windows boxen working that can test this? Previous Comments: [2002-11-07 07:41:49] [EMAIL PROTECTED] Make sure the odbc.check_persistent is on and that odbc.allow_persistent is on. Set up a database connection called dsnname Run the script below (substituting [tabname] for a valid table name in your database). Check that you have persistent connections, ie with the webserver idle make sure your database shows connections from the webserver. Restart the database or kill the session belonging to the web server. Re-run the script below and the odbc_exec fails with an error: "connection not open" or smililar depending on your odbc driver. I have found this effect to be the same with the Postgres odbc driver and the Informix 3.30 odbc driver. I presume that odbc.check_persistent is supposed to check that the connection is still attached to the database before pconnect gives it to the script? -- Edit this bug report at http://bugs.php.net/?id=20298&edit=1
#20852 [Opn]: Why Can't insert chinese into MS-ACCESS by COM
ID: 20852
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: ODBC related
+Bug Type: COM related
Operating System: win2000
PHP Version: 4.2.2
New Comment:
COM != ODBC. Re-classifying.
Previous Comments:
[2002-12-05 21:42:08] [EMAIL PROTECTED]
Why Can't insert chinese into MS-ACCESS by COM ??
--
Example:
$conn = new COM("ADODB.Connection") or die("ADO connect failed!");
$rs = new COM("ADODB.RecordSet") or die("ADO recordset failed£¡");
$conn->open("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=test.mdb");
$str="This is a bug!"
$rs = $conn->Execute("insert into [Table_A](Contents)
values('".$str."');");
-
When i use COM insert the variable $str to column [Contents] of the
[Table_A].
I found it only support insert English.
When $str is a English string it success.
But when $str is a Chinese string it abnormal.
--
Edit this bug report at http://bugs.php.net/?id=20852&edit=1
#21082 [Opn->Bgs]: odbc_primarykeys Access
ID: 21082
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: ODBC related
Operating System: Win XP
PHP Version: 4.2.0
New Comment:
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
I believe this was fixed...
Previous Comments:
[2002-12-18 13:28:40] [EMAIL PROTECTED]
I cant get the primarykeys, php always return "Warning: SQL error: ,
SQL state 0 in SQLPrimaryKeys"
";
$i++;
}
}
echo "$i tables";
for ($j=0;$j<$i;$j++) {
echo "Clefs Primaires de ".$tables[$j];
$res = odbc_primarykeys ($con, $qualifiers[$j], $owners[$j],
$tables[$j]);
if ($res)
odbc_result_all ($res);
else
// ==> Warning: SQL error: , SQL state 0 in SQLPrimaryKeys
echo ("Error : ".odbc_error ($con).": ".odbc_errormsg
($con)."");
}
odbc_close ($con);
?>
--
Edit this bug report at http://bugs.php.net/?id=21082&edit=1
#21042 [Opn->Bgs]: Fails to return MS Access MEMO fields
ID: 21042
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: ODBC related
Operating System: Windows NT 4.0
PHP Version: 4.3.0RC3
New Comment:
please read the options on using odbc_connect() and setting cursors for
more information on how to work around this.
Technically a MEMO field is not a valid field for ODBC v2, and as such
is not supported by PHP. The truth is you can hack around it using the
cursor settings in the odbc_connect. Good luck.
Not a bug.
Previous Comments:
[2002-12-16 06:10:00] [EMAIL PROTECTED]
Trying to read MS Access MEMO fields (these are large (>255 chrs) text
fields) fails under 4.3.0RC3 in an Eval'd string whereas they work fine
under 4.2.3.
The error message returned is:
Warning: SQL error: [Microsoft][ODBC Microsoft Access 97 Driver]Invalid
cursor position; no keyset defined , SQL state S1109 in SQLGetData in
c:\InetPub\php\classes\member.php(91) : eval()'d code on line 1
Below is an example of code that causes the problem. The $xFields var
is a CSV list of fields in a table. If only the details field is a MEMO
type then only this will fail. All other types of field (string or
numeric) do not appear to have a problem. The error line will point to
the line containing the 'eval' function call.
CODE##
$xFields = "ref,name,details";
function coreLoad ($cur)
{
global $xFields;
$flds = explode (",", $xFields);
for ($i = 0; $i < sizeof ($flds); $i++)
{
$str = '$this->' . $flds [$i] . ' = odbc_result ($cur, ' . ($i + 1)
. ');';
eval ($str);
}
}
END OF CODE##
The connection to the MS Access database is through a standard ODBC
connection via the Windows Control Panel. No other modules have been
compiled into PHP either in 4.2.3 or 4.3.0RC3.
--
Edit this bug report at http://bugs.php.net/?id=21042&edit=1
#20873 [Opn->Bgs]: DSN with space will not work
ID: 20873
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: ODBC related
Operating System: Win XP Pro
PHP Version: 4.2.3
New Comment:
Try escaping your DSN. There really shouldn't be a space in your dsn
at all though if you were to follow specs.
Previous Comments:
[2002-12-07 02:27:50] [EMAIL PROTECTED]
I would agree with you, accept the DSN can be accessed with a
ColdFusion script I have. Also, I am doing the odbc_connect stuff right
because when I access DSNs without spaces my code works fine.
[2002-12-07 02:01:39] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Given the error message you've recieved I'd say the problem is not PHP,
but rather something else, possible solutions are described in the SQL
error message.
[2002-12-07 01:58:36] [EMAIL PROTECTED]
Using odbc_connect with a DSN with a space causes error:
Code:
$cnx = odbc_connect("BSU Directory","","") or die(odbc_error());
Error:
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\mbaker\Project\processInst.php on line 20
S1000
The same DSN works fine with a ColdFusion template and other DSNs work
fine with PHP.
--
Edit this bug report at http://bugs.php.net/?id=20873&edit=1
#21083 [NEW]: Table variable not correctly working as session cookie
From: [EMAIL PROTECTED] Operating system: Win98SE PHP version: 4.2.3 PHP Bug Type: Session related Bug description: Table variable not correctly working as session cookie First here's the whole script: "); $i++; } ?> I have tested this script both Linux(script works perfectly) and Win98SE(doesn't work). Both have Apache and PHP 4.2.3. So I'm using session cookie $table where to store number 1 in each index. Index increases every time i press refresh. Script should print (after three refresh): 1 1 1 1 But with my Windows scripts prints (after three refresh): Notice: Undefined offset: 0 in c:\www\sessio_taulu_testi.php on line 32 Notice: Undefined offset: 1 in c:\www\sessio_taulu_testi.php on line 32 Notice: Undefined offset: 2 in c:\www\sessio_taulu_testi.php on line 32 1 When entering the script for the first time scripts prints correctly: 1 I have deleted the session file after each time I've executed the script, so that shouldn't be the problem. I would like to know what's the problem in here :) -- Edit bug report at http://bugs.php.net/?id=21083&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21083&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21083&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21083&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21083&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21083&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21083&r=support Expected behavior: http://bugs.php.net/fix.php?id=21083&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21083&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21083&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21083&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21083&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21083&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21083&r=isapi
#20441 [Bgs]: PHP_AUTH_USER isn't set
ID: 20441 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache related Operating System: all PHP Version: 4.3.0-pre2 New Comment: This problem has just caused me a big headache - a customer has been relying on the fact that both .htaccess and PHP_AUTH_USER have been available in parallel since at least PHP 4. They've asked me to fix their scripts, but it would be a massive rewrite to sort out. I only have two customers who do their own scripting, and 50% of them are bitten by this. I think that 4.3.0 may well annoy lots of people with this. I can see from the documentation of bug #19251 why the change has been made, and I understand that that the manual documents the new behaviour, but I suspect this misbehaviour is widely relied upon, and perhaps we should consider an php.ini switch. The only economic solution I can suggest for my customer in the meanwhile is for me to patch php back to its old behaviour. Previous Comments: [2002-12-11 10:58:19] [EMAIL PROTECTED] We fixed a bug, period. Derick [2002-12-11 10:53:53] [EMAIL PROTECTED] Can someone explain this? Apparently some external auth systems did not populate PHP_AUTH_USER while others did... Was this BC break discussed? It has been documented forever but this behavior changed so please explain it. [2002-12-11 10:39:14] [EMAIL PROTECTED] I agree with the previous poster that this is a serious bug. When we upgraded to 4.3.0RC2 our development application broke. [2002-11-22 02:40:55] [EMAIL PROTECTED] This is not bogus!! This is a genuine bug. PHP_AUTH_USER was set in 4.2.3 why has the functionality been changed without warning? This will break so many peoples scripts it is not true. This *HAS TO BE FIXED* os that it works as it did before. Please stop trying to pretend that this is not a bug. It is, and a serious one at that. [2002-11-15 09:10:09] [EMAIL PROTECTED] It was fixed to be like it should be since PHP 3. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20441 -- Edit this bug report at http://bugs.php.net/?id=20441&edit=1
#21082 [NEW]: odbc_primarykeys Access
From: [EMAIL PROTECTED]
Operating system: Win XP
PHP version: 4.2.0
PHP Bug Type: ODBC related
Bug description: odbc_primarykeys Access
I cant get the primarykeys, php always return "Warning: SQL error: , SQL
state 0 in SQLPrimaryKeys"
";
$i++;
}
}
echo "$i tables";
for ($j=0;$j<$i;$j++) {
echo "Clefs Primaires de ".$tables[$j];
$res = odbc_primarykeys ($con, $qualifiers[$j], $owners[$j],
$tables[$j]);
if ($res)
odbc_result_all ($res);
else
// ==> Warning: SQL error: , SQL state 0 in SQLPrimaryKeys
echo ("Error : ".odbc_error ($con).": ".odbc_errormsg ($con)."");
}
odbc_close ($con);
?>
--
Edit bug report at http://bugs.php.net/?id=21082&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21082&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21082&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21082&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21082&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21082&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21082&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21082&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21082&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21082&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21082&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21082&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21082&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21082&r=isapi
#20985 [Com]: heavy load = Segmentation fault
ID: 20985 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: Redhat Linux 7.3 & 8 PHP Version: 4.3.0RC3 New Comment: I'll do my best. Previous Comments: [2002-12-16 15:58:02] [EMAIL PROTECTED] I appreciate your offer, but it would be much better if you could narrow down the problem. There is just too much code to go over. [2002-12-16 07:42:09] [EMAIL PROTECTED] I can give you access to the system. Would you like that? I have also sent an email to [EMAIL PROTECTED] regarding this. [2002-12-15 21:34:42] [EMAIL PROTECTED] This is a fairly big script and I cannot even run it fully because I am missing over a dosen various includes your script requires. Is there any way you could reduce this to a single, preferably short script that could be used to replicate the memory leak you are seeing? [2002-12-15 13:21:15] [EMAIL PROTECTED] The files has been sent to [EMAIL PROTECTED] If none of my scripts has errors I can not get SIGSEGV. But I get "Last leak repeated X times". Have a look at http://test.webalogic.net/bugs/error_log-no_SIGSEGV and the other files at http://test.webalogic.net/ [2002-12-14 23:37:19] [EMAIL PROTECTED] Could you provide copies of the list.phtml & info.phtml scripts? 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/20985 -- Edit this bug report at http://bugs.php.net/?id=20985&edit=1
#21081 [NEW]: SMTP set to localhost or 127.0.0.1 doesn't work.
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.2.2 PHP Bug Type: Mail related Bug description: SMTP set to localhost or 127.0.0.1 doesn't work. I am using PHP versio 4.2.2 on Windows 2000, installed with php-4.2.2-installer.exe. MS SMTP is running and works fine with CDONTS in ASP. But PHP cannot send email if php.ini is set to SMTP =localhost or to SMTP =127.0.0.1. It does work if set to my ISP's SMTP server. -- Edit bug report at http://bugs.php.net/?id=21081&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21081&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21081&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21081&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21081&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21081&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21081&r=support Expected behavior: http://bugs.php.net/fix.php?id=21081&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21081&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21081&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21081&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21081&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21081&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21081&r=isapi
#6645 [Com]: Solution to 6572
ID: 6645 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: ODBC related Operating System: WIN NT4.0 Sp6a PHP Version: 4.0.2 New Comment: See new note on 6572. Fetching the memo field in its own odbc_exec() seems to be sufficient to work around this bug. Previous Comments: [2000-09-09 23:59:28] [EMAIL PROTECTED] ...and then remembered to close this one... [2000-09-09 23:58:59] [EMAIL PROTECTED] I've copied this text into the appropriate bug report (#6572). [2000-09-09 23:41:37] [EMAIL PROTECTED] That should be SQL_CUR_USE_ODBC without the $. [2000-09-09 23:31:59] [EMAIL PROTECTED] Bug 6572 claims that MEMO fields cannot be read. Oddly, this also happens in ASP/vbscript, however you can MEMO fields to work correctly with the following: You can get MEMO fields to work. Right now it takes some finesse. #1) You may try adding $SQL_CUR_USE_ODBC #2) You need to use odbc_longreadlen before you use odbc_fetch_row, otherwise it will not read enough characters. #3) As of 4.0.2, making odbc_longread too long may cause PHP to become unstable. #4) You may need to make a query that only returns the MEMO field to read it correctly. Otherwise it sometimes just doesn't work (this is similar in ASP and so is probably a bug with Access or ODBC drivers for it.) Example: $conn = odbc_connect( $DSN, $user, $pw, $SQL_CUR_USE_ODBC ); $result = odbc_exec( $conn, $query ); odbc_longreadlen( $result, 100); /* Your odbc_fetch_row, etc, will now work */ -- Edit this bug report at http://bugs.php.net/?id=6645&edit=1
#6572 [Com]: ODBC_result cannot fetch MEMO fields from MS Access
ID: 6572 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: ODBC related Operating System: Win NT 4.0 PHP Version: 4.0.1pl2 New Comment: I get the same failure. When I create a new selection that only gets the Memo field and DOES NOT specify odbc_longreadlen($result, 100); the memo field is fetched correctly. Previous Comments: [2000-09-26 21:58:06] [EMAIL PROTECTED] Solved. --Jani [2000-09-20 22:38:55] [EMAIL PROTECTED] Thanks for your help - it solved the problem. Only one thing doesn't work correctly - the carriage returns. It seems that they are converted to spaces. But I'll try to figure this out myself. Thanks again, [EMAIL PROTECTED] [2000-09-09 23:57:15] [EMAIL PROTECTED] Moved in from Bug Report #6645; this appears to be a way of coping. Can the original poster tell whether this helps? - Torben Oddly, this also happens in ASP/vbscript, however you can MEMO fields to work correctly with the following: You can get MEMO fields to work. Right now it takes some finesse. #1) You may try adding SQL_CUR_USE_ODBC #2) You need to use odbc_longreadlen before you use odbc_fetch_row, otherwise it will not read enough characters. #3) As of 4.0.2, making odbc_longread too long may cause PHP to become unstable. #4) You may need to make a query that only returns the MEMO field to read it correctly. Otherwise it sometimes just doesn't work (this is similar in ASP and so is probably a bug with Access or ODBC drivers for it.) Example: $conn = odbc_connect( $DSN, $user, $pw, $SQL_CUR_USE_ODBC ); $result = odbc_exec( $conn, $query ); odbc_longreadlen( $result, 100); /* Your odbc_fetch_row, etc, will now work */ [2000-09-06 05:23:54] [EMAIL PROTECTED] ODBC_result cannot fetch MEMO fields from MS Access \n"; echo ""; echo ""; echo odbc_result($ergebnis, "Name"); echo ",\n"; echo "mailto:";; echo odbc_result($ergebnis, "Email"); echo "\">"; echo odbc_result($ergebnis, "Email"); echo "\n"; echo odbc_result($ergebnis, "Date"); echo ",\n"; echo odbc_result($ergebnis, "Time"); echo ""; echo ""; echo odbc_result($ergebnis, "Memo"); echo ""; echo ""; odbc_free_result($ergebnis); odbc_close($verbindung); ?> I always get the following error message when I run this script: Warning: SQL error: [Microsoft][ODBC Driver Manager] Invalid cursor state, SQL state 24000 in SQLGetData in c:\program files\apache group\apache\htdocs\szeker\new\guestbook.php on line 37 And I'm not the only one - in the language reference there is another user with exactly the same problem. If I change the data type from Memo to Text, everything works fine. But I need more than 255 characters in this field. Is there another possibility to query this field? Or will this bug be fixed? -- Edit this bug report at http://bugs.php.net/?id=6572&edit=1
#19983 [Opn->Bgs]: Compile/Link failure w/Sablotron
ID: 19983
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Compile Failure
Operating System: Mac OS X 10.2
PHP Version: 4.3.0-pre1
New Comment:
The problem __really__ is, combining gcc3 and gcc2 suite, as outlined
in this document:
http://fink.sourceforge.net/doc/porting/preparing.php
Secondly - if any warnings/errors occur as mentioned in the document
above (libtool stuff), the links to patches for those are provided. PHP
already has this covered.
The following works:
1) configure expat, using gcc2 explicetely:
CC=gcc2 \
./configure \
--prefix=/your/prefix
2) configure libiconv, the same way:
CC=gcc2 \
./configure \
--prefix=/your/prefix
3) configure Sablotron (tested with 0.97RC2) using:
CC=gcc2 \
CXX=g++2 \
./configure \
--prefix=/your/prefix \
--with-expat-prefix=/your/prefix \
--with-iconv-prefix=/your/prefix
PHP can then be configured, using:
CC=gcc2 \
CXX=g++2 \
./configure \
--prefix=/your/prefix \
--disable-cgi \
--enable-xslt \
--with-xslt-sablot=/your/prefix \
--with-expat-dir=/your/prefix \
--with-iconv-dir=/your/prefix
I guess the same applies to gcc3, but you have to make sure, that all
libs you include, are compiled with gcc3/g++3 then.
Previous Comments:
[2002-12-17 13:57:23] [EMAIL PROTECTED]
I don't think his workaround works... Putting the -lstdc++
on the end of the ZEND_EXTRA_LIBS variable enables
everything to make, but I cannot make install and I
certainly can't run with Apache... I get similar errors
that [EMAIL PROTECTED] (above) gets. I know this is kind
of a 'me too' response, but I want to emphasize that there
is NO workaround. Thanks!
During make install:
Installing PHP CLI binary:/usr/local/bin/
Installing PEAR environment: /usr/local/lib/php/
dyld: /usr/local/src/build-php-4.3.0RC3/php-4.3.0RC3/sapi/
cli/php Undefined symbols:
__ZTVN10__cxxabiv117__class_type_infoE
__ZTVN10__cxxabiv120__si_class_type_infoE
__ZdaPv
__ZdlPv
__Znwm
___gxx_personality_v0
__ZSt9terminatev
__Znam
__ZTVN10__cxxabiv121__vmi_class_type_infoE
___cxa_pure_virtual
make[1]: *** [install-pear-installer] Trace/BPT trap
make: *** [install-pear] Error 2
[2002-12-17 04:29:14] [EMAIL PROTECTED]
As the original reporter provides a work-around, I'm re-opening this
bug-report, and see if we're able to make some configure hack, that
strips all instances of -lstdc++ and adds one to the end of the linking
process.
[2002-11-18 05:00:53] [EMAIL PROTECTED]
make ./configure --prefix=/usr --with-apxs=/usr/sbin/apxs
--mandir=/usr/share/man --infodir=/usr/share/info
--with-config-file-path=/etc/httpd --enable-calendar
--with-iconv=/usr/local --enable-exif --enable-ftp --enable-wddx
--with-xml --with-zlib --with-curl=/usr --with-gd=/usr/local
--with-jpeg-dir=/usr/local --with-png-dir=/usr/local
--with-imap=../imap-2002.RC10 --with-imap-ssl=/usr --enable-sablot
--enable-sablot-errors-descriptive --enable-xslt
--with-xslt-sablot=/usr/local --with-mcrypt=/usr/local
--with-mhash=/usr/local --with-mysql=/usr/local/mysql
--with-expat-dir=/usr/local
modified ZEND_EXTRA_LIBS in Makefile before make
make is ok
but when I did sudo make install :
dyld: /Users/benoitc/build/php-4.3.0RC1/sapi/cli/php Undefined
symbols:
__ZTVN10__cxxabiv117__class_type_infoE
__ZTVN10__cxxabiv120__si_class_type_infoE
__ZdaPv
__ZdlPv
__Znwm
___gxx_personality_v0
__ZSt9terminatev
__Znam
__ZTVN10__cxxabiv121__vmi_class_type_infoE
___cxa_pure_virtual
make[1]: *** [install-pear-installer] Trace/BPT trap
make: *** [install-pear] Error 2
[2002-10-27 19:48:58] [EMAIL PROTECTED]
libtool 1.4.2
gcc 3.1
autoconf 2.5.something
confirmed problem. Solution? None at this time, I'd like to open a
dialog with an Apple rep about this.
[2002-10-18 17:35:41] [EMAIL PROTECTED]
Additionally: which libtool are you using?
In the current CVS version of libtool ('libtool 1.4e'), there are a
number of fixes regarding to C++ support.
Additionally - set CFLAGS=-O0 to ensure that gcc 3.x is not breaking
code, during it's optimisation.
However - if the work-around you are describing is the only thing that
does work, we will look into it.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/19983
--
Edit this
#21080 [Opn->Bgs]: Single select in form returns wrong variable
ID: 21080 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: RedHat Linux 8.0 PHP Version: 4.2.2 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. Duplication of #18648 (see http://bugs.php.net/18648) Previous Comments: [2002-12-18 11:15:02] [EMAIL PROTECTED] I should add that using a hidden input of the form in the form solves the problem! [2002-12-18 11:13:02] [EMAIL PROTECTED] The following HTML file should produce the result "Field 1" when it calls the PHP file. Instead the result is "Field 1select=Field 1". test.html: Field 1 Field 2 test.php: I used the RedHat php distribution, php-4.2.2-8.0.5 without any recompilation or modification (other than to include the AddType application/x-httpd-php .php line to the httpd configuration). The apache distribution I am using is also native RedHat: httpd-2.0.40-11 -- Edit this bug report at http://bugs.php.net/?id=21080&edit=1
#21080 [Opn]: Single select in form returns wrong variable
ID: 21080 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: RedHat Linux 8.0 PHP Version: 4.2.2 New Comment: I should add that using a hidden input of the form in the form solves the problem! Previous Comments: [2002-12-18 11:13:02] [EMAIL PROTECTED] The following HTML file should produce the result "Field 1" when it calls the PHP file. Instead the result is "Field 1select=Field 1". test.html: Field 1 Field 2 test.php: I used the RedHat php distribution, php-4.2.2-8.0.5 without any recompilation or modification (other than to include the AddType application/x-httpd-php .php line to the httpd configuration). The apache distribution I am using is also native RedHat: httpd-2.0.40-11 -- Edit this bug report at http://bugs.php.net/?id=21080&edit=1
#21080 [NEW]: Single select in form returns wrong variable
From: [EMAIL PROTECTED] Operating system: RedHat Linux 8.0 PHP version: 4.2.2 PHP Bug Type: Apache2 related Bug description: Single select in form returns wrong variable The following HTML file should produce the result "Field 1" when it calls the PHP file. Instead the result is "Field 1select=Field 1". test.html: Field 1 Field 2 test.php: I used the RedHat php distribution, php-4.2.2-8.0.5 without any recompilation or modification (other than to include the AddType application/x-httpd-php .php line to the httpd configuration). The apache distribution I am using is also native RedHat: httpd-2.0.40-11 -- Edit bug report at http://bugs.php.net/?id=21080&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21080&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21080&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21080&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21080&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21080&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21080&r=support Expected behavior: http://bugs.php.net/fix.php?id=21080&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21080&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21080&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21080&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21080&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21080&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21080&r=isapi
#21079 [Opn->Fbk]: Output buffering via ob_gzhandler fails for large pages
ID: 21079 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Output Control Operating System: Linux PHP Version: 4.2.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-12-18 10:54:05] [EMAIL PROTECTED] Output buffering via ob_gzhandler fails for large pages (more than 4188160 = 1024 * 4090 chars for me). The resulting output is empty (just headers are sent but no content) - no warning about exceeding limits or anything else. To test it I used following code, when I commented out + 1 it worked. My configuration: in php.ini I have: max_execution_time = 30 memory_limit = 8M PHP 4.2.1 Apache 1.3.26 Same error (probably) reported by someone with PHP 4.2.2 and Apache 2.0.40, see phpMyAdmin bugreport: http://sourceforge.net/tracker/index.php?func=detail&aid=650481&group_id=23067&atid=377408 -- Edit this bug report at http://bugs.php.net/?id=21079&edit=1
#21079 [NEW]: Output buffering via ob_gzhandler fails for large pages
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.1 PHP Bug Type: Output Control Bug description: Output buffering via ob_gzhandler fails for large pages Output buffering via ob_gzhandler fails for large pages (more than 4188160 = 1024 * 4090 chars for me). The resulting output is empty (just headers are sent but no content) - no warning about exceeding limits or anything else. To test it I used following code, when I commented out + 1 it worked. My configuration: in php.ini I have: max_execution_time = 30 memory_limit = 8M PHP 4.2.1 Apache 1.3.26 Same error (probably) reported by someone with PHP 4.2.2 and Apache 2.0.40, see phpMyAdmin bugreport: http://sourceforge.net/tracker/index.php?func=detail&aid=650481&group_id=23067&atid=377408 -- Edit bug report at http://bugs.php.net/?id=21079&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21079&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21079&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21079&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21079&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21079&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21079&r=support Expected behavior: http://bugs.php.net/fix.php?id=21079&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21079&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21079&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21079&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21079&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21079&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21079&r=isapi
#21044 [Bgs->Opn]: getcwd() returns empty string (not always)
ID: 21044 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Directory function related Operating System: Linux, 2.2.22 PHP Version: 4.3.0RC3 New Comment: I've got the solution! After hacking php sources for a few hours (ok, minutes...) I've found the solution: I had to add '#define VIRTUAL_DIR 0' line just before '#ifdef VIRTUAL_DIR' condition in TSRM/tsrm_virtual_cwd.h file. To my surprise defined values (0 wether 1) has no effect. I just had to add that define. Now everything works. Well, maybe it's my gcc fault. I'm using quite an old one: 2.7.2.3 Thanks for your time. Previous Comments: [2002-12-16 10:17:03] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. I've tries the latest 4.3.0 stable CVS and cannot replicate the bug. getcwd() on non-zts installs uses the native getcwd() provided by your libc, so the virtual host or simular things will have no affect on it. [2002-12-16 08:56:52] [EMAIL PROTECTED] According to phpinfo(): ./configure --with-apxs=/usr/local/apache/bin/apxs --without-pear --with-zlib --with-dom --without-xml --with-expat-dir=/usr/local --with-iconv=/usr/local --with-curl --with-pgsql=/usr/local/pgsql --enable-ftp Full phpinfo() output can be found at: http://www.ma.krakow.pl/~miki/test.php Now that site is running 4.3.0-pre1, but it behaves the same like 4.3.0rc3 I tested it on (with the same configure parameters). [2002-12-16 08:49:30] [EMAIL PROTECTED] Could you please show the parameters you've passed to PHP's configure script, they can be found inside config.nice. [2002-12-16 08:04:36] [EMAIL PROTECTED] getcwd() works only within pages in 'main' document root. Pages under user directories (/~user/) and pages located in every virtual host directory doesn't get proper getcwd(). It results in include() and reqiure() using relative paths not working. Bug came out when I was trying to install fresh copy of postnuke. -- Edit this bug report at http://bugs.php.net/?id=21044&edit=1
#21078 [Bgs]: configure: error: not found. Please reinstall the expat distribution.
ID: 21078 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Configuration Issues Operating System: redhat linux 8.0 PHP Version: 4.3.0RC3 New Comment: Read my response again. Previous Comments: [2002-12-18 09:12:53] [EMAIL PROTECTED] I am sorry that I was not clearer with the 'bug' part. expat is currently installed and being used by python and perl. All the appropriate files are located in /usr/lib/ and it is telling me to reinstall. I have reinstalled and installed 'expat-devel-1.95.4-1.i386.rpm' as well. I have tried configuration with and without the development rpm. Why isn't PHP seeing the expat libraries? Is it looking for a different version? Do I need to configure with a different compiler? I'm sorry if this still doesn't qualify as a bug and if that is the case I will try the support site. Sounds like PHP's not seeing expat where I have specified. Thanks in advance. Robert Byrne [2002-12-18 08:58:42] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. You need to spcify the root install dir for expat --with-expat-dir=/usr (but normally you wouldn't need to add this option at all). [2002-12-18 08:55:43] [EMAIL PROTECTED] ./configure --prefix=/apache/php/ --with-apache2 --with-apxs2=/apache/bin/apxs --with-dom --with-xmlrpc --enable-wddx --with-xml --with-dom --with-expat-dir=/usr/lib/ --enable-so --enable-tracking-vars So, obviously I am configuring PHP to work with XML. I have not yet tried the sablotron and the only bugs I have seen regarding expat are blamed on sablotron. I keep getting the error: configure: error: not found. Please reinstall the expat distribution. I am new to linux and have been writing PHP on a junior level for a year and a half. Any explanations are greatly appreciated. Thanks in advance. Robert Byrne -- Edit this bug report at http://bugs.php.net/?id=21078&edit=1
#21078 [Com]: configure: error: not found. Please reinstall the expat distribution.
ID: 21078 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Configuration Issues Operating System: redhat linux 8.0 PHP Version: 4.3.0RC3 New Comment: I am sorry that I was not clearer with the 'bug' part. expat is currently installed and being used by python and perl. All the appropriate files are located in /usr/lib/ and it is telling me to reinstall. I have reinstalled and installed 'expat-devel-1.95.4-1.i386.rpm' as well. I have tried configuration with and without the development rpm. Why isn't PHP seeing the expat libraries? Is it looking for a different version? Do I need to configure with a different compiler? I'm sorry if this still doesn't qualify as a bug and if that is the case I will try the support site. Sounds like PHP's not seeing expat where I have specified. Thanks in advance. Robert Byrne Previous Comments: [2002-12-18 08:58:42] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. You need to spcify the root install dir for expat --with-expat-dir=/usr (but normally you wouldn't need to add this option at all). [2002-12-18 08:55:43] [EMAIL PROTECTED] ./configure --prefix=/apache/php/ --with-apache2 --with-apxs2=/apache/bin/apxs --with-dom --with-xmlrpc --enable-wddx --with-xml --with-dom --with-expat-dir=/usr/lib/ --enable-so --enable-tracking-vars So, obviously I am configuring PHP to work with XML. I have not yet tried the sablotron and the only bugs I have seen regarding expat are blamed on sablotron. I keep getting the error: configure: error: not found. Please reinstall the expat distribution. I am new to linux and have been writing PHP on a junior level for a year and a half. Any explanations are greatly appreciated. Thanks in advance. Robert Byrne -- Edit this bug report at http://bugs.php.net/?id=21078&edit=1
#21078 [Opn->Bgs]: configure: error: not found. Please reinstall the expat distribution.
ID: 21078 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: redhat linux 8.0 PHP Version: 4.3.0RC3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. You need to spcify the root install dir for expat --with-expat-dir=/usr (but normally you wouldn't need to add this option at all). Previous Comments: [2002-12-18 08:55:43] [EMAIL PROTECTED] ./configure --prefix=/apache/php/ --with-apache2 --with-apxs2=/apache/bin/apxs --with-dom --with-xmlrpc --enable-wddx --with-xml --with-dom --with-expat-dir=/usr/lib/ --enable-so --enable-tracking-vars So, obviously I am configuring PHP to work with XML. I have not yet tried the sablotron and the only bugs I have seen regarding expat are blamed on sablotron. I keep getting the error: configure: error: not found. Please reinstall the expat distribution. I am new to linux and have been writing PHP on a junior level for a year and a half. Any explanations are greatly appreciated. Thanks in advance. Robert Byrne -- Edit this bug report at http://bugs.php.net/?id=21078&edit=1
#21078 [NEW]: configure: error: not found. Please reinstall the expat distribution.
From: [EMAIL PROTECTED] Operating system: redhat linux 8.0 PHP version: 4.3.0RC3 PHP Bug Type: *Configuration Issues Bug description: configure: error: not found. Please reinstall the expat distribution. ./configure --prefix=/apache/php/ --with-apache2 --with-apxs2=/apache/bin/apxs --with-dom --with-xmlrpc --enable-wddx --with-xml --with-dom --with-expat-dir=/usr/lib/ --enable-so --enable-tracking-vars So, obviously I am configuring PHP to work with XML. I have not yet tried the sablotron and the only bugs I have seen regarding expat are blamed on sablotron. I keep getting the error: configure: error: not found. Please reinstall the expat distribution. I am new to linux and have been writing PHP on a junior level for a year and a half. Any explanations are greatly appreciated. Thanks in advance. Robert Byrne -- Edit bug report at http://bugs.php.net/?id=21078&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21078&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21078&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21078&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21078&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21078&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21078&r=support Expected behavior: http://bugs.php.net/fix.php?id=21078&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21078&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21078&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21078&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21078&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21078&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21078&r=isapi
#21077 [Opn->Ctl]: proc_open hangs
ID: 21077 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: Filesystem function related Operating System: any BSD PHP Version: 4CVS-2002-12-18 (dev) -Assigned To: +Assigned To: wez New Comment: assigning and marking on request Previous Comments: [2002-12-18 08:49:40] [EMAIL PROTECTED] proc_open test in the testsuite fails. Seems that proc_close fails now (returns -1). Patch rev 1.85/1.86 on exec.c and related files triggered the bug. -- Edit this bug report at http://bugs.php.net/?id=21077&edit=1
#21077 [NEW]: proc_open hangs
From: [EMAIL PROTECTED] Operating system: any BSD PHP version: 4CVS-2002-12-18 (dev) PHP Bug Type: Filesystem function related Bug description: proc_open hangs proc_open test in the testsuite fails. Seems that proc_close fails now (returns -1). Patch rev 1.85/1.86 on exec.c and related files triggered the bug. -- Edit bug report at http://bugs.php.net/?id=21077&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21077&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21077&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21077&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21077&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21077&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21077&r=support Expected behavior: http://bugs.php.net/fix.php?id=21077&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21077&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21077&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21077&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21077&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21077&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21077&r=isapi
#18359 [NoF->Opn]: PHP module seem to make trouble with authentication under Apache 2
ID: 18359 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: Apache2 related Operating System: Windows 2000 PHP Version: 4.2.1 New Comment: After having made tests, if ErrorDocument 401 is set with a .php3 file, the server doesn't show authencations anymore ! The solution is simple, simply make a HTML page that contains a redirect to the PHP error page, don't forget to send the "bad" URL if you show it in the file... Previous Comments: [2002-12-18 04:34:33] [EMAIL PROTECTED] The problem still exists. Whenever I use a .php-file as Errordocument for 401, authentification failes and directly shows the .php-file. Static html works. [2002-08-26 01:00:09] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-08-08 18:20:27] [EMAIL PROTECTED] Sorry, forgot to say: apache 2.0.39 php 4.2.2 FreeBSD 4.6-STABLE [2002-08-08 18:16:42] [EMAIL PROTECTED] same thing happens to me, commenting out # ErrorDocument 401 /errors/401.php works around the problem [2002-07-25 11:07:38] [EMAIL PROTECTED] Sir, by ht-files I actually mean .htaccess-files... :-) My Problem is exactly the same and it REALLY suxx! 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/18359 -- Edit this bug report at http://bugs.php.net/?id=18359&edit=1
#21076 [NEW]: ODBC_TABLES and ODBC_COLUMNS cannot be called together
From: [EMAIL PROTECTED] Operating system: Win2000, IIS-CGI PHP version: 4.2.3 PHP Bug Type: ODBC related Bug description: ODBC_TABLES and ODBC_COLUMNS cannot be called together The following code: "; print "ODBC_Tables"; $trs = odbc_tables($conn); odbc_free_result($trs); print "ODBC_Columns"; $colrs = odbc_columns($conn); odbc_free_result($colrs); print "Done"; ?> Will generate the output: Connected ODBC_Tables ODBC_Columns Warning: SQL error: , SQL state 0 in SQLColumns in d:\inetpub\wwwroot\php\hs~a.php on line 10 Warning: odbc_free_result(): supplied argument is not a valid ODBC result resource in d:\inetpub\wwwroot\php\hs~a.php on line 11 Done However, the following code with odbc_tables commented out: "; /*print "ODBC_Tables"; $trs = odbc_tables($conn); odbc_free_result($trs);*/ print "ODBC_Columns"; $colrs = odbc_columns($conn); odbc_free_result($colrs); print "Done"; ?> Works fine with the output: Connected ODBC_Columns Done Hope this was clear. Regards, John Lim -- Edit bug report at http://bugs.php.net/?id=21076&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21076&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21076&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21076&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21076&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21076&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21076&r=support Expected behavior: http://bugs.php.net/fix.php?id=21076&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21076&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21076&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21076&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21076&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21076&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21076&r=isapi
#19113 [Com]: HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use
ID: 19113 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Apache related Operating System: FreeBSD 4.6.2 PHP Version: 4.2.2 New Comment: Sorry, you don't understand the problem. The problem is that apache returns "HTTP 200 OK" on CONNECT request, but does NOT really connect to specified addrress. If it is possible to connect through your server to outside, then it's problem of your misconfigured proxy. Previous Comments: [2002-12-16 13:54:03] [EMAIL PROTECTED] This bug is VERY serious. Our web servers have be attacked and used for relaying SPAM. Spammers are using the CONNECT command to proxy to open relay servers masking their IP addresses with ours. [2002-12-12 05:52:03] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-12 05:19:30] [EMAIL PROTECTED] I was now able reproduce this problem, but only in case when index.php was in DocumentRoot of first defined name-based virtual server (which is accepted as the default on that IP/port in such case), and index.php was the default script to execute (if there was something before index.php in DirectoryIndex and if it also existed in DocumentRoot of the default vhost, the bug did not apply). Therefore, i think it is really a php bug I reproduced this with Apache-1.3.26+php-4.1.2 on debian GNU/linux 3.0-woody and also Apache-1.3.27+php-4.2.3 on FreeBSD-4.6.2 [2002-12-03 10:01:43] [EMAIL PROTECTED] Hello, I also have problems with this. However, using apache-1.2.27+mod_ssl2.8.11 and php-4.2.3 i was not able to reproduce this problem with defined way. I think that is not php-related. [2002-11-20 07:41:09] [EMAIL PROTECTED] Reopening, on request of #20517. 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/19113 -- Edit this bug report at http://bugs.php.net/?id=19113&edit=1
#21075 [Csd->Fbk]: array_walk function failing global variable
ID: 21075 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Feedback Bug Type: Scripting Engine problem Operating System: win32 PHP Version: 4.2.3 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2002-12-18 06:59:11] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-18 06:54:58] [EMAIL PROTECTED] I use a global variable declaration in the array_walk function. I was not able to see this variable in the global scope after array_walk. -- Edit this bug report at http://bugs.php.net/?id=21075&edit=1
#21075 [Opn->Csd]: array_walk function failing global variable
ID: 21075 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: win32 PHP Version: 4.2.3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-12-18 06:54:58] [EMAIL PROTECTED] I use a global variable declaration in the array_walk function. I was not able to see this variable in the global scope after array_walk. -- Edit this bug report at http://bugs.php.net/?id=21075&edit=1
#21075 [NEW]: array_walk function failing global variable
From: [EMAIL PROTECTED] Operating system: win32 PHP version: 4.2.3 PHP Bug Type: Scripting Engine problem Bug description: array_walk function failing global variable I use a global variable declaration in the array_walk function. I was not able to see this variable in the global scope after array_walk. -- Edit bug report at http://bugs.php.net/?id=21075&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21075&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21075&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21075&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21075&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21075&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21075&r=support Expected behavior: http://bugs.php.net/fix.php?id=21075&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21075&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21075&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21075&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21075&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21075&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21075&r=isapi
#16411 [Com]: CGI application misbehaved by not returning a complete set of
ID: 16411 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: I have the same problem. Platform: PHP different versions, SQL Server 2000 and Windows 2000. I see it a lot when the server is busy, or when two requests are made really fast after another. Really need a solution for this. Previous Comments: [2002-12-13 11:25:11] [EMAIL PROTECTED] i'm also experiencing this error with win xp, mssql 2000, and php 4.3.0 rc3. is it a problem with php, or with the mssql libraries? [2002-12-08 10:31:33] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-02 19:59:17] [EMAIL PROTECTED] Database connections are all transient. In the original code, I did not close the connections because php would do that at the end of script. But as I was in doubt, I later made a close right before calling the function header() but the same problem happened. I also made another test: in the script I just opened and immediately right after colsed it. The same bug happened. When I removed that tiny chunk of code, every thing worked just fine. [2002-12-02 19:57:52] [EMAIL PROTECTED] Database connections are all transient. In the original code, I did not close the connections because php would do that at the end of script. But as I was in doubt, I later made a close right before calling the function header() but the same problem happened. I also made another test: in the script I just opened and immediately right after colsed it. The same bug happened. When I removed that tiny chunk of code, every thing worked just fine. [2002-11-30 20:36:38] [EMAIL PROTECTED] What are you doing with your database connections? Are they persistant (mssql_pconnect) or transient (mssql_connect)? Do you close your connections explicitly (mssql_close) before the end of your script? vielina, your connections will be closed each time as you are running under the CGI. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16411 -- Edit this bug report at http://bugs.php.net/?id=16411&edit=1
#21068 [Bgs]: ncurses_getch and ncurses_wgetch diff
ID: 21068
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: SuSE 8.0
PHP Version: 4.3.0RC3
New Comment:
Forgot to say that you have to enable keypad for wgetch via
ncurses_keypad($win, TRUE);
Georg
Previous Comments:
[2002-12-18 04:54:39] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Note that not all function keys are supported on any particular
terminal. If you need F-Keys remove your putenv(...)
[2002-12-17 11:40:39] [EMAIL PROTECTED]
maybe this is not a bug, maybe if it is it's not related to php but to
ncurses 5.3 which I use, in this case anyone know a workaround (not to
rewrite a php getch which can handle different key sequences).
Now the result is correct if I don't use window ($ch=265), wgetch
return the sequence $ch=(27, 91, 91, 65)
[2002-12-17 11:33:01] [EMAIL PROTECTED]
ord('e')) {
$ch = ncurses_getch();
ncurses_move($i++, 1);
ncurses_addstr("key --$ch--");
if ($ch == ord('w')) {
$winhandle = ncurses_newwin( 20, 40, $i++, 4);
$j=1;
ncurses_wborder($winhandle,0,0,0,0,0,0,0,0);
while ($ch <> ord('e')) {
$ch = ncurses_wgetch($winhandle);
ncurses_wmove($winhandle, $j++, 1);
ncurses_waddstr($winhandle, "key --$ch--");
}
}
}
ncurses_end();
?>
--
Edit this bug report at http://bugs.php.net/?id=21068&edit=1
#21068 [Opn->Bgs]: ncurses_getch and ncurses_wgetch diff
ID: 21068
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: SuSE 8.0
PHP Version: 4.3.0RC3
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Note that not all function keys are supported on any particular
terminal. If you need F-Keys remove your putenv(...)
Previous Comments:
[2002-12-17 11:40:39] [EMAIL PROTECTED]
maybe this is not a bug, maybe if it is it's not related to php but to
ncurses 5.3 which I use, in this case anyone know a workaround (not to
rewrite a php getch which can handle different key sequences).
Now the result is correct if I don't use window ($ch=265), wgetch
return the sequence $ch=(27, 91, 91, 65)
[2002-12-17 11:33:01] [EMAIL PROTECTED]
ord('e')) {
$ch = ncurses_getch();
ncurses_move($i++, 1);
ncurses_addstr("key --$ch--");
if ($ch == ord('w')) {
$winhandle = ncurses_newwin( 20, 40, $i++, 4);
$j=1;
ncurses_wborder($winhandle,0,0,0,0,0,0,0,0);
while ($ch <> ord('e')) {
$ch = ncurses_wgetch($winhandle);
ncurses_wmove($winhandle, $j++, 1);
ncurses_waddstr($winhandle, "key --$ch--");
}
}
}
ncurses_end();
?>
--
Edit this bug report at http://bugs.php.net/?id=21068&edit=1
#21074 [NEW]: PHP doesn't work with 401 (Auth) ErrorDocument and Apache2
From: [EMAIL PROTECTED] Operating system: Windows XP PHP version: 4.3.0RC3 PHP Bug Type: Apache2 related Bug description: PHP doesn't work with 401 (Auth) ErrorDocument and Apache2 Whenever I use a .php-file as a 401 ErrorDocument, Apache2 fails and shows the file specified as ErrorDocument. My .htaccess contains ErrorDocument 401 /error.php This absolutely works with Apache 1.3.27, but not with ANY Apache 2.0.x. This also still occurs with PHP 4.3RC3. -- Edit bug report at http://bugs.php.net/?id=21074&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21074&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21074&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21074&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21074&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21074&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21074&r=support Expected behavior: http://bugs.php.net/fix.php?id=21074&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21074&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21074&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21074&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21074&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21074&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21074&r=isapi
#21073 [NEW]: linking "configure --with-sapdb" failed
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.3 PHP Bug Type: Compile Failure Bug description: linking "configure --with-sapdb" failed After "./configure --with-sapdb=" the make run ends in : /bin/sh /home/remuser/ttk/php-4.2.3/libtool --silent --mode=link gcc -I. -I/home/remuser/ttk/php-4.2.3/ -I/home/remuser/ttk/php-4.2.3/main -I/home/remuser/ttk/php-4.2.3 -I/home/remuser/ttk/php-4.2.3/Zend -I/home/remuser/ttk/php-4.2.3/ext/mysql/libmysql -I/home/remuser/ttk/odbc_7.3.0.28//incl -I/home/remuser/ttk/php-4.2.3/ext/xml/expat -I/home/remuser/ttk/php-4.2.3/TSRM -g -O2 -o php -export-dynamic stub.lo libphp4.la /usr/i486-suse-linux/bin/ld: cannot find -lsqlrte collect2: ld returned 1 exit status make[1]: *** [php] Error 1 The problem is that entries regarding sqlrte in ./configure and ./ext/odbc/config.m4 for SAP DB are wrong. Following patches fix the problem: patch for ./configure: *** configure.orig Wed Dec 18 10:08:58 2002 --- configure Wed Dec 18 10:08:52 2002 *** *** 42171,42186 esac - case sqlrte in - c|c_r|pthread*) ;; - *) - - - LIBS="-lsqlrte $LIBS" - - - ;; - esac ODBC_TYPE=sapdb cat >> confdefs.h <<\EOF --- 42171,42176 patch for ./ext/odbc/config.m4: *** config.m4.orig Mon Mar 4 10:10:31 2002 --- config.m4 Wed Dec 18 11:48:43 2002 *** *** 135,141 PHP_ADD_INCLUDE($withval/incl) PHP_ADD_LIBPATH($withval/lib) PHP_ADD_LIBRARY(sqlod) - PHP_ADD_LIBRARY(sqlrte) ODBC_TYPE=sapdb AC_DEFINE(HAVE_SAPDB,1,[ ]) AC_MSG_RESULT(yes) --- 135,140 Regards Thomas -- Edit bug report at http://bugs.php.net/?id=21073&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21073&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21073&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21073&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21073&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21073&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21073&r=support Expected behavior: http://bugs.php.net/fix.php?id=21073&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21073&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21073&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21073&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21073&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21073&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21073&r=isapi
#21054 [Com]: 'ob_gzhandler' cannot be used twice???
ID: 21054 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Suspended Bug Type: Output Control Operating System: Redhat 7.2 PHP Version: 4.3.0RC3 New Comment: The same message appears if I place in the begining of the any php script. (W2kPro SP2, PHP4.3.0RC2, Apache 2.0.43) Previous Comments: [2002-12-16 15:56:49] [EMAIL PROTECTED] It's a pretty useless bugreport like this. Suspended until you can profile some real useful information to reproduce this problem. [2002-12-16 15:52:45] [EMAIL PROTECTED] I don't know if it's a particular script to cause the warning, the log don't tell me anything Other informations: Apache: 2.0.43 PHP: 4.3.0RC3 Zend Optimizer: 2.0.3 Configure: './configure' '--enable-track-vars' '--prefix=/usr' '--exec-prefix=/usr' '--libexecdir=/usr/lib/apache' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--datadir=/home/httpd' '--sysconfdir=/etc/httpd/conf' '--localstatedir=/var' '--libdir=/usr/lib/apache' '--includedir=/usr/include/apache' '--mandir=/usr/man' '--with-mysql=/usr' '--with-config-file-path=/usr/local/Zend/etc' '--enable-memory-limit' '--with-apxs2' '--with-zlib' '--disable-session' [2002-12-16 15:45:29] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-12-16 15:44:55] [EMAIL PROTECTED] Sometimes (it seems random) I find in the error_log this fatal error: PHP Warning: (null)() [ref.outcontr ol]: output handler 'ob_gzhandler' cannot be used twice in Unknown on line 0 Repeated 4 times. I haven't activated gz_handler in php.ini and it's not activated in virtaulhosts, I don't set in scripts. I'm not using it, why it tells me that I use it TWICE? Andrea Busia -- Edit this bug report at http://bugs.php.net/?id=21054&edit=1
#18359 [Com]: PHP module seem to make trouble with authentication under Apache 2
ID: 18359 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Apache2 related Operating System: Windows 2000 PHP Version: 4.2.1 New Comment: The problem still exists. Whenever I use a .php-file as Errordocument for 401, authentification failes and directly shows the .php-file. Static html works. Previous Comments: [2002-08-26 01:00:09] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-08-08 18:20:27] [EMAIL PROTECTED] Sorry, forgot to say: apache 2.0.39 php 4.2.2 FreeBSD 4.6-STABLE [2002-08-08 18:16:42] [EMAIL PROTECTED] same thing happens to me, commenting out # ErrorDocument 401 /errors/401.php works around the problem [2002-07-25 11:07:38] [EMAIL PROTECTED] Sir, by ht-files I actually mean .htaccess-files... :-) My Problem is exactly the same and it REALLY suxx! [2002-07-25 09:23:03] [EMAIL PROTECTED] My problem isn't with PHP authentication, but with .htaccess files. If PHP is not loaded, they work, but if it is loaded, I automatically get a 401 error. But if I use PHP authentication ($_SERVER["PHP_AUTH_USER"], $_SERVER["PHP_AUTH_PW"]) it works perfectly, but I want .htaccess files to work correctly... 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/18359 -- Edit this bug report at http://bugs.php.net/?id=18359&edit=1
#21072 [Opn->Bgs]: php not working for other folders other than the root
ID: 21072 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: win2k + SP3 PHP Version: 4.2.3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Previous Comments: [2002-12-17 23:48:24] [EMAIL PROTECTED] i create an alias for gallery folder in htpdconf like this Alias /gallery "C:/gallery" AllowOverride Options FileInfo Order allow,deny Allow from all and when I am trying to access phpinfo.php (http://IP/gallery/setup/phpinfo.php) which is in c:/gallery/setup/phpinfo.php it ggives me this error in error log file PHP Fatal error: Unable to open C:/Program Files/Apache Group/Apache2/htdocs/gallery/setup/phpinfo.php in Unknown on line 0 if i try to access the same file from htdocs everything works perfect, I dont understand why its not workin for the gallery folder! -- Edit this bug report at http://bugs.php.net/?id=21072&edit=1
#20802 [Com]: memory limit crash
ID: 20802 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Scripting Engine problem Operating System: Redhat 7.0 PHP Version: 4.3.0RC2 New Comment: I have the same problem with PHP 4.2.3 on SPARC Solaris 2.7. My program is very complex and I cannot provide simple script to reproduce it. It seems to be hitting default 8 mb memory at random points in the code when it processed enough data. But instead of reporting an error, PHP engine just dies and re-starts execution of the script from the very beginning (!). No records in the logs. PHP is running as Apache 1.3.26 module. Previous Comments: [2002-12-13 07:24:57] [EMAIL PROTECTED] I'm having the same problem with PHP 4.3RC3 with Apache 2.0.43 running with the perchild MPM. After the crash occours, apache does not accept any more connections, even though there are other processes that could handle them, and I'm required to restart it. Here are some outputs from ps and top, before and after the crash, perhaps it will be usefull with something: /* I've pasted only the part that shows the "root" process, and a single child with its accompanying threads; there are 4 more children (with their threads), but they are similar and their state doesn't change */ (1) "ps ax --forest" before 3541 ?S 0:00 /opt/httpd-2.0.43/bin/httpd -k start 3542 ?S 0:00 \_ /opt/httpd-2.0.43/bin/httpd -k start 3545 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k start 3546 ?S 0:38 | \_ /opt/httpd-2.0.43/bin/httpd -k start 3549 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k start 3550 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k start 3556 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k start 3561 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k start 3578 ?S 0:00 | \_ /opt/httpd-2.0.43/bin/httpd -k start (2) "ps ax --forest" before 3541 ?S 0:00 /opt/httpd-2.0.43/bin/httpd -k start 3542 ?S 0:00 \_ /opt/httpd-2.0.43/bin/httpd -k start 3545 ?Z 0:00 | \_ [httpd ] (3) "top" output after the crash PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ Command PPID nFLT nDRT WCHAN Flags 3542 httpd 9 0 58028 56m 4972 S 0.0 7.5 0:00.00 /opt/httpd- 35411 13k rt_sigsus .14. 3545 httpd 8 0 000 Z 0.0 0.0 0:00.04 ( httpd , argc=3, argv=0xbfffe944, init=0x80792f8 <_init>, fini=0x826c8f4 <_fini>, rtld_fini=0x4000a914 <_dl_fini>, stack_end=0xbfffe93c) at ../sysdeps/generic/libc-start.c:92 [2002-12-04 00:33:07] [EMAIL PROTECTED] Veryfied with PHP 4.4.0-dev (Nov 29 2002) and PHP 4.3.0-dev (Nov 25 2002). With both versions the script just ended without any error message, but there is no segmentation fault. Derick [2002-12-03 16:12:50] [EMAIL PROTECTED] I have a php installation with a memory limit set to 8MB. If I try to run this script I don't receive an error like "memory limit excedeed" (10MB > 8MB), simply the server kills the connection without any error on the screen or in the logs. Server configuration: Linux Redhat 7.0 Apache 1.3.22 PHP 4.3.0RC2 Zend Optimizer 2.0.3 Mysql 4.0.5 Configure: './configure' '--enable-track-vars' '--prefix=/usr' '--exec-prefix=/usr' '--libexecdir=/usr/lib/apache' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--datadir=/home/httpd' '--sysconfdir=/etc/httpd/conf' '--localstatedir=/var' '--libdir=/usr/lib/apache' '--includedir=/usr/include/apache' '--mandir=/usr/man' '--with-mysql=/usr' '--enable-memory-limit' '--with-config-file-path=/usr/local/Zend/etc' '--with-apxs' '--with-zlib' -- Edit this bug report at http://bugs.php.net/?id=20802&edit=1
