We are running Couchbase Server 3.0.1 (we installed back in 2014). We are using the C SDK to access it, and have not had a lot of issues, but we have one HUGE issue causing our application to periodically crash. Yes, I know we are running very old code. This routine;
int CCouchbase::put (const char * key, const char * value) {
// initiate the read(s)
lcb_store_cmd_t * cmd = (lcb_store_cmd_t *) calloc(1,sizeof(lcb_store_cmd_t));
cmd->version = 0;
cmd->v.v0.key = key;
cmd->v.v0.nkey = Strlen(key);
cmd->v.v0.bytes = value;
cmd->v.v0.nbytes = Strlen(value);
cmd->v.v0.flags = 0;
cmd->v.v0.cas = 0;
cmd->v.v0.exptime = 0;
//cmd->v.v0.datatype = PROTOCOL_BINARY_DATATYPE_JSON;
cmd->v.v0.operation = LCB_SET;
lcb_store_cmd_st* cmds[] = { cmd };
try {
status = lcb_store (mycbi, (const void *)this, 1, cmds);
lcb_wait(mycbi);
}
catch (...) {
status = LCB_SERVER_BUG;
}
// done
return (status == LCB_SUCCESS ? 0 : status);
}
This will crash every so often on lcb_wait() with some kind of access violation. The try does not “catch” the error in the lib © code.
We would like to start migrating forward but don’t know the recommended path from such old code. We tried using a new lib (2.6.0) and the application compiles and links fine, but it dies instantaneously upon starting with an access violation at address 0x00000. It dies BEFORE the first line of our code runs, and certainly before any Couchbase calls.
What would be the “right” library to move to, assuming we want to upgrade the application FIRST and then the server (and then possibly re-upgrading the application – that is, do the CSDK in steps).
We feel a little trapped and have no path to escape!
Thanks,
Bret
You shouldn’t be using try/catch in the C-based lcb-wait/lcb-store. If any of these functions (or your callbacks) throw exceptions, you leave the library in an undefined state.
If you’re getting a segfault when running a newer version, perhaps run your debugger to see why it’s crashing. I suspect a linking issue where you have multiple versions of the library installed. You should be able to use any C library version with any Couchbase Server version (of course, availability of features depends on the version).
Thanks. I added the try catch just as a test! It’s not in our pros code.
I do set a breakpoint on the entry point to my software and it crashes before that, so during the load of a lib/etc. if I take out the couchlib (or put the older one in) it works. Newer one does not???
Bret
What OS are you using? - it seems to me that this is more an issue with your build environment than anything at the code level?
Using visual studio on windows to build and test. Then port to Linux. Issue is on windows. I’ve tried building several different ways, for example, emulating XP emulating visual studio 2010, etc. All feel the same way. Except one test said I was missing a VC redistributable DLL
You should probably clean your build environment and pick the C SDK version that matches your build environment exactly — although honestly in your situation, it might just be more prudent to build the C library from source itself as well. It’s a standard CMake project and should integrate pretty well.
Maybe there’s some kind of security setting that’s failing? perhaps it won’t allow you to load “random” DLLs?
Mark:
Thanks for your input and quick responses! I painstakingly found the
problem. I was playing around with different versions of libcouchbase
and to make my life easier, I was renaming one of the versioned
directories to just “libcouchbase” because that’s where VS2012 was going
to look for it. For some reason, when I go from certain versions to
other versions, VS doesn’t believe it needs to recompile parts of the
code. I forced VS to recompile/link everything, and it works
perfectly! I got 2 warnings about calls to lcb functions that have been
superseded (lcb_set_configuration_callback and set_error) so I commented
those out and uncommented the line I already had in there to call
set_bootstrap.
Code now runs fine!!!
Interestingly, I also have these lines commented out;
// setup timeouts
//lcb_uint32_t timeout = 10*1000*1000;
//lcb_set_timeout (mycbi, timeout);
//lcb_cntl(mycbi, LCB_CNTL_SET, LCB_CNTL_OP_TIMEOUT, &timeout);
In the 2.2.0 lib we WERE using, if we called set_timeout, we will get
crashes with a stack trace showing the error occurred deep in Windows
internals from libcouchbase (I think in a Wait function). It didn’t
matter if we lengthened or shortened the timeout. Any change to it
would inevitably cause the crash. Does anything like that sound
familiar and/or do you know if changing timeouts is something we
can/should do in newer versions?
Thanks,
Bret
You shouldn’t have any issues modifying timeouts — btw, lcb_set_timeout is deprecated, and now wraps lcb_cntl. The entire library was rewritten for 2.4.0, and that was quite a while ago, so I prefer to forget any version before that even existed :). The library pre 2.4.0 had numerous stability issues, so I wouldn’t be surprised at any kind of odd behavior there.