Article View: gnu.bash.bug
Article #956Re: problem with bash on hpux
From: Chet Ramey
Date: Fri, 20 Nov 1992 08:51
Date: Fri, 20 Nov 1992 08:51
60 lines
2759 bytes
2759 bytes
> Program: bash 1.12.1 > OS: hpux 8.07 > Machine: HP 9000/730 > Compiler: HP C A.08.71 > ---------------------------------------------------------------------- > Problem: I do the following... > > kobra> cd ~d91ali<Here I make TAB for completion> > <I break the competion with C-c> > kobra> cd ~d91ali > free: Called with already freed block argument > > Tell root@kobra to fix this someday. > Stopping myself...ABORT instruction (core dumped) This is the famous Sun YP library problem. Here's a message I sent a while back explaining it. Date: Mon, 27 Jul 1992 14:29:55 -0400 From: Chet Ramey <chet@odin.INS.CWRU.Edu> To: stud7b43@x400gate.bnr.ca Subject: Re: Bug in Bash 1.12.1 > I seem to have found a bug in Bash. > > How to cause the bug to appear: > 1) Start a long username-completion, e.g. > cat ~user<TAB> > Let it run for a while (don't know exactly how long...) > Before it's finished, hit ^C (or whatever the break character > is set to) > 2) As the next command, run a filename completion with a username in it, eg. > cat ~username/.log<TAB> > > Error message: "free: Called with already freed block argument This is a bug in the Sun YP code that everyone seems to have picked up. Sun keeps static state in the YP library code -- a pointer into the data returned from the server. When YP initializes itself (setpwent), it looks at this pointer and calls free on it if it's non-null. So far, so good. If one of the YP functions is interrupted during getpwent (the exact function is interpretwithsave()), and returns NULL, the pointer is freed without being reset to NULL, and the function returns. The next time getpwent is called, it sees that this pointer is non-null, calls free, and the Gnu free() blows up because it's being asked to free freed memory. The traditional Unix mallocs allow memory to be freed multiple times; that's probably why this has never been fixed. You can probably stop it by adding an #undef USE_GNU_MALLOC to the appropriate machine description in machines.h. Chet -- ``The use of history as therapy means the corruption of history as history.'' -- Arthur Schlesinger Chet Ramey, Case Western Reserve University Internet: chet@po.CWRU.Edu
Technical Details
Message-ID:
<9211201851.AA10342.SM@odin.INS.CWRU.Edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!odin.ins.cwru.edu!chetReferences:
chet@odin.ins.cwru.edu (Chet Ramey)Show Full Headers
Complete Article Headers
Newsgroups: gnu.bash.bug Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!odin.ins.cwru.edu!chet From: chet@odin.ins.cwru.edu (Chet Ramey) Subject: Re: problem with bash on hpux Message-ID: <9211201851.AA10342.SM@odin.INS.CWRU.Edu> Sender: gnulists@ai.mit.edu Reply-To: chet@po.cwru.edu Organization: Gnus Not Usenet References: chet@odin.ins.cwru.edu (Chet Ramey) Distribution: gnu Date: Fri, 20 Nov 1992 08:51:24 GMT Approved: bug-bash@prep.ai.mit.edu Lines: 61