Topic: Armory - Discussion Thread - page 175. (Read 521749 times)

Those are the only messages on the logfile.
Not very useful it seems.

no i don't i'm sorry. if it ever happens again, i'll be sure to keep a copy for you.

Yes, it already happened with both those versions. Or at least with 0.82.1. But if I'm not mistaken I've already updated it twice since that started happening. My last update(the second) was today, to 0.82.2.

I'll fire it up and collect a log file to see if there is something useful there.

The compiling is only half of it.  I can't compile the 32-bit version on a 64-bit machine without have the supporting libraries installed as 32-bit (such as python).  If I install those packages as 32-bits, everything breaks, or weird things start happening.  I'm sure I could do it, but I have tried in the past and I could not resolve it in a timely manner.  A second VM seemed easier.

The other half (which wouldn't benefit from cross-compiling) is the process for creating the installer.  The program has to be setup for each new version, and for whatever reason the executable always comes out without an icon, so I have to modify it (using Resource Hacker).  It's not terrible, but if you consider that I do it about 5 times per night (per OS) when tweaking, testing, updating and trying to get out a release, it's pretty annoying.



Strange.  Does this happen with 0.81 also?  0.82.1?  Can you send me a log file?  Just like for wachtwood, I will release a temporary version just for logging network messages (or maybe it will become part of the release, hmm).  Hopefully that will help answer some questions about networking issues.




I don't suppose you have the settings file in your recycle bin or something, do you?  I just looked at how that error is triggered, and it's by the "LastFilterState" variable in the settings file being a string (supposed to be an integer).  I can see why deleting that file fixed it, but I'm curious what it got set to that caused the problem.  I can't see in the code how it could get set to non-integer value.

Ever since you added the version check Armory is always losing the connection to the bitcoin client.
It can't ever hold it for a couple minutes straight.

I do indeed run Windows 7 64 bit. Bummer, setting up a system is time I always feel is just wasted (and not very intellectually stimulating )

Why do you need a specialized dev environment for each of the two versions anyway? Isn't there a cross compiler available?

i was getting this error in an older version (can't remember which one), so I decided to upgrade to the latest, but still get the same error on startup:


so, i can't get any further than the splash logo, then it dies.

edit: okay so i'm going to try the win32 version.

edit 2: before trying the win32 version, i just deleted a few things out of the appdata folder such as mempool.bin and settings file, and it worked.

IMPORTANT -- Help Test!

I originally split Armory for Windows in 32-bit and 64-bit, because I needed it to be a 64-bit application for the memory management (and the 32-bit app was offline-only).  But, since version 0.81, the 32-bit version now has the same functionality.  And I just realized it can be installed and runs fine on 64-bit Windows!  

If this is the case, it will further simplify my build & distribution process (only one .msi file to make!).  I'm getting more excited about this than I should... but anything that makes distribution easier is beneficial for everyone (creating the .msi files takes a bit of effort, so only doing it once would be great).  

If you are reading this and using the 64-bit version, please consider installing the 32-bit version and switching to that as a way of helping me test.  To me, it looks like it works, but there's a lot of subtle problems I can't reproduce, myself.  

I can't think of a reason (anymore) that Armory needs to be a 64-bit application.  Perhaps it runs slower in 32-bits?  Help me find out!  Or give me reasons I should maintain two different versions.

How delightful -- my Win7 development machine/VM just got corrupted.  One too many power-outages has somehow led to system files getting corrupted and random things starting to misbehave  It takes 20 minutes to try to fix sectors on boot, and now all these programs started crashing and asking for me to reinstall.  Including Visual Studio.  Ugh...

On the upside, I finished creating a "networklog" branch and put in the network logging I needed for you.  However, I can't create a Windows binary for it without creating a new Windows VM.  Setting up a new dev VM is likely to take some time.  

My WinXP 32-bit system still works, but not 64-bit.  I assume you are running 64-bit OS...? 

What luck!

Interesting.  I've had one other report of behavior like this, but it was isolated to a Windows machine, so I assumed it was a windows thing.  Have not seen it on linux, until now...

There are some very subtle issues with the way Armory tries to leech off the bitcoind/-qt blockchain files.  So far, it's been pretty good, but this bothers me a bit (seg faults are always concerning).

Given that I can't reproduce it, I might just re-work the blockchain utilities.  I know that if Armory manages its own copy of the blockchain, and Armory has full control of it, there's a lot less that can go wrong.  It's something I wanted to do eventually, anyway.

Okay great. I just wanted to make sure we were on the same line as misunderstandings do happen in text only communication without intonation. Good luck and let me know if you need me.

I don't say much on this topic, but Armory is running fine with me, no error (I'm using 0.82.2)

Love Armory - Have been running v 0.82.2-Alpha that I compiled from git on my Ubunto 12.04 box. It will run fine for 1 or two days, then suddenly I get:


***ERROR:  parseNewBlockData did not get enough data...
Adding new block data to memory pool failed!Block data did not extend the main chain!
Segmentation fault (core dumped)


It starts up fine after that. Nothing is lost. This has happened a couple times, so I thought you should know

ScarecrowMagick

Haha, don't worry.  I didn't interpret it as pushy or anything of the sort.  I really want to spend time on Armory, I just haven't had any period of uninterrupted time to dive into anything big (like changing blockchain utilities again).  However, this network logging thing won't require a lot of attention span, and I will have no problem doing it.  After all, I really want to know what's going on, too.

This excessive work thing is rare for me.  In 6 years I've worked here, I've only worked overtime 2 or 3 times, and never this much.  So this is non-standard, but it's important so I'm putting up with it this one time.   Hell, if I wasn't working, I'd probably be doing Armory 60 hours per week.  My brain is fine with it as long as it's intellectually stimulating

So, if you don't hear from me, remind me later next week.  If you do hear from me, it's not because you coerced me.  It's because I wanted to.  No guilt trips, please.

Wow, I apologize if I came across as pushy or anything, this was not my intention at all.

You do not have to hurry and you can take all the time you need to fix this. I was just reminding you because 5 days ago you posted you'd get to it that night and I hadn't seen or heard anything about it so I thought you might have forgotten. Please don't go work yourself silly for something that isn't that big a deal (It's just the 1.05 BTC I cannot access right now, but will be able to access in the future).

Please don't go and do extra work if you are already working 60 hours, that cannot be healthy.

I haven't forgotten about you.  I'm just working a 60-hour week at work-work and haven't had time to think about Armory much (I'm at work-work right now).

This week is kind of intense, but I will be taking most of the following week off, mostly to catch up on Armory stuff   Then back to my normal schedule of 30 hours/week on each.

However, since you keep reminding me, I'll try to make some time tonight to get the networking logging implemented and send you a special version.  If the problem turns out to be really simple, I'd feel silly if you had to wait a month to figure it out!

Hey, have you had time to look into this already?

You'd think I'd have a settings or CLI option for specifying non-standard satoshi port, but I guess I never added one.   I'll try to remember to add it to the next release.

I use Bitcoin on port 9050 through Tor.  I tried it without Tor and it worked fine.  Is their any way to configure the Armory client to work while running Bitcoin through TOR?

Do you have any abnormal setup, such as bitcoin-qt home directory in a non-standard location?  Or using a non-standard port for bitcoin-qt? 

Armory expects to find blk000*.dat in your C:\Users\\AppData\Roaming\Bitcoin directory, and expects the Satoshi client to be accessible through port 8333.

Also, next time it's open in offline mode, try going to File-->Export Log File and check the file for anything that looks suspicious.  I doubt there's much there (I don't have much networking-related logging code) but it won't hurt.

Anything else you can think of that is non-standard?