From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
Description of problem:
attempting to change directory to a user account that is served from an openLDAP
server (local or remote) causes tcsh to display garbage from the user's entry.
[5:26pm] root@file:~> cd ~j2
in order to restore the prompt a control-D must be given. quite often the
terminal also needs to be reset (control-v,control-o).
Version-Release number of selected component (if applicable):
tcsh-6.12-4, openldap-2.0.27-8, nss_ldap-202-5
Steps to Reproduce:
1. use authconfig to authenticate some user accounts only to LDAP
2. use a tcsh interactive shell (I did not test in scripts)
3. attempt to cd to user's home directory using `cd ~username`
Actual Results: Termincal shows 9-12 lines of garbage apparently retrieved from
the LDAP entry in question. directory is changed but prompt is not restored.
Expected Results: change to user's directory without incident.
bash has never shown this behavior, so I take it to be a tcsh bug, though it
could also be a bug in the way tcsh interacts with nss_ldap.
switching deeper into a user's home directory (say, ~user/public_html) almost
never causes this bug, only switching to the actual home directory.
also, after a user has been accessed once it generally does not freak out again
with that user in the same session (caching?).
tcsh-6.13-6 contains a bug fix that could cause such behavior.
I have not been able to reproduce the bug, nevertheless
please test tcsh-6.13-6 when it appears in rawhide, which
should happen after FC3t2 is released.
I have tested this with tcsh-6.13-9 in a RHEL4 environment and it still exibihts
the same problem. upgraded nss_ldap and openldap as well.
it only seems to happen once per interactive login session. the problem seems
to be with retreiving the directory name itself, as it doesn't matter whether
the home directory is mounted or not for the bug to manifest.
Upgraded to RHEL 4.3 on LDAP server and new client. all newest patches (still
tcsh 6.13-9). error has now changed:
free(86fb14d) bad block. (memtop = 879c000 membot = 86ed000)
and seems to produce terminal garbage less often.
Red Hat apologizes that these issues have not been resolved yet. We do want to
make sure that no important bugs slip through the cracks.
Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/)
for security updates only. If this is a security issue, please reassign to the
'Fedora Legacy' product in bugzilla. Please note that Legacy security update
support for these products will stop on December 31st, 2006.
If this is not a security issue, please check if this issue is still present
in a current Fedora Core release. If so, please change the product and version
to match, and check the box indicating that the requested information has been
If you are currently still running Red Hat Linux 7.3 or 9, please note that
Fedora Legacy security update support for these products will stop on December
31st, 2006. You are strongly advised to upgrade to a current Fedora Core release
or Red Hat Enterprise Linux or comparable. Some information on which option may
be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/.
Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be
closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a
security issue, please change the product as necessary. We thank you for your
help, and apologize again that we haven't handled these issues to this point.
ok, I changed the product/version to RHEL4.4 and verified it exists yet today
this bug is NOT present in RHEL5...
A customer is complaining the same exact problem with RHEL 5.1 and an updated nss_ldap package (v 253-12.el5). The problem seems to don't appear with 5.1 iso package (v 253-5.el5).
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life.
Please See https://access.redhat.com/support/policy/updates/errata/
If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.