Cosmos-sdk: Exporting empty state leads to a segmentation fault

[amrali]

Summary of Bug

This probably low priority, but at [email protected] running gaiad export right after gaiad init causes a segmentation fault trying to deference a garbage memory address.

$ gaiad export
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x461e21e]

goroutine 1 [running]:
github.com/cosmos/cosmos-sdk/baseapp.(*BaseApp).NewContext(0xc420a360c0, 0xc4200c5f01, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
    /Users/redacted/.virtualgo/gaia/src/github.com/cosmos/cosmos-sdk/baseapp/baseapp.go:200 +0x5e
github.com/cosmos/cosmos-sdk/cmd/gaia/app.(*GaiaApp).ExportAppStateAndValidators(0xc420b421e0, 0xc420c0c300, 0x4c8a640, 0xc42000e008, 0x0, 0x0, 0x0, 0x0, 0x0)
    /Users/redacted/.virtualgo/gaia/src/github.com/cosmos/cosmos-sdk/cmd/gaia/app/app.go:191 +0x6a
main.exportAppStateAndTMValidators(0x4c815c0, 0xc420c0c300, 0x4c8a640, 0xc42000e008, 0x0, 0x0, 0x0, 0x0, 0xc42049fa88, 0x469ebf7, ...)
    /Users/redacted/.virtualgo/gaia/src/github.com/cosmos/cosmos-sdk/cmd/gaia/cmd/gaiad/main.go:53 +0x86
github.com/cosmos/cosmos-sdk/server.ConstructAppExporter.func1(0x7ffeefbff2c5, 0x5, 0x4c815c0, 0xc420c0c300, 0x0, 0x0, 0x4618180, 0x49663c0, 0x0, 0x4ac36fe, ...)
    /Users/redacted/.virtualgo/gaia/src/github.com/cosmos/cosmos-sdk/server/constructors.go:82 +0x14c
github.com/cosmos/cosmos-sdk/server.ExportCmd.func1(0xc420b71d40, 0xc420aad280, 0x0, 0x2, 0x0, 0x0)
    /Users/redacted/.virtualgo/gaia/src/github.com/cosmos/cosmos-sdk/server/export.go:23 +0xf9
github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra.(*Command).execute(0xc420b71d40, 0xc420aad220, 0x2, 0x2, 0xc420b71d40, 0xc420aad220)
    /Users/redacted/.virtualgo/gaia/src/github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra/command.go:698 +0x46d
github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc420b70900, 0x499b240, 0xc42049fe01, 0xc420aad180)
    /Users/redacted/.virtualgo/gaia/src/github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra/command.go:783 +0x2e4
github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra.(*Command).Execute(0xc420b70900, 0xc420aad180, 0xc42049fed8)
    /Users/redacted/.virtualgo/gaia/src/github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra/command.go:736 +0x2b
github.com/cosmos/cosmos-sdk/vendor/github.com/tendermint/tendermint/libs/cli.Executor.Execute(0xc420b70900, 0x4c02548, 0x2, 0xc420b66840)
    /Users/redacted/.virtualgo/gaia/src/github.com/cosmos/cosmos-sdk/vendor/github.com/tendermint/tendermint/libs/cli/setup.go:89 +0x4e
main.main()
    /Users/redacted/.virtualgo/gaia/src/github.com/cosmos/cosmos-sdk/cmd/gaia/cmd/gaiad/main.go:38 +0x214

Steps to Reproduce

• gaiad init
• gaiad export

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[AdityaSripal]

I believe exporting any state with gaiad export will cause a panic on v0.23.0, though this has been fixed on develop

A quick fix is to add app.setCheckState(abci.Header{}) to baseapp's initFromStore method if you need to export state.

Solved in #1800

Edit: Misread. Currently can't export right after init.

[ValarDragon]

I think you needed a state transition, or else it errored currently on develop.

[alexanderbez]

Can we close this if fixed on develop?

[ValarDragon]

cc @jlandrews, I don't think this is fixed.

[jlandrews]

So I think the specific bug posted here has been fixed on develop but the fix wasn't merged into 0.23.0. I've just tested on develop though, and it looks like there is an error if you try to export right after an init. I get the following stack trace:

panic: Stored pool should not have been nil

goroutine 1 [running]:
github.com/cosmos/cosmos-sdk/x/stake/keeper.Keeper.GetPool(0x10704a0, 0xc420aaef70, 0xc420116230, 0x10704a0, 0xc420aaef50, 0xff9928, 0xc420116230, 0x4, 0x10781a0, 0xc420a719b0, ...)
    /home/jlandrews/go/src/github.com/cosmos/cosmos-sdk/x/stake/keeper/keeper.go:84 +0x14c
github.com/cosmos/cosmos-sdk/x/stake.WriteGenesis(0x10781a0, 0xc420a719b0, 0xc4205874c0, 0x8, 0x10704a0, 0xc420aaef70, 0xc420116230, 0x10704a0, 0xc420aaef50, 0xff9928, ...)
    /home/jlandrews/go/src/github.com/cosmos/cosmos-sdk/x/stake/genesis.go:62 +0xab
github.com/cosmos/cosmos-sdk/cmd/gaia/app.(*GaiaApp).ExportAppStateAndValidators(0xc420a265a0, 0xc420b111a0, 0x1081d60, 0xc420b081a8, 0x0, 0x0, 0x0, 0x0, 0x0)
    /home/jlandrews/go/src/github.com/cosmos/cosmos-sdk/cmd/gaia/app/app.go:204 +0x1d1
main.exportAppStateAndTMValidators(0x1078d60, 0xc420b111a0, 0x1081d60, 0xc420b081a8, 0x0, 0x0, 0x0, 0x0, 0xc420797a88, 0xa9d987, ...)
    /home/jlandrews/go/src/github.com/cosmos/cosmos-sdk/cmd/gaia/cmd/gaiad/main.go:53 +0x86
github.com/cosmos/cosmos-sdk/server.ConstructAppExporter.func1(0xc4209bf160, 0x16, 0x1078d60, 0xc420b111a0, 0x0, 0x0, 0xa173a0, 0xd5ee80, 0x0, 0xebb08e, ...)
    /home/jlandrews/go/src/github.com/cosmos/cosmos-sdk/server/constructors.go:82 +0x14c
github.com/cosmos/cosmos-sdk/server.ExportCmd.func1(0xc420a6a900, 0x1804a80, 0x0, 0x0, 0x0, 0x0)
    /home/jlandrews/go/src/github.com/cosmos/cosmos-sdk/server/export.go:23 +0xf9
github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra.(*Command).execute(0xc420a6a900, 0x1804a80, 0x0, 0x0, 0xc420a6a900, 0x1804a80)
    /home/jlandrews/go/src/github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra/command.go:698 +0x46d
github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc4200d1440, 0xd937a0, 0xc420797e01, 0xc420a60300)
    /home/jlandrews/go/src/github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra/command.go:783 +0x2e4
github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra.(*Command).Execute(0xc4200d1440, 0xc420a60300, 0xc420797ed8)
    /home/jlandrews/go/src/github.com/cosmos/cosmos-sdk/vendor/github.com/spf13/cobra/command.go:736 +0x2b
github.com/cosmos/cosmos-sdk/vendor/github.com/tendermint/tendermint/libs/cli.Executor.Execute(0xc4200d1440, 0xff9f10, 0x2, 0xc4209bf160)
    /home/jlandrews/go/src/github.com/cosmos/cosmos-sdk/vendor/github.com/tendermint/tendermint/libs/cli/setup.go:89 +0x4e
main.main()
    /home/jlandrews/go/src/github.com/cosmos/cosmos-sdk/cmd/gaia/cmd/gaiad/main.go:38 +0x214

Which I expect is happening because gaiad export attempts to load from the db, and the db has not been initialized with actual state yet. Not sure if this should be considered a bug or not. I suppose expected behavior could be that it basically just outputs the genesis file again, but to me dumping non existent state seems like something that should throw an error. Perhaps the real problem is that gaiad init doesn't actually initialize the state, it just creates a genesis file. (and possibly priv_validator.json / config.toml if they are missing)

[ValarDragon]

Perhaps the real problem is that gaiad init doesn't actually initialize the state, it just creates a genesis file. (and possibly priv_validator.json / config.toml if they are missing)

Thats a good point. I'm not sure gaiad init should be initializing state however, since gaiad init --gen-tx is in the same command. Not sure what the answer to this is. If the answer is that we don't want to change gaiad init, then at the very least we should improve the error message of gaiad export to say something to the extent of "Error, state not initialized. Gaiad export can only be ran after a block has been created"

[AdityaSripal]

@ValarDragon don't think that's true technically. Should be able to run as soon as the chain starts (i.e. before the first block)

[amrali]

I agree with @ValarDragon, if it purposefully panics now then this issue becomes only a UX issue where a better error message (possibly without the unnecessary stack trace) would be a good solution.

[ValarDragon]

@ValarDragon don't think that's true technically. Should be able to run as soon as the chain starts (i.e. before the first block)

You're right, we can export before the first block, once we have a state. I guess we should change the message to "the chain must have started", or smth to that extent. Thanks for pointing that out.

Still not sure if gaiad init should initialize state as @jlandrews suggested. My primary concern is if you want to hand edit the genesis file after you create it via gaiad init, then you would have to call gaiad unsafe_reset_all which seems kinda weird, and will probably confuse more people in the future.

I'm not opposed to just special casing this situation. If there is no state, but the genesis file is created, return the current genesis file. (And display a warning as well) Its not like we're masking some bug with this special case (as not initializing state on gaiad init would be defined as intended behavior).

[jackzampolin]

I think we should go ahead and special case this situation. Agree with @ValarDragon and @amrali here.