Bitcoin Forum>Bitcoin>Development & Technical Discussion>Wallet software>Armory
Pages:
Author

Topic: Armory 0.95 testing phase - page 5. (Read 8478 times)

droark
sr. member
Activity: 525
Merit: 282
Re: Armory 0.95 testing phase
August 19, 2016, 12:16:12 PM
#93
Quote from: goatpig on August 19, 2016, 09:09:52 AM
Does it always fail at the exact same spot?

Yes. I've run it three times. It appears to fail in the exact same spot.

Code:
-INFO  - 1471593104: (DatabaseBuilder.cpp:232) parsed block file #49
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3870106bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3433982bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3342432bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3868824bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 927851bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 645525bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 1047951bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3619855bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3862069bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3863112bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876516bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876290bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876291bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 2067742bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 113849bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 1282bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 275530bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 308762bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 171058bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 2562966bytes
-INFO  - 1471593105: (DatabaseBuilder.cpp:419) Found next block after skipping 128376bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3291330bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3295429bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3333425bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3768617bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3876436bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3857598bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3628980bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3868328bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3869601bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3868498bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3868406bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3876397bytes
-INFO  - 1471593106: (DatabaseBuilder.cpp:419) Found next block after skipping 3876065bytes
Segmentation fault: 11 (core dumped)

Trace looks the same as the trace I posted previously. Same parameters going into deserialize() and the other function calls.

As a side note, once it hits blk00047.dat, the "Found next block after skipped Xbytes" message comes up a lot. It only comes up once before hitting that file. Don't know if that matters but I thought I'd bring it up.
goatpig
legendary
Activity: 3766
Merit: 1364
Armory Developer
Re: Armory 0.95 testing phase
August 19, 2016, 09:09:52 AM
#92
Does it always fail at the exact same spot?
droark
sr. member
Activity: 525
Merit: 282
Re: Armory 0.95 testing phase
August 18, 2016, 06:37:38 PM
#91
Quote from: goatpig on August 13, 2016, 02:31:47 PM
Quote from: droark on August 13, 2016, 01:44:45 PM
Hello. Just FYI, the Mac build is completely broken at the moment. I've put together a PR here. ArmoryDB still segfaults when Armory runs but at least Armory will compile and start. Smiley

It's failing to create sockets on localhost. If you could look into it that would be a great help

Okay. Just looked at the code. Haven't activated debug mode yet but I'd imagine the crash is in the FCGI code, which appears to be pretty ancient. It's not maintained and hasn't been updated in years. I'm not even sure it ever supported OS X. (It was developed before OS X existed and, AFAIK, there was no attempt to port the code.)

I'm not entirely offhand sure how to proceed. I don't have a lot of free time to look into this, and if the problem is with the FCGI codebase, who knows how long it'd take to resolve everything. If somebody wants to help, I'd appreciate it. Smiley

EDIT: Derp. Was going off what goatpig said and assumed it was a socket thing. I don't think it is now. Have a core dump and am trying to decipher everything. It won't tell me which thread crashed, unfortunately.

EDIT 2: Okay. Dropped the blockfile reading code down to a single thread. Looks like the code doesn't like my copy of testnet's blk00050.dat. Here's the trace for what I believe is the offender. (Unfortunately, LLDB doesn't seem to like to explicitly state which thread crashed. Grrr.)

