On Apr 11, 2013, at 9:00 AM CDT, Andrew Clinton ajcli...@gmail.com wrote:
Slow down / pause is something that's planned. Rewind is difficult since
this would require actually logging the trace data (currently it's
transient), which would take up a huge amount of space - though this may be
On Jan 23, 2013, at 8:08 AM CST, David Faure wrote:
On Monday 27 August 2012 15:25:14 Marc Mutz wrote:
If atomic loads and stores on x86 are implemented with a volatile cast,
then the compiler can't reorder stuff around them, either. Not more than
with a std::atomic, at least. QAtomic does
On Jan 20, 2013, at 3:50 PM CST, Nick Overdijk wrote:
I have a nice stacktrace from some memory error in valgrind, and it fails to
print the source file + line number somewhere. Here's the trace:
==63113== Conditional jump or move depends on uninitialised value(s)
[…]
==63113==
On Jan 23, 2013, at 9:55 AM CST, Thiago Macieira wrote:
On quarta-feira, 23 de janeiro de 2013 09.22.49, Dave Goodell wrote:
If you don't want to write inline assembly, this might be your best bet.
But on TSO systems like x86, you only need a compiler barrier. In x86
inline assembly
On Jan 23, 2013, at 10:33 AM CST, Dave Goodell wrote:
Julian/Bart/etc. may have more to add here. I remember having trouble with
annotating load-acquire/store-release in the past. Here's the (only
partially helpful) thread on the topic:
Sorry for the extra email. I accidentally whacked
That looks like it's working to me, at least for a 64-bit architecture. The
failure in the config.log that you have posted is for the 32-bit side of
things. Valgrind builds bi-arch, but MPI implementations generally don't. So
in practice you won't get bi-arch MPI wrappers unless you hack
On May 7, 2012, at 2:15 PM CDT, Martin Kalany wrote:
Am 06.05.2012 00:54, schrieb Philippe Waroquiers:
On Sun, 2012-05-06 at 00:24 +0200, Martin Kalany wrote:
Valgrind documation states that The MPI functions to be wrapped are
assumed to be in an ELF shared object with soname matching
On May 7, 2012, at 2:45 PM CDT, Martin Kalany wrote:
Am 07.05.2012 21:34, schrieb Dave Goodell:
What does ldd YOUR_BINARY_HERE give you? You should see lines that look
like this in the output:
8
libmpich.so.6 =
/sandbox/goodell/mpich2-installed/lib/libmpich.so.6
On Mar 1, 2012, at 5:16 AM CST, Wadud Miah (ITCS) wrote:
this is using Platform MPI 8.1 which is version 2.0 compliant. However, it
just gets stuck at the line:
checking primary target for usable MPI2-compliant C compiler and mpi.h...
I can see some mpicc processes, but nothing proceeds
I'm not sure what's up with your RHEL box, but the Mac has a surprising (and
annoying) trick for getting debugging information. For whatever reason, the
usable debugging information for a Darwin binary isn't actually stored in the
binary itself. Instead you must run a program called dsymutil
On Aug 26, 2011, at 1:12 PM CDT, Sayre, Alan N wrote:
Yes the configure script simply hangs and won't complete successfully.
mpicc resolves to /opt/platform_mpi/bin/mpicc.
Eventually I need to run valgrind on my program. Any suggestions on how
to get this to work?
Are you trying to use
On Aug 26, 2011, at 12:00 PM CDT, Sayre, Alan N wrote:
I am trying to compile v 3.6.1 and configure gets stuck on
“checking primary target for usable MPI2-compliant C compiler and mpi.h..”
What am I doing wrong?
What does gets stuck mean? That the configure script simply hangs and
On Jun 28, 2011, at 12:45 PM CDT, janjust wrote:
I'm trying to build valgrind for testing some simple MPI programs;
however, when building valgrind everything but the libmpiwrap_platform.so
builds. The error that I'm getting is:
-
mpicc-I../include -g -O
On Jun 28, 2011, at 3:45 PM CDT, Dave Goodell wrote:
On Jun 28, 2011, at 2:56 PM CDT, janjust wrote:
Thanks for the reply. ; Setting $MPI_CC=mpicc -noswitcherror moved the
build a bit further but it exited with a different error, this time:
---
...
pgcc-Warning-Unknown switch: -fno
On May 24, 2011, at 12:02 PM CDT, John Reiser wrote:
Those are probably the most labor-intensive ways that you can do it. It's
usually easier to just pass --without-mpicc to configure and use the
normal build process in all other respects.
1. No documentation: no mention of MPI in
If you are trying to trace application calls to the MPI library, then rebuild
your MPICH2 installation with the --enable-shared configure flag. MPICH2
does not build shared libraries by default, but the Valgrind MPI wrappers
expect a shared library in order to build.
If you are trying to
On Apr 12, 2011, at 11:18 AM CDT, David Chapman wrote:
On 4/12/2011 8:24 AM, Wan Mohd Fairuz Wan Ismail wrote:
Hi,
I did a simple code to test out Overlapping src and dst pointers in memcpy
using memcheck. But it seems memcheck don't detect the src and dst addresses
are identical. Any
On Jan 20, 2011, at 6:43 PM CST, john skaller wrote:
OK, so I do this now:
...
if(debug)
fprintf(stderr, Check if *%p=%p is a pointer\n,i,*(void**)i);
scan_object(*(void**)i, reclimit);
...
The VALGRIND macro there doesn't seem to be working, I must be
doing
On Jan 20, 2011, at 4:35 AM CST, john skaller wrote:
On 20/01/2011, at 3:04 AM, Dave Goodell wrote:
On Jan 19, 2011, at 9:52 AM CST, john skaller wrote:
On 20/01/2011, at 2:39 AM, Dave Goodell wrote:
On Jan 18, 2011, at 10:56 PM CST, john skaller wrote:
I could rewrite the GC so
On Jan 20, 2011, at 6:07 PM CST, john skaller wrote:
Hmmm ..ok did some client request stuff .. looks like I found a bug in OSX!
First, what's this?
==7005== Command: tools/flx_ls
==7005==
--7005-- warning: addVar: in range 0xcb2 .. 0xcd7 outside segment 0x1
.. 0x1000eefff
On Jan 19, 2011, at 9:52 AM CST, john skaller wrote:
On 20/01/2011, at 2:39 AM, Dave Goodell wrote:
On Jan 18, 2011, at 10:56 PM CST, john skaller wrote:
I could rewrite the GC so that the stack scan is in a separate subroutine,
and then just exclude that using Valgrinds nice suppression
A few things that might help you here:
1) Build your program with debugging information, which will help you to
understand exactly which line is causing a problem in your stack traces.
2) Tracking down uninitialized value warnings is much easier if you use the
--track-origins=yes option to
As Julian mentioned, a workaround is to disable Valgrind's MPI wrapper support.
An alternative to --with-mpicc=/some/path/that/does/not/exist is
--without-mpicc.
That said, this is actually a minor bug in MPICH2 that I'm surprised hasn't
cropped up until now. I just fixed this on the MPICH2
On Dec 23, 2010, at 12:25 PM CST, Dallman, John wrote:
It appears that everything used in that line is set. Might
valgrind not recognize the values set to idx and length in
the call to sscanf()?
With puzzling things like this, try simply printing the values in
question with printf().
Hi Edwin,
On Jul 20, 2010, at 10:32 AM CDT, Török Edwin wrote:
While it is possible to teach valgrind about ClamAV's pools (see
attached mpool.patch for example), I think valgrind will be more
effective if I just disable ClamAV's pools (and let it use malloc).
This sounds like a practical
On Jul 20, 2010, at 2:07 PM CDT, Török Edwin wrote:
On Tue, 20 Jul 2010 13:34:12 -0500
Dave Goodell good...@mcs.anl.gov wrote:
On Jul 20, 2010, at 10:32 AM CDT, Török Edwin wrote:
While it is possible to teach valgrind about ClamAV's pools (see
attached mpool.patch for example), I think
Is your application multithreaded? Thread scheduling under valgrind is very
different from running normally. AFAIK, only one thread runs at a time, which
can both slow down threaded applications substantially and also increase the
chances of hitting a deadlock bug in your code.
-Dave
On Jul
On Jun 23, 2010, at 5:59 AM CDT, Satya V. Gupta wrote:
Would you happen to know if c++filt requires the instrumented process to be
running in order for it to do the translation? Or is the required
information already present in the Valgrind trace for c++filt to do this
translation
On Jun 8, 2010 , at 3:05 PM CDT, Alex Slover wrote:
Hello-
I'm using the custom memory pool macros for the first time, and though
I've read through all of Memcheck's documentation, there are a few
questions I'm still not quite clear on. I'd also like to explain my
custom memory allocation
On Apr 14, 2010, at 6:01 AM, Mogens Lindholdt Lauridsen wrote:
First of all... I don't know what went wrong, but I apparently
didn't have your patch in the valgrind binary when I ran that test.
Sorry.
No worries, it's easy to do.
I have now tried your test program without valgrind, and
was using.
-Dave
On Apr 9, 2010, at 12:29 PM, Dave Goodell wrote:
I think it's a dcbzl cache line zeroing instruction. The valgrind
folks already have a bug filed for it:
http://bugs.kde.org/show_bug.cgi?id=135264
I don't know how hard it would be to add to VEX/valgrind. Probably
easy
hours and only seen this one time. I guess that the trigger for this
piece of code is dependent on the input data from the internet radio
and also timing.
I will see if I can make a testcase to prove your patch.
Thanks!
Best regards,
Mogens
Dave Goodell good...@mcs.anl.gov
13-04
???
Dave Goodell good...@mcs.anl.gov
13-04-2010 22:28
To
Mogens Lindholdt Lauridsen m...@bang-olufsen.dk
cc
valgrind-users@lists.sourceforge.net
Subject
Re: [Valgrind-users] PPC: unhandled instruction: 0x7C2907EC
I already attached a simple testcase to the ticket [1], although
On Jan 31, 2010, at 1:00 AM, tom fogal wrote:
This is the wrong forum to ask for available suppression files, for
the most part. In this case, you want to go bother your MPI library
vendor.
Matt,
If you are using valgrind with MPICH2 then you should make sure that
you configure MPICH2
On Jan 27, 2010, at 3:28 PM, tom fogal wrote:
vicky lin vicky@gmail.com writes:
There was something strange happened when I used valgrind. I run
my linux program written in c++ and it threw a segment fault, but
when I tried valgrind --tool=memcheck -v ./mycode , the program
did't
On Jan 6, 2010, at 8:54 PM, tom fogal wrote:
Side note to the valgrind devs: does the documentation need to be
updated here? The last paragraph in Support for Threads (linked
below) says that the use of atomic instruction sequences in shared
memory between processes will not work reliably,
36 matches
Mail list logo