No-no.

libraw (.a, .so) is compiled with -DLIBRAW_NOTHREADS, so some internal decoder buffers are static. This is faster, but this library is not reentrant. You may use it in multithreaded environment, but not for decoding several files in parallel

libraw_r is compiled with -pthread and without LIBRAW_NOTHREADS define, so all I/O calls are made via thread-safe version and decoder storage is allocated within LibRaw class. So, extra locks, extra indirection for storage, but thread-safe.

Not reentrant version is several percent faster.

In the best, is that i understand.

I thinks if you use pimpl idiom on LibRaw class you can remove this problem.
If i understand correctly the error, your libraw_memmgr implementation is declared in .h and is inlined.
So when you use it in application free and malloc are not the same that use in the dll.

http://support.microsoft.com/kb/140584/en-us

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.)