SYRIUS v0.0.6 Crashes With Embedded Node

Archived
22

Crashes before login. It happens only in Win 10. Syrius in win 11 is fine…

23

I did the 2nd one… extracted and ran the .exe file from extracted folder, didn’t move it.

24

Reinstalled my win10, i have the following issues

  1. Syrius crashes if znnd is not running in parallel
  2. Closing znnd after syrius is up disconnected syrius from node
  3. I can’t connect to any community nodes, says failed to connect
25

Completely fresh install?

1 Like
26

Just the c drive. Its formatted and win 10 installed

27

hey guys, just an update on the crash! I ran znnd v0.0.5 and am now able to run Syrius v0.0.6 without any issues.

I did not redownload Syrius or anything… So I think it’s really a node issue!

3 Likes
28

I had Syrius crash on one of my Win10 machines, force closed itself after pressing collect on delegation rewards, and ever since can’t re-open it (experiencing the same issue as the others now).

Really odd it would manifest itself randomly, trawling through logs now. Means it’s unlikely to be a dll or missing dependency issue

29

0.0.5 also crashing before login as well now

both on embedded mode, same affected PC

30

log file in znn/consensus just shows this over and over again when opening, usually when working it obviously undertakes a lot more. Maybe its indicative to someone who has experience with Syrius @aliencoder @sumamu ?

=============== Apr 23, 2023 (AEST) ===============
08:37:02.570650 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
08:37:02.572655 version@stat F·[1 63 211] S·507MiB[726KiB 99MiB 406MiB] Sc·[0.25 1.00 0.41]
08:37:02.572655 db@open opening
08:37:02.573655 journal@recovery F·1
08:37:02.573655 journal@recovery recovering @29766
08:37:02.574653 version@stat F·[1 63 211] S·507MiB[726KiB 99MiB 406MiB] Sc·[0.25 1.00 0.41]
08:37:02.581653 db@janitor F·277 G·0
08:37:02.582654 db@open done T·9.9993ms

Also the last file that Syrius has any interaction with (a successful ReadFile operation) before crashing is below:

C:\Users\romeo\AppData\Roaming\znn\nom\438508.ldb

31

getting closer - this is from running Syrius 0.0.6 (not built from source, just extracted with syrius-alphanet-windows-amd64):

t=2023-04-23T12:59:18+1000 lvl=crit msg="can't start node because don't have all sporks implemented" module=chain hash=9e2438a0ac72fcd8afe230323798270ea77b96edf9c76ca7c0e0695c7a15d331 height=4188199 unimplemented=[0xc0008c6e10]

4188199 was the momentum prior to the first spork

32

Before the issue started, the zenon.log started warning about this:

