Open
Bug 1209359
Opened 9 years ago
Updated 2 years ago
Assert that invalid ipc::FileDescriptor isn't sent over IPC
Categories
(Core :: IPC, defect)
Core
IPC
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox44 | --- | affected |
People
(Reporter: jld, Unassigned)
Details
We used to assert that invalid (default-constructed) mozilla::ipc::FileDescriptor values weren't sent over IPC; code that wants an optional FileDescriptor can use an IPDL union instead. Bug 831307 looks to be when that changed, and it looks like that assertion was on the receiving side, so the stack trace wasn't very useful for finding out what had gone wrong. If we want to enforce this, we should be asserting it on the sending side. Also, from that patch it looks as if there are some cases where dup()/DuplicateHandle() failures could introduce an invalid file descriptor. This seems like a footgun, but I don't know if there's a good way to deal with it, or if that's in scope for this bug. (Could we make FileDescriptor move-constructable and require explicit duplication? And could that help clean up its current somewhat confusing ownership semantics?)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•