*Synopsis*: ksh93 cores as well when application invoked from script cores
CR 7008357 changed on Jan 19 2011 by <User 1-5Q-8426>
=== Field ============ === New Value ============= === Old Value =============
Public Comments New Note
Status 5-Cause Known 3-Accepted
====================== =========================== ===========================
*Change Request ID*: 7008357
*Synopsis*: ksh93 cores as well when application invoked from script cores
Product: solaris
Category: shell
Subcategory: korn93
Type: Defect
Subtype:
Status: 5-Cause Known
Substatus:
Priority: 2-High
Introduced In Release:
Introduced In Build:
Responsible Engineer: <User 1-5Q-8426>
Keywords:
=== *Description* ============================================================
Let's have a program that is generating core:
$ cat a.c
int main(void)
{
int *i = 0;
*i = 0;
return 0;
}
$ gcc a.c
$ ./a.out
Segmentation Fault (core dumped)
$
Let's have a script where the program is invoked:
$ cat a.sh
echo a | ./a.out
$
When the script is run by ksh93, then the ksh93 cores instead of the program:
$ /bin/ksh93 a.sh
a.sh: line 1: 17706: Memory fault(coredump)
Segmentation Fault (core dumped)
$ file core
core: ELF 64-bit LSB core file AMD64 Version 1, from 'ksh93'
$ echo ::stack | mdb core
libc.so.1`kill+0xa()
libshell.so.1`sh_main+0x817()
main+0x57()
0x400ccc()
$
This is not a case for other shells, for example:
$ /bin/bash a.sh
a.sh: line 1: 17721 Done echo a
17722 Segmentation Fault (core dumped) | ./a.out
$ file core
core: ELF 32-bit LSB core file 80386 Version 1, from 'a.out'
$ echo ::stack | mdb core
main+0x26(1, 8047abc, 8047ac4, 8050d00, 0, 0)
_start+0x83(1, 8047bc4, 0, 8047bcc, 8047bf2, 8047c06)
$
So, apparently, ksh93 is doing something wrong.
$ uname -a
SunOS telcontar 5.11 snv_154 i86pc i386 i86pc Solaris
$
*** (#1 of 1): 2010-12-21 18:33:40 GMT+00:00 <User 1-2GGNX3>
=== *Public Comments* ========================================================
The problem is with this part of the code in the sh_done() routine which is
invoked when the shell is terminated.
<usr/src/lib/libshell/common/sh/fault.c>
632 if(sig)
633 {
634 /* generate fault termination code */
635 signal(sig,SIG_DFL);
636 sigrelease(sig);
637 kill(getpid(),sig);
638 pause();
639 }
Looks like this is to make sure the right termination code is set when libshell
is used by one of the ksh93-replacement utilities (like "sleep"). Does not
seem to make sense for the actual shell to kill itself this way. Maybe we need
to differentiate between whether this is the actual ksh93 shell or one of the
utilities using libshell?
*** (#1 of 1): 2011-01-19 12:12:52 GMT+00:00 <User 1-5Q-8426>
=== *Workaround* =============================================================
coreadm can be used to change corefile patterns so the ksh93 core doesn't
overwrite the application core by core dumping on top of it to the same
file name.
*** (#1 of 1): 2010-12-23 17:56:56 GMT+00:00 <User 1-5Q-1267>
=== *Additional Details* =====================================================
Targeted Release:
Commit To Fix In Build:
Fixed In Build:
Integrated In Build:
Verified In Build:
See Also: 6989746
Duplicate of:
Hooks:
Hook1:
Hook2:
Hook3:
Hook4:
Hook5:
Hook6:
Program Management: New Defect
Root Cause:
Fix Affects Documentation: No
Fix Affects Localization: No
=== *History* ================================================================
Date Submitted: 2010-12-21 18:33:39 GMT+00:00
Submitted By: <User 1-2GGNX3>
Status Changed Date Updated Updated By
3-Accepted 2010-12-23 13:29:42 GMT+00:00 <User 1-5Q-8426>
5-Cause Known 2011-01-19 12:12:52 GMT+00:00 <User 1-5Q-8426>
=== *Service Request* ========================================================
Impact: Critical
Functionality: Primary
Severity: 1
Product Name: solaris
Product Release: solaris_nevada
Product Build: snv_154
Operating System: snv_154
Hardware: x86
Submitted Date: 2010-12-21 18:33:40 GMT+00:00
=== *Multiple Release (MR) Cluster* - 0 ======================================
_______________________________________________
ksh93-integration-discuss mailing list
ksh93-integration-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
