Core was generated by `cobchecker32'. Program terminated with signal 10, Bus error.

Core was generated by `cobchecker32'. Program terminated with signal 10, Bus error.

Error: Core was generated by `cobchecker32'. Program terminated with signal 10, Bus error.

Environment: Server Express 5.1 running on HP-UX 11.31 ia64.

 

Description: When undertaking 32 bit compiles a core dump containing the detail following was produced -

Core was generated by `cobchecker32'.

Program terminated with signal 10, Bus error.

BUS_ADRERR - Non-existant physical address

#0  0x60000000f769ea50 in <unknown_procedure> ()

(gdb) bt

#0  0x60000000f769ea50 in <unknown_procedure> ()

warning: Attempting to unwind past bad PC 0x60000000f769ea50

#1  0x60000000f769ea50 in <unknown_procedure> ()

 

But on the same machine, compiling the same program using the 64 bit compiler (cob64) worked fine. 

The 32 bit compiler generated a core file immediately the ‘cob’ command was executed and this was happening on even the simplest COBOL programs.

For example, the command: cob32 –iav helloworld.cbl immediately produced a core.

Even though –v (verbose) was specified in order to display the steps as they were executed, nothing was displayed on the screen, suggesting the compile never actually started.

All methods of compiling were tested (eg setting COBMODE=32, cob32, cobchecker32 etc), but all with the same result.

After inspecting the HP-UX installed patches listed the mfpoll.txt file, it was found that these were not commensurate with the certified patches as shown in the $COBDIR/docs/env.txt file. The patches installed on the user environment were later than those on which the version of Server Express was built on, and this was therefore considered to be the likely cause. However, this turned out to not be the case. This is mentioned here because a great deal of time was spent looking at specific HP-UX patches and trying to determine if some of these were responsible for error.

But there was an OS setting that had been modified. Tthe HP-UX base_pagesize kernel tunable parameter had been set to 64kb, and this caused the error.

Resolution:

This issue was resolved by setting the HP-UX base_pagesize kernel tunable parameter back to the default 4kb.

Prior to HP-UX 11.31 the base_page sizing wasn’t configurable but with 11.31 this could be changed. In this instance the environment was a virtual partition (vPar) and so base_pagesizing was configured to the maximum allowable 64kb, with the view that this would improve performance.

The getconf(1) command can be used to obtain the base page size of the system. The base page size is tuned by invoking the kctune(1M)command to change the kernel tunable parameter base_pagesize. The possible values for this page size are 4 KB [the default], 8 KB, and 16 KB. (The page size 64 KB is also supported, but it is intended solely for the use of the Integrity Virtual Machines host, and is too large for other uses.)

So if this error is encountered check the base_pagesizing kernel tunable parameter and if it has been set to 64kb reset it to the default 4kb and reboot the machine and attempt the 32 bit recompile.

 

Tags (1)

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Top Contributors
Version history
Revision #:
1 of 1
Last update:
‎2013-06-07 14:18
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.