Code:
  thread #4: tid = 0x0003, 0x000000010039d93f ArmoryDB`std::__1::enable_if<__is_forward_iterator::value, void>::type std::__1::__split_buffer&>::__construct_at_end(unsigned char const*, unsigned char const*) [inlined] void std::__1::allocator::construct(this=0x0000700000182928, __p="", __args=0x0000000112bb2000) + 16 at memory:1731, stop reason = signal SIGSTOP
    frame #0: 0x000000010039d93f ArmoryDB`std::__1::enable_if<__is_forward_iterator::value, void>::type std::__1::__split_buffer&>::__construct_at_end(unsigned char const*, unsigned char const*) [inlined] void std::__1::allocator::construct(this=0x0000700000182928, __p="", __args=0x0000000112bb2000) + 16 at memory:1731
    frame #1: 0x000000010039d92f ArmoryDB`std::__1::enable_if<__is_forward_iterator::value, void>::type std::__1::__split_buffer&>::__construct_at_end(unsigned char const*, unsigned char const*) [inlined] void std::__1::allocator_traits >::__construct(__a=0x0000700000182928, __p="", __args=0x0000000112bb2000) + 32 at memory:1647
    frame #2: 0x000000010039d90f ArmoryDB`std::__1::enable_if<__is_forward_iterator::value, void>::type std::__1::__split_buffer&>::__construct_at_end(unsigned char const*, unsigned char const*) [inlined] void std::__1::allocator_traits >::construct(__a=0x0000700000182928, __p="", __args=0x0000000112bb2000) + 32 at memory:1493
    frame #3: 0x000000010039d8ef ArmoryDB`std::__1::enable_if<__is_forward_iterator::value, void>::type std::__1::__split_buffer&>::__construct_at_end(this=0x00007000001824e0, __first="", __last="") + 159 at __split_buffer:263
    frame #4: 0x000000010039af4f ArmoryDB`std::__1::enable_if<(__is_forward_iterator::value) && (is_constructible::reference>::value), std::__1::__wrap_iter >::type std::__1::vector >::insert(this=0x0000700000182918 size=4, __position=(item = '\0'), __first="", __last="") + 1519 at vector:1981
    frame #5: 0x0000000100399d7b ArmoryDB`BinaryData::append(this=0x0000700000182918, bd2=0x00007000001828e8) + 411 at BinaryData.cpp:45
    frame #6: 0x000000010061b334 ArmoryDB`BCTX::getHash(this=0x00007f9eab43c288) const + 276 at BlockDataMap.h:79
    frame #7: 0x0000000100651129 ArmoryDB`BCTX::moveHash(this=0x00007f9eab43c288) + 25 at BlockDataMap.h:96
    frame #8: 0x0000000100648466 ArmoryDB`BlockData::deserialize(this=0x00007000001838c0, data="\x04", size=3868256, blockHeader=0x0000000000000000, getID=function @ 0x0000700000183aa0, checkMerkle=true)>, bool) + 6390 at BlockDataMap.cpp:98
    frame #9: 0x00000001005d5faf ArmoryDB`DatabaseBuilder::addBlocksToDB(this=0x00007f9ea9617918, data="\x04", size=3868256, offset=129075608)::$_3::operator()(unsigned char const*, unsigned long, unsigned long) const + 223 at DatabaseBuilder.cpp:322
    frame #10: 0x00000001005d5eb9 ArmoryDB`bool std::__1::__invoke_void_return_wrapper::__call)::$_3&, unsigned char const*, unsigned long, unsigned long>(DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr)::$_3&&&, unsigned char const*&&, unsigned long&&, unsigned long&&) [inlined] decltype(__f=0x00007f9ea9617918, __args=0x0000700000183c08, __args=0x0000700000183c00, __args=0x0000700000183bf8)::$_3&>(fp)(std::__1::forward(fp0))) std::__1::__invoke)::$_3&, unsigned char const*, unsigned long, unsigned long>(DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr)::$_3&&&, unsigned char const*&&, unsigned long&&, unsigned long&&) + 153 at __functional_base:416
    frame #11: 0x00000001005d5e7b ArmoryDB`bool std::__1::__invoke_void_return_wrapper::__call(DatabaseBuilder::addBlocksToDB(BlockDataLoader&, unsigned short, unsigned long, std::__1::shared_ptr)::$_3&&&, unsigned char const*&&, unsigned long&&, unsigned long&&) + 91 at __functional_base:437
    frame #12: 0x00000001005d5d59 ArmoryDB`std::__1::__function::__func)::$_3, std::__1::allocator)::$_3>, bool (unsigned char const*, unsigned long, unsigned long)>::operator(this=0x00007f9ea9617910, __arg=0x0000700000183c08, __arg=0x0000700000183c00, __arg=0x0000700000183bf8)(unsigned char const*&&, unsigned long&&, unsigned long&&) + 89 at functional:1437
    frame #13: 0x00000001005db97f ArmoryDB`std::__1::function::operator(this=0x00007000001849a0, __arg="\x04", __arg=3868256, __arg=129075608)(unsigned char const*, unsigned long, unsigned long) const + 175 at functional:1817
    frame #14: 0x00000001005d0296 ArmoryDB`DatabaseBuilder::parseBlockFile(this=0x00007f9eab405e80, fileMap="\x04", fileSize=132943864, startOffset=0, callback=function @ 0x00007000001849a0)>) + 2998 at DatabaseBuilder.cpp:443
    frame #15: 0x00000001005ce94e ArmoryDB`DatabaseBuilder::addBlocksToDB(this=0x00007f9eab405e80, bdl=0x0000700000185420, fileID=50, startOffset=0, bo=std::__1::shared_ptr::element_type @ 0x00007f9eab4058c8 strong=3 weak=1) + 638 at DatabaseBuilder.cpp:343
    frame #16: 0x00000001005ce47b ArmoryDB`DatabaseBuilder::updateBlocksInDB(this=0x0000700000184e48, fileID=50, startOffset=0, bo=std::__1::shared_ptr::element_type @ 0x00007f9eab4058c8 strong=3 weak=1, verbose=true)> const&, bool, bool)::$_2::operator()(unsigned short, unsigned long, std::__1::shared_ptr, bool) const + 283 at DatabaseBuilder.cpp:227
    frame #17: 0x00000001005cc758 ArmoryDB`DatabaseBuilder::updateBlocksInDB(this=0x00007f9eab405e80, progress=0x00007f9eab405eb0, verbose=true, initialLoad=true)> const&, bool, bool) + 3384 at DatabaseBuilder.cpp:268
    frame #18: 0x00000001005c8ffa ArmoryDB`DatabaseBuilder::init(this=0x00007f9eab405e80) + 1370 at DatabaseBuilder.cpp:50
    frame #19: 0x00000001003fe976 ArmoryDB`BlockDataManager::loadDiskState(this=0x00007f9eab404310, progress=0x0000700000186c60, forceRescan=false)> const&, bool) + 1126 at BlockUtils.cpp:1553
    frame #20: 0x00000001003fe4e2 ArmoryDB`BlockDataManager::doInitialSyncOnLoad(this=0x00007f9eab404310, progress=0x0000700000186c60)> const&) + 274 at BlockUtils.cpp:1510
    frame #21: 0x00000001004c36b7 ArmoryDB`BlockDataManagerThread::run(this=0x00007fff5f87b788) + 951 at BDM_mainthread.cpp:161
    frame #22: 0x00000001004c325d ArmoryDB`BlockDataManagerThread::thrun(_self=0x00007fff5f87b788) + 29 at BDM_mainthread.cpp:261
    frame #23: 0x00000001004cef6d ArmoryDB`void* std::__1::__thread_proxy >(void*) [inlined] decltype(__f=0x00007f9eab600330, __args=0x00007f9eab600338)(void*)>(fp)(std::__1::forward(fp0))) std::__1::__invoke(void* (*&&)(void*), BlockDataManagerThread*&&) + 24 at __functional_base:416
    frame #24: 0x00000001004cef55 ArmoryDB`void* std::__1::__thread_proxy >(void*) [inlined] void std::__1::__thread_execute(__t=0x00007f9eab600330)(void*), BlockDataManagerThread*>&, std::__1::__tuple_indices<1ul>) + 40 at thread:337
    frame #25: 0x00000001004cef2d ArmoryDB`void* std::__1::__thread_proxy >(__vp=0x00007f9eab600330) + 365 at thread:347
    frame #26: 0x00007fff98ad699d libsystem_pthread.dylib`_pthread_body + 131
    frame #27: 0x00007fff98ad691a libsystem_pthread.dylib`_pthread_start + 168
    frame #28: 0x00007fff98ad4351 libsystem_pthread.dylib`thread_start + 13
goatpig
legendary
Activity: 3766
Merit: 1364
Armory Developer
Re: Armory 0.95 testing phase
August 18, 2016, 03:02:13 PM
#90
Quote from: Carlton Banks on August 18, 2016, 01:21:33 PM
Getting the following with 69577e5:

Code:
(ERROR) BDM.py:184 - DB error: DB version mismatch. Use another dbdir!

...with the accompanying dialog box ("Press OK to quit Armory" etc).


Doesn't matter which directory Armory is pointed at, or if there's an absence of ./databases directory.

Changed some formatting and bumped the internal version, use a fresh DB.
Carlton Banks
legendary
Activity: 3430
Merit: 3080
Re: Armory 0.95 testing phase
August 18, 2016, 01:21:33 PM
#89
Getting the following with 69577e5:

Code:
(ERROR) BDM.py:184 - DB error: DB version mismatch. Use another dbdir!

...with the accompanying dialog box ("Press OK to quit Armory" etc).


Doesn't matter which directory Armory is pointed at, or if there's an absence of ./databases directory.
goatpig
legendary
Activity: 3766
Merit: 1364
Armory Developer
Re: Armory 0.95 testing phase
August 17, 2016, 01:44:13 PM
#88
Quote from: jl2012 on August 17, 2016, 01:19:34 PM
It'd be better for you to use compressed key as it's cheaper anyway

That goes without saying in new wallets. The current wallet format only uses uncompressed keys however.

