Description
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.
Attachments
Issue Links
- related to
-
WT-1 placeholder WT-1
- Closed
-
- Closed
-
- Closed
-
- Closed
-
- Closed
-
- Closed
-
- Closed
-
- Closed