ArmoryDB (Armory 0.96) crashing continously

[streamholder]

Hello,

ArmoryDB keeps crashing ("ArmoryDB.exe has stopped working").

I'm using Bitcoin Core 0.14.1 (which is fully synchronized and runs fine).
I tried reinstalling Armory and also deleting all Armory files. No luck.

The error is always the same & it always happens around the same "parsed block file" (I've observed it between 51 and 62).
Here's an example of the log I get when this happens: https://pastebin.com/jmyMJ0d4
After the last log line gets printed, it *always* crashes, sometimes immediately and sometimes after some interval (I observed at most 20-30 seconds before the crash). I've never observed other/different log lines after the last one of the log I published.
Also, ArmoryQt keeps running just fine after ArmoryDB crashes.

If it's of any help, the %appdata%\Bitcoin and %appdata%\Armory folders are symlinks to another hard drive, but I don't think this has anything to do with it (it should be completely transparent to applications anyway).

EDIT: will Armory 0.95.x work fine with Bitcoin Core 0.14.1? I need to get up and running pretty urgently, so while we get this sorted out I'm fine with using an older version. I just realized that 0.95.1 is what I was trying originally, and then updated to 0.96, so it probably won't help.

[goatpig]

post dbLog.txt

[streamholder]

post dbLog.txt

Here's an example of the log I get when this happens: https://pastebin.com/jmyMJ0d4

Sorry, is this not dbLog.txt?

[goatpig]

1) Delete this folder:

C:\Users\ricca\AppData\Roaming\Armory\databases

2) Make sure Core is fully synced, then shut it down

3) Start ArmoryDB on its own, let it complete building.

4) Once it says "enabling zero conf", start ArmoryQt, then report back.

[streamholder]

1) Delete this folder:

C:\Users\ricca\AppData\Roaming\Armory\databases

2) Make sure Core is fully synced, then shut it down

3) Start ArmoryDB on its own, let it complete building.

4) Once it says "enabling zero conf", start ArmoryQt, then report back.

I'm building the database on 0.95.1 right now and it seems to be working (even with Core open).
Will the same database work with 0.96 or it the new version going to rebuild it? In case the second is true, I'm going to let 0.96 ArmoryDB build the database overnight in a different folder with Core closed, and we'll see if it works. What is the parameter for ArmoryDB to specify the database folder?

[goatpig]

DBs are the same.

[streamholder]

Successfully built the database on 0.95.1, upgraded to 0.96, block rescan still crashed the database twice but third time was the charm. It seems to be working now. Still, 0.96 doesn't really strike me as stable.

EDIT: Ok - I'm unable to spend any coins. I'm using 22 satoshi/byte for the fee, which should be fine. Yesterday I was sending coins around for about 1/4 that, so I don't think it is the problem.

EDIT2: This is probably what's causing it. Gonna try to downgrade to Core 0.13.2.
EDIT3: I confirm that 0.96 still has the issue! Downgrading to Core 0.13.2 fixed it for now.

[goatpig]

EDIT3: I confirm that 0.96 still has the issue! Downgrading to Core 0.13.2 fixed it for now.

It is not. Your issue is completely different, as evidenced by your log files, and I believe I have a fix already.

If you are going to make claims about bugs, either isolate them in code or withhold your opinion, otherwise you are just spreading confusion about the state of a given issue.

[streamholder]

EDIT3: I confirm that 0.96 still has the issue! Downgrading to Core 0.13.2 fixed it for now.

It is not. Your issue is completely different, as evidenced by your log files, and I believe I have a fix already.

If you are going to make claims about bugs, either isolate them in code or withhold your opinion, otherwise you are just spreading confusion about the state of a given issue.

The log files you have are old and related to my first issue, which is not present anymore.
The new issue has the same symptoms and the same solution as the issue outlined in the thread I referenced. If it is a different issue - and you have a fix already - please explain what it is, otherwise your claims are as good as mine.

[goatpig]

The log files you have are old and related to my first issue, which is not present anymore.

This is the issue this topic covers, this is what I respond to. Again, you are confusing people mixing issues together. There are 2 paths to fixing a bug, you either PR code or isolate it for me to fix.

If it is a different issue - and you have a fix already - please explain what it is, otherwise your claims are as good as mine.

https://github.com/goatpig/BitcoinArmory/commit/a2a94e8419968cf8969b161614612c97a85bffe2

The new issue has the same symptoms and the same solution as the issue outlined in the thread I referenced

You are conflating symptoms and causes. Minimum mempool requirements such as coin-age in relation to fee floor can change per Core sub version. You are not isolating the issue in this case.

