Wallet appears for one second, but then coredumps.
Expected behavior
The wallet should start as it did in the previous SDL release, v 1.5.3.
Desktop (please complete the following information):
OS: Arch Linux running SDL v 2.0.0
Additional context
This behaviour did not happen on the previous SDL release, v 1.5.3. Thought it may have been broken due to stickyserver being set, but it still coredumped after that was not set.
**Describe the bug**
SDL v 2.0.0 keeps coredumping
**To Reproduce**
Steps to reproduce the behavior:
1. Start silentdragonlite.
2. Enter password to decrypt wallet.
3. Wallet appears for one second, but then coredumps.
**Expected behavior**
The wallet should start as it did in the previous SDL release, v 1.5.3.
**Desktop (please complete the following information):**
- OS: Arch Linux running SDL v 2.0.0
**Additional context**
This behaviour did not happen on the previous SDL release, v 1.5.3. Thought it may have been broken due to stickyserver being set, but it still coredumped after that was not set.
from the line before the coredump, it is attempting to allocate 2819485 terabytes of RAM, so that is definitely a clue that something is rotten in the state of Denmark
from the line before the coredump, it is attempting to allocate 2819485 terabytes of RAM, so that is definitely a clue that something is rotten in the state of Denmark
@duke it does not coredump, but instead creates another error. Should I change this issue to "SDL 2.0.0 is not functioning" or close this issue & create a new bug with the new error message where SDL 2.0.0 is not functioning correctly?
@duke it does not coredump, but instead creates another error. Should I change this issue to "SDL 2.0.0 is not functioning" or close this issue & create a new bug with the new error message where SDL 2.0.0 is not functioning correctly?
StickyServer in config is set to True (stickyServer=true)
Server configured is server=https://wtfistheinternet.hush.is
SDL GUI Displays the following error message, which is strange as SDL config explicitly calls out a stickied SDL server to use always: "Error when connecting to https://lite.hush.land: Error: Address length too large: 3100056916416461072"
Running SDL from the CLI shows the following
$ ./SilentDragonLite
Loading locale "en"
slot_change_theme : theme_name= "Dark"
slot_change_theme : attempting to open filename= ":/css/res/css/Dark.css"
MainWindow : decrypting wallet= "/home/<<USER-OMITTED>>/.silentdragonlite/silentdragonlite-wallet-enc.dat"
removeWalletEncryptionStartUp : removing wallet encryption
Blake3 Hash: <<OMITTED>>
removeWalletEncryptionStartUp : wallet size= 10399662
Animation dark loaded
Set animation
getSettings
"https://wtfistheinternet.hush.is" is sticky
getSettings
"https://wtfistheinternet.hush.is" is sticky
"loadConnection" : calling doAutoConnect
getSettings
"https://wtfistheinternet.hush.is" is sticky
"doAutoConnect" : Creating connection with server= "https://wtfistheinternet.hush.is"
"doAutoConnect" : Attempting to initialize library with "https://wtfistheinternet.hush.is"
Wallet exists: true
"doAutoConnect" : using existing wallet
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
getRandomServer
Checking if lite server "https://lite.hush.land" is a alive, try= 0
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
Checking if lite server "https://lite.hushpool.is" is a alive, try= 1
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
Checking if lite server "https://lite2.hushpool.is" is a alive, try= 2
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
Checking if lite server "https://lite.hush.is" is a alive, try= 3
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
Checking if lite server "https://lite.hush.community" is a alive, try= 4
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
Checking if lite server "https://lite.myhush.org" is a alive, try= 5
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
Checking if lite server "https://wtfistheinternet.hush.is" is a alive, try= 6
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
Checking if lite server "https://poop.granitefone.me" is a alive, try= 7
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
Branch used: https://git.hush.is/lucretius/SilentDragonLite/src/branch/alloc
Commit used: https://git.hush.is/lucretius/SilentDragonLite/commit/a9fee8c1f0243da87bd2ba49219484eeb2617804
Issue:
- StickyServer in config is set to True (`stickyServer=true`)
- Server configured is `server=https://wtfistheinternet.hush.is`
- SDL GUI Displays the following error message, which is strange as SDL config explicitly calls out a stickied SDL server to use always: "Error when connecting to https://lite.hush.land: Error: Address length too large: 3100056916416461072"
- Running SDL from the CLI shows the following
```
$ ./SilentDragonLite
Loading locale "en"
slot_change_theme : theme_name= "Dark"
slot_change_theme : attempting to open filename= ":/css/res/css/Dark.css"
MainWindow : decrypting wallet= "/home/<<USER-OMITTED>>/.silentdragonlite/silentdragonlite-wallet-enc.dat"
removeWalletEncryptionStartUp : removing wallet encryption
Blake3 Hash: <<OMITTED>>
removeWalletEncryptionStartUp : wallet size= 10399662
Animation dark loaded
Set animation
getSettings
"https://wtfistheinternet.hush.is" is sticky
getSettings
"https://wtfistheinternet.hush.is" is sticky
"loadConnection" : calling doAutoConnect
getSettings
"https://wtfistheinternet.hush.is" is sticky
"doAutoConnect" : Creating connection with server= "https://wtfistheinternet.hush.is"
"doAutoConnect" : Attempting to initialize library with "https://wtfistheinternet.hush.is"
Wallet exists: true
"doAutoConnect" : using existing wallet
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
getRandomServer
Checking if lite server "https://lite.hush.land" is a alive, try= 0
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
Checking if lite server "https://lite.hushpool.is" is a alive, try= 1
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
Checking if lite server "https://lite2.hushpool.is" is a alive, try= 2
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
Checking if lite server "https://lite.hush.is" is a alive, try= 3
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
Checking if lite server "https://lite.hush.community" is a alive, try= 4
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
Checking if lite server "https://lite.myhush.org" is a alive, try= 5
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
Checking if lite server "https://wtfistheinternet.hush.is" is a alive, try= 6
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
Checking if lite server "https://poop.granitefone.me" is a alive, try= 7
Reading wallet version 9
TxId bytes: [8, 215, 140, 181, 5, 60, 233, 14, 157, 215, 23, 77, 99, 55, 144, 108, 92, 98, 22, 49, 73, 236, 14, 251, 222, 90, 60, 118, 201, 17, 189, 163]
Read address length: 3100056916416461072
Address length too large: 3100056916416461072
Error reading WalletTx: Address length too large: 3100056916416461072
```
Since this computer's SDL wallet has been around for some time, I compared the SDL conf file against that of a fresh SDL install and it contains the following which is not in the fresh install:
Since this computer's SDL wallet has been around for some time, I compared the SDL conf file against that of a fresh SDL install and it contains the following which is not in the fresh install:
```
[mobileapp]
allowinternet=false
connectedname=
lastconnectedover=2
lastseentime=1638688400
localnoncehex=e70200000000000000000000000000000000000000000000
remotenoncehex=260000000000000000000000000000000000000000000000
secret=
```
Would any of this cause this issue?
@jahway603 FYI your entire config file is related to the old deleted feature of pairing a mobile app to SDL. You can delete all of it, as suggested by @lucretius . I don't think it's related to this bug but it doesn't hurt to reduce the number of variables we are debugging.
@jahway603 FYI your entire config file is related to the old deleted feature of pairing a mobile app to SDL. You can delete all of it, as suggested by @lucretius . I don't think it's related to this bug but it doesn't hurt to reduce the number of variables we are debugging.
@jahway603@lucretius I think I can explain why SDL GUI Displays the following error message, which is strange as SDL config explicitly calls out a stickied SDL server to use always: "Error when connecting to https://lite.hush.land: ... is happening. In the past, if a sticky server was down, SDL would basically be stuck and stay disconnected. But with the addition of the code that I wrote since 1.5.3 to retry servers in more places, it doesn't check if the current server is sticky and tries to talk to new random servers anyway. This should probably be considered a bug.
I discovered this by adding the @lucretius git repo as a remote and then looking at the code diff between the 1.5.3 release and the alloc branch with this command:
git diff v1.5.3...lucretius/alloc
There is actually quite a lot of code change, and only some of it is related to the new mempool code. Even so, I don't see anything directly in the SDL repo that changes how addresses are handled, so my guess on what code change causes the "Address length too large" bug is related to using different code in this dependency update that is in the diff:
@jahway603 @lucretius I think I can explain why `SDL GUI Displays the following error message, which is strange as SDL config explicitly calls out a stickied SDL server to use always: "Error when connecting to https://lite.hush.land: ...` is happening. In the past, if a sticky server was down, SDL would basically be stuck and stay disconnected. But with the addition of the code that I wrote since 1.5.3 to retry servers in more places, it doesn't check if the current server is sticky and tries to talk to new random servers anyway. This should probably be considered a bug.
I discovered this by adding the @lucretius git repo as a remote and then looking at the code diff between the 1.5.3 release and the alloc branch with this command:
```git diff v1.5.3...lucretius/alloc```
There is actually quite a lot of code change, and only some of it is related to the new mempool code. Even so, I don't see anything directly in the SDL repo that changes how addresses are handled, so my guess on what code change causes the "Address length too large" bug is related to using different code in this dependency update that is in the diff:
```
diff --git a/lib/Cargo.toml b/lib/Cargo.toml
index 11e08b7..8b2a775 100644
--- a/lib/Cargo.toml
+++ b/lib/Cargo.toml
@@ -12,4 +12,4 @@ crate-type = ["staticlib"]
libc = "0.2.58"
lazy_static = "1.4.0"
blake3 = "0.3.4"
-silentdragonlitelib = { git = "https://git.hush.is/hush/silentdragonlite-cli", rev = "0181b16fd037f98c760e668bb6af8a41dd0d6267" }
+silentdragonlitelib = { git = "https://git.hush.is/lucretius/silentdragonlite-cli", rev = "fbb8cd1a12bfed4a094c470ffdfabcedec384a51" }
```
currently txid_bytes is logged as debugging but I don't think that is very useful. The txid seems valid and does not contain addresses. The bug is related to the IncomingTxMetadata data structure. We may want to log the entire IncomingTxMetadata data structure to see what is going on.
It needs more error checking. For instance, the address inside IncomingTxMetadata is just listed as a String but it should have a minimum and maximum length that is checked. I see one part of the code checks against a max length of 120 but all zaddrs are of length 78 so that should be changed to 78. We could also verify it has a minimum length, which would be 34 bytes.
The address seems to come from the output of the encode_payment_address function but the return value of that function is not checked, it might be null or invalid and that might be causing this bug. So, every place where we do something like
let addr = encode_payment_address(...)
we should verify that we get a valid looking address (which could be a transparent or zaddr). A simple "valid address" function could just check that the prefix of the address is either R or zs1 and that is has a max length of 78 and min length of 34. I think if we do that we will narrow down exactly where this bug is coming from.
@lucretius my suggestion for where to look for this bug is in the code diff of silentdragonlite-cli . I used
```
git diff 0181b16fd037f98c760e668bb6af8a41dd0d6267..fbb8cd1a12bfed4a094c470ffdfabcedec384a51
```
to look at it. Here are my thoughts :
currently `txid_bytes` is logged as debugging but I don't think that is very useful. The txid seems valid and does not contain addresses. The bug is related to the `IncomingTxMetadata` data structure. We may want to log the entire `IncomingTxMetadata` data structure to see what is going on.
It needs more error checking. For instance, the address inside IncomingTxMetadata is just listed as a `String` but it should have a minimum and maximum length that is checked. I see one part of the code checks against a max length of 120 but all zaddrs are of length 78 so that should be changed to 78. We could also verify it has a minimum length, which would be 34 bytes.
The address seems to come from the output of the `encode_payment_address` function but the return value of that function is not checked, it might be null or invalid and that might be causing this bug. So, every place where we do something like
```
let addr = encode_payment_address(...)
```
we should verify that we get a valid looking address (which could be a transparent or zaddr). A simple "valid address" function could just check that the prefix of the address is either `R` or `zs1` and that is has a max length of 78 and min length of 34. I think if we do that we will narrow down exactly where this bug is coming from.
Describe the bug
SDL v 2.0.0 keeps coredumping
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The wallet should start as it did in the previous SDL release, v 1.5.3.
Desktop (please complete the following information):
Additional context
This behaviour did not happen on the previous SDL release, v 1.5.3. Thought it may have been broken due to stickyserver being set, but it still coredumped after that was not set.
from the CLI:
from the line before the coredump, it is attempting to allocate 2819485 terabytes of RAM, so that is definitely a clue that something is rotten in the state of Denmark
@jahway603 I think @lucretius has fixed this bug, correct?
@duke it does not coredump, but instead creates another error. Should I change this issue to "SDL 2.0.0 is not functioning" or close this issue & create a new bug with the new error message where SDL 2.0.0 is not functioning correctly?
@jahway603 document the latest details and what commit/branch you are using here sounds fine
Branch used: https://git.hush.is/lucretius/SilentDragonLite/src/branch/alloc
Commit used:
a9fee8c1f0Issue:
stickyServer=true)server=https://wtfistheinternet.hush.isSince this computer's SDL wallet has been around for some time, I compared the SDL conf file against that of a fresh SDL install and it contains the following which is not in the fresh install:
Would any of this cause this issue?
Same issues whether I compile with rustc 1.49 or 1.63
@jahway603 FYI your entire config file is related to the old deleted feature of pairing a mobile app to SDL. You can delete all of it, as suggested by @lucretius . I don't think it's related to this bug but it doesn't hurt to reduce the number of variables we are debugging.
@jahway603 @lucretius I think I can explain why
SDL GUI Displays the following error message, which is strange as SDL config explicitly calls out a stickied SDL server to use always: "Error when connecting to https://lite.hush.land: ...is happening. In the past, if a sticky server was down, SDL would basically be stuck and stay disconnected. But with the addition of the code that I wrote since 1.5.3 to retry servers in more places, it doesn't check if the current server is sticky and tries to talk to new random servers anyway. This should probably be considered a bug.I discovered this by adding the @lucretius git repo as a remote and then looking at the code diff between the 1.5.3 release and the alloc branch with this command:
git diff v1.5.3...lucretius/allocThere is actually quite a lot of code change, and only some of it is related to the new mempool code. Even so, I don't see anything directly in the SDL repo that changes how addresses are handled, so my guess on what code change causes the "Address length too large" bug is related to using different code in this dependency update that is in the diff:
@lucretius my suggestion for where to look for this bug is in the code diff of silentdragonlite-cli . I used
to look at it. Here are my thoughts :
currently
txid_bytesis logged as debugging but I don't think that is very useful. The txid seems valid and does not contain addresses. The bug is related to theIncomingTxMetadatadata structure. We may want to log the entireIncomingTxMetadatadata structure to see what is going on.It needs more error checking. For instance, the address inside IncomingTxMetadata is just listed as a
Stringbut it should have a minimum and maximum length that is checked. I see one part of the code checks against a max length of 120 but all zaddrs are of length 78 so that should be changed to 78. We could also verify it has a minimum length, which would be 34 bytes.The address seems to come from the output of the
encode_payment_addressfunction but the return value of that function is not checked, it might be null or invalid and that might be causing this bug. So, every place where we do something likewe should verify that we get a valid looking address (which could be a transparent or zaddr). A simple "valid address" function could just check that the prefix of the address is either
Rorzs1and that is has a max length of 78 and min length of 34. I think if we do that we will narrow down exactly where this bug is coming from.