Armory 0.93 testing release! (with 0.05 BTC bug bounty)

[goatpig]

Can an Armory data dir/DB be shared between Windows and Ubuntu, e.g. in a VM or dual-boot setup? I tried to have Bitcoin and Armory share (via Shared Folders, Ubuntu is the guest) with Oracle VM VirtualBox and had issues with both.

This was in the log (note that the path there is correct):
-ERROR - 1422668995: (BDM_mainthread.cpp:429) BDM thread failed: Failed to open db /media/sf_Armory/databases/blocks (Invalid argument)

And then when I tried to open it in Windows later, it was corrupt:


Currently doing a rebuild/rescan like it suggested.

LMDB detects its page size from the OS it is running under, not it's meta data. If the different OS have different page size, it will completely fail to align the meta pages (remember, it's a mapped DB, it does every thing by address and offsets) and corrupt them. Then your DB will go kebab.

That or it could be something entirely different. I'm not 100% familiar with LMDB's code base, more like 70%. And I've also never tried what you suggested. I remember remember doing it with our LevelDB database between Windows Host and Linux client however, and that worked fine. But I also remember that LevelDB will stick to the page size it finds in its meta data regardless of the supporting OS (for having played with the feature), so this is my prime suspect.

[1714682591]

1714682591

[1714682591]

1714682591

[1714682591]

1714682591

[picobit]

The bad news is that paper backups do not work.  When I click on the Print button, the OS X print menu comes up, but it is almost unresponsive.  Sometimes it can be cancelled, and once I managed to open the sub-menu and choosing PDF preview (which never came up).  I remember this being a problem once in the past too, but then the problem appeared to go away.

I can't fully reproduce this. I did see a bit of odd behavior and did see a Qt-related crash at one point. Still, I was able to print a paper backup.

Based off what I've seen here and elsewhere, I believe the problem has to do with how Qt handles modal windows. There's just something inherently broken in Qt4 for OSX that the team refuses to fix, and will never fix. (4.8.7 will supposedly be the last Qt4 release.) I had to port over some fixes from Qt5 awhile back just to make Armory reasonably stable. It seems these fixes aren't enough, unfortunately. For me, the fixes are pretty good. For others, they're not enough. Short of an upgrade to Qt5, I doubt there's much I can do, unfortunately. If anybody wants to take a crack and submit some pull requests, I'll be happy to take a look. Otherwise, it is what it is.

This sounds like a likely explanation.  I guess at some point updating to Qt 5 will be inevitable.

So the next big thing on the Armory to-do list after the new wallet format: Qt5 and Python 3   
(it is the kind of tasks that any developer hates...   Necessary to avoid "technological debt".  But boring, gives no new features or anything else the users can appreciate, and introduces a bunch of new bugs).

[doug_armory]

So the next big thing on the Armory to-do list after the new wallet format: Qt5 and Python 3   
(it is the kind of tasks that any developer hates...   Necessary to avoid "technological debt".  But boring, gives no new features or anything else the users can appreciate, and introduces a bunch of new bugs).

Heh. Believe me, I'm gung ho for upgrades. I even did a rough pass at a Qt5 upgrade awhile back. Alas, for various reasons, it may be awhile before Py3/Qt5 (they would, in all likelihood, come paired together) are used in Armory. Anybody who feels strongly enough that we should upgrade ASAP should make some respectful noise. OS X users in particular should speak up. I believe 4.8.7 will be the final Qt4 release, meaning that any support for OSX 10.11 can't be guaranteed.

[Carlton Banks]

So the next big thing on the Armory to-do list after the new wallet format: Qt5 and Python 3  
(it is the kind of tasks that any developer hates...   Necessary to avoid "technological debt".  But boring, gives no new features or anything else the users can appreciate, and introduces a bunch of new bugs).

Heh. Believe me, I'm gung ho for upgrades. I even did a rough pass at a Qt5 upgrade awhile back. Alas, for various reasons, it may be awhile before Py3/Qt5 (they would, in all likelihood, come paired together) are used in Armory. Anybody who feels strongly enough that we should upgrade ASAP should make some respectful noise. OS X users in particular should speak up. I believe 4.8.7 will be the final Qt4 release, meaning that any support for OSX 10.11 can't be guaranteed.

Re: bolded

If it causes any other problems at all with development, I'd like to register my interest in removing support for OSX. It's a minority user group and it's expensive to develop for (both in maintaining the latest version of the development suite, and in the time spent wrestling with what sounds like a very badly supported GUI framework).

You guys have attracted several complaints and little praise for the OSX build up to now, in spite of spending significant resources on it. There's got to come a time when you start deciding whether or not this is at all valuable (and whether it doesn't actually damage the Armory brand more than if it were dropped, at least until OSX can be brought much closer to the usability of Linux & Windows builds). I feel like your time may be better spent concentrating on the builds that aren't so much of a (seemingly accumulating) struggle.

[bitpop]

Os x is moving to an app model anyway

[Carlton Banks]

Os x is moving to an app model anyway

Sounds like Game Over. Apple are turning into the AOL of the operating system world (i.e. rich grandmas need only apply). It's sad stuff.

[bitpop]

Os x is moving to an app model anyway

Sounds like Game Over. Apple are turning into the AOL of the operating system world (i.e. rich grandmas need only apply). It's sad stuff.

Windows 8 too. They're turning powerful computers into a toy like a tablet. It's a joke.

[goatpig]

If it causes any other problems at all with development, I'd like to register my interest in removing support for OSX. It's a minority user group and it's expensive to develop for (both in maintaining the latest version of the development suite, and in the time spent wrestling with what sounds like a very badly supported GUI framework).

Not gonna happen. Some of our investors and publicly prominent users run on OSX. And generally, while we'd like to stop supporting some outdated OSes eventually, OSX doesn't fall in that basket and we can't just outright pull the rug.

Windows 8 too. They're turning powerful computers into a toy like a tablet. It's a joke.

I know Microsoft deserves a lot of the heat it gets, but that one is a bit harsh. MS has a long history of maintaining backwards compatibility and supporting deprecated calls for... pretty much ever. Also consider that the upcoming Windows 10 still runs on the same kernel (6.x) as Vista. On top of that, maybe 99% of the basic GUI WinAPI calls are shared with kernel 5.x (WinXP and 2k). What's stopping me from running Armory on Win2k is its very lack luster threading API, not the GUI code.

Compared to that, Apple likes to bin certain GUI API calls from a minor version to another. Not playing in the same league at all.

There is something the be said about that. While MS chooses to integrate its GDE its closed source kernel, at least they have the common sense of insuring a lot of backwards compatibility between builds. Apple on the other hand takes an open source kernel without a GDE and instead the proper hooks in place to support any, forces its GDE on it and breaks GUI interoperability mechanics from version to version, on what I can only call a whim.

[Carlton Banks]

Some of our investors and publicly prominent users run on OSX. And generally, while we'd like to stop supporting some outdated OSes eventually, OSX doesn't fall in that basket and we can't just outright pull the rug.

As long as your investors are willing to foot the bill for the way this unfolds, then I can't find any fault with that. I predict serious problems with getting yourself inside Apple's walled garden without being coerced into compromising the product. There's a big danger you might be put in a position where you spend more money on OSX development than for any other platform, and end up having thrown all that money away. Investors wouldn't be impressed if so.

Apple on the other hand takes an open source kernel without a GDE and instead the proper hooks in place to support any, forces its GDE on it and breaks GUI interoperability mechanics from version to version, on what I can only call a whim.

A whim that they charge both the users and the developers handsomely to indulge. It's whimsical profiteering, if you like.

[bitpop]

Ok can we at least agree not to support any other coins?

[goatpig]

As long as your investors are willing to foot the bill for the way this unfolds, then I can't find any fault with that. I predict serious problems with getting yourself inside Apple's walled garden without being coerced into compromising the product. There's a big danger you might be put in a position where you spend more money on OSX development than for any other platform, and end up having thrown all that money away. Investors wouldn't be impressed if so.

We currently have good cause the believe our OSX related GUI issues would go away with Qt5. Qt5 would require Python3 and that is desirable on its own. The move the Python3 is expensive but something we eventually need to do. It's more a matter of "when" and priorities than "should we". The move to Qt5 should be rather cheap past that point.

Now, if we get through all of this and OSX is still not behaving, our stance towards this OS could very well change. Our current position hinges on our assumption that a strong solution to the OSX snafu exists, and that there are a lot of other benefits to leverage from that change.

A whim that they charge both the users and the developers handsomely to indulge. It's whimsical profiteering, if you like.

I say whim as opposed to an informed decision, respectful of professional development idioms. Then again, whim is somehow part of their business model. I just don't get why their customers like to get treated that way.

Ok can we at least agree not to support any other coins?

