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: Eyal L. <ey...@ey...> - 2004-02-12 23:18:35
|
As you can see this exception is reported in popen(), where the application does not have control over argv[] or envp[]. The command executed is something like this: char cmd[256]; sprintf (cmd, ... fp = popen (cmd, "r"); I am reasonably sure that 'cmd' has the correct content at popen() time. ==11069== Time: 2004/02/13 09:11:06 ==11069== Thread 2: ==11069== Syscall param execve(envp) contains uninitialised or unaddressable byte(s) ==11069== at 0x3C917F06: execve (in /lib/libc-2.2.5.so) ==11069== by 0x3C91810C: execl (in /lib/libc-2.2.5.so) ==11069== by 0x3C8D96DA: _IO_proc_open (in /lib/libc-2.2.5.so) ==11069== by 0x3C8D983A: _IO_popen (in /lib/libc-2.2.5.so) ==11069== by 0x3C7DB68B: ??? (socket.c:3524) ==11069== by 0x3C7DBF0B: skx089 (socket.c:3699) ==11069== by 0x3C140B77: smz007 (lockclie.c:269) ==11069== by 0x3C14095A: smz024 (lockclie.c:231) ==11069== by 0x8056748: init_idtlocks (loadit.c:3367) ==11069== by 0x8057899: ssa_main_local (loadit.c:3585) ==11069== by 0x3C7C28C6: ??? (main.c:860) ==11069== by 0x3C7E42E4: ??? (thread.c:651) ==11069== by 0x3C822D26: thread_wrapper (vg_libpthread.c:745) ==11069== by 0xB800F25F: (within /data2/usr/local/lib/valgrind/stage2) ==11069== Address 0x4FFFDF24 is not stack'd, malloc'd or free'd ==11069== Time: 2004/02/13 09:11:06 ==11069== Thread 2: ==11069== Syscall param execve(envp[i]) contains uninitialised or unaddressable byte(s) ==11069== at 0x3C917F06: execve (in /lib/libc-2.2.5.so) ==11069== by 0x3C91810C: execl (in /lib/libc-2.2.5.so) ==11069== by 0x3C8D96DA: _IO_proc_open (in /lib/libc-2.2.5.so) ==11069== by 0x3C8D983A: _IO_popen (in /lib/libc-2.2.5.so) ==11069== by 0x3C7DB68B: ??? (socket.c:3524) ==11069== by 0x3C7DBF0B: skx089 (socket.c:3699) ==11069== by 0x3C140B77: smz007 (lockclie.c:269) ==11069== by 0x3C14095A: smz024 (lockclie.c:231) ==11069== by 0x8056748: init_idtlocks (loadit.c:3367) ==11069== by 0x8057899: ssa_main_local (loadit.c:3585) ==11069== by 0x3C7C28C6: ??? (main.c:860) ==11069== by 0x3C7E42E4: ??? (thread.c:651) ==11069== by 0x3C822D26: thread_wrapper (vg_libpthread.c:745) ==11069== by 0xB800F25F: (within /data2/usr/local/lib/valgrind/stage2) ==11069== Address 0x4FFFE246 is not stack'd, malloc'd or free'd -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Bryan O'S. <bo...@se...> - 2004-02-12 21:33:21
|
On Thu, 2004-02-12 at 11:58, Ayodele Thomas wrote: > Do you know if during IA32 emulation, are you able to take advantage of > the additional 64-bit address space, or are you still limited the same way > that you are on a 32bit machine? I really just want mmap to give me > access to more than 2GB of address space for a single process. The easiest thing is to run IA32 emulation in 3G/1G mode. Beyond that, I don't know. <b |
|
From: Ayodele T. <em...@st...> - 2004-02-12 20:00:00
|
Do you know if during IA32 emulation, are you able to take advantage of the additional 64-bit address space, or are you still limited the same way that you are on a 32bit machine? I really just want mmap to give me access to more than 2GB of address space for a single process. Ayo > > On Wed, 2004-02-11 at 14:33, Nicholas Nethercote wrote: > > > > It > > might be possible to run 32-bit code on an Opteron -- but I'm not sure > > about that -- but that probably won't help you. > > Andi Kleen claims it works on 2.6.2 Opteron kernels with IA32 emulation > using the 3G/1G split. Prior kernels had bugs that prevented it from > running at all on Opteron. > > <b > -- --------------------------------------------------------------- Ayodele Bolaji Thomas "Joy in the Morning" Ph.D. Candidate Electrical Engineering Computer Systems Laboratory Stanford University Ayo...@st... Support our troops. Support our country. Pray for Peace. \o/ "We succeed, not because of Affirmative Action, but in spite of the conditions that make it necessary" (ABE '98) "War may sometimes be a necessary evil. But no matter how necessary, it is always an evil, never a good. We will not learn to live together in peace by killing each other's children." Jimmy Carter '02 --------------------------------------------------------------- |
|
From: Bryan O'S. <bo...@se...> - 2004-02-12 19:22:11
|
On Wed, 2004-02-11 at 14:33, Nicholas Nethercote wrote: > It > might be possible to run 32-bit code on an Opteron -- but I'm not sure > about that -- but that probably won't help you. Andi Kleen claims it works on 2.6.2 Opteron kernels with IA32 emulation using the 3G/1G split. Prior kernels had bugs that prevented it from running at all on Opteron. <b |
|
From: Tom H. <th...@cy...> - 2004-02-12 18:01:56
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Thu, 12 Feb 2004, Tom Hughes wrote:
>
> > The .def files have one line per test and specify the instruction to
> > execute, a set of values to be loaded into registers before executing
> > the instruction, a set of arguments to give to the instruction, and a
> > set of expected values to look for afterwards.
>
> Did you come up with all the inputs and expected outputs? If so, whoa.
Pretty much. I just read the architecture reference manual and worked
up test cases and calculated the expected results by hand.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-12 17:43:09
|
CVS commit by nethercote: Added XPLC M +5 -1 users.html 1.40 --- devel-home/valgrind/users.html #1.39:1.40 @@ -227,4 +227,8 @@ <dt><a href="http://www.boost.org">Boost C++ libraries</a> <dd>A collection of portable C++ source libraries. + +<dt><a href="http://xplc.sf.net">XPLC</a> +<dd>A system of cross-platform lightweight components to aid software extension + and reuse. </dl> @@ -302,5 +306,5 @@ <dt><a href="http://www.qubesoft.com/q/engine.php">QSDK</a> -<dd>A high performance cross platform game engine for Windows, Linux, +<dd>A high performance cross-platform game engine for Windows, Linux, PS2 and XBox. Free for non-console development. </dl> |
|
From: Nicholas N. <nj...@ca...> - 2004-02-12 17:25:35
|
On Thu, 12 Feb 2004, Tom Hughes wrote: > The .def files have one line per test and specify the instruction to > execute, a set of values to be loaded into registers before executing > the instruction, a set of arguments to give to the instruction, and a > set of expected values to look for afterwards. Did you come up with all the inputs and expected outputs? If so, whoa. > > I wonder if the C could be more succinct, eg. by using macros? The > > five generated .c files take up about 2MB :) > > I know what you mean about the size, but most of the code is specific > to the test in terms of the initial values and expected results not to > mention the exact assembly code to use, so I'm not sure how much could > be commoned out. Converting spaces to tabs cuts about 15% :) Other than that, maybe some preprocessor trickery, although you're right in that there aren't any more easy cuts to be made. N |
|
From: Tom H. <th...@cy...> - 2004-02-12 15:02:09
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> Tom, can you explain exactly what your insn_*.c tests do? AFAICT, they
> test every single instruction in some way, but I'd like to know exactly
> what is being tested.
Basically the idea is to test that the instructions have the same
effect under valgrind that they do when run normally.
The .def files have one line per test and specify the instruction to
execute, a set of values to be loaded into registers before executing
the instruction, a set of arguments to give to the instruction, and a
set of expected values to look for afterwards.
The perl script then turns that into the C files which can be compiled
and run outside of valgrind to produce the expected results which
should just be a list of ok's. It can then be run under valgrind to
make sure it produces the same result.
Currently they are only run under the none tool to check the basic
instruction translation but they should really be run under each tool
to check that the tools can all handle everything. I did run them all
under memcheck and fix any issues that came up but that isn't in the
regression tests yet. With helgrind there are still a number of
failures though.
> (Great idea, BTW, thanks for putting the effort into the scripts to
> generate the test cases... although I wonder if the C could be more
> succinct, eg. by using macros? The five generated .c files take up about
> 2MB :)
I know what you mean about the size, but most of the code is specific
to the test in terms of the initial values and expected results not to
mention the exact assembly code to use, so I'm not sure how much could
be commoned out.
> If it's really thorough, this seems like a reasonable replacement for the
> lost --stop-after flag... if we can plausibly test every instruction
> sufficiently(*), we can be certain the VCPU is correct.
Well the tests are generally as good as you make them. I tried to do a
basic test of each instruction but I didn't always poke that hard at
the edge cases. It isn't currently testing the flags with all the
instructions that can effect them either, although that would be easy
enough to add - the syntax supports it and they are already checked
for some instructions.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-12 14:46:45
|
On Thu, 12 Feb 2004, Nicholas Nethercote wrote: > Heroic patch from Tom Hughes: > > This patch adds translation tests for most of the basic x86 instructions and > fixes a few missing/broken instructions to work properly. Tom, can you explain exactly what your insn_*.c tests do? AFAICT, they test every single instruction in some way, but I'd like to know exactly what is being tested. (Great idea, BTW, thanks for putting the effort into the scripts to generate the test cases... although I wonder if the C could be more succinct, eg. by using macros? The five generated .c files take up about 2MB :) If it's really thorough, this seems like a reasonable replacement for the lost --stop-after flag... if we can plausibly test every instruction sufficiently(*), we can be certain the VCPU is correct. (*) The definition of 'sufficiently' is crucial here... I'm not quite sure what it means. N |
|
From: Nicholas N. <nj...@ca...> - 2004-02-12 14:35:37
|
CVS commit by nethercote:
Now doing pre_mem_read()s on the args to execve(), so eg. Memcheck can check
them. Added a regtest for this.
A memcheck/tests/execve.c 1.1 [no copyright]
A memcheck/tests/execve.stderr.exp 1.1
A memcheck/tests/execve.vgtest 1.1
M +17 -2 coregrind/vg_syscalls.c 1.84
M +4 -1 memcheck/tests/Makefile.am 1.31
--- valgrind/coregrind/vg_syscalls.c #1.83:1.84
@@ -1811,4 +1811,16 @@ PRE(capset)
}
+// Pre_read a char** argument.
+void pre_argv_envp(Addr a, ThreadId tid, Char* s1, Char* s2)
+{
+ while (True) {
+ Addr a_deref = deref_Addr( tid, a, s1 );
+ if (0 == a_deref)
+ break;
+ SYSCALL_TRACK( pre_mem_read_asciiz, tid, s2, a_deref );
+ a += sizeof(char*);
+ }
+}
+
PRE(execve)
{
@@ -1816,6 +1828,9 @@ PRE(execve)
char *const argv [],
char *const envp[]); */
- MAYBE_PRINTF("execve ( %p(%s), %p, %p ) --- NOT CHECKED\n",
- arg1, arg1, arg2, arg3);
+ MAYBE_PRINTF("execve ( %p(%s), %p, %p )\n", arg1, arg1, arg2, arg3);
+
+ SYSCALL_TRACK( pre_mem_read_asciiz, tid, "execve(filename)", arg1 );
+ pre_argv_envp( arg2, tid, "execve(argv)", "execve(argv[i])" );
+ pre_argv_envp( arg3, tid, "execve(envp)", "execve(envp[i])" );
/* Erk. If the exec fails, then the following will have made a
--- valgrind/memcheck/tests/Makefile.am #1.30:1.31
@@ -25,4 +25,5 @@
errs1.stderr.exp errs1.vgtest \
exitprog.stderr.exp exitprog.vgtest \
+ execve.stderr.exp execve.vgtest \
fprw.stderr.exp fprw.vgtest \
fwrite.stderr.exp fwrite.stdout.exp fwrite.vgtest \
@@ -69,5 +70,6 @@
badaddrvalue badfree badjump badloop badrw brk buflen_check \
clientperm custom_alloc \
- doublefree error_counts errs1 exitprog fprw fwrite inits inline \
+ doublefree error_counts errs1 exitprog execve \
+ fprw fwrite inits inline \
malloc1 malloc2 malloc3 manuel1 manuel2 manuel3 \
memalign_test memcmptest mmaptest nanoleak new_nothrow null_socket \
@@ -94,4 +96,5 @@
error_counts_SOURCES = error_counts.c
errs1_SOURCES = errs1.c
+execve_SOURCES = execve.c
exitprog_SOURCES = exitprog.c
fprw_SOURCES = fprw.c
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-12 08:37:10
|
CVS commit by nethercote: Add files I forgot to when I committed Tom Hughes' patch for bug 73907. A insn_basic.def 1.1 A insn_basic.stderr.exp 1.1 A insn_basic.stdout.exp 1.1 A insn_basic.vgtest 1.1 A insn_cmov.def 1.1 A insn_cmov.stderr.exp 1.1 A insn_cmov.stdout.exp 1.1 A insn_cmov.vgtest 1.1 A insn_mmxext.def 1.1 A insn_mmxext.stderr.exp 1.1 A insn_mmxext.stdout.exp 1.1 A insn_mmxext.vgtest 1.1 |
|
From: Tom H. <th...@cy...> - 2004-02-12 08:27:50
|
In message <200...@of...>
Nicholas Nethercote <nj...@ca...> wrote:
> CVS commit by nethercote:
>
> Heroic patch from Tom Hughes:
>
> This patch adds translation tests for most of the basic x86 instructions and
> fixes a few missing/broken instructions to work properly.
I think you forgot to add the new files again ;-) This is a list of
all the files in question:
none/tests/insn_basic.def
none/tests/insn_basic.stderr.exp
none/tests/insn_basic.stdout.exp
none/tests/insn_basic.vgtest
none/tests/insn_cmov.def
none/tests/insn_cmov.stderr.exp
none/tests/insn_cmov.stdout.exp
none/tests/insn_cmov.vgtest
none/tests/insn_mmxext.def
none/tests/insn_mmxext.stderr.exp
none/tests/insn_mmxext.stdout.exp
none/tests/insn_mmxext.vgtest
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: John L. <le...@mo...> - 2004-02-12 00:51:30
|
On Wed, Feb 11, 2004 at 11:26:30PM +0000, Nicholas Nethercote wrote: > > Is there any way to go beyond 2GB on 32-bit linux, or is that just a > > fundamental limit? > > I thought you could get up to 3GB by default. And I believe there are Only by moving the standard mapping locations around, i.e. not easily. john -- "Spammers get STABBED by GOD." - Ron Echeverri |