|
|
Rank: Advanced Member
Groups: Member
Joined: 2/11/2015
Posts: 122
|
I discovered a bug when trying to resolve a crash in my software. I believe the bug exists on either the EO.Browser code or the Chrome code.
If you prepare a large series of script calls to execute in the browser that result either directly or indirectly in DOM manipulations EO will throw a stack overflow exception;
I have a test project ready to go. It contains the libraries, a test page, and the Visual Studio project files.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi, Thanks for posting in the forum. Yes, a test project will be crucial for troubleshooting this kind of problems. Please follow these instructions to send the test project to us: http://www.essentialobjects.com/forum/test_project.aspxThanks
|
|
Rank: Advanced Member
Groups: Member
Joined: 2/11/2015
Posts: 122
|
There is a local policy problem with submitting the test project via email, I'm currently investigating if I can get around the issue.
If I cannot is there any alternative submission mechanism I can use?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
Make sure you remove all the DLLs from your test project. If that still does not work, you might want to use a web based email solution to send us the test files. Or you can post the test project somewhere online and the PM us the download link (make sure you do not include your license key in the test project). The general rule is we have no way of getting around your security policy if your security policy is meant to work.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 2/11/2015
Posts: 122
|
My support team has released the email, you should receive the test project shortly, please verify for me that you have received it.
I wanted to add some more details about the project configuration in the mean time.
I'm using the Multi-DLL library, I have not tested if the problem is present in the Single-DLL version of the EO library.
If it is not present in the Single-DLL version, please note that due to memory requirements we cannot switch to the Single-DLL version.
Per your guidelines I will not be including the libraries in the zip file, however the project is still setup to reference them.
The test project is setup to Reference EO.WebBrowser.Dll and EO.WebBrowser.Wpf.dll
I also included the following DLLs in the project root so they will be copied to the output dir.
d3dcompiler_46.dll
EO.WebBrowser.Native.dll
ffmpegsumo.dll
icudt.dll
libEGL.dll
libGLESv2.dll
|
|
Rank: Advanced Member
Groups: Member
Joined: 2/11/2015
Posts: 122
|
Have you received the test project?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
Yes. We have received the test project. We will look into it and get back to you as soon as possible.
Thanks!
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
This is just to let you know that we have posted a new build that should fix this problem. You can download the new build from our download page. Please take a look and let us know how it goes.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 2/11/2015
Posts: 122
|
Hi,
It looks like this worked for the QueueScriptCall method. However it appears to not resolve the issue for EvalScript, though this may be due to a less than obvious re-entrant call chain.
We will be moving over to QueueScriptCall to resolve the issue on our end.
Thank you for the quick response!
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
Thanks for the update. Yes. EvalScript can cause strange re-entry issues that are rather hard to troubleshoot. Re-entry is allowed for both, but QueueScriptCall can avoid most re-entry issue because of the "queue" nature of the call.
Thanks!
|
|