0.96.1 testing build #4

[goatpig]

BUG #1:

Cannot reproduce, never was able to. What locale are you using?

BUG #2:

Do not use auto bitcoind. Also build the current state of testing.

[1713934263]

1713934263

[1713934263]

1713934263

[Mr.Vice]

BUG #1:

Cannot reproduce, never was able to. What locale are you using?

BUG #2:

Do not use auto bitcoind. Also build the current state of testing.

Regarding Bug #1: I'm using the german locale [Deutsch (de)].
Bug #2: I've completed a rebuild & rescan with some block deser errors, but managed to run through anyway. So it seems to work now, but with build #3. I'm going to test build #4 on another machine seperatly.

Kind regards :-)

[goatpig]

Regarding Bug #1: I'm using the german locale [Deutsch (de)].

Make sure your datadir path, wallet comments and labels only have ASCII characters in them. If they have non ASCII characters, it will break the wallet. Use the wallet recovery tool to fix the issue.

[gangtraet]

Make sure your datadir path, wallet comments and labels only have ASCII characters in them. If they have non ASCII characters, it will break the wallet. Use the wallet recovery tool to fix the issue.

Ouch!  It is very easy to type a comment in your own language with a non-ascii character, e.g. in a comment.  Perhaps the GUI should test for ascii-ness of such input, to prevent wallet corruption.

[goatpig]

Make sure your datadir path, wallet comments and labels only have ASCII characters in them. If they have non ASCII characters, it will break the wallet. Use the wallet recovery tool to fix the issue.

Ouch!  It is very easy to type a comment in your own language with a non-ascii character, e.g. in a comment.  Perhaps the GUI should test for ascii-ness of such input, to prevent wallet corruption.

That's technical debt inherited from the Python code base. I don't really want to dedicate time to this since there is the fallback of the wallet recovery code. The issue lies with the wallet code itself, not locales per se. Custom text fields in the Python wallets have a hard coded size for these, and while they check for the size, non ASCII chars can count as more than a byte, therefor the deserialization can fail.

My way of dealing with this is the new C++ wallets which simply won't have any such limitations to begin with, and have a whole lot more test coverage. I only have so much appetite for modifying mission critical Python code.

[Mr.Vice]

Make sure your datadir path, wallet comments and labels only have ASCII characters in them. If they have non ASCII characters, it will break the wallet. Use the wallet recovery tool to fix the issue.

Ouch!  It is very easy to type a comment in your own language with a non-ascii character, e.g. in a comment.  Perhaps the GUI should test for ascii-ness of such input, to prevent wallet corruption.

That's technical debt inherited from the Python code base. I don't really want to dedicate time to this since there is the fallback of the wallet recovery code. The issue lies with the wallet code itself, not locales per se. Custom text fields in the Python wallets have a hard coded size for these, and while they check for the size, non ASCII chars can count as more than a byte, therefor the deserialization can fail.

My way of dealing with this is the new C++ wallets which simply won't have any such limitations to begin with, and have a whole lot more test coverage. I only have so much appetite for modifying mission critical Python code.

I've found one folder I'd been using for storing unsigned transactions, in order to use them over different local user accounts. The folder is called "Öffentlich" in german, although Windows works with given folder names in english in the background anyway. But it seem I've called another folder "Öffentlich ..." in that same dir that was custom. So I've renamed it to "Oeffentlich". Wallet didn't seem to be affected by this, since Armory couldn't find any errors and when I try to enter a non-ascii characted in any label I automatically receive an error prompt message.

What's more problematic are the custom folders, because for e.g. in german you have many characters which are not ascii compatible.

Another question regarding RPC. Why does Armory display in auto-managed bitcoind that RPC is disabled? Since .1 or .2 of the testing builds I get that tool-tip when hovering over that block count?
I'm currently rebuilding with auto-managed bitcoind disabled like you suggested. But now the block count is green insted of purple?

[goatpig]

Another question regarding RPC. Why does Armory display in auto-managed bitcoind that RPC is disabled? Since .1 or .2 of the testing builds I get that tool-tip when hovering over that block count?
I'm currently rebuilding with auto-managed bitcoind disabled like you suggested. But now the block count is green insted of purple?

I'd have to look into it.

[alomar]

i didn't get an answer to this in the other thread so i thought i'd post it here:

is there any general reason why both 0.95.1 and 0.96 *.deb in a Debian VM would both show Connected status bottom right but be stuck at 470751?  everything else appears ok.

getblockcount shows correct height.

[goatpig]

i didn't get an answer to this in the other thread so i thought i'd post it here:

is there any general reason why both 0.95.1 and 0.96 *.deb in a Debian VM would both show Connected status bottom right but be stuck at 470751?  everything else appears ok.

getblockcount shows correct height.

Connected only means the DB is connected to a node over the P2P layer. The block height is what your DB sees as the longest chain. If it's behind your node, your DB has an issue. Try 0.96.0.4, it fixes a lot of that stuff.

[WiiD]

I use 0.96.0.4 and cannot access my BTCs since then.
ArmoryDB.exe always crashes at "Scanning Transaction History" at 98 or 99%.

[goatpig]

logs

[WiiD]

Where do I find them?

[goatpig]

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockDataManagerConfig.cpp#L32

[WiiD]

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockDataManagerConfig.cpp#L32

I do not understand what I do with this?
I just upgraded to 0.96.1 from the newest sticked thread, same problem.
ArmoryDB.exe always crashes at "Scanning Transaction History" , I am not able to access my BTCs since weeks and that is much money..

[goatpig]

Code:

const string BlockDataManagerConfig::defaultDataDir_ = 
   "~/Armory";

This is where you find your logs. Otherwise extract them from the file menu option.

[WiiD]

http://pastebin.ca/3848861

[WiiD]

http://pastebin.ca/3848861

Please help me, I need to access my BTCs, it is all my money.

[goatpig]

I can't do this here, it's too much of a pain to crawl back through history to figure out what's going on. This is why you don't hijack a thread to ask for help. Make your own.

[Holliday]

Please help me, I need to access my BTCs, it is all my money.

Extract your private keys and import them into a wallet that is easier to use (and less secure).