Normally, SIGABRT triggers a core dump according to the man pages. So
why doesn't valgrind dump the core?
Um, I don't know. What architecture are you running on? Can you send a
small test case program that shows the problem?
J
On Tuesday 21 October 2008, tom fogal wrote:
I'm debugging a program which has an overwhelming number of errors.
Most all of them come from LDAP code in a standard library, as well as
various components of Open MPI, so they are not things I can
reasonably fix.
If you tell openmpi mpirun
In that case, Valgrind is somewhat irrelevant. An equivalent problem
(it seems to me) is this: for a threaded program running natively,
how do you force the Linux kernel to run a thread of your choice
next, when there is more than one runnable thread? I don't know
how. You can do
T1T2 T3 T4
acquire(x) acquire(x) read(abc) write(abc)
write(abc)read(abc) y = abc*18 z =42/abc
release(x) release(x) ... whatever ..
Darryl (I think) wants to see is
Just make install is not enough to install a port on freebsd. You can
find the instructions to build a port here:
http://www.freebsd.org/doc/en/books/handbook/ports-using.html
So there is a FreeBSD port of valgrind? What version is it?
J
On Saturday 15 November 2008, Nicholas Nethercote wrote:
On Tue, 11 Nov 2008, Bahle, Ken wrote:
My team would very much like to employ a tool such as valgrind. Our main
platform is AIX 5.3 and I see that AIX support is listed in the manual as
experimental. Just how experimental is it and
On Tuesday 09 December 2008, Bart Van Assche wrote:
Can you please tell me on which Linux distribution drd-trunk printed
noise for the call to pthread_exit() ? At least on Fedora 6 I have not
been able to reproduce this behavior.
Sorry for the slow response. I got tied up chasing fixing a
On Sunday 14 December 2008, Bart Van Assche wrote:
Both algorithms are valuable. Unfortunately there is not yet any known
way to combine those two algorithms (Eraser and happens-before)
without also combining the disadvantages of both algorithms.
It could be argued that, because of this
On Sunday 14 December 2008, Miguel Ojeda wrote:
Helgrind in 3.3.1 uses an algorithm which sometimes incorrectly reports
races, which I think is what happened here. (These limitations are
documented in the Helgrind 3.3.1 manual). Helgrind in the trunk uses
a less aggressive algorithm,
==15155== ==15151==by 0x805EE02: agent(int, unsigned char**)
(Agent.cpp:153) ==15151==by 0x8057790: main (AgentMain.cpp:125)
==15155==
15151==
==15151=14 bytes in 112 bytes in 1 blocks are still reachable in loss
record 272 of 4,611===15151==
I think
I am willing to test a bunch of shell utilities and code to find more
syscalls that are missing, but should I open individual tickets for each
syscall or stuff them onto the existing ticket?
Put them all on the existing ticket. The important information is, in
each case, the syscall number
Options used:
--log-file=/scratch/work/valgrind_check.pid%p
--leak-check=full
--leak-resolution=high
--undef-value-errors=yes
--track-fds=yes
--workaround-gcc296-bugs=yes
--error-limit=no
--num-callers=60
--run-libc-freeres=no
-v
--tool=memcheck
You need
On Friday 09 January 2009, Matthew Clark wrote:
Below is the valgrind run with the trace-signals enabled.
--21465-- signal 11 arrived ... si_code=2, EIP=0xffe266c, eip=0x428abe48
--21465-- SIGSEGV: si_code=2 faultaddr=0x3818eef8 tid=1 ESP=0x7e981fe0
seg=0x38042000-0x381cefff
--21465--
Let me make sure I understand it clearly. You have mentioned that,
--child-silent-after-fork option suppresses all output between a fork and
exec. The %p specifier in the --log-file option, I thought is used to give
every pid its own file and to avoid the jumbling up in log files. So fork
Program received signal SIGILL, Illegal instruction.
0x380303e4 in vgPlain_machine_get_hwcaps () at m_machine.c:453
453 m_machine.c: No such file or directory.
in m_machine.c
This SIGILL is OK. You should tell GDB to pass the signal to Valgrind
and continue. Then what happens?
Hi,
http://article.gmane.org/gmane.comp.version-control.git/107391
This did make it (and I replied), but it went to our devs list
(valgrind-develop...@lists.sourceforge.net) and not to this one.
J
--
This SF.net
I have a server which creates a new detached pthread every time it
accepts a new connection.
Hmm, detached threads are bad news, at least from a race detection
point of view. See
http://www.valgrind.org/docs/manual/hg-manual.html#hg-manual.effective-use
point 5 (Round up all finished
On Thursday 29 January 2009, Rainer Gerhards wrote:
The standard io library is not thread safe.
Are you sure about that?
http://www.unix.org/whitepapers/reentrant.html:
The POSIX.1 and C-language functions that operate on character
streams (represented by pointers to objects of type
-3.4.0/BUILD/bin/valgrind -v ps
(or my other code)
gives me:
==25081== Memcheck, a memory error detector.
==25081== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==25081== Using LibVEX rev 1878, a library for dynamic binary
translation. ==25081== Copyright (C) 2004-2008
On Thursday 05 February 2009, Christoph Bartoschek wrote:
Hi,
today I had to learn that the attached program is incorrect. It is not
allowed to destroy the barrier while not all threads have left the
pthread_barrier_wait() call.
Unfortunately neither DRD nor Helgrind warn about this error.
First of all, are you able to compile and run (on Valgrind) any simple
program (eg, hello world), in 64-bit mode?
J
==7237910== Process terminating with default action of signal 11 (SIGSEGV):
dump
ing core
==7237910== Access not within mapped region at address 0xFFFE
invalid read. However, there is no indication of why it is invalid.
Um, it says it is invalid because you are reading freed memory:
==27712== Invalid read of size 8
==27712==at 0x40904A: std::valarrayint::size() const
(valarray:772)
[...]
==27712== Address 0x5588760 is 0 bytes inside
On Friday 06 February 2009, Ross Boylan wrote:
On Fri, 2009-02-06 at 19:47 +0100, Julian Seward wrote:
invalid read. However, there is no indication of why it is invalid.
Um, it says it is invalid because you are reading freed memory:
I believe those are 2 separate error reports
Christoph,
I understand, by reading the thread that Tom Fogal refers to ..
http://groups.google.com/group/comp.programming.threads/browse_thread/thread/
4f65535d6192aa50/a5f4bf1e3b437c4d?lnk=stq=#a5f4bf1e3b437c4d
.. that the POSIX pthreads standard is in a way broken:
you cannot know when
Thank you. So is the correct reading that the first block gives the
stack trace of the call that triggered the error, and the second block
gives the stack trace of the earlier code (whose execution is now
complete) that freed the memory?
Yes.
J
My libc is glibc 2.9-0exp2 from Debian experimental. I looked at
I think that is probably the cause of the problem. Valgrind 3.4.x
works fine with glibc 2.9, but the glibc version needs to be known
at build time. If I had to guess, I would say your system originally
had glibc-2.8, and
I've cross compiled Valgrind 3.4 and 3.2.3 for PPC on a Linux/x86
machine.I'm using Valgrind on QEMU(PPC emulator).
Is this the user mode simulator or the full system simulator?
Valgrind 3.4 doesn't seem to report errors properly when used with a test
program,while Valgrind 3.2.3 reports
Still same story, see http://sebastian.wangnick.de/valgrind-3.4.1.out.gz
.gz is invalid:
$ wget http://sebastian.wangnick.de/valgrind-3.4.1.out.gz
$ gzip -tv ./valgrind-3.4.1.out.gz
./valgrind-3.4.1.out.gz:
gzip: ./valgrind-3.4.1.out.gz: invalid compressed data--crc error
gzip:
AFAIK, Julian recently added some functions to get at variable name for
a given stack address. You need it the other way around: get information
about number of parameter and types, and how to access them.
Yes, that information (parameter names and types) is definitely in the
Dwarf3, and the
Valgrind 3.4 doesn't seem to report errors properly when used with a test
program,while Valgrind 3.2.3 reports errors when run on the same test
program.Am I missing something?I'd appreciate any pointers.
Some questions:
* what does
readelf -a /lib/libc-2.3.4.so | grep soname
produce?
Does anyone know if such a function, that returns the block between two
addresses exists?
I think what you want to do isn't doable, at least it isn't the way you've
been looking at it so far.
There are two times that are important here: when the block is translated
(translation-time) and when
We are pleased to announce a new release of Valgrind, version 3.4.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.4.1 (28 February 2009)
On Wednesday 04 March 2009, Dallman, John wrote:
They indicate that valgrind's memory manager was asked to
handle a block (actually a single contiguous address
interval, which could be a block or a non-block) of more
than 100,000,000 bytes ... on x86_64 with 64-bit addresses
and much
Which version of Valgrind is this with?
32-bit executables on amd64-linux or ppc64-linux should work fine.
It gets tested regularly.
Which memo did I miss?
Can you first try with the svn trunk; Tom just fixed a bug in that which
may be related (or not).
svn co
On Friday 08 May 2009, Theodoros V. Kalamatianos wrote:
On Fri, 8 May 2009, Nicholas Nethercote wrote:
This paper is related too:
author = {Jonas Maebe and Michiel Ronsse and Koen De Bosschere},
title = {Precise detection of memory leaks},
booktitle = {Proceedings
Tom,
Thanks. I don't think it actually makes any difference though. I can
reproduce what you're seeing on F10 x86 with the original program.
Could you pls send the objdump -d of the insn it's complaining about
+ the few preceding ones, so as to show how the flags get set?
J
On Thursday 14 May 2009, Russell E. Owen wrote:
I'm trying to install Valgrid 3.4.1 on a shared disk in such a way that
all of our users can use it, though we have a mix of various flavors of
linux box (x86 64-bit, 32-bit and AMD64).
I assume this is the relevant section of the documentation,
Is there any way I could mark an interesting location in memory with
the client mechanism and then get
Valgrind to show me a backtrace everytime the location was touched? If
not it would be a really useful tool :-)
yeh
#include memcheck/memcheck.h
On Thursday 21 May 2009, Andy Howell wrote:
Colin Miller wrote:
Andy Howell wrote:
I have some code that uses the pre-processor to generate code to log
messages:
#define logDebug if ( Log::minLevel = Log::LVL_DEBUG ) Log::printLog
Helgrind reports data races ultimately due to the
BTW, I am assuming that there is no limitation on the signature of the
orignal function with regards to doing I_WRAP_SONAME_FNNAME_ZZ (as there
are for CALL_FN_*_*) - the manual doesn't call out explicitly.
As far as I know there are no such limitations.
There are -- you can only pass
anyone change it between comparing it to A and setting it to B). Because
of the way Valgrind works (simulating instructions), the atomic
instructions get broken up into separate loads/stores, meaning that
they're no longer atomic (i.e. it's possible for someone to change the
location in
That's fixed now, in the trunk (not 3.4.x). If you put in atomic
instructions then you should get out (something equivalent to)
atomic instructions. So V should now play nice with other processes
communicating via shared memory.
Cool, that's good to know :) Is there a place I can read
On Monday 27 July 2009, Patrick Smears wrote:
On Fri, 24 Jul 2009, Patrick Smears wrote:
On Fri, 24 Jul 2009, Julian Seward wrote:
anyone change it between comparing it to A and setting it to B).
Because of the way Valgrind works (simulating instructions), the atomic
instructions get
Konstantin, have you got any insights here?
J
==21259== Possible data race during read of size 4 at 0x5ac5ef0 by thread #6
==21259==at 0x5A70662: std::string::_Rep::_M_is_leaked() const
(basic_string.h:189)
==21259==by 0x5A72076:
std::string::_Rep::_M_grab(std::allocatorchar const,
On Sunday 02 August 2009, Iain wrote:
I've been hacking a simple valgrind tool that tracks calls to certain
functions, and I was able to use the lackey code to work out how to do
that,
but I can't work out how to get the parameters the the function is called
with.
To be honest, I'm not even
I want the xml content to go to --xml-file and everything else
to --log-file, the file names being different. Is there a way to do this.
That's how it is supposed to work already!
--xml=yes --log-file=/tmp/valgrind_myapp.pid%p
--xml-file=/tmp/valgrind_myapp.xml%p
should do
any
filtering/searching/analysis of valgrind_myapp.pid%p, you only
need to distinguish empty vs nonempty.
J
On Thursday 06 August 2009, Madhan Sadasivam wrote:
It sure does Julian, I messed something for sure in my earlier trial.
Thanks,
Madhan.
On Thu, Aug 6, 2009 at 2:42 PM, Julian Seward
./boost_cyl_bessel_i_valgrind_bug_test
==28028== Memcheck, a memory error detector.
==28028== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==28028== Using LibVEX rev 1884, a library for dynamic binary translation.
==28028== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==28028== Using valgrind
We are pleased to announce a new release of Valgrind, version 3.5.0,
available from http://www.valgrind.org.
Valgrind is an open-source suite of simulation based debugging and
profiling tools. With the tools that come with Valgrind, you can
automatically detect many memory management and
On Thursday 20 August 2009, Paul Floyd wrote:
Nikos Chantziaras wrote:
If you look at the release notes of 3.5.0 (they were posted here too)
you'll see that this change is intended. So if you want the extra
suppression files, you will need to copy them manually. The specific
note said:
On Monday 24 August 2009 10:22:27 am Ken wrote:
I used callgrind to profile a storage engine of mysql and got this out put.
Callgrind: threads.c:247 (vgCallgrind_post_signal): Assertion 'tid ==
vgCallgrind_current_tid' failed.
I think that's been fixed in 3.5.0 (not 100% sure though).
On Wednesday 16 September 2009, Sean McBride wrote:
Hi all,
I'm not seeing source file names and line numbers running memcheck on
Mac OS X 10.5.8. After some investigation I determined valgrind does
not deal well with spaces in path names. :(
Ah, darn .. (sinking feeling ..)
Duh.
Yes,
How to proceed? Is this a valgrind bug?
File a bug, including exact details of how to reproduce, so
that it doesn't get forgotten about. Adding a small standalone
test case will majorly increase the chances of it being
fixed.
Then, see if --sim-hints=lax-ioctls helps work around this
for
valgrind: m_transtab.c:808 (invalidate_icache): Assertion 'cls == 32 ||
cls == 64 || cls == 128' failed.
Maybe try allowing a value of 16. (I think there are two places
where this is checked; you'll fall over the other shortly.)
J
On Saturday 10 October 2009, John Reiser wrote:
- memcheck/mc_main.c; set_address_range_perms()
VG_(message)(Vg_UserMsg, Warning: set address range perms:
large range [0x%lx, 0x%lx) (%s)\n,
Plant a breakpoint on that message in
*Memcheck: mc_machine.c:673 (get_otrack_shadow_offset_wrk): the
'impossible' happened.
It's a bug in memcheck. Should be easy to fix. What version of
valgrind is this, exactly? And what architecture are you running on?
J
*Memcheck: mc_machine.c:673 (get_otrack_shadow_offset_wrk): the
'impossible' happened.
What was the line immediately before this one? Specifically, I want
to see the result from this printf
VG_(printf)(MC_(get_otrack_shadow_offset)(x86)(off=%d,sz=%d)\n,
offset,szB);
J
On Friday 22 January 2010, tom fogal wrote:
I'm seeing leaks such as [1] and [2] in an application I work on. A
potential caveat is that I am compiling with _GLIBCXX_DEBUG, and thus I
should be getting a debug STL
That might be an out-of-date thing to do. See
On Sunday 31 January 2010, tom fogal wrote:
Matt Funk matze...@gmx.net writes:
is NOT suppressed by the following statement (in my suppression file):
It might be that it doesn't match because you deleted the write(buf)
part.
Debugging MPI apps with Valgrind is certainly possible, but you
The method used in line 611 is in a different class:
267:Agent *Cell::getVegAgent(spcid id) const {
268: Agent *pAgent = NULL;
269: if (id NUM_VEG) {
270: pAgent = m_apVegetation[id];
271: }
272: // this is to check for uninitialized
273: if (pAgent
On Monday 15 February 2010, Tom Hughes wrote:
On 15/02/10 08:23, stecca michele wrote:
Hi all...
The problem is not related to the CRC error but to JAVA 1.6.
I successfully used Valgrind with a C program and with a JAVA 1.5 too.
The problem is related to JAVA 1.6. I tried to run it
--4274-- Reading debug info from /lib/libc-2.10.1.so ..
--4274-- .. CRC mismatch (computed e2035481 wanted a2d8b96b)
--4274-- Reading debug info from /usr/lib/debug/lib/libc-2.10.1.so ..
Seems like find_debug_file calls open_debug_file with various different
names to see if any of them
Sounds like it might be a known bug which has been fixed,
https://bugs.kde.org/show_bug.cgi?id=205541
Check out the trunk and try that. Instructions are at
http://www.valgrind.org/downloads/repository.html
Note that Memcheck doesn't like user-space threading implementations
much, and so you
Excellent, the svn version removes many violations. I still have a
couple, though. Here are two samples which show up quite often:
==5789== Thread 1:
==5789== Invalid read of size 16
==5789==at 0x303E27E164: __GI_strcmp (in /lib64/libc-2.11.1.so)
Try adding, to
This seems to work :) Before I send the diff, let me ask another set
of questions. Maybe some other simple copy (I searched the files in
./memcheck, but did not find any replacements there -- with my very
little knowledge on memcheck):
=11294== Thread 4:
==11294== Invalid read of size 4
Is there going to be support for Big Endian in the future releases.
There are no plans to support bigendian-ARM at present.
J
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed
On Wednesday 07 April 2010, Tom Hughes wrote:
On 07/04/10 20:15, Oliver Schneider wrote:
Or perhaps there is a good reason why Valgrind doesn't have that (given
I am not blind and the option truly doesn't exist).
The good reason is that right back when valgrind was started
experimentation
On Thursday 20 May 2010 04:01:49 Alejandro Llanos wrote:
Yes, sorry, that is a noob error
Thanks =)
But now I have a question about you said,
Valgrind recognize my processor like a amd64, right??
So, Does it matter? if I want to run Cachegrind for example. Or What other
consequences can
The easiest thing to do for a start is put a full fork of valgrind +
Avalanche up on a repository somewhere. That way at least people can
see and use it while you decide if you want to take the support hit of
keeping up with the main Valgrind branch.
Did the message that the above text
On Wednesday 26 May 2010, Dallman, John wrote:
This is fine with some kinds of data. One can make a smaller bitmap,
or a shorter sound clip. But with what I do - accurate 3D shape
representation - one can't get anything meaningful into 1KB or so.
I just took a look at our directory of
Thank you. I just tried r11145. It stops both with drd and memcheck,
even in very small programs, after giving the following output:
valgrind: mmap(0x40, 823296) failed in UME with error 22 (Invalid
argument). valgrind: this can be caused by executables with very large
text, data or bss
Oh, darn. It looks like I broke cross compilation recently by
introducing link_tool_exe.c as part of the build process.
Honestly .. the your best bet is to rewrite link_tool_exe.c as
a perl script, so it can run on the host. I actually started out
to write it as a perl script, but couldn't
Probably best just to use Math::BigInt then you can do arbitrary
precision integer arithmetic regardless of the underlying platform.
Is Math::BigInt is supported as standard in Perl? and also, in older
Perls? Obviously if the build process is going to rely on it then
it needs to be available
It will help a lot if you specify the byte values (say, 8 of them)
in the instruction stream at address 0x9ceb615.
Yes. You didn't show the actual bytes it is complaining about, which
are present in the failure message. Without those it is impossible to
say anything.
==1460==by
It will help a lot if you specify the byte values (say, 8 of them)
in the instruction stream at address 0x9ceb615.
Yes. You didn't show the actual bytes it is complaining about, which
are present in the failure message. Without those it is impossible to
say anything.
How would I
On Monday, June 07, 2010, Tom Hughes wrote:
On 07/06/10 07:15, Julian Seward wrote:
Probably best just to use Math::BigInt then you can do arbitrary
precision integer arithmetic regardless of the underlying platform.
Is Math::BigInt is supported as standard in Perl? and also, in older
That's interesting. I remember rumours that there was a bug
in the env var handling once before, but I could not find it.
I wonder if it got filed as a bug. Dan, one of yours maybe?
J
On Monday, June 14, 2010, Thomas Rast wrote:
Thomas Rast wrote:
0x7fffc45381fb GIT_DIFF_TOOM=bad-tool
On Monday, June 14, 2010, Thomas Rast wrote:
Sorry, I should have quoted the link, I had it in the original post:
http://bugs.kde.org/show_bug.cgi?id=215914
The symptomps match so I think it's this bug.
Please could you add your analysis and patch to the above URL.
Bug reports and fixes
With --demangle=yes, Valgrind generates a SIGSEGV almost immediately in
VG_(strcmp) and with --demangle=no, it doesn't. Pretty symbols would have
helped me get closer to a solution to my problem, but ugly symbols are
not very helpful.
Just to make this very clear: you can convert an ugly
On Tuesday, June 29, 2010, Matthew Mosby wrote:
Hello everyone,
I am having some problems installing valgrind on my mac. I am trying
to use the regular gcc compiler (gcc4.4.4) and am running into
problems as it does not support two or the options specified in the
makefile
-arch
Valgrind has never supported a.out binaries. If a.out.h is being
included, it must be for some other reason.
J
On Wednesday, July 21, 2010, Karl Krach wrote:
Hello,
I want to compile the Valgrind on x86 for PowerPC target. I use the
toolchain from Buildroot, and the compilation stops
Nothing unusual about getting the message, as the headers contained in
our VCS are from 3.5.0. However, what I was wondering now is whether it
is possible to update the headers in our VCS and whether it is going to
work on older Valgrind versions. Basically all other Valgrind
installations
On Thursday, July 29, 2010, İsmail Dönmez wrote:
Hello;
I was happy to hear Valgrind is ported darwin/amd64, so I grabbed the
sources from trunk and compiled it. But it crashes on startup, here are
some details;
I am surprised to hear this. I have been using trunk on
Mac OSX 10.6 64bit
On Wednesday, July 28, 2010, Barry L. Rountree wrote:
The Valgrind: A Program Supervision Framework mentions One
important design decision was to ensure Valgrind could stop
simulated CPU and revert back to the real CPU part way through
program execution.
I'm not seeing this mentioned
I got valgrind source from svn://svn.valgrind.org/valgrind/branches/ARM
That branch is old (closed). It has been merged into the trunk, so you
should use svn://svn.valgrind.org/valgrind/trunk.
Alternatively if you want to try experimental Thumb/Thumb2 support
then try
On Friday, July 30, 2010, myrmidia wrote:
Hi there,
I try to use valgrind with a Java program to detect memory leak within a
'C' library. This 'C' library is access by JNA (Java Native Access :
https://jna.dev.java.net) framework... For information, this program is
running on a Virtual
: 11248
Node Kind: directory
Schedule: normal
Last Changed Author: bart
Last Changed Rev: 11248
Last Changed Date: 2010-07-31 14:37:58 +0100 (Sat, 31 Jul 2010)
Thanks
--- On Tue, 8/3/10, Julian Seward jsew...@acm.org wrote:
From: Julian Seward jsew...@acm.org
Subject: Re: [Valgrind-users
Exactly what sequence of commands did you give to fetch, configure
and build the source?
J
On Wednesday, August 04, 2010, Gus Steurer wrote:
Hello,
After attempting to install Valgrind on Snow Leopard, I am treated with
i686-apple-darwin10-gcc-4.2.1: ./m_mach/mach_vmUser.c: No such file
make -k check builds all the regtests that it can; if something breaks
then it just moves on to the next one.
Then to run them you can do
To run one test, you must do something like:
perl tests/vg_regtest memcheck/tests/addressable
J
You can also send output to a network socket (eg, --log-socket=127.0.0.1:1500)
and have the valgrind-listener program listen on the socket. This is
really really useful (at least I think so :-) but nobody seems to know
it exists.
J
On Thursday, August 12, 2010, WAROQUIERS Philippe wrote:
You
On Thursday, August 12, 2010, WAROQUIERS Philippe wrote:
From: Julian Seward [mailto:jsew...@acm.org]
You can also send output to a network socket (eg,
--log-socket=127.0.0.1:1500)
and have the valgrind-listener program listen on the socket. This is
really really useful (at least I think so
On Thursday, August 12, 2010, Madhan Sadasivam wrote:
This seems to be a valid issue:
[..]
- confirmed on x86 and AMD64 bit systems with Valgrind 3.5.0.
As Dan says, this is already fixed in the trunk. Please check out
and try it using the directions listed at
This has been fixed in the trunk. You can check out and build it
easily using the instructions shown at
http://www.valgrind.org/downloads/repository.html
J
On Monday, August 16, 2010, Gaetano Mendola wrote:
Hi all,
I'm using valgrind-3.6.0.SVN-Debian installed on my ubuntu distribution,
On Thursday, September 09, 2010, Thomas Reilly wrote:
MacOS 10.6, valgrind-svn from a couple weeks ago.
vex x86-IR: unhandled instruction bytes: 0x66 0xF 0xBF 0x44
==880== valgrind: Unrecognised instruction at address 0x307dab.
...
==880== Process terminating with default action of signal 4
On Wednesday, September 15, 2010, Alexander Potapenko wrote:
This is the 3DNow! pfadd instruction.
Looks like Valgrind doesn't currently support 3DNow!, but the cpuid
implementation claims it does, so your code tries to execute it.
cat /proc/cpuinfo on the cpu emulated since r2011 says
flags
any help in overcoming this would be appreciated.
Use gcc.
J
On Sunday, September 26, 2010, Hans Pirnay wrote:
Hello everyone,
I get the following error trying to compile valgrind 3.5.0 with icc
version 11.1:
make exits with the following error:
...
icc -Wno-long-long
IIRC, you need to be running a 64-bit kernel. V will segfault on AIX
if you're running a 32-bit kernel.
Also I thought 3.4.1 worked on AIX5.3. It's generally better than 3.3.1,
if only because then you'll have origin tracking for Memcheck.
J
On Friday, January 21, 2011, Stutz Oliver wrote:
/long_namespace_xml.cpp
as they might be related to this problem.
J
On Friday, January 28, 2011, Holtgrewe, Manuel wrote:
Is there any news on this?
Am 11.01.2011 um 08:46 schrieb Manuel Holtgrewe:
I am using version 3.6.0.
Am 10.01.2011 um 18:13 schrieb Julian Seward:
I thought we fixed this already
On Friday, January 28, 2011, john skaller wrote:
Quick Google shows you're not the only one with a problem:
http://www.mail-archive.com/valgrind-users@lists.sourceforge.net/msg01801.h
tml https://bugs.kde.org/show_bug.cgi?id=205241#c80
http://markmail.org/message/rxkvvfgqozlepq3y
Only the
On Wednesday, February 02, 2011, Josef Weidendorfer wrote:
It looks like GCC parses 3i as complex integer literal, and implicitly
casts to a regular integer without warning, which then would become size
== 0, which obviously is not the right thing here.
Makes sense, except that what it
1 - 100 of 345 matches
Mail list logo
