Armory 0.93 testing release! (with 0.05 BTC bug bounty)

[hardhouseinc]

Support ticket submitted but trying to find some quicker answers
Here if anyone else has seen the same problems.


I have tried EVERYTHING now with no luck.
Installed new Armory V0.93
Opened Armory in Offline mode and then did a full factory reset.
Installed new BitcoinQT V0.10
RE-Downloaded full blockchain with BitCoinQT.
Verified blockchain with BitCoinQT / verified green check mark and full start of BitCoinQT.

Shutdown BitCoinQT and start Armory normally.
Loading BTC.
Organizing Blockchain approximately 2+ hours EVERY time Armory started.

If wallet is deleted / opens OK.
All wallets deleted and new wallet created for further troubleshooting.
Problem persists on old and newest version of Armory using both 0.9.3 and
newest version of BitCoinQT.

I have a question based on the new DB size, when using supernode will the DB still be as large as it is now?

No supernode is huge, ~90GB currently.

I got same problem of BDM error box.  It asks me to rebuild and rescan.  I did it twice and it loads once correctly, then after next time same error.
Anyone fix this?

That was done on previous version to try and fix the problem but I had no luck.
Im trying to download now AGAIN, full factory reset, to see if that may work now on
the newest version.

Open a support ticket, attach log files.

[1714616674]

1714616674

[btchris]

is now showing "Building Databases 61.5%"

Are you sure you're running 0.93 (this is the 0.93 thread after all...)?

0.92 and older had a Building Databases step, 0.93 replaced this with a much faster (1 - 2 hours long) Organizing Blockchain step AFAIK.

[Searinox]

is now showing "Building Databases 61.5%"

Are you sure you're running 0.93 (this is the 0.93 thread after all...)?

0.92 and older had a Building Databases step, 0.93 replaced this with a much faster (1 - 2 hours long) Organizing Blockchain step AFAIK.

It does appear to be building it much faster, but it then gets stuck at ~18.9GB.

https://i.imgur.com/MFB1sDv.png?1 Help -> About picture
http://pastebin.com/raw.php?i=HVazH8aS Recent Armory log since the 18.9GB DB loop.

EDIT: Laptop now also got stuck with a 20.0GB Data_Armory folder. That's two different machines.

Also, both Armories, when asked to Quit go to "Preparing to shut down..." and just stay there intermittently, with the UI still responsive, until Quit is selected again, then it actually closes.

[goatpig]

--datadir=E:\Program Files (x86)\Armory\Data_Armory

Is this your "system" program files? Can't have the datadir in a restricted folder

EDIT: Laptop now also got stuck with a 20.0GB Data_Armory folder. That's two different machines.

Same copy of the blockchain on both machines? Can I see the other log file?

[Searinox]

--datadir=E:\Program Files (x86)\Armory\Data_Armory

Is this your "system" program files? Can't have the datadir in a restricted folder

Again, I said this

I've not been using the torrent ever. Everything is running with admin privs as UAC has been disabled from day 1 of windows install(5.5 years ago) and there is only one admin account on the pc.

There are no restrictions, no UAC, also the node has been running fine for almost a year. Me and Armory both have write access rights to the folder, as Armory HAS been creating a database in Data_Armory, si it is clearly able to write to it. And in any case no, neither the desktop nor the laptop have datadir in the system program files, those are on C: and the armory ones are on drives D: and E: respectively where i manually created the folders and put in whatever didn't fit on C:.

The database, after some Armory restarts, has stuck at 18.9GB on the Desktop and refuses to go up despite intense activity. Upon relaunch, a handful new blocks that emerged over the past few hours are downloaded, it catches up, then proceeds back to the Database building part, where the progress indicators completely freeze despite the program continuing to run. On the Laptop the exact same is happening, except after a few restarts and a crash it finally climbed from 20GB to 22.1GB. The UI behaves exactly the same, no progress bar activity on Building DB, no percent change, spinning disk animation is still, but the UI works, I can check wallet etc and unexplained constant harddisk activity.

