[regression] lensfun 0.2.3-0ubuntu4 freezes UFRaw.

I can verify this problem. UFRaw with LensFun stopped working for me as well, after updating to 0ubuntu4. After reverting to 0ubuntu3 everything worked again.

This problem can be checked without manually building UFRaw... I maintain a PPA, with UFRaw CVS checkouts with LensFun support:
  https://launchpad.net/~pmjdebruijn/+archive/ppa

My PPA packages suffer from the same issue as reported bij Niels...

Hi,

hm... interesting, thanks for the bug report.

I very much doubt that it's related to the source changes I did (see http://launchpadlibrarian.net/32071063/lensfun_0.2.3-0ubuntu3_0.2.3-0ubuntu4.diff.gz) to be honest.

It might however be related that -0ubuntu3 binaries were back then built with gcc-4.3, the -0ubuntu4 binaries with gcc-4.4 (which is now the default).

Looking at the ufraw sources from the ppa and at the lensfun sources, I must admit that I'm quite clueless at the moment. The problematic part seems to stem from ufraw, in ufraw_lens_ui.cpp, function fill_tca_page. There's a loop, that repeatedly calls lf_get_tca_model_desc and increments the first parameter (which is an enumeration with only two values btw.).
Lensfun in turn should have returned NULL if the enum is out of range (see libs/lensfun/lens.cpp).

Can you check if this loop is indeed the problematic part?

A wild theory I could give at this point is that gcc-4.4 (probably on error) believes that an enum which has only two values can never be out of bounds and hence eliminates the statements after the switch/case block in lensfun. I'll need to take a closer look at the resulting assembly to see if this is true though.

Cheers,
    Stefan.

Wow, usually my wild guesses are complete and utter nonsense. This time, it looks like I was right though.

Attaching disassembly of lfLens::GetTCAModelDesc(lfTCAModel, char const**, lfParameter const***), both from 0.2.3-0ubuntu4 (compiled with gcc-4.4) and from unstable's 0.2.3-2. The source of the function is the same.

Though I believe that this is a bug in the gcc-4.4 (I faintly recall that POSIX says that enum's are treated as ints, at least in C... but my memory may be wrong in this regard), I guess that the loop in ufraw should really be fixed to pass only values as defined by the enum to lensfun.

(hmpf, I'd like to make this bug affect both gcc-4.4 and lensfun, but I fail... can anyone who knows where to click do this please? Thanks!)

is this http://gcc.gnu.org/PR36917 ?

Yes, it is. So gcc is behaving correctly there. Moving back to lensfun.

So here for some language legalese:
ufraw calls the c method, where it's (to my understanding) legal to treat an enum as an int. It's not nice to exceed the bounds, but it's legal.

In lensfun, the C function is a wrapper around the c++ method. There the compiler may reduce the size of the enum (as per upstream bug report). So this wrapper needs adjustment to check the enum for the bounds. How tricky :).

I'll upload a fix soonish (maybe this evening).

Cheers,
      Stefan.

This bug was fixed in the package lensfun - 0.2.3-0ubuntu5

---------------
lensfun (0.2.3-0ubuntu5) karmic; urgency=low

  * Add 20-enum-sentinel patch to have g++-4.4 not remove the otherwise
    unreachable code handling out-of-bounds enum values via the
    c-wrapper functions. LP: #433368.

 -- Stefan Potyra <email address hidden> Mon, 21 Sep 2009 22:51:28 +0200

The bug is still present in lensfun 0.2.3 0ubuntu5.

hm... a closer look at ufraw reveals that the same out of bounds accessing is used for different enumeration values.
I must admit, that -- while that's legal from a C perspective -- I think it's not a too good idea to use out of bounds values for the enums in ufraw.

I guess it would be a better idea to get ufraw fixed, instead of applying band-aid patches to lensfun. I'll attach a patch against the ppa package of ufraw that hopefully fixes the problem. Can you check if that works, and if so, forward it to ufraw authors?

Are you ok, if I'll mark the bug in lensfun invalid if this works out?

Cheers,
    Stefan.

The patch fixes UFRaw and I'll commit it to cvs (I'm one of the UFRaw developers).

I still think the problem should be kept open until it is fixed in lensfun. A library should never be allowed to break on valid C code - even if it is obfuscated.

I'll try to import new CVS code into my PPA tonight...

> I still think the problem should be kept open until it is fixed in lensfun. A library should never be allowed to break on valid
> C code - even if it is obfuscated.

I already mailed Andrew Zabolotny (the lensfun author) the link to this bug report. But commits to lensfun cvs seem very sporadic.

Pascal, thanks a lot, that's what I wanted to do next ;).

I just updated my PPA, with code directly from CVS without any further patches, and everything seems dandy...

Since the current lensfun in Ubuntu is only half-fixed, I'll upload a version which adds sentinels to all enums (that way lensfun should again behave as if it were compiled with -4.3).

For reference, see the attached patch.

Cheers,
   Stefan.

This bug was fixed in the package lensfun - 0.2.3-0ubuntu6

---------------
lensfun (0.2.3-0ubuntu6) karmic; urgency=low

  * Add sentinels for other enums to 20-enum-sentinel, LP: #433368
    (second try).

 -- Stefan Potyra <email address hidden> Wed, 23 Sep 2009 20:59:58 +0200