Solana: CLI vote-update-commission is broken

[kwunyeung]

Problem

The CLI command solana vote-update-commission is broken in v1.2.10.

Full stack trace

thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 1', /rustc/4fb7144ed159f94491249e86d5bbd033b5d60550/src/libcore/slice/mod.rs:2842:10
stack backtrace:
   0:        0x10763c0af - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h43ad886765c40c91
   1:        0x10765d18e - core::fmt::write::he548ee6ce743d415
   2:        0x107634487 - std::io::Write::write_fmt::hf0a8cad0ca2251e3
   3:        0x10763e12a - std::panicking::default_hook::{{closure}}::h166f557a03fd111a
   4:        0x10763de6c - std::panicking::default_hook::h16057d891db6b023
   5:        0x10763e808 - std::panicking::rust_panic_with_hook::h2db5049a14746a6d
   6:        0x10763e3a2 - rust_begin_unwind
   7:        0x10765aeaf - core::panicking::panic_fmt::hd7d9261f4286def0
   8:        0x10765ae79 - core::panicking::panic_bounds_check::hbf3575b7c57682db
   9:        0x10716aea2 - solana_cli::vote::process_vote_update_commission::hf04e9c078f9261c5
  10:        0x10710b881 - solana_cli::cli::process_command::h28367b342cfaf711
  11:        0x1070d4fef - solana::main::h8edb2404df98ab2a
  12:        0x1070d1b16 - std::rt::lang_start::{{closure}}::h2d677802be5c4ba5
  13:        0x10763e268 - std::panicking::try::do_call::h7c88c220bfff6b21
  14:        0x107641e5b - __rust_maybe_catch_panic
  15:        0x10763ecda - std::rt::lang_start_internal::h94930f81f540a165
  16:        0x1070d6729 - main

Proposed Solution

[Reisen]

Problem is due to the fact that the final AUTHORIZED_KEYPAIR argument is not included in config.signers.

[mvines]

@t-nelson - can you please take a look at this along with the v1.1 backport of this command

[t-nelson]

@mvines Yep! Already on it

[t-nelson]

@kwunyeung @Reisen do either of you have an example command line? I've been unable to reproduce on master, 1.2.10 local debug build or 1.2.10 from the release tarball

[Reisen]

@t-nelson Sure thing, here's a real one where I try and change my commission to 8% (same as it already is):

Working Tree: 50970bc8f93c50dd5e3ec766835aefd471013fd8 (tag: v1.2.10, origin/v1.2)
Clean build:

$ RUST_BACKTRACE=1 ./target/release/solana vote-update-commission ~/.config/solana/vote.json 8 ~/.config/solana/id.json
thread 'main' panicked at 'index out of bounds: the len is 1 but the index is 1', cli/src/vote.rs:588:33
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1076
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1537
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
  11: rust_begin_unwind
             at src/libstd/panicking.rs:385
  12: core::panicking::panic_fmt
             at src/libcore/panicking.rs:86
  13: core::panicking::panic_bounds_check
             at src/libcore/panicking.rs:63
  14: solana_cli::vote::process_vote_update_commission
  15: solana_cli::cli::process_command
  16: solana::main
  17: std::rt::lang_start::{{closure}}
  18: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  19: std::panicking::try::do_call
             at src/libstd/panicking.rs:297
  20: std::panicking::try
             at src/libstd/panicking.rs:274
  21: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  22: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  23: main
  24: __libc_start_main
  25: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Let me see if I can debug what's happening on my system for you though.

[Reisen]

@t-nelson Ok not convinced the problem is in generate_unique_signers after all. It seems the key is in config.signers[0] for me, but the function expects it in config.signers[1]. I'm not sure what key you must have that I don't that allows it to work for you. 🤷‍♂️

[t-nelson]

Ah! Got it. I'm paying fees with whatever random default key is sitting in my config dir, not the validator ID. Since they're the same in your case, the duplicate is elided and there will only be one signer in the config.

Hard-coded indices get you every time :wink:

Thanks for digging in to this!

[t-nelson]

Turns out there were a couple more vote subcommands susceptible to the same issue. #11045 should take care of 'em. Thanks again for reporting!