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?)
You need to log in before you can comment on or make changes to this bug.