mailing.* tokens cause memory leak in civimail.cronjob.php, plus another problem

I have been having memory issues with civimail.cronjob.php - see http://forum.civicrm.org/index.php/topic,22359.msg93724.html and http://forum.civicrm.org/index.php/topic,22211.msg93343.html

I've found the cause of the memory, and I have attached a patch. There's another issue, but I'm not sure how to resolve that.

Our CiviMail Mailing header includes the mailing.viewUrl token. During the processing of each email CRM_Mailing_BAO_Mailing::getTokenData() is called to process this token. Here's the code for mailing.* tokens ...

} else if( $type == 'mailing' ) {
require_once 'CRM/Mailing/BAO/Mailing.php';
$mailing = new CRM_Mailing_BAO_Mailing( );
$mailing->find( true );
if ( $token == 'name' )

{ $data = $mailing->name ; }

else if ( $token == 'group' )

{ $groups = $mailing->getGroupNames( ); $data = implode(', ', $groups); }

} else {

The creating and populating of a new CRM_Mailing_BAO_Mailing has two issues ...

• When I use CRM_Utils_System::memory() it tells me that memory usage increases by 3Mb each time this is called. Commenting out the call resolves the memory issue.
• The find() call populates the CRM_Mailing_BAO_Mailing with the content of the first mailing - not this mailing. I suspect if I was using the mailing.name token I'd get a surprise!

I think the fix should be ...

• Only do a 'new' and a 'find' if they're needed - ie when the token is mailing.name or mailing.group
• Review whether 'new' and 'find' are actually needed - why not use $this rather than $mailing?

The attached patch assumes that $this can be used instead of creating a new mailing.