Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

32-bit Parity crashes with: out of memory #4439

Closed
brenzi opened this issue Feb 5, 2017 · 11 comments
Closed

32-bit Parity crashes with: out of memory #4439

brenzi opened this issue Feb 5, 2017 · 11 comments
Labels
F2-bug 🐞 The client fails to follow expected behavior. M4-core ⛓ Core client code / Rust.

Comments

@brenzi
Copy link

brenzi commented Feb 5, 2017

I'm running
Parity/v1.6.0-unstable-b2ecf1c-20170131/x86-linux-gnu/rustc1.14.0

And I can't sync (from scratch) the chain, neither with --warp nor without it.

2017-02-05 17:53:55  IO Worker #2 INFO import  Syncing snapshot 36/74   #2422716    0/21/25 peers      2 GiB db    4 MiB chain  0 bytes queue    9 KiB sync
2017-02-05 17:53:56  IO Worker #2 TRACE sync  == Connected 51: Gsoil_MMF_TN/v1.4.1-430cc246/linux/go1.6.3
2017-02-05 17:53:56  IO Worker #2 TRACE sync  Sending status to 51, protocol version 63
2017-02-05 17:53:56  IO Worker #1 TRACE sync  New peer 51 (protocol: 63, network: 42, difficulty: Some(155108701485), latest:a617…34d6, genesis:e138…9359, snapshot:None)
2017-02-05 17:53:56  IO Worker #1 TRACE sync  Peer 51 genesis hash mismatch (ours: d4e5…8fa3, theirs: e138…9359)
2017-02-05 17:53:56  IO Worker #3 TRACE sync  == Disconnecting 51: Gsoil_MMF_TN/v1.4.1-430cc246/linux/go1.6.3
2017-02-05 17:53:56  IO Worker #3 TRACE sync  56 Ignoring transactions while syncing
2017-02-05 17:53:56  IO Worker #3 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:56  IO Worker #2 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:56  IO Worker #1 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:56  IO Worker #0 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:56  IO Worker #1 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:56  IO Worker #1 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:56  IO Worker #3 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:56  IO Worker #3 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:56  IO Worker #0 TRACE sync  == Connected 72: Geth/v1.4.13-stable/linux/go1.5.1
2017-02-05 17:53:56  IO Worker #0 TRACE sync  Sending status to 72, protocol version 63
2017-02-05 17:53:57  IO Worker #1 TRACE sync  59 -> GetBlockHeaders (number: 3087002, max: 192, skip: 0, reverse:false)
2017-02-05 17:53:57  IO Worker #1 TRACE sync  59 -> GetBlockHeaders: returned 0 entries
2017-02-05 17:53:57  IO Worker #1 TRACE sync  59 -> GetNodeData: 2 entries
2017-02-05 17:53:57  IO Worker #0 TRACE sync  New peer 72 (protocol: 63, network: 1, difficulty: Some(264331105670), latest:fe4f…ac30, genesis:7fed…1e7a, snapshot:None)
2017-02-05 17:53:57  IO Worker #0 TRACE sync  Peer 72 genesis hash mismatch (ours: d4e5…8fa3, theirs: 7fed…1e7a)
2017-02-05 17:53:57  IO Worker #0 TRACE sync  == Disconnecting 72: Geth/v1.4.13-stable/linux/go1.5.1
2017-02-05 17:53:57  IO Worker #3 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:57  IO Worker #1 TRACE sync  59 -> GetNodeData: return 0 entries
2017-02-05 17:53:57  IO Worker #2 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:57  IO Worker #1 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:57  IO Worker #0 TRACE sync  4 Ignoring transactions while syncing
2017-02-05 17:53:57  IO Worker #1 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:57  IO Worker #3 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:57  IO Worker #1 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:57  IO Worker #0 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:57  IO Worker #3 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:57  IO Worker #2 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:57  IO Worker #1 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:57  IO Worker #0 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:57  IO Worker #3 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:57  IO Worker #2 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:57  IO Worker #0 TRACE sync  83 -> GetBlockHeaders (number: 1295772, max: 192, skip: 0, reverse:false)
2017-02-05 17:53:58  IO Worker #3 TRACE sync  83 -> GetReceipts: 7 entries
2017-02-05 17:53:58  IO Worker #1 TRACE sync  47 -> GetBlockBodies: returned 0 entries
2017-02-05 17:53:58  IO Worker #1 TRACE sync  == Connected 58: Geth/v1.5.1-stable-dc197cb9/linux/go1.7.3
2017-02-05 17:53:58  IO Worker #1 TRACE sync  Sending status to 58, protocol version 63
2017-02-05 17:53:58  IO Worker #1 TRACE sync  New peer 58 (protocol: 63, network: 5566, difficulty: Some(351819442811), latest:99d2…0cbf, genesis:a5eb…18f4, snapshot:None)
2017-02-05 17:53:58  IO Worker #1 TRACE sync  Peer 58 genesis hash mismatch (ours: d4e5…8fa3, theirs: a5eb…18f4)
2017-02-05 17:53:58  IO Worker #1 TRACE sync  == Disconnecting 58: Geth/v1.5.1-stable-dc197cb9/linux/go1.7.3
2017-02-05 17:53:58  IO Worker #3 TRACE sync  83 -> GetNodeData: 2 entries
2017-02-05 17:53:58  IO Worker #1 TRACE sync  67 Ignoring transactions while syncing
2017-02-05 17:53:58  IO Worker #3 TRACE sync  83 -> GetNodeData: return 0 entries
2017-02-05 17:53:58  IO Worker #3 TRACE sync  == Connected 6: Geth/v1.5.4-stable-b70acf3c/linux/go1.7.3
2017-02-05 17:53:58  IO Worker #3 TRACE sync  Sending status to 6, protocol version 63
2017-02-05 17:53:58  IO Worker #1 TRACE sync  New peer 6 (protocol: 63, network: 1, difficulty: Some(174207339022641639), latest:a8c3…d63a, genesis:d4e5…8fa3, snapshot:None)
2017-02-05 17:53:58  IO Worker #1 DEBUG sync  Connected 6:Geth/v1.5.4-stable-b70acf3c/linux/go1.7.3
2017-02-05 17:53:58  IO Worker #1 TRACE sync  6 <- GetForkHeader: at 1920000
2017-02-05 17:53:58  IO Worker #2 TRACE sync  83 -> GetBlockBodies: returned 12 entries
2017-02-05 17:53:59  IO Worker #1 TRACE sync  6 -> GetBlockHeaders (number: 1920000, max: 1, skip: 0, reverse:false)
2017-02-05 17:53:59  IO Worker #1 TRACE sync  6: Returning cached fork header
2017-02-05 17:53:59  IO Worker #1 TRACE sync  6 -> GetBlockHeaders: returned 1 entries
2017-02-05 17:53:59  IO Worker #1 TRACE sync  6 -> GetBlockHeaders (number: 104894, max: 192, skip: 0, reverse:false)
2017-02-05 17:53:59  IO Worker #2 TRACE sync  == Disconnecting 83: Geth/v1.5.8-stable-f58fb322/windows/go1.7.4
2017-02-05 17:53:59  IO Worker #2 DEBUG sync  Disconnected 83
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Syncing with peers: 21 active, 19 confirmed, 21 total
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Waiting for the snapshot restoration
2017-02-05 17:53:59  IO Worker #2 TRACE sync  == Connected 69: Geth/Spain/v1.5.8-unstable-d63752ef/linux/go1.7.3
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Sending status to 69, protocol version 63
2017-02-05 17:53:59  IO Worker #2 TRACE sync  == Connected 45: Parity/v1.4.9-beta-48924e9-20170109/x86_64-linux-gnu/rustc1.14.0
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Sending status to 45, protocol version 1
2017-02-05 17:53:59  IO Worker #3 TRACE sync  New peer 69 (protocol: 63, network: 23723, difficulty: Some(127979750341), latest:eb20…5259, genesis:8d72…cdfa, snapshot:None)
2017-02-05 17:53:59  IO Worker #3 TRACE sync  Peer 69 genesis hash mismatch (ours: d4e5…8fa3, theirs: 8d72…cdfa)
2017-02-05 17:53:59  IO Worker #3 TRACE sync  == Disconnecting 69: Geth/Spain/v1.5.8-unstable-d63752ef/linux/go1.7.3
2017-02-05 17:53:59  IO Worker #2 TRACE sync  6: Chain is too short to confirm the block
2017-02-05 17:53:59  IO Worker #2 TRACE sync  Skipping busy peer 6
2017-02-05 17:53:59  IO Worker #2 TRACE sync  == Disconnecting 45: Parity/v1.4.9-beta-48924e9-20170109/x86_64-linux-gnu/rustc1.14.0
2017-02-05 17:53:59  IO Worker #3 TRACE sync  6 -> GetBlockBodies: returned 2 entries
fatal runtime error: out of memory
Illegal instruction (core dumped)
@arkpar
Copy link
Collaborator

arkpar commented Feb 5, 2017

How much free memory does your machine have? What's the output of free -m?

@gavofyork gavofyork added the Z1-question 🙋‍♀️ Issue is a question. Closer should answer. label Feb 5, 2017
@brenzi
Copy link
Author

brenzi commented Feb 6, 2017 

              total        used        free      shared  buff/cache   available
Mem:           7891        1816        4448         145        1625        5661
Swap:          1926           0        1926

@tomusdrw
Copy link
Collaborator

tomusdrw commented Feb 6, 2017

@brenzi You have 8GB of ram, but you run 32-bit system, it means that at most 3.5GB can be utilized by the system. I would recommend upgrading to 64-bits.

@brenzi
Copy link
Author

brenzi commented Feb 6, 2017 •
edited
Loading

I'm running a 64bit system, but cargo seems to have decided to build parity with 32bit (what caused some dependency trouble when building. I just installed the 32bit packages along the 64bit ones and build worked.

Linux blackbox 4.4.0-59-lowlatency #80-Ubuntu SMP PREEMPT Fri Jan 6 21:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

I guess this could be the root of the issue? Then my question is, why
cargo install --git https://github.com/ethcore/parity.git parity
decides to build in 32bit.

This didn't happen with my last build. I'm sure I had a 64bit binary last time

