[KPhotoAlbum] KPhotoAlbum crashes while generating thumbnails during start

Mon Apr 29 23:22:55 BST 2013

Am 29.04.2013 17:31, schrieb Miika Turkia: 

> On Mon, Apr 29, 2013
at 2:16 PM, Manfred Usselmann <usselmann.m at icg-online.de> wrote:
> 
>>
Hi Miika, 
>> 
>> am 27.04.2013 06 [1]:24, schrieb Miika Turkia: 
>>

>>> On Wed, Apr 24, 2013 at 10:50 PM, Manfred Usselmann
<usselmann.m at icg-online.de> wrote:
>>> 
>>>> I have about 30000 images
and with an earlier version of kphotoalbum I could use the application
but 4.4 crashes every time after a while during the generation of the
preview images. Last time it happened when 26% was done.
>>> 
>>> To me
it looks like the crash occurs at raw decoding (kdcraw is a library we
use for that and seems to be the culprit). However, if that is the case
the upgrade from older version of KPA to 4.4 should not start crashing
(or actually the older version should crash the same). Of course the
trouble could also be how we use the library...
>> 
>> Indeed, I found
some files in a subfolder (none image files with misc. extensions) which
had been there for years without causing issues. After deleting those
files KPA no longer abended.
> 
> Can you send me some file that causes
a crash so I can try to see what the problem is with that/them?
Generally we should only handle image files and extra stuff under image
root should not cause problems. But as you discovered, we do still have
bugs...

It was the folder 'Image-ExifTool-5.72'. I deleted it since I
didn't use it since years. I have now restored it from backup, good
opportunity to test my backup solution. ;-) 

I will send it to you
directly. 

>> But then KPA was very slow. Especially opening the detail
window from a thumbnail did take for ever. I tried to solve this by
reextracting the exif information. Didn't help. After a while KPA did
crash again with my data file with segmentation fault. I noticed that
the demo database did work so I concluded that it must have something to
do with my index.xml. I did rebuild my index.xml which took nearly a
day.
> 
> For me KPA works faster than the previous version. However,
when you first start using 4.4 generating thumbnails will take quite a
long time. And until the thumbnails are generated it is very slow -
unusable. 
> 
>> Now KPA is running again but still unusably slow. And
all my categorizations / tags are in the old file which I can't open any
more. :-(
> 
> You should still be able to open the old index.xml (if
you did not loose it completely). KPA supports command line option -c
that takes the index file as parameter and should allow you to open it
up. However, the file name must be index.xml, differently named file is
"sanitized" to index.xml.

Yes, I still have it as index.xml.old. What
happened is that I deleted a file .DS_Store in the root directory of my
images tree. Afaik this file is created when the share is accessed by a
Mac and of no use at all. But after the removal of this file KPA startet
crashing again with segmentation fault immediately after start of the
program: 

Application: KPhotoAlbum (kphotoalbum), signal: Segmentation
fault 

Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread
0x7f7f41464800 (LWP 11962))] 

Thread 3 (Thread 0x7f7f2a5bc700 (LWP
11964)): 

#0 0x00007f7f3ce4d05e in pthread_cond_timedwait@@GLIBC_2.3.2
() from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f7f39646935 in
g_cond_wait_until () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2
0x00007f7f395dcb81 in ?? () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007f7f395dd1ca in
g_async_queue_timeout_pop () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007f7f3962b6b2 in ?? ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f7f3962aeb5 in ??
() from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6 0x00007f7f3ce48f8e in
start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#7
0x00007f7f3d157e1d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 2 (Thread 0x7f7f29dbb700 (LWP 11965)): 

#0 0x00007f7f3d14b3cd
in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f7f396071dc in
?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007f7f396076ba
in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3
0x00007f7f3180a4f6 in ?? () from
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4 0x00007f7f3962aeb5 in ?? ()
from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5 0x00007f7f3ce48f8e in
start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6
0x00007f7f3d157e1d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x7f7f41464800 (LWP 11962)): 

[KCrash Handler] 

#5
0x0000000000474da0 in ?? ()
#6 0x000000000047c4f6 in ?? ()
#7
0x000000000047ceb5 in ?? ()
#8 0x000000000046f072 in ?? ()
#9
0x00000000005102df in ?? ()
#10 0x00000000004decb0 in ?? ()
#11
0x00000000004df8b0 in ?? ()
#12 0x000000000043b0ea in ?? ()
#13
0x00007f7f3d07fea5 in __libc_start_main () from
/lib/x86_64-linux-gnu/libc.so.6
#14 0x0000000000444d71 in _start ()

This is why I renamed index.xml to index.xml.old so that KPA had to
create a new index. With this new index file it is no longer crashing.
Just extremely slow. When I rename the old file to index.xml the crash
occurs again. 
Strange... 

I still have some none image files in
subfolders (e.g. html, css from html slideshows) and also some raw files
which may be not well supported (xf3). I will try to clean this up to
see if this solves my issues. 

I do not know about the xf3 but NEF, CR2
and ORF are working fine for me. (I use the option to use embedded JPG
or half sized raw, thus I only load the embedded thumbnail that is in
higher resolution than my display.) 

then there is something wrong
somewhere. Naturally I would like to fix any bugs related to performance
and crashes, but this will require us to be able to see the problem...

Sure. All I can say is that I didn't have such issues with previous
versions of KPA with the same files... 

Links:
------
[1]
tel:27.04.2013%2006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20130430/e06b6544/attachment.htm>