double free or corruption (fasttop)

[ChinaChenp]

hi，i use you source code , but when i test many times, it will case a bug like this:

*** Error in `./../../build64_release/cplusutils/lrucache/lrucache_test': corrupted double-linked list: 0x00007f03c80008d0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7b9e3)[0x7f04bf1a69e3]
/lib64/libc.so.6(+0x7c4fe)[0x7f04bf1a74fe]
./../../build64_release/cplusutils/lrucache/lrucache_test[0x40d1a4]
/lib64/libstdc++.so.6(+0xb52b0)[0x7f04bfabb2b0]
/lib64/libpthread.so.0(+0x7e25)[0x7f04bfd15e25]
/lib64/libc.so.6(clone+0x6d)[0x7f04bf22334d]

I finnally find the two members define order is wrong:
Map cache_;
list_type keys_;

I think correct should be like this:
list_type keys_;
Map cache_;

[cculianu]

Hi,

Are you testing in a multithreaded app?

I am reviewing the code to this header to evaluate if I can use it in my project. I think the issue is that both get() and getCopy() are not thread safe, even if you instantiate the template with a real mutex.

While they guard access to the cache via a lock guard -- They release the lock when returning and get() returns a reference to internal cache data, while getCopy is just a wrapper around get() that does a copy-construct around the const Value & returned from get().

The real fix to all of this is to implement a getCopy() that holds the lock while it constructs the returned object, and only use getCopy() in multithreaded environments.

@mohaps Thoughts on this?

I am thinking of opening up an issue for thread-safety,

[cculianu]

See #19