#33093 [Opn->Fbk]: token_get_all() inconsistent results?
ID: 33093
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: Mac OS X 10.4.1
PHP Version: 5.0.4
New Comment:
wheres the missing data?
php -r 'var_dump(token_get_all(""));'
array(6) {
[0]=>
array(2) {
[0]=>
int(366)
[1]=>
string(6) "
array(2) {
[0]=>
int(316)
[1]=>
string(4) "echo"
}
[2]=>
array(2) {
[0]=>
int(369)
[1]=>
string(1) " "
}
[3]=>
array(2) {
[0]=>
int(309)
[1]=>
string(4) "$var"
}
[4]=>
array(2) {
[0]=>
int(369)
[1]=>
string(1) " "
}
[5]=>
array(2) {
[0]=>
int(368)
[1]=>
string(2) "?>"
}
}
php -r 'var_dump(token_get_all(""));'
array(7) {
[0]=>
array(2) {
[0]=>
int(366)
[1]=>
string(6) "
array(2) {
[0]=>
int(369)
[1]=>
string(1) "
"
}
[2]=>
array(2) {
[0]=>
int(316)
[1]=>
string(4) "echo"
}
[3]=>
array(2) {
[0]=>
int(369)
[1]=>
string(1) " "
}
[4]=>
array(2) {
[0]=>
int(309)
[1]=>
string(4) "$var"
}
[5]=>
array(2) {
[0]=>
int(369)
[1]=>
string(1) "
"
}
[6]=>
array(2) {
[0]=>
int(368)
[1]=>
string(2) "?>"
}
Previous Comments:
[2005-05-21 18:40:38] [EMAIL PROTECTED]
Description:
It appears that token_get_all() does not report T_OPEN_TAG and
T_WHITESPACE properly, depending on the whitespace following the
opening tag. For example, when parsing ...
... you get T_OPEN_TAG, T_ECHO, T_WHITESPACE, T_VAR, T_WHITESPACE, and
T_CLOSE_TAG. This is not entirely the expected result (I would expect
T_WHITESPACE between the open tag and the echo).
However, when parsing the functional equivalent...
you get "<", "?", T_STRING ("php"), T_WHITESPACE, T_ECHO, T_WHITESPACE,
T_VAR, T_WHITESPACE, and T_CLOSE_TAG. In addition, the first whitespace
value reported does not include all the newlines (it drops one).
Although Macs use \r for their newlines natively, the test code uses
the Unix-standard \n, so I don't think it's Mac-related.
If this is in fact a bug, the current behavior makes it difficult to
write a reliable userland code auditor and report proper line numbers.
Am I missing some assumptions behind the behavior of the tokenizer
function?
--
Edit this bug report at http://bugs.php.net/?id=33093&edit=1
#33093 [Fbk]: token_get_all() inconsistent results?
ID: 33093
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Unknown/Other Function
Operating System: Mac OS X 10.4.1
PHP Version: 5.0.4
New Comment:
Actually the tokenizer just plugs into the internal tokenize code used
by the engine. As such, the engine doesnt need to know some
information, and is written to work as quickly and effeciently as
possible, rather than being 100% dead on for parsing.
It's unlikely to be fixed just for token_get_all(), as introducing
changes can have quite radical effects sometimes when touching that bit
of code.
The values with the tokens should enable you to get the CR/LF count
ok..
Previous Comments:
[2005-05-22 05:51:20] [EMAIL PROTECTED]
wheres the missing data?
php -r 'var_dump(token_get_all(""));'
array(6) {
[0]=>
array(2) {
[0]=>
int(366)
[1]=>
string(6) "
array(2) {
[0]=>
int(316)
[1]=>
string(4) "echo"
}
[2]=>
array(2) {
[0]=>
int(369)
[1]=>
string(1) " "
}
[3]=>
array(2) {
[0]=>
int(309)
[1]=>
string(4) "$var"
}
[4]=>
array(2) {
[0]=>
int(369)
[1]=>
string(1) " "
}
[5]=>
array(2) {
[0]=>
int(368)
[1]=>
string(2) "?>"
}
}
php -r 'var_dump(token_get_all(""));'
array(7) {
[0]=>
array(2) {
[0]=>
int(366)
[1]=>
string(6) "
array(2) {
[0]=>
int(369)
[1]=>
string(1) "
"
}
[2]=>
array(2) {
[0]=>
int(316)
[1]=>
string(4) "echo"
}
[3]=>
array(2) {
[0]=>
int(369)
[1]=>
string(1) " "
}
[4]=>
array(2) {
[0]=>
int(309)
[1]=>
string(4) "$var"
}
[5]=>
array(2) {
[0]=>
int(369)
[1]=>
string(1) "
"
}
[6]=>
array(2) {
[0]=>
int(368)
[1]=>
string(2) "?>"
}
[2005-05-21 18:40:38] [EMAIL PROTECTED]
Description:
It appears that token_get_all() does not report T_OPEN_TAG and
T_WHITESPACE properly, depending on the whitespace following the
opening tag. For example, when parsing ...
... you get T_OPEN_TAG, T_ECHO, T_WHITESPACE, T_VAR, T_WHITESPACE, and
T_CLOSE_TAG. This is not entirely the expected result (I would expect
T_WHITESPACE between the open tag and the echo).
However, when parsing the functional equivalent...
you get "<", "?", T_STRING ("php"), T_WHITESPACE, T_ECHO, T_WHITESPACE,
T_VAR, T_WHITESPACE, and T_CLOSE_TAG. In addition, the first whitespace
value reported does not include all the newlines (it drops one).
Although Macs use \r for their newlines natively, the test code uses
the Unix-standard \n, so I don't think it's Mac-related.
If this is in fact a bug, the current behavior makes it difficult to
write a reliable userland code auditor and report proper line numbers.
Am I missing some assumptions behind the behavior of the tokenizer
function?
--
Edit this bug report at http://bugs.php.net/?id=33093&edit=1
#33098 [NEW]: mysql_fetch_array(mysql_query("mysql query here")) crashes
From: tloudimm at go2 dot pl
Operating system: Linux
PHP version: 4.3.11
PHP Bug Type: MySQL related
Bug description: mysql_fetch_array(mysql_query("mysql query here")) crashes
Description:
hi there. i found a bug [well, i think it's a bug, it onced crashed my
apache server].. found it in 4.3.10 first, than in 4.3.11 again. anyway,
here's some sample code:
however
i searched bug database and found nothing like my observations. sorry if i
make too much mess - delete my report if so :) greetings.
--
Edit bug report at http://bugs.php.net/?id=33098&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33098&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33098&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33098&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33098&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33098&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33098&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33098&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33098&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33098&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33098&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33098&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33098&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33098&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33098&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33098&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33098&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33098&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33098&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33098&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33098&r=mysqlcfg
#32810 [Asn]: fread after tmpfile() reads only 8192 bytes
ID: 32810 Updated by: [EMAIL PROTECTED] Reported By: matteo at beccati dot com Status: Assigned Bug Type: Filesystem function related Operating System: * PHP Version: 5CVS, 4CVS (2005-04-24) Assigned To: wez New Comment: php5-win32-200505191430 is still suffering from this. Previous Comments: [2005-04-24 16:40:51] [EMAIL PROTECTED] Wez breaks, Wez fixes. (Streams stuff broke this) [2005-04-24 16:04:54] matteo at beccati dot com Description: In recent PHP versions, fread only reads 8192 bytes from a file generated with tmpfile(). I've already seen bug reports #29023 and #30936 which seem strongly related to this issue. From what I can see, fread on local files isn't limited to the PHP chunk size of 8192, while a fread on a tmpfile acts like it was i.e. a network stream, breaking backwards compatibility. I found out this issue investigating a recently reported bug for phpAdsNew, which uses this function to deal with remote ftp-stored files. IMVHO this can be considered a bug in in the tmpfile() implementation. If you don't agree, well... I suggest to mark it as a documentation bug, because I couldn't find nothing related to the 8192 bytes limit in the manual. Versions/OS tested and affected: PHP 4.3.10 Linux PHP 4.3.11 FreeBSD and Windows PHP 5.0.4 Windows Versions/OS tested and unaffected: PHP 4.3.4 Windows Reproduce code: --- Expected result: Bytes written: 10 Bytes read:10 Actual result: -- Bytes written: 10 Bytes read:8192 -- Edit this bug report at http://bugs.php.net/?id=32810&edit=1
#29023 [Csd->Opn]: fread() only reads 8192 bytes from a local file
ID: 29023 Updated by: [EMAIL PROTECTED] Reported By: benjcarson at digitaljunkies dot ca -Status: Closed +Status: Open Bug Type: Filesystem function related Operating System: Linux PHP Version: 5CVS-2004-07-05 (dev) Assigned To: wez New Comment: I think there are a couple dupes (#32810, #32469, maybe even #30441) of this one. And on a recent win head snapshot it was still broken: php5-win32-200505191430 Previous Comments: [2004-07-10 12:57:28] [EMAIL PROTECTED] This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. [2004-07-06 16:42:38] benjcarson at digitaljunkies dot ca While I realize that file_get_contents() is faster, the code that lead me to this bug was not my own. It was Smarty (2.6.2, although 2.6.3 has the same problem), which has worked very well with PHP5 until now. [2004-07-06 15:26:51] [EMAIL PROTECTED] I really can't see how this can be CORRECT behaviour as this has worked (like it says in docs too :) before just fine. OTOH, you should always use file_get_contents() instead anyway. :) [2004-07-06 09:14:52] [EMAIL PROTECTED] Assigning to Wez... although I'd say that this is *correct* behavior, it shouldn't cause a BC break. [2004-07-05 22:28:48] benjcarson at digitaljunkies dot ca Description: In the latest cvs snap, fread() does not read more than 8192 bytes from a local file, despite specifying a larger read size as the second parameter. If the fread() call is wrapped in a while (!feof) loop the file can be read correctly, but only 8k at a time. This contradicts the first example in the manual (http://www.php.net/manual/en/function.fread.php) and is a BC break. As far as I can tell the change was made sometime between the 2004-06-22 snap and the 2004-07-04 snap. I've tested both using my php.ini file and without (i.e. using the built-in defaults). I configured using the following command: ./configure --prefix=/usr --with-apxs=/usr/bin/apxs \ --enable-memory-limit \ --with-layout-GNU\ --enable-bcmath \ --enable-calendar \ --with-curl=/usr \ --enable-exif \ --enable-ftp \ --enable-mbstring \ --enable-shmop \ --enable-sockets \ --enable-sysvsem \ --enable-sysvshm \ --enable-wddx \ --with-bz2 \ --with-config-file-path=/etc/php5/apache \ --with-gd=/usr \ --with-freetype-dir=shared,/usr \ --with-jpeg-dir=/usr \ --with-png-dir=shared,/usr \ --with-ttf=shared,/usr \ --with-xpm-dir=shared,/usr/X11R6 \ --with-gettext \ --with-kerberos=/usr \ --with-ldap=shared,/usr \ --with-mhash=shared,/usr \ --with-mm \ --with-ncurses=/usr \ --with-openssl=/usr \ --with-pcre-regex=/usr \ --with-pear \ --with-pgsql \ --with-pspell=/usr \ --with-zlib \ --with-zlib-dir=/usr Reproduce code: --- #!/usr/bin/php Expected result: (the file's actual size, in bytes) Actual result: -- 8192 -- Edit this bug report at http://bugs.php.net/?id=29023&edit=1
#32851 [Com]: open_basedir restrictions do not work with file creation in symlinked directory
ID: 32851
Comment by: aarong at thinkcomputer dot com
Reported By: stegelmann at rz dot rwth-aachen dot de
Status: Open
Bug Type: Safe Mode/open_basedir
Operating System: SunOS 5.8
PHP Version: 5.0.4, 4.3.11
New Comment:
I'm often getting open_basedir errors where I shouldn't, when writing
to a path where the file already exists:
Warning: fopen(): open_basedir restriction in effect.
File(/home/sites/www.thinkcomputer.com/web/index.html) is not within
the allowed path(s):
(/home/sites/www.thinkcomputer.com/web:/home/think/lampshade:/home/think/whiteboard:/home/think/mail:/home/think/phpmyadmin:/tmp)
in /home/think/whiteboard/shared/shared.inc.php on line 565
In this case, the warning is simply wrong:
/home/sites/www.thinkcomputer.com/web/index.html *is* within the
allowed path /home/sites/www.thinkcomputer.com/web. Furthermore,
/home/sites/www.thinkcomputer.com is a symlink to /home/sites/site1,
but putting /home/sites/site1 in the open_basedir allowed path listing
doesn't change anything except the literal text of the error. Adding
trailing slashes also doesn't help. Maybe I'm missing something here,
but this seems like a bug... I'm running 4.3.11 on Apache 1.3.33.
Previous Comments:
[2005-04-28 00:06:15] stegelmann at rz dot rwth-aachen dot de
I've read the documentation. At the risk of repeating myself:
If the symlink was resolved - I would expect at least one of the given
open_basedirs to match (as both possibilities are specified - resolved
and unresolved).
If this is not the intended way it should work, why is there a
difference between creating a new and opening an existing file (as
opening an existing file in the symlinked directory works, while
creating a new file fails)?
[2005-04-27 23:28:23] [EMAIL PROTECTED]
This is expected behaviour and it's documented in the docs:
"When a script tries to open a file with, for example, fopen() or
gzopen(), the location of the file is checked. When the file is outside
the specified directory-tree, PHP will refuse to open it. All symbolic
links are resolved, so it's not possible to avoid this restriction with
a symlink."
http://www.php.net/manual/en/features.safe-mode.php
Pay attentions to the last sentence.
[2005-04-27 14:45:30] stegelmann at rz dot rwth-aachen dot de
To perhaps clarify - after the file was created with your code:
$f = fopen("/export2/home/websites/it/test", "w");
the previously unsuccessful attempt:
$f = fopen("/export/home/websites/it/test", "w");
does work (as I mentioned in the initial report).
So just the file's creation fails in combination with the symlink.
[2005-04-27 14:29:51] stegelmann at rz dot rwth-aachen dot de
$f = fopen("/export2/home/websites/it/test", "w");
does work.
[2005-04-27 12:59:39] [EMAIL PROTECTED]
Does this work:
$f = fopen("/export2/home/websites/it/test", "w");
ie. writing to the actual directory..?
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/32851
--
Edit this bug report at http://bugs.php.net/?id=32851&edit=1
#33097 [Fbk]: OCI_Password_Change fails to change password
ID: 33097
Updated by: [EMAIL PROTECTED]
Reported By: dboeke at eesus dot jnj dot com
Status: Feedback
Bug Type: OCI8 related
Operating System: Win2k Server ver 5.0.2195 SP4
PHP Version: 5.0.4
New Comment:
And please try to use oci_password_change() with your locally installed
Oracle.
Previous Comments:
[2005-05-21 23:10:13] [EMAIL PROTECTED]
And what happens if you try to change the password using sqlplus (but
not with "alter user" command) ?
[2005-05-21 22:20:56] dboeke at eesus dot jnj dot com
Description:
I am using the binary download of php 5.04 for win32 platforms. It is
running as a CGI under Apache/2.0.52. The only extension that I have
loaded is php_oci8.dll [Revision: 1.257.2.6]
The Windows 2000 Server that PHP is running on has the Oracle9i
9.2.0.1.0 Server and Client installed.
The Oracle server that we are connecting to is running Oracle 8i
Enterprise 8.1.7.2.0 on Unix. This server has complexity rules set
(minimum password length of 6 and passwords must have 3 levels of
complexity: letters, numbers and special chars)
We created a webpage for users to be able to change their oracle
password. It has worked for almost all users. However, we have a user
that had a password: Ddnn!$52
He was unable to change the password, even though he could logon to
oracle through SqlPlus with the password. The OCI_Change_Password
function returned the oracle error: ORA-28008: invalid old password.
This means that the PHP script successfully authenticated him using
$conn=oci_new_connect($userID, $oldPwd, $oraSid); function but the
oci_password_change($conn, $userID, $oldPwd, $newPwd); using the same
variable values was unable to properly authenticate to oracle?
Also, I discovered while I was testing, that when I changed my password
(using the webform) to Ddnn!$52, that I could no longer log into oracle
via any means. It seems like the value of the old/new password is
possibly being changed by the oci_password_change function.
Reproduce code:
---
'Success') : oci_error($conn);
@oci_close($conn);
} else { $e = oci_error(); }
} else { $e = array('message'=>'Please Change Your Password'); }
echo"\n\n\tOCI Change Pwd
Test\n\n\n" .
"\n" . $e['message'] . "\n" .
"Oracle Instance: \n"
.
"User Name: \n" .
"Current Password: \n" .
"New Password: \n" .
"\n"
.
"\n\n\n\n";
?>
Expected result:
Password changed with no error if user submitted the correct password
information.
Actual result:
--
ORA-28008: invalid old password
--
Edit this bug report at http://bugs.php.net/?id=33097&edit=1
#33097 [Opn->Fbk]: OCI_Password_Change fails to change password
ID: 33097
Updated by: [EMAIL PROTECTED]
Reported By: dboeke at eesus dot jnj dot com
-Status: Open
+Status: Feedback
Bug Type: OCI8 related
Operating System: Win2k Server ver 5.0.2195 SP4
PHP Version: 5.0.4
New Comment:
And what happens if you try to change the password using sqlplus (but
not with "alter user" command) ?
Previous Comments:
[2005-05-21 22:20:56] dboeke at eesus dot jnj dot com
Description:
I am using the binary download of php 5.04 for win32 platforms. It is
running as a CGI under Apache/2.0.52. The only extension that I have
loaded is php_oci8.dll [Revision: 1.257.2.6]
The Windows 2000 Server that PHP is running on has the Oracle9i
9.2.0.1.0 Server and Client installed.
The Oracle server that we are connecting to is running Oracle 8i
Enterprise 8.1.7.2.0 on Unix. This server has complexity rules set
(minimum password length of 6 and passwords must have 3 levels of
complexity: letters, numbers and special chars)
We created a webpage for users to be able to change their oracle
password. It has worked for almost all users. However, we have a user
that had a password: Ddnn!$52
He was unable to change the password, even though he could logon to
oracle through SqlPlus with the password. The OCI_Change_Password
function returned the oracle error: ORA-28008: invalid old password.
This means that the PHP script successfully authenticated him using
$conn=oci_new_connect($userID, $oldPwd, $oraSid); function but the
oci_password_change($conn, $userID, $oldPwd, $newPwd); using the same
variable values was unable to properly authenticate to oracle?
Also, I discovered while I was testing, that when I changed my password
(using the webform) to Ddnn!$52, that I could no longer log into oracle
via any means. It seems like the value of the old/new password is
possibly being changed by the oci_password_change function.
Reproduce code:
---
'Success') : oci_error($conn);
@oci_close($conn);
} else { $e = oci_error(); }
} else { $e = array('message'=>'Please Change Your Password'); }
echo"\n\n\tOCI Change Pwd
Test\n\n\n" .
"\n" . $e['message'] . "\n" .
"Oracle Instance: \n"
.
"User Name: \n" .
"Current Password: \n" .
"New Password: \n" .
"\n"
.
"\n\n\n\n";
?>
Expected result:
Password changed with no error if user submitted the correct password
information.
Actual result:
--
ORA-28008: invalid old password
--
Edit this bug report at http://bugs.php.net/?id=33097&edit=1
#33097 [NEW]: OCI_Password_Change fails to change password
From: dboeke at eesus dot jnj dot com
Operating system: Win2k Server ver 5.0.2195 SP4
PHP version: 5.0.4
PHP Bug Type: OCI8 related
Bug description: OCI_Password_Change fails to change password
Description:
I am using the binary download of php 5.04 for win32 platforms. It is
running as a CGI under Apache/2.0.52. The only extension that I have
loaded is php_oci8.dll [Revision: 1.257.2.6]
The Windows 2000 Server that PHP is running on has the Oracle9i 9.2.0.1.0
Server and Client installed.
The Oracle server that we are connecting to is running Oracle 8i
Enterprise 8.1.7.2.0 on Unix. This server has complexity rules set
(minimum password length of 6 and passwords must have 3 levels of
complexity: letters, numbers and special chars)
We created a webpage for users to be able to change their oracle password.
It has worked for almost all users. However, we have a user that had a
password: Ddnn!$52
He was unable to change the password, even though he could logon to oracle
through SqlPlus with the password. The OCI_Change_Password function
returned the oracle error: ORA-28008: invalid old password.
This means that the PHP script successfully authenticated him using
$conn=oci_new_connect($userID, $oldPwd, $oraSid); function but the
oci_password_change($conn, $userID, $oldPwd, $newPwd); using the same
variable values was unable to properly authenticate to oracle?
Also, I discovered while I was testing, that when I changed my password
(using the webform) to Ddnn!$52, that I could no longer log into oracle
via any means. It seems like the value of the old/new password is
possibly being changed by the oci_password_change function.
Reproduce code:
---
'Success') : oci_error($conn);
@oci_close($conn);
} else { $e = oci_error(); }
} else { $e = array('message'=>'Please Change Your Password'); }
echo"\n\n\tOCI Change Pwd
Test\n\n\n" .
"\n" . $e['message'] . "\n" .
"Oracle Instance: \n" .
"User Name: \n" .
"Current Password: \n" .
"New Password: \n" .
"\n" .
"\n\n\n\n";
?>
Expected result:
Password changed with no error if user submitted the correct password
information.
Actual result:
--
ORA-28008: invalid old password
--
Edit bug report at http://bugs.php.net/?id=33097&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33097&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33097&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33097&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33097&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33097&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33097&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33097&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33097&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33097&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33097&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33097&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33097&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33097&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33097&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33097&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33097&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33097&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33097&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33097&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33097&r=mysqlcfg
#33072 [Asn->Csd]: session_save_path bypass safe_mode restriction
ID: 33072
Updated by: [EMAIL PROTECTED]
Reported By: andrey at ruweb dot net
-Status: Assigned
+Status: Closed
Bug Type:Safe Mode/open_basedir
PHP Version: 5.0.4, 4.3.11
Assigned To: rasmus
New Comment:
Fixed in CVS
Previous Comments:
[2005-05-21 19:20:41] [EMAIL PROTECTED]
Testing a fix now
[2005-05-21 17:13:51] zxqc2 at dunc dot com dot au
session_save_path also does not perform the open_basedir check.
It does seem reasonable to allow access to the default
session.save_path set by the ISP (even if not within the allowable
open_basedir path) - which PHP does allow.
However when a script attempts to change it through
session_save_path(...) it would make sense to perform this check to
prevent access to session directories of other virtual hosts.
I am aware that similar issues have been discussed before, and also
that there are better ways to secure sessions, but I thought I'd
mention it here for the record.
[2005-05-19 23:21:34] andrey at ruweb dot net
Description:
(Sorry, I didn't found any reports about that issue. Can't believe
nobody reported this yet!)
ini_set('session.save_path','...') works great - it produces an error
when user is trying to set session.save_path to directory owned by
another user.
But why session_save_path doesn't perform safe_mode checks?
For now with session_save_path any server user can quietly substitute
session contents at any site located at the same server if he knows the
path to directory where that site's session files stored. :(
--
Edit this bug report at http://bugs.php.net/?id=33072&edit=1
#33095 [NEW]: pspell stops working under increased load
From: mkellogg at wordreference dot com
Operating system: Windows 2003
PHP version: 4.3.11
PHP Bug Type: Pspell related
Bug description: pspell stops working under increased load
Description:
I have tried this under IIS and Apache on Windows 2003. The script works
fine in testing, but once I put it in production on the server, it stops
working within a few minutes.
Using latest version of Aspell 0.50.3
Reproduce code:
---
http://forum.wordreference.com/wr_spelling/iframe5.txt
pspell_config_create("en");
$pspell_link = pspell_new("en","","","", PSPELL_FAST);
if (!pspell_check($pspell_link, $_GET['word'])) {
$suggestions = pspell_suggest($pspell_link, $_GET['word']);
foreach ($suggestions as $key => $suggestion) {
echo "$suggestion";
}
}
?>
Expected result:
Spelling suggestions. :)
Actual result:
--
User: A page that hangs.
Apache's error message:
PHP Warning: PSPELL couldn't open the dictionary. reason: No word lists
can be found for the language "en". in C:\\Program Files\\Apache
Group\\Apache2\\htdocs\\iframe5.php on line 4
Apache often crashes as a result, too.
IIS error message as seen by Firefox users:
PHP has encountered an Access Violation at ...
--
Edit bug report at http://bugs.php.net/?id=33095&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33095&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33095&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33095&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33095&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33095&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33095&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33095&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33095&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33095&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33095&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33095&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33095&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33095&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33095&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33095&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33095&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33095&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33095&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33095&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33095&r=mysqlcfg
#32330 [Asn]: session_destroy, "Failed to initialize storage module", custom session handler
ID: 32330 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Session related Operating System: * PHP Version: 5CVS, 4CVS (2005-03-17) Assigned To: sniper New Comment: I think you are on the right track mfischer. It looks like PS(mod) and PS(mod_data) can get out of synch which would cause this. And I think all the others with seemingly unrelated issues are actually related. If PS(mod_data) leaks out of the per-request sandbox and infects subsequent requests all it takes is one application on a server to use its own session handler and it could affect other seemingly trivial standalone session apps on that server. Previous Comments: [2005-05-19 14:09:55] lekhoi at lekhoi dot com dot au I use Window XP -- running Apache SQLite version 2.8.14 PHP version 5.0.4 and am experiencing the same problem of PHP reporting error when calling session_start() I have never have this problem before. However, I am using SQLiteManager ver 1.0.6 and during the development stage I came across this problem. This problem occurs quite randomly specially when I try to modify the database structure or have troubled sql statement. It feels and sounds like a memory leak problem with SQLite functions. I have to stress that I come across this only when using SQLiteManager. I have used and configured session using SQLite as the database for sessions storing and never have a problem. To fix this, I restart Apache, and it works everytime. [2005-05-17 21:01:39] semorales at segob dot gob dot mx Any notice about this bug? I'm thinking about using the handler but I'm afraid it will crash my server. Please let me know. [2005-04-30 11:31:53] dmih at in-solve dot ru I've added several notes as this bug (marked as bogus): http://bugs.php.net/bug.php?id=32897 Please consider them, as it seems that it is about this bug really. Thanks. [2005-04-19 07:37:14] labsy at seznam dot org Since this bug is non-persistent, it is very hard to reproduce. Now, since I run PHP 5.0.2 as ISAPI module, I did a change and added php5isapi.dll also as ISAPI FILTER under web site properties in IIS. I don't have a slight idea what would that change, but it seems to solve problem - I hope. [2005-04-19 07:18:46] labsy at seznam dot org I was experiencing this problem one year ago, but now it reoccured. I run PHP 5.0.2 on Win 2000/IIS I act as WebHosting provider, host about 170 domains. Now, one thing that attracted my attention was, that one of my users installed osCommerce portal few days ago. Since osCommerce handles sessions its own way, it seems to corrupt session handling function in PHP all over my server. Any file which has session_start() at the beginning, needs to be loaded twice, first attempt to load page produces the mentioned error, but after reload session initializes normally. I have session.save_handler = files session.save_path = "C:\PHP\sessiondata" ;this dir is world writeable All my PHP files only use session_start() and $_SESSION[] variable cals, no other session functions are used. It worked fine, until one of my users installed osCommerce portal. 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/32330 -- Edit this bug report at http://bugs.php.net/?id=32330&edit=1
#33094 [Opn->WFx]: Too deep recursion leads to segfault
ID: 33094 Updated by: [EMAIL PROTECTED] Reported By: manager at mirchevideas dot com -Status: Open +Status: Wont fix Bug Type: Reproducible crash Operating System: Linux PHP Version: 4.3.10 New Comment: Search the bug database before submitting new reports. Previous Comments: [2005-05-21 18:42:04] manager at mirchevideas dot com Description: Segfault of the httpd server Reproduce code: --- '; flush(); test($level+1); } ?> Expected result: Fatal error : Nesting level too deep - recursive dependency? Actual result: -- Going up to ~21000 and then just stopping to print. This is because it segfaulted. -- Edit this bug report at http://bugs.php.net/?id=33094&edit=1
#33072 [Opn->Asn]: session_save_path bypass safe_mode restriction
ID: 33072
Updated by: [EMAIL PROTECTED]
Reported By: andrey at ruweb dot net
-Status: Open
+Status: Assigned
Bug Type:Safe Mode/open_basedir
PHP Version: 5.0.4, 4.3.11
-Assigned To:
+Assigned To: rasmus
New Comment:
Testing a fix now
Previous Comments:
[2005-05-21 17:13:51] zxqc2 at dunc dot com dot au
session_save_path also does not perform the open_basedir check.
It does seem reasonable to allow access to the default
session.save_path set by the ISP (even if not within the allowable
open_basedir path) - which PHP does allow.
However when a script attempts to change it through
session_save_path(...) it would make sense to perform this check to
prevent access to session directories of other virtual hosts.
I am aware that similar issues have been discussed before, and also
that there are better ways to secure sessions, but I thought I'd
mention it here for the record.
[2005-05-19 23:21:34] andrey at ruweb dot net
Description:
(Sorry, I didn't found any reports about that issue. Can't believe
nobody reported this yet!)
ini_set('session.save_path','...') works great - it produces an error
when user is trying to set session.save_path to directory owned by
another user.
But why session_save_path doesn't perform safe_mode checks?
For now with session_save_path any server user can quietly substitute
session contents at any site located at the same server if he knows the
path to directory where that site's session files stored. :(
--
Edit this bug report at http://bugs.php.net/?id=33072&edit=1
#33093 [NEW]: token_get_all() inconsistent results?
From: [EMAIL PROTECTED]
Operating system: Mac OS X 10.4.1
PHP version: 5.0.4
PHP Bug Type: Unknown/Other Function
Bug description: token_get_all() inconsistent results?
Description:
It appears that token_get_all() does not report T_OPEN_TAG and
T_WHITESPACE properly, depending on the whitespace following the opening
tag. For example, when parsing ...
... you get T_OPEN_TAG, T_ECHO, T_WHITESPACE, T_VAR, T_WHITESPACE, and
T_CLOSE_TAG. This is not entirely the expected result (I would expect
T_WHITESPACE between the open tag and the echo).
However, when parsing the functional equivalent...
you get "<", "?", T_STRING ("php"), T_WHITESPACE, T_ECHO, T_WHITESPACE,
T_VAR, T_WHITESPACE, and T_CLOSE_TAG. In addition, the first whitespace
value reported does not include all the newlines (it drops one).
Although Macs use \r for their newlines natively, the test code uses the
Unix-standard \n, so I don't think it's Mac-related.
If this is in fact a bug, the current behavior makes it difficult to write
a reliable userland code auditor and report proper line numbers.
Am I missing some assumptions behind the behavior of the tokenizer
function?
--
Edit bug report at http://bugs.php.net/?id=33093&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33093&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33093&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33093&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33093&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33093&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33093&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33093&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33093&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33093&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33093&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33093&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33093&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33093&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33093&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33093&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33093&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33093&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33093&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33093&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33093&r=mysqlcfg
#33094 [NEW]: Too deep recursion leads to segfault
From: manager at mirchevideas dot com Operating system: Linux PHP version: 4.3.10 PHP Bug Type: Reproducible crash Bug description: Too deep recursion leads to segfault Description: Segfault of the httpd server Reproduce code: --- '; flush(); test($level+1); } ?> Expected result: Fatal error : Nesting level too deep - recursive dependency? Actual result: -- Going up to ~21000 and then just stopping to print. This is because it segfaulted. -- Edit bug report at http://bugs.php.net/?id=33094&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33094&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33094&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33094&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33094&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33094&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33094&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33094&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33094&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33094&r=support Expected behavior: http://bugs.php.net/fix.php?id=33094&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33094&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33094&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33094&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33094&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33094&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33094&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33094&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33094&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33094&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33094&r=mysqlcfg
#33092 [Opn]: Unable to complete network request to host
ID: 33092
User updated by: fabio at bs2 dot com dot br
Reported By: fabio at bs2 dot com dot br
Status: Open
Bug Type: InterBase related
Operating System: FreeBSD
PHP Version: 5.0.4
New Comment:
in one test without the connection persistent connection of liveUser
the error occurs too.
Previous Comments:
[2005-05-21 16:47:36] fabio at bs2 dot com dot br
Description:
the interbase server is not on same computer as the script
I'm using connect, the error had to be in the connect function and not
in the query function.
the function connect should be get the connection from the previous
persistent connection. In mysql_connect function have an parameter
new_link to force to create new connection, but interbase not.
the version of Apache in the server where the error occurs is 2.0.54
I have the same code in other machine(development server) with Apache
1.3 and php 5.0.3 and works ok.
Reproduce code:
---
{conecting to bd using liveUser and MDB with persistent connection}
$con = ibase_connect(...);
$res = ibase_query($con ,"SELECT * FROM someTable"); // the error
occurs here
$row = ibase_fetch_assoc($res);
var_dump($row);
ibase_close($con);
Actual result:
--
ibase_query() [function.ibase-query]: Unable to complete network
request to host "some ip". Error reading data from the connection. Bad
file descriptor.
--
Edit this bug report at http://bugs.php.net/?id=33092&edit=1
#33092 [NEW]: Unable to complete network request to host
From: fabio at bs2 dot com dot br
Operating system: FreeBSD
PHP version: 5.0.4
PHP Bug Type: InterBase related
Bug description: Unable to complete network request to host
Description:
the interbase server is not on same computer as the script
I'm using connect, the error had to be in the connect function and not in
the query function.
the function connect should be get the connection from the previous
persistent connection. In mysql_connect function have an parameter
new_link to force to create new connection, but interbase not.
the version of Apache in the server where the error occurs is 2.0.54
I have the same code in other machine(development server) with Apache 1.3
and php 5.0.3 and works ok.
Reproduce code:
---
{conecting to bd using liveUser and MDB with persistent connection}
$con = ibase_connect(...);
$res = ibase_query($con ,"SELECT * FROM someTable"); // the error occurs
here
$row = ibase_fetch_assoc($res);
var_dump($row);
ibase_close($con);
Actual result:
--
ibase_query() [function.ibase-query]: Unable to complete network request
to host "some ip". Error reading data from the connection. Bad file
descriptor.
--
Edit bug report at http://bugs.php.net/?id=33092&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33092&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33092&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33092&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33092&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33092&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33092&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33092&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33092&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33092&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33092&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33092&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33092&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33092&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33092&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33092&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33092&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33092&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33092&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33092&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33092&r=mysqlcfg
#33072 [Com]: session_save_path bypass safe_mode restriction
ID: 33072
Comment by: zxqc2 at dunc dot com dot au
Reported By: andrey at ruweb dot net
Status: Open
Bug Type:Safe Mode/open_basedir
PHP Version: 5.0.4, 4.3.11
New Comment:
session_save_path also does not perform the open_basedir check.
It does seem reasonable to allow access to the default
session.save_path set by the ISP (even if not within the allowable
open_basedir path) - which PHP does allow.
However when a script attempts to change it through
session_save_path(...) it would make sense to perform this check to
prevent access to session directories of other virtual hosts.
I am aware that similar issues have been discussed before, and also
that there are better ways to secure sessions, but I thought I'd
mention it here for the record.
Previous Comments:
[2005-05-19 23:21:34] andrey at ruweb dot net
Description:
(Sorry, I didn't found any reports about that issue. Can't believe
nobody reported this yet!)
ini_set('session.save_path','...') works great - it produces an error
when user is trying to set session.save_path to directory owned by
another user.
But why session_save_path doesn't perform safe_mode checks?
For now with session_save_path any server user can quietly substitute
session contents at any site located at the same server if he knows the
path to directory where that site's session files stored. :(
--
Edit this bug report at http://bugs.php.net/?id=33072&edit=1
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876 Comment by: gul_murjani at yahoo dot com Reported By: golden at riscom dot com Status: No Feedback Bug Type: Session related Operating System: freebsd 4.8 PHP Version: 4.3.9-4.3.10 Assigned To: sniper New Comment: Hi, I'm experiencing this problem in at least 2 sites. Since it's a error that appears in random, I wrote a simple script to try and reproduce the error. This is the script: All it does is invoke "session_start()" and use one session variable. It then reloads itself every 10 seconds. On HOSTMANIL.ORG and HOSTMANIL.NET, the error comes up. But there is no pattern at all. Sometimes out of 20 refreshes, there's an error, half the time. If the error comes up, I have to do a manual refresh. I notice that the session variable is not destroyed at all. It continues counting from where it stopped. The problem is at one point in HOSTMANILA.ORG, it kept on coming up every 2 auto refreshes (and I do an F5). But now, it's was good for 45 straign auto refreshes before the error came up. That's how random the error is. I do a lot of programming, mostly in PHP but I'm not "deep" technical. So I'm not sure if I'm missing something. I'm running the scripts on 5 sites. These are all on different servers although all of them are from shared hosting services using cPanel / WHM. http://www.hostmanila.org/test.php http://www.hostmanila.biz/test.php http://www.hostmanila.net/test.php http://www.vcdpix.com/test.php http://www.smokedbangus.com/test.php So far, it's only happened on HOSTMANILA.ORG and HOSTMANILA.NET. Here's the rundown on each site: HOSTMANILA.ORG (error) Linux 2.4.30-gator_r1 Apache 1.3.33 (Unix) PERL 5.8.4 PHP 4.3.11 cPanel 9.9.9-STABLE 15 HOSTMANILA.BIZ (fine) Linux 2.4.30-1-s5 Apache 1.3.33 (Unix) PERL 5.8.3 PHP 4.3.11 cPanel 10.2.0-RELEASE 82 HOSTMANILA.NET (error) Linux 2.4.26-grsec Apache 1.3.33 (Unix) PERL 5.8.0 PHP 4.3.11 cPanel 10.0.0-RELEASE 7 VCDPIX.COM (fine) Linux 2.4.20-24.9 Apache 1.3.33 (Unix) PERL 5.8.1 PHP 4.3.9 cPanel 10.0.0-RELEASE 7 SMOKEDBANGUS.COM (fine) Linux 2.4.20-20.7smp Apache 1.3.33 (Unix) PERL 5.8.4 PHP 4.3.10 cPanel 10.0.0-CURRENT 107 I can't imagine developing anything in PHP without making use of session_start() so I hope the issue is resolved. Regards, Gul hostmanila.com Previous Comments: [2005-05-21 01:24:55] jspec at bellsouth dot net I have now experienced this beast with a completely different hosting company. They are both running 4.3.10 - is this fixed in 4.3.11? [2005-05-18 22:48:45] dmih at in-solve dot ru We (as hosting company) are hoping that PHP team will track this bug down some day. Indeed, we can do not much to help or to fix it. This bug is hard to fix because it appears randomly, and there is no definite recreate scenario. There is assumption that this is http://bugs.php.net/bug.php?id=32330 bug, but I am not completely sure. You may suggest your hosting company to lower average server load - it will help this bug to happen rarely or even at no times. Lower - I mean - something lower than 50% avg CPU load on 1CPU server or 80% on 2+ CPU server. But that is only our hosting company workaround, not the solution. [2005-05-17 18:00:36] jspec at bellsouth dot net My hosting company is unable to fix the random "Failed to initialize storage module" error and it is making my account unusable. They cannot seem to fix it. What is the story with this!? [2005-04-29 11:04:06] dmih at in-solve dot ru Please kindly pay attention to this bug. It is REAL bug, not fantasy of 100+ man. Random session handler error. No Feedback status is surely lame for this, as you are getting feedback. There is no reproduce code because bug is "random bug under heavy load" class. We hope for you. Thanks. [2005-04-08 19:03:08] todd dot trann at palidar dot com RedHat 9 PHP 4.3.9 from RPM (php-4.3.9-11.rh90.art) Zend Engine 1.3.0, Optimizer 2.5.5 I am experiencing the same problem: the error indicates storage module "user", yet php.ini has it set to "files", and nowhere in my code do I change it to "user". The problem comes and goes as the page is reloaded. A PHP page with no session code does not exhibit the problem. My /tmp directory is world writable. Todd 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/25876 -- Edit this bug report at http://bugs.php.net/?id=25876&edit=1
#33091 [Opn->Bgs]: no image processing with image magick in typo3 3.7.0
ID: 33091 Updated by: [EMAIL PROTECTED] Reported By: rasi at rasi dot ch -Status: Open +Status: Bogus Bug Type: *Graphics related Operating System: SBS 2003 (iis6) PHP Version: 4.3.11 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. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. This is not a support forum for third-party applications. Previous Comments: [2005-05-21 13:15:33] rasi at rasi dot ch Description: no image processing with image magick 6.2.2.1 or 6.2.2.2 or 6.2.2.4 in typo3 3.7.0 running php in isapi mode on microsoft small business server 2003 with iis6. in fast cgi mode are no problems thanks in advance gerhard rasi http://rasi.ch -- Edit this bug report at http://bugs.php.net/?id=33091&edit=1
#33091 [NEW]: no image processing with image magick in typo3 3.7.0
From: rasi at rasi dot ch Operating system: SBS 2003 (iis6) PHP version: 4.3.11 PHP Bug Type: *Graphics related Bug description: no image processing with image magick in typo3 3.7.0 Description: no image processing with image magick 6.2.2.1 or 6.2.2.2 or 6.2.2.4 in typo3 3.7.0 running php in isapi mode on microsoft small business server 2003 with iis6. in fast cgi mode are no problems thanks in advance gerhard rasi http://rasi.ch -- Edit bug report at http://bugs.php.net/?id=33091&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33091&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33091&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33091&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33091&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33091&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33091&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33091&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33091&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33091&r=support Expected behavior: http://bugs.php.net/fix.php?id=33091&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33091&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33091&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33091&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33091&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33091&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33091&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33091&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33091&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33091&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33091&r=mysqlcfg
#33090 [Asn->Csd]: mysql_prepare doesn't return an error
ID: 33090
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: MySQLi related
Operating System: all
PHP Version: 5.0.4
Assigned To: georg
New Comment:
This bug has been fixed in CVS.
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/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2005-05-21 10:37:26] [EMAIL PROTECTED]
Description:
In later versions of libmysqlclient 4.1 and 5.0 the api
call mysql_stmt_close also clears mysql->net.error*
values.
This affects that mysql_prepare doesn't return an error
with current version of libmysql.
Reproduce code:
---
prepare("this will never work"))) {
printf("Error: %s\n", $mysql->error);
}
$mysql->close();
?>
Expected result:
Error: You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for
the right syntax to use near 'this will never work' at
line 1
Actual result:
--
Error:
--
Edit this bug report at http://bugs.php.net/?id=33090&edit=1
#33090 [NEW]: mysql_prepare doesn't return an error
From: [EMAIL PROTECTED]
Operating system: all
PHP version: 5.0.4
PHP Bug Type: MySQLi related
Bug description: mysql_prepare doesn't return an error
Description:
In later versions of libmysqlclient 4.1 and 5.0 the api
call mysql_stmt_close also clears mysql->net.error*
values.
This affects that mysql_prepare doesn't return an error
with current version of libmysql.
Reproduce code:
---
prepare("this will never work"))) {
printf("Error: %s\n", $mysql->error);
}
$mysql->close();
?>
Expected result:
Error: You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for
the right syntax to use near 'this will never work' at
line 1
Actual result:
--
Error:
--
Edit bug report at http://bugs.php.net/?id=33090&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33090&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33090&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33090&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33090&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33090&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33090&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33090&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33090&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33090&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33090&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33090&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33090&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33090&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33090&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33090&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33090&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33090&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33090&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33090&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33090&r=mysqlcfg
#33090 [Opn->Asn]: mysql_prepare doesn't return an error
ID: 33090
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: MySQLi related
Operating System: all
PHP Version: 5.0.4
-Assigned To:
+Assigned To: georg
Previous Comments:
[2005-05-21 10:37:26] [EMAIL PROTECTED]
Description:
In later versions of libmysqlclient 4.1 and 5.0 the api
call mysql_stmt_close also clears mysql->net.error*
values.
This affects that mysql_prepare doesn't return an error
with current version of libmysql.
Reproduce code:
---
prepare("this will never work"))) {
printf("Error: %s\n", $mysql->error);
}
$mysql->close();
?>
Expected result:
Error: You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for
the right syntax to use near 'this will never work' at
line 1
Actual result:
--
Error:
--
Edit this bug report at http://bugs.php.net/?id=33090&edit=1
#33089 [NEW]: Ibase dont work with special caracteres (^ ~ ´)
From: koyote at task dot com dot br Operating system: Windows Xp PHP version: 5.0.4 PHP Bug Type: InterBase related Bug description: Ibase dont work with special caracteres (^ ~ ´) Description: I have a table of cities and some of then have accent, like Araxá . If i make a normal sql SELECT * FROM CITIES where have ID, NAME and STATE. The function starts to collect from the database and print in the screen. But when it reads a city that have accent it stops and generates a Warning. I had search a lot in the internet and i couldnt find anything about it. I think that ibase have problems to read accent in Interbase Databases. Reproduce code: --- sth); ?> Expected result: It should return a string with all the values from each field of the row. Actual result: -- PHP Warning: ibase_fetch_row() [function.ibase-fetch-row]: arithmetic exception, numeric overflow, or string truncation Cannot transliterate character between character sets in C:\Inetpub\wwwroot\croquiteca\banco.php on line 45 -- Edit bug report at http://bugs.php.net/?id=33089&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33089&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33089&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33089&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33089&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33089&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33089&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33089&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33089&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33089&r=support Expected behavior: http://bugs.php.net/fix.php?id=33089&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33089&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33089&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33089&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33089&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33089&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33089&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33089&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33089&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33089&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33089&r=mysqlcfg
