Way to debug crashing?

[ugradedeveloper]

I am using the SDK in a software product that is used by our employees to mark-up existing PDF documents. The software also allows inserting pages from a standardized set of existing handouts. PDF-XChange Viewer often crashes when the page insert operation is executed.

I have been trying to collect enough information to allow the Tracker development team to reproduce the crash, but it is very difficult. For one thing, the crash does not happen predictably. It may happen once or twice for a given document, but on the third try it will work. Also, there is great variety in the documents that our users manipulate. Some were created from word-processing files and some come from scanned documents. Finally, there is no standardization of the hardware on which the software runs.

Since I cannot collect enough information for the developers to reproduce the problem, I wonder if there is any other approach to finding the cause. Would it be possible for me to obtain a special 'debug' build that would emit information about the current state of the application at the time it encounters a fatal error? I don't know if this would even be possible or helpful, I am just bit desperate to get this problem fixed, as it is causing some of my users real aggravation.

Thanks for anything you can do

Lewis

[John - Tracker Supp]

Before going further - a few questions - as we do not have any known stability issues at all as you will see for a quick perusal of other forum topics ...

What specific SDK are you using - the ActiveX (Iassume) or the Simple DLL..

What build is currently being used and distributed - the latest is 2.050

Is there any common installation properties - e.g. Windows OS ?

Thanks

[ugradedeveloper]

Yes, I am using the ActiveX SDK.

I have just distributed build 49 to my users a few days ago, and the problem is still occuring. I have been steadily rolling out the new builds over the past year or so, and the problem has persisted.

Regarding common installation properties, our employees for the most part have to supply their own computer, so there is no consistency at all. For the one user who experiences the problem most often, the OS is XP Pro, SP 2. But I suspect her experiencing the problem more often is simply due to the fact that she uses the relevant feature more often.

Any other information I can supply?

[ugradedeveloper]

One more thing I should mention. This is almost certainly the key issue and I should have mentioned it at first.

There are two types of handouts that we use. One type consists of plain document text and these never seem to cause a problem.

The second group contain interactive forms with Javascript. Because of the limitations of the existing Viewer, the application cannot simply insert the new page, as the form elements will not be respected. So I coded a workaround whereby:
1) the active document is closed and saved to a temporary file
2) the document containing the interactive form is copied over the filename of the original document, and this is opened
3) all pages from the temporary file (the original document) are then inserted into the currently opened document, after the existing page. This is when the viewer crashes.

When the viewer component crashes, my application recognizes that the insert operation failed and it then tries to roll back the situation to where it was at the beginning. This means closing the file which is currently open and trying to copy the original document back to its proper name/location. Because all the errors are logged, I can see the pattern which occurs. At this point, a second error inevitably follows, which is "The process cannot access the file [name] because it is being used by another process." [name] is the file which was last opened, the one containing the interactive form.

I guess that all this closing, copying and reopening of files is the cause of the problem, but due to the needs of my application (written originally using Adobe Acrobat) and the current limitations of the viewer, I have not been able to find another solution.

Thanks again.

[John - Tracker Supp]

Hi - could you provide a couple of sample forms so we can experiment here ...

If you prefer - you can email these to support@pdf-xchange.com with a link back to this forum article for reference, also I suspect it is going to be helpful to us both if we can get some sample code from you to investigate to see if we can offer some advice here on effecient/safe processes/ logic to follow for the task at hand - perhaps some Pseudo code initially so we can better understand the process used (and also how this might present itself to your clients) - one concern would be just how much back and forth processing is going on with the document open etc ... - but there could be many area's to look at.

Many thanks.

[ugradedeveloper]

I am replying by e-mail.

Thanks.

[John - Tracker Supp]

OK - thanks

[Stefan - PDF-XChange]

Hey Lewis,

When did you send the e-mail as I can't seem to find it in support@ and Vasyl would like to investigate and has requested the contents of this e-mail?

