Starting preliminary 0.94 testing - "Headless fullnode" - page 12.

Carlton Banks

legendary

Activity: 3430

Merit: 3074

Code:

[New Thread 0x7fffd7fff700 (LWP 3900)]
[Thread 0x7fffd7fff700 (LWP 3900) exited]
-WARN  - 1431799612: (lmdb_wrapper.cpp:659) Clearing history
-WARN  - 1431799612: (BlockWriteBatcher.cpp:1556) Starting with: 
-WARN  - 1431799612: (BlockWriteBatcher.cpp:1557) 1 workers
-WARN  - 1431799612: (BlockWriteBatcher.cpp:1558) 1 writers
-WARN  - 1431799612: (BlockUtils.cpp:1071) Scanning from 0 to 356710
[New Thread 0x7fffd7fff700 (LWP 3901)]
[New Thread 0x7fffdc9ae700 (LWP 3902)]
[New Thread 0x7fffd77fe700 (LWP 3903)]
[New Thread 0x7fffd699e700 (LWP 3904)]
[New Thread 0x7fffd4d90700 (LWP 3905)]
[New Thread 0x7fffcffff700 (LWP 3906)]
[New Thread 0x7fffcf7fe700 (LWP 3907)]
[Thread 0x7fffd4d90700 (LWP 3905) exited]
[New Thread 0x7fffd4d90700 (LWP 3908)]
[Thread 0x7fffd4d90700 (LWP 3908) exited]
[New Thread 0x7fffd4d90700 (LWP 3909)]
[Thread 0x7fffd4d90700 (LWP 3909) exited]
-WARN  - 1431799616: (BlockWriteBatcher.cpp:355) Finished applying blocks up to 2500
[New Thread 0x7fffd4d90700 (LWP 3911)]
[New Thread 0x7fffceffd700 (LWP 3912)]
[Thread 0x7fffceffd700 (LWP 3912) exited]
[New Thread 0x7fffceffd700 (LWP 3913)]
[Thread 0x7fffceffd700 (LWP 3913) exited]
[New Thread 0x7fffceffd700 (LWP 3914)]
[Thread 0x7fffceffd700 (LWP 3914) exited]
-WARN  - 1431799619: (BlockWriteBatcher.cpp:355) Finished applying blocks up to 85000
[Thread 0x7fffd4d90700 (LWP 3911) exited]
[New Thread 0x7fffd4d90700 (LWP 3916)]
[New Thread 0x7fffceffd700 (LWP 3917)]
[Thread 0x7fffd4d90700 (LWP 3916) exited]
[New Thread 0x7fffce7fc700 (LWP 3918)]
[Thread 0x7fffce7fc700 (LWP 3918) exited]

{CARLTON EDIT}

[New Thread 0x7fffd4d90700 (LWP 5281)]
[New Thread 0x7fffcdffb700 (LWP 5282)]
[New Thread 0x7fffcd7fa700 (LWP 5283)]
[Thread 0x7fffd4d90700 (LWP 5281) exited]
[Thread 0x7fffcd7fa700 (LWP 5283) exited]
[New Thread 0x7fffcd7fa700 (LWP 5284)]
[Thread 0x7fffcdffb700 (LWP 5282) exited]
[Thread 0x7fffcd7fa700 (LWP 5284) exited]
[New Thread 0x7fffcdffb700 (LWP 5285)]
[New Thread 0x7fffcd7fa700 (LWP 5286)]
[New Thread 0x7fffceffd700 (LWP 5287)]
[Thread 0x7fffcd7fa700 (LWP 5286) exited]
[Thread 0x7fffceffd700 (LWP 5287) exited]
[New Thread 0x7fffceffd700 (LWP 5288)]
[Thread 0x7fffcdffb700 (LWP 5285) exited]
[New Thread 0x7fffd4d90700 (LWP 5290)]
[New Thread 0x7fffcdffb700 (LWP 5291)]
[New Thread 0x7fffcd7fa700 (LWP 5292)]
[Thread 0x7fffd4d90700 (LWP 5290) exited]
[Thread 0x7fffcd7fa700 (LWP 5292) exited]
[Thread 0x7fffcdffb700 (LWP 5291) exited]
[New Thread 0x7fffce7fc700 (LWP 5294)]
[New Thread 0x7fffcd7fa700 (LWP 5293)]
[Thread 0x7fffce7fc700 (LWP 5294) exited]
[New Thread 0x7fffce7fc700 (LWP 5295)]
[Thread 0x7fffceffd700 (LWP 5288) exited]
(WARNING) SDM.py:726 - bitcoind exited, bitcoind STDOUT:
(WARNING) SDM.py:728 - 
(WARNING) SDM.py:729 - bitcoind exited, bitcoind STDERR:
(WARNING) SDM.py:731 - 
[Thread 0x7fffce7fc700 (LWP 5295) exited]
(ERROR) Networking.py:366 - ***Connection to Satoshi client LOST!  Attempting to reconnect...
(ERROR) ArmoryQt.py:5842 - BitcoindNotAvailable: should not happen...
[Thread 0x7fffcd7fa700 (LWP 5293) exited]
[New Thread 0x7fffd4d90700 (LWP 5296)]
[New Thread 0x7fffcd7fa700 (LWP 5297)]
[New Thread 0x7fffce7fc700 (LWP 5298)]
[Thread 0x7fffd4d90700 (LWP 5296) exited]
[Thread 0x7fffce7fc700 (LWP 5298) exited]
[New Thread 0x7fffceffd700 (LWP 5300)]
[New Thread 0x7fffce7fc700 (LWP 5299)]
[Thread 0x7fffcd7fa700 (LWP 5297) exited]
[Thread 0x7fffceffd700 (LWP 5300) exited]
[New Thread 0x7fffceffd700 (LWP 5301)]
[Thread 0x7fffceffd700 (LWP 5301) exited]
[Thread 0x7fffce7fc700 (LWP 5299) exited]
[New Thread 0x7fffd4d90700 (LWP 5302)]
[New Thread 0x7fffce7fc700 (LWP 5303)]
[Thread 0x7fffd4d90700 (LWP 5302) exited]
[New Thread 0x7fffceffd700 (LWP 5304)]
[Thread 0x7fffceffd700 (LWP 5304) exited]
[Thread 0x7fffce7fc700 (LWP 5303) exited]
[New Thread 0x7fffcd7fa700 (LWP 5306)]
[New Thread 0x7fffceffd700 (LWP 5305)]
[Thread 0x7fffcd7fa700 (LWP 5306) exited]
[New Thread 0x7fffcd7fa700 (LWP 5307)]
[Thread 0x7fffcd7fa700 (LWP 5307) exited]
[Thread 0x7fffceffd700 (LWP 5305) exited]
[New Thread 0x7fffd4d90700 (LWP 5308)]
[New Thread 0x7fffceffd700 (LWP 5309)]
[New Thread 0x7fffcd7fa700 (LWP 5310)]
[Thread 0x7fffd4d90700 (LWP 5308) exited]
[Thread 0x7fffcd7fa700 (LWP 5310) exited]
[Thread 0x7fffceffd700 (LWP 5309) exited]
[New Thread 0x7fffcd7fa700 (LWP 5312)]
[New Thread 0x7fffce7fc700 (LWP 5313)]
[Thread 0x7fffce7fc700 (LWP 5313) exited]
[New Thread 0x7fffce7fc700 (LWP 5314)]
[Thread 0x7fffce7fc700 (LWP 5314) exited]
[Thread 0x7fffcd7fa700 (LWP 5312) exited]
[New Thread 0x7fffd4d90700 (LWP 5315)]
[Thread 0x7fffd4d90700 (LWP 5315) exited]
[New Thread 0x7fffcd7fa700 (LWP 5316)]
[New Thread 0x7fffce7fc700 (LWP 5317)]
[Thread 0x7fffce7fc700 (LWP 5317) exited]
[Thread 0x7fffcd7fa700 (LWP 5316) exited]
[New Thread 0x7fffceffd700 (LWP 5320)]
[New Thread 0x7fffce7fc700 (LWP 5318)]
-WARN  - 1431800044: (BlockWriteBatcher.cpp:355) Finished applying blocks up to 217500

{CARLTON EDIT}

[New Thread 0x7fffce7fc700 (LWP 5617)]
[Thread 0x7fffceffd700 (LWP 5614) exited]
[Thread 0x7fffce7fc700 (LWP 5617) exited]
[New Thread 0x7fffd4d90700 (LWP 5619)]
[New Thread 0x7fffce7fc700 (LWP 5620)]
[New Thread 0x7fffceffd700 (LWP 5621)]
[Thread 0x7fffceffd700 (LWP 5621) exited]
[Thread 0x7fffd4d90700 (LWP 5619) exited]
[Thread 0x7fffce7fc700 (LWP 5620) exited]
[New Thread 0x7fffce7fc700 (LWP 5622)]
[New Thread 0x7fffceffd700 (LWP 5623)]
[Thread 0x7fffceffd700 (LWP 5623) exited]
[Thread 0x7fffce7fc700 (LWP 5622) exited]
[New Thread 0x7fffd4d90700 (LWP 5624)]
[New Thread 0x7fffce7fc700 (LWP 5625)]
[New Thread 0x7fffceffd700 (LWP 5626)]
[New Thread 0x7fffcd7fa700 (LWP 5627)]
[Thread 0x7fffceffd700 (LWP 5626) exited]
[Thread 0x7fffce7fc700 (LWP 5625) exited]
[New Thread 0x7fffce7fc700 (LWP 5628)]
[Thread 0x7fffce7fc700 (LWP 5628) exited]
[Thread 0x7fffd4d90700 (LWP 5624) exited]
[New Thread 0x7fffce7fc700 (LWP 5629)]
[Thread 0x7fffce7fc700 (LWP 5629) exited]
[Thread 0x7fffcd7fa700 (LWP 5627) exited]
[New Thread 0x7fffd4d90700 (LWP 5631)]
[New Thread 0x7fffcd7fa700 (LWP 5632)]
[New Thread 0x7fffce7fc700 (LWP 5633)]
[Thread 0x7fffd4d90700 (LWP 5631) exited]
[New Thread 0x7fffceffd700 (LWP 5634)]
[Thread 0x7fffce7fc700 (LWP 5633) exited]
[Thread 0x7fffcd7fa700 (LWP 5632) exited]
[New Thread 0x7fffcd7fa700 (LWP 5635)]
-INFO  - 1431800186: (BDM_mainthread.cpp:273) Stop requested detected
[Thread 0x7fffcd7fa700 (LWP 5635) exited]
[New Thread 0x7fffcd7fa700 (LWP 5636)]
terminate called without an active exception

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffdd1af700 (LWP 3645)]
0x00007ffff6fc8165 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) run ArmoryQt.py
The program being debugged has been started already.
Start it from the beginning? (y or n) ^Cn
Program not restarted.
(gdb) quit
A debugging session is active.

	Inferior 1 [process 2698] will be killed.

Quit anyway? (y or n) y
Quitting: Couldn't get registers: No such process.
user@machine:~/BitcoinArmory$ gdb python
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
(gdb) run ArmoryQt.py
Starting program: /usr/bin/python ArmoryQt.py
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
********************************************************************************
Loading Armory Engine:
   Armory Version:       0.93.99.1
   Armory Build:         578c0724b9
   PyBtcWallet  Version: 1.35
Detected Operating system: Linux
   OS Variant            : ('debian', '7.8', '')
   User home-directory   : /home/user
   Satoshi BTC directory : /home/user/.bitcoin
   Armory home dir       : /home/user/.armory
   ArmoryDB directory     : /home/user/.armory/databases
   Armory settings file  : /home/user/.armory/ArmorySettings.txt
   Armory log file       : /home/user/.armory/armorylog.txt
   Do wallet checking    : True
[New Thread 0x7fffddbb6700 (LWP 5671)]
[New Thread 0x7fffdd1af700 (LWP 5675)]
[New Thread 0x7fffdc9ae700 (LWP 5676)]
[Thread 0x7fffdc9ae700 (LWP 5676) exited]
[New Thread 0x7fffdc9ae700 (LWP 5712)]
[Thread 0x7fffdc9ae700 (LWP 5712) exited]
[New Thread 0x7fffdc9ae700 (LWP 5715)]
[New Thread 0x7fffdc1ad700 (LWP 5716)]
[New Thread 0x7fffdb9ac700 (LWP 5717)]
[Thread 0x7fffdb9ac700 (LWP 5717) exited]
[New Thread 0x7fffdb9ac700 (LWP 5718)]
[Thread 0x7fffdb9ac700 (LWP 5718) exited]
[New Thread 0x7fffdb9ac700 (LWP 5719)]
[Thread 0x7fffdb9ac700 (LWP 5719) exited]

{CARLTON EDIT}

[Thread 0x7fffdc9ae700 (LWP 6561) exited]
[New Thread 0x7fffdc9ae700 (LWP 6562)]
[Thread 0x7fffdc9ae700 (LWP 6562) exited]
[New Thread 0x7fffdc9ae700 (LWP 6563)]
[Thread 0x7fffdc9ae700 (LWP 6563) exited]
[New Thread 0x7fffdc9ae700 (LWP 6564)]
[Thread 0x7fffdc9ae700 (LWP 6564) exited]
[New Thread 0x7fffdc9ae700 (LWP 6565)]
[Thread 0x7fffdc9ae700 (LWP 6565) exited]
[New Thread 0x7fffdc9ae700 (LWP 6566)]
[Thread 0x7fffdc9ae700 (LWP 6566) exited]
[New Thread 0x7fffdc9ae700 (LWP 6567)]
[Thread 0x7fffdc9ae700 (LWP 6567) exited]
[New Thread 0x7fffdc9ae700 (LWP 6568)]
[Thread 0x7fffdc9ae700 (LWP 6568) exited]
[New Thread 0x7fffdc9ae700 (LWP 6569)]
[Thread 0x7fffdc9ae700 (LWP 6569) exited]
[New Thread 0x7fffdc9ae700 (LWP 6570)]
[Thread 0x7fffdc9ae700 (LWP 6570) exited]
[New Thread 0x7fffdc9ae700 (LWP 6571)]
[Thread 0x7fffdc9ae700 (LWP 6571) exited]
[New Thread 0x7fffdc9ae700 (LWP 6572)]
[Thread 0x7fffdc9ae700 (LWP 6572) exited]
[New Thread 0x7fffdc9ae700 (LWP 6573)]
[Thread 0x7fffdc9ae700 (LWP 6573) exited]
[New Thread 0x7fffdc9ae700 (LWP 6574)]
[Thread 0x7fffdd1af700 (LWP 5785) exited]
[New Thread 0x7fffdd1af700 (LWP 6575)]
-INFO  - 1431800624: (BlockUtils.cpp:850) blkfile dir: /.bitcoin/blocks
-INFO  - 1431800624: (BlockUtils.cpp:851) lmdb dir: /.armory/databases
-INFO  - 1431800624: (lmdb_wrapper.cpp:439) Opening databases...
-INFO  - 1431800624: (BlockUtils.cpp:1181) Executing: doInitialSyncOnLoad
-INFO  - 1431800624: (BlockUtils.cpp:1253) Total number of blk*.dat files: 270
-INFO  - 1431800624: (BlockUtils.cpp:1254) Total blockchain bytes: 36,138,815,515
-INFO  - 1431800624: (BlockUtils.cpp:1628) Reading headers from db
[Thread 0x7fffdc9ae700 (LWP 6574) exited]
[New Thread 0x7fffdc9ae700 (LWP 6576)]
[Thread 0x7fffdc9ae700 (LWP 6576) exited]
[New Thread 0x7fffdc9ae700 (LWP 6578)]
[Thread 0x7fffdc9ae700 (LWP 6578) exited]
[New Thread 0x7fffdc9ae700 (LWP 6579)]
[Thread 0x7fffdc9ae700 (LWP 6579) exited]
[New Thread 0x7fffdc9ae700 (LWP 6580)]
[Thread 0x7fffdc9ae700 (LWP 6580) exited]
[New Thread 0x7fffdc9ae700 (LWP 6581)]
[Thread 0x7fffdc9ae700 (LWP 6581) exited]
[New Thread 0x7fffdc9ae700 (LWP 6582)]
[Thread 0x7fffdc9ae700 (LWP 6582) exited]
[New Thread 0x7fffdc9ae700 (LWP 6583)]
[Thread 0x7fffdc9ae700 (LWP 6583) exited]
[New Thread 0x7fffdc9ae700 (LWP 6584)]
[Thread 0x7fffdc9ae700 (LWP 6584) exited]
[New Thread 0x7fffdc9ae700 (LWP 6585)]
[Thread 0x7fffdc9ae700 (LWP 6585) exited]
[New Thread 0x7fffdc9ae700 (LWP 6586)]
[Thread 0x7fffdc9ae700 (LWP 6586) exited]
-INFO  - 1431800642: (BlockUtils.cpp:1654) Found 356721 headers in db
-DEBUG - 1431800642: (Blockchain.cpp:214) Organizing chain w/ rebuild
[New Thread 0x7fffdc9ae700 (LWP 6587)]
[Thread 0x7fffdc9ae700 (LWP 6587) exited]
[New Thread 0x7fffdc9ae700 (LWP 6588)]
[Thread 0x7fffdc9ae700 (LWP 6588) exited]
[New Thread 0x7fffdc9ae700 (LWP 6589)]
[Thread 0x7fffdc9ae700 (LWP 6589) exited]
[New Thread 0x7fffdc9ae700 (LWP 6591)]
[Thread 0x7fffdc9ae700 (LWP 6591) exited]
-WARN  - 1431800645: (BlockUtils.cpp:1282) --- Fetching SSH summaries for 491 registered addresses
-INFO  - 1431800646: (BlockUtils.cpp:1295) Left off at file 269, offset 71957593
-INFO  - 1431800646: (BlockUtils.cpp:1298) Reading headers and building chain...
-INFO  - 1431800646: (BlockUtils.cpp:1299) Starting at block file 269 offset 71957593
-INFO  - 1431800646: (BlockUtils.cpp:1301) Block height 356710
-WARN  - 1431800646: (Blockchain.cpp:50) Somehow tried to add header that's already in map
-WARN  - 1431800646: (Blockchain.cpp:51)     Header Hash: 00000000000000000456959f4335793c1ba488a78f6941c1b56baea08c098815
-WARN  - 1431800646: (Blockchain.cpp:50) Somehow tried to add header that's already in map
-WARN  - 1431800646: (Blockchain.cpp:51)     Header Hash: 000000000000000001d0f5ed714b78d466f97731beb4ca155367433bcdac028a
-WARN  - 1431800646: (Blockchain.cpp:50) Somehow tried to add header that's already in map
-WARN  - 1431800646: (Blockchain.cpp:51)     Header Hash: 000000000000000014386b1c3f544efa0b0fa0840a7993183027a6b0f1425dc4
-WARN  - 1431800646: (Blockchain.cpp:50) Somehow tried to add header that's already in map
-WARN  - 1431800646: (Blockchain.cpp:51)     Header Hash: 000000000000000006c5c96065b4f447d78cd761cec54aba452d7acb824a67c1
-WARN  - 1431800646: (Blockchain.cpp:50) Somehow tried to add header that's already in map
-WARN  - 1431800646: (Blockchain.cpp:51)     Header Hash: 0000000000000000167945b0f576dcac6d20d64f13b20d5cf655308d848ff682
-WARN  - 1431800646: (Blockchain.cpp:50) Somehow tried to add header that's already in map
-WARN  - 1431800646: (Blockchain.cpp:51)     Header Hash: 000000000000000003390048ffcf6e78725d9863c032c690b9a479a6f130ac81
-WARN  - 1431800646: (Blockchain.cpp:50) Somehow tried to add header that's already in map
-WARN  - 1431800646: (Blockchain.cpp:51)     Header Hash: 000000000000000011c2bc499d60ea233f52e3c01a0e652d6c61f863395d980e
-WARN  - 1431800646: (Blockchain.cpp:50) Somehow tried to add header that's already in map
-WARN  - 1431800646: (Blockchain.cpp:51)     Header Hash: 00000000000000000a4e923d2b9066d115ed317840a4bdbd4b86155b8d0d6381
-WARN  - 1431800646: (Blockchain.cpp:50) Somehow tried to add header that's already in map
-WARN  - 1431800646: (Blockchain.cpp:51)     Header Hash: 000000000000000008e12725ad276d16a4bd43434282f97d05d5cfb378ab1859
-WARN  - 1431800646: (Blockchain.cpp:50) Somehow tried to add header that's already in map
-WARN  - 1431800646: (Blockchain.cpp:51)     Header Hash: 000000000000000007c14b361d4fe8b0578d43051b70b078335d4ccdfabd24f6
-WARN  - 1431800646: (Blockchain.cpp:50) Somehow tried to add header that's already in map
-WARN  - 1431800646: (Blockchain.cpp:51)     Header Hash: 0000000000000000160f830c3b4234adee0bbf88bec999658ddb251d231cc16d
-WARN  - 1431800646: (Blockchain.cpp:50) Somehow tried to add header that's already in map
-WARN  - 1431800646: (Blockchain.cpp:51)     Header Hash: 000000000000000013d22ac7f29342ebaa7ea6dd6d0a0db8f511972b2666377a
-WARN  - 1431800646: (Blockchain.cpp:50) Somehow tried to add header that's already in map
-WARN  - 1431800646: (Blockchain.cpp:51)     Header Hash: 00000000000000001114f7a74345ad847d27ae1ab6154aea01e459a5072c7d6d
-WARN  - 1431800646: (Blockchain.cpp:50) Somehow tried to add header that's already in map
-WARN  - 1431800646: (Blockchain.cpp:51)     Header Hash: 0000000000000000131705e6c6d3201c48fc237ff9ece5df8a99d88c30f878ec
-DEBUG - 1431800646: (Blockchain.cpp:214) Organizing chain w/ rebuild
[New Thread 0x7fffdc9ae700 (LWP 6592)]
[Thread 0x7fffdc9ae700 (LWP 6592) exited]
[New Thread 0x7fffdc9ae700 (LWP 6594)]
[Thread 0x7fffdc9ae700 (LWP 6594) exited]
-INFO  - 1431800646: (BlockUtils.cpp:1337) Looking for first unrecognized block
-INFO  - 1431800646: (BlockUtils.cpp:1489) Loading block data... file 269 offset 69889767
-ERROR - 1431800646: (BlockUtils.cpp:516) Next block header found at offset 69889775
-INFO  - 1431800646: (BlockUtils.cpp:544) Reading raw blocks finished at file 269 offset 79963756
-INFO  - 1431800646: (BlockUtils.cpp:1354) Wrote blocks to DB in 0.06s
-INFO  - 1431800646: (BlockUtils.cpp:1371) Checking dupIDs from 226068 onward
-WARN  - 1431800646: (BlockWriteBatcher.cpp:1556) Starting with: 
-WARN  - 1431800646: (BlockWriteBatcher.cpp:1557) 1 workers
-WARN  - 1431800646: (BlockWriteBatcher.cpp:1558) 1 writers
-WARN  - 1431800646: (BlockUtils.cpp:1071) Scanning from 226068 to 356713
[New Thread 0x7fffdc9ae700 (LWP 6612)]
[New Thread 0x7fffd7fff700 (LWP 6613)]
[New Thread 0x7fffd77fe700 (LWP 6614)]
[New Thread 0x7fffd699e700 (LWP 6615)]
[New Thread 0x7fffc6e90700 (LWP 6616)]
[New Thread 0x7fffc668f700 (LWP 6617)]
[New Thread 0x7fffc5e8e700 (LWP 6618)]

(python:5764): Gtk-CRITICAL **: IA__gtk_progress_configure: assertion `value >= min && value <= max' failed
[Thread 0x7fffc5e8e700 (LWP 6618) exited]
[New Thread 0x7fffc5e8e700 (LWP 6620)]
[New Thread 0x7fffc568d700 (LWP 6621)]
[Thread 0x7fffc568d700 (LWP 6621) exited]
[New Thread 0x7fffc568d700 (LWP 6622)]
[Thread 0x7fffc568d700 (LWP 6622) exited]
[Thread 0x7fffc5e8e700 (LWP 6620) exited]
[New Thread 0x7fffc5e8e700 (LWP 6623)]
[New Thread 0x7fffc568d700 (LWP 6624)]
[New Thread 0x7fffc4e8c700 (LWP 6625)]
[Thread 0x7fffc4e8c700 (LWP 6625) exited]
[Thread 0x7fffc5e8e700 (LWP 6623) exited]
[New Thread 0x7fffc4e8c700 (LWP 6626)]
[Thread 0x7fffc568d700 (LWP 6624) exited]
[Thread 0x7fffc4e8c700 (LWP 6626) exited]
[New Thread 0x7fffc4e8c700 (LWP 6627)]
[Thread 0x7fffc4e8c700 (LWP 6627) exited]
[New Thread 0x7fffc4e8c700 (LWP 6628)]
[New Thread 0x7fffc568d700 (LWP 6629)]
[Thread 0x7fffc568d700 (LWP 6629) exited]
[New Thread 0x7fffc568d700 (LWP 6630)]
[Thread 0x7fffc568d700 (LWP 6630) exited]
[New Thread 0x7fffc568d700 (LWP 6631)]
[Thread 0x7fffc4e8c700 (LWP 6628) exited]
[New Thread 0x7fffc5e8e700 (LWP 6632)]
[New Thread 0x7fffc4e8c700 (LWP 6633)]
[Thread 0x7fffc5e8e700 (LWP 6632) exited]
[New Thread 0x7fffb7fff700 (LWP 6634)]
[Thread 0x7fffb7fff700 (LWP 6634) exited]
[New Thread 0x7fffb77fe700 (LWP 6635)]
[Thread 0x7fffc4e8c700 (LWP 6633) exited]
[New Thread 0x7fffb7fff700 (LWP 6636)]
[Thread 0x7fffb7fff700 (LWP 6636) exited]
[New Thread 0x7fffb7fff700 (LWP 6637)]
[Thread 0x7fffc568d700 (LWP 6631) exited]
[Thread 0x7fffb7fff700 (LWP 6637) exited]
[New Thread 0x7fffb7fff700 (LWP 6638)]
[Thread 0x7fffb7fff700 (LWP 6638) exited]
[New Thread 0x7fffb7fff700 (LWP 6639)]
[Thread 0x7fffb7fff700 (LWP 6639) exited]
[Thread 0x7fffb77fe700 (LWP 6635) exited]
[New Thread 0x7fffc5e8e700 (LWP 6640)]
[New Thread 0x7fffb77fe700 (LWP 6641)]
[New Thread 0x7fffb7fff700 (LWP 6642)]
[Thread 0x7fffb7fff700 (LWP 6642) exited]
[Thread 0x7fffc5e8e700 (LWP 6640) exited]
[New Thread 0x7fffb7fff700 (LWP 6643)]
[Thread 0x7fffb77fe700 (LWP 6641) exited]
[New Thread 0x7fffc568d700 (LWP 6644)]
[Thread 0x7fffc568d700 (LWP 6644) exited]
[New Thread 0x7fffc568d700 (LWP 6645)]
[New Thread 0x7fffb77fe700 (LWP 6646)]
[Thread 0x7fffb77fe700 (LWP 6646) exited]
[Thread 0x7fffc568d700 (LWP 6645) exited]
-WARN  - 1431800658: (BlockWriteBatcher.cpp:355) Finished applying blocks up to 227500
[New Thread 0x7fffc568d700 (LWP 6647)]
[Thread 0x7fffc568d700 (LWP 6647) exited]
[Thread 0x7fffb7fff700 (LWP 6643) exited]
[New Thread 0x7fffc5e8e700 (LWP 6648)]
[New Thread 0x7fffb7fff700 (LWP 6649)]
[New Thread 0x7fffc568d700 (LWP 6650)]
[Thread 0x7fffc5e8e700 (LWP 6648) exited]
[Thread 0x7fffc568d700 (LWP 6650) exited]
[New Thread 0x7fffb77fe700 (LWP 6651)]
[New Thread 0x7fffc568d700 (LWP 6652)]
[New Thread 0x7fffc4e8c700 (LWP 6653)]
[Thread 0x7fffb7fff700 (LWP 6649) exited]
[Thread 0x7fffc4e8c700 (LWP 6653) exited]
[New Thread 0x7fffc4e8c700 (LWP 6654)]
[Thread 0x7fffb77fe700 (LWP 6651) exited]
[Thread 0x7fffc4e8c700 (LWP 6654) exited]
[New Thread 0x7fffc4e8c700 (LWP 6655)]
[Thread 0x7fffc4e8c700 (LWP 6655) exited]
[Thread 0x7fffc568d700 (LWP 6652) exited]
[New Thread 0x7fffc5e8e700 (LWP 6656)]
[Thread 0x7fffc5e8e700 (LWP 6656) exited]
[New Thread 0x7fffc568d700 (LWP 6658)]
[New Thread 0x7fffc4e8c700 (LWP 6659)]
[Thread 0x7fffc4e8c700 (LWP 6659) exited]
[New Thread 0x7fffc4e8c700 (LWP 6660)]
[Thread 0x7fffc568d700 (LWP 6658) exited]
[New Thread 0x7fffb77fe700 (LWP 6661)]
[Thread 0x7fffb77fe700 (LWP 6661) exited]
[New Thread 0x7fffb77fe700 (LWP 6662)]
[Thread 0x7fffb77fe700 (LWP 6662) exited]
[New Thread 0x7fffb77fe700 (LWP 6663)]
[Thread 0x7fffb77fe700 (LWP 6663) exited]
[New Thread 0x7fffb77fe700 (LWP 6664)]
[Thread 0x7fffb77fe700 (LWP 6664) exited]
[Thread 0x7fffc4e8c700 (LWP 6660) exited]
[New Thread 0x7fffc5e8e700 (LWP 6665)]
[New Thread 0x7fffc4e8c700 (LWP 6666)]
[Thread 0x7fffc5e8e700 (LWP 6665) exited]
[New Thread 0x7fffb77fe700 (LWP 6667)]
[Thread 0x7fffb77fe700 (LWP 6667) exited]
[Thread 0x7fffc4e8c700 (LWP 6666) exited]
[New Thread 0x7fffc4e8c700 (LWP 6668)]
[New Thread 0x7fffb77fe700 (LWP 6669)]
[New Thread 0x7fffc568d700 (LWP 6670)]
[Thread 0x7fffc568d700 (LWP 6670) exited]
[Thread 0x7fffb77fe700 (LWP 6669) exited]
[New Thread 0x7fffb77fe700 (LWP 6671)]
[Thread 0x7fffb77fe700 (LWP 6671) exited]
[New Thread 0x7fffb77fe700 (LWP 6672)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd7fff700 (LWP 6613)]
0x00007ffff70b6d00 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) backtrace
#0  0x00007ffff70b6d00 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fffef6c44ac in BinaryData::copyFrom (this=0x7fffd7ffe800, inData=0x7fff6807d1e3 , sz=80) at BinaryData.h:196
#2  0x00007fffef7150b7 in BlockHeader::unserialize (this=0x7fffd7ffe800, ptr=0x7fff6807d1e3 , size=80) at BlockObj.cpp:30
#3  0x00007fffef71527b in BlockHeader::unserialize (this=0x7fffd7ffe800, str=...) at BlockObj.cpp:47
#4  0x00007fffef7152bd in BlockHeader::unserialize (this=0x7fffd7ffe800, brr=...) at BlockObj.cpp:53
#5  0x00007fffef6e0a8b in BlockHeader::BlockHeader (this=0x7fffd7ffe800, brr=...) at BlockObj.h:52
#6  0x00007fffef7a132a in PulledBlock::unserializeFullBlock (this=0x7fffa9016b40, brr=..., doFrag=true, withPrefix=false) at BlockWriteBatcher.h:230
#7  0x00007fffef78d4dd in GrabThreadData::pullBlockAtIter (pb=..., iter=..., db=0x165b6b0, bfa=...) at BlockWriteBatcher.cpp:489
#8  0x00007fffef78936d in GrabThreadData::grabBlocksFromDB (blockData=..., threadId=0) at BlockWriteBatcher.cpp:279
#9  0x00007fffef7ca79f in std::_Bind_simple, unsigned int))(std::shared_ptr, unsigned int)>::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) (this=0x7fffba7b9620) at /usr/include/c++/4.7/functional:1598
#10 0x00007fffef7ca461 in std::_Bind_simple, unsigned int))(std::shared_ptr, unsigned int)>::operator()() (
    this=0x7fffba7b9620) at /usr/include/c++/4.7/functional:1586
#11 0x00007fffef7ca24c in std::thread::_Impl, unsigned int))(std::shared_ptr, unsigned int)> >::_M_run() (this=0x7fffba7b9608) at /usr/include/c++/4.7/thread:115
#12 0x00007ffff4e65400 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#13 0x00007ffff7bc7b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#14 0x00007ffff707195d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#15 0x0000000000000000 in ?? ()

Not typical of the first crashes, but there's probably something useful in here. There's two separate trials from the same tx scan; bitcoind crashed in the first trial, and the tx scan just carried on. I wasn't too sure about that, and thought that at least starting bitcoind again was a good idea. It wasn't/it didn't work out (SDM considered bitcoind reconnected only once Armory went into it's shutdown routine. Where it would normally throw up a balloon notifier to indicate bitcoind disconnection, instead a re-establishment notifier appeared, the shutdown routine then crashed). So there's definitely some information there to help with debugging the Db building when unexpected/disruptive things happen.

goatpig

legendary

Activity: 3640

Merit: 1345

Armory Developer

Welcome to my world =P

Threading issues are tricky. Consider no one has ran into trouble in-house, and our first 2 testers get something right away.

You could try to force the thread count per task manually see how it reacts. In BlockWriteBatcher.cpp, around line 1540, add the lines in bold:

Quote

else
{
//otherwise, give workers 90% of the processing power
int32_t writers = (totalThreadCount_ * 10) / 100;
if (writers < 1)
writers = 1;

int32_t workers = totalThreadCount_ - writers;
if (workers < 1)
workers = 1;

workers = 1;
writers = 1;

nWorkers_.store(workers);
nWriters_.store(writers);
}

This controls the amount of workers (reading through transactions and extracting history) and writers (here you would force them both to 1 to test low performance stability).

Also, around line 385:

Quote

{
//Grab the SSHheader static mutex. This makes sure only this scan is
//creating new SSH keys. If several scanning threads were to take place,
//it could possibly result in key collision, as scan threads are not aware
//of each others' state
unique_lock addressingLock(SSHheaders::keyAddressingMutex_);

uint32_t nThreads = 3;
if (int(endBlock) - int(startBlock) < 100)
nThreads = 1;

nThreads = 1;

prepareSshToModify(scf);

This controls the amount of "grab" threads, which pull raw data from the blockchain and serialize it into PulledBlock objects used by the workers. Be nice and don't comment on my naming sense, unlike some of my colleagues T__T.

This stuff needs consolidated but I'll get to that once the thread toggler is done. As you can see, it runs on static thread counts currently, but it's meant to adjust resource per task dynamically (to squeeze every last drop of processing power regardless of the machine, and eventually give the user live control over how many cpu cores it can use).

For max performance in Fullnode, you want a grab thread per worker and only 1 writer.

Carlton Banks

legendary

Activity: 3430

Merit: 3074

Quote from: goatpig on May 15, 2015, 07:56:45 PM

Carlton Banks: That's usually symptomatic of a threading issue. Throw off the timing a little and the issue doesn't appear anymore.

I thought it couldn't possibly have been a threading problem, as yesterday the behaviour was totally consistent across multiple trials. And today it isn't, so I guess it must be threading related (someone might think you knew something about this code Cheesy

). That's pretty curious though, several consecutive trials that generate basically the same result, and then several more consecutive trials that produce completely different result, also all the same as each other, and all without any material change to the build. In addition, not one GTK+ CRITICAL assertion fails appeared on the console today.

To clarify the pattern of crashing yesterday: scanning from blocks 0 - 200,000, Armory crashed without even sending segfault messages to console, and it only got through 2-5 thousand blocks before the crashes. That's a lot of restarts to get it to scan the first 200,000 blocks.

So I've got no segfault tracebacks to post, as I've not had even one. Will carry on testing debug build using gdb in hope it will enter the same state again.

goatpig

legendary

Activity: 3640

Merit: 1345

Armory Developer

btchris: unless you consistantly get the same error, this probably the aftermath of a buffer overrun in another thread

Carlton Banks: That's usually symptomatic of a threading issue. Throw off the timing a little and the issue doesn't appear anymore.

Carlton Banks

legendary

Activity: 3430

Merit: 3074

Quote from: goatpig on May 15, 2015, 04:42:55 PM

First install gdb. On Debian based systems, sudo apt-get install gdb will do it. I'm not familiar with rpm but I expect there are gdb builds available.

With gdb installed, type these commands in the top code folder:

Quote

make clean
make DEBUG=1 <- build with debug symbols
gdb python <- start python in debug mode
run ./ArmoryQt.py <- The command line argument goes after run
... <- code is now running, wait till it segfaults
backtrace <- after it segfaults, you receive control back, type in backtrace and paste the result back in this thread

Ok, in the gdb environment and using a build with the debug level you specified, 93.99.1 scans the wallet without a single complaint. That seems pretty weird. Didn't re-checkout, didn't re-clone, didn't change a thing other than follow the above instructions. It looks like the ffreeze branch is up to the same commit as yesterday anyway, so checking out or re-cloning couldn't cause a difference. Don't understand it at all.

Also tried outside of gdb, also the same. Still waiting for the scan to complete in this trial, but it seems just as stable as when using gdb

btchris

hero member

Activity: 672

Merit: 504

a.k.a. gurnec on GitHub

Code:

First-chance exception at 0x000007FEDFD63450 (_CppBlockUtils.pyd) in python.exe: 0xC0000005: Access violation reading location 0x0000000088067A8D.

On Win 7 64-bit, I'm also getting an access violation while scanning txs. Running the latest in the ffreeze branch (578c072). Here's a stack trace (via VS 2013) from a debug build:

Code:

 	_CppBlockUtils.pyd!memcpy() Line 356	Unknown
 	_CppBlockUtils.pyd!BinaryData::copyFrom(const unsigned char * inData=0x0000000088067a8d, unsigned __int64 sz=80) Line 198	C++
 	_CppBlockUtils.pyd!BlockHeader::unserialize(const unsigned char * ptr=0x0000000088067a8d, unsigned int size=80) Line 31	C++
 	_CppBlockUtils.pyd!BlockHeader::unserialize(const BinaryDataRef & str={...}) Line 48	C++
 	_CppBlockUtils.pyd!BlockHeader::unserialize(BinaryRefReader & brr={...}) Line 54	C++
 	_CppBlockUtils.pyd!BlockHeader::BlockHeader(BinaryRefReader & brr={...}) Line 52	C++
 	_CppBlockUtils.pyd!PulledBlock::unserializeFullBlock(BinaryRefReader brr={...}, bool doFrag=true, bool withPrefix=false) Line 230	C++
>	_CppBlockUtils.pyd!GrabThreadData::pullBlockAtIter(PulledBlock & pb={...}, LDBIter & iter={...}, LMDBBlockDatabase * db=0x00000000003baa10, BlockFileAccessor & bfa={...}) Line 490	C++
 	_CppBlockUtils.pyd!GrabThreadData::grabBlocksFromDB(std::shared_ptr blockData={...}, unsigned int threadId=2) Line 279	C++
 	_CppBlockUtils.pyd!std::_Bind<1,void,void (__cdecl*const)(std::shared_ptr,unsigned int),std::shared_ptr,unsigned int>::_Do_call<,0,1>(std::tuple<> _Myfargs={...}, std::_Arg_idx<0,1> __formal={...}) Line 1150	C++
 	_CppBlockUtils.pyd!std::_Bind<1,void,void (__cdecl*const)(std::shared_ptr,unsigned int),std::shared_ptr,unsigned int>::operator()<>() Line 1138	C++
 	_CppBlockUtils.pyd!std::_LaunchPad,unsigned int),std::shared_ptr,unsigned int> >::_Run(std::_LaunchPad,unsigned int),std::shared_ptr,unsigned int> > * _Ln=0x0000000007d1d060) Line 196	C++
 	_CppBlockUtils.pyd!std::_LaunchPad,unsigned int),std::shared_ptr,unsigned int> >::_Go() Line 188	C++
 	_CppBlockUtils.pyd!_Call_func(void * _Data=0x000000000f8b18b0) Line 28	C++
 	_CppBlockUtils.pyd!_callthreadstartex() Line 376	C
 	_CppBlockUtils.pyd!_threadstartex(void * ptd=0x000000000f8b18b0) Line 354	C
 	kernel32.dll!BaseThreadInitThunk()	Unknown
 	ntdll.dll!RtlUserThreadStart()	Unknown

I think there's something going on near GrabThreadData::pullBlockAtIter(); here's a locals dump after switching to that frame:

Code:

-		bdr	{ptr_=0x0000000088067a8d "" nBytes_=155478 }	BinaryDataRef
+		    ptr_	0x0000000088067a8d ""	const unsigned char *
		    nBytes_	155478	unsigned __int64
-		pb	{stxMap_={ size=0 } nextBlock_=empty fmp_={current_=shared_ptr {lastSeenCumulated_={...} fetch_=FETCH_NONE (0) filemap_=0xec27b9f8692f2700  ...} [1 strong ref] [default] ...} }	PulledBlock &
+		    DBBlock	{dataCopy_={data_={ size=0 } } thisHash_={data_={ size=0 } } numTx_=4294967295 ...}	DBBlock
+		    stxMap_	{ size=0 }	std::map,std::allocator > >
+		    nextBlock_	empty	std::shared_ptr
-		    fmp_	{current_=shared_ptr {lastSeenCumulated_={...} fetch_=FETCH_NONE (0) filemap_=0xec27b9f8692f2700  ...} [1 strong ref] [default] ...}	FileMapContainer
-		        current_	shared_ptr {lastSeenCumulated_={...} fetch_=FETCH_NONE (0) filemap_=0xec27b9f8692f2700  ...} [1 strong ref] [default]	std::shared_ptr
-		            [ptr]	0x000000005ad12f50 {lastSeenCumulated_={...} fetch_=FETCH_NONE (0) filemap_=0xec27b9f8692f2700  ...}	FileMap *
-		                lastSeenCumulated_	{...}	std::atomic
		                fetch_	FETCH_NONE (0)	FILEMAP_FETCH
+		                filemap_	0xec27b9f8692f2700 	unsigned char *
		                mapsize_	15458524216405398507	unsigned __int64
		                fnum_	82	unsigned short
+		            [deleter and allocator]	default	std::_Ref_count_base
+		            [Raw View]	0x000000004186a2f8 {...}	std::shared_ptr *
-		        prev_	0x00000000154bf8e0 shared_ptr {lastSeenCumulated_={...} fetch_=FETCH_ACCESSED (2) filemap_=0x0000000021b70040 "ù¾´Ù\x1ef\x2" ...} [941 strong refs] [default]	std::shared_ptr *
-		            [ptr]	0x0000000069977950 {lastSeenCumulated_={...} fetch_=FETCH_ACCESSED (2) filemap_=0x0000000021b70040 "ù¾´Ù\x1ef\x2" ...}	FileMap *
+		                lastSeenCumulated_	{...}	std::atomic
		                fetch_	FETCH_ACCESSED (2)	FILEMAP_FETCH
-		                filemap_	0x0000000021b70040 "ù¾´Ù\x1ef\x2"	unsigned char *
		                mapsize_	134020078	unsigned __int64
		                fnum_	81	unsigned short
+		            [deleter and allocator]	default	std::_Ref_count_base
+		            [Raw View]	0x00000000154bf8e0 {...}	std::shared_ptr *
+		iter	{iter_={db_=0x00000000003baaa0 {env=0x000000000038f000 {dbenv=0x000000000581ed80 {...} threadTxMutex_=...} ...} ...} ...}	LDBIter &
+		db	0x00000000003baa10 {baseDir_="C:\\Users\\Chris\\AppData\\Roaming\\Armory\\databases" genesisBlkHash_=...}	LMDBBlockDatabase *
+		bfa	{blkFiles_=shared_ptr { size=270 } [3 strong refs] [default] blkMaps_={ size=2 } lastSeenCumulative_=...}	BlockFileAccessor &
		fnum	82	unsigned short
+		brr	{bdRef_={ptr_=0x0000000065ebbb90 "R" nBytes_=16 } totalSize_=16 pos_=16 }	BinaryRefReader
		offset	555597	unsigned __int64
		size	155478	unsigned int

First off, fnum, offset, and size look good. I verified that they point to the beginning of block 258860, and that the block file doesn't appear corrupted. At the very least, the merkle root is correct.

Here are two things that pop out at me though. pb.fmp_.current_->filemap_ and pb.fmp_.current_->mapsize_ are clearly invalid, perhaps something is overwriting them? IIUC, bdr.ptr_ is calculated from filemap_ and offset, and so bdr.ptr_ is invalid, and it's what eventually gets passed to memcpy() which causes the access violation.

Another thing that looks strange is that I thought (I could be wrong) that bdr.ptr_ == filemap_ + offset, but in the locals above it's not (or multiple things are getting overwritten?).

I'm not quite sure where to go from here.... whatever happened, it may be too late at this point in the debug to find.

goatpig

legendary

Activity: 3640

Merit: 1345

Armory Developer

Quote from: Carlton Banks on May 15, 2015, 04:07:22 PM

Quote from: goatpig on May 15, 2015, 03:38:07 PM

Carlton Banks: would you mind building ffreeze in debug mode, running it in gdb and posting the backtrace when it crashes?

I don't totally know what you mean, but yes in principle. What's gdb?

https://www.gnu.org/software/gdb/

Essentially, linux debug mode. First install gdb. On Debian based systems, sudo apt-get install gdb will do it. I'm not familiar with rpm but I expect there are gdb builds available.

With gdb installed, type these commands in the top code folder:

Quote

make clean
make DEBUG=1 <- build with debug symbols
gdb python <- start python in debug mode
run ./ArmoryQt.py <- The command line argument goes after run
... <- code is now running, wait till it segfaults
backtrace <- after it segfaults, you receive control back, type in backtrace and paste the result back in this thread

Carlton Banks

legendary

Activity: 3430

Merit: 3074

Quote from: goatpig on May 15, 2015, 03:38:07 PM

Carlton Banks: would you mind building ffreeze in debug mode, running it in gdb and posting the backtrace when it crashes?

I don't totally know what you mean, but yes in principle. What's gdb?

goatpig

legendary

Activity: 3640

Merit: 1345

Armory Developer

Carlton Banks: would you mind building ffreeze in debug mode, running it in gdb and posting the backtrace when it crashes?

goatpig

legendary

Activity: 3640

Merit: 1345

Armory Developer

Quote from: justusranvier on May 15, 2015, 12:23:47 PM

Quote from: etotheipi on May 13, 2015, 06:54:19 PM

It's also is a heck of a lot faster to start up Armory the first time once Core is sync'd, since we're not building a 30+ GB database anymore. It's called "headless fullnode" because it's the same as previous "fullnode" version of Armory, but without maintaining it's own copy of the blockchain (of course, if you run supernode it will maintain your 2x-3x sized DB, but that's not the default Armory mode).

Will it ever be possible to run Armory without requiring filesystem-level access to the block files?

Seems like a change such as this makes such an operating mode more difficult.

I run bitcoind and Armory in separate virtual machines, and finding a way to share those files in a way that gets all the permissions right and satisfies LevelDB's locking requirements is non-trivial.

It would be great to have an option for Armory to maintain its own database using blocks it obtains via its peer connection to the node, rather than via direct filesystem access, without requiring a supernode.

We do plan on implementing blocks over p2p

justusranvier

legendary

Activity: 1400

Merit: 1009

Quote from: etotheipi on May 13, 2015, 06:54:19 PM

It's also is a heck of a lot faster to start up Armory the first time once Core is sync'd, since we're not building a 30+ GB database anymore. It's called "headless fullnode" because it's the same as previous "fullnode" version of Armory, but without maintaining it's own copy of the blockchain (of course, if you run supernode it will maintain your 2x-3x sized DB, but that's not the default Armory mode).

Will it ever be possible to run Armory without requiring filesystem-level access to the block files?

Seems like a change such as this makes such an operating mode more difficult.

I run bitcoind and Armory in separate virtual machines, and finding a way to share those files in a way that gets all the permissions right and satisfies LevelDB's locking requirements is non-trivial.

It would be great to have an option for Armory to maintain its own database using blocks it obtains via its peer connection to the node, rather than via direct filesystem access, without requiring a supernode.

Carlton Banks

legendary

Activity: 3430

Merit: 3074

Ok, any wallet that needs it's tx hints recording (plus whatever else) is somewhere close to the problem. If I create an empty wallet and rebuild the Db, nice smooth scanning, except for a couple of seg faults

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

This reminds me that we should probably remove all torrent-related code from Armory for 0.94. It is no longer needed with Core 0.10+ (headers first), and it was actually designed such that you could remove the torrent code directory and Armory would bypass trying to use it. We wanted to wait for sufficient people to have upgraded to Core 0.10 and Armory 0.93+, and I think that's likely to be the case now (we couldn't upgrade the Core links in the secure downloader, without inadvertantly leading to 0.92 users installing Core 0.10 which doesn't work).

Carlton Banks

legendary

Activity: 3430

Merit: 3074

Can't get the SDM code to find satoshi datadir no matter what I do. Works fine without it though.

goatpig

legendary

Activity: 3640

Merit: 1345

Armory Developer

Quote from: Carlton Banks on May 14, 2015, 04:32:35 PM

Also, SDM mode produces this:

Code:

Traceback (most recent call last):
  File "/usr/lib/armory-testing/ArmoryQt.py", line 7129, in 
    form = ArmoryMainWindow(splashScreen=SPLASH)
  File "/usr/lib/armory-testing/ArmoryQt.py", line 259, in __init__
    self.startBitcoindIfNecessary()
  File "/usr/lib/armory-testing/ArmoryQt.py", line 2441, in startBitcoindIfNecessary
    self.setSatoshiPaths()
  File "/usr/lib/armory-testing/ArmoryQt.py", line 2499, in setSatoshiPaths
    TheTDM.setSatoshiDir(self.satoshiHomePath)
AttributeError: 'FakeTDM' object has no attribute 'setSatoshiDir'

and then crashes.

That's the torrent manager failing to find your /blocks folder. That suggests it's looking at an empty folder.

Carlton Banks

legendary

Activity: 3430

Merit: 3074

Also, SDM mode produces this:

Code:

Traceback (most recent call last):
  File "/usr/lib/armory-testing/ArmoryQt.py", line 7129, in 
    form = ArmoryMainWindow(splashScreen=SPLASH)
  File "/usr/lib/armory-testing/ArmoryQt.py", line 259, in __init__
    self.startBitcoindIfNecessary()
  File "/usr/lib/armory-testing/ArmoryQt.py", line 2441, in startBitcoindIfNecessary
    self.setSatoshiPaths()
  File "/usr/lib/armory-testing/ArmoryQt.py", line 2499, in setSatoshiPaths
    TheTDM.setSatoshiDir(self.satoshiHomePath)
AttributeError: 'FakeTDM' object has no attribute 'setSatoshiDir'

and then crashes.

Carlton Banks

legendary

Activity: 3430

Merit: 3074

There is a pattern to it. It's very crash prone from blocks 0 > ~200,000. Then it stayed up until top block, minus one seg fault. Doesn't correspond to any pattern in the wallet file/s I'm trying it out with, or I don't think so anyway (I originally though it might be coinbase tx's that were the problem, but I get this with any wallet)

goatpig

legendary

Activity: 3640

Merit: 1345

Armory Developer

Quote from: Carlton Banks on May 14, 2015, 02:21:03 PM

Whole thing crashes when scanning tx's. CPU/Memory usage goes vertical-ish.

Possibly the source of offence:

Code:

(python:3377): Gtk-CRITICAL **: IA__gtk_progress_configure: assertion `value >= min && value <= max' failed
Killed

