Summary: | image editor always crashes when triggering Colour Auto-Correction | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Adam Spiers <kde-bugs> |
Component: | Plugin-Editor-AutoColors | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | andrew.i.coles, caulier.gilles |
Priority: | NOR | ||
Version: | 2.0.0 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 1.9.0 | |
Sentry Crash Report: | |||
Attachments: |
capture of gdb session when digikam crashed
list of installed rpms |
Created attachment 56450 [details]
list of installed rpms
As you can quite easily see from the code lines given in the backtrace, the AutoCorrection plugin comes from digikam 1.7.0 and is of course binary incompatible with digikam 2.0.0 Sorry for the noise - but can you explain what I did wrong? Did I compile it wrong, or run it wrong? Are you saying I compiled 2.0.0 against the 1.7.0 plugin (in which case the compile should not have succeeded), or that I compiled correctly but it accidentally linked against the 1.7.0 plugin at run-time? I was worried about that, but as I already mentioned I tried both with and without LD_LIBRARY_PATH set, and I thought ld's RPATH option should take care of that anyway. Or do I really have to uninstall the rpm version of 1.7.0? Ideally it should be possible to have 1.7.0 (or 1.8.0) and 2.0.0 co-installed on the same machine, so that I can help test both versions. I looked at the backtrace more carefully. gdb refers to debug symbols in /usr/lib/debug/digikam-1.7.0, but that directory does not even exist on my system! So there is something stranger happening here. Sorry, I'm not really sure what you did wrong. It's very difficult to resolve such issues, even more so that KDE runtime plays a role in loading plugins. I have never tried to install two versions in parallel, perhaps others can give you some hints. No, I wouldn't recommend keeping two separate versions. I tried it myself a few times and there was always some libs mixup or other troubles. So I highly recommend uninstalling the distro package, recompiling the 2.0 version (delete the build folder and start over) and keeping only that one. Thanks for the advice Marcel and Martin. I would really like to be able to test both 1.8.0 and 2.0.0, so before I give up on this possibility completely, it would be great if you were able to give me some pointers on how the plugins are loaded, e.g. how the KDE runtime is involved, or maybe a URL for some documentation or code. Then maybe I could figure out the rest with ldd / strace / objdump etc. Try: export LOCALDIR=/path/you/installed/digikam/to export PATH=$LOCALDIR/bin:$PATH export LD_LIBRARY_PATH=$LOCALDIR/lib:$LD_LIBRARY_PATH export KDEDIRS=$LOCALDIR:/usr kbuildsycoca4 digikam (In reply to comment #8) > Try: > > export LOCALDIR=/path/you/installed/digikam/to > export PATH=$LOCALDIR/bin:$PATH > export LD_LIBRARY_PATH=$LOCALDIR/lib:$LD_LIBRARY_PATH > export KDEDIRS=$LOCALDIR:/usr > kbuildsycoca4 > digikam Thanks, that worked! |
Created attachment 56449 [details] capture of gdb session when digikam crashed Version: 2.0.0 (using KDE 4.5.5) OS: Linux I compiled 2.0.0-beta1 on openSUSE 11.3 x86_64 like this: mkdir build cd build cmake -DKFACE_EXTERNAL_FINDOPENCV:BOOL=TRUE -DCMAKE_BUILD_TYPE=debugfull -DCMAKE_INSTALL_PREFIX=/opt/digikam2 .. make sudo make install Then I ran it and tried to auto-correct the colour of an image: 1. /opt/digikam2/bin/digikam 2. Enter to select an image 3. F4 to enter image editor 4. Control+Shift+B to open Colour Auto-Correction and it crashes every time. Additionally, when drkonqi tries to get a stacktrace, gdb crashes every time with a message like the following: internal-error: virtual memory exhausted: can't allocate 11942884 bytes. but I monitored with htop and there was still (a) physical RAM free, and (b) 2GB of swap completely unused. So to work around this gdb bug, I re-ran: gdb /opt/digikam2/bin/digikam so that I could collect a partial stacktrace from gdb before gdb crashed. The results are attached. I tried running both with and without LD_LIBRARY_PATH=/opt/digikam2/lib64, and got the same stacktrace every time. Reproducible: Always