Re: [Valgrind-users] Will the BBV tool support ARMv7 and ARMv8?
The BBV developer has long left. There are no plans to enhance that tool's functionality to support other platforms. Florian On 09.03.2016 07:35, Lennox Wu wrote: > Hi all, > According to the document of BBV tool, ARM is not supported currently. > Is there any plan to support ARMv7 and ARMv8? > > Best, > Lennox > > > > -- > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140 > > > > ___ > Valgrind-users mailing list > Valgrind-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Assertion 'eltSzB <= ddpa->poolSzB' failed
On 03.02.2016 21:50, Philippe Waroquiers wrote: > > The assert might be caused by the debuginfo containing a string bigger > than SEGINFO_STRPOOLSIZE (64Kb). Why exactly are we having yet another fixed size buffer here? I've spent a lot of time crawling through the code and getting rid of those. To read this is a bit of a disappointment. Florian -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] [SPAM] Fw: new message
Hello! New message, please read <http://stpaulssydney.org/may.php?0doq2> Florian Krohm -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] porition names length
On 28.10.2015 12:04, Marco Cisternino wrote: > Good morning, > > I'm new on the list and I would like to ask you something about the Valgrind > output. > > My c++ code uses a lot of templates so the name of the functions are usually > huge. > > When Valgrind finds an error, it prints the type of error and where it > happens "at 0x: name of the function". > > If the name of the function is too long Valgrind cuts it. > > Is there a way to change the maximal length of the function name? What you describe should have been fixed in the latest valgrind release 3.11.0 If you are using an older version, function names will be cut and there is no way to change that with a command line parameter. If, however, you are using 3.11.0 then this is a bug we want to know more about. Please file a bug here: https://bugs.kde.org/enter_bug.cgi?product=valgrind and include a (small) testcase. Florian -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Counting instructions for specific part of my code using Callgrind
On 28.08.2015 09:03, Josef Weidendorfer wrote:
> This suggests we should document the difference between
> START/STOP_INSTRUMENTAITON
> and TOGGLE_COLLECT better.
Hmm, yes :) Any chance you can write something up in time for 3.11 ?
>
>> for (int i = 1; i <= 1000; ++i) {
>>CALLGRIND_START_INSTRUMENTATION;
>>n += i;
>>CALLGRIND_STOP_INSTRUMENTATION;
>> }
>
> With macros in C, the compiler can reorder stuff, so you may end up with
> something like
>
>> for (int i = 1; i <= 1000; ++i) {
>>n += i;
>>CALLGRIND_START_INSTRUMENTATION;
>>CALLGRIND_STOP_INSTRUMENTATION;
>> }
>
Huh? CALLGRIND_START_INSTRUMENTATION expands into a statement sequence
that includes
__asm__ volatile("whatever" ::: "memory");
and GCC docs say:
If your assembler instructions access memory in an unpredictable
fashion, add 'memory' to the list of clobbered registers.
Wouldn't that prevent the CALLGRIND_START_INSTRUMENTATION from being
moved around? Reason being that the memory clobber might change the
value of "i" in a way not visible to the compiler?
Florian
--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] error configure valgrind for build
On 20.08.2015 19:12, Mike McLaughlin wrote: I run configure like so: ../../valgrind-3.10.1/configure --prefix /usr/local And get the following error message: checking the GLIBC_VERSION version... unsupported version 2.21 configure: error: Valgrind requires glibc version 2.2 - 2.19. This there anyway to build with my existing glibc 2.21. It seems like I'm so close. This has been fixed a while ago in the development version of valgrind and will be in the next release. If you cannot wait that long, check out the code repository. How to do that and how to build valgrind is described here: http://valgrind.org/downloads/repository.html Florian -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] --db-attach to be removed in next valgrind release
When valgrind 3.10.0 was released in September 2014, the feature to attach a debugger using --db-attach was deprecated and scheduled to be removed in the next feature release. The rationale for deprecation is valgrind's built-in GDB server. Its capabilities are superior and it is also less brittle. Detailed documentation can be found here: http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver This note is a gentle reminder of that upcoming change. We haven't heard any objections to the plan and *now* would be a good time to raise them, if there are any. Florian -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind: FATAL: aspacem assertion failed:
On 15.04.2015 15:45, Julian Seward wrote: --2993:2:aspacemReading /proc/self/maps --2993:0:aspacem -1: ANON 003800-00382a5fff 2777088 r-x-- SmFixed d=0x000 i=8527o=32768 (0) m=0 /usr/lib/valgrind/memcheck-arm-linux This isn't sane, because for an ANON segment we should have d=0 and i=0 and o=0. Clearly, this is not an ANON segment but a file segment. I suggest to change the condition on line 3248 in aspacemgr-linux.c (refering to 3.10.1 sources) to if (1) and rerun. That way we can see the contents of /proc/self/maps and can deduce why d == 0 (it should be != 0). Florian -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Help: Can't make Valgrind executable.
On 22.01.2015 21:21, John Reiser wrote: After extracting the tar'd files, I entered the ./configure command, then make, then make install. *Then when I try to test it with valgrind ls -l I get: -bash: valgrind: command not found.** * Most likely make install did not succeed unless you ran it as root. Regular users typically don't have write permissions in /usr/local which is the default install point fro valgrind. As John suggested use --prefix= when configuring. e.g. ./configure --prefix=/tmp/whatever make make install /tmp/whatever/bin/valgrind ls -l Florian There's no file in the installation folder called simply valgrind. (I'm expecting to find an executable file by this name.) - README To install from a tar.bz2 distribution: 4. Run ./configure, with some options if you wish. The only interesting one is the usual --prefix=/where/you/want/it/installed. - configure ac_default_prefix=/usr/local . . . Installation directories: --prefix=PREFIX install architecture-independent files in PREFIX [$ac_default_prefix] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX] By default, \`make install' will install all the files in \`$ac_default_prefix/bin', \`$ac_default_prefix/lib' etc. - So by default you should look for /usr/local/bin/valgrind . Often you would put /usr/local/bin as one of the paths in your $PATH shell environment variable. -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] valgrind-3.10 does not link on
I've fixed this in revision 14673. Curious, what GCC version have you been using? I recommend you file a bug report in the future as issues reported on the mailing list easily get forgotten. Florian On 18.09.2014 10:09, Matthias Apitz wrote: Hello, This is on a Linux host running: valgrind-3.10.0 uname -a Linux SRAP03DXOH 2.6.5-7.191-bigsmp #1 SMP Tue Jun 28 14:58:56 UTC 2005 i686 athlon i386 GNU/Linux valgrind-3.10.0 CFLAGS=-DPTRACE_GETSIGINFO=0x4202 export CFLAGS valgrind-3.10.0 ./configure valgrind-3.10.0 gmake ... mv -f .deps/memcheck_x86_linux-mc_errors.Tpo .deps/memcheck_x86_linux-mc_errors.Po ../coregrind/link_tool_exe_linux 0x3800 gcc -Wno-long-long -DPTRACE_GETSIGINFO=0x4202 -o memcheck-x86-linux -m32 -mpreferred-stack-boundary=2 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -fno-builtin -fomit-frame-pointer -O2 -static -nodefaultlibs -nostartfiles -u _start -m32 memcheck_x86_linux-mc_leakcheck.o memcheck_x86_linux-mc_malloc_wrappers.o memcheck_x86_linux-mc_main.o memcheck_x86_linux-mc_translate.o memcheck_x86_linux-mc_machine.o memcheck_x86_linux-mc_errors.o ../coregrind/libcoregrind-x86-linux.a ../VEX/libvex-x86-linux.a -lgcc ../coregrind/libcoregrind-x86-linux.a(libcoregrind_x86_linux_a-syswrap-linux.o)(.text+0x14bba): In function `vgSysWrap_linux_sys_ioctl_after': m_syswrap/syswrap-linux.c:8476: undefined reference to `__builtin_popcountll' ../coregrind/libcoregrind-x86-linux.a(libcoregrind_x86_linux_a-syswrap-linux.o)(.text+0x1ddcb): In function `vgSysWrap_linux_sys_ioctl_before': m_syswrap/syswrap-linux.c:5748: undefined reference to `__builtin_popcountll' collect2: ld returned 1 exit status gmake[3]: *** [memcheck-x86-linux] Error 1 gmake[3]: Leaving directory `/home/guru/v43/sisis-pap/src/valgrind/valgrind-3.10.0/memcheck' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/home/guru/v43/sisis-pap/src/valgrind/valgrind-3.10.0/memcheck' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/guru/v43/sisis-pap/src/valgrind/valgrind-3.10.0' gmake: *** [all] Error 2 Vy 73 matthias -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Spam (7.009):Re: valgrind-3.10 does not link on
On 29.10.2014 12:00, Tom Hughes wrote: On 29/10/14 10:29, Julian Seward wrote: On 10/29/2014 09:24 AM, Florian Krohm wrote: I've fixed this in revision 14673. Curious, what GCC version have you been using? I think the deciding factor might be, not the gcc version, but the CPU variant being compiled for. In particular that some AMDs do or don't have special variants of these in hardware, or some such. That was my initial assumption, but I'm not sure it can be true because a fairly generic build that just targets any old x86_64 or whatever does work. Right.. If GCC knows nothing about, say, __builtin_popcount then __builtin_popcount(value) appears to the compiler as call to an unknown (undeclared) function. That compiles OK (KR allows that) but probably with a warning. Linking of cause will fail. Florian -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind 3.10.0 support for ICC
On 27.09.2014 01:59, Gregory Czajkowski wrote: My experiences building with ICC.. I recommend you open a bugzilla for this if you want this to go anywhere. Here: https://bugs.kde.org/enter_bug.cgi?product=valgrind We do not have icc at our disposal for testing. So patches would be needed as well. Florian -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] can't compile valgrind 3.10.0 on SuSE Linux SLES 10SP3 64bit
On 16.09.2014 02:27, Patrick J. LoPresti wrote: I can confirm PTRACE_GETSIGINFO and PTRACE_SETSIGINFO are present in sys/ptrace.h for all architectures (including s390) as of glibc 2.5 but not 2.4. Well, except for ia64, where they were added a little earlier (2.3). Since Valgrind does not (yet) support ia64, (__GLIBC__ 2) || (__GLIBC__ == 2 __GLIBC_MINOR__ 4) -- suitably negated -- should do the trick... Thanks. I've changed this in r14565. Florian -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] newbie - problem fixed!
This issue will be fixed in the next valgrind release. So you won't have to work around it anymore. Florian On 15.09.2014 13:31, Alan Duda wrote: Florian and Philippe, As you both suggested, I changed the HOST variable to a value that did not include a '/' (slash). That fixed the problem. Thank you very much!!! xxx Hi, I just installed valgrind-3.10.0. I'm getting these results when I execute the program: 2700ISP valgrind ./alx2 ==23669== Memcheck, a memory error detector ==23669== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==23669== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info ==23669== Command: ./alx2 ==23669== ==23669== error 2 No such file or directory ==23669== cannot create shared_mem file /tmp/vgdb-pipe-shared-mem-vgdb-23669-by- aduda-on-/home/developer/files 2700ISP Can anybody tell me what I need to do to get this to run? Alan -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] newbie: (take2) problem running valgrind-3.10.0
On 12.09.2014 13:02, Alan Duda wrote: Hi, I just installed valgrind-3.10.0. I'm getting these results when I execute the program: 2700ISP valgrind ./alx2 ==23669== Memcheck, a memory error detector ==23669== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==23669== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info ==23669== Command: ./alx2 ==23669== ==23669== error 2 No such file or directory ==23669== cannot create shared_mem file /tmp/vgdb-pipe-shared-mem-vgdb-23669-by- aduda-on-/home/developer/files 2700ISP Can anybody tell me what I need to do to get this to run? This file name looks odd as it contains nested directories (here /home/developer/files): /tmp/vgdb-pipe-shared-mem-vgdb-23669-by-aduda-on-/home/developer/files In general this file should have a name like this: /tmp/vgdb-pipe-shared-mem-vgdb-PID-by-USER-on-HOST where PID, USER, and HOST are syntactic variables with the obvious meaning. valgrind is not expecting a '/' in the host name (or user name). What does echo $HOSTand echo $HOSTNAMEsay. I bet one of those expands to /home/developer/files If so, then change it to something benign not containing a '/' character and it should work. Florian -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind-3.10.0 BETA is available for testing
On 03.09.2014 13:03, Julian Seward wrote: A beta tarball for 3.10.0 is available now at http://www.valgrind.org/downloads/valgrind-3.10.0.BETA1.tar.bz2 (md5sum = dee188c79a9795fee178ba17f42c40b3) I just tested this on my x86-64. I see one unexpected failure in the testsuite: helgrind/tests/hg05_race2 fails like so: --- hg05_race2.stderr.exp 2014-09-02 12:32:36.0 +0200 +++ hg05_race2.stderr.out 2014-09-03 17:47:06.739851222 +0200 @@ -26,8 +26,7 @@ at 0x: th (hg05_race2.c:17) by 0x: mythread_wrapper (hg_intercepts.c:...) ... - Location 0x is 0 bytes inside foo.poot[5].plop[11], - declared at hg05_race2.c:24, in frame #x of thread x + Address 0x is on thread #x's stack @@ -42,8 +41,7 @@ at 0x: th (hg05_race2.c:17) by 0x: mythread_wrapper (hg_intercepts.c:...) ... - Location 0x is 0 bytes inside foo.poot[5].plop[11], - declared at hg05_race2.c:24, in frame #x of thread x + Address 0x is on thread #x's stack THis is with gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2. Is this a known issue? Florian -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind-3.10.0 BETA is available for testing
On 03.09.2014 19:02, Florian Krohm wrote: On 03.09.2014 13:03, Julian Seward wrote: A beta tarball for 3.10.0 is available now at http://www.valgrind.org/downloads/valgrind-3.10.0.BETA1.tar.bz2 (md5sum = dee188c79a9795fee178ba17f42c40b3) I just tested this on my x86-64. I see one unexpected failure in the testsuite: helgrind/tests/hg05_race2 fails like so: --- hg05_race2.stderr.exp 2014-09-02 12:32:36.0 +0200 +++ hg05_race2.stderr.out 2014-09-03 17:47:06.739851222 +0200 @@ -26,8 +26,7 @@ at 0x: th (hg05_race2.c:17) by 0x: mythread_wrapper (hg_intercepts.c:...) ... - Location 0x is 0 bytes inside foo.poot[5].plop[11], - declared at hg05_race2.c:24, in frame #x of thread x + Address 0x is on thread #x's stack @@ -42,8 +41,7 @@ at 0x: th (hg05_race2.c:17) by 0x: mythread_wrapper (hg_intercepts.c:...) ... - Location 0x is 0 bytes inside foo.poot[5].plop[11], - declared at hg05_race2.c:24, in frame #x of thread x + Address 0x is on thread #x's stack THis is with gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2. Is this a known issue? I reran the regtest and this time the test passed. That does not sound good. Looks like I should run memcheck on helgrind Florian -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind-3.10.0 BETA is available for testing
On 03.09.2014 21:56, Philippe Waroquiers wrote: On Wed, 2014-09-03 at 21:02 +0200, Florian Krohm wrote: I reran the regtest and this time the test passed. That does not sound good. Looks like I should run memcheck on helgrind I did run the full test suite in an outer memcheck some days ago. Did not find anything wrong; Oh, cool. Saves me some time. Would be worth trying with --fair-sched=yes and see if that is more reproducable Did not make a difference. I have not been able to reproduce the failure with or without --fair-sched=yes. Florian -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Problem building ppc64 tests due to altivec flag...
This is a bug. I've opened https://bugs.kde.org/show_bug.cgi?id=338731 There is a patch attached to that bug that should fix the build issue. It would be good if you could try it out. And even better if you could run this command perl tests/vg_regtest none/tests/ppc64 afterwards. Florian On 01.09.2014 06:35, Bob Cochran wrote: Hello, I was cross compiling valgrind tonight using OpenEmbbeded and ran into an error during the compilation of none/tests/ppc64/jm-insns.c. Although configure correctly determined that my Freescale T1040 (E5500) doesn't support Altivec, the Makefile in none/tests/ppc64 appears to have -maltivec hardcoded for jm_insns_CFLAGS. Compiling failed when GCC was passed -maltivec. I patched out the altivec flag in the Makefile, and my valgrind packages finished building (won't try the test suite any time soon). From searching, I see that there have been Altivec issues in the past, but I didn't see this particular issue come up. Can I get some guidance on whether this is a bug in the Makefile or whether it's something that I should be avoiding if I had configured things differently? Thanks Bob -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Found A Spelling Mistake in faq page
On 19.08.2014 04:37, Shaopeng Chen wrote: Hey all, I found a spelling mistake in the web page of FAQ( http://valgrind.org/docs/manual/faq.html#faq.pronounce). *1.1.**How do you pronounce Valgrind?* The Val as in the world value. The grind is pronounced with a short 'i' -- ie. grinned (rhymes with tinned) rather than grined (rhymes with find). Don't feel bad: almost everyone gets it wrong at first. The word *world* in first sentence should be ,I think ,*word*. That's right. I've fixed this. Thanks, Florian -- ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Dirty calls
On 03/22/2014 08:51 AM, Domingues Luis Filipe wrote: Hello, I'm using dirty-calls on a tool I'm building. And I want to know what's the limitations of the parameters for dirty-calls (Types, how many...) The answer depends on the architecture you're using. E.g. for x86-64 you may pass up to 6 arguments; for s390 you may pass up to 5. In general, minimising the number of arguments of a helper call is a good idea because instruction selection will often generate register-to-register moves for the arguments and the register allocator does not do a very good job throwing them out. Take a look at VEX/priv/host_ARCH_isel.c to find out what is allowed for the architecture you have in mind. Search for Ist_Dirty. AFAIK only integer arguments are allowed. Florian -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Unhandled instruction in libm
On 08/06/2013 08:02 PM, Kingsley, James Leonard wrote: Attempting to use valgrind on my system gives me an 'unrecognised instruction' error. I am reasonably sure that it's a valgrind issue Yes, it is. vex amd64-IR: unhandled instruction bytes: 0xC4 0xE3 0xD9 0x6B 0x3D 0x4E 0x19 0x6 vex amd64-IR: REX=0 REX.W=1 REX.R=0 REX.X=0 REX.B=0 vex amd64-IR: VEX=1 VEX.L=0 VEX.n=0x4 ESC=0F3A vex amd64-IR: PFX.66=1 PFX.F2=0 PFX.F3=0 ==25013== valgrind: Unrecognised instruction at address 0x4c37a00. ==25013==at 0x4C37A00: __ieee754_log_sse2 (in /lib64/libm-2.15.so) This function has caused trouble before. See https://bugs.kde.org/show_bug.cgi?id=320965 Any suggestions on fixing this? No work-around really, other than recompiling libm with a suitable set of compiler flags (I would not know what those are). If you're brave and have some time, you might be interested in adding support for this instruction to valgrind. The code to look at would be in valgrind/VEX/priv/guest_amd64_toIR.c, function disInstr_AMD64_WRK and underneath. Florian -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Example / Manual for usage of the VEX decoder
On 10/05/2012 03:18 AM, Christoph Niethammer wrote: Hello, I am wondering if there is any example or manual/documentation which shows how to decode a program on the instruction level with valgrind. The VEX header files are somehow confusing me. No, there are no docs for what you seek. Take a look at the 1st attachment of this bug: https://bugs.kde.org/show_bug.cgi?id=272405 That is a standalone program that reads insns from a file and pipes them through VEX. It does all the setup and initialisation work that VEX needs. The catch is that it is somewhat old and may no longer compile. But it should not be too difficult to update it. The overall flow in VEX hasn't changed since. You need to link against e.g VEX/libvex-amd64-linux.a (depending on the platform you're on). Florian -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Line number of source file for shared library now shown
On 07/12/2012 12:11 AM, Nil Nik wrote: Hello, I have executable main, which usages shared library math.so. There is memory leak in math.so, but valgrind does not show the details of math.so following is the example where information of shared library is missing: ==9347== 20 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==9347==at 0x4005BDC: malloc (vg_replace_malloc.c:195) ==9347==by 0x400A599: ??? ==9347==by 0x8048A87: main (in /home/test/main) ==9347== ==9347== LEAK SUMMARY: ==9347==definitely lost: 20 bytes in 1 blocks ==9347==indirectly lost: 0 bytes in 0 blocks ==9347== possibly lost: 0 bytes in 0 blocks ==9347==still reachable: 0 bytes in 0 blocks ==9347== suppressed: 0 bytes in 0 blocks How do i get location within math.so? The shared lib has no debug info. That's why you don't get a file name and line number. If math.so is your own shared object read this: http://valgrind.org/docs/manual/faq.html#faq.unhelpful If it is a system lib you need to install a version that has debug info. That depends on your distro and I can't help with that. Florian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Invalid file descriptor 1019
On 07/16/2012 02:14 PM, daniel.janzon wrote: Hi guys, I get a lot of ==8186== Warning: invalid file descriptor 1019 in syscall open() That message is issued if the file descriptor exceeds the limit that is allowed for the process. On my Ubuntu 12.something uname -a tells me I can use 1024 file descriptors. Valgrind reserves 10 for itself. So 1019 would be off limits on my system. If this applies to you: increase the limit, does it help? If not: Run valgrind with --trace-children=yes --trace-syscalls=yes --track-ids=yes That should shed some light. Search for sys_open (or similar) and look at the next line. It contains the file descriptor in *hex*. If that invalid file descriptor does not show up, then I'm afraid only a gdb session on valgrind will help. Florian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind 3.7.0/memcheck error message cut short
On 03/02/2012 06:39 AM, Julian Seward wrote:
On Friday, March 02, 2012, SFBay Area wrote:
Hi,
I have started coding in C++ and use a lot of templates, and I do mean a
lot. Unfortunately, my type names became way too long for Valgrind to
handle. Currently, it seems that it cuts the type name at around 4100
characters (slightly less than that). That is not much of a problem per se,
but it means I do not know where the error is reported to be (the file+line
number combination is missing). Any idea where the error message length is
specified? I am using memcheck and the newest stable Valgrind 3.7.0.
It might be BUF_LEN defined in VG_(describe_IP) in
coregrind/m_debuginfo/debuginfo.c, currently 4096.
Alternatively you can use --demangle=no and demangle
the output by hand by pushing it through c++filt.
There is also a hard-coded limit here:
void VG_(demangle) ( Bool do_cxx_demangling, Bool do_z_demangling,
Char* orig, Char* result, Int result_size )
{
# define N_ZBUF 4096
HChar* demangled = NULL;
HChar z_demangled[N_ZBUF];
If you increase N_ZBUF does it fix your problem?
Florian
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] The bug that got away...
On 11/01/2011 06:33 PM, Peter Toft wrote:
Hi all
Try to find the errors in this C/C++ snippet using valgrind:
#include stdio.h
/* Save as code.c */
int main(void)
{
int i=-1,a[2],b[2],c[2];
a[0] = 1; a[1] = 2;
b[0] = 3; b[1] = 4;
c[0] = 5; c[1] = 6;
printf(%i %in,b[i],a[i]);
return 0;
}
Compile using gcc -o bla code.c -Wall and check the code using
valgrind ./bla.
Valgrind finds nothing even though I index a[-1] and b[-1] - not
good...
Not good. But expected. Memcheck, the default valgrind tool, does not
find array overruns on variables allocated on the stack.
You might want to try ptrcheck:
http://valgrind.org/docs/manual/pc-manual.html#pc-manual.how-works.sg-checks
Insure++ would for sure find the negative index, but GCC nor Valgrind
will get it...
It's lame that GCC does not find it. Try clang. I wouldn't be surprised,
if it catches this error but I haven't tried it.
Florian
--
RSA#174; Conference 2012
Save $700 by Nov 18
Register now#33;
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] I want to be one of the valgrind-list
On 09/23/2011 10:03 AM, 奕楠 邱 wrote: Hello, I visited the valgrind website today, I want to be one member of valgrind list Because I met some problem, I want to know the operation of valgrind source code Should I send my question to this email address? Questions about the source code are better directed to the valgrind-developers list. There is a link somewhere on this page http://valgrind.org/support/mailing_lists.html To get a general idea of how valgrind works you want to read this paper first: http://valgrind.org/docs/valgrind2007.pdf Florian -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind for IBM 4690 OS
On 08/24/2011 05:12 PM, Panchabakesan Thiagarajan wrote: Thanks for your reply... I'm a bit new to this developing environment, so took some time to analyse on whats happening. We develop on a Windows platform using Cygwin and the compiler is Intel ICC compiler. The executables are typically .386 or .286. The target machine runs on IBM 4690 OS, in its turn was a derivative of Concurrent DOS. Though the flavours are different the underlying OS remains the same The underlying OS is Windows and that is not supported. so could this tool be used with minor modificaitons if required for adopting to this OS? No, this would be a major undertaking. For one thing you would have to wrap all system calls and tell valgrind what they do to memory (read, write, allocate, etc). I doubt that there is sufficient information about Windows system calls available to make porting valgrind a well defined task. Florian -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind for IBM 4690 OS
On 08/22/2011 04:28 PM, Panchabakesan Thiagarajan wrote: Hi, I need to use the Valgrind tool for analysing an application which runs on IBM 4690 OS. Should the tool be built with the .x86 extention and then sent to my target machine for analyzing my application or should that be directly installed on my target machine? Neither will do you any good. IBM 4690 is not a supported platform. See here: http://valgrind.org/info/platforms.html Florian -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Possible Error: Callgrind Version 3.6.1 cg_annotate : Line 1 Missing command line
On 05/27/2011 01:22 PM, Josef Weidendorfer wrote: On Friday 27 May 2011, WAROQUIERS Philippe wrote: Changing in gdbserver the two letters for callgrind is very easy at this stage (as nobody is yet depending on these letters, it is only in Valgrind svn 3.7.0). Good. But if we better change these, what should these 2 letters be ? Is there a need for vgdb to stick with 2 letters? I much would prefer clg instead. Since years I use the alias clg='valgrind --tool=callgrind', and in the callgrind sources I use the CLG_ prefix quite often. I agree with Josef it would be best if we could drop the 2-letter-acronym requirement. My preference would be to use the tool name instead (and not some form of abbreviation). That increases usability as it eliminates all confusion. I fail to see the value of having to use an abbreviated tool name in certain contexts. It's just one more thing to remember. And it's not clear to me what the value is in return. Florian -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Possible Error: Callgrind Version 3.6.1 cg_annotate : Line 1 Missing command line
On 05/25/2011 04:06 AM, Josef Weidendorfer wrote: You need to use callgrind_annotate. cg_annotate is the tool for cachegrind output. The naming is a little bit unfortunate. Definitely. How about renaming cg_annotate to cachegrind_annotate? In the presence of shells doing command completion the extra typing burden is quite contained. We can keep cg_annotate around for another release but deprecate it. Then it can be removed in the release after next. Florian -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Problem resolving a Valgrind reported error
On 03/28/2011 09:26 PM, Santosh Navale wrote:
Hi,
The following is the message I get when I run valgrind on my C code.
==16455== Use of uninitialised value of size 8
==16455==at 0x4E6A76B: _itoa_word (_itoa.c:195)
==16455==by 0x4E6B9B8: vfprintf (vfprintf.c:1613)
==16455==by 0x4E75869: printf (printf.c:35)
==16455==by 0x400830: main (matrix1.c:42)
==16455== Uninitialised value was created by a heap allocation
==16455==at 0x4C244E8: malloc (vg_replace_malloc.c:236)
==16455==by 0x400752: main (matrix1.c:28)
From my understanding something on line 28 in the file matrix1.c is causing
an error. When I look at the source code,
matrix = (int **) malloc (size * sizeof(int *));
for (row = 0; row size; row++) {
matrix[row] = (int *) malloc (size * sizeof(int));
--- Line 28
}
I do not see how this can be a problem. Am I missing something very
fundamental?
You might. Line 28 allocates memory but it does not initialize it.
matrix[row[ is initialized, of course, but matrix[row][0] etc.. is not.
Florian
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Valgrind doesn't work on systems with no /tmp dir
On 03/15/2011 05:19 PM, Shamis, Pavel wrote: Hey, Valgrind doesn't work on systems that don't have /tmp directory. After some debug we found that the /tmp directory is actually hardcoded in the code. I changed the code to get the TMP directory from environment variable. As result it provides us a way to customize temporary directory location. If no value is specified, the default one (/tmp) is used. Please see attached patch. It really may be helpful to see some resolution for the problem in future Valgrind version. Yes, this should be fixed. Not sure whether a valgrind specific environment variable is needed. TMPDIR usually serves this purpose in unix-like OSes and should probably be used instead. Can you file a bug, so this won't fall through the cracks? See http://valgrind.org/support/bug_reports.html for some info on how to do that. Florian -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Log every memory access
On 02/20/2011 02:52 AM, zhouxu(NUDT) wrote: Hi everyone, I am new to Valgrind. I want to log an program's every memory access. Each log entry should contain thread id, memory address, read or write. I want to know if Valgrind can do this job and how? Thank you! Yes that can be done. You need to instrument the intermediate representation. A memory read will be represented by an Iex_Load expression and a memory write will be represented by a Ist_Store statement. Take a look at libvex_ir.h for a description of the IR and at the lackey tool for a simple instrumentation example. Good luck, Florian -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
