Path: utzoo!telly!philmtl!uunet!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!news From: chet@cwns1.CWRU.EDU (Chet Ramey) Newsgroups: gnu.bash.bug Subject: Re: bash bug report Message-ID: <1989Dec3.223522.5935@usenet.ins.cwru.edu> Date: 3 Dec 89 22:35:22 GMT References: <8912030428.AA01426@kailand.kai.com> Reply-To: chet@po.CWRU.Edu (Chet Ramey) Distribution: gnu Organization: Case Western Reserve Univ. Cleveland, Ohio, (USA) Lines: 30 In article <8912030428.AA01426@kailand.kai.com> pwolfe@kailand.kai.com (Patrick Wolfe) writes: >First, there appears to be a bug in the malloc routines. When I compiled bash >with the supplied malloc, it would die with "free: invalid argument" after >the following command sequence was executed: > > $ lf ~partial-username > $ lf ~partial-username > >The first command would work, but the second one would kill bash. When I >recompiled using the system's malloc, everything seems to work okay. This is a problem with YP (this is just one of many problems with YP) and the password routines that interact with it. These YP routines keep a socket open to the YP server, and close and reopen it when they think they need to (which is only right *some* of the time). Based on this assumption, the routines keep a pointer into the data returned from the YP server. When you do a `setpwent', setpwent frees up this storage if it thinks it needs to. This isn't always right, and you end up freeing freed storage. The Dynix free () allows you to free freed blocks; the bash free () doesn't. I tend to think the fault is with the Dynix free () and the YP routines. Chet Ramey -- Chet Ramey Network Services Group "Where's my froggie?" Case Western Reserve University chet@ins.CWRU.Edu