You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(6) |
2
(3) |
3
|
4
(3) |
5
(10) |
6
(4) |
7
(5) |
|
8
(1) |
9
(3) |
10
(11) |
11
(18) |
12
(13) |
13
(4) |
14
(11) |
|
15
(12) |
16
(6) |
17
(1) |
18
(13) |
19
(14) |
20
(12) |
21
(3) |
|
22
(17) |
23
(18) |
24
(17) |
25
(24) |
26
(15) |
27
(7) |
28
(23) |
|
29
(31) |
|
|
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2004-02-25 17:19:41
|
On Wed, 2004-02-25 at 03:51, Tom Hughes wrote: > > When segment overrides are used, the GETSEG/USESEG pair is used to > > convert far pointers to flat addresses. That's fine. But what happens > > when there is no segment override? Eg. if we set %ds, which affects > > most ops, are GETSEG/USESEG pairs introduced then? > > Not as far as I know, but I might be wrong. No, I think we just gloss over them, assuming that [cdse]s are all "flat". Very few programs play with these - I think Wine and dosemu are the only real contenders. There are also a pile of other magics associated with segments. For example, you can set 16-bit mode in cs, so that you're running 16 bit sized instructions by default (with the size override prefix meaning "32 bits"). J |
|
From: Tom H. <th...@cy...> - 2004-02-25 16:34:41
|
Nightly build on audi ( Red Hat 9 ) started at 2004-02-25 16:32:32 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow U valgrind/massif/hp2ps/Main.c U valgrind/massif/hp2ps/Main.h U valgrind/massif/hp2ps/Makefile.am U valgrind/massif/hp2ps/Makefile.old U valgrind/massif/hp2ps/Marks.c U valgrind/massif/hp2ps/Marks.h U valgrind/massif/hp2ps/PsFile.c U valgrind/massif/hp2ps/PsFile.h U valgrind/massif/hp2ps/README U valgrind/massif/hp2ps/Reorder.c U valgrind/massif/hp2ps/Reorder.h cvs [checkout aborted]: received interrupt signal /tmp/valgrind.21175/valgrind running: aclocal running: autoheader autoheader: /usr/bin/autom4te failed with exit status: 0 error: while running 'autoheader' /home/thh/bin/vgtest: line 27: ./configure: No such file or directory make: *** No targets specified and no makefile found. Stop. make: *** No rule to make target `regtest'. Stop. |
|
From: <js...@ac...> - 2004-02-25 15:43:09
|
Nightly build on phoenix ( SuSE 8.2 ) started at 2004-02-25 04:00:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 125 tests, 13 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) |
|
From: <js...@ac...> - 2004-02-25 15:43:06
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-02-25 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 125 tests, 13 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) |
|
From: Ashley P. <as...@pi...> - 2004-02-25 13:20:10
|
On Wed, 2004-02-25 at 13:07, Julian Seward wrote: > My only slight hesitation about putting this stuff in cvs is that > anybody can run tests and so swamp the list with messages. But I > guess we can deal with that if it happens. The best way I can think of doing this would be to add the report generating script to CVS with a default email of `whoami`@`hostname` and just have override this yourselves in your crontab files. > Re filtering (Ashley's original question) things we could do are: > > * set up a new mail list "val...@li..." > and send all autobuild messages there. I'd prefer not to do this > as it would require new potential contributors to be aware of, > and subscribe to, the list. > > * include a phrase like "valgrind-nightly" in the message header > or body, which can easily be spotted by mail clients? I would > prefer this. This was what I was thinking of but it would also be possibly to set up a specific from address which could be filtered on if adding headers proved to be to difficult. Ashley, |
|
From: Julian S. <js...@ac...> - 2004-02-25 13:16:02
|
CVS commit by jseward: Add the nightly build scripts. A README.txt 1.1 A bin/nightly 1.1 A conf/nemesis.conf 1.1 A conf/nemesis.sendmail 1.1 |
|
From: Tom H. <th...@cy...> - 2004-02-25 13:05:08
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> On Wednesday 25 February 2004 03:00, Tom Hughes wrote:
>> Nightly build on standard ( Red Hat 7.2 ) started at 2004-02-25 03:00:00
>
>> `test -f 'vg_scheduler.c' || echo './'`vg_scheduler.c In file included from
>> vg_scheduler.c:1286:
>> /usr/include/pthread.h:163: parse error before "__thread"
>
> Any idea what happened here? Is it that the 7.2 pthread.h
> has a variable called __thread, and you are using a newer gcc
> which regard it as a keyword?
Exactly. The gcc on that box had been updated to 3.2.2 but the glibc
is still an old one that uses __thread as a formal parameter name in
one of the prototypes in pthread.h.
I fixed it this morning by changing the header file to avoid the use
of __thread given that it is now a reserved word in gcc.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Julian S. <js...@ac...> - 2004-02-25 13:03:44
|
> It doesn't try and work out pass/fail at the moment - it just sends > the last 20 lines of the output ;-) Strictly speaking none of them > pass as they all fail at least one regression test at the moment. We could do with better logic for figuring out the text to be mailed to the list. What I would like to see is: - if the build failed before regression tests, the last 20 or so lines of build log, so we can see why it failed. As per last night's failed R H 7.2 build. - if the build succeeds, then I'd like to see the entire summary results of the regression tests, not just the last 20 lines. That is, I'd want to see the line == N tests, N stderr failures, N stdout failures ============= and everything thereafter. Another shortcoming of the existing code is that it doesn't stop if something breaks, eg if the cvs co fails, it keeps going anyway. This should be fixed. My only slight hesitation about putting this stuff in cvs is that anybody can run tests and so swamp the list with messages. But I guess we can deal with that if it happens. Re filtering (Ashley's original question) things we could do are: * set up a new mail list "val...@li..." and send all autobuild messages there. I'd prefer not to do this as it would require new potential contributors to be aware of, and subscribe to, the list. * include a phrase like "valgrind-nightly" in the message header or body, which can easily be spotted by mail clients? I would prefer this. J |
|
From: Julian S. <js...@ac...> - 2004-02-25 12:56:52
|
On Wednesday 25 February 2004 03:00, Tom Hughes wrote: > Nightly build on standard ( Red Hat 7.2 ) started at 2004-02-25 03:00:00 > `test -f 'vg_scheduler.c' || echo './'`vg_scheduler.c In file included from > vg_scheduler.c:1286: > /usr/include/pthread.h:163: parse error before "__thread" Any idea what happened here? Is it that the 7.2 pthread.h has a variable called __thread, and you are using a newer gcc which regard it as a keyword? J |
|
From: Tom H. <th...@cy...> - 2004-02-25 12:03:47
|
In message <1077709751.657.153.camel@ashley>
Ashley Pittman <as...@pi...> wrote:
> I'm am happy with just the distribution name and version as Tom included
> in his header. I did find it hard to tell if some of Toms builds had
> passed or failed though, it looks like they passed as they don't have
> any of the Make: footer but in this case they probably shouldn't include
> the tail of the log file.
It doesn't try and work out pass/fail at the moment - it just sends
the last 20 lines of the output ;-) Strictly speaking none of them
pass as they all fail at least one regression test at the moment.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-02-25 11:52:37
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> I just learnt about segment registers properly for the first time. Now I
> see what the fuss is all about. I have some questions about them, I would
> appreciate answers from any kind soul...
I'm not a huge expert or anything, but I'll see what I cam do...
> - Who uses them? Some ordinary apps, I guess... does glibc, or other
> relevant libraries?
They are mostly a hang over from 16 bit days and 32 bit systems don't
generally use them very much. That said, they are used as a way of
doing thread local storage just because it's a convenient trick to use
for that.
Linuxthreads uses the LDT for that where the kernel loads a new LDT
each time it does a context switch and the code then uses a segment
register to index into the LDT to find the piece of TLS data it
wants. That limits you to 8192 slots because that is the size of a
descriptor table.
NPTL uses the GDT and the kernel just updates the three TLS slots in
the GDT on a context switch. Those slots effectively hold pointers to
large blocks of TLS data that are managed by glibc/libpthread.
> - AFAICT, we virtualise the LDT, but not the GDT(?) Linux has the
> modify_ldt() syscall, does it not use the GDT at all so we don't have to
> worry about it, or is there something else happening?
The CVS head does virtualise the GDT as well, or at least that part of
it that the kernel effectively exposes to user land, namely the TLS data
pointers. The set_thread_area and get_thread_area calls are used to
modify that part of the GDT.
The kernel itself uses a few other GDT entries for it's own use but
they don't change on a per-process basis as far as I know and they're
not intended for use outside the kernel.
> - if segment registers are in use, if I print a pointer, I'm really only
> printing the offset within the current segment, rather than the true
> virtual address, right? (Which is why V must convert it, for the skin's
> sake.)
Yep.
> - AFAICT, the following is true
> - %cs is implicit operand to every instruction fetch?
> - %ss is implicit operand to every stack instruction?
> - %ds is implicit operand to all non-stack, non-string ops?
> - %es is implicit operand to string ops?
> - segment overrides are required to use %fs, %gs
That sounds about right, but in 32 bit code it is rare for anything
other that %fs or %gs to be used - the code, stack and data segments
are usually fixed by the system to give a flat address space.
> When segment overrides are used, the GETSEG/USESEG pair is used to
> convert far pointers to flat addresses. That's fine. But what happens
> when there is no segment override? Eg. if we set %ds, which affects
> most ops, are GETSEG/USESEG pairs introduced then?
Not as far as I know, but I might be wrong.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Ashley P. <as...@pi...> - 2004-02-25 11:50:37
|
On Wed, 2004-02-25 at 11:22, Nicholas Nethercote wrote: > On Wed, 25 Feb 2004, Ashley Pittman wrote: > > Is there a way to automatically filter these build logs into a different > > folder, I know I could do it on the subject line but I want replies to > > them to be handled correctly. Ideally there would be some extra header > > information that the autobuilders add but I can't see any. > > We need a general way to handle these regression test messages. Nightly > tests are a great idea, but it's a mess at the moment, because people have > only just started doing it. > The script could also give a bit more info about the machine (eg. use > uname -a, find the glibc version). And it would be nice if specifying the > per-machine info was simpler. And spamming vg-dev with all the failures > every day maybe isn't the best way to do it? But I can't think of > anything better... I don't mind them coming to vg-dev, we already have the CVS commits coming to this list and procmail manages to stash them out the way for me quite nicely. I find it comforting to know that things are ticking over and I know how easy it is to break code for different platforms. (I'm not a valgrind developer but live in hope that I might one day be able to use it so lurk on this list) I'm am happy with just the distribution name and version as Tom included in his header. I did find it hard to tell if some of Toms builds had passed or failed though, it looks like they passed as they don't have any of the Make: footer but in this case they probably shouldn't include the tail of the log file. Ideally procmail could filter the failed and successful ones too without having to grub inside the message contents but if there was a header to say build-log this would just be putting something in the subject which would be a good idea anyway. Ashley, |
|
From: Nicholas N. <nj...@ca...> - 2004-02-25 11:30:10
|
Hi,
I just learnt about segment registers properly for the first time. Now I
see what the fuss is all about. I have some questions about them, I would
appreciate answers from any kind soul...
- Who uses them? Some ordinary apps, I guess... does glibc, or other
relevant libraries?
- AFAICT, we virtualise the LDT, but not the GDT(?) Linux has the
modify_ldt() syscall, does it not use the GDT at all so we don't have to
worry about it, or is there something else happening?
- if segment registers are in use, if I print a pointer, I'm really only
printing the offset within the current segment, rather than the true
virtual address, right? (Which is why V must convert it, for the skin's
sake.)
- AFAICT, the following is true
- %cs is implicit operand to every instruction fetch?
- %ss is implicit operand to every stack instruction?
- %ds is implicit operand to all non-stack, non-string ops?
- %es is implicit operand to string ops?
- segment overrides are required to use %fs, %gs
When segment overrides are used, the GETSEG/USESEG pair is used to
convert far pointers to flat addresses. That's fine. But what happens
when there is no segment override? Eg. if we set %ds, which affects
most ops, are GETSEG/USESEG pairs introduced then?
Thanks.
N
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-25 11:23:30
|
On Wed, 25 Feb 2004, Ashley Pittman wrote: > On Wed, 2004-02-25 at 03:00, Tom Hughes wrote: > > Nightly build on standard ( Red Hat 7.2 ) started at 2004-02-25 03:00:00 GMT > > > > Checking out source tree ... done > > Configuring ... done > > Building ... done > > Running regression tests ... done > > > > Last 20 lines of log.verbose follow > > Is there a way to automatically filter these build logs into a different > folder, I know I could do it on the subject line but I want replies to > them to be handled correctly. Ideally there would be some extra header > information that the autobuilders add but I can't see any. We need a general way to handle these regression test messages. Nightly tests are a great idea, but it's a mess at the moment, because people have only just started doing it. The test script should go into CVS, and there should be a minimal wrapper that checks out the HEAD and launches the test script (so that changes to the test script propagate to everyone's machines; hopefully the wrapper could be so simple that people could have their own local copies that wouldn't need updating). The script could also give a bit more info about the machine (eg. use uname -a, find the glibc version). And it would be nice if specifying the per-machine info was simpler. And spamming vg-dev with all the failures every day maybe isn't the best way to do it? But I can't think of anything better... N |
|
From: Tom H. <th...@cy...> - 2004-02-25 11:16:58
|
In message <1077707442.642.99.camel@ashley>
Ashley Pittman <as...@pi...> wrote:
> On Wed, 2004-02-25 at 03:00, Tom Hughes wrote:
>> Nightly build on standard ( Red Hat 7.2 ) started at 2004-02-25 03:00:00 GMT
>>
>> Checking out source tree ... done
>> Configuring ... done
>> Building ... done
>> Running regression tests ... done
>>
>> Last 20 lines of log.verbose follow
>
> Is there a way to automatically filter these build logs into a different
> folder, I know I could do it on the subject line but I want replies to
> them to be handled correctly. Ideally there would be some extra header
> information that the autobuilders add but I can't see any.
There aren't any special header on my autobuilder at the moment but I
could add something although I'd have to change how I send the mail.
I don't know about Julian's as I wrote my own script in the end and
his seem to have stopped at the moment anyway...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Ashley P. <as...@pi...> - 2004-02-25 11:12:11
|
On Wed, 2004-02-25 at 03:00, Tom Hughes wrote: > Nightly build on standard ( Red Hat 7.2 ) started at 2004-02-25 03:00:00 GMT > > Checking out source tree ... done > Configuring ... done > Building ... done > Running regression tests ... done > > Last 20 lines of log.verbose follow Is there a way to automatically filter these build logs into a different folder, I know I could do it on the subject line but I want replies to them to be handled correctly. Ideally there would be some extra header information that the autobuilders add but I can't see any. The relevant parts of my .forward file are: elif $h_to: contains kd...@kd... then save Maildir/.Lists.valgrind.cvs/ elif $h_list-post: contains val...@li... then save Maildir/.Lists.valgrind.devel/ elif $h_list-post: contains val...@li... then save Maildir/.Lists.valgrind.users/ Ashley, |
|
From: Tom H. <to...@co...> - 2004-02-25 03:23:31
|
Nightly build on dunsmere ( Fedora Core 1 ) started at 2004-02-25 03:20:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 126 tests, 15 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/fwrite (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) |
|
From: Tom H. <th...@cy...> - 2004-02-25 03:18:53
|
Nightly build on audi ( Red Hat 9 ) started at 2004-02-25 03:15:00 GMT 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 syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 126 tests, 10 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) |
|
From: Tom H. <th...@cy...> - 2004-02-25 03:13:36
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-02-25 03:10:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 126 tests, 17 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/writev (stderr) |
|
From: Tom H. <th...@cy...> - 2004-02-25 03:08:47
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-02-25 03:05:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow none/tests/insn_mmxext (stderr) none/tests/insn_sse (stderr) none/tests/map_unmap (stderr) none/tests/mremap (stderr) none/tests/munmap_exe (stderr) none/tests/pth_blockedsig (stderr) none/tests/rcl_assert (stderr) none/tests/rcrl (stderr) none/tests/readline1 (stderr) none/tests/resolv (stderr) none/tests/seg_override (stderr) none/tests/sha1_test (stderr) none/tests/shortpush (stderr) none/tests/shorts (stderr) none/tests/smc1 (stderr) none/tests/syscall-restart1 (stderr) none/tests/syscall-restart2 (stderr) none/tests/system (stderr) none/tests/yield (stderr) |
|
From: Tom H. <th...@cy...> - 2004-02-25 03:01:44
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-02-25 03:00:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow make[3]: Entering directory `/tmp/valgrind.17591/valgrind/coregrind/arch' make[3]: Nothing to be done for `check-am'. make[3]: Leaving directory `/tmp/valgrind.17591/valgrind/coregrind/arch' make[2]: Leaving directory `/tmp/valgrind.17591/valgrind/coregrind/arch' Making check in . make[2]: Entering directory `/tmp/valgrind.17591/valgrind/coregrind' source='vg_scheduler.c' object='vg_scheduler.o' libtool=no \ depfile='.deps/vg_scheduler.Po' tmpdepfile='.deps/vg_scheduler.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include -I./x86 -DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -Winline -Wall -Wshadow -O -fno-omit-frame-pointer -mpreferred-stack-boundary=2 -g -DELFSZ=32 -c `test -f 'vg_scheduler.c' || echo './'`vg_scheduler.c In file included from vg_scheduler.c:1286: /usr/include/pthread.h:163: parse error before "__thread" /usr/include/pthread.h:165: `pthread_create' declared as function returning a function /usr/include/pthread.h:166: parse error before "void" /usr/include/pthread.h:591: storage class specified for parameter `type name' make[2]: *** [vg_scheduler.o] Error 1 make[2]: Leaving directory `/tmp/valgrind.17591/valgrind/coregrind' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.17591/valgrind/coregrind' make: *** [check-recursive] Error 1 |
|
From: Jeremy F. <je...@go...> - 2004-02-25 00:20:38
|
On Tue, 2004-02-24 at 15:34, Nicholas Nethercote wrote: > Ok, so what's the definition of a show-stopping bug? Does Dirk's ulimit > problem count? Not really, since it only applies to setting a datasize ulimit, which is a pretty useless thing to set anyway (since glibc malloc will always get around it by using mmap). More seriously, the brk extension in stage1 was pretty sensitive to the kernel's limits on how rapidly you can grow the brk, which depends on things like how much physical memory there is, how busy the machine is, and so on. Anyway, I just checked in a fix for it. J |
|
From: Jeremy F. <je...@go...> - 2004-02-25 00:18:03
|
On Tue, 2004-02-24 at 14:53, Nicholas Nethercote wrote: > - we now have explicit rip-relative addressing (section 1.4.2.6). > Interesting, although I'm not sure what it will be useful for. I don't think we can use it too much, but it might be useful. More interesting is that it means that client code won't have to play tricks with call to get the EIP into a register, so we can generate better code for that (like we do when we recognize "call 1f; 1:"). > - segment registers are being demoted. In 64-bit mode, they are > "generally (but not completely) disabled". Roughly speaking, it seems > only %fs and %gs do something in 64-bit mode, although there are various > caveats. See section 1.6.4. Yes, that's a bit irritating; we'll have to generate explicit bounds checking to make sure client pointers are within range. I'm thinking that we'll probably end up putting Valgrind code down low (<256Mbytes), and restricting the client address space to 256M upwards (I think this is OK; the standard load address is pretty high). We could then use "test" to make sure the appropriate bits in the address are non-zero. The other good thing is that we have more registers to play with - especially useful if we can run 32-bit code while in 64-bit mode, so we have more machine registers than VCPU registers. No spilling! J |
|
From: Jeremy F. <je...@go...> - 2004-02-25 00:08:11
|
CVS commit by fitzhardinge:
Fix shmdt by using the right argument for the shared segment address.
M +3 -3 vg_syscalls.c 1.91
--- valgrind/coregrind/vg_syscalls.c #1.90:1.91
@@ -2649,5 +2649,5 @@ PRE(ipc)
}
case 22: /* IPCOP_shmdt */
- if (!valid_client_addr(arg1, 1, tid, "shmdt"))
+ if (!valid_client_addr(arg5, 1, tid, "shmdt"))
res = -VKI_EINVAL;
break;
@@ -2788,7 +2788,7 @@ POST(ipc)
case 22: /* IPCOP_shmdt */
{
- Segment *s = VG_(find_segment)(arg1);
+ Segment *s = VG_(find_segment)(arg5);
- if (s != NULL && (s->flags & SF_SHM) && VG_(seg_contains)(s, arg1, 1)) {
+ if (s != NULL && (s->flags & SF_SHM) && VG_(seg_contains)(s, arg5, 1)) {
VG_TRACK( die_mem_munmap, s->addr, s->len );
VG_(unmap_range)(s->addr, s->len);
|