This is the laptop log. http://pastebin.com/raw.php?i=9R3tF96P

[goatpig]

Ok, what about this then:

Same copy of the blockchain on both machines?

Also, pick whatever machine, delete the databases folder and the log files, start Armory and let it run till it crashes, then post the fresh logs.

[Searinox]

No, they each downloaded the blockchain independently from scratch. I don't know if I can replicate that crash, it was a one-off oddity. It had run for 24h+ building the blockchain then armory db without a single crash and I restarted it repeatedly, it crashed once then didn't when I relaunched it. I'll see what I can do. Since you're only asking questions despite seeing both machines' logs I'm guessing the logs were of no help?

[goatpig]

No, they each downloaded the blockchain independently from scratch. I don't know if I can replicate that crash, it was a one-off oddity. It had run for 24h+ building the blockchain then armory db without a single crash and I restarted it repeatedly, it crashed once then didn't when I relaunched it. I'll see what I can do. Since you're only asking questions despite seeing both machines' logs I'm guessing the logs were of no help?

The logs don't have the one good hint I was hoping for. On the other hand I didn't pick that the error is not deterministic at first. That's an interesting point on its own. I was under the impression the error was occurring 100% under the "right" conditions, which is why I hoped a fresh log + fresh db folder would really outline the exact error.

Have you seen any pattern in the bug appearance? What would you say is the failure to success ratio?

If you can't get it to fail when it's starting from scratch then just report it and that's about it. I'll have to get my clue from some other vector.

[Searinox]

No, they each downloaded the blockchain independently from scratch. I don't know if I can replicate that crash, it was a one-off oddity. It had run for 24h+ building the blockchain then armory db without a single crash and I restarted it repeatedly, it crashed once then didn't when I relaunched it. I'll see what I can do. Since you're only asking questions despite seeing both machines' logs I'm guessing the logs were of no help?

The logs don't have the one good hint I was hoping for. On the other hand I didn't pick that the error is not deterministic at first. That's an interesting point on its own. I was under the impression the error was occurring 100% under the "right" conditions, which is why I hoped a fresh log + fresh db folder would really outline the exact error.

Have you seen any pattern in the bug appearance? What would you say is the failure to success ratio?

If you can't get it to fail when it's starting from scratch then just report it and that's about it. I'll have to get my clue from some other vector.

While I cannot get it to CRASH from scratch, both the fresh startup with no DBs and subsequent startups all do the same thing 100%: They build the DB in "silence" with the status part of the UI unresponsive, then, at some point during the Armory DB building part, they stop progressing for no apparent reason around 19-20GB size, while the disk activity continues to be intense. Once they reach that, they stay there indefinetly. Subsequent restarts of the app will show Armory catch up with the extra few blocks that popped up on the network during that time, but once they get back to building the Armory DB they again stop and they remain that way, best I've checked, for at least 6 hours. Since the initial 20GB are built in less than 2 hours, I doubt the remaining 9GB of Armory DB are actually taking that long.

The other thing to point out, again with 100% occurrence, is closing the Armory once it is in this state. The UI says a big "Preparing to shut down" on the main page, but remains stuck at that stage while still using the HDD. It takes a second go to the File -> Quit Armory for it to close, and then it does it in a few seconds. Usually when an app cannot shut down it doesn't "try harder" the second time you ask it, it either eventually does it from the initial command or it doesn't at all and has to be killed through forced end task, but in this case Armory actually requires me to issue the Quit Armory option twice in order to close.

I have checked my task manager and can find no phantom armory/bitcoind/guardian processes, so it's also not the case of a previous lingering process. I really am confused.

[goatpig]

