WordPress.org

Make WordPress Core

Opened 20 months ago

Last modified 7 months ago

#21650 new defect (bug)

replace serialize() with print_r() in stats() function in wp-includes/cache.php

Reported by: bobbingwide Owned by:
Milestone: Future Release Priority: low
Severity: minor Version: 3.4.1
Component: Cache API Keywords: needs-patch
Focuses: Cc:

Description

In PHP 5.3 it is no longer possible to serialize data that contains a SimpleXMLElement object. It produces a fatal error. See https://bugs.php.net/bug.php?id=49800

The stats() function attempts to determine the allocated space for objects in the cache by using strlen() of the serialized object.

This can fail for the reason above.

Given that the figure returned is simply an estimation of the space
I propose that the code is changed to use
print_r( $cache, true ) instead of serialize( $cache )

ie. to become
echo "<li><strong>Group:</strong> $group - ( " . number_format( strlen( print_r( $cache, true ) ) / 1024, 2 ) . 'k )</li>';

This TRAC was raised after a longish chain of events starting with #18488 and the final response (today) which led to another chance discovery of a similar problem in the debug-bar plugin.

http://wordpress.org/support/topic/plugin-debug-bar-fatal-error-uncaught-exception-serialization-of-simplexmlelement-is-not-allowed

Attachments (1)

cache.php.21650.diff (564 bytes) - added by bobbingwide 20 months ago.
Replace serialize() with print_r() to avoid Fatal error (WP 3.5)

Download all attachments as: .zip

Change History (8)

bobbingwide20 months ago

Replace serialize() with print_r() to avoid Fatal error (WP 3.5)

comment:1 scribu20 months ago

  • Severity changed from normal to minor

The way this estimation is presented is very misleading; it makes you think you're viewing the size of the cache in memory, rather than the lenght of it's serialization.

comment:2 scribu20 months ago

Other than that, switching to print_r() seems sane.

comment:3 wonderboymusic20 months ago

  • Keywords has-patch added

comment:4 wonderboymusic8 months ago

  • Milestone changed from Awaiting Review to 3.7

comment:5 nacin8 months ago

How is a SimpleXMLElement object making its way into object cache? It should not be allowed in postmeta, options, etc., as those all serialize (even going into cache). I imagine it would only occur when you are using your own cache bucket?

Should we do a try/catch and fall back to print_r()? I'm fine with moving over to print_r() but it's probably even less of a decent representation of the approximate size in cache.

comment:6 follow-up: ryan8 months ago

A try/catch with fallback to print_r() seems sufficient to cover this edge case. serialize() does give us a better approximation.

comment:7 in reply to: ↑ 6 nacin7 months ago

  • Keywords needs-patch added; has-patch removed
  • Milestone changed from 3.7 to Future Release
  • Priority changed from normal to low

Replying to ryan:

A try/catch with fallback to print_r() seems sufficient to cover this edge case. serialize() does give us a better approximation.

Yeah, I agree. Happy to commit a patch that does this. Because this is merely a debugging situation, and it's a very particular issue, I'm pushing on this. Super edge.

Note: See TracTickets for help on using tickets.