m_logtrunc_truncate: Assertion `0 && "m_logtrunc_truncate no longer used"' failed.

[pramalhe]

Hello,
When we increase the 'arraySize' in rbench to 1 million we get an assert:
build/library/mcore/src/log/logtrunc.c:207: m_logtrunc_truncate: Assertion `0 && "m_logtrunc_truncate no longer used"' failed.
even though I increased the RW_SET_SIZE to 50000000 in library/configuration/default/mtm.py.

Is there some other hard-coded limitation?

We typically test data structures with 1M keys (it's not really that much nowadays). Without figuring out what is the limit here we won't be able to do that.

Here is the stack trace:

#0 0x00007ffff59b9c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff59bd028 in __GI_abort () at abort.c:89
#2 0x00007ffff59b2bf6 in __assert_fail_base (fmt=0x7ffff5b07018 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x7ffff6db38f0 "0 && "m_logtrunc_truncate no longer used"",
file=file@entry=0x7ffff6db3820 "build/library/mcore/src/log/logtrunc.c", line=line@entry=207,
function=function@entry=0x7ffff6db3930 <PRETTY_FUNCTION.6304> "m_logtrunc_truncate") at assert.c:92
#3 0x00007ffff59b2ca2 in __GI___assert_fail (assertion=0x7ffff6db38f0 "0 && "m_logtrunc_truncate no longer used"",
file=0x7ffff6db3820 "build/library/mcore/src/log/logtrunc.c", line=207, function=0x7ffff6db3930 <PRETTY_FUNCTION.6304> "m_logtrunc_truncate")
at assert.c:101
#4 0x00007ffff6db1c7f in m_logtrunc_truncate (set=0x620a00) at build/library/mcore/src/log/logtrunc.c:207
#5 0x00007ffff73cabd8 in m_tmlog_base_write (set=0x620a00, tmlog=0x624940, addr=17593335974368, val=0, mask=18446744073709551615)
at library/mtm/include/mode/pwb-common/tmlog_base.h:74
#6 0x00007ffff73cb25a in insert_write_set_entry_after (new_entry=0x7ffefe70de10, tail=0x7ffefe70dd90, transaction=0x631fb0,
cache_neighbor=0x7ffefe70dd90) at build/library/mtm/include/mode/pwb-common/barrier-bits.h:194
#7 0x00007ffff73cb878 in pwb_write_internal (tx=0x631fb0, addr=0x1000448a89e0, value=0, mask=18446744073709551615, enable_isolation=1)
at build/library/mtm/include/mode/pwb-common/barrier-bits.h:467
#8 0x00007ffff73cbfc2 in mtm_pwbetl_store (tx=0x631fb0, addr=0x1000448a89e0, value=0) at build/library/mtm/src/mode/pwbetl/barrier.c:49
#9 0x00007ffff73cc24e in mtm_pwbetl_store_bytes (tx=0x631fb0, addr=0x1000448a89e0 "", buf=0x7fffffffe0c0 "", size=8)
at build/library/mtm/src/mode/pwbetl/barrier.c:73
#10 0x00007ffff73cd1e5 in _ITM_WU8 (addr=0x1000448a89e0, value=0) at build/library/mtm/src/mode/pwbetl/barrier.c:76
#11 0x0000000000401f09 in transaction clone for WrapperM::WrapperM(long) (this=0x1000448a89e0, val=0)
at build/examples/rbench/BenchmarkPersistency.hpp:46
#12 0x0000000000401d16 in transaction clone for mnemosyne::Mnemosyne::alloc<WrapperM, int>(int&&) (this=0x7fffffffe2d3)
at build/examples/rbench/Mnemosyne.hpp:103
#13 0x0000000000401f8f in transaction clone for PersistentArraymnemosyne::Mnemosyne::PersistentArray(mnemosyne::Mnemosyne&) (this=0x100043fc9000,
pe=...) at build/examples/rbench/BenchmarkPersistency.hpp:55
#14 0x0000000000401e98 in transaction clone for mnemosyne::Mnemosyne::alloc<PersistentArraymnemosyne::Mnemosyne, mnemosyne::Mnemosyne&>(mnemosyne::Mnemosyn
e&) (this=0x7fffffffe2d3) at build/examples/rbench/Mnemosyne.hpp:103
---Type to continue, or q to quit---
#15 0x0000000000401be0 in transaction clone for long long BenchmarkPersistency::arrayBenchmark_rw<mnemosyne::Mnemosyne, WrapperM>(std::chrono::duration<long,
std::ratio<1l, 1l> >, long, int)::{lambda()#1}::operator()() const (__closure=0x7fffffffe370) at build/examples/rbench/BenchmarkPersistency.hpp:283
#16 0x0000000000403f43 in mnemosyne::Mnemosyne::write_transaction<long long BenchmarkPersistency::arrayBenchmark_rw<mnemosyne::Mnemosyne, WrapperM>(std::chro
no::duration<long, std::ratio<1l, 1l> >, long, int)::{lambda()#1}>(long long BenchmarkPersistency::arrayBenchmark_rw<mnemosyne::Mnemosyne, WrapperM>(std::chr
ono::duration<long, std::ratio<1l, 1l> >, long, int)::{lambda()#1}&&) (this=0x7fffffffe2d3,
func=<unknown type in /home/vagrant/mnemosyne-gcc/usermode/build/examples/rbench/rbench, CU 0x0, DIE 0x17a37>)
at build/examples/rbench/Mnemosyne.hpp:73
#17 0x00000000004033ed in BenchmarkPersistency::arrayBenchmark_rw<mnemosyne::Mnemosyne, WrapperM> (this=0x7fffffffe3f8, testLengthSeconds=...,
numWordsPerTransaction=256, numRuns=1) at build/examples/rbench/BenchmarkPersistency.hpp:280
#18 0x000000000040272c in BenchmarkPersistency::allThroughputTests () at build/examples/rbench/BenchmarkPersistency.hpp:509
#19 0x00000000004016ac in main (argc=1, argv=0x7fffffffe5b8) at build/examples/rbench/rbench.cpp:14
(gdb)

[hvolos]

Well, this one took me a while to even remember what is going on. I have no recollection when we introduced this assertion, but I think it is right. What is going on is that it runs out of persistent log space as synchronous log truncation cannot happen until the transaction commits, so it triggers this cryptic assertion check. The RW_SET_SIZE variable controls the volatile write-set lookaside buffer in the TM runtime. You can try to increase the size of the persistent log by changing the number of entries PHYSICAL_LOG_NUM_ENTRIES_LOG2 in usermode/library/mcore/include/log/log_i.h
Note this is base 2 logarithm, so the actual number of entries is 2^PHYSICAL_LOG_NUM_ENTRIES_LOG2
Hope this helps. I know, code maintenance is long due.

[pramalhe]

Humm increasing PHYSICAL_LOG_NUM_ENTRIES_LOG2 causes issues somewhere else. I guess there isn't enough memory for everything ;)
I'll take it as a limitation of the library. We got to 10k keys in our data structures, that's enough for now.
I'll close the issue.

Thanks for the help!

[hvolos]

Right, after taking another look, there is another macro variable LOG_POOL_SIZE that limits the size of the log pool. This is defined in library/mcore/include/pregionlayout.h. You could try to change that as well, but I don't know what else might break. It's been nearly five years since the last time I touched this code, so I don't have a good recollection. One thing is for sure, all these variables should be defined in a single place, and ideally be configurable at runtime. I am opening a new issue (#20) to improve parameter configuration, but I don't know when I will get the chance to actually do it.