Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection use after free #78

Closed
dahankzter opened this issue Nov 14, 2014 · 10 comments
Closed

Connection use after free #78

dahankzter opened this issue Nov 14, 2014 · 10 comments

Comments

@dahankzter
Copy link

I realize that the bigger issue may be a bit away but is there something to do to work around this at the moment?

I get this in all the time when i spawn to read some data asynchronously.

@sfackler
Copy link
Owner

You should be able to make changes like this: #34 (comment)

@sfackler
Copy link
Owner

Did that help?

@dahankzter
Copy link
Author

I do not know I am sorry I did not have time to test it before and now there seems to have been changes in virtually all my libs. :(

Fixed it all except:

error: mismatched types: expected `&[&postgres::types::ToSql]`, found `[_, ..0]` (expected &-ptr, found array of 0 elements)
src/hello_world.rs:91         for row in stmt.query([]).unwrap() {

Does the example in the readme still work?

@zr40
Copy link
Contributor

zr40 commented Nov 25, 2014

That [] should be changed to &[]. Apparently this was missed by #80.

@dahankzter
Copy link
Author

Thanks!

And the trick in the referenced issue seems to work. I had much more complex logic so I used a for loop something like this:

 let mut rows = stmt.query(&[]).unwrap();

        for row in rows {
            let object = TestStruct {
                data_int: row.get(0u),
                data_str: row.get(1u),
                data_vector: row.get(2u),
            };

            let encoded = json::encode(&object);
            tx.send(encoded);
        }
        rows;

Is that correct?

@sfackler
Copy link
Owner

Yep! I believe that the important part is that the statement and rows objects are "rooted". If they're only part of the expression that generates the return value of the block, then things get destructed in the wrong order.

@sfackler
Copy link
Owner

I fixed the brokenness in the README examples too: 3fb5043

@dahankzter
Copy link
Author

Nice, thanks! How will the underlying thing be resolved? The idea is that the workaround should not be needed right?

@sfackler
Copy link
Owner

The compiler will make sure that things are structured so that destructors will run in the right order, I believe by preventing the broken version from compiling.

@dahankzter
Copy link
Author

But how much mental bookkeeping should be needed? Maybe this will get natural when I get more into Rust but now it feels like "I want to execute something in a task, lets code it but make sure we root things properly" seems a little bit cumbersome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants