Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Genesis import fails for large exports #9567

Closed
mhofman opened this issue Jun 22, 2024 · 0 comments · Fixed by #9549
Closed

Genesis import fails for large exports #9567

mhofman opened this issue Jun 22, 2024 · 0 comments · Fixed by #9549
Labels
agoric-cosmos bug Something isn't working

Comments

@mhofman
Copy link
Member

mhofman commented Jun 22, 2024

Describe the bug

Generating a new genesis through agd export results in a genesis.json that is too large to be imported. Besides the large amount of memory used, the cosmos sdk attempts to store the original genesis file as is in its golevelDB, which has a limit of 4GB per document.

To Reproduce

agd export on mainnet or devnet, followed by agd start using the new genesis

Expected behavior

While large genesis can result in a huge RAM consumption, it should at least be possible to import.

Platform Environment

upgrade-15 and master on mainnet or devnet

Screenshots

panic: snappy: decoded block is too large [recovered]
        panic: snappy: decoded block is too large [recovered]
        panic: snappy: decoded block is too large

goroutine 86 [running]:
github.com/syndtr/goleveldb/leveldb.(*DB).mCompaction.func1()
        /go/pkg/mod/github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7/leveldb/db_compaction.go:763 +0xc5
panic({0x7f9222a12620, 0xc0001edcc0})
        /usr/local/go/src/runtime/panic.go:884 +0x213
github.com/syndtr/goleveldb/leveldb.(*DB).compactionTransact.func1()
        /go/pkg/mod/github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7/leveldb/db_compaction.go:159 +0x9b
panic({0x7f9222a12620, 0xc0001edcc0})
        /usr/local/go/src/runtime/panic.go:884 +0x213
github.com/golang/snappy.Encode({0xc0011fe118?, 0x12?, 0x0?}, {0xc002b00000?, 0x7f922299a500?, 0x7f92203e270a?})
        /go/pkg/mod/github.com/golang/snappy@v0.0.4/encode.go:22 +0x2d1
github.com/syndtr/goleveldb/leveldb/table.(*Writer).writeBlock(0xc000f36000, 0xc000f36060, 0xc000f36060?)
        /go/pkg/mod/github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7/leveldb/table/writer.go:172 +0x139
github.com/syndtr/goleveldb/leveldb/table.(*Writer).finishBlock(0xc000f36000)
        /go/pkg/mod/github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7/leveldb/table/writer.go:223 +0x46
github.com/syndtr/goleveldb/leveldb/table.(*Writer).Append(0xc000f36000, {0x1c563030000, 0x12, 0x194fec000}, {0x1c563030012, 0x194feb506, 0x194febfee})
        /go/pkg/mod/github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7/leveldb/table/writer.go:256 +0x253
github.com/syndtr/goleveldb/leveldb.(*tWriter).append(0xc0005a4de0, {0x1c563030000, 0x12, 0x194fec000}, {0x1c563030012, 0x194feb506, 0x194febfee})
        /go/pkg/mod/github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7/leveldb/table.go:558 +0x1e5
github.com/syndtr/goleveldb/leveldb.(*tOps).createFrom(0x7f92203ebdd3?, {0x7f9222d9ed40, 0xc001274080})
        /go/pkg/mod/github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7/leveldb/table.go:397 +0x16d
github.com/syndtr/goleveldb/leveldb.(*session).flushMemdb(0xc000defa40, 0xc0011fa3c0, 0xc0001917a0, 0xc001663b10?)
        /go/pkg/mod/github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7/leveldb/session_compaction.go:35 +0x116
github.com/syndtr/goleveldb/leveldb.(*DB).memCompaction.func1(0xc0005a4401?)
        /go/pkg/mod/github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7/leveldb/db_compaction.go:305 +0xa5
github.com/syndtr/goleveldb/leveldb.(*compactionTransactFunc).run(0x0?, 0x0?)
        /go/pkg/mod/github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7/leveldb/db_compaction.go:242 +0x1f
github.com/syndtr/goleveldb/leveldb.(*DB).compactionTransact(0xc00066afc0, {0x7f9221dc1dbb, 0xb}, {0x7f9222d76f48, 0xc001650030})
        /go/pkg/mod/github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7/leveldb/db_compaction.go:186 +0x217
github.com/syndtr/goleveldb/leveldb.(*DB).compactionTransactFunc(...)
        /go/pkg/mod/github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7/leveldb/db_compaction.go:253
github.com/syndtr/goleveldb/leveldb.(*DB).memCompaction(0xc00066afc0)
        /go/pkg/mod/github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7/leveldb/db_compaction.go:303 +0x3e8
github.com/syndtr/goleveldb/leveldb.(*DB).mCompaction(0xc00066afc0)
        /go/pkg/mod/github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7/leveldb/db_compaction.go:777 +0x93
created by github.com/syndtr/goleveldb/leveldb.openDB
        /go/pkg/mod/github.com/syndtr/goleveldb@v1.0.1-0.20210819022825-2ae1ddf74ef7/leveldb/db.go:156 +0x5d8
@mhofman mhofman added bug Something isn't working agoric-cosmos labels Jun 22, 2024
@mergify mergify bot closed this as completed in #9549 Jun 25, 2024
mergify bot added a commit that referenced this issue Jun 25, 2024
Closes #9567

## Description
Stores the swing-store export data outside of the genesis file, and only include a hash of it in genesis for validation.

This is the bulk of the data in the genesis file (on mainnet 6GB vs 300MB for the rest), and it serves little purpose to keep it in there. Furthermore golevelDB chokes when cosmos attempts to store the genesis file inside the DB (limit of 4GB documents)

### Security Considerations
None, the data remains validated

### Scaling Considerations
Reduces memory usage on genesis export / import. Furthermore we avoid iterating over the data twice on import, which is painfully slow for IAVL.

### Documentation Considerations
None

### Testing Considerations
Added a3p acceptance test

Manually tested as follow:
```
cd packages/cosmic-swingset
make scenario2-setup
make scenario2-run-chain
# wait until there are blocks, then kill
mkdir t1/n0/export
agd --home t1/n0 export --export-dir t1/n0/export
agd --home t1/n0 tendermint unsafe-reset-all
mv t1/n0/export/* t1/n0/config
make scenario2-run-chain
# verify blocks are being produced after genesis restart
```

### Upgrade Considerations
There is a compatibility mode to load genesis files with export data embedded.
mhofman pushed a commit that referenced this issue Jun 25, 2024
Closes #9567

## Description
Stores the swing-store export data outside of the genesis file, and only include a hash of it in genesis for validation.

This is the bulk of the data in the genesis file (on mainnet 6GB vs 300MB for the rest), and it serves little purpose to keep it in there. Furthermore golevelDB chokes when cosmos attempts to store the genesis file inside the DB (limit of 4GB documents)

### Security Considerations
None, the data remains validated

### Scaling Considerations
Reduces memory usage on genesis export / import. Furthermore we avoid iterating over the data twice on import, which is painfully slow for IAVL.

### Documentation Considerations
None

### Testing Considerations
Added a3p acceptance test

Manually tested as follow:
```
cd packages/cosmic-swingset
make scenario2-setup
make scenario2-run-chain
# wait until there are blocks, then kill
mkdir t1/n0/export
agd --home t1/n0 export --export-dir t1/n0/export
agd --home t1/n0 tendermint unsafe-reset-all
mv t1/n0/export/* t1/n0/config
make scenario2-run-chain
# verify blocks are being produced after genesis restart
```

### Upgrade Considerations
There is a compatibility mode to load genesis files with export data embedded.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
agoric-cosmos bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant