and leaks,
or like this
valgrind -v ./main
if am only interested in the errors.
Hope this helps
Jody
On Mon, Jul 7, 2014 at 4:33 PM, Ying Zhang wrote:
> Hello,
>
> I'm testing valgrind with a very simple C program:
>
> #include
>
> int main()
> {
>
I must admit this null checking of mine is also an old school left-over...
On Tue, Oct 2, 2012 at 5:16 PM, David Chapman wrote:
> On 10/2/2012 7:33 AM, Patrick J. LoPresti wrote:
>>
>> On Tue, Oct 2, 2012 at 5:55 AM, jody wrote:
>>>
>>>
>>> -
the number of Cells was greater than 65535 the counter would
wrap over to 0 and start deleting the cells
with low indices for the second time.
So now only my curiosity question about the closing brackets remain :)
Jody
On Tue, Oct 2, 2012 at 3:35 PM, jody wrote:
> Thanks for the explanation.
bracket of the destructor listed as the caller
of the destructor itself?
Jody
On Tue, Oct 2, 2012 at 5:02 PM, David Faure wrote:
> On Tuesday 02 October 2012 14:55:57 jody wrote:
>> Th puzzling thing is that WorldTile.cpp:267 and TDWorker.cpp:130 refer
>> to the closing
Yes, i already did that (downloaded and built the tarball from the
Valgrind site) -
and now the memcpy messages have disappeared.
Thanks again
Jody
On Wed, Jun 13, 2012 at 10:04 AM, Igmar Palsenberg wrote:
>
>
>> Thank You for the information!
>> I am using valgrind 3.6.1
Thank You for the information!
I am using valgrind 3.6.1-r3 (newest gentoo ebuild)
Jody
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has ch
k You
Jody
On Tue, Jun 12, 2012 at 4:23 PM, jody wrote:
> Hi
>
> In my code i use memcpy to copy data between two arrays of unsigned char:
> memcpy(pNew, pDataPiece, iBlockSize);
>
> iBlockSize has the correct size (197) which i used to create pDataPiece
>
> In valgr
)?
Do i have to copy multiples of 8 to make memcpy and/or memmove happy?
Thank You
Jody
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has chan
k being only 40 bytes, i don't know if the developers
will hurry with fixing this... :)
jody
>> jody
>>
>> On Wed, Apr 14, 2010 at 9:15 AM, Zhenhua Zhang
>> wrote:
>>> Hi,
>>>
>>> Valgrind reports definitely lost memory leak when I am invo
Hi
It is very well possible that openpty itself has a leak.
It is quite common that library functions don't clean up nicely after
their work is done...
jody
On Wed, Apr 14, 2010 at 9:15 AM, Zhenhua Zhang wrote:
> Hi,
>
> Valgrind reports definitely lost memory leak when I am invo
Also make sure you compile with debug info (compiler option '-g' if you are
using gcc)
jody
On Wed, Apr 14, 2010 at 8:47 AM, Bjoern Doebel wrote:
> Ok. Can you add some kind of printf() to your app and see if you're
> running the right binary? As uninitialized value d
Thanks - i think the client-request VALGRIND_CHECK_VALUE_IS_DEFINED is
what i'm looking for.
Jody
On Tue, Feb 2, 2010 at 8:42 AM, Konstantin Serebryany
wrote:
>
>
> On Mon, Feb 1, 2010 at 5:22 PM, jody wrote:
>>
>> I accidentally replied tpo Julian only.
>> He
I accidentally replied tpo Julian only.
Here it is for the list.
Sorry, jody
-- Forwarded message --
From: jody
Date: Mon, Feb 1, 2010 at 3:21 PM
Subject: Re: [Valgrind-users] variable goes uninitialized after
'return' of method
To: Julian Seward
Thank you for yo
if i have interpreted the results
correctly, i.e. pAgent is uninitialized
only after it is returned from the method, but is ok inside the method.
If this is true, how can this happen?
Thank YOu
Jody
--
The Planet: dedicated and
Thank You!
On Mon, Feb 1, 2010 at 9:44 AM, Alexander Potapenko wrote:
> You should use Memcheck:Cond rather than Memceck:ValueX.
> Try looking at valgrind --gen-suppressions=all ./test
>
> On Sun, Jan 31, 2010 at 7:32 PM, jody wrote:
>> Hi
>> I am using g++ (Gentoo 4.3.4
in my suppression file?
Thank You
Jody
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and manag
Hi graham
Are you sure that all libraries needed by valgrind are accessible
on all your nodes? If it is Open MPIy wrote:
> On Wed, Apr 15, 2009 at 6:31 AM, Graham Mark wrote:
>>
>> I'm trying to track down the cause of a seg fault in my MPI program.
>> Here's what happens with valgrind.
>>
>> % m
Bart
I modified the glibc-2.X-drd.supp and recompiled valgrind.
It works - the printf() are not complained about anymore.
Thanks!
Jody
On Thu, Jan 29, 2009 at 11:06 AM, Bart Van Assche
wrote:
> On Thu, Jan 29, 2009 at 9:58 AM, jody wrote:
>> I tried out DRD, but even though i rea
don't seem to bother DRD...
Jody
On Thu, Jan 29, 2009 at 10:39 AM, Rainer Gerhards wrote:
> On Thu, Jan 29, 2009 at 9:58 AM, jody wrote:
>> Hi
>> I tried out DRD, but even though i read the DRD manual,
>> i don't really understand the output (i used --tool=drd -
one to one of the worker threads.
> Only if there are no available worker threads does it create new
> threads.
>
Here again, this would probably have to be done by some sign-in/sign-out
mechanism...
Thanks for the suggestions
Jody
> J
>
/lib/libc-2.7.so)
==19067==by 0x40090C3: pthread_create* (drd_pthread_intercepts.c:295)
==19067==by 0x8049A4C: OutputCollector::start() (OutputCollector.cpp:103)
==19067==by 0x804918F: main (in /home/jody/progs/outputredir/OCTest)
==19067== Other segment end (thread 1/1)
==19067==
eed to keep
track of the threads?
Thank You
Jody
On Wed, Jan 28, 2009 at 10:18 PM, Rainer Gerhards wrote:
> I agree to these comments, but would also recommend to not *only* use
> helgrind but also the new DRD tool. DRD did an excellent job for my
> project. The newest release
deque.h:725)
==18078==by 0x804C64D: LineBuffer::~LineBuffer() (LineBuffer.cpp:21)
==18078==by 0x8049FC2: OutBuffer::~OutBuffer() (OutBuffer.cpp:28)
==18078==by 0x8049205: main (in /home/jody/progs/outputredir/OCTest)
==18078== This conflicts with a previous write of size 4 by thread #3
Thanks for the explanation - that fixed the issue!
Jody
On Wed, Jan 28, 2009 at 11:27 AM, Tom Hughes wrote:
> jody wrote:
>
>> I simplified the server to the point where it only calls accept (see
>> below),
>> and the errors still prevail.
>> I compile it with
>
and the errors still prevail.
I compile it with
g++ -g -Wall dummysrv.cpp -o dummysrv
(g++ (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33))
What do these messages mean and how can i fix that?
The position "below main" is a little bit vague...
Thank You
Jody
Here's the code:
#in
25 matches
Mail list logo
