Bug 474114 - command hang in ksh and cpu workload is high
command hang in ksh and cpu workload is high
Status: CLOSED DUPLICATE of bug 474115
Product: Fedora
Classification: Fedora
Component: mksh (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Robert Scheck
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-02 05:23 EST by Michal Hlavinka
Modified: 2008-12-02 06:21 EST (History)
1 user (show)

See Also:
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:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
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 ***

Note You need to log in before you can comment on or make changes to this bug.