|
From: Philippe W. <phi...@sk...> - 2010-10-22 22:34:12
|
At work, we are evaluating helgrind and drd (on a big C++ executable). After bypassing bug http://bugs.kde.org/show_bug.cgi?id=255009 , helgrind still crashes relatively quickly due to lack of memory. (drd is still running after about 1 hour of cpu, so there is some hope I will have something when I return to work on monday :). This discusses the helgrind 'out of memory'. We observe that the memory used by helgrind is reasonable during +- 10 minutes of cpu (helgrind uses about two to three times the memory without valgrind). Then in something like one minute, the memory reaches 4 Gb, which causes a crash (as this is a 32 bits application). --profile-heap=yes shows that the cost center "hg.ids.5 (univ_laog)" is the main culprit for the memory usage. Here is the state of the "tool" arena at the crash time: (note: the below is produced with a valgrind containing the fix for "quadratic memory fragmentation" (bug 250101) but the same behaviour is observed with an unpatched 3.6.0. -------- Arena "tool": 3330277376/3330277376 max/curr mmap'd, 3257130328/3257130328 max/curr on_loan -------- 32 in 1: hashtable.Hc.1 48 in 2: commandline.sua.3 64 in 2: commandline.sua.2 192 in 8: libhb.Thr__new.1 216 in 1: initimg-linux.sce.5 304 in 2: hg.mstSs.1 352 in 8: hg.mk_Thread.1 352 in 8: libhb.Thr__new.3 (local_Kws_and_stacks) 400 in 2: hg.pSfs.1 416 in 6: hg.mpttT.1 792 in 49: hg.mctCloa.1 1,136 in 119: hg.lae.1 1,472 in 50: hg.mctCI.1 1,992 in 5: hg.ids.3 2,000 in 1: hg.ids.1 2,544 in 24: hg.lNaw.1 14,408 in 194: errormgr.mre.2 49,152 in 4: libhb.Thr__new.2 196,632 in 1: hashtable.resize.1 354,840 in 39,459: hg.lae.2 679,072 in 41,235: hg.lae.3 786,456 in 1: libhb.event_map_init.2 (context table) 856,848 in 34,844: hg.new_MallocMeta.1 933,144 in 37,645: libhb.zsm_init.1 (map_shmem) 976,296 in 39,579: hg.laog__init.1 1,016,696 in 41,236: hg.laog__init.2 1,652,280 in 169,836: libhb.VTS__new.1 2,173,264 in 135,810: libhb.SO__Alloc.1 2,488,576 in 2: libhb.vts_tab_init.1 3,257,336 in 135,704: hg.ids.2 4,514,648 in 169,837: libhb.vts_set_init.1 5,814,880 in 320,351: hg.ids.4 6,514,000 in 135,703: hg.mk_Lock.1 21,835,480 in 20,529: libhb.event_map_init.4 (oldref tree) 22,923,592 in 339,672: libhb.VTS__new.2 28,095,248 in 1,293: libhb.aFfw.1 (LineF storage) 44,620,304 in 860: libhb.event_map_init.1 (RCEC groups) 51,174,424 in 1,068: libhb.event_map_init.3 (OldRef groups) 3,056,190,440 in 126,826: hg.ids.5 (univ_laog) I understood that the univ_laog is used for producing the lock order checks. (laog seems to be Lock Acquisition Order Graph). So, I tried --track-lockorders=no, but that seems to only disable the reporting of lock order errors, not the building of the data structure. Is it normal that the lock acquisition graph becomes so huge ? (at first sight, I would expect such a graph to not be *that* huge). If it is normal that this graph can become huge, I can try to avoid building this graph when --track-lockorders=no is given. but that assumes that the univ_laog data structure is only useful for track-lockorders. So, is univ_laog only used for track-lockorders=yes ? Or is this univ_laog needed for something else in helgrind ? |