In my ongoing saga of writing a safe wrapper for the Cassandra C++ driver, my eye now turns towards avoiding memory leaks when calling C functions with signatures like:
cass_string_init2(const char* data, cass_size_t length);
or
cass_string_init(const char* null_terminated);
I have tried a few different approaches that nominally work, and produce a correct result, but I haven't found a way to manage the lifetime of this data properly. Two example approaches are below.
pub fn str_to_ref(mystr:&str) -> *const i8 {unsafe{
let cstr = CString::from_slice(mystr.as_bytes());
cstr.as_slice().as_ptr()
}}
and
pub fn str_to_ref(mystr: &str) -> *const i8 {
let l = mystr.as_bytes();
unsafe {
let b = alloc::heap::allocate(mystr.len()+1, 8);
let s = slice::from_raw_parts_mut(b, mystr.len()+1);
slice::bytes::copy_memory(s, l);
s[mystr.len()] = 0;
return b as *const i8;
}
}
The first does invalid memory accesses like
==26355== Address 0x782d140 is 0 bytes inside a block of size 320 free'd
==26355== at 0x1361A8: je_valgrind_freelike_block (in /home/tupshin/workspaces/rust/cql-ffi/target/basic)
==26355== by 0x11272D: heap::imp::deallocate::h7b540039fbffea4dPha (in /home/tupshin/workspaces/rust/cql-ffi/target/basic)
==26355== by 0x112679: heap::deallocate::h3897fed87b942253tba (in /home/tupshin/workspaces/rust/cql-ffi/target/basic)
==26355== by 0x112627: vec::dealloc::h7978768019700822177 (in /home/tupshin/workspaces/rust/cql-ffi/target/basic)
==26355== by 0x112074: vec::Vec$LT$T$GT$.Drop::drop::h239007174869221309 (in /home/tupshin/workspaces/rust/cql-ffi/target/basic)
==26355== by 0x111F9D: collections..vec..Vec$LT$i8$GT$::glue_drop.5732::h978a83960ecb86a4 (in /home/tupshin/workspaces/rust/cql-ffi/target/basic)
==26355== by 0x111F6D: std..ffi..c_str..CString::glue_drop.5729::h953a595760f34a9d (in /home/tupshin/workspaces/rust/cql-ffi/target/basic)
==26355== by 0x112903: cql_ffi::helpers::str_to_ref::hef3994fa55168b90bqd (in /home/tupshin/workspaces/rust/cql-ffi/target/basic)
=
while the second doesn't know when to deallocate its memory, resulting in:
==29782== 8 bytes in 1 blocks are definitely lost in loss record 1 of 115
==29782== at 0x12A5B2: je_mallocx (in /home/tupshin/workspaces/rust/cql-ffi/target/basic)
==29782== by 0x1142D5: heap::imp::allocate::h3fa8a1c097e9ea53Tfa (in /home/tupshin/workspaces/rust/cql-ffi/target/basic)
==29782== by 0x114221: heap::allocate::h18d191ce51ab2236gaa (in /home/tupshin/workspaces/rust/cql-ffi/target/basic)
==29782== by 0x112874: cql_ffi::helpers::str_to_ref::h5b60f207d1e31841bqd (helpers.rs:25)
Using either of those two approaches as a starting point, or something completely different, I would really appreciate some guidance on a proper way to accomplish this.
Edit:
Shep's answer perfectly solved my issues using cass_string_init and cass_string_init2. Thank you so much. However, I'm still not clear on passing *const i8 params to other functions such as:
CASS_EXPORT CassError
cass_cluster_set_contact_points(CassCluster* cluster,
const char* contact_points);
which expect to be passed a reference to a null-terminated string.
Based on the previous approach that worked for CassStrings, along with the CString docs, I came up with the following:
pub struct ContactPoints(*const c_char);
pub trait AsContactPoints {
fn as_contact_points(&self) -> ContactPoints;
}
impl AsContactPoints for str {
fn as_contact_points(&self) -> ContactPoints {
let cstr = CString::new(self).unwrap();
let bytes = cstr.as_bytes_with_nul();
let ptr = bytes.as_ptr();
ContactPoints(ptr as *const i8)
}
}
(the excessive let bindings there are just to make sure I wasn't missing any subtlety)
and that runs correctly, but valgrind complains:
==22043== Invalid read of size 1
==22043== at 0x4C2E0E2: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22043== by 0x4F8AED8: cass_cluster_set_contact_points (in /usr/local/lib/libcassandra.so.1.0.0)
==22043== by 0x11367A: cql_ffi::cluster::CassCluster::set_contact_points::h575496cbf7644b9e6oa (cluster.rs:76)
See Question&Answers more detail:
os