Welcome Guest Search | Active Topics | Sign In | Register

EO.PDF hang issue Options
Daba
Posted: Wednesday, May 22, 2019 7:08:36 AM
Rank: Newbie
Groups: Member

Joined: 12/10/2018
Posts: 5
Hi.

I made a post a while back about a memory leak issue we had with a Pdf-generation C# windows service running EO v15.
We have now acquired a new license, and upgraded our service in production, which solved the memory leak issue.
However, we now encounter a different issue. Occasionally the service hangs, and stops generating pdf's. The memory use of the running processes are static, but the CPU usage is reduced to 0. After restarting the service, everything returns to normal, until the issue is encountered again. There is no exception thrown, and therefore also no error message. We suspect the error to originate from EO.PDF, as we have not experienced a similar error prior to upgrading from v15 to v19.1.25.

We have been unable to recreate the error, as we do not know under what circumstances it occurs. I can see in the ChangeLog for v19.1.11, you fixed an issue which sounds similar to what we're experiencing: "Fixed converting HTML that contains an iframe with invalid Url can cause EO.Pdf to hang issue;".
Can you assist with diagnosing the issue, or perhaps shed some light on how you identified the root cause for the aforementioned similar issue?
eo_support
Posted: Wednesday, May 22, 2019 9:35:54 AM
Rank: Administration
Groups: Administration

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

There can be many completely different scenarios that could cause HTML to PDF converter to hang and we can only works on a case by case basis. For the previous issue that was fixed in 19.1.11, it was caused by an iframe with an invalid Url. In order to start the conversion, the PDF converter would wait for the whole document to be loaded first. This would in turn wait for all iframes to be loaded. Prior to 19.1.11, if an iframe has an invalid Url, it would not to notify the parent document (the main document to be converted) that it has finished loading (failed). This causes the parent document not to realize that all iframes are done loading and cause the converter to hang. In this particular case, the converter will not hang forever --- it will eventually trigger a time out error and other concurrent conversion will continue to function. So this does not appear to be the same as the issue you are running into.

The most effective way to troubleshoot such issue is to create a test app to reproduce it. If that's not possible, you can enable the build in debug monitor if that's possible by calling this method when your application starts:

https://www.essentialobjects.com/doc/eo.base.runtime.startdebugmonitor.aspx

You can then wait for the application to hang and let us know. We can then examine the internal state/logs to see what we can find.

Thanks!
Daba
Posted: Tuesday, June 18, 2019 4:36:21 AM
Rank: Newbie
Groups: Member

Joined: 12/10/2018
Posts: 5
Hi,

Making a test project is difficult, as we are not able to recreate the issue locally, and the occurrences are not predictable.

I have looked at the remote debug monitor and have gotten it to work locally. However, I’m not sure this is a viable way to troubleshoot the problem for us. As I understand it, it only allows you (EO) to access our application remotely, it does not allow us to debug the application ourselves or create a dump of the application state to send to you for analysis – i.e. we would have to keep the application in a non-working state until you are able to perform your analysis.

Is this understanding of the debug monitor tool correct? If so we will need a different strategy for debugging the issue, because we can’t keep the application in a non-working state for that long, and more than that I can’t see us being able to grant anyone that kind of access to any of our environments.
eo_support
Posted: Tuesday, June 18, 2019 1:43:11 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,218
Yes. Your understanding is correct. One thing you can try to do is use a debugger to capture the stack trace of all running stacks when the problem occurs and send that to us. That can often tell us which threads are deadlocking with which. We are also looking into adding such features in our remote debug monitor so that you can capture the stack trace and then restart the application without having to leave it hanging for a long period of time.
Daba
Posted: Monday, August 5, 2019 5:45:22 AM
Rank: Newbie
Groups: Member

Joined: 12/10/2018
Posts: 5
Hi.

I have made a dump of the process, to which e-mail address should i send it?
eo_support
Posted: Monday, August 5, 2019 2:08:35 PM
Rank: Administration
Groups: Administration

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

You can use our contact us page to send it to us. If you update to the latest build, you can also use DebugTools.exe to both capture the debug information and send it us directly. DebugTools.exe is our preferred method since it specifically captures the information that we are mostly interested.

Thanks!
eo_support
Posted: Wednesday, August 21, 2019 2:11:01 PM
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 fix this problem. You can download the new build from our download page.

Thanks!


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.