Do you own a Debenu Quick PDF Library version 7, 8, 9, 10, 11, 12, 13 or iSEDQuickPDF license? Upgrade to Debenu Quick PDF Library 14 today!

Debenu Quick PDF Library - PDF SDK Community Forum Homepage
Forum Home Forum Home > For Users of the Library > I need help - I can help
  New Posts New Posts RSS Feed - After upgrade SaveToFile fails on some systems.
  FAQ FAQ  Forum Search   Register Register  Login Login

After upgrade SaveToFile fails on some systems.

 Post Reply Post Reply
Author
Message
yapihds View Drop Down
Beginner
Beginner


Joined: 09 Jul 21
Status: Offline
Points: 3
Post Options Post Options   Thanks (0) Thanks(0)   Quote yapihds Quote  Post ReplyReply Direct Link To This Post Topic: After upgrade SaveToFile fails on some systems.
    Posted: 09 Jul 21 at 12:27AM
We have an old library that was setup to use V8.16 of QuickPdf and I was tasked to upgrade to the latest V18.11 to see if it would fix some random Access Violations we were getting. Everything seemed to work in our testing but once it was released to production we have seen some systems where the call to SaveToFile fails and LastErrorCode is 0. Does anyone have any ideas on what would have changed to cause SaveToFile to fail on some systems.

Note: The way our usage of QuickPdf was implemented is weird to me. There are helper functions that load, draw, save the pdf for each element on the pdf. So there can be hundreds of calls to load and save the same pdf from/to the file system. It worked with the old library version but the new version eventually fails on one of the saves in the middle of producing the pdf and only on some systems.
Back to Top
tfrost View Drop Down
Senior Member
Senior Member


Joined: 06 Sep 10
Location: UK
Status: Offline
Points: 363
Post Options Post Options   Thanks (0) Thanks(0)   Quote tfrost Quote  Post ReplyReply Direct Link To This Post Posted: 09 Jul 21 at 11:24AM
These symptoms are consistent with a bug in your code, perhaps a random overwrite or buffer overflow, which has just moved elsewhere after upgrading, to cause a different fault. What programming language are you using? If it was Delphi I would suggest trying to change all the load/save functions except the first and last to use a Tmemorystream instead of a file; still not ideal, but faster, and simpler than a complete rewrite, and it might avoid problems if they arise from the repeated save and load operations.
Back to Top
yapihds View Drop Down
Beginner
Beginner


Joined: 09 Jul 21
Status: Offline
Points: 3
Post Options Post Options   Thanks (0) Thanks(0)   Quote yapihds Quote  Post ReplyReply Direct Link To This Post Posted: 09 Jul 21 at 6:02PM
Yeah, I was thinking how we are using the library is problematic. We are using C#(.Net 4).
I added some logging around many of the operations and received a production log file from our tech support from a system showing symptoms yesterday.
Generating the PDF runs fine for awhile and then one of the save operations fails.
  'PdfHelper Error in DrawRectangleYN calling QuickPdf SaveToFile. Result: 0, Last Error Code: 0'
Once the save fails it is game over because it looks like the progress made generating the pdf is lost. I start getting.
  'PdfHelper Error in DrawText calling QuickPdf LoadFromFile. Result: 0, Last Error Code: 401'

Is there a chance the File IO changed between versions and the SaveToFile calls are competing with each other?

Also, the system that the log file was generated on is a VMWare VM could that be a factor?

I might be able to get by-off to rewrite the wrapper library to keep the document in progress in memory and only save once at the end, but that may take awhile to get too.

Any other thoughts would be appreciated.
Thanks!
Back to Top
tfrost View Drop Down
Senior Member
Senior Member


Joined: 06 Sep 10
Location: UK
Status: Offline
Points: 363
Post Options Post Options   Thanks (0) Thanks(0)   Quote tfrost Quote  Post ReplyReply Direct Link To This Post Posted: 09 Jul 21 at 11:03PM
I am only an occasional C# user, so I cannot really help with debugging. In your position I would fire up Process Monitor from SysInternals, and filter on the pathname used for save.  It will tell you whether there was really a file error and if so what it was.  This may be difficult if you cannot reproduce the problem in-house, but even when it runs without failure, procmon may reveal something about the way the raw file operations are being performed.

Is the file local or on a UNC path when it fails?  Rapid opening and closing a file on a network drive can sometimes fail if Windows directory and file info caching is enabled (which it is, by default). If this may be happening, try registry entries which set the three cache times to 0 on the machine running your application, as described at
https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/file-server/
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 11.01
Copyright ©2001-2014 Web Wiz Ltd.

Copyright © 2017 Debenu. Debenu Quick PDF Library is a PDF SDK. All rights reserved. AboutContactBlogSupportOnline Store