Thanks for info.

It looks like I need to provide four different DLLS:
librawT.dll - /MT
librawTd.dll - /MTd
librawD.dll - /MD
librawDd.dll - /MDd

Oh! Windows make me crazy!

I've test with valgrind. No memory error found ^^

I check your build option and my visual project option. We have a difference .
You use /MT and i use /MD. In this config, on an xp the main example crash on the first unpack.
If i change you option to use /MD it don't crash :D
I found more information about this mix error here :
http://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.71).aspx

Caution Do not mix static and dynamic versions of the run-time libraries. Having more than one copy of the run-time libraries in a process can cause problems, because static data in one copy is not shared with the other copy. The linker prevents you from linking with both static and dynamic versions within one .exe file, but you can still end up with two (or more) copies of the run-time libraries. For example, a dynamic-link library linked with the static (non-DLL) versions of the run-time libraries can cause problems when used with an .exe file that was linked with the dynamic (DLL) version of the run-time libraries. (You should also avoid mixing the debug and non-debug versions of the libraries in one process.)

I'll check tomorrow with my application if it's only that.

ps :I think you should propose a debug and a release dll with /MD and /MDd option.

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?