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
|
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: Dag W. <da...@wi...> - 2003-04-27 18:04:13
|
Hi, I'm building valgrind for several versions of the Red Hat distribution.=20 You can find these packages at: http://dag.wieers.com/packages/valgrind/ Or have them installed automatically using apt as described on: http://dag.wieers.com/apt/ The RH9 package is build on a clean RH9 by doing 'unset CFLAGS' as=20 described in RH BugZilla #88846. make was not updated. I also included a small C program that would check if NPTL threading was=20 supported (at runtime). But I superseded that with using getconf directly= .=20 (This works on all distributions and is much cleaner.) Using getconf was advised on a mailinglist somewhere (I can't remember=20 where exactly I read that.) However I have the source of the small C=20 program still in my SPEC file for educational purposes.) It would be nice though if valgrind could check for itself if NPTL=20 threading is supported at loadtime ? Or at least take over my changes to=20 coregrind/valgrind.in so that it is check in runtime (instead of checking= =20 at compile-time) You can do this by doing: perl -pi.orig -e 's|^nptl_threading=3D.*$|nptl_threading=3D"$(if getconf = GNU_LIBPTHREAD_VERSION &>/dev/null; then echo "yes"; else echo "no"; fi)"= |' coregrind/valgrind.in PS These packages still have a problem with some private GLIBC symbols=20 that are in the dependencies of the package. I can't seem to fix this by=20 doing: %define __find_provides() /usr/lib/rpm/find-provides %* | grep -v '^libp= thread.so' %define __find_requires() /usr/lib/rpm/find-requires %* | grep -v 'libc.= so.6(GLIBC_PRIVATE)' So unless I find a clean way of doing this, you might have to install wit= h=20 --nodeps on some RH's (RH80 and RH73 afaik). PS2 I'm not subscribed, please put me in CC if you have any remarks. Kind regards, -- dag wieers, da...@wi..., http://dag.wieers.com/ -- =ABAny errors in spelling, tact or fact are transmission errors=BB |
|
From: Josef W. <Jos...@gm...> - 2003-04-27 14:31:38
|
On Tuesday 22 April 2003 00:19, Nicholas Nethercote wrote: > ... > > Nick, we should add a implementation of getcwd() to V, and use absolute > > file paths. But this still doesn't work with chroot() programs :-( > > Another option: --dumpfile-fd=... > > How's this for a better solution: let's abandon the creation of the > cachegrind.out.<pid> file at startup. Originally, Cachegrind aborted if > it couldn't open the cachegrind.out.<pid> file, and I put the > open-at-startup code in so that if it couldn't open the file, the abort > would happen at the start of execution, not at the end after waiting what > could be a long time. > > But then Cachegrind was changed so it didn't abort if the file couldn't be > opened, because sometimes with --trace-children=yes it happened often (I > can't remember why). > > So now there's absolutely no point in opening the file at the start and > then reopening it at the end. So I'd be happy to remove the opening at Yes. > the start. But, the cachegrind.out.<pid> file should really be written in > the directory the program was invoked from, regardless of any cwd change Yes again. To tell the true, the "--base=" CLO addition was a quick workaround for this problem, as there's no getcwd() in valgrind's libc. We should add it and use the cwd at program start as absolute path for the cachegrind.out files. > commands during execution, so the getcwd() implementation still seems like > a good idea. Does this sound sensible, Josef? I don't understand the > chroot() problem, can you explain it to me, and how it interacts here? After a chroot(), a process can only access files below the given root in chroot(), if the files wasn't opened already. E.g, when cachegrinding the FTP damon, you don't have access to the cwd at program start on dump time. But I think this is neglectable, as chroot() is rare. > > N > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Philippe E. <ph...@wa...> - 2003-04-27 00:49:12
|
Julian Seward wrote:
> 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.
Sorry no test case. 0x66/0xF3/0xF2 prefix are valid
first byte opcode for some sse/ss2e instruction
e.g.
F3 0F 58/r addss xmm1, xmm2/m32
they are listed in table Intel P4 documentation Doc P4
Volume 2 Table A-3 Two byte opcode map, in each cell some
insn specify an additionnal opcode which is in fact the
first byte of the instructions, if you already handle
0x66 0xF there is only a few new opcode else ...
regards,
Phil
|