https://bugs.kde.org/show_bug.cgi?id=426175
--- Comment #34 from Marcel <maes...@gmail.com> --- (In reply to caulier.gilles from comment #28) > Hi Marcel, > > The problem is not directly in dnnfacedetectorssd. Look well the back-trace. > All continue in low level inside... OpenCV API. The memory problem is at > this place. > > This is what we suspect since a while: the big puzzle named OpenCV as too > many way to optimize computation / process/ data management, using hardware, > as GPU. > > I'm in contact with team from KDenlive project (video montage application) > which use also OpenCV in background with the same problem. > > The solution is to disable optimizations at OpenCV compilation. I do it for > all bundles, but it's not possible for native digiKam version where we don't > have control of OpenCV configuration. > > So the ultimate solution is to find a real solution in digiKam code to > prevent this memory leak. The problem is to find the context where this > dysfunction appear, and it's certainly sue to compilation option in OpenCV, > as, i never reproduce this memory leak on all Linux version installed in my > computer since many year. This want mean that OpenCV here is compiled > without a specific optimization. The Q is which one? > > If you look in OpenCV CMake top level options, you will see a very huge list > of possibility. It's completely crazy... > > This is what's i use for the bundles : > > https://invent.kde.org/graphics/digikam/-/blob/master/project/bundles/ > 3rdparty/ext_opencv/CMakeLists.txt#L11 > > Another possibility, is a problem with a specific kernel option or a GPU > driver bug, used indirectly by OpenCV. Here again, the complexity to found > the reasons is similar to the distance which separate the sun and the earth. > > Gilles Gilles, you are right about the memory leak in openCV. For me it's the first time reading a valgrind output and I want to understand it. From my understanding there are more problems then just the one in openCV. Whats about the one QRect::operator& or QRect::isValid() or qRound(double) or Digikam::DNNFaceDetectorBase::correctBbox. I guess in most examples it's just because of an uninitialized variable, but shouldn't that be fixed anyway. Can't this lead to undefined behavior in same strange cases?(In reply to caulier.gilles from comment #28) > Hi Marcel, > > The problem is not directly in dnnfacedetectorssd. Look well the back-trace. > All continue in low level inside... OpenCV API. The memory problem is at > this place. > > This is what we suspect since a while: the big puzzle named OpenCV as too > many way to optimize computation / process/ data management, using hardware, > as GPU. > > I'm in contact with team from KDenlive project (video montage application) > which use also OpenCV in background with the same problem. > > The solution is to disable optimizations at OpenCV compilation. I do it for > all bundles, but it's not possible for native digiKam version where we don't > have control of OpenCV configuration. > > So the ultimate solution is to find a real solution in digiKam code to > prevent this memory leak. The problem is to find the context where this > dysfunction appear, and it's certainly sue to compilation option in OpenCV, > as, i never reproduce this memory leak on all Linux version installed in my > computer since many year. This want mean that OpenCV here is compiled > without a specific optimization. The Q is which one? > > If you look in OpenCV CMake top level options, you will see a very huge list > of possibility. It's completely crazy... > > This is what's i use for the bundles : > > https://invent.kde.org/graphics/digikam/-/blob/master/project/bundles/ > 3rdparty/ext_opencv/CMakeLists.txt#L11 > > Another possibility, is a problem with a specific kernel option or a GPU > driver bug, used indirectly by OpenCV. Here again, the complexity to found > the reasons is similar to the distance which separate the sun and the earth. > > Gilles Gilles, you are right about the memory leak in openCV. For me it's the first time reading a valgrind output and I want to understand it. From my understanding there are more problems then just the one in openCV. Whats about the one QRect::operator& or QRect::isValid() or qRound(double) or Digikam::DNNFaceDetectorBase::correctBbox. I guess in most examples it's just because of an uninitialized variable, but shouldn't that be fixed anyway. Can't this lead to undefined behavior in same strange cases? -- You are receiving this mail because: You are watching all bug changes.
