php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #57380 Reopened bug
Submitted: 2006-11-16 05:18 UTC Modified: 2009-02-16 20:23 UTC
From: bert at procurios dot nl Assigned:
Status: No Feedback Package: APC (PECL)
PHP Version: 5.1.6 OS: Linux Debian Sarge x86_64
Private report: No CVE-ID: None
View Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
38 - 13 = ?
Subscribe to this entry?

 
 [2006-11-16 05:18 UTC] bert at procurios dot nl 
Description:
------------
APC Version: 3.0.12p2

We're running a server with a fixed set of PHP files that do not change very often (Apache 1.3.33, PHP 5.1.6, APC 3.0.12p2, default settings).

Sometimes we suddenly got fatal errors on that server in files that we did not change. There are two ways to solve the errors: 1) Restart apache, 2) touch the file

There's a structure in the cause of the parse errors:
* PHP Fatal error:  Unknown function:  defime() in /data/probase2/core/user.class.php on line 12
* PHP Warning: require_once(Imagd/Graph/Element.php) [<a href='function.require-once'>function.require-once</a>]: failed to open stream: No such file or directory in /usr/local/lib/php/Image/Graph/Plotarea/Element.php on line 33

Look at the corruption: 
* 'defime' vs. 'define'
* 'Imagd' vs. 'Image'

Somehow one character was corrupted in the APC cache, the file on disk contains the correct character. Therefore it is sufficient to get APC to reload the file to fix the problem (by touching the file or by restarting apache).

I don't know how to reproduce this or how to prevent this from happening. Some usage info: The sites in this system get about 100.000 pageviews/day.

Runtime Settings
----------------
apc.cache_by_default	1
apc.enable_cli	0
apc.enabled	1
apc.file_update_protection	2
apc.filters	
apc.gc_ttl	3600
apc.include_once_override	0
apc.max_file_size	1M
apc.mmap_file_mask	
apc.num_files_hint	1000
apc.optimization	0
apc.report_autofilter	0
apc.shm_segments	1
apc.shm_size	30
apc.slam_defense	0
apc.stat	1
apc.ttl	0
apc.user_entries_hint	100
apc.user_ttl	0
apc.write_lock	1


General Cache Information
-------------------------
APC Version	3.0.12p2
PHP Version	5.1.6
APC Host	[snip]
Server Software	Apache/1.3.33 (Debian GNU/Linux)
Cached Files	128 ( 15.3 MBytes)
Cached Variables	0 ( 0.0 Bytes)
Hits	73985
Misses	131
Request Rate	122.10 cache requests/second
Time To Live	0
Shared Memory	1 Segment(s) with 30.0 MBytes
Cache full count	0
Start Time	2006/11/16 11:06:09
Uptime	10 minutes

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-12-08 03:34 UTC] probase at procurios dot nl 
Last night around 2:00 our mailbox was flooded with PHP Warnings telling us that a script was trying to include "Relation.kivi.php". This file does not exist - it's named "Relation.kiwi.php". 

There were no changes in the files on disk around that time and again it was solved by restarting apache (and thereby restarting apc).

PHP Warning: require_once(/data/probase2/modules/mod_relation/classes/Relation.kivi.php) [<a href='function.require-once'>function.require-once</a>]: failed to open stream: No such file or directory in /data/probase2/modules/mod_relation/frameView.php on line 9
 [2007-02-13 09:42 UTC] probase at procurios dot nl 
We still suffer a lot from this bug. The last weeks we had a lot of problems with autoload. The path autoload uses to require() the file gets corrupted and a user error is cast. This is fixed after reloading APC or apache.

Is there any chance that a APC developer might look into this problem? It's killing the stability and uptime of our applications.

One of my colleagues suggested that it might be linked to this bug: http://gallery.menalto.com/node/50396
 [2007-02-24 06:51 UTC] rasmus@php.net 
Have you tried the CVS version?  We are just about to release 3.0.13 and it would be good to know if this still exists for you.
 [2007-05-09 04:17 UTC] probase at procurios dot nl 
Tried with PHP 5.2.2 and APC 3.0.13 and 3.0.14 and still the same problems. Usually the problems are autoload-related.
 [2007-05-17 18:37 UTC] zoe at postcarbon dot org 
How did this turn out?  Was a solution ever found?

I've got the same problem, only the offset for the character garbling is a little bigger - s becomes 3, t becomes 4, u becomes 5, etc.  I'm using PHP 4.4.2.
 [2007-06-28 16:20 UTC] probase at procurios dot nl 
This is still a problem for our product. If we enable APC these errors appear within the minute.
 [2007-06-28 16:21 UTC] bert at procurios dot nl 
Bug is still open...
 [2008-09-08 17:37 UTC] shire@php.net 
Are you updating these files while the server is running?

There have been a lot of changes to the memory management, can we once again ask you to test out the latest CVS version to see if it fixes your problem or lends more clues?
 [2009-02-16 20:23 UTC] shire@php.net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 31 16:00:01 2025 UTC