Topic: Armory 0.93 testing release! (with 0.05 BTC bug bounty) - page 24. (Read 35695 times)

This must be a subtle bug of some sort. I'm running OSX 10.9.5 (I'll upgrade to 10.10 soon) with an SSD, and I've never had issues with DB building. My 10.10 VM works fine too. Perhaps you're running a bit low on space? I'm not aware of any other potential causes right now, as this seems to happen to some people on every OS.

Thanks.

Finally finished building the database while I'm out, now scanning transaction history. 9% done, 15 hours to go.

Is there any way armory could use a GPU as well as a CPU to help speed these up?

I just noticed one more thing in the logs.

-INFO  - 1420984504: (BlockUtils.cpp:1119) Starting at block file 216 offset 124278660
-INFO  - 1420984504: (BlockUtils.cpp:1121) Block height 338437
-DEBUG - 1420984504: (Blockchain.cpp:208) Organizing chain w/ rebuild
-INFO  - 1420984816: (BlockUtils.cpp:1236) Loading block data... file 21 offset 45157597

-INFO  - 1421068874: (BlockUtils.cpp:1119) Starting at block file 217 offset 39342749
-INFO  - 1421068874: (BlockUtils.cpp:1121) Block height 338585
-DEBUG - 1421068875: (Blockchain.cpp:208) Organizing chain w/ rebuild
-INFO  - 1421069155: (BlockUtils.cpp:1236) Loading block data... file 48 offset 62952398

it took 18 hours here to build the database running on ssd drive

On my machine, according to current estimates, yes, 6-7 days appears to be realistic to scan transactions for a supernode. I'm not surprised that the times are higher than for a standard node in the old version, but not being able to see the bottleneck does have me concerned. (if it were obviously pegging the HDD access, memory access, or one core of CPU, for instance, I would understand it)

Wait, so scanning transactions takes 6 days on average, you're saying?
If it really takes that long, I'm waiting for 0.93 stable release, I'll take my chances with 0.92.3(0.92.3 worked fine with 0.10).

I'm having the same problems/questions (I'm using --supernode, haven't tried without it): slow database building, about 1 MB/sec disk access during database building and 1-3 MB/sec during transaction scanning instead of max (about 30 MB/sec on my HDD), and now that the database is built, even slower transaction scanning (estimate ranging from 3 days to 2 weeks, usually about 6 days). What is the bottleneck here, since it's obviously not CPU (24 mins of CPU time used in 17 hours of running - usually 0-1% use) or hard drive access?

Mine goes slightly slower than yours, and it fluctuates the exact same way, and building databases is the only thing that is so slow. Loading headers, organizing blockchain all take less than 5 mins and 20 mins respectively.
My Bitcoin QT also disconnects, then reconnects roughly every 1:45 hours.

I noticed that read/write ops are running at the same speed that random ones do. Perhaps Armory or its new DB format isn't writing correctly?

I also have a Windows computer building databases right now, but it's going at about the same speed as jammer's(Windows 8, better hardware, etc).

bug:

if running out of disk space during --supernode database build, armory will do a segmentatiion fault..

restarting will close armory with (still full disk)

-WARN  - 1421048897: (BlockUtils.cpp:863) Scanning from 329539 to 338605
terminate called after throwing an instance of 'LMDBException'
  what():  Failed to close env tx (Inddata/uddata-fejl)
Afbrudt (SIGABRT)

database build is taking forever too. Been running for over 24 hours on my PC now, and last night when I went to bed it was 75%, now ~7 hours later it's at 80%, with the time varying wildly from 1.5 days to 16 hours.

I read into this, and my clock is properly synced with the internet, and the correct time zone.

It does flash up occasionally disconnected/reconnected from bitcoin qt, but if i've already downloaded the blockchain, and it's building databases (ie after this), surely this shouldn't matter, right?

Last few lines in the log are

