Skip to content
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

Closed
GerHobbelt opened this issue Oct 9, 2019 · 1 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
Milestone

Comments

@GerHobbelt
Copy link
Collaborator

Sometimes it takes a few seconds, sometimes ages before it happens: you ALMOST always end up with something like this in the log (v82pre):

20191006.105355 [Q] INFO  [Daemon.Maintainable:BackgroundWorkerDaemon.DoMaintenance_Infrequent] [172.801M] Indexing document 1FC78F204EF19FF95BC260B9BC9A9B57CCE8E
20191006.105355 [Q] DEBUG [Daemon.Maintainable:BackgroundWorkerDaemon.DoMaintenance_Infrequent] [172.916M] Using calculated PDF page count for file D:\Qiqqa\base\INTRANET_EF52564A-831D-42F2-B956-815CF0418C08\documents\1\1FC78F204EF19FF95BC260B9BC9A9B57CCE8E.pdf
20191006.105356 [Q] INFO  [Daemon.Maintainable:BackgroundWorkerDaemon.DoMaintenance_Infrequent] [174.430M] Indexing document 1FC11E81DE5201255F4DB72F18EF011931DB595
20191006.105356 [Q] DEBUG [Daemon.Maintainable:BackgroundWorkerDaemon.DoMaintenance_Infrequent] [174.537M] Using calculated PDF page count for file D:\Qiqqa\base\INTRANET_EF52564A-831D-42F2-B956-815CF0418C08\documents\1\1FC11E81DE5201255F4DB72F18EF011931DB595.pdf
20191006.105356 [Q] INFO  [Daemon.Maintainable:BackgroundWorkerDaemon.DoMaintenance_Infrequent] [172.161M] Indexing document 1FBD5921AC058917E69BD6D94A64E4FCD19E2DA
20191006.105356 [Q] DEBUG [Daemon.Maintainable:BackgroundWorkerDaemon.DoMaintenance_Infrequent] [172.267M] Using calculated PDF page count for file D:\Qiqqa\base\INTRANET_EF52564A-831D-42F2-B956-815CF0418C08\documents\1\1FBD5921AC058917E69BD6D94A64E4FCD19E2DA.pdf
The program '[22320] Qiqqa.exe: Program Trace' has exited with code 0 (0x0).
The program '[22320] Qiqqa.exe' has exited with code -1073740940 (0xc0000374).

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.

@GerHobbelt 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 GerHobbelt added this to the v82 milestone 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 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.
@GerHobbelt
Copy link
Collaborator Author

Closing and decluttering the issue list so it stays workable for me: fixed in https://github.com/GerHobbelt/qiqqa-open-source mainline=master branch, i.e. v82pre3 experimental release and beyond.

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
Projects
None yet
Development

No branches or pull requests

1 participant