Pages:
Author

Topic: 0.96.4 RC3 - page 2. (Read 1022 times)

sr. member
Activity: 471
Merit: 252
January 29, 2018, 04:27:36 PM
#36
Code:
-INFO  - 20:25:41: (BlockchainScanner.cpp:857) scanned block #506662
-INFO  - 20:25:41: (lmdb_wrapper.cpp:388) Opening databases...
-INFO  - 20:25:41: (DatabaseBuilder.cpp:186) scanned new blocks in 0s
-INFO  - 20:25:41: (DatabaseBuilder.cpp:190) init db in 18s
-INFO  - 20:25:41: (BDM_supportClasses.cpp:1891) Enabling zero-conf tracking
-INFO  - 20:26:28: (SocketObject.cpp:355) POLLIN recv return 0
-ERROR - 20:26:28: (BitcoinP2P.cpp:1037) caught StopBlockingLoop in processDataStackThread
legendary
Activity: 3738
Merit: 1360
Armory Developer
January 28, 2018, 06:03:14 PM
#35
HDD and SSD, I cannot know exactly because I use lvm, so it can reside anywhere...

Most likely the issue is that the node write operation committing the new file to disk (which happens once or twice a day) is not flushed by the time Armory goes looking for it, courtesy of cached disks (which is after processing the new block notification over P2P from the node).

Looking at the code, it doesn't seem that throw is crawling all the way back to the main execution thread, so it's unexpected that it would kill the entire process. On the other hand, that also means it could be caught and handled. If you can build from source and are willing to tinker with that stuff, I can tell you what code to add to try and fix this.
sr. member
Activity: 471
Merit: 252
January 28, 2018, 05:51:56 PM
#34
Compare the file creation timestamp to the log message error timestamp.
I'll see next time.

What kind of hardware does your blockchain data reside on? How long do you let the DB run?

HDD and SSD, I cannot know exactly because I use lvm, so it can reside anywhere...

I let it run between 1 hour and 8 hours usually.
legendary
Activity: 3738
Merit: 1360
Armory Developer
January 28, 2018, 05:46:46 PM
#33
It seems it does:

Compare the file creation timestamp to the log message error timestamp. What kind of hardware does your blockchain data reside on? How long do you let the DB run?
sr. member
Activity: 471
Merit: 252
January 28, 2018, 04:58:53 PM
#32
What OS you on?
Linux

Also, at the moment it happens, does the missing blk file reside on disk?
It seems it does:
Code:
$ ls .bitcoin/blocks/blk01147.dat -lh
-rw------- 1 user user 96M ene 28 21:55 .bitcoin/blocks/blk01147.dat

Is restarting the DB fixing it?
Yup.
ArmoryDB aborts and when I start it again, it seems to run fine.
legendary
Activity: 3738
Merit: 1360
Armory Developer
January 28, 2018, 04:17:36 PM
#31
What OS you on? Also, at the moment it happens, does the missing blk file reside on disk? Is restarting the DB fixing it?
sr. member
Activity: 471
Merit: 252
January 28, 2018, 02:52:57 PM
#30
Almost once a day.
legendary
Activity: 3738
Merit: 1360
Armory Developer
January 28, 2018, 11:35:58 AM
#29
Consistently?
sr. member
Activity: 471
Merit: 252
January 28, 2018, 08:04:08 AM
#28
Getting this error in ArmoryDB:
Code:
-ERROR - 11:54:59: (BlockchainScanner.cpp:445) Missing file map for output scan, this is unexpected
-ERROR - 11:54:59: (BlockchainScanner.cpp:447) Has the following block files:
-ERROR - 11:54:59: (BlockchainScanner.cpp:449)  --- #1146
-ERROR - 11:54:59: (BlockchainScanner.cpp:451) Was looking for id #1147
terminate called after throwing an instance of 'std::runtime_error'
  what():  missing file map
legendary
Activity: 3738
Merit: 1360
Armory Developer
January 26, 2018, 02:01:58 PM
#27
Sorting is a PITA to implement in GUI so don't hold your breath for that one.

how about search?

I have plans for some advanced search/sorting but not in a 0.96 iteration.
member
Activity: 178
Merit: 10
January 26, 2018, 12:34:46 PM
#26
Sorting is a PITA to implement in GUI so don't hold your breath for that one.

how about search?
newbie
Activity: 7
Merit: 0
January 25, 2018, 07:15:30 AM
#25
So, I just pasted the transaction details into blockchain.info/decode-tx and it came out correct. I also realized that armory had the correct PrevTxHash as input, but the sender address was still wrong. FYI: blockchains tool doesn't list the sender address, just the previous tx hash. I then broadcasted it, and it immediately showed up correctly in armory.

So I know the setup works, and I have my private keys, but it would be nice to know whether the sending issues were mine or the software. I did use RBF if that matters.


*Edit.
To keep from spamming too much, I'll just edit this post. I tried again with the same result. Online machine running 0.96.3 on windows didn't accept the transaction file as signed.

When I upgraded the online computer back to 0.96.3.992 and loaded the transaction it recognizes it as valid. I initially had the same problem with syncing, and it didn't work starting bitcond manually either. What did work was running bitcoin-qt before starting armory. It synced, recognized the transaction, and broadcast it successfully.

Hopefully this will help someone else someday. Thanks for help and patience.
newbie
Activity: 7
Merit: 0
January 25, 2018, 06:30:52 AM
#24
I can't remember if it did or not, but I did check task manager and closed it manually if it did. This has solved some issues before, so I 'm aware of it.

Anyway, I just tried again and this time I was able to open the "broadcast raw transaction" option, paste the raw data, and get it parsed. As the outputs looked correct, I tried broadcasting, but nothing happened. I checked the parsed tx data again, and noticed that the sender address was not the one I had specified. Instead of the one with spendable UTXOs, it was one that shows up empty on blockchain.info. When I copy in the "signed" transaction data again to the online system, it still provides the correct transaction details, except for the fact that it comes in unsigned.

I really don't understand this...

***I don't think it should matter, but the offline signing wallet was made from a secure printed fragmentet backup in order to test it. The online watch-only wallet was created before I deleted and regenerated my wallet.
sr. member
Activity: 525
Merit: 282
January 25, 2018, 04:48:13 AM
#23
Just curious, when you started up RC3, was ArmoryDB still running in the task manager? That can cause problems. If it wasn't, I'm not sure offhand what could be going on.
newbie
Activity: 7
Merit: 0
January 25, 2018, 03:59:32 AM
#22
So I followed your advise, and installing the offline bundle (I used 0.92.2) on Ubuntu 14.04 worked perfectly, and I was able to upgrade to current version without any additional dependencies or tweeks. Thanks!

My online system was initially running on windows 10, with core 0.15.1 and armory 0.96.3, which I knew ran well, and received transactions. I then upgraded the online version to 0.96.3.992, and sent a test transaction to the watch only wallet I had saved on it. This led some issues as others have also described. First, armory stopped syncing, and despite saying it was online, it was frozen multiple blocks behind without. I only noticed this when it didn't pick up my test transaction, as 0.96.3 had did. After restarting it and rescanning, I quit armory and started core, allowing it to sync. Then starting armory and rescan/rebuilding, it still didn't pick up the transaction despite it now being confirmed within the block height armory had synced. It should be noted armory still didn't sync blocks newer than I had downloaded with core. I reverted back to 0.96.3 and it immediately worked, so it was not really a problem. Let me know if/what logs you would like to look at, and I can PM them.

To complete the test, I then created a transaction online, copied it to a usb, and imported to my offline signer. Everything looked ok, so I signed and it automatically saved it back on the USB. The transaction block became about twice as before signing. Importing it to the online computer, it claimed the transaction was unsigned. It could still read the details of the transaction. I tried again, and this time manually saving a text file of the signed transaction as well, but neither worked.

