From owner-freebsd-current Fri Jun 8 1:14:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id 4444137B401 for ; Fri, 8 Jun 2001 01:14:18 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.138.245.Dial1.SanJose1.Level3.net [209.245.138.245]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA06008; Fri, 8 Jun 2001 01:13:54 -0700 (PDT) Message-ID: <3B20895B.95D0C1DD@mindspring.com> Date: Fri, 08 Jun 2001 01:14:19 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com Cc: Armin Ollig , current@FreeBSD.ORG, Dag-Erling Smorgrav Subject: Re: nsrexecd in FreeBSD current References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Jacob wrote: [ ... FreeBSD Legato client coredump ... ] > This is really a 'ports' issue... No, it's an Advocacy and commercial support of FreeBSD issue. > I don't know why this happens. It was suggested that it > was probably a bug in nsrexecd- malloc maybe. Possibly. > It doesn't always happen, as it's happily running right > now on at least one i386 running -current (June 3) and > one alpha (June 2)- but don't let the dates spoof you as > these systems were fine a month ago as well. > > Since all nsrexecd does is open a socket range and start > listening so that a remote server can connect and do NSR > style authentication, and that nsrexecd has been reported > to die right away if it dies at all, one can presume that > each instance does just about the same thing. A common Linux-derived code bug is that thaey do not bzero() the sockaddr_in before starting to fill it out. In the BSD case, this results in code that either cores immediately, or code which runs intermittently, based on local configuration (since that determines how much of the first 4k of the stack is scribbled on, instead of being left all zero's, as it was on startup, and then overlays the sockaddr_in that is the culprit). This bug is consistent with the behaviour you are seeing, and should probably be reported to the maintainer of the code (at Legato). -- Terry (who has fixed many of these in OpenLDAP, SLPv1, and other prrograms too numerous to name) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message