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: John R.
|
Julian Seward wrote: > I've been testing the 3.2 branch on OpenSUSE 10.2 (kernel 2.6.18.2, glibc-2.5) > and mostly it works pretty well. However, it can't run bash: ... > sys_mmap ( 0xFFFDE000, 69636, 5, 2050, 3, 0 ) --> [pre-fail] Failure(0xC) > sys_mmap ( 0xFFFD9000, 90236, 5, 2050, 3, 0 ) --> [pre-fail] Failure(0xC) > sys_mmap ( 0xFFFA1000, 319664, 5, 2050, 3, 0 ) --> [pre-fail] Failure(0xC) > > This strikes me as strange because the addresses (0xFFFDE000 etc) are almost > at the end of 4G. It's also strange because other programs, including large > ones, run just fine, and these .so's are mapped quite low, as is normal. It's also strange because the file offset (6th argument) is 0 from the same fd 3 (5th argument) but with three different sizes (2nd argument). Is this three successive attempts at a single mapping, or serial execution of a parallel mapping? > > Is it legitimate for ld.so to attempt to map anything to the 0xFFFDxxxx > areas? Without MAP_FIXED in the 4th argument, then a non-zero 1st argument is just a preference which the kernel may choose to ignore, and should ignore if outside the apparent 2G user space. ld-linux sets such a preference for a pre-linked .so. This can be done by mmap(phdr[0].p_vaddr, ... which "just happens" to be what ET_EXEC also requires. Doing a plain 'cat /proc/self/maps' shows that the stack is placed > just below the 2G boundary and there is nothing above, which makes me > think this kernel is running in a 2G+2G configuration. ... I have encountered similar symptoms on x86 without valgrind and with earlier versions of kernel and glibc and my code. The sys_mmap ( 0xFFFDE000, 69636, 5, 2050,,) with a first argument that is close to 4G suggests a mixup with respect to pre-linking and/or -fPIE (position-independent executable) and/or policy to randomize address space. The address was formed by subtracting a size from 0. 2050==0x802 ==> (MAP_EXEC | MAP_DENYWRITE) which is the usual protection for shared .text, and does not include MAP_FIXED (0x10). This also is suspicious, because without MAP_FIXED the kernel gives no guarantee of relative position among the 3 PT_LOAD from the same file, which /bin/ld [or the creator of that file] probably expected. And if MAP_FIXED _is_ present, then there should have been a prior "reservation" mmap() of size roundup(69636) + roundup(90236) + roundup(319664) in order for ld-linux to preserve relative position. Run under strace. Note which file corresponds to fd 3, and run "readelf --segments" on that file. There should be 3 PT_LOAD with sizes that match the second argument to mmap(), unless the 6th argument being 0 is telling us that these were successive attempts at a single mapping, instead of serialized implementation of parallel mapping. If the .p_vaddr of the lowest-addressed PT_LOAD is not 0, then pre-linking definitely is involved. Un-prelink (and/or un-PIE, and/or un-set random assignment policy) and try again. If .p_vaddr is 0, then consult the code to ld-linux. Also check the recent history of fs/binfmt_elf.c and related vma code in linux kernel. -- |
|
From: Julian S. <js...@ac...> - 2006-12-31 20:08:27
|
I've been testing the 3.2 branch on OpenSUSE 10.2 (kernel 2.6.18.2, glibc-2.5) and mostly it works pretty well. However, it can't run bash: sewardj@imac:~/Vg32BRANCH/branch32$ ./Inst/bin/valgrind /bin/bash [... preamble ...] ERROR: ld.so: object '/home/sewardj/Vg32BRANCH/branch32/Inst/lib/valgrind/ppc32-linux/vgpreload_core.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object '/home/sewardj/Vg32BRANCH/branch32/Inst/lib/valgrind/ppc32-linux/vgpreload_memcheck.so' from LD_PRELOAD cannot be preloaded: ignored. /bin/bash: error while loading shared libraries: libreadline.so.5: failed to map segment from shared object: Cannot allocate memory V starts up OK and loads /bin/bash and its ELF interpreter as usual, and starts it. However, at some point ld.so is doing some fixed mmaps for the 3 .so's mentioned above, and these are failing: sys_mmap ( 0xFFFDE000, 69636, 5, 2050, 3, 0 ) --> [pre-fail] Failure(0xC) sys_mmap ( 0xFFFD9000, 90236, 5, 2050, 3, 0 ) --> [pre-fail] Failure(0xC) sys_mmap ( 0xFFFA1000, 319664, 5, 2050, 3, 0 ) --> [pre-fail] Failure(0xC) This strikes me as strange because the addresses (0xFFFDE000 etc) are almost at the end of 4G. It's also strange because other programs, including large ones, run just fine, and these .so's are mapped quite low, as is normal. Is it legitimate for ld.so to attempt to map anything to the 0xFFFDxxxx areas? Doing a plain 'cat /proc/self/maps' shows that the stack is placed just below the 2G boundary and there is nothing above, which makes me think this kernel is running in a 2G+2G configuration. This machine is an old G3, if that's relevant: processor : 0 cpu : 740/750 temperature : 31-33 C (uncalibrated) clock : 400.000000MHz revision : 131.0 (pvr 0008 8300) bogomips : 49.79 timebase : 24967326 platform : PowerMac machine : PowerMac2,1 motherboard : PowerMac2,1 MacRISC2 MacRISC Power Macintosh detected as : 66 (iMac FireWire) pmac flags : 00000014 L2 cache : 512K unified pmac-generation : NewWorld I tested some other architecture variations and cannot reproduce it on any other setup: SuSE 10.2 on x86 and amd64 SuSE 10.1 on ppc32 Any ideas what might be going on? J |
|
From: <sv...@va...> - 2006-12-31 19:40:58
|
Author: sewardj
Date: 2006-12-31 19:40:56 +0000 (Sun, 31 Dec 2006)
New Revision: 6470
Log:
Merge r6469 (Provide a replacement for mempcpy.)
Modified:
branches/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.c
Modified: branches/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.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
--- branches/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.c 2006-12-31 =
18:55:56 UTC (rev 6469)
+++ branches/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.c 2006-12-31 =
19:40:56 UTC (rev 6470)
@@ -562,6 +562,42 @@
GLIBC25___STRCPY_CHK(m_libc_so_star, __strcpy_chk)
=20
=20
+/* mempcpy */
+#define GLIBC25_MEMPCPY(soname, fnname) \
+ void* VG_REPLACE_FUNCTION_ZU(soname,fnname) \
+ ( void *dst, const void *src, SizeT len ); \
+ void* VG_REPLACE_FUNCTION_ZU(soname,fnname) \
+ ( void *dst, const void *src, SizeT len ) \
+ { \
+ register char *d; \
+ register char *s; \
+ SizeT len_saved =3D len; \
+ \
+ if (len =3D=3D 0) \
+ return dst; \
+ \
+ if (is_overlap(dst, src, len, len)) \
+ complain3("mempcpy", dst, src, len); \
+ \
+ if ( dst > src ) { \
+ d =3D (char *)dst + len - 1; \
+ s =3D (char *)src + len - 1; \
+ while ( len-- ) { \
+ *d-- =3D *s--; \
+ } \
+ } else if ( dst < src ) { \
+ d =3D (char *)dst; \
+ s =3D (char *)src; \
+ while ( len-- ) { \
+ *d++ =3D *s++; \
+ } \
+ } \
+ return (void*)( ((char*)dst) + len_saved ); \
+ }
+
+GLIBC25_MEMPCPY(m_libc_so_star, mempcpy)
+
+
/*--------------------------------------------------------------------*/
/*--- end ---*/
/*--------------------------------------------------------------------*/
|
|
From: Julian S. <js...@ac...> - 2006-12-31 19:18:47
|
> can be easily intercepted (via VG_(needs_malloc_replacement)(...)). But is > it normal that via this mechanism malloc() calls performed by /lib/ld- > linux.so are not intercepted ? Unfortunately there will be an initial section of the program for which these intercepts do not apply. The replacement functions live in drd/vgpreload_drd-<arch>-linux.so (by analogy with memcheck's ones). At startup, V loads the executable into memory - that is, maps its text and data sections, and those of its ELF interpreter, but that's all. It then starts running the ELF interpreter on the simulated CPU, and that takes care of loading/linking all the other .so's. V doesn't have any further involvement, which is nice, since ELF linking/loading is a nightmare of complexity. Except .. the preload .so's, drd/vgpreload_drd-<arch>-linux.so et al. These need to be incorporated into the memory image of the client program. V can't do that directly, so what it does is to add the name of this .so to the LD_PRELOAD env var handed to the client. This causes its dynamic linker to load in the preload. As soon as the preload is loaded (via an mmap syscall) V reads its symbol tables, notes the malloc replacements, and routes all subsequent malloc/free calls to them. But by then it may be that ld.so has already called malloc/free. I think that explains what you are seeing. I hope that makes sense. Loading the executable and getting started is one of the most hairy parts of the system. Does the lack of intercepts right from the start cause a problem for drd? J |
|
From: Tom H. <to...@co...> - 2006-12-31 19:03:40
|
In message <e2e...@ma...>
"Bart Van Assche" <bar...@gm...> wrote:
> Thanks for the URL. Ulrich Drepper has a paper about DSO's (dynamic shared
> objects) that explains the GOT (global offset table) and the PLT (procedure
> linkage table). Apparently the data races that were detected and that I
> would like to suppress are caused by lazy relocation of symbols in shared
> libraries. Each time a function in a shared library is called, this happens
> via an indirect jump in the GOT (at least on IA-32). The first time a shared
> library function is called, the corresponding entry in the GOT is filled in.
> There is one GOT entry per shared library function, and these entries are
> shared over threads. Does anyone have a suggestion on how I can find out the
> address range of all GOT entries ? Then I can easily suppress data races
> triggered on the GOT.
You mean PLT I think, not GOT - the GOT is for global data access and
the PLT is for function calls.
The ELF reader in m_debuginfo already detects the PLT and GOT so you
would need to make it record that information somewhere I guess.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: John R.
|
Bart Van Assche wrote: > There is one GOT entry per shared library function, and these entries are > shared over threads. Does anyone have a suggestion on how I can find out > the address range of all GOT entries ? Then I can easily suppress data > races triggered on the GOT. Such entries are marked with a relocation type such as R_386_JUMP_SLOT in a table described by DT_JMPREL and DT_PLTRELSZ, which can be found in a PT_DYNAMIC segment. Peruse the output from an example such as: readelf --headers --dynamic --reloc /bin/date and refer to #include <elf.h> for declarations. There can be adventure here. Both ld-linux.so and prelink may relocate various items at varying times, and in the past the conventions have changed from one release of glibc to another. -- |
|
From: <sv...@va...> - 2006-12-31 18:56:00
|
Author: sewardj
Date: 2006-12-31 18:55:56 +0000 (Sun, 31 Dec 2006)
New Revision: 6469
Log:
Provide a replacement for mempcpy.
Modified:
trunk/memcheck/mc_replace_strmem.c
Modified: trunk/memcheck/mc_replace_strmem.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_replace_strmem.c 2006-12-31 15:33:12 UTC (rev 6468)
+++ trunk/memcheck/mc_replace_strmem.c 2006-12-31 18:55:56 UTC (rev 6469)
@@ -558,6 +558,42 @@
GLIBC25___STRCPY_CHK(m_libc_soname, __strcpy_chk)
=20
=20
+/* mempcpy */
+#define GLIBC25_MEMPCPY(soname, fnname) \
+ void* VG_REPLACE_FUNCTION_ZU(soname,fnname) \
+ ( void *dst, const void *src, SizeT len ); \
+ void* VG_REPLACE_FUNCTION_ZU(soname,fnname) \
+ ( void *dst, const void *src, SizeT len ) \
+ { \
+ register char *d; \
+ register char *s; \
+ SizeT len_saved =3D len; \
+ \
+ if (len =3D=3D 0) \
+ return dst; \
+ \
+ if (is_overlap(dst, src, len, len)) \
+ RECORD_OVERLAP_ERROR("mempcpy", dst, src, len); \
+ \
+ if ( dst > src ) { \
+ d =3D (char *)dst + len - 1; \
+ s =3D (char *)src + len - 1; \
+ while ( len-- ) { \
+ *d-- =3D *s--; \
+ } \
+ } else if ( dst < src ) { \
+ d =3D (char *)dst; \
+ s =3D (char *)src; \
+ while ( len-- ) { \
+ *d++ =3D *s++; \
+ } \
+ } \
+ return (void*)( ((char*)dst) + len_saved ); \
+ }
+
+GLIBC25_MEMPCPY(m_libc_soname, mempcpy)
+
+
/*------------------------------------------------------------*/
/*--- AIX stuff only after this point ---*/
/*------------------------------------------------------------*/
|
|
From: Bart V. A. <bar...@gm...> - 2006-12-31 18:14:33
|
Valgrind's core has the nice feature that dynamic memory allocation calls
can be easily intercepted (via VG_(needs_malloc_replacement)(...)). But is
it normal that via this mechanism malloc() calls performed by /lib/ld-
linux.so are not intercepted ?
Consider the following program:
#include <iostream>
#include <mcheck.h>
#include <pthread.h>
static void init() __attribute__((constructor));
static void init()
{
putenv("MALLOC_TRACE=new_delete-mtrace.txt");
mtrace();
}
void* thread_func(void*)
{
delete new int;
return 0;
}
int main(int argc, char** argv)
{
pthread_t tid;
std::cout << "main, before pthread_create()\n" << std::flush;
pthread_create(&tid, 0, thread_func, 0);
std::cout << "main, after pthread_create()\n" << std::flush;
delete new int;
std::cout << "main, before pthread_join()\n" << std::flush;
pthread_join(tid, 0);
std::cout << "main, after pthread_join()\n" << std::flush;
return 0;
}
This program produces the following output:
$ cat new_delete-mtrace.txt
= Start
@ /lib/ld-linux.so.2:[0xb7fe33b8] + 0x804a4b8 0x88
@ /usr/local/lib/libstdc++.so.6:(_Znwj+0x27)[0xb7f76f47] + 0x804a548 0x4
@ /usr/local/lib/libstdc++.so.6:(_ZdlPv+0x21)[0xb7f757e1] - 0x804a548
@ /usr/local/lib/libstdc++.so.6:(_Znwj+0x27)[0xb7f76f47] + 0x804a548 0x4
@ /usr/local/lib/libstdc++.so.6:(_ZdlPv+0x21)[0xb7f757e1] - 0x804a548
@ /lib/libc.so.6:(clearenv+0x7e)[0xb7da1b6e] - 0x804a008
Is it normal that Valgrind's malloc() replacement is not triggered for the
first allocation from /lib/ld-linux.so.2 ?
Bart.
|
|
From: Bart V. A. <bar...@gm...> - 2006-12-31 17:49:08
|
On 12/29/06, John Reiser <jr...@bi...> wrote: > > Bart Van Assche wrote: > > Does anyone know where I can find comprehensive documentation of how ELF > > shared library symbols are resolved at runtime ? > > The source code to glibc may well be the only place that is detailed > enough > to answer questions that are necessary to resolve issues regarding races. > The ELF section of http://people.redhat.com/drepper/ points to some > papers > that may help. > Thanks for the URL. Ulrich Drepper has a paper about DSO's (dynamic shared objects) that explains the GOT (global offset table) and the PLT (procedure linkage table). Apparently the data races that were detected and that I would like to suppress are caused by lazy relocation of symbols in shared libraries. Each time a function in a shared library is called, this happens via an indirect jump in the GOT (at least on IA-32). The first time a shared library function is called, the corresponding entry in the GOT is filled in. There is one GOT entry per shared library function, and these entries are shared over threads. Does anyone have a suggestion on how I can find out the address range of all GOT entries ? Then I can easily suppress data races triggered on the GOT. Bart. |
|
From: <sv...@va...> - 2006-12-31 15:33:14
|
Author: sewardj
Date: 2006-12-31 15:33:12 +0000 (Sun, 31 Dec 2006)
New Revision: 6468
Log:
Merge r6467 (Apparently needed on Red Hat 7.3.)
Modified:
branches/VALGRIND_3_2_BRANCH/xfree-4.supp
Modified: branches/VALGRIND_3_2_BRANCH/xfree-4.supp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/VALGRIND_3_2_BRANCH/xfree-4.supp 2006-12-31 15:26:48 UTC (re=
v 6467)
+++ branches/VALGRIND_3_2_BRANCH/xfree-4.supp 2006-12-31 15:33:12 UTC (re=
v 6468)
@@ -100,6 +100,14 @@
}
=20
{
+ libX11.so.6.2/libX11.so.6.2/libXaw.so.7.0(Addr4)
+ Memcheck:Addr4
+ obj:/usr/X11R6/lib*/libX11.so.6.2
+ obj:/usr/X11R6/lib*/libX11.so.6.2
+ obj:/usr/X11R6/lib*/libXaw.so.7.0
+}
+
+{
libX11.so.6.2/libXaw.so.7.0/libXaw.so.7.0(Cond)
Memcheck:Cond
obj:/usr/X11R6/lib*/libX11.so.6.2
|
|
From: <sv...@va...> - 2006-12-31 15:26:53
|
Author: sewardj
Date: 2006-12-31 15:26:48 +0000 (Sun, 31 Dec 2006)
New Revision: 6467
Log:
Apparently needed on Red Hat 7.3.
Modified:
trunk/xfree-4.supp
Modified: trunk/xfree-4.supp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/xfree-4.supp 2006-12-31 02:32:00 UTC (rev 6466)
+++ trunk/xfree-4.supp 2006-12-31 15:26:48 UTC (rev 6467)
@@ -99,6 +99,14 @@
}
=20
{
+ libX11.so.6.2/libX11.so.6.2/libXaw.so.7.0(Addr4)
+ Memcheck:Addr4
+ obj:/usr/X11R6/lib*/libX11.so.6.2
+ obj:/usr/X11R6/lib*/libX11.so.6.2
+ obj:/usr/X11R6/lib*/libXaw.so.7.0
+}
+
+{
libX11.so.6.2/libXaw.so.7.0/libXaw.so.7.0(Cond)
Memcheck:Cond
obj:/usr/X11R6/lib*/libX11.so.6.2
|
|
From: Bart V. A. <bar...@gm...> - 2006-12-31 09:48:21
|
On 12/29/06, Josef Weidendorfer <Jos...@gm...> wrote:
>
> Why is this a race at all?
> The accesses in thread 1 are before main() is called, and only there
> is the 2nd thread created, which does the other accesses.
>
> Josef
>
I don't know why, but some of the call stacks printed by Valgrind's core are
wrong. The load reported by drd as conflicting happened after
pthread_create(), not before main(). This is made clear by some tracing I
added to the test program:
$ cat drd/tests/new_delete.cpp
#include <iostream>
#include <pthread.h>
void* thread_func(void*)
{
delete new int;
return 0;
}
int main(int argc, char** argv)
{
pthread_t tid;
std::cout << "main, before pthread_create()\n" << std::flush;
pthread_create(&tid, 0, thread_func, 0);
std::cout << "main, after pthread_create()\n" << std::flush;
delete new int;
std::cout << "main, before pthread_join()\n" << std::flush;
pthread_join(tid, 0);
std::cout << "main, after pthread_join()\n" << std::flush;
return 0;
}
$ VALGRIND_LIB=.in_place coregrind/valgrind --tool=drd
--trace-address=$((0x08049BE4)) drd/tests/new_delete
==5994== drd, a data race detector.
==5994== Copyright (C) 2006, and GNU GPL'd, by Bart Van Assche.
THIS SOFTWARE IS A PROTOTYPE, AND IS NOT YET RELEASED
==5994== Using LibVEX rev 1680, a library for dynamic binary translation.
==5994== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==5994== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation
framework.
==5994== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==5994== For more details, rerun with: -v
==5994==
==5994== load 0x8049BE4 size 4 thread 1
==5994== at 0x400A613: _dl_relocate_object (in /lib/ld-2.4.so)
==5994== by 0x4004777: dl_main (in /lib/ld-2.4.so)
==5994== by 0x40131CA: _dl_sysdep_start (in /lib/ld-2.4.so)
==5994== by 0x40011F3: _dl_start (in /lib/ld-2.4.so)
==5994== by 0x4000846: (within /lib/ld-2.4.so)
==5994== store 0x8049BE4 size 4 thread 1
==5994== at 0x400A613: _dl_relocate_object (in /lib/ld-2.4.so)
==5994== by 0x4004777: dl_main (in /lib/ld-2.4.so)
==5994== by 0x40131CA: _dl_sysdep_start (in /lib/ld-2.4.so)
==5994== by 0x40011F3: _dl_start (in /lib/ld-2.4.so)
==5994== by 0x4000846: (within /lib/ld-2.4.so)
main, before pthread_create()
==5994== load 0x8049BE4 size 4 thread 2
==5994== at 0x8048654: (within
/home/bart/software/valgrind-svn/drd/tests/new_delete)
==5994== by 0x4022E1C: vg_thread_wrapper (drd_preloaded.c:133)
==5994== by 0x404434A: start_thread (in /lib/libpthread-2.4.so)
==5994== by 0x421C65D: clone (in /lib/libc-2.4.so)
==5994== store 0x8049BE4 size 4 thread 2
==5994== at 0x400D274: _dl_fixup (in /lib/ld-2.4.so)
==5994== by 0x401262F: _dl_runtime_resolve (in /lib/ld-2.4.so)
==5994== by 0x4022E1C: vg_thread_wrapper (drd_preloaded.c:133)
==5994== by 0x404434A: start_thread (in /lib/libpthread-2.4.so)
==5994== by 0x421C65D: clone (in /lib/libc-2.4.so)
main, after pthread_create()
==5994== load 0x8049BE4 size 4 thread 1
==5994== at 0x8048654: (within
/home/bart/software/valgrind-svn/drd/tests/new_delete)
==5994== by 0x417487B: (below main) (in /lib/libc-2.4.so)
==5994== Conflicting load by thread 1 at 0x08049BE4 size 4
==5994== at 0x8048654: (within
/home/bart/software/valgrind-svn/drd/tests/new_delete)
==5994== by 0x417487B: (below main) (in /lib/libc-2.4.so)
==5994== Allocation context: drd/tests/new_delete, NONE:Data
==5994== Other segment start (thread 2)
==5994== (thread finished, call stack no longer available)
==5994== Other segment end (thread 2)
==5994== (thread finished, call stack no longer available)
==5994==
==5994== Conflicting load by thread 1 at 0x08049BF0 size 4
==5994== at 0x8048684: (within
/home/bart/software/valgrind-svn/drd/tests/new_delete)
==5994== by 0x417487B: (below main) (in /lib/libc-2.4.so)
==5994== Allocation context: drd/tests/new_delete, NONE:Data
==5994== Other segment start (thread 2)
==5994== (thread finished, call stack no longer available)
==5994== Other segment end (thread 2)
==5994== (thread finished, call stack no longer available)
main, before pthread_join()
==5994==
==5994== Conflicting load by thread 1 at 0x0401B310 size 4
==5994== at 0x40094E8: _dl_lookup_symbol_x (in /lib/ld-2.4.so)
==5994== by 0x400D24C: _dl_fixup (in /lib/ld-2.4.so)
==5994== by 0x401262F: _dl_runtime_resolve (in /lib/ld-2.4.so)
==5994== by 0x417487B: (below main) (in /lib/libc-2.4.so)
==5994== Allocation context: _rtld_local (offset 752, size 1524) in /lib/ld-
2.4.so, ld-linux.so.2:Data
==5994== Other segment start (thread 2)
==5994== (thread finished, call stack no longer available)
==5994== Other segment end (thread 2)
==5994== (thread finished, call stack no longer available)
==5994==
==5994== Conflicting store by thread 1 at 0x0401B310 size 4
==5994== at 0x40094E8: _dl_lookup_symbol_x (in /lib/ld-2.4.so)
==5994== by 0x400D24C: _dl_fixup (in /lib/ld-2.4.so)
==5994== by 0x401262F: _dl_runtime_resolve (in /lib/ld-2.4.so)
==5994== by 0x417487B: (below main) (in /lib/libc-2.4.so)
==5994== Allocation context: _rtld_local (offset 752, size 1524) in /lib/ld-
2.4.so, ld-linux.so.2:Data
==5994== Other segment start (thread 2)
==5994== (thread finished, call stack no longer available)
==5994== Other segment end (thread 2)
==5994== (thread finished, call stack no longer available)
==5994==
==5994== Conflicting store by thread 1 at 0x0401E4AD size 1
==5994== at 0x40096D9: _dl_lookup_symbol_x (in /lib/ld-2.4.so)
==5994== by 0x400D24C: _dl_fixup (in /lib/ld-2.4.so)
==5994== by 0x401262F: _dl_runtime_resolve (in /lib/ld-2.4.so)
==5994== by 0x417487B: (below main) (in /lib/libc-2.4.so)
==5994== Allocation context: heap
==5994== Other segment start (thread 2)
==5994== (thread finished, call stack no longer available)
==5994== Other segment end (thread 2)
==5994== (thread finished, call stack no longer available)
==5994==
==5994== Conflicting store by thread 1 at 0x04A81D9C size 4
==5994== at 0x40455ED: pthread_join (in /lib/libpthread-2.4.so)
==5994== by 0x4021F6E: pthread_join (drd_preloaded.c:220)
==5994== by 0x80488AE: main (new_delete.cpp:18)
==5994== Allocation context: stack of thread 2, offset -612
==5994== Other segment start (thread 2)
==5994== (thread finished, call stack no longer available)
==5994== Other segment end (thread 2)
==5994== (thread finished, call stack no longer available)
==5994==
==5994== Conflicting load by thread 1 at 0x04A81C04 size 4
==5994== at 0x40442A8: __free_tcb (in /lib/libpthread-2.4.so)
==5994== by 0x4045670: pthread_join (in /lib/libpthread-2.4.so)
==5994== by 0x4021F6E: pthread_join (drd_preloaded.c:220)
==5994== by 0x80488AE: main (new_delete.cpp:18)
==5994== Allocation context: stack of thread 2, offset -1020
==5994== Other segment start (thread 2)
==5994== (thread finished, call stack no longer available)
==5994== Other segment end (thread 2)
==5994== (thread finished, call stack no longer available)
==5994==
==5994== Conflicting store by thread 1 at 0x04A81C04 size 4
==5994== at 0x40442A8: __free_tcb (in /lib/libpthread-2.4.so)
==5994== by 0x4045670: pthread_join (in /lib/libpthread-2.4.so)
==5994== by 0x4021F6E: pthread_join (drd_preloaded.c:220)
==5994== by 0x80488AE: main (new_delete.cpp:18)
==5994== Allocation context: stack of thread 2, offset -1020
==5994== Other segment start (thread 2)
==5994== (thread finished, call stack no longer available)
==5994== Other segment end (thread 2)
==5994== (thread finished, call stack no longer available)
main, after pthread_join()
==5994==
==5994== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 0 from 0)
Bart.
|
|
From: Bart V. A. <bar...@gm...> - 2006-12-31 09:02:50
|
On 12/30/06, Nicholas Nethercote <nj...@cs...> wrote: > > On Sat, 30 Dec 2006, Bart Van Assche wrote: > > > A new drd version is available at > > > http://home.euphonynet.be/bvassche/valgrind/valgrind-6458-drd-2006-12-30.patch.gz > . > > > > * attempted to write a suppression file that suppresses some data races > > present in ld.so / libc / libstd++ / libpthread (drd/default.supp). I > > learned that suppressing data races by callstack probably won't be too > > coarse for the drd tool: several call stacks have to be included for > > accesses to the same location, and the danger exists that some of these > call > > stacks suppress data races that should be reported to the user. > > Did you mean "probably will be too coarse"? Yes. > Summarized: although one important algorithm change is still needed > (segment > > merging), the tool is already useful for finding out which data races > > happened and why. But it will be a challenge to suppress all intended > data > > races (in ld.so, glibc, libstdc++ and libpthread.so). > > Good! I think data race detectors generally have a lower signal-to-noise > ratio than eg. Memcheck, but it seems people will still be interested. > > Nick > My own goal is still to make drd meet or exceed Intel's VTune. The Thread Checker included in VTune doesn't report any false positives as far as I know. Bart. |
|
From: <js...@ac...> - 2006-12-31 06:07:38
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-12-31 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 == 217 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-31 05:09:53
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-12-31 04:30:01 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) ================================================= == Results from 24 hours ago == ================================================= 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, 2 stdout failures, 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) none/tests/pth_detached (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Dec 31 04:51:49 2006 --- new.short Sun Dec 31 05:10:04 2006 *************** *** 10,12 **** ! == 250 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) --- 10,12 ---- ! == 250 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (stderr) *************** *** 18,20 **** none/tests/mremap2 (stdout) - none/tests/pth_detached (stdout) --- 18,19 ---- |
|
From: Tom H. <to...@co...> - 2006-12-31 03:59:34
|
Nightly build on dunsmere ( athlon, Fedora Core 6 ) started at 2006-12-31 03:30:07 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 == 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) |
|
From: Tom H. <th...@cy...> - 2006-12-31 03:24:19
|
Nightly build on dellow ( x86_64, Fedora Core 6 ) started at 2006-12-31 03:10:09 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 == 281 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) |
|
From: <sv...@va...> - 2006-12-31 02:32:02
|
Author: sewardj
Date: 2006-12-31 02:32:00 +0000 (Sun, 31 Dec 2006)
New Revision: 6466
Log:
Update
Modified:
trunk/docs/internals/3_2_BUGSTATUS.txt
Modified: trunk/docs/internals/3_2_BUGSTATUS.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/docs/internals/3_2_BUGSTATUS.txt 2006-12-31 02:30:16 UTC (rev 6=
465)
+++ trunk/docs/internals/3_2_BUGSTATUS.txt 2006-12-31 02:32:00 UTC (rev 6=
466)
@@ -87,8 +87,7 @@
=20
vx1679 vx1695 32 135421 x86->IR: unhandled Grp5(R) case 6 [ok]
=20
-vx1675 vx1697 32 n-i-bz x86 COPY-CondP (Espindola #2, users, Nov =
1)
- (NEEDS VERIFICATION; regtest =3D espindol=
a2.c)
+vx1675 vx1697 32 n-i-bz x86 COPY-CondP (Espindola #2, dev, Nov 1)
=20
vx1677 vx1704 32 n-i-bz IR comments
=20
@@ -130,7 +129,9 @@
=20
vx1669 vx1700 32 n-i-bz ppc64 be imm64 improvement (hdefs.c only)
=20
-pending pending 32 136300 support 64K pages on ppc64-linux
+r6459/61
+ r6457/8/60
+ 32 136300 support 64K pages on ppc64-linux
=3D=3D 139124
=20
r6404/5 r6431 32 n-i-bz fix ppc insn set tests for gcc >=3D 4.1
@@ -169,7 +170,9 @@
Test/make run cleanly on SuSE 10.2 x86/amd64/ppc32 and FC6 ditto
Last update was 25 Dec 06
=20
+r6462/3 r6464/5 32 n-i-bz glibc-2.5 support
=20
+
------- Bugs reported and fixed in 3.2.0 ------
=20
SSE3 commits: vx1635,1636, v5997
|
|
From: <sv...@va...> - 2006-12-31 02:30:19
|
Author: sewardj Date: 2006-12-31 02:30:16 +0000 (Sun, 31 Dec 2006) New Revision: 6465 Log: Merge r6463 (Redo a suppression in X.org style.) Modified: branches/VALGRIND_3_2_BRANCH/xfree-4.supp Modified: branches/VALGRIND_3_2_BRANCH/xfree-4.supp =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- branches/VALGRIND_3_2_BRANCH/xfree-4.supp 2006-12-31 02:26:57 UTC (re= v 6464) +++ branches/VALGRIND_3_2_BRANCH/xfree-4.supp 2006-12-31 02:30:16 UTC (re= v 6465) @@ -213,6 +213,12 @@ obj:/usr/X11*/lib*/libXft.so* obj:/usr/X11*/lib*/libXft.so* } +{ + XftFontOpenInfo-umod-127-strangeness-a-la-xorg + Memcheck:Value8 + obj:/usr/lib*/libXft.so* + obj:/usr/lib*/libXft.so* +} =20 { More X padding stuff |
|
From: <sv...@va...> - 2006-12-31 02:26:59
|
Author: sewardj
Date: 2006-12-31 02:26:57 +0000 (Sun, 31 Dec 2006)
New Revision: 6464
Log:
Merge r6462 (Intercept/replace glibc-2.5's __strcpy_chk function)
Modified:
branches/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.c
Modified: branches/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.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
--- branches/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.c 2006-12-31 =
01:05:19 UTC (rev 6463)
+++ branches/VALGRIND_3_2_BRANCH/memcheck/mc_replace_strmem.c 2006-12-31 =
02:26:57 UTC (rev 6464)
@@ -536,6 +536,32 @@
GLIBC232_RAWMEMCHR(m_libc_so_star, rawmemchr)
=20
=20
+/* glibc variant of strcpy that checks the dest is big enough. */
+#define GLIBC25___STRCPY_CHK(soname,fnname) \
+ char* VG_REPLACE_FUNCTION_ZU(soname,fnname) \
+ (char* dst, const char* src, SizeT len); =
\
+ char* VG_REPLACE_FUNCTION_ZU(soname,fnname) \
+ (char* dst, const char* src, SizeT len) \
+ { \
+ extern void _exit(int status); \
+ char* ret =3D dst; \
+ if (! len) \
+ goto badness; \
+ while ((*dst++ =3D *src++) !=3D '\0') \
+ if (--len =3D=3D 0) \
+ goto badness; \
+ return ret; \
+ badness: \
+ VALGRIND_PRINTF_BACKTRACE( \
+ "***buffer overflow detected ***: program terminated"); \
+ _exit(127); \
+ /*NOTREACHED*/ \
+ return NULL; \
+ }
+
+GLIBC25___STRCPY_CHK(m_libc_so_star, __strcpy_chk)
+
+
/*--------------------------------------------------------------------*/
/*--- end ---*/
/*--------------------------------------------------------------------*/
|
|
From: <js...@ac...> - 2006-12-31 01:16:39
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2006-12-31 02:00:01 CET 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 == 223 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) |
|
From: <sv...@va...> - 2006-12-31 01:05:23
|
Author: sewardj Date: 2006-12-31 01:05:19 +0000 (Sun, 31 Dec 2006) New Revision: 6463 Log: Redo a suppression in X.org style. Modified: trunk/xfree-4.supp Modified: trunk/xfree-4.supp =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/xfree-4.supp 2006-12-31 00:22:30 UTC (rev 6462) +++ trunk/xfree-4.supp 2006-12-31 01:05:19 UTC (rev 6463) @@ -212,6 +212,12 @@ obj:/usr/X11*/lib*/libXft.so* obj:/usr/X11*/lib*/libXft.so* } +{ + XftFontOpenInfo-umod-127-strangeness-a-la-xorg + Memcheck:Value8 + obj:/usr/lib*/libXft.so* + obj:/usr/lib*/libXft.so* +} =20 { More X padding stuff |
|
From: <sv...@va...> - 2006-12-31 00:22:34
|
Author: sewardj
Date: 2006-12-31 00:22:30 +0000 (Sun, 31 Dec 2006)
New Revision: 6462
Log:
Intercept/replace glibc-2.5's __strcpy_chk function for the usual
reasons: it reads word-sized chunks from memory and so produces lots
of errors in SuSE 10.2 (amd64).
Modified:
trunk/memcheck/mc_replace_strmem.c
Modified: trunk/memcheck/mc_replace_strmem.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_replace_strmem.c 2006-12-30 17:58:20 UTC (rev 6461)
+++ trunk/memcheck/mc_replace_strmem.c 2006-12-31 00:22:30 UTC (rev 6462)
@@ -532,6 +532,32 @@
GLIBC232_RAWMEMCHR(m_libc_soname, rawmemchr)
=20
=20
+/* glibc variant of strcpy that checks the dest is big enough. */
+#define GLIBC25___STRCPY_CHK(soname,fnname) \
+ char* VG_REPLACE_FUNCTION_ZU(soname,fnname) \
+ (char* dst, const char* src, SizeT len); =
\
+ char* VG_REPLACE_FUNCTION_ZU(soname,fnname) \
+ (char* dst, const char* src, SizeT len) \
+ { \
+ extern void _exit(int status); \
+ char* ret =3D dst; \
+ if (! len) \
+ goto badness; \
+ while ((*dst++ =3D *src++) !=3D '\0') \
+ if (--len =3D=3D 0) \
+ goto badness; \
+ return ret; \
+ badness: \
+ VALGRIND_PRINTF_BACKTRACE( \
+ "***buffer overflow detected ***: program terminated"); \
+ _exit(127); \
+ /*NOTREACHED*/ \
+ return NULL; \
+ }
+
+GLIBC25___STRCPY_CHK(m_libc_soname, __strcpy_chk)
+
+
/*------------------------------------------------------------*/
/*--- AIX stuff only after this point ---*/
/*------------------------------------------------------------*/
|