Closed Bug 871390 Opened 7 years ago Closed 7 years ago
Leaking Shmem with No
Swap canvas update
This is a regression from bug 863223. When we send the transaction, we add the Shmem to the changeset and clear our local reference to it. On the compositor side, we give the Shmem to the ImageHost, which uploads to the texture from it and then creates a reply to send it back. Since this is a no-reply transaction, we don't bother to send the reply and we leak instead. What was the intended behaviour here? To create a new shmem every frame (and have the compositor free it), or to keep re-using it (and require that the compositor finish copying from it during the transaction). We should also probably send this intention over IPC so that the compositor knows that it shouldn't be writing a reply. And assert that no reply changesets are generated. Attached is a simple fix that just makes sure we hang onto a copy of the Shmem so we can release it.
7 years ago
Duplicate of this bug: 870165
This bug is a regression from my patch for 863223. I accidentally made 2d canvas transaction async instead of webgl ones.
Assignee: nobody → snorp
Attachment #749313 - Flags: review?(matt.woodrow)
Attachment #749313 - Flags: review?(matt.woodrow) → review+
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
Comment on attachment 749313 [details] [diff] [review] Sends 2d transactions synchronously and webgl ones async [Approval Request Comment] Low risk, fixes gigantic memory leak when using 2d canvas. Been on m-c for a couple weeks without issues.
Attachment #749313 - Flags: approval-mozilla-aurora?
Attachment #749313 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.