While I cannot get it to CRASH from scratch, both the fresh startup with no DBs and subsequent startups all do the same thing 100%: They build the DB in "silence" with the status part of the UI unresponsive, then, at some point during the Armory DB building part, they stop progressing for no apparent reason around 19-20GB size, while the disk activity continues to be intense. Once they reach that, they stay there indefinetly. Subsequent restarts of the app will show Armory catch up with the extra few blocks that popped up on the network during that time, but once they get back to building the Armory DB they again stop and they remain that way, best I've checked, for at least 6 hours. Since the initial 20GB are built in less than 2 hours, I doubt the remaining 9GB of Armory DB are actually taking that long.

The other thing to point out, again with 100% occurrence, is closing the Armory once it is in this state. The UI says a big "Preparing to shut down" on the main page, but remains stuck at that stage while still using the HDD. It takes a second go to the File -> Quit Armory for it to close, and then it does it in a few seconds. Usually when an app cannot shut down it doesn't "try harder" the second time you ask it, it either eventually does it from the initial command or it doesn't at all and has to be killed through forced end task, but in this case Armory actually requires me to issue the Quit Armory option twice in order to close.

I have checked my task manager and can find no phantom armory/bitcoind/guardian processes, so it's also not the case of a previous lingering process. I really am confused.

Ok so, do the original thing I asked for: wipe your log files and database folder on either of your machines, let it start fresh all the way up to the point where it gets stuck. Then kill the process and give me the logs. I think that'll yield some interesting data.

[zombieslayer9099]

I found another bug: When signing any multisig/simulfunding transaction that will not be broadcast yet, attempting to close the window by pressing X has no effect. Can a Done button be added to these?

[doug_armory]

I found another bug: When signing any multisig/simulfunding transaction that will not be broadcast yet, attempting to close the window by pressing X has no effect. Can a Done button be added to these?

That's probably another Qt bug. (I know you're a Mac user.) Adding a button should be doable. I'll get that going. Thanks for the report.

[TimS]

0.92.99.7 supernode, Windows 7
I had two new transactions today, one sending and then one receiving. Both showed up when they had 0-conf, and then disappeared later, making Armory show an incorrect balance. I think each disappeared when it got a confirmation. Upgraded to 0.93, ran Help > Clear All Unconfirmed, and restarted Armory several times with no change.
Something that might have had an impact on this was that I also had a wallet loaded into Armory with ~131,000 imported private keys and many transactions on those addresses.

Wallet size will not impact supernode at all. This is some sort of scanning corner case. Can you see these transaction as part of the main chain in bc.info? I won't be going directly after this since I'm currently modifying a bunch of stuff in supernode for more stability and speed (this is for 0.93.1)

Yes, the transactions appear in the main chain, and no orphaned/other blocks (that bc.info is aware of).

I'm still having this issue in 0.93 and the current 0.93-bugfix branch (0.93-beta-a4561d1fa9 is what shows up in About): a perfectly ordinary transaction appears when it has 0-conf, then disappears when it gets 1 confirmation (until I rescan, which takes a long time).

This appears in the log every time it encounters a new block:

Code:

-ERROR - 1425181756: (..\StoredBlockObj.cpp:1863) We should've found an unpsent txio in the subSSH but didn't
-ERROR - 1425181756: (..\BlockUtils.cpp:1585) Error adding block data: missing txio!

Also, maybe related, I have these lines repeated many times in my log files, from 2-20:

Code:

2015-02-20 18:17 (ERROR) -- Traceback (most recent call last):
  File "armorymodels.pyc", line 1102, in data
  File "CppBlockUtils.pyc", line 1729, in getScrAddrObjByKey
RuntimeError: no ScrAddr matches key 

2015-02-20 18:17 (ERROR) -- Traceback (most recent call last):
  File "armorymodels.pyc", line 1169, in data
  File "CppBlockUtils.pyc", line 1729, in getScrAddrObjByKey
RuntimeError: no ScrAddr matches key 

2015-02-20 18:17 (ERROR) -- Traceback (most recent call last):
  File "armorymodels.pyc", line 1128, in data
  File "CppBlockUtils.pyc", line 1729, in getScrAddrObjByKey
