Bitcoin Forum

Bitcoin => Armory => Topic started by: hashtag on August 14, 2020, 04:07:57 PM



Title: Armory returns to the send window instead of asking for password and sending
Post by: hashtag on August 14, 2020, 04:07:57 PM
It worked fine earlier today, but now when i click "send" it asks me to confirm im ok with the low fee and then returns to the send window instead of asking for password and sending as it did before.
I haven't changed or anything on that install.


Title: Re: Armory returns to the send window instead of asking for password and sending
Post by: goatpig on August 14, 2020, 06:03:24 PM
Post your logs.


Title: Re: Armory returns to the send window instead of asking for password and sending
Post by: hashtag on August 17, 2020, 08:13:43 AM
Quote
2020-08-17 11:11:11 (ERROR) -- Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 948, in createTxAndBroadcast
    ustx = self.validateInputsGetUSTX()
  File "/usr/lib/armory/ui/TxFrames.py", line 902, in validateInputsGetUSTX
    lockTime=TheBDM.getTopBlockHeight())
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2513, in createFromTxOutSelection
    return self.createFromPyTx(thePyTx, pubKeyMap, txMap, p2shMap)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2414, in createFromPyTx
    cppPrevTx = TheBDM.bdv().getTxByHash(txhash)
  File "/usr/lib/armory/CppBlockUtils.py", line 1662, in getTxByHash
    def getTxByHash(self, *args): return _CppBlockUtils.BlockDataViewer_getTxByHash(self, *args)
DbErrorMsg: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7f4929064300> >

2020-08-17 11:11:37 (ERROR) -- Traceback (most recent call last):
  File "/usr/lib/armory/ui/TxFrames.py", line 948, in createTxAndBroadcast
    ustx = self.validateInputsGetUSTX()
  File "/usr/lib/armory/ui/TxFrames.py", line 902, in validateInputsGetUSTX
    lockTime=TheBDM.getTopBlockHeight())
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2513, in createFromTxOutSelection
    return self.createFromPyTx(thePyTx, pubKeyMap, txMap, p2shMap)
  File "/usr/lib/armory/armoryengine/Transaction.py", line 2414, in createFromPyTx
    cppPrevTx = TheBDM.bdv().getTxByHash(txhash)
  File "/usr/lib/armory/CppBlockUtils.py", line 1662, in getTxByHash
    def getTxByHash(self, *args): return _CppBlockUtils.BlockDataViewer_getTxByHash(self, *args)
DbErrorMsg: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7f49291c6c60> >


Title: Re: Armory returns to the send window instead of asking for password and sending
Post by: goatpig on August 17, 2020, 02:39:05 PM
Need to see the full log. This error can be a false positive, if it's trying to fetch the hash for the tx you are creating.


Title: Re: Armory returns to the send window instead of asking for password and sending
Post by: hashtag on August 17, 2020, 04:40:18 PM
here is the full thing
https://paste.ubuntu.com/p/54Q2zQzrTj/



please note this is from Ubuntu 19.10 in VirtualBox (because of the py3 issue) with .bitcoin and .armory folders shared from the host. But it used to work just fine.


Title: Re: Armory returns to the send window instead of asking for password and sending
Post by: hashtag on August 17, 2020, 04:45:32 PM
actually after further testing sending still works for the other wallets in armory but this particular one.
I have used it on the host system before upgrading to ubuntu 20.04 and it worked, now is the first time im trying to use it in the VM and it doesn't.

The only difference I see between the non-working one and the others is that it has 1 pending transaction (but I'm not using its coin, using coin control to select confirmed transaction) and the password is longer.


Title: Re: Armory returns to the send window instead of asking for password and sending
Post by: goatpig on August 17, 2020, 07:31:45 PM
Then it's a DB corruption issue. You need to rebuild & rescan the DB to fix the issue.


Title: Re: Armory returns to the send window instead of asking for password and sending
Post by: hashtag on August 24, 2020, 03:13:04 PM
yes that fixed it, thanks!