php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #40967 On hold until seen again
Submitted: 2007-03-31 15:06 UTC Modified: 2007-04-03 21:16 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: Webbed dot Pete at gmail dot com Assigned:
Status: Not a bug Package: Reproducible crash
PHP Version: 5.2.1 OS: Linux
Private report: No CVE-ID: None
 [2007-03-31 15:06 UTC] Webbed dot Pete at gmail dot com
Description:
------------
If I do 
{ 
  $from=getarray();
  $tgt=array_merge($to,$from); 
} 
all is well. But if I do 
{
  $tgt=array_merge($to,getarray());
}
then the page blows up with a 500 internal server error (and getarray() is never called). 
I can't (yet) duplicate this as a simple test case; it only happens in the middle of a large site source base.

This is on an Apache server (1.3.37) with PHP 5.2.1 running as CGI.

The *really* painful part is the 500 Internal Server Error, with no PHP error messages of any kind. Made it incredibly painful to track this down ;)

Reproduce code:
---------------
See above. I've not yet got a simple test case. All of the following produce the 500 error:

  $tgt=array_merge($to,getarray());
  $tgt=array_merge($to,$from=getarray());
  $tgt=array_merge($to,(array)getarray());

Only if the getarray() call is outside the array_merge() does it succeed.

Expected result:
----------------
a) No error

b) Better debugability of 500 Internal Server Errors caused by PHP


Actual result:
--------------
500 Internal Server Error with no other message.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-04-01 22:51 UTC] judas dot iscariote at gmail dot com
Then tell use what the.. the getarray() function does **exactly**
 [2007-04-02 09:06 UTC] Webbed dot Pete at gmail dot com
[To answer your question directly: the getarray() function retrieves an array from an in-memory global cache var]

Actually, the getarray() function is immaterial; it's never called when the system is set in "crash mode". I put a debug trace-to-file on the line before and after the array_merge() call, and also as the first element of the getarray() function. The debug trace inside getarray() is never called while getarray() is embedded in the array_merge() call.

Now the good-yet-a-bit-frustrating news: we've resolved this issue, in an unusual way. The solution may be informative to other hard to track-down bugs.

Bottom line: the array_merge() problem went away when our webhost company rebuilt the custom php5 cgi script that runs php5 in the phpSuExec environment! How the execution environment can have any impact on array_merge() is beyond me, but that's the facts.

How we found this. Told here for the benefit of others who may find similarly troubling issues:
 
I discovered another 500 error that *did* point to execution environment (crash on chdir() with 100% perfect permissions) and reported it to our sitehost tech support, who escalated it to top tier support.

The chdir() crash was recognized as a phpSuExec issue, specifically "a problem with our php5 cgi script that launches PHP5 with custom configuration options which resulted in premature end of script headers errors."

Unfortunately, the corrupted cgi script was not saved for analysis. They simply ran their rebuild-php5-environment script, overwriting the whole thing.

In retrospect, they suspect an update to cPanel may have corrupted the script. The conversation continues: if an update did this, then perhaps other servers in their farm have the same problem and can be diff'd with mine. They don't keep backups of these scripts since they can be auto-gen'd.

I hope that helps! I'm still amazed that *anything* in the execution environment can impact the operation of something as benign as array_merge().

Pete
 [2007-04-03 18:47 UTC] tony2001@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.


 [2007-04-03 21:02 UTC] Webbed dot Pete at gmail dot com
Tony,

Sorry but the boilerplate response doesn't match the bug report.

I've already diagnosed the 'bug' as far as possible. Apparently the real issue had more to do with a strange interaction with the run environment more than with the code itself.

For now this might as well be placed on hold until someone else finds a similar situation, because my host provider lost the 'buggy' version of the php5-cgi-run script. 

For now, my hope is that this report will at least help others track down the problem when they see similar attributes.
 [2007-04-03 21:10 UTC] tony2001@php.net
500 Error is not PHP problem.
Please reopen the report when/if you have more information on the issue and how to reproduce it.
It doesn't make much sense to keep the report in the current state, because I can name you thousand reasons for this behaviour and all of them has nothing to do with PHP.
 [2007-04-03 21:16 UTC] Webbed dot Pete at gmail dot com
"It doesn't make much sense to keep the report in the current state"

I certainly agree! :)

"I can name you thousand reasons for this behaviour and all of
them has nothing to do with PHP."

Well, in this case it's clearly not the interpreter itself but MAY be related to the PHP environment variables used for setup.

As you suggested, we'll ask our network to report any similar situation(s).

Thanks much!
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Mon Jul 14 16:01:34 2025 UTC