| Summary: | Digikam crashes on startup | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Jan Gosmann <jan> |
| Component: | Portability-Runtime | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | bkn, caulier.gilles, dani |
| Priority: | NOR | ||
| Version: | 2.5.0 | ||
| Target Milestone: | --- | ||
| Platform: | MacPorts | ||
| OS: | macOS | ||
| Latest Commit: | Version Fixed In: | 6.0.0 | |
| Sentry Crash Report: | |||
|
Description
Jan Gosmann
2012-01-26 21:39:25 UTC
DBUS for KDE is not initialized on your system : D-Bus call failed: "The name org.kde.kded was not provided by any .service files" Why ??? no idea. Wrong install, missing packages ? Gilles Caulier Oh, I missed that line. So I started kded manually and that line disappeared. However, the problem still persists and the output seems to be the same (except that one line). If you run another KDE program as Kate editor, you can also reproduce it ? Gilles Caulier I do not have Kate installed, but KMyMoney and Showfoto for example are working. I recommend to install kate and try again... Just to see... Gilles Caulier Kate is also working. There is no reason to see digKam not working at startup. Since dbus must work on your computer now, the backtrace from the console still the same ? Gilles Caulier This is the new backtrace which seems to be pretty much the same: digikam(3685)/KSharedDataCache ensureFileAllocated: This system misses support for posix_fallocate() -- ensure this partition has room for at least 10547296 bytes. digikam(3685)/KSharedDataCache: Unable to find an appropriate lock to guard the shared cache. This *should* be essentially impossible. :( digikam(3685)/KSharedDataCache: Unable to perform initial setup, this system probably does not really support process-shared pthreads or semaphores, even though it claims otherwise. digikam(3685)/KSharedDataCache: Unable to unmap shared memory segment 0x117a8b000 2012-02-01 20:37:41.864 digikam[3685:7803] Can't open input server /Library/InputManagers/MultiClutchInputManager.bundle QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in use, all queries will cease to work. digikam(3685)/KSharedDataCache ensureFileAllocated: This system misses support for posix_fallocate() -- ensure this partition has room for at least 10547296 bytes. digikam(3685)/KSharedDataCache: Unable to find an appropriate lock to guard the shared cache. This *should* be essentially impossible. :( digikam(3685)/KSharedDataCache: Unable to perform initial setup, this system probably does not really support process-shared pthreads or semaphores, even though it claims otherwise. digikam(3685)/KSharedDataCache: Unable to unmap shared memory segment 0x11b98c000 QKqueueFileSystemWatcherEngine::addPaths: open: Too many open files QFileSystemWatcher: failed to add paths: [some path] [lots of repititions for the previous two lines (as it seems at least once for every directory)] digikam(3685)/digikam (core) Digikam::ImageInfoJob::slotResult: Failed to list url: "" digikam(3685)/digikam (core) Digikam::ImageInfoJob::slotResult: Failed to list url: "" QEventDispatcherUNIXPrivate(): Unable to create thread pipe: Too many open files QEventDispatcherUNIXPrivate(): Can not continue without a thread pipe Abort trap: 6 I get the same console output and crash on my system (OSX 10.7.2) To those that see this bug, does this happen if there are no images in your library? I.e. can you try moving your library out of the way and start digikam with an empty library. I run digikam on OS X 10.6.x and as far as i can tell, digikam needs the patch in https://bugs.kde.org/show_bug.cgi?id=289330 to run properly (unless you have less than about 220 pictures). It hasn't run out-of-the-box on OS X 10.6.x since digikam-2.3.0. I can start Digikam without a library. Then it is likely related (or the exact same) the bug i mentioned above. Depending on your familiarity with macports you can try to patch it, but download the latest patch from the bug report i mentioned above (its a very simple patch), then, (NOTE: i did not expand BUILDPATH in step 2 since it is very long) $ port configure digikam $ cd /opt/local/var/macports/build/BUILDPATH/digikam/work/digikam-2.5.0/core $ patch -p1 < PATHTO/0001-disable-filewatching-on-OS-X-but-dir-watching-still-.patch $ port install digikam good luck! Digikam runs fine when I start with an empty library. If I understand correctly, with the patch digikam will watch only directories, not files. But it would still be limited to watch a maximum of 255 directories, right? I have > 702 directories in my library, so I assume digikam will still crash even with this patch. Should I patch digikam to disable fs watching completely? Would it have other sideeffects besides not seeing new files on the fly? On Feb 5, 2012, at 8:20 AM, Daniel Zuberbühler wrote: > https://bugs.kde.org/show_bug.cgi?id=292522 > > > > > > --- Comment #13 from Daniel Zuberbühler <dani zubinet org> 2012-02-05 13:20:55 --- > Digikam runs fine when I start with an empty library. > > If I understand correctly, with the patch digikam will watch only directories, > not files. > But it would still be limited to watch a maximum of 255 directories, right? > I have > 702 directories in my library, so I assume digikam will still crash > even with this patch. > yes, you're absolutely correct. > Should I patch digikam to disable fs watching completely? Would it have other > sideeffects besides not seeing new files on the fly? > yes. disabling fs watching on os x seems to be the way to go. Actually I did try running digikam patched with brad's patch. It starts up properly, even with > 255 directories and I don't get any related error messages on the console. I guess the file limit really only applies to files but not to directories. Tried the patch from ticket #289330 and it solved the problem also for me. *** This bug has been marked as a duplicate of bug 289330 *** Not reproducible with 6.0.0 |