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

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

picobit
hero member
Activity: 547
Merit: 500
Decor in numeris
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 19, 2015, 01:31:58 PM
#44
Quote
Glad to hear about how inconvenient this "licensed freedom" stuff is in reality (whoever would have guessed? lol).

I used to be a strong supporter of open source licenses; and I still firmly support the principle.  But I must admit that they are showing signs of failure.  Sad

BTW, copyright is not something you "claim".  Copyright is something you have automatically if you write something, so if you do *not* release your software under some sort of license then you can certainly sue anybody who uses it in their own code later.  Open source licenses are probably a necessary evil; the original idea being to "subvert" copyright law to do the opposite of what the law intends: to allow you to reuse the code instead of forbid it.  I think that GPL and friends to a large degree have succeeded in that, but their own success (and the resulting proliferation of licenses) hold the seed to failure.

I guess we are neither 100% agreeing, nor 100% disagreeing, but certainly approaching 100% off-topic...  Smiley
Carlton Banks
legendary
Activity: 3430
Merit: 3080
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 19, 2015, 12:40:12 PM
#43
Quote from: picobit on May 19, 2015, 12:06:48 PM
While I agree that trying to protect freedom by enforcing restrictions to said freedom is a bit absurd, it sort of makes sense under the current copyright laws, if you do not want others to make a little change to your code and then claiming it as their own - possibly taking away your own freedom to use it.

You can prove you wrote the code without licensing it, and that was possible pretty much as of the advent of PGP (which was less than 10 years after Stallman's original publication of GPL). Copyright as a basic concept makes no sense for openly distributed code, so there is literally no reason to license the code at all. If someone tries to copyright your code after the fact, then the truth will be plain for all to see.

Quote from: picobit on May 19, 2015, 12:06:48 PM
Unfortunately, the open source license situation is by now completely out of control, with dozens of slightly incompatible licenses out there.  Trying to create something using parts from several projects is a nightmare.  It became obviously absurd once the GNU Public License stopped being compatible with itself! (version 2 and 3 are incompatible!).




Glad to hear about how inconvenient this "licensed freedom" stuff is in reality (whoever would have guessed? lol). If I was a lawyer looking at that previous sentence, I would be slavering: "Delicious conflict! Don't stop, I'm almost there..."
picobit
hero member
Activity: 547
Merit: 500
Decor in numeris
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 19, 2015, 12:06:48 PM
#42
The GPL states that you can use and modify the code in any way you like, with the sole exception that if you distribute the original or modified code you must do so under the same license.  Other open source the licenses do not contain that restriction.  The AGPL place the extra restriction on your use of the code that if you make a publicly facing server using modified code, you must make those modifications publicly available.  In principle, that is a good idea, you then know what you get as a service.  But it does restrict using other peoples codes for your own business purposes.  Fortunately, Armory is not publicly facing, it has Bitcoin Core between itself and the world.  Otherwise, the license would indeed prevent you from trying out such a modification!  Angry

While I agree that trying to protect freedom by enforcing restrictions to said freedom is a bit absurd, it sort of makes sense under the current copyright laws, if you do not want others to make a little change to your code and then claiming it as their own - possibly taking away your own freedom to use it.

Unfortunately, the open source license situation is by now completely out of control, with dozens of slightly incompatible licenses out there.  Trying to create something using parts from several projects is a nightmare.  It became obviously absurd once the GNU Public License stopped being compatible with itself! (version 2 and 3 are incompatible!).


Carlton Banks
legendary
Activity: 3430
Merit: 3080
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 19, 2015, 10:43:30 AM
#41
Quote from: goatpig on May 19, 2015, 08:49:58 AM
Quote from: Carlton Banks on May 19, 2015, 08:26:31 AM
That's fine, as long as I perceive no risk to me or my affects, then I'm as happy doing that as I've ever been (you're publishing to github after all).

My understanding of the AGPL license is that if you were to modify Armory source and distribute binaries (or run a commercial activity) based on those changes without publishing the altered code publicly, you would be in infringement. I don't think this affects changes for personal and non commercial use. Regardless, if you were to fork Armory publicly (say on a public github repo), you could do as many changes as you like. That's just my interpretation however.

From my perspective there is no license infringement in doing those changes under these conditions, and you have my guarantee I won't be coming after you over this. Again, I'm no lawyer and these words only engage me. I don't have the credentials to speak for the business on this matter.

If anything the responsibility is mine since I asked you to do these changes.

I have next to zero expectation that ATI would do something like that, but stranger things have happened. I'm just not going to use my own valuable time in order to observe something I believe is wrong. So, testing: yes. Reading/acknowledging conditions in "freedom" licenses: no.

