Closed fogoat closed 5 years ago
Please run the sanctuary in valgrind from a compiled copy, then enter the issue with the valgrind log after proof of the crash is found.
Yes, I will keep this open, please, give us a valgrind log.
Attached is the valgrind log from a MN that crashed. I hope this helps.
Here is the second crash from different node.
@sunk818 Ok, I took a look at the valgrind log.
It appears whoever ran it didnt follow the instructions above - was it run from a biblepay binary, or a compiled biblepay node? I mentioned that valgrind must be run on a compiled copy.
Log is not helpful. The other log is the same as the first log - binary.
Could you provide better instructions. You are asking help from people who are not familiar with compiling etc
Sure! Basically, what we are trying to do is trap an error at runtime and capture the specific original line number and c++ filename, since we believe this particular error is in an untraceable procedure most likely occurring in the middle of a legacy instantsend transaction. The reason we need the exact line, is because c++ casts resulting in segfaults could be anywhere, and therefore its almost impossible to put enough logging in to catch the exact line without valgrind. In order for valgrind to output anything useful, it needs the original symbols encoded and the debug line number pointers. It can only get that from a running biblepay version that was compiled on the same flavor box as it is running (IE ubuntu 16.04 is running a biblepay compiled on ubuntu 16.04 64 bit version by gnu, etc).
So, in light of this, all you have to do is compile biblepay on the machine with valgrind, then run biblepay in valgrind.
To compile bbp just use the existing instructions: https://github.com/biblepay/biblepay/blob/master/BuildBiblePay.txt
After compiled if you are running QT for instance:
cd ~/biblepay/src/qt Instead of launching it normally like this: ./biblepay-qt
Launch like this:
valgrind ./biblepay-qt
Of course we want to capture the output to the log, so please do the same as you did before (capture both stdout and stderr, as valgrind prints out very extremely important info to stderr) and we would probably miss what we need if both pipes are not redirected to the log.
One more thing; If you crash a lot, I recommend cleaning your .dat files and blocks and chainstate and resyncing. The crash could be from having corrupted mncache or mnpayment data.
I believe this is no longer an issue since you upgraded all your masternodes and the consensus conflict is gone with over 50% agreeing on version 1198 code now. Will re-open if Discord user reports further issues.
Okdoki on discord reporting many masternodes crashed
6/8 MN crashed just after block 104899 accepted @ 2019-03-03 12:32:29 2/8 MN were still active after block 104899, here is the log of one of them:
Once again this Unable to find hashBlock 0000000000000000000000000000000000000000000000000000000000000000 line...