The one way to do so would be to grab the raw tx that fails to broadcast through Armory with Core 0.14.1 and push it directly from the RPC to read the error code verbose (verbose which should be available in armorylog.txt since 0.96, so I'd like to see that).

[streamholder]

The log files you have are old and related to my first issue, which is not present anymore.

This is the issue this topic covers, this is what I respond to. Again, you are confusing people mixing issues together. There are 2 paths to fixing a bug, you either PR code or isolate it for me to fix.

If it is a different issue - and you have a fix already - please explain what it is, otherwise your claims are as good as mine.

https://github.com/goatpig/BitcoinArmory/commit/a2a94e8419968cf8969b161614612c97a85bffe2

The new issue has the same symptoms and the same solution as the issue outlined in the thread I referenced

You are conflating symptoms and causes. Minimum mempool requirements such as coin-age in relation to fee floor can change per Core sub version. You are not isolating the issue in this case.

The one way to do so would be to grab the raw tx that fails to broadcast through Armory with Core 0.14.1 and push it directly from the RPC to read the error code verbose (verbose which should be available in armorylog.txt since 0.96, so I'd like to see that).

I'm not isolating the issue to a particular section of the code because I have not the knowledge or the time to do that, as Armory's codebase is quite complicated and messy and frankly my own complicated and messy codebases are more than enough. For the same reason, a particular commit that changes a few line doesn't mean much to me.
All I said (God forbid that someone takes my words as provocation, I'm just trying to move my Bitcoin and to report back to you) is that the issue that was previously decribed is not resolved, that is presents exactly the same way, and that the same workaround still works. I'm literally saying no more than that. I'm also not implying anything else, including e.g. that the underlying cause is the same. I apologize if it came through that way.

The log simply says that the transaction times out, unless I'm missing something:

Code:

2017-05-06 14:55 (INFO) -- (PPRINT from ArmoryQt.py:3088)

  01000000 0109b9db f08122b8 6bbaf955 2aff9505 e66ff6bf a7013a86 8a7aae89 
  36cdf58a c4000000 008b4830 45022100 90f9e43a 035a6cf1 dfb5acd2 a1d24aea 
  0b154a81 c8edaf0d e3d08a09 84900f5e 022025e3 b4be653a 1b438a49 14568ebd 
  00a2eda8 a745540c 4217f6e4 89a932ff 09410141 045ed39b a1aab680 5d9ab9ed 
  1a096745 e1a7bb59 667d0fed b47c7c08 7f705143 8921fd3f 55407740 a5e74614 
  960193d7 27bf41f1 abbf1aec 6952ca3c f9591aef edffffff ff013be5 3e050000 
  00001976 a914a74b 354efbe1 3422ebd6 a004d897 f274223a 53d388ac d0180700 
2017-05-06 14:55 (INFO) -- (PPRINT from ArmoryQt.py:3089)
Transaction:
   TxHash:    b470d020049677645d5ed4024844de94eaee8ad7b682e3213662ab2c0637c2cf (BE)
   Version:   1
   nInputs:   1
   nOutputs:  1
   LockTime:  465104
   Inputs: 
      PyTxIn:
         PrevTxHash: c48af5cd3689ae7a8a863a01a7bff66fe60595ff2a55f9ba6bb82281f0dbb909 (BE)
         TxOutIndex: 0
         Script:     (48304502210090f9e43a035a6cf1dfb5acd2a1d24aea0b154a81c8edaf0de3d0)
         Sender:     1QJfNJGoP8o3U2NiXUK2gm5JtcDjiP6aUN
         Seq:        4294967295
   Outputs: 
      TxOut:
         Value:   88007995 (0.88007995)
         Script:  OP_DUP OP_HASH160 (1GFZwbYTfHdcKDwCw6HZUXUJamnuz8EREK) OP_EQUALVERIFY OP_CHECKSIG

2017-05-06 14:55 (INFO) -- ArmoryQt.py:3094 - Sending Tx, cfc237062cab623621e382b6d78aeeea94de444802d45e5d6477960420d070b4
2017-05-06 14:55 (ERROR) -- Traceback (most recent call last):
  File "qtdialogs.pyc", line 1571, in execSendBtc
AttributeError: 'DlgWalletDetails' object has no attribute 'wltAddrModel'

2017-05-06 14:55 (ERROR) -- ArmoryQt.py:3108 - Transaction was not accepted by the Satoshi client
2017-05-06 14:55 (ERROR) -- ArmoryQt.py:3109 - Raw transaction:
2017-05-06 14:55 (ERROR) -- (PPRINT from ArmoryQt.py:3110)

  01000000 0109b9db f08122b8 6bbaf955 2aff9505 e66ff6bf a7013a86 8a7aae89 
  36cdf58a c4000000 008b4830 45022100 90f9e43a 035a6cf1 dfb5acd2 a1d24aea 
  0b154a81 c8edaf0d e3d08a09 84900f5e 022025e3 b4be653a 1b438a49 14568ebd 
  00a2eda8 a745540c 4217f6e4 89a932ff 09410141 045ed39b a1aab680 5d9ab9ed 
  1a096745 e1a7bb59 667d0fed b47c7c08 7f705143 8921fd3f 55407740 a5e74614 
  960193d7 27bf41f1 abbf1aec 6952ca3c f9591aef edffffff ff013be5 3e050000 
  00001976 a914a74b 354efbe1 3422ebd6 a004d897 f274223a 53d388ac d0180700 
2017-05-06 14:55 (ERROR) -- ArmoryQt.py:3111 - Transaction details
2017-05-06 14:55 (ERROR) -- (PPRINT from ArmoryQt.py:3112)
Transaction:
   TxHash:    b470d020049677645d5ed4024844de94eaee8ad7b682e3213662ab2c0637c2cf (BE)
   Version:   1
   nInputs:   1
   nOutputs:  1
   LockTime:  465104
   Inputs: 
      PyTxIn:
         PrevTxHash: c48af5cd3689ae7a8a863a01a7bff66fe60595ff2a55f9ba6bb82281f0dbb909 (BE)
         TxOutIndex: 0
         Script:     (48304502210090f9e43a035a6cf1dfb5acd2a1d24aea0b154a81c8edaf0de3d0)
         Sender:     1QJfNJGoP8o3U2NiXUK2gm5JtcDjiP6aUN
         Seq:        4294967295
   Outputs: 
      TxOut:
         Value:   88007995 (0.88007995)
         Script:  OP_DUP OP_HASH160 (1GFZwbYTfHdcKDwCw6HZUXUJamnuz8EREK) OP_EQUALVERIFY OP_CHECKSIG

2017-05-06 14:55 (ERROR) -- ArmoryQt.py:3113 - Failure message: tx broadcast timed out (send)

Entire log here (6000+ lines).

As for "This is the issue this topic covers, this is what I respond to.", sorry for mixing things up, since you are a moderator here I'm sure you can move this to a separate topic if you think it would work out better, or I can open a new topic myself if you prefer.

[achow101]

Nothing in your log indicates that the error is in any way related to the previous transaction broadcast timeout issue, even though it appears that way and the fix for that still works. Can you broadcast the raw transaction through Bitcoin Core's sendrawtransaction RPC? If you don't know how to do that, I can do it for you, the raw transaction is in the log file.

[goatpig]

For the same reason, a particular commit that changes a few line doesn't mean much to me.

I was mostly referring the commit's title.

I'm not isolating the issue to a particular section of the code because I have not the knowledge or the time to do that, as Armory's codebase is quite complicated and messy and frankly my own complicated and messy codebases are more than enough.

Which I expected. At the same time you bump 3 threads with your conclusions which only leads to more confusion about what the issue actually is. The majority of users silently parse the forum and troubleshoot themselves with the informations they find. How do you expect me not to call you out on this?

Entire log here (6000+ lines).

That's actually quite useful. Will investigate.

As for "This is the issue this topic covers, this is what I respond to.", sorry for mixing things up, since you are a moderator here I'm sure you can move this to a separate topic if you think it would work out better, or I can open a new topic myself if you prefer.

I don't modify users posts/topics unless they break the forum's general rules. What I prefer from users is that they stick to one topic per issue. Keeps the content shorter and makes it easier to search for solutions.

[streamholder]

Nothing in your log indicates that the error is in any way related to the previous transaction broadcast timeout issue, even though it appears that way and the fix for that still works. Can you broadcast the raw transaction through Bitcoin Core's sendrawtransaction RPC? If you don't know how to do that, I can do it for you, the raw transaction is in the log file.

The funds are no longer available.

I'm not isolating the issue to a particular section of the code because I have not the knowledge or the time to do that, as Armory's codebase is quite complicated and messy and frankly my own complicated and messy codebases are more than enough.

Which I expected. At the same time you bump 3 threads with your conclusions which only leads to more confusion about what the issue actually is. The majority of users silently parse the forum and troubleshoot themselves with the informations they find. How do you expect me not to call you out on this?

To be fair, it's not like they were buried 10 pages deep. They were among the latest topics. One of them was mine, another one was from a user that was still clueless and has now got a viable workaround, and the third one, well, fair enough, I'm sorry.
Just to be entirely clear, I didn't/don't expect you to do anything, I barely know you. I was trying to relay my finding on the matter, not to trigger a specific reaction from you.

Entire log here (6000+ lines).

That's actually quite useful. Will investigate.

As for "This is the issue this topic covers, this is what I respond to.", sorry for mixing things up, since you are a moderator here I'm sure you can move this to a separate topic if you think it would work out better, or I can open a new topic myself if you prefer.

I don't modify users posts/topics unless they break the forum's general rules. What I prefer from users is that they stick to one topic per issue. Keeps the content shorter and makes it easier to search for solutions.

Ok.