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: Nicholas N. <nj...@cs...> - 2008-07-09 22:06:17
|
On Mon, 7 Jul 2008 sv...@va... wrote: > Author: bart > Date: 2008-07-07 19:38:17 +0100 (Mon, 07 Jul 2008) > New Revision: 8388 > > Log: > Added paragraphs about the glib and Qt libraries. Do you mean "glibc"? Nick |
|
From: John R.
|
This is patch 14/14 on the valgrind side for wine+valgrind co-operation. Use MSVC FPO (Frame Pointer Omitted) debugging info to get better tracebacks. -- |
|
From: John R.
|
This is patch 13/14 on the valgrind side for wine+valgrind co-operation. The redirections for Win32 symbols _strlen, _strchr, _strcat, _strcpy which can be instantiated in any module (both .exe and .dll). -- |
|
From: John R.
|
This is patch 12/14 on the valgrind side for wine+valgrind co-operation. Handle debugging information (symbols and line numbers) for .pdb files used by win32 apps running under wine. Wine explicitly tells valgrind about .pdb. Wine's implementation of module loading is vastly different from that used by ld-linux.so, and it is too difficult to recognize what is going on just by observing the calls to mmap and mprotect. Also, practical use is eased because all calls [both from the app and from wine internal] go through just one wine module, LoadLibrary. -- |
|
From: John R.
|
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. -- |
|
From: John R.
|
This is patch 10/14 on the valgrind side for wine+valgrind co-operation. Co-operate with wine in cross-launching at execve. Detect when a wine application is being invoked, and splice valgrind_launcher into argv[] as appropriate. -- |
|
From: John R.
|
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. -- |
|
[Valgrind-developers] (8/14) vgsvn+wine-chkstk-nosym.patch recover
from frequent memcheck complaints
From: John R. |
This is patch 8/14 on the valgrind side for wine+valgrind co-operation. Win32 applications are required to allocate local stack frames (anything other than an actual PUSH instruction) using a subroutine __chkstk. __chkstk is equivalent to alloca(), but also probes each page. The probe insures that each stack page is instantiated immediately. This guarantees that the stack never suffers a _delayed_ out-of-memory condition. Also, advanced Win32 apps can and do notice each page fault; but a fault on the stack likely would recurse infinitely, and the app cannot do anything reasonable to recover. The stylized probe allows the operating system to hide page faults on the stack from the app. Unfortunately, the probing mechanism references memory on the unprotected side of the stack pointer, so memcheck notices. If symbols are available, then __chkstk can be redirected. However, there can be one instance of __chkstk per module (.dll or .so), and symbols often are not available for at least some of the .dlls. The slowdown that results from memcheck noticing, analyzing, and suppressing these errors (as often as several per subroutine CALL) is dramatic: sometimes an additional factor of 10. Therefore, it is essential to recover from these errors. Not only __chkstk, but also _strlen, _strchr, etc from Win32, and also some of the new "4x4" implementations of strlen, strchr, etc in glibc (4 bytes at a time, with inner loop unrolled 4 times) that can be missed by redirection, particularly in ld-linux.so. Luckily, there are quick heuristics (one or two compares) to separate likely candidates for recovery from the universe of all detected errors. If the heuristic indicates, then the original instruction stream is compared against the known culprits. If positively identified, then the instruction-stream translations are updated on-the-fly with a new redirection. Thus the speed penalty is paid just once per "missing" redirection. This affects Win32 __chkstk, _strlen, _strchr, _strcat and also glibc "4x4" code for strlen, strchr (4 bytes-at-a-time, and inner loop unrolled 4 times.) -- |
|
From: John R.
|
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. -- |
|
From: John R.
|
This is patch 6/14 on the valgrind side for wine+valgrind co-operation. Wine's plans for how to use the address space are communicated through [a pointer to] an array of struct. -- |
|
From: John R.
|
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. -- |
|
From: John R.
|
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. -- |
|
From: John R.
|
This is patch 3/14 on the valgrind side for wine+valgrind co-operation. Initialize the x86 Global Descriptor Table with plausible values. -- |
|
From: John R.
|
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. -- |
|
From: John R.
|
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. -- |
|
From: John R.
|
Hi, This series of patches enables memcheck and wine to work together enough to get useful results when analyzing applications originally written to run on Microsoft Win32 operating systems for x86, but now run under wine on Linux x86. Following messages will contain the patches for the valgrind side. Patches for the wine side have been submitted to win...@wi.... A web page to track the combined patches will appear anon, and will be announced. Summary: (1/14) bogey.patch detect some stack overflows (2/14) stacks.patch notify valgrind of explicit stack switching (3/14) VEX-x86-initGDT.patch better initial GlobalDescriptorTable (4/14) VEX-x86-loadSegReg_and_Reg.patch implement LDS/LES/LFS/LGS/LSS (5/14) vgsvn+wine-0-interface.patch better alloc_zeroed_x86_GDT (6/14) vgsvn+wine-0-preload-info.patch communicate wine address space (7/14) vgsvn+wine-addressspace.patch implement wine address space (8/14) vgsvn+wine-chkstk-nosym.patch recover from frequent memcheck complaints (9/14) vgsvn+wine-large-range.patch better warning message (10/14) vgsvn+wine-launch.patch co-operate on inter-launching wine (11/14) vgsvn+wine-leakcheck-overlap.patch better error message (12/14) vgsvn+wine-load-pdb-debuginfo.patch handle .pdb symbols and line numbers (13/14) vgsvn+wine-replace-strmem.patch _strlen etc. (14/14) vgsvn+wine-stacktrace.patch succeed when MSVC FramePointerOmitted -- |
|
From: <sv...@va...> - 2008-07-09 13:18:08
|
Author: bart
Date: 2008-07-09 14:18:14 +0100 (Wed, 09 Jul 2008)
New Revision: 8410
Log:
Added even more dynamic loader suppression patterns.
Modified:
trunk/glibc-2.X-drd.supp
Modified: trunk/glibc-2.X-drd.supp
===================================================================
--- trunk/glibc-2.X-drd.supp 2008-07-09 12:43:35 UTC (rev 8409)
+++ trunk/glibc-2.X-drd.supp 2008-07-09 13:18:14 UTC (rev 8410)
@@ -34,11 +34,29 @@
dl-dlsym-2
drd:ConflictingAccess
obj:/lib/ld-*.so
+ obj:/lib/libc-*.so
+ obj:/lib/libdl-*.so
+ obj:/lib/ld-*.so
+ obj:/lib/libdl-*.so
+ fun:dlsym
+}
+{
+ dl-dlsym-3
+ drd:ConflictingAccess
+ obj:/lib/ld-*.so
obj:/lib/tls/*/cmov/libc-*.so
obj:/lib/ld-*.so
fun:__libc_dlsym
}
{
+ dl-dlsym-4
+ drd:ConflictingAccess
+ obj:/lib/ld-*.so
+ obj:/lib/libc-*.so
+ obj:/lib/ld-*.so
+ fun:__libc_dlsym
+}
+{
dl-backtrace_symbols
drd:ConflictingAccess
fun:_dl_addr
|
|
From: <sv...@va...> - 2008-07-09 12:43:33
|
Author: bart
Date: 2008-07-09 13:43:35 +0100 (Wed, 09 Jul 2008)
New Revision: 8409
Log:
Print section type and name as a last resort in case the other allocation context detection attempts failed.
Modified:
trunk/drd/drd_error.c
Modified: trunk/drd/drd_error.c
===================================================================
--- trunk/drd/drd_error.c 2008-07-09 12:42:08 UTC (rev 8408)
+++ trunk/drd/drd_error.c 2008-07-09 12:43:35 UTC (rev 8409)
@@ -134,7 +134,21 @@
}
else
{
- VG_(message)(Vg_UserMsg, "Allocation context: unknown.");
+ char sect_name[64];
+ VgSectKind sect_kind;
+
+ sect_kind = VG_(seginfo_sect_kind)(sect_name, sizeof(sect_name), dri->addr);
+ if (sect_kind != Vg_SectUnknown)
+ {
+ VG_(message)(Vg_UserMsg,
+ "Allocation context: %s section of %s",
+ VG_(pp_SectKind)(sect_kind),
+ sect_name);
+ }
+ else
+ {
+ VG_(message)(Vg_UserMsg, "Allocation context: unknown.");
+ }
}
if (s_drd_show_conflicting_segments)
{
|
|
From: <sv...@va...> - 2008-07-09 12:42:11
|
Author: bart
Date: 2008-07-09 13:42:08 +0100 (Wed, 09 Jul 2008)
New Revision: 8408
Log:
Added more dynamic loader suppression patterns.
Modified:
trunk/glibc-2.X-drd.supp
Modified: trunk/glibc-2.X-drd.supp
===================================================================
--- trunk/glibc-2.X-drd.supp 2008-07-09 09:23:28 UTC (rev 8407)
+++ trunk/glibc-2.X-drd.supp 2008-07-09 12:42:08 UTC (rev 8408)
@@ -24,6 +24,27 @@
obj:/lib*/ld-*.so
}
{
+ dl-dlsym-1
+ drd:ConflictingAccess
+ obj:/lib/ld-*.so
+ obj:/lib/tls/*/cmov/libc-*.so
+ fun:_dl_sym
+}
+{
+ dl-dlsym-2
+ drd:ConflictingAccess
+ obj:/lib/ld-*.so
+ obj:/lib/tls/*/cmov/libc-*.so
+ obj:/lib/ld-*.so
+ fun:__libc_dlsym
+}
+{
+ dl-backtrace_symbols
+ drd:ConflictingAccess
+ fun:_dl_addr
+ fun:backtrace_symbols
+}
+{
libc
drd:ConflictingAccess
fun:__libc_enable_asynccancel
|
|
From: <sv...@va...> - 2008-07-09 09:23:21
|
Author: bart
Date: 2008-07-09 10:23:28 +0100 (Wed, 09 Jul 2008)
New Revision: 8407
Log:
Updated DRD test plan.
Added:
trunk/drd/scripts/add-libjemalloc-support
Modified:
trunk/drd/Testing.txt
Modified: trunk/drd/Testing.txt
===================================================================
--- trunk/drd/Testing.txt 2008-07-09 07:55:38 UTC (rev 8406)
+++ trunk/drd/Testing.txt 2008-07-09 09:23:28 UTC (rev 8407)
@@ -7,22 +7,25 @@
2. Run Konstantin's regression tests:
svn checkout http://data-race-test.googlecode.com/svn/trunk drt
make -C drt/unittest -s build
- ./vg-in-place --tool=drd drt/unittest/racecheck_unittest 2>&1|less
+ ./vg-in-place --tool=drd --check-stack-var=yes drt/unittest/racecheck_unittest 2>&1|less
3. Test the slowdown for matinv for various matrix sizes via the script
drd/scripts/run-matinv (must be about 24 for i == 1 and about
31 for i == 10 with n == 200).
4. Test whether DRD works with standard KDE applications and whether it does
- not print any false positives:
- ./vg-in-place --tool=drd kate
- ./vg-in-place --tool=drd --check-stack-var=yes kate
- ./vg-in-place --trace-children=yes --tool=drd knode
- ./vg-in-place --trace-children=yes --tool=drd --check-stack-var=yes knode
- ./vg-in-place --trace-children=yes --tool=drd amarokapp
+ not print any false positives. Test this both with KDE3 and KDE4.
+ ./vg-in-place --tool=drd --var-info=yes kate
+ ./vg-in-place --tool=drd --var-info=yes --check-stack-var=yes kate
+ ./vg-in-place --tool=drd --var-info=yes --trace-children=yes knode
+ ./vg-in-place --tool=drd --var-info=yes --check-stack-var=yes --trace-children=yes knode
+ ./vg-in-place --tool=drd --var-info=yes --check-stack-var=yes /usr/bin/designer
5. Test whether DRD works with standard GNOME applications. Expect
race reports triggered by ORBit_RootObject_duplicate() and after
having closed the GNOME terminal window:
- ./vg-in-place --trace-children=yes --tool=drd gnome-terminal
-6. Test DRD with Firefox. First of all, build and install Firefox 3:
+ ./vg-in-place --tool=drd --var-info=yes --trace-children=yes gnome-terminal
+6. Test DRD with Firefox. First of all, make sure that Valgrind is patched
+ such that it supports libjemalloc.so:
+ drd/scripts/add-libjemalloc-support
+ Next, build and install Firefox 3:
drd/scripts/download-and-build-firefox
- Next, run the following command:
- LD_LIBRARY_PATH=$HOME/software/mozilla-build/dist/lib: ./vg-in-place --trace-children=yes --tool=drd $HOME/software/mozilla-build/dist/bin/firefox-bin
+ Now run the following command:
+ LD_LIBRARY_PATH=$HOME/software/mozilla-build/dist/lib: ./vg-in-place --tool=drd --check-stack-var=yes --trace-children=yes $HOME/software/mozilla-build/dist/bin/firefox-bin
Added: trunk/drd/scripts/add-libjemalloc-support
===================================================================
--- trunk/drd/scripts/add-libjemalloc-support (rev 0)
+++ trunk/drd/scripts/add-libjemalloc-support 2008-07-09 09:23:28 UTC (rev 8407)
@@ -0,0 +1,96 @@
+#!/bin/bash
+
+if [ ! -e coregrind/m_replacemalloc/vg_replace_malloc.c ]; then
+ echo "Error: please start this script from the Valgrind source directory."
+ exit 1
+fi
+
+if grep -q -w libjemallocZdsoZa coregrind/m_replacemalloc/vg_replace_malloc.c;
+then
+ echo "The libjemalloc patch is already present."
+ exit 0
+fi
+
+{ cat <<'EOF' | patch -p0; } || exit $?
+Index: coregrind/m_replacemalloc/vg_replace_malloc.c
+===================================================================
+--- coregrind/m_replacemalloc/vg_replace_malloc.c (revision 7759)
++++ coregrind/m_replacemalloc/vg_replace_malloc.c (revision 7778)
+@@ -68,6 +68,10 @@
+ # error "Unknown platform"
+ #endif
+
++/* --- Soname of libjemalloc. --- */
++
++#define m_jemalloc_soname libjemallocZdsoZa /* libjemalloc.so* */
++
+ /* --- Soname of the GNU C++ library. --- */
+
+ #define m_libstdcxx_soname libstdcZpZpZa // libstdc++*
+@@ -203,6 +207,7 @@
+ // (from_so, from_fn, v's replacement)
+
+ // malloc
++ALLOC_or_NULL(m_jemalloc_soname, malloc, malloc);
+ ALLOC_or_NULL(m_libstdcxx_soname, malloc, malloc);
+ ALLOC_or_NULL(m_libc_soname, malloc, malloc);
+ #if defined(VGP_ppc32_aix5) || defined(VGP_ppc64_aix5)
+@@ -319,6 +324,7 @@
+ }
+
+ // free
++FREE(m_jemalloc_soname, free, free );
+ FREE(m_libstdcxx_soname, free, free );
+ FREE(m_libc_soname, free, free );
+ #if defined(VGP_ppc32_aix5) || defined(VGP_ppc64_aix5)
+@@ -394,6 +400,7 @@
+ return v; \
+ }
+
++CALLOC(m_jemalloc_soname, calloc);
+ CALLOC(m_libc_soname, calloc);
+ #if defined(VGP_ppc32_aix5) || defined(VGP_ppc64_aix5)
+ CALLOC(m_libc_soname, calloc_common);
+@@ -426,6 +433,7 @@
+ return v; \
+ }
+
++REALLOC(m_jemalloc_soname, realloc);
+ REALLOC(m_libc_soname, realloc);
+ #if defined(VGP_ppc32_aix5) || defined(VGP_ppc64_aix5)
+ REALLOC(m_libc_soname, realloc_common);
+@@ -457,6 +465,7 @@
+ return v; \
+ }
+
++MEMALIGN(m_jemalloc_soname, memalign);
+ MEMALIGN(m_libc_soname, memalign);
+
+
+@@ -483,6 +492,7 @@
+ ((SizeT)pszB, size); \
+ }
+
++VALLOC(m_jemalloc_soname, valloc);
+ VALLOC(m_libc_soname, valloc);
+
+
+@@ -566,6 +576,7 @@
+ return VKI_ENOMEM; \
+ }
+
++POSIX_MEMALIGN(m_jemalloc_soname, posix_memalign);
+ POSIX_MEMALIGN(m_libc_soname, posix_memalign);
+ #if defined(VGP_ppc32_aix5) || defined(VGP_ppc64_aix5)
+ /* 27 Nov 07: it appears that xlc links into executables, a
+@@ -596,6 +607,7 @@
+ return pszB; \
+ }
+
++MALLOC_USABLE_SIZE(m_jemalloc_soname, malloc_usable_size);
+ MALLOC_USABLE_SIZE(m_libc_soname, malloc_usable_size);
+
+
+EOF
+
+make -s
Property changes on: trunk/drd/scripts/add-libjemalloc-support
___________________________________________________________________
Name: svn:executable
+ *
|
|
From: Bart V. A. <bar...@gm...> - 2008-07-09 08:47:30
|
On Wed, Jul 9, 2008 at 9:47 AM, Julian Seward <js...@ac...> wrote: > On Wednesday 09 July 2008 09:47, Tom Hughes wrote: >> Do the GLib allocation routines not wind up calling the C library ones >> and hence get caught that way? > > Indeed; we've been shipping memcheck for N years now (5+ ?) and I don't > recall anybody telling us we were not intercepting memory allocation/ > free functions in glib. I would think memcheck would be unusable on > KDE and Gnome applications due to high noise level if that were really > the case. Are you sure? Hello Tom and Julian, Further analysis learned me that GLib uses the glibc memory allocation functions, unless told to do otherwise by a call to g_mem_set_vtable(). Sorry for the confusion -- I'll drop the patch. Bart. |
|
From: <sv...@va...> - 2008-07-09 07:55:30
|
Author: bart
Date: 2008-07-09 08:55:38 +0100 (Wed, 09 Jul 2008)
New Revision: 8406
Log:
Added GPR1 offset definitions.
Modified:
branches/CROSS_COMPILATION/vex-cross-compilation.patch
Modified: branches/CROSS_COMPILATION/vex-cross-compilation.patch
===================================================================
--- branches/CROSS_COMPILATION/vex-cross-compilation.patch 2008-07-09 07:39:09 UTC (rev 8405)
+++ branches/CROSS_COMPILATION/vex-cross-compilation.patch 2008-07-09 07:55:38 UTC (rev 8406)
@@ -1,6 +1,6 @@
Index: VEX/auxprogs/genoffsets.c
===================================================================
---- VEX/auxprogs/genoffsets.c (revision 1849)
+--- VEX/auxprogs/genoffsets.c (revision 1857)
+++ VEX/auxprogs/genoffsets.c (working copy)
@@ -46,7 +46,9 @@
@@ -13,7 +13,7 @@
#include "../pub/libvex_basictypes.h"
#include "../pub/libvex_guest_x86.h"
-@@ -54,184 +56,187 @@
+@@ -54,184 +56,193 @@
#include "../pub/libvex_guest_ppc32.h"
#include "../pub/libvex_guest_ppc64.h"
@@ -162,6 +162,9 @@
offsetof(VexGuestPPC32State,guest_GPR0));
- printf("#define OFFSET_ppc32_GPR2 %3d\n",
++ DEFINE(OFFSET_ppc32_GPR1,
++ offsetof(VexGuestPPC32State,guest_GPR1));
++
+ DEFINE(OFFSET_ppc32_GPR2,
offsetof(VexGuestPPC32State,guest_GPR2));
@@ -213,6 +216,9 @@
offsetof(VexGuestPPC64State,guest_GPR0));
- printf("#define OFFSET_ppc64_GPR2 %4d\n",
++ DEFINE(OFFSET_ppc64_GPR1,
++ offsetof(VexGuestPPC64State,guest_GPR1));
++
+ DEFINE(OFFSET_ppc64_GPR2,
offsetof(VexGuestPPC64State,guest_GPR2));
@@ -259,7 +265,7 @@
printf("\n");
Index: VEX/Makefile
===================================================================
---- VEX/Makefile (revision 1849)
+--- VEX/Makefile (revision 1857)
+++ VEX/Makefile (working copy)
@@ -178,9 +178,10 @@
@cat priv/main/vex_svnversion.h
|
|
From: Julian S. <js...@ac...> - 2008-07-09 07:55:24
|
On Wednesday 09 July 2008 09:47, Tom Hughes wrote: > In message <200...@gm...> > > Bart Van Assche <bar...@gm...> wrote: > > The GLib library is a general-purpose utility library which provides a.o. > > memory management functions. This library is used by almost all GNOME and > > KDE applications. Intercepting the GLib memory allocation functions is > > necessary for correct operation of the memcheck, massif, helgrind, drd > > and exp-omega Valgrind tools. The patch below makes Valgrind recognize > > the GLib memory management functions. Please review the patch below. > > Do the GLib allocation routines not wind up calling the C library ones > and hence get caught that way? Indeed; we've been shipping memcheck for N years now (5+ ?) and I don't recall anybody telling us we were not intercepting memory allocation/ free functions in glib. I would think memcheck would be unusable on KDE and Gnome applications due to high noise level if that were really the case. Are you sure? J |
|
From: Tom H. <to...@co...> - 2008-07-09 07:47:21
|
In message <200...@gm...>
Bart Van Assche <bar...@gm...> wrote:
> The GLib library is a general-purpose utility library which provides a.o.
> memory management functions. This library is used by almost all GNOME and KDE
> applications. Intercepting the GLib memory allocation functions is necessary
> for correct operation of the memcheck, massif, helgrind, drd and exp-omega
> Valgrind tools. The patch below makes Valgrind recognize the GLib memory
> management functions. Please review the patch below.
Do the GLib allocation routines not wind up calling the C library ones
and hence get caught that way?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2008-07-09 07:39:12
|
Author: bart
Date: 2008-07-09 08:39:09 +0100 (Wed, 09 Jul 2008)
New Revision: 8405
Log:
Enabled support for the sched_setparam() system call on the amd64, ppc32 and ppc64 platforms (was already enabled on x86).
Modified:
trunk/coregrind/m_syswrap/syswrap-amd64-linux.c
trunk/coregrind/m_syswrap/syswrap-ppc32-linux.c
trunk/coregrind/m_syswrap/syswrap-ppc64-linux.c
Modified: trunk/coregrind/m_syswrap/syswrap-amd64-linux.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-amd64-linux.c 2008-07-08 20:46:48 UTC (rev 8404)
+++ trunk/coregrind/m_syswrap/syswrap-amd64-linux.c 2008-07-09 07:39:09 UTC (rev 8405)
@@ -1216,7 +1216,7 @@
GENX_(__NR_getpriority, sys_getpriority), // 140
GENX_(__NR_setpriority, sys_setpriority), // 141
-//zz LINXY(__NR_sched_setparam, sys_sched_setparam), // 142
+ LINXY(__NR_sched_setparam, sys_sched_setparam), // 142
LINXY(__NR_sched_getparam, sys_sched_getparam), // 143
LINX_(__NR_sched_setscheduler, sys_sched_setscheduler), // 144
Modified: trunk/coregrind/m_syswrap/syswrap-ppc32-linux.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-ppc32-linux.c 2008-07-08 20:46:48 UTC (rev 8404)
+++ trunk/coregrind/m_syswrap/syswrap-ppc32-linux.c 2008-07-09 07:39:09 UTC (rev 8405)
@@ -1655,7 +1655,7 @@
GENX_(__NR_munlock, sys_munlock), // 151
GENX_(__NR_mlockall, sys_mlockall), // 152
LINX_(__NR_munlockall, sys_munlockall), // 153
-//.. LINXY(__NR_sched_setparam, sys_sched_setparam), // 154
+ LINXY(__NR_sched_setparam, sys_sched_setparam), // 154
//..
LINXY(__NR_sched_getparam, sys_sched_getparam), // 155
LINX_(__NR_sched_setscheduler, sys_sched_setscheduler), // 156
Modified: trunk/coregrind/m_syswrap/syswrap-ppc64-linux.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-ppc64-linux.c 2008-07-08 20:46:48 UTC (rev 8404)
+++ trunk/coregrind/m_syswrap/syswrap-ppc64-linux.c 2008-07-09 07:39:09 UTC (rev 8405)
@@ -1324,7 +1324,7 @@
GENX_(__NR_munlock, sys_munlock), // 151
GENX_(__NR_mlockall, sys_mlockall), // 152
LINX_(__NR_munlockall, sys_munlockall), // 153
-// _____(__NR_sched_setparam, sys_sched_setparam), // 154
+ LINXY(__NR_sched_setparam, sys_sched_setparam), // 154
LINXY(__NR_sched_getparam, sys_sched_getparam), // 155
LINX_(__NR_sched_setscheduler, sys_sched_setscheduler), // 156
|