rust - 为什么在通过 massif 执行时连接到 Rust 中的 MySQL 会崩溃？

Question

考虑这个使用 mysql crate 版本 12.3.1 的小程序:

extern crate mysql;

fn main() {
    mysql::Pool::new("mysql://user@localhost:3306").expect("Could not connect to MySQL");
}

cargo .toml:

[package]
name = "massiftest"
version = "0.1.0"

[dependencies]
mysql = "12.3.1"

我有一个运行在 localhost:3306 上的 MySQL 服务器，通过 cargo run 执行它不会产生任何错误。但是，如果我使用 massif 运行它，我可以重现以下崩溃:

$ RUST_BACKTRACE=1 valgrind --tool=massif --num-callers=50 ./target/debug/massiftest
==6790== Massif, a heap profiler
==6790== Copyright (C) 2003-2015, and GNU GPL'd, by Nicholas Nethercote
==6790== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==6790== Command: ./target/debug/massiftest
==6790==
thread 'main' panicked at 'internal error: entered unreachable code: not all instructions were compiled! found uncompiled instruction: Compiled(Bytes(InstBytes { goto: 7, start: 219, end: 219 }))', /home/philipp/.cargo/registry/src/github.com-1ecc6299db9ec823/regex-0.2.10/src/compile.rs:788:18
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: <unknown>
  26: <unknown>
  27: <unknown>
  28: <unknown>
  29: <unknown>
  30: <unknown>
  31: <unknown>
  32: <unknown>
  33: <unknown>
  34: <unknown>
  35: <unknown>
  36: <unknown>
  37: <unknown>
  38: <unknown>
  39: <unknown>
  40: <unknown>
  41: <unknown>
  42: <unknown>
  43: <unknown>
  44: <unknown>
  45: <unknown>
  46: <unknown>
  47: <unknown>
  48: __libc_start_main
  49: <unknown>
==6790==
==6790== Process terminating with default action of signal 11 (SIGSEGV)
==6790==  Access not within mapped region at address 0x19
==6790==    at 0x254D36: core::ptr::drop_in_place::h9901a25205599d45 (ptr.rs:59)
==6790==    by 0x254D3A: core::ptr::drop_in_place::h9901a25205599d45 (ptr.rs:59)
==6790==    by 0x254D3A: core::ptr::drop_in_place::h9901a25205599d45 (ptr.rs:59)
==6790==    by 0x24BF89: _$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..ops..drop..Drop$GT$::drop::h5f694fd60b6c5066 (vec.rs:2127)
==6790==    by 0x2547A4: core::ptr::drop_in_place::h89b929960fc4b665 (ptr.rs:59)
==6790==    by 0x256F6F: core::ptr::drop_in_place::he8c4a5678cd0b221 (ptr.rs:59)
==6790==    by 0x254D3A: core::ptr::drop_in_place::h9901a25205599d45 (ptr.rs:59)
==6790==    by 0x24BF89: _$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$core..ops..drop..Drop$GT$::drop::h5f694fd60b6c5066 (vec.rs:2127)
==6790==    by 0x2547A4: core::ptr::drop_in_place::h89b929960fc4b665 (ptr.rs:59)
==6790==    by 0x256F6F: core::ptr::drop_in_place::he8c4a5678cd0b221 (ptr.rs:59)
==6790==    by 0x24CBDA: _$LT$alloc..vec..IntoIter$LT$T$GT$$u20$as$u20$core..ops..drop..Drop$GT$::drop::h323e1d02d841c5c3 (vec.rs:2424)
==6790==    by 0x257644: core::ptr::drop_in_place::hf8a356cb7d744b7c (ptr.rs:59)
==6790==    by 0x23D42B: regex::compile::Compiler::fill::h40d905207ffae07e (compile.rs:683)
==6790==    by 0x23D681: regex::compile::Compiler::fill_to_next::h7e5c4951b8ccf284 (compile.rs:690)
==6790==    by 0x23CCCC: regex::compile::Compiler::c_repeat_range::he48d5edb603fa1a2 (compile.rs:660)
==6790==    by 0x23B43A: regex::compile::Compiler::c_repeat::hd0674add2349dce5 (compile.rs:566)
==6790==    by 0x23595B: regex::compile::Compiler::c::h6e2f7c66c680728d (compile.rs:361)
==6790==    by 0x2363FD: regex::compile::Compiler::c_capture::hdeed9e649c6c8985 (compile.rs:370)
==6790==    by 0x2360B3: regex::compile::Compiler::c::h6e2f7c66c680728d (compile.rs:341)
==6790==    by 0x23A27B: regex::compile::Compiler::c_concat::hf34b737216385c45 (compile.rs:503)
==6790==    by 0x236214: regex::compile::Compiler::c::h6e2f7c66c680728d (compile.rs:357)
==6790==    by 0x2363FD: regex::compile::Compiler::c_capture::hdeed9e649c6c8985 (compile.rs:370)
==6790==    by 0x233CBE: regex::compile::Compiler::compile_one::h383b59bbedb7205d (compile.rs:148)
==6790==    by 0x233288: regex::compile::Compiler::compile::h5a10a88947640e81 (compile.rs:129)
==6790==    by 0x1D85F6: regex::exec::ExecBuilder::build::hfc7ca8484cbb6466 (exec.rs:304)
==6790==    by 0x1BE967: regex::re_builder::bytes::RegexBuilder::build::hc36d4c14e674b5e8 (re_builder.rs:77)
==6790==    by 0x218EE8: regex::re_bytes::Regex::new::h6c31ca336193b53b (re_bytes.rs:120)
==6790==    by 0x1B4773: core::ops::function::FnOnce::call_once::h0ba821d4b82efa91 (packets.rs:34)
==6790==    by 0x1939E2: _$LT$lazy_static..lazy..Lazy$LT$T$GT$$GT$::get::_$u7b$$u7b$closure$u7d$$u7d$::hceaf94d1f1e5785e (lazy.rs:24)
==6790==    by 0x1972D9: std::sync::once::Once::call_once::_$u7b$$u7b$closure$u7d$$u7d$::ha7cea6c7e6b4bacb (once.rs:227)
==6790==    by 0x36E50C: std::sync::once::Once::call_inner::h9d56229e10caf16f (once.rs:340)
==6790==    by 0x1971B3: std::sync::once::Once::call_once::h60fa32612fe1558b (once.rs:227)
==6790==    by 0x1A14CA: _$LT$mysql_common..packets..VERSION_RE$u20$as$u20$core..ops..deref..Deref$GT$::deref::hd9eed8de29b22816 (lazy.rs:23)
==6790==    by 0x1A0E1A: mysql_common::packets::HandshakePacket::server_version_parsed::h9a814fa77edfc821 (packets.rs:845)
==6790==    by 0x152859: mysql::conn::Conn::handle_handshake::h58a0f34c75ee7dc9 (mod.rs:773)
==6790==    by 0x1530B1: mysql::conn::Conn::do_handshake::_$u7b$$u7b$closure$u7d$$u7d$::hab7b3479b287f94f (mod.rs:801)
==6790==    by 0x163BA0: _$LT$core..result..Result$LT$T$C$$u20$E$GT$$GT$::and_then::h60f0cf035e0f4cda (result.rs:621)
==6790==    by 0x152A1A: mysql::conn::Conn::do_handshake::hcf7c5d8d74e8c9b1 (mod.rs:786)
==6790==    by 0x1588E5: mysql::conn::Conn::connect::hdc169ab3f7d6e9ec (mod.rs:1398)
==6790==    by 0x150B47: mysql::conn::Conn::new::hd04cf16ca6073f67 (mod.rs:630)
==6790==    by 0x1722A0: mysql::conn::pool::InnerPool::new_conn::h834e46591434439c (pool.rs:43)
==6790==    by 0x1720A3: mysql::conn::pool::InnerPool::new::he0e45a60210c82e4 (pool.rs:38)
==6790==    by 0x13A38E: mysql::conn::pool::Pool::new_manual::h3b93cd2e5084bece (pool.rs:195)
==6790==    by 0x13A831: mysql::conn::pool::Pool::new::hea509d1fce53a7c3 (pool.rs:190)
==6790==    by 0x143F57: massiftest::main::h97cbbec4f95365eb (main.rs:4)
==6790==    by 0x1408B1: std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h0add17d4b7ff7ebc (rt.rs:74)
==6790==    by 0x36EFA7: _ZN3std9panicking3try7do_call17h7d33aea9be52481fE.llvm.BFE82564 (rt.rs:59)
==6790==    by 0x384DAE: __rust_maybe_catch_panic (lib.rs:101)
==6790==    by 0x371FF9: std::rt::lang_start_internal::h16c0c37ef62d8e5a (panicking.rs:459)
==6790==    by 0x140891: std::rt::lang_start::hcd183d75c99491f4 (rt.rs:74)
==6790==  If you believe this happened as a result of a stack
==6790==  overflow in your program's main thread (unlikely but
==6790==  possible), you can try to increase the size of the
==6790==  main thread stack using the --main-stacksize= flag.
==6790==  The main thread stack size used in this run was 8388608.
==6790==
Segmentation fault

这里可能是什么原因，是否有可能避免这种情况？

我有一个更大的应用程序，我想分析它的内存使用情况，但这妨碍了我。

Answer 1

如 the Regex issue 中所述，可以通过将分配器从 jemalloc 切换开来修复在 Valgrind 下运行 Rust 程序:

#![feature(allocator_api, global_allocator)]

extern crate mysql;

use std::heap::System;

#[global_allocator]
static A: System = System;

fn main() {
    mysql::Pool::new("mysql://user@localhost:3306").expect("Could not connect to MySQL");
}

这仅限于 Rust nightly，因为 #![feature] 可能不会在稳定发布 channel 上使用。