"I hereby state the conditions under which you can be free". It's absurd, and fell out of relevance as soon as the first digitally signed commits were available for repo software.
goatpig
legendary
Activity: 3766
Merit: 1364
Armory Developer
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 19, 2015, 08:49:58 AM
#40
Quote from: Carlton Banks on May 19, 2015, 08:26:31 AM
That's fine, as long as I perceive no risk to me or my affects, then I'm as happy doing that as I've ever been (you're publishing to github after all).

My understanding of the AGPL license is that if you were to modify Armory source and distribute binaries (or run a commercial activity) based on those changes without publishing the altered code publicly, you would be in infringement. I don't think this affects changes for personal and non commercial use. Regardless, if you were to fork Armory publicly (say on a public github repo), you could do as many changes as you like. That's just my interpretation however.

From my perspective there is no license infringement in doing those changes under these conditions, and you have my guarantee I won't be coming after you over this. Again, I'm no lawyer and these words only engage me. I don't have the credentials to speak for the business on this matter.

If anything the responsibility is mine since I asked you to do these changes.
Carlton Banks
legendary
Activity: 3430
Merit: 3080
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 19, 2015, 08:26:31 AM
#39
Quote from: goatpig on May 19, 2015, 07:52:43 AM
Quote from: Carlton Banks on May 19, 2015, 07:01:50 AM
I don't know whether you're asking me to break the terms of the license by doing that. Can I get some assurance that I'm protected from legal action by your employers? I have zero interest in reading the license terms myself, it is, in my opinion, abhorrent to use litigation to enforce so-called freedom.

I don't know how the legal stuff goes. I can give you my personal guarantee but I don't know what that is worth either, legally speaking (I doubt I'm in a position to do that). I'm going to push some stuff today and I'll disable the prefetch thread along the way, how about you wait for that?

That's fine, as long as I perceive no risk to me or my affects, then I'm as happy doing that as I've ever been (you're publishing to github after all).
goatpig
legendary
Activity: 3766
Merit: 1364
Armory Developer
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 19, 2015, 07:52:43 AM
#38
Quote from: Carlton Banks on May 19, 2015, 07:01:50 AM
I don't know whether you're asking me to break the terms of the license by doing that. Can I get some assurance that I'm protected from legal action by your employers? I have zero interest in reading the license terms myself, it is, in my opinion, abhorrent to use litigation to enforce so-called freedom.

I don't know how the legal stuff goes. I can give you my personal guarantee but I don't know what that is worth either, legally speaking (I doubt I'm in a position to do that). I'm going to push some stuff today and I'll disable the prefetch thread along the way, how about you wait for that?
Carlton Banks
legendary
Activity: 3430
Merit: 3080
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 19, 2015, 07:01:50 AM
#37
Quote from: goatpig on May 19, 2015, 06:40:54 AM
Carlton Banks, btcchris: something new to try, disable the block data prefetch thread.

In BlockWriteBatcher.h#416, comment out these 2 lines:

Quote
  LoadedBlockData(const LoadedBlockData&) = delete;
   BFA_PREFETCH getPrefetchMode(void)
   {
      /*if (startBlock_ < endBlock_ && endBlock_ - startBlock_ > 100)
         return PREFETCH_FORWARD;*/
      
      return PREFETCH_NONE;
   }

Regarding speed, in fullnode the bottleneck is your CPU. On my Debian VM with 2 workers I scan fullnode in 40min. On my host with 9 workers I scan it in 5 (i7 5820). Once the thread toggler is ready it should run a lot better than going with some estimated value.

I don't know whether you're asking me to break the terms of the license by doing that. Can I get some assurance that I'm protected from legal action by your employers? I have zero interest in reading the license terms myself, it is, in my opinion, abhorrent to use litigation to enforce so-called freedom.
goatpig
legendary
Activity: 3766
Merit: 1364
Armory Developer
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 19, 2015, 06:40:54 AM
#36
Carlton Banks, btcchris: something new to try, disable the block data prefetch thread.

In BlockWriteBatcher.h#416, comment out these 2 lines:

Quote
  LoadedBlockData(const LoadedBlockData&) = delete;
   BFA_PREFETCH getPrefetchMode(void)
   {
      /*if (startBlock_ < endBlock_ && endBlock_ - startBlock_ > 100)
         return PREFETCH_FORWARD;*/
      
      return PREFETCH_NONE;
   }

Regarding speed, in fullnode the bottleneck is your CPU. On my Debian VM with 2 workers I scan fullnode in 40min. On my host with 9 workers I scan it in 5 (i7 5820). Once the thread toggler is ready it should run a lot better than going with some estimated value.
njaard
newbie
Activity: 29
Merit: 0
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 18, 2015, 06:43:59 PM
#35
Thank you Carlton Banks,

SIGKILL is often caused by Linux's out-of-memory killer. Linux is saying "I'm out of memory, I'm gonna kill an application that I think is to blame", and in this case it guesses Armory, which is probably the correct one. Running dmesg should show that the "OOM" event. Maybe you can confirm?

The second crash is definitely our fault, but it's hard to tell what's causing it.
Carlton Banks
legendary
Activity: 3430
Merit: 3080
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 18, 2015, 05:51:35 PM
#34
Code:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcb19f700 (LWP 3421)]
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=0x7fffcb19e800, inData=0x7fff44278bc3 "\001", sz=80) at BinaryData.h:196
#2  0x00007fffef7150b7 in BlockHeader::unserialize (this=0x7fffcb19e800, ptr=0x7fff44278bc3 "\001", size=80) at BlockObj.cpp:30
#3  0x00007fffef71527b in BlockHeader::unserialize (this=0x7fffcb19e800, str=...) at BlockObj.cpp:47
#4  0x00007fffef7152bd in BlockHeader::unserialize (this=0x7fffcb19e800, brr=...) at BlockObj.cpp:53
#5  0x00007fffef6e0a8b in BlockHeader::BlockHeader (this=0x7fffcb19e800, brr=...) at BlockObj.h:52
#6  0x00007fffef7a132a in PulledBlock::unserializeFullBlock (this=0x7fff6415def0, 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=2) 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=0x7fffc3db1620) at /usr/include/c++/4.7/functional:1598
#10 0x00007fffef7ca461 in std::_Bind_simple, unsigned int))(std::shared_ptr, unsigned int)>::operator()() (this=0x7fffc3db1620)
    at /usr/include/c++/4.7/functional:1586
