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
(6) |
2
(3) |
3
|
4
(3) |
5
(10) |
6
(4) |
7
(5) |
|
8
(1) |
9
(3) |
10
(11) |
11
(18) |
12
(13) |
13
(4) |
14
(11) |
|
15
(12) |
16
(6) |
17
(1) |
18
(13) |
19
(14) |
20
(12) |
21
(3) |
|
22
(17) |
23
(18) |
24
(17) |
25
(24) |
26
(15) |
27
(7) |
28
(23) |
|
29
(31) |
|
|
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2004-02-29 23:39:55
|
On Sun, 2004-02-29 at 14:16, Tom Hughes wrote:
> In message <1078091257.30493.82.camel@localhost.localdomain>
> Jeremy Fitzhardinge <je...@go...> wrote:
>
> > my_malloc ends up calling real malloc(), which on some libc's ends up
> > calling init_libc_tsd_keys recursively. The mutex is already held, so
> > it fails the second time through.
>
> Doesn't init_libc_tsd_keys already check for recursive calls before
> trying to do the lock though?
Not correctly. The recursion path is:
init_libc_tsd_keys ->
__pthread_key_create ->
get_or_allocate_specifics_ptr ->
my_malloc ->
malloc ->
... ->
init_libc_tsd_keys
init_libc_tsd_keys doesn't set libc_specifics_inited until after calling
__pthread_key_create.
Perhaps it should set it as early as possible.
J
|
|
From: Jeremy F. <je...@go...> - 2004-02-29 23:14:44
|
On Sat, 2004-02-28 at 12:54, Robert Walsh wrote:
> > Any other show-stoppers?
>
> If your code overrides operator new(), then 73655 is going to bite you.
> I don't know how common this is, but it's definitely stopping us from
> using Valgrind on our compiler at the moment.
>
> I think I know how to fix this - I just haven't sat down and thought it
> through yet. Drop me an email if you want to hear to gory details.
The bug is that Valgrind shouldn't be going around overriding symbols
any old place - it should be overriding them in specific libraries. The
new symbol intercept mechanism is careful to specify the intercepts in
terms of library/symbol, so that this is the case.
In this mechanism is the intercepts are provided by the library through
various client calls (for example, the init function in
vg_preloadmemcheck.so says "I override malloc!", etc). This keeps
things nice and modular, since the library which does the override tells
Valgrind about it itself, without having to scatter the knowledge
around.
The problem is that it relies on the init functions being run really
early - before any other code is run. It is *not* OK to use glibc
malloc for a while, and then intercept it with the Valgrind malloc -
things will get very confused.
So the quick fix is to make the intercept functions also globally
visible to the linker, so ld.so's override machinery can see it. This
happens early enough, but it causes unintended functions to be
overridden - in this case, operator new().
The correct fix needs to have two properties to be really satisfying:
1. the libraries containing intercepts must be self-describing, so
that there's no external knowledge of what functions they want
to intercept
2. it needs to take effect as soon as the library is mapped in,
before any code is run
The current code satisfies 1, but not 2.
I tried an experiment with adding a special valgrind-specific section to
intercept-containing .so files (.valgrind.intercept), which contains the
library and symbol name of the intercepted function, and the pointer to
the intercepting function. The idea is that when we see the client map
in a file which we identify as an ELF .so file, we check for a
.valgrind.intercept section, and set up the intercepts so described.
This problem with this scheme is that it is complex and ELF-specific.
The complexity comes from the fact that we need to interpret relocation
information to understand the string references in the
.valgrind.intercept section. Also, since an ELF file is mapped in with
several mmap calls, we need to delay evaluation until all the relevent
mmaps have been performed (normally this isn't an issue, since they
symtab is entirely contained within one mmaped chunk, and needs no
relocation; in the .valgrind.intercept case, we need to inspect the data
section for the strings making up the intercept description).
I guess the alternative to self-description is having a single source
file which is compiled for Valgrind-internal use and for client use,
containing the appropriate parts for each. At least this would
centralize things into a single source file, even if it has pieces
scattered between core and client. But it still has issues about when
to trigger the registration of the intercepts.
J
|
|
From: Tom H. <th...@cy...> - 2004-02-29 22:20:46
|
In message <1078091257.30493.82.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> my_malloc ends up calling real malloc(), which on some libc's ends up
> calling init_libc_tsd_keys recursively. The mutex is already held, so
> it fails the second time through.
Doesn't init_libc_tsd_keys already check for recursive calls before
trying to do the lock though?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2004-02-29 21:51:17
|
On Sat, 2004-02-28 at 10:13, Tom Hughes wrote: > *************** > *** 2 **** > --- 3,7 ---- > + valgrind's libpthread.so: init_libc_tsd_keys: lock > + Please report this bug at: valgrind.kde.org > > Which is a bit odd, because from looking at the code it means that > the attempt to lock the mutex in init_libc_tsd_keys is failing for > some reason. Yes, this is the result of some unwanted recursion. Um. What was it. Ah yes: my_malloc ends up calling real malloc(), which on some libc's ends up calling init_libc_tsd_keys recursively. The mutex is already held, so it fails the second time through. my_malloc could use the MALLOC client request, but that causes other problems, which I don't remember completely. Some dependency on whether the tool you have is overriding malloc or not. J |
|
From: Jeremy F. <je...@go...> - 2004-02-29 21:46:48
|
On Sat, 2004-02-28 at 09:20, Tom Hughes wrote: > *************** > *** 5 **** > ! at 0x........: accept (in /...libc...) > --- 5 ---- > ! at 0x........: _dl_sysinfo_int80 (in /lib/ld-2.3.2.so) > > This is down to the FC1 kernel/glibc combination making use of the sysinfo > page so that all system calls appear to occur in _dl_sysinfo_int80 but I did > think that Jeremy had put a hack in valgrind to make it back out to the next > function in that case when printing the stack trace. Yes, that happens when you run under a kernel which doesn't have a sysinfo page. Normally, glibc will use the kernel's sysinfo, but if there isn't one, it uses _dl_sysinfo_int80. The FV loader will substitute the kernel's sysinfo page for its own, so that if your kernel supports sysinfo, Valgrind will do the right thing. The problem here is that it only substitutes an existing sysinfo page, but won't add an entry if there isn't one already. This means that glibc will use its own, and cause bogus traces like this. The fix is simple: add a sysinfo entry to the AUXV, even if there isn't one already. J |
|
From: Nicholas N. <nj...@ca...> - 2004-02-29 20:09:50
|
CVS commit by nethercote:
Added Mnet
M +3 -0 users.html 1.51
--- devel-home/valgrind/users.html #1.50:1.51
@@ -409,4 +409,7 @@
<dd>A free, platform-independent library that reads and writes the
MS Write 3.0/3.1 document format.
+
+<dt><a href="http://mnet.sf.net/">Mnet</a>
+<dd>A distributed file store.
</dl>
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-29 17:50:30
|
CVS commit by nethercote: Added LibVNCServer M +5 -1 users.html 1.50 --- devel-home/valgrind/users.html #1.49:1.50 @@ -98,5 +98,5 @@ <dt><a href="http://atlas.web.cern.ch/Atlas/Welcome.html">Atlas</a> and <a href="http://cmsinfo.cern.ch/Welcome.html">CMS</a> experiments at - <a href="http://www.cern.ch">CERN's</a> + <a href="http://www.cern.ch">CERN</a>'s <a href="http://lhc-new-homepage.web.cern.ch/lhc-new-homepage/">Large Hadron Collider</a> @@ -244,4 +244,8 @@ <dt><a href="http://xplc.sf.net/">XPLC</a> <dd>Lightweight cross-platform components to aid software extension and reuse. + +<dt><a href="http://libvncserver.sf.net/">LibVNCServer</a> +<dd>A free library which makes it fun to write a server that connects to + VNCViewer. </dl> |
|
From: Nicholas N. <nj...@ca...> - 2004-02-29 15:57:31
|
CVS commit by nethercote:
Patch from Bartosz Taudul: latest GCC requires regparm(n) attributes on both
function declarations and definitions. [copied from HEAD]
M +8 -8 helgrind/hg_main.c 1.60.2.4
M +8 -8 memcheck/mc_include.h 1.16.2.1
--- valgrind/helgrind/hg_main.c #1.60.2.3:1.60.2.4
@@ -3102,40 +3102,40 @@ static void eraser_mem_write(Addr a, UIn
#undef DEBUG_STATE
-static void eraser_mem_help_read_1(Addr a)
+REGPARM(1) static void eraser_mem_help_read_1(Addr a)
{
eraser_mem_read(a, 1, VG_(get_current_tid)());
}
-static void eraser_mem_help_read_2(Addr a)
+REGPARM(1) static void eraser_mem_help_read_2(Addr a)
{
eraser_mem_read(a, 2, VG_(get_current_tid)());
}
-static void eraser_mem_help_read_4(Addr a)
+REGPARM(1) static void eraser_mem_help_read_4(Addr a)
{
eraser_mem_read(a, 4, VG_(get_current_tid)());
}
-static void eraser_mem_help_read_N(Addr a, UInt size)
+REGPARM(2) static void eraser_mem_help_read_N(Addr a, UInt size)
{
eraser_mem_read(a, size, VG_(get_current_tid)());
}
-static void eraser_mem_help_write_1(Addr a, UInt val)
+REGPARM(2) static void eraser_mem_help_write_1(Addr a, UInt val)
{
if (*(UChar *)a != val)
eraser_mem_write(a, 1, VG_(get_current_tid)());
}
-static void eraser_mem_help_write_2(Addr a, UInt val)
+REGPARM(2) static void eraser_mem_help_write_2(Addr a, UInt val)
{
if (*(UShort *)a != val)
eraser_mem_write(a, 2, VG_(get_current_tid)());
}
-static void eraser_mem_help_write_4(Addr a, UInt val)
+REGPARM(2) static void eraser_mem_help_write_4(Addr a, UInt val)
{
if (*(UInt *)a != val)
eraser_mem_write(a, 4, VG_(get_current_tid)());
}
-static void eraser_mem_help_write_N(Addr a, UInt size)
+REGPARM(2) static void eraser_mem_help_write_N(Addr a, UInt size)
{
eraser_mem_write(a, size, VG_(get_current_tid)());
--- valgrind/memcheck/mc_include.h #1.16:1.16.2.1
@@ -122,14 +122,14 @@ extern void MC_(helper_value_check0_fail
/* Functions defined in mc_main.c */
-extern void MC_(helperc_STOREV4) ( Addr, UInt );
-extern void MC_(helperc_STOREV2) ( Addr, UInt );
-extern void MC_(helperc_STOREV1) ( Addr, UInt );
+extern __attribute__ ((regparm(2))) void MC_(helperc_STOREV4) ( Addr, UInt );
+extern __attribute__ ((regparm(2))) void MC_(helperc_STOREV2) ( Addr, UInt );
+extern __attribute__ ((regparm(2))) void MC_(helperc_STOREV1) ( Addr, UInt );
-extern UInt MC_(helperc_LOADV1) ( Addr );
-extern UInt MC_(helperc_LOADV2) ( Addr );
-extern UInt MC_(helperc_LOADV4) ( Addr );
+extern __attribute__ ((regparm(1))) UInt MC_(helperc_LOADV1) ( Addr );
+extern __attribute__ ((regparm(1))) UInt MC_(helperc_LOADV2) ( Addr );
+extern __attribute__ ((regparm(1))) UInt MC_(helperc_LOADV4) ( Addr );
-extern void MC_(fpu_write_check) ( Addr addr, Int size );
-extern void MC_(fpu_read_check) ( Addr addr, Int size );
+extern __attribute__ ((regparm(2))) void MC_(fpu_write_check) ( Addr addr, Int size );
+extern __attribute__ ((regparm(2))) void MC_(fpu_read_check) ( Addr addr, Int size );
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-29 15:53:53
|
CVS commit by nethercote:
Patch from Bartosz Taudul: latest GCC requires regparm(n) attributes on both
function declarations and definitions.
M +8 -8 helgrind/hg_main.c 1.72
M +8 -8 memcheck/mc_include.h 1.19
--- valgrind/helgrind/hg_main.c #1.71:1.72
@@ -3104,40 +3104,40 @@ static void eraser_mem_write(Addr a, UIn
#undef DEBUG_STATE
-static void eraser_mem_help_read_1(Addr a)
+REGPARM(1) static void eraser_mem_help_read_1(Addr a)
{
eraser_mem_read(a, 1, VG_(get_current_tid)());
}
-static void eraser_mem_help_read_2(Addr a)
+REGPARM(1) static void eraser_mem_help_read_2(Addr a)
{
eraser_mem_read(a, 2, VG_(get_current_tid)());
}
-static void eraser_mem_help_read_4(Addr a)
+REGPARM(1) static void eraser_mem_help_read_4(Addr a)
{
eraser_mem_read(a, 4, VG_(get_current_tid)());
}
-static void eraser_mem_help_read_N(Addr a, UInt size)
+REGPARM(2) static void eraser_mem_help_read_N(Addr a, UInt size)
{
eraser_mem_read(a, size, VG_(get_current_tid)());
}
-static void eraser_mem_help_write_1(Addr a, UInt val)
+REGPARM(2) static void eraser_mem_help_write_1(Addr a, UInt val)
{
if (*(UChar *)a != val)
eraser_mem_write(a, 1, VG_(get_current_tid)());
}
-static void eraser_mem_help_write_2(Addr a, UInt val)
+REGPARM(2) static void eraser_mem_help_write_2(Addr a, UInt val)
{
if (*(UShort *)a != val)
eraser_mem_write(a, 2, VG_(get_current_tid)());
}
-static void eraser_mem_help_write_4(Addr a, UInt val)
+REGPARM(2) static void eraser_mem_help_write_4(Addr a, UInt val)
{
if (*(UInt *)a != val)
eraser_mem_write(a, 4, VG_(get_current_tid)());
}
-static void eraser_mem_help_write_N(Addr a, UInt size)
+REGPARM(2) static void eraser_mem_help_write_N(Addr a, UInt size)
{
eraser_mem_write(a, size, VG_(get_current_tid)());
--- valgrind/memcheck/mc_include.h #1.18:1.19
@@ -122,14 +122,14 @@ extern void MC_(helper_value_check0_fail
/* Functions defined in mc_main.c */
-extern void MC_(helperc_STOREV4) ( Addr, UInt );
-extern void MC_(helperc_STOREV2) ( Addr, UInt );
-extern void MC_(helperc_STOREV1) ( Addr, UInt );
+extern __attribute__ ((regparm(2))) void MC_(helperc_STOREV4) ( Addr, UInt );
+extern __attribute__ ((regparm(2))) void MC_(helperc_STOREV2) ( Addr, UInt );
+extern __attribute__ ((regparm(2))) void MC_(helperc_STOREV1) ( Addr, UInt );
-extern UInt MC_(helperc_LOADV1) ( Addr );
-extern UInt MC_(helperc_LOADV2) ( Addr );
-extern UInt MC_(helperc_LOADV4) ( Addr );
+extern __attribute__ ((regparm(1))) UInt MC_(helperc_LOADV1) ( Addr );
+extern __attribute__ ((regparm(1))) UInt MC_(helperc_LOADV2) ( Addr );
+extern __attribute__ ((regparm(1))) UInt MC_(helperc_LOADV4) ( Addr );
-extern void MC_(fpu_write_check) ( Addr addr, Int size );
-extern void MC_(fpu_read_check) ( Addr addr, Int size );
+extern __attribute__ ((regparm(2))) void MC_(fpu_write_check) ( Addr addr, Int size );
+extern __attribute__ ((regparm(2))) void MC_(fpu_read_check) ( Addr addr, Int size );
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-29 14:29:24
|
CVS commit by nethercote: Add CMS, PowerDNS, KolourPaint, LibMSWrite -- we now have 102 projects listed! M +21 -5 users.html 1.49 --- devel-home/valgrind/users.html #1.48:1.49 @@ -92,10 +92,15 @@ <h3>Scientific</h3> <dl> -<dt><a href="http://marsrovers.jpl.nasa.gov/home/">NASA Mars Exploration Rover</a> +<dt><a href="http://marsrovers.jpl.nasa.gov/home/">NASA Mars Exploration + Rover</a> <dd>Navigation and vision systems. -<dt><a href="http://atlas.web.cern.ch/Atlas/Welcome.html">Atlas</a> -<dd>The data acquisition, analysis and simulation software for the Atlas - Experiment at CERN's Large Hadron Collider. +<dt><a href="http://atlas.web.cern.ch/Atlas/Welcome.html">Atlas</a> and + <a href="http://cmsinfo.cern.ch/Welcome.html">CMS</a> experiments at + <a href="http://www.cern.ch">CERN's</a> + <a href="http://lhc-new-homepage.web.cern.ch/lhc-new-homepage/">Large + Hadron Collider</a> +<dd>Data acquisition, reconstruction, analysis, visualisation and + simulation software. <dt><a href="http://www.hlrs.de/organization/pds/projects/pacx-mpi/">PACX-MPI</a> @@ -148,4 +153,7 @@ <dt><a href="http://www.paraview.org/">ParaView</a> <dd>A visualizer for large data sets. + +<dt><a href="http://kolourpaint.sf.net/">KolourPaint</a> +<dd>An easy-to-use paint program for KDE. </dl> @@ -349,7 +357,11 @@ <h3>Internet</h3> <dl> -<dt><a href="http://messenger.yahoo.com/messenger/download/unix.html">Yahoo! Messenger</a> +<dt><a href="http://messenger.yahoo.com/messenger/download/unix.html">Yahoo! + Messenger</a> <dd>A free instant messaging service. +<dt><a href="http://www.powerdns.com">PowerDNS</a> +<dd>A modern, advanced and high performance authoritative-only nameserver. + <dt><a href="http://pan.rebelbase.com/">Pan</a> <dd>A newsreader supporting offline newsreading, article filtering, and @@ -389,4 +401,8 @@ <dt><a href="http://www.gtk-papaya.org/">Papaya</a> <dd>A GTK+-2.0 MUD client for UNIX and Windows. + +<dt><a href="http://sourceforge.net/projects/libmswrite/">LibMSWrite</a> +<dd>A free, platform-independent library that reads and writes the + MS Write 3.0/3.1 document format. </dl> |
|
From: Nicholas N. <nj...@ca...> - 2004-02-29 14:17:16
|
CVS commit by nethercote: Be picky with URLs M +39 -39 users.html 1.48 --- devel-home/valgrind/users.html #1.47:1.48 @@ -15,5 +15,5 @@ <h3>Office Software</h3> <dl> -<dt><a href="http://openoffice.org">OpenOffice</a> +<dt><a href="http://openoffice.org/">OpenOffice</a> <dd>An open source multi-platform office productivity suite. (<a href="http://www.kegel.com/openoffice/valgrindingOOo.html">Examples</a> @@ -23,8 +23,8 @@ <dd>A commercial multi-platform office productivity suite, based on OpenOffice. -<dt><a href="http://www.koffice.org">KOffice</a> +<dt><a href="http://www.koffice.org/">KOffice</a> <dd>A multi-application, integrated office suite. -<dt><a href="http://www.gnumeric.org">Gnumeric</a> +<dt><a href="http://www.gnumeric.org/">Gnumeric</a> <dd>A replacement for proprietary spreadsheets. @@ -40,5 +40,5 @@ <h3>Web Browsers</h3> <dl> -<dt><a href="http://www.mozilla.org">Mozilla</a> +<dt><a href="http://www.mozilla.org/">Mozilla</a> <dd>Web application suite, for browsing, email, IRC chat and HTML editing. @@ -46,11 +46,11 @@ <dd>A lean, fast web browser derived from the Mozilla suite. -<dt><a href="http://www.opera.com">Opera</a> +<dt><a href="http://www.opera.com/">Opera</a> <dd>A fast, multi-platform web browser. -<dt><a href="http://www.konqueror.org">Konqueror</a> +<dt><a href="http://www.konqueror.org/">Konqueror</a> <dd>A web browser, file manager, and universal document viewing application. -<dt><a href="http://galeon.sf.net">Galeon</a> +<dt><a href="http://galeon.sf.net/">Galeon</a> <dd>A web browser for GNOME that uses Mozilla's rendering engine. @@ -62,13 +62,13 @@ <h3>Databases and Search Engines</h3> <dl> -<dt><a href="http://www.mysql.com">MySQL</a> +<dt><a href="http://www.mysql.com/">MySQL</a> <dd>The World's most popular open source database. (A <a href="http://www.mysql.com/doc/en/Tools_used_to_create_MySQL.html">thank you</a> from MySQL.) -<dt><a href="http://www.postgresql.org">PostgreSQL</a> +<dt><a href="http://www.postgresql.org/">PostgreSQL</a> <dd>The World's most advanced open source database. -<dt><a href="http://www.teratext.com">Teratext Database System</a> +<dt><a href="http://www.teratext.com/">Teratext Database System</a> <dd>A terabyte-capable text database. @@ -84,5 +84,5 @@ <dd>A database performance monitoring and acceleration tool. -<dt><a href="http://www.exalead.com">Exalead</a> +<dt><a href="http://www.exalead.com/">Exalead</a> <dd>A search and navigation platform, including search engine, XML processing libraries, and statistical linguistics. @@ -103,8 +103,8 @@ through high-speed networks or the internet. -<dt><a href="http://www.flowtech.se">SHIPFLOW/Chapman</a> +<dt><a href="http://www.flowtech.se/">SHIPFLOW/Chapman</a> <dd>Special purpose software for investigating marine vessel hydrodynamics. -<dt><a href="http://teem.sf.net">Teem</a> +<dt><a href="http://teem.sf.net/">Teem</a> <dd>A collection of C libraries for manipulating and visualizing structured scientific data. @@ -114,8 +114,8 @@ <dd>Numerical libraries for linear finite elements in two dimensions. -<dt><a href="http://www.cactuscode.org">Cactus</a> +<dt><a href="http://www.cactuscode.org/">Cactus</a> <dd>A framework for parallel computation and collaborative code development. -<dt><a href="http://www.harmonyware.com">HarmonyWare</a> +<dt><a href="http://www.harmonyware.com/">HarmonyWare</a> <dd>NURBS-based geometry translator tools. @@ -130,9 +130,9 @@ <h3>Graphics and Visualization</h3> <dl> -<dt><a href="http://www.opensg.org">OpenSG</a> +<dt><a href="http://www.opensg.org/">OpenSG</a> <dd>A portable scenegraph system for creating realtime graphics programs, e.g. for virtual reality applications. -<dt><a href="http://www.equinox3d.com">EQUINOX-3D</a> +<dt><a href="http://www.equinox3d.com/">EQUINOX-3D</a> <dd>A modeling, animation and renderering suite for 3D graphics on Linux and Unix. @@ -142,9 +142,9 @@ browsing. -<dt><a href="http://www.vtk.org">VTK</a> +<dt><a href="http://www.vtk.org/">VTK</a> <dd>An open source software system for 3D computer graphics, image processing, and visualization. -<dt><a href="http://www.paraview.org">ParaView</a> +<dt><a href="http://www.paraview.org/">ParaView</a> <dd>A visualizer for large data sets. </dl> @@ -213,8 +213,8 @@ <h3>Development Environments and Libraries</h3> <dl> -<dt><a href="http://www.kde.org">KDE</a> +<dt><a href="http://www.kde.org/">KDE</a> <dd>An open source graphical desktop environment for Unix workstations. -<dt><a href="http://www.gnome.org">GNOME</a> +<dt><a href="http://www.gnome.org/">GNOME</a> <dd>A desktop environment and developer platform for Unix and Linux systems. @@ -222,8 +222,8 @@ <dd>A multi-platform, C++ application development framework. -<dt><a href="http://opie.handhelds.org">Opie</a> +<dt><a href="http://opie.handhelds.org/">Opie</a> <dd>A graphical user environment for PDAs and other Linux devices. -<dt><a href="http://www.uclibc.org">uClibc</a> +<dt><a href="http://www.uclibc.org/">uClibc</a> <dd>A compact C library for embedded systems. @@ -231,8 +231,8 @@ <dd>GNOME's multi-platform XML C parser and toolkit. -<dt><a href="http://www.boost.org">Boost C++ libraries</a> +<dt><a href="http://www.boost.org/">Boost C++ libraries</a> <dd>A collection of portable C++ source libraries. -<dt><a href="http://xplc.sf.net">XPLC</a> +<dt><a href="http://xplc.sf.net/">XPLC</a> <dd>Lightweight cross-platform components to aid software extension and reuse. </dl> @@ -276,23 +276,23 @@ <h3>System</h3> <dl> -<dt><a href="http://www.samba.org">Samba</a> +<dt><a href="http://www.samba.org/">Samba</a> <dd>An open source suite providing seamless file and print services to SMB/CIFS clients. -<dt><a href="http://www.xinetd.org">Xinetd</a> +<dt><a href="http://www.xinetd.org/">Xinetd</a> <dd>A secure and powerful replacement for inetd, the internet services daemon. (<a href="http://www.securiteam.com/unixfocus/6P00D208UC.html">Example</a> bug found.) -<dt><a href="http://www.ntop.org">ntop</a> +<dt><a href="http://www.ntop.org/">ntop</a> <dd>A network traffic probe that shows network usage. -<dt><a href="http://www.prelude-ids.org">Prelude IDS</a> +<dt><a href="http://www.prelude-ids.org/">Prelude IDS</a> <dd>A hybrid intrusion detection system for network/host security. -<dt><a href="http://synce.sf.net">SynCE</a> +<dt><a href="http://synce.sf.net/">SynCE</a> <dd>A WinCE communications layer. -<dt><a href="http://gimp-print.sf.net">Gimp-Print</a> +<dt><a href="http://gimp-print.sf.net/">Gimp-Print</a> <dd>Printer drivers for use with Ghostscript, CUPS, Foomatic, and The GIMP. @@ -335,8 +335,8 @@ <dd>A turn-based strategy game with a fantasy theme. -<dt><a href="http://crystal.sf.net">Crystal Space</a> +<dt><a href="http://crystal.sf.net/">Crystal Space</a> <dd>A portable 3D game engine. -<dt><a href="http://www.scummvm.org">ScummVM</a> +<dt><a href="http://www.scummvm.org/">ScummVM</a> <dd>A virtual machine for classic graphical adventure games. @@ -366,9 +366,9 @@ <h3>Other</h3> <dl> -<dt><a href="http://www.sas.com">SAS</a> +<dt><a href="http://www.sas.com/">SAS</a> <dd>A 25 MLOC integrated data management, business intelligence and analysis system. -<dt><a href="http://www.gimp.org">The GIMP</a> +<dt><a href="http://www.gimp.org/">The GIMP</a> <dd>The GNU Image Manipulation Program. @@ -377,15 +377,15 @@ and more. -<dt><a href="http://www.sportvision.com">SportVision</a> +<dt><a href="http://www.sportvision.com/">SportVision</a> <dd>Various tools for virtual enhancements to live TV sports broadcasts. -<dt><a href="http://www.chipvision.com">ORINOCO</a> +<dt><a href="http://www.chipvision.com/">ORINOCO</a> <dd>A tool to estimate the power dissipation of hardware/ASIC designs. -<dt><a href="http://www.xmlBlaster.org">xmlBlaster</a> +<dt><a href="http://www.xmlBlaster.org/">xmlBlaster</a> <dd>A publish/subscribe and PtP message oriented middleware with easy access from C, C++, Java, Perl, Python. -<dt><a href="http://www.gtk-papaya.org">Papaya</a> +<dt><a href="http://www.gtk-papaya.org/">Papaya</a> <dd>A GTK+-2.0 MUD client for UNIX and Windows. </dl> |
|
From: Tom H. <th...@cy...> - 2004-02-29 13:07:22
|
In message <Pin...@re...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Sat, 28 Feb 2004, Tom Hughes wrote:
>
> > Virtually every test on RH7.3 is failing with a series of errors
> > like this:
> >
> > + warning: line info addresses out of order at entry 939: 0x........ 0x........
> > + warning: line info addresses out of order at entry 943: 0x........ 0x........
>
> We could remove such lines using the basic filter. Or not spit out the
> warning if it's not important.
I've filtered them out for now so I can see the wood from the trees.
Somebody with more knowledge of the stabs code than me needs to work
out what the messages mean and whether they're important.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-02-29 13:04:40
|
CVS commit by thughes:
Added some extra suppressions for glibc 2.2.5 on RedHat 7.3 systems.
M +16 -0 glibc-2.2.supp 1.23
--- valgrind/glibc-2.2.supp #1.22:1.23
@@ -172,4 +172,12 @@
{
+ _dl_lookup_versioned_symbol_internal/fixup/_dl_runtime_resolve
+ Helgrind:Eraser
+ fun:_dl_lookup_versioned_symbol_internal
+ fun:fixup
+ fun:_dl_runtime_resolve
+}
+
+{
_dl_fini/exit/__libc_start_main
Helgrind:Eraser
@@ -351,4 +359,12 @@
fun:_dl_start_final
}
+{
+ _dl_relocate_object_internal/dl_main/_dl_sysdep_start/_dl_start_final(Cond)
+ Memcheck:Cond
+ fun:_dl_relocate_object_internal
+ fun:dl_main
+ fun:_dl_sysdep_start
+ fun:_dl_start_final
+}
{
|
|
From: Tom H. <th...@cy...> - 2004-02-29 13:04:04
|
CVS commit by thughes: Modified the basic standard error filter to strip out line info out of order warnings which some systems seem to produce. M +4 -1 filter_stderr_basic 1.16 --- valgrind/tests/filter_stderr_basic #1.15:1.16 @@ -31,3 +31,6 @@ sed "s/ __getsockname / getsockname /" | sed "s/ __sigaction / sigaction /" | -sed "s/ __GI___/ __/" +sed "s/ __GI___/ __/" | + +# Remove line info out of order warnings +sed "/warning: line info addresses out of order/d" |
|
From: Tom H. <th...@cy...> - 2004-02-29 12:45:55
|
CVS commit by thughes:
Add an extra suppression for glibc 2.3.2 on RedHat 8.0 systems.
M +7 -0 glibc-2.3.supp 1.11
--- valgrind/glibc-2.3.supp #1.10:1.11
@@ -131,4 +131,11 @@
}
{
+ _dl_lookup_versioned_symbol/ld-2.3.2.so/ld-2.3.2.so
+ Helgrind:Eraser
+ fun:_dl_lookup_versioned_symbol
+ obj:/lib/ld-2.3.2.so
+ obj:/lib/ld-2.3.2.so
+}
+{
_dl_fini
Helgrind:Eraser
|
|
From: <sun...@t2...> - 2004-02-29 12:12:35
|
Hi,
I'm interested in writing a new skin around valgrind that will enable
comprehensive memory profiling.
I haven't found many profiling tools, and one I found (MemProf)
crashes on our code.
Also, our tool has a lot of dependencies on IS tools. This is a problem s=
ince
many people here use allocators, and rebuilding everything from scratch w=
ithout
them can be very unfun :).
My skin basically enables wrapping any function the user chooses. I then =
do 2
things:
1. Save the stack.
2. Analyze the sources to understand which class has just been allocated,=
if
any.
This means I can also detail how much objects of each class exist.
=20
For example, a user can write a config similar to this:
{
alloc_fun: allocator<T>::allocate(n);
alloced =3D sizeof(T)*n;
}
{
dealloc_fun: allocator<T>::allocate(n);
dealloced =3D sizeof(T)*n;
}
or use wildcards, etc.
This way we can analyze our memory usage without having horrible compilat=
ions.
It seems to me like this might be worth getting into the core too perhaps=
: the
ability to override allocation functions, so instead of re-compiling
everything, I'll just instruct valgrind to do this:
{
func: allocate(n)
replace_by: malloc(n)
}
Unless of course I want to debug my allocators.. :)
At any rate, I'm trying to read the values passed to the allocate(..)
function by doing the following code:
// ebp address
Addr ebp =3D (Addr)(VG_(baseBlock)[VGOFF_(m_ebp)]);
Addr eip =3D ((Uint*)ebp)[1];
int first_var =3D ((Uint*)ebp)[2];
This code is similar to what happens in VG_(get_ExeContext2), so I
cannot see why it doesn't work.
I do notice however that ebp, eip are correct, but first_var always
equals one.
Can anyone direct me how to obtain its value? Perhaps it can be done
during instrumentation (I'm currently doing it when my hook is called
at the function entry)?
Thanks,
Yair
----- End forwarded message -----
|
|
From: Lifshitz, Y. <yai...@in...> - 2004-02-29 12:06:31
|
> Hi,
>=20
> I'm interested in writing a new skin around valgrind that will enable
> comprehensive memory profiling.
>=20
> I haven't found many profiling tools, and one I found (MemProf)
> crashes on our code.
> Also, our tool has a lot of dependencies on IS tools. This is a
> problem since many people here use allocators, and rebuilding
> everything from scratch without them can be very unfun :).
>=20
> My skin basically enables wrapping any function the user chooses. I
> then do 2 things:
>=20
> 1. Save the stack.
> 2. Analyze the sources to understand which class has just been
> allocated, if any.
>=20
> This means I can also detail how much objects of each class exist.
>=20
> For example, a user can write a config similar to this:
>=20
> {
> alloc_fun: allocator<T>::allocate(n);
> alloced =3D sizeof(T)*n;
> }
>=20
> {
> dealloc_fun: allocator<T>::allocate(n);
> dealloced =3D sizeof(T)*n;
> }
>=20
> or use wildcards, etc.
>=20
> This way we can analyze our memory usage without having horrible
> compilations.
> It seems to me like this might be worth getting into the core too
> perhaps: the ability to override allocation functions, so instead of
> re-compiling everything, I'll just instruct valgrind to do this:
>=20
> {
> func: allocate(n)
> replace_by: malloc(n)
> }
>=20
> Unless of course I want to debug my allocators.. :)
>=20
> At any rate, I'm trying to read the values passed to the allocate(..)
> function by doing the following code:
>=20
> // ebp address
> Addr ebp =3D (Addr)(VG_(baseBlock)[VGOFF_(m_ebp)]);
> Addr eip =3D ((Uint*)ebp)[1];
> int first_var =3D ((Uint*)ebp)[2];
>=20
> This code is similar to what happens in VG_(get_ExeContext2), so I
> cannot see why it doesn't work.
> I do notice however that ebp, eip are correct, but first_var always
> equals one.
>=20
> Can anyone direct me how to obtain its value? Perhaps it can be done
> during instrumentation (I'm currently doing it when my hook is called
> at the function entry)?
>=20
>=20
> Thanks,
>=20
> Yair
>=20
|
|
From: Tom H. <th...@cy...> - 2004-02-29 12:06:16
|
CVS commit by thughes:
Changed the fdleak tests to explicitly attach /dev/null as the standard
input so that the output is well known regardless of whether the test is
run from a terminal or from cron.
M +2 -2 fdleak_cmsg.stderr.exp 1.4
M +1 -0 fdleak_cmsg.vgtest 1.2
M +1 -1 fdleak_creat.stderr.exp 1.4
M +1 -0 fdleak_creat.vgtest 1.2
M +1 -1 fdleak_dup.stderr.exp 1.4
M +1 -0 fdleak_dup.vgtest 1.2
M +1 -1 fdleak_dup2.stderr.exp 1.4
M +1 -0 fdleak_dup2.vgtest 1.2
M +1 -1 fdleak_fcntl.stderr.exp 1.4
M +1 -0 fdleak_fcntl.vgtest 1.2
M +2 -2 fdleak_ipv4.stderr.exp 1.4
M +1 -0 fdleak_ipv4.vgtest 1.2
M +1 -1 fdleak_open.stderr.exp 1.4
M +1 -0 fdleak_open.vgtest 1.2
M +1 -1 fdleak_pipe.stderr.exp 1.4
M +1 -0 fdleak_pipe.vgtest 1.2
M +1 -1 fdleak_socketpair.stderr.exp 1.4
M +1 -0 fdleak_socketpair.vgtest 1.2
--- valgrind/corecheck/tests/fdleak_cmsg.stderr.exp #1.3:1.4
@@ -24,5 +24,5 @@
<inherited from parent>
-Open file descriptor .: .
+Open file descriptor .: /dev/null
<inherited from parent>
@@ -49,5 +49,5 @@
<inherited from parent>
-Open file descriptor .: .
+Open file descriptor .: /dev/null
<inherited from parent>
--- valgrind/corecheck/tests/fdleak_cmsg.vgtest #1.1:1.2
@@ -2,2 +2,3 @@
vgopts: --track-fds=yes
stderr_filter: filter_fdleak
+args: < /dev/null
--- valgrind/corecheck/tests/fdleak_creat.stderr.exp #1.3:1.4
@@ -14,5 +14,5 @@
<inherited from parent>
-Open file descriptor .: .
+Open file descriptor .: /dev/null
<inherited from parent>
--- valgrind/corecheck/tests/fdleak_creat.vgtest #1.1:1.2
@@ -2,2 +2,3 @@
vgopts: --track-fds=yes
stderr_filter: filter_fdleak
+args: < /dev/null
--- valgrind/corecheck/tests/fdleak_dup.stderr.exp #1.3:1.4
@@ -18,5 +18,5 @@
<inherited from parent>
-Open file descriptor .: .
+Open file descriptor .: /dev/null
<inherited from parent>
--- valgrind/corecheck/tests/fdleak_dup.vgtest #1.1:1.2
@@ -2,2 +2,3 @@
vgopts: --track-fds=yes
stderr_filter: filter_fdleak
+args: < /dev/null
--- valgrind/corecheck/tests/fdleak_dup2.stderr.exp #1.3:1.4
@@ -23,5 +23,5 @@
<inherited from parent>
-Open file descriptor .: .
+Open file descriptor .: /dev/null
<inherited from parent>
--- valgrind/corecheck/tests/fdleak_dup2.vgtest #1.1:1.2
@@ -2,2 +2,3 @@
vgopts: --track-fds=yes
stderr_filter: filter_fdleak
+args: < /dev/null
--- valgrind/corecheck/tests/fdleak_fcntl.stderr.exp #1.3:1.4
@@ -17,5 +17,5 @@
<inherited from parent>
-Open file descriptor .: .
+Open file descriptor .: /dev/null
<inherited from parent>
--- valgrind/corecheck/tests/fdleak_fcntl.vgtest #1.1:1.2
@@ -2,2 +2,3 @@
vgopts: --track-fds=yes
stderr_filter: filter_fdleak
+args: < /dev/null
--- valgrind/corecheck/tests/fdleak_ipv4.stderr.exp #1.3:1.4
@@ -16,5 +16,5 @@
<inherited from parent>
-Open file descriptor .: .
+Open file descriptor .: /dev/null
<inherited from parent>
@@ -33,5 +33,5 @@
<inherited from parent>
-Open file descriptor .: .
+Open file descriptor .: /dev/null
<inherited from parent>
--- valgrind/corecheck/tests/fdleak_ipv4.vgtest #1.1:1.2
@@ -2,2 +2,3 @@
vgopts: --track-fds=yes
stderr_filter: filter_fdleak
+args: < /dev/null
--- valgrind/corecheck/tests/fdleak_open.stderr.exp #1.3:1.4
@@ -13,5 +13,5 @@
<inherited from parent>
-Open file descriptor .: .
+Open file descriptor .: /dev/null
<inherited from parent>
--- valgrind/corecheck/tests/fdleak_open.vgtest #1.1:1.2
@@ -2,2 +2,3 @@
vgopts: --track-fds=yes
stderr_filter: filter_fdleak
+args: < /dev/null
--- valgrind/corecheck/tests/fdleak_pipe.stderr.exp #1.3:1.4
@@ -18,5 +18,5 @@
<inherited from parent>
-Open file descriptor .: .
+Open file descriptor .: /dev/null
<inherited from parent>
--- valgrind/corecheck/tests/fdleak_pipe.vgtest #1.1:1.2
@@ -2,2 +2,3 @@
vgopts: --track-fds=yes
stderr_filter: filter_fdleak
+args: < /dev/null
--- valgrind/corecheck/tests/fdleak_socketpair.stderr.exp #1.3:1.4
@@ -18,5 +18,5 @@
<inherited from parent>
-Open file descriptor .: .
+Open file descriptor .: /dev/null
<inherited from parent>
--- valgrind/corecheck/tests/fdleak_socketpair.vgtest #1.1:1.2
@@ -2,2 +2,3 @@
vgopts: --track-fds=yes
stderr_filter: filter_fdleak
+args: < /dev/null
|
|
From: Tom H. <th...@cy...> - 2004-02-29 11:00:53
|
In message <Pin...@re...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Sat, 28 Feb 2004, Tom Hughes wrote:
>
> > The fdleak_ failures are caused by the overnight tests being run from
> > cron and getting /dev/null as standard input which is explicitly left
> > alone by the filter script and hence the output doesn't match the
> > expected results which are designed for running from a terminal where
> > the terminal name would get filtered out.
>
> I understood that paragraph up to "standard input", but the rest lost me.
> How is the filter script interacting with /dev/null? How does the
> terminal name get filtered out? Sorry if I'm being dense.
The /dev/null was actually a red herring as standard input is
actually a pipe under cron it seems.
If you run the fdleak tests from an interactive session then the
output will include something like this:
==12551== Open file descriptor 2: /dev/pts/13
==12551== <inherited from parent>
==12551==
==12551== Open file descriptor 1: /dev/pts/13
==12551== <inherited from parent>
==12551==
==12551== Open file descriptor 0: /dev/pts/13
==12551== <inherited from parent>
which is then stripped to this:
==12551== Open file descriptor .: .
==12551== <inherited from parent>
==12551==
==12551== Open file descriptor .: .
==12551== <inherited from parent>
==12551==
==12551== Open file descriptor .: .
==12551== <inherited from parent>
So that the exact name of the terminal device doesn't effect whether
or not the test passes. Running from cron means that the standard input
output and error devices are pipes instead of terminals, which means
you get output like this:
==12509== Open file descriptor 2:
==12509== <inherited from parent>
==12509==
==12509== Open file descriptor 1:
==12509== <inherited from parent>
==12509==
==12509== Open file descriptor 0:
==12509== <inherited from parent>
Note that valgrind isn't able to work out what the descriptor is
because it's a pipe, so leaves that blank. That is then stripped
to this:
==12509== Open file descriptor .:
==12509== <inherited from parent>
==12509==
==12509== Open file descriptor .:
==12509== <inherited from parent>
==12509==
==12509== Open file descriptor .:
==12509== <inherited from parent>
Which doesn't match the results because of the final . being missing.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: <js...@ac...> - 2004-02-29 04:10:55
|
Nightly build on phoenix ( SuSE 8.2 ) started at 2004-02-29 04:00:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 125 tests, 13 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) |
|
From: <js...@ac...> - 2004-02-29 03:54:39
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-02-29 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 125 tests, 13 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) |
|
From: Tom H. <to...@co...> - 2004-02-29 03:26:02
|
Nightly build on dunsmere ( Fedora Core 1 ) started at 2004-02-29 03:20:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 126 tests, 15 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/fwrite (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) |
|
From: Tom H. <th...@cy...> - 2004-02-29 03:20:54
|
Nightly build on audi ( Red Hat 9 ) started at 2004-02-29 03:15:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow smc1: valgrind ./smc1 syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 126 tests, 11 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) massif/tests/true_text (stderr) |
|
From: Tom H. <th...@cy...> - 2004-02-29 03:16:12
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-02-29 03:10:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 126 tests, 17 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/writev (stderr) |
|
From: Tom H. <th...@cy...> - 2004-02-29 03:11:07
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-02-29 03:05:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow none/tests/insn_mmxext (stderr) none/tests/insn_sse (stderr) none/tests/map_unmap (stderr) none/tests/mremap (stderr) none/tests/munmap_exe (stderr) none/tests/pth_blockedsig (stderr) none/tests/rcl_assert (stderr) none/tests/rcrl (stderr) none/tests/readline1 (stderr) none/tests/resolv (stderr) none/tests/seg_override (stderr) none/tests/sha1_test (stderr) none/tests/shortpush (stderr) none/tests/shorts (stderr) none/tests/smc1 (stderr) none/tests/syscall-restart1 (stderr) none/tests/syscall-restart2 (stderr) none/tests/system (stderr) none/tests/yield (stderr) |