|
From: Konstantin S. <kon...@gm...> - 2009-10-14 12:44:13
|
On Wed, Oct 14, 2009 at 4:05 PM, Julian Seward <js...@ac...> wrote: > On Wednesday 14 October 2009, Konstantin Serebryany wrote: > > > I did not think about opening this file for the duration of the run... > :) > > > I need to check the occupied memory very often so that the tool can > ^^^^^^^^^^ > > Actually, you only need to check it when the process' mappings change, > or when sbrk happens, since that's the only way(s) the process can acquire > more memory. No need for spin-style polling. > > So .. get your tool to monitor the "new_mem_mmap" and "die_mem_mmap" > This will notify me when the client program does mmap/brk. Right? But I also need to watch for mmap/brk of valgrind itself. Is it possible? --kcc > core-tool events. When you get notified of one of those, then check > the memory situation. See Memcheck sources for examples how (it's easy). > > One danger, though; the following race leading to a segfault: > > tool is notified of new_mem_mmap > tool decides to reread /proc/self/status > so it does VG_(malloc) to allocate a buffer > which results in m_mallocfree doing mmap > which results in a new_mem_mmap notification > > We've had problems like this in the past. (I think the above scenario > is impossible, but nevertheless ..) I would strongly suggest that all > the code you have inside your new_mem_mmap does not do any dynamic > mem allocation. Best to read the file, check if need to reduce mem > consumption, if so, set a flag, and exit. Then, elsewhere in your > tool, check the flag, and if set, dump memory, or whatever. > > J > |