@arkpar
Copy link
Collaborator

arkpar commented Feb 6, 2017

If you are using rustup make sure it has correct platform set as default with rustup default x86_64-unknown-linux-gnu iirc

@brenzi
Copy link
Author

brenzi commented Feb 6, 2017

ah, got it, thanks. It seems the 32bit setup has somehow survived the upgrade to the new 64bit ubuntu because it sits in my home folder which I kept. Yet it's strange that my last build was 64bit. Anyhow, I'm building now and hoping the issue will be fixed.

thanks for your quick support.

@rphmeier rphmeier reopened this Feb 10, 2017
@rphmeier
Copy link
Contributor

@brenzi Assuming everything worked?

@arkpar arkpar changed the title parity crashes with: out of memory 32-bit Parity crashes with: out of memory Feb 10, 2017
@arkpar
Copy link
Collaborator

arkpar commented Feb 10, 2017

We still need to make sure memory usage is under 1GB with default settings.

@arkpar arkpar added F2-bug 🐞 The client fails to follow expected behavior. and removed Z1-question 🙋‍♀️ Issue is a question. Closer should answer. labels Feb 10, 2017
@rphmeier rphmeier added the M4-core ⛓ Core client code / Rust. label Feb 10, 2017
@brenzi
Copy link
Author

brenzi commented Feb 10, 2017

it works for me now (with 64bit build)

@5chdn
Copy link
Contributor

5chdn commented May 9, 2017

This issue is labelled with bug: The client fails to follow expected behavior; and is inactive for several months. It's neither assigned nor linked to a milestone.

Please, decide on a deadline and assign this ticket to a developer within 7 days or close it if fixed otherwise.

This was referenced May 9, 2017
Closed
Closed
@arkpar
Copy link
Collaborator

arkpar commented May 10, 2017

Resolved with #5526

@arkpar arkpar closed this as completed May 10, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
F2-bug 🐞 The client fails to follow expected behavior. M4-core ⛓ Core client code / Rust.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@gavofyork @tomusdrw @arkpar @rphmeier @brenzi @5chdn