I've encountered some strange behavior where I cannot erase a key that was previously inserted into ALEX.
I've put together a self-contained program that reproduces the problem along with a trace. The program can be compiled by placing it under src in this repository (and adding an add_executable() to the CMakeLists.txt file). To reproduce, just run the compiled program with the provided trace.
The program and trace will bulk load ALEX with 9000 64-bit keys and then run a series of inserts and deletes. The delete of the last key in the trace (347892347588) appears to fail because erase() returns 0. However, the key should exist in ALEX because it was inserted earlier (line 16694 in the trace) and was not deleted afterwards.
I was able to reproduce the problem in both Debug and Release mode. I tried compiling on machines with g++ v9.3.0 and v11.1.0 and was able to reproduce this problem with both compiler versions.
I've encountered some strange behavior where I cannot erase a key that was previously inserted into ALEX.
I've put together a self-contained program that reproduces the problem along with a trace. The program can be compiled by placing it under
src
in this repository (and adding anadd_executable()
to theCMakeLists.txt
file). To reproduce, just run the compiled program with the provided trace.The program and trace will bulk load ALEX with 9000 64-bit keys and then run a series of inserts and deletes. The delete of the last key in the trace (
347892347588
) appears to fail becauseerase()
returns 0. However, the key should exist in ALEX because it was inserted earlier (line 16694 in the trace) and was not deleted afterwards.I was able to reproduce the problem in both
Debug
andRelease
mode. I tried compiling on machines withg++
v9.3.0 and v11.1.0 and was able to reproduce this problem with both compiler versions.Trace: alex_remove_not_found.log
Program:
Expected output:
Actual output: