You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(9) |
|
2
(12) |
3
(19) |
4
(18) |
5
(22) |
6
(25) |
7
(18) |
8
(24) |
|
9
(16) |
10
(15) |
11
(22) |
12
(7) |
13
(19) |
14
(5) |
15
(8) |
|
16
(7) |
17
(8) |
18
(9) |
19
(7) |
20
(13) |
21
(16) |
22
(7) |
|
23
(10) |
24
(8) |
25
(4) |
26
(4) |
27
(9) |
28
(4) |
29
(5) |
|
30
(8) |
31
(4) |
|
|
|
|
|
|
From: Rich C. <Ric...@me...> - 2007-12-06 23:05:38
|
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== by 0x4007DDC: _dl_init_paths (in /lib/ld-2.5.so) ==17779== by 0x40033CE: dl_main (in /lib/ld-2.5.so) ==17779== by 0x4014A05: _dl_sysdep_start (in /lib/ld-2.5.so) ==17779== by 0x4000C2F: _dl_start (in /lib/ld-2.5.so) ==17779== by 0x4000816: (within /lib/ld-2.5.so) ==17779== ==17779== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- On Thu, 6 Dec 2007 16:40:29 +0100 Julian Seward <js...@ac...> wrote: > > > 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). > > Unless any critical breakage shows up, I plan to ship this as > 3.3.0 final at the weekend. > > J > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > -- Rich Coe ric...@me... Virtual Principle Engineer General Electric Healthcare Technologies Global Software Platforms, Computer Technology Team |
|
From: Tom H. <to...@co...> - 2007-12-06 22:50:39
|
In message <Pin...@mu...>
Nicholas Nethercote <nj...@cs...> 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 problem with the secondary V bits table in Memcheck. That table
> >> holds the full V bits for all memory bytes that are partially defined.
> >> It's happened a couple of times, but always in situations that are
> >> impossible for me to reproduce. If you are able to reduce it to a small
> >> test, or are able to do any debugging yourself, that would be very helpful.
> >
> > 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!
> > [...]
> > Any suggestions for the best way to debug it?
>
> The relevant code starts with this line, around line 838:
>
> /* --------------- Secondary V bit table ------------ */
>
> It's a fairly basic data structure, the only notable thing is that we
> periodically garbage collect (GC) it, ie. remove stale nodes. The easy
> first thing to try is to turn off the GC, ie. make gcSecVBitTable() do
> nothing. If that makes the problem go away, then we know that the GC is
> removing nodes it shouldn't.
Well I made that function do nothing, and it still happens...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2007-12-06 21:43:28
|
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 bytes that are partially defined. >> It's happened a couple of times, but always in situations that are >> impossible for me to reproduce. If you are able to reduce it to a small >> test, or are able to do any debugging yourself, that would be very helpful. > > 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! > [...] > Any suggestions for the best way to debug it? The relevant code starts with this line, around line 838: /* --------------- Secondary V bit table ------------ */ It's a fairly basic data structure, the only notable thing is that we periodically garbage collect (GC) it, ie. remove stale nodes. The easy first thing to try is to turn off the GC, ie. make gcSecVBitTable() do nothing. If that makes the problem go away, then we know that the GC is removing nodes it shouldn't. It might also be useful if you can run with -v. The "memcheck GC" lines indicate when GCs are happening. Nick |
|
From: Julian S. <js...@ac...> - 2007-12-06 20:02:25
|
> > 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 several signals are emitted. Which one should one
> use to establish the happens-before relation? This could make the tool
> dependent on the scheduler. For example the following code:
>
> Thread 1: Thread 2:
>
> a. pthread_mutex_lock(mutex); 1. pthread_mutex_lock(mutex);
> b. while (COND != 1) { 2. COND = 1;
> c. pthread_cond_wait(cv); 3. pthread_cond_signal(cv);
> d. } 4. pthread_mutex_unlock(mutex);
> e. pthread_mutex_unlock(mutex); 5. pthread_mutex_lock(mutex);
> f. COND = 3; 6. COND = 2;
> 7. pthread_cond_signal(cv);
> 8. pthread_mutex_unlock(mutex);
>
> If thread 1 wakes up on the first signal in line 3, then there is a problem
> in lines f and 6. If thread 1 wakes up on the second signal in line 7, one
> would not detect an error. Detecting the error in the first case would be
> the hard case in my opinion.
You will get scheduler-related results even from a simpler example
(which is equivalent to Konstantin's original program):
initially COND = 0
Thread 1: Thread 2:
a. pthread_mutex_lock(mutex); 1. pthread_mutex_lock(mutex);
b. while (COND != 1) { 2. COND = 1;
c. pthread_cond_wait(cv); 3. pthread_cond_signal(cv);
d. } 4. pthread_mutex_unlock(mutex);
e. pthread_mutex_unlock(mutex);
f. COND = 3; 5. pthread_mutex_lock(mutex);
6. COND = 4;
7. pthread_mutex_unlock(mutex);
(Assuming the wait happens before the signal, so the signal is not lost).
State changes to COND are:
initially COND is New
After (b) COND is Excl(Thread1)
After (2) COND is ShM({Thread1,Thread2},{mutex})
After (3) signals at (c), COND is Excl(Thread1) as per proposed rule
Now if f happens before 5/6/7:
After (f) COND is Excl(Thread1)
After (5/6/7) COND is ShM({Thread1,Thread2},{mutex}), and no error
But if 5/6/7 happens before f:
After (5/6/7) COND is ShM({Thread1,Thread2},{mutex})
After (f) COND is ShM({Thread1,Thread2},{}) -- error
Without the proposed rule, the error is detected regardless of the
scheduling.
Such a rule can easily enough be installed in Helgrind. But you can't
have it both ways:
If the rule is installed, effectively you are promising that after the
signal from Thread 2 to Thread 1, Thread 2 will not access COND again
until Thread 1 first signals back at Thread 2. That makes Helgrind shut
up, but you lose some ability of Helgrind to report errors resulting
from later violations of the promise, depending on the scheduling.
If the rule is not installed, then Helgrind complains, but it can
at least check what happens next, independent of scheduling.
J
|
|
From: Bart V. A. <bar...@gm...> - 2007-12-06 18:13:39
|
On Dec 6, 2007 4:40 PM, Julian Seward <js...@ac...> 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 weekend. The file exp-drd/tests/fp_race.stderr.exp2 is present in SVN but is missing in the tar file, which makes the first drd regression test fail on AMD64. Can you add this file to the tarball ? $ perl tests/vg_regtest exp-drd -- Running tests in exp-drd/tests ------------------------------------- fp_race: valgrind ./fp_race *** fp_race failed (stderr) *** fp_race2: valgrind ./fp_race -m pth_broadcast: valgrind ./pth_broadcast pth_cond_race: valgrind ./pth_cond_race pth_cond_race2: valgrind ./pth_cond_race -m pth_create_chain: valgrind ./pth_create_chain 100 pth_detached: valgrind ./pth_detached 1 1 pth_detached2: valgrind ./pth_detached 10 10 sigalrm: valgrind ./sigalrm -- Finished tests in exp-drd/tests ------------------------------------- -- Regards, Bart Van Assche. |
|
From: Julian S. <js...@ac...> - 2007-12-06 15:41:19
|
> 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). Unless any critical breakage shows up, I plan to ship this as 3.3.0 final at the weekend. J |
|
From: Tom H. <to...@co...> - 2007-12-06 15:39:21
|
In message <200...@or...>
Christoph Bartoschek <bar...@or...> 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_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
>> machines have the same CPUs? I ask because just recently Christoph
>> Bartoschek (IIRC) reported some strangeness to do with memory
>> corruption and CPUs. Or something. Christoph, can you summarise
>> what it is you found?
>
> We could resolve the strangeness by updating the linux kernel.
> The kernel comming with opensuse 10.2 had the error. Updating Opensuse to 10.3
> resolved the issues. Our sysadmin tells me that all distributions with
> kernels smaller than or equal to 2.6.18 showed the error.
Both the machines in question are running 2.6.23.1-49.fc8 kernels.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Christoph B. <bar...@or...> - 2007-12-06 15:35:05
|
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 probably sounds like a really dumbass question, but .. do the two > machines have the same CPUs? I ask because just recently Christoph > Bartoschek (IIRC) reported some strangeness to do with memory > corruption and CPUs. Or something. Christoph, can you summarise > what it is you found? We could resolve the strangeness by updating the linux kernel. The kernel comming with opensuse 10.2 had the error. Updating Opensuse to 10.3 resolved the issues. Our sysadmin tells me that all distributions with kernels smaller than or equal to 2.6.18 showed the error. I have attached the testprogram that forces the error. This program forces the error after running about 10 - 60 minutes. If it runs longer than 60 minutes it does not fail. The program just allocates a big array and increments the values inside. The program fails if the expected value is not in a memory cell. The program shows the error when it is run natively. It is not run as a valgrind client. I've only used in our machines with 64 GiB of memory and used 67 as the parameter. I would expect that you have to change the program to allocate only 4.1 GiB on a 4 GiB machine. Currently it accepts only full GiB steps. You should also adapt the number of threads to the available number of cores. Greetings Christoph |
|
From: Tom H. <to...@co...> - 2007-12-06 15:26:47
|
In message <200...@ac...>
Julian Seward <js...@ac...> 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
>> Fedora 8!
>
> This probably sounds like a really dumbass question, but .. do the two
> machines have the same CPUs? I ask because just recently Christoph
> Bartoschek (IIRC) reported some strangeness to do with memory
> corruption and CPUs. Or something. Christoph, can you summarise
> what it is you found?
No - the home machine (where it is failing) is lot newer. It has:
vendor_id : AuthenticAMD
cpu family : 15
model : 75
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
stepping : 2
cpu MHz : 1000.000
cache size : 512 KB
The work machine has two single core Opterons:
vendor_id : AuthenticAMD
cpu family : 15
model : 5
model name : AMD Opteron(tm) Processor 250
stepping : 10
cpu MHz : 2393.189
cache size : 1024 KB
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2007-12-06 15:18:13
|
> 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 machines have the same CPUs? I ask because just recently Christoph Bartoschek (IIRC) reported some strangeness to do with memory corruption and CPUs. Or something. Christoph, can you summarise what it is you found? J |
|
From: Tom H. <to...@co...> - 2007-12-06 09:34:39
|
On Dec 6, 2007 1:14 AM, Nicholas Nethercote <nj...@cs...> 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.winehq.org/Wine_and_Valgrind applied. > > > > I'm just running "valgrind --trace-children=yes notepad" and I get: > > > > Memcheck: mc_main.c:957 (get_sec_vbits8): Assertion 'n' failed. > > Memcheck: get_sec_vbits8: no node for address 0x6FA9EA0 (0x6FA9EAC) > > > > ==9850== at 0x38018ACD: report_and_quit (m_libcassert.c:140) > > ==9850== by 0x8: ??? > > ==9850== by 0x9: ??? > > ==9850== by 0x9: ??? > > ==9850== by 0x40000005: ??? > > ==9850== by 0xFFFFFFFE: ??? > > > > Any ideas? > > It's a problem with the secondary V bits table in Memcheck. That table > holds the full V bits for all memory bytes that are partially defined. > It's happened a couple of times, but always in situations that are > impossible for me to reproduce. If you are able to reduce it to a small > test, or are able to do any debugging yourself, that would be very helpful. 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! > One thing you could do is try commenting out all these lines and see if it > goes away. If it does, you could then experiment with which combinations > make it go away. > > #define PERF_FAST_LOADV 1 > #define PERF_FAST_STOREV 1 > > #define PERF_FAST_SARP 1 > > #define PERF_FAST_STACK 1 > #define PERF_FAST_STACK2 1 I've commented them all out and it makes no difference. There are also no bad writes reported beforehand, which rules out Julian's suggestion. Any suggestions for the best way to debug it? Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Konstantin S. <kon...@gm...> - 2007-12-06 09:23:13
|
Hi
One more question:
% cat missed_race.cc
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
// 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 of helgrind depends on values of
// sleep_parent/sleep_worker.
// If the values are close (sleep_parent=1000, sleep_worker=2000),
// detection of the race actually depends on luck.
// On my system it is detected 1 of 4-5 of times.
//
// If the parent gets to 'GLOB=1' first, then no race is detected.
// We have Exclusive(parent)->ShR(parent,worker)
//
// If the worker gets to print(GLOB) first, then the race is reported.
// We have Exclusive(worked)->ShM({parent,worker}, {empty lockset})
//
// This race should (IMHO) be detected independently of sleep values.
// Do we need to have ExclusiveR and ExclusiveW instead of just Exclusive?
int GLOB = 0;
const int sleep_parent=1000;
const int sleep_worker=2000;
void *worker(void*)
{
usleep(sleep_worker);
printf("GLOB=%d\n", GLOB);
return NULL;
}
int main(int argc, char **argv)
{
pthread_t threadid;
pthread_create(&threadid, NULL, worker, NULL);
usleep(sleep_parent);
GLOB = 1;
pthread_join(threadid, NULL);
}
/*
% g++ -g missed_race.cc -lpthread
% for((i=1; i <= 10; i++)); do echo ---------- $i;
~/race/valgrind32orig/Inst/bin/valgrind -q --tool=helgrind ./a.out 2>&1 |
grep -A 5 Possible; done
---------- 1
---------- 2
---------- 3
---------- 4
---------- 5
---------- 6
==13246== Possible data race during write of size 4 at 0x8049850
==13246== at 0x8048585: main (missed_race.cc:40)
==13246== Old state: owned exclusively by thread #2
==13246== New state: shared-modified by threads #1, #2
==13246== Reason: this thread, #1, holds no locks at all
GLOB=0
---------- 7
---------- 8
==13254== Possible data race during write of size 4 at 0x8049850
==13254== at 0x8048585: main (missed_race.cc:40)
==13254== Old state: owned exclusively by thread #2
==13254== New state: shared-modified by threads #1, #2
==13254== Reason: this thread, #1, holds no locks at all
GLOB=0
---------- 9
---------- 10
%
*/
|
|
From: Konstantin S. <kon...@gm...> - 2007-12-06 08:53:02
|
> > 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 have to wait until after 3.3.0 is released now.
That''l be great!
I've modified my test (attached, q2.cc), hope it will be helpful :)
It now has N worker threads. If N >= 2 the race is reported even for GLOB1.
GLOB[12] are now read-only in workers.
As I understand, helgrind currently can transfer Exclusive(worker) ->
Exclusive(parent) but can not transfer
ShRO(worker1,worker2)->Exclusive(parent) in presence of cond_wait().
I did not find VALGRIND_HG_POST_WAIT anywhere in valgrind nor in the net.
Is it supposed to be used like this?
#include "helgrind.h"
...
pthread_mutex_lock(&MU);
while (COND != n_tasks) {
pthread_cond_wait(&CV, &MU);
}
VALGRIND_HG_POST_WAIT(&CV)
pthread_mutex_unlock(&MU);
Thanks,
--kcc
On Dec 6, 2007 12:08 AM, Julian Seward <js...@ac...> wrote:
>
> > On Wednesday 05 December 2007 18:10, Christoph Bartoschek wrote:
> > [...]
> >
> > 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.
>
> Thanks for the feedback. I might be able to improve the situation, but
> that will have to wait until after 3.3.0 is released now.
>
> J
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|
|
From: Bart V. A. <bar...@gm...> - 2007-12-06 07:18:01
|
On Dec 5, 2007 1:29 PM, Julian Seward <js...@ac...> wrote: > On Wednesday 05 December 2007 13:17, Konstantin Serebryany wrote: > > >> As far as I understand, helgrind is not more than just Eraser :) > > helgrind is more than just Eraser :) > > True. Helgrind is Eraser + usage of happens-before dependencies > resulting from thread creation, joinage, condition-variable signalling > (to the extent these dependencies are visible), and through semaphore > events, + the ability to transfer memory from shared states to exclusive > ownership states at pthread_join points. Although I have a lot of respect for the work you have done on the Helgrind tool, I still do not understand why you started from the Eraser algorithm. This algorithm is easy to mislead, e.g. it doesn't recognize user-implemented synchronization primitives. Many developers implement reader-writer locks on top of mutexes because this makes code easier to port between Linux and Windows. Obtaining a reader-lock is then implemented as (simplified) (lock mutex, increment reader count, unlock mutex). The Eraser algorithm won't recognize such code as a reader lock. Another issue with the Eraser algorithms are HPC algorithms where computations consist of several steps, where the different steps are only separated by barriers. The memory accesses within a step of the different threads do not conflict, but the memory accesses of different steps contain conflicts. A vector-clock based algorithm won't report any false positive for this scenario, but an Eraser-style algorithm will report all conflicting accesses as data races. Regards, Bart Van Assche. |
|
From: Tom H. <th...@cy...> - 2007-12-06 03:57:38
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-12-06 03:15:02 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 321 tests, 62 stderr failures, 1 stdout failure, 28 post failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/noisy_child (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/bug152022 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) massif/tests/alloc-fns-A (post) massif/tests/alloc-fns-B (post) massif/tests/basic (post) massif/tests/basic2 (post) massif/tests/big-alloc (post) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/custom_alloc (post) massif/tests/deep-A (post) massif/tests/deep-B (stderr) massif/tests/deep-B (post) massif/tests/deep-C (stderr) massif/tests/deep-C (post) massif/tests/deep-D (post) massif/tests/ignoring (post) massif/tests/insig (post) massif/tests/long-time (post) massif/tests/new-cpp (post) massif/tests/null (post) massif/tests/one (post) massif/tests/overloaded-new (post) massif/tests/peak (post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) massif/tests/realloc (stderr) massif/tests/realloc (post) massif/tests/thresholds_0_0 (post) massif/tests/thresholds_0_10 (post) massif/tests/thresholds_10_0 (post) massif/tests/thresholds_10_10 (post) massif/tests/thresholds_5_0 (post) massif/tests/thresholds_5_10 (post) massif/tests/zero1 (post) massif/tests/zero2 (post) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/hg06_readshared (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc02_simple_tls (stderr) helgrind/tests/tc03_re_excl (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) |
|
From: Tom H. <th...@cy...> - 2007-12-06 03:33:35
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-12-06 03:05:05 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 355 tests, 7 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2007-12-06 03:27:19
|
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2007-12-06 03:10:05 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 355 tests, 10 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 355 tests, 10 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_cvsimple (stdout) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Dec 6 03:19:03 2007 --- new.short Thu Dec 6 03:27:19 2007 *************** *** 16,18 **** none/tests/mremap2 (stdout) ! none/tests/pth_cvsimple (stdout) helgrind/tests/tc17_sembar (stderr) --- 16,18 ---- none/tests/mremap2 (stdout) ! none/tests/pth_detached (stdout) helgrind/tests/tc17_sembar (stderr) |
|
From: Tom H. <th...@cy...> - 2007-12-06 03:13:42
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-12-06 03:00:02 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 357 tests, 24 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 357 tests, 25 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Dec 6 03:06:54 2007 --- new.short Thu Dec 6 03:13:45 2007 *************** *** 8,10 **** ! == 357 tests, 25 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) --- 8,10 ---- ! == 357 tests, 24 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) *************** *** 29,31 **** helgrind/tests/tc17_sembar (stderr) - helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) --- 29,30 ---- |
|
From: <sv...@va...> - 2007-12-06 03:03:34
|
Author: sewardj
Date: 2007-12-06 01:58:05 +0000 (Thu, 06 Dec 2007)
New Revision: 7280
Log:
Another supp.
Modified:
trunk/glibc-2.34567-NPTL-helgrind.supp
/usr/local/etc/subversion//commit-email.pl: `/usr/local/bin/svnlook diff /home/svn/repos/valgrind -r 7280' failed with this output:
Modified: trunk/glibc-2.34567-NPTL-helgrind.supp
===================================================================
--- trunk/glibc-2.34567-NPTL-helgrind.supp 2007-12-05 21:51:50 UTC (rev 7279)
+++ trunk/glibc-2.34567-NPTL-helgrind.supp 2007-12-06 01:58:05 UTC (rev 7280)
@@ -346,6 +346,13 @@
obj:/lib*/ld-2.3.*so
}
{
+ helgrind-glibc23-003
+ Helgrind:Race
+ obj:/lib*/ld-2.3.*so
+ obj:/lib*/libc-2.3.*so
+ obj:/lib*/libc-2.3.*so
+}
+{
helgrind-glibc23-004
Helgrind:Race
obj:/lib*/libc-2.3.*so
svnlook: Can't open directory '/tmp/svnlook.1': Not a directory
|
|
From: <sv...@va...> - 2007-12-06 03:03:33
|
Author: sewardj Date: 2007-12-06 02:13:37 +0000 (Thu, 06 Dec 2007) New Revision: 7281 Log: Update. Modified: trunk/ACKNOWLEDGEMENTS /usr/local/etc/subversion//commit-email.pl: `/usr/local/bin/svnlook diff /home/svn/repos/valgrind -r 7281' failed with this output: Modified: trunk/ACKNOWLEDGEMENTS =================================================================== --- trunk/ACKNOWLEDGEMENTS 2007-12-06 01:58:05 UTC (rev 7280) +++ trunk/ACKNOWLEDGEMENTS 2007-12-06 02:13:37 UTC (rev 7281) @@ -60,5 +60,9 @@ for use in Valgrind. Michael Matz and Simon Hausmann modified the GNU binutils demangler(s) for use in Valgrind. -And lots and lots of other people sent bug reports, patches, and very -helpful feedback. +Many, many people sent bug reports, patches, and helpful feedback. + +Development of Valgrind was supported in part by the Tri-Lab Partners +(Lawrence Livermore National Laboratory, Los Alamos National +Laboratory, and Sandia National Laboratories) of the U.S. Department +of Energy's Advanced Simulation & Computing (ASC) Program. svnlook: Can't open directory '/tmp/svnlook.2': Not a directory |
|
From: <sv...@va...> - 2007-12-06 03:03:33
|
Author: sewardj Date: 2007-12-06 02:15:16 +0000 (Thu, 06 Dec 2007) New Revision: 7282 Log: --> 3.3.0.RC2. Modified: trunk/NEWS trunk/configure.in /usr/local/etc/subversion//commit-email.pl: `/usr/local/bin/svnlook diff /home/svn/repos/valgrind -r 7282' failed with this output: Modified: trunk/NEWS =================================================================== --- trunk/NEWS 2007-12-06 02:13:37 UTC (rev 7281) +++ trunk/NEWS 2007-12-06 02:15:16 UTC (rev 7282) @@ -228,6 +228,7 @@ OSs. (3.3.0.RC1: 2 Dec 2007, vex r1803, valgrind r7268). +(3.3.0.RC2: 5 Dec 2007, vex r1804, valgrind r7282). (3.3.0: X Dec 2006, vex rXXXX, valgrind rXXXX). Modified: trunk/configure.in =================================================================== --- trunk/configure.in 2007-12-06 02:13:37 UTC (rev 7281) +++ trunk/configure.in 2007-12-06 02:15:16 UTC (rev 7282) @@ -8,7 +8,7 @@ ##------------------------------------------------------------## # Process this file with autoconf to produce a configure script. -AC_INIT(Valgrind, 3.3.0.RC1, val...@li...) +AC_INIT(Valgrind, 3.3.0.RC2, val...@li...) AC_CONFIG_SRCDIR(coregrind/m_main.c) AM_CONFIG_HEADER(config.h) AM_INIT_AUTOMAKE svnlook: Can't open directory '/tmp/svnlook.3': Not a directory |
|
From: <js...@ac...> - 2007-12-06 01:39:48
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-12-06 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 ... failed Regression test results follow == 288 tests, 27 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/res_search (stdout) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... failed Last 20 lines of verbose log follow echo Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2007-12-05T02:00:01} valgrind svn: Unknown hostname 'svn.valgrind.org' ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Dec 6 02:00:48 2007 --- new.short Thu Dec 6 02:12:15 2007 *************** *** 1,7 **** ! Checking out valgrind source tree ... failed ! Last 20 lines of verbose log follow echo - Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2007-12-05T02:00:01} valgrind - svn: Unknown hostname 'svn.valgrind.org' --- 1,40 ---- ! Checking out valgrind source tree ... done ! Configuring valgrind ... done ! Building valgrind ... done ! Running regression tests ... failed ! Regression test results follow ! ! == 288 tests, 27 stderr failures, 3 stdout failures, 0 post failures == ! memcheck/tests/deep_templates (stdout) ! memcheck/tests/leak-cycle (stderr) ! memcheck/tests/leak-tree (stderr) ! memcheck/tests/malloc_free_fill (stderr) ! memcheck/tests/pointer-trace (stderr) ! none/tests/faultstatus (stderr) ! none/tests/fdleak_cmsg (stderr) ! none/tests/mremap (stderr) ! none/tests/mremap2 (stdout) ! none/tests/res_search (stdout) ! helgrind/tests/hg02_deadlock (stderr) ! helgrind/tests/hg03_inherit (stderr) ! helgrind/tests/hg04_race (stderr) ! helgrind/tests/hg05_race2 (stderr) ! helgrind/tests/tc01_simple_race (stderr) ! helgrind/tests/tc05_simple_race (stderr) ! helgrind/tests/tc06_two_races (stderr) ! helgrind/tests/tc07_hbl1 (stderr) ! helgrind/tests/tc08_hbl2 (stderr) ! helgrind/tests/tc09_bad_unlock (stderr) ! helgrind/tests/tc11_XCHG (stderr) ! helgrind/tests/tc14_laog_dinphils (stderr) ! helgrind/tests/tc16_byterace (stderr) ! helgrind/tests/tc17_sembar (stderr) ! helgrind/tests/tc19_shadowmem (stderr) ! helgrind/tests/tc20_verifywrap (stderr) ! helgrind/tests/tc21_pthonce (stderr) ! helgrind/tests/tc22_exit_w_lock (stderr) ! helgrind/tests/tc23_bogus_condwait (stderr) ! helgrind/tests/tc24_nonzero_sem (stderr) |
|
From: Nicholas N. <nj...@cs...> - 2007-12-06 01:15:01
|
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.winehq.org/Wine_and_Valgrind applied. > > I'm just running "valgrind --trace-children=yes notepad" and I get: > > Memcheck: mc_main.c:957 (get_sec_vbits8): Assertion 'n' failed. > Memcheck: get_sec_vbits8: no node for address 0x6FA9EA0 (0x6FA9EAC) > > ==9850== at 0x38018ACD: report_and_quit (m_libcassert.c:140) > ==9850== by 0x8: ??? > ==9850== by 0x9: ??? > ==9850== by 0x9: ??? > ==9850== by 0x40000005: ??? > ==9850== by 0xFFFFFFFE: ??? > > Any ideas? It's a problem with the secondary V bits table in Memcheck. That table holds the full V bits for all memory bytes that are partially defined. It's happened a couple of times, but always in situations that are impossible for me to reproduce. If you are able to reduce it to a small test, or are able to do any debugging yourself, that would be very helpful. One thing you could do is try commenting out all these lines and see if it goes away. If it does, you could then experiment with which combinations make it go away. #define PERF_FAST_LOADV 1 #define PERF_FAST_STOREV 1 #define PERF_FAST_SARP 1 #define PERF_FAST_STACK 1 #define PERF_FAST_STACK2 1 Nick |
|
From: Julian S. <js...@ac...> - 2007-12-06 00:22:52
|
Hmm, Memcheck does very occasionally keel over like that, but the reason for it has never been established. Is it repeatable? Were there any invalid reads/writes prior to this point, that might have trashed any Memcheck-specific data structures? Nick may well have something more constructive to add. J On Thursday 06 December 2007 01:11, 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.winehq.org/Wine_and_Valgrind applied. > > I'm just running "valgrind --trace-children=yes notepad" and I get: > > Memcheck: mc_main.c:957 (get_sec_vbits8): Assertion 'n' failed. > Memcheck: get_sec_vbits8: no node for address 0x6FA9EA0 (0x6FA9EAC) > > ==9850== at 0x38018ACD: report_and_quit (m_libcassert.c:140) > ==9850== by 0x8: ??? > ==9850== by 0x9: ??? > ==9850== by 0x9: ??? > ==9850== by 0x40000005: ??? > ==9850== by 0xFFFFFFFE: ??? > > Any ideas? > > Tom |
|
From: Tom H. <to...@co...> - 2007-12-06 00:11:15
|
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.winehq.org/Wine_and_Valgrind applied. I'm just running "valgrind --trace-children=yes notepad" and I get: Memcheck: mc_main.c:957 (get_sec_vbits8): Assertion 'n' failed. Memcheck: get_sec_vbits8: no node for address 0x6FA9EA0 (0x6FA9EAC) ==9850== at 0x38018ACD: report_and_quit (m_libcassert.c:140) ==9850== by 0x8: ??? ==9850== by 0x9: ??? ==9850== by 0x9: ??? ==9850== by 0x40000005: ??? ==9850== by 0xFFFFFFFE: ??? Any ideas? Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |