|
|
Rank: Advanced Member
Groups: Member
Joined: 11/3/2015
Posts: 65
|
Ah, okay sorry...
I'll change it in my program.
fyi I found a memory leak in the Webside.
"Normal chrome" has no problem with it, but EO. ... But I could fix it.
Now I'm going to monitor, if there are other problems, that causses crashes, too.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
M.Kramer wrote:Ah, okay sorry...
I'll change it in my program.
fyi I found a memory leak in the Webside.
"Normal chrome" has no problem with it, but EO. ... But I could fix it.
Now I'm going to monitor, if there are other problems, that causses crashes, too. It's not uncommon that a page runs with "Normal Chrome" but not with EO because of memory leaks. EO child processes run in 32 bit mode and Google Chrome usually runs in 64 bit mode. So if there is a memory leak, Google Chrome usually can tolerate it longer. However in any case a memory leak in your page should always be fixed.
|
|
Rank: Advanced Member
Groups: Member
Joined: 11/3/2015
Posts: 65
|
Quote:However in any case a memory leak in your page should always be fixed. of course ;)
|
|
Rank: Advanced Member
Groups: Member
Joined: 11/3/2015
Posts: 65
|
Hi, next case (as I told you, I think there are more than one problem) The Webengine crashes sometimes at one user while she is opening the ContextMenu. Sadly no crash report except System.Exception: This WebView either has already been destroyed or is being destroyed. Quote:
tmpWebView.BeforeContextMenu += new BeforeContextMenuHandler(WebView_BeforeContextMenu);
void WebView_BeforeContextMenu(object sender, BeforeContextMenuEventArgs e)
{
e.Menu.Items.Clear();
e.Menu.Items.Add(new EO.WebBrowser.MenuItem("Ausschneiden", CommandIds.Cut));
e.Menu.Items.Add(new EO.WebBrowser.MenuItem("Kopieren", CommandIds.Copy));
e.Menu.Items.Add(new EO.WebBrowser.MenuItem("Einfügen", CommandIds.Paste));
e.Menu.Items.Add(new EO.WebBrowser.MenuItem("Löschen", CommandIds.Delete));
e.Menu.Items.Add(EO.WebBrowser.MenuItem.CreateSeparator());
e.Menu.Items.Add(new EO.WebBrowser.MenuItem("Drucken", CommandIds.Print));
}
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
M.Kramer wrote:Hi,
next case (as I told you, I think there are more than one problem)
The Webengine crashes sometimes at one user while she is opening the ContextMenu.
Sadly no crash report except System.Exception: This WebView either has already been destroyed or is being destroyed.
Please try to reproduce it first. There isn't much we can do at all if you just say it crashed.
|
|
Rank: Advanced Member
Groups: Member
Joined: 11/3/2015
Posts: 65
|
Hi,
now I'm abel to reproduce it.
It appears after several (20-30?) clicks on the right mous button.
I've got e crashreport in .dat format and will send it to you now.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
Hi,
Please try to isolate the problem into a test project and send the test project to us. This crash seems to have occurred after the WebView has already been closed. So it is not the root of the problem. The root of the problem is somehow the WebView is closed and we have to find out why it has been closed.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Hello, a new comment on my initial issue here, it appears that no crashdata is collected/saved for the issue that we are experiencing.
How do we continue to debug it?
So far it looks like an important factor is that lots of Javascript is being executed on the page after certain user interactions, these are all queued via QueueScriptCall.
Please give us some direction on what we can do next to get to the root of this issue because in this way we cannot release our product with the EO browser to all of our customers and we'll be forced to stop using the EO browser eventually, which would be a shame because it is better in most regards than the standard WinForms control.
Is there maybe in your code something that can dispose/destroy the browser control if something goes wrong when executing Javascript?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
Hi,
There isn't much we can do unless you can reproduce it. Chromium has over 20 million lines of code and it is not possible for us to "guess" what could be wrong in these 20 million+ lines of code. The only way to precisely resolve an issue is to reproduce it, debug it, fix it and then verify it. Any other way would be just shooting in the dark. We would either miss the problem completely, or accidently hit a switch that turns of the alarm but not fixing the issue itself. Not only we would be wasting our time in that case, the same problem could surface for you again later at a different place in a different form. So it has no benefit to you either. As such for this kind of issue it must be reproduced first.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Hello,
We have enabled crashdata reporting for a while and it looks we got a hit when the error occurred now, unfortunately this is the only crash report we've gotten while we already have had tons of crashes since our last comment.
So we have a 28 KB file that should contain the binary crash data, however the crash occurred when we were working on sensitive data that we are not allowed to share with other parties. Is there a way to debug/decode this crashdump by ourselves such that we can make sure that there's no sensitive data included in the crashdump?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
Hi,
There is no way you can decode the crash report yourself. It mainly contains information about running threads and their stacks. We will need to match that data with our debug symbols in order to locate the location of the crash, which often can reveal the root cause. There is no guarantee that the stack won't contain any sensitive data though because it contains the value of local variables and argument. So for example, if your code call LoadUrl(your_senstive_url) and this stack is captured, then the value of your_sensitive_url argument will be in the stack capture. Obviously we are not interested in any of your sensitive data because our goal is to troubleshoot the problem. However if that is a problem for you then you might want to find out someway to reproduce the problem with dummy data.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Okay, that is something we will need to discuss internally then, we can reproduce the issue in a dummy application however no crash report has been generated in any of the dozens of crashes I have faced in the dummy application. However, after lots of hours of debugging we have found an anomaly that we believe is in the EO engine and it could be related to the issue we are facing. We have a reproducible example where we have the following: 1. Click on a button in the browser which gets handled via the ObjectForScripting/window.external call and waits on a manual reset event slim. (Normally this would show a modal dialog on top of the webcontrol in the actual application) 2. We perform an action that keeps the browser busy for a specified amount of time, for example 10 seconds. 3. We release the manual reset event slim. (Normally this would be closing the modal dialog) 4. We click on a button in the browser that shows an alert to the user. Because waiting on the manual reset event slim locks the entire main UI thread we started a second UI thread where the "Expensive script" and "Unblock" buttons are available. Now I'll share the code we are running and what steps to take in order to reproduce the issue we are seeing. The code: Quote:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;
using EO.WebBrowser;
using EO.WinForm;
namespace EOTestNestedClick
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(CreateForm());
}
private static Form CreateForm()
{
var manualResetEventSlim = new ManualResetEventSlim();
var form = new Form
{
Size = new System.Drawing.Size(1280, 1024)
};
var webView = new WebView();
webView.ObjectForScripting = new ExternalObject(webView, manualResetEventSlim);
webView.LoadHtml(
@"<html><body>
<button onclick='window.external.block();'>Block</button>
<br />
<button onclick='alert(42);'>Alert</button>
</body></html>");
WebView.ShowDebugUI();
var webControl = new WebControl
{
Dock = DockStyle.Fill,
WebView = webView
};
var unblockButton = new Button
{
Dock = DockStyle.Bottom,
Text = "Unblock"
};
unblockButton.Click += (sender, e) => manualResetEventSlim.Set();
var expensiveScriptButton = new Button
{
Dock = DockStyle.Right,
Text = "Expensive script"
};
expensiveScriptButton.Click += (sender, e) =>
{
webView.QueueScriptCall(
@"(function() {
var d = new Date ().getTime () + 10000;
while (new Date ().getTime () < d) {
}
})();");
};
form.Controls.Add(webControl);
var buttonForm = new Form
{
Size = new System.Drawing.Size(800, 600)
};
buttonForm.Controls.Add(unblockButton);
buttonForm.Controls.Add(expensiveScriptButton);
new Thread(() =>
{
var nativeWindow = new NativeWindow();
nativeWindow.AssignHandle(IntPtr.Zero);
buttonForm.ShowDialog(nativeWindow);
}).Start();
return form;
}
}
public class ExternalObject
{
private readonly WebView webView;
private readonly ManualResetEventSlim manualResetEventSlim;
public ExternalObject(WebView webView, ManualResetEventSlim manualResetEventSlim)
{
this.webView = webView;
this.manualResetEventSlim = manualResetEventSlim;
}
public void block()
{
manualResetEventSlim.Wait();
}
}
}
The steps in order to reproduce the issue: 1. Wait until the browser is loaded and open its DevTools. 2. Click on the Performance tab and start profiling. 3. Click on the "Block" button in the browser. 4. Click on the "Expensive script" button in the form on the other UI thread. 5. Click on the "Unblock" button in the form on the other UI thread, make sure this is done within the 10 seconds of computation performed in the expensive script call. 6. Click on the "Alert" button in the browser even though the form is locked. Also within those 10 seconds. 7. Wait until the browser is unlocked/unfrozen, this should be after those 10 seconds. 8. Stop profiling. What you will see is that at one point there will be an "Event (click)" nested inside another "Event (click)" on the main thread. We expect that those clicks are handled in succession. We also believe that this could be the root cause of the issue we are facing. I have attached a screenshot of the profiler output that we are seeing. 
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
Hi,
Thanks for the detailed information. We were able to find the root of the problem. This issue will be fixed in our next build. Specifically there are two issues in the current build:
1. In the current version, "Expensive script" would start while extInvoke is still running. This would cause JavaScript engine re-entering and it should not be allowed. In the new build, this script will not run until extInvoke returns;
2. As you noticed the nesting mouse click event should not be allowed. This will also be fixed;
We will reply here again as soon as the new build is available.
Thanks
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
Hi,
This is just to let you know that we have posted a new build that should address this issue. You can download the new build from our download page. Please take a look and let us know how it goes.
Because the new version does not allow re-entering JavaScript engine during extInvoke, it is no longer possible to call EvalScript from inside extInvoke handler. If you have code that relies this, you would need to change such code since it is no longer allowed.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 10/24/2018
Posts: 97
|
Thank you for the fix! The behavior that we reported in the last post has indeed been resolved. Unfortunately our original issue still persists. We don't know whether it is related to the latest fix, but now we have found a reliable way to reproduce the problem in our application. It is most likely related to blocking inside an ObjectForScripting handler for an extended period, the problem (the webview going white) seems to only appear after having been blocked for at least 30 seconds. Possibly QueueScriptCall (and the delayed execution of said scripts) is also involved. We have decided to analyze these unexpected eowp.exe shutdowns with use of GFlags > Monitoring Silent Process Exit. And indeed, we have found something: "The process 'C:\Program Files\Pluriform Client\PluriNova\eowp.exe' was terminated by the process 'C:\Windows\System32\svchost.exe' with termination code -1073741819. The creation time for the exiting process was 0x01d585be7a26e3cc." The resulting error code in HEX is exactly FFFF FFFF C000 0005, which most likely indicates an access violation exception (when ignoring the leading FFFF FFFF which are probably the result of a high bit somewhere in the return code). This lead us to also collecting heap dumps whenever a crash occurred. The monitor collected two heap dumps of eowp.exe, which may be possibly because one browser was nested on top of another one. Following is a WeTransfer link of said dumps: https://we.tl/t-LmmQ4ovhRqWe are using the latest version, 2019.2.91.0. Unfortunately we cannot provide a reproducible example in a test application as the relevant code to our issue is a very big amount and may result in rebuilding half of our application. We really hope that you can work together with us to identify and fix the root cause based on these crash dumps, no other errors or EO crashdumps occur whenever this issue occurs.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,218
|
Hi,
Thanks for confirming the fix for the even re-entering issue.
We are not able to debug eowp.exe with your debug dump because the browser engine code is loaded from memory, not directly from a physical DLL. In order to debug the browser engine, we must have additional information such as which code segments is loaded to what address. When the code is directly loaded from a physical DLL file, the loading is done by Windows and such information is maintained by Windows and accessible through a debugger. For eowp.exe, the code is loaded by us and such information is maintained by us and would be included in our own crash report. This means we we have no way to debug your crash dump.
Due to the sheer size of the Chromium browser engine, the most effective way to track down to the problem is to have a repro. We can't speculate among a million possibilities among millions of lines of code. So if you have a way to duplicate it, please try to isolate it and send it to us.
Additionally, we are beginning to switch to the 2020 cycle and the browser engine will be updated around year end. So you may also want to wait until the new engine is out and see if that resolves the issue for you. Since we are already at the end of the 2019 cycle, even if we find the root of the this issue, it will most likely to be addressed in our initial 2020 build.
Thanks!
|
|