Jorge de Antonio writes:
> So please, if someone already has (or knows where to find) Valgrind's
> binaries already working for AIX 5.2 o 5.3 please let me know, I'd
> really, really apreciate it.
As someone who has occasionally developed on AIX myself, I'd recommend
just developing on Linux and
"Osman, Ahmed" writes:
> I'm trying to run valgrind 3.5 on my code with these options "--log-file=resu
> lts/valgrind_%p.log --num-callers=50 --child-silent-after-fork=yes --gen-supp
> ressions=yes"
>
> I'm seeing the following in the log files:
> ==4630== Memcheck, a memory error detector
[snip]
ajit gunge writes:
> I wanted to know are there any good programs which I can refer too to
> get the real feel of valgrind.I want to use this tool and see exactly
> how this works and I ant to know all the options.Is it used only for
> mem leak issues or any thing apart from this.
You could start
ajit gunge writes:
> I am trying to install valgrind on one of my servers which is running
> RHEL.It is asking password for me to install.I dotn know what
> password I have to give for running valgri nd.Can anyone suggest what
> am I doing wrong.
You do not need a password to run valgrind.
You a
Massif is saying that I have allocated a (quite large) std::vector
inside my `main' function [1]. The vector template is not used at all
in the file which declares the main function.
Is this vector coming from a static initializer, then? How can I
identify the location of the allocation?
This i
maxime louvel writes:
> The problem is that decoders have real-time constraints and thus
> monitoring an overwhelmed application may lead to false information.
I don't think anything akin to valgrind is the right tool for the job.
Just try running your program through the "null" tool ("lackey"? o
Douglas Leeder writes:
> Alec Matusis wrote:
> > I am trying to debug a leaking TCP server written in Python running
> > on Linux x86_64
>
> I think you're problem is right there - 'Python'.
>
> Python objects can't be leaked (at the C/valgrind level), because the
> Python run-time will keep refer
Kenneth Simpson writes:
> When I run a program with stderr to the screen and stdio to a file, valgrind
> and gdb work fine.
>
> But when I run the same program with stderr and stdio to the same file, gdb c
> an't attach to the process (which results in a defunct process.)
>
> Here is the comm
Matt Funk writes:
> i have seen some stuff on the mailing list about this, however, it
> hasn't gotten me anywhere. So basically i am wondering:
> - is this warning is to be expected and thus to be ignored?
As a general rule, no valgrind error is something you should ignore.
That said, everyone's
Matt Funk writes:
> {
>
>Memcheck:Param
>write(buf)
>fun:__write_nocancel
>fun:ibv_cmd_create_cq
>fun:mthca_create_cq
>fun:ibv_create_cq@@IBVERBS_1.1
>fun:rdma_iba_hca_init
>fun:MPIDI_CH3I_RMDA_init
>fun:MPIDI_CH3_Init
>fun:MPID_Init
>fun:MPIR_Init_t
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 segment fault and continued to run and returned the
> e
writes:
> I've a simple FORTRAN code that does some operation (no more than
> addition and multiplication) with complex number.
>
> I've compiled my code with the -g option and with the -o3. And some
> of the resulting values are different. So I started inserting some
> WRITE statements in the in
Julian Seward writes:
> 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 mig
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 -- though by the internal names I see in
the symbols here, I don't appear to be getting any sort of debug bits
for std::string.
Nathan Rittenhouse writes:
> Currently, I'm running the Catchconv Valgrind extension against
> an application to generate a path constraint. The application in
> question clones() several times and even has a clone() from inside of
> a clone()'d thread/process.
>
> I added some debug message print
Zvi Vered writes:
> When I ran 'valgrind ln -l' I got:
> valgrind: failed to start tool 'memcheck' for platform 'x86-linux': no
> such file or directory
>
> What can be the reason for such an error ?
AFAIK, "valgrind" is only a thin wrapper whose job it is to effectively
or exactly LD_PRELOAD a
;d memory.
I've never heard of anyone using the latter, but then again I don't
interact with many people that use even posix shared memory anyway.
-tom
[1] http://valgrind.org/docs/manual/dist.news.html
> On Thu, Jan 7, 2010 at 6:06 AM, tom fogal wrote:
>
> > Milind writes:
>
Milind writes:
[snip]
> I am writing an application that will run on a system that
> has multiple CPU cores and each core having multiple hardware
> threads. With multiple CPU cores there will be simultaneous memory
> access requests.
>
> I would like to know
> - whether Valgrind supports multicor
essage-ID: <803a75c30912271044ked995bewe8843b4e2d5c5...@mail.gmail.com>
Subject:
in C++
From: Selçuk Cevher
To: tom fogal
- --0015174483dc3dafca047bba2e3a
Content-Type: text/plain; charset=ISO-8859-1
To be able to run as a daemon, my application runs the fork() command for
once.
writes:
> Hi All,
>
> I have a bunch of C++ application which runs as daemons in Linux.
>
> Another reason for it to crash might be corrupted input data that it
> processes.
>
> I used --leak-check=yes and --log-file=foo.txt options with Valgrind.
>
> However, Valgrind did not report any invalid w
Indi Tristanto writes:
> I am trying to debug a large iterative solver that has been compiled using =
> intel fortran 10 and open mpi 1.2.6.
>
> Invalid write of size 8
> at 0x511BF6B: _int_malloc (in /opt/openmpi-1.2.6/intel/lib/libopen-pal.so=
> .0.0.0) =20
> by 0x511B710: malloc (in /opt/o
yami writes:
> I tried to run a amd64-linux program on valgrind 3.5.0, but valgrind
> said modify_ldt syscall is missing. After checking the 3.5.0 source
> code, I think Valgrind 3.5.0 does not support modify_ldt amd64-linux.
http://valgrind.org/docs/manual/dist.readme-missing.html
See: "Writing
waseem shaukat writes:
> For your help=2C i have tried make clean and make distclean but st=
> ill i got the same error. Is there another way to get rid of this corrupt l=
> ibrary.
Just rm the whole directory and re-extract from a tarball.
-tom
> > From: josef.weidendor...@gmx.de
> >
kiness you believe to be from the nvidia
driver, post one of the errors and I'll hopefully be able to identify
it as such.
Cheers,
-tom
> On Fri, Aug 14, 2009 at 4:59 PM, Michel Audette
> wrote:
>
> > FYI...
> >
> > Michel
> >
> > -- Forw
Michel Audette writes:
> See example below. I don't recall details of offending instructions
> being replaced by ??? in the past. Is this a new option that I should
> be setting, or an indication of a spurious error?
>
> ==27271== Use of uninitialised value of size 8
> ==27271==at 0x187FCEC6:
Christopher Kuhlman writes:
> The internet pages say that for "uninitialized value" errors, it is
> helpful to specify the "--track-origins=yes" option.
>
> Yet when I do, I get:
> valgrind: Bad option '--track-origins=yes'; aborting.
Check the version fo valgrind you've got. track-origins was a
y actual code?
Possible? Technically, yes. Exceedingly unlikely.
I (highly) recommend -D_GLIBCXX_DEBUG -D_GLIBCXX_CONCEPT_CHECKS when
using the STL w/ libstdc++.
-tom
> On Tue, Aug 11, 2009 at 9:13 AM, tom fogal wrote:
> > Jonathon writes:
> >> I was wondering if it is pos
Jonathon writes:
> I was wondering if it is possible to get valgrind to make an "assert"
> so my debugger can catch it when a memory error occurs? I would like
> to determine what is causing this memory error and it would be nice
> if I could do this.
No, but it can do better: suspend the proces
Ivan Ivanov writes:
> Just in case: the purpose why I need that is that I'd like to quickly
> find the source line where the allocation (and possible deallocation
> if this is a dangling pointer) of memory for some problematic object
> occurred. The point is when there are a lot of unfamiliar code
Hi Simon,
let's keep discussions on-list. Mostly since I'm no valgrind expert,
and if I make incorrect statements I'd like one to jump in with a clue
bat :)
Simon Gornall writes:
>
> On Jul 12, 2009, at 2:02 PM, tom fogal wrote:
>
> > Simon Gornall wri
Simon Gornall writes:
> I'm trying to run my application under valgrind, and it's failing
> when I initialise the OpenGL context... I get the debug log:
To clarify -- are you saying that it can initialize the context fine
when run standalone, and only fails through valgrind?
(I'm going to assume
Please keep discussions on-list.
David Gregorczyk writes:
> but what can I do to summarize massif's multiple outputs for
> each child process? I've tried to watch out memory usage for
> Xerces-C++ and get more than 10 output files. To get complete memory
> consumption, I have to intrepret every
David Gregorczyk writes:
> is there any possibility to detect maximum heap memory usage of an
> application?
[snip]
> I've tried --tool=massif but I didn't understand to interpret it
> correctly.
>
> Can anybody help me?
http://valgrind.org/docs/manual/ms-manual.html#ms-manual.theoutputpreamble
Andy Howell writes:
> Julian Seward wrote:
> >>When I specify --db-attach with helgrind, the debugger is attached to t
> he
> >> thread in question, not the its parent process. Is there a way to make it
> >> attach to the process instead?
> >
> > Not sure I quite understand. When you say "pa
4 -moreblah something.c
you can also check if the binary under test is 64bit with `file'.
-tom
> Patrick
>
> On Thu, May 14, 2009 at 03:03:37PM -0600, tom fogal wrote:
> > patrick.al...@noaa.gov writes:
> > > I am using valgrind 3.4.1 to try to find a memory leak.
patrick.al...@noaa.gov writes:
> I am using valgrind 3.4.1 to try to find a memory leak. My
> program has an initial routine which allocates a lot of memory -
> around 1 GB. When I run the program by itself it runs fine, however
> when I run it under valgrind, one of the many malloc calls in
> th
"Russell E. Owen" writes:
> 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).
[snip]
> `cd' to the
> directory where you want the object files and executabl
Evan writes:
> I need to run an opengl and mpi program remotely - with valgrind.
>
> I'm attempting to run a command like so:
>
> LD_PRELOAD=$prefix/lib/valgrind/amd64-linux/libmpiwrap.so mpirun -np
> $i $prefix/bin/valgrind vglrun ./test
This probably won't work because mpirun will spawn ssh'
Colin Miller writes:
> tom fogal wrote:
> > I'm seeing valgrind stack traces that point to errors from libraries
> > which shouldn't be relevant to the given error messages. Here's an
> > example:
> >
> >
> >
> > Any idea what&#
I'm seeing valgrind stack traces that point to errors from libraries
which shouldn't be relevant to the given error messages. Here's an
example:
Conditional jump or move depends on uninitialised value(s)
at 0x4C230A8: strlen (mc_replace_strmem.c:242)
by 0x402702: std::char_traits::
Ross Boylan writes:
> When I run a test program with leak-check, the first error is
> ==14820== Use of uninitialised value of size 4
> ==14820==at 0x40F6841: (within /usr/lib/libstdc++.so.6.0.10)
> ==14820==by 0x40FE394: std::ostreambuf_iterator ar> > std::num_put > > >::_M_insert_int(std:
Micah N Gorrell writes:
> Doesn't `definedness' propagate in valgrind? Further, as I remember
> > you would only see an issue when the uninitialized value directed a
> > computation, or was output.
> >
> > For example:
> >
> > 1 int m(int x) {
> > 2return x + 42;
> >
Micah N Gorrell writes:
> On Thu, 12 Feb 2009, valgrind-users-boun...@lists.sourceforge.net wrote:
>
> > On Thu, 12 Feb 2009, valgrind-users-boun...@lists.sourceforge.net wrote:
> >
> > > > So, if SocketReceive returned an uninitialised value then
> > > > it can cause this? So that tells me that
Christoph Bartoschek writes:
> Am Donnerstag, 5. Februar 2009 schrieb Julian Seward:
> > 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
Fernando Coelho writes:
[snip]
> For a final question, is there any log option that I am missing or it just =
> write the result on the screen?
$ valgrind --log-file=myprog.vg.%p /path/to/your/program --options
the `%p' gets replace with the process ID, which is nice when you're
doing multip
Julian Seward writes:
>
> A release candidate for Valgrind 3.4.0 is available at
> http://www.valgrind.org/downloads/valgrind-3.4.0.RC1.tar.bz2.
>
> Please give it a try on whatever platforms are important for
> you. Unless any showstopper bugs appear, the final 3.4.0 release
> will be on 2 Janu
Burlen Loring writes:
> Hi all,
Hi Burlen! Hope all is well.
> Valgrind identifies uninitialized memory when it's used in a
> conditional. It's very smart and can tell when one uninitialized
> value is assigned to another. I'd like to be able to see is a trace
> of all of those assignments that
"Polina Dudnik" <[EMAIL PROTECTED]> writes:
> This relates back to my question about making threads switch more
> often. The reason for that is that I need to have data races. But I
> found the link to helgrind which talks about data races. What I am not
> clear about is how can data races occur if
forgot to CC the list..
--- Forwarded Message
Reply-To: [EMAIL PROTECTED]
From: tom fogal <[EMAIL PROTECTED]>
To: Frank Mertens <[EMAIL PROTECTED]>
Subject: Re: [Valgrind-users] valgrind reporting memory leaks with
pthread_getspecific()/pthread_setspecific
In-Reply-To: Your mes
Julian Seward <[EMAIL PROTECTED]> writes:
>
> > 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?
Brian Wainscott <[EMAIL PROTECTED]> writes:
> I've been a long time user of valgrind, but am having serious problems with
> recent versions. I don't know if it is the switch from ia32 to x86_64, the
> switch from lam 7 to openmpi, or the switch from valgrind 2 to valgrind 3,
[snip]
> When I bui
Julian Seward <[EMAIL PROTECTED]> writes:
>
> > > Darryl (I think) wants to see is something like:
> > >
> > > while in T1's C.S. `x', the variable `abc':
> > > saw a write from T1 of size whatever
> > > saw a write from T4 of size whatever
> > > saw a read from T3 of s
wanted to clarify up front.
Darryl Miles <[EMAIL PROTECTED]> writes:
> tom fogal wrote:
> > Darryl Miles <[EMAIL PROTECTED]> writes:
> >> tom fogal wrote:
> > It doesn't; I wrote this before I understood your `acquire a
> > VG-internal lock at syscall
Darryl Miles <[EMAIL PROTECTED]> writes:
> Julian Seward wrote:
> > I can't claim to really understand this, but I do have a couple of
> > questions:
> >
> > * "it knows that T2 is blocked in the kernel"
> > how does V know that a syscall it is about do perform (on behalf
> > of the client
Darryl Miles <[EMAIL PROTECTED]> writes:
> tom fogal wrote:
> > One thing I neglected to think about earlier is how one would do a
> > `Can I still run?' check. There is no notification to a user process
> > when a context switch comes back.
> >
Darryl Miles <[EMAIL PROTECTED]> writes:
> tom fogal wrote:
> > Darryl Miles <[EMAIL PROTECTED]> writes:
> >> Julian Seward wrote:
> >> Then on the return from the system call the current thread checks to see
> >> if it is still allowed to run, if i
Darryl Miles <[EMAIL PROTECTED]> writes:
> Julian Seward wrote:
> > Yes, I guess so. Although I'm not sure how this could be implemented.
> > The trick with the pipe in sema.c implements a lock well enough, but how
> > does one implement a lock in which (1) the unlocker can control which
> > threa
Darryl Miles <[EMAIL PROTECTED]> writes:
> John Shilkaitis wrote:
> > On Fri, Oct 24, 2008 at 4:58 PM, Darryl Miles
> > Is it possible to make valgrind dump out the locations of the "Still
> > Reachable" pointers to still allocated memory at program exit ?
> >
> > Add --show-reachable=yes
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.
It is too time consuming to use --gen-suppressions=all and then copy
and paste out
Brian Wainscott <[EMAIL PROTECTED]> writes:
>
> tom fogal wrote:
[snip]
> When I turn off this particular warning.I get no errors at all, until
> it dies in "free()", presumably from heap corruption.
Doh. I must have missed this in my earlier email; g
Brian Wainscott <[EMAIL PROTECTED]> writes:
>
> tom fogal wrote:
>
> > Brian Wainscott <[EMAIL PROTECTED]> writes:
> >
> >> But I'm still seeing LOTS of these which I didn't see in earlier
> >> versions of valgrind (circa. 2 years ag
ne it also reserves 8 bytes for the return value as well (even if
the return value is smaller, that is).
I guess the next step would be examining the assembly to verify. I'll
leave that as an excercise for the reader ;)
-tom
> tom fogal wrote:
> > Brian Wainscott <[EMAIL
Brian Wainscott <[EMAIL PROTECTED]> writes:
> #include
> main()
> {
>int i,j;
>
>for(i=j=0; i< 5; i++) {
> j=do_sub(j);
>}
>
>printf("Result = %d\n",j);
> }
> int do_sub(int in)
> {
>int out;
> //int junk=1;/* No errors */
>int junk; /* Errors */
>
>out
63 matches
Mail list logo
