Bitcoin Forum
October 19, 2017, 06:48:45 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: [ANN] The first Armory-for-OSX Release! (Testing)  (Read 4330 times)
gwillen
Newbie
*
Offline Offline

Activity: 16


View Profile
April 16, 2013, 07:20:13 PM
 #21

So, in theory DYLD_LIBRARY_PATH isn't the right way to accomplish this sort of thing -- you're supposed to be able to embed library paths in the executable so that it knows where to look to load the right ones.

In practice I don't know how to do this, or what I'm talking about.

If you received a PM from this account on or prior to June 12, 2011, it wasn't me! Someone was squatting on this account and using it to scam people. I can verify by GPG that this is now the real gwillen from #bitcoin-otc.
1508438925
Hero Member
*
Offline Offline

Posts: 1508438925

View Profile Personal Message (Offline)

Ignore
1508438925
Reply with quote  #2

1508438925
Report to moderator
1508438925
Hero Member
*
Offline Offline

Posts: 1508438925

View Profile Personal Message (Offline)

Ignore
1508438925
Reply with quote  #2

1508438925
Report to moderator
1508438925
Hero Member
*
Offline Offline

Posts: 1508438925

View Profile Personal Message (Offline)

Ignore
1508438925
Reply with quote  #2

1508438925
Report to moderator
The block chain is the main innovation of Bitcoin. It is the first distributed timestamping system.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1508438925
Hero Member
*
Offline Offline

Posts: 1508438925

View Profile Personal Message (Offline)

Ignore
1508438925
Reply with quote  #2

1508438925
Report to moderator
higuys
Newbie
*
Offline Offline

Activity: 28


They all look just the same


View Profile
April 16, 2013, 10:02:10 PM
 #22

DYLD_LIBRARY_PATH tells the dynamic linker (dyld) to look in the specified places for libraries before it tries the locations in the binary headers and subsequently crashes because it can't find anything. It makes sense then that otool doesn't tell you where the libraries that are actually being used are coming from, as this is being done at runtime and requires no static changes to the binaries. You could set the correct places in the binaries, but you're going to have to edit the build configuration for qt and anything that uses those dependencies. Imo that's not going to change anything and you'll just spend time pulling your hair out.

I don't know what the problem is for everyone since there's only one post with actual error output and it's a segfault. I can't debug that without being able to reproduce it.

If it is trying to find more libraries installed globally that aren't there, you should get an error saying so. If this is the case it's not a big deal, and it can be fixed. I really don't think it is, though, as this would have come up again at some point in the past month.

I suspect some of the problems are coming from the fact that the minimum OS X version is set to 10.8 in the python executable, since etotheipi is building on 10.8.

You can do a search/replace with a hex editor on any binaries you think have a minimum version set like so:
Search: 24 00 00 00 10 00 00 00 00 08 0A 00 00 08 0A 00
Replace: 24 00 00 00 10 00 00 00 00 06 0A 00 00 06 0A 00

This will change the minimum version from 10.8 to 10.6

1FCGREde5U8VRbGJBHVoebs1sCjUSzEuY
picobit
Hero Member
*****
Offline Offline

Activity: 547


Decor in numeris


View Profile
April 17, 2013, 06:35:40 AM
 #23

I have made a tiny bit of progress.  It turns out that on my machine, some libraries are loaded from /usr/local/Cellar which will not be present in normal installations.

I set the environment variable DYLD_PRINT_LIBRARIES to 1, that causes the dynamic loader to print the path of all libraries loaded to stderr, and then I started Armory from a terminal (that, by the way, prevents the crash, and fonts are slightly different, so something must be subtly different).  In any case, a long list of libraries appears, and at the end these suspicious lines:
Code:
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqgif.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqico.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqjpeg.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqmng.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqsvg.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/lib/QtSvg.framework/Versions/4/QtSvg
dyld: loaded: /usr/local/Cellar/qt/4.8.4/lib/QtXml.framework/Versions/4/QtXml
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqtga.dylib
dyld: loaded: /usr/local/Cellar/qt/4.8.4/plugins/imageformats/libqtiff.dylib
These should certainly not be loaded from there!  They don't appear to be included in the app.  It could be some optional stuff that Qt loads if it finds it, explaining the strange crashes.  Perhaps including them in the app would help.

EDIT: Removing .profile cause it to crash in the Terminal too.  The self-build one still does not crash.  This is the error message:
Code:
./MacOS/Armory: line 5:   925 Illegal instruction: 4  bin/python armorybuild/ArmoryQt.pyc
picobit
Hero Member
*****
Offline Offline

Activity: 547


Decor in numeris


View Profile
April 17, 2013, 07:10:49 AM
 #24

I think I am on to something, and have a working hypothesis.

My evidence so far:
  • My .profile cause the app to work when called from the Terminal, disabling my .profile cause it to crash.
  • My .profile cause three libraries to be loaded from /usr/local instead of from etotheipi's app: sip.so, QtCore.so, QtGui.so
  • The crash is caused by an illegal instruction.
  • My MacBook is almost three years old.

I suspect that the problems are caused by one or more of the dependencies (sip or Qt) to be built with optimizations for the actual CPU on which it is built.  Older CPUs will then not support one or more instructions in the code.  This explains why only some people see the problem (those with older machines) and why it does not depend on the OS version.

To do: find the offending dependency, and fix its Makefile.
picobit
Hero Member
*****
Offline Offline

Activity: 547


Decor in numeris


View Profile
April 17, 2013, 03:04:11 PM
 #25

@etotheipi:

Could you try adding --env=std to the brew line installing sip and pyqt, it looks like the "superenv" feature in Homebrew is removing options specifying a more general architecture from the compilation commands.  You will have to uninstall pyqt and sip, otherwise the script will not reinstall them.

something like
Code:
brew install --env=std cryptopp swig qt pyqt wget
(I have tested that sip and pyqt builds with that option, but I have not tested the rest.  I suspect that it is pyqt that is causing the trouble.)

This is a long shot, but it might work.  I could then test the resulting .app and see if it runs.
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
April 17, 2013, 04:28:50 PM
 #26

Unfortunately, I don't have a system to test on that doesn't work, so the best I can do is try your suggestion, and post the results.

I uninstalled all the brew dependencies, cleaned all the build directories, added --env=std, and then rebuilt everything.  For some reason, the result is 300 kB smaller... not sure why.  But I did it, so you can try it.  I have updated the original post here.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
picobit
Hero Member
*****
Offline Offline

Activity: 547


Decor in numeris


View Profile
April 17, 2013, 07:06:24 PM
 #27

Unfortunately, I don't have a system to test on that doesn't work, so the best I can do is try your suggestion, and post the results.

I uninstalled all the brew dependencies, cleaned all the build directories, added --env=std, and then rebuilt everything.  For some reason, the result is 300 kB smaller... not sure why.  But I did it, so you can try it.  I have updated the original post here.
Dammit!  No difference, it still crashes.

Well, if you can't fix the problem, document it Smiley   Some people (probably on older Macs) will find the app crashing - and will have to build it themselves.  Certainly not an optimal solution, but the majority that don't see the problem will probably be happy anyway.

By the way, it is sip.so that cause the crash, according to Apple's crash reporter.  I really cannot see why.
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
April 17, 2013, 07:12:19 PM
 #28

Do you have a way to check whether anything really changed?  I mean, I tried uninstalling everything, but there's a chance that it didn't do it right.  I was thinking of restoring a fresh OSX install to try it, but I forgot to save the fresh-install state.  I figured what I did was enough...

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
picobit
Hero Member
*****
Offline Offline

Activity: 547


Decor in numeris


View Profile
April 17, 2013, 07:21:03 PM
 #29

The sip.so library has the same SHA1, so it has not changed.  I would think that a timestamp or something would change when compiling, so perhaps it has not worked.  It should be enough to do "brew uninstall sip" before and "brew install --env=std sip" afterwards.  On the other hand, now that it looks like it is sip and not pyqt that is the culprit, I am less sure about the --env=std stuff.
maxmint
Hero Member
*****
Offline Offline

Activity: 700



View Profile
April 18, 2013, 05:59:41 AM
 #30

