Attempting to recreate simple example fails on a syntax error

[cschneid]

Rust v1.0
[cqlsh 4.1.1 | Cassandra 2.0.14 | CQL spec 3.1.1 | Thrift protocol 19.39.0]

My code is nearly the same as the code in examples/

extern crate cassandra;
use cassandra::*;
static CONTACT_POINTS:&'static str = "172.20.20.10";

fn main() {
  println!("Before cluster connect");
  let cluster = &CassCluster::new()
                      .set_contact_points(CONTACT_POINTS).unwrap()
                      .set_load_balance_round_robin().unwrap();

  println!("Before session connect");
  let mut session = CassSession::new().connect(&cluster).wait().unwrap();
  println!("Before session execute");
  let result = session.execute("SELECT keyspace_name FROM system.schema_keyspaces;", 0).wait().unwrap();

  println!("{:?}", result);

  session.close().wait().unwrap();
}

And I get the output & error:

in Ticks/ on master
› cargo run --verbose
       Fresh gcc v0.3.5
       Fresh libc v0.1.7
       Fresh cql_bindgen v0.0.11
       Fresh cassandra v0.2.5
       Fresh time v0.1.25
       Fresh Ticks v0.1.0 (file:///Users/cschneid/Code/Rust/Ticks)
     Running `target/debug/Ticks`
Before cluster connect
Before session connect
Before session execute
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: "Syntax error"', /Users/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-mac/build/src/libcore/result.rs:729
Process didn't exit successfully: `target/debug/Ticks` (exit code: 101)

The query runs fine in the cqlsh interface, so there's something else going on with the result, or result unwraping. I have the c++ library linked from their homebrew recipe, which is 1.0.0.

[tupshin]

Hmmm...odd. I copied your exact code and just changed the ip address to be 127.0.0.1 and it runs perfectly on my linux laptop, running DSE 4.6, which is the same as Cassandra 2.0:
Before cluster connect
Before session connect
Before session execute
Result row count: 11
'"metrics"'
'"dse_system"'
'"tester"'
'"HiveMetaStore"'
'"examples"'
'"system"'
'"cfs_archive"'
'"system_traces"'
'"crustfs"'
'"cfs"'
'"dse_security"

You might turn on debug logging on the server to get a better idea. I'll keep thinking about this, and let me know if you any other thoughts.

[tupshin]

Oh, also, do the built in examples work for you?

[tupshin]

So I've now seen this happen twice. Once with a run of target/debug/basic and another time with target/debug/collections. I'm going to try running wireshark to capture all data between client and server and see if I can reproduce it again.

[mikepb]

I think the issue may have to do with how CString#as_ptr() is used in statement.rs:80. According to the CString#as_ptr() documentation, the returned C string is only valid as long as the query: CString is valid. As the variable is deallocated after returning from the function, the memory location for the C string may be overridden before the FFI library uses the string. The documentation suggests that CString#into_raw() or CString#into_ptr() along with CString#from_raw() or CString#from_ptr() would be more appropriate.

I ran into this problem while learning Rust FFI. I could be mistaken about your use case, though. Hope this helps!

[mikepb]

Nevermind, the CassStatement documentation states that cass_statement_new copies the input string.

[tupshin]

I believe later refactorings and bug fixes resolved a race condition that could cause this. Please reopen if you see it again.