FS#56180 - [lensfun] segfault in lfModifier::~lfModifier

Attached to Project: Arch Linux
Opened by David Phillips (phillid) - Tuesday, 31 October 2017, 10:35 GMT
Last edited by Antonio Rojas (arojas) - Saturday, 11 November 2017, 11:49 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Antonio Rojas (arojas)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

The lensfun library as used by packages such as gimp-ufraw encounters a segmentation fault in the destructor for lfModifier. This destructor only seems to be invoked when an image either the program should exit, or when the next image in the queue should be loaded for processing.

Rebuilding lensfun resolved the issue for me. Initially just used git HEAD, observed the issue gone and ran a git bisect, but it proved inconclusive. I tried rebuilding locally from asp with no changes to the PKGBUILD whatsoever and the bug disappeared.

Additional info:
* Running lensfun 0.3.2-3
* Running gimp-ufraw 0.22-10
* Stacktrace from running into the segfault in lensfun-0.3.2-3 through ufraw attached. A few syms missing.

Steps to reproduce:

1) Open ufraw (untested with other tools that make use of lensfun's library)
2) Load a raw or JPG image
3) Press "Cancel" in ufraw
4) Observe segfault
5) Stroke beard, scratch head
6) Rebuild and find the bug mysteriously gone
   gdb-lensfun-crash.txt (1.8 KiB)
This task depends upon

Closed by  Antonio Rojas (arojas)
Saturday, 11 November 2017, 11:49 GMT
Reason for closing:  Fixed
Additional comments about closing:  lensfun 0.3.2-5
Comment by Antonio Rojas (arojas) - Tuesday, 31 October 2017, 11:43 GMT
Rebuilding doesn't make any difference here.
Comment by David Phillips (phillid) - Tuesday, 31 October 2017, 12:58 GMT
Bizarre. I will try building in a clean chroot tomorrow to isolate external factors. Does the -git version from the AUR make any difference your end, out of interest?

I should also make it doubly clear that I mean rebuilding lensfun, not ufraw.
Comment by Antonio Rojas (arojas) - Tuesday, 31 October 2017, 13:13 GMT
No, the git version also segfaults here.
Comment by Antonio Rojas (arojas) - Sunday, 05 November 2017, 10:34 GMT
ping?
Comment by David Phillips (phillid) - Saturday, 11 November 2017, 00:57 GMT
Built inside a chroot and built package results in segfault; without building in a chroot, no segfault. Potentially configuration or other leaking in which should be included for the chrooted build?
Comment by Doug Newgard (Scimmia) - Saturday, 11 November 2017, 00:58 GMT
You have a build log for building on your system outside a chroot?
Comment by David Phillips (phillid) - Saturday, 11 November 2017, 02:05 GMT
Here is the log. Had to tee makepkg's entire output with `2>&1` since makepkg's -L didn't appear to want to catch the output to stderr from some parts of the build.
   outside-chroot.log (8.1 KiB)
Comment by David Phillips (phillid) - Saturday, 11 November 2017, 02:08 GMT
Erm, pardon me. Here is the log when not using ccache…
   outside-chroot.log (10.8 KiB)
Comment by David Phillips (phillid) - Saturday, 11 November 2017, 02:18 GMT
Ack, ignore those. I seem to have tracked the problem down. It seems I was accidentally building with clang outside of the chroot, and when I switched to gcc, the compiled objects were somehow cached, creating the illusion that the same compiler produced different results outside the chroot compared to inside.

Further thorough cleaning and testing indicates that when lensfun is built with clang, inside chroot or out, then the problem goes away. I will investigate and take it upstream. Sorry for the noise.

EDIT: I have confirmed that it is an issue with ufraw itself passing a null pointer to the destructor. Perhaps clang inserts some null guards in destructors. I'm not so well versed in these things to be able to tell, nor to be able to tell gcc to do such things.
Comment by Antonio Rojas (arojas) - Saturday, 11 November 2017, 11:48 GMT
Thanks for the investigation. This has an easy workaround for GCC, but it still needs to be properly fixed so please report it upstream.

Loading...