Currently, the above three implementations leak memory, as their cursors are created but never destroyed. The reason why they're never destroyed is due to a conflict in how they're written: In certain cases, stack memory is bound to the cursor, which cursor->destroy then attempts to free. In most cases this results in a segfault. As a temporary measure, most cursor->destroy calls have been commented out.
The relevant tests should be refactored to avoid the situation of free-ing stack memory.
Reference: test_oadictionaryhandler.c:353 and 380.
Currently, the above three implementations leak memory, as their cursors are created but never destroyed. The reason why they're never destroyed is due to a conflict in how they're written: In certain cases, stack memory is bound to the cursor, which
cursor->destroy
then attempts tofree
. In most cases this results in a segfault. As a temporary measure, mostcursor->destroy
calls have been commented out.The relevant tests should be refactored to avoid the situation of
free
-ing stack memory.Reference:
test_oadictionaryhandler.c:353
and 380.