It's an age old, stable format that has proved itself, so I will develop the new format from scratch and leave the current one untouched. The difficulty will be around how to operate legacy wallets imported into the new format with regard to address chains and old backups.
achow101
staff
Activity: 3458
Merit: 6793
Just writing some code
Re: Armory 0.95 testing phase
August 17, 2016, 01:22:20 PM
#87
Quote from: jl2012 on August 17, 2016, 01:19:34 PM
Quote from: achow101 on August 11, 2016, 07:45:23 PM
Quote from: jl2012 on August 11, 2016, 07:42:33 PM
Do you use compressed or uncompressed key for segwit?
Armory uses uncompressed keys. Segwit wallet support has not been implemented yet.

To prevent spamming we may want to make uncompressed keys in segwit non-standard or even invalid. It'd be better for you to use compressed key as it's cheaper anyway
AFAIK compressed keys will be used in the new wallet format that goatpig will be making. The version with segwit wallet capabilities will have that new wallet.
jl2012
legendary
Activity: 1792
Merit: 1111
Re: Armory 0.95 testing phase
August 17, 2016, 01:19:34 PM
#86
Quote from: achow101 on August 11, 2016, 07:45:23 PM
Quote from: jl2012 on August 11, 2016, 07:42:33 PM
Do you use compressed or uncompressed key for segwit?
Armory uses uncompressed keys. Segwit wallet support has not been implemented yet.

To prevent spamming we may want to make uncompressed keys in segwit non-standard or even invalid. It'd be better for you to use compressed key as it's cheaper anyway
goatpig
legendary
Activity: 3766
Merit: 1364
Armory Developer
Re: Armory 0.95 testing phase
August 15, 2016, 04:47:21 PM
#85
Quote from: achow101 on August 15, 2016, 04:44:16 PM
Not sure if this was already reported.

I don't see any of my addresses having a balance when I look at the wallet properties. But I can still send (at least fairly sure that I can) Bitcoin. But coin control doesn't work.

Haven't ported these features yet. Coming soon.
achow101
staff
Activity: 3458
Merit: 6793
Just writing some code
Re: Armory 0.95 testing phase
August 15, 2016, 04:44:16 PM
#84
Not sure if this was already reported.

I don't see any of my addresses having a balance when I look at the wallet properties. But I can still send (at least fairly sure that I can) Bitcoin. But coin control doesn't work.
goatpig
legendary
Activity: 3766
Merit: 1364
Armory Developer
Re: Armory 0.95 testing phase
August 13, 2016, 02:31:47 PM
#83
Quote from: droark on August 13, 2016, 01:44:45 PM
Hello. Just FYI, the Mac build is completely broken at the moment. I've put together a PR here. ArmoryDB still segfaults when Armory runs but at least Armory will compile and start. Smiley

It's failing to create sockets on localhost. If you could look into it that would be a great help
droark
sr. member
Activity: 525
Merit: 282
Re: Armory 0.95 testing phase
August 13, 2016, 01:44:45 PM
#82
Hello. Just FYI, the Mac build is completely broken at the moment. I've put together a PR here. ArmoryDB still segfaults when Armory runs but at least Armory will compile and start. Smiley
achow101
staff
Activity: 3458
Merit: 6793
Just writing some code
Re: Armory 0.95 testing phase
August 11, 2016, 07:45:23 PM
#81
Quote from: jl2012 on August 11, 2016, 07:42:33 PM
Do you use compressed or uncompressed key for segwit?
Armory uses uncompressed keys. Segwit wallet support has not been implemented yet.
jl2012
legendary
Activity: 1792
Merit: 1111
Re: Armory 0.95 testing phase
August 11, 2016, 07:42:33 PM
#80
Do you use compressed or uncompressed key for segwit?
goatpig
legendary
Activity: 3766
Merit: 1364
Armory Developer
Re: Armory 0.95 testing phase
August 08, 2016, 11:45:07 AM
#79
A supernode in the bitcoin space generally refers to a database that tracks all address history on chain. As an example, this is the kind of engine a blockchain explorer service needs to look up arbitrary address history.
johnlu
sr. member
Activity: 471
Merit: 252
Re: Armory 0.95 testing phase
August 08, 2016, 11:08:01 AM
#78
Quote from: goatpig on July 24, 2016, 08:19:42 PM
There are still a few convenience features I haven't implemented yet, albeit they should be done quickly, notably:
...
- a fee per byte feature in spend dialogs with tx size projections.

Yay! I've been waiting for this feature. Great! :-)

Quote from: goatpig on July 24, 2016, 08:19:42 PM
Stuff that won't be in the scope of this release and when to expect them:
- New wallets: That's for 0.96, with full SegWit support (create and spend from SW transactions).
- HW wallets support: Most likely a point release for 0.96.
- Fee estimates: Expect a point release on top of 0.95 (.1~2)
- Blocks over P2P. 0.97 most likely
- DB to Client encryption and auth. Again, probably 0.97
- Code modularization: most of it for 0.96
- Supernode: 0.98

Where can I read what an Armory Supernode is?
goatpig
legendary
Activity: 3766
Merit: 1364
Armory Developer
Re: Armory 0.95 testing phase
August 02, 2016, 08:03:27 PM
#77
Quote from: achow101 on August 02, 2016, 07:43:28 PM
Qt started spamming this
Code:
-ERROR - 1470184862: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success

Then it hung with this
Code:
-ERROR - 1470184862: (SocketObject.cpp:139) POLLNVAL in writeToSocket

And then I had to kill it.

I'm working on this one.

Quote
The db had this error message
Code:
-ERROR - 1470184739: (BDM_Server.cpp:637) caught isEmpty in Clients maintenance loop

This is a debug statement, the error isn't benign.

Quote
Also, trying to view any transaction that I received gets me
Code:
Traceback (most recent call last):
  File "ArmoryQt.py", line 3626, in dblClickLedger
    self.showLedgerTx()
  File "ArmoryQt.py", line 3649, in showLedgerTx
    DlgDispTxInfo( pytx, self.walletMap[wltID], self, self, txtime=txtime).exec_()
  File "/home/andy/bitcoin/BitcoinArmory/qtdialogs.py", line 5667, in __init__
    self.data = extractTxInfo(pytx, txtime)
  File "/home/andy/bitcoin/BitcoinArmory/qtdialogs.py", line 5594, in extractTxInfo
    prevTx = TheBDM.bdv().getTxByHash(prevTxHash)
  File "/home/andy/bitcoin/BitcoinArmory/CppBlockUtils.py", line 1276, in getTxByHash
    def getTxByHash(self, *args): return _CppBlockUtils.BlockDataViewer_getTxByHash(self, *args)
RuntimeError

I think some transactions didn't make it into the db.

I'm aware of this, will look at it after I stabilize the client.
achow101
staff
Activity: 3458
Merit: 6793
Just writing some code
Re: Armory 0.95 testing phase
August 02, 2016, 07:43:28 PM
#76
Qt started spamming this
Code:
-ERROR - 1470184862: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success

Then it hung with this
Code:
-ERROR - 1470184862: (SocketObject.cpp:139) POLLNVAL in writeToSocket

And then I had to kill it.

The db had this error message
Code:
-ERROR - 1470184739: (BDM_Server.cpp:637) caught isEmpty in Clients maintenance loop

Also, trying to view any transaction that I received gets me
Code:
Traceback (most recent call last):
  File "ArmoryQt.py", line 3626, in dblClickLedger
    self.showLedgerTx()
  File "ArmoryQt.py", line 3649, in showLedgerTx
    DlgDispTxInfo( pytx, self.walletMap[wltID], self, self, txtime=txtime).exec_()
  File "/home/andy/bitcoin/BitcoinArmory/qtdialogs.py", line 5667, in __init__
    self.data = extractTxInfo(pytx, txtime)
  File "/home/andy/bitcoin/BitcoinArmory/qtdialogs.py", line 5594, in extractTxInfo
    prevTx = TheBDM.bdv().getTxByHash(prevTxHash)
  File "/home/andy/bitcoin/BitcoinArmory/CppBlockUtils.py", line 1276, in getTxByHash
    def getTxByHash(self, *args): return _CppBlockUtils.BlockDataViewer_getTxByHash(self, *args)
RuntimeError

I think some transactions didn't make it into the db.
goatpig
legendary
Activity: 3766
Merit: 1364
Armory Developer
Re: Armory 0.95 testing phase
August 02, 2016, 02:36:10 PM
#75
Quote from: Carlton Banks on August 02, 2016, 02:27:32 PM
Nope... Gui was functional enough to shut down with the actual gui, and the Db went down gracefully with it.

At least it's one step further to being stable, I'll take solace in that.
Carlton Banks
legendary
Activity: 3430
Merit: 3080
Re: Armory 0.95 testing phase
August 02, 2016, 02:27:32 PM
#74
Nope... Gui was functional enough to shut down with the actual gui, and the Db went down gracefully with it.
Pages:
Bitcoin Forum>Bitcoin>Development & Technical Discussion>Wallet software>Armory
Jump to: