Armory - Discussion Thread - page 178.

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: dooglus on July 29, 2012, 06:57:00 PM

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");
 
    }

Since adding that line to the code I've had no further crashes. I'm pretty sure that fixes the bug. There's probably a more efficient way to get the same result than re-opening all the blockchain files, but at least I've found the problem now.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: Kluge on August 01, 2012, 05:29:02 AM

A bit OT... Anyone know how to export watch-only addresses from Armory, and get them into Blockchain.info or the Bitcoin Wallet Watcher app for Android? With Blockchain.info, I am able to import addresses one at a time, but I don't have a week to spend copy/pasting addresses one-by-one, and can't find a bulk import option, less "Import Backup," which I can't figure out how to paste a load of of watch-only addresses into. I've tried just the address strings, just public keys, and strings with public keys -- pasting any of those into Blockchain.info returns "Cannot Decode Import Data," and the Android app returns "0<=size"

I have not done this myself, but I suspect it may have to do with the formatting of the keys. For one, Armory displays private and public keys with a space between every quad of hex characters, which is done for ease of copying/typing by hand, but not necessarily handled by other applications (actually, it's probably not). Second, for public keys, they are usually serialized slightly differently. Armory displays this:

Quote

PublicX : 94bb ad39 3082 eb3d 82c3 2ef5 59d8 9528 a46d f6a5 f711 ea07 36b9 3441 a182 51a5
PublicY : e9c2 ea48 55de 4b62 a19d cc84 8ce7 18a4 0224 797c c6e3 8190 622d d2a9 ebbf 5e8f

But most applications would use the concatenated version with "04" prefix byte (and without the spaces between):

Quote

04 94bb ad39 3082 eb3d 82c3 2ef5 59d8 9528 a46d f6a5 f711 ea07 36b9 3441 a182 51a5 e9c2 ea48 55de 4b62 a19d cc84 8ce7 18a4 0224 797c c6e3 8190 622d d2a9 ebbf 5e8f

This wasn't done to be confusing: it was done because this display is much cleaner and I didn't expect anyone to really use it for anything (and if they did, I expected they might already know what to do with it). But as I write this, I realize I should add a checkbox for "Raw Public Key" which gives you exactly what other apps would expect.

Kluge

donator

Activity: 1218

Merit: 1015

A bit OT... Anyone know how to export watch-only addresses from Armory, and get them into Blockchain.info or the Bitcoin Wallet Watcher app for Android? With Blockchain.info, I am able to import addresses one at a time, but I don't have a week to spend copy/pasting addresses one-by-one, and can't find a bulk import option, less "Import Backup," which I can't figure out how to paste a load of of watch-only addresses into. I've tried just the address strings, just public keys, and strings with public keys -- pasting any of those into Blockchain.info returns "Cannot Decode Import Data," and the Android app returns "0<=size"

dooglus

legendary

Activity: 2940

Merit: 1333

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:

Quote

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

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: etotheipi on July 28, 2012, 02:22:08 PM

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:

Quote

-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:

Quote

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

According to gdb, at the time of the crash:

Quote

(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.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: dooglus on July 28, 2012, 12:15:27 PM

Quote from: etotheipi on July 27, 2012, 03:39:05 PM

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...

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: wachtwoord on July 28, 2012, 01:10:50 PM

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.... Undecided

wachtwoord

legendary

Activity: 2324

Merit: 1125

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?

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: etotheipi on July 27, 2012, 03:39:05 PM

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.

dooglus

legendary

Activity: 2940

Merit: 1333

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 , argc=2, ubp_av=0x7fffffffe498, init=, fini=, 
    rtld_fini=, 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::allocator >*> >> = {
    _M_impl = { >*>> = {<__gnu_cxx::new_allocator >*>> = {}, }, _M_start = 0xd845b0, _M_finish = 0xd845c0, _M_end_of_storage = 0xd845c0}}, }
(gdb) p fileSizes_
$5 = { >> = {
    _M_impl = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_start = 0x10a7a20, 
      _M_finish = 0x10a7a28, _M_end_of_storage = 0x10a7a28}}, }
(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

legendary

Activity: 2940

Merit: 1333

Quote from: etotheipi on July 27, 2012, 03:39:05 PM

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

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

dooglus

legendary

Activity: 2940

Merit: 1333

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=, input=, length=258) at sha.cpp:453
#2  0x00007ffff5484cc7 in CryptoPP::IteratedHashBase::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 , argc=2, ubp_av=0x7fffffffe498, init=, fini=, 
    rtld_fini=, stack_end=0x7fffffffe488) at libc-start.c:226
#19 0x000000000041b931 in _start ()
(gdb)

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: dooglus on July 19, 2012, 02:30:22 PM

Quote from: dooglus on July 18, 2012, 01:36:06 PM

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:

Quote

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

, lenOutPtr=0xbffff1bc) at BtcUtils.h:243
243 uint8_t firstByte = strmPtr[0];
(gdb) where
#0 0xb735eb18 in BtcUtils::readVarInt (strmPtr=0x4

, 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 >*, std::vector >*) (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 >*, std::vector >*) (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?

traderjoe

jr. member

Activity: 34

Merit: 12

Just tried the updated 0.82.1 for W64, no freezing on-load problem. Grin

Haven't tested any more than starting it up a couple times.

BadBitcoin (James Sutton)

donator

Activity: 452

Merit: 252

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

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

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.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: Raoul Duke on July 24, 2012, 10:01:13 AM

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 Huh

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).

Raoul Duke

legendary

Activity: 1358

Merit: 1002

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 Huh

It had just sent 1 tx so I can't figure out what's happening.

molecular

donator

Activity: 2772

Merit: 1019

Quote from: etotheipi on July 23, 2012, 01:58:00 PM

Quote from: molecular on July 23, 2012, 08:58:00 AM

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://bitcointalksearch.org/topic/m.965679 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!

Topic: Armory - Discussion Thread - page 178. (Read 521829 times)