#20190 [Com]: Random mem corruption: zend_get_executed_filename() mismatch
ID: 20190
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Apache related
Operating System: FreeBSD
PHP Version: 4.3.0-dev
New Comment:
I upgraded to 4.3 the other day and ran into this problem big time.
Today I went back to 4.2.3 and am still running into the error(s)
occasionally... I've made sure that PHP 4.2.3 is installed and running
and (according to phpinfo()) it is.
Apache 1.3.27 FreeeBSD 4.7p-1 PHP 4.2.3 and PHP 4.3.0
Ack!
Previous Comments:
[2002-11-14 15:45:26] [EMAIL PROTECTED]
Hi,
>when this bug occurs, to confirm the wrong ini values?
Ok, i'll do that.
>1) there are 2 vhosts, where vhost A has open_basedir >restriction in
effect, via php_admin_value in > context and vhost B
>doesn't
Nope. Both virtal servers have a open basedir restriction
turned on here.
>2) vhost B includes a file and subsequently vhost A >includes one.
That's correct.
For some strange reason, the bug does not happen on
a test setup with the same apache config. Of course
I was not able to copy all web-stuff over and simulate
true load.
So it is very difficult to reproduce.
Martin
[2002-11-14 11:39:16] [EMAIL PROTECTED]
Could you test the values:
registered_zend_ini_directives
and
EG(ini_directives)
when this bug occurs, to confirm the wrong ini values?
I'm trying to reproduce this, can you confirm, that this bug happens
when:
1) there are 2 vhosts, where vhost A has open_basedir restriction in
effect, via php_admin_value in context and vhost B
doesn't
2) vhost B includes a file and subsequently vhost A includes one.
So in order to increase the chances of hitting this bug, one could:
set Max and MinSpareServers to 1 and request the different vhosts?
[2002-11-14 03:09:27] [EMAIL PROTECTED]
I can confirm that it still happens with the latest cvs 4.3 snapshot
from yesterday (2002-11-13).
If I get some pointers, I could add some debug code.
Funny thing is that the webserver runs about 30min to
2 hours ok, and then I hit begin to hit the bug. Always
after the same files:
It's always the same, you can see it because the filename
has two slashes /www/doc/customer2/html/visions/php//
This path really exists. The thing that does not exist,
is the file wrapper.php. It exists in the customer1 path
so we really really should not end here.
Nov 14 05:37:24 server-bsl1 httpd: open_basedir: Used openbasedir
/www/doc/custermer1, file
/www/doc/customer2/html/visions/php//wrapper.php executed_filename
(/www/doc/customer1/index.php)
It looks to me that this case only happens after the apache
child has processed a include as last thing and then preceeds again a
different webserver.
Anyone knows more ?
Martin
[2002-11-02 14:27:04] [EMAIL PROTECTED]
I'd like to jump this upto a critical standing. Mainly because it will
get someone else to review the patch. Hopefully that someone else will
be a bit more intimately knowledgable with the whole Zend memory system
than I.
[2002-11-01 08:22:04] [EMAIL PROTECTED]
My patch explained a bit more ...
The main trick is that we do a stat() on
$path:
if (( stat (path, &statbuf)) < 0) {
If the file does not exist, we can be sure that we triggered the bug
and we let the check pass.
As already said, this is only a workaround for the ugly
bug ...
Martin
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/20190
--
Edit this bug report at http://bugs.php.net/?id=20190&edit=1
#19292 [Com]: random error: open_basedir restriction in effect. File is in wrong directory
ID: 19292 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Apache related Operating System: linux PHP Version: 4.2.3,4.3.0 New Comment: Same problem FreeBSD 4.7p3 PHP 4.3.0 PHP 4.2.3 Apache 1.3.27 (bug 20190) Previous Comments: [2003-01-17 13:57:47] [EMAIL PROTECTED] The same probleme is in php4-STABLE-200301171630 Please correct that Warning: Unknown(): open_basedir restriction in effect. File(/home/ovh/www/forum/list.php) is not within the allowed path(s): (/home/users/xiaoping) in Unknown on line 0 Warning: Unknown(/home/ovh/www/forum/list.php): failed to create stream: Operation not permitted in Unknown on line 0 Warning: (null)() [function.include]: Failed opening '/home/ovh/www/forum/list.php' for inclusion (include_path='.:/upload/') in Unknown on line 0 [2003-01-12 05:40:52] [EMAIL PROTECTED] Same problem with php 4.3.0 / apache 1.3.27 / Slackware The problem seems to appear when a virtual host has a open_basedir defined, but not in other virtualhost. In this case others virtual hosts take the value of one of defined open_basedir. (maybe the value come from another http child open in same time) Seems to have same behaviour with auto_append. Hope it will help to solve this bug. Fred [2003-01-11 21:33:19] [EMAIL PROTECTED] I have 2 FreeBSD servers with the same problem. Both have /www as symlink. Real path is /home/www. I also have a Windows machine, with no symlink ;-) - no problem there. /www is c:/www there, and all works. All machines have same httpd.conf, same Apache, same 4.2.3 [2003-01-11 05:16:38] [EMAIL PROTECTED] 4.3.o stills has the same problem, the test suite I posted on 30 Oct 2002 12:56am fails with this messages: Warning: main() [function.main]: open_basedir restriction in effect. File(/usr/local/lib/php/hello.php) is not within the allowed path(s): (/usr/local/http-docs/common/scripts/) in /usr/local/http-docs/common/lib/test/test.php on line 5 Warning: main(hello.php) [function.main]: failed to create stream: Not owner in /usr/local/http-docs/common/lib/test/test.php on line 5 Fatal error: main() [function.main]: Failed opening required 'hello.php' (include_path='./:/usr/local/http-docs/common/lib:/usr/local/lib/php:/usr/local/http-docs/common/lib/phpwhois') in /usr/local/http-docs/common/lib/test/test.php on line 5 where test.php tries to include hello.php which is in /usr/local/http-docs/common/lib/test that is a path that's included in include_path [2003-01-10 04:36:13] [EMAIL PROTECTED] Update version. Bug confirmed in 4.3.0 - final. 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/19292 -- Edit this bug report at http://bugs.php.net/?id=19292&edit=1
#21874 [NEW]: ini_get returns values from other vservers
From: [EMAIL PROTECTED]
Operating system: FreeBSD
PHP version: 4.2.2
PHP Bug Type: PHP options/info functions
Bug description: ini_get returns values from other vservers
I have a file:
';
?>
And I have multiple virtual host specifications like:
{Domain names and file paths have been changed to protech the
innocent...}
ServerName myapp.site1.com
ServerAdmin [EMAIL PROTECTED]
DocumentRoot /home/mainapplication
php_admin_value upload_tmp_dir /home/client1/tmp
php_admin_value error_log /home/client1/log
php_value error_reporting 7
php_flag display_errors On
php_flag log_errors On
php_flag register_globals on
php_flag display_errors off
ServerName myapp.site2.com
ServerAdmin [EMAIL PROTECTED]
DocumentRoot /home/mainapplication
php_admin_value upload_tmp_dir /home/client2/tmp
php_admin_value error_log /home/client2/log
php_value error_reporting 7
php_flag display_errors On
php_flag log_errors On
php_flag register_globals on
php_flag display_errors off
N.B. When using PHPA, the problem is incredibly obvious (changes
continuously), however with it removed, and reloading the page HUNDREDS of
times, I saw this happen twice.
The only values displayed are those of ACTIVE virtual servers... at least
that is what seems to be happening.
--
Edit bug report at http://bugs.php.net/?id=21874&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21874&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21874&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21874&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21874&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21874&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21874&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21874&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21874&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21874&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21874&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21874&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21874&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21874&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21874&r=gnused
Bug #16518: undefined symbol: stat
From: [EMAIL PROTECTED] Operating system: RedHat 7.2 / Debian 3.0 PHP version: 4.0CVS-2002-04-09 PHP Bug Type: Informix related Bug description: undefined symbol: stat I have successfully got apache-2.0.35 & php4.2-CVS to work fine together, but when I recompile php with informix support it compiles fine but when I try to start apache2 I get the folloing message. [root@redhat bin]# ./apachectl start Syntax error on line 217 of /usr/local/apache/conf/httpd.conf: Cannot load /usr/local/apache/modules/libphp4.so into server: /opt/informix/lib/esql/libthgen.so: undefined symbol: stat ./apachectl start: httpd could not be started [root@redhat bin]# It appears to be a problem with the latest version of the Informix CSDK 2.70 because I downgraded to 2.60 and everything compiled and runs fine after the downgrade! -- Edit bug report at http://bugs.php.net/?id=16518&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16518&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16518&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16518&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16518&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16518&r=support Expected behavior: http://bugs.php.net/fix.php?id=16518&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16518&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16518&r=submittedtwice
Bug #17445: open_basedir warning when including file in same dir
From: [EMAIL PROTECTED] Operating system: FreeB SD 4.4 PHP version: 4.2.1 PHP Bug Type: Scripting Engine problem Bug description: open_basedir warning when including file in same dir I have set open_basedir = /home/user I have set include_path = .:/home/user/lib:/home/user/site/lib I have a file located in: /home/user/site/htdocs/ which requires another file in the same directory. The include WORKS. BUT IT PRODUCED A WARNING: Warning: open_basedir restriction in effect. File is in wrong directory in /home/user/site/htdocs/file1.php on line 3 File2 is here. The "File2 is here" is produced by the included file. I've seen others comment on this problem, but could find no solution or open occurance of it in the bug list. Thanks. Mitch. -- Edit bug report at http://bugs.php.net/?id=17445&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17445&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17445&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17445&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17445&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17445&r=support Expected behavior: http://bugs.php.net/fix.php?id=17445&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17445&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17445&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17445&r=globals
#19460 [Com]: HTTP_POST_VARS trims 4 characters from left side of each field with array name
ID: 19460 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: mbstring related Operating System: Linux 2.4.9-34 (RedHat 7.2) PHP Version: 4.2.3 New Comment: What about people that are running production servers that have been bitten by this! We can't use CVS versions of PHP! The workaround described as [remove --enable-mbstr-enc- trans] isn't valid as I never compiled my PHP with -- enable-mbstr-enc-trans in the first place :-) Previous Comments: [2002-10-16 00:42:51] [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-10-16 00:10:36] [EMAIL PROTECTED] What does it mean "This has been fixed in CVS"? Do I need to get a new copy of cvs? If so, where do I get it? Or is CVS a place where I can get a new copy of php? If so, where is this "cvs"? More info. needed. [2002-09-18 09:45:05] [EMAIL PROTECTED] The issue was with the --enable-mbstr-enc-trans configure option; remove it from your configure line and rebuild and the problem goes away. This has been fixed in CVS. (Reclassifying) [2002-09-18 09:38:23] [EMAIL PROTECTED] Is this the bug report which my report (19476) was set bogus for? This says it's apache 2 related, I'm running 1.3.26. Was this, in fact, fixed then? [2002-09-17 21:06:22] [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. 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/19460 -- Edit this bug report at http://bugs.php.net/?id=19460&edit=1
Bug #15151 Updated: Decimals/Numerics stored as int64 always display as xxx.2
ID: 15151 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: InterBase related Operating System: Windows PHP Version: 4.1.1 New Comment: The original fix I posted has its own bug (due to me not VC++) when the number is less than 0 but greater than -1 the negative sign does not appear. This fixes it (and the original problem also): case SQL_INT64: tv64 = (ISC_INT64) *((ISC_INT64 *) data); iv64 = (tv64 / (int) pow(10.0, (double) -scale)); fv64 = (ISC_INT64) abs((int) tv64 % (int) pow(10.0, (double) -scale)); val->type = IS_STRING; if ( tv64 < 0 && iv64 == 0 ) val->value.str.len = sprintf(string_data, "-0"); else val->value.str.len = sprintf(string_data, "%Ld", iv64); val->value.str.len += sprintf(string_data + val->value.str.len, ".%0*Ld", -scale, fv64); val->value.str.val = estrdup(string_data); break; Previous Comments: [2002-01-21 13:15:30] [EMAIL PROTECTED] This is also reported as #13807 [2002-01-21 13:10:17] [EMAIL PROTECTED] Decimals/Numerics that are stored as 64-bit integers always display as xxx.2. The following should fix the problem: Original code (on or about line 1782): val->value.str.len = sprintf(string_data, "%Ld.%0*Ld", (ISC_INT64) (*((ISC_INT64 *)data) / (int) pow(10.0, (double) -scale)), -scale, (ISC_INT64) abs((int) (*((ISC_INT64 *)data) % (int) pow(10.0, (double) -scale; Change to: val->value.str.len = sprintf(string_data, "%Ld", (ISC_INT64) (*((ISC_INT64 *)data) / (int) pow(10.0, (double) -scale))); val->value.str.len += sprintf(string_data + val->value.str.len, ".%0*Ld", -scale, (ISC_INT64) abs((int) (*((ISC_INT64 *)data) % (int) pow(10.0, (double) -scale; The problem is with MSVC++. It doesn't seem to like two int64s in the same sprintf statement. I don't yet have all the pieces to compile the extension so I have not fully tested it, but I have duplicated the problem in a test program and verified that the above code fixes the problem in the test program. -- Edit this bug report at http://bugs.php.net/?id=15151&edit=1
Bug #15151 Updated: Decimals/Numerics stored as int64 always display as xxx.2
ID: 15151 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: InterBase related Operating System: Windows PHP Version: 4.1.1 New Comment: The original fix I posted has its own bug (due to me not VC++) when the number is less than 0 but greater than -1 the negative sign does not appear. This fixes it (and the original problem also): Add these declarations: ISC_INT64 tv64; ISC_INT64 iv64; ISC_INT64 fv64; then change the code: case SQL_INT64: tv64 = (ISC_INT64) *((ISC_INT64 *) data); iv64 = (tv64 / (int) pow(10.0, (double) -scale)); fv64 = (ISC_INT64) abs((int) tv64 % (int) pow(10.0, (double) -scale)); val->type = IS_STRING; if ( tv64 < 0 && iv64 == 0 ) val->value.str.len = sprintf(string_data, "-0"); else val->value.str.len = sprintf(string_data, "%Ld", iv64); val->value.str.len += sprintf(string_data + val->value.str.len, ".%0*Ld", -scale, fv64); val->value.str.val = estrdup(string_data); break; Previous Comments: [2002-03-27 11:06:10] [EMAIL PROTECTED] The original fix I posted has its own bug (due to me not VC++) when the number is less than 0 but greater than -1 the negative sign does not appear. This fixes it (and the original problem also): case SQL_INT64: tv64 = (ISC_INT64) *((ISC_INT64 *) data); iv64 = (tv64 / (int) pow(10.0, (double) -scale)); fv64 = (ISC_INT64) abs((int) tv64 % (int) pow(10.0, (double) -scale)); val->type = IS_STRING; if ( tv64 < 0 && iv64 == 0 ) val->value.str.len = sprintf(string_data, "-0"); else val->value.str.len = sprintf(string_data, "%Ld", iv64); val->value.str.len += sprintf(string_data + val->value.str.len, ".%0*Ld", -scale, fv64); val->value.str.val = estrdup(string_data); break; [2002-01-21 13:15:30] [EMAIL PROTECTED] This is also reported as #13807 [2002-01-21 13:10:17] [EMAIL PROTECTED] Decimals/Numerics that are stored as 64-bit integers always display as xxx.2. The following should fix the problem: Original code (on or about line 1782): val->value.str.len = sprintf(string_data, "%Ld.%0*Ld", (ISC_INT64) (*((ISC_INT64 *)data) / (int) pow(10.0, (double) -scale)), -scale, (ISC_INT64) abs((int) (*((ISC_INT64 *)data) % (int) pow(10.0, (double) -scale; Change to: val->value.str.len = sprintf(string_data, "%Ld", (ISC_INT64) (*((ISC_INT64 *)data) / (int) pow(10.0, (double) -scale))); val->value.str.len += sprintf(string_data + val->value.str.len, ".%0*Ld", -scale, (ISC_INT64) abs((int) (*((ISC_INT64 *)data) % (int) pow(10.0, (double) -scale; The problem is with MSVC++. It doesn't seem to like two int64s in the same sprintf statement. I don't yet have all the pieces to compile the extension so I have not fully tested it, but I have duplicated the problem in a test program and verified that the above code fixes the problem in the test program. -- Edit this bug report at http://bugs.php.net/?id=15151&edit=1
#20190 [Com]: Random mem corruption: zend_get_executed_filename() mismatch
ID: 20190 Comment by: mitch at karboneye dot com Reported By: mbr at freebsd dot org Status: Critical Bug Type: Apache related Operating System: FreeBSD PHP Version: 4.3.0-dev New Comment: *sigh* STILL happening with 4.3.1 FreeBSD 4.7 - 5.0 Previous Comments: [2003-01-21 08:42:27] r at orcafat dot com Have this problem on 4.3.0 RELEASE! and 4.2.3 upgrade Version on this bug please. [2003-01-16 17:22:32] mitch at karboneye dot com I upgraded to 4.3 the other day and ran into this problem big time. Today I went back to 4.2.3 and am still running into the error(s) occasionally... I've made sure that PHP 4.2.3 is installed and running and (according to phpinfo()) it is. Apache 1.3.27 FreeeBSD 4.7p-1 PHP 4.2.3 and PHP 4.3.0 Ack! [2002-11-14 15:45:26] mbr at freebsd dot org Hi, >when this bug occurs, to confirm the wrong ini values? Ok, i'll do that. >1) there are 2 vhosts, where vhost A has open_basedir >restriction in effect, via php_admin_value in > context and vhost B >doesn't Nope. Both virtal servers have a open basedir restriction turned on here. >2) vhost B includes a file and subsequently vhost A >includes one. That's correct. For some strange reason, the bug does not happen on a test setup with the same apache config. Of course I was not able to copy all web-stuff over and simulate true load. So it is very difficult to reproduce. Martin [2002-11-14 11:39:16] [EMAIL PROTECTED] Could you test the values: registered_zend_ini_directives and EG(ini_directives) when this bug occurs, to confirm the wrong ini values? I'm trying to reproduce this, can you confirm, that this bug happens when: 1) there are 2 vhosts, where vhost A has open_basedir restriction in effect, via php_admin_value in context and vhost B doesn't 2) vhost B includes a file and subsequently vhost A includes one. So in order to increase the chances of hitting this bug, one could: set Max and MinSpareServers to 1 and request the different vhosts? [2002-11-14 03:09:27] mbr at freebsd dot org I can confirm that it still happens with the latest cvs 4.3 snapshot from yesterday (2002-11-13). If I get some pointers, I could add some debug code. Funny thing is that the webserver runs about 30min to 2 hours ok, and then I hit begin to hit the bug. Always after the same files: It's always the same, you can see it because the filename has two slashes /www/doc/customer2/html/visions/php// This path really exists. The thing that does not exist, is the file wrapper.php. It exists in the customer1 path so we really really should not end here. Nov 14 05:37:24 server-bsl1 httpd: open_basedir: Used openbasedir /www/doc/custermer1, file /www/doc/customer2/html/visions/php//wrapper.php executed_filename (/www/doc/customer1/index.php) It looks to me that this case only happens after the apache child has processed a include as last thing and then preceeds again a different webserver. Anyone knows more ? Martin 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/20190 -- Edit this bug report at http://bugs.php.net/?id=20190&edit=1
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876 Comment by: mitch at webcob dot com Reported By: golden at riscom dot com Status: Bogus Bug Type: Session related Operating System: freebsd 4.8 PHP Version: 4.3.3 New Comment: I'm also running FreeBSD 4.8 - same problem. My /tmp is on a separate partition, and has plenty of space... a restart (even a graceful one) seems to fix the problem. As a temp fix, I heard someone say that the sites they had using custom session storage handlers did NOT exhibit the problem, so I think I may try an auto-prepend file containing such an override on a server-wide basis. Any comment on this idea? Please copy my email. Thanks. Previous Comments: [2004-02-18 11:18:59] bigrob at cox-internet dot com I'm having the same problems. FreeBSD 4.8, php 4.3.4. THIS IS GETTING VERY annoying. It quit doing it for a month, then almost to the exact day it just started up again this morning at 1AM and hasn't stoppd. Apache 2.0.47 as well. Restarting apache seems to do the trick for about a minute, then it starts popping up again. I've already had 20 customers call this morning saying they cannot place orders and they give me the error. I've check my apache access logs as well as the php log. I get this error several times: [18-Feb-2004 10:15:39] PHP Warning: Unknown(): A session is active. You cannot change the session module's ini settings at this time. in Unknown on line 0 Almost always following it is this srror: [18-Feb-2004 10:15:51] PHP Fatal error: session_start(): Failed to initialize storage module. in /mydir/myfile.php3 on line 2 All that is in myfile.php3 is session_start(); These errors started happening after moving to a new sever. NO PROBLEMS in the past, was using Apache 1.3.8 I believe and PHP 4.3.0. PHP People, WHAT ARE CAUSING THESE ERRORS [2004-02-18 07:35:32] c dot i dot morris at durham dot ac dot uk We're also getting this bug. Apache 1.3.27 PHP 4.3.2 Solaris 8 (rather than BSD) as the OS It happens intermittently, reloading the page _usually_ clears it. Different users report different things. I've never been able to duplicate it on my browsers (tested IE and Mozilla, no difference), a colleague gets it occasionally, users reporting the problem to us get it one time in three in the worst cases. /tmp is writeable and has a huge amount of free space. Multiple users have reported the problem to us, the minimal code sample already reported is the only common part. We are attempting to find if there is anything special about the requests that trigger it, but so far nothing - will update if we find anything. [2004-02-10 16:45:59] bernoico at netcabo dot pt A have this problem to, is very annoying... I made a search in google for "Fatal error: session_start(): Failed to initialize storage module" and I found millions of sites in this condition... Are there any work around? Thanks. [2004-02-07 22:58:14] [EMAIL PROTECTED] close [2004-02-05 04:08:22] golden at riscom dot com Open 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
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876
Comment by: mitch at webcob dot com
Reported By: golden at riscom dot com
Status: Closed
Bug Type: Session related
Operating System: freebsd 4.8
PHP Version: 4.3.3
New Comment:
Having this problem again too.
I WAS having this problem with FreeBSD 4.4 / Apache 1.3.27 / PHP
4.3.2.
The problem started happening again a couple days ago...
Seems to be a Heisenbug - ever time I add code to output debug info and
restart apache, the problem seems to have disappeared or moved to a
different website / vhost.
Problem does not seem to happen on all vhosts at the same time...
Just upgraded to PHP 4.3.7
The problem still persists.
I have done all the recommended "fixes" - checking disk space,
permissions, changing storage location, etc. Am currently working on a
db based storage moduel to include on all sites experiencing the
problem as in interrum fix.
Please CC me on any updates.
thanks.
Previous Comments:
[2004-06-17 10:18:10] searchadm at goschorn dot de
PHP Fatal error: session_start(): Failed to initialize storage module:
user (path: /tmp) in ...
PHP 4.3.7 (4.3.4 also)
Apache 2.0.48
Suse Linux 8.2
after apachectl restart it works again for a while
[2004-06-15 15:05:39] datacompboy at mail dot ru
Currently runned workaround via
auto_prepend_file = /etc/httpd/phpinc.php
and in /etc/httpd/phpinc.php
[2004-06-15 14:47:13] datacompboy at mail dot ru
I have running Apache
SERVER_SOFTWARE Apache/1.3.20 Sun Cobalt (Unix) mod_jk mod_ssl/2.8.4
OpenSSL/0.9.7d PHP/4.3.7 mod_auth_pam_external/0.1 FrontPage/5.0.2.2510
mod_perl/1.26
Small code to see:
Producing
session.save_handler files files
and below:
Fatal error: session_start(): Failed to initialize storage module:
user (path: /tmp) in a.php on line 3
Can't say what to do to fix that _STRANGE_ error :/
[2004-06-14 01:43:26] sha3134 at njit dot edu
I was having this problem intially with php-4.3.2 with squieralmail.
After an upgrade of both SQ and PHP-4.3.7, the problem persists, though
more random. Hitting refresh usually clears this error. As i discovered
though the error happens with pages using start_session and
session.save_path permissions for files are correct and i have tried
clearing it out. I have not tried the:
ini_set('session.save_handler', 'files');
as i its already defined in my php.ini file.
Note this is a very random bug/feature. Could this be due to high load
or high io on the server ?
[2004-05-27 09:23:21] yertletheturtle82 at yahoo dot com
I am running version 4.3.6 and receive this error consistently when
attempting to run phprojekt. It was running with no problems
previously. I am also running Drupal which uses php also, but seems to
have no problems at all. Not sure why this started happening all of a
sudden. Running RH9.0.
It seemed to start when I was trying to re-compile PHP with IMAP
support.
Thanks
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
#38111 [Com]: PHP crashes IIS worker process and application pool
ID: 38111 Comment by: mitch at mitchellgeere dot com Reported By: svendavidh at hotmail dot com Status: No Feedback Bug Type: IIS related Operating System: Windows Server 2003 Std. Ed. R2 PHP Version: 5.1.4 New Comment: I am running Windows Vista Ultimate with PHP 5.2, MySql, IIS 7.0. I am evaluating php, so far asp.net is holding my favour. Previous Comments: [2007-05-27 05:03:49] doug at shontz dot net I am having this problem also. Clean installs of Vista (IIS7) and Server 2003 Enterprise (IIS6). PHP Version 5.2.2 with no additional plugins or filters (isapi or otherwise) on either box. Disable PHP and the problem stops...enable it and I can log it happening multiple times within an hour. I am running open source apps such as Joomla and WordPress, but I can get this to happen without having any pages on the site at all. [2007-05-23 09:35:10] bjoern dot andersen at atosorigin dot com Additional Info: The problem seems to go away when all webs run in the same application pool (No multithreading). So there is a point to start. It's not a real workaround for us, because in the huge production environment we run, we need to separate the application in safe pools. [2007-05-23 09:22:13] bjoern dot andersen at atosorigin dot com Same here with 5.2.2 in win2k3SP2/IIS6 32 Bit. PHP installed as ISAPI extension, not filter. Many concurrent application pools. Event Type: Information Event Source: Application Error Event Category: (100) Event ID: 1004 Date: 23.05.2007 Time: 11:09:44 User: N/A Computer: P-NG-W3PHP2 Description: Reporting queued error: faulting application w3wp.exe, version 6.0.3790.3959, faulting module php5isapi.dll, version 5.2.2.2, fault address 0x23d7. Happens often, but not always. In variour applications. I am willing to give feedback or debug info, if you specify what you need. [2007-05-22 12:02:32] rzhaman at hotmail dot com Same here with PHP 5.2.1, Windows Server 2003 (SP1), and IIS 6. Clean install. [2007-05-10 15:33:20] roger dot weiss at gmail dot com I am also getting these. This only start happening after we installed 5.2.1.1. I will install 5.2.2 and let you know if the problem persists. faulting module php5isapi.dll, version 5.2.1.1, fault address 0x23d7 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/38111 -- Edit this bug report at http://bugs.php.net/?id=38111&edit=1
#42131 [NEW]: in_array return 0 value when there's no specified 0 value in array
From: mitch dot pascual at phpugph dot com
Operating system: Windows XP
PHP version: 5.2.3
PHP Bug Type: Arrays related
Bug description: in_array return 0 value when there's no specified 0 value in
array
Description:
return 0 value when there's no specified 0 value in array
Reproduce code:
---
PHP.net, java => java.com, 0 =>
javascript, 1 => actionscript);
foreach ($array2 as $key => $value) {
if ( in_array($key, $array1) ) {
print in array: $key ;
} else {
print not in array: $key ;
} # end if
} # end foreach
?>
Expected result:
in array: php
in array: java
not in array: 0
not in array: 1
Actual result:
--
in array: php
in array: java
in array: 0
not in array: 1
--
Edit bug report at http://bugs.php.net/?id=42131&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42131&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42131&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42131&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42131&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42131&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42131&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42131&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42131&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42131&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42131&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42131&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42131&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42131&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42131&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42131&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42131&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42131&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42131&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42131&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42131&r=mysqlcfg
#42131 [Bgs]: in_array return 0 value when there's no specified 0 value in array
ID: 42131
User updated by: mitch dot pascual at phpugph dot com
Reported By: mitch dot pascual at phpugph dot com
Status: Bogus
Bug Type: Arrays related
Operating System: Windows XP
PHP Version: 5.2.3
New Comment:
Hi,
On the code I provided, how come that there's a value 0 on the array
($array1)? Can you please explain it further?
Thanks a lot!
Previous Comments:
[2007-07-28 12:26:11] [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
.
[2007-07-28 11:58:29] mitch dot pascual at phpugph dot com
Description:
return 0 value when there's no specified 0 value in array
Reproduce code:
---
PHP.net, java => java.com, 0 =>
javascript, 1 => actionscript);
foreach ($array2 as $key => $value) {
if ( in_array($key, $array1) ) {
print in array: $key ;
} else {
print not in array: $key ;
} # end if
} # end foreach
?>
Expected result:
in array: php
in array: java
not in array: 0
not in array: 1
Actual result:
--
in array: php
in array: java
in array: 0
not in array: 1
--
Edit this bug report at http://bugs.php.net/?id=42131&edit=1
