Page MenuHomePhorge

PHP 8.2 "strlen(): Passing null to parameter #1 ($string) of type string is deprecated" in configuration
Closed, ResolvedPublic


When I sign in as an admin in my Phorge instance, I get a notification saying that Config 'notification.servers' is invalid as illustrated below :

screenshot-phorge-bug-config-notification.png (454×899 px, 36 KB)

First of all, I can see that the value is restored to "strlen(): Passing null to parameter #1 ($string) of type string is deprecated" witch is something abnormal for sure. I cannot find any error trace to identify where the issue is located (nothing in my web server log). Any idea to get the stacktrace and propose a fix ?

The second weird thing is that the 'notification.servers' key looks correct (by the way, it was not complaining before I moved my instance from PHP 7.4 to PHP 8.2). Here is its value :

root@xxx:/var/www/phorge/bin# ./config get notification.servers
  "config": [
      "key": "notification.servers",
      "source": "local",
      "value": [
          "type": "client",
          "host": "my.phorge.instance",
          "port": 22280,
          "protocol": "http"
          "type": "admin",
          "host": "",
          "port": 22281,
          "protocol": "http"
      "status": "set",
      "errorInfo": null
      "key": "notification.servers",
      "source": "database",
      "value": null,
      "status": "unset",
      "errorInfo": null

Event Timeline

Testing with my PHP 8.1, I can't replicate this. But I do have a bunch of PHP 8.1 fixes in place which are still awaiting approval.

One of them, D25367, fixes one instance of a strlen(null) being displayed without a stack trace. As that diff also fixes dashboards failing under PHP 8.1+, it might be worth patching it and seeing if it resolves the issue?

arc patch D25367

I applied this diff but unfortunately, it doesn't fix the issue...
What was your strategy to locate strlen(null) issue without any stacktrace, manual code analysis ?

What was your strategy to locate strlen(null) issue without any stacktrace, manual code analysis ?

'git grep' to find where the error page was generated, then adding the missing phlog($ex) to get the stack trace.

Eg: For the "Config 'notification.servers' Invalid" error you displayed:

$ git grep Config | grep Invalid
src/__phutil_library_map__.php:    'PhabricatorInvalidConfigSetupCheck' => 'applications/config/check/PhabricatorInvalidConfigSetupCheck.php',
src/__phutil_library_map__.php:    'PhabricatorInvalidConfigSetupCheck' => 'PhabricatorSetupCheck',
src/applications/auth/provider/PhabricatorAuthProvider.php:      throw new PhutilInvalidStateException('attachProviderConfig');
src/applications/config/check/PhabricatorInvalidConfigSetupCheck.php:final class PhabricatorInvalidConfigSetupCheck extends PhabricatorSetupCheck {
src/applications/config/check/PhabricatorInvalidConfigSetupCheck.php:    $groups = PhabricatorApplicationConfigOptions::loadAll();
src/applications/config/check/PhabricatorInvalidConfigSetupCheck.php:            PhabricatorEnv::getUnrepairedEnvConfig($option->getKey()));
src/applications/config/check/PhabricatorInvalidConfigSetupCheck.php:        } catch (PhabricatorConfigValidationException $ex) {
src/applications/config/check/PhabricatorInvalidConfigSetupCheck.php:            ->setName(pht("Config '%s' Invalid", $option->getKey()))
src/applications/config/check/PhabricatorInvalidConfigSetupCheck.php:                "Configuration option '%s' has invalid value and ".
src/applications/config/check/PhabricatorInvalidConfigSetupCheck.php:            ->addPhabricatorConfig($option->getKey());
src/applications/maniphest/constants/__tests__/ManiphestTaskStatusTestCase.php:    $this->assertConfigValid(false, pht('Invalid Key'), $invalid_key);

So if you can add to src/applications/config/check/PhabricatorInvalidConfigSetupCheck.php


just after the exception is caught on line 18 in executeChecks(), then that should provide the stack trace.

Great, I'll give it a try as soon as I can.

I finally found it, D25381 fix the issue.