Bug 415489

Can you share P:/Archive/Temp/DigiKam Test/IMG_19190901_820637.JPG and  P:/Archive/Temp/DigiKam Test/TheBroadways0010_1.JPG files that we can see in the debug log ?

Gilles Caulier

Created attachment 124676 [details]
Debug Log 2

I can't share those images, sorry, I should have checked before posting.

I have an image which causes the same crash (IMG_20130825_170807.JPG) but it doesn't have the same debug log entry so there may be more than one problem.

The problem image is DSC_0017_1.JPG which is too large to attach but is accessible here:
https://1drv.ms/u/s!AhmvR4JSJH8OkwwXmqk0n0yOBH7d?e=56RzXD

Can you choose something else in the sidebars for testing than the map. We may also have a crash in Marble.

This message is also strange, which does not occur under Linux:
QObject::connect: signal not found in Digikam::MaintenanceTool

Maik

This new type of signal/slot connection can probably not be processed by MinGW. It is not relevant for this crash, but maintenance tasks cannot currently be canceled in the Windows version.

connect(this, static_cast<void (ProgressItem::*)(const QString&)>
    (&ProgressItem::progressItemCanceled),
    this, &MaintenanceTool::slotCancel);

Maik

Maik, look this : https://forum.qt.io/topic/35638/issue-with-new-signal-slot-mechanism-in-mingw-qt5-2/2

MXE use G++ 5.5.0 and is compatible with C++11. We just need to force compiler to use C++11 in CMake at configuration stage.

Ok, if MinGW uses C++03 by default, then it is clear. I cannot reproduce the crash with the test image in a Windows 10 VM.

Maik

I can't reliably reproduce this problem in different Windows sessions. Restarting the PC seems to resolve the issue sometimes.

However, when the problem was present the following observations are 100% repeatable on my PC at least.

- "Slideshow" and "Open with Default Application" do NOT result in the crash. 

- "Open...", "Preview", "Scan For Faces", "OpenGL Image Viewer" and "Presentation..." all result in a crash.


Here's a list of actions I've tried to fix the issue when present:
"Refresh"
"Reread Metadata From File"
"Write Metadata to File"
"Rename"
"Assign Labels" -> "Rating"
"Rotate right"
Adjusting creation date.
Deleting the database in Windows and adding a new collection.

Created attachment 124685 [details]
AppCashView Screenshot

I looked at the Report.wer files in C:\ProgramData\Microsoft\Windows\WER\ReportArchive with AppCrashView.

Not sure if it's any use to you.

If the file exists, it would be of interest:

C:\Users\%USERNAME%\AppData\Local\digikam_crash.log

Maik

*** Bug 415521 has been marked as a duplicate of this bug. ***

