| Summary: | digikam hangs on startup "reading database" | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Christof Schulze <christof.schulze> |
| Component: | Database-Scan | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | ||
| Priority: | NOR | ||
| Version: | 0.9.5 | ||
| Target Milestone: | --- | ||
| Platform: | FreeBSD Ports | ||
| OS: | FreeBSD | ||
| Latest Commit: | Version Fixed In: | 1.0.0 | |
| Sentry Crash Report: | |||
Problem exist too with digiKam 0.10.0 ? Gilles Caulier Aren't there any debugging infos in the console? For me this strace output isn't very useful, can you take a look if some error messages appear in the console? Andi at the time I cannot test with digikam 0.10 as it does not compile for FreeBSD due to a Makefile shakeup. This is already known to the FreeBSD team I will report back when this issue is resolved. The debug info in the console, are not helpful as they do not contain an error message. Anyways this is what I see: % digikam digikam: Removing Album: /bilder jule/2009_01_30 digikam: ScanLib: Finding non-existent Albums: 6138 ms digikam: ScanLib: Finding items not in database: 13479 ms digikam: ScanLib: Updating items without a date: 20 ms digikam: Removing: blatt0021.jpeg in 373 digikam: Removing: blatt0022.jpeg in 373 digikam: Removing: mandy-konflikt.jpeg in 373 digikam: KDirWatch method = FAM This is the output of top while digikam is running: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1380 erika 1 70 0 166M 43776K CPU1 1 1:30 29.98% kded4 1167 root 1 47 0 363M 314M select 0 0:13 0.98% Xorg 1605 erika 1 4 0 133M 50072K sbwait 1 0:12 0.00% digikam Maybe the state is useful here. Such high usage of kded4 isn't normal. And it points somewhere in kdelibs as source of problem IMO. Was is so high before digiKam was started? it is always that high. On the other hand, the cpu is also clocked down to 300 Mhz so cpu usage may look high here. Running digikam with ktrace works most of the time. Lois is right (his message went to mailing list): ------------------------------------- I had also that issue on 64 bits Mandriva 2008.1 (and also previous mandrivas). I solved it by removing the KDirWatch addDir calls. Of course, directory changes are not seen now by digiKam, but at least, the (great) application starts. The problem seems to be a communication one between the fam/gamin lib and server but I didn't get further. I do a diff at home and send the 'patch' (not really a patch, as it removes something). I had also that issue on 64 bits Mandriva 2008.1 (and also previous mandrivas). I solved it by removing the KDirWatch addDir calls. Of course, directory changes are not seen now by digiKam, but at least, the (great) application starts. The problem seems to be a communication one between the fam/gamin lib and server but I didn't get further. I do a diff at home and send the 'patch' (not really a patch, as it removes something). ------------------------------------- I would not advocate messing with sources, just turn off fam/gam in system settings (depends on your distro). In fact I remember that with KDE3 there were problems with FAM and I disabled it completely by removing guilty package. I finally got digikam 0.10 installed and it does not show this kind of behavior for me. Christof, So, this fiel can be closed ? Gilles Caulier It works for me but I kept it open so that Mikolaj can put his patch here. People still using 0.9 might be able to benefit from it. It was Lois Brarda patch, not mine and and I never got it. But, as I wrote above, this is issue rather on distro level because KDirWatch is usually good service. I would vote for closing this bug, if anyone want to attach patch to this report OK but not include this in proper digiKam sources. |
Version: 0.9.5 (using KDE 3.5.10) OS: FreeBSD Installed from: FreeBSD Ports This does not happen any time but most of the time: When starting digikam, it hangs after having printed "reading database" in the splash screen. strace revealed: gettimeofday({0, 0}, NULL) = 0 write(15, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 58) = 58 select(16, [], NULL, NULL, {0, 0}) = 0 (Timeout) gettimeofday({0, 0}, NULL) = 0 gettimeofday({0, 0}, NULL) = 0 stat("/home/erika/Bilder/2007/070806 Sommerkurs/Marie", {st_mode=056, st_size=14073972177043504, ...}) = 0 select(16, [4 5], NULL, NULL, {3670067, 6946862}) = 1 (in [4 5 6]) read(15, "\20\0\1\0Y\0\10\0\6\00009.jpg\27\0\1\0Y\0\10\0\r\00052_inde"..., 1034) = 1034 select(16, [3 4 5 6 9 10 11 13], NULL, NULL, {1535085, 5832705}) = 1 (in [3]) read(15, "\27\0\1\0Y\0\10\0\r\00032_index.html\27\0\1\0Y\0\10\0\r\0"..., 1034) = 1034 select(16, [1 4 5 12 13], NULL, NULL, {2019910766, 1836345390}) = 1 (in [2 3 5 6 8 9 10 12]) read(15, "html\27\0\1\0Y\0\10\0\r\00045_index.html\27\0\1\0Y\0"..., 1015) = 302 select(16, [11], NULL, NULL, {1869098752, 1697604973}) = 0 (Timeout) gettimeofday({1634429298, 1818837551}, NULL) = 0 write(15, "der/2003/skitour/Marielder/2003/s"..., 57) = 57 select(16, [0 1 3 5 6 8 11 13 14], NULL, NULL, {1294955125, 1701409377}) = 0 (Timeout) gettimeofday({1919247468, 808464943}, NULL) = 0 gettimeofday({1802710835, 1970238569}, NULL) = 0 stat("/home/erika/Bilder/2007/070806 Sommerkurs/Martin", {st_mode=0, st_size=0, ...}) = 0 select(16, [], NULL, NULL, {0, 0}) = 0 (Timeout) gettimeofday({0, 0}, NULL) = 0 write(15, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 58) = 58 select(16, [], NULL, NULL, {0, 0}) = 0 (Timeout) gettimeofday({0, 0}, NULL) = 0 gettimeofday({0, 0}, NULL) = 0 stat("/home/erika/Bilder/2007/070806 Sommerkurs/Robert", {st_mode=0, st_size=0, ...}) = 0 select(16, [], NULL, NULL, {0, 0}) = 0 (Timeout) gettimeofday({0, 0}, NULL) = 0 write(15, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 58) = 58 select(16, [], NULL, NULL, {0, 0}) = 0 (Timeout) gettimeofday({0, 0}, NULL) = 0 gettimeofday({0, 0}, NULL) = 0 stat("/home/erika/Bilder/2007/070806 Sommerkurs/Sandra1", {st_mode=0, st_size=0, ...}) = 0 select(16, [], NULL, NULL, {0, 0}) = 0 (Timeout) gettimeofday({0, 0}, NULL) = 0 write(15, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 59 it hangs there forever. I had this happen on FreeBSD and Linux Systems. I will gladly provide more information, please let me know what is needed.