https://bugs.kde.org/show_bug.cgi?id=399923
--- Comment #16 from caulier.gil...@gmail.com --- I think this problem is due to a race condition, undetectable with valgrind as speed is reduced a lots. This can be relevant of thread serialization used in face management. For me this code that I review a split in dedicated source code is too complicated. Marcel has written all this code with a student when face detection have been introduced and lets as well for a while Another negative point is opencast. This library is a large puzzle and, as I can see unit test code for image quality sorter, with few line of code, valgrind report a lots of memory corruption In project/script/ there is a bootstrap script to compile opencast with the minimum requirements for digikam. With this kind of env. digikam do not crash here less time with opencv but it,s not perfect. So with this multiple error prone, face management can become instable as we don’t control how opencv is compiled on target computer. Some way to progress in investigations: 1/ write one unit test to call face management with all options available in digikam This will simplify the test but as low level code is complicated, this kind of test can only confirm the bug without to isolate the source of the problem. 2/ as all classes as well isolated in face management, rewrite the thread serialization can be better. Sure the performance will decrease, but the gain over code complexity will be better to understand and to maintain. Typically, an ActionJob to parse image in a separated thread to detect faces, one other to perform identification, and one other to process database requests through a cache mechanism to not bloat with multiple queries. -- You are receiving this mail because: You are watching all bug changes.
