You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(6) |
2
(16) |
3
(3) |
4
(11) |
5
(2) |
|
6
(4) |
7
(11) |
8
(4) |
9
(6) |
10
(25) |
11
(10) |
12
(1) |
|
13
(2) |
14
(6) |
15
(16) |
16
(19) |
17
(16) |
18
(5) |
19
|
|
20
(4) |
21
(5) |
22
(21) |
23
(4) |
24
(14) |
25
(3) |
26
(9) |
|
27
(3) |
28
(13) |
29
(6) |
30
(16) |
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-29 18:41:13
|
On Tue, 29 Apr 2003, John Reiser wrote: > Where are the arguments to a system call checked for having defined values? > For instance, open() can take 3 arguments, yet case __NR_open in > coregrind/vg_syscalls.c does no checking regarding arg3. See testcase below. > > If trailing arguments to mmap2() [and/or other syscalls that take many] > are omitted, then shouldn't valgrind complain? It's not just open() and mmap2(). All direct system call args (integers, pointers, etc) aren't checked. Only blocks of memory pointed to by pointer arguments are checked. So Valgrind won't catch any undefined integer arguments to any system calls. I guess Julian did it this way because these kinds of errors will (presumably) be pretty uncommon compared to undefined blocks of memory -- you'd need an undefined stack variable or argument, and gcc -O picks up possibly undefined stack vars -- and it would be a pain to add all the extra checking. Maybe it should be there, but in practice I think these are pretty uncommon cases. Correct me if I'm wrong... N |
|
From: John R.
|
Where are the arguments to a system call checked for having defined values?
For instance, open() can take 3 arguments, yet case __NR_open in
coregrind/vg_syscalls.c does no checking regarding arg3. See testcase below.
If trailing arguments to mmap2() [and/or other syscalls that take many]
are omitted, then shouldn't valgrind complain?
The checking of __NR_select and __NR_newselect is incorrect in 1.9.5:
-----
if (arg2 != 0)
SYSCALL_TRACK( pre_mem_read, tst, "newselect(readfds)",
arg2, arg1/8 /* __FD_SETSIZE/8 */ );
-----
Every instance of "arg1/8" should be "(7+arg1)/8" instead. It is very
common for code that uses select() to "know" exactly the maximum fd in a set,
and to specify only 1+max_fd as arg1. So if max_fd is 3 then arg1 is 4,
and arg1/8 is zero, yet the kernel must (and does) read at least 1 byte
in this case. In fact, examining the code for get_fd_set() in
linux/include/linux/poll.h leads to the conclusion that "4*((31 + arg1)/32)"
is the byte length that Linux actually uses on x86. [Try putting an fd_set
high on a page, unaligned, near a page hole.]
-----bug_open.c
#include <stdlib.h>
#include <fcntl.h>
main()
{
return open("foo", O_CREAT|O_RDWR);
/* Missing 3rd arg [permission bits] to open(), should be diagnosed
as a read from an allocated-but-unwritten location on stack,
followed by [an implied, and actual] use of the value by the kernel.
As compiled by gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
using "gcc -g" [no -O]:
0x8048324 <main>: push %ebp
0x8048325 <main+1>: mov %esp,%ebp
0x8048327 <main+3>: sub $0x8,%esp
0x804832a <main+6>: and $0xfffffff0,%esp
0x804832d <main+9>: mov $0x0,%eax
0x8048332 <main+14>: sub %eax,%esp
0x8048334 <main+16>: sub $0x8,%esp # 3rd arg undefined
0x8048337 <main+19>: push $0x42 # 2nd arg (flags)
0x8048339 <main+21>: push $0x80483f4 # 1st arg (name)
0x804833e <main+26>: call 0x8048264 <open>
Similar holes can be observed with gcc < 3.2 by declaring a local
array whose initial elements are never written.
*/
}
-----
--
John Reiser, jreiser@BitWagon.com
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-29 08:26:22
|
On Mon, 28 Apr 2003, Stuart Brorson wrote: > > This is how "make ; make install" created the script. When I > > uncommented "LD_DEBUG=symbols", and "export LD_DEBUG" valgrind started > > working. Yay!!!! > > Actually, the only thing this did was allow valgrind to spew a whole > bunch of cruft before segfaulting. Here are the last few lines before > segfaulting: That just tells the dynamic linker to spew out some debugging info. > By the way, I did put in a bunch of "echo" statements into the > valgrind script. The place where it segfaults is when it actually > execs the invoked program at the end of the script. It doesn't puke > for any of the environmental set-up statements. Hmm, can you use GDB to find where the seg fault is happening, if it's happening within Valgrind (presumably) and what line number? N |
|
From: Dominic M. <dma...@ai...> - 2003-04-29 02:21:22
|
Here's a very short test program that produces this error for me. I'm
using a Pentium 3, though, not a Pentium 4. The problem only happens if I
use the -march=pentium3 option with gcc 3.x.
Test program:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
float f = rand() / (float)RAND_MAX;
printf("f=%f\n", f);
return 0;
}
Compilation line:
gcc -march=pentium3 foo.c
> gcc -v
Thread model: posix
gcc version 3.2
> valgrind --version
valgrind-1.9.4
I hope this helps!
- Dominic
---------------------------------------------------------------
From: Julian Seward <js...@ac...>
To: val...@li...
Date: Sun, 27 Apr 2003 00:13:43 +0100
Subject: [Valgrind-users] Need test case for: REPE then 0xF: Unhandled
REPE
case
Hello. I'm trying to put together bug fixes for 1.9.6.
Several people reported this panic:
REPE then 0xF
valgrind: the `impossible' happened:
Unhandled REPE case
I'd like to fix it, since it seems to afflict quite a number
of people. However, reading my Intel P4 documentation I can't
figure out what instruction this is.
So: does anyone have a smallish test case I can use to reproduce
this with? Or (not so good, but it would be a help) can anyone
tell me what the byte after the 0xF is? You can find out
by changing vg_to_ucode.c:4321 from
VG_(printf)("REPE then 0x%x\n", (UInt)abyte);
to
VG_(printf)("REPE then 0x%x 0x%x\n", (UInt)abyte,
(UInt)getUChar(eip));
I prefer a test case tho, so I can test any fix I make.
Thanks,
J
|
|
From: <sd...@cl...> - 2003-04-29 00:28:17
|
Rats! I was too optimistic about fixing the problem. . . . . > > On Mon, 28 Apr 2003, Stuart Brorson wrote: > > > > > With great anticipation I downloaded and built valgrind-1.9.5 last > > > night. I did a vanilla "./configure ; make ; make install". When I > > > tried "valgrind ls -l", I got "Segmentation fault (core dumped)". > > > Rats! When I run valgrind alone, I also get a segfault. > > > > You mean even if you just type "valgrind"? Weird... something must going > > wrong in Valgrind's startup shell script. Yes, even if I just type "valgrind". > > Can you try fiddling with $PREFIX/bin/valgrind, inserting some debug > > "echo" statements to work out where exactly the seg fault is happening? > > > > N > > OK, I fixed my problem. I examined /usr/local/bin/valgrind. It > turned out that at one place in that script I had: > > #LD_DEBUG=files > #LD_DEBUG=symbols > #export LD_DEBUG > > This is how "make ; make install" created the script. When I > uncommented "LD_DEBUG=symbols", and "export LD_DEBUG" valgrind started > working. Yay!!!! Actually, the only thing this did was allow valgrind to spew a whole bunch of cruft before segfaulting. Here are the last few lines before segfaulting: 22740: symbol=_dl_map_object_deps; lookup in file=/lib/i686/libc.so.6 22740: symbol=_dl_map_object_deps; lookup in file=/lib/ld-linux.so.2 22740: 22740: calling init: /usr/local/lib/valgrind/valgrind.so 22740: 22740: symbol=__register_frame_info; lookup in file=true 22740: symbol=__register_frame_info; lookup in file=/usr/local/lib/valgrind/vgskin_memcheck.so 22740: symbol=__register_frame_info; lookup in file=/usr/local/lib/valgrind/valgrind.so 22740: symbol=__register_frame_info; lookup in file=/lib/i686/libc.so.6 By the way, I did put in a bunch of "echo" statements into the valgrind script. The place where it segfaults is when it actually execs the invoked program at the end of the script. It doesn't puke for any of the environmental set-up statements. Does anybody have any ideas about what is wrong? Stuart |
|
From: <sd...@cl...> - 2003-04-29 00:09:57
|
Hi -- > On Mon, 28 Apr 2003, Stuart Brorson wrote: > > > With great anticipation I downloaded and built valgrind-1.9.5 last > > night. I did a vanilla "./configure ; make ; make install". When I > > tried "valgrind ls -l", I got "Segmentation fault (core dumped)". > > Rats! When I run valgrind alone, I also get a segfault. > > You mean even if you just type "valgrind"? Weird... something must going > wrong in Valgrind's startup shell script. > > Can you try fiddling with $PREFIX/bin/valgrind, inserting some debug > "echo" statements to work out where exactly the seg fault is happening? > > N OK, I fixed my problem. I examined /usr/local/bin/valgrind. It turned out that at one place in that script I had: #LD_DEBUG=files #LD_DEBUG=symbols #export LD_DEBUG This is how "make ; make install" created the script. When I uncommented "LD_DEBUG=symbols", and "export LD_DEBUG" valgrind started working. Yay!!!! Now my only question is: why did the default install procedure create a script with this option commented out? Or did I just not RTFM? Stuart |