From owner-freebsd-hackers Mon Apr 3 18:51:10 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA27109 for hackers-outgoing; Mon, 3 Apr 1995 18:51:10 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id SAA27042; Mon, 3 Apr 1995 18:50:03 -0700 Received: by sequent.kiae.su id AA25598 (5.65.kiae-2 ); Tue, 4 Apr 1995 05:33:34 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 4 Apr 95 05:33:34 +0400 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id FAA01527; Tue, 4 Apr 1995 05:33:30 +0400 To: freebsd-bugs@FreeBSD.org, "House of Debuggin'" Cc: freebsd-hackers@FreeBSD.org References: <199504032144.RAA00659@skynet.ctr.columbia.edu> In-Reply-To: <199504032144.RAA00659@skynet.ctr.columbia.edu>; from House of Debuggin' at Mon, 3 Apr 1995 17:44:16 -0400 (EDT) Message-Id: Organization: Olahm Ha-Yetzirah Date: Tue, 4 Apr 1995 05:33:30 +0400 X-Mailer: Mail/@ [v2.32 FreeBSD] From: "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Re: emacs + NIS + free() == ???? Lines: 30 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1491 Sender: hackers-owner@FreeBSD.org Precedence: bulk In message <199504032144.RAA00659@skynet.ctr.columbia.edu> House of Debuggin' writes: >What seems to be happening is that endnetgrent() is ending up inside >emacs's own internal version of free(). getnetgrent() and endnetgrent() >are invoked by the code which I added to getpwent.c to do >+@netgroup/-@netgroup overrides. Since getnetgrent() was never called >as part of getpwuid() before, I'm tempted to think that this was a >lurking problem that I foolishly prodded into the open. That or I screwed >something up myself, which is equally likely. The best way to catch it -- track all malloc/free sequences and malloc chain consistensy. Any of malloc debugging packages will help here. Basically it hapens when: 1) You free non-malloced address. 2) You damage malloc chain by overwriting beyond requested range. >The select() man page seems to suggest that values larger than 256 >are valid. The RPC problem could be fixed by clamping the value >returned by _rpc_dtablesize() at 256, but that only gets around >what could be buggy behavior in select(). Select man page have slightly wrong information about expanding default 256 limit. I just commit manpage with proper description. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849