DBTOOL Option 3 causes the database to crash

After DBTOOL Option 6 was used to try and fix a record, Option 3 was used to validate the table and the database crashed. 

Progress stack trace from dbtool reads:

PROGRESS stack trace as of <Date & Time>
command line not initialized
#1 [0x44d412] dbut_uttraceback+0x12b from <dlc>/bin/dbtool
#2 [0x44a4c9] dbut_uttrace+0x139 from <dlc>/bin/dbtool
#3 [0x438462] dbExit+0x47 from <dlc>/bin/dbtool
#4 [0x42b1d2] drSigFatal+0xd1 from <dlc>/bin/dbtool
#5 [0x7500f790] tfind@@GLIBC_2.2.5+0x7500f790 from /lib64/libpthread.so.0
#6 [0x44fe55] dsmMsgdCallBack+0xa3 from <dlc>/bin/dbtool
#7 [0x5106f6] rlaiDump+0x388 from <dlc>/bin/dbtool
#8 [0x49044d] rlStructDump+0x234 from <dlc>/bin/dbtool
#9 [0x4908d0] rlrdprv+0x1e5 from <dlc>/bin/dbtool
#10 [0x48c7a2] rlrej+0x388 from <dlc>/bin/dbtool
#11 [0x4ae1d5] tmrej+0x17c from <dlc>/bin/dbtool
#12 [0x45eadf] dsmTransaction+0x226 from <dlc>/bin/dbtool
#13 [0x40c523] smallRecordFragFixup+0x181 from <dlc>/bin/dbtool
#14 [0x40faf3] buildRecords+0x934 from <dlc>/bin/dbtool
#15 [0x410644] processBlocks+0x26f from <dlc>/bin/dbtool
#16 [0x4131fe] main+0x16b2 from <dlc>/bin/dbtool
#17 [0x74c1ed5d] __tls_get_addr@@GLIBC_2.3+0x74c1ed5d from /lib64/libc.so.6

DBRPR scan of the same table shows the following results:

Scan of <tablename> extent 1 90% complete
<tablename> extent 1 dbkey 5230944, of table 283, partition 0. Invalid data block found. Reason: Bad record size Records overlap 
Scan of <tablename> extent 1 100% complete

Database record corruption exists in the database reported by lg file error messages and client side logging

DBTOOL crashed when it was trying to process corrupt data and failed because it did not have knowledge about the corruption and was not prepared to handle it.

The fact that DBTOOL Option 6 was run initially has nothing to do with the subsequent DBTOOL Option 3 crash. While the "Record Fixup) Option can fix common record corruption like: a mismatched record field number in record header, or small record fragments that might cause a problem when update on the fragment results to size of rowid of its next fragment (32->64 bit), it cannot fix all record corruption specifically invalid record size, invalid table numbers and corrupt fields.  

 

Upgrade to OpenEdge 11.7.0 Where DBTOOL Option 3 has been updated to report common errors like invalid record size and invalid table number when all tables are selected and then stop further processing on the corrupt fields. When a specific table is selected,  records that have invalid size or table number are skipped. For further information refer to Article DBTOOL Option 3 reports inconsistent for single table vs all table validation   

The next corrective action is to dump the available content of the affected Storage Areas, remove the Area and load into a new Storage Area.
Or run DBRPR in fix mode to delete all Bad Records and Blocks it finds.