unamis76
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
March 02, 2015, 04:16:42 PM |
|
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?
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3738
Merit: 1360
Armory Developer
|
|
March 02, 2015, 05:19:31 PM |
|
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
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
March 02, 2015, 05:48:59 PM |
|
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
Moderator
Legendary
Offline
Activity: 3738
Merit: 1360
Armory Developer
|
|
March 02, 2015, 07:40:02 PM |
|
Yes, I am
Are you trying to use Armory on this machine as an offline signer or to get online?
|
|
|
|
unamis76
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
March 02, 2015, 08:32:35 PM |
|
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
Moderator
Legendary
Offline
Activity: 3738
Merit: 1360
Armory Developer
|
|
March 02, 2015, 09:58:32 PM |
|
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
Legendary
Offline
Activity: 1512
Merit: 1012
|
|
March 03, 2015, 11:27:42 AM |
|
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
|
|
March 03, 2015, 08:50:29 PM |
|
Will Bitcoin Core 0.10 be available through the secure downloader?
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3738
Merit: 1360
Armory Developer
|
|
March 03, 2015, 10:54:19 PM |
|
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 (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
March 04, 2015, 02:04:20 AM |
|
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
March 04, 2015, 02:38:37 AM |
|
Works for me but I didn't have problems
|
|
|
|
Searinox
Full Member
Offline
Activity: 147
Merit: 100
Do you like fire? I'm full of it.
|
|
March 04, 2015, 09:21:44 AM Last edit: March 04, 2015, 12:40:25 PM by 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
Newbie
Offline
Activity: 19
Merit: 0
|
|
March 04, 2015, 12:39:31 PM |
|
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
Full Member
Offline
Activity: 147
Merit: 100
Do you like fire? I'm full of it.
|
|
March 04, 2015, 12:40:40 PM Last edit: March 04, 2015, 01:03:22 PM by 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
Newbie
Offline
Activity: 19
Merit: 0
|
|
March 04, 2015, 01:06:55 PM Last edit: March 04, 2015, 01:52:50 PM by 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. 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: .... 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
|
|
March 04, 2015, 02:29:16 PM |
|
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.
|
Senior Developer - Armory Technologies, Inc.
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3738
Merit: 1360
Armory Developer
|
|
March 04, 2015, 03:06:08 PM |
|
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
Moderator
Legendary
Offline
Activity: 3738
Merit: 1360
Armory Developer
|
|
March 04, 2015, 03:07:35 PM |
|
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
Full Member
Offline
Activity: 147
Merit: 100
Do you like fire? I'm full of it.
|
|
March 04, 2015, 03:25:21 PM |
|
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
Moderator
Legendary
Offline
Activity: 3738
Merit: 1360
Armory Developer
|
|
March 04, 2015, 03:42:01 PM |
|
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.
|
|
|
|
|