[ANN] Armory 0.93.1 Official Release

[unamis76]

Tried installing 0.93 on Ubuntu 14.04 and it errored out saying it couldn't install python-gtk2:i386 and Ubuntu Software Center disappeared from my system, along with many apps (VirtualBox, Dropbox, Okular...), what am I missing?

[1713571975]

1713571975

[1713571975]

1713571975

[1713571975]

1713571975

[goatpig]

Tried installing 0.93 on Ubuntu 14.04 and it errored out saying it couldn't install python-gtk2:i386 and Ubuntu Software Center disappeared from my system, along with many apps (VirtualBox, Dropbox, Okular...), what am I missing?

You are using a 32bit OS?

[unamis76]

Tried installing 0.93 on Ubuntu 14.04 and it errored out saying it couldn't install python-gtk2:i386 and Ubuntu Software Center disappeared from my system, along with many apps (VirtualBox, Dropbox, Okular...), what am I missing?

You are using a 32bit OS?

Yes, I am

[goatpig]

Yes, I am

Are you trying to use Armory on this machine as an offline signer or to get online?

[unamis76]

Yes, I am

Are you trying to use Armory on this machine as an offline signer or to get online?

It's an online machine, and I used the Armory Installer

[goatpig]

It's an online machine, and I used the Armory Installer

No x86 online for 0.93. Go back to 0.92.3 and wait for the next release for x86

[unamis76]

It's an online machine, and I used the Armory Installer

No x86 online for 0.93. Go back to 0.92.3 and wait for the next release for x86

Odd, your website lists 0.93 for Ubuntu 12.04+ (32bit), I thought your binaries would be compatible...

I guess I'll just install it on my 64 bit machine

[achow101_alt]

Will Bitcoin Core 0.10 be available through the secure downloader?

[goatpig]

It's an online machine, and I used the Armory Installer

No x86 online for 0.93. Go back to 0.92.3 and wait for the next release for x86

Odd, your website lists 0.93 for Ubuntu 12.04+ (32bit), I thought your binaries would be compatible...

I guess I'll just install it on my 64 bit machine

Yeah we forgot to rename all that stuff, sorry about that =(

[etotheipi]

For anyone having issues with 0.93 BDM errors, I just pushed goatpig's fix into 0.93.0.70.  Yeah weird version number. This will be 0.93.1 after we've confirmed it does what it's supposed to.

As usual, get it from the secure downloader within Armory (help->update software).

  Armory 0.93.0.70-testing for Windows XP, Vista, 7, 8+ (64-bit)
  Armory 0.93.0.70-testing for MacOSX 10.7+ (64bit)
  Armory 0.93.0.70-testing for Ubuntu 12.04+ (32bit)
  Armory 0.93.0.70-testing for Ubuntu 12.04+ (64bit)
  Armory 0.93.0.70-testing for RaspberryPi  (armhf)

  Armory 0.93.0.70-testing Offline Bundle for Ubuntu 12.04 exact (32bit)
  Armory 0.93.0.70-testing Offline Bundle for Ubuntu 12.04 exact (64bit)
  Armory 0.93.0.70-testing Offline Bundle for RaspberryPi  (armhf)

  Armory 0.93.0.70-testing: Signed hashes of all installers

[bitpop]

Works for me but I didn't have problems

[Searinox]

Deleted Armory's DB and upgraded to this version. The progress on the UI appears not to freeze anymore and I can actually see Armory building the DB. Will edit this post or make a new one if it actually makes it beyond 19-20GB or completes building.

[sflicht]

For anyone having issues with 0.93 BDM errors, I just pushed goatpig's fix into 0.93.0.70.  Yeah weird version number. This will be 0.93.1 after we've confirmed it does what it's supposed to.

As usual, get it from the secure downloader within Armory (help->update software).
ashes of all installers [/url]

Secure downloader shows only 0.91 for OS X.

[Searinox]

Done rebuilding. For the first time, this version of Armory 0.93 successfully completes building the DB without progress unresponsiveness or non-specific hangups.

I must however make a note about memory usage. While I do understand from other threads that Armory doesn't actually gobble up all the memory and merely softly asks the OS to pre-commit space for it and release it at any moment if another program needs it, I still find it untennable to constantly run a program in the background that makes my gauging of free RAM unreliable. I don't want to have to use my PC in a manner where task manager is continually showing 99% RAM being used up, preventing me from actually seeing when a program does indeed get out of hand. Since I've seen no other program ever do this, I'd find it reasonable that Armory could scale down the practice too since I really don't see it needing to commit so much RAM in the first place.

EDIT: Upon a 2nd startup it seems to only do this RAM thing when it first builds the Armory DB, or at least, because the DB isn't that far behind it does it to a significantly less extent on future startups. It's still weird and, if Armory does think it's nice to have this type of DB lookup convenience, I don't think it should do it in a manner that's visible to the user(task manager).

Btw Armory's startup scanning and reach of full functionality is significantly faster than before. Cheers!

[sflicht]

FWIW the 0.93.0.7 patch seems  *more* unstable on OS X: instead of popups about BDM errors, it just crashes outright.

I've included the OS error traceback and the ERROR part of my armory log below.

Code:

Process:               Python [55136]
Path:                  /Users/USER/Downloads/Armory 2.app/Contents/MacOS/Python
Identifier:            com.armory.armory
Version:               ???
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Python [55136]
User ID:               501

Date/Time:             2015-03-04 07:52:28.384 -0500
OS Version:            Mac OS X 10.10.2 (14C109)
Report Version:        11
Anonymous UUID:        5A98AC76-3157-7B75-505C-CA45B9237DF7

Sleep/Wake UUID:       6CFCD9AF-1AC6-4A02-BC77-B35669F33722

Time Awake Since Boot: 1200000 seconds
Time Since Wake:       8800 seconds

Crashed Thread:        5

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x000000011bb00000

VM Regions Near 0x11bb00000:
    mapped file            000000011ab00000-000000011bb00000 [ 16.0M] r--/r-x SM=PRV  /Users/USER/Library/Application Support/Bitcoin/*/*.dat
--> 
    MALLOC_LARGE           0000000122afc000-0000000122bf0000 [  976K] rw-/rwx SM=PRV  

Thread 0:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff8c91d4de mach_msg_trap + 10
1   libsystem_kernel.dylib        	0x00007fff8c91c64f mach_msg + 55
2   com.apple.CoreFoundation      	0x00007fff86a09b34 __CFRunLoopServiceMachPort + 212
3   com.apple.CoreFoundation      	0x00007fff86a08ffb __CFRunLoopRun + 1371
4   com.apple.CoreFoundation      	0x00007fff86a08858 CFRunLoopRunSpecific + 296
5   com.apple.HIToolbox           	0x00007fff8f7ebaef RunCurrentEventLoopInMode + 235
6   com.apple.HIToolbox           	0x00007fff8f7eb86a ReceiveNextEventCommon + 431
7   com.apple.HIToolbox           	0x00007fff8f7eb6ab _BlockUntilNextEventMatchingListInModeWithFilter + 71
8   com.apple.AppKit              	0x00007fff87d8ff81 _DPSNextEvent + 964
9   com.apple.AppKit              	0x00007fff87d8f730 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 194
10  com.apple.AppKit              	0x00007fff87d83593 -[NSApplication run] + 594
11  QtGui                         	0x0000000105b9387a QEventDispatcherMac::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 538
12  QtCore                        	0x0000000105127cad QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 477
13  QtCore                        	0x000000010512aec7 QCoreApplication::exec() + 199
14  QtGui.so                      	0x0000000105392610 meth_QApplication_exec_(_object*, _object*) + 80
15  org.python.python             	0x00000001000b0806 PyEval_EvalFrameEx + 20486
16  org.python.python             	0x00000001000ab58d PyEval_EvalCodeEx + 1725
17  org.python.python             	0x00000001000aaec6 PyEval_EvalCode + 54
18  org.python.python             	0x00000001000d43e4 PyRun_FileExFlags + 164
19  org.python.python             	0x00000001000d3f61 PyRun_SimpleFileExFlags + 769
20  org.python.python             	0x00000001000eafd7 Py_Main + 3063
21  Python                        	0x0000000100000e55 0x100000000 + 3669
22  Python                        	0x0000000100000d71 0x100000000 + 3441

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib        	0x00007fff8c923232 kevent64 + 10
1   libdispatch.dylib             	0x00007fff8bc61a6a _dispatch_mgr_thread + 52

Thread 2:: com.apple.CFSocket.private
0   libsystem_kernel.dylib        	0x00007fff8c9223fa __select + 10
1   libsystem_pthread.dylib       	0x00007fff88973268 _pthread_body + 131
2   libsystem_pthread.dylib       	0x00007fff889731e5 _pthread_start + 176
3   libsystem_pthread.dylib       	0x00007fff8897141d thread_start + 13

Thread 3:
0   libsystem_kernel.dylib        	0x00007fff8c91d4de mach_msg_trap + 10
1   libsystem_kernel.dylib        	0x00007fff8c91c64f mach_msg + 55
2   com.apple.CoreFoundation      	0x00007fff86a09b34 __CFRunLoopServiceMachPort + 212
3   com.apple.CoreFoundation      	0x00007fff86a08ffb __CFRunLoopRun + 1371
4   com.apple.CoreFoundation      	0x00007fff86a08858 CFRunLoopRunSpecific + 296
5   com.apple.AppKit              	0x00007fff87ef333b _NSEventThread + 137
6   libsystem_pthread.dylib       	0x00007fff88973268 _pthread_body + 131
7   libsystem_pthread.dylib       	0x00007fff889731e5 _pthread_start + 176
8   libsystem_pthread.dylib       	0x00007fff8897141d thread_start + 13

Thread 4:
0   libsystem_kernel.dylib        	0x00007fff8c9223fa __select + 10
1   org.python.python             	0x00000001000b0806 PyEval_EvalFrameEx + 20486
2   org.python.python             	0x00000001000ab58d PyEval_EvalCodeEx + 1725
3   org.python.python             	0x000000010003658c function_call + 364
4   org.python.python             	0x0000000100010d53 PyObject_Call + 99
5   org.python.python             	0x00000001000aeccd PyEval_EvalFrameEx + 13517
6   org.python.python             	0x00000001000ab58d PyEval_EvalCodeEx + 1725
7   org.python.python             	0x00000001000b3139 fast_function + 297
8   org.python.python             	0x00000001000ae9a5 PyEval_EvalFrameEx + 12709
9   org.python.python             	0x00000001000b30d2 fast_function + 194
10  org.python.python             	0x00000001000ae9a5 PyEval_EvalFrameEx + 12709
11  org.python.python             	0x00000001000b30d2 fast_function + 194
12  org.python.python             	0x00000001000ae9a5 PyEval_EvalFrameEx + 12709
13  org.python.python             	0x00000001000ab58d PyEval_EvalCodeEx + 1725
14  org.python.python             	0x000000010003658c function_call + 364
15  org.python.python             	0x0000000100010d53 PyObject_Call + 99
16  org.python.python             	0x000000010001dec6 instancemethod_call + 166
17  org.python.python             	0x0000000100010d53 PyObject_Call + 99
18  org.python.python             	0x00000001000b289d PyEval_CallObjectWithKeywords + 93
19  org.python.python             	0x00000001000ed1a6 t_bootstrap + 70
20  libsystem_pthread.dylib       	0x00007fff88973268 _pthread_body + 131
21  libsystem_pthread.dylib       	0x00007fff889731e5 _pthread_start + 176
22  libsystem_pthread.dylib       	0x00007fff8897141d thread_start + 13

Thread 5 Crashed:
0   libsystem_platform.dylib      	0x00007fff8ae51fc9 _platform_memmove$VARIANT$Unknown + 41
1   _CppBlockUtils.so             	0x0000000107205fce BinaryData::BinaryData(BinaryDataRef const&) + 78
2   _CppBlockUtils.so             	0x0000000107257408 BlockDataManager_LevelDB::BitcoinQtBlockFiles::readRawBlocksFromFile(BlockDataManager_LevelDB::BitcoinQtBlockFiles::BlkFile const&, unsigned long long, unsigned long long, std::__1::function<void (BinaryData const&, std::__1::pair<unsigned long, unsigned long long> const&, unsigned int)> const&) + 1144
3   _CppBlockUtils.so             	0x0000000107254ead BlockDataManager_LevelDB::BitcoinQtBlockFiles::readRawBlocks(std::__1::pair<unsigned long, unsigned long long>, std::__1::pair<unsigned long, unsigned long long>, std::__1::function<void (BinaryData const&, std::__1::pair<unsigned long, unsigned long long> const&, unsigned int)> const&) + 189
4   _CppBlockUtils.so             	0x0000000107250883 BlockDataManager_LevelDB::loadBlockData(ProgressReporter&, std::__1::pair<unsigned long, unsigned long long> const&, bool) + 419
5   _CppBlockUtils.so             	0x000000010724dfe9 BlockDataManager_LevelDB::loadDiskState(std::__1::function<void (BDMPhase, double, unsigned int, unsigned int)> const&, bool) + 3081
6   _CppBlockUtils.so             	0x00000001072a529e BlockDataManagerThread::run() + 462
7   _CppBlockUtils.so             	0x00000001072a5019 BlockDataManagerThread::thrun(void*) + 9
8   libsystem_pthread.dylib       	0x00007fff88973268 _pthread_body + 131
9   libsystem_pthread.dylib       	0x00007fff889731e5 _pthread_start + 176
10  libsystem_pthread.dylib       	0x00007fff8897141d thread_start + 13

Thread 5 crashed with X86 Thread State (64-bit):
  rax: 0x0000000115d80000  rbx: 0x0000000107f00428  rcx: 0x000000000002902f  rdx: 0x0000000000083a5c
  rdi: 0x0000000115ddaa2d  rsi: 0x000000011bb00000  rbp: 0x0000000107f00380  rsp: 0x0000000107f00380
   r8: 0x0000000000000000   r9: 0x000000000000000b  r10: 0x000000000000000d  r11: 0xfffffffffa2daa2d
  r12: 0x0000000000fa55cf  r13: 0x0000000101b5a210  r14: 0x000000011baa55d3  r15: 0x0000000000083a5c
  rip: 0x00007fff8ae51fc9  rfl: 0x0000000000010206  cr2: 0x000000011bb00000
  
Logical CPU:     2
Error Code:      0x00000004
Trap Number:     14


Binary Images: ....

Code:

Log file opened at 1425473672: /Users/sflicht/Library/Application Support/Armory/armorycpplog.txt
-INFO  - 1425473685: (BlockUtils.cpp:861) blkfile dir: /Users/sflicht/Library/Application Support/Bitcoin/blocks
-INFO  - 1425473685: (BlockUtils.cpp:862) lmdb dir: /Users/sflicht/Library/Application Support/Armory/databases
-INFO  - 1425473685: (lmdb_wrapper.cpp:478) Opening databases...
-INFO  - 1425473685: (BlockUtils.cpp:1193) Executing: doInitialSyncOnLoad_Rescan
-INFO  - 1425473685: (BlockUtils.cpp:1255) Total number of blk*.dat files: 78
-INFO  - 1425473685: (BlockUtils.cpp:1256) Total blockchain bytes: 10,461,603,124
-INFO  - 1425473685: (BlockUtils.cpp:1597) Reading headers from db
-INFO  - 1425473686: (BlockUtils.cpp:1623) Found 254495 headers in db
-DEBUG - 1425473686: (Blockchain.cpp:211) Organizing chain w/ rebuild
-WARN  - 1425473686: (BlockUtils.cpp:1285) --- Fetching SSH summaries for 1000 registered addresses
-INFO  - 1425473686: (BlockUtils.cpp:1298) Left off at file 77, offset 106193333
-INFO  - 1425473686: (BlockUtils.cpp:1301) Reading headers and building chain...
-INFO  - 1425473686: (BlockUtils.cpp:1302) Starting at block file 77 offset 106193333
-INFO  - 1425473686: (BlockUtils.cpp:1304) Block height 254435
-DEBUG - 1425473687: (Blockchain.cpp:211) Organizing chain w/ rebuild
-INFO  - 1425473687: (BlockUtils.cpp:1339) Looking for first unrecognized block
-INFO  - 1425473687: (BlockUtils.cpp:1488) Loading block data... file 77 offset 98453429
-ERROR - 1425473687: (BlockUtils.cpp:536) Next block header found at offset 98453437
-INFO  - 1425473687: (BlockUtils.cpp:564) Reading raw blocks finished at file 77 offset 121385335
-INFO  - 1425473687: (BlockUtils.cpp:1356) Wrote blocks to DB in 0.266411s
-ERROR - 1425473687: (lmdb_wrapper.cpp:1517) Block height exceeds DupID lookup table
-ERROR - 1425473687: (BlockUtils.cpp:1395) missing 58 block headers
-ERROR - 1425473687: (BDM_mainthread.cpp:427) BDM thread failed: Missing headers! This blockchain copy is corruptbeyond repair, time for a factory reset!

EDIT: Eventually managed to build the database and scan the tx history. Keeping my fingers crossed.

EDIT2: Still unstable. Bitcoin-QT is still slowly catching up, but Armory didn't seem to be communicating with it (~30 minutes without Armory getting the new blocks bitcoin downloaded). Restarting armory led to "Missing headers: factory reset required" errors. After a couple of "light" resets (no db rebuild) it seems to have resolved itself and is rescanning the tx history. I have no technical expertise on these matters, but I wonder if partially-downloaded blocks are causing issues?

[doug_armory]

FWIW the 0.93.0.7 patch seems  *more* unstable on OS X: instead of popups about BDM errors, it just crashes outright.

I'm glad the crash went away. The crash actually looked exactly like a last-minute bug that was fixed right before 0.93 came out.

Anyway, for various reasons, Armory remains unstable on some systems. On my system, Armory is stable. (That said, I haven't run the official 0.93.0.70 build yet.) On others, it's wonky. My suspicion is that it's due to Qt, a library we rely on. We are working on a possible solution in the background. It probably won't be ready for awhile yet but I do have hope that, after patiently waiting for so long, a reasonably stable OS X build will finally be out soon.

[goatpig]

sflicht:

You either let Armory manage bitcoind for you, or you start BitcoinQt manually and let it sync fully before you start Armory. Instead, you are starting BitcoinQt and letting Armory run on top of a blocks folder that Core is still indexing through milestones hashes, which guarantees you'll run into missing block data. Let BitcoinQt do its thing then start Armory.

[goatpig]

Done rebuilding. For the first time, this version of Armory 0.93 successfully completes building the DB without progress unresponsiveness or non-specific hangups.

I must however make a note about memory usage. While I do understand from other threads that Armory doesn't actually gobble up all the memory and merely softly asks the OS to pre-commit space for it and release it at any moment if another program needs it, I still find it untennable to constantly run a program in the background that makes my gauging of free RAM unreliable. I don't want to have to use my PC in a manner where task manager is continually showing 99% RAM being used up, preventing me from actually seeing when a program does indeed get out of hand. Since I've seen no other program ever do this, I'd find it reasonable that Armory could scale down the practice too since I really don't see it needing to commit so much RAM in the first place.

EDIT: Upon a 2nd startup it seems to only do this RAM thing when it first builds the Armory DB, or at least, because the DB isn't that far behind it does it to a significantly less extent on future startups. It's still weird and, if Armory does think it's nice to have this type of DB lookup convenience, I don't think it should do it in a manner that's visible to the user(task manager).

Btw Armory's startup scanning and reach of full functionality is significantly faster than before. Cheers!

Next version will take it easier on the RAM front. For now I'm more interested in stability.

[Searinox]

Understandable. And in that, Armory works, and better than ever. Significant improvements in speed can be felt in steps 2 and 3. There is nothing that can be done about bitcoind's slow startup is there? It's a problem with bitcoind not Armory.

[goatpig]

Understandable. And in that, Armory works, and better than ever. Significant improvements in speed can be felt in steps 2 and 3. There is nothing that can be done about bitcoind's slow startup is there? It's a problem with bitcoind not Armory.

Something can and will be done in the next version. It won't make it instant but it should prevent it from redownloading the last few blocks over and over.