🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.bash.bug
Article #956

Re: problem with bash on hpux

#956
From: Chet Ramey
Date: Fri, 20 Nov 1992 08:51
60 lines
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!chet
References: 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