Topic: Private key import fails on 0.95.1 (with a side order of NULL dereferencing) (Read 455 times)
January 16, 2017, 11:36:53 AM
Cool. Just wanted to make sure this was on the radar.
January 15, 2017, 11:41:59 PM
I changed a lot of code around wallets this upcoming version, I'll have to rework imports basically from the ground up, so the code is gonna change completely (and well, work)
January 15, 2017, 11:37:02 PM
Hello. I tried to import a private key from a physical coin somebody gave me. When I finally found the right form for the key, Armory didn't complain but didn't do anything else. Here's what I saw in armorylog.txt.
Looking into the code, it looks like this commit is the culprit, with addAddressBulk() removed. I didn't try adding it back because I didn't know if it would upset any proverbial apple carts. Instead, I got 0.94.1 going in a VM, imported the wallet where I wanted the imported key to go, added the key, and exported the wallet back to my primary client. After everything was scanned, the funds were picked up. (The imported key even showed the miner pickaxe. I was pleasantly surprised by this easter egg!)
This workaround isn't perfect, though. I quit Armory and tried to restart. It crashed upon startup. Here's what I saw. It looked like there was a NULL dereference but I didn't save that portion of the report, unfortunately. (Reminder: 0.95.1 on macOS 10.12.2, the latest version.)
The OS asked if I wanted to try to reopen the window or start fresh. If I tried starting fresh, Armory crashed the same way. Once I tried a reopen, everything seemed fine. Restarting seems fine. I wonder if this has something to do with the wallet integrity scan not being done when I reimported the wallet with the imported key.
Thanks. I'm happy to do any testing if any fixes come up.
Code:
2017-01-15 18:35 (ERROR) -- Traceback (most recent call last):
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/qtdialogs.py", line 3028, in okayClicked
self.processUserString(securePrintCode)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/qtdialogs.py", line 3161, in processUserString
self.wlt.sweepAddressList(sweepAddrList, self.main)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/armoryengine/PyBtcWallet.py", line 52, in inner
return func(*args, **kwargs)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/armoryengine/PyBtcWallet.py", line 3199, in sweepAddressList
self.cppWallet.addAddressBulk(addrBulk, False)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/CppBlockUtils.py", line 2246, in
__getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/CppBlockUtils.py", line 83, in _swig_getattr
raise AttributeError("'%s' object has no attribute '%s'" % (class_type.__name__, name))
AttributeError: 'BtcWallet' object has no attribute 'addAddressBulk'
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/qtdialogs.py", line 3028, in okayClicked
self.processUserString(securePrintCode)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/qtdialogs.py", line 3161, in processUserString
self.wlt.sweepAddressList(sweepAddrList, self.main)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/armoryengine/PyBtcWallet.py", line 52, in inner
return func(*args, **kwargs)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/armoryengine/PyBtcWallet.py", line 3199, in sweepAddressList
self.cppWallet.addAddressBulk(addrBulk, False)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/CppBlockUtils.py", line 2246, in
__getattr__ = lambda self, name: _swig_getattr(self, BtcWallet, name)
File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/CppBlockUtils.py", line 83, in _swig_getattr
raise AttributeError("'%s' object has no attribute '%s'" % (class_type.__name__, name))
AttributeError: 'BtcWallet' object has no attribute 'addAddressBulk'
Looking into the code, it looks like this commit is the culprit, with addAddressBulk() removed. I didn't try adding it back because I didn't know if it would upset any proverbial apple carts. Instead, I got 0.94.1 going in a VM, imported the wallet where I wanted the imported key to go, added the key, and exported the wallet back to my primary client. After everything was scanned, the funds were picked up. (The imported key even showed the miner pickaxe. I was pleasantly surprised by this easter egg!)
This workaround isn't perfect, though. I quit Armory and tried to restart. It crashed upon startup. Here's what I saw. It looked like there was a NULL dereference but I didn't save that portion of the report, unfortunately. (Reminder: 0.95.1 on macOS 10.12.2, the latest version.)
Code:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 _CppBlockUtils.so 0x000000010683e6ef BinaryDataObject Arguments::get() + 31
1 _CppBlockUtils.so 0x0000000106833657 SwigClient::BlockDataViewer::registerWithDB(BinaryData) + 439
2 _CppBlockUtils.so 0x00000001069a4a31 _wrap_BlockDataViewer_registerWithDB(_object*, _object*) + 481
0 _CppBlockUtils.so 0x000000010683e6ef BinaryDataObject Arguments::get
1 _CppBlockUtils.so 0x0000000106833657 SwigClient::BlockDataViewer::registerWithDB(BinaryData) + 439
2 _CppBlockUtils.so 0x00000001069a4a31 _wrap_BlockDataViewer_registerWithDB(_object*, _object*) + 481
The OS asked if I wanted to try to reopen the window or start fresh. If I tried starting fresh, Armory crashed the same way. Once I tried a reopen, everything seemed fine. Restarting seems fine. I wonder if this has something to do with the wallet integrity scan not being done when I reimported the wallet with the imported key.
Thanks. I'm happy to do any testing if any fixes come up.
Jump to: