Welcome Guest Search | Active Topics | Sign In | Register

Essential Objects Product Support Forum » All Products » Support » Web browser possible racing condition (v2015.2.37.0)

Web browser possible racing condition (v2015.2.37.0) Options
Previous Topic · Next Topic
Jim B
Posted: Tuesday, September 1, 2015 4:21:57 AM
Rank: Advanced Member
Groups: Member

Joined: 1/31/2015
Posts: 70
Hello,

While trying to reproduce an issue with the keyboard focus getting "lost" and never returned, we have stumbled on a strange behavior on TabbedBrowser.

Scenario:
Environment: Virtual windows 7 x64 machine with 4096mb ram, single core (core is important)

Actions:
1) open up tabbedbrowser
2) load a pdf (either from file or from the web) on about 65 new tabs. We do this by loading an html file (file:///c:/test.html) with the following contents:

Code: HTML/ASPX 
<html>
<body>
<a href="#" onclick="window.open('https://library.snu.ac.kr/sites/default/files/library-brochure/leading_the_way_2015.pdf', '_blank', 'fullscreen=yes'); return false;">MyPDF</a>
</body>
</html>


Expected behaviour:
all pdf tabs should open and cpu should return to idle

Actual outcome:
On our test machine, the 63rd tab always causes 100% cpu

Notes: on another machine under same OS and multi-core i7, Tabbedbrowser crashes (closes unexpectedly) before the 40th tab opens.

We hope that if you guys could identify a racing condition within your code under the above conditions, you could exterminate a bug that has been causing at least 3 different problems (keyboard focus being lost forever, printer not spooling and various channel disconnections/ child process not ready exceptions).

Maybe we could close all these cases together.

I can give you access to the test machine if this helps.

Thanks for reading!

Regards,

Jim
Back to top
 
eo_support
Posted: Monday, September 7, 2015 4:55:29 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,229
Hi,

We were able to reproduce this problem. The root of the problem is a memory allocation failure in the render process. The supposed behavior when this occurs is to crash the process immediately (on purpose) so that the code that uses the allocation result would not have a chance to act on invalid buffer thus causing more strange issues. However there is a bug in our code that falls into an infinite loop when it supposes to crash the process.

In real life scneario such crash is much less likely to occur. The reason that it occurs in your case is because all tabs that loads Url from the same domain is managed by a single render process. In real life scenario people can have dozens of tabs that loads pages from various domains --- thus spliting the load into various render processes and reducing the chances of any of these render process hitting the memory limit. In your case since all tabs are opening the same Url, so they are all managed by a single render process thus will hit the memory limit pretty fast.

In our next build the render process will crash as expected in this case. The crash event will be propogated back to your process and trigger the WebView.Closed event. You can handle this event to and recreate the WebView if needed. Note that you may want to delay recreating since a single render process crash will results in all the WebViews using that process to close, so if you automatically create one new WebView when an old one dies, then you will immediately hit the memory limit again.

Thanks!
Back to top
 
Jim B
Posted: Tuesday, September 8, 2015 5:01:40 AM
Rank: Advanced Member
Groups: Member

Joined: 1/31/2015
Posts: 70
Hello,

Thanks for investigating and replying.

Our application is performing automations on a single website only. Unfortunately, the normal scenario for us is opening all pdfs from the same domain. Also, our clients use several types of windows pcs, some are strong with enough ram installed but some are weak 2gb machines.

You write that in your next build, the render process will crash as expected. My guess is that it will be hard for us to handle this allocation failure in a "graceful" way.

Why does the allocation failure occur in the first place?

Kind regards,

Jim
Back to top
 
eo_support
Posted: Tuesday, September 8, 2015 7:57:53 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,229
Hi,

You will need to change your application design for this. The "expected" crash behavior is the behavior of the chromium browser engine. So it would not be practical for us to to try to change it.

The reason that it fails in the first place is because the render process is a 32 bit process so it only got 2GB of virtual memory space no matter how much physical memory you have. As long as that process getting close to the 2GB virtual memory space limit allocation will fail.

Thanks!
Back to top
 
Jim B
Posted: Tuesday, September 8, 2015 8:02:26 AM
Rank: Advanced Member
Groups: Member

Joined: 1/31/2015
Posts: 70
I see. It makes sense.

We should be ok by redesigning this part after you fix the crashing bit.

Thanks for replying

jim
Back to top
 


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.