grin: thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Chain(Error { inner:

Hello, On a Debian 9.6, downloaded grin v0.5.1, install ok, md5sum ok, just launching

grin --floonet

… and nothing happens. Not even a grin process running.

edit: the issue is still present with grin v0.5.2

grin-server.log

20190110 16:19:40.169 INFO grin_util::logger - log4rs is initialized, file level: Debug, stdout level: Warn, min. level: Debug
20190110 16:19:40.169 INFO grin - Using configuration file at /home/userz/.grin/floo/grin-server.toml
20190110 16:19:40.169 INFO grin - This is Grin version 0.5.1 (git v0.5.1), built for x86_64-unknown-linux-gnu by rustc 1.31.1 (b6c32da9b 2018-12-18).
20190110 16:19:40.169 DEBUG grin - Built with profile "release", features "".
20190110 16:19:40.169 WARN grin::cmd::server - Starting GRIN in UI mode...
20190110 16:19:40.169 INFO grin_servers::grin::server - Starting server, genesis block: edc758c1
20190110 16:19:40.202 DEBUG grin_chain::txhashset::txhashset - Error returned, discarding txhashset extension: Other Error: output vs rproof MMRs different sizes 
 Cause: Unknown 
 Backtrace: 
20190110 16:19:40.219 ERROR grin_util::logger - 
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Chain(Error { inner: 

Other Error: output vs rproof MMRs different sizes })': libcore/result.rs:1009stack backtrace:
   0:     0x55982a88665d - backtrace::backtrace::trace::hd74837959dc31a2c
   1:     0x55982a885872 - <backtrace::capture::Backtrace as core::default::Default>::default::hfbe03539066da14f
   2:     0x55982a8858e9 - backtrace::capture::Backtrace::new::hd9d47426559d8b68
   3:     0x55982a80f390 - grin_util::logger::send_panic_to_log::{{closure}}::h0919c24963251ad6
   4:     0x55982a9570e6 - std::panicking::rust_panic_with_hook::hde420d6fd4455550
                        at libstd/panicking.rs:480
   5:     0x55982a956c31 - std::panicking::continue_panic_fmt::h8f394f3c578bcc76
                        at libstd/panicking.rs:390
   6:     0x55982a956b15 - rust_begin_unwind
                        at libstd/panicking.rs:325
   7:     0x55982a9a0b8c - core::panicking::panic_fmt::hca5dc4e8b320bc56
                        at libcore/panicking.rs:77
   8:     0x55982a0dbf49 - core::result::unwrap_failed::h31e8096bf431f8db
   9:     0x55982a0947b0 - grin::cmd::server::start_server::hb8666c7b00b2e941
  10:     0x55982a0953c8 - grin::cmd::server::server_command::ha8bb4497bcf97bf1
  11:     0x55982a11fd26 - grin::real_main::hb39a0190d567a13c
  12:     0x55982a11e665 - grin::main::hab1e977be2785e7c
  13:     0x55982a0f00b2 - std::rt::lang_start::{{closure}}::h2873acc0c7532388
  14:     0x55982a956ab2 - std::rt::lang_start_internal::{{closure}}::hafa8ecdacd368ebb
                        at libstd/rt.rs:59
                         - std::panicking::try::do_call::h8c0dbb48abbdf4df
                        at libstd/panicking.rs:310
  15:     0x55982a969189 - __rust_maybe_catch_panic
                        at libpanic_unwind/lib.rs:102
  16:     0x55982a93830a - std::panicking::try::hbc21637ba5f64d73
                        at libstd/panicking.rs:289
                         - std::panic::catch_unwind::h954917b922b8d970
                        at libstd/panic.rs:392
                         - std::rt::lang_start_internal::h5b2de3cc38c3b406
                        at libstd/rt.rs:58
  17:     0x55982a120a74 - main
  18:     0x7fe95dd722e0 - __libc_start_main
  19:     0x55982a060f80 - <unknown>
  20:                0x0 - <unknown>

I would be happy to help with that. How could I diagnose more ? Thanks

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 4
  • Comments: 25 (9 by maintainers)

Most upvoted comments

It’s because we compile grin with avx/avx2 support, so it fails on cpus without those extensions. I’ll open an issue to track it

 elfx86exts grin
MODE64 (call)
CMOV (cmova)
SSE1 (movups)
SSE2 (movq)
SSSE3 (pshufb)
AVX (vxorps)
AVX2 (vpcmpeqd)
BMI2 (mulx)
ADX (adcx)
BMI (andn)
CPU Generation: Unknown

I did the same thing of deleting the chain_data and it still produced the issue.

I built a new one from the source code and I’m not having the problems anymore.

@h1-cwc wrote

Did you get this issue solved

Not at the moment. I read several people having issues with binaries, but succeeding with a build. So it’s what I try now (not finished).

I guess the issue may be related to character encoding, or a missing message ?