So my hot wallet causes a segfault. Armory crashes with both the full and watching-only wallet when online. I've tested in both OSX and Ubuntu 12.04.

Should I send the watching-only to you, or do you have some logs you want me to send?

Send a log first. If I can't get what I need, I'll ask for the hot wallet.

Well the log is just "Segmentation fault (core dumped)"

OH! I forgot I added another feature. Under "Help-->Revert All Settings". This will delete your settings file and your mempool file. This should be like a fresh install of Armory (but it will keep your wallets). I doubt that is your problem, specifically, but it is worth trying in these strange situations.

I guess I better take the watching-only wallet, if you don't mind. Send it to me via email.

(1) I'm sure there's a vulnerability there... but luckily I don't think the printer drivers were designed to forward traffic. I bet if someone on the other side of the network was really good, they could detect when an Armory backup is printing and figure out how to extract it... But I would put that low on my list of serious concerns (at least, for regular users)

(2) I can't really prevent that. There's nothing that flags the wallet as having the intention of being online or offline, and a lot of times, the user may just be tired of using offline wallets and want to bring it online-encrypted. I mean, an "offline wallet" is just a regular wallet. What makes it "offline" is the system on which it is loaded.

For reasons described somewhere in the last 72 pages, I static compile python into the C++ utilities, but not all systems have the static libraries. However, if you modify the Makefile to look for .so instead of .a, it will work. I should try to add an autodetect branch in the Makefile to automatically do that. Alternatively, if you are using Ubuntu, installing python-dev should resolve it.

I'm on Arch. I did a quick work around of symlinking it instead.

First use of "threading" branch: Very nice work etotheipi, it's great! Having Armory starting instantly is great. I'll have a play around with it to see if I can find any bugs, and report back.Hope you can incorporate it to the master branch soon.

Edit:

I got a seg fault after a few minutes of starting Armory - threading branch. (I presume just as it had finished scanning the blockchain).

For reasons described somewhere in the last 72 pages, I static compile python into the C++ utilities, ....

This makes me wonder if I am doing something wrong. I have compiled the git source on Mac OS X, and start the program with

Code:

python ArmoryQt.py

Am I missing an executable I should run instead? If I am starting the Python executable that will load libpython - if Armory then has the same library built-in, that should be asking for trouble.

Picobit, it's complicated. Python libraries are needed for "swig" in order to compile the C++ utilities. But Armory itself still needs python on your system in order to run. Don't worry, nothing is wrong

For reasons described somewhere in the last 72 pages, I static compile python into the C++ utilities, but not all systems have the static libraries. However, if you modify the Makefile to look for .so instead of .a, it will work. I should try to add an autodetect branch in the Makefile to automatically do that. Alternatively, if you are using Ubuntu, installing python-dev should resolve it.

I'm on Arch. I did a quick work around of symlinking it instead.

First use of "threading" branch: Very nice work etotheipi, it's great! Having Armory starting instantly is great. I'll have a play around with it to see if I can find any bugs, and report back.Hope you can incorporate it to the master branch soon.

Edit:

I got a seg fault after a few minutes of starting Armory - threading branch. (I presume just as it had finished scanning the blockchain).

Whoops, it looks like I left the makefile in debug mode. I will recommit it not in debug...

There is a known bug that I just isolated, that has to do with creating addresses while Armory is scanning, and then it attempts to rescan right away. I just isolated it (and prints the same message you showed), and will be examining it in the debugger later this evening. This is what I was referring to in my previous message about "gotta figure this out sometime".

I feel like I've been going in circles, but I'm think I'm better off than a week ago. I re-enabled most operations during scanning, and so far they work most of the time without crashing. Wallet recovery, sweeping, importing, keypool extension, should all be queued up for execution when Armory is currently scanning.

I haven't built any installers yet, but I was pleasantly surprised with how many people are running from the git repo... so maybe that's enough.

@Red Emerald: there was a wallet recovery bug I introduced somehow... I don't know how long it's been there but it's definitely fixed, now. Can you please re-restore the wallet you were having issues with?

Pulled the latest threading branch, and all seems smooth. Had no crash on load, as before. I'm quite pleased with it.Have you got any more features planned, as I can't think of any thing else that I personally would need; it seems to have everything.

Pulled the latest threading branch, and all seems smooth. Had no crash on load, as before. I'm quite pleased with it.Have you got any more features planned, as I can't think of any thing else that I personally would need; it seems to have everything.

That's quite a relief! I caught two big bugs today. It looked like there might still be the occasional crash, but I have to give in some time and just release it. It can't be perfect...

I have mostly only polishing left for beta, no major features. Though, all this seg faulting and issues with file-reading has encouraged me to bump up the priority on making Armory maintain its own blockchain files. This would not only solve a great many instabilities related to sharing the blkXXXX.dat files with Bitcoin-Qt, but it would load faster, use less RAM (it will be HDD-heavy instead of RAM-heavy), and allow users to connect to any trusted full node not necessarily localhost. But it means blockchain data would be duplicated on the HDD.

I think I'll stick to my plan to do the new wallets first. There's too many benefits of the new wallet format, like finally supporting compressed public keys (and migrating Bitcoin-Qt wallets), encrypted-backupable comment/label files, and multi-sig preparation (won't be implemented just yet, but I need the new wallet format to support P2SH). Plus, some users have expressed pleasure that Armory is so lightweight in terms of HDD space, so I think it's a good idea to lock in the current stable design, and change around the CONOPs (concept of operations) later.

I'll do a semi-official release in the next day or two, and get some more users clicking on it. Perhaps within a week of feedback I can officially tag it Beta. Once again, please let me know about any issues/polishing, or any minor feature requests.

Major bug fix!: Windows 32-bit installers were not compiled with multi-threading support!!! It was 1-2 months between when I figured out how to enable multi-threading, and the next time I fired up my Win32 dev environment. I thought my VM was just behaving wacky when it didn't work, but it was a real problem!

This also means that if you were a good samaritan and actually installed the 32-bit version on your 64-bit Windows system, then you probably didn't get to experience the months of multi-threading upgrades.

Below is the Windows 32-bit installer for 0.84.4 which also has all the other bug fixes I mentioned before.

I pulled the latest version (git pull) and compiled it. Unfortunately, it does not work very well :-( I did a "make clean" followed by a "make" just in case something was not recompiled, but that did not help.

BUG 1:

I tried to generate a transaction from an offline wallet. I clicked "Send Bitcoins" and selected the offline wallet. Then I pressed OK and got this error:

I get the same error when sending from a normal wallet, by the way. Just tried it.

BUG 2:

Previously to this, I tried to export all transaction from an online wallet. I chose File / Export Transactions, chose .csv format and selected a wallet (an unencrypted online wallet). When I click export, a normal Save window appears, but it is dead. It does not react to pressing any body, and I cannot get rid of it or quit Armory. In the end I had to press Ctrl-C in the Terminal window where I started Armory.

I am running Mac OS X version 10.8.2 (Mountain Lion). It is the first time I have any trouble with Armory's basic functionality (although I have never tried the export transaction menu point before).

Okay, something is definitely not right. At all. There are parts of my source files missing. This happened before ... a chunk of wallet code disappeared was causing my wallets to break. I assumed I had done something stupid in vim, but now looking at qtdialogs.py, there seem to be other things missing.

This all happened after a hard crash happened two days ago. I wonder if it somehow corrupted some files...

I'll be investigating...

EDIT: Thank god for git. Showed me exactly what disappeared (two things, one of which was that "createTxAndBroadcast" function), and I was able to copy it right back in. The bizarre thing is, it almost looks malicious -- not only did it destroy functionality, but everything that has disappeared still ran and "compiled". The code was continuous and valid... just not correct.

I will investigate further, but for now I recommitted to 0.84.4 all those updates.

I updated, and tried again. I wanted to make a test transaction from the offline wallet. Now I can specify the payment, and get all the way to the window where I should save the transaction. Unfortunately, that window is totally unresponsive, and I can neither save the transaction nor get rid of the window (short of killing the Python process with Ctrl-C).

The second time I tried, the file name did not appear in the Save window. I could type in a name myself, but again I could not save the file or close the window, and had to kill Python.

EDIT: Thank god for git. Showed me exactly what disappeared (two things, one of which was that "createTxAndBroadcast" function), and I was able to copy it right back in. The bizarre thing is, it almost looks malicious -- not only did it destroy functionality, but everything that has disappeared still ran and "compiled". The code was continuous and valid... just not correct.

I will investigate further, but for now I recommitted to 0.84.4 all those updates.

What are the odds that a part of a file drops out in such a way that it is still syntactically correct?? On the other hand, if it was malicious, why remove the part of the code leading the user to enter the password - why not just steal the password....

In any case, I suppose git can show you exactly what was changed, and when.

I updated, and tried again. I wanted to make a test transaction from the offline wallet. Now I can specify the payment, and get all the way to the window where I should save the transaction. Unfortunately, that window is totally unresponsive, and I can neither save the transaction nor get rid of the window (short of killing the Python process with Ctrl-C).

The second time I tried, the file name did not appear in the Save window. I could type in a name myself, but again I could not save the file or close the window, and had to kill Python.

EDIT: Thank god for git. Showed me exactly what disappeared (two things, one of which was that "createTxAndBroadcast" function), and I was able to copy it right back in. The bizarre thing is, it almost looks malicious -- not only did it destroy functionality, but everything that has disappeared still ran and "compiled". The code was continuous and valid... just not correct.

I will investigate further, but for now I recommitted to 0.84.4 all those updates.

What are the odds that a part of a file drops out in such a way that it is still syntactically correct?? On the other hand, if it was malicious, why remove the part of the code leading the user to enter the password - why not just steal the password....

In any case, I suppose git can show you exactly what was changed, and when.

I shouldn't have said "malicious." This was all timed with a hard system crash. Yes, large chunks of code went missing in a conveniently-transparent way, but if it was malicious, they wouldn't be doing it just to waste my time bug hunting. I will instead attribute this to vim + hard crash... I've lost code before with vim (like, two other times in 10 years), but git makes it easy to recover.

I will go back into testing mode, and start testing send-transactions, offline tx, etc. Though, I might not get to it until tomorrow...

64 bit crashes all the time when pressing "go online"happened after switched to expert mode, after that nothing matters: constant crashes.

My QT has an account, I could not import it into Armory. Armory doesn't see it.

PS Now it crashes on starting it all the time...

What OS? What version? There's a ArmorySettings.txt file and mempool.bin file in the home directory. Delete both. Or if you can open it in Offline mode, Help-> Revert all Settings (does the same thing without digging into directories)

If it continues to keep crashing then please email me a copy of the log file.