-
-
Notifications
You must be signed in to change notification settings - Fork 65
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
long running FolderWatcher add session + recover PDFs from library: 100% CPU and random application crash (error 0xc0000374) #98
Labels
🧑🤝🧑help wanted🧑🤝🧑
Extra attention is needed.
🕵investigate
Needs further analysis to find the root cause.
🤔question
Further information is requested or this is a support question
Milestone
Comments
GerHobbelt
added
🧑🤝🧑help wanted🧑🤝🧑
Extra attention is needed.
🤔question
Further information is requested or this is a support question
🕵investigate
Needs further analysis to find the root cause.
labels
Oct 9, 2019
GerHobbelt
added a commit
to GerHobbelt/qiqqa-open-source
that referenced
this issue
Oct 9, 2019
… suspicion of memleaking and heapcorrupting as per jimmejardine#98 initial analysis report
GerHobbelt
added a commit
to GerHobbelt/qiqqa-open-source
that referenced
this issue
Oct 9, 2019
- 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)
GerHobbelt
changed the title
long running FolderWatcher add session + recover PDFs from library: 100% CPU and random application crash (error
long running FolderWatcher add session + recover PDFs from library: 100% CPU and random application crash (error 0xc0000374)
Oct 9, 2019
GerHobbelt
added a commit
to GerHobbelt/qiqqa-open-source
that referenced
this issue
Oct 15, 2019
…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)
GerHobbelt
added a commit
to GerHobbelt/qiqqa-open-source
that referenced
this issue
Oct 15, 2019
…ion code in CitationManager and shallow-copy the Attributes of a DictionaryBasedObject.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
🧑🤝🧑help wanted🧑🤝🧑
Extra attention is needed.
🕵investigate
Needs further analysis to find the root cause.
🤔question
Further information is requested or this is a support question
Sometimes it takes a few seconds, sometimes ages before it happens: you ALMOST always end up with something like this in the log (v82pre):
Adding logging to
CountPDFPages()
API seems to change the behaviour, but the crashes don't go away, they just occur at differen times. Besides, the moment of crash is highly unpredictable anyway, which is indicative of something seriously nasty and deep-rooted, e.g. timing/locking issues with multithreaded object/variable use (see #96 for one example of that)Analysis so far / Workaround = fix? 🤔🤔🤔 ❓
After running many of the sessions, which all abort Qiqqa suddenly and without any noise, just poof! and Qiqqa's gone!, every time with the same error 0xc0000374 which the InterWebz identify as memory heap corrupted, it smells like Sorax lib usage inside CountPDFPages() is a memory leaker (???) and corruptor as often the amount of (logged) memory-used-by-the-app slowly grows just before the final log line says '0xc0000374'.
Disabling the Sorax invocation in that API apparently removes the problem of sudden death, as now LuceneNet starts to throw hairballs after intense runs of several hours -- which never succeeded before due to the error code 0xc0000374: longest run was about 30 mins then.
The text was updated successfully, but these errors were encountered: