There's a core dump in the statistics support – I don't understand it yet, but here's the interesting stack trace, from the develop branch:
(gdb) where #0 __curstat_file_init (session=0x80302fc00, uri=0x80385200b "file:extra2.wt", cfg=0x7fffff5facc0, cst=0x803831c00) at src/cursor/cur_stat.c:356 WT-1 0x00000008008cee13 in __wt_curstat_init (session=0x80302fc00, uri=0x803852000 "statistics:file:extra2.wt", cfg=0x7fffff5facc0, cst=0x803831c00) at src/cursor/cur_stat.c:399 WT-2 0x00000008008cf558 in __wt_curstat_open (session=0x80302fc00, uri=0x803852000 "statistics:file:extra2.wt", cfg=0x7fffff5facc0, cursorp=0x7fffff5fad00) at src/cursor/cur_stat.c:501 WT-3 0x00000008008b0b60 in __statlog_dump (session=0x80302fc00, name=0x8030184c0 "file:extra2.wt", conn_stats=0) at src/conn/conn_stat.c:162 WT-4 0x00000008008b0dc6 in __statlog_apply (session=0x80302fc00, cfg=0x0) at src/conn/conn_stat.c:205 WT-5 0x00000008008aa3b9 in __conn_btree_apply_internal (session=0x80302fc00, dhandle=0x80307e000, func=0x8008b0d10 <__statlog_apply>, cfg=0x0) at src/conn/conn_dhandle.c:487 WT-6 0x00000008008aa2f6 in __wt_conn_btree_apply (session=0x80302fc00, apply_checkpoints=0, uri=0x0, func=0x8008b0d10 <__statlog_apply>, cfg=0x0) at src/conn/conn_dhandle.c:535 WT-7 0x00000008008af781 in __statlog_log_one (session=0x80302fc00, path=0x7fffff5faf70, tmp=0x7fffff5faf48) at src/conn/conn_stat.c:327 WT-8 0x00000008008b084d in __statlog_server (arg=0x80302fc00) at src/conn/conn_stat.c:414
The statistics server opened a btree handle in the session in *conn_btree_apply_internal, then wanders down to *curstat_file_init which opens another btree handle in the same session and then releases it. Then, we return back up to here:
Program received signal SIGSEGV, Segmentation fault. 0x000000080094fb08 in __wt_session_release_btree (session=0x80302fc00) at src/session/session_dhandle.c:134 134 btree = S2BT(session); gdb) where #0 0x000000080094fb08 in __wt_session_release_btree (session=0x80302fc00) at src/session/session_dhandle.c:134 WT-1 0x00000008008aa444 in __conn_btree_apply_internal (session=0x80302fc00, dhandle=0x80307e000, func=0x8008b0d10 <__statlog_apply>, cfg=0x0) at src/conn/conn_dhandle.c:491 WT-2 0x00000008008aa2f6 in __wt_conn_btree_apply (session=0x80302fc00, apply_checkpoints=0, uri=0x0, func=0x8008b0d10 <__statlog_apply>, cfg=0x0) at src/conn/conn_dhandle.c:535 WT-3 0x00000008008af781 in __statlog_log_one (session=0x80302fc00, path=0x7fffff5faf70, tmp=0x7fffff5faf48) at src/conn/conn_stat.c:327 WT-4 0x00000008008b084d in __statlog_server (arg=0x80302fc00) at src/conn/conn_stat.c:414
where we again release the btree handle, only it's already been released and we core dump with a NULL session->dhandle reference.
- related to
-
WT-1 placeholder WT-1
- Closed
-
WT-2 What does metadata look like?
- Closed
-
WT-3 What file formats are required?
- Closed
-
WT-4 Flexible cursor traversals
- Closed
-
WT-5 How does pget work: is it necessary?
- Closed
-
WT-6 Complex schema example
- Closed
-
WT-7 Do we need the handle->err/errx methods?
- Closed
-
WT-8 Do we need table load, bulk-load and/or dump methods?
- Closed