Bug 474114

Summary: command hang in ksh and cpu workload is high
Product: [Fedora] Fedora Reporter: Michal Hlavinka <mhlavink>
Component: mkshAssignee: Robert Scheck <redhat-bugzilla>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 10CC: redhat-bugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-12-02 06:21:04 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Michal Hlavinka 2008-12-02 05:23:37 EST
Description of problem:
command hang in ksh and cpu workload is high

Version-Release number of selected component (if applicable):
mksh-36-1.fc10.x86_64

How reproducible:


Steps to Reproduce:
1. create a script like belowing:
# cat hang.sh 
#!/bin/ksh
alias ls="ls"
i=`ls`
echo $i

2. issuce the script
  # ./hang.sh

Actual Results:
  script hangs while executing  i=`ls`, and the cpu workload is nearly 100%

Expected Results:
   The script runs smoothly.


Additional Information:

# ps -e | grep hang
21776 pts/3    00:00:27 hang.sh

# strace -p 21776 
brk(0xa057000)                          = 0xa057000
brk(0xa078000)                          = 0xa078000
brk(0xa099000)                          = 0xa099000
brk(0xa0ba000)                          = 0xa0ba000
brk(0xa0db000)                          = 0xa0db000
brk(0xa0fc000)                          = 0xa0fc000
brk(0xa11d000)                          = 0xa11d000
...

# ltrace -p 21776 
__rawmemchr(0x9480688, 0, 0xbff7e808, 0x8049a6a, 0x9fb71a8)          =
0x948068a 
memset(0x80758a2, '\000', 63)                                        =
0x80758a2 
strcmp("ls", "ls")                                                   = 0
__ctype_b_loc()                                                      =
0xb7fdda84
__rawmemchr(0x9480688, 0, 0xbff7e808, 0x8049a6a, 0x9fb7210)          =
0x948068a 
memset(0x80758a2, '\000', 63)                                        =
0x80758a2 
strcmp("ls", "ls")                                                   = 0
__ctype_b_loc()                                                      =
0xb7fdda84
__rawmemchr(0x9480688, 0, 0xbff7e808, 0x8049a6a, 0x9fb7278)          =
0x948068a 
memset(0x80758a2, '\000', 63)                                        =
0x80758a2 
strcmp("ls", "ls")                                                   = 0
__ctype_b_loc()                                                      =
0xb7fdda84
__rawmemchr(0x9480688, 0, 0xbff7e808, 0x8049a6a, 0x9fb72e0)          =
0x948068a 
memset(0x80758a2, '\000

WARNING: when you try to reproduce this, mksh starts to consume more and more memory very quickly, so ulimit -m and ulimit -v to something lower than unlimited is very useful.
Comment 1 Michal Hlavinka 2008-12-02 05:28:37 EST
my mistake, strace and ltrace are originally from pdksh, but this bug is easily reproducible with mksh
Comment 2 Robert Scheck 2008-12-02 05:30:27 EST
Ehm, is it possible, that you're mixing up ksh and mksh? You wrote ksh above,
not mksh...
Comment 3 Michal Hlavinka 2008-12-02 06:18:31 EST
(In reply to comment #2)
> Ehm, is it possible, that you're mixing up ksh and mksh? You wrote ksh above,
> not mksh...

no, it's really mksh. I have ksh->mksh symlink
Comment 4 Robert Scheck 2008-12-02 06:21:04 EST
Closing hereby - even if one is Fedora, other is EPEL. Same problem, once 
something comes up, I would push the update anyway to both.

*** This bug has been marked as a duplicate of bug 474115 ***