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

go to bug id or search bugs for

Bug #62398 APC stat=0 replaces a `require` filename with empty string
Submitted: 2012-06-23 02:34 UTC Modified: 2013-07-25 12:00 UTC
From: andrew at quizlet dot com Assigned: rasmus (profile)
Status: Closed Package: APC (PECL)
PHP Version: 5.4.4 / 5.4.3 OS: Mac OS X / Solaris SmartOS
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: andrew at quizlet dot com
New email:
PHP Version: OS:

 

 [2012-06-23 02:34 UTC] andrew at quizlet dot com 
Description:
------------
I have a file that does "require 'base.php';" at the top of the file. When I 
load that page after rebooting apache, everything works fine. When I reload the 
page, php comes up blank. PHP gives the warning that it's trying to require '' 
instead of 'base.php'.

PHP Warning:  require(): Filename cannot be empty in /var/builds/844/app/set.php 
on line 3
PHP Fatal error:  require(): Failed opening required '' (include_path='.') in 
/var/builds/844/app/set.php on line 3

PHP version:
----------------
PHP 5.4.4 (cli) (built: Jun 22 2012 18:30:23) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

Apache version:
----------------
Server version: Apache/2.2.22 (Unix)
Server built:   Feb  7 2012 03:02:43

APC version: 3.1.10 (even though it reports 3.1.9 [another bug]).

This bug did NOT occur in 5.3.12 and APC 3.1.9.


Test script:
---------------
My set.php file:
------------------
<?php

require 'base.php';
....


My APC config:
-----------------------
[APC]
;specifies the size for each shared memory segment
apc.shm_size=50M
;max amount of memory a script can occupy
apc.max_file_size=1M
apc.ttl=0
apc.gc_ttl=3600
; means we are always atomically editing the files
apc.file_update_protection=0
apc.enabled=1
apc.enable_cli=1
apc.cache_by_default=1
; breaks wordpress
apc.include_once_override=0
apc.localcache=0
apc.localcache.size=512
apc.num_files_hint=1000
apc.report_autofilter=0
apc.rfc1867=0
apc.slam_defense=0
apc.stat=0
apc.stat_ctime=0
acp.ttl=7200
apc.user_entries_hint=2048
apc.user_ttl=7200
apc.write_lock=1

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-06-23 02:37 UTC] andrew at quizlet dot com
-Summary: APC forgets replaces a require filename with empty string +Summary: APC replaces a `require` filename with empty string
 [2012-06-23 02:37 UTC] andrew at quizlet dot com 
fix title
 [2012-06-26 01:06 UTC] andrew at quizlet dot com 
I reproduced this on my mac (using standard macports). I narrowed it down to 
stat=0. If I omit stat=0 or set it to stat=1, the problem goes away.

This is reproduced across platforms.
 [2012-06-26 01:06 UTC] andrew at quizlet dot com
-Summary: APC replaces a `require` filename with empty string +Summary: APC stat=0 replaces a `require` filename with empty string -Operating System: Solaris SmartOS +Operating System: Mac OS X / Solaris SmartOS -PHP Version: 5.4.4 +PHP Version: 5.4.4 / 5.4.3
 [2012-07-03 13:28 UTC] rasmus@php.net
-Status: Open +Status: Feedback
 [2012-07-03 13:28 UTC] rasmus@php.net 
For 5.4.x, please use the SVN version of APC for now. There have been some 
interned strings fixes recently that most likely fixes this. Try it and report 
back, please.
 [2012-07-03 18:32 UTC] andrew at quizlet dot com 
Still broken on Trunk
-------

Just tried with SVN trunk on mac:
svn co http://svn.php.net/repository/pecl/apc/trunk/ apc-trunk
cd apc-trunk
phpize
./configure --prefix /opt/local --enable-apc
make
make install
.....

This is what php info says about apc:

APC Support	enabled
Version	3.1.11-dev
APC Debugging	Disabled
MMAP Support	Enabled
MMAP File Mask	no value
Locking type	pthread mutex Locks
Serialization Support	php
Revision	$Revision: 325875 $
Build Date	Jul 3 2012 11:20:54


And `make test` passes all tests except for:


APC: bindump file cache part 1 [tests/apc_bin_002.phpt]
 [2012-07-03 20:59 UTC] rasmus@php.net 
This works fine on Linux and FreeBSD and this is the only report we have of this 
issue. Until someone who is able to debug this can reproduce it, this probably 
won't be fixed.
 [2012-07-19 17:05 UTC] rasmus@php.net 
Automatic comment from SVN on behalf of rasmus
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=326703
Log: Fix bug 62398
 [2012-07-19 17:06 UTC] rasmus@php.net 
Well, that was a dumb bug. Fixed in svn now. I'll try to get through a few more 
open APC bugs and get a release out soon, but in the meantime grab the SVN 
version and verify that this works for you now.
 [2012-07-19 17:06 UTC] rasmus@php.net
-Status: Feedback +Status: Closed -Assigned To: +Assigned To: rasmus
 [2012-07-20 00:17 UTC] andrew at quizlet dot com 
Awesome, thanks a lot Rasmus!
 [2012-07-20 17:27 UTC] ab@php.net 
Automatic comment from SVN on behalf of ab
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=326740
Log: added base for testing with cli server plus a test for bug #62398
 [2014-03-17 16:41 UTC] antoni at friki dot cat 
I can reproduce the same ploblem with APC installed from Debian Stable.
Rasmus's patch is already aplied.

I already have reported it here (sorry for crossing):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741956

The only difference is that I can reproduce this problem with 'include' (not 'require'). Make it sense?
 [2014-08-06 08:18 UTC] mk at cloudcontrol dot de 
The bug is present also for below versions:

PHP version:
----------------
PHP 5.4.30-2+deb.sury.org~precise+1 (cli) (built: Jul  2 2014 12:07:10)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies

Apache version:
----------------
Apache/2.2.22 (Unix)

APC version:
----------------
3.1.13
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Thu Jan 09 16:01:29 2025 UTC