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
(11) |
2
(8) |
|
3
(8) |
4
(8) |
5
(8) |
6
(19) |
7
(17) |
8
(12) |
9
(10) |
|
10
(15) |
11
(18) |
12
(14) |
13
(16) |
14
(24) |
15
(16) |
16
(12) |
|
17
(25) |
18
(23) |
19
(12) |
20
(10) |
21
(9) |
22
(12) |
23
(13) |
|
24
(19) |
25
(7) |
26
(39) |
27
(22) |
28
(22) |
29
(16) |
30
(13) |
|
31
(23) |
|
|
|
|
|
|
|
From: Nuno L. <nun...@sa...> - 2006-12-17 23:05:16
|
>> For example this report >> http://gcov.php.net/viewer.php?version=PHP_5_2&func=valgrind&file=v8a0751b5 >>763509f655d06762b4300b41 says: >> >> ==31871== Invalid free() / delete / delete[] >> ==31871== at 0x401D39E: free (vg_replace_malloc.c:233) >> ==31871== by 0x59BB11B: (within /lib/libc-2.3.2.so) >> ==31871== by 0x59BAE64: __libc_freeres (in /lib/libc-2.3.2.so) >> ==31871== by 0x40184C1: _vgnU_freeres (vg_preloaded.c:60) >> ==31871== by 0x58DAB17: exit (in /lib/libc-2.3.2.so) >> ==31871== by 0x58C4E3D: (below main) (in /lib/libc-2.3.2.so) >> ==31871== Address 0x59E2E90 is not stack'd, malloc'd or (recently) >> free'd > > Hi. There was a bug with --gen-suppressions=all, which will be fixed > in V 3.2.2. See patches below. However, that probably won't fix the > above. Try running with --run-libc-freeres=no, and see > http://www.valgrind.org/docs/manual/manual-core.html#manual-core.flags > for background on it. Many thanks for your fast answer. The patches applied cleanly and valgrind is now generating suppressions correctly (I'll let you know if I find further problems). >> BTW, just another question: is it possible to add support to silent the >> errors from an entire lib or for example use wilcards in the function >> trace >> (this would be very useful for us, as for example in php 4 and php 5 the >> entry point function has different names and thus I need two entries in >> the >> suppression file that only differ in that entry point function name.) > > See > http://www.valgrind.org/docs/manual/manual-core.html#manual-core.suppress > > You can use function names or object names. And you can use use ? and * > in those names. That gives some level of flexibility. Ah, ups.. I didn't read that page before. Now my suppressions file is much smaller and easier to maintain :) BTW, just a small note: on the page you mention above, it is written the following: "Remaining lines: This is the calling context for the error -- the chain of function calls that led to it. There can be up to four of these lines". This is clearly not true.. at least valgrind generates frequently suppressions with a much bigger stack trace. Thanks, Nuno |
|
From: Nicholas N. <nj...@cs...> - 2006-12-17 22:02:49
|
On Sun, 17 Dec 2006, Bart Van Assche wrote: > That's correct. But I already noticed that I will have to make changes > to drd such that the outcome of regression tests is reproducible. E.g. > drd currently prints absolute pathnames every time it prints the name > of a sourcefile -- this should be a relative pathname. And even if drd > detects the same set of data races during every run, these are not > always printed in the same order. I'm still thinking about a solution > for this. Note that each test has a "filter" that transforms the actual output into the expected .exp file. Most tests use the standard ones but you can use test-specific ones. You might be able to utilise that. > I'll have a look at the OSet data structure -- it certainly would be > welcome if I wouldn't have to manage separate implementations for 32 > and 64-bit architectures. Do you have an idea of how lookups in an > OSet compare with lookups in the three-level bitmap data structure I > defined ? And how about memory consumption ? Is there any > documentation available about OSet's apart of Valgrind's source files > ? No. But the comment at the top of coregrind/m_oset.c is reasonably detailed (overhead is 12 bytes on 32-bit machines, 24 bytes on 64-bit machines). Then if you use VG_(malloc) to allocate them you have some more overhead: 16 bytes on 32-bit machines, 32 bytes on 64-bit machines -- see the comment near the top of coregrind/m_mallocfree.c. Nick |
|
From: Bart V. A. <bar...@gm...> - 2006-12-17 20:41:01
|
On 12/17/06, Julian Seward <js...@ac...> wrote: > On Thursday 14 December 2006 03:08, Nicholas Nethercote wrote: > > > Any comments on the proposed core changes and/or the drd tool are > > > welcome. > > > > These changes look great. I appreciate that you have addressed the > > concerns Julian and I have raised previously. The minimal set of > > coregrind/ changes is looking good. > > Yes, I also appreciate that. > > I presume you are building up a set of test programs as you go along? > Those will eventually be useful as regression tests. That's correct. But I already noticed that I will have to make changes to drd such that the outcome of regression tests is reproducible. E.g. drd currently prints absolute pathnames every time it prints the name of a sourcefile -- this should be a relative pathname. And even if drd detects the same set of data races during every run, these are not always printed in the same order. I'm still thinking about a solution for this. > > > Next issues I will work on: segment merging, and more accurate error > > > reporting. This should solve the OOM errors triggered by drd and make the > > > tool more usable. > > Do you plan / have any interest in trying the danger-set idea? I had > thought a bit about how to implement the lazy set merging involved. > It also avoids having two different pieces of code for 32-bit and > 64-bit machines. > > The idea is to remove the fixed 3-level bitmap and instead use an > OSet of pages (of some size). Naively, each memory access then > requires a lookup in the OSet, which could be slow. So, associate > with the OSet a small, fixed size cache which holds the most popular > pages for very quick access. This is an idea I used recently in > mc_main.c (auxmap_L1/auxmap_L2) and it works pretty well. > > Anyway I volunteer to implement this (+ the lazy set union stuff) > if you are interested in trying the danger-set scheme. The next item I'll work on is to implement the so-called danger set algorithm (see also the file drd/TODO.txt in the patch). I don't think it will be necessary to save an call stack with each memory access: with the current bitmap implementation it's probably faster to check for data races upon each memory access instead of storing a call stack per access and only reporting data races when a new segment is started. I'll have a look at the OSet data structure -- it certainly would be welcome if I wouldn't have to manage separate implementations for 32 and 64-bit architectures. Do you have an idea of how lookups in an OSet compare with lookups in the three-level bitmap data structure I defined ? And how about memory consumption ? Is there any documentation available about OSet's apart of Valgrind's source files ? Bart. |
|
From: Bart V. A. <bar...@gm...> - 2006-12-17 20:28:55
|
On 12/17/06, Julian Seward <js...@ac...> wrote: > > > Would it be wise to switch the calling > > order of VG_(set_running)() and VG_TRACK(post_thread_create)() ? > > Well, no .. I don't think so. The problem is that V uses a big > lock to ensure everything is serialised. thread_wrapper() is > one of the very few places where there is genuinely > 1 kernel > thread runnable, because that's what V asks sys_clone() to run when > the client does sys_clone(). So basically the first thing that > thread_wrapper() does is to acquire the big lock. Before that is > done, it isn't safe to touch any global state of the system. > > Note that VG_(set_running) and VG_(set_sleeping) are poorly named. > I should rename to them to VG_(acquire_biglock) and VG_(release_biglock) > respectively. > > Anyway: does the existing sequence cause a problem for drd? The current behavior is not easy to work with in drd: the drd tool can only create a thread record if it has both the ThreadId of the newly created thread and the ThreadId of the parent thread. This information is only passed to tools via VG_TRACK(post_thread_create)(), and not via VG_TRACK(thread_run)(). Or: I would have to ignore any VG_TRACK(thread_run)() calls that happen before VG_TRACK(post_thread_create)(). This is something that should be done by the core IMHO. Bart. |
|
From: <sv...@va...> - 2006-12-17 19:36:07
|
Author: sewardj
Date: 2006-12-17 19:36:06 +0000 (Sun, 17 Dec 2006)
New Revision: 6409
Log:
Rename VG_(get_lwp_tid) to VG_(lwpid_to_vgtid).
Modified:
trunk/coregrind/m_libcassert.c
trunk/coregrind/m_signals.c
trunk/coregrind/m_syswrap/syswrap-generic.c
trunk/coregrind/m_threadstate.c
trunk/coregrind/pub_core_threadstate.h
Modified: trunk/coregrind/m_libcassert.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_libcassert.c 2006-12-17 18:58:55 UTC (rev 6408)
+++ trunk/coregrind/m_libcassert.c 2006-12-17 19:36:06 UTC (rev 6409)
@@ -130,7 +130,8 @@
{
Addr stacktop;
Addr ips[BACKTRACE_DEPTH];
- ThreadState *tst =3D VG_(get_ThreadState)( VG_(get_lwp_tid)(VG_(getti=
d)()) );
+ ThreadState *tst=20
+ =3D VG_(get_ThreadState)( VG_(lwpid_to_vgtid)( VG_(gettid)() ) );
=20
// If necessary, fake up an ExeContext which is of our actual real CP=
U
// state. Could cause problems if we got the panic/exception within =
the
Modified: trunk/coregrind/m_signals.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_signals.c 2006-12-17 18:58:55 UTC (rev 6408)
+++ trunk/coregrind/m_signals.c 2006-12-17 19:36:06 UTC (rev 6409)
@@ -1567,7 +1567,7 @@
static=20
void async_signalhandler ( Int sigNo, vki_siginfo_t *info, struct vki_uc=
ontext *uc )
{
- ThreadId tid =3D VG_(get_lwp_tid)(VG_(gettid)());
+ ThreadId tid =3D VG_(lwpid_to_vgtid)(VG_(gettid)());
ThreadState *tst =3D VG_(get_ThreadState)(tid);
=20
#ifdef VGO_linux
@@ -1687,7 +1687,7 @@
static
void sync_signalhandler ( Int sigNo, vki_siginfo_t *info, struct vki_uco=
ntext *uc )
{
- ThreadId tid =3D VG_(get_lwp_tid)(VG_(gettid)());
+ ThreadId tid =3D VG_(lwpid_to_vgtid)(VG_(gettid)());
=20
vg_assert(info !=3D NULL);
vg_assert(info->si_signo =3D=3D sigNo);
@@ -1857,7 +1857,8 @@
from the client's code, then we can jump back into the scheduler
and have it delivered. Otherwise it's a Valgrind bug. */
{ =20
- ThreadState *tst =3D VG_(get_ThreadState)(VG_(get_lwp_tid)(VG_(get=
tid)()));
+ ThreadState *tst=20
+ =3D VG_(get_ThreadState)(VG_(lwpid_to_vgtid)(VG_(gettid)()));
=20
if (VG_(sigismember)(&tst->sig_mask, sigNo)) {
/* signal is blocked, but they're not allowed to block faults */
@@ -1908,7 +1909,7 @@
*/
static void sigvgkill_handler(int signo, vki_siginfo_t *si, struct vki_u=
context *uc)
{
- ThreadId tid =3D VG_(get_lwp_tid)(VG_(gettid)());
+ ThreadId tid =3D VG_(lwpid_to_vgtid)(VG_(gettid)());
ThreadStatus at_signal =3D VG_(threads)[tid].status;
=20
if (VG_(clo_trace_signals))
Modified: trunk/coregrind/m_syswrap/syswrap-generic.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-generic.c 2006-12-17 18:58:55 UTC (=
rev 6408)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2006-12-17 19:36:06 UTC (=
rev 6409)
@@ -4722,7 +4722,7 @@
if (pid <=3D 0)
return False;
=20
- tid =3D VG_(get_lwp_tid)(pid);
+ tid =3D VG_(lwpid_to_vgtid)(pid);
if (tid =3D=3D VG_INVALID_THREADID)
return False; /* none of our threads */
=20
Modified: trunk/coregrind/m_threadstate.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_threadstate.c 2006-12-17 18:58:55 UTC (rev 6408)
+++ trunk/coregrind/m_threadstate.c 2006-12-17 19:36:06 UTC (rev 6409)
@@ -126,7 +126,7 @@
=20
/* Given an LWP id (ie, real kernel thread id), find the corresponding
ThreadId */
-ThreadId VG_(get_lwp_tid)(Int lwp)
+ThreadId VG_(lwpid_to_vgtid)(Int lwp)
{
ThreadId tid;
=20
Modified: trunk/coregrind/pub_core_threadstate.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/pub_core_threadstate.h 2006-12-17 18:58:55 UTC (rev 6=
408)
+++ trunk/coregrind/pub_core_threadstate.h 2006-12-17 19:36:06 UTC (rev 6=
409)
@@ -257,7 +257,7 @@
=20
/* Given an LWP id (ie, real kernel thread id), find the corresponding
ThreadId */
-extern ThreadId VG_(get_lwp_tid)(Int lwpid);
+extern ThreadId VG_(lwpid_to_vgtid)(Int lwpid);
=20
#endif // __PUB_CORE_THREADSTATE_H
=20
|
|
From: Julian S. <js...@ac...> - 2006-12-17 19:02:23
|
> Note that VG_(set_running) and VG_(set_sleeping) are poorly named.
> I should rename to them to VG_(acquire_biglock) and VG_(release_biglock)
> respectively.
Ok, did that (r6408). This makes it clearer that
(1) Valgrind has a Big Lock ("the_BigLock" in scheduler.c)
(2) Before doing basically anything at all, whether running
the core, the tool, or JIT-generated code, a thread must
hold the lock: it must have gone past VG_(acquire_BigLock)
but not have gone past VG_(release_BigLock).
J
|
|
From: <sv...@va...> - 2006-12-17 18:59:01
|
Author: sewardj
Date: 2006-12-17 18:58:55 +0000 (Sun, 17 Dec 2006)
New Revision: 6408
Log:
A naming-only change: rename VG_(set_running) to VG_(acquire_BigLock)
and VG_(set_sleeping) to VG_(release_BigLock). And some other minor
renamings to the thread locking stuff, to make it easier to follow.
Modified:
trunk/coregrind/m_scheduler/priv_sema.h
trunk/coregrind/m_scheduler/scheduler.c
trunk/coregrind/m_scheduler/sema.c
trunk/coregrind/m_signals.c
trunk/coregrind/m_syswrap/syswrap-linux.c
trunk/coregrind/m_syswrap/syswrap-main.c
trunk/coregrind/m_syswrap/syswrap-ppc32-aix5.c
trunk/coregrind/m_syswrap/syswrap-ppc64-aix5.c
trunk/coregrind/pub_core_scheduler.h
Modified: trunk/coregrind/m_scheduler/priv_sema.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_scheduler/priv_sema.h 2006-12-17 17:40:06 UTC (rev =
6407)
+++ trunk/coregrind/m_scheduler/priv_sema.h 2006-12-17 18:58:55 UTC (rev =
6408)
@@ -32,10 +32,9 @@
#define __PRIV_SEMA_H
=20
/* Not really a semaphore, but use a pipe for a token-passing scheme */
-/* Not really a semaphore, but use a pipe for a token-passing scheme */
typedef struct {
Int pipe[2];
- Int owner_thread; /* who currently has it */
+ Int owner_lwpid; /* who currently has it */
} vg_sema_t;
=20
// Nb: this may be OS-specific, but let's not factor it out until we
Modified: trunk/coregrind/m_scheduler/scheduler.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_scheduler/scheduler.c 2006-12-17 17:40:06 UTC (rev =
6407)
+++ trunk/coregrind/m_scheduler/scheduler.c 2006-12-17 18:58:55 UTC (rev =
6408)
@@ -38,13 +38,13 @@
There are no extra threads.
=20
The main difference is that Valgrind only allows one client thread
- to run at once. This is controlled with the VCPU semaphore,
- "run_sema". Any time a thread wants to run client code or
+ to run at once. This is controlled with the CPU Big Lock,
+ "the_BigLock". Any time a thread wants to run client code or
manipulate any shared state (which is anything other than its own
- ThreadState entry), it must hold the run_sema.
+ ThreadState entry), it must hold the_BigLock.
=20
When a thread is about to block in a blocking syscall, it releases
- run_sema, and re-takes it when it becomes runnable again (either
+ the_BigLock, and re-takes it when it becomes runnable again (either
because the syscall finished, or we took a signal).
=20
VG_(scheduler) therefore runs in each thread. It returns only when
@@ -135,7 +135,7 @@
}
=20
/* CPU semaphore, so that threads can run exclusively */
-static vg_sema_t run_sema;
+static vg_sema_t the_BigLock;
=20
=20
/* ---------------------------------------------------------------------
@@ -189,14 +189,14 @@
}
=20
/*=20
- Mark a thread as Runnable. This will block until the run_sema is
+ Mark a thread as Runnable. This will block until the_BigLock is
available, so that we get exclusive access to all the shared
- structures and the CPU. Up until we get the sema, we must not
+ structures and the CPU. Up until we get the_BigLock, we must not
touch any shared state.
=20
When this returns, we'll actually be running.
*/
-void VG_(set_running)(ThreadId tid, HChar* who)
+void VG_(acquire_BigLock)(ThreadId tid, HChar* who)
{
ThreadState *tst;
=20
@@ -209,10 +209,10 @@
}
#endif
=20
- /* First, acquire the lock. We can't do anything else safely prior
- to this point. Even doing debug printing prior to this point
- is, technically, wrong. */
- ML_(sema_down)(&run_sema);
+ /* First, acquire the_BigLock. We can't do anything else safely
+ prior to this point. Even doing debug printing prior to this
+ point is, technically, wrong. */
+ ML_(sema_down)(&the_BigLock);
=20
tst =3D VG_(get_ThreadState)(tid);
=20
@@ -246,7 +246,7 @@
but it may mean that we remain in a Runnable state and we're just
yielding the CPU to another thread).
*/
-void VG_(set_sleeping)(ThreadId tid, ThreadStatus sleepstate, HChar* who=
)
+void VG_(release_BigLock)(ThreadId tid, ThreadStatus sleepstate, HChar* =
who)
{
ThreadState *tst =3D VG_(get_ThreadState)(tid);
=20
@@ -268,9 +268,9 @@
print_sched_event(tid, buf);
}
=20
- /* Release the run_sema; this will reschedule any runnable
+ /* Release the_BigLock; this will reschedule any runnable
thread. */
- ML_(sema_up)(&run_sema);
+ ML_(sema_up)(&the_BigLock);
}
=20
/* Clear out the ThreadState and release the semaphore. Leaves the
@@ -291,7 +291,7 @@
if (VG_(clo_trace_sched))
print_sched_event(tid, "release lock in VG_(exit_thread)");
=20
- ML_(sema_up)(&run_sema);
+ ML_(sema_up)(&the_BigLock);
}
=20
/* If 'tid' is blocked in a syscall, send it SIGVGKILL so as to get it
@@ -321,14 +321,14 @@
vg_assert(tid !=3D VG_INVALID_THREADID);
vg_assert(VG_(threads)[tid].os_state.lwpid =3D=3D VG_(gettid)());
=20
- VG_(set_sleeping)(tid, VgTs_Yielding, "VG_(vg_yield)");
+ VG_(release_BigLock)(tid, VgTs_Yielding, "VG_(vg_yield)");
=20
/*=20
Tell the kernel we're yielding.
*/
VG_(do_syscall0)(__NR_sched_yield);
=20
- VG_(set_running)(tid, "VG_(vg_yield)");
+ VG_(acquire_BigLock)(tid, "VG_(vg_yield)");
}
=20
=20
@@ -413,9 +413,9 @@
would be too hard to try to re-number the thread and relocate the =
=20
thread state down to VG_(threads)[1]. =
=20
=
=20
- This function also needs to reinitialize the run_sema, since =
=20
- otherwise we may end up sharing its state with the parent, which =
=20
- would be deeply confusing. =
=20
+ This function also needs to reinitialize the_BigLock, since
+ otherwise we may end up sharing its state with the parent, which
+ would be deeply confusing.
*/ =20
static void sched_fork_cleanup(ThreadId me)
{
@@ -435,9 +435,9 @@
}
=20
/* re-init and take the sema */
- ML_(sema_deinit)(&run_sema);
- ML_(sema_init)(&run_sema);
- ML_(sema_down)(&run_sema);
+ ML_(sema_deinit)(&the_BigLock);
+ ML_(sema_init)(&the_BigLock);
+ ML_(sema_down)(&the_BigLock);
}
=20
=20
@@ -457,7 +457,7 @@
vg_assert(VG_IS_PAGE_ALIGNED(clstack_end+1));
vg_assert(VG_IS_PAGE_ALIGNED(clstack_size));
=20
- ML_(sema_init)(&run_sema);
+ ML_(sema_init)(&the_BigLock);
=20
for (i =3D 0 /* NB; not 1 */; i < VG_N_THREADS; i++) {
/* Paranoia .. completely zero it out. */
@@ -813,7 +813,7 @@
/*=20
Run a thread until it wants to exit.
=20
- We assume that the caller has already called VG_(set_running) for
+ We assume that the caller has already called VG_(acquire_BigLock) for
us, so we own the VCPU. Also, all signals are blocked.
*/
VgSchedReturnCode VG_(scheduler) ( ThreadId tid )
@@ -860,8 +860,8 @@
/* 3 Aug 06: doing sys__nsleep works but crashes some apps.
sys_yield also helps the problem, whilst not crashing apps. =
*/
=20
- VG_(set_sleeping)(tid, VgTs_Yielding,=20
- "VG_(scheduler):timeslice");
+ VG_(release_BigLock)(tid, VgTs_Yielding,=20
+ "VG_(scheduler):timeslice");
/* ------------ now we don't have The Lock ------------ */
=20
# if defined(VGP_ppc32_aix5) || defined(VGP_ppc64_aix5)
@@ -878,7 +878,7 @@
}
# endif
=20
- VG_(set_running)(tid, "VG_(scheduler):timeslice");
+ VG_(acquire_BigLock)(tid, "VG_(scheduler):timeslice");
/* ------------ now we do have The Lock ------------ */
=20
/* OK, do some relatively expensive housekeeping stuff */
@@ -1387,7 +1387,7 @@
if (!VG_(is_running_thread)(tid)) {
VG_(message)(Vg_DebugMsg,
"Thread %d is supposed to be running, "
- "but doesn't own run_sema (owned by %d)\n",=20
+ "but doesn't own the_BigLock (owned by %d)\n",=20
tid, VG_(running_tid));
bad =3D True;
}
@@ -1399,9 +1399,9 @@
bad =3D True;
}
=20
- if (lwpid !=3D run_sema.owner_thread) {
+ if (lwpid !=3D the_BigLock.owner_lwpid) {
VG_(message)(Vg_DebugMsg,
- "Thread %d doesn't own the run_sema\n",
+ "Thread (LWPID) %d doesn't own the_BigLock\n",
tid);
bad =3D True;
}
Modified: trunk/coregrind/m_scheduler/sema.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_scheduler/sema.c 2006-12-17 17:40:06 UTC (rev 6407)
+++ trunk/coregrind/m_scheduler/sema.c 2006-12-17 18:58:55 UTC (rev 6408)
@@ -65,7 +65,7 @@
sema->pipe[1]);
vg_assert(sema->pipe[0] !=3D sema->pipe[1]);
=20
- sema->owner_thread =3D -1;
+ sema->owner_lwpid =3D -1;
=20
/* create initial token */
sema_char =3D 'A';
@@ -78,12 +78,12 @@
=20
void ML_(sema_deinit)(vg_sema_t *sema)
{
- vg_assert(sema->owner_thread !=3D -1); /* must be initialised */
+ vg_assert(sema->owner_lwpid !=3D -1); /* must be initialised */
vg_assert(sema->pipe[0] !=3D sema->pipe[1]);
VG_(close)(sema->pipe[0]);
VG_(close)(sema->pipe[1]);
sema->pipe[0] =3D sema->pipe[1] =3D -1;
- sema->owner_thread =3D -1;
+ sema->owner_lwpid =3D -1;
}
=20
/* get a token */
@@ -93,7 +93,7 @@
Int ret;
Int lwpid =3D VG_(gettid)();
=20
- vg_assert(sema->owner_thread !=3D lwpid); /* can't have it already */
+ vg_assert(sema->owner_lwpid !=3D lwpid); /* can't have it already */
vg_assert(sema->pipe[0] !=3D sema->pipe[1]);
=20
again:
@@ -113,7 +113,7 @@
=20
if (sema_char =3D=3D 'Z') sema_char =3D 'A'; else sema_char++;
=20
- sema->owner_thread =3D lwpid;
+ sema->owner_lwpid =3D lwpid;
}
=20
/* put token back */
@@ -123,11 +123,11 @@
Char buf[2];
buf[0] =3D sema_char;=20
buf[1] =3D 0;
- vg_assert(sema->owner_thread !=3D -1); /* must be initialised */
+ vg_assert(sema->owner_lwpid !=3D -1); /* must be initialised */
vg_assert(sema->pipe[0] !=3D sema->pipe[1]);
- vg_assert(sema->owner_thread =3D=3D VG_(gettid)()); /* must have it *=
/
+ vg_assert(sema->owner_lwpid =3D=3D VG_(gettid)()); /* must have it */
=20
- sema->owner_thread =3D 0;
+ sema->owner_lwpid =3D 0;
=20
ret =3D VG_(write)(sema->pipe[1], buf, 1);
=20
Modified: trunk/coregrind/m_signals.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_signals.c 2006-12-17 17:40:06 UTC (rev 6407)
+++ trunk/coregrind/m_signals.c 2006-12-17 18:58:55 UTC (rev 6408)
@@ -1589,7 +1589,7 @@
vg_assert(tst->status =3D=3D VgTs_WaitSys);
=20
/* The thread isn't currently running, make it so before going on */
- VG_(set_running)(tid, "async_signalhandler");
+ VG_(acquire_BigLock)(tid, "async_signalhandler");
=20
/* Update thread state properly */
VG_(fixup_guest_state_after_syscall_interrupted)(
@@ -1915,7 +1915,7 @@
VG_(message)(Vg_DebugMsg,=20
"sigvgkill for lwp %d tid %d", VG_(gettid)(), tid);
=20
- VG_(set_running)(tid, "sigvgkill_handler");
+ VG_(acquire_BigLock)(tid, "sigvgkill_handler");
=20
vg_assert(signo =3D=3D VG_SIGVGKILL);
vg_assert(si->si_signo =3D=3D signo);
Modified: trunk/coregrind/m_syswrap/syswrap-linux.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-linux.c 2006-12-17 17:40:06 UTC (re=
v 6407)
+++ trunk/coregrind/m_syswrap/syswrap-linux.c 2006-12-17 18:58:55 UTC (re=
v 6408)
@@ -71,7 +71,7 @@
vg_assert(tst->status =3D=3D VgTs_Init);
=20
/* make sure we get the CPU lock before doing anything significant */
- VG_(set_running)(tid, "thread_wrapper(starting new thread)");
+ VG_(acquire_BigLock)(tid, "thread_wrapper(starting new thread)");
=20
if (0)
VG_(printf)("thread tid %d started: stack =3D %p\n",
Modified: trunk/coregrind/m_syswrap/syswrap-main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-main.c 2006-12-17 17:40:06 UTC (rev=
6407)
+++ trunk/coregrind/m_syswrap/syswrap-main.c 2006-12-17 18:58:55 UTC (rev=
6408)
@@ -38,7 +38,7 @@
#include "pub_core_libcprint.h"
#include "pub_core_libcproc.h" // For VG_(getpid)()
#include "pub_core_libcsignal.h"
-#include "pub_core_scheduler.h" // For VG_(set_sleeping), VG_(set_ru=
nning),
+#include "pub_core_scheduler.h" // For VG_({acquire,release}_BigLock=
),
// and VG_(vg_yield)
#include "pub_core_stacktrace.h" // For VG_(get_and_pp_StackTrace)()
#include "pub_core_tooliface.h"
@@ -915,7 +915,7 @@
putSyscallArgsIntoGuestState( &sci->args, &tst->arch.vex );
=20
/* Drop the lock */
- VG_(set_sleeping)(tid, VgTs_WaitSys, "VG_(client_syscall)[async=
]");
+ VG_(release_BigLock)(tid, VgTs_WaitSys, "VG_(client_syscall)[as=
ync]");
=20
/* Do the call, which operates directly on the guest state,
not on our abstracted copies of the args/result. */
@@ -930,7 +930,7 @@
to the scheduler. */
=20
/* Reacquire the lock */
- VG_(set_running)(tid, "VG_(client_syscall)[async]");
+ VG_(acquire_BigLock)(tid, "VG_(client_syscall)[async]");
=20
/* Even more impedance matching. Extract the syscall status
from the guest state. */
Modified: trunk/coregrind/m_syswrap/syswrap-ppc32-aix5.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-ppc32-aix5.c 2006-12-17 17:40:06 UT=
C (rev 6407)
+++ trunk/coregrind/m_syswrap/syswrap-ppc32-aix5.c 2006-12-17 18:58:55 UT=
C (rev 6408)
@@ -94,7 +94,7 @@
vg_assert(tst->status =3D=3D VgTs_Init);
=20
/* make sure we get the CPU lock before doing anything significant */
- VG_(set_running)(tid, "thread_wrapper(starting new thread)");
+ VG_(acquire_BigLock)(tid, "thread_wrapper(starting new thread)");
=20
if (0)
VG_(printf)("thread tid %d started: stack =3D %p\n",
Modified: trunk/coregrind/m_syswrap/syswrap-ppc64-aix5.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-ppc64-aix5.c 2006-12-17 17:40:06 UT=
C (rev 6407)
+++ trunk/coregrind/m_syswrap/syswrap-ppc64-aix5.c 2006-12-17 18:58:55 UT=
C (rev 6408)
@@ -94,7 +94,7 @@
vg_assert(tst->status =3D=3D VgTs_Init);
=20
/* make sure we get the CPU lock before doing anything significant */
- VG_(set_running)(tid, "thread_wrapper(starting new thread)");
+ VG_(acquire_BigLock)(tid, "thread_wrapper(starting new thread)");
=20
if (0)
VG_(printf)("thread tid %d started: stack =3D %p\n",
Modified: trunk/coregrind/pub_core_scheduler.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/pub_core_scheduler.h 2006-12-17 17:40:06 UTC (rev 640=
7)
+++ trunk/coregrind/pub_core_scheduler.h 2006-12-17 18:58:55 UTC (rev 640=
8)
@@ -57,7 +57,7 @@
thread state to VgTs_Runnable, and the thread will attempt to take
the CPU lock. By the time it returns, tid will be the running
thread. */
-extern void VG_(set_running) ( ThreadId tid, HChar* who );
+extern void VG_(acquire_BigLock) ( ThreadId tid, HChar* who );
=20
/* Set a thread into a sleeping state. Before the call, the thread
must be runnable, and holding the CPU lock. When this call
@@ -67,7 +67,7 @@
caller must be careful not to touch any shared state. It is also
the caller's responsibility to actually block until the thread is
ready to run again. */
-extern void VG_(set_sleeping) ( ThreadId tid, ThreadStatus state, HChar*=
who );
+extern void VG_(release_BigLock) ( ThreadId tid, ThreadStatus state, HCh=
ar* who );
=20
/* Yield the CPU for a while */
extern void VG_(vg_yield)(void);
|
|
From: Julian S. <js...@ac...> - 2006-12-17 18:56:07
|
On Wednesday 13 December 2006 18:10, Bart Van Assche wrote: > A new patch is available: > http://home.euphonynet.be/bvassche/valgrind/valgrind-6397-drd-2006-12-13.pa >tch.gz Just looking through the patch again. Minor observation: does drd_vc.h need <stdint.h> ? pub_tool_basics gives you UInt, which is guaranteed to be a 32-bit unsigned int on all platforms. J |
|
From: Julian S. <js...@ac...> - 2006-12-17 18:06:38
|
On Thursday 14 December 2006 03:08, Nicholas Nethercote wrote: > > Any comments on the proposed core changes and/or the drd tool are > > welcome. > > These changes look great. I appreciate that you have addressed the > concerns Julian and I have raised previously. The minimal set of > coregrind/ changes is looking good. Yes, I also appreciate that. I presume you are building up a set of test programs as you go along? Those will eventually be useful as regression tests. > > Next issues I will work on: segment merging, and more accurate error > > reporting. This should solve the OOM errors triggered by drd and make the > > tool more usable. Do you plan / have any interest in trying the danger-set idea? I had thought a bit about how to implement the lazy set merging involved. It also avoids having two different pieces of code for 32-bit and 64-bit machines. The idea is to remove the fixed 3-level bitmap and instead use an OSet of pages (of some size). Naively, each memory access then requires a lookup in the OSet, which could be slow. So, associate with the OSet a small, fixed size cache which holds the most popular pages for very quick access. This is an idea I used recently in mc_main.c (auxmap_L1/auxmap_L2) and it works pretty well. Anyway I volunteer to implement this (+ the lazy set union stuff) if you are interested in trying the danger-set scheme. J |
|
From: Julian S. <js...@ac...> - 2006-12-17 17:51:51
|
Well, I can see what you're saying. But like Nick I'm reluctant to add non-essential functionality to the core. I'm still a bit unclear about this. As I understand it, programs that want to see thread names in error reports have to use the client requests specially. So it won't be of benefit to programs that don't use these client requests, correct? Or does drd's pthread wrappers use them in a way which benefits any program run by drd? I think it would help to clarify the way in which you intend this to be used, and to show some error messages from drd with/without thread names. J On Thursday 14 December 2006 10:39, Bart Van Assche wrote: > On 12/14/06, Nicholas Nethercote <nj...@cs...> wrote: > > I couldn't work out how the different thread_name components fit > > together. Can you briefly describe them? As usual, I'm wondering if we > > can avoid adding new stuff to the core :) > > This is how it currently works: > - The client tells to Valgrind's core which name it wants to associate > with each thread via a client request (VG_USERREQ__SET_THREAD_NAME). > - When Valgrind's core encounters this client request, it stores the > thread name and remembers that thread name until the thread finishes. > - Each time a thread name changes, the core calls > VG_TRACK(thread_name)(tid, name). > - The drd tool registers a tracking function such that it is informed > about thread name changes. The drd tool includes these thread names in > its error reports. The drd tool also remembers thread names longer > than the core. E.g. after a thread finished and before it is joined > via pthread_join(), the core already has discarded all information > related to that thread but drd still knows about that thread (name, > POSIX thread ID, etc.). > - Currently Valgrind's core does nothing else with thread names than > storing them and making these names available to tools. > > I recommend however to include thread names in the error reports of > all tools. When using e.g. memcheck on multithreaded programs, it is > very helpful to know which thread an error report relates to. The only > option available now is to switch back from NPTL to linuxthreads, such > that the process ID included in each line of output relates uniquely > to a thread. But even with linuxthreads I have to make the application > keep a file in /tmp up to date with the relationship between pid_t and > thread name, such that it becomes possible to translate pid_t's into > thread names. Including thread names directly in memcheck's error > reports would make memcheck easier to use with multithreaded software. > > Bart. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: <sv...@va...> - 2006-12-17 17:40:40
|
Author: sewardj
Date: 2006-12-17 17:40:36 +0000 (Sun, 17 Dec 2006)
New Revision: 1688
Log:
Make compilable again.
Modified:
trunk/test/test-amd64.c
Modified: trunk/test/test-amd64.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/test/test-amd64.c 2006-12-17 14:24:05 UTC (rev 1687)
+++ trunk/test/test-amd64.c 2006-12-17 17:40:36 UTC (rev 1688)
@@ -41,7 +41,7 @@
=20
/* Setting this to 1 creates a very comprehensive test of
integer condition codes. */
-#define TEST_INTEGER_VERBOSE 0
+#define TEST_INTEGER_VERBOSE 1
=20
typedef long long int int64;
=20
@@ -551,7 +551,7 @@
"movl $0x12345678, %0\n"\
#op " %" size "2, %" size "0 ; setz %b1" \
: "=3Dr" (res), "=3Dq" (resz)\
- : "g" (val));\
+ : "r" (val));\
printf("%-10s A=3D%08x R=3D%08x %d\n", #op, val, res, resz);\
}
=20
|
|
From: <sv...@va...> - 2006-12-17 17:40:09
|
Author: sewardj
Date: 2006-12-17 17:40:06 +0000 (Sun, 17 Dec 2006)
New Revision: 6407
Log:
Add locking so this produces repeatable results (Bart Van Assche).
Modified:
trunk/none/tests/pth_detached.c
trunk/none/tests/pth_detached.stdout.exp
Modified: trunk/none/tests/pth_detached.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/none/tests/pth_detached.c 2006-12-17 14:20:31 UTC (rev 6406)
+++ trunk/none/tests/pth_detached.c 2006-12-17 17:40:06 UTC (rev 6407)
@@ -8,20 +8,37 @@
#include <stdlib.h>
#include <unistd.h>
=20
-static int s_finished_count;
+static int s_finished_count =3D 0;
+static pthread_spinlock_t s_spinlock;
=20
+void increment_finished_count()
+{
+ pthread_spin_lock(&s_spinlock);
+ s_finished_count++;
+ pthread_spin_unlock(&s_spinlock);
+}
+
+int get_finished_count()
+{
+ int result;
+ pthread_spin_lock(&s_spinlock);
+ result =3D s_finished_count;
+ pthread_spin_unlock(&s_spinlock);
+ return result;
+}
+
static void* thread_func1(void* arg)
{
write(STDOUT_FILENO, ".", 1);
- s_finished_count++;
+ increment_finished_count();
return 0;
}
=20
static void* thread_func2(void* arg)
{
pthread_detach(pthread_self());
- write(STDOUT_FILENO, "*", 1);
- s_finished_count++;
+ write(STDOUT_FILENO, ".", 1);
+ increment_finished_count();
return 0;
}
=20
@@ -32,7 +49,9 @@
int i;
int detachstate;
pthread_attr_t attr;
- =20
+
+ pthread_spin_init(&s_spinlock, 0);
+
pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
assert(pthread_attr_getdetachstate(&attr, &detachstate) =3D=3D 0);
@@ -57,12 +76,15 @@
pthread_attr_destroy(&attr);
=20
// Wait until all detached threads have written their output to stdout=
.
- while (s_finished_count < count1 + count2)
+ while (get_finished_count() < count1 + count2)
{
struct timespec delay =3D { 0, 1 * 1000 * 1000 };
nanosleep(&delay, 0);
}
=20
printf("\n");
+
+ pthread_spin_destroy(&s_spinlock);
+
return 0;
}
Modified: trunk/none/tests/pth_detached.stdout.exp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/none/tests/pth_detached.stdout.exp 2006-12-17 14:20:31 UTC (rev=
6406)
+++ trunk/none/tests/pth_detached.stdout.exp 2006-12-17 17:40:06 UTC (rev=
6407)
@@ -1 +1 @@
-........................................................................=
............................*********************************************=
*******************************************************
+........................................................................=
.........................................................................=
.......................................................
|
|
From: Julian S. <js...@ac...> - 2006-12-17 17:39:11
|
I had a look at this just now. On Tuesday 12 December 2006 13:11, Bart Van Assche wrote: > By adding tracing in the drd tool I found out that Valgrind's core > first calls VG_TRACK(thread_run)() before it calls > VG_TRACK(post_thread_create)() when a new thread is created. This > surprised me. Is this intended behavior ? The first tracking function > is called from coregrind/m_scheduler/scheduler.c, function > VG_(set_running)(). The second tracking function is called from > coregrind/m_syswrap/syswrap-linux.c, function thread_wrapper(). > thread_wrapper() calls VG_(set_running)() before it calls > VG_TRACK(post_thread_create)(). Would it be wise to switch the calling > order of VG_(set_running)() and VG_TRACK(post_thread_create)() ? Well, no .. I don't think so. The problem is that V uses a big lock to ensure everything is serialised. thread_wrapper() is one of the very few places where there is genuinely > 1 kernel thread runnable, because that's what V asks sys_clone() to run when the client does sys_clone(). So basically the first thing that thread_wrapper() does is to acquire the big lock. Before that is done, it isn't safe to touch any global state of the system. Note that VG_(set_running) and VG_(set_sleeping) are poorly named. I should rename to them to VG_(acquire_biglock) and VG_(release_biglock) respectively. Anyway: does the existing sequence cause a problem for drd? J |
|
From: Julian S. <js...@ac...> - 2006-12-17 16:50:42
|
> For example this report > http://gcov.php.net/viewer.php?version=PHP_5_2&func=valgrind&file=v8a0751b5 >763509f655d06762b4300b41 says: > > ==31871== Invalid free() / delete / delete[] > ==31871== at 0x401D39E: free (vg_replace_malloc.c:233) > ==31871== by 0x59BB11B: (within /lib/libc-2.3.2.so) > ==31871== by 0x59BAE64: __libc_freeres (in /lib/libc-2.3.2.so) > ==31871== by 0x40184C1: _vgnU_freeres (vg_preloaded.c:60) > ==31871== by 0x58DAB17: exit (in /lib/libc-2.3.2.so) > ==31871== by 0x58C4E3D: (below main) (in /lib/libc-2.3.2.so) > ==31871== Address 0x59E2E90 is not stack'd, malloc'd or (recently) free'd Hi. There was a bug with --gen-suppressions=all, which will be fixed in V 3.2.2. See patches below. However, that probably won't fix the above. Try running with --run-libc-freeres=no, and see http://www.valgrind.org/docs/manual/manual-core.html#manual-core.flags for background on it. > BTW, just another question: is it possible to add support to silent the > errors from an entire lib or for example use wilcards in the function trace > (this would be very useful for us, as for example in php 4 and php 5 the > entry point function has different names and thus I need two entries in the > suppression file that only differ in that entry point function name.) See http://www.valgrind.org/docs/manual/manual-core.html#manual-core.suppress You can use function names or object names. And you can use use ? and * in those names. That gives some level of flexibility. J Author: sewardj Date: 2006-12-06 03:35:38 +0000 (Wed, 06 Dec 2006) New Revision: 6377 Log: When generating suppressions, remember to Z-demangle function names, since the suppression-matching machinery does the same. Not doing so causes auto-generated suppressions involving Z-mangled fn names to not work. Modified: trunk/coregrind/m_errormgr.c Modified: trunk/coregrind/m_errormgr.c =================================================================== --- trunk/coregrind/m_errormgr.c 2006-12-01 18:48:56 UTC (rev 6376) +++ trunk/coregrind/m_errormgr.c 2006-12-06 03:35:38 UTC (rev 6377) @@ -402,7 +402,7 @@ { static UChar buf[ERRTXT_LEN]; - if ( VG_(get_fnname_nodemangle) (ip, buf, ERRTXT_LEN) ) { + if ( VG_(get_fnname_Z_demangle_only) (ip, buf, ERRTXT_LEN) ) { VG_(printf)(" fun:%s\n", buf); } else if ( VG_(get_objname)(ip, buf, ERRTXT_LEN) ) { VG_(printf)(" obj:%s\n", buf); Author: sewardj Date: 2006-12-06 03:36:24 +0000 (Wed, 06 Dec 2006) New Revision: 6378 Log: Fix suppression-matching bogon (Paul Floyd). Modified: trunk/memcheck/mc_main.c Modified: trunk/memcheck/mc_main.c =================================================================== --- trunk/memcheck/mc_main.c 2006-12-06 03:35:38 UTC (rev 6377) +++ trunk/memcheck/mc_main.c 2006-12-06 03:36:24 UTC (rev 6378) @@ -3437,7 +3437,7 @@ return (ekind == FreeErr || ekind == FreeMismatchErr); case OverlapSupp: - return (ekind = OverlapErr); + return (ekind == OverlapErr); case LeakSupp: return (ekind == LeakErr); |
|
From: Nuno L. <nun...@sa...> - 2006-12-17 16:26:42
|
Hi, First of all let me thank you for this wonderful tool ;) I work in the PHP project and we are using valgrind in our automated test suite (http://gcov.php.net). It tests several extensions, which makes PHP to be linked with several libraries (each one with its own leaks and similar stuff). I'm currently having some difficulties in suppressing all those errors that come from external libraries, expecially after I added the oracle lib to the build (it has some optimizations that seem to confuse valgrind). For example this report http://gcov.php.net/viewer.php?version=PHP_5_2&func=valgrind&file=v8a0751b5763509f655d06762b4300b41 says: ==31871== Invalid free() / delete / delete[] ==31871== at 0x401D39E: free (vg_replace_malloc.c:233) ==31871== by 0x59BB11B: (within /lib/libc-2.3.2.so) ==31871== by 0x59BAE64: __libc_freeres (in /lib/libc-2.3.2.so) ==31871== by 0x40184C1: _vgnU_freeres (vg_preloaded.c:60) ==31871== by 0x58DAB17: exit (in /lib/libc-2.3.2.so) ==31871== by 0x58C4E3D: (below main) (in /lib/libc-2.3.2.so) ==31871== Address 0x59E2E90 is not stack'd, malloc'd or (recently) free'd --gen-suppressions=all produces: { <insert a suppression name here> Memcheck:Free fun:_vgrZU_libcZdsoZa_free obj:/lib/libc-2.3.2.so fun:__libc_freeres fun:_vgnU_freeres fun:exit fun:__libc_start_main } The problem is that this doesn't suppress the error. I don't know if you are aware of this problem, but I ran in a few similar issues in the server (some I could fix by replacing '_vgrZU_libcZdsoZa_free' with 'free', but not this one). If you need more details about the tests, just ask ;) BTW, just another question: is it possible to add support to silent the errors from an entire lib or for example use wilcards in the function trace (this would be very useful for us, as for example in php 4 and php 5 the entry point function has different names and thus I need two entries in the suppression file that only differ in that entry point function name.) Thanks in advance, Nuno |
|
From: <sv...@va...> - 2006-12-17 14:24:07
|
Author: sewardj
Date: 2006-12-17 14:24:05 +0000 (Sun, 17 Dec 2006)
New Revision: 1687
Log:
Make this compilable again.
Modified:
trunk/test/test-i386.c
trunk/test/test-i386.h
Modified: trunk/test/test-i386.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/test/test-i386.c 2006-12-01 02:59:17 UTC (rev 1686)
+++ trunk/test/test-i386.c 2006-12-17 14:24:05 UTC (rev 1687)
@@ -32,7 +32,7 @@
=20
/* Setting this to 1 creates a very comprehensive test of
integer condition codes. */
-#define TEST_INTEGER_VERBOSE 0
+#define TEST_INTEGER_VERBOSE 1
=20
=20
//#define LINUX_VM86_IOPL_FIX
@@ -261,12 +261,12 @@
: "=3Dr" (res)\
: "r" (v1), "r" (v2));\
printf("%-10s %d\n", "set" JCC, res);\
- {\
+ { int one =3D 1; \
asm("movl $0x12345678, %0\n\t"\
"cmpl %2, %1\n\t"\
"cmov" JCC "l %3, %0\n\t"\
: "=3Dr" (res)\
- : "r" (v1), "r" (v2), "m" (1));\
+ : "r" (v1), "r" (v2), "m" (one));\
printf("%-10s R=3D0x%08x\n", "cmov" JCC "l", res);\
asm("movl $0x12345678, %0\n\t"\
"cmpl %2, %1\n\t"\
@@ -506,11 +506,12 @@
{\
int res, val, resz;\
val =3D op0;\
- asm("xorl %1, %1\n"\
- "movl $0x12345678, %0\n"\
- #op " %" size "2, %" size "0 ; setz %b1" \
+ asm("xorl %1, %1\n\t"\
+ "movl $0x12345678, %0\n\t"\
+ #op " %" size "2, %" size "0\n\t" \
+ "setz %b1" \
: "=3Dr" (res), "=3Dq" (resz)\
- : "g" (val));\
+ : "r" (val));\
printf("%-10s A=3D%08x R=3D%08x %d\n", #op, val, res, resz);\
}
=20
@@ -594,7 +595,8 @@
/* test all roundings */
asm volatile ("fstcw %0" : "=3Dm" (fpuc));
for(i=3D0;i<4;i++) {
- asm volatile ("fldcw %0" : : "m" ((fpuc & ~0x0c00) | (i << 10)))=
;
+ int16_t tmp =3D (fpuc & ~0x0c00) | (i << 10);
+ asm volatile ("fldcw %0" : : "m" (tmp));
asm volatile ("fist %0" : "=3Dm" (wa) : "t" (a));
asm volatile ("fistl %0" : "=3Dm" (ia) : "t" (a));
asm volatile ("fistpll %0" : "=3Dm" (lla) : "t" (a) : "st");
Modified: trunk/test/test-i386.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/test/test-i386.h 2006-12-01 02:59:17 UTC (rev 1686)
+++ trunk/test/test-i386.h 2006-12-17 14:24:05 UTC (rev 1687)
@@ -1,4 +1,6 @@
=20
+#define FULLTXT 1
+
#define exec_op glue(exec_, OP)
#define exec_opl glue(glue(exec_, OP), l)
#define exec_opw glue(glue(exec_, OP), w)
@@ -29,8 +31,13 @@
res =3D s0;
flags =3D iflags;
EXECOP1("", res, flags);
- printf("%-6s A=3D%08x R=3D%08x CCIN=3D%04x CC=3D%04x\n",
- stringify(OP) "l", s0, res, iflags, flags & CC_MASK);
+ if (FULLTXT)
+ printf("%-6s A=3D%08x R=3D%08x CCIN=3D%04x CC=3D%04x\n",
+ stringify(OP) "l", s0, res, iflags, flags & CC_MASK);
+ else
+ printf("%08x %04x %04x\n",
+ res, iflags, flags & CC_MASK);
+
}
inline void exec_opw(int s0, int s1, int iflags)
{
@@ -38,8 +45,13 @@
res =3D s0;
flags =3D iflags;
EXECOP1("w", res, flags);
- printf("%-6s A=3D%08x R=3D%08x CCIN=3D%04x CC=3D%04x\n",
- stringify(OP) "w", s0, res, iflags, flags & CC_MASK);
+ if (FULLTXT)
+ printf("%-6s A=3D%08x R=3D%08x CCIN=3D%04x CC=3D%04x\n",
+ stringify(OP) "w", s0, res, iflags, flags & CC_MASK);
+ else
+ printf("%08x %04x %04x\n",
+ res, iflags, flags & CC_MASK);
+
}
inline void exec_opb(int s0, int s1, int iflags)
{
@@ -47,8 +59,13 @@
res =3D s0;
flags =3D iflags;
EXECOP1("b", res, flags);
- printf("%-6s A=3D%08x R=3D%08x CCIN=3D%04x CC=3D%04x\n",
- stringify(OP) "b", s0, res, iflags, flags & CC_MASK);
+ if (FULLTXT)
+ printf("%-6s A=3D%08x R=3D%08x CCIN=3D%04x CC=3D%04x\n",
+ stringify(OP) "b", s0, res, iflags, flags & CC_MASK);
+ else
+ printf("%08x %04x %04x\n",
+ res, iflags, flags & CC_MASK);
+
}
#else
inline void exec_opl(int s0, int s1, int iflags)
@@ -57,8 +74,12 @@
res =3D s0;
flags =3D iflags;
EXECOP2("", res, s1, flags);
- printf("%-6s A=3D%08x B=3D%08x R=3D%08x CCIN=3D%04x CC=3D%04x\n",
- stringify(OP) "l", s0, s1, res, iflags, flags & CC_MASK);
+ if (FULLTXT)
+ printf("%-6s A=3D%08x B=3D%08x R=3D%08x CCIN=3D%04x CC=3D%04x\n",
+ stringify(OP) "l", s0, s1, res, iflags, flags & CC_MASK);
+ else
+ printf("%08x %04x %04x\n",
+ res, iflags, flags & CC_MASK);
}
=20
inline void exec_opw(int s0, int s1, int iflags)
@@ -67,8 +88,12 @@
res =3D s0;
flags =3D iflags;
EXECOP2("w", res, s1, flags);
- printf("%-6s A=3D%08x B=3D%08x R=3D%08x CCIN=3D%04x CC=3D%04x\n",
- stringify(OP) "w", s0, s1, res, iflags, flags & CC_MASK);
+ if (FULLTXT)
+ printf("%-6s A=3D%08x B=3D%08x R=3D%08x CCIN=3D%04x CC=3D%04x\n",
+ stringify(OP) "w", s0, s1, res, iflags, flags & CC_MASK);
+ else
+ printf("%08x %04x %04x\n",
+ res, iflags, flags & CC_MASK);
}
=20
inline void exec_opb(int s0, int s1, int iflags)
@@ -77,8 +102,12 @@
res =3D s0;
flags =3D iflags;
EXECOP2("b", res, s1, flags);
- printf("%-6s A=3D%08x B=3D%08x R=3D%08x CCIN=3D%04x CC=3D%04x\n",
- stringify(OP) "b", s0, s1, res, iflags, flags & CC_MASK);
+ if (FULLTXT)
+ printf("%-6s A=3D%08x B=3D%08x R=3D%08x CCIN=3D%04x CC=3D%04x\n",
+ stringify(OP) "b", s0, s1, res, iflags, flags & CC_MASK);
+ else
+ printf("%08x %04x %04x\n",
+ res, iflags, flags & CC_MASK);
}
#endif
=20
@@ -177,3 +206,5 @@
=20
#undef OP
#undef OP_CC
+
+#undef FULLTXT
|
|
From: <sv...@va...> - 2006-12-17 14:20:34
|
Author: sewardj
Date: 2006-12-17 14:20:31 +0000 (Sun, 17 Dec 2006)
New Revision: 6406
Log:
Add missing case, apparently not very popular :-)
Modified:
trunk/memcheck/mc_translate.c
Modified: trunk/memcheck/mc_translate.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/memcheck/mc_translate.c 2006-12-16 14:25:04 UTC (rev 6405)
+++ trunk/memcheck/mc_translate.c 2006-12-17 14:20:31 UTC (rev 6406)
@@ -2439,6 +2439,7 @@
=20
case Iop_1Uto8:
case Iop_16to8:
+ case Iop_16HIto8:
case Iop_32to8:
case Iop_64to8:
return assignNew(mce, Ity_I8, unop(op, vatom));
|
|
From: <js...@ac...> - 2006-12-17 05:06:21
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-12-17 09:00:01 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 == 215 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: <js...@ac...> - 2006-12-17 05:03:13
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-12-17 04:30:02 GMT Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 250 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <to...@co...> - 2006-12-17 03:59:14
|
Nightly build on dunsmere ( athlon, Fedora Core 6 ) started at 2006-12-17 03:30:06 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 == 252 tests, 5 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) none/tests/tls (stdout) ================================================= == 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 == 252 tests, 5 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Dec 17 03:46:14 2006 --- new.short Sun Dec 17 03:59:08 2006 *************** *** 8,10 **** ! == 252 tests, 5 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 252 tests, 5 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) *************** *** 16,17 **** --- 16,18 ---- none/tests/pth_detached (stdout) + none/tests/tls (stdout) |
|
From: Tom H. <th...@cy...> - 2006-12-17 03:24:05
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-12-17 03:15:02 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccbx1Vgl.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbx1Vgl.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbx1Vgl.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbx1Vgl.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbx1Vgl.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbx1Vgl.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbx1Vgl.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbx1Vgl.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.14354/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.14354/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.14354/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.14354/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.14354/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccbUEx9k.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbUEx9k.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbUEx9k.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbUEx9k.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbUEx9k.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbUEx9k.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbUEx9k.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbUEx9k.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.14354/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.14354/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.14354/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.14354/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.14354/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Dec 17 03:19:30 2006 --- new.short Sun Dec 17 03:23:57 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccbUEx9k.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbUEx9k.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbUEx9k.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbUEx9k.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbUEx9k.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbUEx9k.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbUEx9k.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbUEx9k.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 --- 7,16 ---- Last 20 lines of verbose log follow echo ! /tmp/ccbx1Vgl.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbx1Vgl.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbx1Vgl.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbx1Vgl.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbx1Vgl.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbx1Vgl.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbx1Vgl.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbx1Vgl.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-12-17 03:23:01
|
Nightly build on dellow ( x86_64, Fedora Core 6 ) started at 2006-12-17 03:10: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 == 280 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == 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 == 280 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Dec 17 03:16:34 2006 --- new.short Sun Dec 17 03:22:54 2006 *************** *** 8,10 **** ! == 280 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 280 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) *************** *** 14,16 **** none/tests/mremap2 (stdout) - none/tests/pth_detached (stdout) --- 14,15 ---- |
|
From: Tom H. <th...@cy...> - 2006-12-17 03:17:54
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-12-17 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 == 280 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-12-17 03:11:49
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-12-17 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 ... failed Regression test results follow == 282 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == 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) |
|
From: <js...@ac...> - 2006-12-17 01:16:37
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2006-12-17 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 == 221 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) ================================================= == 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 == 221 tests, 6 stderr failures, 4 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (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/ppc32/jm-int (stdout) none/tests/ppc64/jm-int (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Dec 17 02:08:21 2006 --- new.short Sun Dec 17 02:16:33 2006 *************** *** 8,10 **** ! == 221 tests, 6 stderr failures, 4 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) --- 8,10 ---- ! == 221 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) *************** *** 17,20 **** none/tests/mremap2 (stdout) - none/tests/ppc32/jm-int (stdout) - none/tests/ppc64/jm-int (stdout) --- 17,18 ---- |