Logs are otherwise uneventful

How far did it get in block height?

Carlton Banks

legendary

Activity: 3430

Merit: 3074

Quote from: etotheipi on May 14, 2015, 03:00:08 PM

Did you pull the latest ffreeze?

I did:

Code:

git clone git://github.com/etotheipi/BitcoinArmory.git
cd ~/BitcoinArmory
git checkout ffreeze
make

Quote from: etotheipi on May 14, 2015, 03:00:08 PM

Did you wipe the database?

Yes

Quote from: etotheipi on May 14, 2015, 03:00:08 PM

Is the version number 0.93.99.1?

Yes

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: Carlton Banks on May 14, 2015, 02:21:03 PM

Whole thing crashes when scanning tx's. CPU/Memory usage goes vertical-ish.

Possibly the source of offence:

Code:

(python:3377): Gtk-CRITICAL **: IA__gtk_progress_configure: assertion `value >= min && value <= max' failed
Killed

Logs are otherwise uneventful

Did you pull the latest ffreeze? There was a problem with thread synchronization a couple days ago, and we all experienced the exact same issue. As of yesterday (when I posted this thread) that was fixed and no one else had the issue. Did you wipe the database? Is the version number 0.93.99.1?

Topic: Starting preliminary 0.94 testing - "Headless fullnode" - page 12. (Read 15098 times)