From owner-freebsd-hackers Mon May 18 19:18:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA12887 for freebsd-hackers-outgoing; Mon, 18 May 1998 19:18:21 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA12787 for ; Mon, 18 May 1998 19:17:38 -0700 (PDT) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.8) with ESMTP id TAA08741; Mon, 18 May 1998 19:17:31 -0700 (PDT) (envelope-from jdp) Message-Id: <199805190217.TAA08741@austin.polstra.com> To: chuckr@glue.umd.edu Subject: Re: g++ new allocator In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Cc: hackers@FreeBSD.ORG Date: Mon, 18 May 1998 19:17:31 -0700 From: John Polstra Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Chuck Robey wrote: > On Sun, 17 May 1998, Greg Lehey wrote: > > > On Sat, 16 May 1998 at 10:20:38 -0400, Chuck Robey wrote: > > > Does anyone know if the "new" operator, using g++, uses it's own > > > allocator, or PHK's libc malloc? I have a problem I'm trying to shoot > > > that uses the libstdc++ and sigbus's, and I was wondering which route > > > the code is going. > > > > My understanding is that it uses whichever malloc is bound in with the > > executable. > > ... Umm ... it's built using our libstdc++ (I just compiled it). The > question is what malloc does the g++ using our own libstdc++ (on > current, actually) use? I didn't post this to current because I didn't > think it applied only to current. > > I guess I don't understand what you mean by "whichever malloc is bound > in with the executable", if I'm doing the binding here. I'm 99% certain it uses malloc. But you can easily find out for sure with a simple experiment. Create a tiny C++ program that allocates something with "new". Compile it for debugging. Run it under the debugger and set a breakpoint on "malloc". Look at the stack trace and see whether it's being called from new. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message