(In reply to Maik Qualmann from comment #11)
> If the file exists, it would be of interest:
> 
> C:\Users\%USERNAME%\AppData\Local\digikam_crash.log
> 
> Maik

No such file unfortunately. Let me know how I can generate it and I will try.

The log should have been created automatically. There is another option with the debugger, but it is a little more difficult, let's see if you can do it.

Start the CMD.exe and execute the following commands:

cd "C:\Program Files\digiKam"
gdb digikam

(gdb) r    <=== type "r" + enter for run digikam

.... output from digikam...crash...

(gdb) bt   <=== type "bt" + enter for the backtrace

.... post this messages

(gdb) q    <=== type "q" + enter for quit

Maik

Created attachment 124700 [details]
DebugView log for digiKam-6.4.0 crash on windows 10 on switching to preview mode

I started DebugView and switched from Thumbnails to Preview mode a few times to produce this file.

Created attachment 124701 [details]
gdb digiKam log for digiKam-6.4.0 crash on windows 10 on switching to preview mode

This log was extracted using below steps:
cd "C:\Program Files\digiKam"
gdb digikam

(gdb) r    <=== type "r" + enter for run digikam

.... output from digikam...crash...

(gdb) bt   <=== type "bt" + enter for the backtrace

.... post this messages

(gdb) q    <=== type "q" + enter for quit

We have this error message:
--------
Qt Concurrent has caught an exception thrown from a worker thread.	
This is not supported, exceptions thrown in worker threads must be	
caught before control returns to Qt Concurrent.
--------

I checked where it is created in Qt. We should probably compile Qt with QT_NO_EXCEPTIONS, which is probably the standard. But we may have an exception that we no longer catch. This exception only occurs on some Windows installations. I will test a workaround for Windows here.

Maik

Git commit 7fffd49c5fc9080e96af2f0bf9ce642c6c5e349a by Maik Qualmann.
Committed on 25/12/2019 at 12:11.
Pushed by mqualmann into branch 'master'.

try to fix crash on preview image

M  +14   -6    core/libs/dimg/loaders/dimgloader.h

https://invent.kde.org/kde/digikam/commit/7fffd49c5fc9080e96af2f0bf9ce642c6c5e349a

A new test version of digiKam-7.0.0-Beta1 is available. Can the crash still be reproduced?

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

Maik

(In reply to Maik Qualmann from comment #14)
> The log should have been created automatically. There is another option with
> the debugger, but it is a little more difficult, let's see if you can do it.
> 
> Start the CMD.exe and execute the following commands:
> 
> cd "C:\Program Files\digiKam"
> gdb digikam
> 
> (gdb) r    <=== type "r" + enter for run digikam
> 
> .... output from digikam...crash...
> 
> (gdb) bt   <=== type "bt" + enter for the backtrace
> 
> .... post this messages
> 
> (gdb) q    <=== type "q" + enter for quit
> 
> Maik

Same output as ajay1976:

#0  0x66cd8dd0 in Z11qt_assert_xPKcS0_S0_i () from C:\Program Files (x86)\digiKam\Qt5Core.dll
#1  0x00000000 in ?? ()

Can you please deactivate color management in digiKam Setup and test again?

Maik

(In reply to Maik Qualmann from comment #21)
> Can you please deactivate color management in digiKam Setup and test again?
> 
> Maik

With "Enable Colour Management" set to off, it makes no difference.

Also, I disabled all plugins and this makes no difference either.

Just one side observation. The following line insists that digikam_crash.log is output:
 
"warning: digikam.general: DrMinGw crash-file will be located at:  "C:\\Users\\USERNAME\\AppData\\Local\\digikam_crash.log""

This file is never made on my system, or if it is created, it must get deleted again soon after.

(In reply to Maik Qualmann from comment #19)
> A new test version of digiKam-7.0.0-Beta1 is available. Can the crash still
> be reproduced?
> 
> https://files.kde.org/digikam/
> 
> Maik

The version digiKam-7.0.0-beta1-20191227T084042-Win64 does not crash as far as I tested it.

The car ash log must be present. I already experienced some conflicts with anti-virus stuff. Are you a virus guard enabled and n your system ?

Another Q: did you use the 32 bits or the 64 bits version on est our system ? If your windows is 64 bits, use DK 64 bits too.

I have Win 10 64 bit.

When the invitation went out to test 7.0.0 Beta 1, I looked at the list of packages and saw only 32 bit:

    digiKam-7.0.0-beta1-Win32.exe

But now I look harder and I see the 64 bit version:

    digiKam-7.0.0-beta1-20191221T072646-Win64.exe

I think it I missed it because these versions are not next to each other in the list due to differing filename convention. At the time I assumed you hadn't got around to the 64 bit version and figured it wouldn't matter anyway but I guess not! So that's why I installed 32 bit DK on my 64 bit Win 10.

It looks like it is the trigger for this problem because I installed digiKam-7.0.0-beta1-20191221T072646-Win64.exe (i.e. before QT_NO_EXCEPTIONS) and the problem is gone. My apologies for wasting your time.

I tested digiKam-7.0.0-Beta1 32-bit on Windows 10. It still crashed after some time. I could capture DebugView log. But while trying to capture digikam debug log my digikam hanged and I had to kill it. I have attached DebugView log.

Created attachment 124771 [details]
DebugView log for digiKam-6.4.0 crash on windows 10 while in Preview mode after fix

You tested a digiKam 32 on a Windows 10 32 bits or 64 bits ?

(In reply to caulier.gilles from comment #30)
> You tested a digiKam 32 on a Windows 10 32 bits or 64 bits ?

I tested on Windows 10 32 bit.