Armory - Discussion Thread

[etotheipi]

One can also do it with armory instead of strongcoin-offlinetx-script, but firefox+strongcoin-offlinetx-script seem simpler to install onto an offline machine than armory (took me multiple sessions of 1-2 hours to get armory onto the offline ubuntu machine).

Molecular,

What was the cause of the problem here?  If you use the supplied "offline-bundle", it takes about 30 seconds to install on an offline Ubuntu machine (double-click InstallAllDeps.sh, and you're done).  If something wasn't so easy, then I'd like to know how it can be improved.  I expected the offline machine to be the easiest...

[molecular]

One can also do it with armory instead of strongcoin-offlinetx-script, but firefox+strongcoin-offlinetx-script seem simpler to install onto an offline machine than armory (took me multiple sessions of 1-2 hours to get armory onto the offline ubuntu machine).

Molecular,

What was the cause of the problem here?  If you use the supplied "offline-bundle", it takes about 30 seconds to install on an offline Ubuntu machine (double-click InstallAllDeps.sh, and you're done).  If something wasn't so easy, then I'd like to know how it can be improved.  I expected the offline machine to be the easiest...

it was discussed here back when I did it. I think first it was wrong python version, then it was mainly wrong glibc version linked against the swig stuff vs. the version on my ubuntu. I ended up using a version of cppForSwig I compiled on a different host. Read post https://bitcointalk.org/index.php?topic=56424.msg965679#msg965679 and onwards for more info.

[etotheipi]

it was discussed here back when I did it. I think first it was wrong python version, then it was mainly wrong glibc version linked against the swig stuff vs. the version on my ubuntu. I ended up using a version of cppForSwig I compiled on a different host. Read post https://bitcointalk.org/index.php?topic=56424.msg965679#msg965679 and onwards for more info.

Ahh.  All that python dependency stuff should be a non-issue, now.  And it wouldn't have been issue if you were using Ubuntu 10.04-32bit (which is what I made the offline-bundle for), but I recognize some users will use different distros and/or want to compile it themselves.   However, even that has been improved with static compiling of python into the C++ utilities. 

When I do the next release, I'll make a couple extra offline bundles -- one for 10.04 and 12.04. And I will include all the packages you need to compile it, not just install it. 

[molecular]

it was discussed here back when I did it. I think first it was wrong python version, then it was mainly wrong glibc version linked against the swig stuff vs. the version on my ubuntu. I ended up using a version of cppForSwig I compiled on a different host. Read post https://bitcointalk.org/index.php?topic=56424.msg965679#msg965679 and onwards for more info.

Ahh.  All that python dependency stuff should be a non-issue, now.  And it wouldn't have been issue if you were using Ubuntu 10.04-32bit (which is what I made the offline-bundle for), but I recognize some users will use different distros and/or want to compile it themselves.   However, even that has been improved with static compiling of python into the C++ utilities. 

When I do the next release, I'll make a couple extra offline bundles -- one for 10.04 and 12.04. And I will include all the packages you need to compile it, not just install it. 

Now that I call an improvement!

[Raoul Duke]

Code:

2012-07-24 15:55 (INFO) -- qtdialogs.py:5033 - Change address behavior: NewAddr
2012-07-24 15:56 (ERROR) -- qtdialogs.py:4858 - Problem sending transaction!
Traceback (most recent call last):
  File "/usr/share/armory/qtdialogs.py", line 4848, in createTxAndBroadcast
    finalTx = txdp.prepareFinalTx()
  File "/usr/share/armory/armoryengine.py", line 5572, in prepareFinalTx
    else: LOGDEBUG('Signatures for input', i, 'are valid!')
  File "/usr/share/armory/armoryengine.py", line 293, in LOGDEBUG
    logstr = msg % a
TypeError: not all arguments converted during string formatting

Can't send transaction, no idea why It had just sent 1 tx so I can't figure out what's happening.

[etotheipi]

Code:

2012-07-24 15:55 (INFO) -- qtdialogs.py:5033 - Change address behavior: NewAddr
2012-07-24 15:56 (ERROR) -- qtdialogs.py:4858 - Problem sending transaction!
Traceback (most recent call last):
  File "/usr/share/armory/qtdialogs.py", line 4848, in createTxAndBroadcast
    finalTx = txdp.prepareFinalTx()
  File "/usr/share/armory/armoryengine.py", line 5572, in prepareFinalTx
    else: LOGDEBUG('Signatures for input', i, 'are valid!')
  File "/usr/share/armory/armoryengine.py", line 293, in LOGDEBUG
    logstr = msg % a
TypeError: not all arguments converted during string formatting

Can't send transaction, no idea why It had just sent 1 tx so I can't figure out what's happening.

Looks like version 0.82.1.  It's an error in the error-logging code (yes, silly) that causes it to bail before it actually sends the tx.  This is the same message that someone else has reported, and I committed a fix last week.  I think you only need to do a git pull, then restart (no recompile required).

[etotheipi]

Version 0.82.1 updated.  Same download links as before, but the files/installers have been updated (except for 32-bit linux).

Windows users, please try this version and confirm no more freezing on-load:

Windows 64-bit installer
Windows 32-bit installer
Linux 64-bit Debian package
Linux 64-bit Debian package


Unfortunately, been really busy, and I'm going out of town tomorrow.  I won't have enough time to make this an official release, but I'm sure people will test and let me know what they think.  I'll do it when I get back.  I will still check on the thread and check emails, but I won't be near my dev computer for the next 10 days!

UPDATE: I just added Linux-32bit download above.  Also just witnessed a crash in Windows during debugging, that is pointing me to some code that is suspicious.  Unfortunately, I can't dig into until I get back, but I'll leave open the debugger and I will dig into it when I get back.

[BadBitcoin (James Sutton)]

sent a little donation today eto, any ETA on the +0.6 wallet merger?

[traderjoe]

Just tried the updated 0.82.1 for W64, no freezing on-load problem.     Haven't tested any more than starting it up a couple times.

[dooglus]

I'm now running it in gdb to hopefully get a stack trace for you, though in my experience running it in gdb is often enough to stop the crash from happening.

I finally got a crash from the version I built with debugging symbols.  Here's the backtrace:

Let's look at all the bets ever placed at SatoshiDice.com
there are 27 bet types
lessthan 64000 is listed
first SD Tx is in block 176627

Program received signal SIGSEGV, Segmentation fault.
0xb735eb18 in BtcUtils::readVarInt (strmPtr=0x4 <Address 0x4 out of bounds>, lenOutPtr=0xbffff1bc) at BtcUtils.h:243
243         uint8_t firstByte = strmPtr[0];
(gdb) where
#0  0xb735eb18 in BtcUtils::readVarInt (strmPtr=0x4 <Address 0x4 out of bounds>, lenOutPtr=0xbffff1bc) at BtcUtils.h:243
#1  0xb735e446 in BinaryRefReader::get_var_int (this=0xbffff1e8, nRead=0x0) at BinaryData.cpp:203
#2  0xb736afd0 in BtcUtils::TxCalcLength (ptr=0x0, offsetsIn=0xbffff31c, offsetsOut=0xbffff328) at BtcUtils.h:564
#3  0xb736683d in Tx::unserialize (this=0xbffff2f8, ptr=0x0) at BlockObj.cpp:529
#4  0xb736bc24 in Tx::Tx (this=0xbffff2f8, ptr=0x0) at BlockObj.h:348
#5  0xb7367a58 in TxRef::getTxCopy (this=0x20b092b4) at BlockObj.cpp:718
#6  0xb74f0944 in _wrap_TxRef_getTxCopy (args=0xb7b4f34c) at CppBlockUtils_wrap.cxx:33750
#7  0x080f77c3 in PyEval_EvalFrameEx ()
#8  0x080f7e20 in PyEval_EvalFrameEx ()
#9  0x080fd804 in PyEval_EvalCodeEx ()
#10 0x080fe177 in PyEval_EvalCode ()
#11 0x0811acd0 in ?? ()
#12 0x0811b8e9 in PyRun_FileExFlags ()
#13 0x0811c4cc in PyRun_SimpleFileExFlags ()
#14 0x0812c7c6 in Py_Main ()
#15 0x0805da0b in main ()
(gdb)

I'll leave the gdb session running, so if there are any commands you want me to type at it, I can do so.

strmPtr=0x4 doesn't look good though.  Pointers usually have high values, not 4...

I had the same crash happen while running in valgrind:

Code:

==28163== Invalid read of size 1
==28163==    at 0x840C0C8: BinaryRefReader::get_var_int(unsigned char*) (in /home/chris/Programs/BitcoinArmory/_CppBlockUtils.so)
==28163==    by 0x84153D3: BtcUtils::TxCalcLength(unsigned char const*, std::vector<unsigned int, std::allocator<unsigned int> >*, std::vector<unsigned int, std::allocator<unsigned int> >*) (in /home/chris/Programs/BitcoinArmory/_CppBlockUtils.so)
==28163==    by 0x84118B8: Tx::unserialize(unsigned char const*) (in /home/chris/Programs/BitcoinArmory/_CppBlockUtils.so)
==28163==    by 0x84119AE: TxRef::getTxCopy() const (in /home/chris/Programs/BitcoinArmory/_CppBlockUtils.so)
==28163==    by 0x8531970: _wrap_TxRef_getTxCopy (in /home/chris/Programs/BitcoinArmory/_CppBlockUtils.so)
==28163==    by 0x42A484: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==28163==    by 0x42ABE1: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==28163==    by 0x4317F1: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==28163==    by 0x54B170: PyRun_FileExFlags (in /usr/bin/python2.7)
==28163==    by 0x54B7D7: PyRun_SimpleFileExFlags (in /usr/bin/python2.7)
==28163==    by 0x54C5D5: Py_Main (in /usr/bin/python2.7)
==28163==    by 0x5FAC76C: (below main) (libc-start.c:226)
==28163==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==28163== 
==28163== 
==28163== Process terminating with default action of signal 11 (SIGSEGV)
==28163==  Access not within mapped region at address 0x4
==28163==    at 0x840C0C8: BinaryRefReader::get_var_int(unsigned char*) (in /home/chris/Programs/BitcoinArmory/_CppBlockUtils.so)
==28163==    by 0x84153D3: BtcUtils::TxCalcLength(unsigned char const*, std::vector<unsigned int, std::allocator<unsigned int> >*, std::vector<unsigned int, std::allocator<unsigned int> >*) (in /home/chris/Programs/BitcoinArmory/_CppBlockUtils.so)
==28163==    by 0x84118B8: Tx::unserialize(unsigned char const*) (in /home/chris/Programs/BitcoinArmory/_CppBlockUtils.so)
==28163==    by 0x84119AE: TxRef::getTxCopy() const (in /home/chris/Programs/BitcoinArmory/_CppBlockUtils.so)
==28163==    by 0x8531970: _wrap_TxRef_getTxCopy (in /home/chris/Programs/BitcoinArmory/_CppBlockUtils.so)
==28163==    by 0x42A484: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==28163==    by 0x42ABE1: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==28163==    by 0x4317F1: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==28163==    by 0x54B170: PyRun_FileExFlags (in /usr/bin/python2.7)
==28163==    by 0x54B7D7: PyRun_SimpleFileExFlags (in /usr/bin/python2.7)
==28163==    by 0x54C5D5: Py_Main (in /usr/bin/python2.7)
==28163==    by 0x5FAC76C: (below main) (libc-start.c:226)

There were many other complaints from valgrind, but then again there always are.  The first serious looking one was:

Code:

==28163== Invalid read of size 4
==28163==    at 0x57A95F: PyObject_Free (in /usr/bin/python2.7)
==28163==    by 0x443F66: ??? (in /usr/bin/python2.7)
==28163==    by 0x50D0AF: ??? (in /usr/bin/python2.7)
==28163==    by 0x50DA8A: ??? (in /usr/bin/python2.7)
==28163==    by 0x488792: ??? (in /usr/bin/python2.7)
==28163==    by 0x50E2E3: ??? (in /usr/bin/python2.7)
==28163==    by 0x432F0A: ??? (in /usr/bin/python2.7)
==28163==    by 0x4C7C75: PyObject_Call (in /usr/bin/python2.7)
==28163==    by 0x4C7D35: PyEval_CallObjectWithKeywords (in /usr/bin/python2.7)
==28163==    by 0x42C8A4: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==28163==    by 0x4317F1: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==28163==    by 0x54A077: PyImport_ExecCodeModuleEx (in /usr/bin/python2.7)
==28163==  Address 0x667b020 is 448 bytes inside a block of size 2,731 free'd
==28163==    at 0x4C2A82E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28163==    by 0x42606E: PyMarshal_ReadLastObjectFromFile (in /usr/bin/python2.7)
==28163==    by 0x50D020: ??? (in /usr/bin/python2.7)
==28163==    by 0x50DA8A: ??? (in /usr/bin/python2.7)
==28163==    by 0x488792: ??? (in /usr/bin/python2.7)
==28163==    by 0x50E2E3: ??? (in /usr/bin/python2.7)
==28163==    by 0x432F0A: ??? (in /usr/bin/python2.7)
==28163==    by 0x4C7C75: PyObject_Call (in /usr/bin/python2.7)
==28163==    by 0x4C7D35: PyEval_CallObjectWithKeywords (in /usr/bin/python2.7)
==28163==    by 0x42C8A4: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==28163==    by 0x4317F1: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==28163==    by 0x54A077: PyImport_ExecCodeModuleEx (in /usr/bin/python2.7)

and the first serious one mentioning _CppBlockUtils.so was:

Code:

==28163== Invalid read of size 4
==28163==    at 0x532DE9: ??? (in /usr/bin/python2.7)
==28163==    by 0x553D1A: ??? (in /usr/bin/python2.7)
==28163==    by 0x43A35F: PyUnicodeUCS4_Format (in /usr/bin/python2.7)
==28163==    by 0x43B43C: PyString_Format (in /usr/bin/python2.7)
==28163==    by 0x42BDC2: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==28163==    by 0x4317F1: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==28163==    by 0x54B170: PyRun_FileExFlags (in /usr/bin/python2.7)
==28163==    by 0x54B7D7: PyRun_SimpleFileExFlags (in /usr/bin/python2.7)
==28163==    by 0x54C5D5: Py_Main (in /usr/bin/python2.7)
==28163==    by 0x5FAC76C: (below main) (libc-start.c:226)
==28163==  Address 0x6dc8d020 is 704 bytes inside a block of size 798 free'd
==28163==    at 0x4C2A4BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28163==    by 0x8531A30: _wrap_TxRef_getTxCopy (in /home/chris/Programs/BitcoinArmory/_CppBlockUtils.so)
==28163==    by 0x42A484: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==28163==    by 0x42ABE1: PyEval_EvalFrameEx (in /usr/bin/python2.7)
==28163==    by 0x4317F1: PyEval_EvalCodeEx (in /usr/bin/python2.7)
==28163==    by 0x54B170: PyRun_FileExFlags (in /usr/bin/python2.7)
==28163==    by 0x54B7D7: PyRun_SimpleFileExFlags (in /usr/bin/python2.7)
==28163==    by 0x54C5D5: Py_Main (in /usr/bin/python2.7)
==28163==    by 0x5FAC76C: (below main) (libc-start.c:226)

I suspect that last one is the problem.  Could it be that _wrap_TxRef_getTxCopy is deleting an object while something still has a pointer to it?

[dooglus]

I just had another crash while running the satoshidice armory code.  This time it happened much earlier on, while parsing the blockchain:

Code:

Opening file 1: /home/chris/.bitcoin//blk0001.dat
Opening file 2: /home/chris/.bitcoin//blk0002.dat
Highest blkXXXX.dat file: 2
Attempting to read blockchain from file: /home/chris/.bitcoin//blk0001.dat
/home/chris/.bitcoin//blk0001.dat is 2000.15 MB
Attempting to read blockchain from file: /home/chris/.bitcoin//blk0002.dat
/home/chris/.bitcoin//blk0002.dat is 210.012 MB

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff54a9262 in CryptoPP::X86_SHA256_HashBlocks (state=0x7ffff585a830, data=0x0, len=256) at sha.cpp:435
435		);
(gdb) where
#0  0x00007ffff54a9262 in CryptoPP::X86_SHA256_HashBlocks (state=0x7ffff585a830, data=0x0, len=256) at sha.cpp:435
#1  0x00007ffff54aa2f4 in CryptoPP::SHA256::HashMultipleBlocks (this=<optimized out>, input=<optimized out>, length=258) at sha.cpp:453
#2  0x00007ffff5484cc7 in CryptoPP::IteratedHashBase<unsigned int, CryptoPP::HashTransformation>::Update (this=0x7ffff585a7c0, input=0x0, len=258)
    at iterhash.cpp:55
#3  0x00007ffff53d150c in BtcUtils::getHash256(unsigned char const*, unsigned int) () from ../_CppBlockUtils.so
#4  0x00007ffff53cb1fa in TxRef::getThisHash() const () from ../_CppBlockUtils.so
#5  0x00007ffff53db4bf in BlockDataManager_FileRefs::insertTxRef(BinaryData const&, FileDataPtr&, BlockHeader*) () from ../_CppBlockUtils.so
#6  0x00007ffff53dc904 in BlockDataManager_FileRefs::parseNewBlockData(BinaryRefReader&, unsigned int, unsigned int, unsigned int) () from ../_CppBlockUtils.so
#7  0x00007ffff53e5296 in BlockDataManager_FileRefs::parseEntireBlockchain(std::string, unsigned int) () from ../_CppBlockUtils.so
#8  0x00007ffff54d4a7d in _wrap_BlockDataManager_FileRefs_parseEntireBlockchain () from ../_CppBlockUtils.so
#9  0x000000000042ecbc in PyEval_EvalFrameEx ()
#10 0x00000000004317f2 in PyEval_EvalCodeEx ()
#11 0x000000000042a998 in PyEval_EvalFrameEx ()
#12 0x00000000004317f2 in PyEval_EvalCodeEx ()
#13 0x000000000042a998 in PyEval_EvalFrameEx ()
#14 0x00000000004317f2 in PyEval_EvalCodeEx ()
#15 0x000000000054b171 in PyRun_FileExFlags ()
#16 0x000000000054b7d8 in PyRun_SimpleFileExFlags ()
#17 0x000000000054c5d6 in Py_Main ()
#18 0x00007ffff68e576d in __libc_start_main (main=0x41b900 <main>, argc=2, ubp_av=0x7fffffffe498, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffffffe488) at libc-start.c:226
#19 0x000000000041b931 in _start ()
(gdb)

[etotheipi]

I just had another crash while running the satoshidice armory code.  This time it happened much earlier on, while parsing the blockchain:

Code:

Opening file 1: /home/chris/.bitcoin//blk0001.dat
Opening file 2: /home/chris/.bitcoin//blk0002.dat
Highest blkXXXX.dat file: 2
Attempting to read blockchain from file: /home/chris/.bitcoin//blk0001.dat
/home/chris/.bitcoin//blk0001.dat is 2000.15 MB
Attempting to read blockchain from file: /home/chris/.bitcoin//blk0002.dat
/home/chris/.bitcoin//blk0002.dat is 210.012 MB

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff54a9262 in CryptoPP::X86_SHA256_HashBlocks (state=0x7ffff585a830, data=0x0, len=256) at sha.cpp:435
435		);
(gdb) where
#0  0x00007ffff54a9262 in CryptoPP::X86_SHA256_HashBlocks (state=0x7ffff585a830, data=0x0, len=256) at sha.cpp:435
#1  0x00007ffff54aa2f4 in CryptoPP::SHA256::HashMultipleBlocks (this=<optimized out>, input=<optimized out>, length=258) at sha.cpp:453
#2  0x00007ffff5484cc7 in CryptoPP::IteratedHashBase<unsigned int, CryptoPP::HashTransformation>::Update (this=0x7ffff585a7c0, input=0x0, len=258)
    at iterhash.cpp:55
#3  0x00007ffff53d150c in BtcUtils::getHash256(unsigned char const*, unsigned int) () from ../_CppBlockUtils.so
#4  0x00007ffff53cb1fa in TxRef::getThisHash() const () from ../_CppBlockUtils.so
#5  0x00007ffff53db4bf in BlockDataManager_FileRefs::insertTxRef(BinaryData const&, FileDataPtr&, BlockHeader*) () from ../_CppBlockUtils.so
#6  0x00007ffff53dc904 in BlockDataManager_FileRefs::parseNewBlockData(BinaryRefReader&, unsigned int, unsigned int, unsigned int) () from ../_CppBlockUtils.so
#7  0x00007ffff53e5296 in BlockDataManager_FileRefs::parseEntireBlockchain(std::string, unsigned int) () from ../_CppBlockUtils.so
#8  0x00007ffff54d4a7d in _wrap_BlockDataManager_FileRefs_parseEntireBlockchain () from ../_CppBlockUtils.so
(gdb)

Both crashes you posted I believe are related.  In both cases, data is supposed to be pulled from the blk000X.dat file (and then a pointer to that is to be used for hashing/parsing), but the data isn't getting read from disk.  Looking at the code (where it's supposed to pull the data from disk), there's multiple places for it to return NULL.  Unfortunately, by the time the segfault happens, it's already long past where the problem occurred.

Given the previous backtrace you gave me, I would suspect that the filestream is simply closed or inaccessible.  Or I somehow mismanaged the file stream objects/pointers.  Unfortunately, the only way to catch this will be really slow, and I'd have to be able to reproduce it.  If you can reliably reproduce it, next time you run it in gdb, can you put a breakpoint at FileDataPtr.h:290?  If it crashes there, check for what's going on with cidx, cstart, cbytes and the values of the pointers in openFiles_ and the values of fileSizes_.  However, if it doesn't crash at that conditional, I'll have to do some work to add some extra conditions and re-run the sample_armory_code.py script over and over until it crashes.   

[dooglus]

If you can reliably reproduce it, next time you run it in gdb, can you put a breakpoint at FileDataPtr.h:290?  If it crashes there, [...]

I don't follow you.  Putting a breakpoint there won't change where it crashes.  Do you mean "if the breakpoint is triggered, [...]"?  I guess that's what you mean.  I'll watch out for it being triggered.

I just noticed that editing FileDataPtr.h doesn't cause BlockUtils.o or ../_CppBlockUtils.so to be rebuilt, but it should.  How did you generate the Makefile?  It seems you're missing some dependencies.

Code:

diff --git a/cppForSwig/Makefile b/cppForSwig/Makefile
-BlockUtils.o: BlockUtils.h BinaryData.h UniversalTimer.h BlockUtils.cpp
+BlockUtils.o: BlockUtils.h BinaryData.h UniversalTimer.h BlockUtils.cpp FileDataPtr.h

[dooglus]

I've only ever seen it crash once when loading the blockchain.  Usually the crash happens after processing lots of blocks.  I put the breakpoint in place and finally it crashed.  Here's what I found:

Code:

Sat Jul 28 01:04:51 2012 UNDER 24000 BLOCK 191118 TX e7b4a0ececfa3cad6b76b7ea622b3cabb5e8aa386c7069e05c7859bbb6e036cc BET         6.80000000 LOSE        -6.76650000
Sat Jul 28 01:04:51 2012 UNDER 24000 BLOCK 191118 TX 2cc561544ae99d2339d4ff85c25005e8b9edc3aecbd2f5c7c54a118cd7edf268 BET        43.80000000 LOSE       -43.58150000
Sat Jul 28 01:04:51 2012 UNDER 24000 BLOCK 191118 TX bbf25561526aa2e64ab1820e22f1c76fe0ec8d13ef7e5495566079c5c7b310ae BET        70.00000000 LOSE       -69.65050000
.....FileDataPtr.h:291 return NULL

Breakpoint 1, FileDataCache::getCachedDataPtr (this=0x7ffff585a3e0, fdref=...) at FileDataPtr.h:292
292	         return NULL;
(gdb) where
#0  FileDataCache::getCachedDataPtr (this=0x7ffff585a3e0, fdref=...) at FileDataPtr.h:292
#1  0x00007ffff52acef2 in FileDataPtr::getUnsafeDataPtr (this=0x31df6218) at FileDataPtr.cpp:25
#2  0x00007ffff52b4400 in TxRef::getTxCopy (this=0x31df6218) at BlockObj.cpp:718
#3  0x00007ffff545be19 in _wrap_TxRef_getTxCopy (args=0x7ffff7eda0d0) at CppBlockUtils_wrap.cxx:35980
#4  0x000000000042a485 in PyEval_EvalFrameEx ()
#5  0x000000000042abe2 in PyEval_EvalFrameEx ()
#6  0x00000000004317f2 in PyEval_EvalCodeEx ()
#7  0x000000000054b171 in PyRun_FileExFlags ()
#8  0x000000000054b7d8 in PyRun_SimpleFileExFlags ()
#9  0x000000000054c5d6 in Py_Main ()
#10 0x00007ffff68e576d in __libc_start_main (main=0x41b900 <main>, argc=2, ubp_av=0x7fffffffe498, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffffffe488) at libc-start.c:226
#11 0x000000000041b931 in _start ()
(gdb) p cidx
$1 = 1
(gdb) p cstart
$2 = 227533755
(gdb) p cbytes
$3 = 168
(gdb) p openFiles_
$4 = {<std::_Vector_base<std::basic_ifstream<char, std::char_traits<char> >*, std::allocator<std::basic_ifstream<char, std::char_traits<char> >*> >> = {
    _M_impl = {<std::allocator<std::basic_ifstream<char, std::char_traits<char> >*>> = {<__gnu_cxx::new_allocator<std::basic_ifstream<char, std::char_traits<char> >*>> = {<No data fields>}, <No data fields>}, _M_start = 0xd845b0, _M_finish = 0xd845c0, _M_end_of_storage = 0xd845c0}}, <No data fields>}
(gdb) p fileSizes_
$5 = {<std::_Vector_base<unsigned int, std::allocator<unsigned int> >> = {
    _M_impl = {<std::allocator<unsigned int>> = {<__gnu_cxx::new_allocator<unsigned int>> = {<No data fields>}, <No data fields>}, _M_start = 0x10a7a20, 
      _M_finish = 0x10a7a28, _M_end_of_storage = 0x10a7a28}}, <No data fields>}
(gdb) 

I'll leave gdb running, so if there's anything else you want me to type at the gdb prompt, let me know...

[dooglus]

However, if it doesn't crash at that conditional, I'll have to do some work to add some extra conditions and re-run the sample_armory_code.py script over and over until it crashes.   

I wanted it to crash while loading the blockchain.  So I put an infinite loop around the BDM_LoadBlockchainFile() call, and ran TheBDM.Reset() after each load so it would continually reload the blockchain.

I left it running overnight.  It loaded the blockchain 125 times but didn't trigger the breakpoint once.

[wachtwoord]

How do I send coins?

I am trying to send coins, enter an address to send to, an amount to send, a comment and a fee (0.0). Then I press send and it gives an overview of the transactions, subsequently I enter my pass phrase and then it doesn't send and returns to the send window. When I press send again the overview screen comes up again and after continue I am back at the send coins screen.

What am I doing wrong here?

[etotheipi]

How do I send coins?

I am trying to send coins, enter an address to send to, an amount to send, a comment and a fee (0.0). Then I press send and it gives an overview of the transactions, subsequently I enter my pass phrase and then it doesn't send and returns to the send window. When I press send again the overview screen comes up again and after continue I am back at the send coins screen.

What am I doing wrong here?

I bet this is another error-in-the-error-logging-code issue.  I think it may have been fixed in the latest 0.82.1 version I posted.  Were you using it? (posted about 4 days ago).  It's been a while, but I seem to remember seeing a similar error and then fixing it.  If you are using 0.82+, can you try to send the transaction, then when it fails, go to the main menu and File-->Export Log File.  Only the last 50 or so lines will be necessary to see what happened.  If you think it might be sensitive, just extract the error message and PM/email it to me.   

But again, I think this may be fixed already in the previous post.  This is why I kept 0.82+ in testing so long, because I touched every part of the code to put in logging and inevitably broke stuff.... 

[etotheipi]

However, if it doesn't crash at that conditional, I'll have to do some work to add some extra conditions and re-run the sample_armory_code.py script over and over until it crashes.   

I wanted it to crash while loading the blockchain.  So I put an infinite loop around the BDM_LoadBlockchainFile() call, and ran TheBDM.Reset() after each load so it would continually reload the blockchain.

