Core Dumped about karbowanec HOT 11 CLOSED

Here is part of valgrind output:

==6038==

valgrind: m_mallocfree.c:307 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.
valgrind: Heap block lo/hi size mismatch: lo = 46656, hi = 10845964556480854131.
This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata. If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away. Please try that before reporting this as a bug.

host stacktrace:
==6038== at 0x58095D7A: show_sched_status_wrk (m_libcassert.c:355)
==6038== by 0x58095E84: report_and_quit (m_libcassert.c:426)
==6038== by 0x58096011: vgPlain_assert_fail (m_libcassert.c:492)
==6038== by 0x580A4351: get_bszB_as_is (m_mallocfree.c:305)
==6038== by 0x580A4351: get_bszB (m_mallocfree.c:315)
==6038== by 0x580A4351: mergeWithFreeNeighbours (m_mallocfree.c:2061)
==6038== by 0x58053603: release_oldest_block (mc_malloc_wrappers.c:169)
==6038== by 0x58053603: create_MC_Chunk (mc_malloc_wrappers.c:212)
==6038== by 0x580544EE: vgMemCheck_new_block (mc_malloc_wrappers.c:388)
==6038== by 0x580544EE: vgMemCheck___builtin_new (mc_malloc_wrappers.c:417)
==6038== by 0x580FCE3E: do_client_request (scheduler.c:1921)
==6038== by 0x580FCE3E: vgPlain_scheduler (scheduler.c:1488)
==6038== by 0x5810DC96: thread_wrapper (syswrap-linux.c:103)
==6038== by 0x5810DC96: run_a_thread_NORETURN (syswrap-linux.c:156)

sched status:
running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 6038)
==6038== at 0x4C2E216: operator new(unsigned long) (vg_replace_malloc.c:334)
==6038== by 0x490A21: allocate (new_allocator.h:104)
==6038== by 0x490A21: allocate (alloc_traits.h:491)
==6038== by 0x490A21: _M_get_node (stl_tree.h:491)
==6038== by 0x490A21: _M_create_node<std::pair<long unsigned int, SwappedVectorCryptoNote::Blockchain::BlockEntry::ItemEntry> > (stl_tree.h:545)
==6038== by 0x490A21: operator()<std::pair<long unsigned int, SwappedVectorCryptoNote::Blockchain::BlockEntry::ItemEntry> > (stl_tree.h:459)
==6038== by 0x490A21: M_insert<std::pair<long unsigned int, SwappedVectorCryptoNote::Blockchain::BlockEntry::ItemEntry>, std::_Rb_tree<long unsigned int, std::pair<long unsigned int const, SwappedVectorCryptoNote::Blockchain::BlockEntry::ItemEntry>, std::_Select1st<std::pair<long unsigned int const, SwappedVectorCryptoNote::Blockchain::BlockEntry::ItemEntry> >, std::less, std::allocator<std::pair<long unsigned int const, SwappedVectorCryptoNote::Blockchain::BlockEntry::ItemEntry> > >::_Alloc_node> (stl_tree.h:1509)
==6038== by 0x490A21: std::pair<std::_Rb_tree_iterator<std::pair<unsigned long const, SwappedVectorCryptoNote::Blockchain::BlockEntry::ItemEntry> >, bool> std::_Rb_tree<unsigned long, std::pair<unsigned long const, SwappedVectorCryptoNote::Blockchain::BlockEntry::ItemEntry>, std::_Select1st<std::pair<unsigned long const, SwappedVectorCryptoNote::Blockchain::BlockEntry::ItemEntry> >, std::less, std::allocator<std::pair<unsigned long const, SwappedVectorCryptoNote::Blockchain::BlockEntry::ItemEntry> > >::_M_insert_unique<std::pair<unsigned long, SwappedVectorCryptoNote::Blockchain::BlockEntry::ItemEntry> >(std::pair<unsigned long, SwappedVectorCryptoNote::Blockchain::BlockEntry::ItemEntry>&&) (stl_tree.h:1870)
==6038== by 0x4911D1: insert<std::pair<long unsigned int, SwappedVectorCryptoNote::Blockchain::BlockEntry::ItemEntry>, void> (stl_map.h:621)
==6038== by 0x4911D1: SwappedVectorCryptoNote::Blockchain::BlockEntry::prepare(unsigned long) (SwappedVector.h:404)
==6038== by 0x491F25: SwappedVectorCryptoNote::Blockchain::BlockEntry::operator[](unsigned long) (SwappedVector.h:300)
==6038== by 0x4BB0B3: transactionByIndex (Blockchain.cpp:1819)
==6038== by 0x4BB0B3: scanOutputKeysForIndexes<CryptoNote::Blockchain::check_tx_input(const CryptoNote::KeyInput&, const Crypto::Hash&, const std::vectorCrypto::Signature&, uint32_t*)::outputs_visitor> (Blockchain.h:364)
==6038== by 0x4BB0B3: CryptoNote::Blockchain::check_tx_input(CryptoNote::KeyInput const&, Crypto::Hash const&, std::vector<Crypto::Signature, std::allocatorCrypto::Signature > const&, unsigned int*) (Blockchain.cpp:1634)
==6038== by 0x4BB9FF: CryptoNote::Blockchain::checkTransactionInputs(CryptoNote::Transaction const&, Crypto::Hash const&, unsigned int*) (Blockchain.cpp:1552)
==6038== by 0x4BBDEB: checkTransactionInputs (Blockchain.cpp:1530)

from karbowanec.

We believe we may be facing an enemy attack from Niobio
niobiod.log
, this can affect Karbowanec, follow the daemon's log.

from karbowanec.

Could it be due to different versions?

from karbowanec.

We found a memory leak on Swapped Vector that in some cases causes the daemon to crash. It seems this problem has been exploited on our network by sending a transaction with very high mixin (701).
We made a workaround for it until we have a definitive solution, fixing the cache management of Swapped Vector and limiting the value of mixin.
The workaround can be found here
https://github.com/raphaelpereira/niobio-node-daemon/commits/master

from karbowanec.

from karbowanec.

Thanks for an explanation, that is really interesting. Big mixin itself is not a problem when tx size is within limits.

from karbowanec.

Was it 32 bit system or 64 bit that crashed?

from karbowanec.

crashed at the same time in all pools, all of them were LINUX 64 Bits, maybe it could also be transactions with a very high number of IMPUTS.

http://explorer.niobiocash.com/en/?hash=AAB2019A0D663EB1D518FF419A5499C3D63A3E6B95A5D91E097B4B63B5370CC6#blockchain_transaction

from karbowanec.

Our devs are telling me that's not a mem leak, that's heap corruption

from karbowanec.

Sorry to hijack your issue's page. You can close this issue as you don't really have it :)
I would like to thank you for your kind help and let the reference to our (for now in testing) fix, it may be useful in future.
https://github.com/niobio-cash/niobio-node-daemon/tree/fixIssue14
Any comments on the code fix would be appreciated!
https://github.com/niobio-cash/niobio-node-daemon/issues/14

from karbowanec.

No problem, we will try to investigate and probably will implement your fix just in case.

from karbowanec.