Kbase P121121: Multi-threaded binary dump cores on 64-bit platforms
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
2/8/2009 |
|
Status: Verified
SYMPTOM(s):
threaded binary dump fails on 64-bit platform
binary dump fails using -threadnum parameter
Using index <num> for dump of table <name>. (6101)
tables with few records are affected
tables with no records are affected
tables with many duplicate keys on the index used are affected
SYSTEM ERROR: Bus error. (48)
SYSTEM ERROR: Memory violation. (49)
Enterprise database license installed
Stack trace from proutil reads:
Signal 10 (SIGBUS) delivered
free
dbut_utfree
upRecordDumpThr
upBinaryDumpCombined
upBinaryDump
dbusBinaryDump
FACT(s) (Environment):
OpenEdge 10.1A
OpenEdge 10.1B
All Supported Operating Systems
CAUSE:
Bug# OE00135661
CAUSE:
The -threadnum option is used by default or as specified (unless -thread 0 is used). Even though threaded dump is specified, multi threads will not necessarily be started to dump the table.
The algorithm also checks on the following to permit a multi-threaded binary dump:
a.) Enterprise Database License
b.) More than one CPU
c.) The number of entries in the root block of the index used (Primary index by default or that specified by the -index parameter). The threaded-dump algothm splits the root block logically into up to (-threadnum) parts, this will break the index tree in different ranges according to the keys in the root block, each thread works on a range. If there is only one entry in the root block, it cannot be split so a non-threaded (regular) dump will be used.
d.) There is also a special case that affects the number of threads used: if there are duplicate keys in the root block, the duplicate keys are ignored when building the brackets for the threads.
The cause of this failure was found to be that when a condition is met to NOT run a threaded dump, the function upRecordDumpThr() thread info structure list is freed but was not allocated. ie; the un-initialized pointer is not null when we try to free it resulting in the failure.
FIX:
Upgrade to OpenEdge 10.1B01.
If upgrade is not possible, the following two options are available:
1.) Do not to use the -threadnum parameter and set threads 0 in the binary dump cmd line:
$ proutil db-name -C dump [owner-name.]table-name directory [ -index num ] -thread 0
omit the following entries: [-threadnum nthreads] [-dumplist dumpfile]
And consider starting multiple sessions for the binary dump.
2.) ASCII dump the table.