t=2023-04-23T07:51:13+1000 lvl=warn msg="Find non-empty bucket" module=embedded peers=table entries="[enode://8da3624a825e9cc3536c6065f06f0dd38c4703bf32299f171a1d0e69d249c887220b875e1a82a38f8ecb37971d6c6d7741889abe942a1ddef75ac9dce3aa0575@62.171.148.56:35995 enode://0c5213f89c748aab5c39e63bdc65bd97bf446a5229e640086e2784217d24731d78ab53ee5316619dc4299ab759304c5859272d35cfab74fd9106753e0db3d14e@135.148.32.194:35995 enode://0812b9dc68542286330dc768ff87719d13733400022c556a777152dac42e664f29c23a415125c9645783384fc18de91c6ece82b54338875db66530fc1da6ceeb@158.247.209.220:35995 enode://0220d5ed0e17344023d70f8e72259fe0940e232777d88f828c5be5cf67071eae26501182fdc6a9be2ce14db7a8315456594aad5d6f88609c73ad052b8183dd23@139.99.169.68:35995 enode://4c38beeab6bc5531fbe49ebc8c2297d708631a41431b1fd624ddaecd2adda516b25e6de6483a59dededd92b763ad5afc805dcc9b49d6acfdf58c8d244387ff18@216.128.178.220:35995 enode://2155ec9ee05593174451fa0109224f590b039811748274ea754eff2d541c6831cec4c4ab33184e0482e249c245707f88c2588722ca329556f19bfbaf8560be72@5.9.153.75:35995 enode://00be0ab173fa0c60e4f93a8cac0670f0169ffab7e18e9b502e0d59ed0779f88d1cc8cbdea4f1fe784fae5358ef5ade78206fa3444ba6c215a99d0fd07fe89105@51.79.220.30:35995 enode://c10eb6a097b174041cdf59b200b37a9312593e52807e438faac4cba9e65007dad71d7fa2a979a6e2f5b355b7c12d59cf56a6a3dee2c40c7d8f8c5665387c072d@198.244.149.192:35995 enode://446698548dff0319e363927d4fb566af72f1fdb30094d62d217cb71505949cd1936e4781998e6df32d7859d81ef84745e9f73dee1b4d69a076d34098a7879f3e@51.79.207.58:35995 enode://7a57e3a373f5a85a39ca61df1488c2107c7494ac6f2bb36a1671ecb051bd03f1aace5f5eeddb86d3ae0d5959c617801c4c2740a9938625d39f619a04fabb6b6c@51.195.138.179:35995 enode://45b3da04b79407127c7e172920a6fee7ce46b040a46cb563b447db6f9750460cb71cf3ce4b769057621e1dedd7ec25351d1335c955bba46dd90e3b76a3fccb85@149.56.108.141:35995 enode://0509c14897283f99f6cc36dc1b3de53f7290b51866c4c95469b2f956864ad016c59c243127cec28bf9b92816ddf89310e6d57493403ad8a7ec4f38ec47f4edae@193.149.189.76:35995 enode://e65a83e5c4b3976f80b60ce39cb461fbfffa00b3d7390c654e30816713e6567e907aeb75c59130fb4369879ad6e072ff507cd7fe4a020c8ac6732ed61024915c@178.18.250.182:35995 enode://7227e01a72e223c5f8284a62061a5bb4ab97305605b7f325ba2ff5db56323b4e3a41d871722a44a4e45abe8bbdc4a1bd79497fd108370ff4db0a9473d5522b3c@137.184.138.57:35995 enode://895a7ad858af86a0f85578d549a41b35b8565da2833a3731e6605f2efbc90c08d7a12d44f808729d703ef14f99034e57c7261d1808a021810316ecd5b9153410@135.148.121.53:35995 enode://55786f9013e2399cbd7bd8b1bdf52a42b3f09b9b2f713b9b8996702e870634deae8e673c65d123ceb8aab7c374a94f6b7992ce6982427d78a7eb8c1f25619214@95.216.146.33:35995]"

33

copying syrius 0.0.6 files and over writing my previous copy of 0.0.6 allowed it to sync past the Spork momentum

1 Like
34

Yes, and it’s not a crash

1 Like
35

Ah, I see. Weird that it got in a loop like that, acted like it was using znnd 0.0.4 for some reason

36

does that mean SYRIUS should load now that the sporks were activated?

37

If that’s the case then it’s worth still fixing the issue for future periods between sporks activations with new syrius releases.

38

Another way is to time the release of new SYRIUS versions with the timing of approving sporks.

39

I don’t think my issue is the same as the others as it only reared its head after the Spork, whereas others had dramas prior

40

Is this function meant to print something for the user to see? Or just to a log? At the moment I don’t believe it is shown to the user

Is it possible for this to be changed to show the msg to the user and requiring a prompt prior to closing?

fmt.Printf("===== Error =====\n")
		fmt.Printf("Can't start node. %v height %v\n", frontier.Hash, frontier.Height)
		fmt.Printf("Detected an unimplemented spork.\n")
		for _, spork := range unimplemented {
			fmt.Printf("  Spork name `%v` id:`%v`\n", spork.Name, spork.Id)
		}
		fmt.Printf("\n")
		fmt.Printf("Please upgrade your znnd binary\n")
		fmt.Printf("znnd is terminating\n")
		os.Exit(2)
41

I think it was designed this way. They are already shown to the user in the console and it’s closing the node on purpose.