#11 0x00007fffef7ca24c in std::thread::_Impl, unsigned int))(std::shared_ptr, unsigned int)> >::_M_run() (this=0x7fffc3db1608)
    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 ?? ()

backtrace from a subsequent run (no GTK+ CRITICAL entries in the log, or anything that appears unusual, like the threads all finishing one after another from the post above this one).
Carlton Banks
legendary
Activity: 3430
Merit: 3080
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 18, 2015, 04:21:45 PM
#33
Code:
(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 2525)]
[New Thread 0x7fffdd1af700 (LWP 2526)]
-INFO  - 1431981856: (BlockUtils.cpp:850) blkfile dir: /home/user/.bitcoin/blocks
-INFO  - 1431981856: (BlockUtils.cpp:851) lmdb dir: /home/user/.armory/databases
-INFO  - 1431981856: (lmdb_wrapper.cpp:439) Opening databases...
-INFO  - 1431981856: (BlockUtils.cpp:1181) Executing: doInitialSyncOnLoad
-INFO  - 1431981856: (BlockUtils.cpp:1253) Total number of blk*.dat files: 271
-INFO  - 1431981856: (BlockUtils.cpp:1254) Total blockchain bytes: 36,239,124,399
-INFO  - 1431981856: (BlockUtils.cpp:1628) Reading headers from db
[New Thread 0x7fffcd690700 (LWP 2552)]
[Thread 0x7fffcd690700 (LWP 2552) exited]
[New Thread 0x7fffcd690700 (LWP 2555)]
[New Thread 0x7fffccd54700 (LWP 2556)]
(ERROR) announcefetch.py:283 - Specified URL was inaccessible
(ERROR) announcefetch.py:284 - Tried: https://bitcoinarmory.com/announce.txt
[Thread 0x7fffccd54700 (LWP 2556) exited]
[Thread 0x7fffcd690700 (LWP 2555) exited]
(ERROR) announcefetch.py:283 - Specified URL was inaccessible
(ERROR) announcefetch.py:284 - Tried: https://s3.amazonaws.com/bitcoinarmory-media/announce.txt
(WARNING) announcefetch.py:297 - Error fetching announce digest
-INFO  - 1431981868: (BlockUtils.cpp:1654) Found 356730 headers in db
-DEBUG - 1431981868: (Blockchain.cpp:214) Organizing chain w/ rebuild
-WARN  - 1431981871: (BlockUtils.cpp:1282) --- Fetching SSH summaries for 491 registered addresses
-INFO  - 1431981871: (BlockUtils.cpp:1295) Left off at file 269, offset 83960315
-INFO  - 1431981871: (BlockUtils.cpp:1298) Reading headers and building chain...
-INFO  - 1431981871: (BlockUtils.cpp:1299) Starting at block file 269 offset 83960315
-INFO  - 1431981871: (BlockUtils.cpp:1301) Block height 356719
-DEBUG - 1431981872: (Blockchain.cpp:214) Organizing chain w/ rebuild
-INFO  - 1431981875: (BlockUtils.cpp:1337) Looking for first unrecognized block
-INFO  - 1431981875: (BlockUtils.cpp:1489) Loading block data... file 269 offset 83960307
-ERROR - 1431981875: (BlockUtils.cpp:516) Next block header found at offset 83960315
-INFO  - 1431981875: (BlockUtils.cpp:544) Reading raw blocks finished at file 269 offset 133863316
-INFO  - 1431981875: (BlockUtils.cpp:544) Reading raw blocks finished at file 270 offset 50901329
-INFO  - 1431981875: (BlockUtils.cpp:1354) Wrote blocks to DB in 0.3s
-INFO  - 1431981875: (BlockUtils.cpp:1371) Checking dupIDs from 356718 onward
-WARN  - 1431981875: (BlockWriteBatcher.cpp:1556) Starting with: 
-WARN  - 1431981875: (BlockWriteBatcher.cpp:1557) 1 workers
-WARN  - 1431981875: (BlockWriteBatcher.cpp:1558) 1 writers
-WARN  - 1431981875: (BlockUtils.cpp:1071) Scanning from 356719 to 357006

