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

go to bug id or search bugs for

Bug #63437 'require' does not fail, while APC does not load file
Submitted: 2012-11-05 09:17 UTC Modified: 2013-02-18 00:36 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: i at kochira dot com Assigned:
Status: No Feedback Package: APC (PECL)
PHP Version: Irrelevant OS: Ubuntu 12.04.1 LTS
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: i at kochira dot com
New email:
PHP Version: OS:

 

 [2012-11-05 09:17 UTC] i at kochira dot com 
Description:
------------
Using latest PHP available for latest Ubuntu...
PHP 5.3.10-1ubuntu3.4  (APC 3.1.7)
(I checked the changelogs for versions 5.3.11~18, didn't see anything related to 
the problem)

The 'includes' files tree is like that

   ...includes/common/Class.inc
   ...includes/Client1 -> ../common
   ...includes/ClientN -> ../common
   ...includes/ClientX/Class.inc
   ...includes/ClientY/Class.inc

As you can see, there are 3 versions of Class.inc (each having a different 
inode, of course).
X and Y have one each, and common has also one which is used via symbolic links 
from clients 1..N.
But the 3 versions are identical (diff common/Class.inc clientX/Class.inc => no 
difference, for instance). The only reason there are 3 different versions, while 
it's not relevant to our problem, is because sometimes I want X and Y to try a 
new version before uploading to 'common'. But again, the 3 versions are 
identical since about a week ago. (Actually all 'inc' and 'php' files are 
identical, to make it clear)

Class.inc is a class definition (It contains only a class definition).

The NO problem:

  When ClientX&Y 'require' 'ClientX(orY)/Class.inc' there is no problem at all.

Problem:

  When Client1..N 'require' 'Client1..N/Class.inc'
    => No error, no warning in the log
  But the Class definition is not seen by requirer.php.

Investigation:

  After checking the apc_cache_info(), it appears that
    - 'ClientX&Y/Class.inc' are in the cache
    - 'common/Class.inc' is not

  Why the 'require' for Client1..N does not make APC load the file? 
  Why, if it can't, is there no error in the log?

  The only difference between ClientXY and Client1..N is the symbolic links...

Notes:
 - There are many other files in the common and ClientX,Y directories. Only 
Class.inc caused a problem, for some reason (class definition by itself?).
 - Class.inc is not used very often. Maybe the TTL (I use defaults) is of 
concern?


Test script:
---------------
index.php (same version for all clients)

<?php

  require CLIENT_NAME . '/Class.inc'; // define MyClass => No Error

  ...

  $x = new MyClass; 

  /* Error:
     PHP message: PHP Fatal error:  Class 'MyClass' not found in /.../index.php
  */

Expected result:
----------------
The require to make APC to load the common/Class.inc file in its cache, interpret 
it and make PHP aware of the class.

Actual result:
--------------
- require does not produce an error
- MyClass is not known

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-11-05 09:42 UTC] pajoye@php.net
-Status: Open +Status: Feedback
 [2012-11-05 09:42 UTC] pajoye@php.net 
Please try using latest APC.

What are you APC ini settings?
 [2012-11-05 10:09 UTC] i at kochira dot com 
It's a production env. using the latest (and updated) Ubuntu PHP/APC available. 
So, I don't want to take the risk to change the APC version now.
Also the new env was setup a week ago. This is the first time (today) I get such 
a problem reported (and only one file...). So it may not be easy to reproduce 
(again I suspect a TTL correlation.).

APC settings: (defaults +64M cache size)

Version		3.1.7
APC Debugging	Disabled
MMAP Support	Enabled
MMAP File Mask	no value
Locking type	pthread mutex Locks
Serialization Support	php
Revision	$Revision: 307215 $
Build Date	May 2 2011 19:00:42


Directive			Local Value	Master Value
apc.cache_by_default		On		On
apc.canonicalize		On		On
apc.coredump_unmap		Off		Off
apc.enable_cli			Off		Off
apc.enabled			On		On
apc.file_md5			Off		Off
apc.file_update_protection	2		2
apc.filters			no value	no value
apc.gc_ttl			3600		3600
apc.include_once_override	Off		Off
apc.lazy_classes		Off		Off
apc.lazy_functions		Off		Off
apc.max_file_size		1M		1M
apc.mmap_file_mask		no value	no value
apc.num_files_hint		1000		1000
apc.preload_path		no value	no value
apc.report_autofilter		Off		Off
apc.rfc1867			Off		Off
apc.rfc1867_freq		0		0
apc.rfc1867_name		APC_UPLOAD_PROGRESS	APC_UPLOAD_PROGRESS
apc.rfc1867_prefix		upload_		upload_
apc.rfc1867_ttl			3600		3600
apc.serializer			default		default
apc.shm_segments		1		1
apc.shm_size			64M		64M
apc.slam_defense		On		On
apc.stat			On		On
apc.stat_ctime			Off		Off
apc.ttl				0		0
apc.use_request_time		On		On
apc.user_entries_hint		4096		4096
apc.user_ttl			0		0
apc.write_lock			On		On
 [2012-11-05 10:29 UTC] pajoye@php.net 
I would suggest to have the so called staging server to test your environment. 
Many bugs have been fixed since 3.1.7 and some of them could be related to this 
one.
 [2013-02-18 00:36 UTC] pecl-dev at lists dot php dot 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-2024 The PHP Group
All rights reserved. 		Last updated: Tue Apr 16 07:01:29 2024 UTC