Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sometimes dash-qt crashes #1519

Closed
mr-tron opened this issue Jul 11, 2017 · 6 comments
Closed

sometimes dash-qt crashes #1519

mr-tron opened this issue Jul 11, 2017 · 6 comments

Comments

@mr-tron
Copy link

mr-tron commented Jul 11, 2017

dash-qt: /home/ubuntu/build/dash/depends/i686-pc-linux-gnu/share/../include/boost/thread/pthread/recursive_mutex.hpp:113: void boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.

always during mixing via tor proxy.

@tgflynn
Copy link

tgflynn commented Jul 12, 2017

What version of Ubuntu are you running (lsb_release -a) ?

Also did you build dash-qt yourself or use the official binary ?

@mr-tron
Copy link
Author

mr-tron commented Jul 12, 2017

I running whonix (binary it`s debian 8 jessie with some special configs).
i686 arch
last official release 0.12.1.5 binary from dash.org
Dash QT crashes 2-3 times every day.

@tkanerva
Copy link

tkanerva commented Aug 11, 2017

I am also seeing most likely the same issue. Crashes are always related to Darksend (ie. coin mixing).

Debian/8.9 here (jessie), with libboost-1.55 from .debs. Compiled with --with-incompatible-bdb, and with debug symbols. Host is x86_64 kvm-based vps but this happens even on bare metal (tested).

I managed to get a stack trace by attaching gdb to the dashd process. By looking at the trace and the source code, it makes me think some pointers are getting corrupted somewhere.

(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7efd977fe700 (LWP 3461)]
__pthread_mutex_trylock (mutex=0x1f0) at ../nptl/pthread_mutex_trylock.c:43
43 ../nptl/pthread_mutex_trylock.c: No such file or directory.
(gdb) bt
#0 __pthread_mutex_trylock (mutex=0x1f0) at ../nptl/pthread_mutex_trylock.c:43
#1 0x0000000000721096 in try_lock (this=0x1f0) at /usr/include/boost/thread/pthread/recursive_mutex.hpp:120
#2 try_lock (this=0x1f0) at sync.h:70
#3 try_lock (this=) at /usr/include/boost/thread/lock_types.hpp:361
#4 TryEnter (pszName=, pszFile=, nLine=, this=) at sync.h:125
#5 CMutexLock (fTry=true, nLine=486, pszFile=0x92d748 "darksend.cpp", pszName=0x812c08 "pwalletMain->cs_wallet", mutexIn=..., this=) at sync.h:135
#6 CDarksendPool::UnlockCoins (this=this@entry=0xcb1c00 ) at darksend.cpp:486
#7 0x0000000000733ed3 in CDarksendPool::CheckTimeout (this=this@entry=0xcb1c00 ) at darksend.cpp:822
#8 0x00000000007341ff in ThreadCheckDarkSendPool () at darksend.cpp:2511
#9 0x00007efdb16e5aea in ?? () from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0
#10 0x00007efdafa04064 in start_thread (arg=0x7efd977fe700) at pthread_create.c:309
#11 0x00007efdaf73962d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

@mr-tron
Copy link
Author

mr-tron commented Aug 11, 2017

I gave more memory to virtual machine and crashes gone. But it wasn`t OOM.

@tkanerva
Copy link

I took off "-disablewallet" switch from my dashd command line params, and now the crashes are mysteriously gone.

@nmarley
Copy link

nmarley commented Mar 21, 2018

Obsolete

@nmarley nmarley closed this as completed Mar 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants