Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-1694

statistics core dump

    • Type: Icon: Task Task
    • Resolution: Done
    • WT2.5.1
    • Affects Version/s: None
    • Component/s: 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@mongodb.com Michael Cahill (Inactive)
            Reporter:
            keith.bostic@mongodb.com Keith Bostic (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: