it's a very *bip* bug :/

I ve make a lot of test today. With the main have done, crash is very rarely in debug and random in release. I test to add libraw src to not use dll. I've crash only in release.

i'll intall a linux and test with valgrin. Maybe i'll found something.
thanks for your help.

I've run this code in the same enviroment:
Windows7 x64
VC++ 2010 (with SP1)
LibRaw 0.13.1
And no problems in two tests:
* debug build, Canon 30D sample image, about 250 iterations
* release build, Canon 5DmkII sample image, 100+ iterations several times.
I've tried three LibRaw.DLL versions: from 0.13.1 distribution (with and without GPL2/3 packs) and rebuilt from source (without demosaic packs).

So, case is still unconfirmed for me. Is it possible that your computer has some memory problem (becasuse of overclock or overheat or so)?

Also, I've tried to move 'LibRaw proc' declaration outside from loop (within loop the object will be destroyed on each iteration).

without recycle() call, it's crash too. But later.
Good luck.

with this code (approximatively what i do), in release, i crash(heap corruption) with recycle.
If i remove recycle, doesn't crash.
heap corruption could be in recycle? mabe it's the two reclycle call (me and libraw destructor) wich corrupt heap?

#include "libraw.h"
#include <vector>
#include <iostream>
#include <fstream>
 
int main (int argc, char * argv[])
{
     for(int i =1;true;++i)
    {
        std::cout <<"image "<<i<<std::endl;
        std::vector<char > buff;
        std::ifstream f;
        f.open(argv[1],std::iostream::binary);
 
        long size;
        {
            long begin;
            begin = f.tellg();
            f.seekg (0, std::ios::end);
            size = long(f.tellg()) - begin;
            f.seekg (0, std::ios::beg);
        }
        buff.resize(size);
        f.read(&buff[0],size);
 
 
        LibRaw proc;
        std::cout <<"open buffer : " << proc.open_buffer(&buff[0],size) <<std::endl;
        std::cout <<"unpack : " <<  proc.unpack()<<std::endl;
 
        std::cout <<"recycle"<<std::endl<<std::endl;
        proc.recycle();
 
 
    }
 
    return 0;
}
<cpp>

Windows seven 64bits
Visual studio 2010
libraw 1.13.1 build in 32bits

It's a random crash. Generally it's appeare after 10-30 shoot in RAW.

I'll test to read same image N times in a loop to see if this reproduct crash.

I cannot reproduce the problem (using dcraw_emu -mmap *CR2).

Could you please describe your system enviroment (OS, compiler version and so)?

Add the following line to your portfile:

use_parallel_build no

(Looks as if with the current makefile, when using parallel builds it's possible to want to link your executables before the library has beem built.)

usr/local/lib -lexiv2 -lIlmImf -lImath -lHalf -lIex -lfftw3f -lm -ltiff -lgsl -lgslcblas -lraw_r -lpthread -lQtWebKit -lQtXml -lQtGui -lQtCore
/usr/local/lib/libraw_r.a(lib_libraw_r_a-dcraw_fileio.o): In function `LibRaw::apply_profile(char const*, char const*)':
/home/lkk/Downloads/LibRaw-0.13.1/internal/dcraw_fileio.cpp:164: undefined reference to `cmsErrorAction'
/home/lkk/Downloads/LibRaw-0.13.1/internal/dcraw_fileio.cpp:167: undefined reference to `cmsOpenProfileFromFile'
/home/lkk/Downloads/LibRaw-0.13.1/internal/dcraw_fileio.cpp:204: undefined reference to `cmsOpenProfileFromMem'
/home/lkk/Downloads/LibRaw-0.13.1/internal/dcraw_fileio.cpp:229: undefined reference to `cmsCreateTransform'
/home/lkk/Downloads/LibRaw-0.13.1/internal/dcraw_fileio.cpp:230: undefined reference to `cmsDoTransform'
/home/lkk/Downloads/LibRaw-0.13.1/internal/dcraw_fileio.cpp:232: undefined reference to `cmsDeleteTransform'
/home/lkk/Downloads/LibRaw-0.13.1/internal/dcraw_fileio.cpp:233: undefined reference to `cmsCloseProfile'
/home/lkk/Downloads/LibRaw-0.13.1/internal/dcraw_fileio.cpp:235: undefined reference to `cmsCloseProfile'
/home/lkk/Downloads/LibRaw-0.13.1/internal/dcraw_fileio.cpp:177: undefined reference to `cmsOpenProfileFromMem'
/home/lkk/Downloads/LibRaw-0.13.1/internal/dcraw_fileio.cpp:196: undefined reference to `cmsCreate_sRGBProfile'
collect2: ld returned 1 exit status
make: *** [luminance-hdr] Error 1
lkk@lkuntu:~/Downloads/luminance-hdr-2.0.2-pre1$

Please help :(

Shared libraries help distributors, even if the interface is constantly changing. Currently with static libraries, we have to keep rebuilding shotwell manually when we update libraw.

If you generated a shared library, we would make a binary package for this, e.g. libraw13 containing /usr/lib/libraw.so.13.0.0. Shotwell would be linked against this. If you release a new libraw with API changes, then we would make a new binary package libraw14 containing /usr/lib/libraw.so.14.0.0.

This is much the same as the statically linked case, but the advantages are:
- We can easily detect that shotwell is using the old libraw version as we would no longer be able to build libraw13. So we can automatically mark shotwell as needing a recompile.
- If you make a point release and don't change the major version number then no recompilation is required
- If we patch libraw then no recompilation of shotwell is required.

From a distributors point of view we don't mind how often you change the library version number (so if you don't want to make ABI guarantees then just keep increasing the version). libraw.so.999.0.0 is fine with us.

Could you please list these alternatives?

This issue will be fixed in coming 0.12.4 and 0.13.0-Release.

Thanks for report.

Problem solved, Hurray !!!

And it was not so complicated. In case of anyone having the same problem :

- Download the win32 zip of LibRaw (available on this website)
- open the makefile.mingw present in the LibRaw root folder and add the option "-mno-cygwin" to the cflags (this was obvious...)
- rename the Makefile.mingw in Makefile
- compile LibRaw using cygwin and make

You will now have a libraw.a present in the lib folder of LibRaw. This library can be used with codeblocks. You'll probably need to add the ws2_32 lib just after the libraw lib or you'll get undefined references to ntohs4.

Regards