Date: Thu, 11 Jun 1998 01:00:13 +0200 (MET DST) From: Willem Jan Withagen <wjw@surf.IAEhv.nl> To: tlambert@primenet.com (Terry Lambert) Cc: wjw@IAEhv.nl, hackers@FreeBSD.ORG Subject: Re: debugging memory allocation in -stable Message-ID: <199806102300.BAA23346@surf.IAEhv.nl> In-Reply-To: <199806102204.PAA14301@usr01.primenet.com> from Terry Lambert at "Jun 10, 98 10:04:24 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
You ( Terry Lambert ) write: => > Working on some stuff with variant links, crashed became my life. But I => > have some code partially working. Only a few symbolic links later, I get a => > crash due to having already free'ed some buffer. => > => > I'm pretty shure I have to release this buffer in my code, but know I'd like => > to know where this buffer was malloced in the first place. => > How do I figure this out? => => I have not had a chance yet to look at your code. I *will* look at the => code in the near future. From a cursory examination, I have: I didn't want to sound impatient. :-} I'm just eager to get on..... But you'll have to be a little patient with me whilest I'm trying to parse all these data structures with their implicit pre and post conditions. => I think you are not treating symbol expansion as being exactly the same => as link expansion. See the "Check for symbolic link" case in namei() in => vfs_lookup.c. It is exactly analogous to the "readlink" case. In most => cases, an inline expansion is possible. You mean writing the code "inline", or expand the variant-symbol in the buffer? I'm finding a lot of extraneus field which need to be adjusted as well, so incline code seems to be easier. But it's not a clean to read. => This is my opinion from the code integration location. IMO, you should => be wedging the "$" into the cn_hash calaculation, which has to do the => traversal anyway (making it two compares -- nearly free). This one I don't parse at all, but probably will, once you've got full comments on my first attempt. As far as I see: cn_hash would help speedup the process, omitting it for now would not be wrong? => You may want to look at the HASBUF/SAVESTART flags while you are there; => after a manipulation, these should probably be reset on the allocated => version, and tested for the FREE. I'll be looking into that as well. Still my initial question holds: How can I "easily" debug MALLOC/FREE problems in the kernel. --WjW -- Internet Access Eindhoven BV., voice: +31-40-2 393 393, data: +31-40-2 606 606 P.O. 928, 5600 AX Eindhoven, The Netherlands Full Internet connectivity for only fl 12.95 a month. Call now, and login as 'new'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806102300.BAA23346>