Haha, sure

[bitpop]

Coinbase is hipster and does use os x. They could be a client so os x could be relevant.

Anyway, .99 is awesome now! Thanks armory.

[doug_armory]

We currently have good cause the believe our OSX related GUI issues would go away with Qt5. Qt5 would require Python3 and that is desirable on its own. The move the Python3 is expensive but something we eventually need to do. It's more a matter of "when" and priorities than "should we". The move to Qt5 should be rather cheap past that point.

Now, if we get through all of this and OSX is still not behaving, our stance towards this OS could very well change. Our current position hinges on our assumption that a strong solution to the OSX snafu exists, and that there are a lot of other benefits to leverage from that change.

On top of Qt5 appearing to have better OSX support, the upgrade to Qt5 also potentially allows us to leverage the codebase and get Armory or some variant onto iOS and Android. I'M NOT SAYING WE'LL BE ON MOBILE PLATFORMS. I'm just saying that, depending on which way Armory breaks in the coming year, we may have no choice but to upgrade. (Well, we kinda don't anyway, but the more reasons other than "Because Py2/Qt4 are hitting EOL," the better. )

Anyway, yes, part of the problem is that these are "expensive" upgrades, even Qt, which probably won't take more than a couple of days to switch before testing. There are lots of underlying parts that can play with Python and Qt in unexpected ways. Just this weekend, I tinkered with the SWIG parameters on my machine (long story), and I think that caused Armory's behavior to change a bit. If changing a simple compilation parameter can cause the code to act differently, changing virtually all the code will require loads of testing. It is what it is.

[zombieslayer9099]

Unrelated Question: Is anyone else not receiving emails regarding new replies on this topic? I tried disabling/reenabling notifications and nothing.
I don't know where else to put this.

[justusranvier]

aa5db7de00ec7876173bdbabe559deb297c3034d doesn't build:

g++  -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c UniversalTimer.cpp
g++  -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BinaryData.cpp
g++  -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c lmdb_wrapper.cpp
g++  -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c StoredBlockObj.cpp
g++  -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BtcUtils.cpp
g++  -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BlockObj.cpp
g++  -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BlockUtils.cpp
g++  -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c EncryptionUtils.cpp
g++  -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BtcWallet.cpp
In file included from BtcWallet.cpp:11:0:
BlockDataViewer.h:112:9: error: extra qualification ‘BlockDataViewer::’ on member ‘registerAddressBatch’ [-fpermissive]
    void BlockDataViewer::registerAddressBatch(
         ^
Makefile:87: recipe for target 'BtcWallet.o' failed
make[1]: *** [BtcWallet.o] Error 1
make[1]: Leaving directory '/home/justus/src/BitcoinArmory/cppForSwig'
Makefile:9: recipe for target 'all' failed
make: *** [all] Error 2

[goatpig]

void BlockDataViewer::registerAddressBatch(

Classic msvc to gcc snafu: can't declare methods in .h with the class name prefix in gcc. I was merging a bunch of changes back and forth and didnt check the build on Debian. I'll get it under control.

[zombieslayer9099]

On OS X, file dialog is even worse now. It loads the Qt file dialog, but after that it loads the OS X one, and on top of that, it doesn't even load the file in.

[doug_armory]

On OS X, file dialog is even worse now. It loads the Qt file dialog, but after that it loads the OS X one, and on top of that, it doesn't even load the file in.

Should already be patched. I derped and didn't clean something up properly. (Sorry!) (EDIT: .6) should be fine.

[hardhouseinc]

Question for the Armory support guys here.

I had Armory recently crash and then would not open properly anymore, so I did a
factory reset / re-download the blockchain.  This didnt help.

Now Armory always crashes at the exact same point when it is at the
step - building database.

Ive even done a full uninstall of armory, delete all its program files and appdata
folders, reinstall armory, full download of the blockchain, but Armory still always
crashes at the same exact percentage of building databases.

I even re-installed it under a new user account in Win7 but crashes the same.

Ive done a reset / re-download of the blockchain at least 4 or 5 times with the
torrent option enabled and disabled.  Always crashes.  However BitcoinQT always
opens no problem when I check the status of that.

I verified bitcoinQT opens properly, got the green check mark and is fine but
the armory app always crashes now no matter what I try.  Any idea here
how to fix this?  I cant get armory to load anymore so Im kinda locked out
of the wallet if I needed it.


E$

[goatpig]

Are you using the testing version?