|
From: Josef W. <Jos...@gm...> - 2004-03-06 02:30:17
|
Hi, I just tried Calltree to get working with Valgrind CVS. The version can be found at http://kcachegrind.sourceforge.net/calltree-0.9.7.tar.gz It is almost working fine with using "--pointercheck=no", but for large programs I get the follow error when the valgrind process grows over 160M in size: ============================================================ --15217-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --15217-- si_code=1 Fault EIP: 0xB8026F13; Faulting address: 0xBFFCD004 valgrind: the `impossible' happened: Killed by fatal signal Basic block ctr is approximately 226200000 valgrind: vg_mylibc.c:1681 (vgPlain_get_memory_from_mmap): Assertion `p >= (void *)vgPlain_valgrind_mmap_end && p < (void *)vgPlain_valgrind_end' failed. ============================================================= I suppose this to be an out-of-memory condition for the skin/tool. I only use VG_(malloc) a lot like cachegrind... Any suggestions? Thanks, Josef |
|
From: Jeremy F. <je...@go...> - 2004-03-08 01:08:46
|
On Fri, 2004-03-05 at 18:22, Josef Weidendorfer wrote: > Hi, > > I just tried Calltree to get working with Valgrind CVS. > The version can be found at > http://kcachegrind.sourceforge.net/calltree-0.9.7.tar.gz > > It is almost working fine with using "--pointercheck=no", but for large > programs I get the follow error when the valgrind process grows over 160M in > size: Yes, the heap size for Valgrind is set to a relatively small value. The idea is that if a tool needs to allocate large chunks of memory, it could use the shadow memory pool. For most tools, this is sized by a well-understood ratio to the client memory size - but for calltree this doesn't necessarily make a lot of sense. We could increase the Valgrind heap size pretty easily, but it eats into the available client address space. How does Calltree use memory? What does it allocate? J |
|
From: Josef W. <Jos...@gm...> - 2004-03-14 00:14:21
|
Hi, [sorry for the late reply, I was in holiday] Am Monday 08 March 2004 02:00 schrieb Jeremy Fitzhardinge: > Yes, the heap size for Valgrind is set to a relatively small value. The > idea is that if a tool needs to allocate large chunks of memory, it > could use the shadow memory pool. For most tools, this is sized by a > well-understood ratio to the client memory size - but for calltree this > doesn't necessarily make a lot of sense. That's the problem here. It should be possible with a CLO to influence this ratio. > We could increase the Valgrind heap size pretty easily, but it eats into > the available client address space. > > How does Calltree use memory? What does it allocate? The same as Cachegrind, i.e. 64bit counters for cache events per instruction. But as there can be multiple counters for the same instruction (separation by thread, by caller context etc.) this already can be much more. Additionally, for call sites I maintain lists of callees with counters, and a shadow call stack for every thread. So I can't do a good estimation in advance, because the space needed depends on the client code. Would it be possible to make a command line option for bigger Valgrind heap space? If there is a out-of-memory condition, the error message could contain a tip to increase the VG heap space by using this CLO. Should I regard this as a problem of Valgrind core? I think I should release Calltree-0.9.7 for a broader "beta test" (before it is included into Suse 9.1). Josef |
|
From: Doug R. <df...@nl...> - 2004-03-08 09:35:24
|
On Monday 08 March 2004 01:00, Jeremy Fitzhardinge wrote: > On Fri, 2004-03-05 at 18:22, Josef Weidendorfer wrote: > > Hi, > > > > I just tried Calltree to get working with Valgrind CVS. > > The version can be found at > > http://kcachegrind.sourceforge.net/calltree-0.9.7.tar.gz > > > > It is almost working fine with using "--pointercheck=3Dno", but for > > large programs I get the follow error when the valgrind process > > grows over 160M in size: > > Yes, the heap size for Valgrind is set to a relatively small value.=20 > The idea is that if a tool needs to allocate large chunks of memory, > it could use the shadow memory pool. For most tools, this is sized > by a well-understood ratio to the client memory size - but for > calltree this doesn't necessarily make a lot of sense. > > We could increase the Valgrind heap size pretty easily, but it eats > into the available client address space. > > How does Calltree use memory? What does it allocate? I recently had problems with valgrind running out of memory loading the=20 debug information for a program which loaded a large number of shared=20 libraries, all of which had lots of C++ debugging information. We ended=20 up re-arranging things to give valgrind more memory for malloc. =46rom a quick reading of the code, we seem to only decode type=20 information for stabs. Does anything actually use the type information?=20 It certainly seems to take up a lot of space. |
|
From: Jeremy F. <je...@go...> - 2004-03-08 10:30:09
|
On Mon, 2004-03-08 at 01:26, Doug Rabson wrote: > I recently had problems with valgrind running out of memory loading the > debug information for a program which loaded a large number of shared > libraries, all of which had lots of C++ debugging information. We ended > up re-arranging things to give valgrind more memory for malloc. > > From a quick reading of the code, we seem to only decode type > information for stabs. Does anything actually use the type information? > It certainly seems to take up a lot of space. The VG_(describe_addr)() function uses it to generate a symbolic description for a particular address and execution context, using whatever variables happen to be in scope at the time. The intent is to present a much more useful description of a failing address than just the numeric value, or the offset into the malloc block. Helgrind is the only tool to use it really consistently; we should make the rest use it too, where possible (memcheck/addrcheck use it a bit, but not very well). It is pretty large though. I guess the options are to work out how to represent it more compactly, or have an option to not load it. For DWARF2, it should be possible to incrementally load it as necessary, rather than in bulk like stabs forces us to do. J |