590687 - Plugin container process is killed because not responding on RPC call

Status: RESOLVED DUPLICATE of bug 618810

(Core :: IPC, defect)

Description

[Egor Starkov]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.0.19) Gecko/2010031422 Firefox/3.0.19 ( .NET CLR 3.5.30729)
Build Identifier: 

Plugin container process is killed because not responding on RPC call.
There was idea that flash plugin creates new loop somewhere else, but found out that no new loops created.
The main reason of bug is sleeping OnMaybeDequeueOne  thread that dispatches all messages. Receiving thread pushes RPC call to the end of the queue and calls dispatching thread to process it. Dispatching thread pop first message from the queue, process it and goes to idle (by unknown reason). So the rest of queue remains not dispatched. One way of fixing this problem is to make batch dispatching of all incoming messages in one loop, not just single one for every thread iteration.

Reproducible: Always

Steps to Reproduce:
1. Navigate to youtube.com
2. Play any movie longer then 5 minutes
3. If full screen button is masked by 'QUEUE' panel, 
move 'QUEUE' panel by taping button in top-right corner two times OR change
mode to portrait mode
4. Enter full screen mode
Actual Results:  
Movie in full screen mode is playing about 2-3 minutes, then comes back to
embedded mode and grey background with Lego block shows instead movie.

Expected Results:  
Movie is playing in full screen mode.

Comment 1

[Egor Starkov]

Attachment: batch rpc dispatch

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to comment #0)
> Plugin container process is killed because not responding on RPC call.
> There was idea that flash plugin creates new loop somewhere else, but found out
> that no new loops created.
> The main reason of bug is sleeping OnMaybeDequeueOne  thread that dispatches
> all messages. Receiving thread pushes RPC call to the end of the queue and
> calls dispatching thread to process it. Dispatching thread pop first message
> from the queue, process it and goes to idle (by unknown reason).

So you're saying there's a message in the mPending queue, another message is pushed into the queue by the IO thread, the main thread eventually processes the first message but then never processes the second?

If so, this "unknown reason" sounds like the real bug here.  We process one message per event-loop iteration on gtk, windows, and mac, and haven't had any problems like this.

> So the rest of
> queue remains not dispatched. One way of fixing this problem is to make batch
> dispatching of all incoming messages in one loop, not just single one for every
> thread iteration.
> 

That doesn't fix any problems, it just might be papering over whatever problem you're seeing here, in some cases.  We're not going to do batch dispatch without detailed perf data, because batch dispatch can starve the processing of other tasks on the main thread.

You need to find out what the "unknown reason" is and if possible, write a test case for it so that we can test on other platforms.  Then we can look at what needs to be fixed.

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Egor: you might want to try the patch in bug 592002, which sounds similar to what you're seeing here.

Comment 4

[Egor Starkov]

Thanks for hint, but that patch does not help.

Comment 5

[Oleg Romashin (:romaxa)]

This problem is not reproducible with patch from 618810