Kbase 33535: SYSTEM ERROR: Bus error. (48) running from CRON or SCRIPTS
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
Solution ID: P3535
FACT(s) (Environment):
Progress 8.3x
HP-UX
HP-UX 11 32-bit
HP-UX 11 64-bit
SYMPTOM(s):
SYSTEM ERROR: Bus error. (48) running from CRON or SCRIPTS
SYSTEM ERROR: Bus error. (48)
protrace is generated
CAUSE:
A "bus error" is a data alignment error on a memory fetch or store operations caused by incompatible shared libraries, corrupt executables, corrupt data files and sometimes, hardware failure.
Since this error can be caused as a result of multiple reasons, the following information from the customer is useful in helping to narrow the cause down:
- details of the operating system ("uname -a", kernel settings for shared memory and semaphores, available resources)
- an extract from the log file that includes entries from the time problem occurs
- database details (size, structure)
- what the cron/script is trying to do
FIX:
If an applications terminates with a system error 48 running from a script or cron, the following tips will help to narrow the cause down:
1> Run the application from the UNIX command line. If the application completes without error, check the environment in the script. It is important to make sure all relevant environment variables are added and that the $PATH is appended with any directories that need to be included. Also be aware of the permissions for the directory where the script is started.
2> If the system error is limited to certain users, make sure that they have the proper permissions and group id necessary to run the application. You also need to check the permissions on the directory where the script is running. Compare the .profile of that user with one who can run the application successfully.
3> If it is a cron job that is failing, try running the application as root from the UNIX command line. If it runs successfully, then it is probably an environment issue. See (1) above.
4> Try setting the TERM environment variable in the script.
5> Find out how much memory the machine has. Try increasing startup parameters such as:
+ stack (-s) default = 40, should be =/- 1/4 B
+ heap (-hs) and
+ kernel parameters such as "MAXUMEM".
MAXUMEM is no longer used on HP-UX. It's just a name that exists on most UNIX flavors and older HP-UX OS versions. MAXUMEM has been segmented into separate memory pieces which are: DATA, STACK, TEXT.
HP-UX (found by doing 'sysdef') Process Related Parameters:
+ maximum size of data segment(maxdsiz)
+ maximum size of stack segment(maxssiz)
+ maximum size of text segment(maxtsiz)
Increase these parameters per you O/S System Administration Guide. Please refer to your O/S Vendor or HP-UX System Administrator for more information.
6> If error 48 appears to be caused by the application calls we may assume
that it may be the corrupted .r code. If possible, recompile your application. An example of this would be if the issue is related to the function that is handling user events within your application: umeDispatchEvent and wvRunDispatcher are processing various events from user interface.
7> If error 48 appears to be caused by the database index manager function ("cx" entries in the protrace, then "nsadoix" which is a program in the Progress index manager):
- run a "idxfx" (Option 3) which can be run online
8> Check the shared library /usr/lib/libc.2 . Are there any other application on your system that uses this library and does it perhaps mirror this error? Are there any other libc.* files there? Corruption of this file would also be a
probable reason of the problem. If it's possible try to find another version of
this file and link it (using symbolic link) in the same library - to test purposes.
9> Hardware failure cannot be ruled out. Problems with harddisk can cause a bus error, in which case the programs and databases need to be restored.
10> Is it possible to get the piece of code (procedure) that is causing the
problem?