On 10/31/11 12:09, Stuart Henderson wrote:
On 2011-10-28, Jeff Ross<jr...@openvistas.net> wrote:
Hi,
On a very recent snapshot, ufraw is dumping core.
I ktraced it and put the out file at
http://www.openvistas.net/ufraw_ktrace.txt
but the last few lines just before the core is:
15386 ufraw CALL sigprocmask(SIG_SETMASK,0)
15386 ufraw RET sigprocmask -65793/0xfffefeff
15386 ufraw PSIG SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x1c31b1a
trapno=1
15386 ufraw NAMI "ufraw.core"
I tried this on two different systems.
A backtrace from gdb would be much more useful than ktrace.
jross@slony:/home/jross $ gdb ufraw
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd5.0"...
(no debugging symbols found)
(gdb) run
Starting program: /usr/local/bin/ufraw
/usr/local/bin/ufraw:/usr/X11R6/lib/libGL.so.10.0:
/usr/X11R6/lib/libGL.so.12.0 : WARNING: symbol(__glapi_noop_table) size
mismatch, relink your program
[New process 4689, thread 0x7e39b400]
[New process 4689]
[New process 4689, thread 0x81fa6c00]
[New process 4689, thread 0x7c22a800]
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 4689, thread 0x82c67c00]
0x0189db1a in lf_lens_interpolate_vignetting ()
from /usr/local/lib/liblensfun.so.1.0
(gdb) backtrace
#0 0x0189db1a in lf_lens_interpolate_vignetting ()
from /usr/local/lib/liblensfun.so.1.0
#1 0x018a02e3 in lfModifier::AddCoordCallbackDistortion ()
from /usr/local/lib/liblensfun.so.1.0
#2 0x0189a727 in lfModifier::Initialize ()
from /usr/local/lib/liblensfun.so.1.0
#3 0x1c028a3a in __register_frame_info ()
#4 0x1c00d44c in __register_frame_info ()
#5 0x1c00dae1 in __register_frame_info ()
#6 0x1c010508 in __register_frame_info ()
#7 0x1c01077c in __register_frame_info ()
#8 0x1c0113ba in __register_frame_info ()
#9 0x1c053b88 in Exiv2::toBasicString<char, std::string> ()
#10 0x1c00b550 in __register_frame_info ()
#11 0x1c00af97 in ?? ()
#12 0x1c00af97 in ?? ()
#13 0x00000001 in ?? ()
#14 0xcfbd136c in ?? ()
#15 0xcfbd1374 in ?? ()
#16 0xcfbfdff0 in ?? ()
#17 0xcfbd1368 in ?? ()
#18 0xcfbd1320 in ?? ()
#19 0x00000000 in ?? ()
Are there
any particular steps to reproduce the crash?
None other than trying to process a NEF file, either as ufraw or
ufraw-batch.
Do you need a specific image
file? Which arch?
i386
Any malloc.conf options?
No.
Does it go away without them?
Did it work previously, and if so how old was the code you were running
then?
It did but truthfully I can't narrow that down to much more than last
April or so. Then it would have been running a pretty current snapshot.
I then rebuild my workstation and it didn't get re-installed until
just before I reported the crash.
Are your packages all in-sync (i.e. updated from the same snapshot)?
Yes, updated on October 25, then packages updated with the following
from the same mirror:
cd /var/db/pkg
pkgs=`ls`
for i in $pkgs; do
echo Checking $i
/usr/sbin/pkg_add -F update,updatedepends -u -i $i
echo Done with $i
done
Thanks,
Jeff
