From owner-freebsd-bugs Sun Sep 14 00:00:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA26525 for bugs-outgoing; Sun, 14 Sep 1997 00:00:58 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA26059; Sat, 13 Sep 1997 23:59:31 -0700 (PDT) From: Joerg Wunsch Received: (from joerg@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id XAA17802; Sat, 13 Sep 1997 23:56:13 -0700 (PDT) Date: Sat, 13 Sep 1997 23:56:13 -0700 (PDT) Message-Id: <199709140656.XAA17802@freefall.freebsd.org> To: joes@spiritone.com, joerg@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/4122 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: behaviour of src/usr.sbin/syslogd State-Changed-From-To: open-closed State-Changed-By: joerg State-Changed-When: Sun Sep 14 08:55:28 MEST 1997 State-Changed-Why: Documentation slightly improved in rev 1.7 of syslog.conf(5). Apart from this, the way it works is a feature. From owner-freebsd-bugs Sun Sep 14 03:30:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA04523 for bugs-outgoing; Sun, 14 Sep 1997 03:30:06 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA04517; Sun, 14 Sep 1997 03:30:01 -0700 (PDT) Resent-Date: Sun, 14 Sep 1997 03:30:01 -0700 (PDT) Resent-Message-Id: <199709141030.DAA04517@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, sergey@nk.ukrtel.net Received: (from nobody@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA04420; Sun, 14 Sep 1997 03:27:12 -0700 (PDT) Message-Id: <199709141027.DAA04420@hub.freebsd.org> Date: Sun, 14 Sep 1997 03:27:12 -0700 (PDT) From: sergey@nk.ukrtel.net To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: i386/4533: Server with Cyclom-Y PCI card rebooted at random time without visible reason Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4533 >Category: i386 >Synopsis: Server with Cyclom-Y PCI card rebooted at random time without visible reason >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Sep 14 03:30:01 PDT 1997 >Last-Modified: >Originator: Sergey A. Kovalenko >Organization: Nikolaevtelecom >Release: 2.2.2-RELEASE >Environment: >Description: FreeBSD 2.2.2 with Cyclom-16YeP (PCI) multiport card reboot at random time without any visible reason (approx. during 10-15 min. from startup). Also, I'm observe data loss with the same multiport card even if only one port is active. >How-To-Repeat: Insert Cyclom-Y PCI card in your computer with FreeBSD, recompile kernel, and configure one port for accepting dial-in calls. Lock port at 57600 or 115200. Call to the server and transmit large file to server via ftp. During file transfer, try to compile any program, and you can see "silo overflow" messages at system console. During next 10-20 min your server rebooted itself. >Fix: Unknown >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun Sep 14 05:55:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA08642 for bugs-outgoing; Sun, 14 Sep 1997 05:55:36 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA08636; Sun, 14 Sep 1997 05:55:33 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id FAA19974; Sun, 14 Sep 1997 05:52:13 -0700 (PDT) Date: Sun, 14 Sep 1997 05:52:13 -0700 (PDT) Message-Id: <199709141252.FAA19974@freefall.freebsd.org> To: wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, asami@FreeBSD.ORG Subject: Re: misc/4235 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: /usr/share/mk/bsd.ports.mk and GNU configure Responsible-Changed-From-To: freebsd-bugs->asami Responsible-Changed-By: wosch Responsible-Changed-When: Sun Sep 14 05:51:27 PDT 1997 Responsible-Changed-Why: Satoshi Asami is the port master. From owner-freebsd-bugs Sun Sep 14 05:56:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA08760 for bugs-outgoing; Sun, 14 Sep 1997 05:56:28 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA08746; Sun, 14 Sep 1997 05:56:23 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id FAA20054; Sun, 14 Sep 1997 05:53:02 -0700 (PDT) Date: Sun, 14 Sep 1997 05:53:02 -0700 (PDT) Message-Id: <199709141253.FAA20054@freefall.freebsd.org> To: eserte@cs.tu-berlin.de, wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/4417 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: syscons: mouse pointer destroys characters State-Changed-From-To: open-analyzed State-Changed-By: wosch State-Changed-When: Sun Sep 14 05:52:25 PDT 1997 State-Changed-Why: The problem cannot be solved From owner-freebsd-bugs Sun Sep 14 05:57:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA08801 for bugs-outgoing; Sun, 14 Sep 1997 05:57:13 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA08793; Sun, 14 Sep 1997 05:57:07 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id FAA20135; Sun, 14 Sep 1997 05:53:46 -0700 (PDT) Date: Sun, 14 Sep 1997 05:53:46 -0700 (PDT) Message-Id: <199709141253.FAA20135@freefall.freebsd.org> To: eserte@cs.tu-berlin.de, wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/4416 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: syscons: problem with font State-Changed-From-To: open-analyzed State-Changed-By: wosch State-Changed-When: Sun Sep 14 05:53:15 PDT 1997 State-Changed-Why: This is not a bug in syscons. Rather it's a strange feature of MDA/EGA/VGA graphics card. From owner-freebsd-bugs Sun Sep 14 05:57:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA08845 for bugs-outgoing; Sun, 14 Sep 1997 05:57:54 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA08838; Sun, 14 Sep 1997 05:57:49 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id FAA20214; Sun, 14 Sep 1997 05:54:29 -0700 (PDT) Date: Sun, 14 Sep 1997 05:54:29 -0700 (PDT) Message-Id: <199709141254.FAA20214@freefall.freebsd.org> To: wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, phk@FreeBSD.ORG Subject: Re: bin/1702 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: installing of tcl manpages fails from make world Responsible-Changed-From-To: freebsd-bugs->phk Responsible-Changed-By: wosch Responsible-Changed-When: Sun Sep 14 05:54:00 PDT 1997 Responsible-Changed-Why: tcl is Poul-Henning Kamp's area. From owner-freebsd-bugs Sun Sep 14 07:22:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA11555 for bugs-outgoing; Sun, 14 Sep 1997 07:22:41 -0700 (PDT) Received: from room101.sysc.com (root@richmojm2.student.rose-hulman.edu [137.112.206.126]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA11550 for ; Sun, 14 Sep 1997 07:22:37 -0700 (PDT) Received: from localhost (root@localhost) by room101.sysc.com (8.8.5/8.8.5) with SMTP id JAA10631 for ; Sun, 14 Sep 1997 09:21:50 -0500 (EST) Date: Sun, 14 Sep 1997 09:21:50 -0500 (EST) From: Charlie ROOT To: freebsd-bugs@freebsd.org Subject: ide atapi cd-rom in 2.2-stable Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk hello-- i've been getting an input/output error ever since I upgraded to 2.2-stable-- I know my hardware is good because I can go back to the 2.2.2-release kernel and everything works fine ( i know how to mount a cdrom) :) is this a known or confirmed bug in 2.2-stable? i've been talking with someone else who has the same problem in a 2.2 kernel that he cvsup'ed earlier this month... please cc message via e-mail, as i don't subrscribe to this list thanks! --jay From owner-freebsd-bugs Sun Sep 14 07:58:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA13087 for bugs-outgoing; Sun, 14 Sep 1997 07:58:16 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA13082; Sun, 14 Sep 1997 07:58:04 -0700 (PDT) From: Joerg Wunsch Received: (from joerg@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id HAA07264; Sun, 14 Sep 1997 07:54:43 -0700 (PDT) Date: Sun, 14 Sep 1997 07:54:43 -0700 (PDT) Message-Id: <199709141454.HAA07264@freefall.freebsd.org> To: jose.zafra@citicorp.com, joerg@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: i386/4516 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: reboot State-Changed-From-To: open-closed State-Changed-By: joerg State-Changed-When: Sun Sep 14 16:52:44 MEST 1997 State-Changed-Why: The description is confusing enough to not understand the actual problem at all. It looks a lot like using the wrong boot device, but i would rather recommend clarification in a medium like freebsd-questions@freebsd.org, or comp.unix.bsd.freebsd.misc first, and only send a PR once it is sure that there's really a bug in FreeBSD. From owner-freebsd-bugs Sun Sep 14 11:14:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA21170 for bugs-outgoing; Sun, 14 Sep 1997 11:14:05 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21163; Sun, 14 Sep 1997 11:14:00 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA08205; Sun, 14 Sep 1997 11:10:37 -0700 (PDT) Date: Sun, 14 Sep 1997 11:10:37 -0700 (PDT) Message-Id: <199709141810.LAA08205@freefall.freebsd.org> To: laskavy@cs.msu.su, wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/4004 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: moused(8) + international language text = incompatibility State-Changed-From-To: open-analyzed State-Changed-By: wosch State-Changed-When: Sun Sep 14 11:09:44 PDT 1997 State-Changed-Why: The problem cannot be solved From owner-freebsd-bugs Sun Sep 14 11:17:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA21369 for bugs-outgoing; Sun, 14 Sep 1997 11:17:30 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21325; Sun, 14 Sep 1997 11:16:26 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA08288; Sun, 14 Sep 1997 11:13:04 -0700 (PDT) Date: Sun, 14 Sep 1997 11:13:04 -0700 (PDT) Message-Id: <199709141813.LAA08288@freefall.freebsd.org> To: johan@moon.campus.luth.se, wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/4180 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: Missing manpage? State-Changed-From-To: open-closed State-Changed-By: wosch State-Changed-When: Sun Sep 14 11:11:00 PDT 1997 State-Changed-Why: Jordan wrote a manpage and forgot to closed this PR. From owner-freebsd-bugs Sun Sep 14 11:20:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA21547 for bugs-outgoing; Sun, 14 Sep 1997 11:20:48 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21539; Sun, 14 Sep 1997 11:20:38 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA08419; Sun, 14 Sep 1997 11:17:15 -0700 (PDT) Date: Sun, 14 Sep 1997 11:17:15 -0700 (PDT) Message-Id: <199709141817.LAA08419@freefall.freebsd.org> To: nick@foobar.org, wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/4134 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: Potential bufferflow in getpwent(), getpwnam() and getpwuid() State-Changed-From-To: open-closed State-Changed-By: wosch State-Changed-When: Sun Sep 14 11:13:21 PDT 1997 State-Changed-Why: Submitted patch applied. Thanks! src/lib/libc/gen/getpwent.c,v revision: 1.41 From owner-freebsd-bugs Sun Sep 14 11:22:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA21701 for bugs-outgoing; Sun, 14 Sep 1997 11:22:58 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21679; Sun, 14 Sep 1997 11:22:33 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA08578; Sun, 14 Sep 1997 11:19:11 -0700 (PDT) Date: Sun, 14 Sep 1997 11:19:11 -0700 (PDT) Message-Id: <199709141819.LAA08578@freefall.freebsd.org> To: wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: conf/4252 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: sendmail doesn't use smrsh by default Responsible-Changed-From-To: freebsd-bugs->peter Responsible-Changed-By: wosch Responsible-Changed-When: Sun Sep 14 11:18:27 PDT 1997 Responsible-Changed-Why: Sendmail security is Peter's area. From owner-freebsd-bugs Sun Sep 14 11:23:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA21747 for bugs-outgoing; Sun, 14 Sep 1997 11:23:19 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21730; Sun, 14 Sep 1997 11:23:15 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA08656; Sun, 14 Sep 1997 11:19:52 -0700 (PDT) Date: Sun, 14 Sep 1997 11:19:52 -0700 (PDT) Message-Id: <199709141819.LAA08656@freefall.freebsd.org> To: wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, steve@FreeBSD.ORG Subject: Re: bin/4254 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: make in free(): warning: chunk is already free Responsible-Changed-From-To: freebsd-bugs->steve Responsible-Changed-By: wosch Responsible-Changed-When: Sun Sep 14 11:19:24 PDT 1997 Responsible-Changed-Why: make is Steve Passe area. From owner-freebsd-bugs Sun Sep 14 11:24:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA21823 for bugs-outgoing; Sun, 14 Sep 1997 11:24:02 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21804; Sun, 14 Sep 1997 11:23:52 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA08737; Sun, 14 Sep 1997 11:20:30 -0700 (PDT) Date: Sun, 14 Sep 1997 11:20:30 -0700 (PDT) Message-Id: <199709141820.LAA08737@freefall.freebsd.org> To: wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: kern/4271 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: System crashed caused by moving mouse pointer. Responsible-Changed-From-To: freebsd-bugs->sos Responsible-Changed-By: wosch Responsible-Changed-When: Sun Sep 14 11:20:07 PDT 1997 Responsible-Changed-Why: Søren Schmidt area. From owner-freebsd-bugs Sun Sep 14 11:24:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA21834 for bugs-outgoing; Sun, 14 Sep 1997 11:24:04 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21601; Sun, 14 Sep 1997 11:21:30 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA08497; Sun, 14 Sep 1997 11:18:08 -0700 (PDT) Date: Sun, 14 Sep 1997 11:18:08 -0700 (PDT) Message-Id: <199709141818.LAA08497@freefall.freebsd.org> To: wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, wpaul@FreeBSD.ORG Subject: Re: misc/4249 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: ypchsh doesn't care about changing a user shell Responsible-Changed-From-To: freebsd-bugs->wpaul Responsible-Changed-By: wosch Responsible-Changed-When: Sun Sep 14 11:17:33 PDT 1997 Responsible-Changed-Why: YP is Bill Pauls area. From owner-freebsd-bugs Sun Sep 14 11:25:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA21963 for bugs-outgoing; Sun, 14 Sep 1997 11:25:35 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21954; Sun, 14 Sep 1997 11:25:27 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA08894; Sun, 14 Sep 1997 11:22:05 -0700 (PDT) Date: Sun, 14 Sep 1997 11:22:05 -0700 (PDT) Message-Id: <199709141822.LAA08894@freefall.freebsd.org> To: wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, jlemon@FreeBSD.ORG Subject: Re: bin/4354 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: make *world fails because of dependency on X11R6 Responsible-Changed-From-To: freebsd-bugs->jlemon Responsible-Changed-By: wosch Responsible-Changed-When: Sun Sep 14 11:21:22 PDT 1997 Responsible-Changed-Why: Jonathan Lemon was hired to fix the DOS emulator. From owner-freebsd-bugs Sun Sep 14 11:25:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA21986 for bugs-outgoing; Sun, 14 Sep 1997 11:25:42 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21906; Sun, 14 Sep 1997 11:24:32 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA08815; Sun, 14 Sep 1997 11:21:10 -0700 (PDT) Date: Sun, 14 Sep 1997 11:21:10 -0700 (PDT) Message-Id: <199709141821.LAA08815@freefall.freebsd.org> To: wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, ache@FreeBSD.ORG Subject: Re: gnu/4290 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: man wrong viewed koi8-r manpages and neqn wrong defined default device Responsible-Changed-From-To: freebsd-bugs->ache Responsible-Changed-By: wosch Responsible-Changed-When: Sun Sep 14 11:20:41 PDT 1997 Responsible-Changed-Why: Internationalization is Andrey A. Chernov area. From owner-freebsd-bugs Sun Sep 14 11:27:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA22076 for bugs-outgoing; Sun, 14 Sep 1997 11:27:00 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA22069; Sun, 14 Sep 1997 11:26:57 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA09050; Sun, 14 Sep 1997 11:23:35 -0700 (PDT) Date: Sun, 14 Sep 1997 11:23:35 -0700 (PDT) Message-Id: <199709141823.LAA09050@freefall.freebsd.org> To: wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, wpaul@FreeBSD.ORG Subject: Re: bin/4452 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: /etc/ethers and NIS: Bad comment parser Responsible-Changed-From-To: freebsd-bugs->wpaul Responsible-Changed-By: wosch Responsible-Changed-When: Sun Sep 14 11:23:06 PDT 1997 Responsible-Changed-Why: YP is Bill Paul area. From owner-freebsd-bugs Sun Sep 14 11:27:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA22144 for bugs-outgoing; Sun, 14 Sep 1997 11:27:54 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA22135; Sun, 14 Sep 1997 11:27:45 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA09135; Sun, 14 Sep 1997 11:24:23 -0700 (PDT) Date: Sun, 14 Sep 1997 11:24:23 -0700 (PDT) Message-Id: <199709141824.LAA09135@freefall.freebsd.org> To: wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, bde@FreeBSD.ORG Subject: Re: bin/4459 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: No prototype for moncontrol(3) and monstartup(3) Responsible-Changed-From-To: freebsd-bugs->bde Responsible-Changed-By: wosch Responsible-Changed-When: Sun Sep 14 11:23:49 PDT 1997 Responsible-Changed-Why: Fixing include files/prototypes is Bruce's hobby. From owner-freebsd-bugs Sun Sep 14 11:30:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA22359 for bugs-outgoing; Sun, 14 Sep 1997 11:30:18 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA22350; Sun, 14 Sep 1997 11:30:13 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA09253; Sun, 14 Sep 1997 11:26:50 -0700 (PDT) Date: Sun, 14 Sep 1997 11:26:50 -0700 (PDT) Message-Id: <199709141826.LAA09253@freefall.freebsd.org> To: hfir@math.rochester.edu, wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: docs/4462 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: -p flag misdocumented in telnetd(8) State-Changed-From-To: open-closed State-Changed-By: wosch State-Changed-When: Sun Sep 14 11:25:42 PDT 1997 State-Changed-Why: Fixed. Thanks! src/libexec/telnetd/telnetd.8,v revision: 1.9 From owner-freebsd-bugs Sun Sep 14 12:10:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA24466 for bugs-outgoing; Sun, 14 Sep 1997 12:10:06 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA24459; Sun, 14 Sep 1997 12:10:01 -0700 (PDT) Resent-Date: Sun, 14 Sep 1997 12:10:01 -0700 (PDT) Resent-Message-Id: <199709141910.MAA24459@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, "K.J.Koster" Received: from mercury.ukc.ac.uk (mercury.ukc.ac.uk [129.12.21.10]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA24063 for ; Sun, 14 Sep 1997 12:04:03 -0700 (PDT) Received: from kestrel.ukc.ac.uk by mercury.ukc.ac.uk with SMTP (PP); Sun, 14 Sep 1997 20:03:46 +0100 Received: from localhost by kestrel.ukc.ac.uk (5.x/UKC-2.14) id AA18796; Sun, 14 Sep 1997 20:03:45 +0100 Message-Id: Date: Sun, 14 Sep 1997 20:03:45 +0100 (BST) From: "K.J.Koster" To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: i386/4538: byteswapped ATAPI id strings Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4538 >Category: i386 >Synopsis: byteswapped ATAPI id strings >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun Sep 14 12:10:00 PDT 1997 >Last-Modified: >Originator: Kees Jan Koster >Organization: >Release: FreeBSD 2.2.2-RELEASE i386 >Environment: Motherboard: DataExpert 8661 cdrom player: BTC 8x ATAPI previous cdrom player: Pioneer 4x ATAPI dmesg output before applying fix: wdc0: unit 1 (atapi): , removable, iordis dmesg output after applying fix: wdc0: unit 1 (atapi): , removable, iordis >Description: The ID string and the revision strings come out byteswapped. It happened to both my pioneer and my btc drive. The BIOS autodetection also identifies the cdrom player with its bytes swapped, so I blame my BIOS. It annoyed me, so I propose the following kernel config option: options SWAB_ATAPI_ID >How-To-Repeat: n/a ============================================================== Patch for the LINT kernel (/sys/i386/conf/LINT) ============================================================== *** LINT.orig Sun Sep 14 18:19:19 1997 --- LINT Sun Sep 14 18:23:38 1997 *************** *** 641,646 **** --- 641,653 ---- options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC #Don't do it as an LKM + # + # In some cases, the ID and revision strings of the ATAPI device come out + # byteswapped. Use this option to swap them back. This option is purely + # cosmetic and has no influence on the operation of the device. + # + options SWAB_ATAPI_ID #Byteswap the ID and revision strings + # IDE CD-ROM driver - requires wdc controller and ATAPI option device wcd0 ============================================================== Patch for the atapi driver (/sys/i386/isa/atapi.c): ============================================================== *** atapi.c.orig Fri Jan 17 17:02:33 1997 --- atapi.c Sun Sep 14 18:14:34 1997 *************** *** 173,178 **** --- 173,202 ---- extern int wdstart (int ctrlr); extern int wcdattach(struct atapi*, int, struct atapi_params*, int); + #ifdef SWAB_ATAPI_ID + /* copied verbatim from swap.c in the library sources */ + static void + swab(const void *from, void *to, size_t len) + { + register unsigned long temp; + register int n; + register char *fp, *tp; + + n = (len >> 1) + 1; + fp = (char *)from; + tp = (char *)to; + #define STEP temp = *fp++,*tp++ = *fp++,*tp++ = temp + /* round to multiple of 8 */ + while ((--n) & 07) + STEP; + n >>= 3; + while (--n >= 0) { + STEP; STEP; STEP; STEP; + STEP; STEP; STEP; STEP; + } + } + #endif + /* * Probe the ATAPI device at IDE controller `ctlr', drive `unit'. * Called at splbio(). *************** *** 193,204 **** if (! ap) return (0); bcopy (ap->model, buf, sizeof(buf)-1); buf[sizeof(buf)-1] = 0; bcopy (ap->revision, revbuf, sizeof(revbuf)-1); revbuf[sizeof(revbuf)-1] = 0; ! printf ("wdc%d: unit %d (atapi): <%s/%s>", ctlr, unit, buf, revbuf); /* device is removable */ --- 217,235 ---- if (! ap) return (0); + #ifdef SWAB_ATAPI_ID + swab (ap->model, buf, sizeof(buf)-1); + buf[sizeof(buf)-1] = 0; + + swab (ap->revision, revbuf, sizeof(revbuf)-1); + revbuf[sizeof(revbuf)-1] = 0; + #else bcopy (ap->model, buf, sizeof(buf)-1); buf[sizeof(buf)-1] = 0; bcopy (ap->revision, revbuf, sizeof(revbuf)-1); revbuf[sizeof(revbuf)-1] = 0; ! #endif printf ("wdc%d: unit %d (atapi): <%s/%s>", ctlr, unit, buf, revbuf); /* device is removable */ ============================================================== Suggested addition to the handbook and to the wcd manual page: ============================================================== (in the section covering device wcd?) In some cases, the ID and revision strings of the ATAPI device come out byteswapped. Use this option to swap them back. This option is purely cosmetic and has no influence on the operation of the device. >Fix: >Audit-Trail: >Unformatted: X-send-pr-version: 3.2 From owner-freebsd-bugs Sun Sep 14 12:39:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA25510 for bugs-outgoing; Sun, 14 Sep 1997 12:39:46 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA25432; Sun, 14 Sep 1997 12:38:42 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id MAA09699; Sun, 14 Sep 1997 12:35:19 -0700 (PDT) Date: Sun, 14 Sep 1997 12:35:19 -0700 (PDT) Message-Id: <199709141935.MAA09699@freefall.freebsd.org> To: wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, ache@FreeBSD.ORG Subject: Re: bin/4466 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: Locale bug in /usr/bin/write Responsible-Changed-From-To: freebsd-bugs->ache Responsible-Changed-By: wosch Responsible-Changed-When: Sun Sep 14 12:34:39 PDT 1997 Responsible-Changed-Why: Internationalization is Andrey A. Chernov area. From owner-freebsd-bugs Sun Sep 14 12:39:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA25524 for bugs-outgoing; Sun, 14 Sep 1997 12:39:50 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA25491; Sun, 14 Sep 1997 12:39:37 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id MAA09778; Sun, 14 Sep 1997 12:36:15 -0700 (PDT) Date: Sun, 14 Sep 1997 12:36:15 -0700 (PDT) Message-Id: <199709141936.MAA09778@freefall.freebsd.org> To: wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, jdp@FreeBSD.ORG Subject: Re: misc/4482 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: A bug in dynamic loader design Responsible-Changed-From-To: freebsd-bugs->jdp Responsible-Changed-By: wosch Responsible-Changed-When: Sun Sep 14 12:35:30 PDT 1997 Responsible-Changed-Why: Dynamic loader are John Polstra area. From owner-freebsd-bugs Sun Sep 14 12:40:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA25671 for bugs-outgoing; Sun, 14 Sep 1997 12:40:46 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA25663; Sun, 14 Sep 1997 12:40:38 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id MAA09949; Sun, 14 Sep 1997 12:37:15 -0700 (PDT) Date: Sun, 14 Sep 1997 12:37:15 -0700 (PDT) Message-Id: <199709141937.MAA09949@freefall.freebsd.org> To: wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: bin/4484 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: sendmail is barfing Responsible-Changed-From-To: freebsd-bugs->peter Responsible-Changed-By: wosch Responsible-Changed-When: Sun Sep 14 12:36:26 PDT 1997 Responsible-Changed-Why: Sendmail is Peter's area. From owner-freebsd-bugs Sun Sep 14 13:05:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA27496 for bugs-outgoing; Sun, 14 Sep 1997 13:05:15 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA27488; Sun, 14 Sep 1997 13:05:11 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id NAA10293; Sun, 14 Sep 1997 13:05:10 -0700 (PDT) To: Wolfram Schneider cc: johan@moon.campus.luth.se, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/4180 In-reply-to: Your message of "Sun, 14 Sep 1997 11:13:04 PDT." <199709141813.LAA08288@freefall.freebsd.org> Date: Sun, 14 Sep 1997 13:05:10 -0700 Message-ID: <10289.874267510@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I closed a PR, but I didn't know there was more than once against the same topic. :) This probably should have been collapsed into the earlier PR when it was received. > Synopsis: Missing manpage? > > State-Changed-From-To: open-closed > State-Changed-By: wosch > State-Changed-When: Sun Sep 14 11:11:00 PDT 1997 > State-Changed-Why: > > Jordan wrote a manpage and forgot to closed this PR. From owner-freebsd-bugs Sun Sep 14 13:29:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA28492 for bugs-outgoing; Sun, 14 Sep 1997 13:29:17 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA28456; Sun, 14 Sep 1997 13:28:07 -0700 (PDT) From: Wolfram Schneider Received: (from wosch@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id NAA11011; Sun, 14 Sep 1997 13:24:44 -0700 (PDT) Date: Sun, 14 Sep 1997 13:24:44 -0700 (PDT) Message-Id: <199709142024.NAA11011@freefall.freebsd.org> To: zgabor@CoDe.hu@CoDe.hu, wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: docs/2874 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: The gencat command hasn't got a manual page. State-Changed-From-To: open-closed State-Changed-By: wosch State-Changed-When: Sun Sep 14 13:23:58 PDT 1997 State-Changed-Why: FreeBSD has now a gencat manpage. From owner-freebsd-bugs Sun Sep 14 13:40:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA29091 for bugs-outgoing; Sun, 14 Sep 1997 13:40:03 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA29075; Sun, 14 Sep 1997 13:40:01 -0700 (PDT) Resent-Date: Sun, 14 Sep 1997 13:40:01 -0700 (PDT) Resent-Message-Id: <199709142040.NAA29075@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, blank@fox.uni-trier.de Received: from sliphost37.uni-trier.de (root@sliphost37.uni-trier.de [136.199.240.37]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA28647 for ; Sun, 14 Sep 1997 13:31:25 -0700 (PDT) Received: (from blank@localhost) by sliphost37.uni-trier.de (8.8.7/8.8.7) id SAA09834; Sun, 14 Sep 1997 18:47:17 +0200 (CEST) Message-Id: <199709141647.SAA09834@sliphost37.uni-trier.de> Date: Sun, 14 Sep 1997 18:47:17 +0200 (CEST) From: blank@fox.uni-trier.de (Sascha Blank) Reply-To: blank@fox.uni-trier.de To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: docs/4539: Wrong genitive in submitters.sgml Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4539 >Category: docs >Synopsis: Wrong genitive from in submitters.sgml >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Sun Sep 14 13:40:01 PDT 1997 >Last-Modified: >Originator: Sascha Blank >Organization: >Release: FreeBSD 2.2-STABLE i386 >Environment: ident /usr/src/doc/handbook/submitters.sgml: $Id: submitters.sgml,v 1.102 1997/09/12 08:15:59 tg Exp $ >Description: Instead of "whose" there is a "who's". >How-To-Repeat: >Fix: *** submitters.sgml.CURRENT Sun Sep 14 18:42:58 1997 --- submitters.sgml Sun Sep 14 18:43:09 1997 *************** *** 15,21 **** need to be a hot-shot programmer or a close personal friend of the FreeBSD core team in order to have your contributions accepted. The FreeBSD Project's development is done by a large and growing number of ! international contributors who's ages and areas of technical expertise vary greatly, and there is always more work to be done than there are people available to do it. --- 15,21 ---- need to be a hot-shot programmer or a close personal friend of the FreeBSD core team in order to have your contributions accepted. The FreeBSD Project's development is done by a large and growing number of ! international contributors whose ages and areas of technical expertise vary greatly, and there is always more work to be done than there are people available to do it. -- Sascha Blank - mailto:blank@fox.uni-trier.de Student and System Administrator at the University of Trier, Germany Finger my account to receive my Public PGP key I don't speak for my employers, they don't pay me enough for that. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun Sep 14 15:10:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA04378 for bugs-outgoing; Sun, 14 Sep 1997 15:10:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA04369; Sun, 14 Sep 1997 15:10:01 -0700 (PDT) Resent-Date: Sun, 14 Sep 1997 15:10:01 -0700 (PDT) Resent-Message-Id: <199709142210.PAA04369@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, blaz@amis.net Received: from server.amis.net (blaz@server.amis.net [193.77.234.34]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA04028 for ; Sun, 14 Sep 1997 15:07:25 -0700 (PDT) Received: (from uucp@localhost) by server.amis.net (8.8.7/8.8.6/970802) with UUCP id AAA02141 for FreeBSD-gnats-submit@freebsd.org; Mon, 15 Sep 1997 00:04:53 +0200 (CEST) Received: (from blaz@localhost) by gold.amis.net (8.8.6/8.8.5) id AAA00855; Mon, 15 Sep 1997 00:04:25 +0200 (CEST) Message-Id: <199709142204.AAA00855@gold.amis.net> Date: Mon, 15 Sep 1997 00:04:25 +0200 (CEST) From: blaz@amis.net Reply-To: blaz@amis.net To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/4541: Data needed for slovene localization Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4541 >Category: bin >Synopsis: Data needed for slovene localization >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun Sep 14 15:10:00 PDT 1997 >Last-Modified: >Originator: Blaz Zupan >Organization: Medinet >Release: FreeBSD 2.2-STABLE i386 >Environment: >Description: I'm sending this as a PR to make sure it does not get lost. This is all the data needed for slovene localization of FreeBSD. The needed files are: - si.iso.kbd (syscons slovene keymap) to be put in /usr/src/share/syscons/keymaps - iso-8859-2-8x8.fnt, iso-8859-2-8x14.fnt and iso-8859-2-8x16.fnt fonts for syscons, to be put in /usr/src/share/syscons/fonts - si_SI.ISO_8859-2.src localized time strings to be put in /usr/src/share/timedef/data The si.iso.kbd keymap can also be installed as hr.iso.kbd because the croatian and slovene keymaps are exactly the same (as far as I know). Note that there is already an iso-8859-2-8x16.fnt in FreeBSD, but IMHO it is ugly. The one here looks the same as the usual BIOS font on most PC's and is available in all three standard sizes. The si.iso.kbd keymap was created by me, the font files were copied from the Linux kbd package. They were originally created by Kosta Kostis. I tried contacting the author but mail to kosta@blues.sub.de bounces. As the kbd archive has been widely distributed I guess those font files are in the public domain (the original archive contained no copyright statement). The original archive can be found at ftp://ftp.uni-erlangen.de/pub/doc/ISO/charsets/isofont101.tar.gz >How-To-Repeat: Install FreeBSD and notice that there is close to no support for iso-8859-2 languages and no support for slovene. >Fix: Download si-locale.tar.gz from ftp://ftp.amis.net/pub/FreeBSD/ and add the files to the system. After adding the files to the appropriate directories and changing the appropriate makefiles apply the following simple patch to /usr/src/usr.bin/mklocale/data/Makefile: --- Makefile.old Fri Feb 28 23:54:47 1997 +++ Makefile Sun Sep 14 23:51:21 1997 @@ -24,7 +24,7 @@ fr_BE fr_CA fr_CH fr_FR is_IS it_CH it_IT nl_BE nl_NL no_NO \ pt_PT sv_SE -LATIN2LINKS = hr_HR +LATIN2LINKS = hr_HR si_SI .SUFFIXES: .src .out >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun Sep 14 15:20:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA05601 for bugs-outgoing; Sun, 14 Sep 1997 15:20:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA05592; Sun, 14 Sep 1997 15:20:02 -0700 (PDT) Resent-Date: Sun, 14 Sep 1997 15:20:02 -0700 (PDT) Resent-Message-Id: <199709142220.PAA05592@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, blaz@amis.net Received: from server.amis.net (uucp@server.amis.net [193.77.234.34]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA05037 for ; Sun, 14 Sep 1997 15:14:59 -0700 (PDT) Received: (from uucp@localhost) by server.amis.net (8.8.7/8.8.6/970802) with UUCP id AAA02388 for FreeBSD-gnats-submit@freebsd.org; Mon, 15 Sep 1997 00:14:54 +0200 (CEST) Received: (from blaz@localhost) by gold.amis.net (8.8.6/8.8.5) id AAA01037; Mon, 15 Sep 1997 00:15:02 +0200 (CEST) Message-Id: <199709142215.AAA01037@gold.amis.net> Date: Mon, 15 Sep 1997 00:15:02 +0200 (CEST) From: blaz@amis.net Reply-To: blaz@amis.net To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: docs/4542: Slovene WWW and FTP mirrors of FreeBSD Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4542 >Category: docs >Synopsis: Slovene WWW and FTP mirrors of FreeBSD >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun Sep 14 15:20:01 PDT 1997 >Last-Modified: >Originator: Blaz Zupan >Organization: Medinet >Release: FreeBSD 2.2-STABLE i386 >Environment: >Description: For some time now I am operating www.si.freebsd.org and there is also a ftp.si.freebsd.org (an alias for sunsite.fri.uni-lj.si, operated by sunsite@snet.fri.uni-lj.si). I have already sent a request to www@freebsd.org with no reply, so I'm filing this as a PR now :) >How-To-Repeat: Live in Slovenia and try to find a close mirror of the FreeBSD www pages and ftp site. >Fix: Add mirrors to appropriate documentation and www files :) >Audit-Trail: >Unformatted: From owner-freebsd-bugs Sun Sep 14 16:00:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA08758 for bugs-outgoing; Sun, 14 Sep 1997 16:00:06 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA08738; Sun, 14 Sep 1997 16:00:01 -0700 (PDT) Date: Sun, 14 Sep 1997 16:00:01 -0700 (PDT) Message-Id: <199709142300.QAA08738@hub.freebsd.org> To: freebsd-bugs Cc: From: Blaz Zupan Subject: Re: bin/4541: Data needed for slovene localization Reply-To: Blaz Zupan Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR bin/4541; it has been noted by GNATS. From: Blaz Zupan To: freebsd-gnats-submit@freebsd.org, blaz@amis.net Cc: Subject: Re: bin/4541: Data needed for slovene localization Date: Mon, 15 Sep 1997 00:52:55 +0200 I just noticed that the correct ISO two letter code for Slovenian iz "sl" instead of "si" (si is the two-letter country code). So the correct locale name is sl_SI.ISO_8859-2.src, so please consider this when making the changes (the patch for the Makefile is also wrong, it should add sl_SI to LATIN2LINKS instead of si_SI). -- Blaz Zupan, blaz@amis.net, http://www.amis.net/staff/blaz Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia From owner-freebsd-bugs Sun Sep 14 22:30:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA00754 for bugs-outgoing; Sun, 14 Sep 1997 22:30:08 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA00733; Sun, 14 Sep 1997 22:30:02 -0700 (PDT) Resent-Date: Sun, 14 Sep 1997 22:30:02 -0700 (PDT) Resent-Message-Id: <199709150530.WAA00733@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, mi@aldan.ziplink.net Received: from xxx.video-collage.com (xxx.video-collage.com [199.232.254.68]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA00546 for ; Sun, 14 Sep 1997 22:27:29 -0700 (PDT) Received: (from mi@localhost) by xxx.video-collage.com (8.8.5/8.8.5) id BAA21763; Mon, 15 Sep 1997 01:27:22 -0400 (EDT) Message-Id: <199709150527.BAA21763@xxx.video-collage.com> Date: Mon, 15 Sep 1997 01:27:22 -0400 (EDT) From: Mikhail Teterin Reply-To: mi@aldan.ziplink.net To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/4545: no way to specify an alternative `cc' to `f77' Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4545 >Category: bin >Synopsis: f77 will only call `cc', no com-line option, will not check the environment >Confidential: yes >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Sun Sep 14 22:30:01 PDT 1997 >Last-Modified: >Originator: Mikhail Teterin >Organization: >Release: FreeBSD 2.2.1-RELEASE i386 >Environment: >Description: f77 will only call `cc'. There is no (documented) way to specify an alternative (such as pgcc). This makes it impossible to squeeze the most of the Pentium CPU. >How-To-Repeat: CC=pgcc CFLAGS="-mno-486 -mpentium -O2" FFLAGS=$(CFLAGS) >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Mon Sep 15 01:26:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA12778 for bugs-outgoing; Mon, 15 Sep 1997 01:26:16 -0700 (PDT) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA12759 for ; Mon, 15 Sep 1997 01:26:11 -0700 (PDT) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.203]) by innocence.interface-business.de (8.6.11/8.6.9) with SMTP id KAA22017; Mon, 15 Sep 1997 10:26:01 +0200 Received: (from j@localhost) by ida.interface-business.de (8.8.7/8.7.3) id KAA21569; Mon, 15 Sep 1997 10:26:00 +0200 (MET DST) Message-ID: <19970915102600.YM40752@ida.interface-business.de> Date: Mon, 15 Sep 1997 10:26:00 +0200 From: j@ida.interface-business.de (J Wunsch) To: bde@zeta.org.au (Bruce Evans) Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/4486 References: <199709130509.PAA20233@godzilla.zeta.org.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface business GmbH, Dresden Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) In-Reply-To: <199709130509.PAA20233@godzilla.zeta.org.au>; from Bruce Evans on Sep 13, 1997 15:09:59 +1000 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Bruce Evans wrote: > >> Does the broken system also hang for 64-bit video accesses via the FPU? > > > >How would this be done? > > Just access it via 64-bit FPU instructions. Nope, it doesn't hang. It displays some random garbage in the top half of the screen, but i thought this was indended, wasn't it? -- J"org Wunsch Unix support engineer joerg_wunsch@interface-business.de http://www.interface-business.de/~j From owner-freebsd-bugs Mon Sep 15 05:00:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA24567 for bugs-outgoing; Mon, 15 Sep 1997 05:00:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA24529; Mon, 15 Sep 1997 05:00:02 -0700 (PDT) Resent-Date: Mon, 15 Sep 1997 05:00:02 -0700 (PDT) Resent-Message-Id: <199709151200.FAA24529@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, luigi@iet.unipi.it Received: from prova.iet.unipi.it (prova.iet.unipi.it [131.114.9.236]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA24117 for ; Mon, 15 Sep 1997 04:51:12 -0700 (PDT) Received: (from luigi@localhost) by prova.iet.unipi.it (8.8.5/8.8.5) id NAA00546; Mon, 15 Sep 1997 13:51:28 +0200 (CEST) Message-Id: <199709151151.NAA00546@prova.iet.unipi.it> Date: Mon, 15 Sep 1997 13:51:28 +0200 (CEST) From: Luigi Rizzo Reply-To: luigi@iet.unipi.it To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: i386/4547: asc.c and pcaudio.c should use selrecord() Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4547 >Category: i386 >Synopsis: asc.c and pcaudio.c should use selrecord >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Mon Sep 15 05:00:01 PDT 1997 >Last-Modified: >Originator: Luigi Rizzo >Organization: DEIT >Release: FreeBSD -current >Environment: all releases up to -current of 15 sep. 97 >Description: asc.c and pcaudio.c (device drivers in /sys/i386/isa) should be converted to use selrecord() instead of explicitly managing the struct selinfo. >How-To-Repeat: -- >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Mon Sep 15 05:20:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA25441 for bugs-outgoing; Mon, 15 Sep 1997 05:20:25 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA25423; Mon, 15 Sep 1997 05:20:17 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id OAA01565; Mon, 15 Sep 1997 14:24:49 +0200 (SAT) Received: by citadel via recvmail id 1532; Mon Sep 15 14:24:33 1997 by gram.cdsec.com (8.8.5/8.8.5) id NAA27754; Mon, 15 Sep 1997 13:51:14 +0200 (SAT) From: Graham Wheeler Message-Id: <199709151151.NAA27754@cdsec.com> Subject: Re: Memory leak in getservbyXXX? To: julian@whistle.com (Julian Elischer) Date: Mon, 15 Sep 1997 13:51:14 +0200 (SAT) Cc: hackers@freebsd.org, freebsd-bugs@freebsd.org In-Reply-To: <3419A0D8.7DE14518@whistle.com> from "Julian Elischer" at Sep 12, 97 01:06:48 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Mike Smith wrote: > > > > > > If it's a memory leak then it sounds like it's inside the stdio > > > > library, possibly in fopen()/fclose(). Without more data it's going to > > > > be hard to track this one. > > > > > > Tell me about it 8-( > > > > > > It does seem like a memory leak, as the memory use reported by top grows > > > over time. I have memory allocation debugging code which confirms that > > > I have no leaks in my code (at least of C++ objects), and the fact that > > > older sites have been running for months seems to confirm this. > > > > OK. More to the point then it sounds like it's a memory leak due to > > some change in stdio. That's getting slightly easier to chase I > > they aren't using the threaded libc are they? How would I know this? I'm not explicitly saying which; just doing a normal link. I have a static, a shared, and a profiled libc in /usr/lib. Does the threaded libc have a different name, or is it now the default, or does it depend on how libc is compiled? Incidentally, going back to the original problem: I now have about 15 core dumps. Two happened when the program itself dumped the core, the rest were caused by sending SIGABRTs after the program started spinning. These are all after I added the setservent(1) call at the start, so they no longer happen in getservbyXXX. However, in each case the stack backtrace ends in malloc or free. I also have every `new' followed by an assert, and have set the D, A and Z options to malloc; none of these have made a difference. So I'm starting to believe that the problem is heap corruption rather than heap exhaustion, so tools like mprof are probably not much use. It's interesting though that this only happens with 2.2.2, and not under 2.1.0; mayhap it's a problem with gcc somewhere. regards graham -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-bugs Mon Sep 15 10:07:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA10013 for bugs-outgoing; Mon, 15 Sep 1997 10:07:59 -0700 (PDT) Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA09341 for freebsd-bugs@freebsd.org; Mon, 15 Sep 1997 10:00:27 -0700 (PDT) Date: Mon, 15 Sep 1997 10:00:27 -0700 (PDT) Message-Id: <199709151700.KAA09341@hub.freebsd.org> From: FreeBSD bugmaster To: FreeBSD bugs list Subject: Current problem reports Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Current FreeBSD problem reports The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The report has been examined by a team member and evaluated. f - feedback The problem has been solved, and the originator has been given a patch or a fix has been committed. The PR remains in this state pending a response from the originator. s - suspended Work on the problem has been postponed. This happens if a timely solution is not possible or is not cost-effective at the present time. The PR continues to exist, though a solution is not being actively sought. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested. Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [1995/01/11] i386/105 bde Distributed libm (msun) has non-standard o [1995/02/14] kern/216 davidg /kernel: panic: ffs_alloccg: map corrupte a [1996/01/22] kern/965 bde 2.0.5: system crashes daily because of "m o [1996/04/06] kern/1121 dyson System crashes on boot up just after the o [1996/05/07] kern/1177 dyson Machine hangs with message "vm_fork: no p o [1996/06/05] kern/1293 brian Fatal trap 12: page fault while in kernel o [1996/06/11] kern/1311 dyson Panic: vm_page_free while installing new a [1996/07/15] bin/1387 davidn Group file errors cause absolute havoc a [1996/08/09] kern/1487 bde bug in exec(2) o [1996/09/11] kern/1599 panic: locking against myself s [1996/09/13] conf/1608 FreeBSD's bug tracking system does not re o [1996/09/30] kern/1698 sup from around 21:51 GMT 28th very unsta a [1996/10/08] kern/1744 run queue or proc list smashed 4 times in o [1996/10/13] kern/1790 access to /dev/kmem panics system f [1996/10/28] kern/1919 se access to files/directories fails, gives o [1996/11/01] kern/1940 TCP doesn't time out of FIN_WAIT_1 and fl o [1996/11/04] i386/1959 DELAY() won't work for fast CPUs o [1996/11/29] kern/2121 MAXBSIZE in param.h causes kernel panic i o [1996/12/14] i386/2218 cy.c XON/XOFF handling crashes kernel o [1996/12/20] bin/2258 wollman route add/delete [network] xxx.yyy.zzz.0 f [1997/01/01] ports/2352 torstenb wu-ftp port does not work with DES crypte o [1997/01/03] conf/2367 gibbs Buslogic SCSI driver bad probe of 742A EI f [1997/01/04] kern/2371 gibbs SCSI disk corruption o [1997/01/14] kern/2498 On installation, after selecting drivers, o [1997/01/25] bin/2581 imp security holes in libtermcap o [1997/02/11] kern/2717 Panic with daily script (find) o [1997/02/14] bin/2740 wpaul root-fs full erases password table ! o [1997/02/21] misc/2795 Cyclades 8YO -- Not working under 2.1.6-S o [1997/02/28] bin/2837 Globalyst550 Disk-Drive Not found!! o [1997/03/04] kern/2877 Fatal Trap 12: page fault while in kernel o [1997/03/05] kern/2890 System panic after kernel compiled for 12 o [1997/03/08] kern/2923 panic: vm_fault: fault on nofault entry, o [1997/03/13] kern/2980 2.2 crashes after accessing DAT-tape. bot o [1997/03/15] kern/3000 Kernel Panic in 2.2-CURRENT Kernel o [1997/03/16] kern/3005 can't completely install 2.1.7 release; s o [1997/03/17] kern/3017 panic: page fault as of March 11th v2.2 o [1997/03/17] bin/3019 Can't use SCSI disk (SCSI ID>3) on instal o [1997/03/23] misc/3070 Cannot do post install mods to UNIX from o [1997/03/23] kern/3072 Kernel Page Fault During Install of 2.1.7 o [1997/03/25] kern/3103 vi large_file --> reboot without panic o [1997/03/26] ports/3106 torstenb pidentd exits with signal 6 o [1997/03/27] kern/3128 Can't Install FreeBSD 2.2.1 o [1997/03/30] kern/3150 Cyrix 6x86L-P200+ crashes w/ page fault o [1997/04/01] ports/3165 jmz tex-3.14159.tgz lacks file o [1997/04/08] kern/3234 ipfilter.shar - integration complete o [1997/04/12] kern/3267 dyson mtime/ctime sometimes updated when a prog o [1997/04/22] bin/3374 Cannot Install FreeBSD 2.2.1 - installati o [1997/04/27] ports/3394 max jp-Wnn-4.2 fails to make personal diction o [1997/04/28] kern/3404 frequent kernel panics o [1997/05/01] i386/3462 using a PS/2 mouse causes kernel trap in o [1997/05/05] bin/3510 xsm does not work! o [1997/05/07] ports/3536 jmz MakeTexPK calls gftopk with wron argument o [1997/05/12] misc/3586 The boot.flp file is too large to image t o [1997/05/13] kern/3594 EAGAIN and garbage data when reading sock o [1997/05/16] kern/3609 fs on remote host is mounted via NFS, rec o [1997/05/17] misc/3615 Error in /usr/src/lib/libc/gen/sigsetops. o [1997/05/21] bin/3650 Ypserv dumps core randomly. o [1997/05/23] kern/3671 SCSI tape drive with AHA 2940 locks up sy o [1997/05/24] kern/3674 NFS in 2.2 RELEASE hangs. o [1997/05/26] kern/3690 vm problems on 2.2, 2.1.7 works o [1997/05/27] kern/3696 kernel panic during wd hard disk probe if o [1997/05/27] misc/3700 FPE error in "normal" math code o [1997/05/30] kern/3721 kernel panic with netatalk o [1997/06/01] kern/3752 NFS dirs under -current still have proble o [1997/06/01] kern/3753 "make" hangs when building in an NFS dir o [1997/06/02] kern/3761 Inlel EtherExpress pro/100B more than on o [1997/06/11] misc/3846 The sample /etc/amd.map has a security ho o [1997/06/14] ports/3872 ports Enter key not working properly in trn por o [1997/06/16] kern/3887 fxp driver looses packets o [1997/06/17] i386/3895 False FPE (floating point exception) sign o [1997/06/25] kern/3949 The WD controller probe can fail when it o [1997/06/26] misc/3959 files in /usr/local/etc are randomly beco o [1997/07/02] bin/4018 Will not install in 2nd partition of my C o [1997/07/03] kern/4021 Local mount of a local NFS exported direc o [1997/07/10] kern/4074 Kernel panics when accessing a ccd device o [1997/07/11] kern/4076 Adaptec 2940 and non-wide devices o [1997/07/14] ports/4093 ports [oleo] Calculating 1/1 becomes infinity. o [1997/07/31] kern/4200 "vm_fault: fault on nofault entry" when r o [1997/08/11] kern/4273 kernel page faults with heavy disk access o [1997/08/12] bin/4288 brian PPP and PPPD do not stay up after shell e o [1997/08/12] kern/4289 kernel panic: vm_fault: fault on nofault o [1997/08/13] bin/4299 named is vulnerable to DNS spoofing o [1997/08/13] kern/4301 adding a default route lags all network f o [1997/08/16] i386/4315 sio0 and sio1 serial ports fail to probe o [1997/08/17] kern/4328 Degenerate network performance o [1997/08/18] kern/4332 gibbs System crash after SCSI DAT tape access. o [1997/08/18] bin/4333 gibbs Dump backup utility completely crashes th o [1997/08/20] kern/4345 Kernel panic is caused by passing file de o [1997/08/22] kern/4355 Executor does not work with sound configu o [1997/09/02] kern/4453 2.2.2 lockup on restart with ASUS-TX97 mo o [1997/09/03] ports/4458 ports MH's packf command dumps core o [1997/09/07] gnu/4480 cc crashes with Internal compiler error w o [1997/09/07] bin/4491 combination of null-FS , NFS and chroot c o [1997/09/08] ports/4493 ports perl5 port fails to compile 94 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [1995/03/02] misc/229 bde acos() core dump a [1995/03/20] kern/260 davidg msync and munmap don't bother to update m s [1995/04/01] kern/291 se PCI devices still probe/attach after bein f [1995/05/08] bin/389 Simultaneous creation/deletion of dirs co a [1995/05/09] bin/392 Simultaneous cp and ls of files on dos f/ o [1995/05/16] kern/425 wollman arp entries not getting removed when inte a [1995/06/17] kern/527 dufault dump causes assertion in ncr.c o [1995/06/23] kern/546 pci_bus_config() does not init parent poi o [1995/07/02] kern/579 bde sio: RS_IBUFSIZE at 256 bytes serial line f [1995/07/04] kern/587 if_le hangs on OACTIVE with 2k buffer s [1995/07/21] i386/631 if_ix does not support bpf, nor does it a s [1995/07/29] kern/638 Transmitted packets not passed to bpf in f [1995/08/11] gnu/672 Nor all ph headers get created o [1995/08/22] bin/706 jmg increased root DNS traffic and long laten f [1995/09/20] kern/730 gibbs 3Com 3C5x9 probe problem f [1995/09/27] kern/750 cd9660 confused by not-ready or I/O error a [1995/10/07] bin/771 telnet character mode not set and broken o [1995/10/18] bin/786 wpaul Problem with NIS and large group maps o [1995/11/12] kern/820 gibbs scsi tape problems f [1995/11/16] bin/826 mpp tcpmux listener in inetd does not work o [1995/12/20] i386/906 davidg /sys/i386/boot/netboot/nb8390.com cannot o [1996/01/01] bin/926 Mounting nfs disks before starting mountd o [1996/02/12] kern/1020 .Boca 16-port board still hangs a [1996/02/17] bin/1030 steve /bin/sh does not pass environment variabl f [1996/02/28] bin/1050 [floppy] Process (zip) hangs (unkillable) s [1996/03/06] kern/1067 panic: ufs_lock: recursive lock not expec o [1996/03/09] bin/1073 telnet -8 does not work with SunOS or Sol o [1996/03/23] kern/1098 File system corruption (2 cases) o [1996/03/30] bin/1111 scrappy mail.local will happily deliver mail to a f [1996/05/14] kern/1204 umount -f after SCSI reset -> reboot o [1996/05/24] misc/1247 bde Conflicting header files f [1996/05/26] i386/1251 aha0 and bt0(eisa) conflicts again. o [1996/05/26] kern/1256 ZNYX 314 mysterously looses packets o [1996/05/28] kern/1271 phk Kernel panic using PLIP in 27/05 current o [1996/05/31] kern/1284 dyson panic: vm_page_free: freeing busy page o [1996/06/02] i386/1288 bde wdgetctlr (wd.c) return incorrect number o [1996/06/07] kern/1301 davidg DEC FDDI/PCI Adapter: halt code = 6 (DMA o [1996/06/10] kern/1308 dyson vm_page_free: wire count > 1 in 960501-SN a [1996/06/12] bin/1315 ls(1) a [1996/06/18] kern/1333 davidg free vnode isn't: another -stable coredum f [1996/07/03] bin/1364 ps(1) bugs o [1996/07/19] docs/1402 steve sh(1) manual f [1996/07/24] kern/1423 wollman route causes kernel page fault. o [1996/07/25] bin/1429 steve sh(1) and getopts f [1996/08/01] bin/1454 steve /bin/sh bug handling <<[n] FD processing a [1996/08/02] docs/1457 ache ed(1) man o [1996/08/03] bin/1461 Incorrect address binding of Kerberized r o [1996/08/04] kern/1467 gibbs scsi_prevent causing tape problems on clo o [1996/08/18] kern/1512 dyson Use of madvise may may cause bad memory m o [1996/08/22] kern/1533 dyson Machine can be panicked by a userland pro f [1996/09/05] kern/1570 Setting SHMALL > 35000 causes panic o [1996/09/14] kern/1610 dyson mmap() of unassociated memory + mlock() c o [1996/09/16] i386/1626 MUSTEK Scanner hangs NCR SCSI controller f [1996/09/18] kern/1637 mss driver causes feedback (squeal) on so o [1996/09/19] bin/1650 telnet encryption with char-mode and asci o [1996/09/21] kern/1661 ft driver hangs uninterruptably at "bavai o [1996/09/29] kern/1689 wollman TCP extensions throttles distant connecti o [1996/09/29] kern/1692 Page fault while in kernel modem fatal tr o [1996/10/01] bin/1702 phk installing of tcl manpages fails from mak o [1996/10/03] kern/1715 le driver non-reentrant o [1996/10/04] kern/1723 gibbs kernel fault when doing scsi reprobe o [1996/10/04] kern/1724 gibbs HP colorado T4000S tape drive hangs syste o [1996/10/04] kern/1726 panic in kmem_malloc (dump available) o [1996/10/10] kern/1754 netbooted machines freeze with ifconfig a o [1996/10/11] bin/1773 ports A NULL pointer causing segmentation core o [1996/10/13] gnu/1787 markm Diffs with Index: lines are not honored f o [1996/10/15] bin/1810 fsck -p does not check pass 0 filesystems o [1996/10/15] kern/1812 dyson vnodes are left in a locked state o [1996/10/15] kern/1814 cy driver gets deadlocked sometimes o [1996/10/20] kern/1848 breakpoints may be set in shared librarie o [1996/10/21] kern/1856 read-only nfs mount: panic leaf should be a [1996/10/22] ports/1866 wosch popclient flushes remote mailbox even wit o [1996/10/24] kern/1880 kernel crash during boot when using 512 M o [1996/10/26] bin/1892 install(1) removes target file o [1996/10/29] bin/1927 User CPU time getting accounting as syste o [1996/11/07] bin/1973 jmg pppd uses /etc/ppp/options.tty after comm o [1996/11/08] gnu/1981 ypserv handles null key incorrectly o [1996/11/13] ports/2000 asami obsolete software in distfiles directory a [1996/11/13] bin/2001 vi confused about lines to display o [1996/11/13] i386/2002 sio doesn't detect com port on Compaq Con o [1996/11/14] misc/2013 'make world' fails on read-only /usr/src a [1996/11/14] kern/2014 sos Console keyboard lockup problem o [1996/11/15] bin/2016 static libtcl references symbols that are o [1996/11/15] gnu/2035 peter deque bug, local gnu changes to deque hea o [1996/11/18] kern/2053 de0 driver don't work at 100M for Compex o [1996/11/24] kern/2094 wd1: interrupt timeout: o [1996/11/26] bin/2107 problem building a system from cdrom. s [1996/12/03] kern/2142 FP mask not saved for signal handlers o [1996/12/03] kern/2144 kernel panic (page fault) running chgrp o [1996/12/08] kern/2181 2.2-ALPHA flickers/wavers part of the upp o [1996/12/10] bin/2191 syslogd stops logging after several hours o [1996/12/13] bin/2206 NIS Makefile can't manage appletalk entri o [1996/12/17] kern/2232 MSDOSFS corrupts MSDOS partitions > 500Mb o [1996/12/18] kern/2248 Mitsumi CD-ROM driver has "timeout" probl o [1996/12/20] bin/2256 brian PPP process on port will not close when a s [1996/12/22] ports/2268 ports libc from linux emulator does not use /et o [1996/12/22] kern/2270 Hayes ESP serial card locks system as of a [1996/12/25] misc/2283 ache setlocale() in libxpg4 always returns NUL o [1996/12/29] bin/2318 /usr/libexec/rlogind doesn't work after t a [1996/12/30] kern/2325 quota.user enlarged, no boot on 2.2-BETA o [1996/12/30] kern/2330 changing root device to sd0a - ncr0: abor o [1997/01/01] kern/2351 panic:timeout table full f [1997/01/06] kern/2388 joerg start unit command screws up some CDROM d o [1997/01/07] gnu/2394 tar will extract files even if -C command f [1997/01/07] kern/2401 joerg 2.2 RELENG sometimes locks up early on bo o [1997/01/08] kern/2425 amd driver does not reprobe devices. o [1997/01/08] conf/2426 At end of install, panic: Going nowhere w o [1997/01/09] bin/2430 mountd stops on loading if subnet mask is o [1997/01/09] i386/2431 panic: get_pv_entry: cannot get a pv_entr o [1997/01/12] i386/2471 Sound: Reset failed - Can't reopen device o [1997/01/13] misc/2479 sos NEC CD-ROM NOT RECOGNIZED; MATROX MISTIQU o [1997/01/13] bin/2489 gnats mangles sections o [1997/01/16] kern/2507 Renaming DOS directories with "mv" causes o [1997/01/18] kern/2521 kernel from 2.1.6 install CD doesn't acce o [1997/01/20] kern/2538 worm burning suddenly broken o [1997/01/20] bin/2541 cd (using /bin/sh) may leave you in the w o [1997/01/20] kern/2545 se < sd0(ncr0:6:0): COMMAND FAILED ==> Not a [1997/01/21] bin/2549 sos cdcontrol refuses to play audio CDs from f [1997/01/21] misc/2551 davidn limit too small for user root o [1997/01/23] kern/2569 route -iface breaks inet behaivour f [1997/01/24] kern/2570 fenner arpresolve: cant allocate llinfo o [1997/01/25] bin/2591 sh coredumps when passing an argv of a ce o [1997/01/26] bin/2597 everything stops when the new ld.so is in o [1997/01/29] kern/2613 ache syscons mistakes MONO for MONO VGA o [1997/01/29] misc/2614 make reinstall does not work o [1997/01/29] bin/2616 Installs very irratically from the same c o [1997/01/31] kern/2628 code clean up of sys/sys o [1997/01/31] kern/2632 enabling psm mouse causes keyboard to not o [1997/01/31] bin/2633 fsck -p in /etc/rc fails with cannot allo o [1997/02/02] kern/2640 2.2-RELENG leaks memory (router/pppd serv s [1997/02/03] kern/2647 changing existing route to -static crashe o [1997/02/04] ports/2664 ache elm methodically writes garbage into fold o [1997/02/05] kern/2667 wollman bpfattach can hang the system f [1997/02/05] bin/2670 fetch fails with HTTP_PROXY o [1997/02/05] bin/2671 Run-away processes using all CPU time a [1997/02/06] kern/2675 lkmcioctl() is not consistent and careful o [1997/02/07] kern/2690 asami When Using ccd in a mirror mode, file cre o [1997/02/08] kern/2695 sio1 (16540 serial port) is not recognize o [1997/02/09] kern/2698 After rewind I cannot read a tape; blocks o [1997/02/12] kern/2719 added support for magneto-optical SCSI di o [1997/02/14] kern/2732 mcopy 3.0 causes kernel hang o [1997/02/14] bin/2736 No boot block if no FreeBSD partitions on o [1997/02/15] kern/2742 panic: leaf should be empty o [1997/02/15] bin/2747 davidn cannot submit at jobs from within an at j o [1997/02/16] gnu/2749 peter cvs export using remote cvs fails - CVS/T o [1997/02/17] kern/2751 asami 2GB limitation on CCD device partitions s o [1997/02/18] bin/2762 Precedence mistake in libncurses o [1997/02/19] kern/2768 ktrace(1) -i dumps corrupted trace data o [1997/02/19] bin/2769 fsck needs several runs to clean up bad/d o [1997/02/19] kern/2770 panic: vm_fault: fault on nofault entry o [1997/02/19] kern/2771 panic: bad dir f [1997/02/19] kern/2772 gibbs panic: %s:%c:%d: Target did not send an I o [1997/02/19] kern/2773 bad dir panic o [1997/02/20] misc/2784 brian userland PPP rises load to 1.00 o [1997/02/20] bin/2785 wpaul callbootd uses an unitialized variable o [1997/02/20] gnu/2786 gcc version 2.7.2.1 C compiler slows down o [1997/02/21] misc/2793 libc_r make fscanf failure o [1997/02/22] kern/2800 DDS large data writing probrem o [1997/02/25] kern/2815 Custom Kernel crashes o [1997/02/28] bin/2832 w treats corrupted utmp as fatal error o [1997/03/01] kern/2840 mlock+minherit+fork+munlock causes panics o [1997/03/03] i386/2853 sos syscons beeps even if beeping screen is n o [1997/03/03] kern/2858 dfr FreeBSD NFS client can't mount filesystem o [1997/03/04] kern/2873 the od0 devies does not handle a Maxoptix o [1997/03/07] bin/2915 the "-fstype ufs" option of "find" seems o [1997/03/07] ports/2918 ports Unable to pass 8+ command line arguments o [1997/03/08] kern/2919 vm_fault: fault on nofault entry, addr: f o [1997/03/09] bin/2925 non-priviledged user can crash FreeBSD!! o [1997/03/11] bin/2948 can't dump 640MB optical disks o [1997/03/11] ports/2956 ports New Port: xgospel-1.10d in ftp.freebsd.or o [1997/03/12] kern/2965 st0 hang/fail on reading 4mm DAT tape for o [1997/03/12] bin/2969 csh and/or builtin printf has problems wi o [1997/03/12] bin/2973 output of iostat is wrong. o [1997/03/15] kern/2991 RTF_LLINFO routes remain when interface i a [1997/03/15] ports/2994 ports xpm port does not build for the first tim o [1997/03/18] kern/3021 panic after sync during reboot o [1997/03/21] kern/3054 OPL3 sound off by one note o [1997/03/21] bin/3055 umount -f does not work o [1997/03/24] i386/3082 keyboard locks up unexpectedly o [1997/03/24] i386/3083 Toshiba XM-5702B ATAPI CDROM not detected o [1997/03/25] kern/3104 Cannot execute files on a nullfs filesyst o [1997/03/27] conf/3123 /stand/sysintstall does not perform to up s [1997/03/27] bin/3126 Install with mcd0 still broken. o [1997/03/28] i386/3130 Dell Latitude keyboard lock up o [1997/03/28] misc/3133 TIOCSETD error with Cyclades 8Yo o [1997/03/30] gnu/3149 patch-2.1: files possibly created in wron o [1997/03/31] bin/3158 seg faults and cannot update links using f [1997/04/01] kern/3162 2.2 kernel from mar 25th crashes on nfs s o [1997/04/01] bin/3170 vi freaks and dump core if user doesn't e f [1997/04/04] i386/3195 gibbs ahc panic o [1997/04/05] kern/3201 de0 not re-enabled after hub down o [1997/04/05] ports/3205 jmz Mtools-3.0 attempts to flock() a disk par f [1997/04/05] kern/3209 dyson 3.0-current panics on shutdown/reboot/hal o [1997/04/06] kern/3216 panic: pmap_zero_page: CMAP busy o [1997/04/06] kern/3219 sppp or arnet gets looped after connectio o [1997/04/09] kern/3244 ipfw flush closes connections o [1997/04/10] bin/3246 mtree -c should escape whitespace and spe o [1997/04/11] ports/3256 ache ncftp-2.4.2 in packages-2.2 was not linke o [1997/04/12] kern/3263 troubles with digiboard o [1997/04/13] kern/3278 mounting MFS uses up swap space o [1997/04/15] bin/3305 Can't do encrypted rlogin into self f [1997/04/16] bin/3307 Unable to Route to a different Class C wi o [1997/04/18] bin/3325 brian http request over ijppp hangs o [1997/04/18] kern/3327 using gdb may cause hanging processes. f [1997/04/18] kern/3328 dyson another kernel panic o [1997/04/19] kern/3351 Scsi bus timeouts in 2.1.7.1 (adaptec 294 o [1997/04/19] bin/3355 se ncrcontrol fails when -DFAILSAFE in kerne o [1997/04/25] kern/3384 telldir-seekdir can cause livelock o [1997/04/27] kern/3398 off by one error in ffs_alloc o [1997/04/28] bin/3406 rich Fresh Internet Install - Permissions on f o [1997/05/01] gnu/3441 C++ exceptions don't work in shared libra o [1997/05/01] misc/3460 Lots of stuff still refernces /etc/syscon o [1997/05/01] kern/3463 netstat -I packet count increase on sl0 w o [1997/05/02] kern/3468 Panic - page fault in kernel mode o [1997/05/02] gnu/3470 fail to use standart ANSI C++ string clas o [1997/05/03] bin/3478 pwd_mkdb and passwd o [1997/05/04] kern/3495 _thread_fd_table is not initialized with o [1997/05/04] i386/3502 Merge of if_ix* and if_ie* broke EE/16 su o [1997/05/06] bin/3524 rlogin doesn't read $HOSTALIASES for non- o [1997/05/07] conf/3526 Bug in config(8) mechanism o [1997/05/07] kern/3527 if_de.c doesn't recognize Kingston card p o [1997/05/08] misc/3544 Uprgade problem with schg flags o [1997/05/09] kern/3564 using MPU401 driver pagefaults kernel o [1997/05/09] kern/3569 ex0 driver doesn't work with EtherExpress o [1997/05/11] misc/3578 defining CXXFLAGS in /etc/make.conf or en o [1997/05/12] kern/3579 de driver doesn't support newer SMC 9332 o [1997/05/12] kern/3581 intermittent trap 12 in lockstatus() o [1997/05/12] kern/3582 panic: bad dir (mangled entry) in 2.2-STA o [1997/05/12] kern/3583 'syctl kern' dumps core when displaying c o [1997/05/13] conf/3591 parts in rc.local have no effects in rc.* o [1997/05/18] bin/3622 gethostbyname fails for file descriptors o [1997/05/19] kern/3633 description of interface flags in ep(4) m o [1997/05/20] ports/3640 ports xlockmore galaxy bombs out o [1997/05/20] kern/3646 kernel built with "options NETATALK" fail o [1997/05/21] ports/3649 ports xlock quits on receipt of signalxx 8 f [1997/05/21] ports/3654 pst mkdist script is broken. o [1997/05/21] kern/3661 System locked up while editing rc.conf, w o [1997/05/23] bin/3670 make fails in libc o [1997/05/25] kern/3685 panic: fdesc attr o [1997/05/25] kern/3688 fsck -p gets transient unexpected inconsi o [1997/05/29] kern/3707 IP Accounting counts packets two virtual o [1997/05/29] gnu/3714 gdb -w -k /kernel /dev/mem != gdb --wcore o [1997/05/30] conf/3725 Cirrus Logic PCMCIA Controller Support o [1997/05/30] kern/3726 process hangs in 2.2-stable when working o [1997/05/30] kern/3727 SCSI II tape support broken o [1997/06/01] kern/3744 Inability to edit memory area for ed0 pre o [1997/06/01] kern/3745 Use of ed0 with buff addr of C8000 causes o [1997/06/01] bin/3746 daemon screen saver missing o [1997/06/01] conf/3750 phk Potential improvements to rc.firewall o [1997/06/02] i386/3760 Inlel EtherExpress pro/100B !!! o [1997/06/02] bin/3763 df hangs uninterruptably when nfs mount f o [1997/06/03] kern/3771 NFS hangs when writing to local FS re-mou o [1997/06/04] i386/3779 changing cursor to blinking block causes o [1997/06/06] bin/3799 make world failing on 2.2.1 o [1997/06/07] conf/3807 mitsumi cd-rom fx800 (8x cd-rom) is not r o [1997/06/08] gnu/3810 cvs can't handle multiple multiple-path d o [1997/06/09] docs/3817 broken indent manpage o [1997/06/09] ports/3822 asami ports-current Xaw3d doesn't compile o [1997/06/09] kern/3827 fopen/freopen fails on some binary files. o [1997/06/11] bin/3849 Existing quota tools are limited. o [1997/06/13] i386/3857 bios screensaver screws up screen o [1997/06/13] bin/3862 I dont seem to get a login prompt.... o [1997/06/16] misc/3883 @+netgroup entries break +NIS-user entrie o [1997/06/18] kern/3899 df while unmounting floppy crashes 2.2.2 o [1997/06/19] kern/3909 joerg A patch supporting some new worm drivers o [1997/06/19] gnu/3910 sort(1) of 2.2.1R doesn't work in special f [1997/06/22] kern/3925 SO_SNDLOWAT of 0 causes kernel to use 99% o [1997/06/23] bin/3937 getty works on ttyd1 but not ttyd0 o [1997/06/28] misc/3980 access via NFS fails during mount-operati o [1997/06/29] bin/3982 /usr/include/arpa/tftp.h has bug preventi o [1997/06/29] bin/3986 rdist seg faults when target machine is d o [1997/07/01] i386/4006 panic: ahc_intr: AWAITING_MSG for an SCB o [1997/07/02] kern/4012 2.2-RELEASE/Digital UNIX NFSv3 0 length f o [1997/07/02] misc/4013 boot floppy hangs if IDE ZIP Drive presen o [1997/07/03] kern/4022 Fatal double fault using vn device o [1997/07/04] kern/4032 During recovery from scsi errors, incorre o [1997/07/04] gnu/4033 peter cvs clears default branch when adding a f o [1997/07/06] gnu/4042 gdb stackframe in static library shows no o [1997/07/06] docs/4043 man page for directory ops is misleading o [1997/07/07] ports/4050 jfitz mrtg: rateup dumps core with malloc_optio o [1997/07/08] ports/4062 obrien xskyroot o [1997/07/09] kern/4071 Accessing /dev/rst0 causes `DMA beyond en o [1997/07/12] bin/4078 sos Typed password to log in on console and i o [1997/07/17] ports/4105 ports tac_plus port update o [1997/07/17] kern/4107 ch.c does not use bounce buffers o [1997/07/17] gnu/4111 send-pr doesn't se that Category is actua o [1997/07/17] kern/4115 SunOS NFS file has wrong owner if creator o [1997/07/19] kern/4119 can't connect to Win NT 4.0 RAS using MS o [1997/07/20] ports/4129 ports New port uploaded to incoming/sane.tar.gz o [1997/07/25] bin/4167 dump fials for dumping subdirectory o [1997/07/26] bin/4176 restore gets confused when run over pipe o [1997/07/27] ports/4178 jdp The cvsup port cannot be built on a non X o [1997/07/27] ports/4179 fenner lmbench-1.1 dumps core after asking for m o [1997/07/28] kern/4186 nfsiod, panic, page fault in kernel mode o [1997/07/30] kern/4194 kernel pci driver for Digital 21041 Ether f [1997/07/31] bin/4202 pwd_mkdb trashes .db o [1997/08/04] i386/4226 Floating point exception for double preci o [1997/08/05] bin/4231 ipfw no more returns error when deleting o [1997/08/06] kern/4233 pca driver does not support A-law encodin o [1997/08/06] bin/4234 ncurses programs broken, won't work in re o [1997/08/06] kern/4240 kernel fails to recognise 2nd serial port o [1997/08/06] bin/4241 send-pr aborts when emacs is editor o [1997/08/08] conf/4252 peter sendmail doesn't use smrsh by default o [1997/08/09] bin/4254 steve make in free(): warning: chunk is already o [1997/08/09] kern/4256 ahc driver: kernel goes to strange state o [1997/08/10] kern/4260 EOF handling in st(4) is broken o [1997/08/10] kern/4265 Panic in dsinit when multiple FreeBSD sli o [1997/08/10] ports/4267 ports Updated (and renamed) linux-ls port; fixe o [1997/08/10] kern/4270 ch driver does not use bounce buffers a [1997/08/11] kern/4271 sos System crashed caused by moving mouse poi o [1997/08/11] bin/4276 Security problem with DNS resolution o [1997/08/12] kern/4284 le0 goes OACTIVE after some time o [1997/08/13] kern/4295 SL/IP difficulties between 2.2.1 & 2.2.2 o [1997/08/16] kern/4312 arp table gets messed up, syslog "gateway o [1997/08/17] kern/4327 NFS over TCP reconnect problem o [1997/08/20] bin/4341 cc: Internal compiler error: program cpp o [1997/08/21] bin/4353 fetch -m changes modified date o [1997/08/22] bin/4357 wosch bug in adduser script causes duplicate UI o [1997/08/23] bin/4366 bad144 crashes if checking over 2gb o [1997/08/24] bin/4376 pthread_join does not return the values s o [1997/08/25] bin/4379 Make world breaks in sbin/ifconfig o [1997/08/25] docs/4381 mount -t msdos causes panic:vm_fault o [1997/08/25] kern/4382 CURRENT kernel has a "free vnode isn't" p o [1997/08/27] ports/4405 jfitz ascend-radius port is out-of-date a [1997/08/29] kern/4416 syscons: problem with font a [1997/08/29] kern/4417 syscons: mouse pointer destroys character o [1997/09/01] bin/4445 segmentation fault in vfprintf o [1997/09/02] kern/4454 X drops characters/locks up keyboard when o [1997/09/03] bin/4460 lpd hangs exiting (IE in ps table) o [1997/09/06] bin/4476 fetch puzzled while getting files when ma o [1997/09/06] bin/4477 vidcontrol fails to change videomode on s o [1997/09/07] kern/4487 Kernel panic executing a directory o [1997/09/08] bin/4497 Reverse DNS fails for some CIDR *.IN-ADDR o [1997/09/08] kern/4498 Files corrupted when written to Iomega Zi o [1997/09/08] bin/4500 mount_nfs always uses priviledged port o [1997/09/08] kern/4501 df on a stale file system panics o [1997/09/09] kern/4505 Support for Gravis UltraSound PnP card o [1997/09/10] kern/4508 nfs3 data integrity problems o [1997/09/11] gnu/4511 GCC optimization broken with -m486? o [1997/09/11] kern/4513 System lockup appears to be VM related. o [1997/09/12] bin/4518 ipfw cannot handle 6-character interface o [1997/09/12] ports/4519 ports popper 2.3 core dump o [1997/09/13] conf/4522 Polish locale o [1997/09/13] bin/4524 procmail can swap machine to death with m o [1997/09/14] i386/4533 Server with Cyclom-Y PCI card rebooted at 345 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [1994/12/01] kern/35 mount -t union -o -b : lower layer not se o [1995/01/14] bin/115 systat iostat display doesn't scale high o [1995/01/22] kern/176 peter EIDRM not defined in errno.h o [1995/04/20] misc/355 policy on /usr/local permission in base r o [1995/05/13] bin/401 wollman Add REMOTE_* variables a [1995/05/23] i386/440 sos want vidcontrol option to apply settings a [1995/05/27] gnu/450 scrappy tar --exclude -c doesn't work o [1995/06/15] bin/517 wpaul Bad group change with 'install' o [1995/07/05] bin/591 phk SPAP request REJexted in stead of NAKed o [1995/07/09] misc/605 wpaul NIS: get*bynis routine problems f [1995/08/03] kern/652 Multiple addresses on one interface inter s [1995/08/05] gnu/655 jdp ld -r of shared objects worked in 1.1.5, o [1995/08/07] bin/658 ifconfig alias has to be separately given f [1995/08/12] kern/677 dyson X gets a bus error when calling mmap() o [1995/08/13] bin/680 joerg 2.0.5's tip using termios doesn't act the o [1995/08/18] kern/700 fenner The comments in /sys/net/if.h are confusi o [1995/09/26] kern/742 dyson syslog errors accessing Mac hard disks [p o [1995/10/03] kern/765 phk umount -f can`t umount a NFS filesystem i o [1995/11/20] kern/831 one minor complaint about the kernel visu o [1995/11/27] bin/841 stale nfs mounts cannot be umounted o [1995/11/30] bin/854 dyson swapinfo shows incorrect information for o [1995/12/17] kern/900 dyson ext2fs triggers divide by zero trap in vn a [1995/12/29] misc/922 From line handling incorrect in mail.loca a [1995/12/31] kern/924 EISA devices have disappeared from vmstat o [1996/01/21] bin/961 'more $file', incorrect CRLF compacting. o [1996/01/28] kern/975 bde getrusage returns negative deltas a [1996/01/30] bin/981 fenner clnt_broadcast() is not aware of aliases s [1996/02/03] bin/993 peter g++ complains about /usr/include/machine/ o [1996/02/07] bin/999 peter /usr/share/mk/sys.mk missing common $(RM) o [1996/02/12] bin/1021 phk pppd doesn't handle PAP-only authenticati f [1996/02/14] kern/1026 deadlocks if parent vfork and child has c f [1996/02/15] bin/1029 cd behaves erraticly if cwd is a mount-po f [1996/02/19] bin/1037 2.x telnetd handles CTRL-M differently th o [1996/02/25] i386/1042 bde Warning from sio driver reports wrong dev o [1996/02/26] misc/1043 dyson vm_bounce_alloc error on 2.1 install with o [1996/03/20] kern/1090 iostat displays incorrect sps count o [1996/03/20] bin/1093 wollman route's diagnostic is weird o [1996/04/06] kern/1119 dyson Mounted EXT2FS partition is not cleanly u a [1996/04/15] kern/1144 sig{add, del}set and sigismember fns don' a [1996/04/22] bin/1154 Configure tunN device for ip-over-ip tunn o [1996/04/23] bin/1155 systat or top display disagreeing informa o [1996/05/09] bin/1184 scrappy ls + xterm + nvi + columns != 80 + ^Z = m o [1996/05/15] bin/1206 steve /bin/sh + emacs + ^G = ruined terminal o [1996/06/11] bin/1312 automounter hangs on boot o [1996/06/12] conf/1319 muldi3 is not included into kernel's Make a [1996/06/13] bin/1320 gpalmer dump limits blocksize to 32K o [1996/06/18] i386/1331 phk changes and bug in ft driver f [1996/06/18] bin/1332 changes to amd and possible nfs lkm bug? f [1996/07/04] misc/1369 Need SC_MORE_LUS for Emulex MD23 also a [1996/07/07] bin/1375 Extraneous warning from mv(1) f [1996/07/07] misc/1376 if_tun.c does not set if_ibytes and if_ob o [1996/07/18] kern/1399 dyson invoking setuid programs over NFS case vn o [1996/07/21] ports/1416 ports cflow(1) doesn't parse GNU C __attribute_ s [1996/07/23] kern/1421 Non-bug in sosend() o [1996/07/24] misc/1428 ncurses doesn't always display ALTCHARSET o [1996/08/03] kern/1462 nfsstat doesn't work if using LKM'ed vers a [1996/08/07] ports/1470 asami need more info in the ports structure o [1996/08/17] kern/1501 vmstat reports impossible avm after start o [1996/08/17] bin/1502 vmstat 'avm' field merges with procs 'w' o [1996/08/17] kern/1508 sos syscons should protect against useless DD o [1996/08/19] kern/1514 dyson mlock fails on readonly regions o [1996/08/20] kern/1516 dyson vm_fault.c contains dead code or too many o [1996/08/21] ports/1520 ports sudo dosn't recognise certain passwords a o [1996/08/21] bin/1523 "cvs update -d -P" prunes unchecked-in di o [1996/08/24] misc/1538 enhanced /etc/security script a [1996/09/04] bin/1565 Moving a file to it's link completely rem o [1996/09/06] bin/1577 mail -f foo does not look in current dire o [1996/09/08] bin/1589 ftp fails to flush output o [1996/09/11] bin/1598 tip leaves OPOST set on controlling termi o [1996/09/12] docs/1602 ache /usr/lib/terminfo refered to in man termi o [1996/09/12] bin/1607 dfr unmount fails for a NFS fs mounted withou o [1996/09/14] gnu/1611 phk groff should use "system-wide" papersize o [1996/09/14] kern/1614 Attempt to mount an NTFS partition causes f [1996/09/18] kern/1636 mss driver extension to broaden support a [1996/09/18] bin/1642 pkg_install Makefiles could be simplified o [1996/09/19] bin/1649 md5(1) header file makes bad assumption o [1996/09/19] kern/1654 In procfs, vattr doesn't contain correct o [1996/09/20] kern/1658 ktrace/kdump flaky - corrupted ktrace.out o [1996/09/23] i386/1671 s2 map in pcvt isn't ISO 8859-1 and claim o [1996/09/29] kern/1690 apm and sbxvi inappropriately probe as co o [1996/09/29] docs/1691 brian ppp server doc submission o [1996/10/02] misc/1708 monthly login accounting o [1996/10/02] kern/1711 joerg kernel logging of signaled processes shou o [1996/10/03] misc/1717 Use of ntohl causes lint to complain o [1996/10/04] bin/1721 /sbin/route incorrectly installs routes w o [1996/10/04] kern/1725 visual config redraws bits of the screen f [1996/10/08] misc/1738 Install floppy returns random geometry wi o [1996/10/11] conf/1777 sysctl called in /etc/netstart before /us s [1996/10/13] kern/1788 pst netstat gives negative numbers for tcp by o [1996/10/13] misc/1791 syslimits.h does not allow overriding def o [1996/10/13] bin/1793 steve /bin/sh return w/o exitstatus in a functi o [1996/10/14] bin/1804 pkg_create hangs if the packing list has o [1996/10/16] bin/1827 add support of Glidepoint trackpad "tap/d o [1996/10/20] bin/1849 gdb sets library breakpoints on the wrong o [1996/10/20] misc/1853 Syscons font mapping semms not to work pr o [1996/10/20] docs/1855 joerg Addition to LINT o [1996/10/22] kern/1868 system knows it has no keyboard but compl o [1996/10/23] misc/1871 incorrect '===> item' when making world o [1996/10/23] bin/1872 automounter (amd) cannot ls directories w o [1996/10/24] bin/1881 file(1) misidentifies Sun3/m68k executabl o [1996/10/26] bin/1897 Sendmail 8.8.2 requires /etc/sendmail.cw o [1996/10/27] bin/1904 /usr/bin/su is not careful enough in veri o [1996/10/29] bin/1924 if lpd is not running, lpc will say ``no o [1996/10/30] i386/1931 Mitsumi CDrom works well under 2.1.x, fai o [1996/11/01] bin/1941 wtmp and monthly rotation o [1996/11/01] bin/1943 route(8) args o [1996/11/02] bin/1945 Out of date code/comments in dd o [1996/11/04] i386/1953 sos syscons savers have no default timeout o [1996/11/04] gnu/1961 uucp logging files are in /var/spool/uucp o [1996/11/06] bin/1968 FreeBSD has no rdate(8), here's one o [1996/11/06] bin/1970 csh limtail() bug o [1996/11/09] bin/1985 pkg_delete outputs confusing message when o [1996/11/13] kern/2004 route add -link panic o [1996/11/13] bin/2005 Poor command line argument checking and b o [1996/11/14] bin/2008 kerberos tickets from login all have the o [1996/11/15] kern/2022 Switching from X display to virtual conso o [1996/11/16] bin/2036 cpio size wraparound o [1996/11/16] ports/2038 torstenb sshd dies on FreeBSD machines if run as a f [1996/11/18] ports/2051 andreas HDF library port o [1996/11/19] bin/2061 DEBUG_FLAGS in bsd.lib.mk is broken o [1996/11/19] bin/2065 wollman in tzsetup/sysinstall, allow user to type o [1996/11/19] misc/2068 Unstable keyboard mappings on the main tt o [1996/11/20] kern/2072 ZIP drive support is available for FreeBS f [1996/11/21] ports/2079 obrien New ports supporting AWE sound driver (fo o [1996/11/22] docs/2087 ifconfig.8 does not document how to remov o [1996/11/22] bin/2090 clients may bind to FreeBSD ypserv refusi o [1996/11/23] bin/2093 AMD gets sig 11 when /etc/malloc.conf is o [1996/11/25] misc/2105 bsd.lib.mk has problems with STRIP and IN o [1996/11/26] bin/2106 Byte order problem in -current routed o [1996/11/26] i386/2108 sos [ATAPI] wcd driver may hang under certain o [1996/11/28] kern/2118 sos writing to virtual consoles fails to disp o [1996/11/28] bin/2119 mount lies to child about argv0, which ca o [1996/12/01] bin/2133 netstat -s overflows to negative o [1996/12/02] bin/2137 vm statistics are bad o [1996/12/02] kern/2140 FreeBSD leaves EtherExpress 16 net card i o [1996/12/03] ports/2145 pst qpopper bulletin support broken o [1996/12/03] conf/2146 brian wrong /dev for COM2 during installation v o [1996/12/06] i386/2166 psm driver locks the console f [1996/12/07] ports/2169 pst zephyr port does not completely compile f [1996/12/08] ports/2182 ports FreeBSD's and X-32's list of locales do n o [1996/12/08] bin/2184 sendmail has lots of trouble with local d o [1996/12/08] misc/2185 phk add ability to change partition type in l a [1996/12/10] ports/2190 asami need cross-reference to xpdf from X11 por o [1996/12/12] kern/2199 joerg Got a lots of "Target Busy" messages with o [1996/12/14] kern/2214 File System gets corrupted when mounting o [1996/12/14] bin/2216 Ada specs not being compiled into cc/gcc o [1996/12/16] bin/2227 FreeBSD does not recognize WD7000-ASC dri o [1996/12/17] i386/2234 fbsdboot.exe does not turn off floppy dri o [1996/12/17] i386/2239 some interrupts take too long (i.e. BT946 o [1996/12/18] misc/2242 Suggest add optional mt blocksize 512 o [1996/12/18] bin/2247 imp getopt should return -1 rather than EOF o [1996/12/20] bin/2260 brian PPP logins using PAP to Nortel/Shiva syst o [1996/12/21] ports/2264 jmz latex* ports need updating a [1996/12/21] bin/2265 guido su(1) does not call skeyaccess() o [1996/12/24] kern/2273 dufault support for POSIX.4 / POSIX.1a RT-schedul o [1996/12/25] conf/2284 Termcap ibm3163 entry has arrow keys wron o [1996/12/26] bin/2291 race condition in /etc/master.passwd lock o [1996/12/27] kern/2298 Support for DSR/DCD swapping on serial po a [1996/12/27] misc/2302 markm new crypt() including SHS and an extendab o [1996/12/28] misc/2309 Thread safe fixes to malloc, localtime, l o [1996/12/28] ports/2313 torstenb pidentd fails in 2.2-BETA o [1996/12/29] bin/2315 tail segfaults on NFS permission denied o [1996/12/29] misc/2323 FreeBSD.FAQ file in ftp.freebsd.org is lo o [1996/12/30] kern/2327 `Green' saver for pcvt o [1997/01/01] docs/2353 Changes to FAQ o [1997/01/03] bin/2366 libc does not consult /etc/services to fi o [1997/01/03] bin/2368 serial line logins "freeze" during login o [1997/01/06] bin/2382 curses.h / -lcurses incompatible with C++ o [1997/01/06] bin/2383 Inconsistent tputs(3) prototypes in curse o [1997/01/06] misc/2386 patches for new socket credential firewal o [1997/01/06] bin/2387 virtual hosting patches for inetd o [1997/01/06] kern/2390 Some CDROM drives stop audio on cdcontrol o [1997/01/07] kern/2393 filesystems not unmounted following shutd o [1997/01/07] misc/2407 dirent.h does not include sys/types.h o [1997/01/07] bin/2410 pppd(8): failing PAP doesn't force line d o [1997/01/07] kern/2412 Wine does not work o [1997/01/07] ports/2413 peter Cannot redirect "top" output o [1997/01/08] kern/2424 Pressing ALT-Fn during boot -c leave bell o [1997/01/09] kern/2429 Driver for AIMS Lab RadioTrack radio card o [1997/01/10] bin/2437 minor nits on text in 2.2-BETA install o [1997/01/10] bin/2442 davidn setusershell()/endusershell() missing o [1997/01/10] bin/2443 Fetch cannot find the correct boundary be o [1997/01/11] bin/2448 semctl() not portable -- freebsd requires o [1997/01/11] docs/2455 no description "option COMCONSOLE" MLEN o [1997/01/26] misc/2596 dd refuses to respond to SIGkill o [1997/01/26] i386/2598 ep0 in EISA mode hangs if ep0-device (ISA o [1997/01/28] bin/2603 dufault Added POSIX.4/POSIX.1b constants in unist o [1997/01/28] bin/2604 dufault Added POSIX.4/POSIX.1b shm_open()/shm_unl o [1997/01/28] ports/2607 max New port: Gopher-2.3 o [1997/01/29] misc/2617 Utility submission - upsmon - UPS monitor o [1997/01/30] kern/2621 Patch to support Cogent EM110 fast-ethern o [1997/01/30] docs/2623 ipfirewall(4) man page is way out of date o [1997/01/30] bin/2624 kdump unaware of semsys and several other o [1997/01/31] bin/2630 xargs does excessive and inconsistent arg o [1997/02/02] gnu/2637 tar dumped core with -g option. a [1997/02/02] bin/2641 wpaul login_access.c doesn't work with NIS by d o [1997/02/03] ports/2653 pst mh-6.8.4 manpage error for slocal o [1997/02/04] bin/2657 ypserv thinks there is no computers in ne o [1997/02/04] bin/2660 When selecting BSD to boot from system ha o [1997/02/04] bin/2665 port 22 isn't being converted to ".ssh" i o [1997/02/05] bin/2668 modification suggested for rarpd o [1997/02/05] bin/2672 Problem with telnetd s [1997/02/07] ports/2684 torstenb ircII port upgrade; 2.9_roof -> 2.9alpha1 o [1997/02/07] kern/2686 struct igmpmsg in s o [1997/02/07] misc/2687 jkh sysinstall umounts floppy after prompting o [1997/02/10] bin/2703 vipw doesn't allow you to edit master.pas o [1997/02/10] kern/2704 Occasional failure to detect wdc1 on boot o [1997/02/11] conf/2709 FBSD 2.1.6 X-Server installation setup ut o [1997/02/11] bin/2713 ftp daemon processes don't terminate, eve o [1997/02/11] kern/2715 MSDOS-FS 1024/2048 byte/sector media supp o [1997/02/11] kern/2716 od.c/sd.c non 512 byte/sector support imp o [1997/02/13] i386/2729 "make tags" in sys/kern produces barely u o [1997/02/14] bin/2734 jkh pkg_* uses relative paths to executables o [1997/02/14] bin/2735 jkh Add signature support (both MD5 and PGP) o [1997/02/14] bin/2737 yppasswd fails to change password on a su o [1997/02/15] misc/2745 fenner PR querry web form doesn't sort correctly o [1997/02/17] bin/2752 NULL is used instead of 0 many places o [1997/02/20] docs/2780 Description of Linux emulation is out of o [1997/02/20] bin/2782 err man page is slightly wrong o [1997/02/21] misc/2789 na.phone update o [1997/02/22] ports/2797 ports New Port: qmail o [1997/02/23] kern/2806 new kernel tags script o [1997/02/23] kern/2807 pcisupport.c uses sprintf field widths, n o [1997/02/25] i386/2813 hard reference to /usr/src breaks make wo o [1997/02/26] conf/2819 /etc/rc does not execute 'uname' when con o [1997/02/26] conf/2822 ftp install specifying URL confusing o [1997/02/27] gnu/2827 after make world genclass is not installe o [1997/02/28] docs/2833 Repeated topics on FAQ entry hardware com o [1997/03/02] docs/2850 init(8) man page does not document secure o [1997/03/02] bin/2851 script(1) sets argv[0] of the started she o [1997/03/03] kern/2857 DE500 board exhibits capture effect o [1997/03/03] bin/2859 /usr/bin/quota seems to choke on long gro o [1997/03/03] kern/2865 dfr NFS client hangs on umount, ls, df when N o [1997/03/03] bin/2871 showmount -e returns error o [1997/03/04] misc/2882 Duplicate line in /etc/services? o [1997/03/05] kern/2886 fenner mbuf leak in multicast code o [1997/03/06] docs/2897 steve send-pr categories should be explained so o [1997/03/06] bin/2898 fenner arp -a -n buglet a [1997/03/06] ports/2902 ports Fix xmcd port for PACKAGE_BUILDING a [1997/03/06] ports/2905 ports Fixed port: xshisen-1.36 o [1997/03/08] ports/2920 ports patch for mispositioned xv windows under o [1997/03/09] i386/2924 sos syscons X keyboard gets stuck in capsmode o [1997/03/09] ports/2926 ports xmgt-2.31 port, now in pub/incoming on ft o [1997/03/10] bin/2934 sh(1) has problems with $ENV o [1997/03/10] bin/2938 Add -b, -l, and -f options to du(1) o [1997/03/11] ports/2949 ports bsd.port.mk needs something like FETCH_EN o [1997/03/11] ports/2951 ports xgraph source is not on MASTER_SITE o [1997/03/11] misc/2955 pkg_add failed on xemacs via sysintall o [1997/03/12] ports/2961 ports New port(jp-vftool-1.2):japanese/virfonts o [1997/03/13] ports/2974 ports updated Makefile and patch-ab of jp-dvi2p o [1997/03/13] bin/2977 After enabling moused and vidcontrol and o [1997/03/13] bin/2979 GCC complains about stmt. expr. when comp o [1997/03/13] i386/2984 serial port console only prints ~ 1 char o [1997/03/14] ports/2988 joerg vga font is not built o [1997/03/15] ports/2993 ports qmail-port-take2-proff.tar.gz in incoming o [1997/03/15] kern/3001 soundblaster8 card does not work correctl o [1997/03/16] misc/3009 packages-2.2/x11/fvwm-1.24r.tgz corrupt o o [1997/03/17] ports/3012 ports qmailanalog port in incoming o [1997/03/18] conf/3023 By default users have no write permission o [1997/03/18] misc/3024 make reinstall in /usr/src requires writa o [1997/03/18] bin/3025 mv to / trailed dirs prints odd error mes o [1997/03/18] bin/3028 sos add support for Glidepoint pointing devic a [1997/03/21] ports/3052 ports /usr/ports/lang/expect does not find tkCo o [1997/03/22] kern/3061 route does not accept -genmask o [1997/03/24] misc/3075 2.2-R install "features" (non critical) o [1997/03/24] ports/3081 ports sitelispdir is a directory no a path in x o [1997/03/24] ports/3090 torstenb ircii-2.9-roof does not run. o [1997/03/26] misc/3113 make libraries failed. a [1997/03/28] misc/3136 rc.firewall should be run after interface o [1997/03/29] bin/3139 qcamcontrol has a bug where I/O errors ar o [1997/03/29] misc/3140 display message is broken on boot.flp o [1997/03/30] docs/3147 /usr/share/misc/au.postcodes f [1997/03/30] misc/3148 ache adjkerntz screws up during GMT/BST change o [1997/03/31] gnu/3157 Patches to gas and gdb to support MMX ext a [1997/04/01] bin/3164 view copies the file into vi.recover o [1997/04/01] ports/3169 ports nn port broken o [1997/04/01] kern/3172 CS4232 support trouble for mss0 o [1997/04/03] bin/3190 RISCom N2 card driver problem? o [1997/04/04] bin/3194 2.2.1-RELEASE hangs when using /stand/sys o [1997/04/06] bin/3211 ctm uses mktemp()> o [1997/04/06] bin/3212 the pkg_* tools use mktemp() o [1997/04/07] bin/3221 rpc.rusersd : can't communicate with SunO o [1997/04/07] misc/3225 uucpd.c should normalize host names as lo o [1997/04/08] bin/3232 XFree86 installation Problem with non-Mic a [1997/04/08] bin/3233 wosch adduser(8) doesn't add users to the wheel o [1997/04/08] misc/3237 SCRIPTS addition to bsd.prog.mk a [1997/04/09] bin/3241 times(3) returns only stime o [1997/04/09] bin/3242 incorrect prototype for initgroups o [1997/04/09] bin/3245 variable substitution "a=${a:=}" in /bin/ o [1997/04/10] bin/3251 xsysinfo stops refreshing and wastes CPU o [1997/04/10] kern/3253 scsiconf.c: make ZIP disks use optical dr o [1997/04/13] conf/3272 $@ is deprecated I believe, so use ${.TAR o [1997/04/14] kern/3281 errors when "rm -r"-ing in a mounted ext2 o [1997/04/14] kern/3282 ext2fs causes fs-unmount at shutdown/rebo o [1997/04/14] bin/3284 symorder(1): -t option doesnŽt work at al o [1997/04/14] bin/3285 date option for pom(6) (phase of the moon o [1997/04/14] bin/3286 missing error checking in mount_mfs(8) ak o [1997/04/14] kern/3287 missing symbols in /usr/src/sys/i386/i386 o [1997/04/14] kern/3288 addition of a -f (force) option to "write o [1997/04/14] bin/3289 login(1) does not check /etc/skey.access o [1997/04/15] kern/3299 /dev/console hangs f [1997/04/15] kern/3302 msdos FS bogus error o [1997/04/15] ports/3306 ports new port-package for ifmail o [1997/04/17] bin/3314 /etc/daily did not run on April 6, 1997 o [1997/04/17] kern/3317 odd TUBA_INCLUDE use in tcp_input.c o [1997/04/17] ports/3318 ports New port: jigsaw (Java-based HTTP server) o [1997/04/18] ports/3322 markm setlocale problem in lang/perl5 a [1997/04/19] ports/3335 ports new port request of korean/hanemacs o [1997/04/20] ports/3358 asami XFMail-1.1 has been released o [1997/04/20] ports/3363 max port of nana-1.00 for your collection o [1997/04/21] misc/3368 jkh sysinstall upgrade should confirm before f [1997/04/23] kern/3375 Consistent 10 min. delay at boot with REL o [1997/04/24] ports/3379 ports mprof dumps core on FreeBSD 2.2.1 o [1997/04/25] ports/3383 ports kaffe core dumps if LD_LIBRARY_PATH not s o [1997/04/25] bin/3386 kernel 'config' wrapper 'doconfig' ala Di o [1997/04/27] ports/3396 max update of the port of Mesa (now version 2 o [1997/04/27] bin/3399 mv of symbolic link can move directory in o [1997/04/27] docs/3400 MAXMEM uses maths in LINT o [1997/04/27] conf/3401 jkh sysinstall sends empty FreeBSD user regis o [1997/04/28] ports/3411 ports New port - Atari 8 bit computer emulator o [1997/04/29] bin/3416 ibcs emulation problems o [1997/04/29] bin/3418 pkg_create doesn't always create gzip'ed o [1997/05/01] ports/3455 jmz mtools-3.6.tgz could have a better mtools o [1997/05/02] kern/3475 gdb(ptrace?) cause create/modify times on o [1997/05/03] misc/3476 Please add support for .cpp suffix to sta s [1997/05/04] ports/3498 ports nn-current port is out of date o [1997/05/04] ports/3499 markm exim port out of date o [1997/05/05] i386/3504 New features (and manpage) for netboot o [1997/05/05] bin/3506 more did not show iso-8859-n characters o [1997/05/05] bin/3508 FreeBSD 2.2.1 do not view SCSI disk at sw o [1997/05/06] docs/3522 Man pages close(2) misses fcntl lock info o [1997/05/07] bin/3528 fsck fails to detect some illegal block n o [1997/05/08] kern/3546 ktrace works even if no read permission o [1997/05/08] gnu/3552 the -L option of tar does not work proper o [1997/05/09] bin/3556 Bug with -i option in /usr/bin/lpr o [1997/05/09] bin/3558 make reinstall collapses on install-info o [1997/05/09] kern/3560 Timeout counter bug in /sys/i386/isa/wd.c o [1997/05/09] kern/3571 Mounted ext2 prevents umount of filesyste o [1997/05/11] conf/3577 eBones and OBJLINK=yes fails to build o [1997/05/12] kern/3584 cleanup TCP_REASS macro in tcp_input.c o [1997/05/13] conf/3590 Difference in ttys and FAQ f [1997/05/14] ports/3597 ports jp-groff-0.99 port macro update o [1997/05/16] bin/3608 Telnet in linemode will break apart long o [1997/05/17] kern/3611 Internal CPU cache on CyrixiInstead DX2 d o [1997/05/18] gnu/3616 permissions of /usr/libexec/uucp/uuxqt no f [1997/05/19] ports/3634 andreas fvwm95-2.0.43a-i18n-port.tar.gz was put o [1997/05/19] docs/3636 No mention is made in relevant manpages a o [1997/05/20] bin/3638 /bin/w can't handle long /dev/{tty,cua}xx o [1997/05/20] bin/3639 ac doesn't know about FreeBSD's pty names o [1997/05/20] docs/3645 TCP_wrappers package doesn't mention wher o [1997/05/21] bin/3648 find(1) extension for file flags o [1997/05/21] ports/3657 ports Port of NCSA HyperNews submitted as p5-hy o [1997/05/22] i386/3663 Unable to get system printer to work o [1997/05/22] ports/3665 jmz mtools port install fails o [1997/05/22] kern/3667 patches to modularize vnode driver o [1997/05/24] conf/3673 no ddp line in /etc/protocols o [1997/05/25] kern/3678 bug in IPDIVERT code in -current o [1997/05/25] ports/3687 asami Gnat 3.09 Ada Compiler o [1997/05/27] misc/3695 compiled termcap.db not in distribution o [1997/05/28] bin/3705 jkh /stand/sysinstall hangs. pkg_add also ha o [1997/05/29] conf/3713 installation floppy bug o [1997/05/30] kern/3720 Addition for supported Hardware o [1997/05/30] kern/3724 jkh sig-11 on package add in sysinstall o [1997/05/31] ports/3729 scrappy pgsql dies when initiated o [1997/05/31] kern/3731 Addition of a PCI Bridge f [1997/05/31] bin/3733 davidn getty with 'to' option causes pppd to die o [1997/05/31] ports/3737 ports The DHCPD no longer works under FreeBSD 2 o [1997/06/01] kern/3738 Byte and packet counters in ipfw overflow o [1997/06/01] kern/3739 pause key not disabled; weird stuff when o [1997/06/01] conf/3751 Improvements to /etc/rc{,.network,.pccard o [1997/06/02] ports/3759 tg xtem-5.23 (X11 TEx Menu) port submitted ( o [1997/06/02] bin/3762 dufault Bogus return values from rtprio(1) o [1997/06/02] docs/3764 systat(1) -vmstat description seems to be o [1997/06/04] conf/3775 Time Zone for Sri Lanka - LKT o [1997/06/04] bin/3778 ypbind -S domainname,server1,... does not o [1997/06/04] ports/3787 ports ghostscript-3.53 has bad PLIST o [1997/06/07] bin/3805 single process tftpd o [1997/06/07] ports/3806 ports update s3mod to 1.09 o [1997/06/08] docs/3808 The manpage telnet.1 has many bugs. o [1997/06/09] docs/3819 davidn man (5) login.conf specifies passwordtime o [1997/06/09] ports/3824 ports New port: snes97 o [1997/06/09] bin/3826 KerberosIV sometimes hangs rcp o [1997/06/09] ports/3831 ports netris port doesn't install sr o [1997/06/10] kern/3836 Cannot remove HUGE directory o [1997/06/10] bin/3837 dufault new feature for rtprio o [1997/06/10] kern/3839 X startup undoes keyboard repeat rate (pc o [1997/06/12] kern/3853 netboot/ns8390.c breaks NS datasheet o [1997/06/12] i386/3856 Improvement to autodetection logic o [1997/06/13] bin/3859 Setting the $0 variable in perl dosnt do o [1997/06/14] bin/3866 rcs2log fails with eastern timezones o [1997/06/14] ports/3870 ports Upgrade tkdesk 1.0b3 --> 1.0b4 o [1997/06/15] kern/3879 Can't export mounted ext2fs via NFS o [1997/06/16] conf/3886 install does not build sendmail host stat o [1997/06/17] ports/3888 ports port net/wu-ftpd: tiny bug that is wu-ftp o [1997/06/17] bin/3891 NIS-only netgroup lookups don't work o [1997/06/17] ports/3892 max new port: www/webxref (cross-reference ge o [1997/06/17] gnu/3894 manpath segfaults if it dosen't understan o [1997/06/18] kern/3901 Multicast for Intel 10/100 Ethernet Card o [1997/06/19] bin/3903 markm Kerberized su -l fails with segfault o [1997/06/19] misc/3912 ctags(1) cannot trace some macro correctl o [1997/06/20] gnu/3918 vi dosnt wrap lines when called from send o [1997/06/22] ports/3928 ports New port: jp-pgp-2.6.3ia (language) o [1997/06/23] kern/3938 Problem about mmap() over NFS o [1997/06/23] ports/3939 ports new port: latex2html_icon_server o [1997/06/23] ports/3940 ports port of latex2html-96.1 o [1997/06/24] kern/3944 if_le doesnt receive ether multicast pack o [1997/06/24] bin/3947 /usr/src/etc/pccard_ether is too old... o [1997/06/25] kern/3948 nonworking t/tcp server side a [1997/06/25] kern/3953 kern-config: options PANIC_REBOOT_WAIT_TI o [1997/06/25] ports/3955 ports -kpassive_ftp=true fails on socket connec o [1997/06/26] bin/3957 Makefile dependency error in amd o [1997/06/26] ports/3958 jmz a2ps fails if used according to man o [1997/06/26] i386/3962 print disk internal cache size during pro o [1997/06/27] kern/3968 Hardware probes die on Peak SBCs. o [1997/06/28] misc/3981 brian wtmp logging of ppp activity would be nic o [1997/06/29] ports/3983 ports New port: psf toolkit o [1997/06/30] ports/3991 ports set of OffiX ports o [1997/06/30] ports/3997 ports New port: VRML browser (vrweb) a [1997/07/01] bin/4004 moused(8) + international language text = o [1997/07/02] ports/4014 ports package/port installation obeys roots uma o [1997/07/02] ports/4017 ports Someone has to upgrade the plor port! o [1997/07/03] bin/4019 mount_mfs lacks an error message, and exi o [1997/07/03] kern/4020 itojun vxget() in /sys/dev/vx/if_vx.c needs rewo o [1997/07/03] ports/4023 ports One can't play the cardgame Ass on FreeBS o [1997/07/03] i386/4024 sos Patch to add dead key support to syscons o [1997/07/03] ports/4025 ports New port - jp-ebw3 o [1997/07/04] ports/4027 ports New port: rot13-1.3 o [1997/07/05] kern/4037 boot.flp panics after kernel load if >2 s o [1997/07/05] ports/4038 ports Initial port of the alpha-rel. WindowMake o [1997/07/06] kern/4039 2940UW and DCAS 32160 -- hungs if 40 MB/s o [1997/07/07] kern/4051 pppd connect 'chat ...' broken o [1997/07/07] kern/4052 VJ compression drops packets with IP+TCP o [1997/07/07] ports/4055 ports Port for XMpeg3 v1.0 o [1997/07/07] ports/4056 obrien Port for netpipes 3.2 o [1997/07/08] ports/4061 obrien new port: xklock o [1997/07/08] misc/4063 2.2.2R Installation fails if Jaz drive sp o [1997/07/09] ports/4067 ports wrong formats of files in offix.tar o [1997/07/13] ports/4083 ache netscape wrapper doesn't hand off args co o [1997/07/13] kern/4086 Floppy Disk Driver Problem o [1997/07/14] bin/4087 nameservice terminates after ndc restart o [1997/07/16] ports/4103 ports Should I or should I not ? o [1997/07/16] ports/4104 ports Minor fix to hobbes-icons-xpm3 o [1997/07/17] ports/4109 ports New port: xcopilot o [1997/07/17] kern/4112 PPSCLOCK kernel diffs o [1997/07/17] kern/4113 Processes shouldn't get SIGIO when the tt o [1997/07/18] bin/4116 davidn Kerberized login as .root fails to o [1997/07/18] ports/4118 ports New Port: bind 8.1.1 o [1997/07/19] bin/4120 Partition sysid prevents extended DOS par o [1997/07/19] ports/4124 ache Apache 1.2.1 port does not install docume o [1997/07/20] ports/4127 ache netscape-3.01: get rid of bogus error mes o [1997/07/20] ports/4133 ports new port: mpich.tar.gz o [1997/07/21] misc/4138 /etc/rc and sudo : chg to rm -rf /var/run o [1997/07/21] ports/4140 ports New port: xgolgo (x11) o [1997/07/22] ports/4142 ports Hugs port to FreeBSD 2.2.1 o [1997/07/22] ports/4149 ports gcl port isn't of latest version o [1997/07/23] bin/4152 pstat -T o [1997/07/23] kern/4153 New tcp initial send sequence number code o [1997/07/23] bin/4154 wish /bin/sleep handled fractions of a se o [1997/07/24] bin/4157 netstat atalk output should print symboli o [1997/07/24] bin/4163 ftp core dumps after hitting control-C f [1997/07/25] bin/4165 fetch gone to interminable query cycle af o [1997/07/26] bin/4172 link goes down for too long -- transfer f o [1997/07/26] ports/4174 ports file mode of jnethack o [1997/07/27] bin/4182 netstat should always print the interface o [1997/07/27] bin/4183 How about upgrading bc to 1.04? o [1997/07/28] kern/4184 minor nits in sys/netatalk o [1997/07/28] bin/4187 The w command should have a larger tty fi o [1997/07/30] ports/4192 ports New port: Amulet o [1997/07/31] conf/4201 Installing only X-User does not install c o [1997/07/31] ports/4203 ports Updated port file for the perl package p5 o [1997/07/31] bin/4204 ac printed wrong report about tty users o [1997/08/01] misc/4208 sos New syscons font o [1997/08/02] bin/4216 dlsym returns null o [1997/08/03] ports/4219 ports TkRef submitted to Ports o [1997/08/03] kern/4221 Kernel mode pppd doesen't update wtmp on o [1997/08/03] docs/4223 dump(8) man page error o [1997/08/03] ports/4224 ports New Port: qpage (v3.2) o [1997/08/04] ports/4227 ports cops perl script produces errors o [1997/08/04] conf/4229 Ethernet interface unreachable on bootup o [1997/08/06] ports/4232 scrappy Boot-time start of postgressql postmaster o [1997/08/06] misc/4235 asami /usr/share/mk/bsd.ports.mk and GNU config o [1997/08/06] bin/4238 chpass only occasionally works in conjunc o [1997/08/06] ports/4239 ports New Port: xtattr o [1997/08/07] kern/4243 file locking doesn't work for pipe o [1997/08/07] bin/4247 modification to /etc/security for FreeBSD o [1997/08/08] ports/4248 ports Port submission of Chimera 2.0a2 X-WWW Br o [1997/08/08] misc/4249 wpaul ypchsh doesn't care about changing a user a [1997/08/09] kern/4255 SMP kernel freezes on machines with >2 CP a [1997/08/09] kern/4257 itojun scsi RESERVATION CONFLICT support needed o [1997/08/10] ports/4263 ports new ports: jp-vfxdvik-18f (dvi viewer for o [1997/08/10] ports/4264 ports mftp get a Segmentation fault o [1997/08/11] ports/4277 ports New port: asclock o [1997/08/11] ports/4278 ports New port: mouseclock o [1997/08/12] ports/4281 ports Compress pcl graphics files - this is an o [1997/08/12] misc/4285 SDL RISCom/N2 (ISA) o [1997/08/12] ports/4287 jfitz mail/p5-Mail-Folder is broke a [1997/08/13] gnu/4290 ache man wrong viewed koi8-r manpages and neqn o [1997/08/13] ports/4296 ports New Port emulators/stonx o [1997/08/13] kern/4297 dufault SIGEV_NONE and SIGEV_SIGNAL go in signal. o [1997/08/13] bin/4298 joerg Is there any support for using the scsi C o [1997/08/13] i386/4300 msmith The initial timeout on open("/dev/lpt0".. o [1997/08/14] bin/4303 dumpon accepts any device, including none o [1997/08/14] ports/4304 ports Recommendation re. Ports Collection o [1997/08/15] ports/4306 ports update imlib to 0.3 f [1997/08/15] bin/4308 FreeBSD uses an out of date version of vi o [1997/08/15] ports/4311 ports new port of asmail-0.50 o [1997/08/17] misc/4316 pthread_cleanup_{push|pop} nonexistent o [1997/08/17] ports/4319 ports New port: ASFiles-1.0 o [1997/08/17] docs/4320 function prototype in pthread_detach man o [1997/08/17] bin/4323 Initial routing tables incomplete o [1997/08/18] kern/4329 read(2) from /dev/bktr0 hangs o [1997/08/18] ports/4330 ports new ports for rxvt with big5 support o [1997/08/18] ports/4331 ports new port of asprint o [1997/08/20] ports/4343 ports New ports submission - GUI E-Mail util o [1997/08/22] ports/4356 ports sudo shouldn't block signals in tgetpass( s [1997/08/22] ports/4360 ports new port of Amaya-1.0b o [1997/08/23] ports/4362 ports submit new port chinese/rxvt o [1997/08/23] conf/4363 kernel build depend on make obj o [1997/08/23] ports/4364 ports Upgrade Apache Port to 1.2.4 o [1997/08/24] bin/4369 dump can calculate wrong estimate times w o [1997/08/24] ports/4371 ports tkcvs+tkdiff o [1997/08/25] ports/4377 ports bkpupsd [device] o [1997/08/25] ports/4384 ports New port display-1.0 o [1997/08/25] gnu/4385 un- and unclearly documented options in t o [1997/08/26] ports/4387 ports New port: icewm o [1997/08/26] ports/4391 ports New port: VPCE o [1997/08/26] misc/4395 if exists(secure) in /usr/src/Makefile is o [1997/08/26] ports/4400 max jp-vfghostscript-5.03 is now available. o [1997/08/27] ports/4402 ports Port submission: math::MatrixReal o [1997/08/28] bin/4407 sendmail 8.8.7 can't write sendmail.pid o [1997/08/28] ports/4410 ache Update: screen(A multi-screen window mana o [1997/08/28] ports/4412 ports New port: YaTeX (in print and japanese) o [1997/08/29] kern/4413 No way to unmount a floppy that goes bad o [1997/08/29] misc/4414 be.iso.kbd errors in mapping o [1997/08/29] bin/4415 df(1) always pretends success o [1997/08/29] bin/4419 man can display the same man page twice o [1997/08/29] bin/4420 find -exedir doesn't chdir for first entr o [1997/08/30] docs/4439 davidn man pages wrong regarding login.conf o [1997/08/30] kern/4441 3com Etherlink III card not working while o [1997/08/31] conf/4444 Can't seem to configure for a DEC VRT17-H o [1997/09/01] ports/4446 ports New port: Atlast-1.0 o [1997/09/02] bin/4452 wpaul /etc/ethers and NIS: Bad comment parser o [1997/09/03] bin/4459 bde No prototype for moncontrol(3) and monsta o [1997/09/04] kern/4463 When using ipfw, all I get is the followi o [1997/09/04] ports/4465 ports cd-write port doesn't work o [1997/09/04] misc/4468 dlopen is not available from static execu o [1997/09/04] misc/4470 libc_r deviates from the pthread standard o [1997/09/04] docs/4472 manpage for /usr/bin/printf is not comple o [1997/09/07] ports/4481 ports yet another Mac hfs utility o [1997/09/07] misc/4482 jdp A bug in dynamic loader design o [1997/09/07] bin/4483 w, who, and the like are broken o [1997/09/07] bin/4484 peter sendmail is barfing o [1997/09/07] kern/4485 boot fials if root fs blocksize is not 8k o [1997/09/07] ports/4492 ports ports upgrade: korean/netscape3 o [1997/09/08] ports/4496 ports new port of latex2html-97.1.tar.gz o [1997/09/08] ports/4499 ports Update of slurp port o [1997/09/08] bin/4502 Wrong variable type in tftp.h include fil o [1997/09/11] ports/4510 ports New port: lftp-0.12.2 o [1997/09/12] ports/4521 ports 'Joe' editor does not show control-chars o [1997/09/13] ports/4527 ports Fxtv - New TV app port for 2.2.5 & 3.0-cu o [1997/09/13] kern/4528 processes hang if the mount_portal proces o [1997/09/13] ports/4529 ports New port: kaskade-3.1.1 o [1997/09/13] ports/4530 ports New port: Xinvest o [1997/09/13] ports/4531 ports New CAD port: femlab o [1997/09/14] ports/4532 ports path of sendmail in MH o [1997/09/14] ports/4534 ports replace gimp with gimp-devel o [1997/09/14] i386/4538 byteswapped ATAPI id strings o [1997/09/14] docs/4539 Wrong genitive from in submitters.sgml o [1997/09/14] ports/4540 ports Ssh-port not up to date. o [1997/09/14] bin/4541 Data needed for slovene localization o [1997/09/14] docs/4542 Slovene WWW and FTP mirrors of FreeBSD o [1997/09/14] ports/4546 ports HDF-lib port revised o [1997/09/15] i386/4547 asc.c and pcaudio.c should use selrecord 598 problems total. From owner-freebsd-bugs Mon Sep 15 19:30:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA14109 for bugs-outgoing; Mon, 15 Sep 1997 19:30:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA14094; Mon, 15 Sep 1997 19:30:02 -0700 (PDT) Resent-Date: Mon, 15 Sep 1997 19:30:02 -0700 (PDT) Resent-Message-Id: <199709160230.TAA14094@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, ortmann@sparc.isl.net Received: from watcher.isl.net (ppp27-uunet.infopet.com [208.210.103.29]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA13848 for ; Mon, 15 Sep 1997 19:25:08 -0700 (PDT) Received: (from ortmann@localhost) by watcher.isl.net (8.8.7/8.8.5) id VAA02392; Mon, 15 Sep 1997 21:19:58 -0500 (CDT) Message-Id: <199709160219.VAA02392@watcher.isl.net> Date: Mon, 15 Sep 1997 21:19:58 -0500 (CDT) From: Daniel Ortmann Reply-To: ortmann@sparc.isl.net To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/4550: /proc/curproc/{mem,status} are 0 size Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4550 >Category: kern >Synopsis: /proc/curproc/{mem,status} are 0 size >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Sep 15 19:30:00 PDT 1997 >Last-Modified: >Originator: Daniel Ortmann >Organization: (not-applicable) >Release: FreeBSD 3.0-CURRENT i386 >Environment: Last ctm applied before rebuilding the src and kernel is src-cur.3048.gz >Description: /bin/ls -lF /proc/221 total 784 --w------- 1 ortmann ortmann 0 Sep 15 19:47 ctl -r--r--r-- 1 ortmann ortmann 76 Sep 15 19:47 etype -r-xr-xr-x 1 bin bin 393216 Jun 8 11:53 file* -rw------- 1 ortmann ortmann 176 Sep 15 19:47 fpregs -r--r--r-- 1 ortmann ortmann 76 Sep 15 19:47 map -rw-r----- 1 ortmann kmem 0 Sep 15 19:47 mem --w------- 1 ortmann ortmann 0 Sep 15 19:47 note --w------- 1 ortmann ortmann 0 Sep 15 19:47 notepg -rw------- 1 ortmann ortmann 76 Sep 15 19:47 regs -r--r--r-- 1 ortmann ortmann 0 Sep 15 19:47 status The "mem" and "status" files show a size of 0 for all processes that I have inspected. I expected that both of these files would show a non-zero size. >How-To-Repeat: /bin/ls -lF /proc/curproc/ >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Mon Sep 15 19:40:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA14776 for bugs-outgoing; Mon, 15 Sep 1997 19:40:03 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA14764; Mon, 15 Sep 1997 19:40:01 -0700 (PDT) Resent-Date: Mon, 15 Sep 1997 19:40:01 -0700 (PDT) Resent-Message-Id: <199709160240.TAA14764@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, ortmann@sparc.isl.net Received: from watcher.isl.net (ppp27-uunet.infopet.com [208.210.103.29]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA14527 for ; Mon, 15 Sep 1997 19:35:48 -0700 (PDT) Received: (from ortmann@localhost) by watcher.isl.net (8.8.7/8.8.5) id VAA02530; Mon, 15 Sep 1997 21:30:40 -0500 (CDT) Message-Id: <199709160230.VAA02530@watcher.isl.net> Date: Mon, 15 Sep 1997 21:30:40 -0500 (CDT) From: Daniel Ortmann Reply-To: ortmann@sparc.isl.net To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/4551: cat /proc/*/mem gives "cat: /proc/0/mem: Bad address" Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4551 >Category: kern >Synopsis: cat /proc/*/mem gives "cat: /proc/0/mem: Bad address" >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Sep 15 19:40:00 PDT 1997 >Last-Modified: >Originator: Daniel Ortmann >Organization: (not-applicable) >Release: FreeBSD 3.0-CURRENT i386 >Environment: The last ctm update applied was src-cur.3048.gz >Description: cat /proc/*/mem >/dev/null produces the following: cat: /proc/0/mem: Bad address cat: /proc/1/mem: Bad address cat: /proc/119/mem: Bad address cat: /proc/122/mem: Bad address cat: /proc/125/mem: Bad address cat: /proc/128/mem: Bad address cat: /proc/1478/mem: Bad address cat: /proc/1486/mem: Bad address cat: /proc/165/mem: Bad address cat: /proc/1720/mem: Bad address cat: /proc/1968/mem: Bad address cat: /proc/2/mem: Bad address cat: /proc/2040/mem: Bad address cat: /proc/2041/mem: Bad address cat: /proc/210/mem: Bad address cat: /proc/213/mem: Bad address cat: /proc/214/mem: Bad address cat: /proc/215/mem: Bad address cat: /proc/216/mem: Bad address cat: /proc/217/mem: Bad address cat: /proc/218/mem: Bad address cat: /proc/219/mem: Bad address cat: /proc/220/mem: Bad address cat: /proc/221/mem: Bad address cat: /proc/222/mem: Bad address cat: /proc/223/mem: Bad address cat: /proc/224/mem: Bad address cat: /proc/227/mem: Bad address cat: /proc/27/mem: Bad address cat: /proc/3/mem: Bad address cat: /proc/4/mem: Bad address cat: /proc/67/mem: Bad address cat: /proc/85/mem: Bad address cat: /proc/94/mem: Bad address cat: /proc/98/mem: Bad address cat: /proc/curproc/mem: Bad address I expected >How-To-Repeat: cat /proc/*/mem >/dev/null >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Mon Sep 15 21:10:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA19211 for bugs-outgoing; Mon, 15 Sep 1997 21:10:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA19202; Mon, 15 Sep 1997 21:10:01 -0700 (PDT) Date: Mon, 15 Sep 1997 21:10:01 -0700 (PDT) Message-Id: <199709160410.VAA19202@hub.freebsd.org> To: freebsd-bugs Cc: From: John-Mark Gurney Subject: Re: kern/4551: cat /proc/*/mem gives "cat: /proc/0/mem: Bad address" Reply-To: John-Mark Gurney Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR kern/4551; it has been noted by GNATS. From: John-Mark Gurney To: ortmann@sparc.isl.net Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/4551: cat /proc/*/mem gives "cat: /proc/0/mem: Bad address" Date: Mon, 15 Sep 1997 20:59:59 -0700 Daniel Ortmann scribbled this message on Sep 15: > cat /proc/*/mem >/dev/null produces the following: > > cat: /proc/0/mem: Bad address umm.. isn't this expected at /proc/*/mem is the actually memory, and the first page (at least) is usually unmapped)... > cat: /proc/1/mem: Bad address > cat: /proc/119/mem: Bad address > cat: /proc/122/mem: Bad address > cat: /proc/125/mem: Bad address > > I expected what did you expect?? > cat /proc/*/mem >/dev/null just this?? -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-bugs Mon Sep 15 21:51:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA23180 for bugs-outgoing; Mon, 15 Sep 1997 21:51:39 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA23124; Mon, 15 Sep 1997 21:51:23 -0700 (PDT) From: David Greenman Received: (from davidg@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id VAA14695; Mon, 15 Sep 1997 21:47:49 -0700 (PDT) Date: Mon, 15 Sep 1997 21:47:49 -0700 (PDT) Message-Id: <199709160447.VAA14695@freefall.freebsd.org> To: ortmann@sparc.isl.net, davidg@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/4550 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: /proc/curproc/{mem,status} are 0 size State-Changed-From-To: open-closed State-Changed-By: davidg State-Changed-When: Mon Sep 15 21:46:57 PDT 1997 State-Changed-Why: The size is intentionally 0. From owner-freebsd-bugs Mon Sep 15 21:52:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA23317 for bugs-outgoing; Mon, 15 Sep 1997 21:52:14 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA23287; Mon, 15 Sep 1997 21:52:04 -0700 (PDT) From: David Greenman Received: (from davidg@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id VAA14775; Mon, 15 Sep 1997 21:48:30 -0700 (PDT) Date: Mon, 15 Sep 1997 21:48:30 -0700 (PDT) Message-Id: <199709160448.VAA14775@freefall.freebsd.org> To: ortmann@sparc.isl.net, davidg@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/4551 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: cat /proc/*/mem gives "cat: /proc/0/mem: Bad address" State-Changed-From-To: open-closed State-Changed-By: davidg State-Changed-When: Mon Sep 15 21:47:54 PDT 1997 State-Changed-Why: The "bad address" is caused by the first page of a process being unreadable. The results are as expected. From owner-freebsd-bugs Mon Sep 15 23:41:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA14468 for bugs-outgoing; Mon, 15 Sep 1997 23:41:59 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA14402; Mon, 15 Sep 1997 23:41:37 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id QAA20844; Tue, 16 Sep 1997 16:39:52 +1000 Date: Tue, 16 Sep 1997 16:39:52 +1000 From: Bruce Evans Message-Id: <199709160639.QAA20844@godzilla.zeta.org.au> To: davidg@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, ortmann@sparc.isl.net Subject: Re: kern/4550 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Synopsis: /proc/curproc/{mem,status} are 0 size >... >The size is intentionally 0. The bug is that "regular" files are irregular. Bruce From owner-freebsd-bugs Tue Sep 16 00:32:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA27017 for bugs-outgoing; Tue, 16 Sep 1997 00:32:53 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA26998 for ; Tue, 16 Sep 1997 00:32:50 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id AAA28609; Tue, 16 Sep 1997 00:32:49 -0700 (PDT) Date: Tue, 16 Sep 1997 00:32:49 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199709160732.AAA28609@kithrup.com> To: bugs@freebsd.org Subject: Re: kern/4550 Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199709160639.QAA20844.kithrup.freebsd.bugs@godzilla.zeta.org.au> you write: >>The size is intentionally 0. >The bug is that "regular" files are irregular. If csd/bsd files were handled on a per-filesystem basis, I would have made the pseudofiles that. Or possibly named pipes. But they aren't, so I couldn't do that. At some point, it may be worthwhile adding a new filetype -- "pseudofile". Not quite a normal file, not quite a pipe or csd or bsd file. But, for now, they need to remain normal files with a zero length. Note that any program which assumes that a file doesn't change length while it's being read (or written ;)) should probably be considered broken. I believe ftp is one of these; so is rcp. From owner-freebsd-bugs Tue Sep 16 00:50:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA01749 for bugs-outgoing; Tue, 16 Sep 1997 00:50:51 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA01715; Tue, 16 Sep 1997 00:50:44 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA05097; Tue, 16 Sep 1997 09:50:03 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA20208; Tue, 16 Sep 1997 09:44:13 +0200 (MET DST) Message-ID: <19970916094413.EA64826@uriah.heep.sax.de> Date: Tue, 16 Sep 1997 09:44:13 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: bde@zeta.org.au (Bruce Evans) Cc: davidg@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, ortmann@sparc.isl.net Subject: Re: kern/4550 References: <199709160639.QAA20844@godzilla.zeta.org.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199709160639.QAA20844@godzilla.zeta.org.au>; from Bruce Evans on Sep 16, 1997 16:39:52 +1000 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Bruce Evans wrote: > >Synopsis: /proc/curproc/{mem,status} are 0 size > >... > >The size is intentionally 0. > > The bug is that "regular" files are irregular. You mean, it should better display as: i-w------- 1 root wheel ctl ir--r--r-- 1 root wheel etype -r-x------ 1 bin bin 229376 Aug 10 00:06 file* irw------- 1 root wheel fpregs ir--r--r-- 1 root wheel map irw-r----- 1 root kmem mem i-w------- 1 root wheel note i-w------- 1 root wheel notepg irw------- 1 root wheel regs ir--r--r-- 1 root wheel status instead? (`i' == ``irregular file'') ;-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Tue Sep 16 01:12:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA06630 for bugs-outgoing; Tue, 16 Sep 1997 01:12:06 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA05619; Tue, 16 Sep 1997 01:07:59 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id SAA24027; Tue, 16 Sep 1997 18:04:37 +1000 Date: Tue, 16 Sep 1997 18:04:37 +1000 From: Bruce Evans Message-Id: <199709160804.SAA24027@godzilla.zeta.org.au> To: bde@zeta.org.au, j@uriah.heep.sax.de Subject: Re: kern/4550 Cc: davidg@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, ortmann@sparc.isl.net Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> >Synopsis: /proc/curproc/{mem,status} are 0 size >> >... >> >The size is intentionally 0. >> >> The bug is that "regular" files are irregular. > >You mean, it should better display as: > >i-w------- 1 root wheel ctl >ir--r--r-- 1 root wheel etype I mean, so that little things like stdio can work. Bruce >From fseek.c: /* * Can only optimise if: * reading (and not reading-and-writing); * not unbuffered; and * this is a `regular' Unix file (and hence seekfn==__sseek). [and regular files are actually regular] * We must check __NBF first, because it is possible to have __NBF * and __SOPT both set. */ if (fp->_bf._base == NULL) __smakebuf(fp); if (fp->_flags & (__SWR | __SRW | __SNBF | __SNPT)) goto dumb; if ((fp->_flags & __SOPT) == 0) { if (seekfn != __sseek || fp->_file < 0 || fstat(fp->_file, &st) || (st.st_mode & S_IFMT) != S_IFREG) { fp->_flags |= __SNPT; goto dumb; } fp->_blksize = st.st_blksize; fp->_flags |= __SOPT; } From owner-freebsd-bugs Tue Sep 16 02:01:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA12892 for bugs-outgoing; Tue, 16 Sep 1997 02:01:31 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA12886 for ; Tue, 16 Sep 1997 02:01:26 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id SAA25472; Tue, 16 Sep 1997 18:50:50 +1000 Date: Tue, 16 Sep 1997 18:50:50 +1000 From: Bruce Evans Message-Id: <199709160850.SAA25472@godzilla.zeta.org.au> To: bugs@FreeBSD.ORG, sef@Kithrup.COM Subject: Re: kern/4550 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Note that any program which assumes that a file doesn't change length while >it's being read (or written ;)) should probably be considered broken. I >believe ftp is one of these; so is rcp. Try `tar cf /dev/null /proc' for a large collection of errors or Lite2's wc on /proc/*/* for a small collection of errors (it stops on the first error :-(). Bruce From owner-freebsd-bugs Tue Sep 16 05:20:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA20865 for bugs-outgoing; Tue, 16 Sep 1997 05:20:03 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA20851; Tue, 16 Sep 1997 05:20:01 -0700 (PDT) Resent-Date: Tue, 16 Sep 1997 05:20:01 -0700 (PDT) Resent-Message-Id: <199709161220.FAA20851@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, thz@tuebingen.netsurf.de Received: (from nobody@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA20515; Tue, 16 Sep 1997 05:10:47 -0700 (PDT) Message-Id: <199709161210.FAA20515@hub.freebsd.org> Date: Tue, 16 Sep 1997 05:10:47 -0700 (PDT) From: thz@tuebingen.netsurf.de To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: bin/4553: man fails to open manpage if ./man exists in current dir. Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4553 >Category: bin >Synopsis: man fails to open manpage if ./man exists in current dir. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 16 05:20:00 PDT 1997 >Last-Modified: >Originator: Thomas Zenker >Organization: Lennartz electronic >Release: 2.2.1/2.2.2 >Environment: FreeBSD mezcal.tue.le 2.2.2-RELEASE FreeBSD 2.2.2-RELEASE #5: Mon Sep 15 14:36:54 MET DST 1997 thz@mezcal.tue.le:/usr/src/sys/compile/MEZCAL i386 >Description: /usr/bin/man man failes to open the man page if it exists in ./man/manX/manpage.X but not in ./man/catX/manpage.X.gz Obviously it happens because man changes into the directory ./man itself. I didn't verify why there is such a relative directory in the man search path (manpath shows "....:./man:..." last (the offending) line of the output of man -d bpool: "trying command: (cd ./man ; /bin/cat ./man/man3/bpool.3 | /usr/bin/tbl | /usr/bi n/groff -Wall -mtty-char -Tascii -man | /usr/bin/col | /usr/local/bin/less) this will never work, because we are searching in ./man/man/man3 >How-To-Repeat: Create a man directory structure in the current directory, create a manpage in man/man3/mymanpage.3, do a man mymanpage. >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Sep 16 06:30:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA23794 for bugs-outgoing; Tue, 16 Sep 1997 06:30:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA23785; Tue, 16 Sep 1997 06:30:01 -0700 (PDT) Resent-Date: Tue, 16 Sep 1997 06:30:01 -0700 (PDT) Resent-Message-Id: <199709161330.GAA23785@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, thz@tuebingen.netsurf.de Received: (from nobody@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA23560; Tue, 16 Sep 1997 06:25:35 -0700 (PDT) Message-Id: <199709161325.GAA23560@hub.freebsd.org> Date: Tue, 16 Sep 1997 06:25:35 -0700 (PDT) From: thz@tuebingen.netsurf.de To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: bin/4554: pthread_cond_wait() doesn't wait for pthread_cond_signal() Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4554 >Category: bin >Synopsis: pthread_cond_wait() doesn't wait for pthread_cond_signal() >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 16 06:30:00 PDT 1997 >Last-Modified: >Originator: Thomas Zenker >Organization: Lennartz electronic >Release: 2.2.1/2.2.2 >Environment: >Description: pthread_cond_wait returns immediately without waiting for pthread_cond_signal by another thread. the reason is that in pthread_cond_wait the wakeup_time.tv_sec is not explicitely set to "wait forever" (-1). Debugging shows: wakeup_time.tv_sec is allways implicitely set to "wakeup immediately" (0). >How-To-Repeat: Calling pthread_cond_wait() never stops the current thread. >Fix: Set wakeup_time.tv_sec explicitely to wait forever in the function pthread_cond_wait() in file "uthread_cond.c". *** /vol/cdrom/usr/src/lib/libc_r/uthread/uthread_cond.c Fri Sep 20 08:3:50 1996 --- ./uthread_cond.c Tue Sep 16 12:54:56 1997 *************** *** 149,154 **** --- 149,158 ---- switch ((*cond)->c_type) { /* Fast condition variable: */ case COND_TYPE_FAST: + /* Set the wakeup time: wait forever */ + _thread_run->wakeup_time.tv_sec = -1; + _thread_run->wakeup_time.tv_nsec = -1; + /* Queue the running thread for the condition variable:*/ _thread_queue_enq(&(*cond)->c_queue, _thread_run ); >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Sep 16 08:27:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA00206 for bugs-outgoing; Tue, 16 Sep 1997 08:27:12 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA00189; Tue, 16 Sep 1997 08:26:52 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id QAA02570; Tue, 16 Sep 1997 16:54:49 +0200 (CEST) To: joerg_wunsch@interface-business.de (Joerg Wunsch) cc: bugs@FreeBSD.ORG, dfr@FreeBSD.ORG, dyson@FreeBSD.ORG Subject: Re: Yet another 2.2-stable NFS (client) panic In-reply-to: Your message of "Wed, 10 Sep 1997 12:22:02 +0200." <19970910122202.WS38344@ida.interface-business.de> Date: Tue, 16 Sep 1997 16:54:49 +0200 Message-ID: <2568.874421689@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <19970910122202.WS38344@ida.interface-business.de>, J Wunsch writes: >Fatal trap 12: page fault while in kernel mode >fault virtual address = 0x87654371 >fault code = supervisor read, page not present >instruction pointer = 0x8:0xf013476f >stack pointer = 0x10:0xefbffdb0 >frame pointer = 0x10:0xefbffdc0 >code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 >processor eflags = interrupt enabled, resume, IOPL = 3 >current process = 7004 (hpscan) >interrupt mask = bio > >0xf013476f : movl 0x50(%edx),%eax I am not at all happy about the way reassignbuf() is used in the kernel, and would not be one bit surprised if there is a bug there somewhere. No good leads though... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-bugs Tue Sep 16 08:28:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA00332 for bugs-outgoing; Tue, 16 Sep 1997 08:28:17 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA00323 for ; Tue, 16 Sep 1997 08:28:12 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id QAA02510; Tue, 16 Sep 1997 16:44:56 +0200 (CEST) To: Graham Wheeler cc: mike@smith.net.au (Mike Smith), freebsd-bugs@FreeBSD.ORG Subject: Re: Memory leak in getservbyXXX? In-reply-to: Your message of "Sat, 12 Sep 1997 10:40:10 +0200." <199709120840.KAA20043@cdsec.com> Date: Tue, 16 Sep 1997 16:44:56 +0200 Message-ID: <2508.874421096@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk (Sorry for the delay) I've looked at these stack traces, and I'm pretty sure I know the smell of this one. My guess number one is that malloc bails out and that the topmost couple of entries come from the __cleanup that happens in abort(). Make sure that filedescriptor #2 (as in: write(2,"FOO!",4)) is open and points to something that will let you read the message, and look for messages there. Also: ln -s AJ /etc/malloc.conf This will make finding the problem faster in most cases. My guess number two is memory corruption. The only syscalls/libs called from phkmalloc are sbrk(), write(), madvise(), mmap(), and abort(). At least as far as I remember. Hope this helps. Poul-Henning In message <199709120840.KAA20043@cdsec.com>, Graham Wheeler writes: >> > In each case, while the location in our own code varies, the stack trace >> > always ends in a call to getservbyname() or getservbyport(). These in turn >> > are calling either malloc() or free(), which in turn seem to be calling >> > fstat() (at least according to the stack backtrace). >> >> That's fairly odd; malloc()/free() do not call fstat(). Are you using >> the system malloc() or the GNU version? > >Here are three sample core dumps: > >#0 0x52220 in fstat () >#1 0x95000 in ?? () >#2 0x5256e in free () >#3 0x46312 in fclose () >#4 0x334af in endservent () >#5 0x2f84e in getservbyname () > > > >#0 0x51a60 in fstat () >#1 0x63f54 in buffer () >#2 0x51da2 in fstat () >#3 0x524f6 in malloc () >#4 0x50ba9 in __smakebuf () >#5 0x461c0 in __srefill () > > >#0 0x52220 in fstat () >#1 0x83000 in ?? () >#2 0x5256e in free () >#3 0x46312 in fclose () >#4 0x334af in endservent () >#5 0x2f79a in getservbyport () -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-bugs Tue Sep 16 09:06:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA02410 for bugs-outgoing; Tue, 16 Sep 1997 09:06:46 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA02403; Tue, 16 Sep 1997 09:06:39 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id SAA00523; Tue, 16 Sep 1997 18:11:05 +0200 (SAT) Received: by citadel via recvmail id 519; Tue Sep 16 18:10:57 1997 by gram.cdsec.com (8.8.5/8.8.5) id RAA00281; Tue, 16 Sep 1997 17:35:20 +0200 (SAT) From: Graham Wheeler Message-Id: <199709161535.RAA00281@cdsec.com> Subject: Re: Memory leak in getservbyXXX? To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 16 Sep 1997 17:35:19 +0200 (SAT) Cc: freebsd-bugs@freebsd.org, hackers@freebsd.org In-Reply-To: <2508.874421096@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 16, 97 04:44:56 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk First off, I should say that I have found the problem. It is entirely my own code, so apologies for wasting people's time. Nontheless, I appreciate all the suggestions I got, and I learnt some useful stuff in the process (like the malloc options, which I never knew existed, not having done a `man malloc' for several years...) > I've looked at these stack traces, and I'm pretty sure I know the > smell of this one. > > My guess number one is that malloc bails out and that the topmost > couple of entries come from the __cleanup that happens in abort(). > > Make sure that filedescriptor #2 (as in: write(2,"FOO!",4)) is open > and points to something that will let you read the message, and look > for messages there. I'm impressed. The program is run as a daemon, so we weren't seeing the error message. Yesterday I had the idea of redirecting fd 2 when starting it up, and got the clue I needed; namely, malloc was reporting a recursive call. At the time that the gateway program was first written, FreeBSD did not yet support POSIX threads. Because the process is performance-critical, I wanted to avoid blocking calls as much as possible. Amongst such calls were DNS lookups (gethostbyXXX). So I got clever: I made a hash table of IP addresses to symbolic names, and I wrote code which spins off a child process for each DNS lookup which can't be satisfied from the cache. The child process communicates the result back to the parent via a pipe, and the parent adds this to the hash table. Because I wanted this to be completely asynchronous to the normal operation of the gateway, the parent reads from the pipe and inserts the result in the hash table in the SIGCHLD handler. The problem is that inserting an entry in the hash table requires dynamic memory allocation. So if the SIGCHLD happens while in a call to malloc(), then there is a recursive call. I'm currently trying to work around this by preallocating a hash table entry for the result before spinning off the child, and making sure that there are no calls to any other non-reentrant functions in the signal handler. Later I will use threads rather than a child process. It turns out that this was happening under FreeBSD 2.1, but that (i) it doesn't seem to happen as often and (ii) the process always exits. There is a second process running on the firewall whose task is somewhat like SysV's init - namely to keep restarting terminated processes. So we didn't notice it. Under FreeBSD 2.2.2, the process occasionally exits, but in most cases starts spinning in a busy loop, so we did notice it. I am assuming that when the process spins it is caused by the same problem; there is always the possibility that there are two bugs, and that the above will only fix the case where the process exits. I guess I'll find out soon enough... [In my defense I should state that the memory allocation is happening in a virtual method of a class about four levels deeper in the inheritance hierarchy - by the time that method was written I had probably forgotten that it was being called from within a signal handler. I guess this illustrates one of the potential hazards of systems programming in C++.] graham -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-bugs Tue Sep 16 10:43:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA08359 for bugs-outgoing; Tue, 16 Sep 1997 10:43:59 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA08329; Tue, 16 Sep 1997 10:43:50 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id TAA01024; Tue, 16 Sep 1997 19:43:14 +0200 (CEST) To: Graham Wheeler cc: freebsd-bugs@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Memory leak in getservbyXXX? In-reply-to: Your message of "Sat, 16 Sep 1997 17:35:19 +0200." <199709161535.RAA00281@cdsec.com> Date: Tue, 16 Sep 1997 19:43:13 +0200 Message-ID: <1022.874431793@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199709161535.RAA00281@cdsec.com>, Graham Wheeler writes: >First off, I should say that I have found the problem. It is entirely my >own code, so apologies for wasting people's time. Nontheless, I appreciate >all the suggestions I got, and I learnt some useful stuff in the process >(like the malloc options, which I never knew existed, not having done a >`man malloc' for several years...) Well, I found out that nobody else had either :-) It's much against my liking that the process can spin when I call abort(), but that is apearantly what POSIX dictates :-( -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-bugs Tue Sep 16 11:20:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA10727 for bugs-outgoing; Tue, 16 Sep 1997 11:20:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA10702; Tue, 16 Sep 1997 11:20:02 -0700 (PDT) Resent-Date: Tue, 16 Sep 1997 11:20:02 -0700 (PDT) Resent-Message-Id: <199709161820.LAA10702@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, tejblum@arc.hq.cti.ru Received: from yandex.hq.cti.ru (arc.hq.cti.ru [194.67.85.53]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA10313 for ; Tue, 16 Sep 1997 11:15:32 -0700 (PDT) Received: (from tejblum@localhost) by yandex.hq.cti.ru (8.8.7/8.8.5) id WAA14422; Tue, 16 Sep 1997 22:15:18 +0400 (MSD) Message-Id: <199709161815.WAA14422@yandex.hq.cti.ru> Date: Tue, 16 Sep 1997 22:15:18 +0400 (MSD) From: Dmitrij Tejblum Reply-To: tejblum@arc.hq.cti.ru To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: docs/4555: Typo in utf2(4) man page Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4555 >Category: docs >Synopsis: Typo in utf2(4) man page >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 16 11:20:00 PDT 1997 >Last-Modified: >Originator: Dmitrij Tejblum >Organization: CompTek >Release: FreeBSD 2.2-STABLE i386 >Environment: >Description: utf2(4) claims that runes 0x0080-0x03ff (00000bbb.bbbbbbbb) encoded with 2 ^ ^^^ bytes. Of course, it really means 0x0080-0x07ff. >How-To-Repeat: >Fix: --- /usr/src/lib/libc/locale/utf2.4 Tue Sep 16 18:20:11 1997 +++ utf2.4 Tue Sep 16 21:45:31 1997 @@ -60,7 +60,7 @@ encoding is represented by the following table: .Bd -literal [0x0000 - 0x007f] [00000000.0bbbbbbb] -> 0bbbbbbb -[0x0080 - 0x03ff] [00000bbb.bbbbbbbb] -> 110bbbbb, 10bbbbbb +[0x0080 - 0x07ff] [00000bbb.bbbbbbbb] -> 110bbbbb, 10bbbbbb [0x0400 - 0xffff] [bbbbbbbb.bbbbbbbb] -> 1110bbbb, 10bbbbbb, 10bbbbbb .Ed .Pp >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Sep 16 11:20:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA10745 for bugs-outgoing; Tue, 16 Sep 1997 11:20:10 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA10720; Tue, 16 Sep 1997 11:20:04 -0700 (PDT) Resent-Date: Tue, 16 Sep 1997 11:20:04 -0700 (PDT) Resent-Message-Id: <199709161820.LAA10720@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, Matthew Hunt Received: from mph124.rh.psu.edu (hunt@MPH124.rh.psu.edu [128.118.126.83]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA10514 for ; Tue, 16 Sep 1997 11:17:57 -0700 (PDT) Received: (from hunt@localhost) by mph124.rh.psu.edu (8.8.7/8.8.7) id OAA01592; Tue, 16 Sep 1997 14:17:56 -0400 (EDT) Message-Id: <199709161817.OAA01592@mph124.rh.psu.edu> Date: Tue, 16 Sep 1997 14:17:56 -0400 (EDT) From: Matthew Hunt To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: misc/4556: make can't build executable from single Fortran source Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4556 >Category: misc >Synopsis: make can't build executable from single Fortran source >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 16 11:20:02 PDT 1997 >Last-Modified: >Originator: Matthew Hunt >Organization: none >Release: FreeBSD 2.2-STABLE i386 >Environment: FreeBSD mph124.rh.psu.edu 2.2-STABLE FreeBSD 2.2-STABLE #0: Thu Sep 11 20:08:28 EDT 1997 hunt@mph124.rh.psu.edu:/usr/src/sys/compile/WOPR i386 # $Id: sys.mk,v 1.16.2.3 1997/04/20 20:16:13 jkh Exp $ >Description: As the legions reported unnecessarily to jkh, some people write Fortran on FreeBSD. It seems that make knows how to build foo.o from foo.f, but cannot build foo from foo.f. Contrast this behavior with C code; make can build a single C source file into a binary. >How-To-Repeat: I have a simple Fortran program contained in prob1.f. No Makefile is present in the current directory. mph124:~/tmp$ ls -l prob1* -rw-r--r-- 1 hunt users 132 Sep 16 14:06 prob1.f mph124:~/tmp$ make prob1 make: don't know how to make prob1. Stop mph124:~/tmp$ make prob1.o f77 -O -c prob1.f prob1.f: MAIN: >Fix: As far as I can tell, it should work! /usr/share/mk/sys.mk has these two rules: .f: ${FC} ${FFLAGS} ${LDFLAGS} -o ${.TARGET} ${.IMPSRC} [...] .f.o: ${FC} ${FFLAGS} -c ${.IMPSRC} I cannot figure out why the second one works, but the first does not. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Sep 16 16:20:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA26416 for bugs-outgoing; Tue, 16 Sep 1997 16:20:06 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA26404; Tue, 16 Sep 1997 16:20:02 -0700 (PDT) Resent-Date: Tue, 16 Sep 1997 16:20:02 -0700 (PDT) Resent-Message-Id: <199709162320.QAA26404@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, roberte@MEP.Ruhr-Uni-Bochum.de Received: from ghost.mep.ruhr-uni-bochum.de (ghost.mep.ruhr-uni-bochum.de [134.147.6.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA26313 for ; Tue, 16 Sep 1997 16:18:52 -0700 (PDT) Received: (from roberte@localhost) by ghost.mep.ruhr-uni-bochum.de (8.8.5/8.8.4) id BAA19822; Wed, 17 Sep 1997 01:18:51 +0200 (MESZ) Message-Id: <199709162318.BAA19822@ghost.mep.ruhr-uni-bochum.de> Date: Wed, 17 Sep 1997 01:18:51 +0200 (MESZ) From: Robert Eckardt Reply-To: roberte@MEP.Ruhr-Uni-Bochum.de To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/4558: ls -d does not sort directories as plain files Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4558 >Category: bin >Synopsis: ls -d does not sort directories as plain files >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 16 16:20:00 PDT 1997 >Last-Modified: >Originator: Robert Eckardt >Organization: >Release: FreeBSD 2.2.2-RELEASE i386 >Environment: System from WC's 2.2.2 CD >Description: As documented in the man page ls's option `-d' should list directories as plain files. Therefore, one would expect that files and directories are sorted on an equal footing (as it is on SunOS5.4, AIX, Linux). However, the (sorted) directories are appended after the sorted files. I don't know whether this behaviour is considered `classic', but it is inconsistent and surprising. >How-To-Repeat: # cd to_an_empty_test_directory # touch a c # mkdir b # ls -l total 1 -rw-rw-r-- 1 roberte work 0 17 Sep 00:58 a drwxrwxr-x 2 roberte work 512 17 Sep 00:58 b -rw-rw-r-- 1 roberte work 0 17 Sep 00:58 c # ls -ld * -rw-rw-r-- 1 roberte work 0 17 Sep 00:58 a -rw-rw-r-- 1 roberte work 0 17 Sep 00:58 c drwxrwxr-x 2 roberte work 512 17 Sep 00:58 b >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Sep 16 16:45:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA27363 for bugs-outgoing; Tue, 16 Sep 1997 16:45:11 -0700 (PDT) Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA27340 for ; Tue, 16 Sep 1997 16:45:01 -0700 (PDT) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id JAA00286; Wed, 17 Sep 1997 09:08:20 +0930 (CST) Message-Id: <199709162338.JAA00286@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Poul-Henning Kamp cc: Graham Wheeler , mike@smith.net.au (Mike Smith), freebsd-bugs@FreeBSD.ORG Subject: Re: Memory leak in getservbyXXX? In-reply-to: Your message of "Tue, 16 Sep 1997 16:44:56 +0200." <2508.874421096@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Sep 1997 09:08:16 +0930 From: Mike Smith Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The only syscalls/libs called from phkmalloc are sbrk(), write(), > madvise(), mmap(), and abort(). At least as far as I remember. There's a readlink() in there as well, Would building malloc with EXTRA_SANITY help if there is indeed a corruption issue involved? mike From owner-freebsd-bugs Tue Sep 16 18:49:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04460 for bugs-outgoing; Tue, 16 Sep 1997 18:49:27 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04451 for ; Tue, 16 Sep 1997 18:49:24 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id SAA06961; Tue, 16 Sep 1997 18:48:36 -0700 (PDT) Date: Tue, 16 Sep 1997 18:48:36 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199709170148.SAA06961@kithrup.com> To: roberte@MEP.Ruhr-Uni-Bochum.de Subject: Re: bin/4558: ls -d does not sort directories as plain files Newsgroups: kithrup.freebsd.bugs In-Reply-To: <199709162318.BAA19822.kithrup.freebsd.bugs@ghost.mep.ruhr-uni-bochum.de> Organization: Kithrup Enterprises, Ltd. Cc: bugs@freebsd.org Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ># cd to_an_empty_test_directory ># touch a c ># mkdir b ># ls -l >total 1 >-rw-rw-r-- 1 roberte work 0 17 Sep 00:58 a >drwxrwxr-x 2 roberte work 512 17 Sep 00:58 b >-rw-rw-r-- 1 roberte work 0 17 Sep 00:58 c ># ls -ld * >-rw-rw-r-- 1 roberte work 0 17 Sep 00:58 a >-rw-rw-r-- 1 roberte work 0 17 Sep 00:58 c >drwxrwxr-x 2 roberte work 512 17 Sep 00:58 b I think I've figured out what's going on here; I've asked keith bostic for confirmation. In the meanwhile, I've got this patch, which seems to do the trick. (I don't think it's *quite* right, though.) *** ls.c.~1~ Tue Aug 27 14:51:48 1996 --- ls.c Tue Sep 16 18:34:56 1997 *************** *** 519,525 **** if ((*a)->fts_level == FTS_ROOTLEVEL) if (a_info == FTS_D) return (1); ! else if (b_info == FTS_D) return (-1); else return (sortfcn(*a, *b)); --- 519,525 ---- if ((*a)->fts_level == FTS_ROOTLEVEL) if (a_info == FTS_D) return (1); ! else if (b_info == FTS_D && !f_listdir) return (-1); else return (sortfcn(*a, *b)); From owner-freebsd-bugs Tue Sep 16 19:00:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA05035 for bugs-outgoing; Tue, 16 Sep 1997 19:00:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA05017; Tue, 16 Sep 1997 19:00:03 -0700 (PDT) Resent-Date: Tue, 16 Sep 1997 19:00:03 -0700 (PDT) Resent-Message-Id: <199709170200.TAA05017@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, sjr@home.net Received: from istari.home.net (cc158233-a.catv1.md.home.com [24.3.25.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04916 for ; Tue, 16 Sep 1997 18:56:27 -0700 (PDT) Received: (from sjr@localhost) by istari.home.net (8.8.7/8.8.6) id VAA29275; Tue, 16 Sep 1997 21:56:24 -0400 (EDT) Message-Id: <199709170156.VAA29275@istari.home.net> Date: Tue, 16 Sep 1997 21:56:24 -0400 (EDT) From: sjr@home.net Reply-To: sjr@home.net To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: kern/4559: 3C509 elink.h problem Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4559 >Category: kern >Synopsis: ELINK_ID_PORT problem with 3C509 cards >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 16 19:00:01 PDT 1997 >Last-Modified: >Originator: Stephen J. Roznowski >Organization: >Release: FreeBSD 3.0-CURRENT i386 >Environment: FreeBSD-2.2.2 and FreeBSD-3.0 >Description: There is a problem with the 3C509 recognition and the fix that is repeated in the mailing lists is to change ELINK_ID_PORT from 0x100 to 0x110 in /usr/src/sys/i386/isa/elink.h. >How-To-Repeat: >Fix: Change constant as stated above. I'm not sure this is the correct fix, but this is what is repeatly suggested and allows these cards to be recognized. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Tue Sep 16 22:25:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA16661 for bugs-outgoing; Tue, 16 Sep 1997 22:25:47 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA16653 for ; Tue, 16 Sep 1997 22:25:43 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id HAA07155; Wed, 17 Sep 1997 07:25:07 +0200 (CEST) To: Mike Smith cc: Graham Wheeler , freebsd-bugs@FreeBSD.ORG Subject: Re: Memory leak in getservbyXXX? In-reply-to: Your message of "Wed, 17 Sep 1997 09:08:16 +0930." <199709162338.JAA00286@word.smith.net.au> Date: Wed, 17 Sep 1997 07:25:06 +0200 Message-ID: <7153.874473906@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199709162338.JAA00286@word.smith.net.au>, Mike Smith writes: >> >> The only syscalls/libs called from phkmalloc are sbrk(), write(), >> madvise(), mmap(), and abort(). At least as far as I remember. > >There's a readlink() in there as well, Ahh, yes, forgot that. >Would building malloc with EXTRA_SANITY help if there is indeed a >corruption issue involved? I doubt it. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-bugs Tue Sep 16 23:20:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA20592 for bugs-outgoing; Tue, 16 Sep 1997 23:20:06 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA20549; Tue, 16 Sep 1997 23:20:03 -0700 (PDT) Resent-Date: Tue, 16 Sep 1997 23:20:03 -0700 (PDT) Resent-Message-Id: <199709170620.XAA20549@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, nobody@darkening.com Received: (from nobody@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA20300; Tue, 16 Sep 1997 23:16:13 -0700 (PDT) Message-Id: <199709170616.XAA20300@hub.freebsd.org> Date: Tue, 16 Sep 1997 23:16:13 -0700 (PDT) From: nobody@darkening.com To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: misc/4560: XFree86 3.3.1 fails to install properly in the 2.2-RELENG/STABLE tree. Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4560 >Category: misc >Synopsis: XFree86 3.3.1 fails to install properly in the 2.2-RELENG/STABLE tree. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 16 23:20:01 PDT 1997 >Last-Modified: >Originator: Thomas Strömberg >Organization: Burnt Toad/AK Enterprises >Release: 2.2-970911-RELENG >Environment: FreeBSD iskh122.haninge.kth.se 2.2-970911-RELENG FreeBSD 2.2-970911-RELENG #0: Thu Sep 11 12:42:34 GMT 1997 root@make.ican.net:/usr/src/sys/compile/GENERIC i386 >Description: When installing from boot disk, me (And 2 other users) of recent RELENG's have had bad XFree86 installs, where if we ran the Xfree86 configuration from /stand/sysinstall, it would say "Xfree86 has not been installed". This happened to me by installing from FAT, dont know about the other users. >How-To-Repeat: install XFree86 as part of the distribution set, and then try to configure it from /stand/sysinstall >Fix: manually install Xfree86 (./extract *.tgz) >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed Sep 17 02:50:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA03867 for bugs-outgoing; Wed, 17 Sep 1997 02:50:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA03857; Wed, 17 Sep 1997 02:50:01 -0700 (PDT) Date: Wed, 17 Sep 1997 02:50:01 -0700 (PDT) Message-Id: <199709170950.CAA03857@hub.freebsd.org> To: freebsd-bugs Cc: From: Bruce Evans Subject: Re: misc/4556: make can't build executable from single Fortran source Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR misc/4556; it has been noted by GNATS. From: Bruce Evans To: FreeBSD-gnats-submit@FreeBSD.ORG, mph@pobox.com Cc: Subject: Re: misc/4556: make can't build executable from single Fortran source Date: Wed, 17 Sep 1997 19:39:37 +1000 >>Description: > >As the legions reported unnecessarily to jkh, some people write Fortran >on FreeBSD. It seems that make knows how to build foo.o from foo.f, but >cannot build foo from foo.f. Contrast this behavior with C code; make can >build a single C source file into a binary. >As far as I can tell, it should work! /usr/share/mk/sys.mk has these >two rules: > >.f: > ${FC} ${FFLAGS} ${LDFLAGS} -o ${.TARGET} ${.IMPSRC} > >[...] > >.f.o: > ${FC} ${FFLAGS} -c ${.IMPSRC} > > >I cannot figure out why the second one works, but the first does not. The first one is hidden inside a %POSIX ifdef. Bruce From owner-freebsd-bugs Wed Sep 17 05:50:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA09354 for bugs-outgoing; Wed, 17 Sep 1997 05:50:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA09346; Wed, 17 Sep 1997 05:50:01 -0700 (PDT) Date: Wed, 17 Sep 1997 05:50:01 -0700 (PDT) Message-Id: <199709171250.FAA09346@hub.freebsd.org> To: freebsd-bugs Cc: From: Matthew Hunt Subject: Re: misc/4556: make can't build executable from single Fortran source Reply-To: Matthew Hunt Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR misc/4556; it has been noted by GNATS. From: Matthew Hunt To: Bruce Evans Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: misc/4556: make can't build executable from single Fortran source Date: Wed, 17 Sep 1997 08:40:25 -0400 On Wed, Sep 17, 1997 at 07:39:37PM +1000, Bruce Evans wrote: > The first one is hidden inside a %POSIX ifdef. Ah, yes. Actually, the two I posted are both inside the ifdef, but in the else clause, there's: .e.o .r.o .F.o .f.o: ${FC} ${RFLAGS} ${EFLAGS} ${FFLAGS} -c ${.IMPSRC} Thanks for clearing that up, I should have noticed it myself. So I guess my question now is, should there be a rule like: .f: ${FC} ${FFLAGS} ${LDFLAGS} -o ${.TARGET} ${.IMPSRC} in the non-Posix ruleset? -- Matthew Hunt * Think locally, act globally. finger hunt@mph124.rh.psu.edu for PGP public key. From owner-freebsd-bugs Wed Sep 17 06:30:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA10765 for bugs-outgoing; Wed, 17 Sep 1997 06:30:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA10752; Wed, 17 Sep 1997 06:30:02 -0700 (PDT) Resent-Date: Wed, 17 Sep 1997 06:30:02 -0700 (PDT) Resent-Message-Id: <199709171330.GAA10752@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, Norihiro Kumagai Received: from ns1.sharp.co.jp (ns1.sharp.co.jp [202.32.86.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA10658 for ; Wed, 17 Sep 1997 06:26:48 -0700 (PDT) Received: (from uucp@localhost) by ns1.sharp.co.jp (8.6.12/3.4W-95091612) id WAA14804 for ; Wed, 17 Sep 1997 22:26:45 +0900 Received: from marinfw.sharp.co.jp(202.32.86.11) by ns1.sharp.co.jp via smap (V1.3mjr) id sma014779; Wed Sep 17 22:25:47 1997 Received: from td1.tnr.sharp.co.jp (root@td1.tnr.sharp.co.jp [133.159.52.20]) by ns.sharp.co.jp (8.8.5/3.5W-97031013) with ESMTP id WAA07250 for ; Wed, 17 Sep 1997 22:25:47 +0900 (JST) Received: from mailfwd.slab.tnr.sharp.co.jp ([10.32.30.11]) by td1.tnr.sharp.co.jp (8.8.5/3.5W-97080613) with ESMTP id WAA02696 for ; Wed, 17 Sep 1997 22:25:46 +0900 (JST) Received: from tansu.slab.tnr.sharp.co.jp ([10.32.50.1]) by mailfwd.slab.tnr.sharp.co.jp (8.8.4+2.7Wbeta4/3.5Wpl1) with SMTP id WAA11518 for ; Wed, 17 Sep 1997 22:24:58 +0900 (JST) Received: from bell.slab.tnr.sharp.co.jp by tansu.slab.tnr.sharp.co.jp (4.1/3.5Wpl1) id AA19598; Wed, 17 Sep 97 22:25:44 JST Received: by bell.slab.tnr.sharp.co.jp (8.8.5/3.5Wpl5) id WAA00693 for FreeBSD-gnats-submit@freebsd.org; Wed, 17 Sep 1997 22:27:23 +0900 (JST) Message-Id: <199709171327.WAA00693@bell.slab.tnr.sharp.co.jp> Date: Wed, 17 Sep 1997 22:27:23 +0900 (JST) From: Norihiro Kumagai To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: docs/4561: .Ox macro needs to support "OpenBSD 2.1" Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4561 >Category: docs >Synopsis: .Ox macro needs to support "OpenBSD 2.1" >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 17 06:30:01 PDT 1997 >Last-Modified: >Originator: Norihiro Kumagai >Organization: Personal User >Release: FreeBSD 2.2.1-RELEASE i386 >Environment: FreeBSD-2.2.1-RELEASE packages: mirror-2.8,top-3.4,perl-5.003,jp-nkf-1.62,jp-mimekit-1.1, jp-less-290,jp-mh-6.8.3,jp-kterm-6.2.0,jp-kon-0994e, jp-groff-0.99,jp-Canna-3.2.2,xengine-1.0.1,zip-2.1, unzip-5.2,lha-1.14c,inn-1.5.1,jp-cmule-2.3,jp-man-1.1 jp-man-doc-2.1,gmake-3.75,donkey-0.5,lynx-2.7,xpdf-0.6, iozone-2.01 Hardware/Configuration DELL486MX,i486DX2-66MHz,24MB RAM,HDD 320MBIDE+200MBSCSI sc0,sio0,sio1,lpt0,psm0,fdc0,wdc0,wd0,wd1, aha0,sd0(aha0:0:0):,ep0,npx0,npx0: INT 16 interface ccd0-3 >Description: [phenomenon] After manually installing "fsirand.8", which may first appear in 2.2.2-RELEASE?!, as the result of 'man fsirand', you can see; HISTORY The fsirand command appeared in SunOS 3.x. ! This version of fsirand first appeared in A FreeBSD version first ap- peared in FreeBSD 2.2.5. which should have been seen as; The fsirand command appeared in SunOS 3.x. ! This version of fsirand first appeared in OpenBSD 2.1. A FreeBSD version first appeared in FreeBSD 2.2.5. The source code of "fsirand.8" tells as follows: This version of .Nm first appeared in .Ox 2.1 . A .Tn FreeBSD [discussion] The reason it lacks "OpenBSD 2.1" is no provision for new version of 2.1 in the definition of ".Ox" macro. So I believe we should add some adequate description to the macro file: /usr/share/tmac/mdoc/doc-syms. I Note that I examine the file "/usr/share/tmac/mdoc/doc-syms" in 2.2.2-RELEASE and find it also lacks the definition. >How-To-Repeat: 1) Install 2.2.2-RELEASE 2) Type "man fsirand" 3) Examine "HISTORY". >Fix: Please apply the following patch to "doc-syms" file; --- doc-syms.bak Tue Sep 9 23:32:17 1997 +++ doc-syms Tue Sep 9 23:33:29 1997 @@ -208,10 +208,12 @@ .if \\n(.$==2 \{\ . if "\\$1"1.2" \&\\*(tNOpenBSD\\*(aa 1.2\\*(aa\\$2 . if "\\$1"2.0" \&\\*(tNOpenBSD\\*(aa 2.0\\*(aa\\$2 +. if "\\$1"2.1" \&\\*(tNOpenBSD\\*(aa 2.1\\*(aa\\$2 .\} .if \\n(.$==1 \{\ . if "\\$1"1.2" \&\\*(tNOpenBSD\\*(aa 1.2\\*(aa . if "\\$1"2.0" \&\\*(tNOpenBSD\\*(aa 2.0\\*(aa +. if "\\$1"2.1" \&\\*(tNOpenBSD\\*(aa 2.1\\*(aa .\} .. .de Bt >Audit-Trail: >Unformatted: To: FreeBSD-gnats-submit@freebsd.org Cc: horikawa@jp.freebsd.org Subject: .Ox macro needs to support "OpenBSD 2.1" From: kuma Reply-To: kuma@slab.tnr.sharp.co.jp X-send-pr-version: 3.2 From owner-freebsd-bugs Wed Sep 17 06:52:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA11842 for bugs-outgoing; Wed, 17 Sep 1997 06:52:47 -0700 (PDT) Received: from canario.fiscodata (tty816.netpar.com.br [200.255.244.88] (may be forged)) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA11836 for ; Wed, 17 Sep 1997 06:52:40 -0700 (PDT) Received: from canario.fiscodata (canario.fiscodata [192.168.0.1]) by canario.fiscodata (8.8.7/8.8.5) with SMTP id KAA17636 for ; Wed, 17 Sep 1997 10:53:09 GMT Date: Wed, 17 Sep 1997 10:53:08 +0000 (GMT) From: Paulo Cesar Pereira de Andrade X-Sender: paulo@canario.fiscodata To: bugs@freebsd.org Subject: inetd in realloc Message-ID: X-FreeBSD: The Operating System X-Window-System: The Windowing System MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, after running out of swap space, my FreeBSD box is in trouble, so, before I restart it, I guess you would like to know what is happening. It have been restarted last sunday (due to power failure). uname: ------------ FreeBSD canario.fiscodata 2.2-STABLE FreeBSD 2.2-STABLE #0: Fri Aug 22 21:53:41 GMT 1997 root@canario.fiscodata:/usr/src/sys/compile/OTIMIZADO i386 ------------ (I have the last sources, but did not make world yet) swapinfo: ------------ Device 1K-blocks Used Avail Capacity Type /dev/sd0s1b 122880 27136 95680 22% Interleaved ------------ dmesg: ------------ Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2-STABLE #0: Fri Aug 22 21:53:41 GMT 1997 root@canario.fiscodata:/usr/src/sys/compile/OTIMIZADO CPU: AMD Enhanced Am486DX4 Write-Through (486-class CPU) Origin = "AuthenticAMD" Id = 0x484 Stepping=4 Features=0x1 real memory = 16777216 (16384K bytes) avail memory = 14778368 (14432K bytes) ahc0: at 0x1c00-0x1cff irq 11 on eisa0 slot 1 ahc0: aic7770 >= Rev E, Single Channel, SCSI Id=0, 4 SCBs ahc0 waiting for scsi devices to settle (ahc0:1:0): "HP C3724S 5153" type 0 fixed SCSI 2 sd0(ahc0:1:0): Direct-Access 1149MB (2354660 512 byte sectors) (ahc0:6:0): "QUANTUM MAVERICK 540S 0901" type 0 fixed SCSI 2 sd1(ahc0:6:0): Direct-Access 516MB (1057758 512 byte sectors) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <12 virtual consoles, flags=0x0> ed0 at 0x320-0x33f irq 5 on isa ed0: address 00:c0:df:12:9f:d2, type NE2000 (16 bit) sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16450 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16450 sio2: disabled, not probed. lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface lpt1 not found at 0xffffffff fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 765 fd0: 1.44MB 3.5in wdc0 not found at 0x1f0 npx0 flags 0x1 on motherboard npx0: INT 16 interface WARNING: / was not properly dismounted. pid 1752 (ping), uid 1000: exited on signal 3 swap_pager: out of swap space pid 690 (perl), uid 0, was killed: out of swap space pid 3130 (perl), uid 1001: exited on signal 11 (core dumped) swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space pid 8037 (ipop3d), uid 0: exited on signal 6 (core dumped) swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space pid 8047 (ipop3d), uid 0: exited on signal 6 (core dumped) swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space pid 8061 (sendmail), uid 0, was killed: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space swap_pager: out of swap space pid 11374 (perl), uid 0, was killed: out of swap space ------------ Messages to root: ------------ checking setuid files and devices: checking for uids of 0: root 0 toor 0 cmp: EOF on /var/log/dmesg.today canario kernel log messages: [Messages from dmesg] ------------- Problem 1: ------------- > telnet 0 Trying 0.0.0.0... Connected to 0. Escape character is '^]'. inetd in realloc(): warning: junk pointer, too low to make sense. FreeBSD (canario.fiscodata) (ttyp5) login: ------------- After this point, everithing seems to work fine. Problem 2: ------------- > ftp 0 Connected to 0. inetd in realloc(): warning: junk pointer, too low to make sense. ftp> ls Not connected. ftp> open 0 Not connected. ftp> open 0 Connected to 0. inetd in realloc(): warning: junk pointer, too low to make sense. ftp> user Not connected. ftp> ------------- Cant connect. >From a Windows box: ------------- F:\>ftp canario Connected to canario.fiscodata. inetd in realloc(): warning: junk pointer, too low to make sense. User (canario.fiscodata:(none)): paulo 220 canario.fiscodata FTP server (Version 6.00) ready. ftp> ls 331 Password required for paulo. 530 Please login with USER and PASS. 530 Please login with USER and PASS. ftp> user ------------- Worked Again: ------------- F:\>ftp canario Connected to canario.fiscodata. inetd in realloc(): warning: junk pointer, too low to make sense. User (canario.fiscodata:(none)): paulo 220 canario.fiscodata FTP server (Version 6.00) ready. ftp> ls 331 Password required for paulo. ftp> user paulo 530 Please login with USER and PASS. Login failed. ftp> user (username) paulo 331 Password required for paulo. Password: 331 Password required for paulo. Account: paulo 230 User paulo logged in. 502 ACCT command not implemented. Login failed. ftp> user ------------- Worked Sometimes, ftp works "in the first try". Sorry for the long email, but I think it is important. Paulo. From owner-freebsd-bugs Wed Sep 17 12:00:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA02538 for bugs-outgoing; Wed, 17 Sep 1997 12:00:03 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA02524; Wed, 17 Sep 1997 12:00:01 -0700 (PDT) Resent-Date: Wed, 17 Sep 1997 12:00:01 -0700 (PDT) Resent-Message-Id: <199709171900.MAA02524@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, le.englund@trollhattan.mail.telia.com Received: (from nobody@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA02113; Wed, 17 Sep 1997 11:53:48 -0700 (PDT) Message-Id: <199709171853.LAA02113@hub.freebsd.org> Date: Wed, 17 Sep 1997 11:53:48 -0700 (PDT) From: le.englund@trollhattan.mail.telia.com To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: bin/4562: Compiler traps and exits then recompiling kernel Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4562 >Category: bin >Synopsis: Compiler traps and exits then recompiling kernel >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 17 12:00:01 PDT 1997 >Last-Modified: >Originator: Lars-Erik Englund >Organization: >Release: 2.2.2 >Environment: ../../ufs/ffs/ffs_vfops.c: 640: parse error before '1LL1 Error code 1 >Description: Complier traps and exits then L2 cache is enabled, system BIOS is cached, c000 - c400 and c800 - cc00 are cached. >How-To-Repeat: The problem disapers then the parameters above are disabled, and reapers then enabled. My systemboard is an Acer Aopen AP53, BIOS level 2.A0. >Fix: Look at How to repeat the problem. There you have all you need. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed Sep 17 15:00:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA14000 for bugs-outgoing; Wed, 17 Sep 1997 15:00:03 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA13948; Wed, 17 Sep 1997 15:00:01 -0700 (PDT) Date: Wed, 17 Sep 1997 15:00:01 -0700 (PDT) Message-Id: <199709172200.PAA13948@hub.freebsd.org> To: freebsd-bugs Cc: From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: bin/4562: Compiler traps and exits then recompiling kernel Reply-To: j@uriah.heep.sax.de (J Wunsch) Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR bin/4562; it has been noted by GNATS. From: j@uriah.heep.sax.de (J Wunsch) To: le.englund@trollhattan.mail.telia.com Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: bin/4562: Compiler traps and exits then recompiling kernel Date: Wed, 17 Sep 1997 23:37:43 +0200 As le.englund@trollhattan.mail.telia.com wrote: > >Description: > Complier traps and exits then L2 cache is enabled, system BIOS is > cached, c000 - c400 and c800 - cc00 are cached. So how do you expect us to fix your broken hardware? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Wed Sep 17 15:20:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15257 for bugs-outgoing; Wed, 17 Sep 1997 15:20:10 -0700 (PDT) Received: from room101.sysc.com (jayrich@richmojm2.student.rose-hulman.edu [137.112.206.126]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA15252; Wed, 17 Sep 1997 15:20:05 -0700 (PDT) Received: from localhost (jayrich@localhost) by room101.sysc.com (8.8.5/8.8.5) with SMTP id RAA00537; Wed, 17 Sep 1997 17:19:21 -0500 (EST) Date: Wed, 17 Sep 1997 17:19:21 -0500 (EST) From: "Jay M. Richmond" To: freebsd-stable@freebsd.org cc: freebsd-bugs@freebsd.org Subject: ATAPI CD-ROM functionality still missing from 2.2-stable Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello-- A couple weeks ago I brought up the fact that ATAPI support in the 2.2-stable kernel was broken for me ... i received some other e-mail's from people that claimed that their cvsup'ed kernels lacked this functionality as well... i bring this back up again because i receieved no response from the freebsd team and i just tried a cvsup'ed 2.2-stable kernel as of today-- if there's something else i should be doing, please forgive my ignorance and let me know... (via e-mail, i don't subscribe to this list).. thanks. here's what happens: # mount -t cd9660 /dev/wcd0a /mnt/cdrom cd9660: /dev/wcd0a: Input/output error this happens with either /dev/wcd0a or /dev/wcd0c here's what /var/log/messages says: Sep 17 15:57:02 room101 /kernel: wdc1 at 0x170-0x177 irq 15 on isa Sep 17 15:57:02 room101 /kernel: wdc1: unit 1 (atapi): , removable, intr, dma, iordis Sep 17 15:57:02 room101 /kernel: wcd0: 1377Kb/sec, 256Kb cache, audio play, 255 volume levels, ejectable tray Sep 17 15:57:02 room101 /kernel: wcd0: no disc inside, unlocked thanks for your time & reply, jay __ Jay Richmond Owner, BDIC Consulting Group Box 1229 http://bdic.sysc.com Rose-Hulman Institute of Technology (317) 407-7701 5500 Wabash Avenue Rose-Hulman Terre Haute, IN 47803 (812) 877-8772 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzQe9IMAAAEEAKVCBVhfVHCyNOsNvCwXbamYDslPoBoUgllJxGWrjYr8+XOS mAIo6VNyR6E0Q57SICfxAlw8CfrW3jSFZxCalyAr7f4SU/ioF7qOx9AEeRePKbQD XQYT/eUirjo4h1TzQPWMrlGtnehTJfX4LKLeu8WRsMog/6LMzxBohdeuTAY9AAUR tCJKYXkgTS4gUmljaG1vbmQgPGpheXJpY2hAc3lzYy5jb20+ =PTZq -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-bugs Wed Sep 17 15:30:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15703 for bugs-outgoing; Wed, 17 Sep 1997 15:30:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA15695; Wed, 17 Sep 1997 15:30:01 -0700 (PDT) Resent-Date: Wed, 17 Sep 1997 15:30:01 -0700 (PDT) Resent-Message-Id: <199709172230.PAA15695@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, jayrich@room101.sysc.com Received: from room101.sysc.com (jayrich@richmojm2.student.rose-hulman.edu [137.112.206.126]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA15439 for ; Wed, 17 Sep 1997 15:24:17 -0700 (PDT) Received: (from jayrich@localhost) by room101.sysc.com (8.8.5/8.8.5) id RAA00670; Wed, 17 Sep 1997 17:23:33 -0500 (EST) Message-Id: <199709172223.RAA00670@room101.sysc.com> Date: Wed, 17 Sep 1997 17:23:33 -0500 (EST) From: "Jay M. Richmond" Reply-To: jayrich@room101.sysc.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: i386/4563: mount IDE atapi cd-rom reports input/output error Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4563 >Category: i386 >Synopsis: mount IDE atapi cd-rom reports input/output error >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 17 15:30:00 PDT 1997 >Last-Modified: >Originator: Jay M. Richmond >Organization: Rose-Hulman Institute of Technology >Release: FreeBSD 2.2-STABLE i386 >Environment: cd-rom is running off of secondary IDE controller, have tried it as a primary and secondary, same result >Description: # mount -t cd9660 /dev/wcd0a /mnt/cdrom cd9660: /dev/wcd0a: Input/output error this happens with either /dev/wcd0a or /dev/wcd0c here's what /var/log/messages says: Sep 17 15:57:02 room101 /kernel: wdc1 at 0x170-0x177 irq 15 on isa Sep 17 15:57:02 room101 /kernel: wdc1: unit 1 (atapi): , removable, intr, dma, iordis Sep 17 15:57:02 room101 /kernel: wcd0: 1377Kb/sec, 256Kb cache, audio play, 255 volume levels, ejectable tray Sep 17 15:57:02 room101 /kernel: wcd0: no disc inside, unlocked >How-To-Repeat: try to mount my mitsumi cd-rom and it won't do it (see above) >Fix: nothing known >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed Sep 17 18:19:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA24583 for bugs-outgoing; Wed, 17 Sep 1997 18:19:19 -0700 (PDT) Received: from room101.sysc.com (root@richmojm2.student.rose-hulman.edu [137.112.206.126]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA24572 for ; Wed, 17 Sep 1997 18:19:08 -0700 (PDT) Received: from localhost (root@localhost) by room101.sysc.com (8.8.7/8.8.5) with SMTP id UAA00666 for ; Wed, 17 Sep 1997 20:17:52 -0500 (EST) Date: Wed, 17 Sep 1997 20:17:52 -0500 (EST) From: Charlie ROOT To: freebsd-bugs@freebsd.org Subject: ..conitnued.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk continued from previous post... i also tried to recompile stable's cd9660.... got several errors about ssector 'structure has no member named `ssector'' could this be related? thanks,jay From owner-freebsd-bugs Wed Sep 17 18:50:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA26139 for bugs-outgoing; Wed, 17 Sep 1997 18:50:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA26132; Wed, 17 Sep 1997 18:50:01 -0700 (PDT) Resent-Date: Wed, 17 Sep 1997 18:50:01 -0700 (PDT) Resent-Message-Id: <199709180150.SAA26132@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, jayrich@room101.sysc.com Received: from room101.sysc.com (jayrich@richmojm2.student.rose-hulman.edu [137.112.206.126]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA26078 for ; Wed, 17 Sep 1997 18:49:20 -0700 (PDT) Received: (from jayrich@localhost) by room101.sysc.com (8.8.7/8.8.5) id UAA00911; Wed, 17 Sep 1997 20:48:38 -0500 (EST) Message-Id: <199709180148.UAA00911@room101.sysc.com> Date: Wed, 17 Sep 1997 20:48:38 -0500 (EST) From: "Jay M. Richmond" Reply-To: jayrich@room101.sysc.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/4564: 2.2-STABLE's mount_cd9660.c will not compile Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4564 >Category: bin >Synopsis: 2.2-STABLE's mount_cd9660.c will not compile >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 17 18:50:00 PDT 1997 >Last-Modified: >Originator: Jay M. Richmond >Organization: Rose-Hulman Insititute of Technology >Release: FreeBSD 2.2-STABLE i386 >Environment: >Description: I think this may be related to the problem i reported as i386/4563, where i get an input/output error mounting my atapi cd-rom under 2.2-stable, under 2.2.2-release it works fine when you try to compile, it gives several errors about 'structive has no member named 'ssector'' >How-To-Repeat: make mount_cd9660 in /usr/src/sbin or make in /usr/src/sbin/mount_cd9660 >Fix: not known >Audit-Trail: >Unformatted: From owner-freebsd-bugs Wed Sep 17 23:50:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA12181 for bugs-outgoing; Wed, 17 Sep 1997 23:50:38 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA12080; Wed, 17 Sep 1997 23:49:00 -0700 (PDT) Received: (from sef@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id XAA02443; Wed, 17 Sep 1997 23:45:09 -0700 (PDT) Date: Wed, 17 Sep 1997 23:45:09 -0700 (PDT) Message-Id: <199709180645.XAA02443@freefall.freebsd.org> From: Sean Eric Fagan To: FreeBSD bugs mailing list , roberte@MEP.Ruhr-Uni-Bochum.de Subject: Re: bin/4558: ls -d does not sort directories as plain files Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk `Sean Eric Fagan' changed the state to `closed'. State-Changed-From-To: open-closed State-Changed-By: sef State-Changed-When: Wed Sep 17 23:43:23 1997 State-Changed-Why: I just checked in a diff for this. (Okay, this isn't the exact diff I checked in, this is the patch I got from Keith. But it applied cleanly :).) Index: ls.c =================================================================== RCS file: /master/bin/ls/ls.c,v retrieving revision 2.3 retrieving revision 2.4 diff -c -r2.3 -r2.4 *** ls.c 1996/01/09 21:14:03 2.3 --- ls.c 1996/01/21 03:59:47 2.4 *************** *** 519,534 **** if (a_info == FTS_NS || b_info == FTS_NS) return (namecmp(*a, *b)); ! if (a_info == b_info) ! return (sortfcn(*a, *b)); ! ! if ((*a)->fts_level == FTS_ROOTLEVEL) if (a_info == FTS_D) return (1); ! else if (b_info == FTS_D) return (-1); ! else ! return (sortfcn(*a, *b)); ! else ! return (sortfcn(*a, *b)); } --- 519,530 ---- if (a_info == FTS_NS || b_info == FTS_NS) return (namecmp(*a, *b)); ! if (a_info != b_info && ! (*a)->fts_level == FTS_ROOTLEVEL && !f_listdir) { if (a_info == FTS_D) return (1); ! if (b_info == FTS_D) return (-1); ! } ! return (sortfcn(*a, *b)); } From owner-freebsd-bugs Thu Sep 18 00:21:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA14575 for bugs-outgoing; Thu, 18 Sep 1997 00:21:43 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA14413; Thu, 18 Sep 1997 00:20:15 -0700 (PDT) From: Joerg Wunsch Received: (from joerg@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id AAA03058; Thu, 18 Sep 1997 00:16:24 -0700 (PDT) Date: Thu, 18 Sep 1997 00:16:24 -0700 (PDT) Message-Id: <199709180716.AAA03058@freefall.freebsd.org> To: jayrich@room101.sysc.com, joerg@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/4564 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: 2.2-STABLE's mount_cd9660.c will not compile State-Changed-From-To: open-closed State-Changed-By: joerg State-Changed-When: Thu Sep 18 09:15:58 MEST 1997 State-Changed-Why: User error. Incomplete upgrade to RELENG_2_2 sources. From owner-freebsd-bugs Thu Sep 18 00:30:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA15226 for bugs-outgoing; Thu, 18 Sep 1997 00:30:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA15218; Thu, 18 Sep 1997 00:30:02 -0700 (PDT) Date: Thu, 18 Sep 1997 00:30:02 -0700 (PDT) Message-Id: <199709180730.AAA15218@hub.freebsd.org> To: freebsd-bugs Cc: From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: bin/4564: 2.2-STABLE's mount_cd9660.c will not compile Reply-To: j@uriah.heep.sax.de (J Wunsch) Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR bin/4564; it has been noted by GNATS. From: j@uriah.heep.sax.de (J Wunsch) To: jayrich@room101.sysc.com Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/4564: 2.2-STABLE's mount_cd9660.c will not compile Date: Thu, 18 Sep 1997 09:17:56 +0200 As Jay M. Richmond wrote: > when you try to compile, it gives several errors about > 'structive has no member named 'ssector'' Please, do learn how to upgrade your *complete* system first. Of course, mount_cd9660 compiles fine, but if you try it by pulling single files and don't understand the details, you're likely to fall flat on your face. (The above is caused by merging the multisession support into -stable. This happened on Aug 17, do you really think nobody has built a complete RELENG_2_2 system since?) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Thu Sep 18 03:20:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA24537 for bugs-outgoing; Thu, 18 Sep 1997 03:20:09 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA24495; Thu, 18 Sep 1997 03:20:01 -0700 (PDT) Date: Thu, 18 Sep 1997 03:20:01 -0700 (PDT) Message-Id: <199709181020.DAA24495@hub.freebsd.org> To: freebsd-bugs Cc: From: Andre Subject: Re: bin/4524: procmail can swap machine to death with malloc.c from -stable Reply-To: Andre Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR bin/4524; it has been noted by GNATS. From: Andre To: freebsd-gnats-submit@freebsd.org, j@uriah.heep.sax.de Cc: Subject: Re: bin/4524: procmail can swap machine to death with malloc.c from -stable Date: Thu, 18 Sep 1997 12:15:29 +0200 This appears to be the same as in kern/3690. Using the newer malloc.c doesn't work here, but the machine doesn't hang anymore. From owner-freebsd-bugs Thu Sep 18 04:12:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA28862 for bugs-outgoing; Thu, 18 Sep 1997 04:12:24 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA28857 for ; Thu, 18 Sep 1997 04:12:19 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id NAA02643; Thu, 18 Sep 1997 13:11:03 +0200 (CEST) To: Andre cc: freebsd-bugs@freebsd.org Subject: Re: bin/4524: procmail can swap machine to death with malloc.c from -stable In-reply-to: Your message of "Thu, 18 Sep 1997 03:20:01 PDT." <199709181020.DAA24495@hub.freebsd.org> Date: Thu, 18 Sep 1997 13:11:02 +0200 Message-ID: <2641.874581062@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Please try with malloc flag 'H' set. This was changed to be on by default a couple of weeks ago. "man 3 malloc" might be sound reading for you, there are several knobs you can twist. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-bugs Thu Sep 18 04:13:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA28937 for bugs-outgoing; Thu, 18 Sep 1997 04:13:42 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA28922; Thu, 18 Sep 1997 04:13:18 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id EAA04275; Thu, 18 Sep 1997 04:09:26 -0700 (PDT) Date: Thu, 18 Sep 1997 04:09:26 -0700 (PDT) Message-Id: <199709181109.EAA04275@freefall.freebsd.org> To: blaz@amis.net, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/4524 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: procmail can swap machine to death with malloc.c from -stable State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 04:08:24 PDT 1997 State-Changed-Why: There are no signs of bugs in this case. procmail could probably use a smarter algorithm for reading in files. From owner-freebsd-bugs Thu Sep 18 04:15:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA29014 for bugs-outgoing; Thu, 18 Sep 1997 04:15:05 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA28943; Thu, 18 Sep 1997 04:13:44 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id EAA04355; Thu, 18 Sep 1997 04:09:52 -0700 (PDT) Date: Thu, 18 Sep 1997 04:09:52 -0700 (PDT) Message-Id: <199709181109.EAA04355@freefall.freebsd.org> To: Andre.Albsmeier@mchp.siemens.de, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/3690 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: vm problems on 2.2, 2.1.7 works State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 04:09:31 PDT 1997 State-Changed-Why: duplicate see 4524 From owner-freebsd-bugs Thu Sep 18 04:19:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA29169 for bugs-outgoing; Thu, 18 Sep 1997 04:19:08 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA29162 for ; Thu, 18 Sep 1997 04:19:03 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id NAA02661 for ; Thu, 18 Sep 1997 13:18:36 +0200 (CEST) To: freebsd-bugs@freebsd.org Subject: misc/2309 In-reply-to: Your message of "Thu, 18 Sep 1997 03:20:01 PDT." <199709181020.DAA24495@hub.freebsd.org> Date: Thu, 18 Sep 1997 13:18:36 +0200 Message-ID: <2659.874581516@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The patches to malloc.c are no longer applicable. This was solved in a previous rewrite of the locking stuff. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-bugs Thu Sep 18 04:20:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA29291 for bugs-outgoing; Thu, 18 Sep 1997 04:20:22 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA29283; Thu, 18 Sep 1997 04:20:15 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id EAA05238; Thu, 18 Sep 1997 04:16:22 -0700 (PDT) Date: Thu, 18 Sep 1997 04:16:22 -0700 (PDT) Message-Id: <199709181116.EAA05238@freefall.freebsd.org> To: gilham@csl.sri.com, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/2093 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: AMD gets sig 11 when /etc/malloc.conf is linked to AJ State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 04:15:56 PDT 1997 State-Changed-Why: Havn't heard anything on this one for a long time. From owner-freebsd-bugs Thu Sep 18 04:23:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA29428 for bugs-outgoing; Thu, 18 Sep 1997 04:23:56 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA29377; Thu, 18 Sep 1997 04:22:38 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id EAA05325; Thu, 18 Sep 1997 04:18:46 -0700 (PDT) Date: Thu, 18 Sep 1997 04:18:46 -0700 (PDT) Message-Id: <199709181118.EAA05325@freefall.freebsd.org> To: Tor.Egge@idi.ntnu.no, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/3688 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: fsck -p gets transient unexpected inconsistensies State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 04:18:21 PDT 1997 State-Changed-Why: The suggested patch was committed some time ago. From owner-freebsd-bugs Thu Sep 18 06:00:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA04093 for bugs-outgoing; Thu, 18 Sep 1997 06:00:10 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA04050; Thu, 18 Sep 1997 06:00:02 -0700 (PDT) Resent-Date: Thu, 18 Sep 1997 06:00:02 -0700 (PDT) Resent-Message-Id: <199709181300.GAA04050@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, haible@ilog.fr Received: from seagull.cdrom.com (haible@seagull.cdrom.com [204.216.27.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA03925 for ; Thu, 18 Sep 1997 05:58:27 -0700 (PDT) Received: (from haible@localhost) by seagull.cdrom.com (8.8.6/8.6.6) id FAA13606 ; Thu, 18 Sep 1997 05:58:28 -0700 (PDT) Message-Id: <199709181258.FAA13606@seagull.cdrom.com> Date: Thu, 18 Sep 1997 05:58:28 -0700 (PDT) From: haible@seagull.cdrom.com Reply-To: haible@ilog.fr To: FreeBSD-gnats-submit@FreeBSD.ORG Cc: haible@ilog.fr X-Send-Pr-Version: 3.2 Subject: bin/4568: /bin/sh substitution/concatenation bug Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4568 >Category: bin >Synopsis: simple /bin/sh script produces wrong results >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Sep 18 06:00:00 PDT 1997 >Last-Modified: >Originator: Bruno Haible >Organization: ILOG >Release: FreeBSD 2.2-STABLE i386 >Environment: >Description: The following /bin/sh commands unset LINGUAS ALL_LINGUAS="en de fr es" NEW_LINGUAS= for lang in ${LINGUAS=$ALL_LINGUAS}; do case "$ALL_LINGUAS" in *$lang*) NEW_LINGUAS="$NEW_LINGUAS $lang" ;; esac done echo $NEW_LINGUAS print en de fr de fr es instead of en de fr es >How-To-Repeat: Start a sh, then input the above commands. >Fix: unknown >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Sep 18 07:14:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA08215 for bugs-outgoing; Thu, 18 Sep 1997 07:14:38 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA08201; Thu, 18 Sep 1997 07:14:10 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id HAA06534; Thu, 18 Sep 1997 07:10:16 -0700 (PDT) Date: Thu, 18 Sep 1997 07:10:16 -0700 (PDT) Message-Id: <199709181410.HAA06534@freefall.freebsd.org> To: arnej@imf.unit.no, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/2752 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: NULL is used instead of 0 many places State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 07:09:53 PDT 1997 State-Changed-Why: committed, thanks! From owner-freebsd-bugs Thu Sep 18 07:43:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA09944 for bugs-outgoing; Thu, 18 Sep 1997 07:43:12 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA09924; Thu, 18 Sep 1997 07:43:04 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id HAA21307; Thu, 18 Sep 1997 07:39:11 -0700 (PDT) Date: Thu, 18 Sep 1997 07:39:11 -0700 (PDT) Message-Id: <199709181439.HAA21307@freefall.freebsd.org> To: register@sainet.or.jp, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/2837 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: Globalyst550 Disk-Drive Not found!! State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 07:38:59 PDT 1997 State-Changed-Why: deadline. From owner-freebsd-bugs Thu Sep 18 07:50:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA10458 for bugs-outgoing; Thu, 18 Sep 1997 07:50:06 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA10420; Thu, 18 Sep 1997 07:50:00 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id HAA21397; Thu, 18 Sep 1997 07:46:07 -0700 (PDT) Date: Thu, 18 Sep 1997 07:46:07 -0700 (PDT) Message-Id: <199709181446.HAA21397@freefall.freebsd.org> To: ohashi@mickey.ai.kyutech.ac.jp, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: i386/1959 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: DELAY() won't work for fast CPUs State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 07:45:39 PDT 1997 State-Changed-Why: worked around in other ways. From owner-freebsd-bugs Thu Sep 18 07:51:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA10535 for bugs-outgoing; Thu, 18 Sep 1997 07:51:48 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA10525; Thu, 18 Sep 1997 07:51:40 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id HAA21480; Thu, 18 Sep 1997 07:47:47 -0700 (PDT) Date: Thu, 18 Sep 1997 07:47:47 -0700 (PDT) Message-Id: <199709181447.HAA21480@freefall.freebsd.org> To: peter@newton.dialix.com.au, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/1744 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: run queue or proc list smashed 4 times in 2 days State-Changed-From-To: analyzed-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 07:47:20 PDT 1997 State-Changed-Why: I'm sure you've liked this one, right ? From owner-freebsd-bugs Thu Sep 18 07:52:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA10683 for bugs-outgoing; Thu, 18 Sep 1997 07:52:49 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA10675; Thu, 18 Sep 1997 07:52:41 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id HAA21563; Thu, 18 Sep 1997 07:48:48 -0700 (PDT) Date: Thu, 18 Sep 1997 07:48:48 -0700 (PDT) Message-Id: <199709181448.HAA21563@freefall.freebsd.org> To: jjal@geocities.com, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/2498 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: On installation, after selecting drivers, keyboard locks and screen turns to garbage State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 07:48:31 PDT 1997 State-Changed-Why: deadline expired. From owner-freebsd-bugs Thu Sep 18 07:55:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA10776 for bugs-outgoing; Thu, 18 Sep 1997 07:55:34 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA10759; Thu, 18 Sep 1997 07:55:21 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id HAA21647; Thu, 18 Sep 1997 07:51:28 -0700 (PDT) Date: Thu, 18 Sep 1997 07:51:28 -0700 (PDT) Message-Id: <199709181451.HAA21647@freefall.freebsd.org> To: dmm125@bellatlantic.net, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/3005 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: can't completely install 2.1.7 release; sysinstall catches sig 11, hangs when booting from the boot floppy State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 07:50:47 PDT 1997 State-Changed-Why: well, not much data for debugging, and sysinstall has been beat up a fair bit since. From owner-freebsd-bugs Thu Sep 18 07:59:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA11095 for bugs-outgoing; Thu, 18 Sep 1997 07:59:53 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA11072; Thu, 18 Sep 1997 07:59:32 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id RAA14234; Thu, 18 Sep 1997 17:04:33 +0200 (SAT) Received: by citadel via recvmail id 14201; Thu Sep 18 17:04:26 1997 by gram.cdsec.com (8.8.5/8.8.5) id QAA00397; Thu, 18 Sep 1997 16:51:34 +0200 (SAT) From: Graham Wheeler Message-Id: <199709181451.QAA00397@cdsec.com> Subject: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 18 Sep 1997 16:51:33 +0200 (SAT) Cc: hackers@freebsd.org, freebsd-bugs@freebsd.org, gram@gram.cdsec.com (Graham Wheeler) In-Reply-To: <2593.874490931@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 17, 97 12:08:51 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Poul and others This is a preliminary report, as it is still very early and the results we are seeing may be coincidental. Even after removing all non-reentrant calls from the SIGCHLD handler in our gateway program, adding asserts after every call to new, manually rechecking every call to memcpy, memset, strcpy, strcat, etc etc etc, we continued to experience the problems, namely the process either aborting in the malloc/free routines, or going into what appeared to be an infinite loop, where the program chewed CPU cycles but did nothing useful. In the latter case, sending a SIGABRT resulted in stack backtraces which also always ended in malloc() or free(). The recursive malloc call problem was solved by removing the non-reentrant calls, but it appears that heap corruption still takes place. This morning, as an act of near desperation, I linked the code with the libmalloc that is in the ports/devel directory. In fact I linked with the debug version libmalloc_d, which has far more comprehensive integrity checking. Since running the resulting version, there have been no crashes or freezes. As I say, it is still quite early to jump to conclusions, but the program has been running under heavy load for about three hours so far, whereas yesterday it would crash or freeze up within 30 minutes of starting. [For those who haven't been following this thread, this application is the core program in our firewall product, responsible for gatewaying almost all IP packets. The site in question has several thousand users who seem to do little other than surf the web. Thus the amount of memory allocation and freeing that takes place in this application is quite astronomical compared to typical applications. Amongst other allocations, every single packet is held in a dynamically allocated buffer, as is the state information associated with every TCP connection.] I'll follow up on this in the morning (South African time) - if the process is still running smoothly this would suggests that there may be a problem with the malloc/free code in libc. regards graham -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-bugs Thu Sep 18 08:46:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA13837 for bugs-outgoing; Thu, 18 Sep 1997 08:46:45 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA13832; Thu, 18 Sep 1997 08:46:39 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id RAA07200; Thu, 18 Sep 1997 17:45:57 +0200 (CEST) To: Graham Wheeler cc: hackers@freebsd.org, freebsd-bugs@freebsd.org, gram@gram.cdsec.com.dk.tfs.com (Graham Wheeler) Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Sat, 18 Sep 1997 16:51:33 +0200." <199709181451.QAA00397@cdsec.com> Date: Thu, 18 Sep 1997 17:45:57 +0200 Message-ID: <7198.874597557@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709181451.QAA00397@cdsec.com>, Graham Wheeler writes: >Hi Poul and others > >This is a preliminary report, as it is still very early and the results >we are seeing may be coincidental. >I'll follow up on this in the morning (South African time) - if the >process is still running smoothly this would suggests that there >may be a problem with the malloc/free code in libc. Well, you'll still have to do more to convince me. The fact that two malloc implementations act differently is no proof of one of them being wrong, the different policies they use can make a bit difference in the outcome for errors in the main code. Imagine this: char *p = malloc(12); char *q = malloc(12); p[12] = 'B'; In the case of phkmalloc you have written into padding space, in the case of many other mallocs you have just destroyed the "back" pointer for the *q allocation. The results are very different. Another very common mistake is to trust the storage returned to contain zero bytes. Try the following 3 experiments: 1 set the 'A' flag to phkmalloc. 2 set the 'J' flag to phkmalloc. 3 set the 'Z' flag to phkmalloc. If they are any different in behaviour, they your code has a problem. Remember to keep fd#2 open to a logfile. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-bugs Thu Sep 18 09:15:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA15942 for bugs-outgoing; Thu, 18 Sep 1997 09:15:39 -0700 (PDT) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA15901; Thu, 18 Sep 1997 09:15:27 -0700 (PDT) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.5/8.6.9) id SAA16644; Thu, 18 Sep 1997 18:20:34 +0200 (SAT) Received: by citadel via recvmail id 16611; Thu Sep 18 18:19:43 1997 by gram.cdsec.com (8.8.5/8.8.5) id SAA00506; Thu, 18 Sep 1997 18:06:52 +0200 (SAT) From: Graham Wheeler Message-Id: <199709181606.SAA00506@cdsec.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 18 Sep 1997 18:06:51 +0200 (SAT) Cc: hackers@freebsd.org, freebsd-bugs@freebsd.org In-Reply-To: <7198.874597557@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 18, 97 05:45:57 pm X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >This is a preliminary report, as it is still very early and the results > >we are seeing may be coincidental. > > >I'll follow up on this in the morning (South African time) - if the > >process is still running smoothly this would suggests that there > >may be a problem with the malloc/free code in libc. > > Well, you'll still have to do more to convince me. I'll do my best... ;-) > The fact that two malloc implementations act differently is no proof > of one of them being wrong, the different policies they use can make > a bit difference in the outcome for errors in the main code. Agreed. > > Imagine this: > > char *p = malloc(12); > char *q = malloc(12); > p[12] = 'B'; > > In the case of phkmalloc you have written into padding space, > in the case of many other mallocs you have just destroyed the > "back" pointer for the *q allocation. The results are very > different. The debug libmalloc that I am now using uses the following layout for an allocated block: | prevlink | nextlink | size | memspace | size | i.e. the size is stored both immediately preceding and immediately following the useable space. As part of the consistency checking, these two sizes are compared and should match. This should catch almost all small overruns or underruns, and abort the process. So this malloc should be less tolerant of bugs in my code than pkhmalloc is, rather than more tolerant, > Another very common mistake is to trust the storage returned to > contain zero bytes. I certainly don't assume this. I am very careful to either memset the allocated memory to zero if necessary, or, in the case of C++ objects, to explicitly initialise every member variable in the constructor. These are lessons learnt long ago after much pain and suffering... > Try the following 3 experiments: > > 1 set the 'A' flag to phkmalloc. > > 2 set the 'J' flag to phkmalloc. > > 3 set the 'Z' flag to phkmalloc. > > If they are any different in behaviour, they your code has a > problem. I tried all of these already a couple of days back. They made no difference. > Remember to keep fd#2 open to a logfile. Doing so. Can you offer an explanation as to why the process never returns from the call to malloc, nor does it abort? This seems to indicate an infinite loop. Not having delved too deeply into your code, I can only speculate that the linked list is being made circular, so the process is in an infinite, looping traversal. Perhaps that is a check that can be added; namely that walking the list must always proceed forward, never backward (assuming that the list is kept in sequential order). -- Dr Graham Wheeler E-mail: gram@cdsec.com Citadel Data Security Phone: +27(21)23-6065/6/7 Internet/Intranet Network Specialists Mobile: +27(83)-253-9864 Firewalls/Virtual Private Networks Fax: +27(21)24-3656 Data Security Products WWW: http://www.cdsec.com/ From owner-freebsd-bugs Thu Sep 18 09:24:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA16517 for bugs-outgoing; Thu, 18 Sep 1997 09:24:48 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA16498; Thu, 18 Sep 1997 09:24:40 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id SAA10533; Thu, 18 Sep 1997 18:24:04 +0200 (CEST) To: Graham Wheeler cc: hackers@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Sat, 18 Sep 1997 18:06:51 +0200." <199709181606.SAA00506@cdsec.com> Date: Thu, 18 Sep 1997 18:24:04 +0200 Message-ID: <10531.874599844@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199709181606.SAA00506@cdsec.com>, Graham Wheeler writes: >i.e. the size is stored both immediately preceding and immediately >following the useable space. As part of the consistency checking, >these two sizes are compared and should match. This should catch almost >all small overruns or underruns, and abort the process. So this >malloc should be less tolerant of bugs in my code than pkhmalloc is, >rather than more tolerant, again: depends. >Can you offer an explanation as to why the process never returns from >the call to malloc, nor does it abort? This seems to indicate an infinite >loop. Not having delved too deeply into your code, I can only speculate >that the linked list is being made circular, so the process is in an >infinite, looping traversal. Perhaps that is a check that can be added; >namely that walking the list must always proceed forward, never backward >(assuming that the list is kept in sequential order). This is about the only way you could get it to loop I think. That means that somebody wrote to memory malloc hadn't passed them (ie: your code). This would indicate a bug of the class where memory is written to after being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-bugs Thu Sep 18 11:05:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA24118 for bugs-outgoing; Thu, 18 Sep 1997 11:05:41 -0700 (PDT) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA24108 for ; Thu, 18 Sep 1997 11:05:34 -0700 (PDT) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.203]) by innocence.interface-business.de (8.6.11/8.6.9) with SMTP id UAA08989 for ; Thu, 18 Sep 1997 20:05:23 +0200 Received: (from j@localhost) by ida.interface-business.de (8.8.7/8.7.3) id UAA00559; Thu, 18 Sep 1997 20:05:22 +0200 (MET DST) Message-ID: <19970918200521.RX41144@ida.interface-business.de> Date: Thu, 18 Sep 1997 20:05:21 +0200 From: j@ida.interface-business.de (J Wunsch) To: freebsd-bugs@freebsd.org Subject: Re: My 2.2-stable panic reproduced References: <19970908193559.WU22983@ida.interface-business.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface business GmbH, Dresden Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) In-Reply-To: <19970908193559.WU22983@ida.interface-business.de>; from J Wunsch on Sep 8, 1997 19:36:00 +0200 Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I once wrote: > panic: vref used where vget required > > syncing disks... 50 50 42 32 21 9 done It hit again. This time, i've got a coredump. panic: vref used where vget required panic: from debugger dumping to dev 401, offset 241664 dump 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 #9 0xf0117e0a in panic () #10 0xf0134b62 in vref () #11 0xf0107740 in iso_iget (xp=0xefbffd60, ino=49152, relocated=1, ipp=0xefbffcec, isodir=0xf0aa354c) at ../../isofs/cd9660/cd9660_node.c:247 #12 0xf010979d in cd9660_root (mp=0xf0a98200, vpp=0xefbffe14) at ../../isofs/cd9660/cd9660_vfsops.c:558 #13 0xf0133888 in lookup () #14 0xf013329b in namei () #15 0xf0137450 in lstat () #16 0xf01c9cb7 in syscall () (kgdb) up 11 #11 0xf0107740 in iso_iget (xp=0xefbffd60, ino=49152, relocated=1, ipp=0xefbffcec, isodir=0xf0aa354c) at ../../isofs/cd9660/cd9660_node.c:247 247 VREF(ip->i_devvp); (kgdb) l 242 ISO_ILOCK(ip); 243 244 imp = VFSTOISOFS (mntp); 245 ip->i_mnt = imp; 246 ip->i_devvp = imp->im_devvp; 247 VREF(ip->i_devvp); 248 249 if (relocated) { 250 /* 251 * On relocated directories we must (kgdb) p ipp $4 = (struct iso_node **) 0xefbffcec (kgdb) p **ipp $5 = {i_chain = {0x0, 0x0}, i_vnode = 0x87654321, i_devvp = 0x0, i_flag = 4069182888, i_dev = 4028788080, i_number = 0, i_mnt = 0xf08a8f94, i_lockf = 0xf0a6d400, i_endoff = 1049104, i_diroff = 0, i_offset = 0, i_ino = 28672, i_spare0 = 28672, i_spare1 = 0, iso_extent = 1024, i_size = -211922944, iso_start = -211922944, inode = {iso_atime = { tv_sec = 65536, tv_nsec = 0}, iso_mtime = {tv_sec = 14888, tv_nsec = 14888}, iso_ctime = {tv_sec = -267137396, tv_nsec = 0}, iso_mode = 0, iso_uid = 0, iso_gid = 0, iso_links = 0, iso_rdev = 0}, i_lockcount = 0} (kgdb) up #12 0xf010979d in cd9660_root (mp=0xf0a98200, vpp=0xefbffe14) at ../../isofs/cd9660/cd9660_vfsops.c:558 558 error = iso_iget(ip,ip->i_number, (kgdb) l 553 554 /* 555 * With RRIP we must use the `.' entry of the root directory. 556 * Simply tell iget, that it's a relocated directory. 557 */ 558 error = iso_iget(ip,ip->i_number, 559 imp->iso_ftype == ISO_FTYPE_RRIP, 560 &nip,dp); 561 if (error) 562 return error; So what? Replace the VREF by a VGET? The i_vnode value of 0x87654321 sounds terribly interesting. See this bug report: Subject: Yet another 2.2-stable NFS (client) panic X-Mailer: Mutt 0.60_p2-3,5,8-9 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface business GmbH, Dresden Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) Fatal trap 12: page fault while in kernel mode fault virtual address = 0x87654371 fault code = supervisor read, page not present instruction pointer = 0x8:0xf013476f stack pointer = 0x10:0xefbffdb0 Exactly the same bogus value. So who the heck is dumping 0x87654321's all over my memory??? -- J"org Wunsch Unix support engineer joerg_wunsch@interface-business.de http://www.interface-business.de/~j From owner-freebsd-bugs Thu Sep 18 11:16:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA24719 for bugs-outgoing; Thu, 18 Sep 1997 11:16:57 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA24632; Thu, 18 Sep 1997 11:15:13 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA22417; Thu, 18 Sep 1997 11:11:18 -0700 (PDT) Date: Thu, 18 Sep 1997 11:11:18 -0700 (PDT) Message-Id: <199709181811.LAA22417@freefall.freebsd.org> To: wosch@apfel.de, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/3398 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: off by one error in ffs_alloc State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 11:07:53 PDT 1997 State-Changed-Why: applied the patch, thankyou! From owner-freebsd-bugs Thu Sep 18 11:19:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA24840 for bugs-outgoing; Thu, 18 Sep 1997 11:19:00 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA24829; Thu, 18 Sep 1997 11:18:52 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA22523; Thu, 18 Sep 1997 11:14:58 -0700 (PDT) Date: Thu, 18 Sep 1997 11:14:58 -0700 (PDT) Message-Id: <199709181814.LAA22523@freefall.freebsd.org> To: phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, gibbs@FreeBSD.ORG Subject: Re: kern/4032 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: During recovery from scsi errors, incorrect contents might be written to the disk. Responsible-Changed-From-To: freebsd-bugs->gibbs Responsible-Changed-By: phk Responsible-Changed-When: Thu Sep 18 11:14:22 PDT 1997 Responsible-Changed-Why: Hi Justin, if this is fixed already, then just close it. From owner-freebsd-bugs Thu Sep 18 11:24:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA25243 for bugs-outgoing; Thu, 18 Sep 1997 11:24:25 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA25229; Thu, 18 Sep 1997 11:24:10 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA22665; Thu, 18 Sep 1997 11:20:16 -0700 (PDT) Date: Thu, 18 Sep 1997 11:20:16 -0700 (PDT) Message-Id: <199709181820.LAA22665@freefall.freebsd.org> To: thorpej@nas.nasa.gov, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/1649 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: md5(1) header file makes bad assumption State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 11:19:54 PDT 1997 State-Changed-Why: ... and now it's committed too :-) From owner-freebsd-bugs Thu Sep 18 11:26:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA25317 for bugs-outgoing; Thu, 18 Sep 1997 11:26:09 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA25306; Thu, 18 Sep 1997 11:26:00 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA22746; Thu, 18 Sep 1997 11:22:06 -0700 (PDT) Date: Thu, 18 Sep 1997 11:22:06 -0700 (PDT) Message-Id: <199709181822.LAA22746@freefall.freebsd.org> To: carol@tinker.com, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/2807 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: pcisupport.c uses sprintf field widths, not supported in kernel State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 11:21:50 PDT 1997 State-Changed-Why: fixed in -current From owner-freebsd-bugs Thu Sep 18 11:27:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA25424 for bugs-outgoing; Thu, 18 Sep 1997 11:27:13 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA25415; Thu, 18 Sep 1997 11:27:10 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id LAA11021; Thu, 18 Sep 1997 11:25:50 -0700 (PDT) To: Poul-Henning Kamp cc: Graham Wheeler , hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Thu, 18 Sep 1997 18:24:04 +0200." <10531.874599844@critter.freebsd.dk> Date: Thu, 18 Sep 1997 11:25:49 -0700 Message-ID: <11017.874607149@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > This would indicate a bug of the class where memory is written to after > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. Man, I sure wish there was a copy of purify available for FreeBSD. It's great at catching stuff like this! :( Maybe you could hack free() to do an mprotect(addr, len, PROT_NONE) on free'd pages, unprotecting them again as necessary when the malloc routines themselves need to frob that memory. Or, since we're just testing, do it from an internally registered SIGBUS handler which figures out the right thing to do. :-) BTW, how *do* you get the faulting memory location from a SIGBUS handler? I was just playing around with this a bit and noted that it wasn't immediately obvious how you'd get that info from the signal handler. Jordan P.S. I also noticed that processes which catch SIGBUS will dump incomplete core files - only the first 8K is dumped. Sounds like a bug to me and I think we should either dump the whole thing or not dump core at all rather than producing a truncated and rather useless core file! :-) From owner-freebsd-bugs Thu Sep 18 11:33:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA26141 for bugs-outgoing; Thu, 18 Sep 1997 11:33:29 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA25980; Thu, 18 Sep 1997 11:31:58 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA22906; Thu, 18 Sep 1997 11:28:04 -0700 (PDT) Date: Thu, 18 Sep 1997 11:28:04 -0700 (PDT) Message-Id: <199709181828.LAA22906@freefall.freebsd.org> To: dada@sbox.tu-graz.ac.at, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/3288 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: addition of a -f (force) option to "write_mfs_in_kernel.c" State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 11:27:46 PDT 1997 State-Changed-Why: added, thanks! From owner-freebsd-bugs Thu Sep 18 11:33:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA26168 for bugs-outgoing; Thu, 18 Sep 1997 11:33:38 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA26128; Thu, 18 Sep 1997 11:33:22 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA22986; Thu, 18 Sep 1997 11:29:28 -0700 (PDT) Date: Thu, 18 Sep 1997 11:29:28 -0700 (PDT) Message-Id: <199709181829.LAA22986@freefall.freebsd.org> To: proff@iq.org, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/2628 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: code clean up of sys/sys State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 11:29:05 PDT 1997 State-Changed-Why: This is extreemely unlikely to ever happen. From owner-freebsd-bugs Thu Sep 18 11:37:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA26541 for bugs-outgoing; Thu, 18 Sep 1997 11:37:48 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA26521; Thu, 18 Sep 1997 11:37:40 -0700 (PDT) From: Poul-Henning Kamp Received: (from phk@localhost) by freefall.freebsd.org (8.8.6/8.8.5) id LAA23125; Thu, 18 Sep 1997 11:33:46 -0700 (PDT) Date: Thu, 18 Sep 1997 11:33:46 -0700 (PDT) Message-Id: <199709181833.LAA23125@freefall.freebsd.org> To: hannibal@cyberstation.net, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/3104 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Synopsis: Cannot execute files on a nullfs filesystem. State-Changed-From-To: open-closed State-Changed-By: phk State-Changed-When: Thu Sep 18 11:33:28 PDT 1997 State-Changed-Why: applied in nullfs and umapfs. From owner-freebsd-bugs Thu Sep 18 12:03:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA28397 for bugs-outgoing; Thu, 18 Sep 1997 12:03:29 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA28386 for ; Thu, 18 Sep 1997 12:03:24 -0700 (PDT) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id VAA10970; Thu, 18 Sep 1997 21:02:19 +0200 (CEST) To: joerg_wunsch@interface-business.de (Joerg Wunsch) cc: freebsd-bugs@freebsd.org Subject: Re: My 2.2-stable panic reproduced In-reply-to: Your message of "Thu, 18 Sep 1997 20:05:21 +0200." <19970918200521.RX41144@ida.interface-business.de> Date: Thu, 18 Sep 1997 21:02:19 +0200 Message-ID: <10968.874609339@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >$5 = {i_chain = {0x0, 0x0}, i_vnode = 0x87654321, i_devvp = 0x0, > >So what? Replace the VREF by a VGET? The i_vnode value of 0x87654321 >sounds terribly interesting. See this bug report: > >Fatal trap 12: page fault while in kernel mode >fault virtual address = 0x87654371 >fault code = supervisor read, page not present >instruction pointer = 0x8:0xf013476f >stack pointer = 0x10:0xefbffdb0 > >Exactly the same bogus value. So who the heck is dumping 0x87654321's >all over my memory??? Yes, something is weird here. It is a very weird value.. Could you do me the favour of od -X /kernel | grep 8765 and see if it is present anywhere in you kernel ? I don't see it in mine, and if you don't have it either I pressume we're looking at a device driver doing something weird... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-bugs Thu Sep 18 12:50:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA01681 for bugs-outgoing; Thu, 18 Sep 1997 12:50:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA01675; Thu, 18 Sep 1997 12:50:02 -0700 (PDT) Resent-Date: Thu, 18 Sep 1997 12:50:02 -0700 (PDT) Resent-Message-Id: <199709181950.MAA01675@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, john@helium.vapornet.com Received: from helium.vapornet.com (root@helium.vapornet.com [208.202.126.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA00948 for ; Thu, 18 Sep 1997 12:41:17 -0700 (PDT) Received: from argon.vapornet.com (vapornet.xnet.com [205.243.141.107]) by helium.vapornet.com (8.8.7/VaporServer-v3.0+SpamNot) with ESMTP id OAA03542 for ; Thu, 18 Sep 1997 14:41:29 -0500 (CDT) Received: by argon.vapornet.com (8.8.7/VaporClient-1.1) id OAA00848; Thu, 18 Sep 1997 14:41:14 -0500 (CDT) Message-Id: <199709181941.OAA00848@argon.vapornet.com> Date: Thu, 18 Sep 1997 14:41:14 -0500 (CDT) From: john@helium.vapornet.com Reply-To: john@helium.vapornet.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: conf/4572: rc.network and ipfirewall kerne/module detection Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4572 >Category: conf >Synopsis: /etc/rc.network loads ipfirewall lkm regardless of ipfirewall in kernel >Confidential: yes >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Sep 18 12:50:01 PDT 1997 >Last-Modified: >Originator: John Preisler >Organization: VaporNet Inc. >Release: FreeBSD 2.2-STABLE i386 >Environment: freebsd-2.2 stable cvsupped before making world on 9/16 ipfirewall in kernel $Id: rc.network,v 1.1.2.10 1997/09/14 23:35:26 danny Exp $ $Id: rc.conf,v 1.1.2.20 1997/09/14 23:35:24 danny Exp $ $Id: rc.firewall,v 1.6.2.3 1997/09/14 23:35:25 danny Exp $ >Description: test to determine whether ipfirewall is in kernel or not fails. rc.network loads ipfirewall module even when firewall is in kernel. >How-To-Repeat: reboot the machine. >Fix: revise test for firewall_in_kernel or assign it explicitly. i chose to assign it explicitly. >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Sep 18 13:24:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA03631 for bugs-outgoing; Thu, 18 Sep 1997 13:24:08 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA03610 for ; Thu, 18 Sep 1997 13:24:01 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA14500 for freebsd-bugs@FreeBSD.ORG; Thu, 18 Sep 1997 22:23:59 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id WAA08283; Thu, 18 Sep 1997 22:11:35 +0200 (MET DST) Message-ID: <19970918221135.SE56310@uriah.heep.sax.de> Date: Thu, 18 Sep 1997 22:11:35 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: joerg_wunsch@interface-business.de (Joerg Wunsch) Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: My 2.2-stable panic reproduced References: <19970908193559.WU22983@ida.interface-business.de> <19970918200521.RX41144@ida.interface-business.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <19970918200521.RX41144@ida.interface-business.de>; from J Wunsch on Sep 18, 1997 20:05:21 +0200 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I wrote: > (kgdb) p ipp > $4 = (struct iso_node **) 0xefbffcec > (kgdb) p **ipp > $5 = {i_chain = {0x0, 0x0}, i_vnode = 0x87654321, i_devvp = 0x0, > i_flag = 4069182888, i_dev = 4028788080, i_number = 0, i_mnt = 0xf08a8f94, > i_lockf = 0xf0a6d400, i_endoff = 1049104, i_diroff = 0, i_offset = 0, > i_ino = 28672, i_spare0 = 28672, i_spare1 = 0, iso_extent = 1024, > i_size = -211922944, iso_start = -211922944, inode = {iso_atime = { > tv_sec = 65536, tv_nsec = 0}, iso_mtime = {tv_sec = 14888, > tv_nsec = 14888}, iso_ctime = {tv_sec = -267137396, tv_nsec = 0}, > iso_mode = 0, iso_uid = 0, iso_gid = 0, iso_links = 0, iso_rdev = 0}, > i_lockcount = 0} > So what? Replace the VREF by a VGET? The i_vnode value of 0x87654321 > sounds terribly interesting. See this bug report: > > Subject: Yet another 2.2-stable NFS (client) panic > X-Mailer: Mutt 0.60_p2-3,5,8-9 > X-Phone: +49-351-31809-14 > X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E > Organization: interface business GmbH, Dresden > Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x87654371 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf013476f > stack pointer = 0x10:0xefbffdb0 > > Exactly the same bogus value. So who the heck is dumping 0x87654321's > all over my memory??? j@uriah 128% find /usr/src/sys -name '*.[ch]' | xargs fgrep 87654321 /usr/src/sys/sys/buf.h:#define NOLIST ((struct buf *)0x87654321) So what gives? Who's putting NOLIST when and where? Why is it getting dereferenced? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-bugs Thu Sep 18 13:30:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA04239 for bugs-outgoing; Thu, 18 Sep 1997 13:30:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA04221; Thu, 18 Sep 1997 13:30:01 -0700 (PDT) Resent-Date: Thu, 18 Sep 1997 13:30:01 -0700 (PDT) Resent-Message-Id: <199709182030.NAA04221@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, dburr@POBoxes.com Received: from DonaldBurr.dyn.ml.org (ppp6213.la.inreach.net [199.107.160.213]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA03562 for ; Thu, 18 Sep 1997 13:23:32 -0700 (PDT) Received: (from dburr@localhost) by DonaldBurr.dyn.ml.org (8.8.5/8.8.5) id NAA03202; Thu, 18 Sep 1997 13:23:57 -0700 (PDT) Message-Id: <199709182023.NAA03202@DonaldBurr.dyn.ml.org> Date: Thu, 18 Sep 1997 13:23:57 -0700 (PDT) From: dburr@POBoxes.com Reply-To: dburr@POBoxes.com To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: bin/4575: user-ppp (iij-ppp) should use /etc/ppp/ip-{up,down} Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4575 >Category: bin >Synopsis: user-ppp (iij-ppp) should use /etc/ppp/ip-{up,down} >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu Sep 18 13:30:00 PDT 1997 >Last-Modified: >Originator: Donald Burr >Organization: Starfleet Command >Release: FreeBSD 2.2.2-RELEASE i386 >Environment: any properly-installed FreeBSD system >Description: iij-ppp (aka userland PPP) should use the /etc/ppp/ip-up and /etc/ppp/ip-down scripts when the link goes up and down. It should give these scripts the exact same argument list as pppd does. (for compatibility -- I use both pppd and iij-ppp on the same system, and switch whenever it suits me. Or think of the guy who wants to switch FROM pppd TO iij-ppp without having to rewrite his scripts!) The reason why the ip-up/down script arguments are important is that some programs you may want to run in these scripts require arguments. An example (one that I actually use) is with the Monolith DYNDNS service (http://www.ml.org/), which allows users with dynamically-assigned IP addresses (i.e. a PPP account with a ISP) to have their own domain name (e.g. mydom.dyn.ml.org). You need to run a client every time you dial in, so that the Monolith nameserver knows about what IP address you're using now. This client requires, among other data, the IP address of the PPP connection to be passed in as the argument. Other useful uses for the /etc/ppp/ip-{up,down} script are (some of which I actually use): writing all users (wall) when the connection goes up and down, starting SUCK (to grab nntp news), running 'ping ' to keep the connection up all the time, etc. >How-To-Repeat: IRRELEVANT. (RESISTANCE IS FUTILE.) >Fix: Don't ask me -- I'm a doctor, not a programmer! :) >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Sep 18 14:08:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA06889 for bugs-outgoing; Thu, 18 Sep 1997 14:08:37 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA06878; Thu, 18 Sep 1997 14:08:28 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id OAA12918; Thu, 18 Sep 1997 14:05:08 -0700 (MST) From: Terry Lambert Message-Id: <199709182105.OAA12918@usr03.primenet.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Thu, 18 Sep 1997 21:05:07 +0000 (GMT) Cc: gram@cdsec.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-Reply-To: <10531.874599844@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 18, 97 06:24:04 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Can you offer an explanation as to why the process never returns from > >the call to malloc, nor does it abort? This seems to indicate an infinite > >loop. Not having delved too deeply into your code, I can only speculate > >that the linked list is being made circular, so the process is in an > >infinite, looping traversal. Perhaps that is a check that can be added; > >namely that walking the list must always proceed forward, never backward > >(assuming that the list is kept in sequential order). > > This is about the only way you could get it to loop I think. That means > that somebody wrote to memory malloc hadn't passed them (ie: your code). > > This would indicate a bug of the class where memory is written to after > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. You could also get this after a free followed by another malloc for a shorter amount, and another malloc, with code using the original freed pointer. This could blow the list in either direction. Freeing something, making anohter overlapping allocation, and then freeing the original something again could do it too. Humorously, this is exactly the kind of thing you would get when you passed something allocated in thread local storage from thread A to B, and then thread A exits before thread B uses the pointer. 8-). I have suggested for some time now that allocations be ended against page boundries: A page: ,-------------------------------------------------------.,------ | xxx*************************||////// `-------------------------------------------------------'`------ Key: xxx malloc housekeeping *** user area /// guard page (unmapped) The result of any overruns would be a trappable and localizable fault. It is usedful to consider a "hole-y" stack for the same reasons; This would not necessarily require huge modifications to the compiler, on a "call-on-user-stack" mechanism for functions; for a whole-code environment, tiny compiler modifications are all that's necessary (so you push the arguments on the new stack before the call, mostly). The result of this would also be trappable and localizable faults for references of too many variables in the absence of a prototype to flag the error, and overrun of user arrays. If you wanted to go whole-hog, you *could* put each variable against it's guard page. Alternately, you could put all data in a referral area, and take a fault on each data access. The resoloution of the fault condition would check scope (effectively giving you byte level memory protection) and then return the referral area. Or signalling an error. Etc.. At least some of these are trivial to implement; you may want to consider it... Poul was right in his other posting about malloc() implementations showing programmer errors in different, unanticipated ways. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-bugs Thu Sep 18 14:20:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA07643 for bugs-outgoing; Thu, 18 Sep 1997 14:20:39 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA07634; Thu, 18 Sep 1997 14:20:33 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id OAA13921; Thu, 18 Sep 1997 14:19:52 -0700 (MST) From: Terry Lambert Message-Id: <199709182119.OAA13921@usr03.primenet.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 18 Sep 1997 21:19:51 +0000 (GMT) Cc: phk@critter.freebsd.dk, gram@cdsec.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-Reply-To: <11017.874607149@time.cdrom.com> from "Jordan K. Hubbard" at Sep 18, 97 11:25:49 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > This would indicate a bug of the class where memory is written to after > > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. > > Man, I sure wish there was a copy of purify available for FreeBSD. > It's great at catching stuff like this! :( Ask them for a port. What the hell, the worst that could happen is they'd say "no". > Maybe you could hack free() to do an mprotect(addr, len, PROT_NONE) on > free'd pages, unprotecting them again as necessary when the malloc > routines themselves need to frob that memory. Or, since we're just > testing, do it from an internally registered SIGBUS handler which > figures out the right thing to do. :-) Heh. mprotect must operate on pages. See my related suggestion... I didn't specify the mechanism (mprotect is the way it would be done). > BTW, how *do* you get the faulting memory location from a SIGBUS > handler? I was just playing around with this a bit and noted that it > wasn't immediately obvious how you'd get that info from the signal > handler. > > P.S. I also noticed that processes which catch SIGBUS will dump > incomplete core files - only the first 8K is dumped. Sounds like a > bug to me and I think we should either dump the whole thing or not > dump core at all rather than producing a truncated and rather useless > core file! :-) SIGBUS is kind of broken. THe typical way is that thee is a struct passed to the signal handler that isn't defined by POSIX, just like SIGWINCH. Sheesh. I guess I'm now the AntiPOSIX. 8-|. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-bugs Thu Sep 18 14:30:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA08205 for bugs-outgoing; Thu, 18 Sep 1997 14:30:04 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA08189; Thu, 18 Sep 1997 14:30:02 -0700 (PDT) Resent-Date: Thu, 18 Sep 1997 14:30:02 -0700 (PDT) Resent-Message-Id: <199709182130.OAA08189@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, ajhar@noao.edu Received: (from nobody@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA07620; Thu, 18 Sep 1997 14:20:04 -0700 (PDT) Message-Id: <199709182120.OAA07620@hub.freebsd.org> Date: Thu, 18 Sep 1997 14:20:04 -0700 (PDT) From: ajhar@noao.edu To: freebsd-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: www-1.0 Subject: misc/4576: mfs does not mount requested size from /etc/fstab Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4576 >Category: misc >Synopsis: mfs does not mount requested size from /etc/fstab >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Sep 18 14:30:01 PDT 1997 >Last-Modified: >Originator: Edward Ajhar >Organization: National Optical Astronomy Observatories >Release: FreeBSD-2.2-stable from 1997-09-10 >Environment: FreeBSD husa.tuc.noao.edu 2.2-STABLE FreeBSD 2.2-STABLE #0: Fri Sep 12 11:46:07 MST 1997 ajhar@husa.tuc.noao.edu:/usr/src/sys/compile/HUSA i386 >Description: Memory file system when mounted automatically from /etc/fstab does not yield the size filesystem requested. It appears that ~32MB is what you get regardless of what you want, but I have not tried this for sizes smaller than 32MB. (Previously, the size was about the size of the partition [I think].) This began happening, I believe, some time in August. >How-To-Repeat: If /etc/fstab contains /dev/sd0s1b /tmp mfs rw,-s=131072 0 0 a 'df' yields Filesystem 1K-blocks Used Avail Capacity Mounted on mfs:28 31404 4 28888 0% /tmp However, it DOES work to mount a filesystem manually with mount -t mfs -o -s=131072 /dev/sd1s1b /mnt This yields Filesystem 1K-blocks Used Avail Capacity Mounted on mfs:288 63567 1 58481 0% /mnt although this is not really an acceptable work-around for /tmp. >Fix: >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Sep 18 14:30:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA08264 for bugs-outgoing; Thu, 18 Sep 1997 14:30:34 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA08256; Thu, 18 Sep 1997 14:30:31 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id OAA15687; Thu, 18 Sep 1997 14:30:06 -0700 (PDT) To: Terry Lambert cc: phk@critter.freebsd.dk, gram@cdsec.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Thu, 18 Sep 1997 21:19:51 -0000." <199709182119.OAA13921@usr03.primenet.com> Date: Thu, 18 Sep 1997 14:30:06 -0700 Message-ID: <15683.874618206@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > This would indicate a bug of the class where memory is written to after > > > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. > > > > Man, I sure wish there was a copy of purify available for FreeBSD. > > It's great at catching stuff like this! :( > > Ask them for a port. What the hell, the worst that could happen is they'd > say "no". I have. They did. :-) Jordan From owner-freebsd-bugs Thu Sep 18 14:51:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA09736 for bugs-outgoing; Thu, 18 Sep 1997 14:51:37 -0700 (PDT) Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA09730; Thu, 18 Sep 1997 14:51:31 -0700 (PDT) Received: (from tlambert@localhost) by usr03.primenet.com (8.8.5/8.8.5) id OAA16166; Thu, 18 Sep 1997 14:49:45 -0700 (MST) From: Terry Lambert Message-Id: <199709182149.OAA16166@usr03.primenet.com> Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 18 Sep 1997 21:49:44 +0000 (GMT) Cc: tlambert@primenet.com, phk@critter.freebsd.dk, gram@cdsec.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-Reply-To: <15683.874618206@time.cdrom.com> from "Jordan K. Hubbard" at Sep 18, 97 02:30:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Man, I sure wish there was a copy of purify available for FreeBSD. > > > It's great at catching stuff like this! :( > > > > Ask them for a port. What the hell, the worst that could happen is they'd > > say "no". > > I have. They did. :-) Having suffered the worst, there is no place to go but "squeaky wheel". 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-bugs Thu Sep 18 14:56:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA10258 for bugs-outgoing; Thu, 18 Sep 1997 14:56:15 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA10253; Thu, 18 Sep 1997 14:56:12 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id OAA15805; Thu, 18 Sep 1997 14:52:26 -0700 (PDT) To: Terry Lambert cc: phk@critter.freebsd.dk, gram@cdsec.com, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) In-reply-to: Your message of "Thu, 18 Sep 1997 21:49:44 -0000." <199709182149.OAA16166@usr03.primenet.com> Date: Thu, 18 Sep 1997 14:52:26 -0700 Message-ID: <15801.874619546@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk By all means squeak, my friends, squeak. :) Jordan > > > > Man, I sure wish there was a copy of purify available for FreeBSD. > > > > It's great at catching stuff like this! :( > > > > > > Ask them for a port. What the hell, the worst that could happen is they' d > > > say "no". > > > > I have. They did. :-) > > Having suffered the worst, there is no place to go but "squeaky wheel". 8-). > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. From owner-freebsd-bugs Thu Sep 18 15:03:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA10728 for bugs-outgoing; Thu, 18 Sep 1997 15:03:10 -0700 (PDT) Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA10664; Thu, 18 Sep 1997 15:02:39 -0700 (PDT) Message-Id: <199709182202.PAA10664@hub.freebsd.org> Received: from bcars520.ott.bnr.ca (actually 47.128.5.188) by bcarsde4.localhost; Thu, 18 Sep 1997 18:00:39 -0400 Received: from bnr.ca by bcars520.bnr.ca id <09907-0@bcars520.bnr.ca>; Thu, 18 Sep 1997 18:00:20 -0400 Date: 18 Sep 1997 17:59 EDT To: phk@critter.freebsd.dk Cc: hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG From: "Andrew Atrens" Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message "Bug in malloc/free (was: Memory leak in getservbyXXX?)", phk@critter.freebsd.dk writes: > > This is about the only way you could get it to loop I think. That means > that somebody wrote to memory malloc hadn't passed them (ie: your code). > > This would indicate a bug of the class where memory is written to after > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. Why not have free() shred memory its releasing? Shredding memory with high values can often cause the offending code (which is still attempting to r/w this memory) to bus error. >From what I can tell Poul your free() actually gives the memory back to the OS ( at least some of the time ). Perhaps Graham could hack it to *not* give back the memory to the OS ( on those occasions when it would ), and in all cases shred it. Very ungraceful, but depending on the tools available ( or unavailable as in this case ), reasonably effective. Andrew ( opinions mine, not Nortels. ) > > -- > Poul-Henning Kamp FreeBSD coreteam member > phk@FreeBSD.ORG "Real hackers run -current on their laptop." > From owner-freebsd-bugs Thu Sep 18 17:00:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA19174 for bugs-outgoing; Thu, 18 Sep 1997 17:00:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA19136; Thu, 18 Sep 1997 17:00:02 -0700 (PDT) Date: Thu, 18 Sep 1997 17:00:02 -0700 (PDT) Message-Id: <199709190000.RAA19136@hub.freebsd.org> To: freebsd-bugs Cc: From: Peter Wemm Subject: Re: misc/4576: mfs does not mount requested size from /etc/fstab Reply-To: Peter Wemm Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR misc/4576; it has been noted by GNATS. From: Peter Wemm To: ajhar@noao.edu Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: misc/4576: mfs does not mount requested size from /etc/fstab Date: Fri, 19 Sep 1997 07:58:39 +0800 ajhar@noao.edu wrote: > >Number: 4576 > >Category: misc > >Synopsis: mfs does not mount requested size from /etc/fstab [..] > >How-To-Repeat: > If /etc/fstab contains > /dev/sd0s1b /tmp mfs rw,-s=131072 0 0 > a 'df' yields > Filesystem 1K-blocks Used Avail Capacity Mounted on > mfs:28 31404 4 28888 0% /tmp > > However, it DOES work to mount a filesystem manually with > mount -t mfs -o -s=131072 /dev/sd1s1b /mnt > This yields > Filesystem 1K-blocks Used Avail Capacity Mounted on > mfs:288 63567 1 58481 0% /mnt > although this is not really an acceptable work-around for /tmp. This is a ``bug'' in the default /etc/login.conf settings. The resource limits for 'daemon' are what /etc/rc (and hence the mfs mount at boot) are run with. 'daemon' has a datasize limit of 32MB, and mount_mfs goes to a fair bit of trouble to fit within it's hard data limit. I have been thinking of having mount_mfs reset it's hard data limit to infinity if run by root (such as at boot time). This will get a fssize of what was asked for in spite of the /etc/login.conf settings. Another fix would be to put some more suitable settings for daemon in login.conf. Cheers, -Peter From owner-freebsd-bugs Thu Sep 18 17:11:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA20043 for bugs-outgoing; Thu, 18 Sep 1997 17:11:10 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA20004; Thu, 18 Sep 1997 17:10:58 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id CAA07340; Fri, 19 Sep 1997 02:10:43 +0200 (MET DST) Date: Fri, 19 Sep 1997 02:10:43 +0200 (MET DST) Message-Id: <199709190010.CAA07340@bitbox.follo.net> From: Eivind Eklund To: Graham Wheeler CC: phk@critter.freebsd.dk, hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-reply-to: Graham Wheeler's message of Thu, 18 Sep 1997 18:06:51 +0200 (SAT) Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) References: <7198.874597557@critter.freebsd.dk> <199709181606.SAA00506@cdsec.com> Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > >This is a preliminary report, as it is still very early and the results > > >we are seeing may be coincidental. > > > > >I'll follow up on this in the morning (South African time) - if the > > >process is still running smoothly this would suggests that there > > >may be a problem with the malloc/free code in libc. > > > > Well, you'll still have to do more to convince me. > > I'll do my best... ;-) > > > The fact that two malloc implementations act differently is no proof > > of one of them being wrong, the different policies they use can make > > a bit difference in the outcome for errors in the main code. > > Agreed. > > > > > Imagine this: > > > > char *p = malloc(12); > > char *q = malloc(12); > > p[12] = 'B'; > > > > In the case of phkmalloc you have written into padding space, > > in the case of many other mallocs you have just destroyed the > > "back" pointer for the *q allocation. The results are very > > different. > > The debug libmalloc that I am now using uses the following layout for > an allocated block: > > | prevlink | nextlink | size | memspace | size | > > i.e. the size is stored both immediately preceding and immediately > following the useable space. As part of the consistency checking, > these two sizes are compared and should match. This should catch almost > all small overruns or underruns, and abort the process. So this > malloc should be less tolerant of bugs in my code than pkhmalloc is, > rather than more tolerant, Try running efence (not in the ports-collection - I'll remedy that). This little gem of a program add a non-accessible page after or before your allocation (both at the same time is not possible), and will give you a core dump the moment you do an invalid access. I've used it to debug large programs for others before; I fortunately haven't needed it since I switched to FreeBSD, and thus don't know how easy it compile here. It compiled cleanly on SGI and Linux, at least. ftp://ftp.science.unitn.it/pub/unix/programming/libraries/efence-2.04.tar.gz Eivind. From owner-freebsd-bugs Thu Sep 18 19:06:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA28951 for bugs-outgoing; Thu, 18 Sep 1997 19:06:34 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA28927; Thu, 18 Sep 1997 19:06:27 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id TAA01084; Thu, 18 Sep 1997 19:06:21 -0700 (PDT) Message-ID: <19970918190620.27911@hydrogen.nike.efn.org> Date: Thu, 18 Sep 1997 19:06:20 -0700 From: John-Mark Gurney To: Andrew Atrens Cc: hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) References: <199709182202.PAA10664@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709182202.PAA10664@hub.freebsd.org>; from Andrew Atrens on Thu, Sep 18, 1997 at 05:59:00PM -0500 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Andrew Atrens scribbled this message on Sep 18: > In message "Bug in malloc/free (was: Memory leak in getservbyXXX?)", phk@critter.freebsd.dk writes: > > > > > This is about the only way you could get it to loop I think. That means > > that somebody wrote to memory malloc hadn't passed them (ie: your code). > > > > This would indicate a bug of the class where memory is written to after > > being free()'ed, a kind of bug which phkmalloc makes no attempt to catch. > > Why not have free() shred memory its releasing? Shredding memory with high > values can often cause the offending code (which is still attempting > to r/w this memory) to bus error. umm... malloc's option J does this: J ``junk'' fill some junk into the area allocated. Currently junk is bytes of 0xd0, this is pronounced ``Duh'' :-) -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-bugs Thu Sep 18 19:22:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA29739 for bugs-outgoing; Thu, 18 Sep 1997 19:22:35 -0700 (PDT) Received: from sasami.jurai.net (winter@sasami.jurai.net [207.96.1.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA29713; Thu, 18 Sep 1997 19:21:54 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.7/8.8.7) with SMTP id WAA15365; Thu, 18 Sep 1997 22:21:42 -0400 (EDT) Date: Thu, 18 Sep 1997 22:21:42 -0400 (EDT) From: "Matthew N. Dodd" To: ajhar@noao.edu cc: freebsd-gnats-submit@FreeBSD.ORG, GNATS Management , freebsd-bugs@hub.freebsd.org Subject: Re: misc/4576: mfs does not mount requested size from /etc/fstab In-Reply-To: <199709182120.OAA07620@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sorry, this works for me on a fairly recent 2.2-STABLE system /dev/sd0s2b /tmp mfs rw,async,nosuid,nodev,-s=131072 0 0 mfs:22 63567 1313 57169 2% /tmp On Thu, 18 Sep 1997 ajhar@noao.edu wrote: > > >Number: 4576 > >Category: misc > >Synopsis: mfs does not mount requested size from /etc/fstab > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-bugs > >State: open > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Thu Sep 18 14:30:01 PDT 1997 > >Last-Modified: > >Originator: Edward Ajhar > >Organization: > National Optical Astronomy Observatories > >Release: FreeBSD-2.2-stable from 1997-09-10 > >Environment: > FreeBSD husa.tuc.noao.edu 2.2-STABLE FreeBSD 2.2-STABLE #0: Fri Sep 12 11:46:07 MST 1997 ajhar@husa.tuc.noao.edu:/usr/src/sys/compile/HUSA i386 > > >Description: > Memory file system when mounted automatically from /etc/fstab does > not yield the size filesystem requested. It appears that ~32MB is > what you get regardless of what you want, but I have not tried this > for sizes smaller than 32MB. (Previously, the size was about the > size of the partition [I think].) This began happening, I believe, > some time in August. > > > >How-To-Repeat: > If /etc/fstab contains > > /dev/sd0s1b /tmp mfs rw,-s=131072 0 0 > > a 'df' yields > > Filesystem 1K-blocks Used Avail Capacity Mounted on > mfs:28 31404 4 28888 0% /tmp > > > However, it DOES work to mount a filesystem manually with > > mount -t mfs -o -s=131072 /dev/sd1s1b /mnt > > This yields > > Filesystem 1K-blocks Used Avail Capacity Mounted on > mfs:288 63567 1 58481 0% /mnt > > although this is not really an acceptable work-around for /tmp. > > >Fix: > > >Audit-Trail: > >Unformatted: > /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ From owner-freebsd-bugs Thu Sep 18 19:30:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA00212 for bugs-outgoing; Thu, 18 Sep 1997 19:30:05 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA00191; Thu, 18 Sep 1997 19:30:02 -0700 (PDT) Date: Thu, 18 Sep 1997 19:30:02 -0700 (PDT) Message-Id: <199709190230.TAA00191@hub.freebsd.org> To: freebsd-bugs Cc: From: "Matthew N. Dodd" Subject: Re: misc/4576: mfs does not mount requested size from /etc/fstab Reply-To: "Matthew N. Dodd" Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR misc/4576; it has been noted by GNATS. From: "Matthew N. Dodd" To: ajhar@noao.edu Cc: freebsd-gnats-submit@FreeBSD.ORG, GNATS Management , freebsd-bugs@hub.freebsd.org Subject: Re: misc/4576: mfs does not mount requested size from /etc/fstab Date: Thu, 18 Sep 1997 22:21:42 -0400 (EDT) Sorry, this works for me on a fairly recent 2.2-STABLE system /dev/sd0s2b /tmp mfs rw,async,nosuid,nodev,-s=131072 0 0 mfs:22 63567 1313 57169 2% /tmp On Thu, 18 Sep 1997 ajhar@noao.edu wrote: > > >Number: 4576 > >Category: misc > >Synopsis: mfs does not mount requested size from /etc/fstab > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-bugs > >State: open > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Thu Sep 18 14:30:01 PDT 1997 > >Last-Modified: > >Originator: Edward Ajhar > >Organization: > National Optical Astronomy Observatories > >Release: FreeBSD-2.2-stable from 1997-09-10 > >Environment: > FreeBSD husa.tuc.noao.edu 2.2-STABLE FreeBSD 2.2-STABLE #0: Fri Sep 12 11:46:07 MST 1997 ajhar@husa.tuc.noao.edu:/usr/src/sys/compile/HUSA i386 > > >Description: > Memory file system when mounted automatically from /etc/fstab does > not yield the size filesystem requested. It appears that ~32MB is > what you get regardless of what you want, but I have not tried this > for sizes smaller than 32MB. (Previously, the size was about the > size of the partition [I think].) This began happening, I believe, > some time in August. > > > >How-To-Repeat: > If /etc/fstab contains > > /dev/sd0s1b /tmp mfs rw,-s=131072 0 0 > > a 'df' yields > > Filesystem 1K-blocks Used Avail Capacity Mounted on > mfs:28 31404 4 28888 0% /tmp > > > However, it DOES work to mount a filesystem manually with > > mount -t mfs -o -s=131072 /dev/sd1s1b /mnt > > This yields > > Filesystem 1K-blocks Used Avail Capacity Mounted on > mfs:288 63567 1 58481 0% /mnt > > although this is not really an acceptable work-around for /tmp. > > >Fix: > > >Audit-Trail: > >Unformatted: > /* Matthew N. Dodd | A memory retaining a love you had for life winter@jurai.net | As cruel as it seems nothing ever seems to http://www.jurai.net/~winter | go right - FLA M 3.1:53 */ From owner-freebsd-bugs Thu Sep 18 21:02:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA06389 for bugs-outgoing; Thu, 18 Sep 1997 21:02:46 -0700 (PDT) Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA06335; Thu, 18 Sep 1997 21:01:49 -0700 (PDT) Message-Id: <199709190401.VAA06335@hub.freebsd.org> Received: from bcars520.ott.bnr.ca (actually 47.128.5.188) by bcarsde4.localhost; Thu, 18 Sep 1997 23:42:25 -0400 Received: from bnr.ca by bcars520.bnr.ca id <11183-0@bcars520.bnr.ca>; Thu, 18 Sep 1997 23:41:16 -0400 Date: 18 Sep 1997 23:41 EDT To: hackers@FreeBSD.ORG Cc: gram@cdsec.com, phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG From: "Andrew Atrens" Subject: Re: Bug in malloc/free Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Folks, By coincidence I *may* have seen a bug similar to Graham's last night... I'm using 3.0 current ( circa. Aug 08 ). I built `ddd-2.1.1.tar.gz', found in /pub/FreeBSD/distfiles which is a largely C++ interface for gdb and others. Unfortunately, when I tried to run it, it gobbled memory until it choked. I tried a second time, this time killing it with CTRL-C and observed: ^Cddd in malloc(): warning: recursive call. Virtual memory exceeded in `new' After reading Graham's thread I relinked it against libgnumalloc, and low and behold it works like a charm ! Does this point to an incompatibility problem between phkmalloc and g++ compiled code ? Just a thought, Andrew. From owner-freebsd-bugs Thu Sep 18 21:10:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA06923 for bugs-outgoing; Thu, 18 Sep 1997 21:10:06 -0700 (PDT) Received: (from gnats@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA06910; Thu, 18 Sep 1997 21:10:01 -0700 (PDT) Resent-Date: Thu, 18 Sep 1997 21:10:01 -0700 (PDT) Resent-Message-Id: <199709190410.VAA06910@hub.freebsd.org> Resent-From: gnats (GNATS Management) Resent-To: freebsd-bugs Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, sjr@home.net Received: from istari.home.net (cc158233-a.catv1.md.home.com [24.3.25.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA06305 for ; Thu, 18 Sep 1997 21:01:31 -0700 (PDT) Received: (from sjr@localhost) by istari.home.net (8.8.7/8.8.6) id AAA00454; Fri, 19 Sep 1997 00:01:29 -0400 (EDT) Message-Id: <199709190401.AAA00454@istari.home.net> Date: Fri, 19 Sep 1997 00:01:29 -0400 (EDT) From: sjr@home.net Reply-To: sjr@home.net To: FreeBSD-gnats-submit@FreeBSD.ORG X-Send-Pr-Version: 3.2 Subject: docs/4579: Typo in usr.bin/netstat/netstat.1 Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Number: 4579 >Category: docs >Synopsis: Typo in usr.bin/netstat/netstat.1 >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Thu Sep 18 21:10:00 PDT 1997 >Last-Modified: >Originator: Stephen J. Roznowski >Organization: >Release: FreeBSD 3.0-CURRENT i386 >Environment: >Description: It appears that two of these flags got reversed. >How-To-Repeat: >Fix: --- usr.bin/netstat/netstat.1.orig Thu Sep 18 23:57:19 1997 +++ usr.bin/netstat/netstat.1 Thu Sep 18 23:57:39 1997 @@ -227,8 +227,8 @@ manual pages. The mapping between letters and flags is: .Bl -column XXXX RTF_BLACKHOLE -1 RTF_PROTO2 Protocol specific routing flag #1 -2 RTF_PROTO1 Protocol specific routing flag #2 +1 RTF_PROTO1 Protocol specific routing flag #1 +2 RTF_PROTO2 Protocol specific routing flag #2 3 RTF_PROTO3 Protocol specific routing flag #3 B RTF_BLACKHOLE Just discard pkts (during updates) b RTF_BROADCAST The route represents a broadcast address >Audit-Trail: >Unformatted: From owner-freebsd-bugs Thu Sep 18 22:00:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA10417 for bugs-outgoing; Thu, 18 Sep 1997 22:00:15 -0700 (PDT) Received: from spinner.dialix.com.au (spinner.dialix.com.au [202.12.86.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA10314; Thu, 18 Sep 1997 21:59:55 -0700 (PDT) Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.dialix.com.au with ESMTP id MAA07378; Fri, 19 Sep 1997 12:59:34 +0800 (WST) Message-Id: <199709190459.MAA07378@spinner.dialix.com.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Andrew Atrens" cc: hackers@FreeBSD.ORG, gram@cdsec.com, phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG Subject: Re: Bug in malloc/free In-reply-to: Your message of "18 Sep 1997 23:41:00 EDT." <199709190401.VAA06335@hub.freebsd.org> Date: Fri, 19 Sep 1997 12:59:33 +0800 From: Peter Wemm Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Andrew Atrens" wrote: > > Hi Folks, > > By coincidence I *may* have seen a bug similar to Graham's last night... > I'm using 3.0 current ( circa. Aug 08 ). > > I built `ddd-2.1.1.tar.gz', found in /pub/FreeBSD/distfiles which is a > largely C++ interface for gdb and others. Unfortunately, when I tried to > run it, it gobbled memory until it choked. I tried a second time, this > time killing it with CTRL-C and observed: > > ^Cddd in malloc(): warning: recursive call. > Virtual memory exceeded in `new' > > After reading Graham's thread I relinked it against libgnumalloc, and low > and behold it works like a charm ! > > Does this point to an incompatibility problem between phkmalloc and g++ > compiled code ? Hmm, this particular thing sounds like a signal recursion problem.. If a malloc() instance is interrupted in the middle of execution and a signal is taken, and that signal again calls malloc (eg: via new), the state of the malloc arena is 'indeterminate'. Perhaps malloc is doing something that can cause a signal? or perhaps ddd has a fast timer that calls malloc (or new) that can interrupt other malloc calls? Perhaps malloc() could/should block SIGALRM while executing it's non-reentrant parts? > Just a thought, > > Andrew. > Cheers, -Peter From owner-freebsd-bugs Thu Sep 18 22:11:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA11440 for bugs-outgoing; Thu, 18 Sep 1997 22:11:18 -0700 (PDT) Received: from slip129-37-223-142.ca.us.ibm.net (slip129-37-223-142.ca.us.ibm.net [129.37.223.142]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA11434 for ; Thu, 18 Sep 1997 22:11:13 -0700 (PDT) Received: (from jd@localhost) by slip129-37-223-142.ca.us.ibm.net (8.8.5/8.8.5) id WAA13160 for bugs@freebsd.org; Thu, 18 Sep 1997 22:11:20 -0700 (PDT) Date: Thu, 18 Sep 1997 22:11:20 -0700 (PDT) From: "Joseph I. Davida" Message-Id: <199709190511.WAA13160@slip129-37-223-142.ca.us.ibm.net> To: bugs@freebsd.org Subject: Mem Leak ?? Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Running FreeBSD Snap 3.0 System is Pentium P5/200MHz, 64 Meg Ram, 512K Cache, 96 Meg Swap space. X is up and running with the following X apps running: tvtwm window manager xbiff xclock icon manager virtual desktop Xsysinfo vmstat When I try to run netscape (version 4.3b8), I get a message from netscape that I am out of memory. SO I looked at what vmstat was saying: procs memory page disks faults cpu r b w avm fre flt re pi po fr sr s0 c0 w0 in sy cs us sy id 1 0 0 4033532 21008 13 0 0 0 14 0 1 0 0 166 172 30 1 0 99 0 0 0 4029456 21008 2 0 0 0 0 0 0 0 0 113 76 9 0 0 100 0 0 0 4029812 21008 30 0 0 0 33 0 1 0 0 165 1529 48 3 1 96 0 0 0 4029812 21008 13 0 0 0 14 0 1 0 0 109 74 10 0 0 100 0 0 0 4029812 21008 2 0 0 0 0 0 0 0 0 179 372 55 2 1 97 0 0 0 4029812 21008 13 0 0 0 14 0 1 0 0 242 50055 96 16 40 44 0 0 0 4029812 21008 18 0 0 0 19 0 0 0 0 139 1467 37 3 1 96 Holy smokes!! Where did all my free pages go???? Here is the message from bootup, which shows I have plenty of free memory. So where did all the mem go??? Is the kernel losing track of free'ed up memory? Also, look at output of ps -agxl below so you can check resident set sizes. Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-970522-SNAP #0: Wed Aug 6 08:17:50 PDT 1997 root@:/sd0a/usr/src/sys/compile/SARGON CPU: Pentium (199.43-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x1bf real memory = 67108864 (65536K bytes) avail memory = 62771200 (61300K bytes) UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 0 0 0 -18 0 0 0 sched DLs ?? 0:00.03 (swapper) 0 1 0 0 10 0 476 88 wait Is ?? 0:00.02 /sbin/init - 0 2 0 1 -18 0 0 0 psleep DL ?? 0:02.07 (pagedaemon 0 3 0 0 28 0 0 0 psleep DL ?? 0:00.00 (vmdaemon) 0 4 0 0 28 0 0 0 update DL ?? 0:00.67 (update) 0 32 1 6 18 0 204 0 pause Is ?? 0:00.00 adjkerntz -i 0 133 1 0 2 0 200 252 select Is ?? 0:00.19 syslogd 0 168 1 0 2 0 192 160 select Is ?? 0:00.08 inetd 0 170 1 0 18 0 332 240 pause Ss ?? 0:00.26 cron 0 173 1 0 2 0 204 160 select Is ?? 0:00.02 lpd 0 176 1 0 2 0 528 372 accept Is ?? 0:00.04 sendmail: ac 0 225 1 0 2 0 276 316 select I ?? 0:00.07 /usr/X11R6/b 0 230 225 0 2 0 4692 6764 select Ss ?? 2:02.17 /usr/X11R6/b 0 231 225 0 10 0 320 540 wait Is ?? 0:00.06 -:0 108 260 231 0 10 0 496 92 wait Is ?? 0:00.06 /bin/sh /hom 0 276 260 0 2 0 2116 1036 select I ?? 0:05.99 xterm 108 280 260 0 2 0 764 1744 select I ?? 0:04.05 /usr/X11R6/b 0 12237 1 0 2 0 2112 2024 select S ?? 0:03.78 xterm -e vms 0 12287 1 1 2 0 2112 2064 select S ?? 0:01.21 xterm 108 12328 1 6 2 5 288 1744 select SN ?? 0:03.39 xsysinfo 0 12893 111 0 18 0 172 40 pause S ?? 0:00.00 sleep 10 0 12895 25 0 18 0 172 40 pause S ?? 0:00.00 sleep 5 108 12238 12237 0 18 0 292 640 pause Ss+ p0 0:00.64 vmstat 3 108 287 276 0 10 0 348 136 wait Is p1 0:00.42 -ksh (ksh) 108 10570 287 0 2 0 11924 11424 sbwait I+ p1 0:57.60 rn misc.jobs 108 12288 12287 0 10 0 344 656 wait Is p2 0:00.12 -ksh (ksh) 108 12625 12288 0 18 0 372 636 pause I+ p2 0:00.02 Mail bugs@fr 108 12725 12625 0 -6 0 668 916 piperd S+ p2 0:00.34 vi /tmp/Re01 108 12896 12725 1 28 0 652 280 - R+ p2 0:00.01 ps -agxl 108 12897 12725 0 28 0 0 0 - Z+ p2 0:00.00 (vi) 0 222 1 0 3 0 180 164 ttyin Is+ v0 0:00.02 /usr/libexec 0 223 1 0 3 0 180 164 ttyin Is+ v1 0:00.02 /usr/libexec 0 224 1 0 3 0 180 164 ttyin Is+ v2 0:00.02 /usr/libexec 0 25 1 0 10 0 484 112 wait S con- 0:08.57 /bin/sh /sbi 0 111 1 0 10 0 492 116 wait S con- 0:04.62 /bin/sh /sbi 0 88 1 0 18 0 196 200 pause Is+ a0 0:00.04 /usr/local/s From owner-freebsd-bugs Thu Sep 18 22:13:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA11654 for bugs-outgoing; Thu, 18 Sep 1997 22:13:52 -0700 (PDT) Received: from slip129-37-223-142.ca.us.ibm.net (slip129-37-223-142.ca.us.ibm.net [129.37.223.142]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA11648 for ; Thu, 18 Sep 1997 22:13:49 -0700 (PDT) Received: (from jd@localhost) by slip129-37-223-142.ca.us.ibm.net (8.8.5/8.8.5) id WAA13261 for bugs@freebsd.org; Thu, 18 Sep 1997 22:14:01 -0700 (PDT) Date: Thu, 18 Sep 1997 22:14:01 -0700 (PDT) From: "Joseph I. Davida" Message-Id: <199709190514.WAA13261@slip129-37-223-142.ca.us.ibm.net> To: bugs@freebsd.org Subject: My actual mailing address Sender: owner-freebsd-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk If anyone cares to respond to my previous report of "possible memory leak", I can be reached at either of the following: jd@alumni.cs.uwm.edu jd108@ibm.net The "From" email addres of this message is a temporarily assigned address from the ISP IBM Global Networking. Thanks Joe From owner-freebsd-bugs Thu Sep 18 22:22:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA12287 for bugs-outgoing; Thu, 18 Sep 1997 22:22:57 -0700 (PDT) Received: from mail.mco.bellsouth.net.bellsouth.net (mail.mco.bellsouth.net [205.152.48.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA12281 for ; Thu, 18 Sep 1997 22:22:53 -0700 (PDT) From: paul@bellsouth.net Received: from DMs_K5166 (host-32-96-76-90.mco.bellsouth.net [32.96.76.90]) by mail.mco.bellsouth.net.bellsouth.net (8.8.5/8.8.5) with SMTP id BAA29792; Fri, 19 Sep 1997 01:21:21 -0400 (EDT) Date: Fri, 19 Sep 1997 01:21:21 -0400 (EDT) To: paul@bellsouth.net Comments: Authenticated sender is Subject: Only $6 Away From Freedom Message-Id: <199709194351OAA42415@post.mco.bellsouth.net> Sender: owner-freebsd-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 



Only $6 Away From Freedom!!!
			
			
This is a ONE-TIME-ONLY MESSAGE. There is no need to reply or call to 
remove, you will receive no further mailings from us.




> Hello,
> 
>   You have just received the letter that will change your life forever. 
> This email contains six sections;  TESTIMONY, LEGALITY, MECHANICS, DETAILS,
> METHODS and SUMMARY.  Please read through each section very carefully.  This
> a great opportunity to make a substantial amount of money with as little 
> as $6.00 invested with two hours time! 
>   You may or may not have read emails like this one and thought is was too
> good to be true, but it's real!  This is the best of any letters you may or 
> may not have received because this letter provides you with the complete 
> information and tools you will need to be successful and affirm that this 
> is perfectly legal!  Please read through all sections and follow the 
> simple instructions step by step.
> 
> **************************************************************************
> ***************************  TESTIMONY  **********************************
> **************************************************************************
> 
> Hopefully my name is still on the list below. I am a retired attorney,  and
> about two years ago a man came to me with a letter. The letter he  brought me
> is basically the same as the letter in front of you now.  He asked me to
> verify the fact that this letter was legal. I told him that I would review it
> and get back to him. When I first read the letter I thought it was some
> off-the-wall idea to make money. A week later I met again with my client to
> discuss the issue. I told him that the letter originally brought to me was
> not 100% legal. My client asked me to alter the letter to make it 100% legal.
> I advised him to make a small change in the letter and it would be all right.
>   I was curious about the letter, so he told me how it works. I thought it
> was a long shot, so I decided against participating. Before my client left,
> I asked him to keep me updated as to his results. About two months later he
> called to tell me that he had received over $800,000 in cash! I didn't
> believe him so he asked me to try the plan and see for myself. I thought
> about it for a couple of days and decided that there was not much to lose. I
> followed the instructions exactly and 
> mailed out 200 letters. Sure enough, the money started coming! It came slowly
> at first, but after three weeks I was getting more than I could open in a
> day. After about three months the money stopped coming. I kept a precise
> record of my earnings and at the end it totaled $868,439.00.
>   I was earning a good living as a lawyer, but as anyone in the legal
> profession will tell you, there is a lot of stress that comes with the job. I
> told myself if things worked out I would retire from practice and play golf.
> I decided to try the letter again, but this time I sent 500 letters out.
> Well, three months later I had totaled $2,344,178.00!!! I just couldn't
> believe it. I met my old client for lunch to find out how this exactly works.
> He told me that there were a few similar letters  going around. What made
> this one different is the fact that there are six names on the letter, not
> five like most others. That fact alone resulted in far more returns. The
> other factor was the advice I gave him in making sure the whole thing was
> perfectly legal, since no one wants to risk doing anything illegal.  I bet by
> now you are curious about what little change I told him to make. Well, if you
> send a letter like this out, to be legal, you must sell something if you
> expect to receive a dollar.
> I told him that anyone sending a dollar out must receive something in return.
> So when you send a dollar to each of the six names on the list, you must
> include a  slip of paper saying, "Please put me on your mailing list" and
> include your name and mailing address. Your phone # is optional. This is the
> key to the program! The item you will receive for a dollar you send to the
> six names below, is this letter and the right to earn thousands. We will be
> working together to improve each others lives!
> (Responses vary and income could be more or less than stated above)
> 
> ***************************************************************************
> **************************  LEGALITY  *************************************
> ***************************************************************************
> 
> This is basically a mail order opportunity.  As said above, you must receive
> something in return for money put forth.  For everyone who sends $1.00, you
> must in return put them on a mailing list.  Keep it on paper, computer or
> whatever is most convenient for you. You don't have to do anything with this
> list, just keep it updated with everyone's address who sends you money.  This
> is completely legal and you are welcome to verify it yourself by calling the
> US Post Office at 1-(800)-725-2161.  All extra income must be declared at tax
> time.  The sender of this letter assumes no responsibilities for any
> transactions that take place.  Total sums of money will vary due to response
> and number of letters sent. 
> Testimony was given by an anonymous source.  Each individual is conducting
>  a mail opportunity and is not responsible for letters sent out by other mail
> opportunist.  This is legal!  (Refer to title 18, Section 1302 & 1342 of the
> US Postal and Lottery Laws)
> 
> ***************************************************************************
> **************************  MECHANICS  ************************************
> *************************************************************************** 
> 
> 
> So how does this work?  How could I potentially earn a substantial amount of
> money with such an insignificant investment?  The numbers are ASTOUNDING!!!
>  Provided here is a conservative example of how your mailing opportunity
> could earn you more money than you could DREAM!  Assume for example you get a
> 7.5% return rate, which is very
> conservative.
> 1) When you mail out 200 letters, 15 people will send you $1.00.
> 2) Those 15 mail out 200 letters, and 225 people will send you $1.00
> 3) Those 225 mail out 200 letters, and 3,375 people will send you $1.00
> 4) Those 3,375 mail out 200 letters, and 50,625 people will send you $1.00
> 5) Those 50,625 mail out 200 letters, and 759,375 people will send you $1.00
> At this point your name drops off the list, but so far you have received
> $813,615.00!!!!!
> 
>   It works every time, but how well depends on how many letters you send 
> out.  In the example above, you mail out 200 letters, if you mailed out  
> 500 letters, you would have received $2,006,917!!  Check the math yourself, 
> I want you to, but I guarantee it is correct!  With this kind of return, 
> you've got to try it. Try it once and you will do it again!!!
>   Why 6 names instead of 5?  As shown above in the math, if you stopped at 5
> names you would have received $54,240.00.  Why stop there?  With 6 names you
> could receive approximately 15 times that amount!  OVER $800,000.00!!!!!  
> And if you mailed out 500 letters, well you get the idea!
>
> **************************************************************************** 
> **************************  DETAILS  ***************************************
> ****************************************************************************
>  
> Excited?  Here is what you need to do.  Follow the simple instructions below
> exactly, and in about three months you will receive AMAZING amounts of
> money!!!
> 
> A)  Immediately send $1.00 to each of the six people on the list below. Wrap
> the dollar in a note saying "Please add me to your mailing list" and include
> your name and mailing address (Your phone number and email address are 
> optional):
> 
>  1)  Infocom
>      43 Warner Court
>      Glastonbury, CT 06033 USA
> 
> 2) Daniel Thompson
>     492 W. 600 N.
>     Spanish Fork, Ut 84406 USA
> 
> 3) Chris Briscoe
>     PO Box 901315
>     Sandy, Ut 84090  USA
> 
> 4) B. K. Enterprises
>      PO Box 455
>      Seffner, Fl. 33583-0455
> 
> 5) CO Careers
>     P.O. Box 470415
>     Aurora, CO  80047-0415
> 
>6) ASL Corp.
>    P.O. Box 721194
>    Orlando, FL 32872-1194
>
> B) REMOVE the name next to # 1 on the list.  Move the rest of the names up
> one position. Then place YOUR name in the # 6 spot.
> C) When you have completed the above instructions, you have an option of
> mailing your new letter out in three ways: 1) Through the U.S. Postal Service, 
> 2) Through direct e-mail  and/or  3) Through posting email news groups.  Each 
> of these methods is discussed further in the next section of this letter.
> (It's only a $6.00 investment, about the same price as a movie.  We're all
> here to help each other and you have to send money to make money)
>
> ************************************************************************** 
> *****************************  METHODS  **********************************
> **************************************************************************
> 
> Here's how you get this letter out to as many people as you can.  There are
> three different methods, please feel free to use one or ALL of them.  Any way
> you do it you stand to make a bundle!  The three different ways are listed
> below, they are;  News Groups, Post Office Mailing Lists and Bulk Email
> (Listed as A, B and C).
> 
> (A)  NEWS GROUPS:
> 
> FOR NETSCAPE USERS,
> 
> 1) Click on any newsgroup, like normal. Then click on "To News', which is in
> the top left corner of the newsgroup page. This will bring up a message box.
> 
> 2) Fill in the SUBJECT with a flashy title, like the one I used, something to
> catch the eye!!!
> 
> 3) Now go to the message part of the box and retype this letter exactly as it
> is here, with exception of your few changes. (remember to add your name to
> number 6 and move the rest up)
> 
> 4) When your done typing in the WHOLE letter, click on 'FILE' above the send
> button.
> Then, 'SAVE AS..' DO NOT SEND YOUR ARTICLE UNTIL YOU SAVE IT.  (so you
> don't have to type this 200 times :-)
> 
> 5) Now that you have saved the letter, go ahead and send your first copy!
> (click the 'SEND' button in the top left corner)
> 
> 6) This is where you post all 200! OK, go to ANY newsgroup article and click
> the 'TO NEWS' button again. Type in your flashy subject in the 'SUBJECT BOX',
> then go to the message and place your cursor here. Now click on 'ATTACHMENT" 
> which is right below the 'SUBJECT BOX'. Click on attach file then find your 
> letter wherever you saved it.
> Click once on your file then click 'OPEN' then click 'OK'. If you did this
> right, you should see your filename in the 'ATTACHMENT BOX' and it will be
> shaded.
>                       NOW POST AWAY!!
> 
> FOR INTERNET EXPLORER USERS:
> 
> 1)  It's just as easy, holding down the left mouse button, highlight this
> entire article, then press the 'CTRL' key and 'C' key at the same time 
> to copy this article. Then print the article for your records to have the 
> names of those you will be sending $1.00 to.
> 
> 2)  Go to the newsgroups and press 'POST AN ARTICLE' type in your flashy
> subject and click the large window below. Press 'CTRL' and 'V' and the
> article will appear in the message window. **BE SURE TO MAKE YOUR ADDRESS 
> CHANGES TO THE 6 NAMES.** Now re-highlight the article and re-copy it so you 
> have the changes.... then all you have to do for each newsgroup is 'CTRL' 
> and 'V' and press 'POST' . It's that easy!!            
> NOW POST AWAY!!
> 
> THAT'S IT! All you have to do is jump to different newsgroups and post away,
> after you get the hang of it, it will take about 30 seconds for each newsgroup!
> IF these instructions are too complex to follow try Fort's "Free Agent."  It
> is freeware for non-commercial use.  To download it, simply use a  search 
> utility and type Forte Free Agent.  You should be able to find it!  
> **REMEMBER, THE MORE NEWSGROUPS YOU POST IN, THE MORE MONEY
> YOU WILL MAKE!! BUT YOU HAVE TO POST A MINIMUM OF 200**
> 
> (B)  POST OFFICE MAILING LISTS
> 
> If you are going to use the traditional US Postal Service to do this program,
> you will want to order 200 names from a mailing list company.  Two that have
> been most effective for these list are:  (Be sure to ask for "Opportunity
> Seekers" labels)
> 
> S.E. Ring Mailing List ($39 / 300)
> P.O Box 15061
> Ft. Lauderdale, FL 33318 (954) 742-9519
> 
> Advon Distributors ($28 / 200)
> P.O. Box B-11
> Shelly, ID 83274 (800) 992-3866
> 
> If you want to do a large emailing, one source of email addresses (and they
> will also email them out for you) is: (Be sure to ask for "Opportunity
> Seekers" addresses, code AA) 
> 
> Blitz Publishing 
> PO Box 6061-130
> Sherman Oaks, CA 91413
> 
> When your mailing list arrives, place one label on a stamped envelope and
> drop them in the mail box (Be sure to send out 200). Within 90 days the 
> money will start pouring in your mailbox.
> *The mailing list companies listed above are in no way associated with this
> letter.  They are merely suggested resources for being successful*
> 
> (C)  BULK EMAIL
> 
> There are a few programs out there you can buy for a small price that will
> enable you to send mail out to thousands of people at the same time. 
> A couple examples of this software is listed below.  If you take this route
> to send out this letter, I beg you to run the mathematics of it above and
> see how much you could potentially pull in.  With this amount of mailing 
> and only a 1% return rate, which is unheard of, will send you into early
> retirement:
> 
> Ready Aim Fire @ "http://microsyssolutions.com"
> 
> and even better...
> 
> Extractor @ "http://extractor.com"
>  
> or...
> 
> Stealth @ "http://www.netpromos.com"
> 
> That's it! You will begin receiving money from around the world within 
> day's! You may eventually want to rent a P.O. Box due to the large amount
> of mail you receive. If you wish to stay anonymous, you can invent a 
> name to use, as long as the postman will deliver it. 
> **JUST MAKE SURE ALL THE ADDRESSES ARE CORRECT** 
> (The companies listed above are in no way associated with this email. 
> They are simply suggested resources so you can be successful. When you 
> are successful, we all are successful!)
> 
> ************************************************************************
> *****************************  SUMMARY  ******************************** 
> ************************************************************************
> 
> 
>   This is not a joke!  This is not a scam!  This is not a stupid chain
> letter!  This is a mailing opportunity that will bring you great rewards. 
> I beg you to call the Post Office and ask "Is it legal to send out a letter
> requesting that a person send one dollar to be on my mailing list, and then
> when I receive a dollar from that person, put them on it?"  You will see too!
> 
>   I called and check it out!  I want you to also!  Just think what your
> returns will be if you mail out 1000, 10,000 or 50,000 this way!  You don't 
> need to spend hardly any time at all to do this.  You have nothing to lose 
> and everything to gain.
> Don't delete this, just give it a try.  Just forward this letter, you don't
> need to alter this letter in any way except for the addresses and possibly
> the header.  I've done all the work for you in putting together the most
> comprehensive, informative, legal and user friendly letter EVER!  All you
> have to do is send it out with your name at the bottom of the list and sit
> back while the money comes to you.  Send out you $6 dollars today and get
> STARTED! GOOD LUCK FRIENDS!!!!!!!!!!!!!







From owner-freebsd-bugs  Thu Sep 18 22:23:53 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA12370
          for bugs-outgoing; Thu, 18 Sep 1997 22:23:53 -0700 (PDT)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA12358;
          Thu, 18 Sep 1997 22:23:48 -0700 (PDT)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
	by word.smith.net.au (8.8.7/8.8.5) with ESMTP id OAA00674;
	Fri, 19 Sep 1997 14:51:36 +0930 (CST)
Message-Id: <199709190521.OAA00674@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: "Andrew Atrens" 
cc: hackers@FreeBSD.ORG, gram@cdsec.com, phk@critter.freebsd.dk,
        freebsd-bugs@FreeBSD.ORG
Subject: Re: Bug in malloc/free 
In-reply-to: Your message of "18 Sep 1997 23:41:00 EDT."
             <199709190401.VAA06335@hub.freebsd.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 19 Sep 1997 14:51:34 +0930
From: Mike Smith 
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> ^Cddd in malloc(): warning: recursive call.
> Virtual memory exceeded in `new'
> 
> After reading Graham's thread I relinked it against libgnumalloc, and low
> and behold it works like a charm !
> 
> Does this point to an incompatibility problem between phkmalloc and g++
> compiled code ?

Something in malloc, somehow, is calling malloc() again, by the look of 
it. 

Does libg++ define any replacements for any of the standard C library 
functions?  I've been going through just about *everything* I can find
in case Poul has missed something; there is nothing in any of the 
malloc-called code (mostly just abort()) that is likely to be relevant 
to this.

mike



From owner-freebsd-bugs  Thu Sep 18 22:41:30 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA13732
          for bugs-outgoing; Thu, 18 Sep 1997 22:41:30 -0700 (PDT)
Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA13723;
          Thu, 18 Sep 1997 22:41:27 -0700 (PDT)
Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1])
	by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id HAA12159;
	Fri, 19 Sep 1997 07:40:56 +0200 (CEST)
To: "Andrew Atrens" 
cc: hackers@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) 
In-reply-to: Your message of "18 Sep 1997 17:59:00 EDT."
             <199709182204.AAA11611@critter.freebsd.dk> 
Date: Fri, 19 Sep 1997 07:40:55 +0200
Message-ID: <12157.874647655@critter.freebsd.dk>
From: Poul-Henning Kamp 
Sender: owner-freebsd-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <199709182204.AAA11611@critter.freebsd.dk>, "Andrew Atrens" writes:
>In message "Bug in malloc/free (was: Memory leak in getservbyXXX?)", phk@critt
>er.freebsd.dk writes:
>> 
>
>> This is about the only way you could get it to loop I think.  That means
>> that somebody wrote to memory malloc hadn't passed them (ie: your code).
>> 
>> This would indicate a bug of the class where memory is written to after
>> being free()'ed, a kind of bug which phkmalloc makes no attempt to catch.
>
>Why not have free() shred memory its releasing? Shredding memory with high
>values can often cause the offending code (which is still attempting
>to r/w this memory) to bus error.

options 'J' does that.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."

From owner-freebsd-bugs  Thu Sep 18 22:54:42 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA14597
          for bugs-outgoing; Thu, 18 Sep 1997 22:54:42 -0700 (PDT)
Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA14583;
          Thu, 18 Sep 1997 22:54:35 -0700 (PDT)
Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1])
	by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id HAA12449;
	Fri, 19 Sep 1997 07:53:53 +0200 (CEST)
To: Peter Wemm 
cc: "Andrew Atrens" , hackers@freebsd.org, gram@cdsec.com,
        freebsd-bugs@freebsd.org
Subject: Re: Bug in malloc/free 
In-reply-to: Your message of "Fri, 19 Sep 1997 12:59:33 +0800."
             <199709190459.MAA07378@spinner.dialix.com.au> 
Date: Fri, 19 Sep 1997 07:53:53 +0200
Message-ID: <12447.874648433@critter.freebsd.dk>
From: Poul-Henning Kamp 
Sender: owner-freebsd-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <199709190459.MAA07378@spinner.dialix.com.au>, Peter Wemm writes:

>> ^Cddd in malloc(): warning: recursive call.
>> Virtual memory exceeded in `new'
>> 
>> After reading Graham's thread I relinked it against libgnumalloc, and low
>> and behold it works like a charm !
>> 
>> Does this point to an incompatibility problem between phkmalloc and g++
>> compiled code ?
>
>Hmm, this particular thing sounds like a signal recursion problem..
>
>If a malloc() instance is interrupted in the middle of execution and a
>signal is taken, and that signal again calls malloc (eg: via new), the
>state of the malloc arena is 'indeterminate'.
>
>Perhaps malloc is doing something that can cause a signal?  or perhaps ddd
>has a fast timer that calls malloc (or new) that can interrupt other malloc
>calls?  Perhaps malloc() could/should block SIGALRM while executing it's 
>non-reentrant parts?

The solution here would be to block signals around malloc/free.  This would
be rather expensive to do, performance wise, and thus have not been done.

It is the responsibility of the application code anyway...

If somebody writes the patch to malloc to do this under a option, I'll
review and commit, but I don't have the time to do it myself right now.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."

From owner-freebsd-bugs  Thu Sep 18 23:06:58 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA15436
          for bugs-outgoing; Thu, 18 Sep 1997 23:06:58 -0700 (PDT)
Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA15409;
          Thu, 18 Sep 1997 23:06:49 -0700 (PDT)
Received: (from jmg@localhost)
          by hydrogen.nike.efn.org (8.8.7/8.8.7) id XAA01685;
          Thu, 18 Sep 1997 23:06:17 -0700 (PDT)
Message-ID: <19970918230616.02227@hydrogen.nike.efn.org>
Date: Thu, 18 Sep 1997 23:06:16 -0700
From: John-Mark Gurney 
To: Peter Wemm 
Cc: Andrew Atrens , hackers@FreeBSD.ORG, gram@cdsec.com,
        phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG
Subject: Re: Bug in malloc/free
References: <199709190401.VAA06335@hub.freebsd.org> <199709190459.MAA07378@spinner.dialix.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199709190459.MAA07378@spinner.dialix.com.au>; from Peter Wemm on Fri, Sep 19, 1997 at 12:59:33PM +0800
Reply-To: John-Mark Gurney 
Organization: Cu Networking
X-Operating-System: FreeBSD 2.2.1-RELEASE i386
X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31  96 7A 22 B3 D8 56 36 F4
X-Files: The truth is out there
X-URL: http://resnet.uoregon.edu/~gurney_j/
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Peter Wemm scribbled this message on Sep 19:
> "Andrew Atrens" wrote:
> > 
> > Hi Folks,
> > 
> > By coincidence I *may* have seen a bug similar to Graham's last night...
> > I'm using 3.0 current ( circa. Aug 08 ).
> > 
> > I built `ddd-2.1.1.tar.gz', found in /pub/FreeBSD/distfiles which is a
> > largely C++ interface for gdb and others. Unfortunately, when I tried to
> > run it, it gobbled memory until it choked. I tried a second time, this
> > time killing it with CTRL-C and observed:
> > 
> > ^Cddd in malloc(): warning: recursive call.
> > Virtual memory exceeded in `new'
> > 
> > After reading Graham's thread I relinked it against libgnumalloc, and low
> > and behold it works like a charm !
> > 
> > Does this point to an incompatibility problem between phkmalloc and g++
> > compiled code ?
> 
> Hmm, this particular thing sounds like a signal recursion problem..
> 
> If a malloc() instance is interrupted in the middle of execution and a
> signal is taken, and that signal again calls malloc (eg: via new), the
> state of the malloc arena is 'indeterminate'.
> 
> Perhaps malloc is doing something that can cause a signal?  or perhaps ddd
> has a fast timer that calls malloc (or new) that can interrupt other malloc
> calls?  Perhaps malloc() could/should block SIGALRM while executing it's 
> non-reentrant parts?

I thought that you weren't suppose to call routines like these from
signal handlers...  and from the APUE (page278): "Most functions that
are not in Figure 10.3 [Reentrant functions that may be called from a
signal handler] are missing because (a) they are known to use static
data structures, (b) they call malloc or free, or (c) they are part of
the standard I/O library."  so any program that makes calles to these
functions are VERY broken...

-- 
  John-Mark Gurney                          Modem/FAX: +1 541 683 6954
  Cu Networking

  Live in Peace, destroy Micro$oft, support free software, run FreeBSD

From owner-freebsd-bugs  Thu Sep 18 23:22:43 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA16408
          for bugs-outgoing; Thu, 18 Sep 1997 23:22:43 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA16394;
          Thu, 18 Sep 1997 23:22:36 -0700 (PDT)
From: Poul-Henning Kamp 
Received: (from phk@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id XAA26373;
	Thu, 18 Sep 1997 23:18:38 -0700 (PDT)
Date: Thu, 18 Sep 1997 23:18:38 -0700 (PDT)
Message-Id: <199709190618.XAA26373@freefall.freebsd.org>
To: mharo@infolane.com, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: kern/3128
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: Can't Install FreeBSD 2.2.1

State-Changed-From-To: open-closed
State-Changed-By: phk
State-Changed-When: Thu Sep 18 23:18:25 PDT 1997
State-Changed-Why: 

timedout.

From owner-freebsd-bugs  Thu Sep 18 23:23:42 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA16504
          for bugs-outgoing; Thu, 18 Sep 1997 23:23:42 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA16494;
          Thu, 18 Sep 1997 23:23:38 -0700 (PDT)
From: Poul-Henning Kamp 
Received: (from phk@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id XAA26456;
	Thu, 18 Sep 1997 23:19:39 -0700 (PDT)
Date: Thu, 18 Sep 1997 23:19:39 -0700 (PDT)
Message-Id: <199709190619.XAA26456@freefall.freebsd.org>
To: mshine@mindspring.com, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: bin/3374
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: Cannot Install FreeBSD 2.2.1 - installation hangs when copying bin to root directory

State-Changed-From-To: open-closed
State-Changed-By: phk
State-Changed-When: Thu Sep 18 23:19:26 PDT 1997
State-Changed-Why: 

timed out.

From owner-freebsd-bugs  Thu Sep 18 23:25:37 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA16660
          for bugs-outgoing; Thu, 18 Sep 1997 23:25:37 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA16654;
          Thu, 18 Sep 1997 23:25:30 -0700 (PDT)
From: Poul-Henning Kamp 
Received: (from phk@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id XAA26579;
	Thu, 18 Sep 1997 23:21:32 -0700 (PDT)
Date: Thu, 18 Sep 1997 23:21:32 -0700 (PDT)
Message-Id: <199709190621.XAA26579@freefall.freebsd.org>
To: phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, sos@FreeBSD.ORG
Subject: Re: kern/3949
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: The WD controller probe can fail when it shouldn't (and a plausible fix)

Responsible-Changed-From-To: freebsd-bugs->sos
Responsible-Changed-By: phk
Responsible-Changed-When: Thu Sep 18 23:21:07 PDT 1997
Responsible-Changed-Why: 
Soren, den kigger du lige paa ?

From owner-freebsd-bugs  Thu Sep 18 23:28:20 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA16882
          for bugs-outgoing; Thu, 18 Sep 1997 23:28:20 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA16868;
          Thu, 18 Sep 1997 23:28:12 -0700 (PDT)
From: Poul-Henning Kamp 
Received: (from phk@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id XAA26727;
	Thu, 18 Sep 1997 23:24:13 -0700 (PDT)
Date: Thu, 18 Sep 1997 23:24:13 -0700 (PDT)
Message-Id: <199709190624.XAA26727@freefall.freebsd.org>
To: stevedav@netcom.com, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: i386/4315
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: sio0 and sio1 serial ports fail to probe

State-Changed-From-To: open-closed
State-Changed-By: phk
State-Changed-When: Thu Sep 18 23:22:22 PDT 1997
State-Changed-Why: 

Not much we can do.

Try boot -cv
then set flags to 0x80 on the two sio ports.  This will give more verbose
information.  Then check the sources and see what you find.

Alternatively, you may have a PnP challenged motherboard, is there a
BIOS setting for  "PnP OS" / "MSDOS" or similar ?  if so set it to MSDOS.

From owner-freebsd-bugs  Thu Sep 18 23:28:36 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA16928
          for bugs-outgoing; Thu, 18 Sep 1997 23:28:36 -0700 (PDT)
Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA16910;
          Thu, 18 Sep 1997 23:28:30 -0700 (PDT)
Received: (from grog@localhost)
	by freebie.lemis.com (8.8.7/8.8.5) id PAA03644;
	Fri, 19 Sep 1997 15:58:14 +0930 (CST)
Message-ID: <19970919155813.53901@lemis.com>
Date: Fri, 19 Sep 1997 15:58:13 +0930
From: Greg Lehey 
To: Peter Wemm 
Cc: Andrew Atrens , hackers@FreeBSD.ORG, gram@cdsec.com,
        phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG
Subject: Re: Bug in malloc/free
References: <199709190401.VAA06335@hub.freebsd.org> <199709190459.MAA07378@spinner.dialix.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81e
In-Reply-To: <199709190459.MAA07378@spinner.dialix.com.au>; from Peter Wemm on Fri, Sep 19, 1997 at 12:59:33PM +0800
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8250
Fax: +61-8-8388-8250
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Fight-Spam-Now: http://www.cauce.org
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Fri, Sep 19, 1997 at 12:59:33PM +0800, Peter Wemm wrote:
> "Andrew Atrens" wrote:
>>
>> Hi Folks,
>>
>> By coincidence I *may* have seen a bug similar to Graham's last night...
>> I'm using 3.0 current ( circa. Aug 08 ).
>>
>> I built `ddd-2.1.1.tar.gz', found in /pub/FreeBSD/distfiles which is a
>> largely C++ interface for gdb and others. Unfortunately, when I tried to
>> run it, it gobbled memory until it choked. I tried a second time, this
>> time killing it with CTRL-C and observed:
>>
>> ^Cddd in malloc(): warning: recursive call.
>> Virtual memory exceeded in `new'
>>
>> After reading Graham's thread I relinked it against libgnumalloc, and low
>> and behold it works like a charm !
>>
>> Does this point to an incompatibility problem between phkmalloc and g++
>> compiled code ?
>
> Hmm, this particular thing sounds like a signal recursion problem..
>
> If a malloc() instance is interrupted in the middle of execution and a
> signal is taken, and that signal again calls malloc (eg: via new), the
> state of the malloc arena is 'indeterminate'.

Even more insidious are library routines which could call malloc().
To quote PUS:

  By definition, signals interrupt the normal flow of program
  execution.  This can cause problems if they call a function that has
  already been invoked, and which has saved some local state.  The
  function needs to be written specially to avoid such problems--it
  should block either all signals during execution, or, preferably, it
  should be written reentrantly.  Either solution is difficult, and
  typically system libraries do not support this kind of reentrancy.
  On the other hand, there's not much you can do without calling some
  library routine.  POSIX.1 defines "safe" routines that you can call
  from a signal handler.  They are:

  _exit access alarm cfgetispeed cfgetospeed cfsetispeed cfsetospeed
  chdir chmod chown close creat dup dup2 execle execve fcntl fork
  fstat getegid geteuid getgid getgroups getpgrp getpid getppid getuid
  kill link lseek mkdir mkfifo open pathconf pause pipe read rename
  rmdir setgid setpgid setsid setuid sigaction sigaddset sigdelset
  sigemptyset sigfillset sigismember sigpending sigprocmask sigsuspend
  sleep stat sysconf tcdrain tcflow tcflush tcgetattr tcgetpgrp
  tcsendbreak tcsetattr tcsetpgrp time times umask uname unlink utime
  wait waitpid write

  In addition, System V.4 allows abort, exit, longjmp, and signal.

Should we produce some such guidelines?

> Perhaps malloc is doing something that can cause a signal?  or perhaps ddd
> has a fast timer that calls malloc (or new) that can interrupt other malloc
> calls?  Perhaps malloc() could/should block SIGALRM while executing it's
> non-reentrant parts?

Greg

From owner-freebsd-bugs  Thu Sep 18 23:30:22 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA17087
          for bugs-outgoing; Thu, 18 Sep 1997 23:30:22 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA17068;
          Thu, 18 Sep 1997 23:30:08 -0700 (PDT)
From: Poul-Henning Kamp 
Received: (from phk@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id XAA26843;
	Thu, 18 Sep 1997 23:26:09 -0700 (PDT)
Date: Thu, 18 Sep 1997 23:26:09 -0700 (PDT)
Message-Id: <199709190626.XAA26843@freefall.freebsd.org>
To: uhclem%nemesis@fw.ast.com, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: bin/392
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: Simultaneous cp and ls of files on dos f/s hangs procs [FDIV025]

State-Changed-From-To: analyzed-closed
State-Changed-By: phk
State-Changed-When: Thu Sep 18 23:25:43 PDT 1997
State-Changed-Why: 

Significant work has happened since.  Please resubmit if still a problem.

From owner-freebsd-bugs  Thu Sep 18 23:31:09 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA17169
          for bugs-outgoing; Thu, 18 Sep 1997 23:31:09 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA17162;
          Thu, 18 Sep 1997 23:31:04 -0700 (PDT)
From: Poul-Henning Kamp 
Received: (from phk@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id XAA26951;
	Thu, 18 Sep 1997 23:27:06 -0700 (PDT)
Date: Thu, 18 Sep 1997 23:27:06 -0700 (PDT)
Message-Id: <199709190627.XAA26951@freefall.freebsd.org>
To: uhclem%nemesis@fw.ast.com, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: kern/750
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: cd9660 confused by not-ready or I/O errors	FDIV030

State-Changed-From-To: feedback-closed
State-Changed-By: phk
State-Changed-When: Thu Sep 18 23:26:52 PDT 1997
State-Changed-Why: 

timed out.

From owner-freebsd-bugs  Thu Sep 18 23:39:41 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA17911
          for bugs-outgoing; Thu, 18 Sep 1997 23:39:41 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA17903;
          Thu, 18 Sep 1997 23:39:38 -0700 (PDT)
From: Poul-Henning Kamp 
Received: (from phk@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id XAA27170;
	Thu, 18 Sep 1997 23:35:39 -0700 (PDT)
Date: Thu, 18 Sep 1997 23:35:39 -0700 (PDT)
Message-Id: <199709190635.XAA27170@freefall.freebsd.org>
To: uhclem@nemesis.lonestar.org, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: bin/389
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: Simultaneous creation/deletion of dirs corrupts filesystem [FDIV024]

State-Changed-From-To: feedback-closed
State-Changed-By: phk
State-Changed-When: Thu Sep 18 23:35:24 PDT 1997
State-Changed-Why: 
timed out

From owner-freebsd-bugs  Thu Sep 18 23:40:20 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA18026
          for bugs-outgoing; Thu, 18 Sep 1997 23:40:20 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18009;
          Thu, 18 Sep 1997 23:40:15 -0700 (PDT)
From: Poul-Henning Kamp 
Received: (from phk@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id XAA27251;
	Thu, 18 Sep 1997 23:36:16 -0700 (PDT)
Date: Thu, 18 Sep 1997 23:36:16 -0700 (PDT)
Message-Id: <199709190636.XAA27251@freefall.freebsd.org>
To: paul@lambda.demon.co.uk, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: kern/587
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: if_le hangs on OACTIVE with 2k buffer

State-Changed-From-To: feedback-closed
State-Changed-By: phk
State-Changed-When: Thu Sep 18 23:36:02 PDT 1997
State-Changed-Why: 

timed out.

From owner-freebsd-bugs  Thu Sep 18 23:40:51 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA18073
          for bugs-outgoing; Thu, 18 Sep 1997 23:40:51 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18064;
          Thu, 18 Sep 1997 23:40:44 -0700 (PDT)
From: Poul-Henning Kamp 
Received: (from phk@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id XAA27333;
	Thu, 18 Sep 1997 23:36:46 -0700 (PDT)
Date: Thu, 18 Sep 1997 23:36:46 -0700 (PDT)
Message-Id: <199709190636.XAA27333@freefall.freebsd.org>
To: mi@ALDAN.algebra.com, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: bin/1050
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: [floppy] Process (zip) hangs (unkillable) after floppy error

State-Changed-From-To: feedback-closed
State-Changed-By: phk
State-Changed-When: Thu Sep 18 23:36:31 PDT 1997
State-Changed-Why: 

timed out

From owner-freebsd-bugs  Thu Sep 18 23:41:31 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA18136
          for bugs-outgoing; Thu, 18 Sep 1997 23:41:31 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18129;
          Thu, 18 Sep 1997 23:41:27 -0700 (PDT)
From: Poul-Henning Kamp 
Received: (from phk@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id XAA27420;
	Thu, 18 Sep 1997 23:37:29 -0700 (PDT)
Date: Thu, 18 Sep 1997 23:37:29 -0700 (PDT)
Message-Id: <199709190637.XAA27420@freefall.freebsd.org>
To: enami@ba2.so-net.or.jp, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: kern/1026
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: deadlocks if parent vfork and child has cntrl terminal and write through it and exit.

State-Changed-From-To: feedback-closed
State-Changed-By: phk
State-Changed-When: Thu Sep 18 23:37:15 PDT 1997
State-Changed-Why: 
timed out

From owner-freebsd-bugs  Thu Sep 18 23:42:04 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA18174
          for bugs-outgoing; Thu, 18 Sep 1997 23:42:04 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18168;
          Thu, 18 Sep 1997 23:42:00 -0700 (PDT)
From: Poul-Henning Kamp 
Received: (from phk@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id XAA27507;
	Thu, 18 Sep 1997 23:38:02 -0700 (PDT)
Date: Thu, 18 Sep 1997 23:38:02 -0700 (PDT)
Message-Id: <199709190638.XAA27507@freefall.freebsd.org>
To: mi@ALDAN.algebra.com, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: bin/1029
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: cd behaves erraticly if cwd is a mount-point, which was just mounted

State-Changed-From-To: feedback-closed
State-Changed-By: phk
State-Changed-When: Thu Sep 18 23:37:51 PDT 1997
State-Changed-Why: 
 timed out

From owner-freebsd-bugs  Thu Sep 18 23:44:36 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA18353
          for bugs-outgoing; Thu, 18 Sep 1997 23:44:36 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18342;
          Thu, 18 Sep 1997 23:44:29 -0700 (PDT)
From: Poul-Henning Kamp 
Received: (from phk@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id XAA27616;
	Thu, 18 Sep 1997 23:40:30 -0700 (PDT)
Date: Thu, 18 Sep 1997 23:40:30 -0700 (PDT)
Message-Id: <199709190640.XAA27616@freefall.freebsd.org>
To: uhclem@nemesis.lonestar.org, phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: bin/1037
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: 2.x telnetd handles CTRL-M differently than other ttys		FDIV044

State-Changed-From-To: feedback-closed
State-Changed-By: phk
State-Changed-When: Thu Sep 18 23:40:10 PDT 1997
State-Changed-Why: 

timed out.

From owner-freebsd-bugs  Thu Sep 18 23:47:43 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA18507
          for bugs-outgoing; Thu, 18 Sep 1997 23:47:43 -0700 (PDT)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18495;
          Thu, 18 Sep 1997 23:47:37 -0700 (PDT)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id XAA20189;
	Thu, 18 Sep 1997 23:34:20 -0700 (PDT)
Received: from current1.whistle.com(207.76.205.22)
 via SMTP by alpo.whistle.com, id smtpd020186; Fri Sep 19 06:34:18 1997
Date: Thu, 18 Sep 1997 23:33:34 -0700 (PDT)
From: Julian Elischer 
To: Mike Smith 
cc: Andrew Atrens , hackers@FreeBSD.ORG, gram@cdsec.com,
        phk@critter.freebsd.dk, freebsd-bugs@FreeBSD.ORG
Subject: Re: Bug in malloc/free 
In-Reply-To: <199709190521.OAA00674@word.smith.net.au>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


probably a printf or other stdio function

On Fri, 19 Sep 1997, Mike Smith wrote:

> > 
> > ^Cddd in malloc(): warning: recursive call.
> > Virtual memory exceeded in `new'
> > 
> > After reading Graham's thread I relinked it against libgnumalloc, and low
> > and behold it works like a charm !
> > 
> > Does this point to an incompatibility problem between phkmalloc and g++
> > compiled code ?
> 
> Something in malloc, somehow, is calling malloc() again, by the look of 
> it. 
> 
> Does libg++ define any replacements for any of the standard C library 
> functions?  I've been going through just about *everything* I can find
> in case Poul has missed something; there is nothing in any of the 
> malloc-called code (mostly just abort()) that is likely to be relevant 
> to this.
> 
> mike
> 
> 
> 


From owner-freebsd-bugs  Thu Sep 18 23:54:55 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA19133
          for bugs-outgoing; Thu, 18 Sep 1997 23:54:55 -0700 (PDT)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA19115;
          Thu, 18 Sep 1997 23:54:42 -0700 (PDT)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
	by word.smith.net.au (8.8.7/8.8.5) with ESMTP id QAA01100;
	Fri, 19 Sep 1997 16:22:04 +0930 (CST)
Message-Id: <199709190652.QAA01100@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Julian Elischer 
cc: Mike Smith , Andrew Atrens ,
        hackers@FreeBSD.ORG, gram@cdsec.com, phk@critter.freebsd.dk,
        freebsd-bugs@FreeBSD.ORG
Subject: Re: Bug in malloc/free 
In-reply-to: Your message of "Thu, 18 Sep 1997 23:33:34 MST."
              
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 19 Sep 1997 16:22:04 +0930
From: Mike Smith 
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> probably a printf or other stdio function

I *know* this. 8) I'm just trying to find the sucker.  The 'ddd' example 
looked like it was spinning in abort(), which doesn't look like it will
actually come back and call malloc() again.  In olden days, 
if MALLOC_STATS was defined when malloc() was built, the stats dump 
used fprintf(), but this is not the case with 3.x.

mike


From owner-freebsd-bugs  Fri Sep 19 00:24:44 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id AAA20927
          for bugs-outgoing; Fri, 19 Sep 1997 00:24:44 -0700 (PDT)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA20916
          for ; Fri, 19 Sep 1997 00:24:38 -0700 (PDT)
Received: (from root@localhost)
	by dyson.iquest.net (8.8.6/8.8.5) id CAA01122;
	Fri, 19 Sep 1997 02:23:20 -0500 (EST)
From: "John S. Dyson" 
Message-Id: <199709190723.CAA01122@dyson.iquest.net>
Subject: Re: Mem Leak ??
In-Reply-To: <199709190511.WAA13160@slip129-37-223-142.ca.us.ibm.net> from "Joseph I. Davida" at "Sep 18, 97 10:11:20 pm"
To: jd@slip129-37-223-142.ca.us.ibm.net (Joseph I. Davida)
Date: Fri, 19 Sep 1997 02:23:20 -0500 (EST)
Cc: bugs@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Joseph I. Davida said:
> 
> 	Running FreeBSD Snap 3.0
> 	System is Pentium P5/200MHz, 64 Meg Ram, 512K Cache,
> 	96 Meg Swap space.
> 
> 	X is up and running with the following X apps running:
> 	tvtwm window manager
> 	xbiff
> 	xclock
> 	icon manager
> 	virtual desktop
> 	Xsysinfo
> 	vmstat
> 
> 	When I try to run netscape (version 4.3b8), I get a message
> 	from netscape that I am out of memory. SO I looked at what
> 	vmstat was saying:
> 
>  procs      memory     page                    disks      faults      cpu
>  r b w     avm   fre  flt  re  pi  po  fr  sr s0 c0 w0   in   sy  cs us sy id
>  1 0 0 4033532 21008   13   0   0   0  14   0  1  0  0  166  172  30  1  0 99
>  0 0 0 4029456 21008    2   0   0   0   0   0  0  0  0  113   76   9  0  0 100
>  0 0 0 4029812 21008   30   0   0   0  33   0  1  0  0  165 1529  48  3  1 96
>  0 0 0 4029812 21008   13   0   0   0  14   0  1  0  0  109   74  10  0  0 100
>  0 0 0 4029812 21008    2   0   0   0   0   0  0  0  0  179  372  55  2  1 97
>  0 0 0 4029812 21008   13   0   0   0  14   0  1  0  0  242 50055  96 16 40 44
>  0 0 0 4029812 21008   18   0   0   0  19   0  0  0  0  139 1467  37  3  1 96
> 
> 
FreeBSD's concept of free memory is orthogonal to what most people consider
free memory to be.  The only way to determine memory capacity on a FreeBSD
box, is to consider paging rates and free swap space.

John

From owner-freebsd-bugs  Fri Sep 19 01:35:35 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA25202
          for bugs-outgoing; Fri, 19 Sep 1997 01:35:35 -0700 (PDT)
Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA25192;
          Fri, 19 Sep 1997 01:35:30 -0700 (PDT)
Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1])
	by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id KAA12845;
	Fri, 19 Sep 1997 10:34:28 +0200 (CEST)
To: Mike Smith 
cc: Julian Elischer , Andrew Atrens ,
        hackers@freebsd.org, gram@cdsec.com, freebsd-bugs@freebsd.org
Subject: Re: Bug in malloc/free 
In-reply-to: Your message of "Fri, 19 Sep 1997 16:22:04 +0930."
             <199709190652.QAA01100@word.smith.net.au> 
Date: Fri, 19 Sep 1997 10:34:28 +0200
Message-ID: <12843.874658068@critter.freebsd.dk>
From: Poul-Henning Kamp 
Sender: owner-freebsd-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <199709190652.QAA01100@word.smith.net.au>, Mike Smith writes:
>> 
>> probably a printf or other stdio function
>
>I *know* this. 8) I'm just trying to find the sucker.  The 'ddd' example 
>looked like it was spinning in abort(), which doesn't look like it will
>actually come back and call malloc() again.  In olden days, 
>if MALLOC_STATS was defined when malloc() was built, the stats dump 
>used fprintf(), but this is not the case with 3.x.

Some time ago abort() was changed to that it would call __flush(),
because some standard said so.  I still think this is unwise.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."

From owner-freebsd-bugs  Fri Sep 19 01:45:44 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA25901
          for bugs-outgoing; Fri, 19 Sep 1997 01:45:44 -0700 (PDT)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA25891;
          Fri, 19 Sep 1997 01:45:38 -0700 (PDT)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
	by word.smith.net.au (8.8.7/8.8.5) with ESMTP id SAA02922;
	Fri, 19 Sep 1997 18:10:31 +0930 (CST)
Message-Id: <199709190840.SAA02922@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Poul-Henning Kamp 
cc: Mike Smith , Julian Elischer ,
        Andrew Atrens , hackers@freebsd.org, gram@cdsec.com,
        freebsd-bugs@freebsd.org
Subject: Re: Bug in malloc/free 
In-reply-to: Your message of "Fri, 19 Sep 1997 10:34:28 +0200."
             <12843.874658068@critter.freebsd.dk> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 19 Sep 1997 18:10:29 +0930
From: Mike Smith 
Sender: owner-freebsd-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> In message <199709190652.QAA01100@word.smith.net.au>, Mike Smith writes:
> >> 
> >> probably a printf or other stdio function
> >
> >I *know* this. 8) I'm just trying to find the sucker.  The 'ddd' example 
> >looked like it was spinning in abort(), which doesn't look like it will
> >actually come back and call malloc() again.  In olden days, 
> >if MALLOC_STATS was defined when malloc() was built, the stats dump 
> >used fprintf(), but this is not the case with 3.x.
> 
> Some time ago abort() was changed to that it would call __flush(),
> because some standard said so.  I still think this is unwise.

This is only an issue if the user supplies a custom _write 
handler for a FILE.  The standard handler doesn't appear to have any 
opportunity for dynamic allocation.

mike



From owner-freebsd-bugs  Fri Sep 19 02:14:41 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA27446
          for bugs-outgoing; Fri, 19 Sep 1997 02:14:41 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA27425;
          Fri, 19 Sep 1997 02:14:33 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id TAA09952; Fri, 19 Sep 1997 19:09:04 +1000
Date: Fri, 19 Sep 1997 19:09:04 +1000
From: Bruce Evans 
Message-Id: <199709190909.TAA09952@godzilla.zeta.org.au>
To: grog@lemis.com, peter@spinner.dialix.com.au
Subject: Re: Bug in malloc/free
Cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com,
        hackers@FreeBSD.ORG, phk@critter.freebsd.dk
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>  On the other hand, there's not much you can do without calling some
>  library routine.  POSIX.1 defines "safe" routines that you can call
>  from a signal handler.  They are:
>
>  _exit access alarm cfgetispeed cfgetospeed cfsetispeed cfsetospeed
>  chdir chmod chown close creat dup dup2 execle execve fcntl fork
>  fstat getegid geteuid getgid getgroups getpgrp getpid getppid getuid
>  kill link lseek mkdir mkfifo open pathconf pause pipe read rename
>  rmdir setgid setpgid setsid setuid sigaction sigaddset sigdelset
>  sigemptyset sigfillset sigismember sigpending sigprocmask sigsuspend
>  sleep stat sysconf tcdrain tcflow tcflush tcgetattr tcgetpgrp
>  tcsendbreak tcsetattr tcsetpgrp time times umask uname unlink utime
>  wait waitpid write
>
>  In addition, System V.4 allows abort, exit, longjmp, and signal.
>
>Should we produce some such guidelines?

We claim to be sort of POSIX conformant.  Perhaps this is enough.  We
aren't actually POSIX conformant.  All the above "safe" routines may
clobber the global `errno'.

STDC only allows operations on auto variables and assignment to static
variables of type sig_atomic_t.  We aren't STDC conformant either.
Operations on auto floating point variables may corrupt the floating
point state.  This isn't a problem in practice, since nothing useful
can be done using only auto floating point variables.

Bruce

From owner-freebsd-bugs  Fri Sep 19 02:51:54 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA29639
          for bugs-outgoing; Fri, 19 Sep 1997 02:51:54 -0700 (PDT)
Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA29614;
          Fri, 19 Sep 1997 02:51:44 -0700 (PDT)
Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1])
	by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id LAA13120;
	Fri, 19 Sep 1997 11:50:34 +0200 (CEST)
To: Bruce Evans 
cc: grog@lemis.com, peter@spinner.dialix.com.au, atrens@nortel.ca,
        freebsd-bugs@freebsd.org, gram@cdsec.com, hackers@freebsd.org
Subject: Re: Bug in malloc/free 
In-reply-to: Your message of "Fri, 19 Sep 1997 19:09:04 +1000."
             <199709190909.TAA09952@godzilla.zeta.org.au> 
Date: Fri, 19 Sep 1997 11:50:34 +0200
Message-ID: <13118.874662634@critter.freebsd.dk>
From: Poul-Henning Kamp 
Sender: owner-freebsd-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <199709190909.TAA09952@godzilla.zeta.org.au>, Bruce Evans writes:
>>  On the other hand, there's not much you can do without calling some
>>  library routine.  POSIX.1 defines "safe" routines that you can call
>>  from a signal handler.  They are:
>>
>>  _exit access alarm cfgetispeed cfgetospeed cfsetispeed cfsetospeed
>>  chdir chmod chown close creat dup dup2 execle execve fcntl fork
>>  fstat getegid geteuid getgid getgroups getpgrp getpid getppid getuid
>>  kill link lseek mkdir mkfifo open pathconf pause pipe read rename
>>  rmdir setgid setpgid setsid setuid sigaction sigaddset sigdelset
>>  sigemptyset sigfillset sigismember sigpending sigprocmask sigsuspend
>>  sleep stat sysconf tcdrain tcflow tcflush tcgetattr tcgetpgrp
>>  tcsendbreak tcsetattr tcsetpgrp time times umask uname unlink utime
>>  wait waitpid write
>>
>>  In addition, System V.4 allows abort, exit, longjmp, and signal.
>>
>>Should we produce some such guidelines?
>
>We claim to be sort of POSIX conformant.  Perhaps this is enough.  We
>aren't actually POSIX conformant.  All the above "safe" routines may
>clobber the global `errno'.
>
>STDC only allows operations on auto variables and assignment to static
>variables of type sig_atomic_t.  We aren't STDC conformant either.
>Operations on auto floating point variables may corrupt the floating
>point state.  This isn't a problem in practice, since nothing useful
>can be done using only auto floating point variables.

You could calculate pi... :-)

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."

From owner-freebsd-bugs  Fri Sep 19 02:57:19 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA00318
          for bugs-outgoing; Fri, 19 Sep 1997 02:57:19 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA00280;
          Fri, 19 Sep 1997 02:57:10 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id TAA11275; Fri, 19 Sep 1997 19:54:38 +1000
Date: Fri, 19 Sep 1997 19:54:38 +1000
From: Bruce Evans 
Message-Id: <199709190954.TAA11275@godzilla.zeta.org.au>
To: mike@smith.net.au, phk@critter.freebsd.dk
Subject: Re: Bug in malloc/free
Cc: atrens@nortel.ca, freebsd-bugs@freebsd.org, gram@cdsec.com,
        hackers@freebsd.org, julian@whistle.com
Sender: owner-freebsd-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>>> probably a printf or other stdio function
>>
>>I *know* this. 8) I'm just trying to find the sucker.  The 'ddd' example 
>>looked like it was spinning in abort(), which doesn't look like it will
>>actually come back and call malloc() again.  In olden days, 
>...
>Some time ago abort() was changed to that it would call __flush(),
>because some standard said so.  I still think this is unwise.

Standard C says that whether streams are flushed by abort() is
implementation-defined.  POSIX says that abort() shall have the effects
of fclose() if abort() causes process termination, but shall have no
effects otherwise.  Our implementation doesn't quite confirm to this,
since the effects of flushing can be detected:
1. setvbuf() to unbuffered and size 2, then putc() 1 byte, then _exit().
   I think it is guaranteed that 0 bytes are written.
2. As in (1), but set up a SIGABRT handler so that abort() doesn't cause
   termination, and call abort() before _exit().

Flushing in abort() should be safe because abort() is not among the
functions that are safe to call from a signal handler :-).

Bruce

From owner-freebsd-bugs  Fri Sep 19 03:03:55 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id DAA00803
          for bugs-outgoing; Fri, 19 Sep 1997 03:03:55 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA00798;
          Fri, 19 Sep 1997 03:03:49 -0700 (PDT)
From: Brian Somers 
Received: (from brian@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id CAA29482;
	Fri, 19 Sep 1997 02:59:50 -0700 (PDT)
Date: Fri, 19 Sep 1997 02:59:50 -0700 (PDT)
Message-Id: <199709190959.CAA29482@freefall.freebsd.org>
To: dburr@POBoxes.com, brian@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG,
        brian@FreeBSD.ORG
Subject: Re: bin/4575
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: user-ppp (iij-ppp) should use /etc/ppp/ip-{up,down}

State-Changed-From-To: open-closed
State-Changed-By: brian
State-Changed-When: Fri Sep 19 02:56:20 PDT 1997
State-Changed-Why: 
This is a non-issue.  For running ip-up, do the following in
ppp.linkup:

MYADDR:
 !bg /etc/ppp/ip-up MYADDR HISADDR INTERFACE

(I don't know what order you want the args)
Similarly in ppp.linkdown for running ip-down.


Responsible-Changed-From-To: freebsd-bugs->brian
Responsible-Changed-By: brian
Responsible-Changed-When: Fri Sep 19 02:56:20 PDT 1997
Responsible-Changed-Why: 
Ppp's mine

From owner-freebsd-bugs  Fri Sep 19 03:30:07 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id DAA02002
          for bugs-outgoing; Fri, 19 Sep 1997 03:30:07 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA01952;
          Fri, 19 Sep 1997 03:29:56 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id UAA12065; Fri, 19 Sep 1997 20:24:02 +1000
Date: Fri, 19 Sep 1997 20:24:02 +1000
From: Bruce Evans 
Message-Id: <199709191024.UAA12065@godzilla.zeta.org.au>
To: bde@zeta.org.au, phk@critter.freebsd.dk
Subject: Re: Bug in malloc/free
Cc: atrens@nortel.ca, freebsd-bugs@freebsd.org, gram@cdsec.com, grog@lemis.com,
        hackers@freebsd.org, peter@spinner.dialix.com.au
Sender: owner-freebsd-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>>STDC only allows operations on auto variables and assignment to static
>>variables of type sig_atomic_t.  We aren't STDC conformant either.
                   ^volatile
>>Operations on auto floating point variables may corrupt the floating
>>point state.  This isn't a problem in practice, since nothing useful
>>can be done using only auto floating point variables.
>
>You could calculate pi... :-)

I was going to say that this is more useless than usual since there is
no way to output the results.  However, I think the following works:

	volatile sig_atomic_t encoded_results[MANY];

	void handler(int s) {
		int i;

		for (i = 0; i < MANY; ++i)
			encoded_results[i] = bit_of_pi(i) == 0 ? 1 : 2;
	}

There is no way to calculate only a few bits per call since there is no
way to keep track of state.

Bruce

From owner-freebsd-bugs  Fri Sep 19 03:59:46 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id DAA03449
          for bugs-outgoing; Fri, 19 Sep 1997 03:59:46 -0700 (PDT)
Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA03427;
          Fri, 19 Sep 1997 03:59:36 -0700 (PDT)
Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1])
	by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id MAA13266;
	Fri, 19 Sep 1997 12:58:34 +0200 (CEST)
To: Bruce Evans 
cc: mike@smith.net.au, atrens@nortel.ca, freebsd-bugs@freebsd.org,
        gram@cdsec.com, hackers@freebsd.org, julian@whistle.com
Subject: Re: Bug in malloc/free 
In-reply-to: Your message of "Fri, 19 Sep 1997 19:54:38 +1000."
             <199709190954.TAA11275@godzilla.zeta.org.au> 
Date: Fri, 19 Sep 1997 12:58:34 +0200
Message-ID: <13264.874666714@critter.freebsd.dk>
From: Poul-Henning Kamp 
Sender: owner-freebsd-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <199709190954.TAA11275@godzilla.zeta.org.au>, Bruce Evans writes:
>>>> probably a printf or other stdio function
>>>
>>>I *know* this. 8) I'm just trying to find the sucker.  The 'ddd' example 
>>>looked like it was spinning in abort(), which doesn't look like it will
>>>actually come back and call malloc() again.  In olden days, 
>>...
>>Some time ago abort() was changed to that it would call __flush(),
>>because some standard said so.  I still think this is unwise.
>
>Standard C says that whether streams are flushed by abort() is
>implementation-defined.  POSIX says that abort() shall have the effects
>of fclose() if abort() causes process termination, but shall have no
>effects otherwise.  Our implementation doesn't quite confirm to this,
>since the effects of flushing can be detected:
>1. setvbuf() to unbuffered and size 2, then putc() 1 byte, then _exit().
>   I think it is guaranteed that 0 bytes are written.
>2. As in (1), but set up a SIGABRT handler so that abort() doesn't cause
>   termination, and call abort() before _exit().
>
>Flushing in abort() should be safe because abort() is not among the
>functions that are safe to call from a signal handler :-).

Bummer.

So what should I do in malloc when I realize that continuing doesn't
make sense ?

	kill (diesig, getpid()); ?
	for which value of diesig ?


--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."

From owner-freebsd-bugs  Fri Sep 19 04:09:50 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA03986
          for bugs-outgoing; Fri, 19 Sep 1997 04:09:50 -0700 (PDT)
Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA03964;
          Fri, 19 Sep 1997 04:09:41 -0700 (PDT)
Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191])
          by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP
	  id EAA29935; Fri, 19 Sep 1997 04:09:01 -0700 (PDT)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194])
	by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id EAA21801;
	Fri, 19 Sep 1997 04:09:00 -0700 (PDT)
Received: (from gdonl@localhost)
	by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id EAA01819;
	Fri, 19 Sep 1997 04:08:58 -0700 (PDT)
From: Don Lewis 
Message-Id: <199709191108.EAA01819@salsa.gv.tsc.tdk.com>
Date: Fri, 19 Sep 1997 04:08:58 -0700
In-Reply-To: Bruce Evans 
       "Re: Bug in malloc/free" (Sep 19,  7:09pm)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: Bruce Evans , grog@lemis.com, peter@spinner.dialix.com.au
Subject: Re: Bug in malloc/free
Cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com,
        hackers@FreeBSD.ORG, phk@critter.freebsd.dk
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Sep 19,  7:09pm, Bruce Evans wrote:
} Subject: Re: Bug in malloc/free
} 
} We claim to be sort of POSIX conformant.  Perhaps this is enough.  We
} aren't actually POSIX conformant.  All the above "safe" routines may
} clobber the global `errno'.

Which is why I save and restore errno in signal handlers.

			---  Truck

From owner-freebsd-bugs  Fri Sep 19 04:20:24 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA04591
          for bugs-outgoing; Fri, 19 Sep 1997 04:20:24 -0700 (PDT)
Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA04563;
          Fri, 19 Sep 1997 04:20:12 -0700 (PDT)
Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1])
	by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id NAA13343;
	Fri, 19 Sep 1997 13:19:29 +0200 (CEST)
To: Bruce Evans 
cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com, grog@lemis.com,
        hackers@FreeBSD.ORG, peter@spinner.dialix.com.au
Subject: Re: Bug in malloc/free 
In-reply-to: Your message of "Fri, 19 Sep 1997 20:24:02 +1000."
             <199709191024.UAA12065@godzilla.zeta.org.au> 
Date: Fri, 19 Sep 1997 13:19:29 +0200
Message-ID: <13341.874667969@critter.freebsd.dk>
From: Poul-Henning Kamp 
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

In message <199709191024.UAA12065@godzilla.zeta.org.au>, Bruce Evans writes:
>>>STDC only allows operations on auto variables and assignment to static
>>>variables of type sig_atomic_t.  We aren't STDC conformant either.
>                   ^volatile
>>>Operations on auto floating point variables may corrupt the floating
>>>point state.  This isn't a problem in practice, since nothing useful
>>>can be done using only auto floating point variables.
>>
>>You could calculate pi... :-)
>
>I was going to say that this is more useless than usual since there is
>no way to output the results.  However, I think the following works:
>
>	volatile sig_atomic_t encoded_results[MANY];
>
>	void handler(int s) {
>		int i;
>
>		for (i = 0; i < MANY; ++i)
>			encoded_results[i] = bit_of_pi(i) == 0 ? 1 : 2;
>	}
>
>There is no way to calculate only a few bits per call since there is no
>way to keep track of state.

Wrong.  A signal handler can have a private static variable.

:-)

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."

From owner-freebsd-bugs  Fri Sep 19 04:37:21 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA05632
          for bugs-outgoing; Fri, 19 Sep 1997 04:37:21 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA05612;
          Fri, 19 Sep 1997 04:37:15 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id VAA14034; Fri, 19 Sep 1997 21:33:53 +1000
Date: Fri, 19 Sep 1997 21:33:53 +1000
From: Bruce Evans 
Message-Id: <199709191133.VAA14034@godzilla.zeta.org.au>
To: bde@zeta.org.au, phk@critter.freebsd.dk
Subject: Re: Bug in malloc/free
Cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com,
        hackers@FreeBSD.ORG, julian@whistle.com, mike@smith.net.au
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>>Flushing in abort() should be safe because abort() is not among the
>>functions that are safe to call from a signal handler :-).
>
>Bummer.
>
>So what should I do in malloc when I realize that continuing doesn't
>make sense ?
>
>	kill (diesig, getpid()); ?
>	for which value of diesig ?

Calling abort() from malloc() should be safe because malloc() is not
among the functions that are safe to call from a signal handler :-).

Bruce

From owner-freebsd-bugs  Fri Sep 19 04:45:35 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA05959
          for bugs-outgoing; Fri, 19 Sep 1997 04:45:35 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA05930;
          Fri, 19 Sep 1997 04:45:21 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id VAA14216; Fri, 19 Sep 1997 21:40:27 +1000
Date: Fri, 19 Sep 1997 21:40:27 +1000
From: Bruce Evans 
Message-Id: <199709191140.VAA14216@godzilla.zeta.org.au>
To: bde@zeta.org.au, Don.Lewis@tsc.tdk.com, grog@lemis.com,
        peter@spinner.dialix.com.au
Subject: Re: Bug in malloc/free
Cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com,
        hackers@FreeBSD.ORG, phk@critter.freebsd.dk
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>} We claim to be sort of POSIX conformant.  Perhaps this is enough.  We
>} aren't actually POSIX conformant.  All the above "safe" routines may
>} clobber the global `errno'.
>
>Which is why I save and restore errno in signal handlers.

OpenBSD has some fixes in this area.  However, POSIX seems to say that
it is unnecessary ("[the functions shall be reentrant ... without
restriction]").

Bruce

From owner-freebsd-bugs  Fri Sep 19 05:01:57 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA06729
          for bugs-outgoing; Fri, 19 Sep 1997 05:01:57 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA06705;
          Fri, 19 Sep 1997 05:01:49 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id VAA14696; Fri, 19 Sep 1997 21:58:23 +1000
Date: Fri, 19 Sep 1997 21:58:23 +1000
From: Bruce Evans 
Message-Id: <199709191158.VAA14696@godzilla.zeta.org.au>
To: bde@zeta.org.au, phk@critter.freebsd.dk
Subject: Re: Bug in malloc/free
Cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com, grog@lemis.com,
        hackers@FreeBSD.ORG, peter@spinner.dialix.com.au
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>>There is no way to calculate only a few bits per call since there is no
>>way to keep track of state.
>
>Wrong.  A signal handler can have a private static variable.
>
>:-)

Wrong :-).  Such a variable would have static storage duration, so the
usual restrictions apply - the behaviour is undefined if the variable is
accessed, unless it has type volatile sig_atomic_t and the access is an
assignment.

Bruce

From owner-freebsd-bugs  Fri Sep 19 05:44:19 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA09057
          for bugs-outgoing; Fri, 19 Sep 1997 05:44:19 -0700 (PDT)
Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA08916;
          Fri, 19 Sep 1997 05:42:46 -0700 (PDT)
Received: from ws6303-f (root@firix [10.1.143.100])
	by zwei.siemens.at  with ESMTP id OAA25259;
	Fri, 19 Sep 1997 14:22:53 +0200 (MET DST)
Received: from ws6423.gud.siemens.at (ws6423-f) by ws6303-f with ESMTP
	(1.40.112.8/16.2) id AA014021751; Fri, 19 Sep 1997 14:22:31 +0200
Received: by ws6423.gud.siemens.at (SMI-8.6/SMI-SVR4)
	id OAA10145; Fri, 19 Sep 1997 14:21:47 +0200
Date: Fri, 19 Sep 1997 14:21:47 +0200
From: lada@ws6303.gud.siemens.at (marino.ladavac@siemens.at)
Message-Id: <199709191221.OAA10145@ws6423.gud.siemens.at>
To: bde@zeta.org.au, phk@critter.freebsd.dk
Subject: Re: Bug in malloc/free
Cc: mike@smith.net.au, atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG,
        gram@cdsec.com, hackers@FreeBSD.ORG, julian@whistle.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Md5: ZOJEsCaDon/JxZZs6n5vnA==
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> >
> >Flushing in abort() should be safe because abort() is not among the
> >functions that are safe to call from a signal handler :-).
> 
> Bummer.
> 
> So what should I do in malloc when I realize that continuing doesn't
> make sense ?
> 
> 	kill (diesig, getpid()); ?
> 	for which value of diesig ?

	raise( SIGABRT );?
	
or the equivalent

	kill( getpid(), SIGABRT);?
	
/Marino
> 
> 
> --
> Poul-Henning Kamp             FreeBSD coreteam member
> phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
> 

From owner-freebsd-bugs  Fri Sep 19 05:51:23 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA09571
          for bugs-outgoing; Fri, 19 Sep 1997 05:51:23 -0700 (PDT)
Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA09546;
          Fri, 19 Sep 1997 05:51:13 -0700 (PDT)
Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1])
	by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id OAA13894;
	Fri, 19 Sep 1997 14:50:07 +0200 (CEST)
To: Bruce Evans 
cc: atrens@nortel.ca, freebsd-bugs@freebsd.org, gram@cdsec.com,
        hackers@freebsd.org, julian@whistle.com, mike@smith.net.au
Subject: Re: Bug in malloc/free 
In-reply-to: Your message of "Fri, 19 Sep 1997 21:33:53 +1000."
             <199709191133.VAA14034@godzilla.zeta.org.au> 
Date: Fri, 19 Sep 1997 14:50:07 +0200
Message-ID: <13892.874673407@critter.freebsd.dk>
From: Poul-Henning Kamp 
Sender: owner-freebsd-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <199709191133.VAA14034@godzilla.zeta.org.au>, Bruce Evans writes:
>>>Flushing in abort() should be safe because abort() is not among the
>>>functions that are safe to call from a signal handler :-).
>>
>>Bummer.
>>
>>So what should I do in malloc when I realize that continuing doesn't
>>make sense ?
>>
>>	kill (diesig, getpid()); ?
>>	for which value of diesig ?
>
>Calling abort() from malloc() should be safe because malloc() is not
>among the functions that are safe to call from a signal handler :-).

I still seems to me that we need a new function to mean:
	"coredump, right now, no ifs, whens or buts. Thank you."

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."

From owner-freebsd-bugs  Fri Sep 19 05:57:55 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA10115
          for bugs-outgoing; Fri, 19 Sep 1997 05:57:55 -0700 (PDT)
Received: from spinner.dialix.com.au (spinner.dialix.com.au [202.12.86.3])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA10107
          for ; Fri, 19 Sep 1997 05:57:49 -0700 (PDT)
Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1])
          by spinner.dialix.com.au with ESMTP id UAA12282;
          Fri, 19 Sep 1997 20:56:21 +0800 (WST)
Message-Id: <199709191256.UAA12282@spinner.dialix.com.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: "Joseph I. Davida" 
cc: bugs@FreeBSD.ORG
Subject: Re: Mem Leak ?? 
In-reply-to: Your message of "Thu, 18 Sep 1997 22:11:20 MST."
             <199709190511.WAA13160@slip129-37-223-142.ca.us.ibm.net> 
Date: Fri, 19 Sep 1997 20:56:20 +0800
From: Peter Wemm 
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

"Joseph I. Davida" wrote:
[..]
> 	When I try to run netscape (version 4.3b8), I get a message
> 	from netscape that I am out of memory. SO I looked at what
> 	vmstat was saying:

Most likely you have actually run into the relatively low default resource
limit for data memory allocation per process (32MB I think).  Netscape
seems to easily hit this, the communicator version moreso than the lite
version.

>  procs      memory     page                    disks      faults      cpu
>  r b w     avm   fre  flt  re  pi  po  fr  sr s0 c0 w0   in   sy  cs us sy id
>  1 0 0 4033532 21008   13   0   0   0  14   0  1  0  0  166  172  30  1  0 99
>  0 0 0 4029456 21008    2   0   0   0   0   0  0  0  0  113   76   9  0  0 10
    0
>  0 0 0 4029812 21008   30   0   0   0  33   0  1  0  0  165 1529  48  3  1 96
>  0 0 0 4029812 21008   13   0   0   0  14   0  1  0  0  109   74  10  0  0 10
    0
>  0 0 0 4029812 21008    2   0   0   0   0   0  0  0  0  179  372  55  2  1 97
>  0 0 0 4029812 21008   13   0   0   0  14   0  1  0  0  242 50055  96 16 40 4
    4
>  0 0 0 4029812 21008   18   0   0   0  19   0  0  0  0  139 1467  37  3  1 96
> 
> 
> 	Holy smokes!! Where did all my free pages go????
> 
> 	Here is the message from bootup, which shows I have plenty of
> 	free memory. So where did all the mem go??? Is the kernel losing
> 	track of free'ed up memory? Also, look at output of ps -agxl below
> 	so you can check resident set sizes.

As I've heard somewhere before, "Free memory is wasted memory".  Seriously 
though, FreeBSD uses all available memory for disk buffering and data 
caching.  It's more like 'freeable memory' than 'free memory'.  The 
problem is that the system doesn't really keep an accurate count of what 
is 'in memory but can be dumped instantly'.  If you look at the output of 
top, you'll see a lot of memory under 'wired', 'cache' and 'buf'.  Some of 
these are freeable, some not.

Cheers,
-Peter



From owner-freebsd-bugs  Fri Sep 19 06:10:04 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA10768
          for bugs-outgoing; Fri, 19 Sep 1997 06:10:04 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA10761;
          Fri, 19 Sep 1997 06:10:01 -0700 (PDT)
Resent-Date: Fri, 19 Sep 1997 06:10:01 -0700 (PDT)
Resent-Message-Id: <199709191310.GAA10761@hub.freebsd.org>
Resent-From: gnats (GNATS Management)
Resent-To: freebsd-bugs
Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, abial@korin.warman.org.pl
Received: from korin.warman.org.pl (korin.warman.org.pl [148.81.160.10])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA10358
          for ; Fri, 19 Sep 1997 06:01:57 -0700 (PDT)
Received: (from abial@localhost)
	by korin.warman.org.pl (8.8.7/8.8.5) id PAA13501;
	Fri, 19 Sep 1997 15:03:44 +0200 (CEST)
Message-Id: <199709191303.PAA13501@korin.warman.org.pl>
Date: Fri, 19 Sep 1997 15:03:44 +0200 (CEST)
From: Andrzej Bialecki 
Reply-To: abial@korin.warman.org.pl
To: FreeBSD-gnats-submit@FreeBSD.ORG
X-Send-Pr-Version: 3.2
Subject: bin/4582: integer overflow in 'sa -km'
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


>Number:         4582
>Category:       bin
>Synopsis:       integer overflow in 'sa -km'
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Sep 19 06:10:00 PDT 1997
>Last-Modified:
>Originator:     Andrzej Bialecki
>Organization:
Research and Academic Network
>Release:        FreeBSD 3.0-CURRENT i386
>Environment:

	-current as of beginning of Sep

>Description:

	'sa -km' gives erroneous results, most probably because of
	integer overflow somewhere:
korin:~> sa -km
root        328808       514.41cpu      1723820tio4662999034058040619k
daemon         915        18.45cpu         3914tio4645041814295546394k
pwr           1937         0.54cpu         8940tio4674971065316569034k
abial         4695        22.93cpu        66703tio4657095280555631290k
pcg          23562         0.64cpu        50594tio4689191117479392754k
jacek            7         0.00cpu           56tio4667556731635506718k
krzych     3522459      2862.77cpu      4258301tio4664307048490154874k
rafal           51         0.06cpu          428tio4664439222741607509k
krzycki         19         0.02cpu          169tio4664848505141985280k
artw             9         0.02cpu          243tio4664990776516932444k
askrz           17         0.02cpu          180tio4665074672938562251k
lab              2         0.01cpu           32tio4665884345050952797k
nobody          30         1.20cpu        32049tio4642563007591943195k
korin:~>


>How-To-Repeat:

	Turn accounting ON. Issue 'sa -km'.

>Fix:
	
	Don't know.

>Audit-Trail:
>Unformatted:

From owner-freebsd-bugs  Fri Sep 19 06:21:15 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA11267
          for bugs-outgoing; Fri, 19 Sep 1997 06:21:15 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA11243;
          Fri, 19 Sep 1997 06:21:04 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id XAA17318; Fri, 19 Sep 1997 23:18:11 +1000
Date: Fri, 19 Sep 1997 23:18:11 +1000
From: Bruce Evans 
Message-Id: <199709191318.XAA17318@godzilla.zeta.org.au>
To: bde@zeta.org.au, phk@critter.freebsd.dk
Subject: Re: Bug in malloc/free
Cc: atrens@nortel.ca, freebsd-bugs@freebsd.org, gram@cdsec.com,
        hackers@freebsd.org, julian@whistle.com, mike@smith.net.au
Sender: owner-freebsd-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>I still seems to me that we need a new function to mean:
>	"coredump, right now, no ifs, whens or buts. Thank you."

A new signal, like SIGKILL except it generates cores, would be useful.
We would have to fix all the assumptions that sigset_t == int to make
room for another signal number.

Bruce

From owner-freebsd-bugs  Fri Sep 19 07:15:32 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA14323
          for bugs-outgoing; Fri, 19 Sep 1997 07:15:32 -0700 (PDT)
Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA14313;
          Fri, 19 Sep 1997 07:15:22 -0700 (PDT)
Received: (from jmg@localhost)
          by hydrogen.nike.efn.org (8.8.7/8.8.7) id HAA04957;
          Fri, 19 Sep 1997 07:15:19 -0700 (PDT)
Message-ID: <19970919071518.15473@hydrogen.nike.efn.org>
Date: Fri, 19 Sep 1997 07:15:18 -0700
From: John-Mark Gurney 
To: freebsd-bugs@FreeBSD.ORG, hackers@FreeBSD.ORG
Subject: Re: Bug in malloc/free
References: <199709191221.OAA10145@ws6423.gud.siemens.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199709191221.OAA10145@ws6423.gud.siemens.at>; from marino.ladavac@siemens.at on Fri, Sep 19, 1997 at 02:21:47PM +0200
Reply-To: John-Mark Gurney 
Organization: Cu Networking
X-Operating-System: FreeBSD 2.2.1-RELEASE i386
X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31  96 7A 22 B3 D8 56 36 F4
X-Files: The truth is out there
X-URL: http://resnet.uoregon.edu/~gurney_j/
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

marino.ladavac@siemens.at scribbled this message on Sep 19:
> > >
> > >Flushing in abort() should be safe because abort() is not among the
> > >functions that are safe to call from a signal handler :-).
> > 
> > Bummer.
> > 
> > So what should I do in malloc when I realize that continuing doesn't
> > make sense ?
> > 
> > 	kill (diesig, getpid()); ?
> > 	for which value of diesig ?
> 
> 	raise( SIGABRT );?
> 	
> or the equivalent
> 
> 	kill( getpid(), SIGABRT);?

what happens what it's masked or caught??  Only SIGKILL and SIGSTOP can't
be caught or ignored... (see signal(3) for more info)...

-- 
  John-Mark Gurney                          Modem/FAX: +1 541 683 6954
  Cu Networking

  Live in Peace, destroy Micro$oft, support free software, run FreeBSD

From owner-freebsd-bugs  Fri Sep 19 08:02:02 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA17033
          for bugs-outgoing; Fri, 19 Sep 1997 08:02:02 -0700 (PDT)
Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA17013;
          Fri, 19 Sep 1997 08:01:56 -0700 (PDT)
Received: from right.PCS (right.PCS [148.105.10.31])
	by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id KAA01781;
	Fri, 19 Sep 1997 10:01:04 -0500 (CDT)
Received: (from jlemon@localhost)
	by right.PCS (8.6.13/8.6.4) id KAA29922;
	Fri, 19 Sep 1997 10:00:28 -0500
Message-ID: <19970919100027.23678@right.PCS>
Date: Fri, 19 Sep 1997 10:00:27 -0500
From: Jonathan Lemon 
To: Bruce Evans 
Cc: phk@critter.freebsd.dk, atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG,
        gram@cdsec.com, hackers@FreeBSD.ORG, julian@whistle.com,
        mike@smith.net.au
Subject: Re: Bug in malloc/free
References: <199709191318.XAA17318@godzilla.zeta.org.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.61.1
In-Reply-To: <199709191318.XAA17318@godzilla.zeta.org.au>; from Bruce Evans on Sep 09, 1997 at 11:18:11PM +1000
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Sep 09, 1997 at 11:18:11PM +1000, Bruce Evans wrote:
> >I still seems to me that we need a new function to mean:
> >	"coredump, right now, no ifs, whens or buts. Thank you."
> 
> A new signal, like SIGKILL except it generates cores, would be useful.
> We would have to fix all the assumptions that sigset_t == int to make
> room for another signal number.

``SIGCORE''  :-)
--
Jonathan

From owner-freebsd-bugs  Fri Sep 19 08:23:11 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA18188
          for bugs-outgoing; Fri, 19 Sep 1997 08:23:11 -0700 (PDT)
Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA18159;
          Fri, 19 Sep 1997 08:22:51 -0700 (PDT)
Received: from ws6303-f (root@firix [10.1.143.100])
	by zwei.siemens.at  with ESMTP id RAA02443;
	Fri, 19 Sep 1997 17:21:57 +0200 (MET DST)
Received: from ws6423.gud.siemens.at (ws6423-f) by ws6303-f with ESMTP
	(1.40.112.8/16.2) id AA027142495; Fri, 19 Sep 1997 17:21:35 +0200
Received: by ws6423.gud.siemens.at (SMI-8.6/SMI-SVR4)
	id RAA10438; Fri, 19 Sep 1997 17:20:50 +0200
Date: Fri, 19 Sep 1997 17:20:50 +0200
From: lada@ws6303.gud.siemens.at (marino.ladavac@siemens.at)
Message-Id: <199709191520.RAA10438@ws6423.gud.siemens.at>
To: freebsd-bugs@FreeBSD.ORG, hackers@FreeBSD.ORG, gurney_j@resnet.uoregon.edu
Subject: Re: Bug in malloc/free
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Md5: YrwSafdQSM6jeHcMCB3EGg==
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> From owner-freebsd-hackers@FreeBSD.ORG Fri Sep 19 16:54:54 MET 1997
> Date: Fri, 19 Sep 1997 07:15:18 -0700
> From: John-Mark Gurney 
> To: freebsd-bugs@FreeBSD.ORG, hackers@FreeBSD.ORG
> Subject: Re: Bug in malloc/free
> Mime-Version: 1.0
> X-Operating-System: FreeBSD 2.2.1-RELEASE i386
> X-Pgp-Fingerprint: B7 EC EF F8 AE ED A7 31  96 7A 22 B3 D8 56 36 F4
> X-Files: The truth is out there
> X-Url: http://resnet.uoregon.edu/~gurney_j/
> X-Loop: FreeBSD.org
> 
> marino.ladavac@siemens.at scribbled this message on Sep 19:
> > > >
> > > >Flushing in abort() should be safe because abort() is not among the
> > > >functions that are safe to call from a signal handler :-).
> > > 
> > > Bummer.
> > > 
> > > So what should I do in malloc when I realize that continuing doesn't
> > > make sense ?
> > > 
> > > 	kill (diesig, getpid()); ?
> > > 	for which value of diesig ?
> > 
> > 	raise( SIGABRT );?
> > 	
> > or the equivalent
> > 
> > 	kill( getpid(), SIGABRT);?
> 
> what happens what it's masked or caught??  Only SIGKILL and SIGSTOP can't
> be caught or ignored... (see signal(3) for more info)...

then I am an idiot who deserves the punishment.  I mean, If I want to
abort(), I am sure not going to catch or mask SIGABRT.  I thought this much
could be taken for granted.

Otherwise, you would need another signal, as Bruce already stated.

BTW, I strongly believe that the assumption that NSIG<=32 is dieing away
very fast as there are some nontrivial platforms where the converse is
true:

HP-UX 10.10:
#  define _SIGDIL       32      /* DIL signal */
#  define _SIGXCPU      33      /* CPU time limit exceeded (setrlimit)  */
#  define _SIGXFSZ      34      /* CPU file size limit exceeded (setrlimit)  */

Solaris 5.5.1:
#define SIGWAITING 32   /* process's lwps are blocked */
#define SIGLWP  33      /* special signal used by thread library */
#define SIGFREEZE 34    /* special signal used by CPR */
#define SIGTHAW 35      /* special signal used by CPR */
#define SIGCANCEL 36    /* thread cancellation signal used by libthread */
/* insert new signals here, and move _SIGRTM* appropriately */
#define _SIGRTMIN 37    /* first (highest-priority) realtime signal */
#define _SIGRTMAX 44    /* last (lowest-priority) realtime signal */

IMHO as far as UNIX is concerned, these two are pretty much the mainstream,
and, modullo SunOS brain dead 8bit FILE.fd size, had no problems porting
software to them.  sigset_t is sigset_t--who cares to what does it really
map.

/Marino

> -- 
>   John-Mark Gurney                          Modem/FAX: +1 541 683 6954
>   Cu Networking
> 
>   Live in Peace, destroy Micro$oft, support free software, run FreeBSD
> 

From owner-freebsd-bugs  Fri Sep 19 08:31:42 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA18698
          for bugs-outgoing; Fri, 19 Sep 1997 08:31:42 -0700 (PDT)
Received: from usr07.primenet.com (tlambert@usr07.primenet.com [206.165.6.207])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA18693;
          Fri, 19 Sep 1997 08:31:40 -0700 (PDT)
Received: (from tlambert@localhost)
	by usr07.primenet.com (8.8.5/8.8.5) id IAA07978;
	Fri, 19 Sep 1997 08:31:34 -0700 (MST)
From: Terry Lambert 
Message-Id: <199709191531.IAA07978@usr07.primenet.com>
Subject: Re: Bug in malloc/free
To: Don.Lewis@tsc.tdk.com (Don Lewis)
Date: Fri, 19 Sep 1997 15:31:34 +0000 (GMT)
Cc: hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
In-Reply-To: <199709191108.EAA01819@salsa.gv.tsc.tdk.com> from "Don Lewis" at Sep 19, 97 04:08:58 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> } Subject: Re: Bug in malloc/free
> } 
> } We claim to be sort of POSIX conformant.  Perhaps this is enough.  We
> } aren't actually POSIX conformant.  All the above "safe" routines may
> } clobber the global `errno'.
> 
> Which is why I save and restore errno in signal handlers.

Perhaps this should be done by the trampoline code on the user's
behalf...


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-bugs  Fri Sep 19 08:37:55 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA19117
          for bugs-outgoing; Fri, 19 Sep 1997 08:37:55 -0700 (PDT)
Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA19112;
          Fri, 19 Sep 1997 08:37:51 -0700 (PDT)
Received: (from jmg@localhost)
          by hydrogen.nike.efn.org (8.8.7/8.8.7) id IAA06554;
          Fri, 19 Sep 1997 08:37:23 -0700 (PDT)
Message-ID: <19970919083722.51186@hydrogen.nike.efn.org>
Date: Fri, 19 Sep 1997 08:37:22 -0700
From: John-Mark Gurney 
To: "marino.ladavac@siemens.at" 
Cc: freebsd-bugs@FreeBSD.ORG, hackers@FreeBSD.ORG
Subject: Re: Bug in malloc/free
References: <199709191520.RAA10438@ws6423.gud.siemens.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199709191520.RAA10438@ws6423.gud.siemens.at>; from marino.ladavac@siemens.at on Fri, Sep 19, 1997 at 05:20:50PM +0200
Reply-To: John-Mark Gurney 
Organization: Cu Networking
X-Operating-System: FreeBSD 2.2.1-RELEASE i386
X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31  96 7A 22 B3 D8 56 36 F4
X-Files: The truth is out there
X-URL: http://resnet.uoregon.edu/~gurney_j/
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

marino.ladavac@siemens.at scribbled this message on Sep 19:
> > marino.ladavac@siemens.at scribbled this message on Sep 19:
> > > > >
> > > > >Flushing in abort() should be safe because abort() is not among the
> > > > >functions that are safe to call from a signal handler :-).
> > > > 
> > > > Bummer.
> > > > 
> > > > So what should I do in malloc when I realize that continuing doesn't
> > > > make sense ?
> > > > 
> > > > 	kill (diesig, getpid()); ?
> > > > 	for which value of diesig ?
> > > 
> > > 	raise( SIGABRT );?
> > > 	
> > > or the equivalent
> > > 
> > > 	kill( getpid(), SIGABRT);?
> > 
> > what happens what it's masked or caught??  Only SIGKILL and SIGSTOP can't
> > be caught or ignored... (see signal(3) for more info)...
> 
> then I am an idiot who deserves the punishment.  I mean, If I want to
> abort(), I am sure not going to catch or mask SIGABRT.  I thought this much
> could be taken for granted.

sorry.... if you were called from another program (as malloc is), the
SIGABRT will be in an unknown state...  and requires fiddling with the
signals first... as you state...  it just wasn't clear that you knew
this was needed...

> Otherwise, you would need another signal, as Bruce already stated.

I agree... a friend of mine is VERY annoyed that you can't reliably get
a core dump with a very simple operation...

> 
> BTW, I strongly believe that the assumption that NSIG<=32 is dieing away
> very fast as there are some nontrivial platforms where the converse is
> true:

this is good to hear...

[...]

> IMHO as far as UNIX is concerned, these two are pretty much the mainstream,
> and, modullo SunOS brain dead 8bit FILE.fd size, had no problems porting
> software to them.  sigset_t is sigset_t--who cares to what does it really
> map.

-- 
  John-Mark Gurney                          Modem/FAX: +1 541 683 6954
  Cu Networking

  Live in Peace, destroy Micro$oft, support free software, run FreeBSD

From owner-freebsd-bugs  Fri Sep 19 09:59:28 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA24372
          for bugs-outgoing; Fri, 19 Sep 1997 09:59:28 -0700 (PDT)
Received: from dublin.iona.ie (root@operation.dublin.iona.ie [192.122.221.5])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA24363;
          Fri, 19 Sep 1997 09:59:13 -0700 (PDT)
Received: from ultra (ultra [192.122.221.136]) by dublin.iona.ie (8.7.5/jm-1.01) with SMTP id RAA17969; Fri, 19 Sep 1997 17:58:42 +0100 (BST)
Date: Fri, 19 Sep 1997 17:58:18 +0100 (BST)
From: Niall Smart 
X-Sender: nsmart@ultra
To: Terry Lambert 
cc: Don Lewis , hackers@FreeBSD.ORG,
        freebsd-bugs@FreeBSD.ORG
Subject: Re: Bug in malloc/free
In-Reply-To: <199709191531.IAA07978@usr07.primenet.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Fri, 19 Sep 1997, Terry Lambert wrote:

> > } We claim to be sort of POSIX conformant.  Perhaps this is enough.  We
> > } aren't actually POSIX conformant.  All the above "safe" routines may
> > } clobber the global `errno'.
> > 
> > Which is why I save and restore errno in signal handlers.
> 
> Perhaps this should be done by the trampoline code on the user's
> behalf...

Perhaps that would encourage people to write non-portable code.

--
Niall Smart
Customer Engineering,
IONA Technologies. (www.iona.com)


From owner-freebsd-bugs  Fri Sep 19 12:16:03 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA01799
          for bugs-outgoing; Fri, 19 Sep 1997 12:16:03 -0700 (PDT)
Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA01757;
          Fri, 19 Sep 1997 12:15:48 -0700 (PDT)
Received: from ponds.dignus.com (ponds.vnet.net [166.82.177.48])
          by elvis.vnet.net (8.8.5/8.8.4) with ESMTP
	  id PAA00215; Fri, 19 Sep 1997 15:15:38 -0400 (EDT)
Received: from lakes.dignus.com (lakes [10.0.0.3])
	by ponds.dignus.com (8.8.5/8.8.5) with ESMTP id IAA10812;
	Fri, 19 Sep 1997 08:28:26 -0400 (EDT)
Received: (from rivers@localhost) by lakes.dignus.com (8.8.5/8.6.9) id IAA22376; Fri, 19 Sep 1997 08:19:18 -0400 (EDT)
Date: Fri, 19 Sep 1997 08:19:18 -0400 (EDT)
From: Thomas David Rivers 
Message-Id: <199709191219.IAA22376@lakes.dignus.com>
To: freebsd-bugs@FreeBSD.ORG, phk@FreeBSD.ORG, wosch@apfel.de
Subject: Re: kern/3398
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> Synopsis: off by one error in ffs_alloc
> 
> State-Changed-From-To: open-closed
> State-Changed-By: phk
> State-Changed-When: Thu Sep 18 11:07:53 PDT 1997
> State-Changed-Why: 
> applied the patch, thankyou!
> 

 I've been off the list for a while - can someone relate
the details of this - in particular, the patch (or, just 
point me to it...)

	- Thanks -
	- Dave Rivers -

From owner-freebsd-bugs  Fri Sep 19 13:03:19 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id NAA04372
          for bugs-outgoing; Fri, 19 Sep 1997 13:03:19 -0700 (PDT)
Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA04342;
          Fri, 19 Sep 1997 13:03:12 -0700 (PDT)
Received: (from tlambert@localhost)
	by usr03.primenet.com (8.8.5/8.8.5) id NAA29627;
	Fri, 19 Sep 1997 13:02:33 -0700 (MST)
From: Terry Lambert 
Message-Id: <199709192002.NAA29627@usr03.primenet.com>
Subject: Re: Bug in malloc/free
To: nsmart@iona.com (Niall Smart)
Date: Fri, 19 Sep 1997 20:02:33 +0000 (GMT)
Cc: tlambert@primenet.com, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG,
        freebsd-bugs@FreeBSD.ORG
In-Reply-To:  from "Niall Smart" at Sep 19, 97 05:58:18 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > > } We claim to be sort of POSIX conformant.  Perhaps this is enough.  We
> > > } aren't actually POSIX conformant.  All the above "safe" routines may
> > > } clobber the global `errno'.
> > > 
> > > Which is why I save and restore errno in signal handlers.
> > 
> > Perhaps this should be done by the trampoline code on the user's
> > behalf...
> 
> Perhaps that would encourage people to write non-portable code.

When a read or write fault occurs on page zero in a program running
on SVR4, rather than crashing, the map the page and note the effect.

There is a kernel tunable that can turn this off, but a great many
legacy programs dereference NULL pointers, expecting a NULL pointer
to be identical to a NULL string.

The default for SVR4 is arguably incorrect, but it follows the principle
of least astonishment, and allows legacy code to run.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-bugs  Fri Sep 19 13:04:04 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id NAA04372
          for bugs-outgoing; Fri, 19 Sep 1997 13:03:19 -0700 (PDT)
Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA04342;
          Fri, 19 Sep 1997 13:03:12 -0700 (PDT)
Received: (from tlambert@localhost)
	by usr03.primenet.com (8.8.5/8.8.5) id NAA29627;
	Fri, 19 Sep 1997 13:02:33 -0700 (MST)
From: Terry Lambert 
Message-Id: <199709192002.NAA29627@usr03.primenet.com>
Subject: Re: Bug in malloc/free
To: nsmart@iona.com (Niall Smart)
Date: Fri, 19 Sep 1997 20:02:33 +0000 (GMT)
Cc: tlambert@primenet.com, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG,
        freebsd-bugs@FreeBSD.ORG
In-Reply-To:  from "Niall Smart" at Sep 19, 97 05:58:18 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > > } We claim to be sort of POSIX conformant.  Perhaps this is enough.  We
> > > } aren't actually POSIX conformant.  All the above "safe" routines may
> > > } clobber the global `errno'.
> > > 
> > > Which is why I save and restore errno in signal handlers.
> > 
> > Perhaps this should be done by the trampoline code on the user's
> > behalf...
> 
> Perhaps that would encourage people to write non-portable code.

When a read or write fault occurs on page zero in a program running
on SVR4, rather than crashing, the map the page and note the effect.

There is a kernel tunable that can turn this off, but a great many
legacy programs dereference NULL pointers, expecting a NULL pointer
to be identical to a NULL string.

The default for SVR4 is arguably incorrect, but it follows the principle
of least astonishment, and allows legacy code to run.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-bugs  Fri Sep 19 13:58:46 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id NAA07845
          for bugs-outgoing; Fri, 19 Sep 1997 13:58:46 -0700 (PDT)
Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA07792;
          Fri, 19 Sep 1997 13:58:32 -0700 (PDT)
Message-Id: <199709192058.NAA07792@hub.freebsd.org>
Received: from bcars520.ott.bnr.ca (actually 47.128.5.188) 
          by bcarsde4.localhost; Fri, 19 Sep 1997 16:57:18 -0400
Received: from bnr.ca by bcars520.bnr.ca id <12675-0@bcars520.bnr.ca>;
          Fri, 19 Sep 1997 16:56:30 -0400
Date: 19 Sep 1997 16:56 EDT
To: nsmart@iona.com
Cc: tlambert@primenet.com, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG,
        freebsd-bugs@FreeBSD.ORG
From: "Andrew Atrens" 
Subject: Re: Bug in malloc/free
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

In message "Bug in malloc/free", nsmart@iona.com writes:

> On Fri, 19 Sep 1997, Terry Lambert wrote:
> 
> > > } We claim to be sort of POSIX conformant.  Perhaps this is enough.  We
> > > } aren't actually POSIX conformant.  All the above "safe" routines may
> > > } clobber the global `errno'.
> > > 
> > > Which is why I save and restore errno in signal handlers.
> > 
> > Perhaps this should be done by the trampoline code on the user's
> > behalf...
> 
> Perhaps that would encourage people to write non-portable code.

Detecting changes in errno ( when there should be no change ), would
be useful for debugging. Armed with this knowledge the trampoline code
could `SIGCORE' the offending app, or allow it to run, I guess it depends
on your religion - I for one vote for SIGCORE. In either case I think it
would be nice for the trampoline code to `repair' errno. Its the robust
thing to do.

Andrew.

> 
> --
> Niall Smart
> Customer Engineering,
> IONA Technologies. (www.iona.com)
> 
>                                              

From owner-freebsd-bugs  Fri Sep 19 14:39:25 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA10910
          for bugs-outgoing; Fri, 19 Sep 1997 14:39:25 -0700 (PDT)
Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA10898;
          Fri, 19 Sep 1997 14:39:17 -0700 (PDT)
Received: from panke.panke.de (anonymous229.ppp.cs.tu-berlin.de [130.149.17.229])
	by mail.cs.tu-berlin.de (8.8.6/8.8.6) with ESMTP id XAA17284;
	Fri, 19 Sep 1997 23:38:05 +0200 (MET DST)
Received: (from wosch@localhost) by panke.panke.de (8.8.5/8.6.12) id XAA00584; Fri, 19 Sep 1997 23:06:31 +0200 (MET DST)
Message-ID: <19970919230630.51960@panke.de>
Date: Fri, 19 Sep 1997 23:06:30 +0200
From: Wolfram Schneider 
To: Thomas David Rivers 
Cc: freebsd-bugs@FreeBSD.ORG, phk@FreeBSD.ORG, wosch@apfel.de
Subject: Re: kern/3398
References: <199709191219.IAA22376@lakes.dignus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.79
In-Reply-To: <199709191219.IAA22376@lakes.dignus.com>; from Thomas David Rivers on Fri, Sep 19, 1997 at 08:19:18AM -0400
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Fri, Sep 19, 1997 at 08:19:18AM -0400, Thomas David Rivers wrote:
> > Synopsis: off by one error in ffs_alloc
>  I've been off the list for a while - can someone relate
> the details of this - in particular, the patch (or, just 
> point me to it...)

See the CVS Repository

http://www.freebsd.org/cgi/cvsweb.cgi ->
	src/sys/ufs/ffs/ffs_alloc.c

-- 
Wolfram Schneider      http://www.apfel.de/~wosch/

From owner-freebsd-bugs  Fri Sep 19 14:44:09 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA11314
          for bugs-outgoing; Fri, 19 Sep 1997 14:44:09 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA11293;
          Fri, 19 Sep 1997 14:43:57 -0700 (PDT)
From: Wolfram Schneider 
Received: (from wosch@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id OAA18368;
	Fri, 19 Sep 1997 14:39:54 -0700 (PDT)
Date: Fri, 19 Sep 1997 14:39:54 -0700 (PDT)
Message-Id: <199709192139.OAA18368@freefall.freebsd.org>
To: kuma@slab.tnr.sharp.co.jp, wosch@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: docs/4561
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: .Ox macro needs to support "OpenBSD 2.1"

State-Changed-From-To: open-closed
State-Changed-By: wosch
State-Changed-When: Fri Sep 19 14:38:04 PDT 1997
State-Changed-Why: 
patch applied, thanks!
src/contrib/groff/tmac/doc-syms revision: 1.11

From owner-freebsd-bugs  Fri Sep 19 14:50:06 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA11732
          for bugs-outgoing; Fri, 19 Sep 1997 14:50:06 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA11722;
          Fri, 19 Sep 1997 14:50:02 -0700 (PDT)
Resent-Date: Fri, 19 Sep 1997 14:50:02 -0700 (PDT)
Resent-Message-Id: <199709192150.OAA11722@hub.freebsd.org>
Resent-From: gnats (GNATS Management)
Resent-To: freebsd-bugs
Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, arnej@math.ntnu.no
Received: from romberg.math.ntnu.no (153@romberg.imf.unit.no [129.241.15.150])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA11059
          for ; Fri, 19 Sep 1997 14:40:18 -0700 (PDT)
Received: (qmail 12319 invoked from network); 19 Sep 1997 21:40:14 -0000
Received: from frida.math.ntnu.no (129.241.15.136)
  by romberg.imf.unit.no with SMTP; 19 Sep 1997 21:40:14 -0000
Received: (from arnej@localhost)
          by frida.math.ntnu.no (8.8.7/8.8.4)
	  id XAA21866; Fri, 19 Sep 1997 23:40:13 +0200 (MEST)
Message-Id: <199709192140.XAA21866@frida.math.ntnu.no>
Date: Fri, 19 Sep 1997 23:40:13 +0200 (MEST)
From: arnej@math.ntnu.no
Reply-To: arnej@math.ntnu.no
To: FreeBSD-gnats-submit@FreeBSD.ORG
X-Send-Pr-Version: 3.2
Subject: bin/4585: termcap search fails too early
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


>Number:         4585
>Category:       bin
>Synopsis:       termcap search fails too early
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Sep 19 14:50:00 PDT 1997
>Last-Modified:
>Originator:     Arne Henrik Juul
>Organization:
Norwegian University of Technology and Science
>Release:        FreeBSD 2.2-STABLE i386
>Environment:

	

>Description:

	The routines to find termcap entries (ultimately ending
	up in getent in libc) has problems if it has problems
	opening your ~/.termcap; only ENOENT is ignored.  But
	there may be other reasons why this fails and it should
	proceed to try /usr/share/misc/termcap; we got the problem
	when xterm couldn't access the home directory (because
	xterm is suid root, the home directory was on NFS without
	root privs, and was mod 700).  Other failure modes could
	probably be found as well.

>How-To-Repeat:

	Have a home directory on NFS, mounted without root privs,
	mode 700, then try starting xterm.  You should get the
	rather obscure message "unable to find usable termcap entry."

>Fix:
	
Patch from NetBSD:

Index: src/lib/libc/gen/getcap.c
===================================================================
RCS file: /usr/cvs/src/lib/libc/gen/getcap.c,v
retrieving revision 1.4
diff -u -r1.4 getcap.c
--- getcap.c	1995/10/22 14:36:15	1.4
+++ getcap.c	1997/09/19 21:26:27
@@ -269,10 +269,7 @@
 				fd = open(*db_p, O_RDONLY, 0);
 				if (fd < 0) {
 					/* No error on unfound file. */
-					if (errno == ENOENT)
-						continue;
-					free(record);
-					return (-2);
+					continue;
 				}
 				myfd = 1;
 			}
>Audit-Trail:
>Unformatted:

From owner-freebsd-bugs  Fri Sep 19 15:28:50 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA14006
          for bugs-outgoing; Fri, 19 Sep 1997 15:28:50 -0700 (PDT)
Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA13956;
          Fri, 19 Sep 1997 15:28:21 -0700 (PDT)
Received: (from grog@localhost)
	by freebie.lemis.com (8.8.7/8.8.5) id HAA17463;
	Sat, 20 Sep 1997 07:57:53 +0930 (CST)
Message-ID: <19970920075752.19257@lemis.com>
Date: Sat, 20 Sep 1997 07:57:52 +0930
From: Greg Lehey 
To: Bruce Evans 
Cc: phk@critter.freebsd.dk, atrens@nortel.ca, freebsd-bugs@freebsd.org,
        gram@cdsec.com, hackers@freebsd.org, peter@spinner.dialix.com.au
Subject: Re: Bug in malloc/free
References: <199709191024.UAA12065@godzilla.zeta.org.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81e
In-Reply-To: <199709191024.UAA12065@godzilla.zeta.org.au>; from Bruce Evans on Fri, Sep 19, 1997 at 08:24:02PM +1000
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8250
Fax: +61-8-8388-8250
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Fight-Spam-Now: http://www.cauce.org
Sender: owner-freebsd-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Fri, Sep 19, 1997 at 08:24:02PM +1000, Bruce Evans wrote:
>>> STDC only allows operations on auto variables and assignment to static
>>> variables of type sig_atomic_t.  We aren't STDC conformant either.
>                    ^volatile
>>> Operations on auto floating point variables may corrupt the floating
>>> point state.  This isn't a problem in practice, since nothing useful
>>> can be done using only auto floating point variables.
>>
>> You could calculate pi... :-)
>
> I was going to say that this is more useless than usual since there is
> no way to output the results.

JOOI, what does a pi calculator need a signal handler for?

Greg

From owner-freebsd-bugs  Fri Sep 19 15:36:22 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA14868
          for bugs-outgoing; Fri, 19 Sep 1997 15:36:22 -0700 (PDT)
Date: Fri, 19 Sep 1997 15:36:22 -0700 (PDT)
From: owner-freebsd-bugs
Message-Id: <199709192236.PAA14868@hub.freebsd.org>
To: undisclosed-recipients:;


From owner-freebsd-bugs  Fri Sep 19 15:40:04 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA15233
          for bugs-outgoing; Fri, 19 Sep 1997 15:40:04 -0700 (PDT)
Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA14836;
          Fri, 19 Sep 1997 15:36:10 -0700 (PDT)
Received: (from grog@localhost)
	by freebie.lemis.com (8.8.7/8.8.5) id IAA17509;
	Sat, 20 Sep 1997 08:05:54 +0930 (CST)
Message-ID: <19970920080554.38866@lemis.com>
Date: Sat, 20 Sep 1997 08:05:54 +0930
From: Greg Lehey 
To: Terry Lambert 
Cc: Niall Smart , Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG,
        freebsd-bugs@FreeBSD.ORG
Subject: Re: Bug in malloc/free
References:  <199709192002.NAA29627@usr03.primenet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81e
In-Reply-To: <199709192002.NAA29627@usr03.primenet.com>; from Terry Lambert on Fri, Sep 19, 1997 at 08:02:33PM +0000
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8250
Fax: +61-8-8388-8250
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Fight-Spam-Now: http://www.cauce.org
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Fri, Sep 19, 1997 at 08:02:33PM +0000, Terry Lambert wrote:
>>>> } We claim to be sort of POSIX conformant.  Perhaps this is enough.  We
>>>> } aren't actually POSIX conformant.  All the above "safe" routines may
>>>> } clobber the global `errno'.
>>>>
>>>> Which is why I save and restore errno in signal handlers.
>>>
>>> Perhaps this should be done by the trampoline code on the user's
>>> behalf...
>>
>> Perhaps that would encourage people to write non-portable code.
>
> When a read or write fault occurs on page zero in a program running
> on SVR4, rather than crashing, the map the page and note the effect.
>
> There is a kernel tunable that can turn this off, but a great many
> legacy programs dereference NULL pointers, expecting a NULL pointer
> to be identical to a NULL string.
>
> The default for SVR4 is arguably incorrect, but it follows the principle
> of least astonishment, and allows legacy code to run.

It's not just incorrect, it's inconsistent.  Some SVR4 do, some SVR4
don't.

True SRV4 story (I'll omit the name of the vendor to protect the
guilty): they had some problems with a runaway csh which went crazy
after the stdin line dropped, and ultimately it killed the system.
They determined that, for some reason, csh wasn't responding to
SIGHUP.  So they introduced a kernel mod to send a SIGKILL after 100
SIGHUPs.

Greg

From owner-freebsd-bugs  Fri Sep 19 15:44:21 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id PAA15541
          for bugs-outgoing; Fri, 19 Sep 1997 15:44:21 -0700 (PDT)
Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA15519;
          Fri, 19 Sep 1997 15:44:14 -0700 (PDT)
Received: (from grog@localhost)
	by freebie.lemis.com (8.8.7/8.8.5) id IAA17548;
	Sat, 20 Sep 1997 08:12:43 +0930 (CST)
Message-ID: <19970920081243.54396@lemis.com>
Date: Sat, 20 Sep 1997 08:12:43 +0930
From: Greg Lehey 
To: Bruce Evans 
Cc: phk@critter.freebsd.dk, atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG,
        gram@cdsec.com, hackers@FreeBSD.ORG, julian@whistle.com,
        mike@smith.net.au
Subject: Re: Bug in malloc/free
References: <199709191318.XAA17318@godzilla.zeta.org.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81e
In-Reply-To: <199709191318.XAA17318@godzilla.zeta.org.au>; from Bruce Evans on Fri, Sep 19, 1997 at 11:18:11PM +1000
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8250
Fax: +61-8-8388-8250
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Fight-Spam-Now: http://www.cauce.org
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Fri, Sep 19, 1997 at 11:18:11PM +1000, Bruce Evans wrote:
>> I still seems to me that we need a new function to mean:
>>	"coredump, right now, no ifs, whens or buts. Thank you."
>
> A new signal, like SIGKILL except it generates cores, would be useful.
> We would have to fix all the assumptions that sigset_t == int to make
> room for another signal number.

Is that really so important?  You can call sigaction from a signal
handler, so you can unmask the signal before calling it.  A new signal
for the sake of a couple of lines of library code?

Greg

From owner-freebsd-bugs  Fri Sep 19 16:49:34 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id QAA18838
          for bugs-outgoing; Fri, 19 Sep 1997 16:49:34 -0700 (PDT)
Received: from usr04.primenet.com (tlambert@usr04.primenet.com [206.165.6.204])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA18831;
          Fri, 19 Sep 1997 16:49:29 -0700 (PDT)
Received: (from tlambert@localhost)
	by usr04.primenet.com (8.8.5/8.8.5) id QAA19815;
	Fri, 19 Sep 1997 16:49:07 -0700 (MST)
From: Terry Lambert 
Message-Id: <199709192349.QAA19815@usr04.primenet.com>
Subject: Re: Bug in malloc/free
To: grog@lemis.com (Greg Lehey)
Date: Fri, 19 Sep 1997 23:49:06 +0000 (GMT)
Cc: tlambert@primenet.com, nsmart@iona.com, Don.Lewis@tsc.tdk.com,
        hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
In-Reply-To: <19970920080554.38866@lemis.com> from "Greg Lehey" at Sep 20, 97 08:05:54 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > When a read or write fault occurs on page zero in a program running
> > on SVR4, rather than crashing, they map the page and note the effect.

[ ... ]

> It's not just incorrect, it's inconsistent.  Some SVR4 do, some SVR4
> don't.

Sorry dude, but if it's derived from USL sources, it does this,
unless they've specifically taken it out.  If so, then they are
probably paying a huge royalty increment for the priveledge,
since you pay more (by a factor of 10) for not being exactly their
sources for everything but drivers.

Seems kind of a petty reason to page huge royalties...


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-bugs  Fri Sep 19 17:11:38 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA20095
          for bugs-outgoing; Fri, 19 Sep 1997 17:11:38 -0700 (PDT)
Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA20090;
          Fri, 19 Sep 1997 17:11:36 -0700 (PDT)
Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191])
          by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP
	  id RAA08138; Fri, 19 Sep 1997 17:11:24 -0700 (PDT)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194])
	by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id RAA04031;
	Fri, 19 Sep 1997 17:11:23 -0700 (PDT)
Received: (from gdonl@localhost)
	by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id RAA07321;
	Fri, 19 Sep 1997 17:11:22 -0700 (PDT)
From: Don Lewis 
Message-Id: <199709200011.RAA07321@salsa.gv.tsc.tdk.com>
Date: Fri, 19 Sep 1997 17:11:22 -0700
In-Reply-To: Terry Lambert 
       "Re: Bug in malloc/free" (Sep 19,  3:31pm)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: Terry Lambert , Don.Lewis@tsc.tdk.com (Don Lewis)
Subject: Re: Bug in malloc/free
Cc: hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Sep 19,  3:31pm, Terry Lambert wrote:
} Subject: Re: Bug in malloc/free
} > } Subject: Re: Bug in malloc/free
} > } 
} > } We claim to be sort of POSIX conformant.  Perhaps this is enough.  We
} > } aren't actually POSIX conformant.  All the above "safe" routines may
} > } clobber the global `errno'.
} > 
} > Which is why I save and restore errno in signal handlers.
} 
} Perhaps this should be done by the trampoline code on the user's
} behalf...

Probably, though it's not necessary if the handler only sets a volatile
flag, and it doesn't help those of us who write code that tries to be
portable to environments where signal handlers can trash errno.

			---  Truck

From owner-freebsd-bugs  Fri Sep 19 17:12:18 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA20188
          for bugs-outgoing; Fri, 19 Sep 1997 17:12:18 -0700 (PDT)
Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA20153;
          Fri, 19 Sep 1997 17:12:07 -0700 (PDT)
Received: (from grog@localhost)
	by freebie.lemis.com (8.8.7/8.8.5) id JAA17894;
	Sat, 20 Sep 1997 09:41:55 +0930 (CST)
Message-ID: <19970920094155.13744@lemis.com>
Date: Sat, 20 Sep 1997 09:41:55 +0930
From: Greg Lehey 
To: Terry Lambert 
Cc: nsmart@iona.com, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG,
        freebsd-bugs@FreeBSD.ORG
Subject: Re: Bug in malloc/free
References: <19970920080554.38866@lemis.com> <199709192349.QAA19815@usr04.primenet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81e
In-Reply-To: <199709192349.QAA19815@usr04.primenet.com>; from Terry Lambert on Fri, Sep 19, 1997 at 11:49:06PM +0000
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8250
Fax: +61-8-8388-8250
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Fight-Spam-Now: http://www.cauce.org
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Fri, Sep 19, 1997 at 11:49:06PM +0000, Terry Lambert wrote:
>>> When a read or write fault occurs on page zero in a program running
>>> on SVR4, rather than crashing, they map the page and note the effect.
>
> [ ... ]
>
>> It's not just incorrect, it's inconsistent.  Some SVR4 do, some SVR4
>> don't.
>
> Sorry dude, but if it's derived from USL sources, it does this,
> unless they've specifically taken it out.

If you say so.  Then they've specifically taken it out.

> If so, then they are probably paying a huge royalty increment for
> the priveledge, since you pay more (by a factor of 10) for not being
> exactly their sources for everything but drivers.

*All* the SVR4 systems I know deviate elsewhere than the drivers.

> Seems kind of a petty reason to page huge royalties...

Yes, that's the impression that Tandem had too.  But how can you ship
a product that's full of bugs?

Greg

From owner-freebsd-bugs  Fri Sep 19 18:23:51 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id SAA23686
          for bugs-outgoing; Fri, 19 Sep 1997 18:23:51 -0700 (PDT)
Received: from zeus.xtalwind.net (xtal32.xtalwind.net [205.160.242.83])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA23677;
          Fri, 19 Sep 1997 18:23:46 -0700 (PDT)
Received: from localhost (zeus.xtalwind.net [127.0.0.1])
	by zeus.xtalwind.net (8.8.7/8.8.5) with SMTP id VAA29619;
	Fri, 19 Sep 1997 21:23:29 -0400 (EDT)
Date: Fri, 19 Sep 1997 21:23:29 -0400 (EDT)
From: jack 
X-Sender: jack@zeus.xtalwind.net
To: Greg Lehey 
cc: hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: Bug in malloc/free
In-Reply-To: <19970920094155.13744@lemis.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Sat, 20 Sep 1997, Greg Lehey wrote:

> But how can you ship a product that's full of bugs? 

Bill Gates can certainly answer that question for you.  :)


--------------------------------------------------------------------------
Jack O'Neill                    Finger jacko@diamond.xtalwind.net or  
jack@xtalwind.net               http://www.xtalwind.net/~jacko/pubpgp.html
#include     for my PGP key.
 PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67   FD 09 E9 3C 5F CC EB CD
--------------------------------------------------------------------------


From owner-freebsd-bugs  Fri Sep 19 19:07:18 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA25509
          for bugs-outgoing; Fri, 19 Sep 1997 19:07:18 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA25503;
          Fri, 19 Sep 1997 19:07:07 -0700 (PDT)
From: Peter Wemm 
Received: (from peter@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id TAA20212;
	Fri, 19 Sep 1997 19:03:02 -0700 (PDT)
Date: Fri, 19 Sep 1997 19:03:02 -0700 (PDT)
Message-Id: <199709200203.TAA20212@freefall.freebsd.org>
To: peter@newton.dialix.com.au, peter@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: kern/1744
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: run queue or proc list smashed 4 times in 2 days

State-Changed-From-To: closed-open
State-Changed-By: peter
State-Changed-When: Fri Sep 19 18:57:58 PDT 1997
State-Changed-Why: 
Actually, no, it's not fixed, it happened two days ago on another machine
on a three day old 2.2-stable kernel.  That particular machine regularly
has VM deadlocks.  (It's only got 16MB of ram and running a couple of
incoming sendmails will kill it.  The MaxDaemonChildren sendmail setting
has been lowered to 2 :-( )

From owner-freebsd-bugs  Fri Sep 19 19:41:35 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA27055
          for bugs-outgoing; Fri, 19 Sep 1997 19:41:35 -0700 (PDT)
Received: from nemesis.lonestar.org ([204.178.74.200])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA27049;
          Fri, 19 Sep 1997 19:41:33 -0700 (PDT)
Received: by nemesis.lonestar.org (Smail3.1.27.1 #22)
	id m0xCFSf-000tydC; Fri, 19 Sep 97 21:39 CDT
Message-Id: 
Date: Fri, 19 Sep 97 21:39 CDT
To: phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
From: uhclem@nemesis.lonestar.org (Frank Durda IV)
Sent: Fri Sep 19 1997, 21:39:56 CDT
Subject: Re: bin/1037
Cc: uhclem.ds3@nemesis.lonestar.org
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

[0]Synopsis: 2.x telnetd handles CTRL-M differently than other ttys	FDIV044
[0]State-Changed-From-To: feedback-closed
[0]State-Changed-By: phk
[0]State-Changed-When: Thu Sep 18 23:40:10 PDT 1997
[0]State-Changed-Why: 
[0]
[0]timed out.

Uh, pity you did that without asking.  This item has not been fixed,
despite me providing a one line patch that fixed this and a handfull of
other open PRs (at least two not from me) back in March.   The keeper of
the TCP/IP universe is apparently still sticking to the position that
breaking TELNET clients on many other platforms as well as the one
provided with FreeBSD is OK.

The patch works fine on all releases to date, including engineering
releases as recent as two weeks ago.  I put this patch on every FreeBSD 
system I touch.  I write software for a 43,000 customer ISP and those
machines are being accessed constantly by all sorts of telnet clients, and
the patch seems to solve the problem nicely, and all of those telnet clients
running under Windows, MAC-OS, IRIX, OS/2, and every other brand of UNIX
out there now work just fine, and the keys on their keyboard act as expected.
Without the patch, they ALL screw-up.


Below you will find the mailing list traffic where this specific problem
was last discussed (at least with me being involved).  As of a peek at the
current source tree from two weeks ago, this one line patch has still not
been applied.  Although I can check the change in myself, I would really
rather the keeper of that code address this issue.   I am old fashioned about
scribbling in someone elses code.  But, we are coming up on two years
waiting on this...


Frank Durda IV - only these addresses work:|"The FreeBSD Kevorkian
          | PR resolution system:  Ignore
or             | the fix and then close the PR
These Anti-spam addresses expire Oct. 15th | because it "timed out".


>Date: Tue, 11 Mar 1997 21:30:01 -0800 (PST)
>Message-Id: <199703120530.VAA16850@freefall.freebsd.org>
>To: freebsd-bugs@freefall.freebsd.org
>From: uhclem@nemesis.lonestar.org (Frank Durda IV)
>Subject: re: bin/1037 and bin/771  Patch included
>Reply-To: uhclem@nemesis.lonestar.org (Frank Durda IV)
>Sender: owner-bugs@FreeBSD.ORG
>X-Loop: FreeBSD.org
>Precedence: bulk

The following reply was made to PR bin/1037; it has been noted by GNATS.

>From: uhclem@nemesis.lonestar.org (Frank Durda IV)
>To: mpp@freefall.freebsd.org, bugs@freebsd.org,
>        FreeBSD-gnats-submit@freebsd.org
>Cc: uhclem@nemesis.lonestar.org
>Subject: re: bin/1037 and bin/771  Patch included
>Date: Tue, 11 Mar 97 23:26 CST

 [0]Are you still seeing the problem reported in your FreeBSD problem
 [0]report # 1037?  Have you tried later versions of FreeBSD, such as 
 [0]FreeBSD 2.2 GAMMA or FreeBSD 3.0-current?  Any other information 
 [0]you could provide would be helpful.  If you are still seeing the 
 [0]problem, what version of FreeBSD are you running right now?
 [0]Mike Pritchard
 
 Regarding:
 bin/1037:
 Synopsis:       2.x telnetd handles CTRL-M differently than other ttys	FDIV044
 bin/771:
 Synopsis:	telnet character mode not set and broken when set - FDIV034
 
 
 No, these items remain broken in 2.2-GAMMA, and all releases back to
 at least the 2.1.0-RELEASE.  It worked correctly in 1.1.5.1.
 
 I've been hoping somebody would quit stalling over the religious issues
 here and fix this, but apparently that won't happen after a year on the
 books, so here is a patch that solves the religious issue with a
 technical fix:
 
 
 -----FIX BEGINS-----
 *** telnetd.c.00	Sun Jan 12 15:56:33 1997
 --- telnetd.c	Wed Feb 26 16:07:15 1997
 ***************
 *** 179,184 ****
 --- 179,187 ----
   
   	progname = *argv;
   
 + 	linemode=1;			/*Default to mode that all brands
 + 					  of telnets handle correctly*/
 + 
   #ifdef CRAY
   	/*
   	 * Get number of pty's before trying to process options,
 -----FIX ENDS-----
 
 
 That's it.  The patch works on all telnetds released from 2.1.0
 thru 2.2-GAMMAs and would close bin/771 and bin/1037 if applied.
 It might even resolve bin/1073, but I don't have a way to test that.
 
 
 Discussion
 
 The problem was, is, and apparently will always be that starting with
 2.x, telnetd has wanted to run in LINEMODE by default, because it
 is more efficient in using the TCP/IP transport media than the
 character-at-a-time modes used previously in 1.1.5.1 and earlier
 as well as BSD 4.3.
 
 The problem with that was, is, and will always be that not all TELNET
 clients on all known platforms implement LINEMODE correctly in that
 they don't know about what to do for various action (wakeup)
 control-characters, such as the ones available in csh for command editing
 and completion.  ^D, ^W, ^R, , ^U, etc.   These commands break in
 the presence of LINEMODE in various ways.   To demonstrate, try this simple
 test.
 
 Login into a csh session on a FreeBSD target via the console or
 a serial connection and follow this command sequence:
 
 	% set filec
 	% cd /stand
 	% ls i		should display
 	ifconfig*
 	% ls i		should finish command string:  % ls ifconfig
 	% ls ifconfig	should erase "ifconfig": % ls 
 	% ls 		should redraw on next line: ls
 	ls f		should display
 	find* fsck* ft*
 	% ls fs		should finish "fsck": % ls fsck
 	% ls fsck	should erase: %
 	%
 
 Now telnet into the same system (try "telnet ." if you like and
 see the behavior difference).   Login as the same user and repeat
 the sequence above.
 
 I don't care if you telnet from any FreeBSD 2.x release, SCO UNIX 3.2,
 DEC OSF 3.2G or 4.0B, IRIX V.4, from NETBSD 1.x, Windows '95 TELNET,
 or from NCSA Telnet 2.3.07 (I've tested all of these), they will all
 malfunction telnetting to FreeBSD 2.x, at least until you apply the patch.
 
 The other aspect of the bad behavior of telnetd was shown by two different
 programs provided previously, but I'll repeat one here.  This is code
 pulled from an existing application written in the BSD 4.2/3 days, which
 ran fine on 1.1.5.1 and works on 2.x from the console or serial
 ports, but not via telnet, unless you apply the patch:
 
 -----chars.c-----
 #include 
 #include  
 #include 
 extern char	*ttyname();
 
 static	struct  stat	ttystatus;
 int	stdin_isatty, stdout_isatty;
 char	*ttynam_stdout;
 static  struct	sgttyb	old, new;
 static	struct  stat	ttystatus;
 int	stdin_isatty, stdout_isatty;
 char	*ttynam_stdout;
 
 #define	EOT	'\004'
 static int	eof=EOT,  killc=CTRL('U'),  erase=CTRL('H'),  werase=CTRL('W');
 
 main()
 {
 	char c;
 	printf("Press these keys  [T] [E] [S] [T] [Enter] [CTRL][J] [CTRL][M] [Esc]\n");
 	save_tty();
 	set_tty();
 
 	while((c=getchar())!=EOF && c!=0x1b) {
 		printf("%02x ",c);
 	}
 
 	restore_tty();
 	printf("\nYou should see 74 65 73 74 0a 0a 0a\n");
 }
 
 
 save_tty()
 {
 	struct tchars	tc;
 	struct ltchars t;
 
 	fstat(fileno(stdout), &ttystatus);
 	ttynam_stdout = ttyname(fileno(stdout));
 	stdout_isatty = (ioctl(fileno(stdout), TIOCGETP, &old) >= 0);
 	stdin_isatty = (ioctl(fileno(stdin), TIOCGETP, &old) >= 0);
 	if (ioctl(fileno(stdin), TIOCGLTC, &t) == 0)
 		werase = (int)t.t_werasc;
 
 	killc = (int)old.sg_kill;
 	erase = (int)old.sg_erase;
 	if (ioctl(fileno(stdin), TIOCGETC, &tc) == 0)
 		eof = (int)tc.t_eofc;
 
 	new = old;
 	new.sg_flags |= CBREAK;
 	new.sg_flags &= ~ECHO;
 }
 
 set_tty()
 {
 	ioctl(fileno(stdin), TIOCSETN, &new);
 }
 
 restore_tty()
 {
 	if (stdout_isatty)
 		chmod(ttynam_stdout, (int)ttystatus.st_mode&0777);
 	if (stdin_isatty)
 		ioctl(fileno(stdin), TIOCSETP, &old);
 }
 
 -----END of chars.c-----
 
 Compile this program on FreeBSD, and then execute it and follow
 the instructions.  Telnetting into FreeBSD 2.x without the above
 patch will give incorrect results in that CTRL-J/CTRL-M entered by
 the telnet user are not read as 0x0a by the program as they are when
 the same program is run on a console or serial session.
 
 Running the program with a telnetd that is patched, OR from the console
 or serial ports will work correctly CTRL-M/CTRL-J both are read as 0x0a.
 
 The program also behaves correctly when compiled and run on
 the other platforms mentioned, demonstrating that the problem is in the
 FreeBSD telnetd because it tries to force a mode that the clients can't
 handle correctly.
 
 
 All the patch does is instruct telnetd to negotiate a character mode by
 default that all of the above telnet clients handle correctly.
 If the user wants additional link efficiency at the cost of the
 problems shown above, then by all means he/she can switch to
 LINEMODE once the telnet connection is started if that mode can be used.
 No feature or capability is taken away by the patch.
 
 Yes, we could simply have everybody using every telnet client
 everywhere have to turn off LINEMODE each time they use telnet
 to a FreeBSD platform in order for existing shells and applications
 to work via telnet.  This is the religious argument that all the
 clients everywhere are broken and the FreeBSD telnetd isn't.
 Sorry, but I don't buy this.  We must fit in with the rest of the
 universe.
 
 It still seems that the default setting should provide maximum
 compatibility, which is the case with this patch installed.
 
 
 I recommend that this change be included in 2.2-RELEASE.
 
 

From owner-freebsd-bugs  Fri Sep 19 21:36:28 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA02828
          for bugs-outgoing; Fri, 19 Sep 1997 21:36:28 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA02813;
          Fri, 19 Sep 1997 21:36:08 -0700 (PDT)
From: Peter Wemm 
Received: (from peter@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id VAA23330;
	Fri, 19 Sep 1997 21:32:02 -0700 (PDT)
Date: Fri, 19 Sep 1997 21:32:02 -0700 (PDT)
Message-Id: <199709200432.VAA23330@freefall.freebsd.org>
To: uhclem@nemesis.lonestar.org, peter@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: bin/1037
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: 2.x telnetd handles CTRL-M differently than other ttys		FDIV044

State-Changed-From-To: closed-open
State-Changed-By: peter
State-Changed-When: Fri Sep 19 21:31:03 PDT 1997
State-Changed-Why: 
This is still a problem.

From owner-freebsd-bugs  Fri Sep 19 22:13:14 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA04772
          for bugs-outgoing; Fri, 19 Sep 1997 22:13:14 -0700 (PDT)
Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA04767;
          Fri, 19 Sep 1997 22:13:12 -0700 (PDT)
Received: (from tlambert@localhost)
	by usr02.primenet.com (8.8.5/8.8.5) id WAA17696;
	Fri, 19 Sep 1997 22:12:59 -0700 (MST)
From: Terry Lambert 
Message-Id: <199709200512.WAA17696@usr02.primenet.com>
Subject: Re: Bug in malloc/free
To: grog@lemis.com (Greg Lehey)
Date: Sat, 20 Sep 1997 05:12:58 +0000 (GMT)
Cc: tlambert@primenet.com, nsmart@iona.com, Don.Lewis@tsc.tdk.com,
        hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
In-Reply-To: <19970920094155.13744@lemis.com> from "Greg Lehey" at Sep 20, 97 09:41:55 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> But how can you ship a product that's full of bugs?

At a guess?

Compete with Microsoft, instead of trying to drive all of the other
poor UNIX schmucks out of business instead.  Then you can do what
Microsoft does.

Oh, wait!  That would require adherence to standards, and none of
these idiotic "value added" "standard plus extensions" things that
make it so UNIX from different vendors is not interoperable...
forget I said anything.  8-|.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

From owner-freebsd-bugs  Fri Sep 19 22:22:44 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA05773
          for bugs-outgoing; Fri, 19 Sep 1997 22:22:44 -0700 (PDT)
Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA05740;
          Fri, 19 Sep 1997 22:22:36 -0700 (PDT)
Received: (from grog@localhost)
	by freebie.lemis.com (8.8.7/8.8.5) id OAA23761;
	Sat, 20 Sep 1997 14:52:27 +0930 (CST)
Message-ID: <19970920145226.36630@lemis.com>
Date: Sat, 20 Sep 1997 14:52:26 +0930
From: Greg Lehey 
To: Terry Lambert 
Cc: nsmart@iona.com, Don.Lewis@tsc.tdk.com, hackers@FreeBSD.ORG,
        freebsd-bugs@FreeBSD.ORG
Subject: Re: Bug in malloc/free
References: <19970920094155.13744@lemis.com> <199709200512.WAA17696@usr02.primenet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81e
In-Reply-To: <199709200512.WAA17696@usr02.primenet.com>; from Terry Lambert on Sat, Sep 20, 1997 at 05:12:58AM +0000
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8250
Fax: +61-8-8388-8250
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Fight-Spam-Now: http://www.cauce.org
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Sat, Sep 20, 1997 at 05:12:58AM +0000, Terry Lambert wrote:
>> But how can you ship a product that's full of bugs?
>
> At a guess?
>
> Compete with Microsoft, instead of trying to drive all of the other
> poor UNIX schmucks out of business instead.  Then you can do what
> Microsoft does.

So *that*'s why Tandem has got into bed with Microslop.

> Oh, wait!  That would require adherence to standards, and none of
> these idiotic "value added" "standard plus extensions" things that
> make it so UNIX from different vendors is not interoperable...
> forget I said anything.  8-|.

From owner-freebsd-bugs  Fri Sep 19 22:30:05 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA06755
          for bugs-outgoing; Fri, 19 Sep 1997 22:30:05 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA06746;
          Fri, 19 Sep 1997 22:30:02 -0700 (PDT)
Resent-Date: Fri, 19 Sep 1997 22:30:02 -0700 (PDT)
Resent-Message-Id: <199709200530.WAA06746@hub.freebsd.org>
Resent-From: gnats (GNATS Management)
Resent-To: freebsd-bugs
Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, zhaowu@ee.princeton.edu
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id WAA05819;
          Fri, 19 Sep 1997 22:23:02 -0700 (PDT)
Message-Id: <199709200523.WAA05819@hub.freebsd.org>
Date: Fri, 19 Sep 1997 22:23:02 -0700 (PDT)
From: zhaowu@ee.princeton.edu
To: freebsd-gnats-submit@FreeBSD.ORG
X-Send-Pr-Version: www-1.0
Subject: conf/4586: bugs in network setup
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


>Number:         4586
>Category:       conf
>Synopsis:       bugs in network setup
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Sep 19 22:30:01 PDT 1997
>Last-Modified:
>Originator:     Zhao Wu
>Organization:
Princeton Univ.
>Release:        2.2.2 Release
>Environment:
FreeBSD myname.my.domain 2.2.2-RELEASE FreeBSD 2.2.2-RELEASE #0: Tue May 20 10:45:24 GMT 1997     jkh@time.cdrom.com:/usr/src/sys/compile/GENERIC  i386
>Description:
I have a Dell Pentium II 266. It has a 3C905 etherlink card (PCI).
I installed freeBSD 2.2.2 via FTP without any problem. However, when
I reboot the machine after installation, I found the network didn't
work at all: hostname, domain name, gateway address, ... everything
is unknown. "ifconfig -au" indicated that only loopback is activated.
I tried to use /stand/sysinstall to setup network, but still it didn't
work. Furthermore, something strange appeared in the setup window.
E.g. "myname.my.domain   # Set this!" appeared in the hostname field
and messed things up. I think this is because the installation program
simply extracted the information from /etc/rc.conf without filtering out
comments.
>How-To-Repeat:
Everytime when I install BSD 2.2.2 on my Dell Pentium II
(model: Dimension XPS H266).
>Fix:
manually modify /etc/rc.conf:

1. add 'vx0' to network_interfaces, i.e.
      network_interfaces="lo0 vx0"

2. add ifconfig_vx0
      ifconfig_vx0="inet x.x.x.x netmask y.y.y.y broadcast z.z.z.z"
   where x.x.x.x, y.y.y.y and z.z.z.z refer to your machine IP address,
   netmask and broadcast address respectively.

3. Change hostname from "myname.my.domain" to the hostname of your machine

4. Change defaultrouter from "NO" to the IP address of your router.

5. Reboot
>Audit-Trail:
>Unformatted:

From owner-freebsd-bugs  Sat Sep 20 02:51:21 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA21958
          for bugs-outgoing; Sat, 20 Sep 1997 02:51:21 -0700 (PDT)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA21937;
          Sat, 20 Sep 1997 02:51:16 -0700 (PDT)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id LAA11294; Sat, 20 Sep 1997 11:50:31 +0200
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.7/8.8.5) id LAA12024;
	Sat, 20 Sep 1997 11:39:26 +0200 (MET DST)
Message-ID: <19970920113924.CS57824@uriah.heep.sax.de>
Date: Sat, 20 Sep 1997 11:39:24 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: uhclem@nemesis.lonestar.org (Frank Durda IV)
Cc: phk@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, uhclem.ds3@nemesis.lonestar.org
Subject: Re: bin/1037
References: 
X-Mailer: Mutt 0.60_p2-3,5,8-9
Mime-Version: 1.0
X-Phone: +49-351-2012 669
X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F  93 21 E0 7D F9 12 D6 4E
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
In-Reply-To: ; from Frank Durda IV on Sep 19, 1997 21:39:00 -0600
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

As Frank Durda IV wrote:

> Uh, pity you did that without asking.  This item has not been fixed,
> despite me providing a one line patch that fixed this and a handfull of
> other open PRs (at least two not from me) back in March.

>  -----FIX BEGINS-----
>  *** telnetd.c.00	Sun Jan 12 15:56:33 1997
>  --- telnetd.c	Wed Feb 26 16:07:15 1997
>  ***************
>  *** 179,184 ****
>  --- 179,187 ----
>    
>    	progname = *argv;
>    
>  + 	linemode=1;			/*Default to mode that all brands
>  + 					  of telnets handle correctly*/
>  + 
>    #ifdef CRAY
>    	/*
>    	 * Get number of pty's before trying to process options,
>  -----FIX ENDS-----

I don't see why you not just start your telnetd with `-l', instead of
adding another hack to it.

It's arguable whether we should start it with -l by default, since so
many telnet clients in the world are apparently broken.  But you've
got the option, so why don't you use it in the first place?

-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

From owner-freebsd-bugs  Sat Sep 20 03:40:24 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id DAA28851
          for bugs-outgoing; Sat, 20 Sep 1997 03:40:24 -0700 (PDT)
Received: from spinner.dialix.com.au (spinner.dialix.com.au [202.12.86.3])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA28844;
          Sat, 20 Sep 1997 03:40:12 -0700 (PDT)
Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1])
          by spinner.dialix.com.au with ESMTP id SAA28982;
          Sat, 20 Sep 1997 18:39:17 +0800 (WST)
Message-Id: <199709201039.SAA28982@spinner.dialix.com.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
cc: uhclem@nemesis.lonestar.org (Frank Durda IV), phk@FreeBSD.ORG,
        freebsd-bugs@FreeBSD.ORG, uhclem.ds3@nemesis.lonestar.org
Subject: Re: bin/1037 
In-reply-to: Your message of "Sat, 20 Sep 1997 11:39:24 +0200."
             <19970920113924.CS57824@uriah.heep.sax.de> 
Date: Sat, 20 Sep 1997 18:39:16 +0800
From: Peter Wemm 
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

J Wunsch wrote:
> As Frank Durda IV wrote:
> 
> > Uh, pity you did that without asking.  This item has not been fixed,
> > despite me providing a one line patch that fixed this and a handfull of
> > other open PRs (at least two not from me) back in March.
> 
> >  -----FIX BEGINS-----
> >  *** telnetd.c.00	Sun Jan 12 15:56:33 1997
> >  --- telnetd.c	Wed Feb 26 16:07:15 1997
> >  ***************
> >  *** 179,184 ****
> >  --- 179,187 ----
> >    
> >    	progname = *argv;
> >    
> >  + 	linemode=1;			/*Default to mode that all brands
> >  + 					  of telnets handle correctly*/
> >  + 
> >    #ifdef CRAY
> >    	/*
> >    	 * Get number of pty's before trying to process options,
> >  -----FIX ENDS-----
> 
> I don't see why you not just start your telnetd with `-l', instead of
> adding another hack to it.

No, this is different..  -l sets the "alwayslinemode".  The 'linemode' 
variable does something else.

> It's arguable whether we should start it with -l by default, since so
> many telnet clients in the world are apparently broken.  But you've
> got the option, so why don't you use it in the first place?

The change to the 'linemode' variable default slightly changes telnetd's 
assumptions.  Trying to follow the code is nightmareish, but as best as I 
can tell, it (approximately) causes telnetd to not attempt to initiate 
linemode unless it hears linemode options from the client first.  ie: it 
won't try and *tell* the client to turn it on unless the client is a newer 
one (such as ours) that initiates the linemode handshaking.  As I said, I 
do not understand the state processing, so I'm not sure.

> -- 
> cheers, J"org
> 
> joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
> Never trust an operating system you don't have sources for. ;-)
> 

Cheers,
-Peter



From owner-freebsd-bugs  Sat Sep 20 04:21:54 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA00432
          for bugs-outgoing; Sat, 20 Sep 1997 04:21:54 -0700 (PDT)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA00416;
          Sat, 20 Sep 1997 04:21:44 -0700 (PDT)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id NAA12443; Sat, 20 Sep 1997 13:20:27 +0200
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.7/8.8.5) id MAA04489;
	Sat, 20 Sep 1997 12:55:42 +0200 (MET DST)
Message-ID: <19970920125541.KG31358@uriah.heep.sax.de>
Date: Sat, 20 Sep 1997 12:55:41 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: peter@spinner.dialix.com.au (Peter Wemm)
Cc: uhclem@nemesis.lonestar.org (Frank Durda IV), phk@FreeBSD.ORG,
        freebsd-bugs@FreeBSD.ORG, uhclem.ds3@nemesis.lonestar.org
Subject: Re: bin/1037
References: <19970920113924.CS57824@uriah.heep.sax.de> <199709201039.SAA28982@spinner.dialix.com.au>
X-Mailer: Mutt 0.60_p2-3,5,8-9
Mime-Version: 1.0
X-Phone: +49-351-2012 669
X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F  93 21 E0 7D F9 12 D6 4E
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
In-Reply-To: <199709201039.SAA28982@spinner.dialix.com.au>; from Peter Wemm on Sep 20, 1997 18:39:16 +0800
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

As Peter Wemm wrote:

> > I don't see why you not just start your telnetd with `-l', instead of
> > adding another hack to it.
> 
> No, this is different..  -l sets the "alwayslinemode".  The 'linemode' 
> variable does something else.

Ok, explanation sold. :)  But then, my vote is still to make it another
option (-L perhaps).

-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

From owner-freebsd-bugs  Sat Sep 20 04:30:04 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA00838
          for bugs-outgoing; Sat, 20 Sep 1997 04:30:04 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA00831;
          Sat, 20 Sep 1997 04:30:01 -0700 (PDT)
Date: Sat, 20 Sep 1997 04:30:01 -0700 (PDT)
Message-Id: <199709201130.EAA00831@hub.freebsd.org>
To: freebsd-bugs
Cc: 
From: j@uriah.heep.sax.de (J Wunsch)
Subject: Re: bin/4585: termcap search fails too early
Reply-To: j@uriah.heep.sax.de (J Wunsch)
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR bin/4585; it has been noted by GNATS.

From: j@uriah.heep.sax.de (J Wunsch)
To: arnej@math.ntnu.no
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/4585: termcap search fails too early
Date: Sat, 20 Sep 1997 13:19:43 +0200

 As arnej@math.ntnu.no wrote:
 
 > Patch from NetBSD:
 > 
 > Index: src/lib/libc/gen/getcap.c
 > ===================================================================
 > RCS file: /usr/cvs/src/lib/libc/gen/getcap.c,v
 > retrieving revision 1.4
 > diff -u -r1.4 getcap.c
 > --- getcap.c	1995/10/22 14:36:15	1.4
 > +++ getcap.c	1997/09/19 21:26:27
 > @@ -269,10 +269,7 @@
 >  				fd = open(*db_p, O_RDONLY, 0);
 >  				if (fd < 0) {
 >  					/* No error on unfound file. */
 > -					if (errno == ENOENT)
 > -						continue;
 > -					free(record);
 > -					return (-2);
 > +					continue;
 >  				}
 >  				myfd = 1;
 >  			}
 
 Why would it be wrong to make it continue only in the ENOENT and
 EACCES?  Maybe ELOOP, too.  Something like EMFILE or ENFILE should for
 sure be treated as an error in the first place.
 
 -- 
 cheers, J"org
 
 joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
 Never trust an operating system you don't have sources for. ;-)

From owner-freebsd-bugs  Sat Sep 20 05:20:04 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA02446
          for bugs-outgoing; Sat, 20 Sep 1997 05:20:04 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA02418;
          Sat, 20 Sep 1997 05:20:02 -0700 (PDT)
Resent-Date: Sat, 20 Sep 1997 05:20:02 -0700 (PDT)
Resent-Message-Id: <199709201220.FAA02418@hub.freebsd.org>
Resent-From: gnats (GNATS Management)
Resent-To: freebsd-bugs
Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, wosch@cs.tu-berlin.de
Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA02327
          for ; Sat, 20 Sep 1997 05:18:33 -0700 (PDT)
Received: from panke.panke.de (anonymous217.ppp.cs.tu-berlin.de [130.149.17.217])
	by mail.cs.tu-berlin.de (8.8.6/8.8.6) with ESMTP id OAA27782
	for ; Sat, 20 Sep 1997 14:13:59 +0200 (MET DST)
Received: (from wosch@localhost) by panke.panke.de (8.8.5/8.6.12) id OAA01321; Sat, 20 Sep 1997 14:06:11 +0200 (MET DST)
Message-Id: <199709201206.OAA01321@panke.panke.de>
Date: Sat, 20 Sep 1997 14:06:11 +0200 (MET DST)
From: Wolfram Schneider 
Reply-To: wosch@cs.tu-berlin.de
To: FreeBSD-gnats-submit@FreeBSD.ORG
X-Send-Pr-Version: 3.2
Subject: bin/4587: bad implemented dot support in chown(8)
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


>Number:         4587
>Category:       bin
>Synopsis:       bad implemented dot support in chown(8)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Sep 20 05:20:01 PDT 1997
>Last-Modified:
>Originator:     Wolfram Schneider
>Organization:
>Release:        FreeBSD 2.2-RELEASE i386
>Environment:


Chown(8) compiled with -DSUPPORT_DOT (backward compatibility) does
first check for a `.' and then for `:' as a delimiter. 
Usernames with a dot will fail.

# chown r.r:bin /tmp/bla
chown: r:bin: illegal group name


Fix: first check for a `:' and then for a `.'

Index: chown.c
===================================================================
RCS file: /usr/cvs/src/usr.sbin/chown/chown.c,v
retrieving revision 1.4
diff -u -r1.4 chown.c
--- chown.c	1996/08/14 18:13:58	1.4
+++ chown.c	1997/09/20 11:30:12
@@ -136,16 +136,16 @@
 
 	uid = gid = -1;
 	if (ischown) {
-#ifdef SUPPORT_DOT
-		if ((cp = strchr(*argv, '.')) != NULL) {
+		if ((cp = strchr(*argv, ':')) != NULL) {
 			*cp++ = '\0';
 			a_gid(cp);
-		} else
-#endif
-		if ((cp = strchr(*argv, ':')) != NULL) {
+		}
+#ifdef SUPPORT_DOT
+		else if ((cp = strchr(*argv, '.')) != NULL) {
 			*cp++ = '\0';
 			a_gid(cp);
 		}
+#endif
 		a_uid(*argv);
 	} else
 		a_gid(*argv);


>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:
>Unformatted:

From owner-freebsd-bugs  Sat Sep 20 05:58:06 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA03677
          for bugs-outgoing; Sat, 20 Sep 1997 05:58:06 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA03672;
          Sat, 20 Sep 1997 05:58:01 -0700 (PDT)
From: "Jordan K. Hubbard" 
Received: (from jkh@localhost)
	by freefall.freebsd.org (8.8.6/8.8.5) id FAA27928;
	Sat, 20 Sep 1997 05:53:52 -0700 (PDT)
Date: Sat, 20 Sep 1997 05:53:52 -0700 (PDT)
Message-Id: <199709201253.FAA27928@freefall.freebsd.org>
To: zhaowu@ee.princeton.edu, jkh@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG
Subject: Re: conf/4586
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Synopsis: bugs in network setup

State-Changed-From-To: open-closed
State-Changed-By: jkh
State-Changed-When: Sat Sep 20 05:53:42 PDT 1997
State-Changed-Why: 
Fixed in subsequent releases.

From owner-freebsd-bugs  Sat Sep 20 06:16:19 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA04434
          for bugs-outgoing; Sat, 20 Sep 1997 06:16:19 -0700 (PDT)
Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA04422;
          Sat, 20 Sep 1997 06:16:15 -0700 (PDT)
Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id GAA27085; Sat, 20 Sep 1997 06:14:30 -0700 (PDT)
To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
cc: peter@spinner.dialix.com.au (Peter Wemm),
        uhclem@nemesis.lonestar.org (Frank Durda IV), phk@FreeBSD.ORG,
        freebsd-bugs@FreeBSD.ORG, uhclem.ds3@nemesis.lonestar.org
Subject: Re: bin/1037 
In-reply-to: Your message of "Sat, 20 Sep 1997 12:55:41 +0200."
             <19970920125541.KG31358@uriah.heep.sax.de> 
Date: Sat, 20 Sep 1997 06:14:30 -0700
Message-ID: <27081.874761270@time.cdrom.com>
From: "Jordan K. Hubbard" 
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Given the extent of Frank's negative experience with the non-changed
telnet and positive experiences with the changed one, I think it'd be
more than reasonable to add a flag which turns it *off* and uses the
settings he suggests as the default.  That way you still have your
escape hatch in case it causes dysfunction in some corner case yet all
those Windows puppies are happy in the OOB configuration.

Also, since nobody seems to care *too* much about this or we'd have
settled it in less than 2 years time, why not just let Frank commit it
and also take any of the potential heat if it doesn't work?  That'd
be the best "See, we *were* right about that default!" rebuttal of
them all. ;-)

					Jordan

> As Peter Wemm wrote:
> 
> > > I don't see why you not just start your telnetd with `-l', instead of
> > > adding another hack to it.
> > 
> > No, this is different..  -l sets the "alwayslinemode".  The 'linemode' 
> > variable does something else.
> 
> Ok, explanation sold. :)  But then, my vote is still to make it another
> option (-L perhaps).
> 
> -- 
> cheers, J"org
> 
> joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
> Never trust an operating system you don't have sources for. ;-)


From owner-freebsd-bugs  Sat Sep 20 06:47:36 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA05672
          for bugs-outgoing; Sat, 20 Sep 1997 06:47:36 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA05624;
          Sat, 20 Sep 1997 06:47:16 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id XAA26010; Sat, 20 Sep 1997 23:45:16 +1000
Date: Sat, 20 Sep 1997 23:45:16 +1000
From: Bruce Evans 
Message-Id: <199709201345.XAA26010@godzilla.zeta.org.au>
To: bde@zeta.org.au, grog@lemis.com
Subject: Re: Bug in malloc/free
Cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com,
        hackers@FreeBSD.ORG, julian@whistle.com, mike@smith.net.au,
        phk@critter.freebsd.dk
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>>>	"coredump, right now, no ifs, whens or buts. Thank you."
>>
>> A new signal, like SIGKILL except it generates cores, would be useful.
>> We would have to fix all the assumptions that sigset_t == int to make
>> room for another signal number.
>
>Is that really so important?  You can call sigaction from a signal
>handler, so you can unmask the signal before calling it.  A new signal
>for the sake of a couple of lines of library code?

Only broken libraries could do that, since if a signal is masked then
something must want it masked.

Bruce

From owner-freebsd-bugs  Sat Sep 20 07:53:13 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id HAA08365
          for bugs-outgoing; Sat, 20 Sep 1997 07:53:13 -0700 (PDT)
Received: from sax.sax.de (sax.sax.de [193.175.26.33])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA08357;
          Sat, 20 Sep 1997 07:53:09 -0700 (PDT)
Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id QAA13798; Sat, 20 Sep 1997 16:51:35 +0200
Received: (from j@localhost)
	by uriah.heep.sax.de (8.8.7/8.8.5) id QAA00372;
	Sat, 20 Sep 1997 16:48:11 +0200 (MET DST)
Message-ID: <19970920164809.GY16922@uriah.heep.sax.de>
Date: Sat, 20 Sep 1997 16:48:09 +0200
From: j@uriah.heep.sax.de (J Wunsch)
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Cc: peter@spinner.dialix.com.au (Peter Wemm),
        uhclem@nemesis.lonestar.org (Frank Durda IV), phk@FreeBSD.ORG,
        freebsd-bugs@FreeBSD.ORG, uhclem.ds3@nemesis.lonestar.org
Subject: Re: bin/1037
References: <19970920125541.KG31358@uriah.heep.sax.de> <27081.874761270@time.cdrom.com>
X-Mailer: Mutt 0.60_p2-3,5,8-9
Mime-Version: 1.0
X-Phone: +49-351-2012 669
X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F  93 21 E0 7D F9 12 D6 4E
Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
In-Reply-To: <27081.874761270@time.cdrom.com>; from Jordan K. Hubbard on Sep 20, 1997 06:14:30 -0700
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

As Jordan K. Hubbard wrote:

> Also, since nobody seems to care *too* much about this or we'd have
> settled it in less than 2 years time, why not just let Frank commit it
> and also take any of the potential heat if it doesn't work?

Since this already turned into a typical proof of the Parkinson law, i
don't object against this either.

-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

From owner-freebsd-bugs  Sat Sep 20 08:04:21 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA09075
          for bugs-outgoing; Sat, 20 Sep 1997 08:04:21 -0700 (PDT)
Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA09065;
          Sat, 20 Sep 1997 08:04:15 -0700 (PDT)
Received: from greenpeace.grondar.za (greenpeace.grondar.za [196.7.18.132])
	by gratis.grondar.za (8.8.7/8.8.7) with ESMTP id RAA25876;
	Sat, 20 Sep 1997 17:04:09 +0200 (SAT)
Received: from greenpeace.grondar.za (localhost [127.0.0.1])
	by greenpeace.grondar.za (8.8.7/8.8.7) with ESMTP id RAA11350;
	Sat, 20 Sep 1997 17:04:41 +0200 (SAT)
Message-Id: <199709201504.RAA11350@greenpeace.grondar.za>
X-Mailer: exmh version 2.0zeta 7/24/97
To: "Jordan K. Hubbard" 
cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch),
        peter@spinner.dialix.com.au (Peter Wemm),
        uhclem@nemesis.lonestar.org (Frank Durda IV), phk@FreeBSD.ORG,
        freebsd-bugs@FreeBSD.ORG, uhclem.ds3@nemesis.lonestar.org
Subject: Re: bin/1037 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 20 Sep 1997 17:04:36 +0200
From: Mark Murray 
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

"Jordan K. Hubbard" wrote:
> Also, since nobody seems to care *too* much about this or we'd have
> settled it in less than 2 years time, why not just let Frank commit it
> and also take any of the potential heat if it doesn't work?  That'd
> be the best "See, we *were* right about that default!" rebuttal of
> them all. ;-)

Please make sure the diffs get entered into crypto telnet as well :-)

M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org



From owner-freebsd-bugs  Sat Sep 20 08:30:04 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA10257
          for bugs-outgoing; Sat, 20 Sep 1997 08:30:04 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA10248;
          Sat, 20 Sep 1997 08:30:02 -0700 (PDT)
Resent-Date: Sat, 20 Sep 1997 08:30:02 -0700 (PDT)
Resent-Message-Id: <199709201530.IAA10248@hub.freebsd.org>
Resent-From: gnats (GNATS Management)
Resent-To: freebsd-bugs
Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, hsu@mail.clinet.fi
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA10110
          for ; Sat, 20 Sep 1997 08:26:16 -0700 (PDT)
Received: from zetor.clinet.fi (root@zetor.clinet.fi [194.100.0.11])
	by hauki.clinet.fi (8.8.6/8.8.6) with ESMTP id SAA04431
	for ; Sat, 20 Sep 1997 18:25:43 +0300 (EET DST)
Received: (hsu@localhost) by zetor.clinet.fi (8.8.7/8.6.4) id SAA23098; Sat, 20 Sep 1997 18:25:42 +0300 (EEST)
Message-Id: <199709201525.SAA23098@zetor.clinet.fi>
Date: Sat, 20 Sep 1997 18:25:42 +0300 (EEST)
From: Heikki Suonsivu 
Reply-To: hsu@mail.clinet.fi
To: FreeBSD-gnats-submit@FreeBSD.ORG
X-Send-Pr-Version: 3.2
Subject: kern/4588: NFS access locks up
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


>Number:         4588
>Category:       kern
>Synopsis:       NFS access locks up
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Sep 20 08:30:01 PDT 1997
>Last-Modified:
>Originator:     Heikki Suonsivu
>Organization:
Clinet, Espoo, Finland
>Release:        FreeBSD 2.2-STABLE i386
>Environment:

FreeBSD-2.2, mostly late STABLE kernels but this seems to have been around
for some time.  These are usually SCSI, either NCR or 2940 configurations,
with 64M to 128M of memory, Pentiums from 133MHz and up.

>Description:

NFS clients deadlock on something, directories or files.  Nothing kills the
processes, not even kill -9.  For some reason the files are almost always
files which are WWW server related, but not necessarily on WWW server's
disks.  So it is access logs and users WWW directories which lock up.  It
could be either the directory or one of the files in the directory which go
into this state.  I think the reason for WWW stuff to lock up is related to
usage pattern, as we have seen the problem with other files, just it has
been rare.

Usually rebooting the client fixes it temporarily, but some cases it won't.
In particular if it failed when user was using microsoft frontpage to
update the contents of the directory, it usually locks the directory up
again as soon as he tries to update the pages after the reboot.

It seems to be the client which is the problem, as while some clients lock
up reading the file/directory I can still see it from other nfs clients.

ps axuwwwl:

USER       PID %CPU %MEM   VSZ  RSS  TT  STAT STARTED       TIME COMMAND            UID   PID  PPID CPU PRI NI   VSZ  RSS WCHAN  STAT  TT       TIME COMMAND
hsu       9170  0.0  0.3   228  208  p0  D+    5:27PM    0:00.03 less access_log.   105  9170 20972   1  -4  0   228  208 nfsvin D+    p0    0:00.03 less access_log.874368000
hsu      19077  0.0  0.1   196   68  p7  R+    6:08PM    0:00.01 egrep (less|USER   105 19077 18879   3  28  0   196   68 -      R+    p7    0:00.01 egrep (less|USER)

fstat:

hsu      less        9170   wd /m/varasto/usr  21696 drwxr-xr-x     512  r
hsu      less        9170 text /usr       9064 -r-xr-xr-x   73728  r
hsu      less        9170    0 /          4189 crw--w----   ttyp0 rw
hsu      less        9170    1 /          4189 crw--w----   ttyp0 rw
hsu      less        9170    2 /          4189 crw--w----   ttyp0 rw
hsu      less        9170    3 /          3993 crw-rw-rw-     tty  r

I cannot get sensible tcpdump unless I know how to look for a specific
thing, the nfs server is very busy.  Any ideas what to look for ? 

>How-To-Repeat:

Busy clients seem to exhibit this more frequently.

>Fix:
	
-- 
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@clinet.fi
mobile +358-40-5519679 work +358-9-43542270 fax -4555276
>Audit-Trail:
>Unformatted:

From owner-freebsd-bugs  Sat Sep 20 09:04:48 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA12197
          for bugs-outgoing; Sat, 20 Sep 1997 09:04:48 -0700 (PDT)
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA12191;
          Sat, 20 Sep 1997 09:04:44 -0700 (PDT)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.8.5/8.8.5) id MAA04486;
	Sat, 20 Sep 1997 12:04:26 -0400 (EDT)
Date: Sat, 20 Sep 1997 12:04:26 -0400 (EDT)
From: Garrett Wollman 
Message-Id: <199709201604.MAA04486@khavrinen.lcs.mit.edu>
To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
Cc: jkh@time.cdrom.com (Jordan K. Hubbard),
        peter@spinner.dialix.com.au (Peter Wemm),
        uhclem@nemesis.lonestar.org (Frank Durda IV), phk@FreeBSD.ORG,
        freebsd-bugs@FreeBSD.ORG, uhclem.ds3@nemesis.lonestar.org
Subject: Re: bin/1037
In-Reply-To: <19970920164809.GY16922@uriah.heep.sax.de>
References: <19970920125541.KG31358@uriah.heep.sax.de>
	<27081.874761270@time.cdrom.com>
	<19970920164809.GY16922@uriah.heep.sax.de>
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

< As Jordan K. Hubbard wrote:
>> Also, since nobody seems to care *too* much about this or we'd have
>> settled it in less than 2 years time, why not just let Frank commit it
>> and also take any of the potential heat if it doesn't work?

> Since this already turned into a typical proof of the Parkinson law, i
> don't object against this either.

Actually, I have a small problem with it.  However. I don't have any
better solution, but we should keep in mind that the proposed fix is a
hackaround for a more serious problem, that being a fairly fundamental
difference between TELNET's LINEMODE and POSIX's !ICANON + ISIG mode
works for programs such as csh (and also emacs in certain modes).  I
would prefer a more sophisticated approach that attempted to divine
more carefully which was the most useful behavior.  Certainly straight
ICANON|ISIG mode should still invoke LINEMODE and not the ancient old
line-at-a-time mode.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
wollman@lcs.mit.edu  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick

From owner-freebsd-bugs  Sat Sep 20 10:40:04 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id KAA17739
          for bugs-outgoing; Sat, 20 Sep 1997 10:40:04 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id KAA17699;
          Sat, 20 Sep 1997 10:40:01 -0700 (PDT)
Resent-Date: Sat, 20 Sep 1997 10:40:01 -0700 (PDT)
Resent-Message-Id: <199709201740.KAA17699@hub.freebsd.org>
Resent-From: gnats (GNATS Management)
Resent-To: freebsd-bugs
Resent-Reply-To: FreeBSD-gnats@FreeBSD.ORG, beckmann@nacamar.net
Received: from ns.nacamar.net (ns.nacamar.net [194.162.162.194])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA17633
          for ; Sat, 20 Sep 1997 10:38:59 -0700 (PDT)
Received: (from petzi@localhost)
	by ns.nacamar.net (8.8.6/8.8.5) id TAA02243;
	Sat, 20 Sep 1997 19:38:51 +0200 (MET DST)
Message-Id: <199709201738.TAA02243@ns.nacamar.net>
Date: Sat, 20 Sep 1997 19:38:51 +0200 (MET DST)
From: petzi@nacamar.net
Reply-To: beckmann@nacamar.net
To: FreeBSD-gnats-submit@FreeBSD.ORG
X-Send-Pr-Version: 3.2
Subject: kern/4589: de0: abnormal interrupt: receive process stopped
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


>Number:         4589
>Category:       kern
>Synopsis:       de driver error message during boot
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Sep 20 10:40:00 PDT 1997
>Last-Modified:
>Originator:     Michael Beckmann
>Organization:
Nacamar
>Release:        FreeBSD 2.2-970918-RELENG i386
>Environment:

	Recent versions of 2.2-RELENG
	PCI Ethernet card driven by de driver

>Description:

	When compiling a kernel with MAXMEM set to (128*1024) or (256*1024),
	an error message occurs during boot of the system:

	/kernel: de0  rev 17 int a irq 10 on pci0:9
	/kernel: de0: 21041 [10Mb/s] pass 1.1
	/kernel: de0: address 00:00:c0:94:e7:f8
	/kernel: de0: enabling 10baseT port
	/kernel: de0: abnormal interrupt: receive process stopped
	
	
	This message does not occur when the kernel was compiled without the
	MAXMEM option.

>How-To-Repeat:
	
	Problem occurs in various tested hardware confugurations.
	Ethernet cards used were various revisions of SMC EtherPower 10 Combo

	Typical kernel config file to reproduce the problem:
	


#       $Id: GENERIC,v 1.77.2.10 1997/06/06 12:24:17 jkh Exp $

machine         "i386"
cpu             "I586_CPU"
cpu             "I686_CPU"
ident           BLAH
maxusers        128

options         INET                    #InterNETworking
options         FFS                     #Berkeley Fast Filesystem
options         PROCFS                  #Process filesystem
options         "COMPAT_43"             #Compatible with BSD 4.3 [KEEP THIS!]
options         SCSI_DELAY=15           #Be pessimistic about Joe SCSI device
#options                BOUNCE_BUFFERS          #include support for DMA bounce buffers
options         UCONSOLE                #Allow users to grab the console
options         FAILSAFE                #Be conservative
options         USERCONFIG              #boot -c editor
options         VISUAL_USERCONFIG       #visual boot -c editor
options         "MAXMEM=(128*1024)"

config          kernel  root on sd0

controller      isa0
controller      pci0

controller      fdc0    at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
disk            fd0     at fdc0 drive 0

# A single entry for any of these controllers (ncr, ahb, ahc, amd) is
# sufficient for any number of installed devices.
controller      ncr0

controller      scbus0

device          sd0

# syscons is the default console driver, resembling an SCO console
device          sc0     at isa? port "IO_KBD" tty irq 1 vector scintr

# Mandatory, don't remove
device          npx0    at isa? port "IO_NPX" flags 0x1 irq 13 vector npxintr


device          sio0    at isa? port "IO_COM1" tty irq 4 vector siointr
device          sio1    at isa? port "IO_COM2" tty irq 3 vector siointr

device de0

pseudo-device   loop
pseudo-device   ether
pseudo-device   log
pseudo-device   vn      1
pseudo-device   pty     16
pseudo-device   gzip            # Exec gzipped a.out's
pseudo-device   bpf     2


>Fix:
	

>Audit-Trail:
>Unformatted:

From owner-freebsd-bugs  Sat Sep 20 17:00:08 1997
Return-Path: 
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA03085
          for bugs-outgoing; Sat, 20 Sep 1997 17:00:08 -0700 (PDT)
Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA03070;
          Sat, 20 Sep 1997 17:00:02 -0700 (PDT)
Received: (from grog@localhost)
	by freebie.lemis.com (8.8.7/8.8.5) id JAA02354;
	Sun, 21 Sep 1997 09:28:56 +0930 (CST)
Message-ID: <19970921092855.07004@lemis.com>
Date: Sun, 21 Sep 1997 09:28:55 +0930
From: Greg Lehey 
To: Bruce Evans 
Cc: atrens@nortel.ca, freebsd-bugs@FreeBSD.ORG, gram@cdsec.com,
        hackers@FreeBSD.ORG, julian@whistle.com, mike@smith.net.au,
        phk@critter.freebsd.dk
Subject: Re: Bug in malloc/free
References: <199709201345.XAA26010@godzilla.zeta.org.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81e
In-Reply-To: <199709201345.XAA26010@godzilla.zeta.org.au>; from Bruce Evans on Sat, Sep 20, 1997 at 11:45:16PM +1000
Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8250
Fax: +61-8-8388-8250
Mobile: +61-41-739-7062
WWW-Home-Page: http://www.lemis.com/~grog
Fight-Spam-Now: http://www.cauce.org
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Sat, Sep 20, 1997 at 11:45:16PM +1000, Bruce Evans wrote:
>>>>	"coredump, right now, no ifs, whens or buts. Thank you."
>>>
>>> A new signal, like SIGKILL except it generates cores, would be useful.
>>> We would have to fix all the assumptions that sigset_t == int to make
>>> room for another signal number.
>>
>> Is that really so important?  You can call sigaction from a signal
>> handler, so you can unmask the signal before calling it.  A new signal
>> for the sake of a couple of lines of library code?
>
> Only broken libraries could do that, since if a signal is masked then
> something must want it masked.

If a signal is masked, it's reasonable to assume that the something
that wants it masked is also planning to continue execution.  If our
library function has decided that we want a complete, unconditional
termination of the process, then by definition it has priority.
There's really no difference between doing it this way and adding
another signal, except that the latter adds to kernel bloat.

Greg