This generally happens when memory errors in the application under test
(here, "btserver") are so bad they wind up trashing Valgrind's storage
too. If Valgrind has reported memory errors prior to this point, try
fixing them first.
J
--19817-- VALGRIND INTERNAL ERROR: Valgrind received a
Is there anything that can be done with memcheck to make it consume less memory?
First of all, figure out whether memcheck got sigkilled because the machine
ran out of space, or because you hit some shell limit/ulimit. In the former
case, you can then try adding swap space to the machine.
On 05/08/2022 16:08, Tom Hughes via Valgrind-users wrote:
If you want to know for sure who killed it then strace it while
it runs and it should show you who sends the signel but my bet is
that it's the kernel.
Or possibly watch `dmesg -w` running in another shell.
J
On 13/07/2022 16:38, Bresalier, Rob (Nokia - US/Murray Hill) wrote:
We are trying to track down a suspected place in our code that keeps
accumulating memory in a 'still reachable'.
It sounds like you're trying to track down a "process lifetime" leak.
You'd be better off using one of the heap
Any ideas why this memory leak is not being detected by valgrind?
Because it's not really possible to do so. Consider the problem of knowing
when an mmap-d page is no longer in use. Those pages are presumably managed
by your app, in some way that is unknown to Valgrind/Memcheck, hence it
We are pleased to announce a new release of Valgrind, version 3.18.1,
available from http://valgrind.org/downloads/current.html.
3.18.1 fixes a number of bugs and adds support for glibc-2.34, and for new
platforms x86/FreeBSD and amd64/FreeBSD. Debuginfo reading is faster, and
Rust demangling
We are pleased to announce a new release of Valgrind, version 3.16.1,
available from http://valgrind.org/downloads/current.html. The source tarball
is signed with the PGP key at the bottom of this message.
3.16.1 updates support for existing platforms and reduces Memcheck's false
positive rate
That doesn't sound right. I use DHAT extensively and expect a slowdown of
perhaps 50:1, maybe less. What you're describing is a slowdown factor of
at least several thousand.
Bear in mind though that (1) V sequentialises thread execution, which wil
make a big difference if the program is
You can't easily avoid this problem, because it occurs in a system library,
not in your own code:
==306851== valgrind: Unrecognised instruction at address 0x6ddf581.
==306851==at 0x6DDF581: opal_pointer_array_construct (in
/opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3)
Greetings.
A first release candidate for 3.16.0 is available at
https://sourceware.org/pub/valgrind/valgrind-3.16.0.RC2.tar.bz2
(md5 = 21ac87434ed32bcfe5ea86a0978440ba)
Please give it a try on platforms that are important for you. If no serious
issues are reported, the 3.16.0 final release
Program received signal SIGILL: Illegal instruction.
Backtrace for this error:
vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5
0x25 0xA8 0x18 0x0
vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE
vex amd64->IR:
On 14/09/2019 21:11, Fred Smith wrote:
Hi all!
I'm new to this list, but have used Valgrind many times in the past.
Today I'm making a serious effort to clean up a non-trivial body of code, and
have run into a number of error reports like this one:
Try again with the trunk now
(git clone
Did you look into using the following option?
--ignore-range-below-sp=- do not report errors for
accesses at the given offsets below SP
J
On 18/11/2019 09:02, Jefferson Carpenter wrote:
I'm debugging a mingw-compiled exe running under Wine, and I'm
Hi Mark,
> Julian would you mind creating a signed tag for this commit?
> Using the same pgp key you used to sign the release tar ball?
>
> git tag -s -m "valgrind 3.15.0 release" VALGRIND_3_15_0 \
> 608cb11914e5f23d0fc12c61dad29c5c7952a1de
> git push --tags
Done!
J
> Valgrind-3.13 (actually I compiled 3.15, but it says 3.13 with Valgrind
> --version)
In that case you're not running the version you compiled.
Try running 3.15 and give it the flag --keep-debuginfo=yes. Does that help?
J
___
Valgrind-users
I guess that the problem is that the build of valgrind somehow removed
the debug (unwind) information on
/usr/lib/valgrind/vgpreload_memcheck-arm-linux.so
and that's why there is no backtrace. Can you rebuild valgrind so that
the debug information on that file is preserved?
J
> drd: drd_vc.c:96 (vgDrd_vc_increment): Assertion 'oldcount <
> vc->vc[i].count' failed.
I suspect (I don't know for sure) that this is a vector clock overflow.
That might happen if your program performed more that 2^32 inter-thread
synchronisation events, for example, mutex lock, unlock,
We are pleased to announce a new release of Valgrind, version 3.15.0,
available from http://valgrind.org/downloads/current.html. The source tarball
is signed with the PGP key at the bottom of this message.
3.15.0 updates support for existing platforms and adds a major overhaul of the
DHAT heap
failures are reported in RC2, this is very likely
to morph into the final 3.15.0 release.
J
> On 08/04/2019 11:11, Julian Seward wrote:
>
> A first release candidate for 3.15.0 is available at
> https://sourceware.org/pub/valgrind/valgrind-3.15.0.RC1.ta
Greetings.
A first release candidate for 3.15.0 is available at
https://sourceware.org/pub/valgrind/valgrind-3.15.0.RC1.tar.bz2
(md5 = 56d9f5e25615d48110da0aa5764d481e)
Please give it a try on platforms that are important for you. If no serious
issues are reported, the 3.15.0 final release
The official Massif documentation is at
http://valgrind.org/docs/manual/ms-manual.html.
time is measured in instructions, not nanoseconds, so as to make runs
repeatable. The various _B values are sizes of things in bytes. See
the above URL for details.
J
On 08/04/2019 07:34, Yogi S wrote:
> I'll shortly send a second message listing the bugs I think are a priority.
Please feel free to disagree and/or add other bugs. This is only my personal
prioritisation.
J
Higher prio (really should fix for 3.15.0)
404843 s390x: backtrace sometimes ends prematurely
405182 Valgrind
Greetings all.
I'd like to propose a 3.15.0 release in just under a month from now, on
5 April. The last release, 3.14.0, was on 9 Oct 2018. In the past few years
we've released pretty much once a year. That has the undesirable effect of
making fixes and new features available only after a
> Are there any such recommendated specs for an "ideal" valgrind running
> machine? Assuming this machine will only run valgrind and nothing else.
Although it runs multithreaded programs (obviously), Valgrind itself is single
threaded. This means it can only make use of one core (really, one
On 13/12/2018 07:53, Chris Teague wrote:
> For some
> reason, valgrind produces errors on this code with -O0, but not with any
> other settings (-O1, -O2, -O3, -Os, -Ofast).
It might just be the case that gcc is clever enough to know that the memset
has no visible effect on the program state,
On 13/12/2018 01:07, Chris Teague wrote:
> 4. Clear out the threads stack via memset() to ensure I don't leave any
> interesting data in the heap.
If I had to guess, I'd say it was this. When the stack pointer moves up
(to deallocate stuff stored on the stack), Memcheck marks the just-freed
On 05/11/18 01:49, John Carter wrote:
> For example, what optimization flags (for compiling the unit tests) have
> been found helpful?
What flags are you using at the moment, for your unit tests?
I have tended to use -Og -g as a reasonable tradeoff between debuggability
and performance (which
We are pleased to announce a new release of Valgrind, version 3.14.0,
available from http://www.valgrind.org.
3.14.0 updates support for existing platforms. There are, as ever, many
refinements and bug fixes. The release notes below give more details.
Our thanks to all those who contribute to
Greetings.
Per the subject line, valgrind-3.14.0.RC2 is available for testing, at:
ftp://sourceware.org/pub/valgrind/valgrind-3.14.0.RC2.tar.bz2
https://sourceware.org/pub/valgrind/valgrind-3.14.0.RC2.tar.bz2
(md5 = e92f8816973396edd6d0cbcd820ccca0)
Please give it a try on systems, and
On 17/09/18 18:15, Alexander Brock wrote:
> valgrind: m_debuginfo/debuginfo.c:738 (check_CFSI_related_invariants):
> Assertion 'cfsi_fits' failed.
Is that really still failing? I thought that got comprehensively fixed
in the past few weeks. Can you re-try?
J
On 10/09/18 06:34, Jeffrey Walton wrote:
> I believe the warnings are due to one of two things. The first use is
> inline asm adjusting the stack pointer for SSE operations.
I doubt it.
> The second use case is using sp as a general purpose register.
Sounds plausible. But is it safe? What
I would also be in favour of removing it. Doing so would remove several
thousand LOC from the tree, perhaps over 10K. Anything that sgcheck can
do, ASan can do faster and with a lower noise level. So I don't think it
would be missed.
J
On 19/09/17 20:19, John Reiser wrote:
>> Can someone who has worked on the code clarify if Valgrind is in fact
>> expected to work on an ARMv5?
ARMv5 and ARMv6 aren't supported. In theory they could be to some extent, but
they lack adequate concurrency-related instructions (atomic insns, mem
See README.android at the root of the source tree.
J
On 20/06/17 09:16, Wuweijia wrote:
> I want to make android build. But I can not find the sysroot parameter
> in configure command. And How I can make the android version.
>
>
>
>
We are pleased to announce a new release of Valgrind, version 3.13.0,
available from http://www.valgrind.org.
3.13.0 adds support for larger processes and programs, solidifies and improves
support on existing platforms, and provides new heap-use reporting facilities.
There are, as ever, many
On 02/06/17 17:57, Julian Seward wrote:
> An RC1 tarball for 3.13.0 is now available at [..]
Thank you to everybody who tried out the RC1 tarball. There's now
an RC2 available for testing at
ftp://sourceware.org/pub/valgrind/valgrind-3.13.0.RC2.tar.bz2
(md5sum = 6f3c12c41036a59b0f49d597fbd59
On 08/03/17 07:16, A. Lester Buck III wrote:
> I don't understand the last line:
>
> Address 0xf95f6a0 is in the BSS segment of /usr/local/lib/libaws-cpp-\
> sdk-core.so
What this means is, the address that has been passed to free -- that is,
0xf95f6a0 -- is zero-initialised data in
> On 13/01/17 23:03, Philippe Waroquiers wrote:
> So, no developer, no user, no company person telling anything,
> and public information telling the chip will be replaced.
I agree, I think this port should be removed. A whole year with absolutely
no signs of user or maintainer activity is, in
> valgrind: m_translate.c:1772 (vgPlain_translate): Assertion 'tres.status ==
> VexTransOK' failed.
That is a very strange failure. It might just be believable that the front
end failed somehow whilst parsing handwritten assembly in this file
> Thread 3: status = VgTs_Runnable (lwpid 17216)
>
That's not a fair comparison. The Solaris port has a very active
maintainer and (presumably) also has users. By comparison the Tilegx
port has shown no signs of life for a considerable period of time,
despite attempts by more than one person here to contact both maintainers
and users. In my
On 04/11/16 16:04, Nicholas Lamb wrote:
> Does anyone know the maximum verbosity level supported by Valgrind?
2 or 3. Not sure now. You can also get tons of internal debugging info
with -d or -d -d etc.
J
--
We are pleased to announce a new release of Valgrind, version 3.12.0,
available from http://www.valgrind.org.
3.12.0 is a feature release with many improvements and the usual
collection of bug fixes. This release adds support for POWER ISA 3.0,
improves instruction set support on ARM32, ARM64
Eric,
>> Thanks for any insights or clues!
>
> I believe this is https://bugs.kde.org/show_bug.cgi?id=356457
> Sadly it is not well understood. If you could add any information to
> that bug that could help us understand better when this issue triggers
> that would be very helpful. There are
On 16/09/16 17:37, Nicholas Lamb wrote:
> I suppose the advantage of Massif is that it reveals the breakdown
> of heap memory distribution, so you can know how much memory is taken
> by accessible but unreleased blocks. I'm using a variant of the Eclipse
> IDE that provides good visualization of
This is all a bit cryptic, but what it means is: Memcheck will tell you
about leaks where all pointers to a block are lost, so it can never be
freed. But it doesn't say anything about a different kind of leak, in
which blocks are continuously allocated over the lifetime of the program,
but only
Yes, I have seen AVX-512 looming on the horizon for a while. Yes, we
should support it. Dealing with AVX/AVX2 was a lot of work, and there is
not much AVX-512 available hardware out there, which may explain the
relative lack of activity so far.
I would be willing to make the infrastructural
> Appreciate any thoughts,
What version of Valgrind is this?
J
--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
On 03/08/16 13:31, John Spray wrote:
> Ah, that makes sense, thanks. I guess we could also use creatively
> wildcarded strings like *boost*detail*get_once_per_thread_epoch*?
Yes, that might also work.
J
--
> The suppression file we use is:
> https://github.com/ceph/teuthology/blob/master/teuthology/task/valgrind.supp#L303
That has demangled symbol names in it. They should be non-demangled,
and that's why it doesn't match. The easiest way to get the non-demangled
names is to run with
On 02/08/16 22:30, Eqbal wrote:
>> valgrind -v --tool=callgrind --dump-instr=yes --trace-jump=yes
>> --trace-children=yes --smc-check=all --collect-jumps=yes
>> --simulate-cache=yes ./example
Try adding --px-default=allregs-at-mem-access. If that doesn't help
then try
> I'm not sure what I should do at the moment. Is this a problem that
> needs attention? Or am I OK to make install?
Remove the custom CFLAGS and let the build system do its own thing.
The binaries it creates do hardware capability autodetection at startup,
so all the build system really cares
> The output from readelf is below, as you'll see there is a .eh_frame section.
> Is there any dependency on how the Valgrind applications and libraries are
> compiled?
Well yes, but in this case it can't even unwind out of a library that is
provided as part of Valgrind itself. So I don't
> - aspacem_maxAddr = (Addr) 0x7fff;
> + aspacem_maxAddr = (Addr) 0x40 - 1; // 256G
Are you sure this frag is right? It seems to have drastically
reduced aspacem_maxAddr. It may be that this is a constant
that shouldn't change.
You can see what the initial memory layout
On 21/07/16 16:09, Julian Seward wrote:
>
>> - aspacem_maxAddr = (Addr) 0x7fff;
>> + aspacem_maxAddr = (Addr) 0x40 - 1; // 256G
>
> Are you sure this frag is right? It seems to have drastically
> reduced aspacem_maxAddr. It may be that this is a c
This is most likely a problem caused by missing unwind info on the 3.11
vgpreload_memcheck-arm-linux.so. What does
readelf -S vgpreload_memcheck-arm-linux.so
say about them? In particular, do they both have .eh_frame, .extab and
.exidx sections? Basically you need either .eh_frame or (.extab
On 27/10/15 12:02, Karthik Sangaiah wrote:
> 405720: 4e60c508 fmaxnm v8.2d, v8.2d, v0.2d
I'm pretty sure that's implemented. Have you tried with 3.11.0?
I suspect it fails because you are using an earlier version.
J
Chiaki,
> First of all, thank you for sharing this great package.
First of all, thank you for supporting Thunderbird. I use it all the time.
> --11405-- WARNING: Serious error when reading debug info
> --11405-- When reading debug info from
>
Hello!
New message, please read <http://za.jobdiagnosis.com/till.php?l>
Julian Seward
--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
Hello!
New message, please read <http://mixmajorswapshop.com/far.php?ji>
Julian Seward
--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
On 13/08/15 10:03, Dan Kegel wrote:
It would help if you could post a complete example so others could see it
in action. Have you tried hacking it down until it fits in a teacup?
+1 for that.
J
--
I've recently switched over to Valgrind 3.10.1 and I'm now see vast numbers
of 'mismatched free/delete' type messages all coming from std::string
shipped with GCC 4.8.3.
I've seen this a lot in the past year when working with Firefox. I believe
that it is due to what you could call
One question to you: does it make sense to be hard-coding the *0x3001*
case into the generalioctl handler, or should there be an NVIDIA-specific
file in the coregrind/m_syswrap directory?
There is already a mechanism for dealing with proprietary GPU ioctls,
because of the need to run on
On 02/05/15 00:07, Philippe Waroquiers wrote:
This is all normal. Unless you link statically, the program will be
linked with the dynamic loader and other .so, which will be called
at startup
Indeed, a mere 10 instructions to get to main() is cheap. More
typically I have seen it costing
On 15/04/15 16:03, Florian Krohm wrote:
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
--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
--2993:0:aspacem Valgrind: FATAL: aspacem assertion failed:
--2993:0:aspacemsegment_is_sane
Could you try that again with the current SVN trunk, please? I don't
think anyone has much enthusiasm to chase down obscure failures on an old
version (3.8.x).
svn co svn://svn.valgrind.org/valgrind/trunk trunk
cd trunk
./autogen.sh
Then configure/build as normal.
J
--2993:2:aspacem
r15088 compiles correctly without complaining about clang 6.1.0.
Just curious — does anyone know where this was specified to allow the
compilation to proceed?
It was actually 15088 that enabled it. Try 'svn diff -c15088' to see it.
J
On 09/04/15 20:08, Atalay Ozgovde wrote:
This is essentially the same bug as:
https://bugs.kde.org/show_bug.cgi?id=278057
A patch was applied for this bug in version 3.7 and it is considered fixed.
I am using version 3.10, I confirmed in the source code that the patch is
applied. Valgrind
A possible cause could be the page size: as I understand,
mips have different page size setup.
If your valgrind has been compiled with a pagesize
not matching your kernel/setup, then maybe Valgrind might ask
wrongly aligned mmap requests, giving then this EINVAL
Yes, that would be my
valgrind: mmap(0x40, 704512) failed in UME with error 22 (Invalid
argument).
valgrind: this can be caused by executables with very large text, data
or bss segments.
It might be better to update the tool to the trunk, so that we don't have
to guess whether this might be due to something
I added this entry to the filecoregrind/m_syswrap/syswrap-linux.c :
10166 PRE(0x3001)
10167 {
10168 PRINT(NVIDIA UvmInitialize ioctl);
10169 }
The right place to add it is PRE(sys_ioctl) and POST(sys_ioctl).
A more fundamental question is, are you running a kernel
On 11/25/2014 10:22 AM, Pohl, Hartmut wrote:
What confuses me is that the stack trace incorrectly reports a data race
between the first and the second test thread. Which is impossible and makes me
think that maybe the pthread_join() is incorrectly handled by helgrind?
There are a bunch of
On 11/25/2014 02:04 PM, Pohl, Hartmut wrote:
As far as I understand, Thread #5 belongs to the second test case and
thus cannot have a data race with thread #3 due to the pthread_join()s.
I agree.
I put the annotation at the end of the while (that's what I started with).
I looked at this in
We are pleased to announce a new release of Valgrind, version 3.10.1,
available from http://www.valgrind.org. See the attached release
notes for details.
Happy (and productive) debugging and profiling,
-- The Valgrind Developers
Release 3.10.1 (25 November 2014)
On 11/20/2014 09:04 AM, Peter Toft wrote:
One thing that I often is missing with valgrind/massif is a way to know
know where I roughly am in my code when I see a given memory peak.
I could envision to add a valgrind-macro or alike in my C-code to
indicate where I am in my code add
There has been some effort recently to improve Valgrind's support for
Yosemite. If you develop on Mac OS, you might like to try out the
trunk (svn co svn://svn.valgrind.org/valgrind/trunk) and report any
breakage you get. Support for Yosemite is good enough that at least
one large graphical
Valgrind developer room at FOSDEM 2015 (Brussels, Belgium, 31 January).
FOSDEM is a free software event that offers open source communities a
place to meet, share ideas and collaborate. It is renown for being
highly developer-oriented and brings together 5000+ hackers from all
over the world.
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
I wonder if anyone ever tried valgrind in arm64-android.
So far, development has been on standard arm64-linux. It should be
pretty simple to get it working on arm64-android, mostly a question
of fixing the missing instructions that are required.
I don't have a 64-bit Android device to test
On 09/23/2014 03:31 AM, Myoungkyu Song wrote:
I have a question, which maybe was discussed. I would like to implement a
wrapper function for standard API such as strcpy. However, I failed to
do. When I tested a user-defined function like hello(char *, char *)
below, I successfully wrapped
Er, this isn't good. Can you file a bug report
as described at http://www.valgrind.org/support/bug_reports.html
so that this gets tracked properly? If it just remains on the mailing
list it is likely to get forgotten.
Thanks.
J
On 09/18/2014 10:09 AM, Matthias Apitz wrote:
Hello,
This
You need to say what CPU this is on. For x86_64 I think this is
impossible, because all x86_64 processors support at least SSE2.
For x86 (32 bit) this might just be possible. In VEX/priv/guest_x86_toIR.c,
find the code that handles CPUID
case 0xA2: { /* CPUID */
and change it so that
, by Julian Seward et al.
==5290== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==5290== Command: ls
==5290==
==5290==
==5290== Process terminating with default action of signal 4 (SIGILL)
==5290== Illegal opcode at address 0x3808AE70
==5290==at 0x4000E50: _start
Yes, if you get some details on how/why it fails, that would
be good. Also, filing a bug in bugzilla
(see http://www.valgrind.org/support/bug_reports.html)
will ensure your bug report doesn't get lost later on.
J
On 09/25/2014 02:58 PM, Vallevand, Mark K wrote:
I tried that option. Doesn’t
On 09/25/2014 12:52 PM, Eliot Moss wrote:
I started updating the valgrind documentation to add description
of this new feature, and expect to submit a patch soon for
developer approval.
https://bugs.kde.org/show_bug.cgi?id=339405
is the bug, yes?
J
This is HTM lock elision stuff; 3.9.0 doesn't support it but 3.10.0.BETA2
might well do.
I have tried googling on this error but I am not finding much related to
it. Any ideas on how to fix it?
Try with
http://www.valgrind.org/downloads/valgrind-3.10.0.BETA2.tar.bz2
instead.
J
A second beta tarball for 3.10.0 is available now at
http://www.valgrind.org/downloads/valgrind-3.10.0.BETA2.tar.bz2
(md5sum = 785115cf1a3f25afa8d0a97df6a1a879)
Please give it a try in configurations that are important for you, and
report any problems you have, either on this mailing list, or
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)
Please give it a try in configurations that are important for you, and
report any problems you have, either on this mailing list, or
On 09/03/2014 02:47 PM, Phil Longstaff wrote:
Is more information available about these changes?
I'd like to see more detail on improved error messages
and stack traces through inlined function calls.
Sure. Here is the entire NEWS entry for the release so far.
J
Release 3.10.0 (mid
On 08/19/2014 02:31 PM, Jan Včelák wrote:
I believe the problem originates in some kind of race.
Try --fair-sched=yes to see if you can reproduce the problem more
often and/or more reliably.
J
--
Slashdot TV.
Video
On 08/16/2014 03:19 AM, Van Snyder wrote:
It seems that cachegrind could be extended to do complete precise
profiling.
What do you mean by complete precise profiling? Can you clarify?
J
--
I think we saw recently (last couple of months?) a case where Memcheck
didn't do any intercepts with uClibC, and it turned out that the problem
was that uClibc had not been built with LD_PRELOAD support. So the
intercept .so never got loaded into the process. I wonder if that is
the case here?
On 05/21/2014 05:24 PM, Andrejs Bogdanovs wrote:
Hi Julian!
Soname for malloc intercepts should be one defined in VG_Z_LIBC_SONAME?
include/pub_tool_redir.h:244:# define VG_Z_LIBC_SONAME libcZdsoZa
// libc.so*
And soname for libuClibc-0.9.33.2.so is libc.so.0:
[andrejs@arch
On 04/14/2014 12:05 PM, Lior Tal wrote:
I am getting an error when executing valgrind with the following options:
valgrind --tool=memcheck --leak-check=full --dsymutil=yes
--read-var-info=yes --log-file=$VALGRIND_LOG ./$MACHO_NAME
Try removing --read-var-info=yes.
J
The trunk now contains a port to AArch64 ARMv8 -- loosely, the
64-bit ARM architecture. It has now reached a stage of being
useful for real debugging, and, in turn, could do with wider
testing.
Memcheck works and has a noise (false-error) level that is
comparable with other targets. All the
On 04/07/2014 10:26 PM, Bob Kuo wrote:
Is it possible to run valgrind *without* the debug symbols available
and then take the valgrind log output, the .map, and the debug symbols
to get a full stack trace? That would simplify our testing greatly.
In theory you might be able to use addr2line,
(guessing at both questions; JosefW would know for definite)
The default callgrind run and callgrind_annonate display shows Ir events, but
I only need to count function entries. Is there a way to only collect those
and have callgrind run faster??
I suspect not. In any case counting insns is
We are pleased to announce a new release of Valgrind, version 3.9.0,
available from http://www.valgrind.org.
3.9.0 is a feature release with many improvements and the usual
collection of bug fixes. This release adds support for MIPS64/Linux,
Intel AVX2 instructions and POWER8 instructions. DFP
On 09/26/2013 04:47 PM, John Reiser wrote:
The likely cause is __float128 operations being performed as double
precision
of two __float80 by the Intel math library for x86_64. Memcheck-3.8.1
implements
__float80 operations as __float64 (ordinary IEEE-754 'double'.)
Thanks for analyzing
On 08/13/2013 10:27 PM, Maynard Johnson wrote:
When I try running Java 5 under current Valgrind (checkout from SVN today),
it results in Valgrind silently dying. The JVM continues to run, but only
the java process shows up in 'top' output. If I run Java 6 under
Valgrind
(i.e., 'valgrind
1 - 100 of 345 matches
Mail list logo
