#343 Crash when using dark frame subtract

closed-works-for-me
nobody
None
5
2013-04-01
2013-03-31
Peter Sütterlin
No

I am processing a bunch of RAW files I took for startrail imaging. I switched off the dark subtract of the camera (Panasonic G5) and recorded a separate dark frame, that I am subtracting with ufraw. I prepared a .ufraw file with neccessary settings and process using ufraw-batch --conf=example.ufraw.

This works fine for most images, but some (9 in 75) do crash ufraw in different ways: Most often I get an (*)

stack smashing detected : ufraw-batch terminated
======= Backtrace: =========
/lib64/libc.so.6(fortify_fail+0x37)[0x7f544d7b5547]
/lib64/libc.so.6(
fortify_fail+0x0)[0x7f544d7b5510]
/usr/lib64/libjpeg.so.62(+0xf1bc)[0x7f544ea2c1bc]
/usr/lib64/libjpeg.so.62(+0x4bf6)[0x7f544ea21bf6]
/usr/lib64/libjpeg.so.62(jpeg_finish_compress+0x94)[0x7f544ea214b4]
ufraw-batch[0x41eac4]
ufraw-batch[0x40bd3f]
ufraw-batch[0x40977a]
/lib64/libc.so.6(__libc_start_main+0xed)[0x7f544d6e523d]
ufraw-batch[0x40bb21]

(*) followed by a longish memory map - attached

On two other occasions, it just died with a segfault, one other triggered the message 'Trace/breakpoint trap'

I had also tried saving as TIFF instead of JPEG, but got the same stack smashing crashes.

If I process the file without subtracting the dark things go fine.

If needed I can make a RAW/dark/ufraw file set available.

1 Attachments

Discussion

  • Sorry - forgot the version: I'm running a self compiled CVS version (dated 2013/03/28) on openSUSE 12.1

     
  • Hi Peter.

    Please make sample file sets available for all three error types if possible.

    Regards,
    Niels Kristian

     
  • Hi Niels Kristian,

    You can download it here: ftp://royac6.royac.iac.es/pit/ufraw-crash.tbz (49MB)

    Contains 4 raws (dark + one for each type), the .ufraw file I used and a small readme.

     
  • Hi Peter.

    Thanks for the samples. I cannot reproduce any of the crashes on my system (Ubuntu 12.04 64-bit) with the current cvs code (no significant changes since March 28th).

    What compiler version is used in openSUSE 12.1? You can find it in the output from 'gcc --version'.

    Please also try to run the segfaulting file through gdb and attach the backtrace from the crash. It might give some useful information.

    Regards,
    Niels Kristian

     
  • Good nws it's probably not ufraw's fault ;^>
    gcc --version is 'gcc (SUSE Linux) 4.6.2'
    The culprit seems to be libjpeg62:

    Program received signal SIGSEGV, Segmentation fault.
    0x00007ffff612fbf3 in ?? () from /usr/lib64/libjpeg.so.62
    (gdb) bt
    #0 0x00007ffff612fbf3 in ?? () from /usr/lib64/libjpeg.so.62
    #1 0x00007ffff612f4b4 in jpeg_finish_compress () from /usr/lib64/libjpeg.so.62
    #2 0x000000000041eac4 in ufraw_write_image (uf=0x786520) at ufraw_writer.c:521
    #3 0x000000000040bd3f in ufraw_batch_saver (uf=0x786520) at ufraw-batch.c:155
    #4 0x000000000040977a in main (argc=3, argv=0x7fffffffdc08) at ufraw-batch.c:98

    No debug info for this lib, sorry. The library package name is libjpeg62-62.0.0-10.4.1.x86_64, it's compiled from libjpeg-turbo-1.1.1-10.4.1.src.rpm.
    But I'll have to check - I saw similar crashes when writing tiff files.

     
  • Makes sense. Ubuntu 12.04 includes libjpeg8c. Is it possible for you to update the library and test Again?

    Regards,
    Niels Kristian

     
  • Not easily. libjpeg8 is installed, but some 20+ devel packages depend on libjpeg62-devel. I'll see if I can do a local install of the devel files.

     
  • OK, I managed to compile it, and the jpeg part now doesn't crash anymore. When compiling I noticed that libtiff is (also) compiled against libjpeg62 - maybe that was the reason for the crashes I saw when saving tiff?
    So seems it's a libjpeg issue and can be closed here? Would be interesting to know though what exactly triggers it - I use jpegs a lot and never saw this before....

     
  • I have closed the bug report. I think you are right that it is a libjpeg62 bug.

    Regards,
    Niels Kristian

     
    • status: open --> closed-works-for-me