> Kuba, > >> Thanks for all the explaining on cycle copying -- that helps me to understand >> what's going on. >>>> PS. Have you ever ran xcircuit through Valgrind's memcheck? >>> No, I haven't, although I occasionally run programs linked to the >>> TCL_MEM_DEBUG version of Tcl/Tk. I don't really know how the two methods >>> compare for efficacy. I guess the Tcl memdebug is better for detecting >>> out-of-bounds array access; it allows one to check for what memory has >>> not been freed when the program exits. However, if you depend on the >>> OS to free a bunch of allocated memory on exit, then it isn't much help >>> in finding ongoing memory leaks. >> Just to give you an idea of what Valgrind is: >> it is a virtual machine that dynamically rewrites machine code with >> instrumentation. >> Valgrind + memcheck rewrites each machine instruction to instrument it for >> accessing >> undefined data at the level of individual bits, as well as out-of-bounds >> access etc. >> Every bit of memory is marked as to whether it has been defined or not. >> Memory >> freed by free() is marked as undefined again, etc. System calls are >> similarly instrumented >> keeping their semantics in mind. It's a very powerful tool. >> There is no substitute for Valgrind. If you use undefined bits anywhere, it >> will catch it, >> no ifs, no buts. By "using" undefined bits it's meant that they are used to >> make decisions >> (conditional jumps & other conditional execution) based on flags, or passed >> to system calls >> -- merely copying undefined bits around can be quieted out IIRC. Expect the >> initial run to be noisy ;) > > It sounds like it is more or less the same thing as what Tcl uses for > its memdebug.
There is no way to emulate it unless you do the whole shebang. Saying that it's somehow "what Tcl uses for its memdebug" is missing the point IMHO. When you run something under Valgrind, you're running under an emulated x86 CPU that offers hardware debugging not to be found on any real hardware. It's quite a feat to achieve. Unless TCL's memdebug has a full just-in-time code generating x86 emulator, that is. > It probably works okay on something like xcircuit which > makes a limited number of allocations. I've tried using tools like that > on magic, which makes billions of allocations in small blocks, and I > don't have the patience to wait for it to finish. In particular, magic > usually gets screwed up deeply nested down in some corner-stitched plane > copying routine, and I haven't found any memory debugging tool that can > make it less painful. In Valgrind, if you hit a free()d memory, it will tell you exactly where it was malloc()d and free()d. IIRC you can also enable tracing a particular memory allocation, and it can give you the execution history that led to the memory being free()d and then accessed. There is no substitute for that. Vlagrind of course slows down execution by a factor of 4-10 depending on what instrumentation you have selected, but it's a nominal slowdown. It doesn't depend much on how many memory allocations/deallocations there are. You of course need plenty of memory to run Valgrind -- I'd say if you can give it an order of magnitude more for the working set, you're safe. Not only the code expands when you stuff it with instrumentation, but also the instrumentation bitmaps and traces can take up plenty. Cheers, Kuba _______________________________________________ Xcircuit-dev mailing list [email protected] http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
