Armory - Discussion Thread

[etotheipi]

Still doesn't work for me...just opens and crashes on "Preparing Databases" even when I restart.

What version of OSX are you on?  And can you please send the two log files to support@bitcoinarmory.com

[1713573979]

1713573979

[1713573979]

1713573979

[etotheipi]

alright no more need to worry, it's now started to work after preparing databases...
I've restarted to see if it continues to work, if not i'll let you know. Thanks for the fast support so far.

Great. Hope it's a smoother experience. Still would be good to know what version of OSX you are using.  Also, could you test the paper backup printing? That was something that was causing the most crashes for users in 0.90

[picobit]

Trying the new Mac build.  First impression: It is faster and smoother than previous versions.  And the fonts stay the same size all the time
The wallet consistency check is also very reassuring.

I did a single offline transaction just to test.  I noticed two issues, none of them are new, and none are serious:

1) Comments written in the transaction are lost.  Perhaps they are lost along with the transfer of the transaction to an older Armory on the offline machine.

2) One CPU is running full speed while Armory has some windows open.  For example after saving the unsigned offline transaction, I can press Done or Continue.  While this window is open, one CPU is loaded 100%.

[picobit]

And I just wanted to test one more feature.  Bang!

I wanted to try making a 2-of-2 paper backup of a wallet I rarely use (no funds in it).  When I presses Print all Fragments, a popup warned me that an error had occurred and that printing would be aborted.  And Armory then opened a blank window, and froze.  I had to force-quit it.

The log:

Code:

2014-02-22 07:47 (ERROR) -- qtdialogs.py:6234 - Problem with private key and/or chaincode.  Aborting.
Traceback (most recent call last):
  File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6231, in __init__
    raise KeyDataError
KeyDataError
2014-02-22 07:48 (ERROR) -- qtdialogs.py:6234 - Problem with private key and/or chaincode.  Aborting.
Traceback (most recent call last):
  File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6231, in __init__
    raise KeyDataError
KeyDataError
2014-02-22 07:48 (ERROR) -- Traceback (most recent call last):
  File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6569, in reject
    self.cleanup()
  File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6554, in cleanup
    self.binPrivCrypt.destroy()
AttributeError: 'DlgPrintBackup' object has no attribute 'binPrivCrypt'

2014-02-22 07:48 (ERROR) -- Traceback (most recent call last):
  File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6569, in reject
    self.cleanup()
  File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6554, in cleanup
    self.binPrivCrypt.destroy()
AttributeError: 'DlgPrintBackup' object has no attribute 'binPrivCrypt'

2014-02-22 07:48 (ERROR) -- Traceback (most recent call last):
  File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6569, in reject
    self.cleanup()
  File "/Users/xxxx/Desktop/Test/Armory.app/Contents/MacOS/py/lib/armory/qtdialogs.py", line 6554, in cleanup
    self.binPrivCrypt.destroy()
AttributeError: 'DlgPrintBackup' object has no attribute 'binPrivCrypt'

2014-02-22 07:49 (INFO) -- ArmoryQt.py:5255 - Resetting BlockDataMgr, freeing memory

EDIT:

I tried again with the same wallet.  Same result.  Then with another wallet, and it worked fine.  Except that the old Print-dialog-not-working-on-Mac problem is back: The system print popup is unresponsive.

[bitpop]

Idk about new version but current Windows doesn't always honor my secs and memory for new wallet. Sometimes it's randomly replaced. I noticed rejected wallets being created during that time.

[yuriygeorge]

Hello, I don't want to stir any panic but I recently downloaded Bitcoin-QT and Bitcoin Armory from legit sites. Bitcoin-QT finally completed downloadng the blockchain so when I open up Armory to start syncing the database, my anti-virus Avast system is showing a bunch of infections:

Infection: VBS:Bicololo-IU [Trj]
File: /Users/xxx/Library/Application Support/Armory/databases/leveldb_blkdata/025281.sst
Process: /Application/Armory.app/Content/MacOS/Python

So what is this? Has anyone seen it? This trojan looks pretty bad, is it a false positive? How did this happen?

EDIT: This is on a MacOs

[substratum]

Hello, I don't want to stir any panic but I recently downloaded Bitcoin-QT and Bitcoin Armory from legit sites. Bitcoin-QT finally completed downloadng the blockchain so when I open up Armory to start syncing the database, my anti-virus Avast system is showing a bunch of infections:

Infection: VBS:Bicololo-IU [Trj]
File: /Users/xxx/Library/Application Support/Armory/databases/leveldb_blkdata/025281.sst
Process: /Application/Armory.app/Content/MacOS/Python

So what is this? Has anyone seen it? This trojan looks pretty bad, is it a false positive? How did this happen?

It's a false positive, I've seen it before and investigated. And a VBS (Visual Basic Script) virus in an Armory .sst file wouldn't even make sense, it's not like Armory would be executing VB script it finds randomly in the blockchain.

[doug_armory]

Hey everyone. Thanks for testing out the OS X build! It's much appreciated. I'm glad that the code is a much smoother experience for you guys. It's not bug-free, I know, but we'll fix them in time. Just send in logs and we'll figure it out.

Picobit, just curious, what happens when you do a plain paper backup? I admit that I didn't do a lot of test prints at home. (Time to invest in a cheap laser printer, I guess.) That said, my printouts worked fine, but it's certainly possible I missed something or users are subject to conditions that don't apply to me. Oh, and which version of OS X are you running? I did all my test prints on 10.9.1.

Thanks again, and keep the reports coming!

[Swimmer63]

I lost the link to download the latest test versions.  Can someone please post it.

[goatpig]

I lost the link to download the latest test versions.  Can someone please post it.

https://bitcointalk.org/index.php?topic=56424.msg5285727#msg5285727

[picobit]

Picobit, just curious, what happens when you do a plain paper backup? I admit that I didn't do a lot of test prints at home. (Time to invest in a cheap laser printer, I guess.) That said, my printouts worked fine, but it's certainly possible I missed something or users are subject to conditions that don't apply to me. Oh, and which version of OS X are you running? I did all my test prints on 10.9.1.

Hi,

I am running OS X version 10.9.1.  It looks like a stability thing - now I cannot reproduce the lock-up, but in stead I can reach the OS X print dialog sometimes, sometimes I get a crash along the way.  When I reach the Print dialog it is hit or miss whether it is responsive or not.  I get random crashes without anything appearing in the log file (I monitor it with 'tail -f').  We have previously had some test builds with this instability, I think it is related to a bug in Qt, probably building on OS X 10.8 is a workaround.  There seems to be something horribly wrong with Qt on OS X 10.9. :-(

[doug_armory]

Picobit, just curious, what happens when you do a plain paper backup? I admit that I didn't do a lot of test prints at home. (Time to invest in a cheap laser printer, I guess.) That said, my printouts worked fine, but it's certainly possible I missed something or users are subject to conditions that don't apply to me. Oh, and which version of OS X are you running? I did all my test prints on 10.9.1.

Hi,

I am running OS X version 10.9.1.  It looks like a stability thing - now I cannot reproduce the lock-up, but in stead I can reach the OS X print dialog sometimes, sometimes I get a crash along the way.  When I reach the Print dialog it is hit or miss whether it is responsive or not.  I get random crashes without anything appearing in the log file (I monitor it with 'tail -f').  We have previously had some test builds with this instability, I think it is related to a bug in Qt, probably building on OS X 10.8 is a workaround.  There seems to be something horribly wrong with Qt on OS X 10.9. :-(

Yeah, Qt4 is a bit of a mess, especially on Mavericks. (You should've seen the builds before my workarounds were implemented. Yuck!) We're looking into solutions and workarounds.

Oh, and just curious, did you run Alan's build or roll your own? If the latter, try Alan's. I believe it was built under 10.8. If you're still seeing stability issues, let me know.

[etotheipi]

Picobit, just curious, what happens when you do a plain paper backup? I admit that I didn't do a lot of test prints at home. (Time to invest in a cheap laser printer, I guess.) That said, my printouts worked fine, but it's certainly possible I missed something or users are subject to conditions that don't apply to me. Oh, and which version of OS X are you running? I did all my test prints on 10.9.1.

Hi,

I am running OS X version 10.9.1.  It looks like a stability thing - now I cannot reproduce the lock-up, but in stead I can reach the OS X print dialog sometimes, sometimes I get a crash along the way.  When I reach the Print dialog it is hit or miss whether it is responsive or not.  I get random crashes without anything appearing in the log file (I monitor it with 'tail -f').  We have previously had some test builds with this instability, I think it is related to a bug in Qt, probably building on OS X 10.8 is a workaround.  There seems to be something horribly wrong with Qt on OS X 10.9. :-(

Yeah, Qt4 is a bit of a mess, especially on Mavericks. (You should've seen the builds before my workarounds were implemented. Yuck!) We're looking into solutions and workarounds.

Oh, and just curious, did you run Alan's build or roll your own? If the latter, try Alan's. I believe it was built under 10.8. If you're still seeing stability issues, let me know.

Mine was built on 10.9. I meant to do it on the 10.8 VM, since it supposedly more reliable.  But I was in a hurry before I left town, and totally forgot to boot the VM.  When I get back I'll try a 10.8 build

[kentt]

On windows 7 I cannot get the new version to run without crashing.  I tried deleting the appdata folder but it always crashes after synchronizing with network. .88 is working on this machine (kinda, crashes every couple days).

[picobit]

Oh, and just curious, did you run Alan's build or roll your own? If the latter, try Alan's. I believe it was built under 10.8. If you're still seeing stability issues, let me know.

I used Alan's, I think it is more useful to test his builds than my own - there could be things that only works when compiled on your own machine.

[bronan]

Why is nothing of this all mentioned on the website.
how come the last available version on the offiicial website is still the buggy 0.88

[spin]

Why is nothing of this all mentioned on the website.
how come the last available version on the offiicial website is still the buggy 0.88

Website has 0.9-beta.

[_r2h]

On windows 7 I cannot get the new version to run without crashing.  I tried deleting the appdata folder but it always crashes after synchronizing with network. .88 is working on this machine (kinda, crashes every couple days).

Armory crashes for me also as soon as it gets 100% sync'd with the network.  Is there a debug log I can send the devs?

This is the win7 crash notes for what it's worth.

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name:   ArmoryQt.exe
  Application Version:   0.0.0.0
  Application Timestamp:   52d48a67
  Fault Module Name:   _CppBlockUtils.pyd
  Fault Module Version:   0.0.0.0
  Fault Module Timestamp:   5307b524
  Exception Code:   c0000005
  Exception Offset:   0011da00
  OS Version:   6.1.7601.2.1.0.256.1
  Locale ID:   1033
  Additional Information 1:   0a9e
  Additional Information 2:   0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:   0a9e
  Additional Information 4:   0a9e372d3b4ad19135b953a78882e789

[fallinglantern]

I can confirm that network syncs are MUCH faster using the testing git branch on a box with a puny CPU (AMD E-350). Bravo! Startup time is now about a minute down from an hour.

[drrussellshane]

On windows 7 I cannot get the new version to run without crashing.  I tried deleting the appdata folder but it always crashes after synchronizing with network. .88 is working on this machine (kinda, crashes every couple days).

Armory crashes for me also as soon as it gets 100% sync'd with the network.  Is there a debug log I can send the devs?

This is the win7 crash notes for what it's worth.

Problem signature:
  Problem Event Name:   APPCRASH
  Application Name:   ArmoryQt.exe
  Application Version:   0.0.0.0
  Application Timestamp:   52d48a67
  Fault Module Name:   _CppBlockUtils.pyd
  Fault Module Version:   0.0.0.0
  Fault Module Timestamp:   5307b524
  Exception Code:   c0000005
  Exception Offset:   0011da00
  OS Version:   6.1.7601.2.1.0.256.1
  Locale ID:   1033
  Additional Information 1:   0a9e
  Additional Information 2:   0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:   0a9e
  Additional Information 4:   0a9e372d3b4ad19135b953a78882e789

I get a crash on Windows 7 pretty much as soon as I try to start the program, with the testing version.

0.90-beta runs fine for me on Windows 7.