The following crash can be reproduced by creating the same prepared statement on several client threads then using them to execute a statement. The preparing step works as intended, but some of the prepares don't return the "<result_metadata>" section which is specified in the protocol (https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v2.spec#L565-L572) and handled correctly. The execute requests handle this scenario by not setting the "skip_metadata" flag (https://github.com/datastax/cpp-driver/blob/1.0/src/execute_request.hpp#L36-L40). I've been able to replicate a situation where the "skip_metadata" flag is not set, but the metadata doesn't get returned. I'm not sure if this is a driver or C* issue yet.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdf5fe700 (LWP 14601)]
0x00007ffff796acee in std::vector<cass::ColumnDefinition, cass::FixedAllocator<cass::ColumnDefinition, 16u> >::size (this=0x8)
533 /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_vector.h: No such file or directory.
#0 0x00007ffff796acee in std::vector<cass::ColumnDefinition, cass::FixedAllocator<cass::ColumnDefinition, 16u> >::size (this=0x8)
#1 0x00007ffff796a490 in cass::Metadata::column_count (this=0x0)
#2 0x00007ffff796a556 in cass::ResultResponse::column_count (this=
#3 0x00007ffff798a462 in cass::ResultResponse::decode_first_row (
#4 0x00007ffff797216c in cass_future_get_result (future=0x7fffd40d7fc0)
#5 0x000000000041ce34 in COS:bRequest::finishInvokeLookup (
this=0x7fffd402b4f0) at Database.cpp:1519
#6 0x000000000041cc9b in COS:bRequest::finishInvoke (this=0x7fffd402b4f0)
#7 0x000000000041f59e in COS:b::onReadyCb (loop=0x66a550, w=0x668388,
revents=524288) at Database.cpp:2432
#8 0x00007ffff72c2efe in ev_invoke_pending (loop=0x66a550) at ev.c:2994
#9 0x00007ffff72c6fcf in ev_run (loop=0x66a550, flags=<value optimized out>)
#10 0x0000000000437c3a in COS::TaskDispatcher::init (this=0x668278)
#11 0x00000000004382f2 in COS::TaskThread::main (thread_=0x668278)
#12 0x00007ffff70a8851 in start_thread () from /lib64/libpthread.so.0
#13 0x00007ffff665690d in clone () from /lib64/libc.so.6
Great, I'll try that tomorrow. Do you use a multi-node cluster or would that also work with a single instance?
This is reproducible with a single node cluster and is only reproducible with C* 2.1. I have been unable to reproduce with C* 2.0. This is also not an issue with C* 1.2 because it's prepare result response never returns "<result_metadata>", but it should be noted that it always returns "<metadata>" for the row result response.
Manually tested against Cassandra 2.1.0. Scenario: Prepare the same statement in several threads. The error: "Expected metadata but no metadata in response" is prints, no set fault..