-
Type:
Task
-
Resolution: Done
-
Affects Version/s: None
-
Component/s: None
-
None
Two problems:
1) The ex_log.java example has a SEGV:
* thread WT-4: tid = 0x43b3a6, 0x0000000123e1d52b libwiredtiger-2.5.1.dylib`__wt_cursor_set_keyv(cursor=0x000000010020ff40, flags=1792, ap=0x0000000100600540) + 1259 at cur_std.c:293, stop reason = signal SIGSEGV
frame #0: 0x0000000123e1d52b libwiredtiger-2.5.1.dylib`__wt_cursor_set_keyv(cursor=0x000000010020ff40, flags=1792, ap=0x0000000100600540) + 1259 at cur_std.c:293
290 if (LF_ISSET(WT_CURSOR_RAW_OK | WT_CURSTD_DUMP_JSON) ||
291 WT_STREQ(fmt, "u")) {
292 item = va_arg(ap, WT_ITEM *);
-> 293 sz = item->size;
294 buf->data = item->data;
295 } else if (WT_STREQ(fmt, "S")) {
296 str = va_arg(ap, const char *);
The WT_CURSOR_RAW flag is set for all cursors in the Java and Python interface code. But this SEGV occurs as a result of an internal call to set_key in cur_log.c:183:
__wt_cursor_set_key(cursor, cl->cur_lsn->file, cl->cur_lsn->offset, key_count);
where RAW is not appropriate. Maybe turning the RAW flag off temporarily for such internal calls will fix this?
2) The Python interface does not use WT_CURSOR_RAW if the cursor is a JSON dump cursor. There's no corresponding code for Java, so likely JSON dump is broken in Java.
There is no python test case for log cursors, and no java test case for log cursors or JSON dump.