test2 and test3 segfault

XMLWordPrintableJSON

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

      I decided to run tests 1-4 again to compare performance. However, both test2 and test3 (with 500m items) took a segfault with similar stacks. These runs were with a production build. Here's some info from the core file for test 2. The pindex->entries looks a bit large, or uninitialized perhaps.

      171			child = pindex->index[base - 1];
(gdb) bt
#0  __wt_row_search (session=0x7f7f8a86ab40, srch_key=0x7f7f50c5ccc8, 
    leaf=<value optimized out>, cbt=0x7f7f50c5cc00, insert=0)
    at ../src/btree/row_srch.c:171
WT-1  0x000000000049cd47 in __cursor_row_search (cbt=0x7f7f50c5cc00)
    at ../src/btree/bt_cursor.c:158
WT-2  __wt_btcur_search (cbt=0x7f7f50c5cc00) at ../src/btree/bt_cursor.c:230
WT-3  0x000000000047119a in __curfile_search (cursor=0x7f7f50c5cc00)
    at ../src/cursor/cur_file.c:177
WT-4  0x000000000047f670 in __clsm_lookup (clsm=0x7f7f50c25180, 
    value=0x7f7f50c25270) at ../src/lsm/lsm_cursor.c:940
WT-5  0x0000000000481334 in __clsm_search (cursor=0x7f7f50c25180)
    at ../src/lsm/lsm_cursor.c:987
WT-6  0x0000000000407d75 in worker (arg=0x7f7f52c06000)
    at ../../../bench/wtperf/wtperf.c:500
WT-7  0x00007f7f8bddeddb in start_thread () from /lib64/libpthread.so.0
WT-8  0x00007f7f8b716a1d in clone () from /lib64/libc.so.6
(gdb) p base
$1 = 3808589409
(gdb) p *pindex
$3 = {entries = 3808589409, index = 0x75d75034ec8711d0}

      Here's the page:

      (gdb) p *page
$4 = {u = {intl = {recno = 0, parent_ref = 0x7f7f66f58d68, 
      __index = 0x7f7f8a812400}, row = {d = 0x0, ins = 0x7f7f66f58d68, 
      upd = 0x7f7f8a812400, entries = 0}, col_fix = {recno = 0, 
      bitf = 0x7f7f66f58d68 "\260O\366f\177\177", entries = 2323719168}, 
    col_var = {recno = 0, d = 0x7f7f66f58d68, repeats = 0x7f7f8a812400, 
      nrepeats = 0, entries = 0}}, dsk = 0x7f7f6fffe000, modify = 0x0, 
  read_gen = 0, memory_footprint = 13005, type = 6 '\006', 
  flags_atomic = 2 '\002'}

      Here's the similar stack from test3's segfault. It looks similar, although I do not have as much information as I'm getting a lot of things optimized out.

      53			child = pindex->index[base - 1];
(gdb) bt
#0  0x00000000004a68be in __wt_col_search (session=0x7f9140c6bb00, 
    recno=184547346, leaf=<value optimized out>, cbt=0x7f9102068d00)
    at ../src/btree/col_srch.c:53
WT-1  0x000000000049c63a in __cursor_col_search (cbt=0x7f9102068d00)
    at ../src/btree/bt_cursor.c:148
WT-2  __wt_btcur_search (cbt=0x7f9102068d00) at ../src/btree/bt_cursor.c:230
WT-3  0x000000000047119a in __curfile_search (cursor=0x7f9102068d00)
    at ../src/cursor/cur_file.c:177
WT-4  0x000000000043c337 in __wt_bloom_hash_get (bloom=0x7f9102057ec0, 
    bhash=<value optimized out>) at ../src/bloom/bloom.c:280
WT-5  0x000000000047f5f8 in __clsm_lookup (clsm=0x7f9102027180, 
    value=0x7f9102027270) at ../src/lsm/lsm_cursor.c:929
WT-6  0x0000000000481334 in __clsm_search (cursor=0x7f9102027180)
    at ../src/lsm/lsm_cursor.c:987
WT-7  0x0000000000407d75 in worker (arg=0x7f910851dc78)
    at ../../../bench/wtperf/wtperf.c:500
WT-8  0x00007f914226bddb in start_thread () from /lib64/libpthread.so.0
WT-9  0x00007f9141ba3a1d in clone () from /lib64/libc.so.6
(gdb) p base
$1 = 1633771873
(gdb) p pindex
$2 = <value optimized out>
(gdb) p *page
$3 = {u = {intl = {recno = 1, parent_ref = 0x7f912ebf26e8, 
      __index = 0x7f9140c21780}, row = {d = 0x1, ins = 0x7f912ebf26e8, 
      upd = 0x7f9140c21780, entries = 0}, col_fix = {recno = 1, 
      bitf = 0x7f912ebf26e8 "\200\203\277.\221\177", entries = 1086461824}, 
    col_var = {recno = 1, d = 0x7f912ebf26e8, repeats = 0x7f9140c21780, 
      nrepeats = 0, entries = 0}}, dsk = 0x7f911f3db000, modify = 0x0, 
  read_gen = 0, memory_footprint = 985, type = 3 '\003', 
  flags_atomic = 2 '\002'}

            Assignee:
            Unassigned
            Reporter:
            Susan LoVerso (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: