Jump to content
Tranz

HBN Trouble Shooting Guide: Assert Failure

Recommended Posts

Tranz

There is a known bug, but not yet fully known reason that may affect some users of HBN, sometimes. This guide will help you get back up and running if it should happen to you and help you prepare for a quick recovery.

 

The bug in general shows itself after a shut down and restart.  You may start up and receive an error message as such:

 

93Opv2w.jpg

 

 

So what is happening?

The best I have gathered so far, is part of the index becomes corrupt or erased and is not loaded into memory. As the index is loaded it is scanned against a hash check. If this fails it aborts the client as shown above.

 

So what can you do? 

The easiest solution is to Navigate to your %appdata%/HoboNickels directory. There you will see some files and folders.  You can remove or rename the folder "txleveldb". Then start up the client. It will request the blocks from the network and rebuild the index. If you are having trouble getting a strong connection from the network, see this guide (https://cryptocointalk.com/topic/9592-hbn-trouble-shooting-guide-syncing-and-checkpoints/?p=80846) This process can be time consuming, and slightly irritating, but there is no danger to your wallet or coins.

 

How to be prepared?

If you want to be prepared in case that could happen to you. Here is one process that can help. After you are up to sync with the block chain, shut down the client. Then in the same directory as above, make a new folder called block_chain_backup. Then copy the blk0001.dat and the txleveldb folder to that new backup folder.  If you would get this failure in the future you could use these 2 files and overlay the ones in the root directory.  This would save at least some time re-syncing with the network.  Be careful not to do anything to other files.  Such as wallet.dat or the database folder

 

What is being done?

Currently I am working on this piece of the code to remove this nuisance of a bug from the client.  But this can be time consuming as the new code is written, I then have to recreate the index, and then try to trash it.  Sometimes the crash is quick other times it can be difficult to make it happen.

 

Can I help?

Yes!  I am offering a bounty of 5,000 HBN to someone who can demonstrably prove where the bug resides and offer a fix to the code base.  Otherwise if it does happen to you. Feel free to post in this thread so we can track this issue. Valuable information would be: What version are you on. What system were you on. Did anything new or recent happen to that computer. Such as a hard crash(power failure) or perhaps a OS patch.  Or anything else you may think is important.

 

If you have any further information or thoughts about this again feel free to post links or ideas.

 

Thanks!

  • Like 1

Share this post


Link to post
Share on other sites
presstab

Tranz thanks for the write up!  I am hoping that I will never have to use it though.... I think that because my client is running 24/7 it might be immune from some of these issues that seem to happen when the block is indexing on loadup.

Share this post


Link to post
Share on other sites
Tranz

So I just loaded up my Mint wallet. And I was a bit surprised to see that I got the same assert failure.. Interesting.. They are not on leveldb, and are in fact a older version of NVC fork.

 

Another user told me they have seen the same failures on BC and NVC. Has anyone else also seen this? If so what coin?

Share this post


Link to post
Share on other sites
presstab

So not an underlying problem with the HBN Qt client, that is good to know. I will try to do some googling and see if I can come up with any threads discussing the issue.

Share this post


Link to post
Share on other sites
tricass

Just experienced this after a power failure. Wallet had been running prior to the power loss. When it tried starting up it failed with this error. I'm running Win 8.1 and had not installed any new patches or software on this box prior. Most likely caused a corruption due to the sudden power loss.

Share this post


Link to post
Share on other sites
Tranz

Sorry to hear that, yes this seems to be the most likely of issues.  After you get back up and running take a snapshot as directed above. Will save some time in the future if it should happen again.

 

I also just had an issue where my client when out of sync.  I closed it down and started it back up and it was trying to reorganize back to a block in the 690,000 range, due to tx block corruption. Was odd to stay the least. I stopped the client, restored by blk0001.dat and txleveldb from backup and I was running again pretty quickly.  But some many oddities with leveldb.

Share this post


Link to post
Share on other sites
tricass

I've taken the snapshot now. Thanks!

Share this post


Link to post
Share on other sites
plusroi

Hi Tranz,

 

It's choppy here.

 

I just sent you a PM on bitcointalk forum with a workaround !

 

It's not a fix per se but an easy workaround!

  • Like 1

Share this post


Link to post
Share on other sites
unick

just got the assertion on Mac

Application Specific Information:
Assertion failed: (!pthread_mutex_lock(&m)), function lock, file /usr/local/include/boost/thread/pthread/recursive_mutex.hpp, line 110.

Share this post


Link to post
Share on other sites
Tranz

That is a bit different. Was this while it as running?

Share this post


Link to post
Share on other sites
unick

Well it happened at shutdown, I don't recall doing anything special

Share this post


Link to post
Share on other sites
Tranz

Ok will it start back up?

Share this post


Link to post
Share on other sites
unick

yep it did just fine, no apparent problems to report other than that one.  I mainly posted it thinking it could give you some hints on the issue, maybe it's not related.

Share this post


Link to post
Share on other sites
Tranz

Thanks I do appreciate it. It might have more to do with the compile technique on the mac, or the boost libraries perhaps.

Share this post


Link to post
Share on other sites
presstab

Tranz do you think it is possible that the assertion error stems from these lines in GetStakeModifierChecksum 

if (fDebug && GetBoolArg("-printstakechecksum"))
        printf("GetStakeModifierChecksum: StakeCheckSum=0x%09"PRI64x", at height=%d\n",
            hashChecksum.Get64(), pindex->nHeight );

 

 

I noticed that NVC and TEK both don't have these lines.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Cryptocurrenytalk Logo

 

News, information, and discussions about cryptocurrencies, blockchains, technology, and events. Blockchaintalk is your source for advice on what to mine, technical details, new launch announcements, and advice from trusted members of the community. Cryptocurrencytalk is your source for everything crypto. We love discussing the world of cryptocurrencies.

 

   
×
×
  • Create New...

Important Information

By using CRYPTOCURRENCYTALK.COM, you agree to our Terms of Use.