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
(33) |
2
(15) |
3
(20) |
4
(22) |
5
(13) |
|
6
(12) |
7
(32) |
8
(17) |
9
(31) |
10
(21) |
11
(7) |
12
(13) |
|
13
(13) |
14
(12) |
15
(10) |
16
(8) |
17
(7) |
18
(28) |
19
(5) |
|
20
(5) |
21
(7) |
22
(11) |
23
(7) |
24
(13) |
25
(7) |
26
(7) |
|
27
(7) |
28
(15) |
29
(30) |
30
(21) |
31
(6) |
|
|
|
From: <sv...@va...> - 2008-07-18 21:03:04
|
Author: sewardj Date: 2008-07-18 22:03:11 +0100 (Fri, 18 Jul 2008) New Revision: 8448 Log: Temporarily disable Qt4-related tests, as they don't build on systems with qt-4.2.1 at least. It appears the type of QMutex::tryLock has changed somewhere after qt-4.2.1. Modified: trunk/drd/tests/Makefile.am Modified: trunk/drd/tests/Makefile.am =================================================================== --- trunk/drd/tests/Makefile.am 2008-07-18 20:46:00 UTC (rev 8447) +++ trunk/drd/tests/Makefile.am 2008-07-18 21:03:11 UTC (rev 8448) @@ -238,9 +238,9 @@ tc24_nonzero_sem \ trylock -if HAVE_QTCORE -check_PROGRAMS += qt4_mutex qt4_rwlock qt4_semaphore -endif +#if HAVE_QTCORE +#check_PROGRAMS += qt4_mutex qt4_rwlock qt4_semaphore +#endif if HAVE_OPENMP check_PROGRAMS += omp_matinv omp_prime @@ -316,17 +316,17 @@ pth_spinlock_SOURCES = pth_spinlock.c pth_spinlock_LDADD = -lpthread -if HAVE_QTCORE -qt4_mutex_SOURCES = qt4_mutex.cpp -qt4_mutex_LDADD = -lQtCore -lpthread +#if HAVE_QTCORE +#qt4_mutex_SOURCES = qt4_mutex.cpp +#qt4_mutex_LDADD = -lQtCore -lpthread +# +#qt4_rwlock_SOURCES = qt4_rwlock.cpp +#qt4_rwlock_LDADD = -lQtCore -lpthread +# +#qt4_semaphore_SOURCES = qt4_semaphore.cpp +#qt4_semaphore_LDADD = -lQtCore -lpthread +#endif -qt4_rwlock_SOURCES = qt4_rwlock.cpp -qt4_rwlock_LDADD = -lQtCore -lpthread - -qt4_semaphore_SOURCES = qt4_semaphore.cpp -qt4_semaphore_LDADD = -lQtCore -lpthread -endif - recursive_mutex_SOURCES = recursive_mutex.c recursive_mutex_LDADD = -lpthread |
|
From: <sv...@va...> - 2008-07-18 20:45:51
|
Author: sewardj
Date: 2008-07-18 21:46:00 +0100 (Fri, 18 Jul 2008)
New Revision: 8447
Log:
Always include the X client library suppressions, and don't bother doing
any testing for X (which was always pretty bogus anyway).
Modified:
trunk/configure.in
Modified: trunk/configure.in
===================================================================
--- trunk/configure.in 2008-07-18 20:34:49 UTC (rev 8446)
+++ trunk/configure.in 2008-07-18 20:46:00 UTC (rev 8447)
@@ -576,17 +576,15 @@
AC_SUBST(GLIBC_VERSION)
-# We don't know how to detect the X client library version
-# (detecting the server version is easy, but no help). So we
-# just use a hack: always include the suppressions for both
-# versions 3 and 4.
-AC_PATH_X
-if test "${no_x}" != 'yes' ; then
- DEFAULT_SUPP="xfree-4.supp ${DEFAULT_SUPP}"
- DEFAULT_SUPP="xfree-3.supp ${DEFAULT_SUPP}"
-fi
+# Add default suppressions for the X client libraries. Make no
+# attempt to detect whether such libraries are installed on the
+# build machine (or even if any X facilities are present); just
+# add the suppressions antidisirregardless.
+DEFAULT_SUPP="xfree-4.supp ${DEFAULT_SUPP}"
+DEFAULT_SUPP="xfree-3.supp ${DEFAULT_SUPP}"
+
# Check for CLOCK_MONOTONIC
AC_MSG_CHECKING([for CLOCK_MONOTONIC])
|
|
From: <sv...@va...> - 2008-07-18 20:34:41
|
Author: sewardj Date: 2008-07-18 21:34:49 +0100 (Fri, 18 Jul 2008) New Revision: 8446 Log: Remove initial settings of CXXFLAGS/CPPFLAGS, as they cause -I/usr/include/qt4 to be given to compilation of the entire system. Modified: trunk/configure.in Modified: trunk/configure.in =================================================================== --- trunk/configure.in 2008-07-18 20:15:46 UTC (rev 8445) +++ trunk/configure.in 2008-07-18 20:34:49 UTC (rev 8446) @@ -52,8 +52,6 @@ # Checks for programs. CFLAGS="-Wno-long-long" -CXXFLAGS="-I/usr/include/qt4" -CPPFLAGS="-I/usr/include/qt4" AC_PROG_LN_S AC_PROG_CC |
|
From: <sv...@va...> - 2008-07-18 20:15:39
|
Author: sewardj
Date: 2008-07-18 21:15:46 +0100 (Fri, 18 Jul 2008)
New Revision: 8445
Log:
Fix a silly mistake resulting in a bunch of global variables being
defined in all the object files in Memcheck.
Modified:
trunk/memcheck/mc_include.h
Modified: trunk/memcheck/mc_include.h
===================================================================
--- trunk/memcheck/mc_include.h 2008-07-18 18:23:24 UTC (rev 8444)
+++ trunk/memcheck/mc_include.h 2008-07-18 20:15:46 UTC (rev 8445)
@@ -98,10 +98,10 @@
MC_Chunk* MC_(get_freed_list_head)( void );
/* For tracking malloc'd blocks */
-VgHashTable MC_(malloc_list);
+extern VgHashTable MC_(malloc_list);
/* For tracking memory pools. */
-VgHashTable MC_(mempool_list);
+extern VgHashTable MC_(mempool_list);
/* Shadow memory functions */
Bool MC_(check_mem_is_noaccess)( Addr a, SizeT len, Addr* bad_addr );
@@ -242,11 +242,11 @@
Reachedness;
/* For VALGRIND_COUNT_LEAKS client request */
-SizeT MC_(bytes_leaked);
-SizeT MC_(bytes_indirect);
-SizeT MC_(bytes_dubious);
-SizeT MC_(bytes_reachable);
-SizeT MC_(bytes_suppressed);
+extern SizeT MC_(bytes_leaked);
+extern SizeT MC_(bytes_indirect);
+extern SizeT MC_(bytes_dubious);
+extern SizeT MC_(bytes_reachable);
+extern SizeT MC_(bytes_suppressed);
typedef
enum {
@@ -289,7 +289,7 @@
value origin could have been collected (but wasn't) ? If yes,
then, at the end of the run, print a 1 line message advising that a
rerun with --track-origins=yes might help. */
-Bool MC_(any_value_errors);
+extern Bool MC_(any_value_errors);
/* Standard functions for error and suppressions as required by the
core/tool iface */
@@ -363,23 +363,23 @@
/*------------------------------------------------------------*/
/* Allow loads from partially-valid addresses? default: YES */
-Bool MC_(clo_partial_loads_ok);
+extern Bool MC_(clo_partial_loads_ok);
/* Max volume of the freed blocks queue. */
-Long MC_(clo_freelist_vol);
+extern Long MC_(clo_freelist_vol);
/* Do leak check at exit? default: NO */
-LeakCheckMode MC_(clo_leak_check);
+extern LeakCheckMode MC_(clo_leak_check);
/* How closely should we compare ExeContexts in leak records? default: 2 */
-VgRes MC_(clo_leak_resolution);
+extern VgRes MC_(clo_leak_resolution);
/* In leak check, show reachable-but-not-freed blocks? default: NO */
-Bool MC_(clo_show_reachable);
+extern Bool MC_(clo_show_reachable);
/* Assume accesses immediately below %esp are due to gcc-2.96 bugs.
* default: NO */
-Bool MC_(clo_workaround_gcc296_bugs);
+extern Bool MC_(clo_workaround_gcc296_bugs);
/* Fill malloc-d/free-d client blocks with a specific value? -1 if
not, else 0x00 .. 0xFF indicating the fill value to use. Can be
@@ -387,8 +387,8 @@
more repeatable ways. Note that malloc-filled and free-filled
areas are still undefined and noaccess respectively. This merely
causes them to contain the specified values. */
-Int MC_(clo_malloc_fill);
-Int MC_(clo_free_fill);
+extern Int MC_(clo_malloc_fill);
+extern Int MC_(clo_free_fill);
/* Indicates the level of instrumentation/checking done by Memcheck.
@@ -413,7 +413,7 @@
The default is 2.
*/
-Int MC_(clo_mc_level);
+extern Int MC_(clo_mc_level);
/*------------------------------------------------------------*/
|
|
From: Tom H. <to...@co...> - 2008-07-18 18:27:58
|
In message <4880CE91.5070506@BitWagon.com>
John Reiser <jreiser@BitWagon.com> wrote:
> Tom Hughes wrote:
>
> > This appears to call back to the alloc_zeroed_x86_GDT routine in
> > valgrind from VEX which I don't believe is allowed so you'll need
> > to find a better way to do that.
>
> It runs correctly, and I'm unclear about what is not allowed, and why.
> The GDT (GlobalDescriptorTable) is part of x86 state for a process.
> Most processes with "flat" address space don't care, but the
> instructions LDS/LES/LFS/LGS/LSS do, and so do PUSH/POP/MOV of
> segment registers. The existing minimal use of the GDT was
> on the valgrind side of the "line" between VEX and valgrind.
> Should it be moved to the VEX side (and exported from there
> so that valgrind can use it)?
The point is that VEX is a library that is supposed to be usable
on it's own without valgrind, so it can't call any routines in
valgrind directly - some sort of callback via a function pointer
has to be used.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2008-07-18 18:21:24
|
Author: sewardj Date: 2008-07-18 19:21:32 +0100 (Fri, 18 Jul 2008) New Revision: 8443 Log: Stop mpxlc complaining about GNU-isms when compiling libmpiwrap.c. Modified: trunk/auxprogs/Makefile.am Modified: trunk/auxprogs/Makefile.am =================================================================== --- trunk/auxprogs/Makefile.am 2008-07-18 18:20:42 UTC (rev 8442) +++ trunk/auxprogs/Makefile.am 2008-07-18 18:21:32 UTC (rev 8443) @@ -45,10 +45,10 @@ # if VGO_AIX5 HACKY_FLAGS_PRI = -g -O -bE:libmpiwrap_aix5.exp -bM:SRE -bnoentry \ - -qflag=w:w \ + -qflag=w:w -qlanglvl=extended \ `echo $(AM_FLAG_M3264_PRI) | sed s/maix/q/g` HACKY_FLAGS_SEC = -g -O -bE:libmpiwrap_aix5.exp -bM:SRE -bnoentry \ - -qflag=w:w \ + -qflag=w:w -qlanglvl=extended \ `echo $(AM_FLAG_M3264_SEC) | sed s/maix/q/g` else HACKY_FLAGS_PRI = -g -O -fno-omit-frame-pointer -Wall -fpic -shared \ |
|
From: <sv...@va...> - 2008-07-18 18:20:35
|
Author: sewardj
Date: 2008-07-18 19:20:42 +0100 (Fri, 18 Jul 2008)
New Revision: 8442
Log:
* Make sure we're using GNU sed; install can otherwise fail
* when getting the gcc version number, be robust to strings like
"gcc.orig (GNU) 3.3.3" -- previous pattern was fooled by the dot
in "gcc.orig"
Modified:
trunk/configure.in
Modified: trunk/configure.in
===================================================================
--- trunk/configure.in 2008-07-18 08:48:04 UTC (rev 8441)
+++ trunk/configure.in 2008-07-18 18:20:42 UTC (rev 8442)
@@ -92,10 +92,30 @@
])
+# Check we have GNU sed: some of the stuff done by "make install" relies
+# on some pretty fancy sed expressions, and AIX sed doesn't produce the
+# same results, causing install to fail
+
+AC_MSG_CHECKING([for GNU sed])
+
+[sed_firstline=`sed --version | head -n 1`]
+
+case "${sed_firstline}" in
+ GNU*)
+ AC_MSG_RESULT([ok, looks like GNU sed])
+ ;;
+ *)
+ AC_MSG_RESULT([please ensure first 'sed' in your path is GNU sed])
+ AC_MSG_RESULT([note: GNU sed is only required at build/install time])
+ AC_MSG_ERROR([build/install requires that 'sed' is GNU sed])
+ ;;
+esac
+
+
# We don't want gcc < 3.0
AC_MSG_CHECKING([for a supported version of gcc])
-[gcc_version=`${CC} --version | head -n 1 | sed 's/^[^0-9.]*\([0-9.]*\).*$/\1/'`]
+[gcc_version=`${CC} --version | head -n 1 | sed 's/^[^0-9]*\([0-9.]*\).*$/\1/'`]
case "${gcc_version}" in
2.*)
|
|
From: John R.
|
Tom Hughes wrote: > In message <4874ED25.3090501@BitWagon.com> > John Reiser <jr...@bi...> wrote: > > >>This is patch 2/14 on the valgrind side for wine+valgrind co-operation. >> >>Let wine tell valgrind about explicit stack switching. >>This is safer, more effective, and less noisy than letting >>valgrind try to figure it out. > > > This mostly looks sensible, just a few queries: > > - What is stack_threshold all about? It seems to cause various > debug messages to be issued when dealing with any stack after > the 625th stack to be registered... Leftover debugging code. [Becomes useful when assumptions are not documented, unclear, or misunderstood.] > > - Why does VG_(unknown_SP_update) no longer check that current_stack > is non-null before dereferencing it? Bug in editing or construction of patch. > > - The comment on VG_(switch_stack) looks bogus both because it > seems to have nothing to do with wine (it looks like you grabbed > it from some previous UML work?) and because it isn't relevant > to the stack code who uses it or why. Previous UML work does apply. I'll revise and re-submit, perhaps after discussion of summary points (which have been snipped from this reply.) -- |
|
From: John R.
|
Tom Hughes wrote: > In message <4874ED33.7060009@BitWagon.com> > John Reiser <jr...@bi...> wrote: > > >>This is patch 3/14 on the valgrind side for wine+valgrind co-operation. >> >>Initialize the x86 Global Descriptor Table with plausible values. > > > This appears to call back to the alloc_zeroed_x86_GDT routine in > valgrind from VEX which I don't believe is allowed so you'll need > to find a better way to do that. It runs correctly, and I'm unclear about what is not allowed, and why. The GDT (GlobalDescriptorTable) is part of x86 state for a process. Most processes with "flat" address space don't care, but the instructions LDS/LES/LFS/LGS/LSS do, and so do PUSH/POP/MOV of segment registers. The existing minimal use of the GDT was on the valgrind side of the "line" between VEX and valgrind. Should it be moved to the VEX side (and exported from there so that valgrind can use it)? -- |
|
From: John R.
|
Tom Hughes wrote: > In message <4874ED7D.9040902@BitWagon.com> > John Reiser <jr...@bi...> wrote: > > >>This is patch 7/14 on the valgrind side for wine+valgrind co-operation. >> >>The valgrind addresspace manager accepts wine's plans for allocating >>address space. For instance, Win32 applications expect to use the >>interval [0, 0x60000000). Wine reserves space for use by the app, >>and valgrind can honor these plans. > > > The thing that immediately stands out here is that you're changing > the default load address for valgrind, which is a major thing. > > The current addresses are the product of many years of attempts to > find the best compromise and I suspect Julian will be very reluctant > to change them. There are four players in the same address space: valgrind, Wine, the Win32 app, and Linux. The Win32 environment allows the app to demand complete control of the interval [4MB, N) where N is very large (certainly larger than 0x38000000) and modest control over [0, 4MB). While most Win32 apps don't care, there are some large and important apps that do. Wine has decided that 0x60000000 should be the upper limit. Thus keeping valgrind out of [0, 0x60000000) is necessary, and [part of] the easiest way to do so is to change the static load address for valgrind tools to 0x60000000. One can imagine a startup relocation phase, perhaps similar to that used by relocatable Linux kernels, which would allow moving valgrind tools to a given address at runtime. Or, perhaps tools could be compiled -fPIC, then prelink to different base addresses. -fPIC loses a register on most architectures, and might be costly. [Can prelink move an ET_EXEC file?] 0x60000000 is necessary for wine, somehow. > > On top of that the patch does involve us getting very intimate with > wine - what is the status of the wine side of this patch? On the Wine side, the first piece involves the mechanism for communicating the different classes of reservations of address space. wine-preloader has been setting the global symbol 'wine_main_preload_info' to point to an array of struct. Due to a bug in binutils, such a symbol cannot be made visible in a valgrind tool, because valgrind tools have no undefined symbols, therefore --export-dynamic is denied. I observe that a binutils bug of this kind likely persists without fix. Therefore I created a new Elf32_auxv_t tag AT_WINE_PRELOAD_INFO to point to the array of struct. This has general applicability, and some advantages even for existing Wine tools and Win32 apps. The rest of the Wine side of this piece has no changes. The second piece on the Wine side involves getting Wine to share the rest of the address space with memcheck. Win32 itself has reservations on [0x7f000000, 0x81000000), so Wine does, too; and that's fine. The problem is Wine grabbing all higher addresses, from 0x81000000 up to the stack. This leaves only [0x60000000, 0x7f000000) to be shared between wine and memcheck, and memcheck runs out for large apps. So the second piece on the Wine side is to not grab [0x81000000, stack), but to share that with memcheck, too. Valgrind tools, through the address space manager, are happy to share with wine each block as allocated and freed. This works fine, but has not yet been acknowledged by Wine. > > Perhaps you could also explain what this patch gives us? It is > certainly possibly to run programs under wine without it as we are > doing so... Some important Win32 apps do not tolerate any intrusion into [0, 0x60000000). This patch caters to such applications. The programs that run under wine while memcheck occupies space at 0x38000000 are less demanding than some other large and important Win32 apps. -- |
|
From: John R.
|
Tom Hughes wrote: > In message <4874ED0B.3000603@BitWagon.com> > John Reiser <jr...@bi...> wrote: > > >>This is patch 1/14 on the valgrind side for wine+valgrind co-operation. >> >>Wine operates in cramped quarters. Detect some stack overflows >>that can ruin your whole day. > > > I'll leave Julian to think about whether this is useful and/or > something we want, but if it is then there are a few style issues: > > - You're counting the number of "blips" in n_blip but you don't > ever use that for anything. > > - The printf that would report the problems is commented out. > > - You're remembering the last 1024 bogeys in a circular buffer > but that history is never used for anything. > > - You have various global variables that should probably be static. The ability to track intensively the accesses to one address has proved to be useful in the last two projects (UserModeLinux, Wine.) Such a facility is particularly valuable during development when conflicting assumptions are unknown or poorly understood, but also during production use by large or important customer applications. In the case of Wine, there is a critical stack that is only 12 KiB and is unprotected by a guard page. Supposedly "it never overflows" but it did for me. Often the accesses which signify problems cannot be recognized or reproduced precisely. Sometimes the first N accesses do not matter, or the cause of the problem is M accesses before an actual error. Thus the count and circular buffer. Determining in advance exactly what to report (and how) is problematic or cumbersome. It is easier to run memcheck under gdb, or to attach gdb externally, then inspect by hand. Thus the "unused" history, non-static variables, etc. The dynamic runtime costs are under the control of CHECK_BOGEY macro. Perhaps the static runtime costs (arrays, counter, subroutine) deserve a "#if FEATURE_BOGEY" conditional compilation flag. But it is worthwhile to have the feature available, and [semi-]ready-to-run. -- |
|
From: Tom H. <to...@co...> - 2008-07-18 09:49:17
|
In message <4874ED25.3090501@BitWagon.com>
John Reiser <jr...@bi...> wrote:
> This is patch 2/14 on the valgrind side for wine+valgrind co-operation.
>
> Let wine tell valgrind about explicit stack switching.
> This is safer, more effective, and less noisy than letting
> valgrind try to figure it out.
This mostly looks sensible, just a few queries:
- What is stack_threshold all about? It seems to cause various
debug messages to be issued when dealing with any stack after
the 625th stack to be registered...
- Why does VG_(unknown_SP_update) no longer check that current_stack
is non-null before dereferencing it?
- The comment on VG_(switch_stack) looks bogus both because it
seems to have nothing to do with wine (it looks like you grabbed
it from some previous UML work?) and because it isn't relevant
to the stack code who uses it or why.
Other than that, a quick summary of what this patch does:
- Makes VALGRIND_STACK_REGISTER return an existing stack ID if
the address range matches rather than allocating a new stack.
- Adds VALGRIND_STACK_DEREGADDR which deregisters a stack
like VALGRIND_STACK_DEREGISTER but which takes an address
rather than a stack ID as the means to find the stack.
- Adds VALGRIND_SWITCH_STACK which tells valgrind that the client
is switching to a new stack.
- If VG_(unknown_SP_update) detects that the new stack pointer
is in a known stack and the old stack pointer is not in that
stack then it returns without either warning or alerting
memcheck to a stack change. This is probably correct I think.
What do people think of these changes in general?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2008-07-18 09:23:41
|
In message <4874ED0B.3000603@BitWagon.com>
John Reiser <jr...@bi...> wrote:
> This is patch 1/14 on the valgrind side for wine+valgrind co-operation.
>
> Wine operates in cramped quarters. Detect some stack overflows
> that can ruin your whole day.
I'll leave Julian to think about whether this is useful and/or
something we want, but if it is then there are a few style issues:
- You're counting the number of "blips" in n_blip but you don't
ever use that for anything.
- The printf that would report the problems is commented out.
- You're remembering the last 1024 bogeys in a circular buffer
but that history is never used for anything.
- You have various global variables that should probably be static.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2008-07-18 08:55:05
|
In message <4874ED7D.9040902@BitWagon.com>
John Reiser <jr...@bi...> wrote:
> This is patch 7/14 on the valgrind side for wine+valgrind co-operation.
>
> The valgrind addresspace manager accepts wine's plans for allocating
> address space. For instance, Win32 applications expect to use the
> interval [0, 0x60000000). Wine reserves space for use by the app,
> and valgrind can honor these plans.
The thing that immediately stands out here is that you're changing
the default load address for valgrind, which is a major thing.
The current addresses are the product of many years of attempts to
find the best compromise and I suspect Julian will be very reluctant
to change them.
On top of that the patch does involve us getting very intimate with
wine - what is the status of the wine side of this patch?
Perhaps you could also explain what this patch gives us? It is
certainly possibly to run programs under wine without it as we are
doing so...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2008-07-18 08:52:12
|
In message <4874ED59.1000007@BitWagon.com>
John Reiser <jr...@bi...> wrote:
> This is patch 5/14 on the valgrind side for wine+valgrind co-operation.
>
> alloc_zeroed_x86_GDT must be more visible.
> Avoid segment 0: hardware treats it as empty, and some software knows this.
If you're going to expose alloc_zeroed_x86_GDT then it needs a VG_()
wrapper, but see my other comment about the callback from VEX that
this change is supporting.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2008-07-18 08:51:03
|
In message <4874ED33.7060009@BitWagon.com>
John Reiser <jr...@bi...> wrote:
> This is patch 3/14 on the valgrind side for wine+valgrind co-operation.
>
> Initialize the x86 Global Descriptor Table with plausible values.
This appears to call back to the alloc_zeroed_x86_GDT routine in
valgrind from VEX which I don't believe is allowed so you'll need
to find a better way to do that.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2008-07-18 08:50:23
|
In message <4874ED4A.9000501@BitWagon.com>
John Reiser <jr...@bi...> wrote:
> This is patch 4/14 on the valgrind side for wine+valgrind co-operation.
>
> Implement the x86 instructions LDS/LES/LFS/LGS/LSS needed by wine for
> subroutine calling between different stack protocols.
This looks like a straightforward addition of some new instructions
to the x86 engine (it adds STI as well as those listed above) so it's
something for you Julian.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2008-07-18 08:48:12
|
In message <4874EE22.4020005@BitWagon.com>
John Reiser <jr...@bi...> wrote:
> This is patch 11/14 on the valgrind side for wine+valgrind co-operation.
>
> If allocated blocks overlap while checking for leaks, then print the
> two actual intervals which overlap, and give a readable message.
> This is much more usable than regurgitating the C code which
> detects the overlap.
Applied.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2008-07-18 08:47:57
|
Author: tom
Date: 2008-07-18 09:48:04 +0100 (Fri, 18 Jul 2008)
New Revision: 8441
Log:
When the leak checker finds overlapping blocks report the details
before asserting.
Based on patch from John Reiser <jreiser@BitWagon.com>.
Modified:
trunk/memcheck/mc_leakcheck.c
Modified: trunk/memcheck/mc_leakcheck.c
===================================================================
--- trunk/memcheck/mc_leakcheck.c 2008-07-18 08:38:44 UTC (rev 8440)
+++ trunk/memcheck/mc_leakcheck.c 2008-07-18 08:48:04 UTC (rev 8441)
@@ -704,14 +704,20 @@
to screw up is to use VALGRIND_MALLOCLIKE_BLOCK for stack
locations; again nonsensical. */
for (i = 0; i < lc_n_shadows-1; i++) {
- tl_assert( /* normal case - no overlap */
- (lc_shadows[i]->data + lc_shadows[i]->szB
- <= lc_shadows[i+1]->data )
- ||
- /* degenerate case: exact duplicates */
- (lc_shadows[i]->data == lc_shadows[i+1]->data
- && lc_shadows[i]->szB == lc_shadows[i+1]->szB)
- );
+ Bool nonsense_overlap = ! (
+ /* normal case - no overlap */
+ (lc_shadows[i]->data + lc_shadows[i]->szB <= lc_shadows[i+1]->data)
+ ||
+ /* degenerate case: exact duplicates */
+ (lc_shadows[i]->data == lc_shadows[i+1]->data
+ && lc_shadows[i]->szB == lc_shadows[i+1]->szB)
+ );
+ if (nonsense_overlap) {
+ VG_(message)(Vg_UserMsg, "Block [0x%lx, 0x%lx) overlaps with block [0x%lx, 0x%lx)",
+ lc_shadows[ i]->data, (lc_shadows[ i]->data + lc_shadows[ i]->szB),
+ lc_shadows[1+ i]->data, (lc_shadows[1+ i]->data + lc_shadows[1+ i]->szB) );
+ }
+ tl_assert (!nonsense_overlap);
}
if (lc_n_shadows == 0) {
|
|
From: Tom H. <to...@co...> - 2008-07-18 08:39:08
|
In message <4874EDFA.1040404@BitWagon.com>
John Reiser <jr...@bi...> wrote:
> This is patch 9/14 on the valgrind side for wine+valgrind co-operation.
>
> Print the actual memory addresses when complaining about setting the
> permissions on a large range. The user can distinguish known and
> unknown cases easily if the actual bounds are displayed.
Applied (although most of it was actually in patch 1...).
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2008-07-18 08:38:43
|
Author: tom
Date: 2008-07-18 09:38:44 +0100 (Fri, 18 Jul 2008)
New Revision: 8440
Log:
When warning about permissions being changed on a large chunk of
memory report the actual addresses involved not just the size.
Based on patch from John Reiser <jreiser@BitWagon.com>.
Modified:
trunk/memcheck/mc_main.c
Modified: trunk/memcheck/mc_main.c
===================================================================
--- trunk/memcheck/mc_main.c 2008-07-17 06:51:03 UTC (rev 8439)
+++ trunk/memcheck/mc_main.c 2008-07-18 08:38:44 UTC (rev 8440)
@@ -1357,7 +1357,8 @@
if (vabits16 == VA_BITS16_UNDEFINED) s = "undefined";
if (vabits16 == VA_BITS16_DEFINED ) s = "defined";
VG_(message)(Vg_UserMsg, "Warning: set address range perms: "
- "large range %lu (%s)", lenT, s);
+ "large range [0x%lx, 0x%lx) (%s)",
+ a, a + lenT, s);
}
}
|
|
From: Philippe W. <phi...@sk...> - 2008-07-18 06:34:53
|
>> That was more than one month ago but it has not yet materialised (all the >> legal paper takes time, I guess). I received some news that the paperwork is advancing, so I guess it should be integrated in a not too far future Philippe |
|
From: Tom H. <th...@cy...> - 2008-07-18 03:10:19
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2008-07-18 03:15:06 BST 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 == 345 tests, 60 stderr failures, 1 stdout failure, 29 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (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/origin1-yes (stderr) memcheck/tests/origin4-many (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (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-names (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/blockfault (stderr) none/tests/mremap2 (stdout) none/tests/shell (stderr) none/tests/shell_valid1 (stderr) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) 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...> - 2008-07-18 02:56:43
|
Nightly build on aston ( x86_64, Fedora Core 5 ) started at 2008-07-18 03:20:08 BST 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 == 443 tests, 8 stderr failures, 2 stdout failures, 2 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) drd/tests/tc08_hbl2 (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 == 443 tests, 8 stderr failures, 1 stdout failure, 2 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Jul 18 03:39:00 2008 --- new.short Fri Jul 18 03:56:51 2008 *************** *** 8,10 **** ! == 443 tests, 8 stderr failures, 1 stdout failure, 2 post failures == memcheck/tests/file_locking (stderr) --- 8,10 ---- ! == 443 tests, 8 stderr failures, 2 stdout failures, 2 post failures == memcheck/tests/file_locking (stderr) *************** *** 20,21 **** --- 20,22 ---- helgrind/tests/tc22_exit_w_lock (stderr) + drd/tests/tc08_hbl2 (stdout) |
|
From: Tom H. <th...@cy...> - 2008-07-18 02:53:23
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2008-07-18 03:05:07 BST 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 == 437 tests, 5 stderr failures, 2 stdout failures, 2 post failures == memcheck/tests/file_locking (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |