Closed
Bug 545757
Opened 15 years ago
Closed 15 years ago
Sync/RPC replies are posted to the IO thread after hangs
Categories
(Core :: IPC, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: cjones, Assigned: cjones)
References
Details
(Whiteboard: [land m-c])
Attachments
(1 file)
(deleted),
patch
|
bent.mozilla
:
review+
|
Details | Diff | Splinter Review |
This can cause messages delivered to the IO thread to race with the incoming notification of the closed channel.
Assignee | ||
Comment 1•15 years ago
|
||
(In reply to comment #0)
> This can cause messages delivered to the IO thread to race with the incoming
> notification of the closed channel.
Also with the destruction of the channel, which can lead to use-after-free. This is the problem I'm seeing locally on TestHangs.
Assignee | ||
Comment 2•15 years ago
|
||
After looking more, what was actually happening is that after a hang timeout, the RPCChannel was still posting replies to rpc in-calls to the RPCChannel. This was causing out-events to remain in the IO thread's queue, and breaking an assumption made about Close() --- after Close(), there's no more pending work for the IO thread. This led to a use-after-Clear() error when the IO thread dequeued the rpc reply posted from a dead channel; AssertIOThread() failed because mIOLoop was 0.
This bug might have been possible with regular channel errors too, but I never saw it after a *lot* of test runs. Might have been luck.
Summary: Close()ing a channel after a hang-kill but before error notification leaves the transport open → Sync/RPC replies are posted to the IO thread after hangs
Assignee | ||
Comment 3•15 years ago
|
||
Assignee: nobody → jones.chris.g
Attachment #426592 -
Flags: review?(bent.mozilla)
Updated•15 years ago
|
Attachment #426592 -
Flags: review?(bent.mozilla) → review+
Assignee | ||
Comment 4•15 years ago
|
||
Whiteboard: [land m-c]
Assignee | ||
Comment 5•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•