Date: Sat, 5 Apr 1997 11:58:05 -0400 (EST) From: "Chad M. Fraleigh" <chadf@bookcase.com> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: hackers@FreeBSD.ORG Subject: Re: Code maintenance Message-ID: <Pine.BSF.3.95.970405112007.21115A-100000@notes> In-Reply-To: <199704051614.BAA27630@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hmm, nasty. You could add an extra field to the memory block header > with the address of the caller in it, which would help a lot. (With > that you could nominate caller and possibly line number, but a full > backtrace for every block is a big ask). Now really, if you compress redundent stack info. The principle is simple.. Log each kernel malloc and free to a file (actually buffering it in memory first and removing as much malloc/free's as possible). You would only log the stack changes (since probably 50-80% might be redundent). For example you have the following call structure: func1->func2->func3->func4->line20->malloc(20) = <loc1> func1->func2->func3->func4->line42->malloc(541) = <loc2> func1->func2->func3->func4->line53->free(<loc1>) func1->func2->func3->func5->line14->malloc(256) = <loc3> This would produce a log of: malloc size = 20 addr = <loc1> stack repeat = 0 stack = func1->func2->func3->func4->line20 malloc size = 541 addr = <loc2> stack repeat = 4 stack = line42 free addr = <loc1> malloc size = 256 addr = <loc3> stack repeat = 3 stack = func5->line14 And if all of this happened in the buffer before writting to disk, only the second and fourth malloc would be logged (the other two would cancel out). Then a utility program would read the file.. cancel out anything that was free-ed. Given a list of debugging info (from nm -a kernel) it would produce a list of what was allocated the memory. Then you could visually see that such-and-such allocted some memory over and over, but never released it. There will of course be some allocation at the begining that will never be released through the life of the boot, but this shouldn't be too hard for someone to reconize. It would have a set file size limit (so you could say don't use more then 32Mb in logging for example). The hard parts in the implimentation would be hooking the mount function so it knew when it could start writting to disk... getting the backtrace info (it's probably not that hard.. I just never tried to do it before), and last would be so you could boot once, have it log, and boot it the next time and not have it log anymore (since now you'd want to anylize it).. some kernel flag I guess or maybe it would only log if the file didn't exist already. I mean a memory tracer like this wouldn't be a standard thing.. it would be purely development that someone could enable (right before a version release for example) to get out some memory glitches. Heck.. if someone has a big enough drive to log on (Gb or so), you could run it for awhile and catch alot of things. Still think it's not viable? -Chad
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970405112007.21115A-100000>