From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 28 20:22:02 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9771137 for ; Mon, 28 Jul 2014 20:22:02 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CA882D77 for ; Mon, 28 Jul 2014 20:22:02 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id b13so7811028wgh.34 for ; Mon, 28 Jul 2014 13:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=keFzr7viVrH1MSUgnXMp3pIRk3T6MCgdldlvANIGHhM=; b=ZCDQiuPn9rVt3lpxtRS4vRRE2FdkfLK0TyNKd8ujp+2QMUiSGvtqQ1CMsx+aoTNbI6 C9CTbDjuE3sfW8t5pZlf/OSHyxi7Ug7GLCOuw6cJqV9n7AsnIP/fMP/mthgiRLJsTz5E 7HCMhpk2TMFBUTCyF8vOjzn73F+TSQEWbIQqqyI0m79vvhpdRxPDGlAqBTxPcxPtYCKW PUp+TMzbKQj3ke2S6J9HfU5ERCXk5d3kS7iNuIVgbK9r+4J2E41J6dDZakkxw+yiL1Eu ZjtSvD12PmD3zViRza3cyWzVzLN+4BMghD2k5Sr2/HpkzwfmEP+n3RW8SnyTJfIjMesD 6Usg== X-Received: by 10.194.158.101 with SMTP id wt5mr15818144wjb.136.1406578919417; Mon, 28 Jul 2014 13:21:59 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id n2sm51935175wjf.40.2014.07.28.13.21.58 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 28 Jul 2014 13:21:58 -0700 (PDT) Date: Mon, 28 Jul 2014 22:21:56 +0200 From: Mateusz Guzik To: suresh gumpula Subject: Re: Allocation/free history Message-ID: <20140728202156.GB9781@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , suresh gumpula , "freebsd-hackers@freebsd.org" References: <20140728191950.GA9781@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 20:22:03 -0000 On Mon, Jul 28, 2014 at 03:37:28PM -0400, suresh gumpula wrote: > Hi, > I am aware of redone(9). I am talking about PC allocation history of > objects. Do we have something like that ? > Well, redzone "remembers" allocation and free backtrace, but does not keep any further history. It is unclear for me if tracking entire history would be of much benefit (note that mere allocation instruction pointer is typically not really helpful and keeping bts for everything would be quite memory consumimg). > Thanks > Suresh > > > On Mon, Jul 28, 2014 at 3:19 PM, Mateusz Guzik wrote: > > > On Mon, Jul 28, 2014 at 01:40:10PM -0400, suresh gumpula wrote: > > > Hi, > > > Knowing the PC of an allocation is very usefull in debugging. Having > > the > > > PC hash table and storing the pc hash either with an object itself( at > > the > > > end) or allocate an exra structure to hold the > > > hash index help us find out who/where an object was allocated. We > > > already have something like this in our own operating system and has > > been a > > > useful thing in debugging. > > > BSD allocator uses power of 2, so storing at the end of an object might > > be > > > wasting lot of memory with large objects. > > > > > > It appears we don’t have something like this in current FBSD codeline and > > > would like to work on this ? Any comments please? > > > > > > > > > It would be something like below. 8 bytes at the end of each object has > > > fecepost which is usefull in finding overwrites and 2 hash indices to the > > > PC table to track allocation history. > > > (kgdb-amd64-7.4-87) x/40w 0xffffff153728b038 > > > 0xffffff153728b038: 0xf6970a05 0x06cb7e0c 0x305a134a > > > 0x831c18bb > > > 0xc0000bed 0x134a2115 > > > > > > 0xffffff153728b050: 0x85687ef8 0xffffffff 0x00000001 > > > 0x83192201 > > > 0xc0000bed 0x1741143b > > > > > > > See redzone(9). > > > > -- > > Mateusz Guzik > > -- Mateusz Guzik