Parallel cl_load() crash (bb #2333).
Reason is twofold:
- cache.c had 2 'static' global variables, thus trying to initialize same cache
from multiple threads
- bytecode2llvm.cpp: something in LLVM 2.7 is crashing when loading in
parallel
Fix is to drop the 'static' on the variable (cache is per engine already).
This also fixes a potential memory leak in clamd!
The other part of the fix is to turn on the mutex around bytecode compilation
always. We don't call cl_load in parallel, so this doesn't affect clamd, but
some may need to call cl_load in parallel.
We treat found_possibly_unwanted as EMAX, except we can't cache
these at all, not even at their own reclevel, and we certainly can't cache
level0 (since we know it'll be virus).
We are still caching siblings in an archive, as long as they don't hit emax
themselves.
There were some variables initialized with values from dereferenced pointers,
and the null check after the init.
Also sizeof must be applied to pointed to element.
This happens due to deleted keys filling the hash,
workaround this issue for now, if this is a performance hog
we'll need to periodically clean up the deleted slots by rehashing
elements.
We never remove keys from the hash, we only replace keys that expire due to LRU,
with the new keys. However the new key is not inserted in the same place as the
old one! (it depends where it hashes) So we need to mark the old key as deleted,
and not as empty. Otherwise future searches could miss keys that are in the
hash!
