Wikimedia Bugzilla is closed!

First glance, without thinking about it too much, suggests you're missing a
library or extension needed to handle decompression. Off the top of my head, I
don't know if this is a built-in one (which would indicate a dodgy/broken PHP
config.) or something else, but that's what it appears to be.

What version of PHP?

We're running PHP version 4.3.11.  The BZip2 module, version 1.0.2, is enabled, as 
well as ZLib version 1.1.4.

This call failing probably indicates that the unserialize() failed in some way. Stick in 
something like var_dump($obj) on the prior lines to see what you've got.

This is what I get when I added the var_dump($obj) line 
to the HistoryBlob.php include file:


if( !is_object( $obj ) ) {
    // Correct for old double-serialization bug.
    $obj = unserialize( $obj );
}

var_dump($obj) 

// Save this item for reference; if pulling many
// items in a row we'll likely use it again.
$obj->uncompress();
$wgBlobCache = array( $this->mOldId => $obj );


Parse error: parse error, unexpected T_VARIABLE 
in /public/vhost/d/dharmaweb/html/includes/HistoryBlob.ph
p on line 258

You need a semicolon at the end of the line.

object(concatenatedgziphistoryblob)(6) { ["mVersion"]=> 
int(0) ["mCompressed"]=> bool(false) ["mItems"]=> array
(3) { ["ccd26dfde854fdb73601545c58811298"]=> string
(73370) " 

Long text of the article here...

 ["mDefaultHash"]=> string
(32) "10dea8ff26d89a7e83531f694ad7b535" ["mFast"]=> int
(0) ["mSize"]=> int(0) } object(historyblobstub)(3) { 
["mOldId"]=> string(4) "3029" ["mHash"]=> string
(32) "1b661dabd3208de1c359fd47713ad77a" ["mRef"]=> 
NULL } 

Do you know how to undo the CompressOld process?  

I just found out that viewing some articles is also having the same problem.  

Here is the error and the var_dump($obj); statement produces:

object(historyblobstub)(3) { ["mOldId"]=> string(4) "1791" ["mHash"]=> string
(32) "795e63467eeabd9e8f5548fedd0a0794" ["mRef"]=> NULL } 
Fatal error: Call to undefined function: uncompress() 
in /public/vhost/d/dharmaweb/html/includes/HistoryBlob.php on line 258

Is there way to uncompress?  Can I just take current articles and reinstall 
the database and import them back in later?

It turns out that when you run compressOld.php on your table, you can lose some
data. 

For articles whose 2nd revision is an article move, data will be lost. 

For the revisions, compressOld.php will first set the initial text entry to a
ConcatenatedGzipHistoryBlob object. 

It will then look at the 2nd revision entry which represents the move:

*************************** 1. row ***************************
        rev_id: 265949
      rev_page: 58415
   rev_comment: 
      rev_user: 0
 rev_user_text: 68.77.43.0
 rev_timestamp: 20060825022115
rev_minor_edit: 0
   rev_deleted: 0
   rev_text_id: 265193
*************************** 2. row ***************************
        rev_id: 265984
      rev_page: 58415
   rev_comment: [[Make You Paper or Essay Longer Than It Is]] moved to [[Make an
Essay Appear Longer Than It Is]]: correct spelling, make title more exact
      rev_user: 1254433
 rev_user_text: Ladanea
 rev_timestamp: 20060825024904
rev_minor_edit: 1
   rev_deleted: 0
   rev_text_id: 265193

Unfortunately this rev_text_id is exactly the same as the first one, and a
HistoryBlobStub gets stored here overwriting the ConcatenatedGzipHistoryBlob
object and data is lost. 

The way to fix this from occuring again is something like this in
maintenance/storage/compressOld.inc:

287,288c287,288
<                                               # Skip if not compressing and
don't overwrite the first revision
<                                               if ( $stubs[$j] !== false &&
$revs[$i + $j]->rev_text_id != $primaryOldid) {
---
>                                               # Skip if not compressing
>                                               if ( $stubs[$j] !== false ) {


Unfortunately there is no way to undo this process and get back your data. Your
only alternative is to somehow import the lost data from a backup, which you
hopefully have, into the text table. 

Thanks, Travis!

Applied fix on trunk in r19726 and rel1.9 in r19727.

I have same problem but i dont know how to fix it. What should i do to solve it?