Topic: Armory - Discussion Thread - page 155. (Read 521749 times)

Just ran into an issue with a few transactions which have been included in a block being stuck at 0 confirmations. I renamed mempool.bin, restarted, and then they weren't in the transaction list at all. What can I give you that would help you figure out the cause?

edit... I'll email you the log, a watching only copy of the wallet, and mempool.bin

prezbo,

Are you compiling from source?  I just put the BlockUtils.cpp with debugging calls in my dropbox folder, and it can be copied right into the cppForSwig directory and recompiled.  It's a P.I.T.A. to debug this stuff, because I can't compile in MSVS in debug mode (because I get crazy linker errors for things like not having python_debug.dll, I haven't figured it out, yet), and I can debug in Linux, but the error doesn't seem to happen there.  

So, the best I can do at the moment, is have it spit output to the console every other line, to find out where the problem is (and the state of some variables when it happened).  I might be able to figure it out just from the output... at the very least I can do more intelligent debugging when I figure out the location.  I am putting it out there right now, because I just ran it on my Win7 VM for 36 hours and it hasn't crashed yet...

---

I found and fixed the bug causing double-display in new wallets.  That's a particularly important bug to fix with the recent influx of new users.  That along with coin control is worth a full release, even without this once-per-24hours-crash bug fixed.   I am in process right now, of compiling and signing the installers.  I will also see if I can get git installed on the offline computer and sign the "v0.86-beta" tag, too (after I create it).

I also figured out why so many users were having trouble with the installers in Windows -- I have been trying to push people onto the 32-bit version, and I think when it installs it skips files it thinks are already there -- including things like python.dll which is 64-bit but then replacing everything else with the 32-bit version.  This is also why a repair/reinstall always fixes it.  I'll see if I can figure out how to force the installer to replace everything.

@Ente,

One other thing I could use is more testing.   I really haven't been getting the quantity of eyes on testing versions as I need to catch all these crazy things.  A lot of silly bugs get by me because I can only test such a small subset of everything.

On that note, I just figured out the tx/balance doubling bug:  it is only when you have freshly created a new wallet and receive coins.  It's because the wallet is somehow getting added twice to the application.  I think I can fix that bug and put it into a 0.86 release.  This seems important to fix for new users getting into Armory the first time...

Thanks Ente:

(a) There are no updates on that yet.  If you have the private key, can you import it into the offline wallet and re-create the watching-only wallet and re-import that on your online computer.  Also, even if I had the pub-key import feature, you can't import public-key-only addresses into a full wallet.  Every address in the wallet must have the private key, or not have the private key (it's too complicated to deal with mixed wallets... you would just create a new wallet for that).

(b) The digital backup does include all imported addresses.  However, I'm more of a fan of paper backups, so I recommend printing out the individual keys (select "Imported Addresses Only").  Especially, if you are importing lots of keys and making digital backups, you don't know which ones have been backed up already without loading the digital backup and checking -- it's obvious if you have them printed, though.

(c) I'm not sure I understand this.  There should be no problem running only bitcoind, and Armory should connect to it the same as it would to Bitcoin-Qt.  Unless you are talking about running bitcoind on a different computer...  (it will be possible to connect to remote nodes, in the future, but it's not ready yet).

Time is definitely a limiting factor in the development.  Almost-full-time job, just got engaged, holiday parties, etc.  My fiance knows how much enjoy working on this, and gives me lots of room/time to work on it, but it would definitely help if I didn't have a job.  But I also don't see how I could sustain on Armory alone without converting it to a paid-product model (and even then, I'm not sure the market is big enough, and the stability of Armory is high enough for that).  Right now I'm mostly happy with the arrangement, despite wanting to spend more time on Armory and less at work, but this is the most stable for me. 

People getting more involved in the code would be great.  Though, I understand Armory code base is big and scary  (about 25k lines of code, so far).  It is fairly well-commented, but it's also flush with corner-case catching, error detection, and luxurious informational dialogs which really obfuscate the intent of the code.  It can be tough for someone to see what the code is doing exactly when I've add multiple ways to detect various error conditions and half a dozen message box warnings to accommodate different conditions.  But I'm not sure there's a good way around that...

I was considering making a plugin system for Armory, that would allow users to create new tabs on the main screen.  There's some details that need to be worked out so that it can be done "safely" (or as safe as is reasonable).  That would definitely make it easy for users to contribute new features that could later be merged when they're fully developed.  Though, I'm not sure that's the best way to get other people involved in the code...

I finally am in the process of switching to armory!
A few questions..

a) I guess no news about "importing" an address when only the public address is known? I imagine this should be possible, as we have the blockchain with all transactions of this address?
edit: It doesn't have to be a watch-only-wallet. Would it be more possible to have a whole new type of "wallet" for this?

b) Imported addresses: The paper backup warns that imported addresses are not included in the paper backup. Are they included in the digital backup / wallet file?

c) and OT: I wish to have bitcoind always running in background. Does anyone know a way to "connect" bitcoin-qt to the running bitcoind, instead of armory, when armory is closed? I would like that option, as I have a lot of wallets from bitcoin-qt left, and start all fresh on armory. And yes, that's nothing I expect the programmer of armory to code ;-)

Thank you for this nice client! I already love it, never restarting the client again to switch wallets! :-)
Also, what is currently the limiting factor in armory's development? Time, funds, tasks, coders?

Ente

Yup, 64 bit win 7. Nice, reinstallation seems to have done the trick.

Ack!  Haven't seen that before!  I assume you are on 64-bit Windows?  I wonder if the 32-bit compiled version doesn't work on 64-bit Windows now, or maybe the installer didn't do everything it was supposed to...?  Can you please try uninstalling it and reinstalling it?  

I can't recompile the Win64 version just yet, because I just caught the dreaded crash in a debugger and I need examine it.  It looks juicy, though!  It thinks there was a blockfile split, and looking for blk0004.dat.   Hopefully this will be a quick fix!  When I'm done, I'll revert the debugging code and compile a Win 64bit version.

This won't start for me...

I just posted a copy of 0.86-testingversion. 

http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.86-beta_windows_testing.msi

Make sure you switch into "Expert" mode, and then there will be a button on the send screen.  It should be self-explanatory

Yes!  I just implemented "Coin Control" in Armory, in version 0.86-beta.  It will let you do exactly that if you are in expert mode!

If you are in Linux or OSX, you can get it right now by switching to the "coincontrol" branch.  If not, you'll have to wait for me to compile Windows versions, but I can do that later tonight.  They won't be official, but since you asked for it, you can help me test it

etotheipi,

I used Armory for several weeks now, and really appreciate the feeling of 100% safety confidence, thank you very much.

Would you plan to develop the function to let users to send bitcoin from a specified address? There is such function in the blockchain.info.

Regards,

HorseRider

Got another one of those just now, two in one day. Could you make an executible with the added debug statements so we can help?

I think losing connection is a symptom, not a cause.  I just put a ton of debug statements in and will start it up and hopefully get a crash in the not-too-distant future.

I got it yesterday on my Mac, but first it printed that it had lost connection to the Satoshi client, so I assumed that was the problem.

I think the chain re-org there was a coincidence.  I, too, have observed the occasional crash in Windows with the exact same thing in the log file -- it seems to be exponentially distributed with an average of about 1 day (its happened within 8 hours before, but usually within 4 days).  I can't tell for sure what is causing it, because it happens so infrequently, but the fact that every time it says "BDM currently doing: ReadBlkUpdate" gives me a good idea of where to look.  I have timed readBlkUpdate, and it takes between 200 and 400 microseconds to run, normally.  I'm not sure what could possibly happen to push it above 10s. 

Also, this only appears to happen in Windows.  Let me know if you've seen it on any other OS.  I'll put some debugging stuff into my Windows VM and see if I can catch more info... it seems that 90% of my bug reports have to do with this problem.

I've had armory crashing twice after running for about two days with the following error:


These are the two lines before the error, which might be of interest


Maybe something to do with chain reorganization?

(Armory 0.85-beta, Windows 7 64 bit)

edit: Ok, maybe not reorg, this is from 3 days ago:

could you maybe implemented and support both ways? in the meaning of writting a loader and you have to specify if it should use the HD more or the RAM. not everyone hasnt enough RAM

Just a random update:  I have been experimenting with LevelDB, and it appears there is an excellent compromise upgrade I can make:  it would be to swap out the underlying C++ txMap_ and headerMap_ normally held in RAM using std::map, with a disk-based equivalent using LevelDB.  The change looks like it would pretty transparent to all code that leverages the C++ utilities (besides creating an extra directory to store the map data).   If that's the only thing I changed, I think I'd get quite a bit of value out of it (and some downside):

++ RAM usage would drop considerably;  probably from 1.5 GB (proportional to blockchain size) to 200 MB (should be pretty flat)
++ Quite a bit of data would be saved between loads naturally, probably leading to much faster startup times
-- HDD usage would go up quite a bit;  probably from 50 MB (for installed files and wallets), to about 1 GB (proportional to blockchain size)
-- Creates a much more "stateful" Armory, which is a downside;  Since I currently always rescan the chain, every load is a fresh start free from problems from the last load.  No matter what bad state Armory got into before, a restart will fix it (because the initial scan is much more robust than handling all the crazy event sequences that users can induce). 

I suppose, if necessary, I could keep the rescanning (so keep the load time high) and just swap RAM for HDD usage.  But I think rebuilding the maps every time would be quite a bit slower than the current RAM solution (gah, always a trade-off).  On the other hand, the underlying C++ libraries have become much more robust over the months, such that it may not actually be that much effort to produce similar robustness with the saved data.  To be clear: it's not *that big of a deal*, but with this scheme comes extra risks that a user could get "locked out" by a bad state of the saved data and have no clear way to recover (as happens with Bitcoin-Qt when blkindex.dat gets corrupted).

Edit: In fact, the most frustrating (and frequent) bug reports I've received, have been because the one file I keep between loads (mempool.bin, for holding zero-conf tx), would get corrupted and prevent Armory from finishing loading.  I actually built into the latest release a way to detect that loading failed three times in a row, and to just delete it.  Perhaps I'll do the same thing for this data -- delete the disk maps and let Armory rebuild them if there's a problem.

I'm pretty busy the next couple weeks, but I guess I can relax a bit, now that beta finished   
Please let me know if you have tried (and succeeded) testing coin control.  I think it will be worth a full release just for that feature if I didn't break anything else.

I'll throw that into my next update, since it clearly improves the situation for some users, without any risk of harm (as far as I can tell...).  I mean, as a band-aid until I get official support throughout the app.

Yes, it fixed that, thanks