*Synopsis*: /usr/bin/hash core dump with invalid arguments
CR 6857344 changed on Sep 18 2009 by <User 1-5Q-4224>
=== Field ============ === New Value ============= === Old Value =============
SR 1-563875604
Functionality Nonessential
Hardware generic
Impact Critical
Operating System snv_123
Product Build snv_123
Product Name solaris
Product Release solaris_nevada
Severity 3
====================== =========================== ===========================
*Change Request ID*: 6857344
*Synopsis*: /usr/bin/hash core dump with invalid arguments
Product: solaris
Category: shell
Subcategory: korn93
Type: Defect
Subtype:
Status: 4-Defer
Substatus: Future Project
Priority: 3-Medium
Introduced In Release:
Introduced In Build:
Responsible Engineer:
Keywords:
=== *Description* ============================================================
Through user error, I typed the following invalid comand, but I got a core dump:
$ /usr/bin/hash -md5 file.txt
hash: -m: unknown option
hash: -d: unknown option
hash: -5: unknown option
Usage: hash [-ptx] [name[=value]...]
Segmentation Fault(coredump)
$
This shouldn't dump a core. I've verified this on two seperate systems. The
following information was taken from snv_110 on an x86 system:
pstack gives me no useful information:
$ pstack core
core 'core' of 20004: /usr/bin/hash -md5 file.txt
$
Similarly, stopping the process at SEGV and attaching mdb shows no stack:
$ truss -SSEGV /usr/bin/hash -md5 file.txt
execve("/usr/bin/hash", 0x080474AC, 0x080474BC) argc = 3
...etc...
Usage: hash [-ptx] [name[=value]...]
write(2, " U s a g e : h a s h ".., 37) = 37
Incurred fault #6, FLTBOUNDS %pc = 0x00000000
siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
Received signal #11, SIGSEGV [default]
siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
$ mdb -p 20025
Loading modules: [ ld.so.1 ]
> $c <==== NO STACK TRACE HERE
> $r
%cs = 0x0043 %eax = 0x00000006
%ds = 0x004b %ebx = 0x00000000
%ss = 0x004b %ecx = 0x00000000
%es = 0x004b %edx = 0xfee16fec libshell.so.1`sh+0x284
%fs = 0x0000 %esi = 0x00000000
%gs = 0x01c3 %edi = 0x00000000
%eip = 0x00000000
%ebp = 0x00000000
%kesp = 0x00000000
%eflags = 0x00010206
id=0 vip=0 vif=0 ac=0 vm=0 rf=1 nt=0 iopl=0x0
status=<of,df,IF,tf,sf,zf,af,PF,cf>
%esp = 0x00000000
%trapno = 0xe
%err = 0x14
>
It would appear that %esp has been NULL'd out here, hence no stack. However,
%eip is also NULL, which probably explains the core dump in this case.
The following information was taken from snv_115 on SPARC:
% /usr/bin/hash -md5 file.txt
hash: -m: unknown option
hash: -d: unknown option
hash: -5: unknown option
Usage: hash [-ptx] [name[=value]...]
Segmentation Fault (core dumped)
% pstack core
core 'core' of 280139: /usr/bin/hash -md5 file.txt
ff23e3f8 longjmp (0, 0, ff1ac000, 6, 0, ff1aeee4) + 8
000111bc main (3, 22000, 11338, 11000, 14, 5) + 9c
00010d00 _start (0, 0, 0, 0, 0, 0) + 108
% mdb /usr/bin/hash ./core
Loading modules: [ libc.so.1 ld.so.1 ]
> $C
ffbff990 libc.so.1`longjmp+8(0, 0, ff1ac000, 6, 0, ff1aeee4)
ffbffac8 main+0x9c(3, 22000, 11338, 11000, 14, 5)
ffbffba8 _start+0x108(0, 0, 0, 0, 0, 0)
> $r
%g0 = 0x00000000 %l0 = 0x00000008
%g1 = 0x00000000 %l1 = 0x00000000
%g2 = 0x00000000 %l2 = 0xff1aeee4 libshell.so.1`sh
%g3 = 0x00000000 %l3 = 0xff1af448 libshell.so.1`_Fcin
%g4 = 0x00000000 %l4 = 0x0000003c
%g5 = 0x00000028 %l5 = 0x00000000
%g6 = 0x00000000 %l6 = 0xff1aeee4 libshell.so.1`sh
%g7 = 0xff372a00 %l7 = 0x00000008
%o0 = 0xff1af168 libshell.so.1`sh+0x284 %i0 = 0x00000000
%o1 = 0x00000006 %i1 = 0x00000000
%o2 = 0x00000000 %i2 = 0xff1ac000
%o3 = 0x00003400 %i3 = 0x00000006
%o4 = 0x00000000 %i4 = 0x00000000
%o5 = 0xff145ed8 libshell.so.1`lex_advance %i5 = 0xff1aeee4 libshell.so.1`sh
%o6 = 0xffbff990 %i6 = 0xffbffac8
%o7 = 0xff138d20 libshell.so.1`sh_trap+0x3a8 %i7 = 0x000111bc main+0x9c
%psr = 0xfe001001 impl=0xf ver=0xe icc=nzvc
ec=0 ef=4096 pil=0 s=0 ps=0 et=0 cwp=0x1
%y = 0x00000000
%pc = 0xff23e3f8 libc.so.1`longjmp+8
%npc = 0xff23e3fc libc.so.1`longjmp+0xc
%sp = 0xffbff990
%fp = 0xffbffac8
%wim = 0x00000000
%tbr = 0x00000000
If I actually run either ksh93 or ksh then "hash -md5 file.txt", then it gives
me the correct usage (and no dump):
ksh93$ hash -md5 file.txt
alias: -md5: bad option(s)
ksh83$
ksh$ hash -md5 file.txt
ksh: hash: bad option(s)
ksh$
It appears to be the presence of any unknown arg which triggers the core dump.
I've logged this against ksh93 as I believe /usr/bin/hash now uses libshell,
and it is something in here which is crashing - please recategorise if
necessary. I also don't know the ksh93 code layout well enough to localise
where the problem is.
*** (#1 of 1): 2009-07-03 11:28:13 GMT+00:00 <User 1-5Q-8389>
=== *Public Comments* ========================================================
It is probably solved in the latest upstream, which should be integrated soon.
*** (#1 of 3): 2009-07-03 11:38:47 GMT+00:00 <User 1-1SURPB>
I reproduced this on snv_111b on intel ( which is a few builds earlier than the
submitter was using and different architecture). I didn't get a stack from the
core, so I used truss -u'*' to see what calls it makes before failing.
I then used truss to start it and stop it at a convenient point:
truss -Tmmap /usr/bin/hash -md5 file.txt
and then used mdb -p and breakpoints to get close to where it fails.
I then used:
while :; do echo "::stack" | mdb -p 2068; echo ":s" | mdb -p 2068; done
to single step it to the failure point, and can now get the core and stack
trace:
libc_hwcap1.so.1`_sbrk_unlocked+0x5d(0)
libc_hwcap1.so.1`sbrk+0x35(0, 0, 1, d08b7bfa)
libast.so.1`sbrkmem+0x90(d08efdf0, 8061210, a000, c000, d08efe88, 0)
libast.so.1`vmextend+0x105(d08efdf0, 400, d08b6184, d08b68f6)
libast.so.1`bestalloc+0x2c8(d08efdf0, 400, 8047308, d08b5936, 80472f0, d07f0298
)
libast.so.1`_ast_malloc+0xa0(400, d0af56da, 47c, d0882385)
libast.so.1`sfsetbuf+0x91d(806af10, 0, ffffffff, d087aeca)
libast.so.1`_sfmode+0x353(806af10, 1, 0, d087c146)
libast.so.1`sfnew+0x36b(0, 0, ffffffff, ffffffff, 7, 806ad80)
libast.so.1`_ast_setlocale+0x65c(6, 8047dfb, 0, d0999762)
libshell.so.1`put_lang+0xff(8068ba0, 8047dfb, 1, 80695a8)
libshell.so.1`nv_putv+0xe0(8068ba0, 8047dfb, 1, 80695a8)
libshell.so.1`nv_putval+0xa5(8068ba0, 8047dfb, 1, 8047560)
libshell.so.1`nv_open+0x8d7(8047df6, 8068ed8, 102280, d099c6c2)
libshell.so.1`env_init+0x7a(d0a06d68, d0999120, a, d099accc)
libshell.so.1`sh_init+0x417(4, 8047a50, 0, d0a30140)
main+0x96(3, 8047ad0, 8047ae0, 8047a8c)
_start+0x7d(3, 8047bdc, 8047bea, 8047bef, 0, 8047bf8)
mdb: stop on SIGSEGV
mdb: target stopped at:
libc_hwcap1.so.1`_sbrk_unlocked+0x5d: movl %edi,(%eax)
*** (#2 of 3): 2009-07-07 15:55:42 GMT+00:00 <User 1-5Q-6085>
Roland Mainz:
The next ksh93-integration update should have the final fix (the original
problem is that libshell does not initalise some points for error handling
(e.g. |setjmp()|) correctly which causes the |longjmp()| calls to jump to
niravana. The real fix is to rip-out the whole manual |setjmp()|/|longjmp()|
and replace it with a clean stack-like architecture to handle the nested
|longjmp()|'s correctly).
*** (#3 of 3): 2009-08-13 08:56:17 GMT+00:00 <User 1-1SURPB>
=== *Workaround* =============================================================
=== *Additional Details* =====================================================
Targeted Release:
Commit To Fix In Build:
Fixed In Build:
Integrated In Build:
Verified In Build:
See Also: 6793763, 6848486
Duplicate of:
Hooks:
Hook1:
Hook2:
Hook3:
Hook4:
Hook5:
Hook6:
Program Management:
Root Cause:
Fix Affects Documentation: No
Fix Affects Localization: No
=== *History* ================================================================
Date Submitted: 2009-07-03 11:28:13 GMT+00:00
Submitted By: <User 1-5Q-8389>
Status Changed Date Updated Updated By
3-Accepted 2009-07-03 11:38:47 GMT+00:00 <User 1-1SURPB>
4-Defer 2009-08-13 08:56:17 GMT+00:00 <User 1-1SURPB>
=== *Service Request* ========================================================
Impact: Limited
Functionality: Nonessential
Severity: 5
Product Name: solaris
Product Release: solaris_nevada
Product Build:
Operating System: snv_115
Hardware: generic
Submitted Date: 2009-07-03 11:28:13 GMT+00:00
=== *Service Request* ========================================================
Impact: Critical
Functionality: Nonessential
Severity: 3
Product Name: solaris
Product Release: solaris_nevada
Product Build: snv_123
Operating System: snv_123
Hardware: generic
Submitted Date: 2009-09-18 21:51:40 GMT+00:00
=== *Multiple Release (MR) Cluster* - 0 ======================================
