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

go to bug id or search bugs for

Request #66354 Allowed memory size in Unknown on line 0
Submitted: 2013-12-26 14:18 UTC Modified: 2013-12-29 19:15 UTC
From: spam2 at rhsoft dot net Assigned:
Status: Not a bug Package: Scripting Engine problem
PHP Version: 5.5.7 OS: Linux
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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: spam2 at rhsoft dot net
New email:
PHP Version: OS:

 

 [2013-12-26 14:18 UTC] spam2 at rhsoft dot net 
Description:
------------
the whole php-error handler needs a rework

it is completly unhelpful get messages with "in unknown"
frankly there is *always* a script invoked and to debug someone needs
to know which script whatever error triggered

on machines with hundrets of vhosts and cronjobs using PHP you have no clue where to look in such cases and since this error was created on my personal workstation and reported twice in a month i would like to find what allocates that much memory

such errors are all over the language

[26-Dec-2013 14:47:28 Europe/Vienna] PHP Fatal error:  Allowed memory size of 335544320 bytes exhausted (tried to allocate 140731389980584 bytes) in Unknown on line 0

Test script:
---------------
by knowing the script there would be nothing to report

Expected result:
----------------
at least the physical path of the running script

Actual result:
--------------
unhelpful error messages

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-12-29 09:05 UTC] krakjoe@php.net
-Status: Open +Status: Not a bug
 [2013-12-29 09:05 UTC] krakjoe@php.net 
There is not always a script being invoked; "in unknown" means precisely that there is _no_ script being invoked, the memory is exhausted by the initialization or some or several modules in your setup and the engine hasn't even got the stage where it is executing user code, it would not be useful to report that these kinds of errors happened in any particular code since that would lead you to look places that can have no impact whatsoever on the error you are experiencing.

There is nothing that we can, or should do about this.
 [2013-12-29 12:50 UTC] spam2 at rhsoft dot net 
> There is not always a script being invoked

this is plain wrong, there maybe is no code auf the called script triggered due initialization but that does not change the fact taht the path of this damned script is for sure known, otherwise the code without the error could not be executed later
 [2013-12-29 19:15 UTC] krakjoe@php.net 
The point is that no code is being executed at the time of that error, it would not be useful to tell you the requested path of the request, since that would only lead you to think it was something wrong with a script in particular and it is not, it is down to the initialization of one or several modules requiring too much memory before script execution can even begin.
 [2013-12-29 19:23 UTC] spam2 at rhsoft dot net 
> The point is that no code is being executed at the time 
> of that error, it would not be useful to tell you the 
> requested path of the request

this is a *wrong* assumption

let the server-admin decide what he thinks is useful for him
hence if i get these messages multiple times for the same of some hundret vhosts it is my job to investigate if it is a attack from outside or the owner of the vhost triggers these errors and wonders about a white page while i have to consider if the limits needs to be raised or notify the customer what he should avoid - to do this i need at minimum the information which of the ten thousands of scripts on the machine was called
 [2014-01-11 18:14 UTC] spam2 at rhsoft dot net 
BTW - the root cause for the "Allowed memory size exhausted" is that PHP upstream broke opcache with 5.5.7 and 5.5.8 horrible while nobody cares or notices (except me and some other guy confirmed the issue)

https://bugs.php.net/bug.php?id=66460

look at my last comment

replace "ext/opcache" in the source tarball of 5.5.8 with the
opcache-source of 5.5.6 fixes all these problems
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri May 17 23:01:32 2024 UTC