I just tried it and unfortunately it never finnishes the inital scanning process (I left it open for 4 hours).
I'm on a brand new iMac with SSD, so I guess it should be done by now.

I'm running bitcoin-qt version 0.7.2 because I already had database problems when using 0.8.1 and had to do a rescan.
Could that be related to the armory problem?

Anyway, thanks so much for getting this started for OS X, really looking forward to a working version!

My PGP-Key: 462D02D8
Verify my messages using keybase: https://keybase.io/maxmint
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
April 18, 2013, 06:03:16 AM
 #31

I just tried it and unfortunately it never finnishes the inital scanning process (I left it open for 4 hours).
I'm on a brand new iMac with SSD, so I guess it should be done by now.

I'm running bitcoin-qt version 0.7.2 because I already had database problems when using 0.8.1 and had to do a rescan.
Could that be related to the armory problem?

Anyway, thanks so much for getting this started for OS X, really looking forward to a working version!

Can you send me a log file?  And to clarify, it finishes "synchronizing" (the first one), but doesn't finish scanning the blockchain (the second one)?  Are you using a non-standard datadir?   I ask because I just found a bug that will be fixed when I release 0.88 soon. 

0.7.1 should work.  But I'll wait to say any more until I see a log file (etotheipi gmail com)

It sounds like 0.88 has to come with a caveat ... flip a coin ... if it's heads, it won't work on your OSX machine... gah! 

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
maxmint
Hero Member
*****
Offline Offline

Activity: 700



View Profile
April 18, 2013, 06:21:07 AM
 #32

Can you send me a log file? 

Here's the log from a recent start:
http://snippi.com/s/so03ak4

And to clarify, it finishes "synchronizing" (the first one), but doesn't finish scanning the blockchain (the second one)?  Are you using a non-standard datadir?   I ask because I just found a bug that will be fixed when I release 0.88 soon. 

It's stuck at the "Scanning Transaction History" process and won't ever get over 75%.
Datadir is the default directory in ~/Library/Application Support/Bitcoin/

My PGP-Key: 462D02D8
Verify my messages using keybase: https://keybase.io/maxmint
picobit
Hero Member
*****
Offline Offline

Activity: 547


Decor in numeris


View Profile
April 18, 2013, 08:22:33 AM
 #33

It sounds like 0.88 has to come with a caveat ... flip a coin ... if it's heads, it won't work on your OSX machine... gah! 
People will use it to play Satoshi Dice anyway, so that is only fitting  Grin
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
April 18, 2013, 05:10:03 PM
 #34

Can you send me a log file? 

Here's the log from a recent start:
http://snippi.com/s/so03ak4

And to clarify, it finishes "synchronizing" (the first one), but doesn't finish scanning the blockchain (the second one)?  Are you using a non-standard datadir?   I ask because I just found a bug that will be fixed when I release 0.88 soon. 

It's stuck at the "Scanning Transaction History" process and won't ever get over 75%.
Datadir is the default directory in ~/Library/Application Support/Bitcoin/

This is becoming all-too-common now.  And I just started on my persistent-blockchain updates -- I will no longer be touching blk*.dat files at all!  This will solve so many bugs like this (though, probably introduce more...)

Until then, you get the same advice I give everyone else.  It looks like there's a glitch in your blk*.dat files which Armory is tripping over.   Redownload the blockchain.  It takes a long time, but it seems to work. 

(1) I can't replicate this problem, so I don't know how to fix it
(2) It is purely an artifact of a design decision that is completely going away... I don't know if it's worth trying to fix it if it will be obsolete in a couple weeks.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
ErebusBat
Hero Member
*****
Offline Offline

Activity: 560

I am the one who knocks


View Profile
April 18, 2013, 10:16:34 PM
 #35

FWIW the beta OSX client seems to be much faster than the one I compiled from the homebrew packages

░▒▓█ Coinroll.it - 1% House Edge Dice Game █▓▒░ • Coinroll Thread • *FREE* 100 BTC Raffle

Signup for CEX.io BitFury exchange and get GHS Instantly!  Don't wait for shipping, mine NOW!
maxmint
Hero Member
*****
Offline Offline

Activity: 700



View Profile
April 18, 2013, 10:25:28 PM
 #36

This is becoming all-too-common now.  And I just started on my persistent-blockchain updates -- I will no longer be touching blk*.dat files at all!  This will solve so many bugs like this (though, probably introduce more...)

Until then, you get the same advice I give everyone else.  It looks like there's a glitch in your blk*.dat files which Armory is tripping over.   Redownload the blockchain.  It takes a long time, but it seems to work. 

(1) I can't replicate this problem, so I don't know how to fix it
(2) It is purely an artifact of a design decision that is completely going away... I don't know if it's worth trying to fix it if it will be obsolete in a couple weeks.

Thanks for your analysis. Actually, I had problems with my local block chain some weeks ago and already re-downloaded the whole thing. Then  I again had problems and switched to Bitcoin-qt 0.7.2 – but there's probably still some faulty data on my computer. An I guess you're right that this is the reason for problems with Armory as well.

I will download the block chain again and I'm looking forward to the next release of Armory. It's simply the best app out there and I really appreciate you working on this!

My PGP-Key: 462D02D8
Verify my messages using keybase: https://keybase.io/maxmint
Jourgensen
Jr. Member
*
Offline Offline

Activity: 46


View Profile
April 19, 2013, 01:24:57 PM
 #37


  • Notifications are disabled completely.  Apparently this solution does not play nicely with Growl.  0.5 BTC to anyone who figures out how to fix it!


I will add 0.5 BTC to this "bounty" to get growl working. I'm sure this would happen after all the bugs are worked out.
italeffect
Sr. Member
****
Offline Offline

Activity: 255



View Profile
April 19, 2013, 06:22:16 PM
 #38

.88 seemed to work for me but actually crashes every time when trying to encrypt a new wallet or decrypt an existing one.

Repeatable Steps:

Click Create new wallet
enter password 3 times
wallet created
unlock wallet
enter password
crash

or

Click Create Paper Backup
Prompt for password
enter password
crash

OS X 10.8.3
Mac Pro 4,1

Process:         python [70016]
Path:            /Applications/Armory.app/Contents/MacOS/Armory
Identifier:      com.armory.armory
Version:         Huh
Code Type:       X86-64 (Native)
Parent Process:  bash [70015]
User ID:         501
Date/Time:       2013-04-19 11:18:10.814 -0700
OS Version:      Mac OS X 10.8.3 (12D78)
Report Version:  10
Crashed Thread:  0  Dispatch queue: com.apple.main-thread
Exception Type:  EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000

Dash: Xdopotr3eAHpsSCMkUyU2YWP3WQWb5X3t8
etotheipi
Legendary
*
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
April 19, 2013, 06:25:06 PM
 #39

.88 seemed to work for me but actually crashes every time when trying to encrypt a new wallet or decrypt an existing one.

Repeatable Steps:

Click Create new wallet
enter password 3 times
wallet created
unlock wallet
enter password
crash

or

Click Create Paper Backup
Prompt for password
enter password
crash

OS X 10.8.3
Mac Pro 4,1

Process:         python [70016]
Path:            /Applications/Armory.app/Contents/MacOS/Armory
Identifier:      com.armory.armory
Version:         Huh
Code Type:       X86-64 (Native)
Parent Process:  bash [70015]
User ID:         501
Date/Time:       2013-04-19 11:18:10.814 -0700
OS Version:      Mac OS X 10.8.3 (12D78)
Report Version:  10
Crashed Thread:  0  Dispatch queue: com.apple.main-thread
Exception Type:  EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000


Can you try restart Armory and do it with a new wallet?  Can you decrypt other wallets?  I've seen an error like this when the wallet was corrupted.  Perhaps it was corrupted immediately, somehow?  It will fail on any operation that requires unlocking.

Also, please send me a log file.  If the error is what I think it is, it'll have a "Stored public key does not match private key!" error (or something like that).

Thanks for the report.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
italeffect
Sr. Member
****
Offline Offline

Activity: 255



View Profile
April 19, 2013, 07:05:34 PM
 #40

Thanks. I just sent via PM. I created a new wallet and repeated the same crash.

Dash: Xdopotr3eAHpsSCMkUyU2YWP3WQWb5X3t8
Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!