On Tue, Jan 23, 2018 at 08:12:49PM +0300, Denis wrote:
> Running namecoind 13.2 for about two years. OpenBSD 6.1amd64 is the last
> version which supports it.
>
> On 6.2 I stuck with malloc() hardening. With no any malloc.conf options
> I have these errors:
>
> namecoind (4563) malloc():bogus pointer (double free?) 0xdfdfdfdfdfdfdfdf
> namecoind (4563) free(): chunk is already free 0x1bc9981cae20
>
> I get a bit different error while set 'S' to malloc.conf
>
> ln -s 'S' /etc/malloc.conf
>
> namecoind (2501) in free(): chunk canary corrupted 0x1ad4b3e5b3b0
> 0x2@0x2 (double free?)
>
> Otto wrote that it means
>
> overwrite of a buffer and/or a double free
>
> Afterwards, I've searched on github.com for namecoin project using
> malloc keyword, seems nothing changed since 13.2 in malloc functionality.
>
> https://github.com/namecoin/namecoin-core/search?utf8=%E2%9C%93&q=malloc&type=
>
> In two Cpp files developers initially reserved additional memory for
> pointers plus allocation if I understand code right :
>
> src/txmempool.h
> <https://github.com/namecoin/namecoin-core/blob/60b5fb9339b5196b7c46e7fc04e6190560d3aff1/src/txmempool.h>
>
> Showing the top match Last indexed Jan 6, 2018
> return memusage::/Malloc/Usage(sizeof(CTransactionRef) + 6 *
> sizeof(void*)) * queuedTx.size() + cachedInnerUsage;
>
>
> src/txmempool.cpp
> <https://github.com/namecoin/namecoin-core/blob/60b5fb9339b5196b7c46e7fc04e6190560d3aff1/src/txmempool.cpp>
>
> Showing the top match Last indexed Jan 6, 2018
> // Estimate the overhead of mapTx to be 15 pointers + an allocation, as
> no exact formula for boost::multi_index_contained is implemented.
>
> return memusage::/Malloc/Usage(sizeof(CTxMemPoolEntry) + 15 *
> sizeof(void*)) * mapTx.size() + memusage::DynamicUsage(mapNextTx) +
> memusage::DynamicUsage(mapDeltas) + memusage::DynamicUsage(mapLinks) +
> memusage::DynamicUsage(vTxHashes) + cachedInnerUsage;
>
> Could somebody help to fix namecoin malloc() to latest malloc
> restrictions in OpenBSD 6.2 ?
Please don't crosspost.
The code above seems to only guess some memory usage statistics and
has little to do with actual memory management.
Any time new or delete is used in a C++ program, it will call malloc
or free so the error can be anywhere. A way to start debugging this is
to use gdb on the coredump generated when the malloc error is hit or
run the program from gdb. If gdb in base does not work properly you
might want to try egdb in ports.
-Otto
