|
From: Chris J. <jo...@he...> - 2005-11-19 21:25:22
|
Hi, I am trying to get the code profiling tool cachegrind working with an application I am working on. I successfully used older versions (pre 2) with eariler iterations of the application on at that time redhat 7.3, but have been having problems with version 2.0.0 onwards on scientific linux 3 (essential Redhat Enterprise 3 with some additions, see https://www.scientificlinux.org/ for details if you are interested). The problem I have is with the code profiling tool cachegrind. If I run the standard memcheck tool, it runs fine, but with cachegrind (which is what I am interested in) I get VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes failed. VG_(get_memory_from_mmap): 240105984 bytes already allocated. Sorry. You could try using a tool that uses less memory; eg. addrcheck instead of memcheck. the full output is here http://www.hep.phy.cam.ac.uk/~jonesc/valgrind-cachegrind.log Which seems to suggest the machine does not have enough memory ? However, the application is running on a box with 2G ram and 2G swap, and normally only requires around 100M to run, so this seems strange ? Is there a bug here, or is it really the case that cachegrind cannot run with this app. That would be a real shame as I found it really useful in the past. Are there any options I can use to reduce the memory usage ? cheers Chris |
|
From: Nicholas N. <nj...@cs...> - 2005-11-19 21:29:49
|
On Sat, 19 Nov 2005, Chris Jones wrote: > The problem I have is with the code profiling tool cachegrind. If I run the > standard memcheck tool, it runs fine, but with cachegrind (which is what I am > interested in) I get > > VG_(get_memory_from_mmap): newSuperblock's request for 1048576 bytes failed. > VG_(get_memory_from_mmap): 240105984 bytes already allocated. Try the current code from the repository (see http://www.valgrind.org/downloads/repository.html) or wait a few days for 3.1.0 to come out -- the problem should be fixed in either case. Nick |
|
From: Chris J. <jo...@he...> - 2005-11-20 14:12:51
|
Hi, > Try the current code from the repository (see > http://www.valgrind.org/downloads/repository.html) or wait a few days for > 3.1.0 to come out -- the problem should be fixed in either case. Thanks for the info. After some playing around I finally got the current SVN version compiled (subversion was missing on the machine ..) However, I now get the error below. Any suggestions ? Is it a problem with valgrind or the library its trying to load ? cheers Chris --6614-- Reading syms from /var/pcce/usera/jonesc/cmtuser/Event/PackedEvent/v1r1/slc3_ia32_gcc323_dbg/libPackedEventDict.so (0xAABE000) --6614-- Reading syms from /afs/cern.ch/sw/lcg/app/releases/SEAL/SEAL_1_6_3/slc3_ia32_gcc323_dbg/lib/libSealSTLDict.so (0xAB2A000) --6614-- Can't stat .so/.exe (to determine its size)?! ==6614== ==6614== Process terminating with default action of signal 6 (SIGABRT): dumping core ==6614== at 0x59ACEEF: raise (in /lib/tls/libc-2.3.2.so) ==6614== by 0x59AE6F4: abort (in /lib/tls/libc-2.3.2.so) ==6614== by 0x59324C6: (within /usr/lib/libstdc++.so.5.0.3) ==6614== by 0x5932513: std::terminate() (in /usr/lib/libstdc++.so.5.0.3) ==6614== by 0x5932685: __cxa_throw (in /usr/lib/libstdc++.so.5.0.3) ==6614== by 0x58EBABF: std::__throw_logic_error(char const*) (in /usr/lib/libstdc++.so.5.0.3) ==6614== by 0x59259C6: (within /usr/lib/libstdc++.so.5.0.3) ==6614== by 0x5921C13: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.5.0.3) ==6614== by 0x4EC4A51: System::getErrorString(unsigned long) (System.cpp:263) ==6614== by 0x4EC4986: System::getLastErrorString() (System.cpp:237) ==6614== by 0x75C00FA: PoolDbCacheSvc::i_loadDictionary(std::string const&) (PoolDbCacheSvc.cpp:354) ==6614== by 0x75BFB83: PoolDbCacheSvc::loadLibraries() (PoolDbCacheSvc.cpp:298) > > Nick > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- +--------------------------------------------------------------+ | Dr Chris R Jones work : +44 (0)1223 337324 | | HEP Group (rm 882) fax : +44 (0)1223 353920 | | Cavendish Laboratory, home : +44 (0)1223 510711 | | Madingley Road, mobile : +44 (0)7723 327477 | | Cambridge, CB3 0HE email : jo...@he... | +--------------------------------------------------------------+ |
|
From: Tom H. <to...@co...> - 2005-11-20 15:13:32
|
In message <200...@he...>
Chris Jones <jo...@he...> wrote:
> Any suggestions ? Is it a problem with valgrind or the library its trying to
> load ?
Technically probably valgrind, but moving the library to a different
fileystem may work around it.
> --6614-- Reading syms
> from /var/pcce/usera/jonesc/cmtuser/Event/PackedEvent/v1r1/slc3_ia32_gcc323_dbg/libPackedEventDict.so
> (0xAABE000)
> --6614-- Reading syms
> from /afs/cern.ch/sw/lcg/app/releases/SEAL/SEAL_1_6_3/slc3_ia32_gcc323_dbg/lib/libSealSTLDict.so
> (0xAB2A000)
> --6614-- Can't stat .so/.exe (to determine its size)?!
That's interesting because I thought I had fixed the primary cause
of this problem, namely use the stat family of system calls instead
of the stat64 ones.
Can you try stracing valgrind and see if there is a stat call returning
an error just before that message and what the error is?
I suspect that moving that file off AFS and onto a convential file
system will work around this though.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-20 15:29:51
Attachments:
valgrind-stat64.patch
|
In message <01a...@lo...>
Tom Hughes <to...@co...> wrote:
> In message <200...@he...>
> Chris Jones <jo...@he...> wrote:
>
> > --6614-- Reading syms
> > from /var/pcce/usera/jonesc/cmtuser/Event/PackedEvent/v1r1/slc3_ia32_gcc323_dbg/libPackedEventDict.so
> > (0xAABE000)
> > --6614-- Reading syms
> > from /afs/cern.ch/sw/lcg/app/releases/SEAL/SEAL_1_6_3/slc3_ia32_gcc323_dbg/lib/libSealSTLDict.so
> > (0xAB2A000)
> > --6614-- Can't stat .so/.exe (to determine its size)?!
>
> That's interesting because I thought I had fixed the primary cause
> of this problem, namely use the stat family of system calls instead
> of the stat64 ones.
It turns out I hadn't fixed the one in the debug info reader. Try this
patch and see if it helps.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Chris J. <jo...@he...> - 2005-11-20 15:32:21
|
Hi there, On Sunday 20 Nov 2005 3:13 pm, Tom Hughes wrote: > In message <200...@he...> > > Chris Jones <jo...@he...> wrote: > > Any suggestions ? Is it a problem with valgrind or the library its trying > > to load ? > > Technically probably valgrind, but moving the library to a different > fileystem may work around it. yes, this seems to be the case. I suspected it could be due to AFS, so ran a few more tests and so far all seem OK now and cachegrind runs just fine. The .so file is still on AFS, but now is cached locally whereas in the first run all AFS files needed loading from the remote server. Possibly the delay this introduced caused the problems ? > Can you try stracing valgrind and see if there is a stat call returning > an error just before that message and what the error is? Unfortunately, I cannot seem to get the error again now that I want to - such is life ... If I do run into this again, I'll try and do what you suggest. cheers Chris |
|
From: Chris J. <jo...@he...> - 2005-11-22 13:06:14
|
Hi, Just thought I will finish up this tread by saying I now have a version of valgrind, which seems to work perfectly with the application I wanted to use it on. This is the first time this has worked since pre valgrind 2.0.0. Many thanks. I also have the external callgrind plugin working, using the head revision from sourceforge, something else which I haven't been able to use for a while. (One minor issue though is the --dump-before and --dump-after options do not seem to work. This is perhaps not the forum for this though and maybe it will be fixed come the final release ?) many thanks for your help Chris |