After upgrade SaveToFile fails on some systems.

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   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.

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
yapihds Members Profile Find Members Posts Beginner Joined: 09 Jul 21 Status: Offline Points: 3	Post Options Post Reply Quote yapihds Report Post Thanks(0) Quote Reply 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.

tfrost Members Profile Find Members Posts Senior Member Joined: 06 Sep 10 Location: UK Status: Offline Points: 437	Post Options Post Reply Quote tfrost Report Post Thanks(0) Quote Reply 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.

yapihds Members Profile Find Members Posts Beginner Joined: 09 Jul 21 Status: Offline Points: 3	Post Options Post Reply Quote yapihds Report Post Thanks(0) Quote Reply 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!

tfrost Members Profile Find Members Posts Senior Member Joined: 06 Sep 10 Location: UK Status: Offline Points: 437	Post Options Post Reply Quote tfrost Report Post Thanks(0) Quote Reply 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/