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
(15) |
3
(36) |
4
(24) |
5
(36) |
|
6
(18) |
7
(16) |
8
(18) |
9
(19) |
10
(18) |
11
(37) |
12
(18) |
|
13
(13) |
14
(21) |
15
(27) |
16
(10) |
17
(16) |
18
(25) |
19
(21) |
|
20
(11) |
21
(14) |
22
(6) |
23
(15) |
24
(27) |
25
(3) |
26
(9) |
|
27
(16) |
28
(24) |
29
(21) |
30
(43) |
31
(42) |
|
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-27 19:25:32
|
On Sun, 27 Mar 2005, Julian Seward wrote: >> VG_(init_post_clo_init) ( & ac_post_clo_init ); >> VG_(init_instrument) ( & ac_instrument ); >> VG_(init_handle_client_request)( & ac_handle_client_request ); >> >> (That's slightly different your suggestion of passing a struct of function >> pointers, but very similar.) > > Jeremy's approach sounds cleaner: just call the tool's init function > and you get back a pointer to a "dictionary" -- a struct full of > fn pointers, with NULLs where the tool doesn't want to override the > core. > > The "register" approach means (if I understand correctly) that > the tool's init function is called, resulting in a bunch of calls > back to the core to register functions; eventually the tool init > fn returns. That sounds more complex (mutable state; more complex > control flow) and I'm not sure what the benefit is. One problem with the dictionary approach is that you are exposing the internals of the struct to tools. I avoided this approach with the 'needs' and 'details' structs for just this reason. > In fact, couldn't this idea be used to almost completely decouple > the tool and core, by passing dictionaries in both directions? > > At startup, the core finds the tool's init fn using dlsym, and > calls it, handing it a dictionary of all core fns which the tool > can have access to. And the returned value is a pointer to the > tool's core-visible dictionary, as already discussed. You certainly could. The tool would still have to import a lot of types and macros from the core. N |
|
From: Julian S. <js...@ac...> - 2005-03-27 19:20:14
|
> Jeremy's approach sounds cleaner: just call the tool's init function > and you get back a pointer to a "dictionary" -- a struct full of > fn pointers, with NULLs where the tool doesn't want to override the > core. In fact, couldn't this idea be used to almost completely decouple the tool and core, by passing dictionaries in both directions? At startup, the core finds the tool's init fn using dlsym, and calls it, handing it a dictionary of all core fns which the tool can have access to. And the returned value is a pointer to the tool's core-visible dictionary, as already discussed. J |
|
From: Julian S. <js...@ac...> - 2005-03-27 19:10:28
|
> > I was hoping to drop all the magic symbol stuff altogether. I would > > prefer it if each tool .so had only a single special symbol to an init > > function; that init function would then call a core function passing a > > structure full of pointers to functions for all its tool functions. That sounds great to me. > I see. So in the same way tools register their 'tracking' functions, eg: > > VG_(init_new_mem_startup) ( & ac_new_mem_startup ); > VG_(init_new_mem_stack_signal) ( & ac_make_accessible ); > > they could do the same things for all the other functions, eg: > > VG_(init_post_clo_init) ( & ac_post_clo_init ); > VG_(init_instrument) ( & ac_instrument ); > VG_(init_handle_client_request)( & ac_handle_client_request ); > > (That's slightly different your suggestion of passing a struct of function > pointers, but very similar.) Jeremy's approach sounds cleaner: just call the tool's init function and you get back a pointer to a "dictionary" -- a struct full of fn pointers, with NULLs where the tool doesn't want to override the core. The "register" approach means (if I understand correctly) that the tool's init function is called, resulting in a bunch of calls back to the core to register functions; eventually the tool init fn returns. That sounds more complex (mutable state; more complex control flow) and I'm not sure what the benefit is. So I vote for the dictionary approach -- assuming I understand this right. J |
|
From: Nicholas N. <nj...@cs...> - 2005-03-27 18:09:48
|
On Sun, 27 Mar 2005, Jeremy Fitzhardinge wrote:
>> - We're relying heavily on dlsym(), which the 2.0.0 approach did not.
>
> I was hoping to drop all the magic symbol stuff altogether. I would prefer
> it if each tool .so had only a single special symbol to an init function;
> that init function would then call a core function passing a structure full
> of pointers to functions for all its tool functions. I don't really like all
> this implicit behaviour based on what symbols happen to exist. I intended
> the dlsym() stuff to be a backwards compatibility thing which would go away
> once all the tools had been converted.
I see. So in the same way tools register their 'tracking' functions, eg:
VG_(init_new_mem_startup) ( & ac_new_mem_startup );
VG_(init_new_mem_stack_signal) ( & ac_make_accessible );
they could do the same things for all the other functions, eg:
VG_(init_post_clo_init) ( & ac_post_clo_init );
VG_(init_instrument) ( & ac_instrument );
VG_(init_handle_client_request)( & ac_handle_client_request );
(That's slightly different your suggestion of passing a struct of function
pointers, but very similar.)
It's marginally more verbose, but you're right that it is better than all
the dlsym stuff. Good idea.
(Actually, we have an awkward mix now -- most of the SK_ functions are
done with dlsym, but the 'tracking' ones are done with function pointers.
Yuk.)
>> - It seems like a lot of the stuff in vg_toolint.c and vg_toolint.h is
>> global when it doesn't need to be. For example, the VG_(missing_*)() and
>> VG_(defined_*)() functions can be made local to vg_toolint.c. This is
>> probably just a matter of tweaking the auto-generation script
>> gen_toolint.pl.
>
> The defined_* ones are used all over the place from its use in the VG_TRACK()
> macro. missing_* need to be global because they're weak symbols which can be
> overridden. The default missing_* functions are in vg_toolint.c, but
> vg_default.c defines some replacements. This should probably be implemented
> by replacing pointers to functions rather than using linker tricks.
You're right about the defined_* ones, but the missing_* ones can be
removed. They don't need to be weak either. But it's all irrelevant if
we switch to using function pointers.
>> - Jeremy, in vg_pthreadmodel.c you call SK_(malloc)() -- why?
>
> The pthread_create code wants to allocate some memory in the client which the
> client can free via VG_USERREQ_FREE. I had to make a couple of small changes
> so this would work for both malloc-replacing and non-malloc-replacing tools.
Ah crap, I recently removed VG_USERREQ_{MALLOC,FREE} from the SVN repo
because they weren't being used.
But what is this memory that's being allocated by pthread_create() for?
Will the client have to use VG_USERREQ_FREE for the thread-modelling to
not leak memory? That would not be nice.
N
|
|
From: Jeremy F. <je...@go...> - 2005-03-27 17:05:07
|
Nicholas Nethercote wrote:
> This involves redefining the meaning of "SK_()" in core.h to prefix
> "vgSkinInternal_", instead of "vgSkin_". There is a lot of other
> stuff in vg_toolint.c for providing default definitions which
> immediately abort, etc. The files vg_toolint.[ch] are auto-generated.
>
> This all took me a while to figure out. There were a few aspects that
> puzzled me.
>
> - The two different meanings of SK_() were really confusing, and
> probably doubled the amount of time it took me to work this all out.
Yeah, that seems a bit bogus. I guess it could have the same
definitions in both tools and core, and you'd simply get a pair of
functions for each tool interface - one in the tool, and one in the
core. Or changing all the core SK_() references to some other prefix macro.
> - We're relying heavily on dlsym(), which the 2.0.0 approach did not.
> Is there a good reason why dlsym() must be used rather than
> LD_PRELOAD? I ask because we use LD_PRELOAD for the vgpreload_foo.so
> files -- can we not use it for the normal vgtool_foo.so files also?
> The use of one mechanism (LD_PRELOAD) would be preferable to the use
> of two (dlsym + LD_PRELOAD), no?
I was hoping to drop all the magic symbol stuff altogether. I would
prefer it if each tool .so had only a single special symbol to an init
function; that init function would then call a core function passing a
structure full of pointers to functions for all its tool functions. I
don't really like all this implicit behaviour based on what symbols
happen to exist. I intended the dlsym() stuff to be a backwards
compatibility thing which would go away once all the tools had been
converted.
LD_PRELOAD won't work for loading the tools because we'd need to set it
before starting valgrind in the first place, but we don't know what tool
to use at that point. You could probably do it by shifting more
command-line parsing into stage1 and have it hack on the environment,
but I'd prefer to keep stage1 as simple as possible.
> - It seems like a lot of the stuff in vg_toolint.c and vg_toolint.h is
> global when it doesn't need to be. For example, the VG_(missing_*)()
> and VG_(defined_*)() functions can be made local to vg_toolint.c.
> This is probably just a matter of tweaking the auto-generation script
> gen_toolint.pl.
The defined_* ones are used all over the place from its use in the
VG_TRACK() macro. missing_* need to be global because they're weak
symbols which can be overridden. The default missing_* functions are in
vg_toolint.c, but vg_default.c defines some replacements. This should
probably be implemented by replacing pointers to functions rather than
using linker tricks.
> - Jeremy, in vg_pthreadmodel.c you call SK_(malloc)() -- why? I'm not
> sure what you're doing there, and I think the SK_(malloc)() in
> vg_default.c might not be getting called, because it relied on the
> 2.0.0-style use of the 'weak' attribute. But I'm really not sure.
> How does that vg_pthreadmodel.c code work? I'd really like to remove
> SK_(malloc)() and SK_(free)() from vg_default.c, now that libpthread
> isn't around to use them.
The pthread_create code wants to allocate some memory in the client
which the client can free via VG_USERREQ_FREE. I had to make a couple
of small changes so this would work for both malloc-replacing and
non-malloc-replacing tools.
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-27 16:37:06
|
Hi, I just spent some time learning how SK_(foo) functions are called. It's a lot more complex than I realised. In v2.0.0 and earlier, we had default definitions of all these functions, such as SK_(instrument)(), in vg_default.c. They were defined with the 'weak' attribute. If the tool had a function called SK_(instrument)(), that would override the one in vg_default.c due to the tool.so being put in LD_PRELOAD. If a tool forgot to provide a function it should have, the default version would end up getting called and it just aborted with an error message. Since v2.1.0, things have gotten more complex. Now, main() calls VG_(tool_init_dlsym)(). It uses dlsym() to find all the functions like vgSkin_instrument() that the core provides. It puts pointers to these functions into a struct called VG_(tool_interface)(). vg_toolint.c then provides functions such as vgSkinInternal_instrument(), which just call vgSkin_instrument() via the pointer in VG_(tool_interface). This involves redefining the meaning of "SK_()" in core.h to prefix "vgSkinInternal_", instead of "vgSkin_". There is a lot of other stuff in vg_toolint.c for providing default definitions which immediately abort, etc. The files vg_toolint.[ch] are auto-generated. This all took me a while to figure out. There were a few aspects that puzzled me. - The two different meanings of SK_() were really confusing, and probably doubled the amount of time it took me to work this all out. - We're relying heavily on dlsym(), which the 2.0.0 approach did not. Is there a good reason why dlsym() must be used rather than LD_PRELOAD? I ask because we use LD_PRELOAD for the vgpreload_foo.so files -- can we not use it for the normal vgtool_foo.so files also? The use of one mechanism (LD_PRELOAD) would be preferable to the use of two (dlsym + LD_PRELOAD), no? - It seems like a lot of the stuff in vg_toolint.c and vg_toolint.h is global when it doesn't need to be. For example, the VG_(missing_*)() and VG_(defined_*)() functions can be made local to vg_toolint.c. This is probably just a matter of tweaking the auto-generation script gen_toolint.pl. - Jeremy, in vg_pthreadmodel.c you call SK_(malloc)() -- why? I'm not sure what you're doing there, and I think the SK_(malloc)() in vg_default.c might not be getting called, because it relied on the 2.0.0-style use of the 'weak' attribute. But I'm really not sure. How does that vg_pthreadmodel.c code work? I'd really like to remove SK_(malloc)() and SK_(free)() from vg_default.c, now that libpthread isn't around to use them. I'm sure there are good reasons for all this, they just weren't obvious to me from the code. Any explanations would be appreciated! Thanks. N |
|
From: Julian S. <js...@ac...> - 2005-03-27 13:26:56
|
> But with valgrind 3.0.0.SVN, I get this: > > valgrind: fatal error: unsupported CPU. > Supported CPUs are: > * x86 with SSE state (Pentium II or above, AMD Athlon or above) > > Is this a problem in valgrind 3.0, or a missing restriction in the 3.0 > documentation? Should I file a bug report about this? The 3.0 line should work on PIIs, but I don't have one to test it on, hence I'm not surprised there's a problem. Have a poke around in coregrind/x86/state.c, function VGA_(getArchAndSubArch). It should be that have_sse0 is set to True and have_sse1 and have_sse2 are set to False, but I guess that is not happening right. J |
|
From: Jeroen N. W. <jn...@xs...> - 2005-03-27 13:06:10
|
I seem to have run into a problem in the portability of valgrind 3.0. On my box, valgrind 2.4.0 from cvs runs 'make regtest' as in the nightly build (audi, Red Hat 9), with only memcheck/tests/scalar failing due to a mismatch in line numbers. [diff attached] Also, a number of tests fail their prereqs: insn_mmxext: (skipping, prereq failed: ../../../tests/cputest x86-mmxext) insn_sse: (skipping, prereq failed: ../../../tests/cputest x86-sse) insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) But with valgrind 3.0.0.SVN, I get this: valgrind: fatal error: unsupported CPU. Supported CPUs are: * x86 with SSE state (Pentium II or above, AMD Athlon or above) [Full verbose output of one test attached.] $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 3 model name : Pentium II (Klamath) stepping : 3 cpu MHz : 233.866 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov mmx bogomips : 466.94 Is this a problem in valgrind 3.0, or a missing restriction in the 3.0 documentation? Should I file a bug report about this? Jeroen. |
|
From: Jeremy F. <je...@go...> - 2005-03-27 07:59:28
|
Nicholas Nethercote wrote:
> struct ThreadState includes the following fields:
>
> UInt stack_size;
> Addr stack_base;
> Addr stack_highest_word;
>
> struct os_state_t (for linux) includes the following fields:
>
> UInt *stack; /* stack base */
> UInt stacksize; /* stack size in UInts */
>
> Is there some overlap here that could be removed? AFAICT,
> ThreadState.stack_base is not used in any meaningful way and could be
> removed. Is one of these stacks for Valgrind and the other for the
> client? It's unclear from the field names.
Yeah, the os_state ones are the Valgrind internal stack, and the ones in
ThreadState are the client stack. ThreadState.stack_base probably isn't
meaningful because we don't allocate client stacks and the useful range
for a stack is between the stackpointer and the top.
So: both sets are needed, but their meanings clarified; stack_base can go.
J
|
|
From: <js...@ac...> - 2005-03-27 03:05:39
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-03-27 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmx: valgrind ./insn_mmx insn_mmxext: (skipping, prereq failed: ../../../tests/cputest x86-mmxext) insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 201 tests, 5 stderr failures, 0 stdout failures ================= memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) corecheck/tests/fdleak_fcntl (stderr) make: *** [regtest] Error 1 |
|
From: Nicholas N. <nj...@cs...> - 2005-03-27 02:51:40
|
Jeremy,
struct ThreadState includes the following fields:
UInt stack_size;
Addr stack_base;
Addr stack_highest_word;
struct os_state_t (for linux) includes the following fields:
UInt *stack; /* stack base */
UInt stacksize; /* stack size in UInts */
Is there some overlap here that could be removed? AFAICT,
ThreadState.stack_base is not used in any meaningful way and could be
removed. Is one of these stacks for Valgrind and the other for the
client? It's unclear from the field names.
Thanks.
N
|
|
From: Tom H. <to...@co...> - 2005-03-27 02:28:32
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-03-27 03:20:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int sh: line 1: 17039 Segmentation fault VALGRINDLIB=/tmp/valgrind.24346/valgrind/.in_place /tmp/valgrind.24346/valgrind/./coregrind/valgrind --command-line-only=yes --memcheck:leak-check=no --addrcheck:leak-check=no --tool=none ./int >int.stdout.out 2>int.stderr.out pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 207 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-27 02:22:09
|
Nightly build on audi ( Red Hat 9 ) started at 2005-03-27 03:15:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow fpu_lazy_eflags: valgrind ./fpu_lazy_eflags insn_basic: valgrind ./insn_basic insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 206 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/scalar (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-27 02:16:22
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-03-27 03:10:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 205 tests, 3 stderr failures, 0 stdout failures ================= memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-27 02:15:28
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-03-27 03:00:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 205 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) addrcheck/tests/leak-tree (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-27 02:11:44
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-03-27 03:05:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 205 tests, 17 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/distinguished-writes (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) addrcheck/tests/leak-0 (stderr) addrcheck/tests/leak-cycle (stderr) addrcheck/tests/leak-regroot (stderr) addrcheck/tests/leak-tree (stderr) make: *** [regtest] Error 1 |