RuntimeError: no ScrAddr matches key 



-ERROR - 1425164415: (..\BlockWriteBatcher.cpp:429) STXO needs to be re-added/marked-unspent but it
-ERROR - 1425164415: (..\BlockWriteBatcher.cpp:430) was already declared unspent in the DB

-WARN  - 1425164415: (..\StoredBlockObj.cpp:1883) failed to erase txio in subshh: doesn't exist!

[goatpig]

How often does this happen? Is it always the same address?

[Searinox]

Where can I get this new 0.93.1 beta? I need it as I have been completely unable to properly run 0.93.

[doug_armory]

Where can I get this new 0.93.1 beta? I need it as I have been completely unable to properly run 0.93.

It's not out yet. We're still testing a fix for a major issue several people have been seeing. We'll post here when the new version is ready.

[goatpig]

This appears in the log every time it encounters a new block:

Code:

-ERROR - 1425181756: (..\StoredBlockObj.cpp:1863) We should've found an unpsent txio in the subSSH but didn't
-ERROR - 1425181756: (..\BlockUtils.cpp:1585) Error adding block data: missing txio!

Also, maybe related, I have these lines repeated many times in my log files, from 2-20:

Code:

2015-02-20 18:17 (ERROR) -- Traceback (most recent call last):
  File "armorymodels.pyc", line 1102, in data
  File "CppBlockUtils.pyc", line 1729, in getScrAddrObjByKey
RuntimeError: no ScrAddr matches key 

2015-02-20 18:17 (ERROR) -- Traceback (most recent call last):
  File "armorymodels.pyc", line 1169, in data
  File "CppBlockUtils.pyc", line 1729, in getScrAddrObjByKey
RuntimeError: no ScrAddr matches key 

2015-02-20 18:17 (ERROR) -- Traceback (most recent call last):
  File "armorymodels.pyc", line 1128, in data
  File "CppBlockUtils.pyc", line 1729, in getScrAddrObjByKey
RuntimeError: no ScrAddr matches key 



-ERROR - 1425164415: (..\BlockWriteBatcher.cpp:429) STXO needs to be re-added/marked-unspent but it
-ERROR - 1425164415: (..\BlockWriteBatcher.cpp:430) was already declared unspent in the DB

-WARN  - 1425164415: (..\StoredBlockObj.cpp:1883) failed to erase txio in subshh: doesn't exist!

I just realized you are using supernode =P. I'm halfway through what I expect is the last change to the DB structure, it will speed up the scanning, with more scalability and stability, and will nuke this issue among others. That'll be packed with the extra slim fullnode version, but it won't be the release we'll put out this week. That one is for emergency bug fixes.

[naska21]

After instalation  and launch of 0.93 on Win XP got "C:/......./ArmoryQt.exe is not valid Win32 application"   

Need to roll back to 0.92.3

Will my  0.93 on-line Armory/Win 7 properly communicate with 0.92.3/ Win XP used as offline ?

[Carlton Banks]

After instalation  and launch of 0.93 on Win XP got "C:/......./ArmoryQt.exe is not valid Win32 application"  

Need to roll back to 0.92.3

Will my  0.93 on-line Armory/Win 7 properly communicate with 0.92.3/ Win XP used as offline ?

I'm afraid it's all true! ArmoryQt.exe isn't a valid Win32 application, and that's a problem with your offline XP machine as it appears to be 32-bit windows. Armory 0.93.0 is all 64-bit. I think goatpig may have promised a 32-bit Windows build of 0.93.next-sub-version. If not, 92.3 still uses the same format for signatures, so you'll be OK no matter what.

[goatpig]

After instalation  and launch of 0.93 on Win XP got "C:/......./ArmoryQt.exe is not valid Win32 application"   

Need to roll back to 0.92.3

Will my  0.93 on-line Armory/Win 7 properly communicate with 0.92.3/ Win XP used as offline ?

Yes, 0.92.x can manage wallets and sign transactions created from 0.93