v8.22.0-rc3 crashes before finishing synchronisation

Question

v8.22.0-rc3 crashes before finishing synchronisation

diegonc opened this issue 10 months ago · 17 comments

diegonc commented 10 months ago

Expected behaviour

The node is able to synchronise fully and continue operation normally.

Actual behaviour

Somewhere before fully synchronisation the application crashes.

The following is the event on the Windows 11 Event Console.
dgb-evtx.zip

To reproduce

Synchronise the blockchain DB, I guess. I started with an old database from 2018 and synchronised up to the very few days of march 2024.

I then downloaded 7.17.3 and completed the synchronisation. And now the v8.22.0-rc3 seems to work ok. So, I'm not sure what's happening.

System information

DigiByte Core : v8.22.0-rc3 (github release digibyte-8.22.0-rc3-win64-setup-unsigned.exe)
OS: Windows 11
CPU: AMD Ryzen 9 5900HX
Disk : 1TB PCIe® 3.0 NVMe™ M.2 (model HFM001TD3JX013N )

There's no unusual log entries in debug.log file before the crash. Only the Windows event attached above.

Answer 1 · 2024-03-11T17:59:32.000Z

Thanks for sharing this. So just to be clear you:

opened v8.22.0-RC3 with an old chain and synced up up to the beginning of March 2024 and then it crashed.
You then launched 7.17.3 and synced it to the present
Finally you closed down 7.17.3 and relaunched 8.22.0-rc3 where it is now running normally, fully synced?

Is that correct?

Did it happen just the once? Or have you been able to recreate it? I don't suppose you have a backup of the old chain to try again?

Answer 2 · 2024-03-11T18:06:20.000Z

Thanks for sharing this. So just to be clear you:

opened v8.22.0-RC3 with an old chain and synced up up to the beginning of March 2024 and then it crashed.

You then launched 7.17.3 and synced it to the present

Finally you closed down 7.17.3 and relaunched 8.22.0-rc3 where it is now running normally, fully synced?

Is that correct?

Correct.

Did it happen just the once? Or have you been able to recreate it?

It happened a few times until I realised I could try fixing it with the stable version.

I don't suppose you have a backup of the old chain to try again?

I do have a backup of the chain from 2018. Unfortunately reaching the point of failure would take another few weeks (my internet is so slow 😢)

It's about 1.1 GB. Probably better to upload somewhere than to attempt to synchronise again

Answer 3 · 2024-03-11T18:16:28.000Z

And there is nothing unusual in debug.log?

Do you know what version the old chain was originally synced with? Was it 7.17.3?

Answer 4 · 2024-03-11T18:23:59.000Z

And there is nothing unusual in debug.log?

Nope, just the blocks being downloaded before the crash.

Do you know what version the old chain was originally synced with? Was it 7.17.3?

Apparently it was 6.14.2 (from the installer name I have in a backup disk)

Answer 5 · 2024-03-11T18:28:05.000Z

Since version 6 chain and 7 is incompatible with each other due to breaking changes I don't think this should be an issue.

The only way to get it working, even if it weren't to crash, is to clear all block data and sync from scratch.

Answer 6 · 2024-03-11T18:39:31.000Z

Ah ok, I wasn't aware. I'll have to sync from scratch then 😭

I have a default wallet and an additional wallet which apparently was created in a subdirectory. I'd like to keep both but version 7.17.3 doesn't seem to support multiple wallets.

Is it ok if I keep using the 8.22 RC3?

Answer 7 · 2024-03-11T18:43:29.000Z

As far as we know for sure, you should be able to keep using 8.22 RC3, but that being said, it is a somewhat experimental version meant for testing to find issues, and there may still be many that we do not yet fully comprehend. The issue you have experienced with the client crashing might just be that, a bug in that version, so please be aware that you may encounter further issues and that we are all extremely grateful if you keep reporting issues found here in GitHub.

Answer 8 · 2024-03-11T18:49:53.000Z

Ok, I will try 8.22.0-RC3 once more, this time from scratch.

Are wallets from version 6 compatible? Is keeping only wallet.dat and the second wallet subdirectory ok? Or should I keep something else?

