Did this article resolve your question/issue?


Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025



Multi-threaded binary dump cores on 64-bit platforms

« Go Back


Article Number000030393
EnvironmentProduct: OpenEdge
Version: 10.1A, 10.1B
OS: All supported platforms
Other: 64-bit
Question/Problem Description
Threaded binary dump fails on 64-bit platform.
Binary dump fails when using the -thread 1 -threadnum parameters.
Binary dump fails when not specifying the -thread -threadnum parameters.
Steps to Reproduce
Clarifying Information
Tables with few records are affected.
Tables with no records are affected.
Tables with many duplicate keys on the index used are affected.

Data integrity checked on tables affected.

Stack trace from _proutil reads:
Signal 10 (SIGBUS) delivered
Error MessageSYSTEM ERROR: Bus error. (48)
SYSTEM ERROR: Memory violation. (49)
Defect/Enhancement NumberDefect PSC00181440 / OE00135661
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 before permitting 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 algorithm 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 on 64-bit OpenEdge versions.
Upgrade to OpenEdge 10.1B01, 10.1C or later.
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.

Full stack trace from _proutil on HP-UX Itanium reads:
PROGRESS stack trace as of 
Command line arguments are
$DLC/bin/_proutil db-name -C dump <table-name> directory -index num -thread 1 -threadnum 4 -dumplist dumpfile

uttraceback + 0x60  [/apl/progress/dlc/bin/_dbutil]
utcore + 0x3a0  [/apl/progress/dlc/bin/_dbutil]
drexit + 0x540  [/apl/progress/dlc/bin/_dbutil]
drSigFatal + 0x90  [/apl/progress/dlc/bin/_dbutil]
---- Signal 10 (SIGBUS) delivered ----
free + 0xb0  [/usr/lib/hpux64/]
dbut_utfree + 0x40  [/apl/progress/dlc/bin/_dbutil]
upRecordDumpThr + 0x240  [/apl/progress/dlc/bin/_dbutil]
upBinaryDumpCombined + 0xd80  [/apl/progress/dlc/bin/_dbutil]
upBinaryDump + 0x40  [/apl/progress/dlc/bin/_dbutil]
dbusBinaryDump + 0xd0  [/apl/progress/dlc/bin/_dbutil]
dbusExecute + 0x620  [/apl/progress/dlc/bin/_dbutil]
drdbUtil + 0x240  [/apl/progress/dlc/bin/_dbutil]
main + 0xd0  [/apl/progress/dlc/bin/_dbutil]
main_opd_entry + 0x50  [/usr/lib/hpux64/]

Last Modified Date9/13/2015 3:37 AM