Can not send any amount of eth.

[noob1313]

No matter what amount of eth I try to send I get a unknown error dialog box and nothing is sent.

[noob1313]

I was able to export the account to another computer and send eth ok.

[almindor]

Did you use Etherwall on the other computer too? Same settings? (e.g. thin client?)

[noob1313]

Yes I did use etherwall on the other computer. Yes both thin client.

On Thu, Aug 31, 2017 at 10:23 PM Aleš Katona notifications@github.com wrote:

Did you use Etherwall on the other computer too? Same settings? (e.g. thin client?)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/almindor/etherwall/issues/57#issuecomment-326470726, or mute the thread https://github.com/notifications/unsubscribe-auth/AeEHtWZAFmm2FfsovKILyT36-pPPJDASks5sd2qWgaJpZM4PJjcM .

[almindor]

Hmm interesting.

Is there any difference between the two machines? Same OS/version?

Did the error only happen on sending? Can you check with the "bad" PC and see if you get proper block number for example? You can see by clicking the little block icon on the left bottom.

[noob1313]

They are both Windows 10. The block number is 4227098 and it is increasing. Shows ready on the bottom center.

On Thu, Aug 31, 2017 at 11:05 PM, Aleš Katona notifications@github.com wrote:

Hmm interesting.

Is there any difference between the two machines? Same OS/version?

Did the error only happen on sending? Can you check with the "bad" PC and see if you get proper block number for example? You can see by clicking the little block icon on the left bottom.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/almindor/etherwall/issues/57#issuecomment-326475829, or mute the thread https://github.com/notifications/unsubscribe-auth/AeEHtamFvohh9HTLmLT5T1ddiSdoX2Iiks5sd3RwgaJpZM4PJjcM .

[almindor]

I suspect the Etherwall/geth version is also same. If you have a tx in the future can you try on the "bad" computer first? After it fails look at the logs/app and logs/geth and take screenshots if possible.

NOTE: a transaction either happens or not, there's no "in between" so if it fails but you don't see it register then it didn't get out. (Etherwall itself will show it, but double check on https://etherscan.io)

[almindor]

Also are both the computers on the same network?

[noob1313]

Yes they are both on the same network. Just tried again I attached the screen shots.

On Fri, Sep 1, 2017 at 10:42 AM, Aleš Katona notifications@github.com wrote:

Also are both the computers on the same network?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/almindor/etherwall/issues/57#issuecomment-326599109, or mute the thread https://github.com/notifications/unsubscribe-auth/AeEHtZGYK7quCyjvCKR1-Y2yqi6sGpGaks5seBftgaJpZM4PJjcM .

[almindor]

I don't see the screenshots..

[noob1313]

Are they there as attachments? I attached them to this one also.

On Fri, Sep 1, 2017 at 11:03 AM, Aleš Katona notifications@github.com wrote:

I don't see the screenshots..

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/almindor/etherwall/issues/57#issuecomment-326604593, or mute the thread https://github.com/notifications/unsubscribe-auth/AeEHtZxmQXCrvuAEp48o8saeks6mYRCiks5seBzXgaJpZM4PJjcM .

[noob1313]

I was sending view email so it didn't take the attachments. Here they are.

[almindor]

OK this is a geth crash. I wonder about the WS disconnect too.

To explain:

In "thin client" mode any operation requiring your private keys or passwords (signing/unlocking etc.) is done using your local geth. Once a transaction is signed and ready to be broadcast it is sent out to the remote geth which has the chaindata downloaded and is in full sync.

In your case it seems two things happened:

1. Your local geth (the one from the /geth part of the logs) crashed. I don't see the beginning of the backtrace tho so it's hard to say on which operation exactly. My guess is on eth_signTransaction but it could've been an unlock too.

2. You also got disconnected from the remote geth after this error, maybe due to some invalid input. I checked the remote logs and don't see anything interesting there tho.

We'll need to get the full backtrace from your local geth so we can report this to the go-ethereum team.

If you're willing, I'll make an issue about getting full geth logs out of Etherwall and release a new version soon so we can do that.

[noob1313]

I am willing just let me know what I can do to help. In the mean time I will just use the other computer and leave the non working as is for further testing.

[notinreality]

I'm having this exact same issue - sending any amount causes an error and then WS disconnect. Unfortunately I don't have a backup PC to use. OS is Windows10 and I have attached app and geth logs gethlog.txt applog.txt

[almindor]

Hmm so on your local geth you got this error:

runtime: out of memory: cannot allocate 268435456-byte block (273678336 in use)
fatal error: out of memory

INFO [09-05|18:55:26] IPC endpoint opened: \\.\pipe\geth.ipc

Looking over go-ethereum's github issues I found https://github.com/ethereum/go-ethereum/issues/14986 still open. I think you just hit this bug :(

You can try and copy an older version of geth (try 1.6.6) from geth downloads Just override geth.exe in your Etherwall folder, you should see the geth version in titlebar after you run Etherwall when done.

See if you get it with geth 1.6.6 too. I'm afraid I can't help more here as it's a geth bug. The only other oddity here is that when that OOM crash happens it seem the TX tries to be sent out via the remote geth instance but fails.

I suspect a bad value got returned by the failing local geth and the remote node just rejects it.

[notinreality]

Yes I noticed the memory error. I have tried both 1.6.6 and 1.6.7 and unfortunately the error still persists. I am going to try doing a full blockchain sync from scratch and seeing if that makes a difference. Thanks for your reply

[almindor]

Wait, I thought you were using the thin client? Are you switching to full-node mode?

[notinreality]

Yes I was using the thin mode but i was going to try full-node mode.

[almindor]

OK if so then make sure you have at least 50GB free space in your selected data directory and that you re-sync from scratch. Otherwise pruning doesn't work and it'll take longer and be bigger.

[notinreality]

Update - I changed the path of my Geth directory to a different hard drive and tried running the 'thin client' version again. Transactions are now working.

[almindor]

Interesting, can you maybe report this to the original geth bugrep I mentioned? Just say you had a similar OOM problem but it got fixed by changing the datadir.

[almindor]

Closing as it seems to be a geth bug.

[petershine88]

I get the same problem and cannot send ETH after downloading the new version 2.1.1 Geth Log.txt

Application Log.txt

Please help to check and advise what is the problem and how to fix it.

Thanks

Peter

[UGatgithub]

As almindor writes above this seems to be this https://github.com/ethereum/go-ethereum/issues/14986 geth bug and you can try with an older geth version or thin client mode (read above).

[almindor]

I'm afraid @UGatgithub is right, there's not much I can do here. You can try an older geth version (just download from the geth downloads page and point etherwall to it).

For some reason changing the datadir helped @UGatgithub's case so maybe you can try doing that, but you need to copy your keystore folder.

If more people post on the original go ethereum issue page this might get fixed sooner by the ethdev team.

[almindor]

As a side note: I'm going to release 2.1.2 with geth 1.7.3 soon, but you can also try updating geth to 1.7.3 and see if maybe it changes anything. Same process, download geth, place somewhere you know and then change the path in etherwall's settings.

NOTE: if you do this and later update etherwall you'll keep using this geth until you point Etherwall back to the one in it's folder.