Segfault when using dynamic_lib

[emberian]

See https://gist.github.com/cmr/82459f5715e673a8e90f. The destructor seems to be called before the constructor ever returns.

@sstewartgallus

[emberian]

I think this has to do with dtors and Result, because I am getting similar issues working on rust-zmq

[emberian]

As another, smaller, example:

use std::libc;

fn main() {
    let context = zmq::Context::new();
    let responder = match context.socket(zmq::REP) {
        Ok(x) => x,
        Err(x) => fail!("%?", x)
    };

    let x = responder.bind("tcp://*:5555");
    error!("%? %?", responder, x);
    let x = x.unwrap();

    let mut buf = [0, ..10];
    loop {
        unsafe { responder.recv_into(buf, 0) };
        println("Received Hello");
        responder.send(bytes!("Hello"), 0);
        unsafe { libc::sleep(1) };
    }
}

works correctly (the socket destructor isn't called early), but

use std::libc;

fn main() {
    let context = zmq::Context::new();
    let responder = match context.socket(zmq::REP).get();

    let x = responder.bind("tcp://*:5555");
    error!("%? %?", responder, x);
    let x = x.unwrap();

    let mut buf = [0, ..10];
    loop {
        unsafe { responder.recv_into(buf, 0) };
        println("Received Hello");
        responder.send(bytes!("Hello"), 0);
        unsafe { libc::sleep(1) };
    }
}

doesn't (the destructor is called during/immediately after the .get() call).

[emberian]

Actually, the problem with the zmq example was with a misplaced Clone implementation and usage of get rather than unwrap, which is a different ball of hair.

[mstewartgallus]

I actually already figured out the problem, and will be sending a pull request along shortly. Basically, the problem is that the DynamicLibrary structure is being created in the open method before checking for errors, and is then thrown away. A similar error exists in the symbol method.

[emberian]

@sstewartgallus you are awesome 💓

[mstewartgallus]

Fixed with #8219

[eminence]

I have re-tested the original issue with the latest master (dc48adc)

I confirm this issue is fixed and can be closed

[pnkfelix]

It looks to me like the test added in #8219 sufficiently covers the case as described in the gist linked in the description.

So the bug has been fixed with a test case; closing.