Memory leaks

Problem
When querying a database, the memory usage of terminus-server keeps growing. This occurs on the dev branch with the terminus-store backend.
How to reproduce

Start a system monitor (for instance gnome-system-monitor)
Play around in the dashboard (click on schema, query etc.) and see the memory size of terminus-server getting bigger.

Additional information
Some valgrind logs of querying and the like:
==1408== 39,312 bytes in 1 blocks are still reachable in loss record 4,049 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5E9AE: do_init_atoms (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E6515C: PL_new_atom (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5CD68: PL_register_blob_type (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EFE9FF: initReservedSymbols (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5EB38: do_init_atoms (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E6515C: PL_new_atom (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F2C681: setPrologFlag (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E6DFAD: PL_set_prolog_flag (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF42AD: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 39,312 bytes in 1 blocks are possibly lost in loss record 4,050 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5E9AE: do_init_atoms (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E6515C: PL_new_atom (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F2C681: setPrologFlag (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E6DFAD: PL_set_prolog_flag (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF42AD: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 39,936 bytes in 18 blocks are still reachable in loss record 4,051 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F10A: htable_alloc_kvs (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F47F: htable_put (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F891: addHTable (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB923A: lookupProcedure (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDB3F5: loadXRc (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDBE20: loadPredicate (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC5CC: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC5CC: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 41,400 bytes in 1,035 blocks are still reachable in loss record 4,052 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E9BB28: lookupFunctorDef (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EAAB96: pl_functor3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6C2B: callProlog (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F08067: pl_with_mutex (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79F63: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6C2B: callProlog (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6E3C: pl_notrace1_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EBB0F1: trapUndefined (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 41,472 bytes in 432 blocks are still reachable in loss record 4,053 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB9186: lookupProcedure (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EBB445: pl_get_predicate_attribute (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79FA5: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E6D8AC: PL_toplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108724: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 41,760 bytes in 1,740 blocks are still reachable in loss record 4,054 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB8B75: newClauseRef (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB8C11: assertProcedure (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDBE90: loadPredicate (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC5CC: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC5CC: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC5CC: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDD25B: loadWicFromStream (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 41,984 bytes in 8 blocks are still reachable in loss record 4,055 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F10A: htable_alloc_kvs (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F47F: htable_put (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F891: addHTable (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB923A: lookupProcedure (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E8DCC5: compileSubClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E9399F: compileBody (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E94FFC: compileClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95BCE: assert_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E96136: record_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E961C9: pl_record_clause3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 42,744 bytes in 137 blocks are possibly lost in loss record 4,056 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0xA25005B: alloc::alloc::alloc::he71f6672ff69332a (alloc.rs:84)
==1408==    by 0xA24FFCB: alloc::alloc::exchange_malloc::h46527e14373cbbb6 (alloc.rs:206)
==1408==    by 0xA1844FF: new<terminus_store::layer::child::ChildSubjectLookup<terminus_store::storage::directory::SharedMmap>> (boxed.rs:121)
==1408==    by 0xA1844FF: _$LT$terminus_store..layer..child..ChildLayer$LT$M$GT$$u20$as$u20$terminus_store..layer..layer..Layer$GT$::lookup_subject::h0c968e5564fb6aac (child.rs:378)
==1408==    by 0xA34C2AA: _$LT$terminus_store..store..StoreLayer$u20$as$u20$terminus_store..layer..layer..Layer$GT$::lookup_subject::hc31873af51cae373 (mod.rs:205)
==1408==    by 0xA5BEC30: _$LT$terminus_store..store..sync..SyncStoreLayer$u20$as$u20$terminus_store..layer..layer..Layer$GT$::lookup_subject::hf2365060bef0b9b4 (sync.rs:163)
==1408==    by 0xA284D7D: layer_lookup_subject (lib.rs:351)
==1408==    by 0x9EB2A6B: pl_layer_lookup_subject (terminus_store.c:589)
==1408==    by 0x4E79FA5: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6C2B: callProlog (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EE5A3B: start_thread (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x60384A3: start_thread (pthread_create.c:456)
==1408==
==1408== 44,032 bytes in 10 blocks are still reachable in loss record 4,057 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F10A: htable_alloc_kvs (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F47F: htable_put (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F891: addHTable (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB923A: lookupProcedure (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E8DCC5: compileSubClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E9399F: compileBody (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E9396F: compileBody (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E94FFC: compileClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95BCE: assert_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E96136: record_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 44,032 bytes in 56 blocks are still reachable in loss record 4,058 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F10A: htable_alloc_kvs (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F47F: htable_put (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F901: updateHTable (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EA9135: exportProcedure (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EA92D8: export_pi (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EA92F0: pl_export1_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4ACF: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 46,608 bytes in 1,942 blocks are still reachable in loss record 4,059 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB8B75: newClauseRef (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E616D2: addClauseBucket (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E618AD: addClauseToIndex (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E61BC0: hashDefinition (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E62368: first_clause_guarded (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E636FA: firstClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E7B4D8: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4ACF: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 47,104 bytes in 7 blocks are still reachable in loss record 4,060 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F10A: htable_alloc_kvs (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F47F: htable_put (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F891: addHTable (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB923A: lookupProcedure (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95E06: assert_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E96136: record_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E961C9: pl_record_clause3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 49,152 bytes in 1 blocks are possibly lost in loss record 4,061 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5C628: allocateAtomBlock.part.6 (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5D474: lookupBlob (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5D6F4: lookupAtom (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E9A5DD: registerBuiltins (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E9A908: initBuildIns (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4ED0CCC: setupProlog (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF42B2: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 49,248 bytes in 2 blocks are still reachable in loss record 4,062 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E61ACD: hashDefinition (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E62368: first_clause_guarded (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E636FA: firstClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E7B4D8: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EBB0F1: trapUndefined (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E72C10: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4ACF: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 49,440 bytes in 56 blocks are still reachable in loss record 4,063 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E61ACD: hashDefinition (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E62368: first_clause_guarded (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E636FA: firstClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E7B4D8: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4ACF: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 54,643 bytes in 1 blocks are still reachable in loss record 4,064 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E8D2C8: initWamTable (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4ED0B9E: setupProlog (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF42B2: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 56,952 bytes in 113 blocks are still reachable in loss record 4,065 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0xA66B22B: alloc::alloc::alloc::h5720529faf6a4289 (alloc.rs:84)
==1408==    by 0xA66B19B: alloc::alloc::exchange_malloc::h96e4bb19607190fc (alloc.rs:206)
==1408==    by 0xA677F65: new<crossbeam_queue::seg_queue::Block<alloc::sync::Arc<tokio_threadpool::task::Task>>> (boxed.rs:121)
==1408==    by 0xA677F65: crossbeam_queue::seg_queue::SegQueue$LT$T$GT$::push::h60912bed1aa34d4c (seg_queue.rs:201)
==1408==    by 0xA68D264: tokio_threadpool::worker::entry::WorkerEntry::remotely_complete_task::hb324e0f074062ccf (entry.rs:266)
==1408==    by 0xA69BA66: tokio_threadpool::worker::Worker::run_task::h1ecf2a8dd4e7574e (mod.rs:515)
==1408==    by 0xA69AEDF: tokio_threadpool::worker::Worker::try_steal_task::hbf0e24cb88f05cbd (mod.rs:416)
==1408==    by 0xA69A4B9: tokio_threadpool::worker::Worker::try_run_task::h54601ba776355230 (mod.rs:301)
==1408==    by 0xA69A2F5: tokio_threadpool::worker::Worker::run::ha620171d3f5df792 (mod.rs:241)
==1408==    by 0xA61BA9B: tokio::runtime::threadpool::builder::Builder::build::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::hf1a0f86368d24d90 (builder.rs:390)
==1408==    by 0xA629E3B: tokio_timer::timer::handle::with_default::_$u7b$$u7b$closure$u7d$$u7d$::h7f92321d998b87fc (handle.rs:101)
==1408==    by 0xA627C63: std::thread::local::LocalKey$LT$T$GT$::try_with::h0591efca88fdf8c2 (local.rs:262)
==1408==
==1408== 58,544 bytes in 3,659 blocks are still reachable in loss record 4,066 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EEE291: addProcedureSourceFile (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95CB0: assert_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E96136: record_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E961C9: pl_record_clause3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4ACF: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 59,920 bytes in 1,498 blocks are still reachable in loss record 4,067 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E9BB28: lookupFunctorDef (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC05F9: build_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC5B14: simple_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC6FFB: complex_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC7A2A: read_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC90E0: read_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC9374: pl_read_clause3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 64,416 bytes in 671 blocks are still reachable in loss record 4,068 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB9186: lookupProcedure (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E8DCC5: compileSubClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E9399F: compileBody (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E94FFC: compileClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95BCE: assert_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E96136: record_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E961C9: pl_record_clause3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 64,524 bytes in 6,007 blocks are still reachable in loss record 4,069 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5D4D8: lookupBlob (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5D6F4: lookupAtom (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC448C: get_token__LD.part.37 (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC4EBB: simple_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC6FFB: complex_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC7A2A: read_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC90E0: read_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC9374: pl_read_clause3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 64,800 bytes in 675 blocks are still reachable in loss record 4,070 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB9186: lookupProcedure (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95E06: assert_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E96136: record_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E961C9: pl_record_clause3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4ACF: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 65,536 bytes in 1 blocks are still reachable in loss record 4,071 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F10A: htable_alloc_kvs (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F47F: htable_put (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F891: addHTable (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F931: addNewHTable (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB7F06: importDefinitionModule (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC5CC: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC5CC: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDD25B: loadWicFromStream (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 65,536 bytes in 1 blocks are still reachable in loss record 4,072 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E9B755: rehashFunctors.part.0 (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E9BADE: lookupFunctorDef (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB4E49: pl_univ2_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E6D8AC: PL_toplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108724: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 65,536 bytes in 1 blocks are definitely lost in loss record 4,073 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E9B94F: registerFunctor (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E9BC9A: lookupFunctorDef (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC05F9: build_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC5B14: simple_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC6FFB: complex_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC7A2A: read_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC90E0: read_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC9374: pl_read_clause3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 65,544 bytes in 1 blocks are still reachable in loss record 4,074 of 4,104
==1408==    at 0x4C2DDCF: realloc (vg_replace_malloc.c:785)
==1408==    by 0x4ED0708: stack_realloc (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E9FCA3: growStacks (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4ECF053: pl_trim_stacks0_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E6D8AC: PL_toplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108724: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 69,360 bytes in 68 blocks are still reachable in loss record 4,075 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x111EA983: ??? (in /usr/lib/x86_64-linux-gnu/libedit.so.2.0.55)
==1408==    by 0x111EB281: ??? (in /usr/lib/x86_64-linux-gnu/libedit.so.2.0.55)
==1408==    by 0x111EB4D7: ??? (in /usr/lib/x86_64-linux-gnu/libedit.so.2.0.55)
==1408==    by 0x111E0CA9: el_init_fd (in /usr/lib/x86_64-linux-gnu/libedit.so.2.0.55)
==1408==    by 0x111E0DC4: el_init (in /usr/lib/x86_64-linux-gnu/libedit.so.2.0.55)
==1408==    by 0x10FD2378: pl_wrap (in /usr/lib/swipl/lib/x86_64-linux/libedit4pl.so)
==1408==    by 0x4E79FEC: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E6D8AC: PL_toplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108724: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 69,360 bytes in 68 blocks are still reachable in loss record 4,076 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x111EAA23: ??? (in /usr/lib/x86_64-linux-gnu/libedit.so.2.0.55)
==1408==    by 0x111EB281: ??? (in /usr/lib/x86_64-linux-gnu/libedit.so.2.0.55)
==1408==    by 0x111EB4D7: ??? (in /usr/lib/x86_64-linux-gnu/libedit.so.2.0.55)
==1408==    by 0x111E0CA9: el_init_fd (in /usr/lib/x86_64-linux-gnu/libedit.so.2.0.55)
==1408==    by 0x111E0DC4: el_init (in /usr/lib/x86_64-linux-gnu/libedit.so.2.0.55)
==1408==    by 0x10FD2378: pl_wrap (in /usr/lib/swipl/lib/x86_64-linux/libedit4pl.so)
==1408==    by 0x4E79FEC: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E6D8AC: PL_toplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108724: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 75,376 bytes in 1,346 blocks are possibly lost in loss record 4,077 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0xA25005B: alloc::alloc::alloc::he71f6672ff69332a (alloc.rs:84)
==1408==    by 0xA24FFCB: alloc::alloc::exchange_malloc::h46527e14373cbbb6 (alloc.rs:206)
==1408==    by 0xA281C29: new<terminus_store::store::sync::SyncStoreLayer> (boxed.rs:121)
==1408==    by 0xA281C29: named_graph_get_head (lib.rs:92)
==1408==    by 0x9EB194C: pl_head (terminus_store.c:76)
==1408==    by 0x4E79F63: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6C2B: callProlog (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EE5A3B: start_thread (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x60384A3: start_thread (pthread_create.c:456)
==1408==
==1408== 77,066 bytes in 1,562 blocks are possibly lost in loss record 4,078 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0xA6FF59B: alloc::alloc::alloc::hd4aea4183502f317 (alloc.rs:84)
==1408==    by 0xA6FF381: _$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Alloc$GT$::alloc::h480641302563a5de (alloc.rs:172)
==1408==    by 0xA6FD4F1: alloc::raw_vec::RawVec$LT$T$C$A$GT$::allocate_in::hdf0c932391516013 (raw_vec.rs:98)
==1408==    by 0xA6FD315: alloc::raw_vec::RawVec$LT$T$GT$::with_capacity::he59c15e7bbc32409 (raw_vec.rs:142)
==1408==    by 0xA6FB7D3: alloc::vec::Vec$LT$T$GT$::with_capacity::h01034cb82ca16857 (vec.rs:356)
==1408==    by 0xA6FBEE0: alloc::slice::hack::to_vec::ha47e2e0d5411d604 (slice.rs:158)
==1408==    by 0xA6FF714: alloc::slice::_$LT$impl$u20$$u5b$T$u5d$$GT$::to_vec::h4998449c8f1d41db (slice.rs:379)
==1408==    by 0xA6D8684: alloc::slice::_$LT$impl$u20$alloc..borrow..ToOwned$u20$for$u20$$u5b$T$u5d$$GT$::to_owned::h46d730f63c69ab9c (slice.rs:716)
==1408==    by 0xA519399: alloc::str::_$LT$impl$u20$alloc..borrow..ToOwned$u20$for$u20$str$GT$::to_owned::h6c513b92cb4e973a (str.rs:207)
==1408==    by 0xA42AE95: terminus_store::storage::directory::get_label_from_file::hfe4de0f255ba6d3f (directory.rs:185)
==1408==    by 0xA42C7B0: _$LT$terminus_store..storage..directory..DirectoryLabelStore$u20$as$u20$terminus_store..storage..label..LabelStore$GT$::get_label::h3bc90d719ba2e3c2 (directory.rs:257)
==1408==
==1408== 83,136 bytes in 866 blocks are still reachable in loss record 4,079 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB9186: lookupProcedure (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDB3F5: loadXRc (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDBE20: loadPredicate (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC5CC: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC5CC: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC5CC: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDD25B: loadWicFromStream (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 86,880 bytes in 905 blocks are still reachable in loss record 4,080 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB9186: lookupProcedure (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E8DCC5: compileSubClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E9399F: compileBody (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E9396F: compileBody (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E94FFC: compileClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95BCE: assert_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E96136: record_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E961C9: pl_record_clause3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 89,536 bytes in 293 blocks are still reachable in loss record 4,081 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95587: compileClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95BCE: assert_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E96136: record_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E961C9: pl_record_clause3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EBB0F1: trapUndefined (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E72C10: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4ACF: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 98,304 bytes in 1 blocks are still reachable in loss record 4,082 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5C628: allocateAtomBlock.part.6 (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5D474: lookupBlob (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5D6F4: lookupAtom (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4ED8292: getAtom (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDB304: loadXRc (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDB370: loadXRc (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC786: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC5CC: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 98,304 bytes in 8 blocks are still reachable in loss record 4,083 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0xA6EE06B: alloc::alloc::alloc::ha26ad29b2718f601 (alloc.rs:84)
==1408==    by 0xA6EDE51: _$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Alloc$GT$::alloc::hd4fce9f3a1e51fd6 (alloc.rs:172)
==1408==    by 0xA6E9FF1: alloc::raw_vec::RawVec$LT$T$C$A$GT$::allocate_in::h4992af088d19145b (raw_vec.rs:98)
==1408==    by 0xA6E9E65: alloc::raw_vec::RawVec$LT$T$GT$::with_capacity::h40203dd55ac5499a (raw_vec.rs:142)
==1408==    by 0xA6F5033: alloc::vec::Vec$LT$T$GT$::with_capacity::ha16120202ccaaf0f (vec.rs:356)
==1408==    by 0xA6F0728: mio::sys::unix::epoll::Events::with_capacity::h7ee83912fc62963e (epoll.rs:184)
==1408==    by 0xA6E4C37: mio::poll::Events::with_capacity::h76433514da4913ed (poll.rs:1362)
==1408==    by 0xA63B1CD: tokio_reactor::Reactor::new::hded064c06aa038fb (lib.rs:256)
==1408==    by 0xA61AF56: tokio::runtime::threadpool::builder::Builder::build::h5c3ebe8c09353878 (builder.rs:356)
==1408==    by 0xA61A374: tokio::runtime::threadpool::Runtime::new::h1069aba4c726ff08 (mod.rs:145)
==1408==    by 0xA4BC54D: __static_ref_initialize (sync.rs:18)
==1408==    by 0xA4BC54D: core::ops::function::FnOnce::call_once::h343c611514ba4125 (function.rs:235)
==1408==
==1408== 99,968 bytes in 1,562 blocks are possibly lost in loss record 4,084 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0xA25005B: alloc::alloc::alloc::he71f6672ff69332a (alloc.rs:84)
==1408==    by 0xA24FFCB: alloc::alloc::exchange_malloc::h46527e14373cbbb6 (alloc.rs:206)
==1408==    by 0xA281811: new<terminus_store::store::sync::SyncNamedGraph> (boxed.rs:121)
==1408==    by 0xA281811: open_named_graph (lib.rs:70)
==1408==    by 0x9EB18A6: pl_open_named_graph (terminus_store.c:56)
==1408==    by 0x4E79FA5: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6C2B: callProlog (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EE5A3B: start_thread (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x60384A3: start_thread (pthread_create.c:456)
==1408==
==1408== 115,536 bytes in 574 blocks are still reachable in loss record 4,085 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95587: compileClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95BCE: assert_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95FE5: pl_assertz11_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4ACF: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 118,848 bytes in 7,428 blocks are still reachable in loss record 4,086 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EA8621: import (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EA8B70: pl_import2_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4ACF: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 121,344 bytes in 1,264 blocks are still reachable in loss record 4,087 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB9186: lookupProcedure (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EA9293: export_pi (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EA92F0: pl_export1_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4ACF: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 131,072 bytes in 1 blocks are still reachable in loss record 4,088 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5D154: lookupBlob (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5D6F4: lookupAtom (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC448C: get_token__LD.part.37 (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC4EBB: simple_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC6FFB: complex_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC7A2A: read_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC90E0: read_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC9374: pl_read_clause3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 135,264 bytes in 1,409 blocks are still reachable in loss record 4,089 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB9186: lookupProcedure (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EBB445: pl_get_predicate_attribute (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79FA5: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4ACF: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 151,216 bytes in 610 blocks are still reachable in loss record 4,090 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDBC36: loadPredicate (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC5CC: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDD25B: loadWicFromStream (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4983: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 162,352 bytes in 1,274 blocks are still reachable in loss record 4,091 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95587: compileClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95BCE: assert_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95FE5: pl_assertz11_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6C2B: callProlog (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F08067: pl_with_mutex (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79F63: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6C2B: callProlog (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6E3C: pl_notrace1_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 163,840 bytes in 3 blocks are still reachable in loss record 4,092 of 4,104
==1408==    at 0x4C2DDCF: realloc (vg_replace_malloc.c:785)
==1408==    by 0xA66B2FC: alloc::alloc::realloc::h8a506f3cbb6b31d2 (alloc.rs:128)
==1408==    by 0xA66B085: _$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Alloc$GT$::realloc::hb3182a071ab63438 (alloc.rs:187)
==1408==    by 0xA68B4FC: alloc::raw_vec::RawVec$LT$T$C$A$GT$::reserve_internal::h831f47b119d22fb7 (raw_vec.rs:670)
==1408==    by 0xA68C321: alloc::raw_vec::RawVec$LT$T$C$A$GT$::reserve::h0ab4df7f50cf5bac (raw_vec.rs:495)
==1408==    by 0xA67AB59: alloc::vec::Vec$LT$T$GT$::reserve::h52b1de304f27808a (vec.rs:458)
==1408==    by 0xA67A9D8: alloc::vec::Vec$LT$T$GT$::push::ha3ca665daa1a1f25 (vec.rs:1103)
==1408==    by 0xA6A52CA: slab::Slab$LT$T$GT$::insert_at::h368e1806d6c9a02c (lib.rs:632)
==1408==    by 0xA6A4F8D: slab::Slab$LT$T$GT$::insert::h00760eb0289b4efd (lib.rs:593)
==1408==    by 0xA68D0FD: tokio_threadpool::worker::entry::WorkerEntry::register_task::h2dc22e18db88036e (entry.rs:246)
==1408==    by 0xA69B3C2: tokio_threadpool::worker::Worker::run_task::h1ecf2a8dd4e7574e (mod.rs:456)
==1408==    by 0xA69AEDF: tokio_threadpool::worker::Worker::try_steal_task::hbf0e24cb88f05cbd (mod.rs:416)
==1408==
==1408== 199,848 bytes in 711 blocks are still reachable in loss record 4,093 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95587: compileClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95BCE: assert_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E96136: record_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E961C9: pl_record_clause3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E6D8AC: PL_toplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108724: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 320,912 bytes in 160 blocks are still reachable in loss record 4,094 of 4,104
==1408==    at 0x4C2DDCF: realloc (vg_replace_malloc.c:785)
==1408==    by 0xA6D97FC: alloc::alloc::realloc::h44faf8366b2dd8f5 (alloc.rs:128)
==1408==    by 0xA6D95C5: _$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Alloc$GT$::realloc::h1401f2a0cb8d81be (alloc.rs:187)
==1408==    by 0xA6E2A2C: alloc::raw_vec::RawVec$LT$T$C$A$GT$::reserve_internal::h4c6160995cb76387 (raw_vec.rs:670)
==1408==    by 0xA6E2DF1: alloc::raw_vec::RawVec$LT$T$C$A$GT$::reserve::h02e7114964f068bf (raw_vec.rs:495)
==1408==    by 0xA6DAD09: alloc::vec::Vec$LT$T$GT$::reserve::h3e715be6561b28cf (vec.rs:458)
==1408==    by 0xA439AD7: std::io::read_to_end_with_reservation::ha4f7121a3e92b640 (mod.rs:369)
==1408==    by 0xA4399D9: std::io::read_to_end::h26ee9a584052e32d (mod.rs:356)
==1408==    by 0xA439F54: std::io::Read::read_to_end::h2b0c8315939ac5b6 (mod.rs:648)
==1408==    by 0xA5248F2: _$LT$tokio_io..io..read_to_end..ReadToEnd$LT$A$GT$$u20$as$u20$futures..future..Future$GT$::poll::hb08d089e542610dd (read_to_end.rs:56)
==1408==    by 0xA364B9E: _$LT$futures..future..map..Map$LT$A$C$F$GT$$u20$as$u20$futures..future..Future$GT$::poll::h6f8cdb8e2e4ee012 (map.rs:30)
==1408==    by 0xA394429: _$LT$futures..future..either..Either$LT$A$C$B$GT$$u20$as$u20$futures..future..Future$GT$::poll::h5e4dca6ff650928d (either.rs:36)
==1408==
==1408== 330,120 bytes in 655 blocks are still reachable in loss record 4,095 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0xA66B22B: alloc::alloc::alloc::h5720529faf6a4289 (alloc.rs:84)
==1408==    by 0xA66B19B: alloc::alloc::exchange_malloc::h96e4bb19607190fc (alloc.rs:206)
==1408==    by 0xA677F65: new<crossbeam_queue::seg_queue::Block<alloc::sync::Arc<tokio_threadpool::task::Task>>> (boxed.rs:121)
==1408==    by 0xA677F65: crossbeam_queue::seg_queue::SegQueue$LT$T$GT$::push::h60912bed1aa34d4c (seg_queue.rs:201)
==1408==    by 0xA68D264: tokio_threadpool::worker::entry::WorkerEntry::remotely_complete_task::hb324e0f074062ccf (entry.rs:266)
==1408==    by 0xA69BA66: tokio_threadpool::worker::Worker::run_task::h1ecf2a8dd4e7574e (mod.rs:515)
==1408==    by 0xA69AA56: tokio_threadpool::worker::Worker::try_run_owned_task::hd80973516daca83e (mod.rs:390)
==1408==    by 0xA69A49C: tokio_threadpool::worker::Worker::try_run_task::h54601ba776355230 (mod.rs:297)
==1408==    by 0xA69A2F5: tokio_threadpool::worker::Worker::run::ha620171d3f5df792 (mod.rs:241)
==1408==    by 0xA61BA9B: tokio::runtime::threadpool::builder::Builder::build::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::hf1a0f86368d24d90 (builder.rs:390)
==1408==    by 0xA629E3B: tokio_timer::timer::handle::with_default::_$u7b$$u7b$closure$u7d$$u7d$::h7f92321d998b87fc (handle.rs:101)
==1408==    by 0xA627C63: std::thread::local::LocalKey$LT$T$GT$::try_with::h0591efca88fdf8c2 (local.rs:262)
==1408==
==1408== 330,752 bytes in 125 blocks are still reachable in loss record 4,096 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F10A: htable_alloc_kvs (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F47F: htable_put (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F1F891: addHTable (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EA867E: import (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EA8B70: pl_import2_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4ACF: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 360,448 bytes in 5 blocks are still reachable in loss record 4,097 of 4,104
==1408==    at 0x4C2DDCF: realloc (vg_replace_malloc.c:785)
==1408==    by 0xA66B2FC: alloc::alloc::realloc::h8a506f3cbb6b31d2 (alloc.rs:128)
==1408==    by 0xA66B085: _$LT$alloc..alloc..Global$u20$as$u20$core..alloc..Alloc$GT$::realloc::hb3182a071ab63438 (alloc.rs:187)
==1408==    by 0xA68B4FC: alloc::raw_vec::RawVec$LT$T$C$A$GT$::reserve_internal::h831f47b119d22fb7 (raw_vec.rs:670)
==1408==    by 0xA68C321: alloc::raw_vec::RawVec$LT$T$C$A$GT$::reserve::h0ab4df7f50cf5bac (raw_vec.rs:495)
==1408==    by 0xA67AB59: alloc::vec::Vec$LT$T$GT$::reserve::h52b1de304f27808a (vec.rs:458)
==1408==    by 0xA67A9D8: alloc::vec::Vec$LT$T$GT$::push::ha3ca665daa1a1f25 (vec.rs:1103)
==1408==    by 0xA6A52CA: slab::Slab$LT$T$GT$::insert_at::h368e1806d6c9a02c (lib.rs:632)
==1408==    by 0xA6A4F8D: slab::Slab$LT$T$GT$::insert::h00760eb0289b4efd (lib.rs:593)
==1408==    by 0xA68D0FD: tokio_threadpool::worker::entry::WorkerEntry::register_task::h2dc22e18db88036e (entry.rs:246)
==1408==    by 0xA69B3C2: tokio_threadpool::worker::Worker::run_task::h1ecf2a8dd4e7574e (mod.rs:456)
==1408==    by 0xA69AA56: tokio_threadpool::worker::Worker::try_run_owned_task::hd80973516daca83e (mod.rs:390)
==1408==
==1408== 441,456 bytes in 18,394 blocks are still reachable in loss record 4,098 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E60CCD: allocHeapOrHalt (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB8B75: newClauseRef (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB8C11: assertProcedure (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95CC7: assert_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E96136: record_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E961C9: pl_record_clause3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4ACF: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 460,440 bytes in 1,740 blocks are still reachable in loss record 4,099 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDBC36: loadPredicate (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC5CC: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC5CC: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDC5CC: loadPart (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDCA4D: loadStatement (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EDD25B: loadWicFromStream (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4983: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 589,824 bytes in 2 blocks are possibly lost in loss record 4,100 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5C628: allocateAtomBlock.part.6 (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5D474: lookupBlob (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5D6F4: lookupAtom (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4F2191C: PL_unify_text (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB4603: atomic_list_concat (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4ACF: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== 786,432 bytes in 1 blocks are still reachable in loss record 4,101 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5C628: allocateAtomBlock.part.6 (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5D474: lookupBlob (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E5D6F4: lookupAtom (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC448C: get_token__LD.part.37 (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC4EBB: simple_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC6FFB: complex_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC7A2A: read_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC90E0: read_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EC9374: pl_read_clause3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==
==1408== 1,532,416 bytes in 11,972 blocks are still reachable in loss record 4,102 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0xA66B22B: alloc::alloc::alloc::h5720529faf6a4289 (alloc.rs:84)
==1408==    by 0xA66B19B: alloc::alloc::exchange_malloc::h96e4bb19607190fc (alloc.rs:206)
==1408==    by 0xA6A6DBD: alloc::sync::Arc$LT$T$GT$::new::h39278ecbb3715592 (sync.rs:306)
==1408==    by 0xA6992FF: _$LT$$RF$tokio_threadpool..sender..Sender$u20$as$u20$tokio_executor..executor..Executor$GT$::spawn::he41a8e947bc04f02 (sender.rs:168)
==1408==    by 0xA4B9EE5: tokio_threadpool::sender::Sender::spawn::hff27a00b7db63eee (sender.rs:84)
==1408==    by 0xA4E555D: _$LT$tokio_threadpool..sender..Sender$u20$as$u20$futures..future..Executor$LT$T$GT$$GT$::execute::heb0eb5a86d418f85 (sender.rs:207)
==1408==    by 0xA4B84B1: _$LT$tokio..runtime..threadpool..task_executor..TaskExecutor$u20$as$u20$futures..future..Executor$LT$T$GT$$GT$::execute::hba082e0ddfdb4670 (task_executor.rs:65)
==1408==    by 0xA38E4BB: futures::sync::oneshot::spawn::h1836a491ca64c44b (oneshot.rs:517)
==1408==    by 0xA5BF4BB: terminus_store::store::sync::SyncStore::open::hdc8943dc25014f5b (sync.rs:282)
==1408==    by 0xA28170E: open_named_graph (lib.rs:67)
==1408==    by 0x9EB18A6: pl_open_named_graph (terminus_store.c:56)
==1408==
==1408== 1,532,416 bytes in 11,972 blocks are still reachable in loss record 4,103 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0xA66B22B: alloc::alloc::alloc::h5720529faf6a4289 (alloc.rs:84)
==1408==    by 0xA66B19B: alloc::alloc::exchange_malloc::h96e4bb19607190fc (alloc.rs:206)
==1408==    by 0xA6A6DBD: alloc::sync::Arc$LT$T$GT$::new::h39278ecbb3715592 (sync.rs:306)
==1408==    by 0xA6992FF: _$LT$$RF$tokio_threadpool..sender..Sender$u20$as$u20$tokio_executor..executor..Executor$GT$::spawn::he41a8e947bc04f02 (sender.rs:168)
==1408==    by 0xA4B9DC5: tokio_threadpool::sender::Sender::spawn::hedd6cb8ecb813ff8 (sender.rs:84)
==1408==    by 0xA4E538D: _$LT$tokio_threadpool..sender..Sender$u20$as$u20$futures..future..Executor$LT$T$GT$$GT$::execute::hc30fa031c999c532 (sender.rs:207)
==1408==    by 0xA4B838F: _$LT$tokio..runtime..threadpool..task_executor..TaskExecutor$u20$as$u20$futures..future..Executor$LT$T$GT$$GT$::execute::h78ab25535157aa3b (task_executor.rs:65)
==1408==    by 0xA38F6A5: futures::sync::oneshot::spawn::hbf18f4b4bf54e1ba (oneshot.rs:517)
==1408==    by 0xA5BEFF7: terminus_store::store::sync::SyncNamedGraph::head::ha3dbb3d9050b7690 (sync.rs:236)
==1408==    by 0xA281B08: named_graph_get_head (lib.rs:85)
==1408==    by 0x9EB194C: pl_head (terminus_store.c:76)
==1408==
==1408== 4,341,320 bytes in 18,394 blocks are still reachable in loss record 4,104 of 4,104
==1408==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==1408==    by 0x4E63358: PL_malloc_atomic_unmanaged (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95587: compileClause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E95BCE: assert_term (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E96136: record_clause (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E961C9: pl_record_clause3_va (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4E79C62: PL_next_solution (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB675A: query_loop (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EB6F8A: prologToplevel (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x4EF4ACF: PL_initialise (in /usr/lib/swipl/lib/x86_64-linux/libswipl.so.8.0.3)
==1408==    by 0x108718: main (in /usr/lib/swipl/bin/x86_64-linux/swipl)
==1408==
==1408== LEAK SUMMARY:
==1408==    definitely lost: 160,800 bytes in 205 blocks
==1408==    indirectly lost: 8,192 bytes in 1 blocks
==1408==      possibly lost: 1,221,173 bytes in 14,903 blocks
==1408==    still reachable: 15,880,378 bytes in 149,101 blocks
==1408==                       of which reachable via heuristic:
==1408==                         length64           : 106,520 bytes in 3 blocks
==1408==                         newarray           : 55,160 bytes in 1,594 blocks
==1408==         suppressed: 0 bytes in 0 blocks
==1408==
==1408== For counts of detected and suppressed errors, rerun with: -v
==1408== Use --track-origins=yes to see where uninitialised values come from
==1408== ERROR SUMMARY: 69934 errors from 461 contexts (suppressed: 0 from 0)

Useful bash one-liner:
while :; do curl 'http://localhost:6363/' -H 'Authorization: Basic OnJvb3Q='; done

Start up a system monitor and see the memory usage growing

I can't reproduce the leak anymore after commit #8ed4110ebb3b302a535445298638035f94119d44

The leak seems to be solved on the newest terminus_store_prolog bindings.


docs: skip generating spectaql generation in netlify deploy

We now do this as part of the docs generate dagger pipeline - since it's already there, we might as well just use it - see #7937 and #8118.
Additionally, we do some shenanigans there so that we generate stable results, that don't have random results inserted in there - this requires a custom build of spectaql.
I also switched the docs directory to use yarn instead of npm. We were already using this in our netlify deploy step, but:

Because we only had a package-lock.json file, and not a yarn.lock file, none of our dependencies were actually getting pinned!
This differed from the recommended dev setup.

I've just switched over from npm to yarn, hopefully that's alright!

I would like @crjm to comment if he sees any issue with this specific change:

I also switched the docs directory to use yarn instead of npm. We were already using this in our netlify deploy step...

Apart from the above and one requested change, this seems fine to me.


Make authors' list more welcome to more contributions

In response to the issue reported by @bebatut in issue #2835, I created a direct call to action which is also a hyperlink, the call to action clearly states, "Interested in contributing to this material?". When they click the link, it takes them directly to the How to contribute tutorial page where they can learn and be directed on how to contribute to the material.
I noticed the call to action was not directly under the authors list, what do you think about it?

I resolved the conflict.. :)

Thanks, I triggered the test!

Thank you @bgruening, I noticed there's a failing test....what could be wrong?

@Chinonyemildred if you click on "Details" next to the failing test, you can find the following error message:
Liquid Exception: Could not locate the included file '_includes/contributor-badge-list.html' in any of
["/home/runner/work/training-material/training-material/"]. Ensure it exists in one of those directories
and, if it is a symlink, does not point outside your site source. in /home/runner/work/training-material/training-material/_layouts/tutorial_hands_on.html

the file you are including contributor-badge-list.html does not exist, so please double-check what you wanted to do there

Hi @Chinonyemildred, it seems you're working off of an older version of the GTN, we've replaced the contributor-badge-list.html with contributor-list.html (as you can see by what the diff looks like). Could you please update your GTN branch and start again?

The "Lint broken links" is a bit of a bad name, it will also catch general build failures (like requiring a template which no longer exists on the main branch of the codebase)

Wow....okay, thank you. I'll work on that

@Chinonyemildred I was inspired by your idea to style it a bit like a contributor badge, wondering what you think:

Clicking it will still link to the contributing topic.
If you like this idea, I can add the changes to this PR.


Add drop down menu for docs

The different doc pages on pub.dartlang.org aren't very discoverable right now. How about we make a "Getting Started" button on the top nav that links to docs/ and then turn "Docs" into a drop down with links to each doc page.

This issue has been moved to dart-lang/pub#121.


Add govuk_content_production back into backup config.

It turns out this MongoDB/DocumentDB database was only mostly owned by content-store (which was migrated to Postgres). It's still accessed by publisher, specialist-publisher and service-manual-publisher.
Need to tease out what on earth is going on with these three apps and figure out how bad the situation is and how to fix it, but that's a different matter. For now, just keep backing this stuff up so at least we're not SOL if we lose prod.

I suppose we still would have had DocDB snapshots so would have still been covered, but hey.


Expose switch_context in coverage API

This PR adds Coverage.switch_context method.
I think this is a quite efficient way to expose dynamic context to test runners that already use coverage API.
For example, nose test runner:  https://nose.readthedocs.io/en/latest/plugins/cover.html
The runner already knows the test case name, so there is no need to check each frame dymamically if it entered a test function.   In addition, this would allow runners to report labels consistently with their test case name format.
Excerpt from nose coverage support:
class Coverage(Plugin):
<...>

    def configure(self, options, conf):
        <...>
        if self.enabled:
            self.status['active'] = True
            self.coverInstance = coverage.coverage(auto_data=False,
                branch=self.coverBranches, data_suffix=conf.worker,
                source=self.coverPackages, config_file=self.coverConfigFile)
            self.coverInstance._warn_no_data = False
            self.coverInstance.is_worker = conf.worker
            self.coverInstance.exclude('#pragma[: ]+[nN][oO] [cC][oO][vV][eE][rR]')
        <...>

    def beforeTest(self, *args, **kwargs):
        """
        Begin recording coverage information.
        """

        if self.coverInstance.is_worker:
            self.coverInstance.load()
            self.coverInstance.start()

What do you think about this approach?

I love this approach, and had always been intending to connect the test runners so that they could tell us the context.  Not only do they know when the tests start, but with parametrized tests, they know things we can't know (the data used for the test).
I'd want to see a real pytest plugin that uses this before I felt like it really worked.
Also, we'll now have three different ways that context can be started (built-in test_function, context plugins, and test runners calling this method).  I can't quite wrap my head around how they will all intereract, or even quite how to explain it! :)

Thanks, this works well, and usual, thanks especially for the attention to tests.


[$250] Expense - Unapprove system message changes format after unapproving a scanning expense

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.45-2
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Issue reported by: Applause Internal Team
Action Performed:
Precondition:

Add approvals feature is enabled in Workflows.

Submit a scan expense.
While the receipt is scanning, go to expense report.
Click Approve.
Click on the report header.
Click Unapprove while the receipt is still scanning.
Note that the unapprove system message is "unapproved x".
Refresh the page.

Expected Result:
The unapprove system message should remain "unapproved x".
Actual Result:
The unapprove system message changes to
You
unapproved this report
This issue only happens when the expense is a scan expense and the receipt is scanning.
Workaround:
Unknown
Platforms:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos

https://github.com/user-attachments/assets/7aad5489-a754-43c2-a8e6-c2254e24d09f

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~021843641880485944632
Upwork Job ID:<PHONE_NUMBER>485944632
Last Price Increase: 2024-10-08

Issue OwnerCurrent Issue Owner: @rojiphil

We think that this bug might be related to #wave-collect - Release 1

@bfitzexpensify  FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

Proposal
Please re-state the problem that we are trying to solve in this issue.
The unapprove system message changes to
You
unapproved this report
What is the root cause of that problem?

We don't have logic to handle UNAPPROVED system message.

What changes do you think we should make in order to solve the problem?

Add a UNAPPROVED else if in this:

 } else if (ReportActionsUtils.isActionOfType(action, CONST.REPORT.ACTIONS.TYPE.UNAPPROVED)) {
            const amount = ReportActionsUtils.getOriginalMessage(action)?.amount;
            const currency = ReportActionsUtils.getOriginalMessage(action)?.currency;
            children = <ReportActionItemBasicMessage message={`Unapproved ${CurrencyUtils.convertToDisplayString(amount, currency)}`} />;

The same logic should be applied when displaying message in LHN, copy message, report title, ...

What alternative solutions did you explore? (Optional)

This issue is fixed in this PR.
Let's close this @bfitzexpensify
https://github.com/user-attachments/assets/12825e4e-dd68-4b59-9c67-815e1b241794


how to run /testing/k8s-binder-k8s-hub using k8s

Bug description
how to run /testing/k8s-binder-k8s-hub using k8s？I am a beginner and I sincerely need help.

https://github.com/jupyterhub/binderhub/tree/main/testing/k8s-binder-k8s-hub is mostly for our GitHub CI https://github.com/jupyterhub/binderhub/blob/main/.github/workflows/test.yml
If you just want to install BinderHub please see https://binderhub.readthedocs.io/en/latest/zero-to-binderhub/index.html


⚠ Bofrost.lu has degraded performance

In 415979a, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1288 ms

Resolved: Bofrost.lu performance has improved in 41a74bc after 6 minutes.


Custom module loading on same url depending on user login

How can I load a module depending on a user column like "town"?
For example, I have authenticated users and multiple similar modules. The users have a database param.  called "town":

if town is empty and user requests "real-estate/", the called module is "Modules/Realestate"
if town is "Chelsea" and user requests "real-estate/", the called module is "Modules/RealestateChelsea"
if town is "London" and user requests "real-estate/", the called module is "Modules/RealestateLondon"

Thanks!

This is now possible as all modules are loaded by default.
In the future however, when the module status is stored in database, this might be a possible use case for it.

I want something like this:
$town = Auth::user()->town;
if ($town == 'Chelsea' && Module::has('Realestate'.$town))
{
//load module
}
Can you give me a example? Thank you.

I can't. In my previous message, you can see I explained how this isn't possible.
Up to you, however, to wrap logic around the modules to make it work for your project.


Request for mkey usage in examples

I am using the following tasks to configure snmp communities on a virtual fortigate appliance:
---
- name: Get community
  connection: local
  fortiosconfig:
    https: False
    action: "get"
    host:  "{{ fw_vars['ip'] }}"
    username: "{{ fw_username }}"
    password: "{{ fw_password }}"
    config: "system.snmp community"
    https: False
  register: config

- debug:
    var: config

- name: Edit community 1
  connection: local
  fortiosconfig:
    https: False
    action: "set"
    host:  "{{ fw_vars['ip'] }}"
    username: "{{ fw_username }}"
    password: "{{ fw_password }}"
    config: "system.snmp community"
    https: False
    mkey: 1
    config_parameters:
      name: "{{ fw_vars['ans_snmp_ro'] }}"

I have manually created two entries in the snmp community table. On the appliance side of things I can see the following:
config system snmp community
    edit 1
        set name "test"
    next
    edit 2
        set name "number 2"
    next
end

And from the Ansible debug statement I see:
ok: [localhost] => {
    "config": {
        "changed": false,
        "failed": false,
        "meta": {
            "results": [
                {
                    "events": "cpu-high mem-low log-full intf-ip vpn-tun-up vpn-tun-down ha-switch ha-hb-failure ips-signature ips-anomaly av-virus av-oversize av-pattern av-fragmented fm-if-change bgp-established bgp-backward-transition ha-member-up ha-member-down ent-conf-change av-conserve av-bypass av-oversize-passed av-oversize-blocked ips-pkg-update ips-fail-open faz-disconnect wc-ap-up wc-ap-down fswctl-session-up fswctl-session-down load-balance-real-server-down per-cpu-high",
                    "hosts": [],
                    "hosts6": [],
                    "id": 1,
                    "name": "test",
                    "q_origin_key": 1,
                    "query-v1-port": 161,
                    "query-v1-status": "enable",
                    "query-v2c-port": 161,
                    "query-v2c-status": "enable",
                    "status": "enable",
                    "trap-v1-lport": 162,
                    "trap-v1-rport": 162,
                    "trap-v1-status": "enable",
                    "trap-v2c-lport": 162,
                    "trap-v2c-rport": 162,
                    "trap-v2c-status": "enable"
                },
                {
                    "events": "cpu-high mem-low log-full intf-ip vpn-tun-up vpn-tun-down ha-switch ha-hb-failure ips-signature ips-anomaly av-virus av-oversize av-pattern av-fragmented fm-if-change bgp-established bgp-backward-transition ha-member-up ha-member-down ent-conf-change av-conserve av-bypass av-oversize-passed av-oversize-blocked ips-pkg-update ips-fail-open faz-disconnect wc-ap-up wc-ap-down fswctl-session-up fswctl-session-down load-balance-real-server-down per-cpu-high",
                    "hosts": [],
                    "hosts6": [],
                    "id": 2,
                    "name": "number 2",
                    "q_origin_key": 2,
                    "query-v1-port": 161,
                    "query-v1-status": "enable",
                    "query-v2c-port": 161,
                    "query-v2c-status": "enable",
                    "status": "enable",
                    "trap-v1-lport": 162,
                    "trap-v1-rport": 162,
                    "trap-v1-status": "enable",
                    "trap-v2c-lport": 162,
                    "trap-v2c-rport": 162,
                    "trap-v2c-status": "enable"
                }
            ],
            "status": "success",
            "version": "v6.0.3"
        }
    }
}

I would ideally like to edit one of the entries and based on fortios api reference doc I read, I figured that specifying the mkey would be the same as referencing the id. Here I'm trying to change the name of the first entry from "test" to the variable fw_vars['ans_snmp_ro'] however I get the following error on the Edit Community 1 task:
File \"/usr/local/lib/python2.7/dist-packages/fortiosapi/fortiosapi.py\", line 440, in set\n    mkey = self.get_mkey(path, name, data, vdom=vdom)\n  File \"/usr/local/lib/python2.7/dist-packages/fortiosapi/fortiosapi.py\", line 259, in get_mkey\n    LOG.warning(\"mkey %s not set in the data\", mkey)\nUnboundLocalError: local variable 'mkey' referenced before assignment\n"
However, when I do not try to use the mkey and instead add the line id: 1 under the config_parameters section the module does what I expect it to (change the name of the entry).
I'm not sure what the mkey value is functionally used for. I tried looking through the examples but I do not see any that use that parameter. If someone could add an example on how to use that parameter that would probably clear up my confusion on what it actually does. Thanks!

Hi @Shasties ,
thanks for your comment and sorry for the late reply. The mkey is normally used internally in some methods, to guess the master key of the table being updated without requiring user intervention. Thus, you shouldn't worry about it.
I see anyway that it is still present as input parameter in 'choice_map' and this seems to be a leftover from old modifications. I'll create a PR in the next days to remove it.
Thanks!

Since this has no more activity and the issue is solved I'm closing it.


play button is not properly align

Description
play button of all the games is not visible.
Screenshots
No response
Additional information
No response

Hi @anuza08 , I am assigning this issue to you. Kindly complete your work within a week. Good luck for your work!


EnsuringDiagnosticsHandlers uses weak references for non-trivial refs

Description
CosmosDiagnosticsHandler instances can be referenced by applications indirectly - via CosmosClientConfig - this is needed for example for dynamic reconfiguration. This can lead to unnecessary memory pressure when the application closes (and reopens) clients - but keeps references to the ClientTelemetryConfig instances. This would result in strong references from the diagnostics handlers to CosmosAsyncClient (and due to this netty connection pool buffers etc.). By switching the weak references in this PR the GC can clean-up the CosmsoAsyncClient and netty resources sooner.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

/azp run java - cosmos - tests

/azp run java - cosmos - spark

/azp run java - cosmos - tests

/azp run java - cosmos - spark

/azp run java - cosmos - spark

/azp run java - cosmos - spark

/azp run java - cosmos - spark

/azp run java - cosmos - tests


Advanced Hunter Trick feat-no dropdown bonus feat

The Advanced Hunter Trick feat is not creating a slot below it to put what ranger feat you take with it,  like the basic one does

Duplicate of #1956
This is a known limitation of the system currently.


Ranaming randint to uniform_discrete or discrete_uniform

While randint may be well known from numpy, this is absolutely not a known mathematical name. What do you think about renaming it, keeping randint as an alias?

stats.randint is still there, but there's nothing wrong with it and renaming doesn't necessarily help. so closing


Gap between status bar and top bar in Chrome custom tabs in tablet mode

Describe the bug
In tablet mode, the top bar for Chrome custom tabs is not right below the status bar but moved down by some amount which looks bad and also blocks page elements
To Reproduce

Set smallest width ≥600dp which should activate tablet mode in kiwi
Open any Chrome custom tab

Expected behavior
Top bar is right below status bar
Screenshots

Smartphone (please complete the following information):

Device: Poco F3
Android Version: A11
Kiwi Browser Version: 93.0.4577.52

Additional context
Might be related to #265

Also, is there a way to get rid of the share button at the bottom?

Tablet mode used there is a workaround , instead it should be related to #146


Update README.md

Sigh, google-api-client doesn't work with Python 3.4.

@lesv can you take a look?

PTAL


Added PhpLint task

Closes #7

Coverage remained the same at 100.0% when pulling 40190a88fafbf6075273e11931b75d7e1fc68666 on ricardogobbosouza:task-phplint into 84c3f6607ffb33ecea9c849c05c2461503b7304b on cknow:master.

Coverage remained the same at 100.0% when pulling b35c1f0306ca35eaab09765e4746b4c5c0eea0e2 on ricardogobbosouza:task-phplint into 84c3f6607ffb33ecea9c849c05c2461503b7304b on cknow:master.

Coverage remained the same at 100.0% when pulling 8e4133b287515a6bd4211040132dcc42c017ee07 on ricardogobbosouza:task-phplint into 84c3f6607ffb33ecea9c849c05c2461503b7304b on cknow:master.


Stdin/stdout communication with flow server

It will be grate to send files (override disk content) directly to server.

We get this feature request often, especially from those working on editors. For now there is flow check-contents using which you can send over arbitrary contents (but those contents are only checked, not persisted in any way, by the server). From the help:
Usage: flow check-contents [OPTION]... [FILE]

Runs a flow check on the contents of stdin. If FILE is provided, then
check-contents pretends that the contents of stdin come from FILE

e.g. flow check-contents < foo.js
or   flow check-contents foo.js < foo.js

Just to clarify you understand our request correctly: our editor can have several unsaved files simultaneously, and to perform check, we have to send all unsaved files content to server. Currently, we can send only one.

You can now communicate with the Flow server with LSP protocol. However, we are unlikely to support any other protocols.


Rename Ubuntu2204-Readme.md to Ubuntu-wikivu

İş akışı çatalı
Description
New tool, Bug fixing, or Improvement?
Please include a summary of the change and which issue is fixed. Also include relevant motivation and context.
For new tools, please provide total size and installation time.

Related issue:
Check list

[x] Related issue / work item is attached
[x] Tests are written (if applicable)
[x] Documentation is updated (if applicable)
[x] Changes are tested and related VM images are successfully generated

İş akışı güncellemesi


Try using DiskANN

Milvus supports on-disk index https://milvus.io/docs/disk_index.md. This should reduce compute usage drastically.  DiskANN is enabled by default but I think we need to make sure the volume inside the container is mounted at /var/lib/milvus/data
I think we'll want to add a non-boot persistent disk to the cluster and then have k8s mount that to the query nodes and index nodes. We'll need to use DISKANN as the index type while building the index.
@leothomas Once you have the index update done #54, let's figure out a plan here. Might be good to create a second indexing script/job that can create the DiskANN index that has a volume mounted.
I should be able to quickly adjust the k8s configuration to support this and get some help @sunu too.

@geohacker from a quick look, it doesn't look like the Milvus Helm chart supports mounting a persistent disk to /var/lib/milvus/data like you mentioned. It's mounting an emptyDir there.
Is it possible that the volume is only used to build a local cache of the index and the actual index is stored somewhere else (eg on Minio blob storage for example)?

@sunu Oh I'm not sure if I'm reading this right but this looks exactly like what we want https://github.com/zilliztech/milvus-helm/blob/master/charts/milvus/templates/indexnode-deployment.yaml#L137-L139. What do you think?

@geohacker yes, we do get a volume at the right path but the volume is an ephemeral volume on the boot disk since it uses emptyDir. I talked a bit about this with @leothomas yesterday and we decided we will give it a try and see if we run into any issues. Leo will also ask for clarification about this on the Milvus discord. Our guess is that Milvus stores the actual index on Minio blob storage and the on-disk index volume on index nodes and query nodes are only used for maintaining a local cache of that index. So it's fine for that volume to be ephemeral.
I have deployed the stack back with enableDisk set to true without tweaking any other resource limits etc.

Alright! We've run a successful test with the DiskANN index, and here's the TL;DR: while it works, it doesn't necessary offer the advantages we were hoping for. Namely Milvus's DiskANN implementation contains an un-avoidable product quantization step. @sdenton4 my understanding was that you wanted to avoid any additional compression on the embeddings, which would the make the DiskANN a no-go. Should we continue exploring this indexing strategy? Do you want to explore strategies that would have the model spit out embeddings with fewer dimensions? (And possibly spit out integer  [0:255] values, rather than float, which reduces the byte count by a factor of 4)
The long form:
I started with noticing that the switch to the DiskANN was making the kubernetes index node crash and restart due to hitting CPU limits:

Bumping that limit got us past the crashing and up and running with DiskANN index successfully. I didn't get a chance to test too extensively, but the queries seemed to execute comparably quickly (difficult to compare since I ingested a subset of the data, to verify that the DiskANN index was correctly configured):

(Notice the disk memory usage bumping up from 0 to ~4Gb once the data it loaded into the DiskANN index)
However when I checked a couple days later, I found the index node crashing and restarting again.

I think this was due to the fact that setting the limit but not the requested CPU to 10 gave us some extra burst capacity to use, and when that burst capacity ran out the node started crashing whenever we hit the requested CPU
Looking deeper into the node logs as to why we were using some much CPU when the index was starting up, I noticed this line in the logs:

Which seems to indicate the fact that the DiskANN index requires all that CPU to perform a Product Quantization operation on the 512 dimension embeddings (compressing them from 16384 bytes/vector (512 dims * 32 bytes/float) to 256 bytes/vector).
Since the whole point of using DiskANN was to avoid having to compress or otherwise reduce the embeddings, I posted in the Milvus Discord channel to see if this could somehow be avoided. The response was essentially no, that's how Milvus impelments a DiskANN index. Response:

DISKINDEX is a combine of PQ and Vamana graph index. PQ index is loaded into memory and Vamana graph on disk. When you call search(), it first searches in PQ, then finds some candidates to search again in the Vamana graph on disk. Product quantization step cannot be avoided. If you read the doc for DISKINDEX, you will see some parameters indicate it uses product quantization:

PQCodeBugetGBRatio ---------------- Size limit on the PQ code. A larger value offers a higher recall rate but increases memory usage.

https://milvus.io/docs/disk_index.md#On-disk-Index

Product quantization makes sense; I think it's the PCA that we want to avoid. So this still seems OK to me!

Hey there @sdenton4! Got an update for you:
TL;DR:
The good:
We have ~3.5 million records, from 30 of the 512 embedding files (out of ~3.7k total files) loaded into Milvus using the DiskANN index. The search is performant, but not quite as performant as the current IVF index (~0.1 seconds for ~100 results and  ~7 seconds for 1000 results and 250 seconds for the max result size of 16384). I haven't verified the quality of the index result, since there's no way to do a flat search, but I'm confident the implementation is sound, based on the performance of the other indexes. (I can put together a notebook if we want to evaluate the quality of the DiskANN index results, if needed)
The bad:
In order to search on a collection it has to be loaded into memory, which is proving to be incredibly slow, past ~1.5 million records. With the current ~3.5 million records we're looking at almost 1 hour load time!
I've started a thread in Discord to try to understand why it takes so long to load the collection, especially since the whole point of the on-disk index is that it shouldn't have to be loaded into memory.
There are no errors in the logs, however one clue (that I've shared in the Milvus discord channel) that might point to a bug in Milvus is:
[2024/02/15 20:32:11.583 +00:00] [INFO] [querynode/segment_loader.go:301] ["loading delta..."] [segmentID=447713668967530627]
[2024/02/15 20:32:11.583 +00:00] [INFO] [querynode/segment_loader.go:526] ["there are no delta logs saved with segment, skip loading delete record"] [segmentID=447713668967530627]

Which occurs when loading each segment, and seems to imply that the segment is not sealed. (Context: when loading data into Milvus, the data gets partitioned into segments, with a pre-determined max size. When the segment reaches this size, it gets "sealed" and indexed. This way new data can be searchable as soon as the segment is sealed, even if more data is still being loaded).
Logically, if the segments aren't being sealed, then they're not being indexed, which could be why they're being loaded into memory (rather than searched from disk).
The Milvus devs followed up in Discord, with a rather unhelpful/generic message outlining the memory requirements, rather than addressing the question of why the index segments have to be loaded into memory if were using an on-disk index. They did mention that the unsealed segments might be segments that are simply still in the process of indexing (after the ingestion). I tried releasing the collection and re-loading in this morning, and, while the logs messages indicating the segments hadn't been sealed are no longer showing up in the logs, the collection is still takes >1hr to load.
Going forward, we have a few different options:

We can continue to try work with the DiskANN index, exploring different configurations, memory allocations, partitioning schemes, etc.
We can pivot back to an HNSW or IVF index for performance, and look into an index which includes product quantization in order to reduce the memory requirements of the database (@sdenton4 you had mentioned that production quantization is not a problem, since, unlike PCA, it doesn't drop any dimensions - is that correct?)
We can leave the backend as is (loaded with 1% data sample and DiskANN index) and update the API to remove the PCA transform of input/search vectors, and revisit later.
We can look into pivoting to a different vector database options - we've had some promising results with pgvector at a similar scale (250million records), but there is a huge proliferation of other options we can look at: Pinecone, Weviate, Astra, Vespa, Qdrant, Redis, ElasticsSearch, Cassandra, MyScaleDB, LanceDB, Marqo, etc)

(Note on partitioning: partitioning essentially creates sub-datasets that we can ingest data into and search separately. This is useful for data which is often filtered at search time such as searching for either a TV show or a movie on Netflix. In this case we would create two partitions, and only search one or the other. Datasets where users often want to search across filters, such as literature genres, would not be a good candidate)

Happy to hop on call to chat about this further next week @sdenton4

Thanks for looking into this, Leo!

Yes, product quantization should be fine - it's the PCA we would like to factor out with the 512-dim'l embeddings.

The Milvus+DiskANN does sound like a pain - sounds a bit like they built their system with an in-memory assumption and are behaving strangely when confronted with a new world... I'll try looking around a bit and seeing what else is out there.

The main reason we are getting 16k results right now is so that we can filter down, eg by geography. If we had a system which included metadata in the search itself, a shorter result list would be just fine.


The content is wrong

I can change the redundancy options of  storage account from ZRS to GZRS via Portal.
So i think the following content(Yellow) is wrong. Please check it.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 66ebb48e-c896-a747-bc42-aa203978a1cd
Version Independent ID: 6e7bfefb-e67c-b5d5-89f7-6f1b6a2e8b61
Content: Change how a storage account is replicated - Azure Storage
Content Source: articles/storage/common/redundancy-migration.md
Service: storage
Sub-service: common
GitHub Login: @tamram
Microsoft Alias: tamram

@shendan19880215 Thanks for the question! We are investigating and will update you shortly.

@shendan19880215, thank you for bringing this to our attention. Was this account a BLOB or ADLS Gen2 account? If it is a Blob account, was the account originally a GZRS account that you are trying to failback?

@shendan19880215 Article has been updated! We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.