Regards,
Stefan

[ugradedeveloper]

That's strange because I have already received a reply. It was signed John Verbeeten.

[Stefan - PDF-XChange]

OK then,

Shall we count the case as closed in that case?

Best,
Stefan

[ugradedeveloper]

Shall we count the case as closed in that case?

Well, his reply just said "Will get back to you in the next 24 hours or so - just as soon as we have had a chance to investigate here."

[John - Tracker Supp]

Hi Lewis - JV here - I do have and will be back to you later today.

[Vasyl - PDF-XChange]

Hi, Lewis.

We will investigate and fix this trouble.
Please wait for new build.

Best
Regards.

[ugradedeveloper]

We will investigate and fix this trouble.
Please wait for new build.

Thanks a lot.

I would be grateful if you would let me know when/if you are able to reproduce the error.

Lewis

[Vasyl - PDF-XChange]

Unfortunately - I cannot reproduce this error.
Looking your email, and your pseudocode:

Code: Select all

...
-- this is where the first error occurs
if (InsertPages(tempfile, 0, numPages) == false)
{
     CloseDocument()
     -- this is where the second error "being used by another process"
     File.Copy(tempfile, _gradingFilename, overwrite)
}

I still unable to reproduce error(crash) in this code-line:

Code: Select all

if (InsertPages(tempfile, 0, numPages) == false)

But in second case:

Code: Select all

File.Copy(tempfile, _gradingFilename, overwrite);

you may receive the error(not crash) really because viewer releases document asynchronously.
For the second case we will add special PXCVA_ForceRelease flag for the CloseDocument function.

We will continue investigate this problem.

For test only: please disable your handling for our com-events during executing of your InsertPages.
Also you can try to use the alternate method for page inserting (pseudocude):

Code: Select all

// setup source pages range (all pages)
SetProperty("Operations.InsertPages.File", "<SourceFullFileName>", 0);
SetProperty("Operations.InsertPages.RangeType", "All", 0);
SetProperty("Operations.InsertPages.RangeFilter", "All", 0);
SetProperty("Operations.InsertPages.FromExternal", "true", 0);
// insert all pages from source
DoDocumentVerb(destDocId, NULL, "InsertPages", stub, NULL, PXCVA_NoUI);

HTH.

[ugradedeveloper]

you may receive the error(not crash) really because viewer releases document asynchronously. For the second case we will add special PXCVA_ForceRelease flag for the CloseDocument function.

I suspected that somehow the resource was not really being released right away when a file was closed. This new flag should be helpful, thank you.

For test only: please disable your handling for our com-events during executing of your InsertPages.

Sure, I will try that.

Also you can try to use the alternate method for page inserting (pseudocude):

Code: Select all

// setup source pages range (all pages)
SetProperty("Operations.InsertPages.File", "<SourceFullFileName>", 0);
SetProperty("Operations.InsertPages.RangeType", "All", 0);
SetProperty("Operations.InsertPages.RangeFilter", "All", 0);
SetProperty("Operations.InsertPages.FromExternal", "true", 0);
// insert all pages from source
DoDocumentVerb(destDocId, NULL, "InsertPages", stub, NULL, PXCVA_NoUI);

HTH.

I was aware of that method - I wondered whether it would be worthwhile to try that instead of using Javascript. But I assumed that the implementation of inserting pages would be the same regardless; in other words, that both API methods would feed into the same code behind the scenes. But I will try this if you think it worth while.

Thanks again
Lewis

[John - Tracker Supp]

Hi Lewis,

Please do try and let us know how it goes.

[ugradedeveloper]

I installed an updated program for my main 'problem user' with the Viewer/SDK upgraded to build 50, and made the two suggested changes - disabling the event handler for the duration of the insert operation, and using the non-Javascript method of invoking the insert command. I am sorry to say the crashes and errors are the same as before.

Just to be clear, I should say that by "disabling the event handler" I don't just mean setting the event handler function to return without taking any action, I mean I actually removed the event hook.

Lewis

[Vasyl - PDF-XChange]

Hi, Lewis.

I still cannot reproduce this trouble.
I have written code which is very similar to described by you in your email.
Tried it on the files from your email. My program has executed the test with these (and more other) files some thousand times.
No any crashes, it works properly!

Can you prepare the simple example for reproducing? It will be very helpful in this case.
And - what is OS in your main 'problem user'?

Thanks.

[ugradedeveloper]

Can you prepare the simple example for reproducing? It will be very helpful in this case.
And - what is OS in your main 'problem user'?

The OS string is: Microsoft Windows NT 5.1.2600 Service Pack 2 (Win XP Professional)

I will work on preparing a stripped-down sample for reproducing.

Thank you
Lewis Kapell

[Vasyl - PDF-XChange]

Many thanks.
Will wait for your example and continue investigating...

Best
Regards.

[ugradedeveloper]

I have sent a Visual Studio 2005 project (zipped) by e-mail with instructions about how to reproduce the crash.

Thanks.

Edit: Whoops, I got a message saying the e-mail was blocked. Looks like our server stopped it on the way out because of the contents of the ZIP file. I'll see if I can fix the problem by removing the binaries, if not I will try uploading it here.

Edit again: looks like it went through after I removed all .exe and .dll files.

[John - Tracker Supp]

Thanks Lewis,

Have forwarded to Vasyl who will come back to you directly, pleased note he is based in our European office - so there is a time differential...

Cheers

[Vasyl - PDF-XChange]

Hi Lewis.

You can try to use this temporary workaround:

Code: Select all

SetProperty("PageDisplay.CreateLinksFromURLs", "false", 0);

Please let me know the result. Thanks.

Best
Regards.

[ugradedeveloper]

Well that did it! I tested it with my main 'problem user' and she has used the function a dozen times so far with no errors.

Thank you! I will tell my other users to disable that option if they are encountering the same crashing issue.

Lewis

[Paul - PDF-XChange]

[Vasyl - PDF-XChange]

Super! Thank You, Lewis.

Will fix this trouble in the new build.
You will be able to remove this temporary workaround.

Best
Regards.

[ugradedeveloper]

[John - Tracker Supp]

[ugradedeveloper]

Can anyone confirm that this fix will be in build 51? And when that build is slated for release?

Thanks
Lewis

[John - Tracker Supp]

I can

Released this week/weekend.

[ugradedeveloper]

Thanks.

[John - Tracker Supp]

pleasure.

[MikeHolik]

Was the special PXCVA_ForceRelease flag for the CloseDocument function not added? We too are running into problems where the resource was not really being released right away when a file was closed. Thanks

[Vasyl - PDF-XChange]

Hi, Mike.

You may use one undocumented feature:

Code: Select all

pdfViewer.SetDocumentProperty(docID, "SyncClose", "true", 0);
pdfViewer.CloseDocument(docID);

HTH

[MikeHolik]

Thank you for the quick feedback. One follow up question - CloseDocument called with the PXCVA_NoUI flag is equivalent to calling CloseDocument with no flag and answering "Yes..." when prompted to save correct?

[MikeHolik]

Because it seems that when I call
SetDocumentProperty(..., "SyncClose", "true", 0);
CloseDocument(..., 0) I am prompted to save and if answer yes the document is save right away.

However if I call CloseDocument(..., PXCVA_NoUI) I am not prompted but the document is not save either.

Thank you.

[Vasyl - PDF-XChange]

Sure, the:
CloseDocument(..., PXCVA_NoUI)
- ignores document's modification and closes it immediately, without saving.
Use:
SetDocumentProperty(..., "SyncClose", "true", 0);
SaveDocument(docID, NULL, 0, PXCVA_NoUI);
CloseDocument(..., PXCVA_NoUI);

HTH