almindor / etherwall

Ethereum QT5 Wallet
GNU General Public License v3.0
142 stars 59 forks source link

Etherwall bugs when running geth in light mode #86

Closed UGatgithub closed 5 years ago

UGatgithub commented 6 years ago

Hi almindor, here I reported some bugs when running Etherwall with geth in light mode. My experience is that Light mode works nowadays with Mist and Ethereum Wallet once it finds at least one peer which it does better the last weeks so my question:

Will you pick up on the following two bugs:

  1. Accounts do not show any ether in light mode
  2. Switching to Transactions view crashed Etherwall with a runtime error so users need to kill geth.exe manually via task manager.
almindor commented 6 years ago

Light mode is still considered experimental. The accounts not showing balance is most likely either the light client (geth) not being synced fully yet or bugged (e.g. a bad fork).

I'll check out the crash, I suspect it's related to geth giving some unexpected value in a reply when in light mode.

I'm not planning supporting light mode until it becomes more stable and synchronization is possible. There are also contract-related issues with light mode right now.

Will keep this issue opened until I confirm the tx tab crash.

almindor commented 6 years ago

I just ran geth in a separate terminal with geth --light and used Etherwall with it. Everything seems to work ok as long as you let it connect to peers first. My balances are ok and I could go in the transactions tab as well.

Which version of Geth did you try --light with? I'm using 1.8.1

UGatgithub commented 6 years ago

Etherwall with Geth 1..8.1. under Windows is completely synced (as I said, works with Mist and Ethereum Wallet) and also syncs when I start Etherwall with Additional Geth args: --syncmode light --verbosity 3 --cache 2560 --maxpeers 25 --identity NodeUG

When I select the Transactions tab, this happens image

image

UGatgithub commented 6 years ago

Did a test and can confirm it works when I launch geth --light in a separate PowerShell Window, so the issue only exists when using the Etherwall internal Additional Geth args setup possibility.

UGatgithub commented 6 years ago

When you update Etherwall, take care about the correct syntax (see here: https://gist.github.com/marcialwushu/693bcea078b27fa51daa02c1b94a7e37).

DEPRECATED OPTIONS: --fast Enable fast syncing through state downloads --light Enable light client mode

Sometimes the writing in Etherwall does not work as expected.

Example: --light should be --syncmode “light“ but in Etherwall it only works with --syncmode light

almindor commented 6 years ago

This is interesting since --light should equal --syncmode light.

Reopening. I'll try and reproduce the crash.

UGatgithub commented 6 years ago

Thanks for picking up and reopening, I think I closed it by accident.

UGatgithub commented 6 years ago

Yes, in Etherwall --light gets change automatically to --syncmode light but syncmode “light“ which is the way to enter in the command in Windows PowerShell gives an error and if used within Etherwall as Additional Geth argument.

almindor commented 6 years ago

Hmm can't seem to reproduce on linux. Can you send me your full app logs? It'll contain the geth commandline used so I can be sure i'm using the same combination of params (get the one with syncmode light when it crashes).

UGatgithub commented 6 years ago

I tried it but there is nothing further getting captured in the logs once the crash happens.

You mean this line?

....

Connected to IPC socket Connecting to IPC socket \.\pipe\geth.ipc Geth starting C:/Program Files/Geth/geth.exe --syncmode=light --verbosity 3 --cache 2560 --maxpeers 25 --identity NodeUG --datadir C:/Users/user/AppData/Roaming/Ethereum/ --nousb HTTP Post reply: {"success":true,"currencies":{"Response":"Success","Message":"Do not take life too seriously. You will never get out of it alive.","Data":[{"Symbol":"BTC","Price":0.08232,"Open24Hour":0.08451,"LastUpdateTS":1519757938,"Volume24Hours":456980.75,"Volume24HoursTo":38166.6758},{"Symbol":"USD","Price":873.72,"Open24Hour":863.57,"LastUpdateTS":1519757936,"Volume24Hours":237860.25,"Volume24HoursTo":208285300},{"Symbol":"CAD","Price":1108.38,"Open24Hour":1082.6,"LastUpdateTS":1519757864,"Volume24Hours":1025.23938,"Volume24HoursTo":1120725.25},{"Symbol":"EUR","Price":714.62,"Open24Hour":701.53,"LastUpdateTS":1519757931,"Volume24Hours":41072.19,"Volume24HoursTo":29275820},{"Symbol":"GBP","Price":609.9,"Open24Hour":597.74,"LastUpdateTS":1519757819,"Volume24Hours":699.511047,"Volume24HoursTo":439038.4}],"Type":100,"date":1519757941071}} HTTP Post reply: {"success":true,"result":"2.2.0"} Checking to see if there is an already running geth... Etherwall starting HTTP Post reply: {"success":true,"version":"2.2.0","endpoint":"wss://linde.etherwall.com","nodes":1} Connecting to main Etherwall server HTTP Post request: { }

HTTP Post request: { }

HTTP Post request: { "currencies": [ "BTC", "EUR", "CAD", "USD", "GBP" ], "version": 2 }

UGatgithub commented 5 years ago

This is an old thread but partly still valid. Meanwhile I tested again and can run geth in light mode via Etherwall and once it finds peers, it also syncs up to the actual block. Issues left: Accounts still show 0 balance as in screenshot above and Connection state always shows Connected with 0 peers which can't be correct as it syncs.

almindor commented 5 years ago

Well they improved then :) This should be considered a geth bug. All the values (account balance, syncing, peers) are taken directly from RPC calls to geth (if not using thin client). If you feel like it you can inspect them by turning on debug logging in the log tab and looking at the responses.

UGatgithub commented 5 years ago

No issue any longer, maybe it was some cache issue on my computers side. After a restart of the computer and Etherwall I get account data and peers count now, so finally it seems they have improved enough to be able to run in light mode connecting to a sufficient number of peers within a short period of time so I also close this one now.