On 08/12/15 22:18, Jeffrey Walton wrote:
> Its *really* pathetic the C++ language lacks a mechanism for me to say
> "Object 1 depends upon String 1, 2, 3", and "Object 2 depends upon
> Object 1 and String 1, 2, 3".
What's wrong with the singleton pattern ? When using the singleton
pattern non-cir
On 05/27/15 19:42, Fred Smith wrote:
Not
sure I understand this diagnostic, or if I do, I don’t see
how to solve it:
==00:00:00:16.486
30064== Conflicting store by thread 13 at 0x09440060
to work fine on CentOS
7.0.1046:
$ ./vg-in-place --tool=drd drd/tests/boost_thread
==24662== drd, a thread error detector
==24662== Copyright (C) 2006-2013, and GNU GPL'd, by Bart Van Assche.
==24662== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for
copyright info
==24662== Command: drd
On 18/11/2014 23:33, Benny anam wrote:
I try to figure out some problems about invalid free in android(mips)
device, which may be caused by thread sync, I did as the
README.android says compile the source and push to device, memcheck
works fine in my device, but when I changed option to --tool=
On 06/09/14 13:16, Olivier Goffart wrote:
> On Monday 09 June 2014 09:53:37 Bart Van Assche wrote:
>> If g++ would be modified such that the "if (!guard.first_byte)" test can
>> be skipped at run-time then it would become possible for Helgrind and
>> DRD to rec
On 06/09/14 08:51, Dave Ohlsson wrote:
> int i = 0;
>
> int main()
> {
> std::thread t1( []() { i = 1; } );
> std::thread t2( []() { i = 2; } );
> t1.join();
> t2.join();
> std::cerr << "i = " << i << std::endl;
> return 0;
> }
>
> [other code as before]
>
>
> The proble
On 06/08/14 19:09, David Faure wrote:
> I'm using helgrind quite a lot these days, and I love it.
>
> However I wonder if it doesn't give me false positives for the case of
> reading
> a value from a static object, which was set in the constructor.
>
> Given that gcc does indeed implement "thre
On 06/06/14 09:33, Dave Ohlsson wrote:
> However, the code you posted, and the included comments, match pretty
> much what I already did.
Hello Dave,
I have updated the C++11 instructions in the DRD manual and also the
drd/tests/std_thread.cpp test program. The DRD manual can be generated
as foll
On 06/06/14 09:33, Dave Ohlsson wrote:
> However, the code you posted, and the included comments, match pretty
> much what I already did.
I'm afraid that means that the instructions for shared pointer
annotation in the libstdc++ manual are still broken. See also
https://gcc.gnu.org/bugzilla/show_b
On 06/06/14 07:27, Dave Ohlsson wrote:
> I posted yesterday a question to stackoverflow regarding problems I am
> having with Helgrind/DRD and C++11 thread:
>
> http://stackoverflow.com/questions/24060626/cannot-get-helgrind-drd-work-with-c11-thread
>
> but got no answer.
I think the source code
On 01/08/14 08:34, Alireza Haghdoost wrote:
> Ideally, I can put my application threads to specific CPU cores. Then
> I need a performance monitoring tool which tells me what other
> processes has been executed on these CPU cores during the execution of
> my application.
>
> Does Valgrind a tool t
On 31/10/2013 4:56, hamid alaei wrote:
> Hi everyone,
> Assume there is a C code that do this:
>
> char buff1[20];
> char buff2[30]="some small string";
> ...
> strcpy(buff1, buff2);
>
> This code is can be regarded unsafe not only because it use strcpy(),
> which doesn't accept a size argument for
On 03/04/13 19:31, Young Wn Song wrote:
> I was using Valgrind 3.8.1 DRD on Parsec 2.1 Benchmark suite.
>
> x264 program in Parsec runs for more than few hours and does not stop.
> I know it takes long time but the previous version 3.7.0 DRD finished
> the same program in 300 seconds.
> (I also tri
On 08/25/12 08:45, David Faure wrote:
> How do I tell helgrind that some atomic operations on integers are OK?
>
> A suppression like this works, but it would make helgrind more useful to all
> Qt users if either atomic operations were handled automatically, or if this
> was added to valgrind's
On 06/05/12 16:13, Christoph Bartoschek wrote:
> So I wonder how there can be a data race for writing to data. The
> memory has been just allocated and no other thread knows about it.
>
> How can this happen?
Should have been fixed in r12629.
Bart.
---
On 06/06/12 13:44, Christoph Bartoschek wrote:
> Am 06.06.2012 15:12, schrieb Bart Van Assche:
>
>>> It is just a thin wrapper around glibc malloc.
>>>
>>> at 0x4C2CD6F: malloc (vg_replace_malloc.c:267)
>>> by 0x1D78D377: st_opt_l1_wrap (st_opt_wrap.c:46
On 06/06/12 13:01, Christoph Bartoschek wrote:
> Am 06.06.2012 14:41, schrieb Bart Van Assche:
>> On 06/06/12 07:56, Christoph Bartoschek wrote:
>>
>>> Am 05.06.2012 20:12, schrieb Christoph Bartoschek:
>>>>>>
>>>>>> How can this ha
On 06/06/12 07:56, Christoph Bartoschek wrote:
> Am 05.06.2012 20:12, schrieb Christoph Bartoschek:
How can this happen?
>>>
>>>
>>> Was that output produced by Valgrind 3.7.0 ? If so, do you get the same
>>> output if you build Valgrind from the SVN trunk ?
>>
>>
>> Yes it was from 3.7.
On 06/05/12 16:13, Christoph Bartoschek wrote:
> I get the following race from DRD:
>
> Conflicting store by thread 7 at 0x55fe8aa0 size 8
> by 0x5CCD8750: func() (inv_utils.C:1711)
> by 0x4C2C0C1: ??? (in /usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
> by 0x5047F04: start_thread
On 04/18/12 14:28, Plug Gulp wrote:
> Even though Boost development libraries are installed on my system,
> the configure script fails to detect it.
Does trunk r12507 help ?
Bart.
--
Better than sec? Nothing is better
On 03/13/12 14:47, Panagiotis Foteinos wrote:
> Hello grinders.
>
> So, I find it difficult to see the race. Below, the valgrind DRD output
> follows:
>
> **
> Conflicting load by thread 1 at 0x1221c91c size 4
> ==4907==at 0x5B7028: P
On 03/10/12 00:06, John Rocha wrote:
> I'm finding what appears to be a data race in the std::string class. Although
> I
> find that hard to believe.
>
> I am using libstdc++ 6.0.8, with g++ version 4.1.2 that is using the posix
> thread model, on a Linux machine running SuSE SLES10SP1
>
> Li
On Wed, Jan 11, 2012 at 9:23 AM, Brilliantov Kirill Vladimirovich
wrote:
> configure: error: please use gcc >= 3.0 or clang >= 2.9
>
> How can I solve this problem?
It's a bug in the configure script. You can either modify the gcc
version check in configure.in or check out the Valgrind svn trunk
On Mon, Jan 9, 2012 at 2:45 PM, Joris Koster wrote:
> joris@grazer:~/tmp/src$ valgrind --version
> valgrind-3.6.1-Debian
In the 3.7.0 release notes you can see that the following bug has been fixed:
243935 Helgrind: incorrect handling of ANNOTATE_HAPPENS_BEFORE()/AFTER()
Bart.
---
On Mon, Jan 9, 2012 at 10:24 AM, Joris Koster wrote:
> Yes I saw those but those didn't do the trick :(
Which Valgrind version are you using ? With the trunk version neither
Helgrind nor DRD reports any race conditions with the happens
before/after annotations in place.
Bart.
--
On Fri, Jan 6, 2012 at 4:04 PM, Joris Koster wrote:
> void releaseRef() {
> int nRefCnt = __sync_add_and_fetch(&m_nRefCnt, -1);
> if (nRefCnt == 0) {
> delete this;
> }
> }
Please read the documentation of ANNOTATE_HAPPENS_BEFORE() and
ANNOTATE_HAPPENS_AFTER(
2011/11/28 奕楠 邱 :
> In this website https://bugs.kde.org/show_bug.cgi?id=270777
>
> It teaches me how to compile the MIPS version valgrind
>
> It need to download some patches and make some modification
>
> like this:
>
> $ svn export -r 12270 svn://svn.valgrind.org/valgrind/trunk
> $ cd trunk
> $
2011/11/27 奕楠 邱 :
> Sorry, When I use autoge.sh command, it shows the following error
>
> EXTRA_DIST: variable `noinst_SCRIPTS' is used but `noinst_SCRIPTS' is
> undefined
> error: while running 'automake -a'
>
> Because of this errror, I can't use the ./configure.
>
> Does anyone know this kind of
2011/11/24 奕楠 邱
> Sorry, recently, my research topic need the support of valgrind tool
>
> so, can I put the valgrind source code onto another platform and compile
> it?
>
> there is a multicore platform named tile64
> http://en.wikipedia.org/wiki/TILE64
>
This might help: https://bugs.kde.org/
2011/10/6 Mustafa Reşit Şahin
> I am trying to run Valgrind on a FreeBSD 8.0 system with a Myri ethernet card.
This mailing list is read by users and developers of the official
Valgrind ports (Linux and Darwin). I'm not sure this list is read by
users and/or developers of the FreeBSD Valgrind por
On Sun, Aug 28, 2011 at 6:55 PM, Jeffrey Walton wrote:
> On Sun, Aug 28, 2011 at 12:26 PM, Bart Van Assche wrote:
>> On Sun, Aug 28, 2011 at 6:13 PM, Jeffrey Walton wrote:
>>> (1) Never trust wikipedia.
>>
>> Reading your message makes me wonder whether you are f
On Sun, Aug 28, 2011 at 6:13 PM, Jeffrey Walton wrote:
> (1) Never trust wikipedia.
Reading your message makes me wonder whether you are familiar with the
reason why memory barriers exist, something the Wikipedia authors of
the page about double-checked locking clearly are aware of ? Reading
the
On Sun, Aug 28, 2011 at 2:32 PM, Milian Wolff wrote:
> On Saturday 27 August 2011 23:44:02 Jeffrey Walton wrote:
>> I want to use double checked initialization for a program, but I'm
>> catching some warnings from helgrind. A typical use is shown below.
>>
>> Its kind of tedious to run --gen-suppr
On Sun, Aug 28, 2011 at 5:44 AM, Jeffrey Walton wrote:
> I want to use double checked initialization for a program, but I'm
> catching some warnings from helgrind. A typical use is shown below.
>
> Its kind of tedious to run --gen-suppressions=yes for to develop
> suppressions. Plus, the suppressi
On Wed, Jul 20, 2011 at 9:24 PM, Mudric, Dusan (Dusan) wrote:
> I forgot to mention one more fact. I am using NFS mount.
>
> /etc/fstab:
>
>47.135.159.188:/exports /exports nfs intr,noauto,nolock 0 0
>
> Here is the "valgrind ls -l" output. If started as NFS mounted, nothing
>
On Fri, Jun 17, 2011 at 5:45 PM, Stephanie Stroka
wrote:
>
> My code at that position looks like this:
>
> 284 static uint* sort(uint** matrix, uint width, uint height) {
> 285 uint* data = (uint*) malloc(width * height * sizeof(uint));
> 286 uint i,j=0;
> 287 for(i=0; i 288 fo
2011/5/4 liujianping
> Could valgrind run on Wind River 2.0 ? (the sys on my arm board is Wind
> River 2.0).
> (Wind River 2.0 with kernel 2.6.21; gcc 4.1.2; glibc 2.5)
>
> I find the information on http://valgrind.org/info/
> "Valgrind runs on several popular platforms, such as x86/Linux, AMD64/
On Thu, Apr 21, 2011 at 2:53 PM, Patrick Ohly wrote:
>
> On Mi, 2011-04-20 at 10:35 +0200, Julian Seward wrote:
> > > * clang complains about "return value not ignored as it should be"
> > > when using the client request macros in the code (-Wall
> > > -Werror).
> >
> > Does
On Wed, Apr 20, 2011 at 10:35 AM, Julian Seward wrote:
>
> > * Line information is missing in valgrind report. That works when
> > compiling with gcc.
>
> Yes, I noticed that too. I haven't investigated. btw, you should
> have a look at https://bugs.kde.org/show_bug.cgi?id=242137,
On Fri, Apr 1, 2011 at 4:03 AM, Bob Harris wrote:
> On Mar 31, 2011, at 7:55 PM, Tom Hughes wrote:
>> It's entirely expected that it may fail under valgrind when it doesn't
>> normally because the memory layout is different plus every byte of memory
>> you allocate has a little over a byte (nine b
On Tue, Mar 29, 2011 at 12:24 PM, Bart Van Assche wrote:
>
> On Mon, Mar 28, 2011 at 11:14 PM, Julian Seward wrote:
> > On Monday, March 28, 2011, Bart Van Assche wrote:
> >> On Mon, Mar 28, 2011 at 6:32 PM, Julian Seward wrote:
> >> > On Monday, March
On Wed, Mar 30, 2011 at 5:49 PM, Skindell, David
wrote:
>
>
> *From:* Skindell, David
> *Sent:* Wednesday, March 30, 2011 10:47 AM
> *To:* 'valgrind-users@lists.sourceforge.net'
> *Subject:* Valgrind Feature Query: Storage Driver Testing
>
>
>
> Just trying to find out if Valgrind can be used to m
On Mon, Mar 28, 2011 at 11:14 PM, Julian Seward wrote:
> On Monday, March 28, 2011, Bart Van Assche wrote:
>> On Mon, Mar 28, 2011 at 6:32 PM, Julian Seward wrote:
>> > On Monday, March 28, 2011, Piotr Jaroszyński wrote:
>> > > I think the proper solution is to
On Mon, Mar 28, 2011 at 6:32 PM, Julian Seward wrote:
>
> On Monday, March 28, 2011, Piotr Jaroszyński wrote:
> > I think the proper solution is to add __attribute__((unused)) to
> > _qzz_res. What do you think?
>
> Yes. I just committed exactly such cleanups (r11673). Could
> you try it, to see
don't see it
>
> -Original Message-
> From: bart.vanass...@gmail.com [mailto:bart.vanass...@gmail.com] On Behalf Of
> Bart Van Assche
> Sent: Friday, March 18, 2011 4:14 AM
> To: Osman, Ahmed
> Cc: valgrind-users@lists.sourceforge.net
> Subject: Re: [Valgrind-use
On Thu, Mar 17, 2011 at 11:59 PM, Osman, Ahmed wrote:
> Is there a way to make valgrind report the full path of the source code?
See also the documentation of --fullpath-after= here:
http://www.valgrind.org/docs/manual/manual-core.html#manual-core.options.
Bart.
---
On Fri, Feb 4, 2011 at 12:16 PM, Andrea Mazzoleni wrote:
> I likely found a problem in the DRD when using the --free-is-write
> option. The following test case reports an huge amount of errors that
> are not expected.
> [ ... ]
Sorry that it took so long, but I think I have found and fixed the
pr
2011/3/9 Piotr Adaszyński
> >
> > Strange. Does the output of "make -s regtest" on your setup match that
> > of the nightly PPC build (available in the valgrind-developers mailing
> > list archives) ?
> >
>
> Unfortunately, it's impossible to run "make -s regtest" and perform
> regression tests
On Thu, Mar 3, 2011 at 7:28 PM, Tony Finch wrote:
> On Thu, 3 Mar 2011, Bart Van Assche wrote:
>>
>> Does the patch below help ?
>
> Mostly, except it exposes an __attribute__ clause which also upsets
> standard-C compilers.
>
> I did the following patch which h
On Thu, Mar 3, 2011 at 4:28 PM, Tony Finch wrote:
> We're preparing a release of Exim-4.75 which includes copies of valgrind.h
> and memcheck.h from valgrind-3.6.0. This mostly fixed our portability
> problems. Thanks!
>
> Heiko Schlichting reported a problem compiling on Irix. Its compiler
> does
2011/3/1 Piotr Adaszyński
>
> [ ... ]
> Could you tell me why results from ppc target are different ? What
> could I do wrong ?
Strange. Does the output of "make -s regtest" on your setup match that
of the nightly PPC build (available in the valgrind-developers mailing
list archives) ?
Bart.
--
On Mon, Feb 7, 2011 at 2:05 PM, Konstantin Serebryany <
konstantin.s.serebry...@gmail.com> wrote:
>
> On Mon, Feb 7, 2011 at 2:59 PM, Bart Van Assche wrote:
>
>> On Mon, Feb 7, 2011 at 9:28 AM, Konstantin Serebryany <
>> konstantin.s.serebry...@gmail.com> wrote:
On Mon, Feb 7, 2011 at 9:28 AM, Konstantin Serebryany <
konstantin.s.serebry...@gmail.com> wrote:
>
> On Sun, Feb 6, 2011 at 10:14 PM, Bart Van Assche wrote:
>
>> On Sat, Feb 5, 2011 at 5:54 PM, Konstantin Serebryany <
>> konstantin.s.serebry...@gmail.com> wrote:
On Sat, Feb 5, 2011 at 5:54 PM, Konstantin Serebryany <
konstantin.s.serebry...@gmail.com> wrote:
>
> On Sat, Feb 5, 2011 at 7:36 PM, Bart Van Assche wrote:
>
>> On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany <
>> konstantin.s.serebry...@gmail.com> wrot
On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany <
konstantin.s.serebry...@gmail.com> wrote:
> FYI
> ThreadSanitizer will not report anything on this test, even with
> --free-is-write (which is on by default) because this tool assumes the
> malloc implementation to be correct and ignores eve
On Fri, Feb 4, 2011 at 12:16 PM, Andrea Mazzoleni wrote:
>
> I likely found a problem in the DRD when using the --free-is-write
> option. The following test case reports an huge amount of errors that
> are not expected.
>
> Valgrind and helgrind report no error.
>
> The machine is a Ubuntu 10.4 x8
On Wed, Jan 12, 2011 at 3:28 PM, Tony Finch wrote:
> On Wed, 12 Jan 2011, David Woodhouse wrote:
>>
>> Can we turn the ({ ... }) extension into a static inline function? Or is
>> that not sufficiently portable either?
>
> No, nested functions are not allowed in standard C.
>
> It looks to me like
On Wed, Jan 12, 2011 at 8:53 AM, David Woodhouse wrote:
>
> On Tue, 2011-01-11 at 15:12 +, Tony Finch wrote:
> > Exim doesn't compile with Sun or HP CC since Valgrind support was
> > added. Although valgrind.h protects against usage on unsupported
> > platforms, memcheck.h uses the __extension
On Wed, Sep 15, 2010 at 9:58 AM, Alessandro Biasci
wrote:
>
> On 14/09/2010 16:59, John Reiser wrote:
> >> $ make CROSS_COMPILE=powerpc-860-linux-gnu CC=powerpc-860-linux-gnu-gcc
> >> regtest
> >>
> >
> >> Now I'd like to execute this tests on the target platform (that isn't
> >> the same of compi
On Thu, Sep 2, 2010 at 5:13 PM, wrote:
>
> Hi!
> I am using valgrind together with boost::thread_pool and memcheck reports
> a memory leak. In the boost mailing list it seems that it is not a problem
> with boost:
> http://lists.boost.org/Archives/boost/2010/08/170274.php
>
> Is that something
On Thu, Aug 26, 2010 at 2:34 PM, Sorin Dumitru wrote:
> I am running into a little problem using valgrind 3.5 on powerpc. When I
> start valgrind with --leak-check=full I get some warnings at the start:
>
> --247-- WARNING: Serious error when reading debug info
> --247-- When reading debug info
>
On Tue, Aug 24, 2010 at 12:30 AM, Juan Carlos Martinez Santos
wrote:
> Is there a way to figure out how much the stack grows during the
> execution using Valgrind?
This is possible with DRD and --show-stack-usage -- see also
http://www.valgrind.org/docs/manual/drd-manual.html#drd-manual.options.
On Mon, Aug 9, 2010 at 4:01 PM, Christoffer Haglund <
christoffer.hagl...@nuance.com> wrote:
> That's interesting. This what Memcheck tells me about the application that
> crashes:
>
> $ valgrind --leak-check=full --show-reachable=yes --track-origins=yes
> ./unittest_t9write -r api -o api.xml
>
On Mon, Jul 26, 2010 at 9:13 AM, Sato Takenori wrote:
> I get the following "Invalid read error" on the part below.
>
> 103if(counter_->decrement() == 0){
> 104delete counter_;
> 105if(pointee_) delete pointee_;
> 106}
> 107counter_ = src->counter_;
On Wed, Jul 21, 2010 at 4:30 PM, 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 with the following error message:
>
> /opt/toolchain/usr/include/a.out.h:1:25:
> error: linux/a.out.h: No
On Tue, Jul 20, 2010 at 5:43 PM, Patrick Heckeler <
hecke...@informatik.uni-tuebingen.de> wrote:
>
> On 20 July 2010 17:13, Dan Kegel wrote:
>
>> On Tue, Jul 20, 2010 at 7:33 AM, Patrick Heckeler
>> wrote:
>> > Is there any other possibility to wrap C++ functions?
>>
>> Well, you could use exter
On Mon, Jul 19, 2010 at 6:41 PM, Bert Wesarg wrote:
>
> I would have expected, that when I do a read access on a memory
> location (ie. dereference the pointer), which was previously marked
> with VALGRIND_MAKE_MEM_UNDEFINED(), I get an error message from the
> memcheck tool. But I don't. I also d
On Sun, Jun 20, 2010 at 9:30 PM, Howard Chu wrote:
> Howard Chu wrote:
>> The BerkeleyDB library uses blocks of persistent shared memory to store its
>> environment state, which includes arrays of interprocess shared mutexes.
>> Running an app that uses BDB under valgrind/drd gives a ton of "The o
On Mon, Jun 21, 2010 at 8:03 AM, Pramod wrote:
>>
>> On Fri, Jun 18, 2010 at 1:18 PM, Pramod gmail.com> wrote:
>> >
>> > I have cross-compiled valgrind 3.5.0 to work on MontaVista Linux.
>> >
>> > After installing (copied bin, lib,
> include directories to montavista machine),
>
>> > and running
On Fri, Jun 18, 2010 at 1:18 PM, Pramod wrote:
>
> I have cross-compiled valgrind 3.5.0 to work on MontaVista Linux.
>
> After installing (copied bin, lib, include directories to montavista machine),
> and running valgrind with no arguments, I get a core file from memcheck.
>
> Using GDB, I see th
On Tue, Jun 15, 2010 at 5:55 PM, Robert Berger
wrote:
>
> [ ... ]
>
> That's what my target says:
>
> -bash-3.2# valgrind
> valgrind: failed to start tool 'memcheck' for platform 'ppc32-linux': No
> such file or directory
> -bash-3.2#
You can analyze what went wrong by analyzing the output of the
On Mon, Jun 14, 2010 at 5:28 PM, Robert Berger
wrote:
>
> It looks like last time this mail did not make it to the list.
> Here I try again.
Hi Robert,
Does the current Valgrind trunk build and install fine on your setup ?
Cross-compilation should work again with the current trunk.
Bart.
-
On Sun, Jun 13, 2010 at 1:51 PM, Robert Berger
wrote:
> On 06/10/2010 07:38 PM, Bart Van Assche wrote:
> I'm using ELDK 4.2 on an AMCC kilauea board:
>
> All on the host:
>
> svn co svn://svn.valgrind.org/valgrind/branches/VALGRIND_3_5_BRANCH
>
> VALGRIND_PATH=
On Sun, Jun 13, 2010 at 11:47 AM, Satya V. Gupta wrote:
> I have a supervisory process that is kicked off by an ELF executable which
> in turn invokes some ELF/ python script/ executables based child processes.
> I wish to run valgrind with --tool=callgrind and be able to inject valgrind
> into al
On Thu, Jun 10, 2010 at 5:37 PM, Saranya P. L wrote:
>
> When I try to cross compile valgrind-3.5.0 for ppc and my host is x86 Linux ,
> I am getting the following error
> checking for /proc/self/fd... configure: error: cannot check for file
> existence when cross compiling
>
> I heard that this
of the time I get the
> following:
>
> ==14837== drd, a thread error detector
> ==14837== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche.
> ==14837== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright
> info
> ==14837== Command: ./a.out
ctual concurrency bugs in boost asio or the example code?
>
> Thank you,
>
> Jorge
>
> ==15768== drd, a thread error detector
> ==15768== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche.
> ==15768== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for c
On Tue, Jun 8, 2010 at 11:25 AM, Satya V. Gupta wrote:
> I am using checkgrind on a system that has very little disk space. I am
> wondering if someone knows how I can direct the checkgrind output files
> (basic block, Function before, Function after) to a network socket instead?
>
The most conve
On Mon, Jun 7, 2010 at 9:47 PM, Jorge Moraleda wrote:
>
> On Sat, Jun 5, 2010 at 5:47 AM, Bart Van Assche wrote:
> > On Sat, Jun 5, 2010 at 2:52 AM, Jorge Moraleda
> > wrote:
> >>
> >> I got a drd error in one of my programs, and searching on the web I
>
On Sun, Jun 6, 2010 at 10:41 PM, Julian Seward wrote:
> 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 actua
grind --tool=drd ./a.out
> ==7014== drd, a thread error detector
> ==7014== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche.
> ==7014== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
> ==7014== Command: ./a.out
> ==7014==
> ==7014== Thread 3:
>
On Wed, Jun 2, 2010 at 10:04 PM, Jorge Moraleda
wrote:
> [ ... ]
>
> 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).
> valg
On Wed, Jun 2, 2010 at 3:12 AM, Jorge Moraleda wrote:
>
> On Sun, May 30, 2010 at 12:56 AM, Jorge Moraleda
> wrote:
> > On Sat, May 29, 2010 at 10:56 PM, Bart Van Assche
> > wrote:
> >> On Sat, May 29, 2010 at 7:00 PM, Jorge Moraleda
> >> wrote:
>
On Sat, May 29, 2010 at 7:00 PM, Jorge Moraleda
wrote:
>
> I submitted a condition variable not initialized detected with
> valgrind drd to the boost mailing list, but they report that it is a
> false alarm:
>
> Date: Sat, 29 May 2010 09:29:23 +0400
> From: Andrey Semashev
>
> On 05/29/2010 02:06
n with valgrind --tool=drd ./a.out
>
> produces the following output:
>
> ==10635== drd, a thread error detector
> ==10635== Copyright (C) 2006-2009, and GNU GPL'd, by Bart Van Assche.
> ==10635== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for
> copyright info
On Wed, May 26, 2010 at 9:05 PM, Gary Yang wrote:
> I used the command, svn co svn://svn.valgrind.org/valgrind/trunk valgrind
> got the trunk code. I would like to get the 3.5 branch code. Can someone
> tell me how?
>
Have you already tried the command below ?
svn ls svn://svn.valgrind.org/valg
On Wed, May 26, 2010 at 9:04 PM, Gary Yang wrote:
> [ ... ]
> m_dispatch/dispatch-ppc32-linux.S:142: Error: Unrecognized opcode: `stvx'
> [ ... ]
>
See also https://bugs.kde.org/show_bug.cgi?id=238745.
Bart.
--
___
On Thu, May 13, 2010 at 5:51 AM, Jorge Moraleda wrote:
> I still have not been able to write a small test case that will
> reproduce my race conditions. For what is worth, these are the
> relevant parts of the drd log for one of the race conditions.
> Everything that is not in namespaces std or bo
On Tue, May 11, 2010 at 4:31 PM, Konstantin Serebryany <
konstantin.s.serebry...@gmail.com> wrote:
>
>
> On Tue, May 11, 2010 at 6:27 PM, Bart Van Assche wrote:
>
>> On Tue, May 11, 2010 at 11:20 AM, Konstantin Serebryany <
>> konstantin.s.serebry...@gmail.com>
On Tue, May 11, 2010 at 11:20 AM, Konstantin Serebryany <
konstantin.s.serebry...@gmail.com> wrote:
>
>> Have you already found a workaround that allows to avoid triggering
>> the race report on std::locale::locale() ? If not, it would help if
>> you could post a small example that allows to repro
On Wed, Apr 21, 2010 at 3:40 AM, Jorge Moraleda
wrote:
>>> Hello Jorge,
>>>
>>> Unfortunately not all libraries have been designed with data-race
>>> detection tools in mind. Several libraries contain code that triggers
>>> benign data races. Examples are the I/O code in libstdc++ and in libc.
>>>
On Thu, May 6, 2010 at 10:06 PM, Jorge Moraleda wrote:
> I have a program that makes massif crash reproducibly with a
> segmentation fault. This occurs in the release version 3.5.0 as well
> as in one compiled from source today from subversion:
> valgrind-3.6.0.SVN. The program runs fine in massif
On Tue, Apr 27, 2010 at 9:27 PM, Osman, Ahmed wrote:
>
> I'm trying to run valgrind 3.5 on my code with these options
> "--log-file=results/valgrind_%p.log --num-callers=50
> --child-silent-after-fork=yes --gen-suppressions=yes"
>
> I'm seeing the following in the log files:
> ==4630== Memcheck,
On Wed, Apr 14, 2010 at 8:34 AM, Rainer Gerhards wrote:
> I am working with the svn version of valgrind (updated this morning).
> I see a series of violations in drd which I can not identify the root
> cause. An example violation looks like this:
>
> ==22593== Thread 3:
> ==22593== Conflicting loa
[2];
> > int rc;
> > long t;
> >
> > std::ostringstream dummy;
> > dummy << 0;
> > for(t=0; t<2; t++) {
> > rc = pthread_create(&threads[t], NULL, threadEntry, (void
> > *)t);
> > }
On Tue, Apr 6, 2010 at 12:25 PM, Konstantin Serebryany
wrote:
>
>
> On Tue, Apr 6, 2010 at 2:17 PM, Bart Van Assche wrote:
>>
>> On Tue, Apr 6, 2010 at 7:53 AM, Jorge Moraleda
>> wrote:
>> >
>> > Dear all,
>> >
>> > When I compile
> rc = pthread_create(&threads[t], NULL, threadEntry, (void *)t);
> }
> pthread_exit(NULL);
> }
> // end program /
>
> and run drd on it with:
> $ valgrind --tool=drd ./a.out
>
> I get the following output:
>
>
>From time to time Valgrind users ask how the Valgrind source code can
be cross-compiled. While cross-compiling Valgrind is no different of
cross-compiling any other project that is based on autotools, I'm
posting here a script that should help those who are not familiar with
cross-compilation. Wha
On Wed, Feb 10, 2010 at 11:27 PM, Stephen Williams wrote:
>
> I'm on an x86_64 workstation (Linux 2.6) trying to cross compile
> for ppc (Linux 2.4). I can't even get past the configure, it fails
> with the error:
>
> checking for /proc/self/fd... configure: error: cannot check for file
> existenc
On Thu, Dec 10, 2009 at 2:12 PM, Aleksander
wrote:
>> See also the Valgrind manual for more information about the
>> DRD_TRACE_VAR() macro.
>
> I looked at the online manual, and for DRD_TRACE_VAR() it says I should
> specify an "address range". I don't understand that quite well, though. Is it
>
1 - 100 of 177 matches
Mail list logo
