On Apr 11, 2013, at 9:00 AM CDT, Andrew Clinton 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
> useful for sho
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.
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 "compi
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== Uninit
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
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 th
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<
>> libmpic
On May 7, 2012, at 3:54 PM CDT, Philippe Waroquiers wrote:
> For what concerns the original problem: I understand it is because
> Valgrind was configured with a different mpi that the one you are using
> and that created a mixup in the libs. Is that the explanation ?
I don't think this has been
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 matc
OS X has a terrible anti-feature called ".dSYM" files. These are directories
that you must generate after you build you program, with a tool called
"dsymutil". Search for "--dsymutil" in this section of the valgrind manual:
http://valgrind.org/docs/manual/manual-core.html#manual-core.erropts
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 pro
IIRC, the Open MPI installation that ships with your Mac is not bi-arch. Try
passing "--without-mpicc" as an argument to the configure script.
-Dave
On Dec 23, 2011, at 4:48 PM CST, Xiang Zheng wrote:
> Dear Valgrind Scholars,
>
> I am a new user of this super powerful software.
>
> I just w
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 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 an
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 t
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:
>&g
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:
>
> ---
> make[2]: Entering directory
> `/autofs/na1_home/janjust/valgrind/valgrind_sources/valg
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_.so
> builds. The error that I'm getting is:
>
> -
> mpicc-I../include -g -O -fno-omit-frame-pointer -
On Jun 17, 2011, at 10:52 AM CDT, Stephanie Stroka wrote:
> Am 17.06.2011 17:49, schrieb Tom Hughes:
>> On 17/06/11 16:45, Stephanie Stroka wrote:
>>
>>> My code at that position looks like this:
>>>
>>> 284 static uint* sort(uint** matrix, uint width, uint height) {
>>> 285 uint* data = (ui
On May 24, 2011, at 12:31 PM CDT, Dave Goodell wrote:
> I've got ~1/2 of a patch to fix the mpicc detection already written that has
> been shelved for a while, perhaps I should resume work on it. If I can get
> that working then none of these solutions should be necessar
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
On May 23, 2011, at 9:36 PM CDT, John Reiser wrote:
>> I just like to know whether it's possible to disable the MPI feature when
>> building Valgrind.
>
> Here are two things to try:
>
> 1) Uninstall MPI (at least 'mpicc') then re-build valgrind, starting with
> ./autogen.sh . See "Building
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 tra
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.
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 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
> .. 0x1000ee
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 1
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 us
On Jan 18, 2011, at 10:56 PM CST, john skaller wrote:
> On 19/01/2011, at 5:58 AM, Dave Goodell wrote:
>
>> 2) Tracking down "uninitialized value" warnings is much easier if you use
>> the "--track-origins=yes" option to Valgrind.
>
> Also done
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 MPIC
zed, it has an undefined (garbage) value.
So in your case, take a look at any local variables that are declared in that
function and see if they are used on line 7071. Then make sure that they will
always have been initialized by the time you reach that line.
-Dave
> -Original Message--
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 pri
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 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
>>>
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
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 independ
On Jun 9, 2010 , at 8:08 AM CDT, Alex Slover wrote:
> On Tue, Jun 8, 2010 at 5:01 PM, Dave Goodell wrote:
>> On Jun 8, 2010 , at 3:05 PM CDT, Alex Slover wrote:
>>> 2. I understand that I should use MAKE_MEM_NOACCESS to mark sections
>>> of memory that are used inter
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 alloca
On Apr 29, 2010, at 5:10 PM, Joshua R. Tepper wrote:
> David:
> Thanks for the script (and to Ms. Pittman as well).
(FYI, that's Mr. Pittman; Ashley is male)
> This looks very
> helpful. The only possible issue, I think, will be to guarantee that
> each process has a different pid, which I don'
On Apr 28, 2010, at 1:36 AM, Julian Seward wrote:
> On Wednesday 28 April 2010, Joshua R. Tepper wrote:
>> Hi all,
>> I am trying to use Valgrind to debug an MPI application, but things
>> don't
>> seem to work. I understand that Valgrind explicitly implements
>> wrapper
>> functions for MPI
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, a
cks
> ==823== suppressed: 0 bytes in 0 blocks
> ==823== Rerun with --leak-check=full to see details of leaked memory
> ==823==
> ==823== For counts of detected and suppressed errors, rerun with: -v
> ==823== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)
> I
on for something like 500
> 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
that I 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 woul
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 for someone like Julian who knows that code well, harder for
someon
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 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 throw seg
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 relia
49 matches
Mail list logo
