[ANN][HUC] Huntercoin - Worlds First Decentralized Game/World on the Blockchain

[The Bitcoin Co-op]

Just compiled the huntercore on ubuntu 16.04, and it was syncing in the qt client after adding nodes. Then I was messing around with the name commands in the debug console, and when I typed "name_list" it immediately crashed with this message:

Code:

line 1: 32485 Segmentation fault      (core dumped) 

and I think corrupted db.

Now getting this message when trying to start qt or d:

Code:

huntercoin-qt: main.cpp:2511: bool ConnectBlockWithGameTx(const CBlock&, CValidationState&, CBlockIndex*, CCoinsViewCache&, std::vector<CTransaction>&, const CChainParams&, bool): Assertion `hashPrevBlock == view.GetBestBlock()' failed.
./runqt.sh: line 1:   560 Aborted

Edit: seems to have corrupted my wallet.dat as well :/

Edit2: cleared out blocks, chainstate, database, and gamestates folder as well as wallet.dat and now seems to be syncing again...

Edit3: I'm scared to try name_list again from huntercoin-cli this time 

Thanks for testing that out! I'm sure it will help domob. Snailbrain says he plans to do more testing today, as well. I think price rises tend to make everyone more active Some people might also want to challenge the Dominator--the player or group of players controlling the best coin farms--since those coins are now more valuable.

We also might have another surprise before Huntercore is released, but we're not talking about it, yet.

[1713937840]

1713937840

[1713937840]

1713937840

[1713937840]

1713937840

[snailbrain]

Just compiled the huntercore on ubuntu 16.04, and it was syncing in the qt client after adding nodes. Then I was messing around with the name commands in the debug console, and when I typed "name_list" it immediately crashed with this message:

Code:

line 1: 32485 Segmentation fault      (core dumped) 

and I think corrupted db.

Now getting this message when trying to start qt or d:

Code:

huntercoin-qt: main.cpp:2511: bool ConnectBlockWithGameTx(const CBlock&, CValidationState&, CBlockIndex*, CCoinsViewCache&, std::vector<CTransaction>&, const CChainParams&, bool): Assertion `hashPrevBlock == view.GetBestBlock()' failed.
./runqt.sh: line 1:   560 Aborted

Edit: seems to have corrupted my wallet.dat as well :/

Edit2: cleared out blocks, chainstate, database, and gamestates folder as well as wallet.dat and now seems to be syncing again...

Edit3: I'm scared to try name_list again from huntercoin-cli this time 

Thanks.

This is a known problem at the moment and what is solely holding up huntercore release.

I will place a 5k bounty if someone can fix or produce a solid backtrace to send to Domob for analysis.

[jwinterm]

...
Thanks.

This is a known problem at the moment and what is solely holding up huntercore release.

I will place a 5k bounty if someone can fix or produce a solid backtrace to send to Domob for analysis.

Well, I'm almost synced now, so don't want to mess this chain up, but will running it with strace on a fresh sync trying to reproduce the issue help?

[snailbrain]

...
Thanks.

This is a known problem at the moment and what is solely holding up huntercore release.

I will place a 5k bounty if someone can fix or produce a solid backtrace to send to Domob for analysis.

Well, I'm almost synced now, so don't want to mess this chain up, but will running it with strace on a fresh sync trying to reproduce the issue help?

Thanks. possibly but not sure

GDB i think is what we need

make a copy of your chain when synced.

[jwinterm]

...
Thanks.

This is a known problem at the moment and what is solely holding up huntercore release.

I will place a 5k bounty if someone can fix or produce a solid backtrace to send to Domob for analysis.

Well, I'm almost synced now, so don't want to mess this chain up, but will running it with strace on a fresh sync trying to reproduce the issue help?

Thanks. possibly but not sure

GDB i think is what we need

make a copy of your chain when synced.

Right, was definitely planning to backup chain. GDB requires recompiling?

[snailbrain]

...
Thanks.

This is a known problem at the moment and what is solely holding up huntercore release.

I will place a 5k bounty if someone can fix or produce a solid backtrace to send to Domob for analysis.

Well, I'm almost synced now, so don't want to mess this chain up, but will running it with strace on a fresh sync trying to reproduce the issue help?

Thanks. possibly but not sure

GDB i think is what we need

make a copy of your chain when synced.

Right, was definitely planning to backup chain. GDB requires recompiling?

i've no experience with it but i also read that too, I queried with domob the other day and he says it doesn't.

hopefully he will reply soon.

[domob]

A backtrace would be very useful - I've not been able to produce this crash myself on GNU/Linux.

Ideally recompile where you ./configure with --enable-debug.  But if you don't want to do that or can't, GDB may be able to produce at least some useful information even with the binary you have.

[jwinterm]

A backtrace would be very useful - I've not been able to produce this crash myself on GNU/Linux.

Ideally recompile where you ./configure with --enable-debug.  But if you don't want to do that or can't, GDB may be able to produce at least some useful information even with the binary you have.

I copied directory and recompiled after running ./configure with --enable-debug, but there's nothing additional shown on command line or in debug.log. It did crash when I ran the name_list command in the same way though. Did I need to make clean before running make?

Edit: didn't kill the db this time though...

Edit2: just ran it with strace, here is output when it crashed and just before:

Code:

recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"\1\1\250 \0\0\0\0\0\0\0\0:\1I\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32
recvmsg(6, 0x7fffe7117110, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(6, 0x7fffe7117110, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(6, 0x7fffe7117a40, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(6, 0x7fffe7117c10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(8, 0x7fffe7117c00, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=18, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=POLLIN}], 8, 31 <unfinished ...>
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

I also noticed it's showing a zero balance even though by this time during sync it has confirmed txs worth like 5k HUC, which seems a bit off.


Edit3: here is the entire gdb output:

Code:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe63bb700 (LWP 8345)]
[New Thread 0x7fffe5b9a700 (LWP 8346)]
[New Thread 0x7fffe4d76700 (LWP 8347)]
[New Thread 0x7fffde2c2700 (LWP 8348)]
[New Thread 0x7fffddac1700 (LWP 8349)]
[New Thread 0x7fffcdce3700 (LWP 8352)]
[New Thread 0x7fffcd04b700 (LWP 8355)]
[New Thread 0x7fffc7fff700 (LWP 8357)]
[New Thread 0x7fffc77fe700 (LWP 8358)]
[New Thread 0x7fffc6ffd700 (LWP 8359)]
[New Thread 0x7fffc67fc700 (LWP 8360)]
[New Thread 0x7fffc5ffb700 (LWP 8361)]
[New Thread 0x7fffc57fa700 (LWP 8362)]
[New Thread 0x7fffc4ff9700 (LWP 8363)]
[Thread 0x7fffddac1700 (LWP 8349) exited]
[Thread 0x7fffde2c2700 (LWP 8348) exited]
[New Thread 0x7fffde2c2700 (LWP 8366)]
[Thread 0x7fffde2c2700 (LWP 8366) exited]
[New Thread 0x7fffddac1700 (LWP 8367)]
[New Thread 0x7fffa0d8a700 (LWP 8368)]
[New Thread 0x7fff97fff700 (LWP 8369)]
[New Thread 0x7fff977fe700 (LWP 8370)]
[New Thread 0x7fff96ffd700 (LWP 8371)]
[New Thread 0x7fff967fc700 (LWP 8372)]
[New Thread 0x7fff95ffb700 (LWP 8373)]
[New Thread 0x7fff81ed5700 (LWP 8377)]
[Thread 0x7fffa0d8a700 (LWP 8368) exited]

Thread 7 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcdce3700 (LWP 8352)]
NameListBuilder::startTx (this=this@entry=0x7fffcdce1ee0, tx=...) at wallet/rpcnames.cpp:125
125	  nHeight = pindex->nHeight;

[The Bitcoin Co-op]

The HUC price leveled up--old resistance, new support. Based on where lots of buy orders have been placed, it seem the market roughly agrees, but the line is still being tested. I don't think the market has any idea yet where exactly the ceiling should be, though; just some rough guesses based on the recent spikes. I don't usually sell, anyways

[harissengke]

i always loved this coin since old time

[domob]

Code:

Thread 7 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcdce3700 (LWP 8352)]
NameListBuilder::startTx (this=this@entry=0x7fffcdce1ee0, tx=...) at wallet/rpcnames.cpp:125
125	  nHeight = pindex->nHeight;

