Closed Bug 545757 Opened 11 years ago Closed 11 years ago

Sync/RPC replies are posted to the IO thread after hangs

Categories

(Core :: IPC, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: cjones, Assigned: cjones)

References

Details

(Whiteboard: [land m-c])

Attachments

(1 file)

This can cause messages delivered to the IO thread to race with the incoming notification of the closed channel.
(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.
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: nobody → jones.chris.g
Attachment #426592 - Flags: review?(bent.mozilla)
Attachment #426592 - Flags: review?(bent.mozilla) → review+
Blocks: 545237
http://hg.mozilla.org/mozilla-central/rev/c5ca3076da1b
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.