Background:
I just grabbed the current version of Piwik -- In version 1.5, line 969 appears as:
public function addRowsFromSerializedArray( $stringSerialized )
{
$serialized = unserialize($stringSerialized);
if($serialized === false)
{
throw new Exception("The unserialization has failed!");
}
$this->addRowsFromArray($serialized);
}
and is specifically $serialized = unserialize($stringSerialized);
. The call to unserialize
can be incredibly memory intensive. There is an excellent post here.
As you've noted, this clearly isn't a bug in your script and is a valid Out of Memory.
Suggestion: In the config file, as noted above in my comment:
/.../piwik/config/global.ini.php
I think you may need to increase one of these limits:
# during archiving, Piwik will limit the number of results recorded, for performance reasons
# maximum number of rows for any of the Referers tables (keywords, search engines, campaigns, etc.)
# this limit will also be applied to the Custom Variables names and values reports
datatable_archiving_maximum_rows_referers = 1000
# maximum number of rows for any of the Referers subtable (search engines by keyword, keyword by campaign, etc.)
datatable_archiving_maximum_rows_subtable_referers = 50
# maximum number of rows for any of the Actions tables (pages, downloads, outlinks)
datatable_archiving_maximum_rows_actions = 500
# maximum number of rows for pages in categories (sub pages, when clicking on the + for a page category)
# note: should not exceed the display limit in Piwik_Actions_Controller::ACTIONS_REPORT_ROWS_DISPLAY
# because each subdirectory doesn't have paging at the bottom, so all data should be displayed if possible.
datatable_archiving_maximum_rows_subtable_actions = 100
# maximum number of rows for other tables (Providers, User settings configurations)
datatable_archiving_maximum_rows_standard = 500
where I changed the semi-colons to # signs just to make sf's autocolor readable.
You might also try adding:
CMD_TO_CHECK_SETTINGS="$PHP_BIN -i > /tmp/piwik-php-env.out"
$CMD_TO_CHECK_SETTINGS
to archive.sh to determine if there are other settings afoot which override the php.ini file.
It looks as if you pipe your mails through the sendmail program of Postfix. But when your error occurs then the data stream to sendmail suddenly stops. In this case after 276 bytes. So Postfix is unable to send the mail as the header is incomplete and missing the To: field.
One possibility may be that the PHP script gets killed due to low memory. Or other cleanup tasks that eliminate the process that pipes the mail. While sendmail/Postfix is still running as expected.
Best Answer
Is short tags turned off on the new server?
There's an
<? endif; ?>
block just above the error that will be getting missed by PHP if short tags is off.