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

NULL ref after checkpoint

    • Type: Icon: Task Task
    • Resolution: Done
    • WT2.2
    • Affects Version/s: None
    • Component/s: None
    • Labels:

      Hi @keithbostic, the current thing I'm hitting on new-split is a NULL ref in the tree after a checkpoint:

      Program terminated with signal 11, Segmentation fault.
      #0  0x000000000046abb7 in __wt_ref_key (page=0x7f0a02e437e0, ref=0x0, keyp=0x7f0a85bf6c60, sizep=0x7f0a85bf6c68) at ../src/include/btree.i:402
      402		if (ref->key.pkey & 0x01) {
      (gdb) where
      #0  0x000000000046abb7 in __wt_ref_key (page=0x7f0a02e437e0, ref=0x0, keyp=0x7f0a85bf6c60, sizep=0x7f0a85bf6c68) at ../src/include/btree.i:402
      WT-1  0x000000000046b9bc in __wt_row_search (session=0x7f0a99063e80, srch_key=0x7f0a7a01e140, leaf_page=0x0, cbt=0x7f0a7a01e080) at ../src/btree/row_srch.c:179
      WT-2  0x000000000049f0ab in __cursor_row_search (session=0x7f0a99063e80, cbt=0x7f0a7a01e080) at ../src/btree/bt_cursor.c:158
      
      (gdb) f 1
      WT-1  0x000000000046b9bc in __wt_row_search (session=0x7f0a99063e80, srch_key=0x7f0a7a01e140, leaf_page=0x0, cbt=0x7f0a7a01e080) at ../src/btree/row_srch.c:179
      179			__wt_ref_key(page, child, &item->data, &item->size);
      (gdb) print *page
      $1 = {u = {intl = {recno = 0, parent_ref = 0x7f0a5a8d7610, index = 0x7f09c6cec000}, row = {d = 0x0, ins = 0x7f0a5a8d7610, upd = 0x7f09c6cec000, entries = 0}, col_fix = {recno = 0,
            bitf = 0x7f0a5a8d7610 "\340\067\344\002\n\177", entries = 3335438336}, col_var = {recno = 0, d = 0x7f0a5a8d7610, repeats = 0x7f09c6cec000, nrepeats = 0, entries = 0}},
        dsk = 0x0, modify = 0x7f0a476726a0, read_gen = 286, memory_footprint = 225099, type = 6 '\006', flags_atomic = 16 '\020'}
      
      (gdb) print base
      $2 = 3752
      (gdb) print *pindex
      $3 = {entries = 3752, index = 0x7f09c6cec010}
      (gdb) print *pindex->index@3752
      $4 = {0x7f0a0dd4c340, 0x7f09e1532280, 0x7f09e152d790, 0x7f0a2efff610, 0x7f0a2ef4d820, 0x7f0a2eebe100, 0x7f09e153d6a0, 0x7f0a5bb85280, 0x7f0a5ba40490, 0x7f09e153bd30, 0x7f09e153a2e0,
        0x7f09e1537130, 0x7f09e15343a0, 0x7f09e152f640, 0x7f097402c310, 0x7f0a29f57670, 0x7f0890f1f130, 0x7f0a5f70ff70, 0x7f0a1c6ee7c0, 0x0 <repeats 3733 times>}
      
      (gdb) print *page->modify
      $5 = {disk_snap_min = 23462420, rec_max_txn = 15507796, update_txn = 23462544, bytes_dirty = 225099, u1 = {replace = {addr = 0x7f09a8a48c00 "\240\257\315\341\t\177", size = 51 '3',
            type = 0 '\000'}, m = {multi = 0x7f09a8a48c00, multi_entries = 51}}, u2 = {root_split = 0x0, leaf = {append = 0x0, update = 0x0}}, ovfl_track = 0x0, write_gen = 4,
        page_lock = 8 '\b', flags = 2 '\002'}
      

      So it's a WT_PM_REC_MULTI page, and pindex->entries seems to be much bigger than it should be: only 19 entries are filled in, out of 3752 allocated.

      Any ideas, or do you need more information to chase this one? I'm just running one of Alex's wtperf configs.

            Assignee:
            keith.bostic@mongodb.com Keith Bostic (Inactive)
            Reporter:
            michael.cahill@mongodb.com Michael Cahill (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: