|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79161 ini_set causes 500 error with no error text
Submitted: 2020-01-23 14:02 UTC Modified: 2020-01-23 17:08 UTC
From: martin dot barker at thisisbeacon dot com Assigned:
Status: Not a bug Package: FPM related
PHP Version: 7.4.2 OS: Linux ip-10-1-28-252 4.15.0-1051
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:
Bug Type:
From: martin dot barker at thisisbeacon dot com
New email:
PHP Version: OS:


 [2020-01-23 14:02 UTC] martin dot barker at thisisbeacon dot com
for some reason, `ini_set` in FPM is causing a 500 error with absolutely no error reporting,

So I'm running PHP 7.4.2 via nginx using the PHP socket, this also happened with PHP 7.4.1

 index index.html index.htm index.php;

 location / {
      try_files $uri $uri/ =404;

 location ~ \.php$ {
      include snippets/fastcgi-php.conf;
      fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;

Test script:
using phpMyAdmin Stable branch added `ini_set("display_errors", true);` to config.ini.php above the blowfish secret var set.

set error_report = E_ALL & display_errors = On to the php/7.4/php.ini then restarted php-fpm `service php7.4-fpm restart`

Expected result:
either error that ini_set is not allowed, or for the page to load and PHP to have accepted the ini_set directive.

Actual result:
I just get a blank white screen for a HTTP 500 error, absolutely no error information.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2020-01-23 15:46 UTC]
-Status: Open +Status: Feedback
 [2020-01-23 15:46 UTC]
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.

additionally you could have a look at the error_log setting as it might provide more information. You should also try disabling any extensions to see if that helps
 [2020-01-23 16:06 UTC] martin dot barker at thisisbeacon dot com
-Status: Feedback +Status: Open
 [2020-01-23 16:06 UTC] martin dot barker at thisisbeacon dot com

<?php ini_set("display_error", true);  echo "durrrr"; ?>
 [2020-01-23 16:11 UTC] martin dot barker at thisisbeacon dot com
I would also say that not supporting or testing against one of the biggest applications to use PHP is a little lax in QA.

The fact is a gave a test scenario that is very easy to follow and take a couple of mins to set up not using some small obscure system.
 [2020-01-23 16:23 UTC] martin dot barker at thisisbeacon dot com
-Status: Open +Status: Closed
 [2020-01-23 16:23 UTC] martin dot barker at thisisbeacon dot com
Closed unable to replicate on another box
 [2020-01-23 16:51 UTC] bugreports at gmail dot com
<?php ini_set("display_error", true);  echo "durrrr"; ?>

this is a completly useless comment

* 1: display_error is wrong spelled
* 2: display_errors don't change the error_reporting
 [2020-01-23 17:08 UTC]
-Status: Closed +Status: Not a bug
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sat Jan 22 03:03:33 2022 UTC