Closed
Bug 516713
Opened 15 years ago
Closed 5 years ago
Statically check IPDL protocols for bad states
Categories
(Core :: IPC, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: benjamin, Unassigned)
References
Details
Statically check IPDL protocols. cjones, can you fill in the details of what we actually expect to be able to statically check with IPDL? I know we've talked about checking various kinds of state transitions: are we also going to check for racing asynchronous messages putting a protocol into a conflicting state?
IPDL (the language) already statically prevents deadlock and racy messages. We'd want to statically check that the concrete implementations of IPDL specifications conform to their specifications. This is (will be) checked dynamically for safety reasons, but we'd like to find as many bugs as possible statically. "Conformance" means (1) Don't attempt invalid state machine transitions --- i.e., don't try to send message M1 when it's not allowed by the current state S (2) For generated interface methods that allow C++ code to dynamically choose a "next state," the concrete class will only choose a state allowed by the specification Checking (1) is fairly hard, but some simplifications are possible. Checking (2) is relatively easy --- if a protocol allows dynamic choice of a set of states S, then the set of variables that "flow to" that outparam are a subset of S. To be honest, I don't think this is all that important of a project anymore, in a cost/benefit sense. But if someone wants to jump on it, I can expand on checking (1) in a later comment.
Comment 2•5 years ago
|
||
State machines were removed, and if I recall correctly we never even got to the point of enforcing them dynamically.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Comment 3•5 years ago
|
||
I think there may have been some enforcement in theory, but almost no protocols actually used them.
You need to log in
before you can comment on or make changes to this bug.
Description
•