7 Replies Latest reply: Jan 31, 2014 12:39 PM by userBDBDMS RSS

Core dump inside lock/lock_deadlock.c because of prepare stmt?

VikramDayal Newbie
Currently Being Moderated

Hi,

I get the following core dump at random times:

Program terminated with signal 11, Segmentation fault.

SEGV_MAPERR - Address not mapped to object

 

It always dies on the line:

0x60000000d0a94b40:1 in __dd_build (env=0x4c8df90, atype=1,

    bmp=0x2000000071708a54, nlockers=0x2000000071708a68,

    allocp=0x2000000071708a64, idmap=0x2000000071708a50,

    rejectp=0x2000000071708a84, pri_set=0x2000000071708a6c)

    at ../src/lock/lock_deadlock.c:736

        in ../src/lock/lock_deadlock.c

 

I have a multi threaded application and TXN_BULK is set. Therefore, it should not go into these lines. I have also observed that the system seems to go into the child transaction code only when I bombard the system with a lot of prepare statements from several threads. Superficially it appears that the prepare statement is not guarded against creating child transactions. Can any one please confirm that?

 

 

Here is the stack trace of the thread that took the dump:

#0  0x60000000d0a94b40:1 in __dd_build (env=0x4c8df90, atype=1,

    bmp=0x2000000071708a54, nlockers=0x2000000071708a68,

    allocp=0x2000000071708a64, idmap=0x2000000071708a50,

    rejectp=0x2000000071708a84, pri_set=0x2000000071708a6c)

    at ../src/lock/lock_deadlock.c:736

#1  0x60000000d0a8c0f0:0 in __lock_detect (env=0x4c8df90, atype=1,

    rejectp=0x2000000071708a84) at ../src/lock/lock_deadlock.c:162

#2  0x60000000d0a65890:0 in __lock_vec (env=0x4c8df90,

    sh_locker=0x60000000fee8e3a4, flags=0, list=0x2000000071708ab0, nlist=2,

    elistp=0x2000000071708aa0) at ../src/lock/lock.c:366

#3  0x60000000d0b8a020:0 in __db_lput (dbc=0x133a64d0,

    lockp=0x200000004e7616d8) at ../src/db/db_meta.c:1418

#4  0x60000000d0b1c240:0 in __dbc_cleanup (dbc=0x133a64d0, dbc_n=0x133a5710,

    failed=0) at ../src/db/db_cam.c:2423

#5  0x60000000d0b1ab10:0 in __dbc_iget (dbc=0x133a64d0, key=0x14c8c3f0,

    data=0x14c8c40c, flags=10) at ../src/db/db_cam.c:1166

#6  0x60000000d0b17340:0 in __dbc_get (dbc=0x133a64d0, key=0x14c8c3f0,

    data=0x14c8c40c, flags=8202) at ../src/db/db_cam.c:770

#7  0x60000000d0b75150:0 in __dbc_get_pp (dbc=0x133a64d0, key=0x14c8c3f0,

    data=0x14c8c40c, flags=8202) at ../src/db/db_iface.c:2359

#8  0x60000000d04898b0:0 in sqlite3BtreeMovetoUnpacked (pCur=0x14c8c3a8,

    pUnKey=0x2000000071708b7c, nKey=0, bias=0, pRes=0x2000000071708b78)

    at ../lang/sql/generated/sqlite3.c:39280

#9  0x60000000d05133b0:0 in sqlite3VdbeExec (p=0x13214ba8)

    at ../lang/sql/generated/sqlite3.c:57816

#10 0x60000000d04eb9d0:0 in sqlite3Step (p=0x13214ba8)

    at ../lang/sql/generated/sqlite3.c:51771

#11 0x60000000d0415e70:0 in sqlite3_step (pStmt=0x13214ba8)

    at ../lang/sql/generated/sqlite3.c:51836

 

Here is the stack trace of the other threads when the core dump occurred:

[Switching to thread 36 (system thread 37392)]

#0  0x60000000c044f050:0 in __fsync_sys+0x30 () from /usr/lib/hpux32/libc.so.1

#0  0x60000000c044f050:0 in __fsync_sys+0x30 () from /usr/lib/hpux32/libc.so.1

#1  0x60000000c045efc0:0 in fdatasync+0xc0 () from /usr/lib/hpux32/libc.so.1

#2  0x60000000d0db83c0:0 in __os_fsync (env=0x4c8df90, fhp=0x134fd150)

    at ../src/os/os_fsync.c:93

#3  0x60000000d0d03820:0 in __log_flush_int (dblp=0x13117420,

    lsnp=0x200000006f497160, release=1) at ../src/log/log_put.c:1121

#4  0x60000000d0cfbcc0:0 in __log_flush_commit (env=0x4c8df90,

    lsnp=0x200000006f4971c0, flags=14) at ../src/log/log_put.c:538

#5  0x60000000d0cfa780:0 in __log_put (env=0x4c8df90, lsnp=0x60000000fee8ec60,

    udbt=0x200000006f4972a0, flags=14) at ../src/log/log_put.c:312

#6  0x60000000d0d0f170:0 in __log_put_record_int (env=0x4c8df90, dbp=0x0,

    txnp=0x13342a30, ret_lsnp=0x60000000fee8ec60, flags=6, rectype=10,

    has_data=0, size=32, spec=0x2000000077879570, argp=0x200000006f497378)

    at ../src/log/log_put.c:2002

#7  0x60000000d0d0f760:0 in __log_put_record (env=0x4c8df90, dbp=0x0,

    txnp=0x13342a30, ret_lsnp=0x60000000fee8ec60, flags=6, rectype=10,

    has_data=0, size=32, spec=0x2000000077879570) at ../src/log/log_put.c:1743

#8  0x60000000d0e0dde0:0 in __txn_regop_log (env=0x4c8df90, txnp=0x13342a30,

    ret_lsnp=0x60000000fee8ec60, flags=6, opcode=1, timestamp=1388528242,

    envid=570499172, locks=0x0) at ../src/dbinc_auto/txn_auto.h:40

#9  0x60000000d0e1e110:0 in __txn_commit (txn=0x13342a30, flags=0)

    at ../src/txn/txn.c:786

#10 0x60000000d0e16b70:0 in __txn_commit_pp (txn=0x13342a30, flags=0)

    at ../src/txn/txn.c:632

#11 0x60000000d047e140:0 in sqlite3BtreeCommitPhaseTwo (p=0x13359838,

    bCleanup=0) at ../lang/sql/generated/sqlite3.c:38160

#12 0x60000000d04e3d80:0 in vdbeCommit (db=0x1325b6a8, p=0x13256538)

    at ../lang/sql/generated/sqlite3.c:49931

#13 0x60000000d04e6990:0 in sqlite3VdbeHalt (p=0x13256538)

    at ../lang/sql/generated/sqlite3.c:50321

#14 0x60000000d0500660:0 in sqlite3VdbeExec (p=0x13256538)

    at ../lang/sql/generated/sqlite3.c:56116

#15 0x60000000d04eb9d0:0 in sqlite3Step (p=0x13256538)

    at ../lang/sql/generated/sqlite3.c:51771

#16 0x60000000d0415e70:0 in sqlite3_step (pStmt=0x13256538)

    at ../lang/sql/generated/sqlite3.c:51836

#17 0x60000000d0410ca0:0 in sqlite3_exec (db=0x1325b6a8,

    zSql=0x60000000fe28c0f0 "END TRANSACTION", xCallback=)

    at ../lang/sql/generated/sqlite3.c:77444

 

[Switching to thread 35 (system thread 37391)]

#0  0x60000000c01e2930:0 in __lwp_cond_wait_sys+0x30 ()

   from /usr/lib/hpux32/libpthread.so.1

#0  0x60000000c01e2930:0 in __lwp_cond_wait_sys+0x30 ()

   from /usr/lib/hpux32/libpthread.so.1

#1  0x60000000c00f99c0:0 in <unknown_procedure> + 0xa0 ()

   from /usr/lib/hpux32/libpthread.so.1

#2  0x60000000c00f57c0:0 in <unknown_procedure> + 0x900 ()

   from /usr/lib/hpux32/libpthread.so.1

#3  0x60000000c00f3230:0 in pthread_cond_wait+0xd0 ()

   from /usr/lib/hpux32/libpthread.so.1

#4  0x60000000d0632580:2 in inline __db_pthread_mutex_condwait (timespec=0x0,

    mutexp=0x40000000812ae29c, mutex=108819, env=0x4c8df90)

    at ../src/mutex/mut_pthread.c:321

#5  0x60000000d0632360:0 in __db_pthread_mutex_lock (env=0x4c8df90,

    mutex=108819, timeout=0) at ../src/mutex/mut_pthread.c:416

#6  0x60000000d0a6d9d0:0 in __lock_get_internal (lt=0x13117490,

    sh_locker=0x60000000fee8e534, flags=0, obj=0x13400380,

    lock_mode=DB_LOCK_READ, timeout=100000, lock=0x12bf05f8)

    at ../src/lock/lock.c:989

#7  0x60000000d0a79690:0 in __lock_get (env=0x4c8df90,

    locker=0x60000000fee8e534, flags=0, obj=0x13400380,

    lock_mode=DB_LOCK_READ, lock=0x12bf05f8) at ../src/lock/lock.c:469

#8  0x60000000d0b88a60:0 in __db_lget (dbc=0x134002f0, action=0, pgno=503999,

    mode=DB_LOCK_READ, lkflags=0, lockp=0x12bf05f8) at ../src/db/db_meta.c:1255

#9  0x60000000d0679800:0 in __bamc_next (dbc=0x134002f0, initial_move=0,

    deleted_okay=0) at ../src/btree/bt_cursor.c:2484

#10 0x60000000d066b0b0:0 in __bamc_get (dbc=0x134002f0, key=0x14c8bb80,

    data=0x14c8bb9c, flags=27, pgnop=0x200000006f868938)

    at ../src/btree/bt_cursor.c:1116

#11 0x60000000d0b18e00:0 in __dbc_iget (dbc=0x134002f0, key=0x14c8bb80,

    data=0x14c8bb9c, flags=27) at ../src/db/db_cam.c:952

#12 0x60000000d0b17340:0 in __dbc_get (dbc=0x134002f0, key=0x14c8bb80,

    data=0x14c8bb9c, flags=27) at ../src/db/db_cam.c:770

#13 0x60000000d0b75150:0 in __dbc_get_pp (dbc=0x134002f0, key=0x14c8bb80,

    data=0x14c8bb9c, flags=27) at ../src/db/db_iface.c:2359

#14 0x60000000d0489c50:0 in sqlite3BtreeMovetoUnpacked (pCur=0x14c8bb38,

    pUnKey=0x200000006f8689bc, nKey=0, bias=0, pRes=0x200000006f8689b0)

    at ../lang/sql/generated/sqlite3.c:39294

#15 0x60000000d0506ca0:0 in sqlite3VdbeExec (p=0x13214c88)

    at ../lang/sql/generated/sqlite3.c:56771

#16 0x60000000d04eb9d0:0 in sqlite3Step (p=0x13214c88)

    at ../lang/sql/generated/sqlite3.c:51771

#17 0x60000000d0415e70:0 in sqlite3_step (pStmt=0x13214c88)

    at ../lang/sql/generated/sqlite3.c:51836

 

[Switching to thread 34 (system thread 37390)]

#0  0x60000000c01e2930:0 in __lwp_cond_wait_sys+0x30 ()

   from /usr/lib/hpux32/libpthread.so.1

#0  0x60000000c01e2930:0 in __lwp_cond_wait_sys+0x30 ()

   from /usr/lib/hpux32/libpthread.so.1

#1  0x60000000c00f99c0:0 in <unknown_procedure> + 0xa0 ()

   from /usr/lib/hpux32/libpthread.so.1

#2  0x60000000c00f57c0:0 in <unknown_procedure> + 0x900 ()

   from /usr/lib/hpux32/libpthread.so.1

#3  0x60000000c00f3230:0 in pthread_cond_wait+0xd0 ()

   from /usr/lib/hpux32/libpthread.so.1

#4  0x60000000d0632580:2 in inline __db_pthread_mutex_condwait (timespec=0x0,

    mutexp=0x400000008118f550, mutex=102292, env=0x4c8df90)

    at ../src/mutex/mut_pthread.c:321

#5  0x60000000d0632360:0 in __db_pthread_mutex_lock (env=0x4c8df90,

    mutex=102292, timeout=0) at ../src/mutex/mut_pthread.c:416

#6  0x60000000d0a6d9d0:0 in __lock_get_internal (lt=0x13117490,

    sh_locker=0x60000000fee8d914, flags=0, obj=0x14d4b3c0,

    lock_mode=DB_LOCK_READ, timeout=100000, lock=0x200000006fc3c270)

    at ../src/lock/lock.c:989

#7  0x60000000d0a79690:0 in __lock_get (env=0x4c8df90,

    locker=0x60000000fee8d914, flags=0, obj=0x14d4b3c0,

    lock_mode=DB_LOCK_READ, lock=0x200000006fc3c270) at ../src/lock/lock.c:469

#8  0x60000000d0b88a60:0 in __db_lget (dbc=0x14d4b330, action=0, pgno=368692,

    mode=DB_LOCK_READ, lkflags=0, lockp=0x200000006fc3c270)

    at ../src/db/db_meta.c:1255

#9  0x60000000d06fb310:0 in __bam_search (dbc=0x14d4b330, root_pgno=7,

    key=0x14f8dcd0, flags=257, slevel=1, recnop=0x0, exactp=0x200000006fc3c2b0)

    at ../src/btree/bt_search.c:723

#10 0x60000000d0677600:0 in __bamc_search (dbc=0x14d4b330, root_pgno=0,

    key=0x14f8dcd0, flags=27, exactp=0x200000006fc3c2b0)

    at ../src/btree/bt_cursor.c:2804

#11 0x60000000d066ab90:0 in __bamc_get (dbc=0x14d4b330, key=0x14f8dcd0,

    data=0x14f8dcec, flags=27, pgnop=0x200000006fc3c2c8)

    at ../src/btree/bt_cursor.c:1105

#12 0x60000000d0b18e00:0 in __dbc_iget (dbc=0x14d4b330, key=0x14f8dcd0,

    data=0x14f8dcec, flags=27) at ../src/db/db_cam.c:952

#13 0x60000000d0b17340:0 in __dbc_get (dbc=0x14d4b330, key=0x14f8dcd0,

    data=0x14f8dcec, flags=27) at ../src/db/db_cam.c:770

#14 0x60000000d0b75150:0 in __dbc_get_pp (dbc=0x14d4b330, key=0x14f8dcd0,

    data=0x14f8dcec, flags=27) at ../src/db/db_iface.c:2359

#15 0x60000000d0489c50:0 in sqlite3BtreeMovetoUnpacked (pCur=0x14f8dc88,

    pUnKey=0x0, nKey=2929650, bias=0, pRes=0x200000006fc3c348)

    at ../lang/sql/generated/sqlite3.c:39294

#16 0x60000000d0509e80:0 in sqlite3VdbeExec (p=0x131ef698)

    at ../lang/sql/generated/sqlite3.c:57059

#17 0x60000000d04eb9d0:0 in sqlite3Step (p=0x131ef698)

    at ../lang/sql/generated/sqlite3.c:51771

#18 0x60000000d0415e70:0 in sqlite3_step (pStmt=0x131ef698)

    at ../lang/sql/generated/sqlite3.c:51836

 

[Switching to thread 33 (system thread 37389)]

#0  0x60000000c01e33d0:0 in __lwp_rwlock_rdlock_sys+0x30 ()

   from /usr/lib/hpux32/libpthread.so.1

#0  0x60000000c01e33d0:0 in __lwp_rwlock_rdlock_sys+0x30 ()

   from /usr/lib/hpux32/libpthread.so.1

#1  0x60000000c01e1ff0:0 in _lwp_rwlock_rdlock+0x70 ()

   from /usr/lib/hpux32/libpthread.so.1

#2  0x60000000c015e290:0 in pthread_rwlock_rdlock+0x6d0 ()

   from /usr/lib/hpux32/libpthread.so.1

#3  0x60000000d0633230:0 in __db_pthread_mutex_readlock (env=0x4c8df90,

    mutex=43877) at ../src/mutex/mut_pthread.c:511

#4  0x60000000d0d30ce0:0 in __memp_fget (dbmfp=0x4c8dec0,

    pgnoaddr=0x20000000700123e4, ip=0x60000000fee8b630, txn=0x2b96120,

    flags=0, addrp=0x20000000700123e0) at ../src/mp/mp_fget.c:317

#5  0x60000000d06fbb00:0 in __bam_search (dbc=0x131c6160, root_pgno=7,

    key=0x12c20de0, flags=258, slevel=1, recnop=0x0, exactp=0x2000000070012440)

    at ../src/btree/bt_search.c:806

#6  0x60000000d0677600:0 in __bamc_search (dbc=0x131c6160, root_pgno=0,

    key=0x12c20de0, flags=27, exactp=0x2000000070012440)

    at ../src/btree/bt_cursor.c:2804

#7  0x60000000d066ab90:0 in __bamc_get (dbc=0x131c6160, key=0x12c20de0,

    data=0x12c20dfc, flags=27, pgnop=0x2000000070012458)

    at ../src/btree/bt_cursor.c:1105

#8  0x60000000d0b18e00:0 in __dbc_iget (dbc=0x2c78230, key=0x12c20de0,

    data=0x12c20dfc, flags=27) at ../src/db/db_cam.c:952

#9  0x60000000d0b17340:0 in __dbc_get (dbc=0x2c78230, key=0x12c20de0,

    data=0x12c20dfc, flags=8219) at ../src/db/db_cam.c:770

#10 0x60000000d0b75150:0 in __dbc_get_pp (dbc=0x2c78230, key=0x12c20de0,

    data=0x12c20dfc, flags=8219) at ../src/db/db_iface.c:2359

#11 0x60000000d0489c50:0 in sqlite3BtreeMovetoUnpacked (pCur=0x12c20d98,

    pUnKey=0x0, nKey=2929666, bias=0, pRes=0x20000000700124d8)

    at ../lang/sql/generated/sqlite3.c:39294

#12 0x60000000d0509e80:0 in sqlite3VdbeExec (p=0x2c35ed8)

    at ../lang/sql/generated/sqlite3.c:57059

#13 0x60000000d04eb9d0:0 in sqlite3Step (p=0x2c35ed8)

    at ../lang/sql/generated/sqlite3.c:51771

#14 0x60000000d0415e70:0 in sqlite3_step (pStmt=0x2c35ed8)

    at ../lang/sql/generated/sqlite3.c:51836

  • 1. Re: Core dump inside lock/lock_deadlock.c because of prepare stmt?
    Hanhui Liang Newbie
    Currently Being Moderated

    Hi,

     

     

     

    Thanks for posting the question.

    We want to figure out the problem you met. But the stack traces you provided are not clear enough for us to find out why the problem happened. Could you please provide more details, some pieces of you code, or a short sample to reproduce the problem?

     

     

     

     

     

    Thanks,

  • 2. Re: Core dump inside lock/lock_deadlock.c because of prepare stmt?
    VikramDayal Newbie
    Currently Being Moderated

    Thanks for the quick response.

     

    This will be my third attempt to post the code in here. This time I will post it in multiple parts, so please excuse the multiple replies.

  • 3. Re: Core dump inside lock/lock_deadlock.c because of prepare stmt?
    VikramDayal Newbie
    Currently Being Moderated

    The program consists of several threads (>15) which are doing inserts, updated, deletes using the following strings which are first prepare() and then step().

    const char * const create = "CREATE TABLE 'test_table'"
                       " (field_1 TEXT, field_2 TEXT, field_3 TEXT,"
                       " field_4 TEXT, field_5 INTEGER, field_6 TEXT, field_7 TEXT,"
                       " field_8 TEXT, field_9 TEXT, field_10 TEXT, field_11 TEXT, field_12 TEXT,"
                       " field_13 TEXT, field_14 TEXT, field_15 TEXT, field_16 TEXT,"
                       " field_17 INTEGER, field_18 INTEGER, field_19 INTEGER, field_20 INTEGER,"
                       " field_21 INTEGER, field_22 INTEGER, field_23 INTEGER, field_24 INTEGER,"
                       " field_25 TEXT, field_26 TEXT, field_27 INTEGER, field_28 INTEGER,"
                       " field_29 INTEGER, field_30 INTEGER,  field_31 INTEGER,  field_32 INTEGER,"
                       "  field_33 INTEGER,  field_34 INTEGER,  field_35 INTEGER,  field_36 INTEGER,"
                       "  field_37 REAL,  field_38 TEXT,  field_39 TEXT,  field_40 INTEGER PRIMARY KEY,"
                       " field_41 REAL, field_42 INTEGER, field_43 INTEGER, field_44 INTEGER,"
                       " field_45 TEXT, field_46 REAL, field_47 INTEGER, field_48 INTEGER,"
                       " field_49 INTEGER, field_50 TEXT, field_51 INTEGER, field_52 INTEGER,"
                       " field_53 INTEGER, field_54 TEXT, field_55 TEXT, field_56 TEXT,"
                       " field_57 REAL, field_58 TEXT, field_59 INTEGER, field_60 INTEGER,"
                       " field_61 INTEGER, field_62 INTEGER, field_63 TEXT, field_64 INTEGER,"
                       " field_65 INTEGER, field_66 INTEGER, field_67 INTEGER, field_68 INTEGER,"
                       " field_69  INTEGER, field_70  INTEGER, field_71  INTEGER, field_72 INTEGER,"
                       " field_73  INTEGER, field_74  INTEGER, field_75 INTEGER, field_76 INTEGER,"
                       " field_77 INTEGER, field_78 INTEGER, field_79 TEXT, field_80 TEXT,"
                       " field_81 INTEGER NULL, field_82 INTEGER NULL, field_83 INTEGER NULL, field_84 TEXT,"
                       " field_85 REAL, field_86 TEXT, field_87 REAL, field_88 INTEGER NULL,"
                       " field_89 INTEGER NULL, field_90 TEXT NULL, field_91 TEXT NULL,"
                       " field_92 INTEGER NULL) ;";
                      
    const char * const insert = "INSERT INTO test_table values "
                       " (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,"
                       " ?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?);";   

    const char * const select1 = "SELECT "
    "field_21, field_22, field_26, field_14, field_40, field_24, field_25, field_7, field_8,"
    "field_9, field_10, field_69, field_71, field_72, field_73, field_74, field_78, field_42, "
    "field_44, field_13, field_1, field_2, field_3, field_4, field_5, field_41, field_30, "
    "field_43, field_36, field_49, field_50, field_51, field_55, field_56, field_68, field_6, "
    "field_47, field_52, field_53, field_58, field_59, field_57, field_60, field_61, field_62, "
    "field_76, field_15, field_16, field_35, field_32, field_33, field_77, field_18 "                  
    " FROM test_table WHERE field_20 = ? AND field_31 = 0 ORDER BY field_20, field_18,"
                       " field_14 DESC, field_40 LIMIT 1 ;";


    const char * const select2 = "SELECT "
    "field_23, field_45, field_24, field_25, field_21, field_22, field_44, field_42,"
    "field_43, field_28, field_1, field_2, field_3, field_4, field_5, field_6,"
    "field_80, field_7, field_8, field_9, field_10, field_69, field_70, field_71,"
    "field_72, field_73, field_74, field_75, field_77, field_78, field_26, field_14,"
    "field_15, field_16, field_47, field_76, field_36, field_48, field_50, field_11,"
    "field_86, field_49, field_83, field_51, field_52, field_53, field_54, field_87,"
    "field_89, field_64, field_65, field_66, field_67, field_63, field_56, field_60,"
    "field_61, field_68, field_88, field_79, field_33, field_12, field_39, field_40,"
    "field_85, field_35, field_20, field_38, field_27, field_41"
    " FROM control_table WHERE field_6=? AND field_13 = ? AND field_31 = 1"
                       " ORDER BY field_6,field_13,field_92 LIMIT 1;";

    const char * update1 = "UPDATE test_table SET "
    "field_6=?, field_80=?, field_39=?, field_84=?, field_23=?, field_31=?, field_45=?, field_85=?, "
    "field_83=?, field_86=?, field_87=?, field_89=?, field_60=?, field_61=?, field_88=?, field_70=?,"
    "field_92=? "
    " WHERE field_40=?;";

    const char * const update2 = "UPDATE control_table SET "
                       "field_35=?, field_6=?, field_20=?, field_27=?, field_33=?, field_46=?"
                       " WHERE field_40=?";

  • 4. Re: Core dump inside lock/lock_deadlock.c because of prepare stmt?
    VikramDayal Newbie
    Currently Being Moderated

    The general logic for executing the commands is as follows, I will give the details of the insertProc() in the next post:

     

    void doInsert() {

     

        for (int i=0; i <= MAX_RPDB_RETRIES; i++) {

       rc =BDB_BeginTransaction();

       if (rc != SQLITE_OK)
       {
        HANDLE_TERMINATE(msg.returnCode, __LINE__,0);
       }
         rc = insertProc();
        
          if( (rc == SQLITE_BUSY)  || (rc== SQLITE_LOCKED) || (rc == SQLITE_CORRUPT) )
          {
           // do nothing because TXN_BULK will do an aouto rollback
           TRACE_ERROR << "Busy Error rretry:: " << endl;
           }
          else
          {
            TRACE_ERROR << "Fatal Error :: " << endl;
             HANDLE_TERMINATE (  rc
                               ,__LINE__
                               ,DMSTATUS
                              );
         }
           if(i == MAX_RPDB_RETRIES)
           {
               TRACE_ERROR << "Max retries Message:: " << endl;
             HANDLE_TERMINATE (  rc
                                 ,__LINE__
                                 ,DMSTATUS
                                );
           }
          }
        } // for retries
      
      rc = BDB_EndTransaction();
      if (rc != SQLITE_OK)
      {
       HANDLE_DMTERMINATE(rc, __LINE__,0);
      }

     

    }  // end of function

  • 5. Re: Core dump inside lock/lock_deadlock.c because of prepare stmt?
    VikramDayal Newbie
    Currently Being Moderated

    The general insert function is as follows:

     

    void insertProc()
    {
    rc = sqlite3_prepare_v2(m_db, str, -1,&stmt, 0);
    if (rc != SQLITE_OK)
        return rc;

    // now bind all the variables  
    rc = bind...
    if (rc != SQLITE_OK)
        return rc;


    rc = sqlite3_step(stmt);
    if (rc != SQLITE_OK)
        return rc;

    rc = sqlite3_reset(stmt);
    return SQLITE_OK;

    }

  • 6. Re: Core dump inside lock/lock_deadlock.c because of prepare stmt?
    VikramDayal Newbie
    Currently Being Moderated

    The select and update functions are identical. These functions are running simultaneously on 15 threads. We have done

     

            rc = sqlite3_exec(m_db, "PRAGMA TXN_BULK=1", 0, 0, &zErrMsg);

            if( rc != SQLITE_OK )

     

    at the start of the program to ensure that TXN_BULK is set.

     

    I have put a patch in lock/lock_deadlock.c around the lines where the code is dying. That part of the code should not be executed as it is protected by the check for child transactions (which should not occurr due to TXN_BULK).

     

    I am putting part of the modified code of lock_deadlock.c Would appreciate it if you could confirm if the said patch will prevent similar core dumps.

     

    Please note that the core dump is giving line number ../src/lock/lock_deadlock.c:736. This line corresponds to

       753                                  ndx = lp->indx;

    in the modified code.

     

    Per our understanding of TXN_BULK, the line number  727 should not be executed, but we see it is getting executed many times. The core dump occurrs randomly once a month on any one of our several test servers.

     

       704          for (id = 0; id < count; id++) {

       705                  if (!id_array[id].valid)

       706                          continue;

       707                  if ((ret = __lock_getlocker_int(lt,

       708                      id_array[id].id, 0, &lockerp)) != 0 || lockerp == NULL)

       709                          continue;

       710  printf("Size of reginfo %ld, max =%ld\n", (lt->reginfo).rp->size,(lt->reginfo).rp->max);

       711

       712                  /*

       713                   * If this is a master transaction, try to find one of its

       714                   * children's locks first, as they are probably more recent.

       715                   */

       716                  child = SH_LIST_FIRST(&lockerp->child_locker, __db_locker);

       717                  if (child != NULL) {

       718                          do {

       719  c_retry:                        lp = SH_LIST_FIRSTP(&child->heldby, __db_lock);

       720                                  if (__SH_LIST_WAS_EMPTY(&child->heldby, lp))

       721                                          goto c_next;

       722

       723                                  if (F_ISSET(child, DB_LOCKER_INABORT))

       724                                          id_array[id].in_abort = 1;

       725  printf("Size of reginfo %ld, max =%ld\n", (lt->reginfo).rp->size,(lt->reginfo).rp->max);

       726

       727  printf("(lp > region +  ((lt->reginfo).rp->size)) = %x \n", (lp > region +  ((lt->reginfo).rp->size)) );

       728

       729          unsigned long long lhs_1 = (unsigned long long)(lp);

       730          unsigned long long rhs_2 = (unsigned long long)(region);

       731          unsigned long long rhs_1 = (unsigned long long)(region) +  (unsigned long long)((lt->reginfo).rp->size);

       732          unsigned long long rhs_3 = (unsigned long long)((lt->reginfo).rp->size);

       733

       734  printf("lp: %u, addition: %u, region: %u (lt->reginfo).rp->size: %u \n", lhs_1, rhs_1, rhs_2, rhs_3);

       735

       736  //                              if( (lp < region) || (lp > region +  ((lt->reginfo).rp->size)) )

       737

       738                                  if( (lhs_1 < rhs_2) || (lhs_1 > rhs_1) )

       739                                  {

       740                                          printf("BDB:lock_deadlock.c: Address of region   == %x \n", region);

       741  printf("lp: %u, addition: %u, region: %u (lt->reginfo).rp->size: %u \n", lhs_1, rhs_1, rhs_2, rhs_3);

       742                                          printf("Address of lp   == %x \n", lp);

       743                                          printf("Address of (__db_locker)* lp   == %x \n", (struct __db_locker *) lp);

       744                                          printf("Address of lp+1 == %x \n", (u_int8_t *)lp+1);

       745                                          printf("Address of lp-1 == %x \n", (u_int8_t *)lp + (-1));

       746                                          db_ssize_t first = (child->heldby).slh_first;

       747                                          printf("value  of address slh_first == %x \n", first);

       748                                          printf("value  of slh_first == %ld \n", first);

       749                                          printf("value  of child_heldby == %x \n", &child->heldby);

       750

       751                                          goto c_next;

       752                                  }

       753                                  ndx = lp->indx;

     

     

     

  • 7. Re: Core dump inside lock/lock_deadlock.c because of prepare stmt?
    userBDBDMS Guru Moderator
    Currently Being Moderated

    Looking through this post as well as past bug fixes that have gone into BDB lock code, this is something that should ideally be handled through Oracle Support.   Assuming you have a support contract for BDB, please file an SR with Oracle support.   This is much to complex of an issue that can be properly handled through the forums.     If you have a good reproducible test case that will be useful for support to have but my guess would be that you do not given that this is a multithreaded case and far too often those types of issues are timing related.

     

    thanks

    mike

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points