OOM geth crash - sync stops at 2% and Ether no showing

[tamtamtom]

System information

Version: `0.8.9`
OS & Version: windows 7
Node type: `eth/geth(default)` .1.5.9 (Go)

Downloaded the latest version. but I never saw my ether yet. It seems it is not syncornizig with my account.
see screenshots for configuration

Transaction succesfully done on:

• Check the console, of Mist (CTRL/CMD + ALT + i) and take a screenshot : I don't know what that mean.

sync seems to be stopped at 2% for ever, I let more than 24 hours and nothing.
I tried to remove the Chaindata folder and launch again Ethereum Wallet for fast sync, but it also stops at 2%.

Seems that there is a memory error in the log files from node but I don't know what to do with that.
node.log.zip

HOw to find my Ethers? Please help

Thanks

[markkeulen]

I would like to know the answer to. I seem to have the same problem. Endless waiting for sync, never getting further then 2%. Also have some ether that have been bought for this wallet.

[MaSansky99]

Same problem here. Progress seems stuck at 1% after 1 hour, but number of blocks is very slowly decreasing. All accounts show 0 ETH. Very disturbing. Why doesn't the program have a "fast update" or "reconnect" button of some sorts. Functionality is so minimal, you could call it negative

[f1tsh0]

Same problem here... Always stops at 1% or 2%...

[luclu]

@tamtamtom apparently your computer ran out of memory (OOM) and geth crashed as the logs indicate:

[...]
I0304 08:18:08.873515 eth/downloader/downloader.go:966] imported 384 state entries in   8.000ms: processed 138464, pending at least 132778
I0304 08:18:09.033524 eth/downloader/downloader.go:966] imported 384 state entries in  24.001ms: processed 138848, pending at least 132848
I0304 08:18:09.045525 eth/downloader/downloader.go:966] imported 384 state entries in  11.000ms: processed 139232, pending at least 132535
I0304 08:18:09.129530 core/blockchain.go:805] imported  488 receipts in 113.006ms. #91995 [85f1b9a0… / dad6e223…]
I0304 08:18:09.140530 core/headerchain.go:342] imported  768 headers in 346.019ms. #94080 [fe34b35f… / 490edcfd…]
runtime: out of memory: cannot allocate 268435456-byte block (771424256 in use)
fatal error: out of memory

runtime stack:
runtime.throw(0xd30bbb, 0xd)
	C:/go/src/runtime/panic.go:566 +0x7f
runtime.largeAlloc(0x10000000, 0x464101, 0x52b0ea00)
	C:/go/src/runtime/malloc.go:776 +0xb7
runtime.mallocgc.func1()
	C:/go/src/runtime/malloc.go:669 +0x31
runtime.systemstack(0x1f220a00)
	C:/go/src/runtime/asm_386.s:323 +0x5e
runtime.mstart()
	C:/go/src/runtime/proc.go:1079
[...]

Though Mist should be able to handle backend error like this more graciously and/or give better user feedback.

[MattMensa]

I'm having the same problem using the official wallet software for Windows from https://www.ethereum.org/ (Win32, v0.8.9)
running on Windows 8.1 64bit.

I'm stuck at 2%. Deleting the chaindata-folder did not help. It starts and works ok-fast until 2%, then stops.
Is this a current issue across several platforms?

nodelog.zip

[frozeman]

To calm you down, in the worst case you can always import you private key files to https://www.myetherwallet.com, if you need to access you funds.

Though the syncing issue in the latest versions seems problematic.

Please try deactivating your firewall, if this doesn't help, download a previous version of geth like https://github.com/ethereum/go-ethereum/releases/tag/v1.5.0
Run it from within the cmd.exe and then start mist afterwards

EDITED BY @obscuren: Do NOT do this. 1.5.0 does not contain hard forked code.

[karalabe]

How much memory does your machine have? Are you running 32bit or 64bit version? How much cache does Mist set by default?

[karalabe]

@frozeman Looking at the Mist code

mist/modules/ethereumNode.js

Line 362 in 59b918f

? ['--fast', '--cache', '1024']

, you start Geth with a database cache allowance of 1024MB. If a machine doesn't have 2GB RAM at least, it will go OOM. Also if you run this on a 32bit machine, it will go OOM as it will exceed the 32bit address space.

[frozeman]

@tamtamtom @MattMensa please run geth.exe separate and see if it synced, then

[tamtamtom]

my machine is windows 7 64bits with 6GB RAM.
@frozeman : what do you mean by "run geth.exe separate"??

[frozeman]

Download it here and run it before you start mist https://github.com/ethereum/go-ethereum/releases/tag/v1.5.0 https://github.com/ethereum/go-ethereum/releases (edited, as @karalabe pointed out)

[MattMensa]

@frozeman Thank you very much for your fast an detailed reply.

How much memory does your machine have? Are you running 32bit or 64bit version? How much cache does Mist set by default?

16 GB RAM
Windows 8.1 64bit but running the 32bit version of the wallet. Should I use the 64 bit version?

please run geth.exe separate and see if it synced, then

..then what? :-)
I'm running now the geth.exe from the Ethereum Appdata-Folder.
What information should I supply here when geth.exe is running? I see that it regularly adds new imported blocks.. There is no progress bar though.

[karalabe]

Please run the 64bit version of the wallet, yes.

[karalabe]

And please stick to the latest Geth release, the one recommended by @frozeman doesn't contain the latest fork logic, so it's not compatible with mainnet.

[frozeman]

Yes run the 64 bit version. When you see that it adds new block it synced, but you might want to delete the "chaindata" (only!) from the AppData/Ethereum folder and start geth.exe again, then let it sync through.
You can see the blocknumber in the logged lined on the right, or start mist after to see the progress bar.

[karalabe]

If you run geth on it's own, please specify --fast --cache=512 as cli flags too

[MattMensa]

First try:
I deleted the chaindata folder
I run the 64 bit version -> It starts syncing but stops pretty fast, now at 0%

Second try:
Deleted the chaindata folder again
Made a shortcut to the geth.exe. Added the cli flags (fast, cache=512)
Started geth -> worked for about 10 minutes and created a chaindata folder with the size of around 1.2GB. Then the geth window suddenly closed itself
Started now the 64 bit version again (no deleting of chaindata folder) -> is now stuck @ 2,550,88 blocks left (0%) with 2 peers (not updating)

I did not change to the geth version recommended by @frozeman

Edit: I imported my JSON-File to https://www.myetherwallet.com/
At least I have access now 👍
Thank you for the hint @frozeman

[frozeman]

Can you please start "cmd.exe" first from your windows, then navigate to the geth.exe using cd my path/to/geth/

Then post the logs when the node crashes, otherwise we can't tell whats the issue.

[MattMensa]

Then post the logs when the node crashes, otherwise we can't tell whats the issue.

Could you please specify which log-files you need for the crashing geth.exe and where they are likely to be stored?
I added a zip-file of the C:\Users\user\AppData\Roaming\Ethereum\geth\nodes folder content which includes a log-file with a final time stamp matching to when the windows closed itself.
nodes.zip

[frozeman]

No thats not it, the log will be shown in you command prompt when you start the node from within cmd.exe

[MattMensa]

Ok, now I understand. Thank you.

Here you are:
Geth log.txt

[frozeman]

Hm, sadly this is not showing the initial error its only the rest of the log. I suggest restarting your computer as most likely you still have a geth instance running

Please try to copy the whole log.

[frozeman]

@karalabe it crashes, but the log is so short that we can't see the error :(

[karalabe]

I'll try to boot a windows machine tomorrow morning and check.

…

On Mar 9, 2017 21:04, "Fabian Vogelsteller" ***@***.***> wrote: @karalabe <https://github.com/karalabe> it crashes, but the log is so short that we can't see the error :( — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1701 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH6GdWN_hkUvRygfdzIoM00_Xe8uJrsks5rkE1DgaJpZM4MTBA5> .

[MattMensa]

Geth log 2.txt

@frozeman
Restart did not help. Same issue with geth.
Is there a way to log the whole event in cmd.exe to provide more information?

[luclu]

A PR is available that should hopefully fix this issue: #1750

[MattMensa]