(python:2515): Gtk-CRITICAL **: IA__gtk_progress_configure: assertion `value >= min && value <= max' failed
[New Thread 0x7fffcd690700 (LWP 2558)]
[New Thread 0x7fffccd54700 (LWP 2559)]
[New Thread 0x7fffd6a00700 (LWP 2560)]
[New Thread 0x7fffd61ff700 (LWP 2561)]
[New Thread 0x7fffd19fd700 (LWP 2562)]
[New Thread 0x7fffc79a0700 (LWP 2563)]
[New Thread 0x7fffc719f700 (LWP 2564)]
[Thread 0x7fffc719f700 (LWP 2564) exited]
[New Thread 0x7fffc719f700 (LWP 2565)]
[New Thread 0x7fffc699e700 (LWP 2566)]
[New Thread 0x7fffc619d700 (LWP 2567)]
[Thread 0x7fffc619d700 (LWP 2567) exited]
[Thread 0x7fffc719f700 (LWP 2565) exited]
[Thread 0x7fffc699e700 (LWP 2566) exited]
[New Thread 0x7fffc699e700 (LWP 2569)]
[New Thread 0x7fffc619d700 (LWP 2568)]
[Thread 0x7fffc699e700 (LWP 2569) exited]
[New Thread 0x7fffc699e700 (LWP 2570)]
[Thread 0x7fffc699e700 (LWP 2570) exited]
[Thread 0x7fffccd54700 (LWP 2559) exited]
[Thread 0x7fffd61ff700 (LWP 2561) exited]
[Thread 0x7fffc619d700 (LWP 2568) exited]
[New Thread 0x7fffc719f700 (LWP 2571)]
[New Thread 0x7fffc619d700 (LWP 2572)]
[New Thread 0x7fffd61ff700 (LWP 2573)]
[Thread 0x7fffc719f700 (LWP 2571) exited]
[Thread 0x7fffd61ff700 (LWP 2573) exited]
[New Thread 0x7fffd61ff700 (LWP 2574)]
[Thread 0x7fffc619d700 (LWP 2572) exited]
[New Thread 0x7fffc619d700 (LWP 2575)]
[Thread 0x7fffc619d700 (LWP 2575) exited]
[Thread 0x7fffd6a00700 (LWP 2560) exited]
[Thread 0x7fffd61ff700 (LWP 2574) exited]
[New Thread 0x7fffc719f700 (LWP 2576)]
[New Thread 0x7fffd61ff700 (LWP 2577)]
[New Thread 0x7fffd6a00700 (LWP 2578)]
[Thread 0x7fffc719f700 (LWP 2576) exited]
[Thread 0x7fffd6a00700 (LWP 2578) exited]
[Thread 0x7fffd61ff700 (LWP 2577) exited]
[New Thread 0x7fffd6a00700 (LWP 2579)]
[New Thread 0x7fffd61ff700 (LWP 2580)]
[Thread 0x7fffd61ff700 (LWP 2580) exited]
[Thread 0x7fffd6a00700 (LWP 2579) exited]
[New Thread 0x7fffc719f700 (LWP 2581)]
[New Thread 0x7fffd6a00700 (LWP 2582)]
[New Thread 0x7fffd61ff700 (LWP 2583)]
[Thread 0x7fffc719f700 (LWP 2581) exited]
[Thread 0x7fffd61ff700 (LWP 2583) exited]
[Thread 0x7fffd6a00700 (LWP 2582) exited]
[New Thread 0x7fffc719f700 (LWP 2584)]
[Thread 0x7fffc719f700 (LWP 2584) exited]
[New Thread 0x7fffc719f700 (LWP 2585)]
[Thread 0x7fffc79a0700 (LWP 2563) exited]
[Thread 0x7fffd19fd700 (LWP 2562) exited]
-WARN  - 1431981883: (BlockWriteBatcher.cpp:399) --- feedSleep: 0 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:402) --- workers: 0 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:405) --- writeStxo: 0.08 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:407) --- writeStxo_grabMutex: 0 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:410) --- waitingOnSerThread: 0.13 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:412) --- waitForDataToWrite: 18.89 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:416) --- checkForCollisions: 0 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:418) --- getExistingKeys: 0.01 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:420) --- getNewKeys: 0 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:422) --- getSSHHeadersLock: 0 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:424) --- prepareSSHheaders: 0 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:426) --- computeDBKeys: 0 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:428) --- getSshHeaders: 0.01 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:430) --- waitOnNewDBkeys: 0 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:432) --- finishSerializeSSH: 0.05 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:436) --- serializeSSH: 0.12 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:439) --- serializeDataToCommit: 0.02 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:441) --- serializeSubSsh: 0.01 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:443) --- wait on serThread: 0 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:446) --- finishSer: 0.01 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:449) --- putSSH: 0.08 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:451) --- putSTX: 0.02 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:454) --- getnextfeed: 3.39 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:456) --- inControlThread: 19.01 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:459) --- parseTxOut: 4.56 s
-WARN  - 1431981883: (BlockWriteBatcher.cpp:461) --- parseTxIn: 7.5 s
[Thread 0x7fffcd690700 (LWP 2558) exited]
-INFO  - 1431981883: (BlockUtils.cpp:1451) --- bwbDtor: 0s
-INFO  - 1431981883: (BlockUtils.cpp:1452) Scanned Block range in 19.38s
-INFO  - 1431981883: (BlockUtils.cpp:1455) Finished loading at file 270, offset 50901329
-INFO  - 1431981883: (BlockDataViewer.cpp:155) Enabling zero-conf tracking 
[New Thread 0x7fffcd690700 (LWP 2586)]
[Thread 0x7fffcd690700 (LWP 2586) exited]
[Thread 0x7fffc719f700 (LWP 2585) exited]
-DEBUG - 1431981884: (Blockchain.cpp:214) Organizing chain 
[New Thread 0x7fffc719f700 (LWP 2587)]
[Thread 0x7fffc719f700 (LWP 2587) exited]
(ERROR) Networking.py:366 - ***Connection to Satoshi client LOST!  Attempting to reconnect...
[Thread 0x7fffdd1af700 (LWP 2526) exited]
[Thread 0x7ffff7fe5700 (LWP 2515) exited]
[Inferior 1 (process 2515) exited normally]

(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
Log file doesn't exist [yet]
[New Thread 0x7fffddbb6700 (LWP 2635)]
[New Thread 0x7fffdd1af700 (LWP 2636)]
-INFO  - 1431981950: (BlockUtils.cpp:850) blkfile dir: /home/user.bitcoin/blocks
-INFO  - 1431981950: (BlockUtils.cpp:851) lmdb dir: /home/user/.armory/databases
-INFO  - 1431981950: (lmdb_wrapper.cpp:439) Opening databases...
-INFO  - 1431981950: (BlockUtils.cpp:1181) Executing: doInitialSyncOnLoad
-INFO  - 1431981950: (BlockUtils.cpp:1253) Total number of blk*.dat files: 271
-INFO  - 1431981950: (BlockUtils.cpp:1254) Total blockchain bytes: 36,255,901,615
-INFO  - 1431981950: (BlockUtils.cpp:1628) Reading headers from db
-WARN  - 1431981950: (lmdb_wrapper.cpp:1396) No headers in DB yet!
-INFO  - 1431981950: (BlockUtils.cpp:1654) Found 1 headers in db
-DEBUG - 1431981950: (Blockchain.cpp:214) Organizing chain w/ rebuild
-WARN  - 1431981950: (BlockUtils.cpp:1282) --- Fetching SSH summaries for 491 registered addresses
-INFO  - 1431981950: (BlockUtils.cpp:1295) Left off at file 0, offset 0
-INFO  - 1431981950: (BlockUtils.cpp:1298) Reading headers and building chain...
-INFO  - 1431981950: (BlockUtils.cpp:1299) Starting at block file 0 offset 0
-INFO  - 1431981950: (BlockUtils.cpp:1301) Block height 0
[New Thread 0x7fffcc9db700 (LWP 2662)]
[Thread 0x7fffcc9db700 (LWP 2662) exited]
[New Thread 0x7fffcc9db700 (LWP 2665)]
[New Thread 0x7fffcc1da700 (LWP 2666)]
(ERROR) announcefetch.py:283 - Specified URL was inaccessible
(ERROR) announcefetch.py:284 - Tried: https://bitcoinarmory.com/announce.txt
[Thread 0x7fffcc1da700 (LWP 2666) exited]
[Thread 0x7fffcc9db700 (LWP 2665) exited]
-DEBUG - 1431982053: (Blockchain.cpp:214) Organizing chain w/ rebuild
-INFO  - 1431982056: (BlockUtils.cpp:1337) Looking for first unrecognized block
-INFO  - 1431982087: (BlockUtils.cpp:1489) Loading block data... file 0 offset 0
-INFO  - 1431982091: (BlockUtils.cpp:544) Reading raw blocks finished at file 0 offset 134215774
-INFO  - 1431982092: (BlockUtils.cpp:544) Reading raw blocks finished at file 1 offset 134203642
-INFO  - 1431982092: (BlockUtils.cpp:544) Reading raw blocks finished at file 2 offset 134195561
-INFO  - 1431982094: (BlockUtils.cpp:544) Reading raw blocks finished at file 3 offset 134168011
-INFO  - 1431982095: (BlockUtils.cpp:544) Reading raw blocks finished at file 4 offset 134197561
-INFO  - 1431982096: (BlockUtils.cpp:544) Reading raw blocks finished at file 5 offset 134203484
-INFO  - 1431982096: (BlockUtils.cpp:544) Reading raw blocks finished at file 6 offset 134210618
-INFO  - 1431982097: (BlockUtils.cpp:544) Reading raw blocks finished at file 7 offset 134213443
-INFO  - 1431982098: (BlockUtils.cpp:544) Reading raw blocks finished at file 8 offset 134209487

{SNIP SNIP}

-INFO  - 1431982216: (BlockUtils.cpp:544) Reading raw blocks finished at file 267 offset 134096813
-INFO  - 1431982216: (BlockUtils.cpp:544) Reading raw blocks finished at file 268 offset 133744156
-INFO  - 1431982217: (BlockUtils.cpp:544) Reading raw blocks finished at file 269 offset 133863316
-INFO  - 1431982217: (BlockUtils.cpp:544) Reading raw blocks finished at file 270 offset 52407929
-INFO  - 1431982217: (BlockUtils.cpp:1354) Wrote blocks to DB in 66.61s
-INFO  - 1431982217: (BlockUtils.cpp:1371) Checking dupIDs from 0 onward
-WARN  - 1431982218: (lmdb_wrapper.cpp:659) Clearing history
-WARN  - 1431982218: (BlockWriteBatcher.cpp:1556) Starting with: 
-WARN  - 1431982218: (BlockWriteBatcher.cpp:1557) 1 workers
-WARN  - 1431982218: (BlockWriteBatcher.cpp:1558) 1 writers
-WARN  - 1431982218: (BlockUtils.cpp:1071) Scanning from 0 to 357009
[New Thread 0x7fffcc9db700 (LWP 2690)]
[New Thread 0x7fffcc1da700 (LWP 2691)]
[New Thread 0x7fffd74f8700 (LWP 2692)]
[New Thread 0x7fffd6cf7700 (LWP 2693)]
[New Thread 0x7fffd64f6700 (LWP 2694)]
[New Thread 0x7fffd564e700 (LWP 2695)]
-WARN  - 1431982221: (BlockWriteBatcher.cpp:355) Finished applying blocks up to 2500
[New Thread 0x7fffceb7a700 (LWP 2697)]
-WARN  - 1431982223: (BlockWriteBatcher.cpp:355) Finished applying blocks up to 85000
[Thread 0x7fffceb7a700 (LWP 2697) exited]
[New Thread 0x7fffceb7a700 (LWP 2699)]
[New Thread 0x7fffce379700 (LWP 2700)]
[Thread 0x7fffceb7a700 (LWP 2699) exited]
[New Thread 0x7fffcdb78700 (LWP 2701)]
[Thread 0x7fffcdb78700 (LWP 2701) exited]
[New Thread 0x7fffcdb78700 (LWP 2702)]
[Thread 0x7fffce379700 (LWP 2700) exited]
[New Thread 0x7fffce379700 (LWP 2703)]
-WARN  - 1431982225: (BlockWriteBatcher.cpp:355) Finished applying blocks up to 105000
[Thread 0x7fffce379700 (LWP 2703) exited]
-WARN  - 1431982226: (BlockWriteBatcher.cpp:355) Finished applying blocks up to 115000

{SNIP SNIP}

[New Thread 0x7fffcd377700 (LWP 2891)]
[Thread 0x7fffcd377700 (LWP 2891) exited]
-WARN  - 1431982303: (BlockWriteBatcher.cpp:355) Finished applying blocks up to 170000
[New Thread 0x7fffcd377700 (LWP 2892)]
[Thread 0x7fffce379700 (LWP 2890) exited]
[New Thread 0x7fffce379700 (LWP 2893)]
[Thread 0x7fffce379700 (LWP 2893) exited]
[Thread 0x7fffcd377700 (LWP 2892) exited]
[New Thread 0x7fffceb7a700 (LWP 2894)]
[New Thread 0x7fffcd377700 (LWP 2895)]
[New Thread 0x7fffce379700 (LWP 2896)]
[Thread 0x7fffceb7a700 (LWP 2894) exited]
[Thread 0x7fffce379700 (LWP 2896) exited]
[Thread 0x7fffcd377700 (LWP 2895) exited]
[New Thread 0x7fffce379700 (LWP 2897)]
[New Thread 0x7fffcdb78700 (LWP 2898)]
[Thread 0x7fffce379700 (LWP 2897) exited]
[Thread 0x7fffcdb78700 (LWP 2898) exited]
[New Thread 0x7fffceb7a700 (LWP 2900)]
[New Thread 0x7fffcdb78700 (LWP 2901)]
[Thread 0x7fffceb7a700 (LWP 2900) exited]
[New Thread 0x7fffce379700 (LWP 2902)]
[Thread 0x7fffce379700 (LWP 2902) exited]
-WARN  - 1431982307: (BlockWriteBatcher.cpp:355) Finished applying blocks up to 172500
[New Thread 0x7fffce379700 (LWP 2903)]
[Thread 0x7fffcdb78700 (LWP 2901) exited]
[New Thread 0x7fffcd377700 (LWP 2904)]
[Thread 0x7fffcd377700 (LWP 2904) exited]
[Thread 0x7fffce379700 (LWP 2903) exited]
[New Thread 0x7fffceb7a700 (LWP 2905)]
[New Thread 0x7fffce379700 (LWP 2906)]
[Thread 0x7fffceb7a700 (LWP 2905) exited]
[New Thread 0x7fffcd377700 (LWP 2907)]
[Thread 0x7fffcd377700 (LWP 2907) exited]
[Thread 0x7fffce379700 (LWP 2906) exited]
[New Thread 0x7fffcd377700 (LWP 2908)]
[New Thread 0x7fffce379700 (LWP 2909)]
[Thread 0x7fffce379700 (LWP 2909) exited]
[Thread 0x7fffcd377700 (LWP 2908) exited]
[Thread 0x7fffd564e700 (LWP 2695) exited]
[Thread 0x7fffd64f6700 (LWP 2694) exited]
[Thread 0x7fffd6cf7700 (LWP 2693) exited]
[Thread 0x7fffd74f8700 (LWP 2692) exited]
[Thread 0x7fffcc1da700 (LWP 2691) exited]
[Thread 0x7fffcc9db700 (LWP 2690) exited]
[Thread 0x7fffdd1af700 (LWP 2636) exited]
[Thread 0x7fffddbb6700 (LWP 2635) exited]

Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb) backtrace
No stack.

A pair of trials that crashed today. 
doug_armory
sr. member
Activity: 255
Merit: 250
Senior Developer - Armory
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 18, 2015, 10:44:00 AM
#32
Quote from: Searinox on May 18, 2015, 05:24:38 AM
Is there a downloadable Win x64 binary?

Not for now. This is for people who are able to compile code we supply. We'll offer test binaries eventually.
Searinox
full member
Activity: 147
Merit: 100
Do you like fire? I'm full of it.
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 18, 2015, 05:24:38 AM
#31
Is there a downloadable Win x64 binary?
zombieslayer9099
full member
Activity: 120
Merit: 100
Java Coder
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 17, 2015, 04:01:15 PM
#30
My installation is running just fine
btchris
hero member
Activity: 672
Merit: 504
a.k.a. gurnec on GitHub
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 16, 2015, 07:41:53 PM
#29
Quote from: Carlton Banks on May 16, 2015, 07:32:35 PM
You're reminding me how spoilt I am

Well, your namesake certainly was Grin

Quote from: Carlton Banks on May 16, 2015, 07:32:35 PM
about 40 minutes to scan

I haven't timed it exactly, but it's somewhere around there even with my HDD. I'll pay closer attention next time I do a scan.
Carlton Banks
legendary
Activity: 3430
Merit: 3080
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 16, 2015, 07:32:35 PM
#28
Quote from: btchris on May 16, 2015, 07:01:08 PM
Quote from: Carlton Banks on May 16, 2015, 06:42:07 PM
Another little observation is: we're running to stand still, in performance terms.

For me anyways, 0.94 allows me to place the Armory DB on an SSD whereas before both it and the Bitcoin DB were on an HDD. Practically speaking, this has hugely improved the initial "reading blocks" and "building database" steps, down to about 14 minutes. The tx scanning phase is only slightly faster IIRC (possibly because the Bitcoin DB block files are still on HDD).

In short, when 0.94 works, it's brilliant!

You're reminding me how spoilt I am, I can't imagine a computer without enough SSD space to hold a blockchain or two  Cool. I get the same performance you do for the reading headers/blocks stage, and then about 40 minutes to scan; surprise me and tell me that the scan takes hours from a mechanical disk (are there not cryptography operations taking place in every iteration of that scan? The CPU is bound to be a significant limiting factor). I'm pretty sure the bottleneck with my machine when it comes to the scan is either RAM or CPU (as both, plus swap, get basically maxed out)
btchris
hero member
Activity: 672
Merit: 504
a.k.a. gurnec on GitHub
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 16, 2015, 07:01:08 PM
#27
Quote from: Carlton Banks on May 16, 2015, 06:42:07 PM
Another little observation is: we're running to stand still, in performance terms.

For me anyways, 0.94 allows me to place the Armory DB on an SSD whereas before both it and the Bitcoin DB were on an HDD. Practically speaking, this has hugely improved the initial "reading blocks" and "building database" steps, down to about 14 minutes. The tx scanning phase is only slightly faster IIRC (possibly because the Bitcoin DB block files are still on HDD).

In short, when 0.94 works, it's brilliant!
Carlton Banks
legendary
Activity: 3430
Merit: 3080
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 16, 2015, 06:42:07 PM
#26
Quote from: btchris on May 16, 2015, 05:37:03 PM
Quote from: Carlton Banks on May 16, 2015, 02:13:17 PM
Not typical of the first crashes, but there's probably something useful in here.

That stack trace looks exactly the same as mine on Windows (some of the line #s are off, but I think that's just a symptom of using different debuggers). Even the most recent calls are showing a similar out-of-bounds pointer being passed. FYI I've had one additional crash, and the stack trace was the same (with pb.fmp_.current_->filemap_ and pb.fmp_.current_->mapsize_ in GrabThreadData::pullBlockAtIter() corrupted).

Ah, maybe this has nothing to do with those unexpected things happening in that trial (bitcoind crashing, SDM crashing etc). Debugging threaded applications really does seem as difficult as is made out. How people use other complex or subtle programming constructs in combination with threading, I do not know.

It's tempting to say I'd like a repeat of the failure patterns I got Thursday, those trials were very unstable. Armory mostly crashed after less than 30 seconds, then whatever caused that pattern shifted half through the scan, and then completed without complaint. But is that behaviour actually a whole other category of bug, that just so happens to be triggering the pointer scope bug as it's own natural consequence? It's difficult to tell. Could the debugging environment be invoked at the hypervisor level? I'm sure I've heard this is possible, whereby a VM has it's entire state recorded during software tests, which can then be "played back" should any given run yield bugs that are difficult to find after the fact.

Another little observation is: we're running to stand still, in performance terms. At the time 0.93 was finalised, just a few months ago, I think it took around the same length of time to build and scan as it does with this pre-0.94 build. Obviously we have more blocks/transactions to process/scan now, and goatpig says there's a little more performance to tweak out of this design. Could some of the work (reading the headers or Db writing?) be done concurrently with the blockchain sync? I suspect it would be easier once Armory is actually it's own node.
btchris
hero member
Activity: 672
Merit: 504
a.k.a. gurnec on GitHub
Re: Starting preliminary 0.94 testing - "Headless fullnode"
May 16, 2015, 05:37:03 PM
#25
Quote from: Carlton Banks on May 16, 2015, 02:13:17 PM
Not typical of the first crashes, but there's probably something useful in here.

That stack trace looks exactly the same as mine on Windows (some of the line #s are off, but I think that's just a symptom of using different debuggers). Even the most recent calls are showing a similar out-of-bounds pointer being passed. FYI I've had one additional crash, and the stack trace was the same (with pb.fmp_.current_->filemap_ and pb.fmp_.current_->mapsize_ in GrabThreadData::pullBlockAtIter() corrupted).
Pages:
Bitcoin Forum>Bitcoin>Development & Technical Discussion>Wallet software>Armory
Jump to: