diesel: Diesel Segfaults on host, but not development machine

Hello, I’m in the progress of writing a small discord bot using diesel. However my application seems to receive a segfault on my VPS host (uname -a: Linux ubuntu-512mb-fra1-01 4.4.0-67-generic #88-Ubuntu SMP Wed Mar 8 16:34:45 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux; its the smallest size of an digitalocean droplet). It does not do so on my development machine (uname -a: Linux charon 4.10.2-1-ARCH #1 SMP PREEMPT Mon Mar 13 17:13:41 CET 2017 x86_64 GNU/Linux)

Within GDB I get the following message for the segfautl:

Thread 1 "skellybot" received signal SIGSEGV, Segmentation fault.
0x0000555555a4d5f7 in je_tcache_dalloc_small (binind=<optimized out>, ptr=0x7ffff1ca5880, tcache=0x7ffff1c0c000, tsd=<optimized out>, slow_path=<optimized out>)
at /checkout/src/liballoc_jemalloc/../jemalloc/include/jemalloc/internal/tcache.h:42

bt gives me the following stacktrace:

#0  0x0000555555a4d5f7 in je_tcache_dalloc_small (binind=<optimized out>, ptr=0x7ffff1ca5880, tcache=0x7ffff1c0c000, tsd=<optimized out>, slow_path=<optimized out>)
    at /checkout/src/liballoc_jemalloc/../jemalloc/include/jemalloc/internal/tcache.h:422                                                                           
#1  je_arena_dalloc (tcache=0x7ffff1c0c000, ptr=0x7ffff1ca5880, tsd=<optimized out>, slow_path=<optimized out>)
    at /checkout/src/liballoc_jemalloc/../jemalloc/include/jemalloc/internal/arena.h:1370                      
#2  je_idalloctm (is_metadata=false, tcache=0x7ffff1c0c000, ptr=0x7ffff1ca5880, tsd=<optimized out>, slow_path=<optimized out>) at include/jemalloc/internal/jemalloc_internal.h:1055
#3  je_iqalloc (tcache=0x7ffff1c0c000, ptr=0x7ffff1ca5880, tsd=<optimized out>, slow_path=<optimized out>) at include/jemalloc/internal/jemalloc_internal.h:1079
#4  ifree (slow_path=false, tcache=0x7ffff1c0c000, ptr=0x7ffff1ca5880, tsd=<optimized out>) at /checkout/src/liballoc_jemalloc/../jemalloc/src/jemalloc.c:1819
#5  free (ptr=0x7ffff1ca5880) at /checkout/src/liballoc_jemalloc/../jemalloc/src/jemalloc.c:1922
#6  0x00007ffff7bb09d9 in ?? () from /usr/lib/x86_64-linux-gnu/libpq.so.5
#7  0x0000555555627670 in diesel::pg::connection::raw::{{impl}}::drop (self=0x7fffffff92e0)
    at /home/skeleten/.cargo/registry/src/github.com-1ecc6299db9ec823/diesel-0.11.4/src/pg/connection/raw.rs:95
#8  0x00005555555e53e1 in drop::hc00e4affa891dcbd () at /checkout/src/libcore/iter/iterator.rs:139
#9  0x00005555555e4411 in drop::h82bb99e6329dd1c6 () at /checkout/src/libcore/iter/iterator.rs:139
#10 0x000055555560ee02 in skellybot::user_seen (ctx=0x7fffffffb478, uid=0x7fffffffa1c0) at /home/skeleten/Source/skeleten/skellybot/src/main.rs:139
#11 0x000055555560de02 in skellybot::message_create_event (ctx=0x7fffffffb478, msg=Message = {...}) at /home/skeleten/Source/skeleten/skellybot/src/main.rs:113
#12 0x000055555560c7ee in skellybot::run () at /home/skeleten/Source/skeleten/skellybot/src/main.rs:89
#13 0x000055555560b5e7 in skellybot::main () at /home/skeleten/Source/skeleten/skellybot/src/main.rs:32
#14 0x0000555555a44146 in std::panicking::try::do_call<fn(),()> () at /checkout/src/libstd/panicking.rs:454
#15 0x0000555555a4b4fb in panic_unwind::__rust_maybe_catch_panic () at /checkout/src/libpanic_unwind/lib.rs:98
#16 0x0000555555a44bf7 in std::panicking::try<(),fn()> () at /checkout/src/libstd/panicking.rs:433
#17 std::panic::catch_unwind<fn(),()> () at /checkout/src/libstd/panic.rs:361
#18 std::rt::lang_start () at /checkout/src/libstd/rt.rs:57
#19 0x0000555555615fe3 in main ()

The complete source code I’m runnning can be found under https://github.com/skeleten/skellybot/tree/ece2a04ec61eaa8a1e62ecc3997aa0b7e4e99c6a

The Segfaults happens after receiving the first message which is processed here https://github.com/skeleten/skellybot/blob/ece2a04ec61eaa8a1e62ecc3997aa0b7e4e99c6a/src/main.rs#L111

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 1
Comments: 31 (12 by maintainers)

Most upvoted comments

I’ve managed to write a “simple” program that reproduces this issue:

// diesel = {version = "=1.3.3", features = ["postgres", "r2d2"]}
extern crate diesel;
// reqwest = "=0.9.5"
extern crate reqwest;

use std::thread;
use std::env;
use reqwest::Client;
use diesel::r2d2::*;
use diesel::*;

type PgPool = Pool<ConnectionManager<PgConnection>>;

pub fn init_db_pool() -> PgPool {
    let db = env::var("DATABASE_URL").expect("missing database url");
    let manager = ConnectionManager::<PgConnection>::new(db);
    Pool::new(manager).expect("db pool")
}

fn request() {
        let url = "https://google.com";
        let _res = Client::new().put(url)
            .body("some content")
            .send()
            .expect("request failed");
}

fn main() {
        for i in 0..10 {
                println!("Try {:?}", i);
                let b = thread::spawn(|| {request()});
                let a = thread::spawn(|| {let _ = init_db_pool();});
                a.join();
                b.join();
        }
}

Running this code in the docker container provided above does the following for me:

Dead lock
Segfault with various stack traces

(This does also happen on newer nightlies, so this does not depend on the rustc version)

@matthewkmayer This means this is not a rusoto issue @seanmonstar Any idea on this (The second part is reqwest).

weiznich on Dec 11, 2018

I’ve run into a similar issue (and mistakenly opened #2092). Here’s my code to reproduce:

use diesel::pg::PgConnection;
use diesel::connection::Connection;

fn main() {
    let connection = PgConnection::establish("postgres://USER:PASSWORD@localhost/")
        .unwrap_or_else(|e| panic!("Error connecting to database, {:?}", e));

    let res = reqwest::get("https://example.com").unwrap();

    panic!("");
}

Two funny parts: Removing the reqwest-part causes the program to fail normally, and leaving out the password/username of the postgres connection string also causes the program to fail normally.

Edit: These are the dependencies used:

reqwest = "0.9.18"
diesel = { version = "1.4.2", features = ["postgres"] }

Munksgaard on Jun 18, 2019