From owner-freebsd-hackers Fri Oct 13 04:06:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA26126 for hackers-outgoing; Fri, 13 Oct 1995 04:06:47 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA26120 for ; Fri, 13 Oct 1995 04:06:44 -0700 Received: from exalt.x.org by expo.x.org id AA10103; Fri, 13 Oct 95 07:03:33 -0400 Received: from localhost by exalt.x.org id HAA05408; Fri, 13 Oct 1995 07:03:31 -0400 Message-Id: <199510131103.HAA05408@exalt.x.org> To: hackers@freefall.FreeBSD.org Cc: asami@cs.berkeley.edu, phk@critter.tfs.com Subject: Re: xload dumps core with new phkmalloc In-Reply-To: Your message of Fri, 13 Oct 1995 10:14:59 EST. <1260.813575699@critter.tfs.com> Organization: X Consortium Date: Fri, 13 Oct 1995 07:03:31 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk >> Poul-Henning sent me his malloc and xload works fine for me with >> MALLOC_OPTIONS=Z. To which Poul-Henning said: >You need to set MALLOC_OPTIONS=J, 'Z' means zero the allocation, >'J' means 'junk'. And Satoshi said: >That means it's not fine. :) >MALLOC_OPTIONS=Z means malloc acts like calloc. X libs shouldn't >depend on that. Yeah, well, forgive me for not spelling everything out in nauseous detail; after spending hours building and rebuilding libraries (and finding nothing wrong) I wasn't feeling particularly loquacious. I tried Z, J, and nothing; xload works fine for me using phkmalloc. X libraries do *not* depend on the memory being zeroed. -- Kaleb KEITHLEY