[BUG]: 3L-Cache crashes (SIGSEGV) on trace `meta_reag.oracleGeneral.zst`

[rohitdwivedula]

Describe the bug
Running 3LCache (in size-aware mode) on meta_reag.oracleGeneral.zst crashes with a SIGSEGV a few seconds into the simulation.

To Reproduce

1. Build libCacheSim with: cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DENABLE_3L_CACHE=ON .. && ninja (requires LightGBM, see doc/install.md)
2. Run the command: ./bin/cachesim meta_reag.oracleGeneral.zst oracleGeneral 3LCache 0.001 -e "objective=object-miss-ratio" --num-thread=1
3. Provide input parameters and trace file: trace is meta_reag.oracleGeneral.zst, downloaded from here; cache size fraction 0.001. Same crash at 0.01 and 0.1 too.
4. See error

Expected behavior
Should not crash.

Environment (please complete the following information):

• OS: Ubuntu 22.04.2 LTS
• Compiler: gcc 11.4.0
• libCacheSim version: commit fedce66, branch develop
• Build type: Debug

Input data

• Trace: meta_reag.oracleGeneral.zst.
• Command: ./bin/cachesim meta_reag.oracleGeneral.zst oracleGeneral 3LCache 0.001 -e "objective=object-miss-ratio" --num-thread=1

Error output

Program received signal SIGSEGV, Segmentation fault.
0x0000555555602aa2 in ThreeLCache::ThreeLCacheCache::quick_demotion (this=0x555555722c70)
    at libCacheSim/cache/eviction/3LCache/ThreeLCache.cpp:288
288         auto it = key_map.find(new_obj_keys[i])->second;

#0  ThreeLCache::ThreeLCacheCache::quick_demotion   ThreeLCache.cpp:288
#1  ThreeLCache::ThreeLCacheCache::rank              ThreeLCache.cpp:199
#2  ThreeLCache::ThreeLCacheCache::evict_predobj     ThreeLCache.cpp:357
#3  ThreeLCache::ThreeLCacheCache::evict             ThreeLCache.cpp:305
#4  ThreeLCache_evict                                ThreeLCache_Interface.cpp:274
#5  cache_get_base                                    cache.c:254
#6  ThreeLCache_get                                   ThreeLCache_Interface.cpp:164
#7  simulate                                          sim.c:58
#8  main                                               main.c:25

Additional context
Line 288 does key_map.find(new_obj_keys[i])->second with no check against key_map.end(). Two other places in this same file already guard a similar "key/candidate might be gone" case with a check.

This diff fixed it for me locally:

   while (new_obj_size > (uint64_t)(_currentSize * reserved_space / 100) &&
          j < (int)(sample_rate * 1.5) && (size_t)i < new_obj_keys.size()) {
-    auto it = key_map.find(new_obj_keys[i])->second;
+    auto kit = key_map.find(new_obj_keys[i]);
+    if (kit == key_map.end()) { i++; continue; }
+    auto it = kit->second;
     if (it.list_idx == 0) {