|
From: Philippe W. <phi...@sk...> - 2010-10-26 22:26:19
|
Filed bug 255353 (with patch) to disable the laog construction with --tack-lockorder=no. Note that the patch also fixes a bug in a data structure used for pretty printing and sanity checking: admin_locks was keeping deleted (and so freed) locks in a list. I made a double linked list of it (asusming we can have many locks) and maintained this list when a lock is removed. > What I am wondering is, maybe nodes are not removed from the graph when > memory is freed. So eventually the graph ends up with more and more > nodes. This is just a guess, I should point out. I wrote a small test program combining N *N locks together. At the end of the run, all locks are destroyed, so I was expecting the laog (and other) data structures to be empty. The stats produced at the end seems to indicate that there are still elements in various data structures. I will try (this week-end) to stop the small test program after each mutex destroy and pretty printing the hg data structures after each destroy. If some of the data is being removed in laog (or others) Word Sets, I guess that when all locks are destroyed, then everything must be empty. Note that without the laog data structures, helgrind still crashes with out of memory. What uses a lot of memory then is the cost center 1,483,979,672 in 393,825: libhb.VTS__new.2 Then when I gave --history-level=approx, I think (I am a little bit lost in all the trials I did) it went further but then crashed on the 'threaded fork' bug (255355). BTW, a lot of the address space is used because each shared library (of valgrind or of the executable itself) is mapped multiple times: at least once for mapping text and once for mapping the (writable) data of the shared lib. The executable has many *huge* shared libs, so that takes about 1Gb of space. Is there a way to indicate to privately map the shared libraries, so as to divide the space used by shared libs by two when running under valgrind ? |