Problem/Motivation

Currently unserialize() return value isn't being checked in most cases. Adding error handling would improve Drupal's robustness and make it easier to debug cases where the serialized data has been corrupted. This has and can happen for many different reasons.

Proposed resolution

Add error checking to Drupal\Component\Serialization\PhpSerialize and use it in place of unserialize() when there is no good reason not to.

Remaining tasks

Discuss, improve the patch.

User interface changes

N/A

API changes

Data model changes

N/A

CommentFileSizeAuthor
#6 unserialize-failure-6.patch19.09 KBAntti J. Salminen
#2 drupal-unserialize.patch1.86 KBxavier_g
#1 core-handle-unserialize-failures.patch928 bytesxavier_g
core-handle-unserialize-failures.patch780 bytesxavier_g

Comments

xavier_g’s picture

xavier_g commented
Issue summary: View changes
StatusFileSize
new core-handle-unserialize-failures.patch928 bytes
xavier_g’s picture

xavier_g commented
StatusFileSize
new drupal-unserialize.patch1.86 KB

On second thought, it is probably better to provide a drupal_unserialize() function that takes care of checking the return of PHP's unserialize() and making it available to the caller through an extra parameter. The attached patch (drupal-unserialize.patch) achieves this.

pounard’s picture

pounard
Primary language French
commented

That sounds like a nice idea.

socialnicheguru’s picture

socialnicheguru commented
Status: Active » Needs review
pounard’s picture

pounard
Primary language French
commented

Something is bothering me in there, most of the time, unserialization errors comes from a system change (PHP version change, new PHP extension installed or uninstalled such as igbinary, or corrupted data in the storage level) and therefore, hiding them is hiding a potential unstable system.

My opinion is that the proposed drupal_unserialize() method hide such errors and make a system problem being silent, and that's bad. It should at the bare minimum log it using the WATCHDOG_ERROR level to avoid making them silent.

Ok didn't see that comment:

+  // No '@' operator: let PHP emit a notice if unserialize() fails so that
+  // one can notice there is some kind of problem.
+  // Also, the error offset may be useful.
Antti J. Salminen’s picture

Antti J. Salminen commented
Title: DrupalDatabaseCache::prepareItem() should handle unserialize() failure. » Drupal should handle unserialize() failure
Project: » Drupal core
Version: » 8.0.x-dev
Component: Code » base system
Issue summary: View changes
StatusFileSize
new unserialize-failure-6.patch19.09 KB

Looks like the same code still also exists in Drupal 8. Lack of any checking of unserialize() results also made #2565259: Some route serializations in update test database dumps are broken harder to debug.

#2216527: Inject a serialization format into database key/value storage added a serialization component and it could be possibly enhanced to check for the return value from unserialize() and used for these cases.

The attached patch does some of the work for 8.x. The original reporter mentioned the Drupal 7 equivalent of Drupal\Core\Cache\DatabaseBackend and I ran into this with Drupal\Core\Routing\RouteProvider so I converted those to using the PhpSerialize class in this. I included a test for RouteProvider because I initially created it before finding this issue and thinking of the wider picture.

Status: Needs review » Needs work

The last submitted patch, 6: unserialize-failure-6.patch, failed testing.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

lendude’s picture

lendude
Primary language Dutch
Location Amsterdam
commented
Category: Bug report » Task
Issue tags: +Bug Smash Initiative

Looking at old bug reports as part of the Bug Smash Initiative.

This seems like hardening to protect against bugs, but not a bug itself, so moving this to a Task for now.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.