Texture uploads from web cams leak
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox108 | --- | fixed |
People
(Reporter: jrmuizel, Assigned: jgilbert)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
We seem to leak shmems
Reporter | ||
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
Originally, we special-cased shmems to try to send them directly
without a copy.
Unfortunately, ipc::Shmem doesn't support that, so we
allocated a new shmem on PWebGL and sent that.
However, we didn't include shmem-cleanup steps in RecvTexImage, so we
leaked the shmem.
Let's check if there's a shmem buried in there and clean it up.
Assignee | ||
Comment 2•2 years ago
|
||
Originally, we special-cased shmems to try to send them directly
without a copy.
Unfortunately, ipc::Shmem doesn't support that, so we
allocated a new shmem on PWebGL and sent that.
However, we didn't include shmem-cleanup steps in RecvTexImage, so we
leaked the shmem.
We would be tempted to check inside the Desc in RecvTexImage and cleanup that
shmem, however RawTexImage from dtwebgl also uses this path, and its shmems
are UnsafeShmems, which are not supposed to be cleaned up.
Rather than adding e.g. a bool to differentiate them, let's just explicitly do
the cleanup in the caller that knows it needs to clean up.
One pattern I want to use more often for cross-process lifetimes is:
foo = new RefcountedResource();
SendUseAsync(foo);
SendPing()->Then([foo]() {})
By the time we the promise from SendPing is resolved, we know the remote side is
done with foo
, and so our trivial capturing lambda will take care of releasing
it on the Send side. It's straightforward and safe, and the lifetimes have one
extra return-trip of latency, but that's almost always fine.
Updated•2 years ago
|
Comment 4•2 years ago
|
||
bugherder |
Description
•