-INFO  - 1421029109: (..\BlockUtils.cpp:384) Reading raw blocks finished at file 164 offset 134135074
-INFO  - 1421031238: (..\BlockUtils.cpp:384) Reading raw blocks finished at file 165 offset 133981448
-INFO  - 1421033239: (..\BlockUtils.cpp:384) Reading raw blocks finished at file 166 offset 133941531
-INFO  - 1421035623: (..\BlockUtils.cpp:384) Reading raw blocks finished at file 167 offset 134108933
-INFO  - 1421037781: (..\BlockUtils.cpp:384) Reading raw blocks finished at file 168 offset 134057186
-INFO  - 1421040036: (..\BlockUtils.cpp:384) Reading raw blocks finished at file 169 offset 133981151
-INFO  - 1421042170: (..\BlockUtils.cpp:384) Reading raw blocks finished at file 170 offset 134031450
-INFO  - 1421044261: (..\BlockUtils.cpp:384) Reading raw blocks finished at file 171 offset 134021369
-INFO  - 1421046167: (..\BlockUtils.cpp:384) Reading raw blocks finished at file 172 offset 133970023
-INFO  - 1421048166: (..\BlockUtils.cpp:384) Reading raw blocks finished at file 173 offset 133928453
-INFO  - 1421050733: (..\BlockUtils.cpp:384) Reading raw blocks finished at file 174 offset 134127177

Just checked now ~40 minutes later, and it's jumped to 87% and says 2 hours remaining

1) (Supernode enabled) Import an address into a wallet. View the "Wallet Properties" and now double-click on the imported address. Instead of displaying "Address Information" nothing comes up and this is the log:

2015-01-11 19:36 (ERROR) -- Traceback (most recent call last):
  File "qtdialogs.pyc", line 1968, in dblClickAddressView
  File "qtdialogs.pyc", line 3813, in __init__
IndexError: list index out of range

2) (Supernode enabled) If you try to sweep an address that doesn't have enough in it for a fee (this address only had 0.0001), you get a lot of the same error coming up.

https://www.youtube.com/watch?v=szrJoT6Gv0o

3) (Supernode enabled) If you try to sweep an address that does have enough in it (this address has 0.0002), you get a lot of the same confirmation message popping up.

https://www.youtube.com/watch?v=Ohf_pbmibgw

This is also in the log:

Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in  ignored
(ERROR) Traceback (most recent call last):
  File "/usr/lib/armory/ArmoryQt.py", line 6129, in handleCppNotification
    wlt.doAfterScan()
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 52, in inner
    return func(*args, **kwargs)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 3145, in doAfterScan
    calls[0](*calls[1])
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 52, in inner
    return func(*args, **kwargs)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 3153, in sweepAfterRescan
    sweepToAddr = self.getNextUnusedAddress().getAddr160()
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 989, in getNextUnusedAddress
    self.advanceHighestIndex(1)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 968, in advanceHighestIndex
    self.fillAddressPool()
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 1061, in fillAddressPool
    doRegister=False)))
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 1011, in computeNextAddress
    newAddr = self.addrMap[addr160].extendAddressChain(self.kdfKey)
  File "/usr/lib/armory/armoryengine/Timer.py", line 99, in inner
    ret = func(*args, **kwargs)
  File "/usr/lib/armory/armoryengine/PyBtcAddress.py", line 777, in extendAddressChain
    newAddr = PyBtcAddress()
  File "/usr/lib/armory/armoryengine/PyBtcAddress.py", line 87, in __init__
    self.binPublicKey65        = SecureBinaryData()  # 0x04 X(BE) Y(BE)
RuntimeError: maximum recursion depth exceeded while calling a Python object

Traceback (most recent call last):
  File "/usr/lib/armory/ArmoryQt.py", line 6129, in handleCppNotification
    wlt.doAfterScan()                 
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 52, in inner
    return func(*args, **kwargs)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 3145, in doAfterScan
    calls[0](*calls[1])
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 52, in inner
    return func(*args, **kwargs)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 3153, in sweepAfterRescan
    sweepToAddr = self.getNextUnusedAddress().getAddr160()
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 989, in getNextUnusedAddress
    self.advanceHighestIndex(1)
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 968, in advanceHighestIndex
    self.fillAddressPool()
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 1061, in fillAddressPool
    doRegister=False)))
  File "/usr/lib/armory/armoryengine/PyBtcWallet.py", line 1011, in computeNextAddress
    newAddr = self.addrMap[addr160].extendAddressChain(self.kdfKey)
  File "/usr/lib/armory/armoryengine/Timer.py", line 99, in inner
    ret = func(*args, **kwargs)
  File "/usr/lib/armory/armoryengine/PyBtcAddress.py", line 777, in extendAddressChain
    newAddr = PyBtcAddress()
  File "/usr/lib/armory/armoryengine/PyBtcAddress.py", line 87, in __init__
    self.binPublicKey65        = SecureBinaryData()  # 0x04 X(BE) Y(BE)
RuntimeError: maximum recursion depth exceeded while calling a Python object

4) (Supernode enabled) Removing an imported address breaks the wallet it was imported into. There is a lot of output in the logs I'm not adding here but the video should show enough.

https://www.youtube.com/watch?v=zjQpUn-YZ-M

I'd still like to know why building databases is taking forever.
I'm running on OSX 10.10 with 16 GB of RAM and an SSHD with approx 85 MB/s read/write

I am planning on buying an SSD in the near future

Is it intended that the timestamps in armorycpplog.txt are unix timestamps? Compare the level ("WARN") and timestamp from armorycpplog.txt:
To this from armorylog.txt:
I find the latter much better.

(this may be an old bug or "feature", but I'll post it here just in case)

When Armory is started with --offline, you can't update the Announcements tab. Clicking the button to update manually results in an error.



Sounds more than fair to me. You don't need the same bug reported over and over: once you know that it's not one dialog box, but all of them, it doesn't help to start listing off many dialog boxes.

We've been working on getting the Secure Downloader cleaned up. Some bugs were fixed last night. Not sure if this one was cleaned up along the way. It'll get fixed, though.


I saw it before this thread was started. Not sure where it started. It's not just an OSX issue.

Thanks for letting us know.

Note that the address book in the picture(from Wallet Properties) does not show sending addresses/lockboxes, and the one from the Addresses tab is supposed to show sending addresses/lockboxes.

The Address Book that you were allowed to see only contained addresses from that wallet, which Armory already has, Armory doesn't have your sending addresses, so it cannot show those.

I also tried signing a message with Eligius with one of my wallets, while things are syncing which worked fine.

I noticed something though to do with the sort order in the address book. Tools | Message Signing Verification | Click address book icon

I have different things there. I sorted the columns by letter, and I noticed all the lowercase wallet names at the top, above [[change received]]. If I go in and edit it so the wallet name is beginning with a capital, and click sort again, it drops into order. Then if I rename it back to lowercase, it pops back up the top.

So it doesn't look like the sorting is working correctly. Surely t = T ?

Keep an eye on wallet #61





When it was triplemining, it sorts above the [[change received]], but when it's Triplemining, it's below.


And just further to this, it lets me into the address book as above, but when I click addresses | view address book, it pops this



Surely if I can't get in one way, I shouldn't be able to get into the other?

I'm waiting for armory to sync before I load in wallets with my bitcoin But I did try just now, and it let me import a wallet, even though it's not synced. I try and do a second, and it gives me that error. Is that supposed to be the case?



And then I clicked ok, clicked import again, and even though it's still syncing, it let me do a backup



Then the error saying I couldn't do it just stopped popping up, and lets me do the imports either way. I just imported three wallets

I noticed something, you don't have any wallets loaded, but I have 7.
Another note, the progress bar shows up after I close the Receive Bitcoins window.

I have also been becoming more familiar with the Armory source code, perhaps I could help in bug fixing later.

I get this on Windows too, it pops up a message and that little  progress meter shows up. I move them side by side in screen below.