Any fix or workaround known yet? :-(

[karalabe]

Upgrade to Geth 1.6.0 and if it still fails please send us the output of 'geth version'.

[MattMensa]

Thank you. 1.6.0 fixed it for me

[senarvi]

I'm experiencing this issue after upgrading to 0.8.10 on 64-bit Windows 10. At first Ethereum Wallet crashed while updating the blockchain. I tried rebooting the computer. Now it crashes immediately when I start it at this point (if I got it right):

https://github.com/ethereum/go-ethereum/blob/9184249b393e4e332ae6a2f5d774880a88a9bfd6/ethdb/database.go#L72

and writes this to log:

INFO [05-10|13:16:39] Starting peer-to-peer node               instance=Geth/v1.6.0-stable-facc47cb/windows-386/go1.8.1
INFO [05-10|13:16:39] Allocated cache and file handles         
database=C:\\Users\\user\\AppData\\Roaming\\Ethereum\\geth\\chaindata cache=1024 handles=1024
runtime: out of memory: cannot allocate 268435456-byte block (275775488 in use)
fatal error: out of memory

I have plenty of free memory.

[karalabe]

Run 64 bit version of geth and not the 32 bit version then.

[senarvi]

I used the installer and I think it downloaded both versions, so I assumed it can choose the correct one. I'll try to manually install the 64-bit version then.

[luclu]

@senarvi I tried to replicate the issue but failed.
In my test on Win7 32bit / 64bit:

• Mist will download the correct geth version on win32 and win64
• Mist will launch geth with the correct —cache size of 512/1024 MB

This behaviour is expected with the current code on master.

Could you please open the folder %LOCALAPPDATA%\Mist\binaries\Geth\unpacked and check if all binaries are amd64 ones?

[senarvi]

@luclu I'm using Ethereum-Wallet-installer, not Mist-installer. Using task manager I found out that it launches a 32-bit geth.exe binary from %APPDATA%\Ethereum Wallet\binaries\Geth\unpacked. Ethereum Wallet binary is 64-bit. So maybe a wrong geth binary is packaged with Ethereum Wallet installer?

[luclu]

I still can't reproduce the geth 32bit download with the Ethereum-Wallet-installer-0-8-10.exe on Windows 7 x64.

Here is the content of my %APPDATA%\Ethereum Wallet\binaries\Geth\unpacked folder,
the geth.exe is in turn copied over from the geth-windows-amd64-1.6.0-facc47cb folder:

The taskmanager reports the correct x64 versions of the binaries:

Could it be that the installer did install the 32bit version of Ethereum Wallet?

[senarvi]

No, I had x64 version of Ethereum Wallet.exe (I checked with task manager). Now that I manually replaced geth with x64 version, it's working fine. I don't know what went wrong originally in the installation.

[luclu]

As a hopefully final check could you please remove the unpacked folder, start Ethereum Wallet and check if this will download the x64 version of geth?

[senarvi]

This did download the x64 version. Very strange.

[luclu]

That is good news!
Though, please let me know if this anomaly happens again to you, I'm very happy to assist and investigate to solve it.

[ordinaryCoder]

I m not able to run it on Raspbi Pi3 my geth version

Geth
Version: 1.6.5-stable
Git Commit: cf87713dd42162861b7ed227f79f0638a33571df
Architecture: arm
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.8.3
Operating System: linux
GOPATH=
GOROOT=/usr/local/go

And I get this error whenever I run the miner

> `statINFO [07-07|12:28:54] Generating ethash verification cache epoch=0 percentage=12 elapsed=21.488s
INFO [07-07|12:28:57] Generating ethash verification cache epoch=0 percentage=17 elapsed=24.648s
INFO [07-07|12:29:00] Generating ethash verification cache epoch=0 percentage=25 elapsed=27.649s
INFO [07-07|12:29:03] Generating ethash verification cache epoch=0 percentage=34 elapsed=30.650s
INFO [07-07|12:29:06] Generating ethash verification cache epoch=0 percentage=42 elapsed=33.650s
INFO [07-07|12:29:09] Generating ethash verification cache epoch=0 percentage=48 elapsed=36.651s
INFO [07-07|12:29:12] Generating ethash verification cache epoch=0 percentage=57 elapsed=39.652s
INFO [07-07|12:29:15] Generating ethash verification cache epoch=0 percentage=64 elapsed=42.653s
INFO [07-07|12:29:18] Generating ethash verification cache epoch=0 percentage=72 elapsed=45.653s
INFO [07-07|12:29:21] Generating ethash verification cache epoch=0 percentage=79 elapsed=48.654s
INFO [07-07|12:29:24] Generating ethash verification cache epoch=0 percentage=89 elapsed=51.655s
INFO [07-07|12:29:27] Generating ethash verification cache epoch=0 percentage=94 elapsed=54.665s
INFO [07-07|12:29:29] Generated ethash verification cache epoch=0 elapsed=56.715s
ERROR[07-07|12:29:29] Failed to generate mapped ethash dataset epoch=0 err="cannot allocate memory"
runtime: out of memory: cannot allocate 2147483648-byte block (127926272 in use)
fatal error: out of memory

runtime stack:
runtime.throw(0x8a49e6, 0xd)
/home/travis/.gimme/versions/go1.8.3.linux.amd64/src/runtime/panic.go:596 +0x70
runtime.largeAlloc(0x7ffff100, 0xeebc01, 0x75432758)
/home/travis/.gimme/versions/go1.8.3.linux.amd64/src/runtime/malloc.go:809 +0xe0
runtime.mallocgc.func1()
/home/travis/.gimme/versions/go1.8.3.linux.amd64/src/runtime/malloc.go:702 +0x30
runtime.systemstack(0x1121a000)
/home/travis/.gimme/versions/go1.8.3.linux.amd64/src/runtime/asm_arm.s:264 +0x80
runtime.mstart()
/home/travis/.gimme/versions/go1.8.3.linux.amd64/src/runtime/proc.go:1132

goroutine 76 [running]:
runtime.systemstack_switch()
/home/travis/.gimme/versions/go1.8.3.linux.amd64/src/runtime/asm_arm.s:209 +0x4 fp=0x18755a3c sp=0x18755a38
runtime.mallocgc(0x7ffff100, 0x7c5408, 0x1, 0x4)
/home/travis/.gimme/versions/go1.8.3.linux.amd64/src/runtime/malloc.go:703 +0x9dc fp=0x18755a94 sp=0x18755a3c
runtime.makeslice(0x7c5408, 0x1ffffc40, 0x1ffffc40, 0x112771d0, 0x8e4ad6, 0x28)
/home/travis/.gimme/versions/go1.8.3.linux.amd64/src/runtime/slice.go:54 +0x68 fp=0x18755ab8 sp=0x18755a94
runtime.makeslice64(0x7c5408, 0x1ffffc40, 0x0, 0x1ffffc40, 0x0, 0x2, 0x0, 0x0)
/home/travis/.gimme/versions/go1.8.3.linux.amd64/src/runtime/slice.go:69 +0x44 fp=0x18755ae4 sp=0x18755ab8
github.com/ethereum/go-ethereum/consensus/ethash.(*dataset).generate.func1()
/home/travis/gopath/src/github.com/ethereum/go-ethereum/consensus/ethash/ethash.go:285 +0x6d0 fp=0x18755c7c sp=0x18755ae4
sync.(*Once).Do(0x11374994, 0x11224ca0)
/home/travis/.gimme/versions/go1.8.3.linux.amd64/src/sync/once.go:44 +0xb8 fp=0x18755c94 sp=0x18755c7c
github.com/ethereum/go-ethereum/consensus/ethash.(*dataset).generate(0x11374960, 0x113fa7f0, 0x10, 0x2, 0x0)
/home/travis/gopath/src/github.com/ethereum/go-ethereum/consensus/ethash/ethash.go:294 +0x64 fp=0x18755cb8 sp=0x18755c94
github.com/ethereum/go-ethereum/consensus/ethash.(*Ethash).dataset(0x11270380, 0x1, 0x0, 0x11224f40, 0x7f323fe0, 0x72e7364)
/home/travis/gopath/src/github.com/ethereum/go-ethereum/consensus/ethash/ethash.go:539 +0x614 fp=0x18755dc0 sp=0x18755cb8
github.com/ethereum/go-ethereum/consensus/ethash.(*Ethash).mine(0x11270380, 0x11374870, 0x3, 0x6694e141, 0x354c04f1, 0x112b5c80, 0x112b5cc0)
/home/travis/gopath/src/github.com/ethereum/go-ethereum/consensus/ethash/sealer.go:105 +0xd4 fp=0x18755fac sp=0x18755dc0
github.com/ethereum/go-ethereum/consensus/ethash.(*Ethash).Seal.func1(0x11276d40, 0x11270380, 0x11374870, 0x112b5c80, 0x112b5cc0, 0x3, 0x6694e141, 0x354c04f1)
/home/travis/gopath/src/github.com/ethereum/go-ethereum/consensus/ethash/sealer.go:72 +0x70 fp=0x18755fcc sp=0x18755fac
runtime.goexit()
/home/travis/.gimme/versions/go1.8.3.linux.amd64/src/runtime/asm_arm.s:1017 +0x4 fp=0x18755fcc sp=0x18755fcc
created by github.com/ethereum/go-ethereum/consensus/ethash.(*Ethash).Seal
/home/travis/gopath/src/github.com/ethereum/go-ethereum/consensus/ethash/sealer.go:73 +0x170

goroutine 1 [select]:
github.com/ethereum/go-ethereum/console.(*Console).Interactive(0x1154c3c0)
/home/travis/gopath/src/github.com/ethereum/go-ethereum/console/console.go:321 +0x6f4
main.localConsole(0x113bc320, 0x0, 0x0)
/home/travis/gopath/src/github.com/ethereum/go-ethereum/cmd/geth/consolecmd.go:106 +0x290
github.com/ethereum/go-ethereum/cmd/utils.MigrateFlags.func1(0x113bc320, 0x0, 0x113bc320)
/home/travis/gopath/src/github.com/ethereum/go-ethereum/cmd/utils/flags.go:1103 +0xec
github.com/ethereum/go-ethereum/vendor/gopkg.in/urfave/cli%2ev1.HandleAction(0x7b3a78, 0x1135b0f0, 0x113bc320, 0x11403200, 0x0)
/home/travis/gopath/src/github.com/ethereum/go-ethereum/vendor/gopkg.in/urfave/cli.v1/app.go:485 +0xa8
github.com/ethereum/go-ethereum/vendor/gopkg.in/urfave/cli%2ev1.Command.Run(0x8997a5, 0x7, 0x0, 0x0, 0x0, 0x0, 0x0, 0x8e8837, 0x2b, 0x0, ...)
/home/travis/gopath/src/github.com/ethereum/go-ethereum/vendor/gopkg.in/urfave/cli.v1/command.go:193 +0x7e0
github.com/ethereum/go-ethereum/vendor/gopkg.in/urfave/cli%2ev1.(*App).Run(0x11390c30, 0x11278000, 0xb, 0xc, 0x0, 0x0)
/home/travis/gopath/src/github.com/ethereum/go-ethereum/vendor/gopkg.in/urfave/cli.v1/app.go:250 +0x564
main.main()
/home/travis/gopath/src/github.com/ethereum/go-ethereum/cmd/geth/main.go:185 +0x44

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/home/travis/.gimme/versions/go1.8.3.linux.amd64/src/runtime/asm_arm.s:1017 +0x4

goroutine 20 [chan receive]:
github.com/ethereum/go-ethereum/vendor/github.com/rjeczalik/notify.(*nonrecursiveTree).dispatch(0x112b7300, 0x112b7280)
/home/travis/gopath/src/github.com/ethereum/go-ethereum/vendor/github.com/rjeczalik/notify/tree_nonrecursive.go:36 +0x38
created by github.com/ethereum/go-ethereum/vendor/github.com/rjeczalik/notify.newNonrecursiveTree
/home/travis/gopath/src/github.com/ethereum/go-ethereum/vendor/github.com/rjeczalik/notify/tree_nonrecursive.go:29 +0x158`

[lock]

This thread has been automatically locked because it has not had recent activity. Please open a new issue for related bugs and link to relevant comments in this thread.