That's what I was looking for - it would still be cool if I could reproduce the problem, but I'll take a look at this code to see if I can spot any issue there even without that.  Thanks a lot!

EDIT: It seems that I can now actually reproduce the issue - the crash happens when you call name_list while a name operation in your wallet is pending.  Not sure why I didn't see it before, but I think we can now quickly fix it (hopefully).

[jwinterm]

Code:

Thread 7 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcdce3700 (LWP 8352)]
NameListBuilder::startTx (this=this@entry=0x7fffcdce1ee0, tx=...) at wallet/rpcnames.cpp:125
125	  nHeight = pindex->nHeight;

That's what I was looking for - it would still be cool if I could reproduce the problem, but I'll take a look at this code to see if I can spot any issue there even without that.  Thanks a lot!

EDIT: It seems that I can now actually reproduce the issue - the crash happens when you call name_list while a name operation in your wallet is pending.  Not sure why I didn't see it before, but I think we can now quickly fix it (hopefully).

Nice Glad I could do small part to help shed some light.

[snailbrain]

Code:

Thread 7 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcdce3700 (LWP 8352)]
NameListBuilder::startTx (this=this@entry=0x7fffcdce1ee0, tx=...) at wallet/rpcnames.cpp:125
125	  nHeight = pindex->nHeight;

That's what I was looking for - it would still be cool if I could reproduce the problem, but I'll take a look at this code to see if I can spot any issue there even without that.  Thanks a lot!

EDIT: It seems that I can now actually reproduce the issue - the crash happens when you call name_list while a name operation in your wallet is pending.  Not sure why I didn't see it before, but I think we can now quickly fix it (hopefully).

Nice Glad I could do small part to help shed some light.

domob has pushed a possible fix if you want to test

i'll compile and test tomorrow as well.

if it works - i'll send 5k from the Dev fund

[jwinterm]

Just compiled and tested name_list in qt wallet and it works. Lists all hunters I created up to current sync point. Yay

It's still showing zero balance for me in qt though, and I think I should definitely have a confirmed balance of like 30k HUC at this point. Getinfo call also shows 0 balance.

[snailbrain]

Just compiled and tested name_list in qt wallet and it works. Lists all hunters I created up to current sync point. Yay

It's still showing zero balance for me in qt though, and I think I should definitely have a confirmed balance of like 30k HUC at this point. Getinfo call also shows 0 balance.

i had some issues like this also - i think my wallet became corrupted after the other crashes due to name_list..

could be wrong though - i'll test some soon, almost finished building

[snailbrain]

seems working so far on ubuntu - i can play with the unity client without crashing.. on a pruned chain.

I'm syncing from scratch now on windows

[jwinterm]

Just compiled and tested name_list in qt wallet and it works. Lists all hunters I created up to current sync point. Yay

It's still showing zero balance for me in qt though, and I think I should definitely have a confirmed balance of like 30k HUC at this point. Getinfo call also shows 0 balance.

Nevermind. 34 hours behind now and correct balance is displaying. Maybe I had spent all the stuff that had been confirmed in a later tx or something when I was 30 weeks behind last night.

[cryptospreader_temp]

I have two questions.

Are wallets listed in OP working fine and are they the latest updated wallets?

Any bootstrap available?

[snailbrain]

I have two questions.

Are wallets listed in OP working fine and are they the latest updated wallets?

Any bootstrap available?

yes the one in the OP is fine.

you can download the full chain from chain.huntercoin.org

[JasonXG]

What is going on with this project ? Who actually is the dev ? I hear big talk coming from certain users but nothing to back it up with. Where is tharani ? She was so nice now she just ignores me. Which is really messed up wince she started talking to me. I'm just hearing lies. Also she got neg trust by a trusted member so wtf ?