stalled while loading

[Tim Rupp]

Hi list,

I'm trying to track down a problem I've been seeing on my current
installation of digikam. I'm using the 0.9.0-beta1-r1 version, but saw
it in 0.8.1-2 also.

When I launch digikam, it will get past the "Initializing Main View" and
just stall at "Reading Database"

I can let it sit there all day and it'll never get past it. I end up
ctrl+c'ing the app and running it again.

This may happen 15 - 20 times in a row before it finally gets past the
"Reading Database" message.

There's an initial CPU spike, and then the cpu usage falls to zero. No
disk activity seen either (using dstat to check)

There are other times where the software will come right up in under 3
tries.

Anyone have any ideas how I can go about seeing what is stalling? I'm
open to recompiling anything.

Running FC4 on a 3GHz desktop with 1 gig of ram, but I've seen the same
long pause on a FC6 desktop (with a slower, 733Mhz) cpu

Thanks,
Tim
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

> Hi list,
>
> I'm trying to track down a problem I've been seeing on my current
> installation of digikam. I'm using the 0.9.0-beta1-r1 version, but saw
> it in 0.8.1-2 also.
>
> When I launch digikam, it will get past the "Initializing Main View" and
> just stall at "Reading Database"
>
> I can let it sit there all day and it'll never get past it. I end up
> ctrl+c'ing the app and running it again.
>
> This may happen 15 - 20 times in a row before it finally gets past the
> "Reading Database" message.
>
> There's an initial CPU spike, and then the cpu usage falls to zero. No
> disk activity seen either (using dstat to check)
>
> There are other times where the software will come right up in under 3
> tries.
>
> Anyone have any ideas how I can go about seeing what is stalling? I'm
> open to recompiling anything.

When the app has stalled, you have plenty of time ;-)
Find out with the "ps" tool the PID of the process.
Then attach gdb to it: "gdb att <PID>"
With "bt" you can get a backtrace of the main thread, with "thr appl all bt"
of all current threads, but there should only be one at that time.

Marcel

>
> Running FC4 on a 3GHz desktop with 1 gig of ram, but I've seen the same
> long pause on a FC6 desktop (with a slower, 733Mhz) cpu
>
> Thanks,
> Tim
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Tim Rupp]

Marcel Wiesweg wrote:

>> Hi list,
>>
>> I'm trying to track down a problem I've been seeing on my current
>> installation of digikam. I'm using the 0.9.0-beta1-r1 version, but saw
>> it in 0.8.1-2 also.
>>
>> When I launch digikam, it will get past the "Initializing Main View" and
>> just stall at "Reading Database"
>>
>> I can let it sit there all day and it'll never get past it. I end up
>> ctrl+c'ing the app and running it again.
>>
>> This may happen 15 - 20 times in a row before it finally gets past the
>> "Reading Database" message.
>>
>> There's an initial CPU spike, and then the cpu usage falls to zero. No
>> disk activity seen either (using dstat to check)
>>
>> There are other times where the software will come right up in under 3
>> tries.
>>
>> Anyone have any ideas how I can go about seeing what is stalling? I'm
>> open to recompiling anything.
>
> When the app has stalled, you have plenty of time ;-)
> Find out with the "ps" tool the PID of the process.
> Then attach gdb to it: "gdb att <PID>"
> With "bt" you can get a backtrace of the main thread, with "thr appl all bt"
> of all current threads, but there should only be one at that time.
>
> Marcel
>
>> Running FC4 on a 3GHz desktop with 1 gig of ram, but I've seen the same
>> long pause on a FC6 desktop (with a slower, 733Mhz) cpu
>>
>> Thanks,
>> Tim
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

Hi Marcel, thanks for that suggestion.

When the app hangs, this is what gdb returns. Is this any more useful?
Do you have any suggestions on where to go from this point or where to
find more debugging info?


(gdb) thr appl all bt

Thread 1 (Thread -1208367424 (LWP 628)):
#0  0x001be402 in ?? ()
#1  0x0042a173 in __write_nocancel () from /lib/libpthread.so.0
#2  0x0077f6b5 in ?? () from /usr/lib/libfam.so.0
#3  0x0077f884 in ?? () from /usr/lib/libfam.so.0
#4  0x0077ffc6 in FAMMonitorDirectory () from /usr/lib/libfam.so.0
#5  0x4f03610e in KDirWatchPrivate::useFAM () from /usr/lib/libkio.so.4
#6  0x4f036a6b in KDirWatchPrivate::addEntry () from /usr/lib/libkio.so.4
#7  0x4f036f63 in KDirWatch::addDir () from /usr/lib/libkio.so.4
#8  0x00d9407c in Digikam::AlbumManager::scanPAlbums (this=0x96a5b78) at
albummanager.cpp:433
#9  0x00d94b26 in Digikam::AlbumManager::refresh (this=0x96a5b78) at
albummanager.cpp:327
#10 0x00d94d66 in Digikam::AlbumManager::startScan (this=0x96a5b78) at
albummanager.cpp:320
#11 0x00db41ae in DigikamApp (this=0x96b39f0) at digikamapp.cpp:166
#12 0x0804a4c7 in main (argc=1, argv=0xbfb32294) at main.cpp:244


when it finally does come together and work, this is the gdb bt for the
process.


#0  0x001be402 in ?? ()
#1  0x0029fe7d in ___newselect_nocancel () from /lib/libc.so.6
#2  0x4e1a09a8 in QEventLoop::processEvents () from
/usr/lib/qt-3.3/lib/libqt-mt.so.3
#3  0x4e20edcb in QEventLoop::enterLoop () from
/usr/lib/qt-3.3/lib/libqt-mt.so.3
#4  0x4e20ecd6 in QEventLoop::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3
#5  0x4e1f6119 in QApplication::exec () from
/usr/lib/qt-3.3/lib/libqt-mt.so.3
#6  0x0804a44d in main ()


Ideas?

Thanks,
-Tim
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

> Hi Marcel, thanks for that suggestion.
>
> When the app hangs, this is what gdb returns. Is this any more useful?
> Do you have any suggestions on where to go from this point or where to
> find more debugging info?

Yes, this gives important information: It hangs while installing the directory
watch. For each album directory, digikam creates a KDirWatch (so it happens
while the albums are read from database).

That's the point (#8->#7) where digikams code is left. #7-#5 is kdelibs, #4-#2
is libfam, which together with a daemon provides one way to monitor
directories. All this is completely opaque to digikam.

So the problem can be in
- kdelibs
- libfam
- famd
- kernel

Any "unusual" directories in your album hierarchy? Does it also happen with
other directories?

Marcel

>
>
> (gdb) thr appl all bt
>
> Thread 1 (Thread -1208367424 (LWP 628)):
> #0  0x001be402 in ?? ()
> #1  0x0042a173 in __write_nocancel () from /lib/libpthread.so.0
> #2  0x0077f6b5 in ?? () from /usr/lib/libfam.so.0
> #3  0x0077f884 in ?? () from /usr/lib/libfam.so.0
> #4  0x0077ffc6 in FAMMonitorDirectory () from /usr/lib/libfam.so.0
> #5  0x4f03610e in KDirWatchPrivate::useFAM () from /usr/lib/libkio.so.4
> #6  0x4f036a6b in KDirWatchPrivate::addEntry () from /usr/lib/libkio.so.4
> #7  0x4f036f63 in KDirWatch::addDir () from /usr/lib/libkio.so.4
> #8  0x00d9407c in Digikam::AlbumManager::scanPAlbums (this=0x96a5b78) at
> albummanager.cpp:433
> #9  0x00d94b26 in Digikam::AlbumManager::refresh (this=0x96a5b78) at
> albummanager.cpp:327
> #10 0x00d94d66 in Digikam::AlbumManager::startScan (this=0x96a5b78) at
> albummanager.cpp:320
> #11 0x00db41ae in DigikamApp (this=0x96b39f0) at digikamapp.cpp:166
> #12 0x0804a4c7 in main (argc=1, argv=0xbfb32294) at main.cpp:244
>
>
> when it finally does come together and work, this is the gdb bt for the
> process.
>
>
> #0  0x001be402 in ?? ()
> #1  0x0029fe7d in ___newselect_nocancel () from /lib/libc.so.6
> #2  0x4e1a09a8 in QEventLoop::processEvents () from
> /usr/lib/qt-3.3/lib/libqt-mt.so.3
> #3  0x4e20edcb in QEventLoop::enterLoop () from
> /usr/lib/qt-3.3/lib/libqt-mt.so.3
> #4  0x4e20ecd6 in QEventLoop::exec () from
> /usr/lib/qt-3.3/lib/libqt-mt.so.3 #5  0x4e1f6119 in QApplication::exec ()
> from
> /usr/lib/qt-3.3/lib/libqt-mt.so.3
> #6  0x0804a44d in main ()

That's how it is supposed to be.

>
>
> Ideas?
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Tim Rupp]

Marcel Wiesweg wrote:

>> Hi Marcel, thanks for that suggestion.
>>
>> When the app hangs, this is what gdb returns. Is this any more useful?
>> Do you have any suggestions on where to go from this point or where to
>> find more debugging info?
>
> Yes, this gives important information: It hangs while installing the directory
> watch. For each album directory, digikam creates a KDirWatch (so it happens
> while the albums are read from database).
>
> That's the point (#8->#7) where digikams code is left. #7-#5 is kdelibs, #4-#2
> is libfam, which together with a daemon provides one way to monitor
> directories. All this is completely opaque to digikam.
>
> So the problem can be in
> - kdelibs
> - libfam
> - famd
> - kernel
>
> Any "unusual" directories in your album hierarchy? Does it also happen with
> other directories?
>
> Marcel
>
>>
>> (gdb) thr appl all bt
>>
>> Thread 1 (Thread -1208367424 (LWP 628)):
>> #0  0x001be402 in ?? ()
>> #1  0x0042a173 in __write_nocancel () from /lib/libpthread.so.0
>> #2  0x0077f6b5 in ?? () from /usr/lib/libfam.so.0
>> #3  0x0077f884 in ?? () from /usr/lib/libfam.so.0
>> #4  0x0077ffc6 in FAMMonitorDirectory () from /usr/lib/libfam.so.0
>> #5  0x4f03610e in KDirWatchPrivate::useFAM () from /usr/lib/libkio.so.4
>> #6  0x4f036a6b in KDirWatchPrivate::addEntry () from /usr/lib/libkio.so.4
>> #7  0x4f036f63 in KDirWatch::addDir () from /usr/lib/libkio.so.4
>> #8  0x00d9407c in Digikam::AlbumManager::scanPAlbums (this=0x96a5b78) at
>> albummanager.cpp:433
>> #9  0x00d94b26 in Digikam::AlbumManager::refresh (this=0x96a5b78) at
>> albummanager.cpp:327
>> #10 0x00d94d66 in Digikam::AlbumManager::startScan (this=0x96a5b78) at
>> albummanager.cpp:320
>> #11 0x00db41ae in DigikamApp (this=0x96b39f0) at digikamapp.cpp:166
>> #12 0x0804a4c7 in main (argc=1, argv=0xbfb32294) at main.cpp:244
>>
>>
>> when it finally does come together and work, this is the gdb bt for the
>> process.
>>
>>
>> #0  0x001be402 in ?? ()
>> #1  0x0029fe7d in ___newselect_nocancel () from /lib/libc.so.6
>> #2  0x4e1a09a8 in QEventLoop::processEvents () from
>> /usr/lib/qt-3.3/lib/libqt-mt.so.3
>> #3  0x4e20edcb in QEventLoop::enterLoop () from
>> /usr/lib/qt-3.3/lib/libqt-mt.so.3
>> #4  0x4e20ecd6 in QEventLoop::exec () from
>> /usr/lib/qt-3.3/lib/libqt-mt.so.3 #5  0x4e1f6119 in QApplication::exec ()
>> from
>> /usr/lib/qt-3.3/lib/libqt-mt.so.3
>> #6  0x0804a44d in main ()
>
> That's how it is supposed to be.
>
>>
>> Ideas?
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

hmmm, well, while I go off and find potentially offending albums, what
kind of unusual-ness should I look for?

I guess I use the whole range of special characters in album names

.~!{}[]-_+ etc. whatever kde will let me put in there.

Here's the weirdest part of the whole thing. I can run 'digikam' and the
application will freeze. I attach strace to the pid and it says this

write(12, "5\0\1\0\276\1\2\0+\0/home/tim/Pictures/ran"..., 53

however, if I run 'strace digikam' the app opens up fine and will tick
along without any problems.

I think something is hosed on my system because why would strace make
the application run fine? Is it maybe an smp issue? It's a P4 with
hyperthreading turned on, and it is using an smp kernel.

I'm out of ideas. Thanks for all the help you've provided though Marcel.

-Tim
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users