statistics core dump

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Done
    • WT2.5.1
    • Affects Version/s: None
    • Component/s: None
    • None
    • None

      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.

            Assignee:
            Michael Cahill (Inactive)
            Reporter:
            Keith Bostic (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: