-
-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PDFDocument.SaveToMetaData() will crash spuriously #96
Comments
…a reference to the save logic. (**Incidentally, there are other thread crossings for pdf_document so we'll have to investigate this further as it's not just SAVE activity that's endangered by spurious crashes in annotation, tags or inks lists.**) Everybody should go through the QueueToStorage() API, by the way.
- added WPFDoEvents API for waiting for the UI thread to run its course (UI responsiveness), which is a strengthened version of DoEvents() - added WPFDoEvents APIs for mouse cursor Hourglass/Busybee override and reset: during application startup, this is used to give visual feedback to the user that the work done is taking a while (relatively long startup time, particularly for large libraries which are auto-opened due to saved tab panel sets including their main library tabs) - fixed a couple of crashes, particularly one in the RemarkOnException handler which crashed due to an exception being reported during application shutdown in one particular test run. (hard to reproduce issue, while we were hunting for causes of jimmejardine#98 / jimmejardine#96)
The crashes in Qiqqa (as reported in this issue and others, e.g. #98) are at least in part due to thread-unsafe coding of the After some contemplation, it was decided to make To ensure serialization and regular within-thread larger code thunks working on a PDFDocument instance is still performant and backwards compatible, the original PDFDocument class was moved into a "ThreadUnsafe" namespace and renamed to Remaining suspect areasInks, Annotations and Highlights still pass their lists by reference to callers instead of (deep) copying, hence these bits are still thread-unsafe while the code in PDFDocument might look safe there as there's a basic lock() provided, but as anyone savvy in multiprocess coding knows, that cute critical section is not enough. This is a TODO that should be addressed in a separate issue. |
…e (apart from the inks, annotations and highlights attribute lists). Fixes jimmejardine#96. - improve the internal code of `CloneExistingDocumentFromOtherLibrary_SYNCHRONOUS()` to help ensure we will be able to copy/transfer all metadata from the sourcing document to the clone. Code simplification. - code simplification/performance: remove useless LINQ overhead - `SignalThatDocumentsHaveChanged()`: improve code by making sure that a reference PDF is only provided when there really is only a single PDF signaled! Also see the spots where this API is being used. - belated commit of AlphaFS upgrade/refactoring for jimmejardine#106 ; a multi-pass code review has been applied to uncover all places where (file/directory) paths are manipulated/processed in the Qiqqa code. TODO: Streams. - redesign the ADD/REMOVE/GET-password APIs for PDFDocument as the indirection in the Qiqqa made it bloody hard to make thread-safe otherwise. (Fixes jimmejardine#96 / jimmejardine#98) - ditto for the GC-memleaking bindables of PDFDocument: all the binding stuff has been moved to the PDFDocument thread-safe wrapper class. (TODO: investigate if we can use WeakReferences more/better to prevent memleaks due to infinitely marked PDFDocument instances...) - tweak: `AddLegacyWebLibrariesThatCanBeFoundOnDisk()`: at startup, try to load all .known_web_libraries files you can find as those should provide better (= original) names of the various Commercial Qiqqa Web Libraries. (This is running ahead to the tune of jimmejardine#109 / jimmejardine#103)
…ion code in CitationManager and shallow-copy the Attributes of a DictionaryBasedObject.
|
Running the app at a machine load of sustained 100% (thanks to Qiqqa OCR background processes).
The crash occurs when you edit the BibTeX of a document in the Sniffer, but CPU load is so high that the responsiveness is reduced, so by the time Qiqqa has queued the document for storage in a background task (passing an implicit object reference of
pdf_document
) your next keypress == user edit comes in and it can happen that the Write action coincides such that .NET internals will cause the JSON serializer to barf because "the list has changed" -- which it did!Either we throw critical sections all over the place or we change the application such that it passes a COPY of the
pdf_document
across thread boundaries.Re that lingering user edit due to slow responsiveness: that SHOULD be dealt with already by yet another Save instruction being queued in that same thread-crossing queue as before.
Hence at least SaveToMetaData() has to be made thread-safe by copy-instancing the pdf document and the metadata therein, i.e. a (semi)DEEP COPY is called for AFAICT.
The text was updated successfully, but these errors were encountered: