Bus error (coredump) when running a script that contains sql commands

[Brad Beard]

I run a script containing sql commands on one box and everything works fine. However, if I run the same script on another box, I get a "Bus error (coredump)" error message. Where do I begin looking for the reasoning behind this error? Could it be a kernel parameter difference?

Thanks.

[James R. Ferguson]

Hi:

"Bus error" is the error that the system gives when it tries to find the end of a non-terminated string, asking for more and more data in its search for the end. That is, the system asks for more data than the memory bus can give.

...JRF...

[John Palmer]

Hi Brad,

Do you have Oracle support? If so, I would check out their Metalink site for resolution.

For example, here is a possible hit:-

Problem Description:
====================

You are on HP-UX 10.20 running RDBMS 7.3.4.1. You have created a Korn
shell script that invokes SQL*Plus. One of the environment variables
declared within the script includes dashes '-'. Depending on the
position of the dash, the script will either work or core dump. For
example, this portion of the script with a three-level directory
structure works:

#!/bin/ksh
#
# 3 Level Directory Structure
#
export TMP_DIR=/home/oracle/test-dir1
sqlplus -s < userid/password
spool $TMP_DIR/testsh3.out
spool off

@test.sql
EOF

However, a similar script modified so that "TMP_DIR" is defined to include four
levels of directories fails with a core dump:

#!/bin/ksh
#
# 4 Level Directory Structure
#
export TMP_DIR=/home/oracle/test-dir1/testdir2
sqlplus -s < userid/password
spool $TMP_DIR/testsh4.out
spool off

@test.sql
EOF


Problem Explanation:
====================

The version of the Korne shell that you are using may be causing this problem.


Search Words:
=============

bus error

Solution: CHECK VERSION OF "/BIN/KSH" AVAILABLE ON SYSTEM


Solution Description:
=====================

You need to verify the version of "/bin/ksh" that is being used:

% which ksh
---> /bin/ksh
% what /bin/ksh
/bin/ksh:
$Revision: 78.5.1.11 $
Version 11/16/88
PATCH_10_20: arith.o blok.o ctype.o defs.o edit.o echo.o expand.o fault.o
io.o string.o stak.o word.o emacs.o vi.o hpux_rel.o args.o builtin.o cmd.o main.
o msg.o print.o xec.o name.o macro.o error.o service.o test.o jobs.o
history.o 96/12/19


Solution Description:
=====================

If you are using "/bin/ksh" at one of the following levels, you need to get
Revision: 78.5.1.11 or Revision: 78.5.1.28

$Revision: 78.5.1.16 $
$Revision: 78.5.1.22 $
$Revision: 78.5.1.26 $

Regards,
John

[CHRIS_ANORUO]

Hi Brad,

Check the core file with "file core" and read signal online manual to determine the type of problem. You can also check it with "strings core|pg"

[John Palmer]

Hi again,

Another possibility is this:-

HPUX 10.20

The ksh seems to intermittently coredump (and/or) erroneously run
with one of our scripts that performs Oracle database housecleaning
functions.

This problem is quite serious to us since it can leave the database
in an undesirable state requiring manual cleaning.

When run with set -x, we notice that several heredocs are not shown
in the output, these are the cases that do not execute correctly
and sometimes dump core:

existe=0
+ [ 0 = 0 ]
+ echo drop rel1012_temp
drop rel1012_temp
+ tee /tmp/te1398
+ sqlplus -s ecfcctrp/ecfcctrp <---- Here is the problem
+ existe=1

It should execute the sqlplus statement like the following one:

existe=0
+ [ 0 = 0 ]
+ echo drop rel1003_temp
drop rel1003_temp
+ tee /tmp/te1398
+ sqlplus -s ecfcctrp/ecfcctrp
+ 0< /tmp/sh4300.57

Table dropped.

+ existe=1

There appears to be no heredoc temp file in the failed case, ie the
line:

'+ 0< /tmp/sh4300.57'.

We would like this problem fixed as it impacts on our database use.

Cause Text

ksh(1) had limited the number of open files at
any time to 20, which was not sufficient in the
case of the script which used a large number of
heredocs. ksh(1) didn't handle the case when
this limit was exceeded, and hence it coredumped.

sh-posix(1) did not have any limitation on the
number of open files. It was already using the
system configured value for this. But, the code
which calculated the index to the array into
which the io structures were stored, was not
correct, which resulted in core dump.

Fix Text

The fix has been checked-in to the current release of
HP-UX (11.01)

A 10.20 ksh(1) patch - PHCO_17691 has been delivered
for the fix.


Regards.
John

[Brad Beard]

This is actually Sybase sql. I have now found that the box where this script works has the POSIX cummulative patch and the box that it does not work on does NOT have this patch. I am going to install this patch then retry. I will let you know the outcome. Thank you for your help.

Brad