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
(5) |
2
(15) |
3
(20) |
|
4
(4) |
5
(11) |
6
(8) |
7
(36) |
8
(23) |
9
(6) |
10
(4) |
|
11
(4) |
12
(19) |
13
(17) |
14
(33) |
15
(16) |
16
(17) |
17
(4) |
|
18
(4) |
19
(30) |
20
(22) |
21
(23) |
22
(29) |
23
(20) |
24
(12) |
|
25
(7) |
26
(33) |
27
(10) |
28
(12) |
29
(19) |
30
(15) |
31
(8) |
|
From: Johannes S. <Joh...@gm...> - 2009-01-27 23:33:16
|
Hi,
unfortunately unsubscribed users cannot send to your list, so I am
forwarding this after subscribing.
Short story: we have problems with zlib. No, not those problems.
Apparently, there are uninitialized bytes _in the middle_ of the buffer
filled by deflate().
Maybe someone can shed some light into the issue?
Thanks,
Dscho
---------- Forwarded message ----------
Date: Tue, 27 Jan 2009 22:52:39 +0100 (CET)
From: Johannes Schindelin <Joh...@gm...>
To: Linus Torvalds <tor...@li...>
Cc: zl...@gz..., val...@li...,
Mark Brown <br...@si...>, Jeff King <pe...@pe...>,
Junio C Hamano <gi...@po...>, Git Mailing List <gi...@vg...>
Subject: Re: Valgrind updates
Hi,
[Cc'ed the valgrind-users list, maybe the valgrind Gods can see that our
case is pretty strange, and tell us what we do wrong.]
Note to valgrind experts: this is _not_ about the Conditional thing in
zlib, but about an uninitialized byte _in the middle_ of the zlib output
buffer.
On Tue, 27 Jan 2009, Linus Torvalds wrote:
> Hmm. The zlib faq has a note about zlib doing a conditional on
> uninitialized memory that doesn't matter, and that is what the
> suppression should be about (to avoid a warning about "Conditional jump
> or move depends on uninitialised value").
>
> But that one is documented to not matter for the actual output (zlib
> FAQ#36).
>
> It's possible that zlib really does leave padding bytes around that
> literally don't matter, and that don't get initialized. That really
> would be bad, because it means that the output of git wouldn't be
> repeatable. But I doubt this is the case - original git used to actually
> do the SHA1 over the _compressed_ data, which was admittedly a totally
> and utterly broken design (and we fixed it), but it did work. Maybe it
> worked by luck, but I somehow doubt it.
>
> Some googling did find this:
>
> http://mailman.few.vu.nl/pipermail/sysprog/2008-October/000298.html
>
> which looks very similar: an uninitialized byte in the middle of a
> deflate() packet.
>
> Anyway, I'm just going to Cc 'zl...@gz...', since this definitely is
> _not_ the same issue as in the FAQ, and we're not the only ones seeing it.
>
> [...]
>
> Dscho wrote:
>
> > Yet, the buffer in question is 195 bytes, stream.total_count (which
> > totally agrees with size - stream.avail_out) says it is 58 bytes, and
> > valgrind says that the byte with offset 51 is uninitialized.
>
> The thing to note here is that what we are passing in to "write_buffer()"
> is _exactly_ what zlib deflated for us:
>
> - 'compressed' is the allocation, and is what we used to initialize
> 'stream.next_out' with (at the top of the code sequence above)
>
> - 'size' is gotten from 'stream.total_out' at the end of the compression.
>
> Oh Gods of zlib, please hear our plea for clarification..
To help ye Gods, I put together this almost minimal C program:
-- snip --
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <zlib.h>
int main(int argc, char **argv)
{
const char hdr[] = {
0x74, 0x72, 0x65, 0x65, 0x20, 0x31, 0x36, 0x35,
0x00,
};
int hdrlen = sizeof(hdr);
const char buf[] = {
0x31, 0x30, 0x30, 0x36, 0x34, 0x34, 0x20, 0x66,
0x69, 0x6c, 0x65, 0x31, 0x00, 0x10, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x31, 0x30, 0x30, 0x36, 0x34, 0x34, 0x20,
0x66, 0x69, 0x6c, 0x65, 0x32, 0x00, 0x20, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x31, 0x30, 0x30, 0x36, 0x34, 0x34,
0x20, 0x66, 0x69, 0x6c, 0x65, 0x33, 0x00, 0x30,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x31, 0x30, 0x30, 0x36, 0x34,
0x34, 0x20, 0x66, 0x69, 0x6c, 0x65, 0x34, 0x00,
0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x31, 0x30, 0x30, 0x36,
0x34, 0x34, 0x20, 0x66, 0x69, 0x6c, 0x65, 0x35,
0x00, 0x50, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00,
};
int len = sizeof(buf);
z_stream stream;
unsigned char *compressed;
int size, ret, i;
FILE *out;
memset(&stream, 0, sizeof(stream));
deflateInit(&stream, Z_BEST_SPEED);
size = 8 + deflateBound(&stream, len+hdrlen);
compressed = malloc(size);
if (!compressed)
return 1;
stream.next_out = compressed;
stream.avail_out = size;
stream.next_in = (unsigned char *)hdr;
stream.avail_in = hdrlen;
while ((ret = deflate(&stream, 0)) == Z_OK)
/* nothing */;
/* deflate() returns Z_BUF_ERROR at this point */
stream.next_in = (unsigned char *)buf;
stream.avail_in = len;
ret = deflate(&stream, Z_FINISH);
if (ret != Z_STREAM_END)
return 1;
if (deflateEnd(&stream) != Z_OK)
return 1;
out = fopen("/dev/null", "w");
fwrite(compressed + 51, 51, 1, out);
fwrite(compressed + 51, 1, 1, stderr);
fflush(out);
fclose(out);
free(compressed);
return 0;
}
-- snap --
... which produces this output...
-- snip --
==6348== Memcheck, a memory error detector.
==6348== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==6348== Using LibVEX rev exported, a library for dynamic binary translation.
==6348== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==6348== Using valgrind-3.5.0.SVN, a dynamic binary instrumentation framework.
==6348== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==6348== For more details, rerun with: -v
==6348==
==6348== Use of uninitialised value of size 8
==6348== at 0x4E2FC5B: (within /usr/lib/libz.so.1.2.3.3)
==6348== by 0x4E317B6: (within /usr/lib/libz.so.1.2.3.3)
==6348== by 0x4E2DF9C: (within /usr/lib/libz.so.1.2.3.3)
==6348== by 0x4E2E654: deflate (in /usr/lib/libz.so.1.2.3.3)
==6348== by 0x400957: main (valgrind-testcase.c:60)
==6348==
==6348== Syscall param write(buf) points to uninitialised byte(s)
==6348== at 0x5103D50: write (in /lib/libc-2.6.1.so)
==6348== by 0x50A9AE2: _IO_file_write (in /lib/libc-2.6.1.so)
==6348== by 0x50A9748: (within /lib/libc-2.6.1.so)
==6348== by 0x50A9A4B: _IO_file_xsputn (in /lib/libc-2.6.1.so)
==6348== by 0x509FDBA: fwrite (in /lib/libc-2.6.1.so)
==6348== by 0x4009D7: main (valgrind-testcase.c:69)
==6348== Address 0x53da87b is 51 bytes inside a block of size 195 alloc'd
==6348== at 0x4C222CB: malloc (in /usr/local/lib/valgrind/amd64-linux/vgpreload_memcheck.so)
==6348== by 0x4008D7: main (valgrind-testcase.c:45)
,==6348==
==6348== Syscall param write(buf) points to uninitialised byte(s)
==6348== at 0x5103D50: write (in /lib/libc-2.6.1.so)
==6348== by 0x50A9AE2: _IO_file_write (in /lib/libc-2.6.1.so)
==6348== by 0x50A9748: (within /lib/libc-2.6.1.so)
==6348== by 0x50A9A83: _IO_do_write (in /lib/libc-2.6.1.so)
==6348== by 0x50AA048: _IO_file_sync (in /lib/libc-2.6.1.so)
==6348== by 0x509EDB9: fflush (in /lib/libc-2.6.1.so)
==6348== by 0x4009E0: main (valgrind-testcase.c:70)
==6348== Address 0x4020000 is not stack'd, malloc'd or (recently) free'd
==6348==
==6348== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 15 from 4)
==6348== malloc/free: in use at exit: 0 bytes in 0 blocks.
==6348== malloc/free: 7 allocs, 7 frees, 268,835 bytes allocated.
==6348== For counts of detected errors, rerun with: -v
==6348== Use --track-origins=yes to see where uninitialised values come from
==6348== All heap blocks were freed -- no leaks are possible.
-- snap --
Note that the error only occurs when fwrite()ing to stderr, not
any other file.
This is with valgrind compiled from a git-svn mirror updated today, i.e.
valgrind-3.5.0.SVN.
Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to maj...@vg...
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
|
From: Konstantin S. <kon...@gm...> - 2009-01-27 14:04:36
|
On Tue, Jan 27, 2009 at 5:25 AM, Nicholas Nethercote <n.n...@gm...> wrote: > On Sat, Jan 24, 2009 at 7:54 AM, Rodrigo Dominguez <ro...@ho...> wrote: >> I realize it's a bit early to ask but is Valgrind planning to participate in >> this year's Google Summer of Code? A few students in my group spent last >> summer hacking some of the code and I think participating in the SoC would >> be a nice next step. I'm _really_ interested in that! I have some ideas >> myself and I am also open to suggestions. > > We've never participated. We have a suggested projects page > (http://www.valgrind.org/help/projects.html) with projects of varying > quality. It could be a good fit... Nick, Julian, The page mentioned by Nick looks partially outdated. At least few items (--track-origins=yes, C++ demangler) are already implemented. It would be nice to update the page with fresh ideas before SoC. --kcc (@google.com) > > Nick > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Bart V. A. <bar...@gm...> - 2009-01-27 11:08:05
|
Hello, Regarding the nightly PPC build: this nightly build will work again as soon as the system this build is run on is operational again. The following message appears currently when logging in on the cellbuzz cluster: *** Submitting jobs to the cell nodes is currently not working, due to our PBS Pro license expiring. We are working with Altair to get it renewed. Thank you for your patience. *** Bart. ---------- Forwarded message ---------- From: Bart Van Assche <bar...@gm...> Date: Fri, Jan 23, 2009 at 5:48 PM Subject: [Valgrind-developers] 2009-01-23 02:00:01 EST nightly build (georgia-tech-cellbuzz-native, cellbuzz, ppc64, Fedora 7, native) To: val...@li... Nightly build on georgia-tech-cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) started at 2009-01-23 02:00:01 EST Results differ from 24 hours ago Checking out valgrind source tree ... failed Last 20 lines of verbose log follow echo Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2009-01-23T02:00:01} valgrind Job ID = 20666.cell-user cat: cmd-output.txt: No such file or directory ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... failed Last 20 lines of verbose log follow echo Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2009-01-22T02:00:01} valgrind Job ID = 20661.cell-user cat: cmd-output.txt: No such file or directory ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Jan 23 11:47:58 2009 --- new.short Fri Jan 23 11:48:08 2009 *************** *** 5,8 **** ! Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2009-01-22T02:00:01} valgrind ! Job ID = 20661.cell-user cat: cmd-output.txt: No such file or directory --- 5,8 ---- ! Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2009-01-23T02:00:01} valgrind ! Job ID = 20666.cell-user cat: cmd-output.txt: No such file or directory |
|
From: Ashley P. <as...@pi...> - 2009-01-27 09:46:36
|
On Mon, 2009-01-26 at 14:28 +0000, Tom Hughes wrote: > Julian Seward wrote: > > > I'm doing some merging of stuff into 3_4_BRANCH. Before I commit > > every merge I like to do svn diff -rHEAD to see what I'm about > > to commit. In a trunk tree that works as expected. However, in a > > 3_4_BRANCH tree I get a load of other output too, which I don't > > understand. > > > > The unexpected output is shown below. Is it significant? > > What does it mean? And how can I get rid of it? > > The svn:mergeinfo property is used by recent versions of subversion to > track what merges have been done - it means that if you merge a branch a > second time it knows which edits have already been merged and doesn't > need to do them again. > > It may well be entirely normal for it to be deleted sometimes during a > merge - I don't really have enough experience with it to know. I read this to mean that the 3_4_BRANCH has had something merged to it but the HEAD has not, in which case it could be safely ignored. Ashley, |
|
From: Konstantin S. <kon...@gm...> - 2009-01-27 05:13:36
|
On Tue, Jan 27, 2009 at 12:46 AM, Nicholas Nethercote <n.n...@gm...> wrote: > On Tue, Jan 27, 2009 at 2:45 AM, Konstantin Serebryany > <kon...@gm...> wrote: >> >> Did you ever think that two data race detectors (Helgrind and Drd) is >> too much for the Valgrind project? >> In fact, I think that two is too few. :) >> >> Please welcome ThreadSanitizer, yet another data race detector based >> on Valgrind. >> http://code.google.com/p/data-race-test/wiki/ThreadSanitizer >> >> I'd appreciate your feedback, > > How similar is it to Helgrind http://code.google.com/p/data-race-test/wiki/ThreadSanitizerVsOthers > -- could it conceivably be folded into Helgrind? Yes, and I will be glad if it does! --kcc > > Nick > |
|
From: Nicholas N. <n.n...@gm...> - 2009-01-27 04:26:26
|
On Tue, Jan 20, 2009 at 6:33 AM, Greg Parker <gp...@ap...> wrote: > > I think Xcode is able to build dwarf-in-executable, but I don't know what > options or programs it uses to do that. I tried using Xcode. It has three options for debug info: stabs, DWARF, DWARF + dSYM. The DWARF seems to be exactly the same as DWARF + dSYM except that it doesn't create the .dSYM directory -- ie. it doesn't put the debug info in the executable, just the object files, which isn't much help. Frustrating. Nick |
|
From: Tom H. <th...@cy...> - 2009-01-27 03:47:45
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2009-01-27 03:20:05 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 486 tests, 1 stderr failure, 0 stdout failures, 0 post failures == memcheck/tests/x86-linux/scalar (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 481 tests, 1 stderr failure, 0 stdout failures, 0 post failures == memcheck/tests/x86-linux/scalar (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Jan 27 03:33:54 2009 --- new.short Tue Jan 27 03:47:34 2009 *************** *** 8,10 **** ! == 481 tests, 1 stderr failure, 0 stdout failures, 0 post failures == memcheck/tests/x86-linux/scalar (stderr) --- 8,10 ---- ! == 486 tests, 1 stderr failure, 0 stdout failures, 0 post failures == memcheck/tests/x86-linux/scalar (stderr) |
|
From: Tom H. <th...@cy...> - 2009-01-27 03:44:20
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-01-27 03:05:07 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 477 tests, 6 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) memcheck/tests/x86-linux/scalar (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 472 tests, 6 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) memcheck/tests/x86-linux/scalar (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Jan 27 03:24:47 2009 --- new.short Tue Jan 27 03:44:11 2009 *************** *** 8,10 **** ! == 472 tests, 6 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) --- 8,10 ---- ! == 477 tests, 6 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) |
|
From: Tom H. <th...@cy...> - 2009-01-27 03:32:09
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-01-27 03:10:07 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 483 tests, 5 stderr failures, 2 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/x86-linux/scalar (stderr) none/tests/mremap2 (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 478 tests, 5 stderr failures, 2 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/x86-linux/scalar (stderr) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Jan 27 03:21:04 2009 --- new.short Tue Jan 27 03:32:01 2009 *************** *** 8,10 **** ! == 478 tests, 5 stderr failures, 2 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) --- 8,10 ---- ! == 483 tests, 5 stderr failures, 2 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) |
|
From: Nicholas N. <n.n...@gm...> - 2009-01-27 02:59:06
|
On Sat, Jan 24, 2009 at 7:54 AM, Rodrigo Dominguez <ro...@ho...> wrote: > I realize it's a bit early to ask but is Valgrind planning to participate in > this year's Google Summer of Code? A few students in my group spent last > summer hacking some of the code and I think participating in the SoC would > be a nice next step. I'm _really_ interested in that! I have some ideas > myself and I am also open to suggestions. We've never participated. We have a suggested projects page (http://www.valgrind.org/help/projects.html) with projects of varying quality. It could be a good fit... Nick |