I left it running overnight.  It loaded the blockchain 125 times but didn't trigger the breakpoint once.

I guess it didn't crash, either...?   Sorry I wasn't clear earlier... that breakpoint should never hit if the code is working.  I was hoping it would break and then the current state would be relevant to the problem.

But it looks like you got the crash somewhere relevant before.  Unfortunately, I think I'm just going to have to try to recreate it myself, later.  I'll try your method of putting in an infinite loop and see if I can get it to crash in gdb and then I can dig through it myself.  Unfortuantely, it's going to be a week before I'll get a chance to look at it.  But I'm sure you'll be a master of triggering the error by then and can help make sure that I can reproduce it at that time

Thanks again for taking the time to look at this...

[dooglus]

But it looks like you got the crash somewhere relevant before.

I just had it crash again, after the initial blockchain load, and well into looping through the blocks.

At the time of the crash, my blockchain file sizes are like this:

 -rw-------  1 chris chris 2 097 307 549 Jul 12 20:07 blk0001.dat
 -rw-------  1 chris chris   251 261 998 Jul 29 15:35 blk0002.dat

And the line that causes the crash is:

     if( cidx >= openFiles_.size() || cstart + cbytes > fileSizes_[cidx] )

According to gdb, at the time of the crash:

(gdb) p fileSizes_[cidx]
$8 = (unsigned int &) @0xf78854: 251 117 353
(gdb) p cstart
$9 = 251 225 041

So the problem seems to be caused by the code trying to retrieve from a block which has arrived since the blockchain was initially loaded.

Can you think of a reason that might be happening?  How would the Armory code know about the newly arrived block?  Are you loading the blkindex.dat at all?  That could be an explanation if the blkindex.dat is out of sync with the blk00*.dat files, but I'm not seeing you loading the index file at all.

Edit: I think the problem is caused when the blockchain files grow in size while being read.  The code caches the size of both files, then reads both files.  While reading the first file, there's plenty of time for the 2nd file to grow, ending up with blocks outside of the range defined by the file sizes that were cached.

[dooglus]

I think the following might fix the crash:

Code:

diff --git a/cppForSwig/BlockUtils.cpp b/cppForSwig/BlockUtils.cpp
index 2b08f5e..bf270bf 100644
--- a/cppForSwig/BlockUtils.cpp
+++ b/cppForSwig/BlockUtils.cpp
@@ -2535,6 +2535,7 @@ uint32_t BlockDataManager_FileRefs::parseEntireBlockchain( string   blkdir,
             bsb.reader().advance(nextBlkSize);
          }
       }
+      globalCache.openFile(fnum-1, blkfile);
       TIMER_STOP("ScanBlockchain");
 
    }

i.e. re-open the file after loading its contents, causing the value in fileSizes_ to be updated in the event that the blockchain data file has grown while being read.

I don't see how that would prevent the crash while loading the blockchain that I saw once, but I'm hoping it will fix the much more common crash while looping through the blocks.

I'll let you know how it goes.

Edit: Here's output from the loading the blockchain with a couple of extra print statements to show the cached file sizes:

Opening file 1: /home/chris/.bitcoin//blk0001.dat
fileSizes_[0] = 2097307549
Opening file 2: /home/chris/.bitcoin//blk0002.dat
fileSizes_[1] = 252024334
Highest blkXXXX.dat file: 2
Attempting to read blockchain from file: /home/chris/.bitcoin//blk0001.dat
/home/chris/.bitcoin//blk0001.dat is 2000.15 MB
fileSizes_[0] unchanged after reading file
fileSizes_[0] = 2097307549
Attempting to read blockchain from file: /home/chris/.bitcoin//blk0002.dat
/home/chris/.bitcoin//blk0002.dat is 240.362 MB
fileSizes_[1] changing from 252024334 to 252037572
fileSizes_[1] = 252037572
Organizing chain
Done organizing chain
Loading blockchain took 104.0 sec