From owner-freebsd-hackers  Tue Feb 25 05:46:52 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id FAA22073
          for hackers-outgoing; Tue, 25 Feb 1997 05:46:52 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA22067
          for <freebsd-hackers@freefall.freebsd.org>; Tue, 25 Feb 1997 05:46:47 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id AAA10884; Wed, 26 Feb 1997 00:42:13 +1100
Date: Wed, 26 Feb 1997 00:42:13 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199702251342.AAA10884@godzilla.zeta.org.au>
To: freebsd-hackers@freefall.freebsd.org, nao@sbl.cl.nec.co.jp
Subject: Re: MALLOC(3) writes to stderr...
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>How should we deal with this anomaly? Yep, fixing jserver's memory
>allocation thoroughly might be the ultimate solution, but we need a
>practical solution for now. Must we change jserver to keep stderr open
>and to put error messages into /var/log/jserver.log or something? Or
>make malloc(3) keep silent?

Library routines shouldn't write to std* unless instructed to.  There
should be a malloc option to control the behaviour.  However, malloc()
only seems to print to stderr after severe errors that might have caused
a core dump on other systems.

Bruce