Grin 2.1.1 can't sync

Tech Support
1

Hello to grin community!

Last day i try to setup my first grin installation and after stage 2 of blockchain download it throws me “unsupported instruction / core dump”.

My config is: i5-3230M + ubuntu 16.04 (with latest updates) + grin 2.1.1

Here is from kern.log:

Nov 24 22:49:46 LNX kernel: [15613.830620] traps: peer_read[13701] trap invalid opcode ip:55ef7d9bccca sp:7f461cc126c0 error:0 in grin[55ef7d214000+b$
Nov 24 23:20:58 LNX kernel: [17485.917859] traps: peer_read[15033] trap invalid opcode ip:563862d67cca sp:7f61871d26c0 error:0 in grin[5638625bf000+b$
Nov 24 23:24:17 LNX kernel: [17684.751835] audit: type=1400 audit(1574627057.537:43): apparmor=“DENIED” operation=“file_lock” profile="snap.opera.ope$
Nov 24 23:26:15 LNX kernel: [17802.395922] traps: grin[15422] trap invalid opcode ip:56315638acca sp:7fff7b381f60 error:0 in grin[563155be2000+bfd000]
Nov 24 23:34:21 LNX kernel: [18289.190096] traps: grin[15739] trap invalid opcode ip:562972cb1cca sp:7ffc29355320 error:0 in grin[562972509000+bfd000]
Nov 24 23:37:21 LNX kernel: [18468.926831] traps: grin[15819] trap invalid opcode ip:56430854ccca sp:7ffc6b731960 error:0 in grin[564307da4000+bfd000]

Any ideas?

1 Like
2

Solved.
Solution: building from source.

1 Like
3

i tried more than 20 times for Grin++ wallet in win10, failed all the time ,dont know what to do

4

Hey @MrFish, when you say “failed”, what kind of error do you mean? With more details, someone here might be able to help out. Thanks!

5

downloading the chain state for chain sync I get to 100% and then start from 0% a couple of times。

image
image1186×793 37.8 KB

6

i think its not a personal case,because i found more and more people faced this kind of problem

7

The status shows 2/4 in that screenshot. It should go to 100% in 1/4, then 0% in 2/4 up to 100%, then 3/4, then 4/4. Did it go backward in those steps?

8

100% in 1/4, then 0% in 2/4 up to 100%,and then 0% in 2/4 again

9

I’m observing this problem with both v2.1.1 and v3.0.0. It’s described in the following issue:

If you set file logging to “Debug” in the server config file, you should see output similar to the posted examples.

2 Likes
10

Building from source doesn’t solve it. You may have just gotten lucky.

11

It’s becoming more frequent on Grin++ and Grin, especially for those with slow connections. As the download nears 100%, the seeder drops the connection. It’s a huge nuisance, but we have the option of completely revamping the sync process after the hardfork, due to a change we’re making to the headers. Hopefully it will get much better soon.

2 Likes
13

Very glad to hear this. Please keep us posted when these changes are pushed to the repo.

1 Like
14

Where can we learn more about this change to the headers?

1 Like
15

There’s this RFC: https://github.com/mimblewimble/grin-rfcs/pull/29

It’s based loosely on this idea: https://github.com/mimblewimble/grin/issues/2837

2 Likes
16

How much data, in bytes, is added to each header after these commitments are included? Also, does this enable faster sync for pre-fork blocks?

17

0 bytes per header, since it combines with the output mmr.

Well, pre-horizon, Grin sort of loses the concept of blocks. But yes, it does make it so you can use the fast sync for all UTXOs & kernels, not just the new ones.

1 Like
18

I can confirm this problem since 2.0 actually. It syncs the headers (1/4), but then it cannot sync the chain (2/4). Back in the 2.0 upgrade I thought maybe it had a problem with the upgrade. But today I installed 2.1.1 and tried to sync the blockchain from a fresh start, but it hasn’t helped.

I’m using noobstyle x64 Win10 binaries.

20191205 11:57:03.240 INFO grin_servers::common::adapters - Received 32 block headers from 199.59.105.235:3414
20191205 11:57:03.328 INFO grin_servers::common::adapters - Received 32 block headers from 199.59.105.235:3414
20191205 11:57:03.448 INFO grin_servers::common::adapters - Received 31 block headers from 199.59.105.235:3414
20191205 11:59:32.454 INFO grin_servers::common::types - DandelionEpoch: next_epoch: is_stem: true (90%), relay: Some(PeerAddr(V4(213.239.217.14:3414)))
20191205 12:07:08.291 ERROR grin_servers::grin::sync::state_sync - state_sync: TxHashsetDownload status timeout in 10 minutes!
20191205 12:07:08.302 ERROR grin_servers::grin::sync::state_sync - state_sync: error = Error { inner: 

Sync error }. restart fast sync
20191205 12:07:19.007 ERROR grin_util::logger - 
thread 'main' panicked at 'attempt to subtract with overflow': src/bin\tui\status.rs:180stack backtrace:
   0: <no info> (0x7ff6cc5398ad)
   1: <no info> (0x7ff6cc5382e9)
   2: <no info> (0x7ff6cc4d5941)
   3: <no info> (0x7ff6cc5f1385)
   4: <no info> (0x7ff6cc5f0e94)
   5: <no info> (0x7ff6cc5f0d79)
   6: <no info> (0x7ff6cc605e6c)
   7: <no info> (0x7ff6cc605dae)
   8: <no info> (0x7ff6cbdae7d6)
   9: <no info> (0x7ff6cbdba7a4)
  10: <no info> (0x7ff6cbdb9202)
  11: <no info> (0x7ff6cbdb9bdc)
  12: <no info> (0x7ff6cbdea7d9)
  13: <no info> (0x7ff6cbde9029)
  14: <no info> (0x7ff6cbdc94f6)
  15: <no info> (0x7ff6cc5f0cd7)
  16: <no info> (0x7ff6cc5f89f2)
  17: <no info> (0x7ff6cc5f1582)
  18: <no info> (0x7ff6cbdeb587)
  19: <no info> (0x7ff6cc6547b0)
  20: BaseThreadInitThunk (0x7ffd284a7974)
  21: RtlUserThreadStart (0x7ffd2afaa271)

My internet connection is not slow actually it’s 50 Mbit.

Some more info: My internet connection is a upstream only IPv6 type. This causes some trouble sometimes, because I am not reachable via IPv4 requests. Maybe this has something to do with it?

19

Set logging to “Debug” in the server config file and watch for lines with “txhashset archive” in them. Failure to complete the archive download from the remote peer is a known bug [#2929] and that’s likely what you’re experiencing.

And a word of advice: if your node ever syncs (mine finally did after a few dozen failed attempts), never let it get more than 2 days behind. Otherwise, you’ll have to go through the whole ordeal over again.

The TUI crash I’m seeing in your log output could be related to the node attempting to download from 2 peers at once, which causes the progress display to go bonkers. This is another related bug.

1 Like
20

That’s sad. Grin 1.0 worked so well all the time for me. I’m too busy to contribute at the moment. I hope the team will fix it soon. Thanks for the hint.

Edit: OK, now I restarted the daemon 5 times, and finally the 2nd step passed in only a few minutes. That was unexpected. So it’s indeed a nondeterministic error. In the meantime it synced to 100%.

1 Like