Answer 9 · 2024-03-17T06:10:55.000Z

Is this still a valid issue?

Answer 10 · 2024-03-17T14:45:40.000Z

Is this still a valid issue?

I’m still synchronizing from scratch to test whether the old 6.x db starting point was causing the issue or not.

I’ve already downloaded all the headers, it's now getting the blocks. I guess it will take a few more days.

Answer 11 · 2024-03-18T02:56:48.000Z

Synchronising from scratch, it's still crashing 😞

These are the last few log lines in debug.log before the crash:

2024-03-18T02:29:55Z UpdateTip: new best=000000000000000384d6bbd16db8cf6ddfac4b66a152779936a0f860167be209 height=6026782 version=0x20000202 algo=0 (sha256d) log2_work=77.234133 tx=13004132 date='2018-02-04T13:34:32Z' progress=0.280545 cache=13.9MiB(107002txo)
2024-03-18T02:29:55Z UpdateTip: new best=d7180b3137e8d1d38ee4e713f175cc45e3e8040b68b3680beef9b547ef2be4ab height=6026783 version=0x20000802 algo=4 (qubit) log2_work=77.234136 tx=13004133 date='2018-02-04T13:34:31Z' progress=0.280545 cache=13.9MiB(107003txo)
2024-03-18T02:29:55Z UpdateTip: new best=a44c491882c36c393942d28455cbe2058d536e32f7956e4b9dad63394739cb53 height=6026784 version=0x20000602 algo=3 (skein) log2_work=77.234139 tx=13004138 date='2018-02-04T13:34:35Z' progress=0.280545 cache=13.9MiB(107008txo)
2024-03-18T02:29:55Z UpdateTip: new best=000000000000000157903c70b2b7593ade3b2403d8d46cd8cbad65ba4562f34f height=6026785 version=0x20000202 algo=0 (sha256d) log2_work=77.234142 tx=13004147 date='2018-02-04T13:34:56Z' progress=0.280546 cache=13.9MiB(107019txo)
2024-03-18T02:29:55Z UpdateTip: new best=0000000000000004a35ebc853a9c4d9975b64295c9e9b62a59d980a71eee2734 height=6026786 version=0x20000202 algo=0 (sha256d) log2_work=77.234145 tx=13004149 date='2018-02-04T13:35:02Z' progress=0.280546 cache=13.9MiB(107021txo)
2024-03-18T02:29:55Z UpdateTip: new best=9109ccdb3ff4c835e855b88656f36361773eb1fb1014421ffbd2f11a8add95b3 height=6026787 version=0x20000602 algo=3 (skein) log2_work=77.234148 tx=13004154 date='2018-02-04T13:35:15Z' progress=0.280546 cache=13.9MiB(107024txo)
2024-03-18T02:29:55Z UpdateTip: new best=056bd89abd37c7bb756c78699d4c96e8a9569f7a48cb2fc52930ab5d59ff92ac height=6026788 version=0x20000602 algo=3 (skein) log2_work=77.234151 tx=13004157 date='2018-02-04T13:35:38Z' progress=0.280546 cache=13.9MiB(107027txo)
2024-03-18T02:29:55Z UpdateTip: new best=285a5728826375418f9d49db20923b08465c7fe80205d18f0094d848ff724374 height=6026789 version=0x20000802 algo=4 (qubit) log2_work=77.234154 tx=13004176 date='2018-02-04T13:36:10Z' progress=0.280546 cache=13.9MiB(107026txo)
2024-03-18T02:29:55Z UpdateTip: new best=3c24cc9e25117f23364853f2950d8e59d63746863fad4d4f92fbc650a3469c08 height=6026790 version=0x20000002 algo=1 (scrypt) log2_work=77.234157 tx=13004178 date='2018-02-04T13:36:21Z' progress=0.280546 cache=13.9MiB(107028txo)
2024-03-18T02:29:55Z UpdateTip: new best=235bc878aa10b234b660433d72b27e15b9f9941455c227b03599cf336fe6b277 height=6026791 version=0x20000802 algo=4 (qubit) log2_work=77.234161 tx=13004179 date='2018-02-04T13:36:16Z' progress=0.280546 cache=13.9MiB(107029txo)
2024-03-18T02:29:55Z UpdateTip: new best=06d111500da3bdb14a9b0ff75e035cd25fb644af7f3ed6fb54ad2aa2ec318f1b height=6026792 version=0x20000602 algo=3 (skein) log2_work=77.234164 tx=13004182 date='2018-02-04T13:36:31Z' progress=0.280546 cache=13.9MiB(107032txo)
2024-03-18T02:29:55Z UpdateTip: new best=0000000000000001704b246edb83aeaf3a5fa61b58e47858df75742a11eebca5 height=6026793 version=0x20000202 algo=0 (sha256d) log2_work=77.234167 tx=13004184 date='2018-02-04T13:36:41Z' progress=0.280546 cache=13.9MiB(107034txo)

I suspect this is caused by a transaction from 2018 that is in my wallet (it shows in the recent transactions section since the beginning of the synchronisation), namely the following 10760ee84d1e04bde910b6456d2fa106699e58df0da650273de6e77153dfe88d

But I'm not sure because there are logs of three blocks after it.

A second run went two blocks further before crashing:

2024-03-18T02:47:15Z UpdateTip: new best=3d49645eb387a33fd34b6d7f9999495cb6e19f78c56adcfd7575a3f673e01f8a height=6026794 version=0x20000402 algo=2 (groestl) log2_work=77.234171 tx=13004185 date='2018-02-04T13:36:40Z' progress=0.280546 cache=13.9MiB(107035txo)
2024-03-18T02:47:15Z UpdateTip: new best=eccc1a6cf58a8c758e91d9986d13011ddb47d2bd0fbb1cf3b4eb5328b993f519 height=6026795 version=0x20000602 algo=3 (skein) log2_work=77.234174 tx=13004186 date='2018-02-04T13:36:45Z' progress=0.280546 cache=13.9MiB(107036txo)

I guess, this is consistently crashing now, a third time crashed at height=6026795, again.

Should I try removing the wallet before restarting synchronisation? Just to check whether it's the culprit or not.

Answer 12 · 2024-03-18T15:05:50.000Z

Have you tried a completely fresh sync from the beginning with v8.22 rc3? It seems like you have a corrupted local DB. I have had this happen in the past when upgrading versions. But a fresh sync with latest wallet or a full reindex=1 always fixed the issue. Cheers

Answer 13 · 2024-03-18T15:10:34.000Z

I've done a fresh sync, I think. I started with an empty node directory. Only my old wallet.dat was there.

Answer 14 · 2024-03-18T16:02:43.000Z

Hmm, I deleted wallet.dat and now the synchronisation is not crashing anymore 😕

Any idea of how to recover/upgrade the wallet?

Answer 15 · 2024-03-20T06:28:34.000Z

I hope you have a backup of your wallet.dat? Without it there is absolutely no way to recover your funds unless you have the private keys written down somewhere.

You say empty node folder, can you please elaborate what you mean by this?

Answer 16 · 2024-03-20T10:09:53.000Z

I hope you have a backup of your wallet.dat?

Yes, I have a backup. So, after deleting the wallet the synchronization continued without issues. A few blocks later, I stopped the client, restored the `wallet.dat` and then started the client again. Synchronization continued without problems then. And I was able to move the funds to a newer wallet which hopefully doesn’t have this issues.

You say empty node folder, can you please elaborate what you mean by this?

I mean an empty data directory, where digibyte wallet downloads its files. There was only the `wallet.dat` file in there. As I said above, I’m in the process of moving the funds to another wallet which was created by the newer digibyte-core program. So, with the wallet emptied, I could share the dat file to debug this further, in case anyone is interested :D

…

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

Answer 17 · 2024-03-23T16:46:04.000Z

Well, as my old wallet seems hexed 😄 , I finally moved all the funds to a new one.

Maybe it is related to it being created with an old version of DigiByte-Core although it's weird it only crashed on the old transaction and not on the newer ones made this year.

I'm not sure how many people are in the same situation as me, probably not many. So, it may make sense to close this issue now.