Project

General

Profile

Bug #8611

image processor gets stuck after loading corrupt image

Added by xxvelcrar - over 6 years ago. Updated over 5 years ago.

Status:
Triaged
Priority:
Medium
Assignee:
-
Category:
General
Start date:
Due date:
% Done:

20%

Affected Version:
git development version
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

After loading a 0kb NEF file, the lighttable displays a gray, empty thumbnail and an annoying popup text (#8609). This causes all rendering of further images to cease and only thumbnails are shown - even when loading in the darkroom. This can be seen by trying to zoom in on a picture in the darkroom and noting a high amount of pixelation.

Steps to reproduce:

1. Load corrupt 0kb NEF image
2. double-click on other image to load in darkroom

expected result:
3. darkroom behaves as expected, displaying image and ignoring corrupt one in database.

actual result:
3. zoom in on image, noting high degree of pixelation. message "image FILENAME is not available" still shown even in darkroom, even though that image is not being loaded.

After removing the image from the database, this problem still persists and seems to peg the CPU (perhaps it's stuck in an endless loop).

darktable 0.9.3

History

#1 Updated by Simon Spannagel over 6 years ago

even though I can't understand the "expected result" (how to display a 0kb image "correctly"?) the latter issue still exists:

I can enter darkroom with a corrupted/missing image (hitting (d) when having a skull selected). This should be blocked.

#2 Updated by Simon Spannagel over 6 years ago

Henrik, what about your solution to this? Didn't you mention something in IRC?

#3 Updated by Henrik Andersson over 6 years ago

Yes this is related, actually the same case, expected
solution should be the same if image is missing from disk
and no deadlock as we have today.

#4 Updated by Simon Spannagel over 6 years ago

  • Target version changed from 1.0.3 to Candidate for next patch release

#5 Updated by Simon Spannagel over 6 years ago

  • Affected Version set to git development version
  • % Done changed from 0 to 20
  • Status changed from New to Triaged

There is still an issue with current git:
one worker thread still gets a deadlock and we have a permanent "working" message displayed.

Steps to reproduce:
1) dt: import some sane files
2) exit dt; (re)move one file and create a 0byte file of the same name
3) dt: try to enter dr with this file - we get a skull but the worker thread is still there.

#6 Updated by Simon Spannagel over 5 years ago

  • System set to all

I somehow can still reproduce this when entering dr after the removal. However, returning to lt works and the image is then tagged as non-existing.

Also available in: Atom PDF