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

NULL ref after checkpoint

    XMLWordPrintable

    Details

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

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                keith.bostic Keith Bostic
                Reporter:
                michael.cahill Michael Cahill
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: