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
(17) |
2
(21) |
3
(17) |
4
(28) |
5
(21) |
6
(11) |
|
7
(13) |
8
(21) |
9
(21) |
10
(9) |
11
(11) |
12
(15) |
13
(23) |
|
14
(15) |
15
(22) |
16
(28) |
17
(12) |
18
(15) |
19
(8) |
20
(7) |
|
21
(8) |
22
(12) |
23
(13) |
24
(7) |
25
(7) |
26
(3) |
27
(9) |
|
28
(13) |
29
(7) |
30
(7) |
31
(9) |
|
|
|
|
From: KJK::Hyperion <no...@li...> - 2004-03-03 21:52:50
|
At 10.23 02/03/2004, Nicholas Nethercote wrote: >>>I think that nothing short of a full fork of Valgrind will do >>I get that feeling too. >Same here. Not only does Windows have rather, er, interesting >architectural features, Actually, the kernel is pretty straightforward - Linux 2.6 comes pretty close to it in features and architecture. The problem is that the kernel is too far from the applications. Example: the socket functions are implemented by an user-mode multiplexer, and it's only the *default* implementation that processes them in kernel mode, and anyway they get there as IOCTLs. This makes it very difficult to validate the use an application is making of BSD sockets >you would be fighting its closedness the whole way. Sounds like a nightmare. sounds like real fun, to me :-) but I'm involved in ReactOS (<http://reactos.com/>), so I may be biased |
|
From: Julian S. <js...@ac...> - 2004-03-03 19:56:38
|
> reported errors a lot. Glibc seems to like using the add-fefefeff > and or-7f7f7f7f tricks a lot. I have a formula for getting the > valid bits for the result of an ADD exactly without too much effort. Ha! Tell me what it is (pretty please). I have been wondering how to do that for a long time, without success, since it would also improve accuracy on x86. > * I punted on VG_(saneUInstr) for now. I really should go back and > fill in the parts for the new UInstrs I added. Yes ... do. You'd be amazed how many hours of debugging saneUInstr has saved us collectively. J |
|
From: Julian S. <js...@ac...> - 2004-03-03 19:46:37
|
On Wednesday 03 March 2004 19:29, Madhu M Kurup wrote: > Doug Rabson <df...@nl...> said on March 3,2004: > > On Wed, 2004-03-03 at 11:51, Nicholas Nethercote wrote: > > > [Hmm... Doug -- would you be interested in doing the same with your > > > x86/BSD patch?] > > > > My subversion tree is publically accessible. You can check out my > > 'reasonably stable' tree (based on valgrind cvs from about 10th > > January) with: > > I can second that. The FreeBSD port works well - there are a few edge > cases ( zombie processes and getting stuck in poll loops), but mostly, > it works perfectly. In that case, can one or the other of you use the autotest scripts in nightly/ to run overnight tests, so we can monitor the status? For that matter, doing the same for the ppc port wouldn't be a bad idea. Thanks, J |
|
From: Julian S. <js...@ac...> - 2004-03-03 19:44:48
|
> > A patch against valgrind-2.1.0 to add PowerPC support is at: > > > > http://ozlabs.org/~paulus/ppc-valgrind.patch.gz Amazing. /me is also impressed. How much work was it? > I just had a quick look. Here are some thoughts that pop immediately into > my head: > > - Could you write up a description of the main changes you made, which > parts were affected a lot, which parts weren't affected much, anything > you've learnt? No substitute for reading the entire patch, but valuable > as a high-level introduction. Request seconded by me ... > - Some big changes have been made ("full virtualization") since 2.1.0. I > don't know how much these changes would affect your patch. > > - How much have you tested it? Does it run big programs like OpenOffice > and Mozilla? Does it pass all the regression tests? ("make regtest") Yes, this is critical. How stable is it? > - All the #ifdef-ery is ugly, as you say. In particular, it will be > painfully obvious to you that UCode is heavily geared towards x86. I > see you've had to add 17 new UInstrs. And handling Altivec would > require more (and you can see how awful the MMX/SSE UInstrs are). > > Julian, Jeremy and I have given quite a lot of thought to architecture > ports. The key requirement, in our minds, is that we don't want an NxM > code explosion, where N is the number of architectures, and M is the > number of skins. (Also, factor in a xP for P different operating > systems.) With the "fat UCode" approach you've taken, you unfortunately > have this problem, as you've seen with all the skin changes that were > required. We need to make a strategic decision about porting soon. If we do nothing someone for sure will do basically the same as Paul has done, but for AMD64, and then we will surely be in #ifdef hell. > As a first step, would you be interested in bundling it up (with "make > dist") and putting it somewhere so people can try it? I can link to it > from the Valgrind page. Yes, good plan. Let others hammer on it a bit and see how it holds together. Congratulations on excellent hackery. J |
|
From: Madhu M K. <mm...@ya...> - 2004-03-03 19:16:35
|
Doug Rabson <df...@nl...> said on March 3,2004: > On Wed, 2004-03-03 at 11:51, Nicholas Nethercote wrote: > > > > > [Hmm... Doug -- would you be interested in doing the same with your > > x86/BSD patch?] > > My subversion tree is publically accessible. You can check out my > 'reasonably stable' tree (based on valgrind cvs from about 10th > January) with: I can second that. The FreeBSD port works well - there are a few edge cases ( zombie processes and getting stuck in poll loops), but mostly, it works perfectly. Cheerio, M Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
From: Doug R. <df...@nl...> - 2004-03-03 17:29:08
|
On Wed, 2004-03-03 at 11:51, Nicholas Nethercote wrote: > > [Hmm... Doug -- would you be interested in doing the same with your > x86/BSD patch?] My subversion tree is publically accessible. You can check out my 'reasonably stable' tree (based on valgrind cvs from about 10th January) with: $ svn co svn://svn.rabson.org/repos/valgrind/branches/dfr \ valgrind or you can look at the tree I've been syncing to a more recent valgrind cvs (29th February) with: $ svn co svn://svn.rabson.org/repos/valgrind/branches/dfr-merge \ valgrind I haven't been making public snapshots on a regular basis since I'm still fixing stuff on a fairly regular basis and the few people I've been testing this stuff with seem happy using subversion to keep in sync. |
|
From: Nicholas N. <nj...@ca...> - 2004-03-03 17:08:15
|
CVS commit by nethercote:
Added Coin.
M +3 -0 users.html 1.52
--- devel-home/valgrind/users.html #1.51:1.52
@@ -151,4 +151,7 @@
and visualization.
+<dt><a href="http://www.coin3d.org/">Coin</a>
+<dd>Multi-platform scene graph library for realtime 3D graphics.
+
<dt><a href="http://www.paraview.org/">ParaView</a>
<dd>A visualizer for large data sets.
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-03 11:57:17
|
On Wed, 3 Mar 2004, Paul Mackerras wrote: > I have ported valgrind to PowerPC and I have it running quite nicely, > on Linux of course. > > A patch against valgrind-2.1.0 to add PowerPC support is at: > > http://ozlabs.org/~paulus/ppc-valgrind.patch.gz Wow. I'm impressed! > It would be good if you (valgrind developers) could look at the patch > and give me any comments you have. I would like to get this stuff > included in future releases. > > I have ended up putting in quite a few ifdefs in the code, as that was > the quickest way to make the changes I needed to get it working on > PowerPC. Now that it is working I think it would be worth looking > over what things need to be abstracted out and what might be the best > way to do that. Hopefully that will reduce the number of ifdefs. > > There are still a few limitations and things left to do: > > * It only supports 32-bit instructions at present (doesn't handle the > 64-bit part of the PowerPC architecture). > > * It doesn't handle Altivec instructions (Altivec provides > short-vector SIMD capabilities, a bit like MMX or SSE). I just had a quick look. Here are some thoughts that pop immediately into my head: - Could you write up a description of the main changes you made, which parts were affected a lot, which parts weren't affected much, anything you've learnt? No substitute for reading the entire patch, but valuable as a high-level introduction. - Some big changes have been made ("full virtualization") since 2.1.0. I don't know how much these changes would affect your patch. - How much have you tested it? Does it run big programs like OpenOffice and Mozilla? Does it pass all the regression tests? ("make regtest") - All the #ifdef-ery is ugly, as you say. In particular, it will be painfully obvious to you that UCode is heavily geared towards x86. I see you've had to add 17 new UInstrs. And handling Altivec would require more (and you can see how awful the MMX/SSE UInstrs are). Julian, Jeremy and I have given quite a lot of thought to architecture ports. The key requirement, in our minds, is that we don't want an NxM code explosion, where N is the number of architectures, and M is the number of skins. (Also, factor in a xP for P different operating systems.) With the "fat UCode" approach you've taken, you unfortunately have this problem, as you've seen with all the skin changes that were required. Finding a design that supports multiple architectures without requiring skin rewriting is extremely challenging. We have a Wiki (www.goop.org/twiki/bin/view/Valgrind/ValgrindFutures) where we've discussed various things. Much of it is 6--9 months old, and a bit out of date. But the "IrKnowledge" and "IrOpinions" pages show some of our current thinking; they are a distillation of several failed half-attempts to come up with a concrete design. So I'm personally not convinced the approach you've taken is the right way to go -- it might be acceptable for two architectures, but what happens when someone wants a SPARC port, or an ARM port, etc? Obviously there must be some architecture-specific bits (eg. asm disassembly and code-regeneration), but keeping those bits separate from the skins seems, to me, crucial. Anyway, I congratulate you heartily for undertaking such a big task. Even if your patch doesn't get included as-is, it should provide an extremely valuable base for further work. I won't say more for the moment; I'll be interested to see what other people think. As a first step, would you be interested in bundling it up (with "make dist") and putting it somewhere so people can try it? I can link to it from the Valgrind page. [Hmm... Doug -- would you be interested in doing the same with your x86/BSD patch?] N |
|
From: Paul M. <pa...@sa...> - 2004-03-03 11:20:40
|
I have ported valgrind to PowerPC and I have it running quite nicely, on Linux of course. A patch against valgrind-2.1.0 to add PowerPC support is at: http://ozlabs.org/~paulus/ppc-valgrind.patch.gz I didn't include the patch in this message because it is moderately large (280kB uncompressed) and I thought the mailing list software might reject it. It would be good if you (valgrind developers) could look at the patch and give me any comments you have. I would like to get this stuff included in future releases. I have ended up putting in quite a few ifdefs in the code, as that was the quickest way to make the changes I needed to get it working on PowerPC. Now that it is working I think it would be worth looking over what things need to be abstracted out and what might be the best way to do that. Hopefully that will reduce the number of ifdefs. There are still a few limitations and things left to do: * It only supports 32-bit instructions at present (doesn't handle the 64-bit part of the PowerPC architecture). * It doesn't handle Altivec instructions (Altivec provides short-vector SIMD capabilities, a bit like MMX or SSE). * I haven't generated any suppressions files for libc.so or ld.so. I seem to get lots of errors from them, particularly for programs that use dlopen. I have some prototype code to improve the valid bit computations for ADD and CMP0 (compare against 0) which reduce the reported errors a lot. Glibc seems to like using the add-fefefeff and or-7f7f7f7f tricks a lot. I have a formula for getting the valid bits for the result of an ADD exactly without too much effort. * The code to set cache parameters in cachegrind is pretty minimal at present. * I punted on VG_(saneUInstr) for now. I really should go back and fill in the parts for the new UInstrs I added. Regards, Paul. |
|
From: Tom H. <th...@cy...> - 2004-03-03 11:13:41
|
In message <1078264996.1032.10.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Tue, 2004-03-02 at 01:53, Tom Hughes wrote:
>> This doesn't appear to work. I think the problem is that recent
>> versions of glibc will ignore AT_SYSINFO unless AT_SYSINFO_EHDR is
>> also set - maybe this is what bug 73891 is about?
>
> That would be annoying. I'm not really sure what to put for the ehdr.
Well it needs to be a pointer to a valid ELF header whose entry
point is the address of the sysinfo routine. The easiest way to
do it might be to actually build a separate shared object that
valgrind could map into the client address space in the same way
the 2.6 kernels do. More details of how it works can be found at:
http://lwn.net/Articles/30258/
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: <js...@ac...> - 2004-03-03 04:12:09
|
Nightly build on phoenix ( SuSE 8.2 ) started at 2004-03-03 04:00:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow resolv: valgrind ./resolv seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 125 tests, 5 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: <js...@ac...> - 2004-03-03 03:55:44
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-03-03 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-03-03 03:27:44
|
Nightly build on dunsmere ( Fedora Core 1 ) started at 2004-03-03 03:20:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 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) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-03 03:23:08
|
Nightly build on audi ( Red Hat 9 ) started at 2004-03-03 03:15:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow pth_blockedsig: valgrind ./pth_blockedsig rcl_assert: valgrind ./rcl_assert rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts 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, 1 stderr failure, 0 stdout failures ================= helgrind/tests/inherit (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-03 03:18:05
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-03-03 03:10:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts 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, 6 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-03 03:15:32
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-03-03 03:00:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 126 tests, 12 stderr failures, 5 stdout failures ================= corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/pth_atfork1 (stdout) corecheck/tests/pth_atfork1 (stderr) corecheck/tests/pth_cancel2 (stderr) corecheck/tests/pth_cvsimple (stdout) corecheck/tests/pth_cvsimple (stderr) corecheck/tests/pth_exit (stderr) corecheck/tests/res_search (stdout) helgrind/tests/inherit (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) none/tests/pth_blockedsig (stdout) none/tests/pth_blockedsig (stderr) none/tests/yield (stdout) none/tests/yield (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-03-03 03:13:00
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-03-03 03:05: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, 12 stderr failures, 3 stdout failures ================= corecheck/tests/fdleak_creat (stderr) corecheck/tests/pth_atfork1 (stdout) corecheck/tests/pth_atfork1 (stderr) corecheck/tests/res_search (stdout) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/mismatches (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |