lensfun-0.2.5 causing segfaults in digikam and ufraw

Franklin · 01-02-2011, 07:16 AM

Happy New Year Slackers!

Running slackware-current 32bit. I use digikam-1.7.0, kipi-plugins-1.7.0, and ufraw-0.17 which are all built using the sbo scripts from 13.1 repo.

All the above work fine with lensfun-0.2.3 built from sbo, but trying to update lensfun to 0.2.5 causes segfaults in digiKam and ufraw.

Anyone else seen this and is there a fix? Seems to be caused by a change in lensfun between versions, but I think it's beyond me to sort on my own.

Lensfun-0.2.5 seems to build fine without errors, but I believe there were warnings with respect to makedep. Digikam and ufraw locate the lensfun libraries during the build. Ufraw segfaults on startup and digikam segfaults when the auto lens correction tool is selected from the menu.

I know none of these versions are officially supported either alone or in -current, but just curious if someone had resolved this anywhere.

Thanks in advance!

jamesf · 01-02-2011, 11:18 AM

Note: I don't use lensfun, but I thought I might try to help out a little.

He seems to have changed several things that might affect you: he's changed the way lenses are detected; he's added processor detection code and (at least) sse and sse2 specific code generation. For the first, it looks like a code change in digikam would be necessary (or rollong back to 0.2.3). For the second, if your processor does not have sse or sse2, but you are compiling support for them, then things like this would happen.

If it were me, I'd start by looking at the output of:

Code:

james@darkstar:~$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 2.20GHz
stepping        : 4
cpu MHz         : 2192.606
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm up pebs bts
bogomips        : 4385.21
clflush size    : 64
cache_alignment : 128
address sizes   : 36 bits physical, 32 bits virtual
power management:

and comparing to the build flags for lensfun. If I didn't find a problem there, then I'd try re-compiling/reinstalling lensfun without any processor-specific features. If that didn't work, then I'd roll back to 0.2.3 and email the author a bug report.

Good luck!

titopoquito · 01-02-2011, 03:02 PM

Quote:

Originally Posted by jamesf

If I didn't find a problem there, then I'd try re-compiling/reinstalling lensfun without any processor-specific features. If that didn't work, then I'd roll back to 0.2.3 and email the author a bug report.

I am using lensfun but have not tried to use the newer version. A bug report I found suggests that jamesf could be right: http://www.mail-archive.com/pld-deve.../msg05913.html

That would require to add

Code:

--vectorization=""

to the configure line which disables the SSE* optimizations.

Franklin · 01-02-2011, 06:39 PM

Thanks both of you for your replies! This seems to confirm what I was seeing in a variety of comments here and there on the interweb.
I think for my purposes a rollback to lensfun-0.2.3 is the best choice for the moment. I was hoping to get a more up-to-date lens listing with the newer version, but I'm not convinced the payback will be worth the effort. I'm running the generic kernel on an i5:

Code:

root@dude:~# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 30
model name      : Intel(R) Core(TM) i5 CPU         760  @ 2.80GHz
stepping        : 5
cpu MHz         : 2797.916
cache size      : 8192 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi flexpriority ept vpid
bogomips        : 5595.83
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

The vectorization flag seems easy enough to try. Not sure if the loss of SSE optimizations will make any noticeable difference.
I can't try for a couple of days, but thanks again for giving me some options. I'll be certain to post back if I have any success.

*** edit - I see that there is a patch that was incorporated into CVS:

From the provided bug report link

Quote:

Dnia 2010-09-05, nie o godzinie 11:24 +0200, Kacper Kornet pisze:
> On Sat, Sep 04, 2010 at 08:43:33PM +0100, Przemo Firszt wrote:
> > There is a bug that causes SIGSEGV in ufraw-0.17 when used with
> > lensfun-0.2.5. Turning off vectorisation in lensfun is a known
> > workaround for this bug. See attached patch.
>
> Could you check lensfun-0.2.5-2 from our CVS? I have just added patch
> which is supposed to fix the bug.
Tested & works fine, so ma patch is no longer required.
Thanks,
--
Przemo Firszt <prz...@firszt.eu>

Of course, that may not fix the problem in digiKam ...