Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-12-07 03:15:03 GMT
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ..
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-12-07 03:05:10 GMT
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ...
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2007-12-07 03:10:05 GMT
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ..
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-12-07 03:00:02
GMT
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests
On Fri, 7 Dec 2007, Julian Seward wrote:
> 1. no entry was ever made for "a"
> (really, for VG_ROUNDDN(a, BYTES_PER_SEC_VBIT_NODE)), or
>
> 2. there was an entry, but it has since been deleted, or
>
> 3. some other snafu.
>
> Hmm, on rereading previous messages, all of (2) is irrelevant if
> you
On Wednesday 05 December 2007 18:10, Christoph Bartoschek wrote:
> Am Mittwoch, 5. Dezember 2007 schrieb Julian Seward:
> > On Wednesday 05 December 2007 16:32, Christoph Bartoschek wrote:
> > > The read of COND in the parent thread happens in a segment that is
> > > after the accesses that establi
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-12-07 02:00:01 CET
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... fail
Here's some background. Apologies if you know this already.
The "secondary V bits table" holds V (definedness) bits for selected
few parts of the process' address space. Just the parts of the
address space where bytes are partially defined, that is, neither
completely undefined nor completely d
On Friday 07 December 2007 00:05, Rich Coe wrote:
> I was running the regtest for RC2 when it stopped running at nanotest2.
You mean nanoleak2 ?
What distro and architecture is this with?
J
> Looking at the stderr output, I see valgrind prompting for input.
> Here is ths first prompt:
>
> ==17
I was running the regtest for RC2 when it stopped running at nanotest2.
Looking at the stderr output, I see valgrind prompting for input.
Here is ths first prompt:
==17779== Conditional jump or move depends on uninitialised value(s)
==17779==at 0x4016701: strlen (in /lib/ld-2.5.so)
==17779==
In message <[EMAIL PROTECTED]>
Nicholas Nethercote <[EMAIL PROTECTED]> wrote:
> On Thu, 6 Dec 2007, Tom Hughes wrote:
>
> >>> Memcheck: mc_main.c:957 (get_sec_vbits8): Assertion 'n' failed.
> >>> Memcheck: get_sec_vbits8: no node for address 0x6FA9EA0 (0x6FA9EAC)
> >>
> >> It's a proble
On Thu, 6 Dec 2007, Tom Hughes wrote:
>>> Memcheck: mc_main.c:957 (get_sec_vbits8): Assertion 'n' failed.
>>> Memcheck: get_sec_vbits8: no node for address 0x6FA9EA0 (0x6FA9EAC)
>>
>> It's a problem with the secondary V bits table in Memcheck. That table
>> holds the full V bits for all memory by
> > It would be easy enough (although expensive) to modify Helgrind so that,
> > when thread X signals at Y, memory shared by X and Y is made exclusive
> > to Y. Is that helpful or correct? I don't know. I don't know what the
> > consequences would be, just now.
>
> There is one problem when se
On Dec 6, 2007 4:40 PM, Julian Seward <[EMAIL PROTECTED]> wrote:
>
> I have put a second RC at
>
> http://www.valgrind.org/downloads/valgrind-3.3.0.RC2.tar.bz2
> (MD5 = 735819e3e8d774861326a51f991e13e5).
>
> Unless any critical breakage shows up, I plan to ship this as
> 3.3.0 final at the week
> A release candidate for Valgrind 3.3.0 (3.3.0.RC1) is available for
> testing from [...]
Various people downloaded and tried RC1; thanks for the feedback.
I have put a second RC at
http://www.valgrind.org/downloads/valgrind-3.3.0.RC2.tar.bz2
(MD5 = 735819e3e8d774861326a51f991e13e5).
Unl
In message <[EMAIL PROTECTED]>
Christoph Bartoschek <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 6. Dezember 2007 schrieb Julian Seward:
>> > It is 100% repeatable for me but, interestingly, only on my machine at
>> > home. My machine at work doesn't have the same problem. Both are
>> > x86
Am Donnerstag, 6. Dezember 2007 schrieb Julian Seward:
> > It is 100% repeatable for me but, interestingly, only on my machine at
> > home. My machine at work doesn't have the same problem. Both are
> > x86_64 machines with two cores and 4Gb of memory and both are running
> > Fedora 8!
>
> This pro
In message <[EMAIL PROTECTED]>
Julian Seward <[EMAIL PROTECTED]> wrote:
>> It is 100% repeatable for me but, interestingly, only on my machine at
>> home. My machine at work doesn't have the same problem. Both are
>> x86_64 machines with two cores and 4Gb of memory and both are running
>>
> It is 100% repeatable for me but, interestingly, only on my machine at
> home. My machine at work doesn't have the same problem. Both are
> x86_64 machines with two cores and 4Gb of memory and both are running
> Fedora 8!
This probably sounds like a really dumbass question, but .. do the two
ma
On Dec 6, 2007 1:14 AM, Nicholas Nethercote <[EMAIL PROTECTED]> wrote:
> On Thu, 6 Dec 2007, Tom Hughes wrote:
>
> > I get an assertion in memcheck trying to valgrind a windows program
> > under wine. This is the current trunk code with a tweaked version of
> > the patch from
> > http://wiki.wineh
Hi
One more question:
% cat missed_race.cc
#include
#include
#include
// In this test we do the following:
// parent...worker
// 1. pthread_create(worker)a. sleep(sleep_worker)
// 2. sleep(sleep_parent) b. print(GLOB)
// 3. GLOB = 1
// The behaviour o
> > You are right. But lots of code uses condition variables. I would like
to
> > use helgrind on several code parts that use condition variables, but
> > currently the false positive count is too high.
Oh yes!
> Thanks for the feedback. I might be able to improve the situation, but
> that will h
22 matches
Mail list logo
