Bug 141322 - zsh crashes with certain values of PS1
zsh crashes with certain values of PS1
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: zsh (Show other bugs)
4
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Colin Walters
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-30 09:12 EST by kevin lyda
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 4.2.1-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-11 12:00:12 EDT
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 kevin lyda 2004-11-30 09:12:58 EST
Description of problem:

this value of PS1 will crash zsh:
    PS1="%n@%m(%@)%# "
this value will not:
    PS1="%n@%m(%T)%# "

this is on a machine upgraded from FC1 to FC3.

Version-Release number of selected component (if applicable):

zsh-4.2.0-3

How reproducible:

you can either type it in a zsh shell, or put it in a user's .zshrc
file and try logging in (assuming the user is set to use /bin/zsh as
their shell).

Steps to Reproduce:
1. create a new user account (call him floyd)
2. set floyd's shell to /bin/zsh
3. mv /home/floyd/.zshrc /home/floyd/.zshrc.old
4. echo 'export PS1="%n@%m(%@)%# "' > /home/floyd/.zshrc
5. try to login as floyd
  
Actual results:

you won't be able to login.  if you have an echo statement prior to
the PS1 line, it will echo, but you'll go back to the login prompt.

Expected results:

you'd log in.

Additional info:

i did the following as root:

strace -f -o argh su - floyd

argh is very long, but eventually it gets to:

9233  mremap(0xf1dd8000, 41943040, 83886080, MREMAP_MAYMOVE) = 0xecdd8000
9233  open("/etc/localtime", O_RDONLY)  = 3
9233  fstat64(3, {st_mode=S_IFREG|0644, st_size=1285, ...}) = 0
9233  close(3)                          = 0
9233  mremap(0xecdd8000, 83886080, 167772160, MREMAP_MAYMOVE) = 0xe2dd8000
9233  open("/etc/localtime", O_RDONLY)  = 3
9233  fstat64(3, {st_mode=S_IFREG|0644, st_size=1285, ...}) = 0
9233  close(3)                          = 0
9233  mremap(0xe2dd8000, 167772160, 335544320, MREMAP_MAYMOVE) =
0xcedd8000
9233  open("/etc/localtime", O_RDONLY)  = 3
9233  fstat64(3, {st_mode=S_IFREG|0644, st_size=1285, ...}) = 0
9233  close(3)                          = 0
9233  mremap(0xcedd8000, 335544320, 671088640, MREMAP_MAYMOVE) =
0xa6dd8000
9233  open("/etc/localtime", O_RDONLY)  = 3
9233  fstat64(3, {st_mode=S_IFREG|0644, st_size=1285, ...}) = 0
9233  close(3)                          = 0
9233  mremap(0xa6dd8000, 671088640, 1342177280, MREMAP_MAYMOVE) = -1
ENOMEM
(Cannot allocate memory)
9233  mmap2(NULL, 1342177280, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = -1 ENOMEM (Cannot allocate memory)
Comment 1 Matthew Miller 2006-07-10 18:08:47 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 2 kevin lyda 2006-07-11 04:07:17 EDT
Sorry, I've switched to Ubuntu.  Someone else will need to confirm this on FC5.

It's relatively easy to do - you can just do:

bash$ yum install zsh
bash$ PS1="%n@%m(%@)%# " zsh

If that segfaults, it's still an issue.  If not, it's not an issue.
Comment 3 kevin lyda 2006-07-11 04:42:44 EDT
OK, I pasted this on #linux on irc.linux.ie and the ever helpful Mr. Jakma tried
this out on his FC4 box:

bash$ PS1="%n@%m(%@)%# " zsh
[root@foo]/some/dir# 

Which just goes to show you should test advice before giving it - I think
/etc/zshrc or something like it resets PS1.  So just do this once you run zsh:

[root@foo]/some/dir# PS1="%n@%m(%@)%# "
root@foo( 9:49AM)# 

Perfect.  The version of zsh on this FC4 box is: zsh-4.2.1-2.  It does not
exhibit the same bug.

So unless FC5 degraded in this area I think you can close it.
Comment 4 Matthew Miller 2006-07-11 12:00:12 EDT
Marking fixed in FC4 as per comment #3. Thank you very much!

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