possible memory leak with dash-qt 19.1.0

lano1106 commented 1 year ago

not sure what is the expected memory blueprint for a node but my system ran out of memory this morning and it did make crash another memory-hungry app on my system... (Another qt app... Call stack clearly indicates system memory exhaustion)

#0  0x00007f207347684f in QVector<QPointF>::realloc (this=0x7ffc04d524d0, aalloc=<optimized out>, options=...) at /usr/include/qt/QtCore/qvector.h:716
716                     while (srcBegin != srcEnd)
[Current thread is 1 (Thread 0x7f2070050880 (LWP 3183679))]
(gdb) where
#0  0x00007f207347684f in QVector<QPointF>::realloc(int, QFlags<QArrayData::AllocationOption>) (this=0x7ffc04d524d0, aalloc=<optimized out>, options=...)
    at /usr/include/qt/QtCore/qvector.h:716
#1  0x00007f207348dbfa in QVector<QPointF>::detach() (this=0x7ffc04d524d0) at /usr/include/qt/QtCore/qvector.h:405
#2  QVector<QPointF>::end() (this=0x7ffc04d524d0, this=<optimized out>) at /usr/include/qt/QtCore/qvector.h:214
#3  QVector<QPointF>::last() (this=0x7ffc04d524d0) at /usr/include/qt/QtCore/qvector.h:245
#4  QVector<QPointF>::back() (this=0x7ffc04d524d0) at /usr/include/qt/QtCore/qvector.h:282

NOTE: This is not dash-qt call stack. It is my other app stumbling into the qt framework not making sure that malloc succeeds before using the returned pointer

Describe the issue

dash-qt is using an unusually big amount of memory

top output: 3273565 lano1106 20 0 12.1g 3.6g 625696 S 4.3 11.5 110:13.11 dash-qt

Maybe another important detail. CoinJoin is enabled and has been mixing coins for the last 1-2 days

What version of Dash Core are you using?

19.1.0 from the github tag

Some peculiarity about the build process.

I need to modify the ./Makefile and ./src/Makefile

with those small changes:

Edit Makefile and src/Makefile: setting LIBS = -lsodium

Edit Makefile and src/Makefile: Set BDB_LIBS = -ldb_cxx-5

Archlinux made db v6 available and dash is absolutely incompatible with this version local/db 6.2.32-1 The Berkeley DB embedded database system local/db5.3 5.3.28-2 The Berkeley DB embedded database system v5.3

concerning sodium, without specifying it, the linker tries to link with the static lib or does not link with it at all and linking fails

on ArchLinux zero static libs are distributed. It has only shared libraries

local/libsodium 1.0.18-2 P(ortable|ackageable) NaCl-based crypto library

finally, I am not sure if this is another build system glitch but it links with the version specific of boost libs which forces a rebuild each time boost is upgraded... I could not find where this is configured but maybe using the generic boost libs symbolic links could remove this annoyance...

Machine specs:

OS: ArchLinux, kernel 6.2.10
RAM: 32GB

PastaPastaPasta commented 1 year ago

Definitely concerns me about your weird build system stuff. Have you tried building with the depends system? https://github.com/dashpay/dash/blob/master/doc/build-generic.md#building-dependencies

lano1106 commented 1 year ago

Hi,

no, I am not sure what the depends system is. I'll take a look at it. My build is based on community PKGFILE that AFAIK, has lost its maintainer. It still works fine by simply updating the package version and checksums + the described required minor manual tweaks...

https://aur.archlinux.org/packages/dashcore

build() {
  CFLAGS+=" -fPIC"
  CXXFLAGS+=" -fPIC"
  cd "$_pkgname-$pkgver"
  CPPFLAGS="${CPPFLAGS} -I$PWD/depends/built/$CARCH-pc-linux-gnu/include"
  LDFLAGS="${LDFLAGS} -L${PWD}/depends/built/$CARCH-pc-linux-gnu/lib -L${PWD}/depends/built/$CARCH-pc-linux-gnu/lib64"
  ZMQ_LIBS="-lzmq -lsodium"
  ./autogen.sh
  ./configure --prefix=`pwd`/depends/$CARCH-pc-linux-gnu --with-incompatible-bdb --with-gui=qt5 --disable-zmq
  make
}

dashpay / dash