Armory won't open. Help!

[Piper67]

So last night I tried running my online Armory, and I got an error message directing me to the log file, which read:

Traceback (most recent call last):
File "ArmoryQt.py", line 32, in <module>
File "armoryengine.pyc", line 498, in <module>
File "armoryengine.pyc", line 480, in chopLogFile
MemoryError

I tried running it in offline mode, but the same thing happened.

I tried deleting the databases, no joy.

I tried installing a newer version of Armory, no joy.

I tried uninstalling and then reinstalling both older and newer versions, no joy.

I opened a ticket through the Armory website, but they must be busy, because... no joy.

Running on a Windows 7 machine with 8 gigs of ram that are apparently healthy.

Any ideas?

Thanks in advance.

[TonyT]

Try setting up in a virtual machine or in another computer.  BTW always have the latest version of Armory running.  I feel sorry for you since it took me 44  hours to install Armory (before it was online) since the blockchain had to be downloaded... such is the price of progress?

[Piper67]

Try setting up in a virtual machine or in another computer.  BTW always have the latest version of Armory running.  I feel sorry for you since it took me 44  hours to install Armory (before it was online) since the blockchain had to be downloaded... such is the price of progress?

Oh, I have it running on another system, and have the offline installed on an air gapped computer as well. My only concern is that it just stopped opening up, and won't let me no matter what I try.

I'll add some memory to that computer this evening and see if that does the trick, but I was hoping someone might have some other idea.

Thanks!

[etotheipi]

exception MemoryError
Raised when an operation runs out of memory but the situation may still be rescued (by deleting some objects). The associated value is a string indicating what kind of (internal) operation ran out of memory. Note that because of the underlying memory management architecture (C’s malloc() function), the interpreter may not always be able to completely recover from this situation; it nevertheless raises an exception so that a stack traceback can be printed, in case a run-away program was the cause.

Maybe you ran out of RAM?  Maybe it's actually a completely overflowing log file and it can't read the whole thing in? 

In your Armory home dir, check the size of armorylog.txt and armorycpplog.txt.  How big are they?  Try deleting them.

[Piper67]

exception MemoryError
Raised when an operation runs out of memory but the situation may still be rescued (by deleting some objects). The associated value is a string indicating what kind of (internal) operation ran out of memory. Note that because of the underlying memory management architecture (C’s malloc() function), the interpreter may not always be able to completely recover from this situation; it nevertheless raises an exception so that a stack traceback can be printed, in case a run-away program was the cause.

Maybe you ran out of RAM?  Maybe it's actually a completely overflowing log file and it can't read the whole thing in? 

In your Armory home dir, check the size of armorylog.txt and armorycpplog.txt.  How big are they?  Try deleting them.

Thanks! As I said, I'll add some more ram, and then I'll try deleting those two files.

[Piper67]

such is the price of progress?

No, it's a trade off for maximum security. You can use very available and fast clients like Mycelium or Electrum if you value convenience more than security.

Agreed 100%. I'm actually very happy with Armory going back to the first version I ever downloaded and used.

[etotheipi]

exception MemoryError
Raised when an operation runs out of memory but the situation may still be rescued (by deleting some objects). The associated value is a string indicating what kind of (internal) operation ran out of memory. Note that because of the underlying memory management architecture (C’s malloc() function), the interpreter may not always be able to completely recover from this situation; it nevertheless raises an exception so that a stack traceback can be printed, in case a run-away program was the cause.

Maybe you ran out of RAM?  Maybe it's actually a completely overflowing log file and it can't read the whole thing in?  

In your Armory home dir, check the size of armorylog.txt and armorycpplog.txt.  How big are they?  Try deleting them.

Thanks! As I said, I'll add some more ram, and then I'll try deleting those two files.

Don't worry about the RAM.  my guess is the log file somehow became 20 GB and Armory is choking trying to read it (which is ironic because it's failing while trying to cut it down to 1 MB)

[Piper67]

exception MemoryError
Raised when an operation runs out of memory but the situation may still be rescued (by deleting some objects). The associated value is a string indicating what kind of (internal) operation ran out of memory. Note that because of the underlying memory management architecture (C’s malloc() function), the interpreter may not always be able to completely recover from this situation; it nevertheless raises an exception so that a stack traceback can be printed, in case a run-away program was the cause.

Maybe you ran out of RAM?  Maybe it's actually a completely overflowing log file and it can't read the whole thing in?  

In your Armory home dir, check the size of armorylog.txt and armorycpplog.txt.  How big are they?  Try deleting them.

Thanks! As I said, I'll add some more ram, and then I'll try deleting those two files.

Don't worry about the RAM.  my guess is the log file somehow became 20 GB and Armory is choking trying to read it (which is ironic because it's failing while trying to cut it down to 1 MB)

Awesome. I'll definitely try that... too bad I deleted the databases and now will have to download them again. And that I already bought the ram (but I guess you can never have too much of that!)

[etotheipi]

exception MemoryError
Raised when an operation runs out of memory but the situation may still be rescued (by deleting some objects). The associated value is a string indicating what kind of (internal) operation ran out of memory. Note that because of the underlying memory management architecture (C’s malloc() function), the interpreter may not always be able to completely recover from this situation; it nevertheless raises an exception so that a stack traceback can be printed, in case a run-away program was the cause.

Maybe you ran out of RAM?  Maybe it's actually a completely overflowing log file and it can't read the whole thing in?  

In your Armory home dir, check the size of armorylog.txt and armorycpplog.txt.  How big are they?  Try deleting them.

Thanks! As I said, I'll add some more ram, and then I'll try deleting those two files.

Don't worry about the RAM.  my guess is the log file somehow became 20 GB and Armory is choking trying to read it (which is ironic because it's failing while trying to cut it down to 1 MB)

Awesome. I'll definitely try that... too bad I deleted the databases and now will have to download them again. And that I already bought the ram (but I guess you can never have too much of that!)

Can you please confirm the sizes of those files.  I'm like 99% sure that what I just described is the problem, but I'd like confirmation.  If so, we can tweak the code to avoid this.  The whole point of that code block is to prevent this from happening, but apparently it can't handle once it has happened (perhaps from leaving Armory running for 3 months with a bunch of constant messages being written to log.

[Piper67]

exception MemoryError
Raised when an operation runs out of memory but the situation may still be rescued (by deleting some objects). The associated value is a string indicating what kind of (internal) operation ran out of memory. Note that because of the underlying memory management architecture (C’s malloc() function), the interpreter may not always be able to completely recover from this situation; it nevertheless raises an exception so that a stack traceback can be printed, in case a run-away program was the cause.

Maybe you ran out of RAM?  Maybe it's actually a completely overflowing log file and it can't read the whole thing in?  

In your Armory home dir, check the size of armorylog.txt and armorycpplog.txt.  How big are they?  Try deleting them.

Thanks! As I said, I'll add some more ram, and then I'll try deleting those two files.

Don't worry about the RAM.  my guess is the log file somehow became 20 GB and Armory is choking trying to read it (which is ironic because it's failing while trying to cut it down to 1 MB)

Awesome. I'll definitely try that... too bad I deleted the databases and now will have to download them again. And that I already bought the ram (but I guess you can never have too much of that!)

Can you please confirm the sizes of those files.  I'm like 99% sure that what I just described is the problem, but I'd like confirmation.  If so, we can tweak the code to avoid this.  The whole point of that code block is to prevent this from happening, but apparently it can't handle once it has happened (perhaps from leaving Armory running for 3 months with a bunch of constant messages being written to log.

Sure, I'll check the size before I delete them. I don't think Armory was open for months on that computer, but probably about two weeks. That was running 0.90... one of the advantages of running 0.88 was that it kept crashing at somewhat regular intervals, so I guess this kind of thing never happened 

[Piper67]

exception MemoryError
Raised when an operation runs out of memory but the situation may still be rescued (by deleting some objects). The associated value is a string indicating what kind of (internal) operation ran out of memory. Note that because of the underlying memory management architecture (C’s malloc() function), the interpreter may not always be able to completely recover from this situation; it nevertheless raises an exception so that a stack traceback can be printed, in case a run-away program was the cause.

Maybe you ran out of RAM?  Maybe it's actually a completely overflowing log file and it can't read the whole thing in?  

In your Armory home dir, check the size of armorylog.txt and armorycpplog.txt.  How big are they?  Try deleting them.

Thanks! As I said, I'll add some more ram, and then I'll try deleting those two files.

Don't worry about the RAM.  my guess is the log file somehow became 20 GB and Armory is choking trying to read it (which is ironic because it's failing while trying to cut it down to 1 MB)

Awesome. I'll definitely try that... too bad I deleted the databases and now will have to download them again. And that I already bought the ram (but I guess you can never have too much of that!)

Can you please confirm the sizes of those files.  I'm like 99% sure that what I just described is the problem, but I'd like confirmation.  If so, we can tweak the code to avoid this.  The whole point of that code block is to prevent this from happening, but apparently it can't handle once it has happened (perhaps from leaving Armory running for 3 months with a bunch of constant messages being written to log.

Good news! I deleted the armorylog.txt file and the reinstalled Armory opened... of course now it's going to have to download the databases all over again.

The file was 1.45 GB... the armorycpplog.txt was only a few hundred KB

[TonyT]

Good news! I deleted the armorylog.txt file and the reinstalled Armory opened... of course now it's going to have to download the databases all over again.

The file was 1.45 GB... the armorycpplog.txt was only a few hundred KB

I am watching this thread, and if possible, please feel free to tell how long it took to download the databases and resynch Armory.  It took me 44 hours and I want to see if I'm an outlier or not.

[Piper67]

Good news! I deleted the armorylog.txt file and the reinstalled Armory opened... of course now it's going to have to download the databases all over again.

The file was 1.45 GB... the armorycpplog.txt was only a few hundred KB

I am watching this thread, and if possible, please feel free to tell how long it took to download the databases and resynch Armory.  It took me 44 hours and I want to see if I'm an outlier or not.

Around 5 hours on both of my systems (different connection speeds but both over 10 Mbps)