Open Radar

 
Summary:
I noticed recentsd consuming an increasing amount of real memory while my system is up. I attached Instruments and used the Allocation instrument. In the 15 minutes and 30 seconds I was recording, 43MB of new, persistent allocations were made. Most interesting was a set of 5,471 590-byte mallocs. A look with lldb shows that all of these are variants on this query:

SELECT recents.ROWID,\n       recents.bundle_identifier,\n       recents.dates,\n       recents.display_name,\n       recents.sending_address,\n       recents.original_source,\n       recents.weight,\n       recents.group_kind,\n       contacts.ROWID,\n       contacts.kind,\n       contacts.display_name,\n       contacts.address\n  FROM recents\n  JOIN contacts ON contacts.recent_id = recents.ROWID\n WHERE     recents.count = 1\n\n AND (kind IN (?)\n AND (cpsearch(contacts.display_name, ?, 5)\n OR icusearch(contacts.address, ?, 2))) AND bundle_identifier IN (?) AND last_date > 1349878830843

The last_date condition changes with each query, but otherwise it's the same.

Most of the other allocations seem related to query processing in sqlite. For example, there are 131,000 32 byte allocations triggered during yy_reduce in sqlite3Parser.

My guess is that because the last_date condition is being hard coded in the query rather than taking a parameter, recentsd is unintentionally creating more and more unique statement objects without releasing them.

Also significant: The queries/allocations only show up while Mail.app is running. So the bug may be on the Mail.app side.

Steps to Reproduce:
Watch recentsd memory allocation over an extended period of time.

Expected Results:
Memory usage by recentsd should be stable.

Actual Results:
Memory usage by recentsd grows.

Version:
OS X 10.10 (14A386a)