You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(11) |
2
(13) |
3
(7) |
|
4
(9) |
5
(23) |
6
(19) |
7
(18) |
8
(2) |
9
(7) |
10
(21) |
|
11
(13) |
12
|
13
(8) |
14
(17) |
15
(19) |
16
(25) |
17
(43) |
|
18
(22) |
19
(12) |
20
(19) |
21
(12) |
22
(9) |
23
(12) |
24
(5) |
|
25
(16) |
26
(25) |
27
(24) |
28
(19) |
29
(26) |
30
(25) |
31
(6) |
|
From: Jeremy F. <je...@go...> - 2004-07-27 21:04:37
|
On Tue, 2004-07-27 at 21:16 +0100, Nicholas Nethercote wrote:
> Hi,
>
> I just found a bug in the skiplist implementation; you're going to love
> this.
>
> A skiplist node looks like this:
>
> struct _SkipNode {
> UInt magic;
> UShort level; /* level is the max level (level == 0 means 1 next pointer) */
> SkipNode *next[0];
> };
>
> Part of VG_(SkipNode_Alloc)() looks like this:
>
> n->level = h;
> n->magic = SKIPLIST_MAGIC;
> while (h-- >= 0)
> n->next[h] = NULL;
>
> Seems reasonable, right? Er, actually, that loop iterates from h-1 to -1.
> Bad use of post-decrementing. Whoops.
>
> So why are things still working? Because next[-1] is actually 'level'. So
> the 'level' field of every SkipNode is zero. Hmm, there goes our nice
> logarithmic lookups; the skiplist has effectively degenerated into a
> linked list... or something like that; I didn't investigate to work out
> exactly what is happening.
Oh, nasty. I'm pretty sure I'd checked that some actual skipping was
going on, but maybe not.
Anyway, I'll take a look.
J
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-27 20:16:53
|
Hi,
I just found a bug in the skiplist implementation; you're going to love
this.
A skiplist node looks like this:
struct _SkipNode {
UInt magic;
UShort level; /* level is the max level (level == 0 means 1 next pointer) */
SkipNode *next[0];
};
Part of VG_(SkipNode_Alloc)() looks like this:
n->level = h;
n->magic = SKIPLIST_MAGIC;
while (h-- >= 0)
n->next[h] = NULL;
Seems reasonable, right? Er, actually, that loop iterates from h-1 to -1.
Bad use of post-decrementing. Whoops.
So why are things still working? Because next[-1] is actually 'level'. So
the 'level' field of every SkipNode is zero. Hmm, there goes our nice
logarithmic lookups; the skiplist has effectively degenerated into a
linked list... or something like that; I didn't investigate to work out
exactly what is happening.
So how did I find this? Because on x86-64, the 8-byte pointers mean that
next[-1] clobbers both 'level' and 'magic' (a canary word) and so it
complains about 'magic' being incorrect.
The obvious fix is to change the loop to this:
while (h >= 0) {
n->next[h] = NULL;
h--;
}
except then there's some other problem and a seg fault occurs. I'm
guessing that there's a bug in the skiplist code that has never been
exposed because the levels are always zero. I can't be bothered looking
for it now, I'm hoping someone else will be inspired. Ripping the
skiplist code out into a stand-alone program and running Memcheck on it
might be the easiest thing to do.
[I've been thinking that we should do that for a number of parts of the
systems, the parts that can be easily separated -- eg. the skiplist, the
hashtable, the allocator, etc -- somehow as part of standard testing.
Not that it would have found the above bug...]
N
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-27 20:07:34
|
On Tue, 27 Jul 2004, Tom Hughes wrote: > Does it work with the first patch? Come to that, does it work if > you just take out the assertion? I wasn't entirely sure that it was > the right assertion... Hard to say; just removing the assertion, it gets further before it falls over in the same way as it does for the -h case... N |
|
From: Tom H. <th...@cy...> - 2004-07-27 20:01:14
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Tue, 27 Jul 2004, Tom Hughes wrote:
>
> >> Thanks Tom, this fixes the problem! (And it now falls over slightly
> >> further along :) I had worked out that Valgrind was observing the
> >> requested 0x100000 alignment and the kernel wasn't, but hadn't got any
> >> further than that. The kernel's behaviour seems odd here...
>
> Actually, when not using --help (as I was) although the
> bogus-initialisation problem is fixed, it asserts when loading the client:
>
> valgrind: ume.c:364: mapelf: Assertion `((addr - off) & (align - 1)) ==
> 0' failed.
>
> The relevant values are:
>
> addr = 0x1ff27000, off = 0, align = 100000
Does it work with the first patch? Come to that, does it work if
you just take out the assertion? I wasn't entirely sure that it was
the right assertion...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-27 19:06:21
|
On Tue, 27 Jul 2004, Tom Hughes wrote: >> Thanks Tom, this fixes the problem! (And it now falls over slightly >> further along :) I had worked out that Valgrind was observing the >> requested 0x100000 alignment and the kernel wasn't, but hadn't got any >> further than that. The kernel's behaviour seems odd here... Actually, when not using --help (as I was) although the bogus-initialisation problem is fixed, it asserts when loading the client: valgrind: ume.c:364: mapelf: Assertion `((addr - off) & (align - 1)) == 0' failed. The relevant values are: addr = 0x1ff27000, off = 0, align = 100000 ? N |
|
From: Tom H. <th...@cy...> - 2004-07-27 18:56:27
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> Thanks Tom, this fixes the problem! (And it now falls over slightly
> further along :) I had worked out that Valgrind was observing the
> requested 0x100000 alignment and the kernel wasn't, but hadn't got any
> further than that. The kernel's behaviour seems odd here...
>
> Am I right that this second patch completely obsoletes the first?
Yes.
The first one should work, but you'll be mapping most if not
all of the BSS as copy-on-write pages which are then force to
be mapped by the memset instead of mapping them from /dev/zero
where they will only zpring into existence when used.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-27 18:51:55
|
On Tue, 27 Jul 2004, Jeremy Fitzhardinge wrote: > Looks like mapelf isn't respecting the alignment in the PHDR. What does > readelf -l stage2 say? Seems like mapelf was respecting it, but the kernel wasn't. Or something ilke that... > I bet the distinction between the groups of values is that some are > initialized in the source, and some are not (ie, expected to default to > 0/NULL). They are initialised explicitly in the code; it seems the compiler split them into zero and non-zero halves. Thanks for the help on this one. N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-27 18:50:46
|
On Tue, 27 Jul 2004, Tom Hughes wrote: >> That said, the map output that Nick sent from when stage2 was launched >> directly makes it look like the OS was only round to page boundaries >> anyway! > > This patch may be better - it switches mapelf to do what the kernel > does and only map the pages that are required instead of rounding > everything to the specified alignment. > > It does assert that the overall result has the correct aligment > and will I think mean that the mapping of stage2 when launched by > stage1 will match the mapping when it is launched directly. Thanks Tom, this fixes the problem! (And it now falls over slightly further along :) I had worked out that Valgrind was observing the requested 0x100000 alignment and the kernel wasn't, but hadn't got any further than that. The kernel's behaviour seems odd here... Am I right that this second patch completely obsoletes the first? N |
|
From: Tom H. <th...@cy...> - 2004-07-27 18:21:09
|
In message <ec6...@lo...>
Tom Hughes <th...@cy...> wrote:
> The attached patch should fix it.
>
> That said, the map output that Nick sent from when stage2 was launched
> directly makes it look like the OS was only round to page boundaries
> anyway!
This patch may be better - it switches mapelf to do what the kernel
does and only map the pages that are required instead of rounding
everything to the specified alignment.
It does assert that the overall result has the correct aligment
and will I think mean that the mapping of stage2 when launched by
stage1 will match the mapping when it is launched directly.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-07-27 17:33:28
|
In message <8e1...@lo...>
Tom Hughes <th...@cy...> wrote:
> In message <109...@ix...>
> Jeremy Fitzhardinge <je...@go...> wrote:
>
> > I bet the distinction between the groups of values is that some are
> > initialized in the source, and some are not (ie, expected to default to
> > 0/NULL).
>
> I think this may be the problem - the code to zero pad from filesz
> to memsz looks highly odd to me. Specifically where it works out the
> value of "bytes" which is the amount of memory it zeros.
This is the problem, and it is alignment related. When the odd bit
at the end of the mapping from the file is zero filled it only fills
up to the next page boundary instead of up to the alignment boundary
given in the header.
On x86-32 it happens to work because the alignment in the header is
normally the same as the page size, but x86-64 seems to be using an
alignment of 1Mb for some reason.
The attached patch should fix it.
That said, the map output that Nick sent from when stage2 was launched
directly makes it look like the OS was only round to page boundaries
anyway!
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-07-27 17:19:12
|
In message <109...@ix...>
Jeremy Fitzhardinge <je...@go...> wrote:
> Looks like mapelf isn't respecting the alignment in the PHDR. What does
> readelf -l stage2 say?
It looks like it respects it to me.
> I bet the distinction between the groups of values is that some are
> initialized in the source, and some are not (ie, expected to default to
> 0/NULL).
I think this may be the problem - the code to zero pad from filesz
to memsz looks highly odd to me. Specifically where it works out the
value of "bytes" which is the amount of memory it zeros.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2004-07-27 16:41:38
|
On Tue, 2004-07-27 at 16:20 +0100, Nicholas Nethercote wrote: > On Tue, 27 Jul 2004, Tom Hughes wrote: > > >> Hmm, I just had the idea of running stage2 stand-alone, rather than > >> launching it with stage1 as normal. The bogus-value problem went > >> away, so it's definitely caused by stage1 somehow... > > > > Given the address split between the two blocks of variables, have they > > been put in separate sections in the ELF or something? Perhaps the > > loader in stage1 isn't mapping the file right while the OS is? > > Yeah, when I launch via stage1 I see: > > 60000000-60100000 r-xp 00000000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 > 60100000-60200000 rw-p 00000000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 > > when I launch stage2 directly I see: > > 60000000-600b0000 r-xp 00000000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 > 601b0000-601b1000 rw-p 000b0000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 > > which looks funny. I'll keep looking... Looks like mapelf isn't respecting the alignment in the PHDR. What does readelf -l stage2 say? I bet the distinction between the groups of values is that some are initialized in the source, and some are not (ie, expected to default to 0/NULL). J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-27 15:20:19
|
On Tue, 27 Jul 2004, Tom Hughes wrote: >> Hmm, I just had the idea of running stage2 stand-alone, rather than >> launching it with stage1 as normal. The bogus-value problem went >> away, so it's definitely caused by stage1 somehow... > > Given the address split between the two blocks of variables, have they > been put in separate sections in the ELF or something? Perhaps the > loader in stage1 isn't mapping the file right while the OS is? Yeah, when I launch via stage1 I see: 60000000-60100000 r-xp 00000000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 60100000-60200000 rw-p 00000000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 when I launch stage2 directly I see: 60000000-600b0000 r-xp 00000000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 601b0000-601b1000 rw-p 000b0000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 which looks funny. I'll keep looking... N |
|
From: Tom H. <th...@cy...> - 2004-07-27 15:05:30
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Tue, 27 Jul 2004, Nicholas Nethercote wrote:
>
>> I'm stumped... can anyone see what might be happening here? I'm
>> highly suspicious of the variables being put in two different memory
>> locations.
>
> Hmm, I just had the idea of running stage2 stand-alone, rather than
> launching it with stage1 as normal. The bogus-value problem went
> away, so it's definitely caused by stage1 somehow...
Given the address split between the two blocks of variables, have they
been put in separate sections in the ELF or something? Perhaps the
loader in stage1 isn't mapping the file right while the OS is?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-27 15:01:39
|
On Tue, 27 Jul 2004, Nicholas Nethercote wrote: > I'm stumped... can anyone see what might be happening here? I'm highly > suspicious of the variables being put in two different memory locations. Hmm, I just had the idea of running stage2 stand-alone, rather than launching it with stage1 as normal. The bogus-value problem went away, so it's definitely caused by stage1 somehow... N |
|
From: Bob F. <bfr...@si...> - 2004-07-27 14:15:37
|
On Tue, 27 Jul 2004, Nicholas Nethercote wrote: > > I can tar up my current workspace and put it on my website if that would be > useful. Why not just create a CVS development branch to support the x86-64 port? Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Nicholas N. <nj...@ca...> - 2004-07-27 14:08:47
|
Hi, I'm making progress on x86-64; I've discovered that the calling conventions for functions and system calls are totally different than for x86... ABI documents are useful :) Anyway, I'm getting a strange error. stage1 is successfully starting stage2, but then bad things are happening. The problem is that some of the VG_(clo_*) arguments are initialised to the right values, but some of them are being initialised to totally bogus values. Here's some debugging output -- for each variable I print the name, its address, the value it is initialised to in the code, and then the actual value it gets at run-time. ---------------------------------------- stage2 main! ---------------------------------------- VG_(clo_error_limit) 0x601b03dd = True; 1 VG_(clo_db_command) 0x601b03e0 = VG_CLO_DEFAULT_DBCOMMAND; /usr/bin/gdb -nw %f %p VG_(clo_sanity_level) 0x601b03e8 = 1; 1 VG_(clo_verbosity) 0x601b03ec = 1; 1 VG_(clo_demangle) 0x601b03f0 = True; 1 VG_(clo_trace_children) 0x601bd8ae = False; 0 VG_(clo_log_fd) 0x601b03f4 = 1; 1 VG_(clo_suppressions)[] 0x602f19c0 = ?; 0x602f19c0 VG_(clo_optimise) 0x601b03f8 = True; 1 VG_(clo_trace_codegen) 0x601bd8ca = 0; // 00000000b 0 VG_(clo_trace_syscalls) 0x601bd8cb = False; 0 VG_(clo_backtrace_size) 0x601b03fc = 4; 4 VG_(clo_run_libc_freere)0x601b0400 = True; 1 VG_(clo_track_fds) 0x601bd8e0 = False; 0 VG_(clo_chain_bb) 0x601b0401 = True; 1 VG_(clo_pointercheck) 0x601b0402 = True; 1 ---- VG_(clo_db_attach) 0x601bd8ac = False; 16 VG_(clo_gen_suppression)0x601bd8ad = False; 51 VG_(clo_log_to) 0x601bd8b0 = VgLogTo_Fd; 992843285 VG_(clo_log_name) 0x601bd8b8 = NULL; 0x9715000034210758 VG_(clo_input_fd) 0x601bd8c0 = 0; /* stdin */ 15149 VG_(clo_n_suppressions) 0x601bd8c4 = 0; 124265218 VG_(clo_profile) 0x601bd8c8 = False; 209 VG_(clo_single_step) 0x601bd8c9 = False; 26 VG_(clo_trace_signals) 0x601bd8cc = False; 21 VG_(clo_trace_symtab) 0x601bd8cd = False; 164 VG_(clo_trace_sched) 0x601bd8ce = False; 203 VG_(clo_trace_pthread_level) 0x601bd8d0 = 0; 587333632 VG_(clo_dump_error) 0x601bd8d4 = 0; -1828585352 VG_(clo_weird_hacks) 0x601bd8d8 = NULL; 0xd54516000021 VG_(clo_show_below_main)0x601bd8e1 = False; 2 VG_(clo_branchpred) 0x601bd8e2 = False; 154 Those in the top half are correctly initialised to the value specified in the code. Those in the bottom half are getting bogus values. The bogus values are bogus from the very moment they are mapped into memory, in mapelf(). (I checked this with a hexdump of the just-mapped-in code in mapelf()) The interesting thing is that all the bogus ones are in one memory area around 0x601bd8a0, but most of the correct ones are in a different memory area around 0x601b03d8. (Some of the correct ones have similar addresses to the bogus ones... these are mostly meant to be 0, eg. VG_(clo_trace_children), so they are probably bogus but just getting the right value by chance.) I've used readelf to look at stage2 and the variable addresses do seem to be correct, so that's no help. I'm stumped... can anyone see what might be happening here? I'm highly suspicious of the variables being put in two different memory locations. If it's any use, the equivalent dump for x86 is below; for it the variables aren't partitioned into two different areas, and they are (not surprisingly) all correct. ---------------------------------------- stage2 main! ---------------------------------------- VG_(clo_error_limit) 0xb00826b8 = True; 1 VG_(clo_db_command) 0xb00826bc = VG_CLO_DEFAULT_DBCOMMAND; /usr/bin/gdb -nw %f %p VG_(clo_sanity_level) 0xb00826c4 = 1; 1 VG_(clo_verbosity) 0xb00826c8 = 1; 1 VG_(clo_demangle) 0xb00826cc = True; 1 VG_(clo_trace_children) 0xb00826cd = False; 0 VG_(clo_log_fd) 0xb00826d4 = 1; 1 VG_(clo_suppressions)[] 0xb01b2420 = ?; 0xb01b2420 VG_(clo_optimise) 0xb00826e6 = True; 1 VG_(clo_trace_codegen) 0xb00826e7 = 0; // 00000000b 0 VG_(clo_trace_syscalls) 0xb00826e8 = False; 0 VG_(clo_backtrace_size) 0xb00826f4 = 4; 4 VG_(clo_run_libc_freere)0xb00826fc = True; 1 VG_(clo_track_fds) 0xb00826fd = False; 0 VG_(clo_chain_bb) 0xb00826fe = True; 1 VG_(clo_pointercheck) 0xb0082700 = True; 1 ---- VG_(clo_db_attach) 0xb00826b9 = False; 0 VG_(clo_gen_suppression)0xb00826c0 = False; 0 VG_(clo_log_to) 0xb00826d0 = VgLogTo_Fd; 0 VG_(clo_log_name) 0xb00826d8 = NULL; (nil) VG_(clo_input_fd) 0xb00826dc = 0; /* stdin */ 0 VG_(clo_n_suppressions) 0xb00826e0 = 0; 0 VG_(clo_profile) 0xb00826e4 = False; 0 VG_(clo_single_step) 0xb00826e5 = False; 0 VG_(clo_trace_signals) 0xb00826e9 = False; 0 VG_(clo_trace_symtab) 0xb00826ea = False; 0 VG_(clo_trace_sched) 0xb00826eb = False; 0 VG_(clo_trace_pthread_level) 0xb00826ec = 0; 0 VG_(clo_dump_error) 0xb00826f0 = 0; 0 VG_(clo_weird_hacks) 0xb00826f8 = NULL; (nil) VG_(clo_show_below_main)0xb00826ff = False; 0 VG_(clo_branchpred) 0xb0082701 = False; 0 I can tar up my current workspace and put it on my website if that would be useful. Thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-27 10:45:54
|
On Mon, 26 Jul 2004, Jeremy Fitzhardinge wrote: > There's a few syscalls in which POST should be called on error exit > (nanosleep, for example, needs to return the amount of unslept time on > interrupt). I've been thinking that we should change may_block in > sys_info into a bitfield, and encode a little more in there - like > whether the syscall wants POST called on failure. > > (Another reason for this would be to allow conditional may_block-ness. > Change PRE() to return a boolean, and add a flag into sys_info saying > use the result of PRE rather than a fixed value for blockness. We could > just change all the PREs to return the appropriate thing, or just use > the existing value in the table.) Both ideas sound good to me. N |
|
From: <js...@ac...> - 2004-07-27 03:00:20
|
Nightly build on nemesis ( SuSE 9.1 ) started at 2004-07-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 sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 168 tests, 4 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-07-27 02:25:10
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-07-27 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 7 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-27 02:20:00
|
Nightly build on audi ( Red Hat 9 ) started at 2004-07-27 03:15:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 7 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-27 02:13:21
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-07-27 03:10:04 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 4 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-27 02:08:15
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-07-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 shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 6 stderr failures, 1 stdout failure ================= addrcheck/tests/toobig-allocs (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/new_nothrow (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-27 02:07:33
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-07-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 rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv rlimit_nofile: valgrind ./rlimit_nofile seg_override: valgrind ./seg_override sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 0 stderr failures, 0 stdout failures ================= |