deadlock with SyncRequestProxy

[GoogleCodeExporter]

What steps will reproduce the problem?
1. when cefclient load this url(http://vol.stock.hexun.com/000001.shtm) crashed.

Original issue reported on code.google.com by sibai...@gmail.com on 22 Feb 2011 at 10:02

[GoogleCodeExporter]

The problem appears to be a deadlock with SyncRequestProxy. WaitForCompletion() 
is called which blocks the UI thread. No SyncRequestProxy event hooks are 
called after that so the UI thread is never un-blocked. The problem may be 
timing related since it goes away if enough breakpoints are set in the code.

Original comment by magreenb...@gmail.com on 23 Feb 2011 at 5:27

• Changed title: deadlock with SyncRequestProxy
• Changed state: Accepted

[GoogleCodeExporter]

thanks 

Original comment by sibai...@gmail.com on 24 Feb 2011 at 1:22

[GoogleCodeExporter]

How long could this problem be solved.

Original comment by yyangl...@gmail.com on 1 Mar 2011 at 9:57

[GoogleCodeExporter]

We should test if this problem occurs with the Chromium test_shell application 
as well. If so, it should be reported to the Chromium developers.

Original comment by magreenb...@gmail.com on 2 Mar 2011 at 2:19

[GoogleCodeExporter]

glade to see you replay.nice to see this will be solved quickly.thanks

Original comment by yyangl...@gmail.com on 2 Mar 2011 at 4:29

[GoogleCodeExporter]

Does this problem be appered test_shell?

Original comment by yyangl...@gmail.com on 17 Mar 2011 at 6:03

[GoogleCodeExporter]

Hey, so I ran into this issue trying to use cef (on a project page at 
www.unfuddle.com) and dug into it a bit. It does fail the test_shell 
application for chromium rev 74933.

What I've found is the client_socket_pool is running out of available sockets - 
this results in the stream never becoming available and so the synchronous 
xmlhttprequest can never be serviced.

This ticket has a pretty good description of the issue as documented by the 
chromium team. http://code.google.com/p/chromium/issues/detail?id=12066 

My workaround at the moment is to increase the g_max_sockets_per_group to 15 in 
net/socket/client_socket_pool_manger.cc (will test a bit with tuning but that 
ticket claims that firefox as a single threaded browser (like libcef) has 15 
sockets per host).

Original comment by ddmac...@gmail.com on 24 Mar 2011 at 5:30

[GoogleCodeExporter]

Good catch. I've verified your findings and started a thread about it on 
chromium-dev. The attached patch applies your work-around without changing 
Chromium source code. We'll need to still fix the deadlock problem, but we can 
allow configuration of the max_sockets_per_group value via CefSettings.

Original comment by magreenb...@gmail.com on 24 Mar 2011 at 2:44

Attachments:

• increase_max_sockets_per_group.r206.patch

[GoogleCodeExporter]

The chromium-dev thread is here:
http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/
4aadd0da2c8f2016

Original comment by magreenb...@gmail.com on 24 Mar 2011 at 3:00

[GoogleCodeExporter]

This is blocked in http://crbug.com/45986

Original comment by magreenb...@gmail.com on 7 Apr 2011 at 7:22

[GoogleCodeExporter]

Issue 233 has been merged into this issue.

Original comment by magreenb...@gmail.com on 16 May 2011 at 3:30

[GoogleCodeExporter]

The workaround in comment#8 has been committed in revision 233.

Original comment by magreenb...@gmail.com on 16 May 2011 at 4:57

[GoogleCodeExporter]

Just wanted to add that I saw this as well with cef rev 254 against an internal 
html5 application - the workaround from comment 12 didn't do anything for me, 
even when the limit was greater than 15. 

The TestShell app hangs the same way.

I've attached a stack trace from gdb when hung. Still trying to understand the 
code - so sorry I have no suggestions. The web app has about 5 failed xhr 
requests before I get in the deadlock waiting for one to complete.

Original comment by WynnWil...@gmail.com on 10 Jun 2011 at 10:26

Attachments:

• cef-hang.log

[GoogleCodeExporter]

I should add the attached stack trace is the same for the TestShell.app program.

I don't see the same hang with a full Chromium browser instance.

Original comment by WynnWil...@gmail.com on 10 Jun 2011 at 10:36

[GoogleCodeExporter]

To update comment 13 - I was able to get my webapp to work when I upped the 
limit to 32.

Original comment by WynnWil...@gmail.com on 13 Jun 2011 at 3:31

[GoogleCodeExporter]

Need to update comment 15 - my 32-socket-limit workaround isn't reliable 
either. Still a big problem.

Original comment by WynnWil...@gmail.com on 28 Jun 2011 at 7:09

[GoogleCodeExporter]

I finally tracked down a potential fix for this very hairy problem. In my case 
a sync resource request would occur, then go into a IO pending state, then an 
async resource request would run on the IO thread. Since the UI thread was 
blocked, the async resource request couldn't finish from the UI thread 
notifications, leading to a deadlock.

Here's a patch that fixes the problem for me that uses the LOAD_IGNORE_LIMITS 
flag and the priority settings. Thoughts? Maybe there's a better way - I'm not 
sure what the impact of starting to use the priority setting are. Sorry if it 
doesn't apply cleanly - still figuring out git-svn and how to export.

Original comment by WynnWil...@gmail.com on 7 Jul 2011 at 11:48

Attachments:

• deadlock-fix.patch

[GoogleCodeExporter]

I haven't had a chance to test it yet, but the patch looks good to me except 
for some minor formatting issues.

Original comment by magreenb...@gmail.com on 14 Jul 2011 at 8:52

[GoogleCodeExporter]

The patch in comment #17 has been committed as revision 268 with minor 
formatting changes.

Original comment by magreenb...@gmail.com on 15 Jul 2011 at 8:32

• Changed state: Fixed

[GoogleCodeExporter]

Thanks!

Original comment by WynnWil...@gmail.com on 15 Jul 2011 at 8:38