I tried a third time saving the signed transaction data as a hex text file, and electrum recognized it as signed and offered to broadcast (obviously, it didn't recognize armorys transaction format). I did not broadcast in order to check further. I then tried armory again, but it still would not accept the transaction as signed, nor did it recognize the raw tx data in "Offline Transaction". I then went tools -> broadcast raw transaction, prompting* the following error message:

"Not Online
Bitcoin Core is not available, so Armory will not be able to broadcast any transactions for you."

*This happened before I got to paste the tx data

At this point armory says it is connected and online, and has synced all new blocks on its own.

Although I haven't done it yet, it seems I can still broadcast the transaction using another service, so its more of an inconvenience than a big issue for me personally. Any ideas to what the issue is? I can also pm you the signed and unsigned armory data if you want it, but it seems like the problem lies with the online computer.
newbie
Activity: 7
Merit: 0
January 23, 2018, 04:36:43 AM
#21
Not sure I follow regarding the offline bundle. The reason I asked was because of a post saying an offline release compatible with old CPUs was expected in october. I interpreted this as no offline bundle can be installed on old CPUs. Are you saying the older versions are compatible, so I can install 0.93 and upgrade?

I did try following the bitzuma guide with its 11 dependencies, but had already installed ubuntu 16.04. Both this and the offline bundle was lacking python-qt4. I grabbed that one, but it also failed due to dependencies and I read there were quite a lot of them for 16.04.

Anyways I'll try again on 14.04 both with aforementioned guide and a gcc4.7 release, and if it fails with an old offline package.

Thanks again for your help.
legendary
Activity: 3738
Merit: 1360
Armory Developer
January 22, 2018, 06:45:32 PM
#20
There are builds for old CPUs (gcc4.7). Offline bundles are a different thing. They're a build + the collection of necessary dependencies to run the software. You can get these dependencies from the relevant public repository and they will work with your CPU as long as you chose the right architecture.

Put another way, if you are missing dependencies, you can simply grab those on your own. I test the offline bundles against freshly installed VMs, so as far as I know, they are fully functional. If you are missing dependencies on your machine, might as well list them here so that I can get an idea what's missing.

Installing dependencies is a one time thing (as long as you don't reinstall the OS). Once you have an offline bundle installed and functional, you most likely won't need the offline bundle for the next version, just package. I make a point in not inflating the list of dependencies needlessly, so that part should remain true. Matter of fact, I've drastically reduced it since 0.93. In other words, you could install the 0.93 offline bundle, update Armory to 0.96.4 and most likely get away with it.
newbie
Activity: 7
Merit: 0
January 22, 2018, 05:04:03 PM
#19
Not sure where to ask this question so I'm trying here:

I have tried installing Armory on an offline computer using Ubuntu 16.04, but failed due to the missing dependencies a couple other people have mentioned. I saw using 14.04 would help, but based on the age of my CPU, I guess I would stop at the same point as rothbart in the 0.96.2 release thread.

I'm sure you have better things to do, but are there any plans on making an offline bundle compatible with shitty old CPUs?

Thanks for all your work!
legendary
Activity: 3738
Merit: 1360
Armory Developer
January 18, 2018, 03:49:14 PM
#18
Sorting is a PITA to implement in GUI so don't hold your breath for that one.
member
Activity: 178
Merit: 10
January 18, 2018, 03:18:45 PM
#17
"sudo make install" after compiling on my system for my current version.  does that mean i did both a compile and a local install?  if that's the case, then i need to run "make uninstall" on the previous version before "make clean", right?

Typically you don't need to, as the same files as the previous install will be copied over, overwriting the previous install. But it's preferable to "make uninstall", as it guarantees the old files are removed, in case some of these files are not covered by the new install.

yeah, so i didn't do a "make uninstall", just a "make clean", before compiling this new version and everything is running well.  

thank you very much for all the great work.  this software is as well honed and running as i've ever seen it.  give me a way to sort thousands of UTXO's in Coin Control or search quickly for specific one's and i'll have an orgasm Smiley
Pages:
Jump to: