Bug 500570 - face recognition crash
Summary: face recognition crash
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Faces-Recognition (show other bugs)
Version: 8.6.0
Platform: Microsoft Windows Microsoft Windows
: NOR crash
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-02-22 11:09 UTC by Andy
Modified: 2025-03-06 04:29 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 8.6.0
Sentry Crash Report:


Attachments
logfile (329.73 KB, text/plain)
2025-02-22 11:09 UTC, Andy
Details
Windows-Systeminfo (1.75 KB, text/plain)
2025-02-22 11:49 UTC, Andy
Details
digikam-Componentsinfo (22.89 KB, text/plain)
2025-02-22 11:50 UTC, Andy
Details
mySQL (17.08 KB, image/png)
2025-02-22 17:31 UTC, Andy
Details
Medien (18.96 KB, image/png)
2025-02-22 17:32 UTC, Andy
Details
my.cnf (1.38 KB, text/plain)
2025-02-23 10:04 UTC, Andy
Details
debug1 (56.82 KB, image/png)
2025-02-24 14:46 UTC, Andy
Details
debug (79.56 KB, text/plain)
2025-02-24 20:54 UTC, Andy
Details
Debug in VM with SQlite (83.62 KB, text/plain)
2025-02-25 11:29 UTC, Andy
Details
Screenshot1 (192.08 KB, image/jpeg)
2025-02-25 18:17 UTC, Andy
Details
Log1 (81.64 KB, text/plain)
2025-02-25 18:58 UTC, Andy
Details
Memory Error (21.92 KB, image/jpeg)
2025-02-26 21:04 UTC, Andy
Details
Debug 20250226 (88.58 KB, text/plain)
2025-02-26 21:04 UTC, Andy
Details
Ausgabe 20250301 (91.17 KB, text/plain)
2025-03-01 15:16 UTC, Andy
Details
Ausgabe 20250301_173200 (197.46 KB, text/plain)
2025-03-01 16:37 UTC, Andy
Details
digikam_Log (119.60 KB, text/plain)
2025-03-01 16:37 UTC, Andy
Details
Ausgabe 20250302_091300 (1.06 MB, text/plain)
2025-03-02 08:20 UTC, Andy
Details
Ausgabe 20250302_152500 (716.29 KB, text/plain)
2025-03-02 14:28 UTC, Andy
Details
Ausgabe 20250302_154700 (678.52 KB, text/plain)
2025-03-02 14:51 UTC, Andy
Details
Ausgabe 20250303_194100 (922.54 KB, text/plain)
2025-03-03 18:46 UTC, Andy
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andy 2025-02-22 11:09:51 UTC
Created attachment 178725 [details]
logfile

Hi!

During face recognition, digikam always crashes without an error message. It always crashes at about 4% of the run. It doesn't matter whether one or all processor cores are running.
I have created a log.
When the program crashes, digikam always forgets the last settings in the face recognition at the bottom left.

Cheers
Andy
Comment 1 caulier.gilles 2025-02-22 11:34:34 UTC
The lost of last settings can be normal as the data is not yet flushed on the disk when crash happen.

One core or multicore is not the only settings to check. The new face management code used GPU through OpenCV API to speed up the computation. This settings is located in DK/Setup/Miscs/System :

https://docs.digikam.org/en/setup_application/miscs_settings.html#system-settings

Look at the OpenCL option.

Q: which video card did you use? NVidia, AMD, Intel, other ? Which CPU ? Intel, Arm, other ?

Best

Gilles Caulier
Comment 2 caulier.gilles 2025-02-22 11:35:52 UTC
Also, go to Help/Components Info dialog and CC the contents here.
Comment 3 Andy 2025-02-22 11:49:34 UTC
Created attachment 178726 [details]
Windows-Systeminfo
Comment 4 Andy 2025-02-22 11:50:25 UTC
Created attachment 178727 [details]
digikam-Componentsinfo

attached the information

Tested with and without OpenCL hardware acceleration. Otherwise everything is standard.
Comment 5 Andy 2025-02-22 11:56:29 UTC
I deactivated the delayed metadata synchronization again. After the program crashed and restarted, the queue was empty.
Comment 6 Michael Miller 2025-02-22 12:49:03 UTC
Hi Andy,
I'm sorry your're having trouble.  Are you using the latest Windows image?  I fixed a bug a few weeks ago that caused Windows to crash.  Please make sure you're using the latest build.

If digiKam keeps crashing at the same point every time, it makes me wonder if there is a bad image that we're not handling properly.

Can we try a few things?  First, turn off "Work on all processor cores".  Then run another scan, but expand the progress bar at the bottom.  Since it's crashing at 4%, I'm hoping you want have to watch it for very long.  Try to see what album digiKam is scanning when it crashes.

Now, do another scan exactly the same way, and see if it crashes while scanning the same album.  If it crashes in the same album, then there is a good chance there is a bad image in it.

To verify if it is a bad image, use the "Search-in" tab to exclude the album and scan again.  Does it crash at 4% again, or does it go further?  Please keep track of which album digiKam is scanning.

Please let me know the results.  Meanwhile, I'll try to reproduce the issue on my system.

Cheers,
Mike
Comment 7 Andy 2025-02-22 13:14:41 UTC
Hello Mike,
Windows 10 is up to date.
On the second PC (AMD Phenom II X6) the facial recognition has been running without any problems. On the AMD Ryzen it crashed at 2%.
The thumbnails are stored on C:\digikam\. Could there be something wrong there?

Cheers
Andy
Comment 8 Michael Miller 2025-02-22 13:39:18 UTC
(In reply to Andy from comment #7)
> Hello Mike,
> Windows 10 is up to date.
> On the second PC (AMD Phenom II X6) the facial recognition has been running
> without any problems. On the AMD Ryzen it crashed at 2%.
> The thumbnails are stored on C:\digikam\. Could there be something wrong
> there?
> 
> Cheers
> Andy

Hi Andy,
By "Windows 10 is up to date", do you mean the Windows OS has all the latest patches, or you're running the latest 8.6.0 build of digiKam, or both are up to date?

Are the 2 PCs you're running both using the same image library? Are they using the same image files?

Cheers,
Mike
Comment 9 caulier.gilles 2025-02-22 16:17:15 UTC
>The thumbnails are stored on C:\digikam\. Could there be something wrong there?

Place sounds fine for me...

Best 

Gilles Caulier
Comment 10 caulier.gilles 2025-02-22 16:17:47 UTC
Do you have an Antivirus working in background ?

Gilles Caulier
Comment 11 Andy 2025-02-22 17:31:50 UTC
Created attachment 178739 [details]
mySQL

Hello,

ESET NOD32 is installed on both PCs.

In the picture you can see the database settings. Both computers are set up like this. Each PC has a folder with the thumbnails.

Both PCs use the media from the NAS

digikam version 8.6.0 from 02/21/2025 6:02 p.m. is installed on both PCs.

Could there be problems if the database on "C:\digikam-Thumbs" is defective? Are the thumbnails used for face recognition?

Cheers
Andy
Comment 12 Andy 2025-02-22 17:32:23 UTC
Created attachment 178740 [details]
Medien
Comment 13 Michael Miller 2025-02-22 18:15:15 UTC
> Are the thumbnails used for face recognition?

Hi Andy,
Yes, the thumbnails are used for facial recognition.  The system uses the thumbnail to extract the dimensions of the **Unknown** face.  Known (confirmed) face thumbnails are not used because the face dimensions have already been extracted and saved.

The face engine uses the internal thumbnail service.  I'll do some tests to see how the thumbnail service handles a request when the thumbnail DB is missing, or if the DB doesn't have a thumbnail for the face.

Cheers,
Mike
Comment 14 Andy 2025-02-22 18:41:20 UTC
Hello Mike,
it could be that the image database has errors. My system has had a lot of BSODs in the last few days. I updated the BIOS and all drivers. Since then, the system has been running stably again. Many images and videos were also defective. Fortunately only on the local system and not on the Synology. The day before yesterday, the photos were still being used from drive I:\. After that, I set the Synology paths.

Cheers
Andy
Comment 15 Michael Miller 2025-02-22 20:16:35 UTC
(In reply to Andy from comment #14)
> Hello Mike,
> it could be that the image database has errors. My system has had a lot of
> BSODs in the last few days. I updated the BIOS and all drivers. Since then,
> the system has been running stably again. Many images and videos were also
> defective. Fortunately only on the local system and not on the Synology. The
> day before yesterday, the photos were still being used from drive I:\. After
> that, I set the Synology paths.
> 
> Cheers
> Andy

Hi Andy,
You raise a good point.  

Do the Ryzen and Phenom computers use the same database, like a remote MySQL, or SQLite on the NAS drive (not recommended)? If they use the same DB, and one can scan the collection and the other can't then it's probably not a corrupted DB.

If not, here's another test that would help us identify the problem.  Create new digiKam DBs and try scanning again.  If the error doesn't occur again, then it's most probably a corrupted DB.  If you're using SQLite, the process is easy.  Find the folder with the digiKam DB files (they will be named digikam4.db, recognition.db, similarity.db, and thumbnails-digikam.db).  Rename all of the files from .db to .db.old so we save the data.  Then start digiKam.  Upon startup, digikam will complain it can't find the db files.  Click New Database to create new DB files.  Then add the folders and rescan your collection.

If the error disappears with a fresh DB, then the problem is most likely a corrupted DB.

Cheers,
Mike
Comment 16 Andy 2025-02-22 22:24:35 UTC
Hi!

I have installed a mySQL database in Docker on the Synology. It is a bit slower. But I have not yet found any other way to work with multiple PCs with the same data set.
I have renamed the local thumbnails-digikam.db to *.old. "Recognize faces only" is currently running. The database is getting bigger and after 1.5 hours it has reached 34%. I will continue testing tomorrow and will get back to you.

Cheers
Andy
Comment 17 Andy 2025-02-23 10:04:50 UTC
Created attachment 178764 [details]
my.cnf
Comment 18 Andy 2025-02-23 10:05:14 UTC
The first run overnight was successful. The local thumbnails-digikam.db was rebuilt.
The program now exits again without an error message. With one processor core and with all of them.
The face settings are always changed after a crash.
Could there be a timeout because the PC is very new and perhaps too fast? During face recognition, a short break is taken every now and then, perhaps to write to the main database. If it takes too long, the program crashes.
Enclosed is the content of the my.cnf in Docker

Cheers
Comment 19 Michael Miller 2025-02-23 12:29:30 UTC
Hi Andy,
(In reply to Andy from comment #18)
> The first run overnight was successful. The local thumbnails-digikam.db was
> rebuilt.
That's good news.  This points to an issue with the thumbnail db, but not completely certain yet.

> The program now exits again without an error message. With one processor
> core and with all of them.
> The face settings are always changed after a crash.
Settings are saved to the digikam.rc file when digiKam is closed normally.  When there is a crash the settings aren't saved.  This is expected.

> Could there be a timeout because the PC is very new and perhaps too fast?
> During face recognition, a short break is taken every now and then, perhaps
> to write to the main database. If it takes too long, the program crashes.
This is an interesting hypothesis. How fast is the docker server that's hosting MySQL? I'll have the check with Gilles and Maik to see if this is likely.  There is code in the face pipeline to slow things down if any stage gets behind processing the work.  This is to avoid consuming too much memory and causing a crash.

Cheers,
Mike
Comment 20 Andy 2025-02-23 12:50:52 UTC
It is interesting that all the settings in the bottom left are changed after the crash. I would have thought that after the crash only new settings are not saved and the old settings remain.

My Synology is a DS918+
Intel Celeron J3455, 1.5 GHz, 4 cores
8GB RAM
4 hard drives with SHR btrfs
2 SSDs as SSD cache

I move the thumbnails from the local SSD to the Synology. Then everything is equally slow. ;-)   And check it out.

Andy
Comment 21 Andy 2025-02-23 21:15:14 UTC
Hi!
Unfortunately, resetting the Thumbs database from AMD Ryzen to mySQL didn't help. The first run went through without any problems. The second run stopped again after 2% and closed the program.
I have no idea now.

Andy
Comment 22 caulier.gilles 2025-02-23 21:27:58 UTC
Hi Andy,

The next stage can be a little bit complicated to achieve: capture a debugger backtrace.

The log trace that you provides come from DebugView program. It do not indicate at all any code line where the crash appears in the program.

So you need to install the digiKam window 8.6.0 pre-release including debug symbols (the installer with "-debug" sentence in filename):

https://files.kde.org/digikam/

Later follow instructions given here :

https://www.digikam.org/contribute/#windows-host-1  

Best

Gilles Caulier
Comment 23 Andy 2025-02-23 22:24:07 UTC
Hi
I can't get any further today.

Where can I find "Debug/Attach to Process menu entry" in Visual Studio?

Can you please send me a screenshot?

Cheers
Andy
Comment 25 Andy 2025-02-24 08:55:35 UTC
Hi!

I'm in Visual Studio 22. But I can't find it
"In Visual Studio, select Debug > Attach to Process (or press Ctrl+Alt+P) to open the Attach to Process dialog box".

Do extensions need to be installed? This question came up during installation. But which ones should I have installed?

Cheers
Andy
Comment 26 caulier.gilles 2025-02-24 09:03:57 UTC
Hi Andy,

No idea, as i mostly develop and hack under Linux. 

Look at the Microsoft tutorial here :

https://code.visualstudio.com/Docs/editor/debugging

Best regards

Gilles Caulier
Comment 27 Michael Miller 2025-02-24 13:19:33 UTC
(In reply to Andy from comment #25)
> Hi!
> 
> I'm in Visual Studio 22. But I can't find it
> "In Visual Studio, select Debug > Attach to Process (or press Ctrl+Alt+P) to
> open the Attach to Process dialog box".
> 
> Do extensions need to be installed? This question came up during
> installation. But which ones should I have installed?
> 
> Cheers
> Andy

Hi Andy,
Yes, there are additional things that need installed in Visual Studio 2022.  Go to "Tools->Get Tools and Features" in the top menu bar.  A pop-up windows should appear. In the first tab, which should be "Workloads", make sure "c++ core desktop features" is installed.  If it's installed, you will see it in the right sidebar.  If it's not installed, then you will see a section for it on the left. 

You'll want to install some optional c++ features, too.  At a minimum, you want "Just-In-Time debugger" installed.

When you start Visual Studio, you may see the Visual Studio startup screen asking you to create or open a project.  Click "Continue without code" at the bottom of the "Get Started" column on the right.

After these features are installed and Visual Studio has been restarted, you should see "Debug" in the main menu bar.  Start digiKam, but don't start a face scan yet.  Once digiKam is running and you see the digiKam main window, select "Debug->Attach to Process" from the main menu.  Select the digikam process and click "Attach" in the lower right of the window.

You can now do the face scan, and Visual Studio should give you debug information when it encounters the error.

Cheers,
Mike
Comment 28 Andy 2025-02-24 14:46:02 UTC
Created attachment 178811 [details]
debug1

is it OK like this?
Comment 29 Maik Qualmann 2025-02-24 15:07:54 UTC
Hi Andy,

we need all the text in the debug window, especially the upper part.

Maik
Comment 30 Michael Miller 2025-02-24 15:44:05 UTC
(In reply to Andy from comment #28)
> Created attachment 178811 [details]
> debug1
> 
> is it OK like this?

Hi Andy,
As Maik said, we need all the text.  The easiest way to do this is to click into the debug window in the lower right. Then do ctrl-a for select all, then ctrl-c for copy.  Open Notepad and paste the contents there.  Save the text file, and send that to us.

Thank you for your help.  We appreciate it.

Cheers,
Mike
Comment 31 Andy 2025-02-24 20:54:52 UTC
Created attachment 178839 [details]
debug

Hello Mike and Maik,

I actually just wanted to show that I seem to have got it working ;-) Tried it out in a VM during my working hours.

I've attached the recording up until the crash. I hope you can make something out of it.

Cheers
Andy
Comment 32 Michael Miller 2025-02-24 22:00:02 UTC
(In reply to Andy from comment #31)
> Created attachment 178839 [details]
> debug
> 
> Hello Mike and Maik,
> 
> I actually just wanted to show that I seem to have got it working ;-) Tried
> it out in a VM during my working hours.
> 
> I've attached the recording up until the crash. I hope you can make
> something out of it.
> 
> Cheers
> Andy

Hi Andy,
My German is very rusty.  It's been a few decades since I had to speak it regularly, but it doesn't look like you're running the debug version of digiKam.  Can you please download and run the debug version, please, and send us the logs from that?

https://files.kde.org/digikam/digiKam-8.6.0-20250224T180204-Qt6-Win64-debug.exe

Cheers,
Mike
Comment 33 Maik Qualmann 2025-02-25 06:59:16 UTC
@ Michael, the last line is interesting and indicates that a Q_ASSERT was called, so not a "real" crash. Of course, this could also be in Qt, that we are accessing an empty QList or something similar.

Maik
Comment 34 caulier.gilles 2025-02-25 07:07:27 UTC
Hi all,

This is whats i suspect too...
A QList item access is probably the origin of the Qt exception. A QList must be always checked if empty before to use. It's a rules imposed by Qt.

Andy, please use the 8.6.0 pre-release Windows installer with "-debug" in file name. When crash appears, we will able to identify the exact line in digiKam source code where the exception comes...

Best

Gilles Caulier
Comment 35 caulier.gilles 2025-02-25 07:10:10 UTC
Hi Michael,

QList::isEmpty() is not the only condition. The index in the list to get a value must be in included in the size of the container:

https://doc.qt.io/qt-6/qlist.html#operator-5b-5d

Best

Gilles
Comment 36 Andy 2025-02-25 07:14:02 UTC
(In reply to caulier.gilles from comment #34)
> Andy, bitte verwenden Sie das Windows-Installationsprogramm 8.6.0 vorab mit
> „-debug“ im Dateinamen. Wenn ein Absturz auftritt, können wir die genaue
> Zeile im digiKam-Quellcode identifizieren, in der die Ausnahme auftritt ...
> 
> Am besten
> 
> Gilles Caulier

OK   "-debug"
I was just about to ask that. But I can't test it until this evening.

Cheers
Andy
Comment 37 Andy 2025-02-25 11:29:06 UTC
Created attachment 178858 [details]
Debug in VM with SQlite

Hi!

"C:\Program Files\digiKam\digikam.exe" -debug
does not work

"C:\Program Files\digiKam\digikam.exe" debug
Program starts, but I can't see if debug is running. I'm running Visual Studio though.

Here is the current part that is running in my test VM. Despite the errors, the face recognition continues to work.

Andy
Comment 38 Maik Qualmann 2025-02-25 11:38:43 UTC
Hi Andy,

we're getting closer to the matter. But this doesn't seem to be the output from the window in the bottom right corner?

Maik
Comment 39 Michael Miller 2025-02-25 11:41:19 UTC
(In reply to Andy from comment #37)
> Created attachment 178858 [details]
> Debug in VM with SQlite
> 
> Hi!
> 
> "C:\Program Files\digiKam\digikam.exe" -debug
> does not work
> 
> "C:\Program Files\digiKam\digikam.exe" debug
> Program starts, but I can't see if debug is running. I'm running Visual
> Studio though.
> 
> Here is the current part that is running in my test VM. Despite the errors,
> the face recognition continues to work.
> 
> Andy

(In reply to Andy from comment #37)
> Created attachment 178858 [details]
> Debug in VM with SQlite
> 
> Hi!
> 
> "C:\Program Files\digiKam\digikam.exe" -debug
> does not work
> 
> "C:\Program Files\digiKam\digikam.exe" debug
> Program starts, but I can't see if debug is running. I'm running Visual
> Studio though.
> 
> Here is the current part that is running in my test VM. Despite the errors,
> the face recognition continues to work.
> 
> Andy

Hi Andy,
You need to download and install a new version of digiKam.  On the download page, you'll see a version of digiKam with "-debug" at the end of the name.  This is the file to download and install. The debug version of digiKam includes more information to help Maik, Gilles, and I see what the problem is.  It's a whole new installer, and not just a command line parameter to the existing program.  

Click this link to download the debug version:
https://files.kde.org/digikam/digiKam-8.6.0-20250225T100206-Qt6-Win64-debug.exe

Once it's downloaded, you can install it normally like the non-debug version.

Cheers,
Mike
Comment 40 Maik Qualmann 2025-02-25 11:41:49 UTC
The debug version of digiKam is required. Start digiKam, select "attach to process" in the Debug menu in Visual C++. A window opens with the currently running processes, select digikam.exe.

Maik
Comment 41 Andy 2025-02-25 11:44:38 UTC
I'll try again

On February 24, 2025, I downloaded and installed digiKam-8.6.0-20250224T060216-Qt6-Win64-debug.
Comment 42 Andy 2025-02-25 12:00:13 UTC
digiKam-8.6.0-20250225T100206-Qt6-Win64-debug.exe is now installed

"C:\Program Files\digiKam\digikam.exe" -debug
does not work    
Window with:    "digikam: unknown options: d, e, b, u, g."

I still don't know what I'm doing wrong
Comment 43 caulier.gilles 2025-02-25 12:01:55 UTC
Andy,

When i said  to install digiKam version with the "-debug" in file path, i want mean to re-install digiKam with the installer including debug symbols, not to run the digiKam binary with the -debug option.

Typically install this version :

https://files.kde.org/digikam/digiKam-8.6.0-20250225T100206-Qt6-Win64-debug.exe.mirrorlist

The file is : "digiKam-8.6.0-20250225T100206-Qt6-Win64-debug.exe"

Note the "-debug" in the file-name...

Best

Gilles Caulier
Comment 44 Andy 2025-02-25 12:27:56 UTC
OK. digikam.exe only starts without the addition of -debug. I misunderstood that. The correct program is installed.
I'll run the face recognition this evening and send you the debug output from Visual Studio from the window at the bottom right.
I hope it's good enough for you to understand if I translate my German text into English using Google.
Comment 45 caulier.gilles 2025-02-25 12:32:37 UTC
yes, your English is fine here (:=))))
Comment 46 caulier.gilles 2025-02-25 12:51:00 UTC
>"C:\Program Files\digiKam\digikam.exe" -debug
>does not work   
>Window with:    "digikam: unknown options: d, e, b, u, g."

Nope. Start digiKam as usual without any extra option.

Installing a program with debug symbols as you doing want mean that binary program are more heavy and includes the "debug symbols" in the executable. 

You run it and when it crash, the debugger will be able to trace where the dysfunction appears in the source code.

Best

Gilles Caulier
Comment 47 Andy 2025-02-25 18:17:38 UTC
Created attachment 178881 [details]
Screenshot1

Hey guys,

what do I have to do now? A new window...
Comment 48 Maik Qualmann 2025-02-25 18:48:01 UTC
Hi Anfy,

You can close the window and the debugger will load the source code.
But we need the beginning of this output, can you please scroll up?

Maik
Comment 49 Andy 2025-02-25 18:58:16 UTC
Created attachment 178882 [details]
Log1

I hope I'm doing everything right.
Comment 50 Maik Qualmann 2025-02-25 19:14:39 UTC
@Andy, thanks that helps.

@Michael, it crashes on "delete package;". Before that we have a signal/slot connection without specifying the connection. That means that if Qt detects it between different threads, Qt::QueuedConnection is used. This is executed when the event loop is free again, which means that "package" is still used if it has already been deleted. We need something like deleteLater() here if package is a QObject.

Maik
Comment 51 Michael Miller 2025-02-25 20:00:44 UTC
(In reply to Maik Qualmann from comment #50)
> @Andy, thanks that helps.
> 
> @Michael, it crashes on "delete package;". Before that we have a signal/slot
> connection without specifying the connection. That means that if Qt detects
> it between different threads, Qt::QueuedConnection is used. This is executed
> when the event loop is free again, which means that "package" is still used
> if it has already been deleted. We need something like deleteLater() here if
> package is a QObject.
> 
> Maik

Maik, I don't understand why it's crashing.  The package isn't used after the delete.  The only think I can think of is the QStrings passed to notify are passed as const &, so maybe the internal QString reference count isn't getting updated?  Can you look at mlpipelinefoundation.cpp starting at line 607, and mlpipelinepackagenotify.cpp MLPipelinePackageNotify constructors starting at line 21 to see if I'm doing something wrong with the ::Ptr shared data?

Cheers,
Mike
Comment 52 Maik Qualmann 2025-02-26 07:43:45 UTC
Git commit 83fedb614ab0f2897eafa681c65fb6077e786dd7 by Maik Qualmann.
Committed on 26/02/2025 at 07:42.
Pushed by mqualmann into branch 'master'.

make sure QFutureWatcher has finished

M  +3    -1    core/libs/mlfoundation/mlpipelinefoundation.cpp

https://invent.kde.org/graphics/digikam/-/commit/83fedb614ab0f2897eafa681c65fb6077e786dd7
Comment 53 Maik Qualmann 2025-02-26 17:42:27 UTC
Hi Andy,

the change is small and probably won't help. Can you still test the current Windows build, thanks in advance.

Maik
Comment 54 Andy 2025-02-26 21:04:13 UTC
Created attachment 178923 [details]
Memory Error

Hello Maik,

During the first run there was a memory error. (without debug version)
An error was recorded with the debug version.

Cheers
Andy
Comment 55 Andy 2025-02-26 21:04:40 UTC
Created attachment 178924 [details]
Debug 20250226
Comment 56 Andy 2025-02-27 16:07:23 UTC
Hi!
Can you tell me if the problem is perhaps with the Ryzen PC? Because there are no problems with the old Phenom.

Cheers
Andy
Comment 57 Michael Miller 2025-02-27 16:14:24 UTC
(In reply to Andy from comment #56)
> Hi!
> Can you tell me if the problem is perhaps with the Ryzen PC? Because there
> are no problems with the old Phenom.
> 
> Cheers
> Andy

Hi Andy,
It really shound't matter.  Ryzen, Phenom, Intel Core, Apple M chip should all be the same.  I'm trying to determine if maybe there is what's called a "race condition", and because of the extra power and speed things are happening out of the expected order.  I'm adding some extra error-catching logic and some extra debugging messages now.  The changes should be in the build tomorrow or Saturday.  Then we'll have you download the new version and turn on some additional debugging messages.

We like to work with the theory that if it's happening to one person, then it will probably happen to other people, too.  We use this assumption until we can prove it's something specific to one person's computer.

Cheers,
Mike
Comment 58 Michael Miller 2025-02-27 19:45:03 UTC
Hi Andy,
I want to confirm the error happens when  "Work on processor cores" is checked, and when it is unchecked.  is that correct?

Cheers,
Mike
Comment 59 Andy 2025-02-27 20:40:41 UTC
I started the face recognition with one core and with all cores. The program was always in the foreground.
I also deactivated all cores except one with msconfig. So only 1 core instead of 16 cores.
digikam always crashed.

Andy
Comment 60 Michael Miller 2025-02-27 20:51:10 UTC
Git commit 6c411d939ffbc7323f426a08a82547da21cb7d6b by Michael Miller.
Committed on 27/02/2025 at 20:50.
Pushed by michmill into branch 'master'.

Additional debugging info for Andy

M  +11   -3    core/libs/mlfoundation/mlpipelinefoundation.cpp
M  +1    -0    core/libs/mlfoundation/mlpipelinefoundation.h
M  +30   -3    core/utilities/facemanagement/pipelines/facepipelinebase.cpp
M  +5    -1    core/utilities/facemanagement/pipelines/recognize/facepipelinerecognize.cpp

https://invent.kde.org/graphics/digikam/-/commit/6c411d939ffbc7323f426a08a82547da21cb7d6b
Comment 61 Michael Miller 2025-03-01 13:10:35 UTC
Hi Andy,
There is a new build of digiKam available that has additional logging information.  Can you please download this file?

https://files.kde.org/digikam/digiKam-8.6.0-20250301T100224-Qt6-Win64-debug.exe

After you download and install it, we need to turn on the additional debugging information.  Remember these steps because you'll want to undo do this when were're done fixing this issue.

Click on the Windows Start menu and type "System Properties" (without the quotes). You should see something in the list like "View advanced system settings" (sorry, I don't know what the German translation will be). Click on "View advanced system settings".  You should see a new window.  In the bottom right of the new window there is a button "Environment Variables".  Click on "Environment Variables". An additional window should appear. In the top of the window should be a section for user variables, and the bottom should be system variables.

Click "New" in the user variable section. In the "Variable name" type:

QT_LOGGING_RULES

in the Variable value section type:

digikam*=true

Click "Ok" to add the variable, then click "Ok" again to save it to the Environment variables.

Now you can launch digiKam and Visual Studio like you did before.  Make sure "Use all processor cores" is unchecked in digiKam.  Run the face scan and send us the output like you did before.

Thank you again for your patience and help.  We really appreciate it.

Cheers,
Mike
Comment 62 Andy 2025-03-01 15:16:44 UTC
Created attachment 179005 [details]
Ausgabe 20250301

Hello,

Face recognition ran twice without any problems.
The third time it crashed. Here is the output.

Cheers
Andy
Comment 63 Maik Qualmann 2025-03-01 15:34:34 UTC
Michael has to look at it, what I notice is that the image is loaded and processed twice before it crashes.

Maik
Comment 64 Michael Miller 2025-03-01 15:43:09 UTC
Hi Andy,
Thank you!  This is very helpful.

A few more questions for you.  

Do you have multiple copies of a file called 20080511_110601.jpg in your library?  Maybe they are in different folders?

Can you please run digiKam again the same way?  Before you do a face scan, please go to Settings->Configure digiKam->Miscellaneous->System and make sure "Enable internal debug logging" is checked.

@Maik, 
The duplicate was the first thing I saw, too.  I saw a few other duplicates like 20080316_150003.JPG and 20080118_091633.JPG, but it didn't crash on those. I'll check the SharedQueue code to make sure there's not a race condition there.  The crash would make sense if I'm deleting the package twice.  If this is the problem, it's odd that it has taken this long to present itself.  Maybe Andy just has the special one computer that this happens on.

Cheers,
Mike
Comment 65 Michael Miller 2025-03-01 16:32:18 UTC
Maik,
Ugh!  The duplicate image names is a false-positive.  Andy is doing a recorgnize-only scan, so this is expected if the image has more than one face.  What's important to see is the face ID, and not the image name.  On my system, the face IDs are all unique.

Andy, can you confirm that image 20080511_110601.jpg has at least 2 face regions found on it?

Cheers,
Mike
Comment 66 Andy 2025-03-01 16:37:19 UTC
Created attachment 179011 [details]
Ausgabe 20250301_173200

Hello Mike,

yes, 3 faces were found and already named.
Each picture only appears once in the collection.
Attached are new logs


Andy
Comment 67 Andy 2025-03-01 16:37:35 UTC
Created attachment 179012 [details]
digikam_Log
Comment 68 Michael Miller 2025-03-01 17:19:34 UTC
(In reply to Andy from comment #66)
> Created attachment 179011 [details]
> Ausgabe 20250301_173200
> 
> Hello Mike,
> 
> yes, 3 faces were found and already named.
> Each picture only appears once in the collection.
> Attached are new logs
> 
> 
> Andy

Hi Andy,
Are all the faces in 20090223_120113.JPG and 20080511_110601.jpg confirmed and named? Any any faces in those images Unknown or Unconfrmed?

Cheers,
Mike
Comment 69 Andy 2025-03-01 18:08:25 UTC
Hello Mike,

20090223_120113.JPG 2 faces unknown, no others recognized or named.

20080511_110601.jpg 3 faces named, about 15 unknown.

Cheers 
Andy
Comment 70 Michael Miller 2025-03-01 18:09:58 UTC
(In reply to Andy from comment #69)
> Hello Mike,
> 
> 20090223_120113.JPG 2 faces unknown, no others recognized or named.
> 
> 20080511_110601.jpg 3 faces named, about 15 unknown.
> 
> Cheers 
> Andy

Thank you, Andy.  This helps.

I'm still going over the code to see why this is happening.

Cheers,
Mike
Comment 71 Andy 2025-03-01 18:49:52 UTC
Hi Mike,
could it be due to one of the values ​​in my.cnf?
I have to admit that I don't know what they mean. I gathered them from the internet, except for the last line from your documentation.

[mysqld]
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2
innodb_file_per_table = 1
innodb_read_io_threads = 4
innodb_write_io_threads = 4
query_cache_type = 1
query_cache_size = 128M
max_allowed_packet = 128M

Cheers
Andy
Comment 72 Michael Miller 2025-03-01 20:14:34 UTC
Git commit a2022dc3254597152c7618d86947d162ff4f7f9b by Michael Miller.
Committed on 01/03/2025 at 20:14.
Pushed by michmill into branch 'master'.

clear the pipleline package before deleting

M  +3    -0    core/utilities/facemanagement/pipelines/facepipelinepackagebase.cpp
M  +22   -4    core/utilities/facemanagement/pipelines/recognize/facepipelinerecognize.cpp

https://invent.kde.org/graphics/digikam/-/commit/a2022dc3254597152c7618d86947d162ff4f7f9b
Comment 73 Michael Miller 2025-03-01 20:24:24 UTC
Hi Andy,
I don't think your MySql configuration is causing the issue.  I don't know what is, but I'm pretty sure that's not it.

Can you try rebuilding your face database?  Go to Tools->Maintenance->Detect and recognize faces->Rebuild all training data?

Cheers,
Mike
Comment 74 Michael Miller 2025-03-01 21:11:45 UTC
Hi Andy,
There is a new Windows build with some additional debug information and a few changes.  Can you please download and install the Windows-debug build from here?

https://files.kde.org/digikam/

After you install it, it is the same process as before.  Please make sure the QT_LOGGING_RULES environment variable is still set, and Settings->Configure digiKam->Miscellaneous->System->Enable internal debug logging is still checked.

Cheers,
Mike
Comment 75 Andy 2025-03-02 08:20:34 UTC
Created attachment 179032 [details]
Ausgabe 20250302_091300

Good morning,

I just saw that my last message from yesterday evening isn't here.

I rebuilt the face data under maintenance (Rebuild all training data). The first few percent were very slow. Then suddenly it was 100% and done.

Here is the new output

Cheers
Andy
Comment 76 Michael Miller 2025-03-02 12:23:09 UTC
(In reply to Andy from comment #75)
> Created attachment 179032 [details]
> Ausgabe 20250302_091300
> 
> Good morning,
> 
> I just saw that my last message from yesterday evening isn't here.
> 
> I rebuilt the face data under maintenance (Rebuild all training data). The
> first few percent were very slow. Then suddenly it was 100% and done.
> 
> Here is the new output
> 
> Cheers
> Andy

Hi Andy,
Thank you for this.  Again, this is very helpful.

Can you please check to make sure "Work on all processor cores" is unchecked? There's a line in the output that makes me think maybe it is turned on, but I'm not sure. It's strange.

Also, can you please run 2 more tests, and send us the output?  I want to check if the same strange output shows up in 2 more tests.

I really think we should give you a credit in the next version of digiKam.  Maybe "Quality Test Engineer: Andy". :) Thank you for all your help.

Cheers,
Mike
Comment 77 caulier.gilles 2025-03-02 13:30:39 UTC
I agree to credit Andy as Quality checker here :

https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/widgets/mainview/daboutdata.cpp?ref_type=heads#L122

Andi, thanks for your patience and help...

Gilles Caulier
Comment 78 Andy 2025-03-02 14:28:27 UTC
Created attachment 179040 [details]
Ausgabe 20250302_152500

Hello,
As a quality checker in the credits? So much honor? Thank you very much!
But then please use my real name "André Molkentin"

I made sure that the checkbox is not active for processor cores.

I'm attaching the output. First with the creation of the face database, where it suddenly jumps to 100% and then below that the face recognition with the error.

I'll do a second run right away.

I'm happy to help you!

Cheers
Andy
Comment 79 Andy 2025-03-02 14:51:21 UTC
Created attachment 179041 [details]
Ausgabe 20250302_154700

Hi!

Here the second output

Cheers
Andy
Comment 80 Bug Janitor Service 2025-03-02 18:58:55 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/digikam/-/merge_requests/349
Comment 81 Michael Miller 2025-03-02 19:01:13 UTC
(In reply to Andy from comment #79)
> Created attachment 179041 [details]
> Ausgabe 20250302_154700
> 
> Hi!
> 
> Here the second output
> 
> Cheers
> Andy

Hi Andy,
I think we're getting closer.  I've narrowed it down to just a few things.  I've added some code to help us eliminate at least one possibility.  I'll let you know when we have a new build for you.

Cheers,
Mike
Comment 82 Michael Miller 2025-03-02 19:09:25 UTC
Git commit c0ebbd7d142370d81d10fbc3b9a46e94c92b9468 by Michael Miller.
Committed on 02/03/2025 at 19:09.
Pushed by michmill into branch 'master'.

additional logging info for 500570

M  +5    -5    core/libs/facesengine/detection/opencv-dnn/dnnfacedetectoryunet.cpp
M  +4    -0    core/libs/mlfoundation/mlpipelinefoundation.cpp
M  +5    -29   core/libs/mlfoundation/mlpipelinemacros.h
M  +10   -0    core/libs/tags/autoassignment/pipelines/object/autotagspipelineobject.cpp
M  +23   -8    core/utilities/facemanagement/pipelines/detectrecognize/facepipelinedetectrecognize.cpp
M  +2    -0    core/utilities/facemanagement/pipelines/edit/facepipelineedit.cpp
M  +9    -2    core/utilities/facemanagement/pipelines/facepipelinebase.cpp
M  +24   -7    core/utilities/facemanagement/pipelines/facepipelinepackagebase.cpp
M  +9    -4    core/utilities/facemanagement/pipelines/facepipelinepackagebase.h
M  +10   -3    core/utilities/facemanagement/pipelines/recognize/facepipelinerecognize.cpp
M  +2    -0    core/utilities/facemanagement/pipelines/reset/facepipelinereset.cpp
M  +2    -0    core/utilities/facemanagement/pipelines/retrain/facepipelineretrain.cpp
M  +1    -1    project/bundles/homebrew/config.sh

https://invent.kde.org/graphics/digikam/-/commit/c0ebbd7d142370d81d10fbc3b9a46e94c92b9468
Comment 83 Michael Miller 2025-03-03 11:18:47 UTC
Hi Andy,
There is a new build of digiKam.  Can you please download the debug version and run the same tests?

Cheers,
Mike
Comment 84 Andy 2025-03-03 18:46:32 UTC
Created attachment 179076 [details]
Ausgabe 20250303_194100

Hello,

here is the new output

Andy
Comment 85 Michael Miller 2025-03-03 21:17:56 UTC
(In reply to Andy from comment #84)
> Created attachment 179076 [details]
> Ausgabe 20250303_194100
> 
> Hello,
> 
> here is the new output
> 
> Andy

Hi Andy,
Thank you again!

On your Ryzen PC, did you load and additional OpenCV or GPU acceleration drivers?  The latest dump confirmed my suspicion that something in OpenCV is corrupting memory.  This is typically due to some misconfiguration of OpenCV.  Either an incorrect version of OpenCV, or an extension used by OpenCV (CUDA, for example) that's fully configured correctly is the usual cause.

Gilles and Maik,
The stack trace isn't showing line details for DNNSFaceExtractor::getFaceEmbedding.  Is it possible that not all digiKam code is being built with debug symbols?  It would be useful to know which line in DNNSFaceExtractor::getFaceEmbedding is throwing the error.

Cheers,
Mike
Comment 86 Andy 2025-03-03 22:45:43 UTC
Hello Mike,

I have no idea at the moment which installed software could still have OpenCV. Maybe benchmark programs like AIDA64 or PC Mark 10? I uninstalled them. The Nvidia driver was completely reinstalled. Unfortunately, it didn't help.

Andy
Comment 87 caulier.gilles 2025-03-04 06:37:43 UTC
>The stack trace isn't showing line details for
>DNNSFaceExtractor::getFaceEmbedding.  Is it possible that not all digiKam code
>is being built with debug symbols?  It would be useful to know which line in
>DNNSFaceExtractor::getFaceEmbedding is throwing the error.

Hi Michael,

The debug Windows installer come with all debug symbols in digikamcore, digikamdatabase, and digikamgui dlls. All other object do not have debug symbols to prevent huge size of the installer limited to 2Gb (32 bits NSIS problem not yet solved).

Don't forget that when a exception happen, the debuger backtrace can be broken, corrupted, lost, especially at race condition issues in multithreading context.

Also if the problem come from OpenCV and al, there is no debug symbols in the bundle.

Best
Gilles
Comment 88 Michael Miller 2025-03-04 19:25:34 UTC
(In reply to Andy from comment #84)
> Created attachment 179076 [details]
> Ausgabe 20250303_194100
> 
> Hello,
> 
> here is the new output
> 
> Andy

Hi Andy,
I looked at the log again, and I found something very interesting.  Right before the crash, the pipeline package with serial number 1178 was processed twice.  This shouldn't happen.  It should be impossible, but it happened.  I updated some code, so look for a new Windows build in a day or two.

Thanks for all your help.  With any luck the most recent change fixes the problem.

Cheers,
Mike
Comment 89 Andy 2025-03-04 20:04:51 UTC
Hi Mike,

here is the end of the run just now. The serial number 4230 is loaded twice, processed once, and deleted once. Then processed again and deleted, but without a file name.
I think this is the situation you mean.
I'm looking forward to the next version.

Cheers
Andy

digikam.facesengine: FacePipelineBase::commonFaceThumbnailExtractor: Features extracted for "20150321_142406.jpg"  with serial number  4228
digikam.facesengine: FacePipelineRecognize::classifier: Classifying  "20150321_142406.jpg"  with serial number  4228
digikam.facesengine: FaceClassifier::predictClassifier: classifier stage 3 prediction is:  -1  completed in  0
digikam.facesengine: FacePipelineRecognize::classifier: Predicted label  -1  for  "20150321_142406.jpg"
digikam.facesengine: FacePipelinePackageBase::~FacePipelinePackageBase: Deleting package with serial number 4228
digikam.facesengine: FacePipelineBase::commonFaceThumbnailLoader: Thumbnail loaded for "20150321_142408.jpg"  with serial number  4230
digikam.facesengine: FacePipelineBase::commonFaceThumbnailLoader: Thumbnail loaded for "20150321_142408.jpg"  with serial number  4230
digikam.facesengine: No face landmarks found
digikam.facesengine: Finish computing face embedding in  1  ms
digikam.facesengine: FacePipelineBase::commonFaceThumbnailExtractor: Features extracted for "20150321_142408.jpg"  with serial number  4230
digikam.facesengine: FacePipelineRecognize::classifier: Classifying  "20150321_142408.jpg"  with serial number  4230
digikam.facesengine: FacePipelinePackageBase::~FacePipelinePackageBase: Deleting package with serial number 4230
digikam.facesengine: No face landmarks found
digikam.facesengine: Finish computing face embedding in  1  ms
digikam.facesengine: FacePipelineBase::commonFaceThumbnailExtractor: Features extracted for ""  with serial number  4230
digikam.facesengine: FacePipelineRecognize::classifier: Classifying  ""  with serial number  4230
digikam.facesengine: FacePipelinePackageBase::~FacePipelinePackageBase: Deleting package with serial number 4230
Critical error detected c0000374
Eine Breakpointanweisung (__debugbreak()-Anweisung oder ein ähnlicher Aufruf) wurde in digikam.exe ausgeführt.
Comment 90 Michael Miller 2025-03-04 21:04:57 UTC
(In reply to Andy from comment #89)
> Hi Mike,
> 
> here is the end of the run just now. The serial number 4230 is loaded twice,
> processed once, and deleted once. Then processed again and deleted, but
> without a file name.
> I think this is the situation you mean.
> I'm looking forward to the next version.
> 
> Cheers
> Andy

Hi Andy,
Yes, exactly.  This should be impossible when "Work on processor cores" is unchecked.  Unless I made a mistake, it should be impossible with it checked, too.  I rewrote the code that controls this today, so maybe that will help.

Cheers,
Mike
Comment 91 Michael Miller 2025-03-05 11:27:17 UTC
Hi Andy,
There is a new Windows build on the download site.  Can you please download and test the -debug build.  Same process as before.  I think this might fix it.

Cheers,
Mike
Comment 92 Andy 2025-03-05 20:56:06 UTC
Hi Mike,

I've been testing all evening. There are no more problems. Great work!

Thank you very much!
Andy
Comment 93 Michael Miller 2025-03-05 20:58:29 UTC
(In reply to Andy from comment #92)
> Hi Mike,
> 
> I've been testing all evening. There are no more problems. Great work!
> 
> Thank you very much!
> Andy

YES!  Thank you so much for all of your help and patience.

Cheers,
Mike
Comment 94 caulier.gilles 2025-03-06 04:29:11 UTC
Git commit e3ec4b284379cf08a0a9e327c99841fb72856802 by Gilles Caulier.
Committed on 06/03/2025 at 04:28.
Pushed by cgilles into branch 'master'.

give credits to André Molkentin

M  +9    -2    core/libs/widgets/mainview/daboutdata.cpp

https://invent.kde.org/graphics/digikam/-/commit/e3ec4b284379cf08a0a9e327c99841fb72856802