Parity crash when exiting

[edevil]

Before filing a new issue, please provide the following information.

I'm running:

• Which Parity version?: Parity/v1.8.6-beta-2d051e4-20180109/x86_64-macos/rustc1.22.1
• Which operating system?: MacOS
• How installed?: homebrew
• Are you fully synchronized?: yes
• Which network are you connected to?: private
• Did you try to restart the node?: yes

Your issue description goes here below. Try to include actual vs. expected behavior and steps to reproduce the issue.

I was following the tutorial but when I stop the nodes sometimes they crash:

➜  PoA parity --config node0.toml
Loading config file from node0.toml
2018-01-10 12:06:04 UTC Starting Parity/v1.8.6-beta-2d051e4-20180109/x86_64-macos/rustc1.22.1
2018-01-10 12:06:04 UTC Keys path /tmp/parity0/keys/DemoPoA
2018-01-10 12:06:04 UTC DB path /tmp/parity0/chains/DemoPoA/db/d0678730db7ea493
2018-01-10 12:06:04 UTC Path to dapps /tmp/parity0/dapps
2018-01-10 12:06:04 UTC State DB configuration: fast
2018-01-10 12:06:04 UTC Operating mode: active
2018-01-10 12:06:04 UTC Configured for DemoPoA using AuthorityRound engine
2018-01-10 12:06:05 UTC Updated conversion rate to Ξ1 = US$1338.13 (88965656 wei/gas)
2018-01-10 12:06:09 UTC Public node URL: enode://0991ca8b0960abd087d0b11f5d6f7926f19a95247dffe095e657133e6439b84d10e228a32cca580614ad95610f59794dd66bdb92594ae0eafe2261ef399d28d7@172.16.10.120:30300
2018-01-10 12:06:39 UTC    0/25 peers   8 KiB chain 7 KiB db 0 bytes queue 448 bytes sync  RPC:  0 conn,  0 req/s,   0 µs
^C2018-01-10 12:06:44 UTC Finishing work, please wait...
[1]    74174 segmentation fault (core dumped)  parity --config node0.toml

This is the backtrace from the core file:

(lldb) bt
* thread #1, stop reason = signal SIGSTOP
  * frame #0: 0x00007fffcd75f3f5 libsystem_malloc.dylib`tiny_free_no_lock + 173
    frame #1: 0x00007fffcd7600d5 libsystem_malloc.dylib`free_tiny + 671
    frame #2: 0x0000000106ce7ad1 parity`std::__1::vector<std::__1::pair<rocksdb::Tickers, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<rocksdb::Tickers, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > >::~vector() + 49
    frame #3: 0x00007fffcd65b178 libsystem_c.dylib`__cxa_finalize_ranges + 332
    frame #4: 0x00007fffcd65b4b2 libsystem_c.dylib`exit + 55
    frame #5: 0x000000010721a714 parity`std::process::exit::h390818a7d98718dc + 20
    frame #6: 0x00000001062dd631 parity`parity::main::h9d6bb1ae4dd3a6f6 + 6977
    frame #7: 0x000000010723288c parity`__rust_maybe_catch_panic + 12
    frame #8: 0x0000000107226839 parity`std::rt::lang_start::h7919b8561d5d8bb1 + 473
    frame #9: 0x00007fffcd5c6235 libdyld.dylib`start + 1

[5chdn]

Tagged it ASAP as this often causes DB corruptions.

Might be the reason for #7334

[5chdn]

Probably duplicate of #6213

[andresilva]

Yes, I think this is related to #6213 (and likely a source of DB corruption). These issues seem to point to the RocksDB destructors not being properly called on shutdown.

[andresilva]

This one should be fixed now since it's on shutdown.