| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
running Korn shell scripts causes core dump, and other portability issues
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 running Korn shell scripts causes core dump, and other ... - Oct. 27, '05, 8:36:21 AM
|
|
|
mgokman
Posts: 6
Joined: Oct. 23, '05,
Status: offline
|
I'm trying to port my ksh scripts from Solaris to SFU. The scripts are working fine on Solaris. But, I'm seeing different behavior on SFU. For example, the construct like this seems to be causing core dump:
[[ <condition> ]] && <action>
but the same logic in the construct below causes no core dump:
if [[ <condition> ]]
then
<action>
fi
I also noticed a few other issues.
- path
My script is in /dev/fs/C/lbin, which is the first dir in the PATH. When I call this script while in different working directory it doesn't find it. When I do:
which <script name>
it gives me:
c:\lbin\<script name>
Anyone has any experience with these?
|
|
|
|
|
RE: running Korn shell scripts causes core dump, and ot... - Oct. 27, '05, 11:13:10 AM
|
|
|
Rodney
Posts: 3142
Joined: Jul. 9, '02,
From: /Tools lab
Status: online
|
In reverse order:
> which <script name>
The which command is originally a csh builtin command.
No other shells have it builtin. Since csh maintains a builtin hash list
for the executables in PATH this makes a large amount of sense.
With sh and ksh you want to run the builtin whence command.
> it gives me:
> c:\lbin\<script name>
Notice the Win32 path-style output.
This indicates that the program that got run is a Win32 program, not an Interix program.
I reccomend that in csh use the builtin which and with ksh use
the builtin whence. If you really want to use which with ksh
(or bash or zsh) then install the /Tools which package. You
will at the least get a Unix path out of it.
> ... it doesn't find it.
Check that the file is set for executable. (chmod +x filename) (Number 1 cause)
Otherwise: Which shell are you using ? How did you start your shell? How did you add to PATH?
> ...causing core dump:
This is usually the indication of DEP being active on your machine (hardware and or software).
Ksh is compiled with c89 (akak MSVC) that doesn't write into the stack with executable.
Hence it is running. Your "<action>", I guessing, invokes some gcc built code/program.
The gcc can often have executable code written on the stack. That kicks off DEP.
Anyway, refer to FAQ entry 2.07 about turning this off.
|
|
|
|
|
RE: running Korn shell scripts causes core dump, and ot... - Nov. 1, '05, 3:32:59 PM
|
|
|
mgokman
Posts: 6
Joined: Oct. 23, '05,
Status: offline
|
The <action> in my code is very simple: echo "Text", not invoking anything outside of basig ksh commands.
Also, if the code in <action> is the cause, then why does it work differently when i call it from the if statement?
|
|
|
|
|
RE: running Korn shell scripts causes core dump, and ot... - Nov. 2, '05, 11:34:45 PM
|
|
|
markfunk
Posts: 629
Joined: Mar. 31, '03,
Status: offline
|
Please cut and paste a real example that shows the code you are executing
and shows the results you are experiencing.
If we can repro your problem, chances are we can figure out
the problem or a workaround.
Please also include the output from the following, so we know what
kind of environment you're in:
$ /bin/uname -X
$ /bin/fileinfo
$ /bin/echo $PATH
$ /bin/echo $KSH_VERSION
|
|
|
|
|
RE: running Korn shell scripts causes core dump, and ot... - Nov. 4, '05, 6:46:52 PM
|
|
|
mgokman
Posts: 6
Joined: Oct. 23, '05,
Status: offline
|
The script connects to Oracle and gets some info.
It works on Solaris. This is not final version.
#!/bin/ksh
/bin/uname -X
/bin/fileinfo
/bin/echo $PATH
/bin/echo $KSH_VERSION
sid=$1
rdest=$2
lbin=/dev/fs/C/lbin
logdest=/dev/fs/D/oradata/PROD1/arc
. $lbin/oraenv.ksh $sid
senderr ()
{
msg="$1"
echo "$msg"
#exit 1
}
checkdbup ()
{
sqlplus -s "/ as sysdba" << EOF
set echo off
set feedback off
set heading off
set verify off
set pages 0
select status from v\$instance;
exit
EOF
}
function get_logdest
{
#set -o xtrace
sqlplus -s "/ as sysdba" << EOF
set echo off
set feedback off
set heading off
set verify off
set pages 0
col scn for 999999999999999999999999
select destination from v\$archive_dest
where lower(dest_name) = 'log_archive_dest_1';
exit
EOF
}
function get_arcseq
{
#set -o xtrace
sqlplus -s "/ as sysdba" << EOF
set echo off
set feedback off
set heading off
set verify off
set pages 0
col scn for 999999999999999999999999
select 'set '||sequence#||' '|| first_change# scn from v\$log where
sequence# =
(select max(sequence#) from v\$log where archived='YES');
exit
EOF
}
function get_scn
{
seq=$1
sqlplus -s "/ as sysdba" << EOF
set echo off
set feedback off
set heading off
set verify off
set pages 0
col scn for 999999999999999999999999
select
'set '||
to_char(first_change#, 9999999999999999999999)||' '||
to_char(next_change#, 9999999999999999999999)
from v\$archived_log where sequence# = $seq;
exit
EOF
}
typeset -i maxseq
typeset -i logseq
echo logdest: $logdest
markerbase=$rdest/marker
status=$(checkdbup)
status=CLOSED
echo status: $status
[[ "$status" = "OPEN" ]] || senderr "Error !!!"
#if [[ "$status" != "OPEN" ]]
#then
# senderr "Error !!!"
#fi
eval $(get_arcseq)
maxseq=$1
scn=$2
echo Maxseq: $maxseq Scn: $scn
echo logdest: $logdest
ls -1 $logdest/* | while read fn
do
echo $fn
logseq=$(basename $fn .arc | awk -F\_ '{print $2}')
echo $logseq
if [[ $logseq -le $maxseq ]]; then
echo moving $fn $maxseq to $rdest
[[ $? -eq 0 ]] || senderr "Error moving"
[[ $movedseq -lt $logseq ]] && movedseq=$logseq
fi
done
eval $(get_scn $movedseq)
first_scn=$1
next_scn=$2
markerfl=$markerbase.$movedseq.$first_scn.$next_scn
echo "$markerfl"
echo Done
-----------------
I run it in Ksh window.
Here is the execution log.
System = Interix
Node = MYFOREXREALDB1
Release = 3.5
Version = SP-8.0.1969.1
Machine = x86
Processor = Intel_x86_Family15_Model4_Stepping3
HostSystem = Windows
HostRelease = SP1
HostVersion = 5.2
/dev/fs/C/WINDOWS/system32/PSXSS.EXE 8.0.1969.2
/dev/fs/C/WINDOWS/system32/PSXDLL.DLL 8.0.1969.1
/dev/fs/C/WINDOWS/system32/POSIX.EXE 8.0.1969.1
/dev/fs/C/WINDOWS/system32/PSXRUN.EXE 8.0.1969.1
/dev/fs/C/WINDOWS/system32/drivers/PSXDRV.SYS 8.0.1969.1
/dev/fs/C/lbin:/bin:/opt/gcc.3.3/bin:/usr/contrib/bin:/usr/X11R6/bin:/usr/local/bin:/usr/contrib/win32/bin:/dev/fs/C/WINDOWS/system32:/dev/fs/C/SFU/common:/dev/fs/D/oracle/product/10.1.0/db_1/bin:/dev/fs/C/lbin
@(#)PD KSH v5.2.13 97/10/27 [Interix: 2003/11/07][i18n]
####################################################################
Oracle Environment:
ORACLE_SID: PROD1
ORACLE_HOME:
ORACLE_BASE: /dev/fs/D/oracle
NLS_LANG:
PATH: /dev/fs/C/lbin:/dev/fs/C/lbin:/bin:/opt/gcc.3.3/bin:/usr/contrib/bin:/usr/X11R6/bin:/usr/local/bin:/usr/contrib/win32/bin:/dev/fs/C/WINDOWS/system32:/dev/fs/C/SFU/common:/dev/fs/D/oracle/product/10.1.0/db_1/bin:/dev/fs/C/lbin:/dev/fs/D/oracle/product/10.1.0/db_1/bin:/dev/fs/C/lbin
SQLPATH:
####################################################################
logdest: /dev/fs/D/oradata/PROD1/arc
status: CLOSED
Error !!!
Maxseq: 16787 Scn: 70840768
logdest: /dev/fs/D/oradata/PROD1/arc
/dev/fs/D/oradata/PROD1/arc/ARC_PROD1_0570260760_001_16781.ARC
0
moving /dev/fs/D/oradata/PROD1/arc/ARC_PROD1_0570260760_001_16781.ARC 16787 to
/dev/fs/D/oradata/PROD1/arc/ARC_PROD1_0570260760_001_16782.ARC
0
moving /dev/fs/D/oradata/PROD1/arc/ARC_PROD1_0570260760_001_16782.ARC 16787 to
/dev/fs/D/oradata/PROD1/arc/ARC_PROD1_0570260760_001_16783.ARC
0
moving /dev/fs/D/oradata/PROD1/arc/ARC_PROD1_0570260760_001_16783.ARC 16787 to
/dev/fs/D/oradata/PROD1/arc/ARC_PROD1_0570260760_001_16784.ARC
0
moving /dev/fs/D/oradata/PROD1/arc/ARC_PROD1_0570260760_001_16784.ARC 16787 to
/dev/fs/D/oradata/PROD1/arc/ARC_PROD1_0570260760_001_16785.ARC
0
moving /dev/fs/D/oradata/PROD1/arc/ARC_PROD1_0570260760_001_16785.ARC 16787 to
/dev/fs/D/oradata/PROD1/arc/ARC_PROD1_0570260760_001_16786.ARC
0
moving /dev/fs/D/oradata/PROD1/arc/ARC_PROD1_0570260760_001_16786.ARC 16787 to
/dev/fs/D/oradata/PROD1/arc/ARC_PROD1_0570260760_001_16787.ARC
0
moving /dev/fs/D/oradata/PROD1/arc/ARC_PROD1_0570260760_001_16787.ARC 16787 to
/dev/fs/C/lbin/pusharchlogs_tst.ksh: from: not found
/marker..16787.70840768
Done
Memory fault (core dumped)
|
|
|
|
|
RE: running Korn shell scripts causes core dump, and ot... - Nov. 5, '05, 12:42:01 AM
|
|
|
markfunk
Posts: 629
Joined: Mar. 31, '03,
Status: offline
|
hmm, when I asked for an example, I meant a <small> example.
From your example, I see no evidence that the [[ ]] lines
are causing the core dump.
Have you looked at the core file and tried to identify
what util the core is from ? (the ksh perhaps ?)
Use "strings -a core" may give you a clue.
From the output, there seems to be a problem with
the get_scn() function.
[see the "/dev/fs/C/lbin/pusharchlogs_tst.ksh: from: not found" msg]
And $movedseq is never initialized. This may give you grief.
- try exiting the script before the eval $(get_scn ...) and see
if the core dump still shows up.
|
|
|
|
|
RE: running Korn shell scripts causes core dump, and ot... - Nov. 5, '05, 10:13:24 AM
|
|
|
mgokman
Posts: 6
Joined: Oct. 23, '05,
Status: offline
|
As I said, this is not final script, so disregard the bugs.
strings -a core only returns:
Memory fault (core dumped).
When I remove [[ ]] || <action>
it works fine. Even with core dump it also runs to completion, but ends with core dump.
I tried exiting earlier and had inconsistent results, with and without core.
My issue is, I don't think I'm doing anything illegal, and the script is fairly simple. What is in the environment that causes it to get memory fault? And based on what I read about DEP, I don't think this is my case.
|
|
|
|
|
RE: running Korn shell scripts causes core dump, and ot... - Nov. 6, '05, 4:00:09 PM
|
|
|
mgokman
Posts: 6
Joined: Oct. 23, '05,
Status: offline
|
I'm finding more protability issues.
A simple thing like using here document with Oracle's sqlplus is not working. It calls sqlplus.exe, runs the sql commands, and exists from the outer script when it reaches the sqlplus exit command, instead of continuing the shell script.
Am I the first one trying these things?
Very disappointing.
|
|
|
|
|
RE: running Korn shell scripts causes core dump, and ot... - Nov. 7, '05, 8:15:20 AM
|
|
|
markfunk
Posts: 629
Joined: Mar. 31, '03,
Status: offline
|
quote:
strings -a core only returns:
Memory fault (core dumped).
If /bin/strings dumps core, then I'd say you have a DEP problem.
The only known reason for this util to core dump is because of DEP.
To track down your problem, we definitely need to identify what
util is core dumping.
You are running Interix 3.5 on a Win2003 server SP1 system, so
you either need to get the hotfix patch from microsoft, or
turn DEP off.
About the SQL programs you're running - these are Win32 applications right ?
Win32 apps are notorius for not returning error status codes properly
(ie. behaviour appropriate for UNIX).
This could be the problem.
Have you tried using bash instead of ksh ?
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
