> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of JINMEI Tatuya / ???? > Sent: Thursday, August 07, 2008 2:19 PM > To: Vinny Abello > Cc: [email protected] > Subject: Re: dnsperf and BIND memory consumption > > At Thu, 7 Aug 2008 10:33:25 -0400, > Vinny Abello <[EMAIL PROTECTED]> wrote: > > > > > ======================================================================= > > > - create a symbolic link from "/etc/malloc.conf" to "X": > > > # ln -s X /etc/malloc.conf > > > > What exactly is this trying to accomplish here? JFYI, I don't have a > file /etc/malloc.conf on my server. Did you mean /etc/make.conf? Where > is X being referenced? > > /etc/malloc.conf normally doesn't exist. You should create a new > symbolic link. For other details, see malloc(3). > > > > - start named with a moderate limitation of virtual memory size, > e.g. > > > # /usr/bin/limits -v 384m $path_to_named/named <command line > options> > > > > > > Then the named process will eventually abort itself with a core > dump > > > due to malloc failure. Please show us the stack trace at that > point. > > > Hopefully it will reveal the malloc call that keeps consuming > memory. > > > > How would I show the trace that you require once this happens? > > named will die with a core file. Then perform the following: > > # gdb <path_to_named> <path_to_core> > (gdb) thread apply all bt full
Apparently I got halfway there. I stumbled across the core file a while ago which I didn't realize was created, but had already downgraded so no longer had the original binary to use with gdb. I'll try this on another machine that I will be setting up. I think I should be able to get this data now. -Vinny
