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
|
2
|
3
|
4
|
|
5
(2) |
6
|
7
(1) |
8
(1) |
9
|
10
(1) |
11
|
|
12
(3) |
13
(3) |
14
(3) |
15
(4) |
16
(3) |
17
|
18
(3) |
|
19
(1) |
20
(1) |
21
(3) |
22
|
23
|
24
(1) |
25
(3) |
|
26
|
27
(2) |
28
(10) |
29
|
30
(2) |
31
(2) |
|
|
From: Alex <zhi...@gm...> - 2019-05-14 10:55:59
|
we have have the simple code like this:
#include <stdlib.h>
int main(int argc, char *argv[])
{
malloc(10);
return 0;
}
then run `valgrind --leak-check=no --xml=yes --xml-file=x.xml ./main`
check the x.xml file, we see:
<error>
<unique>0x0</unique>
<tid>1</tid>
<kind>Leak_DefinitelyLost</kind>
<xwhat>
<text>10 bytes in 1 blocks are definitely lost in loss record 1 of
1</text>
<leakedbytes>10</leakedbytes>
<leakedblocks>1</leakedblocks>
</xwhat>
<stack>
<frame>
<ip>0x4C29E4B</ip>
<obj>/usr/local/lib/valgrind/vgpreload_memcheck-amd64-linux.so</obj>
<fn>malloc</fn>
<dir>/home/yizhi.fzh/valgrind-3.15.0/coregrind/m_replacemalloc</dir>
<file>vg_replace_malloc.c</file>
<line>309</line>
</frame>
<frame>
<ip>0x4004FF</ip>
<obj>/home/yizhi.fzh/github/c-quick-test/main</obj>
<fn>main</fn>
<dir>/home/yizhi.fzh/github/c-quick-test</dir>
<file>main.c</file>
<line>6</line>
</frame>
</stack>
</error>
$uname -a
Linux e18c07352.et15sqa 3.10.0-327.ali2008.alios7.x86_64 #1 SMP Tue Nov 29
17:56:13 CST 2016 x86_64 x86_64 x86_64 GNU/Linux
$valgrind --version
valgrind-3.15.0
Thanks
|
|
From: Jinke F. <fan...@ye...> - 2019-05-14 09:58:55
|
Background:
Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture
between AMD and Haiguang Information Technology Co.,Ltd., aims at
providing high performance x86 processor for China server market.
Its first generation processor codename is Dhyana, which
originates from AMD technology and shares most of the
architecture with AMD's family 17h, but with different CPU Vendor
ID("HygonGenuine")/Family series number(Family 18h).
Related Hygon kernel patch can be found on:
http://lkml.kernel.org/r/5ce...@hy...
The results of regression test suite:
== 709 tests, 3 stderr failures, 1 stdout failure, 0 stderrB failures, 0
stdoutB failures, 2 post failures ==
memcheck/tests/leak_cpp_interior (stderr)
memcheck/tests/overlap (stderr)
massif/tests/new-cpp (post)
massif/tests/overloaded-new (post)
none/tests/amd64/avx-1 (stdout)
exp-sgcheck/tests/stackerr (stderr)
...checking makefile consistency
...checking header files and include directives
Makefile:1354: recipe for target 'regtest' failed
make: *** [regtest] Error 1
Is there anything incorrectly?
Please let me know your comments.
Signed-off-by: Jinke Fan <fan...@ye...>
---
coregrind/m_cache.c | 3 ++-
coregrind/m_machine.c | 4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/coregrind/m_cache.c b/coregrind/m_cache.c
index 974ca5dde..0cbaa137e 100644
--- a/coregrind/m_cache.c
+++ b/coregrind/m_cache.c
@@ -501,7 +501,8 @@ get_caches_from_CPUID(VexCacheInfo *ci)
if (0 == VG_(strcmp)(vendor_id, "GenuineIntel")) {
ret = Intel_cache_info(level, ci);
- } else if (0 == VG_(strcmp)(vendor_id, "AuthenticAMD")) {
+ } else if (0 == VG_(strcmp)(vendor_id, "AuthenticAMD") ||
+ 0 == VG_(strcmp)(vendor_id, "HygonGenuine")) {
ret = AMD_cache_info(ci);
} else if (0 == VG_(strcmp)(vendor_id, "CentaurHauls")) {
diff --git a/coregrind/m_machine.c b/coregrind/m_machine.c
index df842aab2..bb2010ccd 100644
--- a/coregrind/m_machine.c
+++ b/coregrind/m_machine.c
@@ -905,7 +905,8 @@ Bool VG_(machine_get_hwcaps)( void )
/* Figure out if this is an AMD that can do MMXEXT. */
have_mmxext = False;
- if (0 == VG_(strcmp)(vstr, "AuthenticAMD")
+ if (((0 == VG_(strcmp)(vstr, "AuthenticAMD")) ||
+ (0 == VG_(strcmp)(vstr, "HygonGenuine")))
&& max_extended >= 0x80000001) {
VG_(cpuid)(0x80000001, 0, &eax, &ebx, &ecx, &edx);
/* Some older AMD processors support a sse1 subset (Integer
SSE). */
@@ -915,6 +916,7 @@ Bool VG_(machine_get_hwcaps)( void )
/* Figure out if this is an AMD or Intel that can do LZCNT. */
have_lzcnt = False;
if ((0 == VG_(strcmp)(vstr, "AuthenticAMD")
+ || 0 == VG_(strcmp)(vstr, "HygonGenuine")
|| 0 == VG_(strcmp)(vstr, "GenuineIntel"))
&& max_extended >= 0x80000001) {
VG_(cpuid)(0x80000001, 0, &eax, &ebx, &ecx, &edx);
--
2.17.1
|
|
From: Philippe W. <phi...@sk...> - 2019-05-14 03:48:31
|
On Mon, 2019-05-13 at 12:22 +0200, Julian Seward wrote: > I would prefer this: > > Original: > Address 0x51d8048 is 8 bytes inside a block of size 15 alloc'd > > Extended: > Address 0x51d8048 is 8 bytes inside a block of size 15 with base address > 0x51d8040, alloc'd > > In particular I'd prefer to not use the [0x51d8040, +15) notation since I > think many users won't know what it means, or at best will be uncertain > what it means. > > Philippe, are you proposing this as a change to the default output, or to be > available only when specifying a flag? I'm reluctant to change the default > output here, since this actually adds redundancy to the error messages which > in general are already long, verbose, and (at least so it seemed in early > years of the project) which users sometimes don't read entirely. Another possible layout is: Address 0x51d8048 is 8 bytes inside a block 0x51d8040[15] alloc'd That is short, and should be understandable by most people that have done some c or c++ or syntactically similar languages. Otherwise, yes, I was thinking to change the default output. But seeing how many people are preferring very different layout, maybe we better have an option to indicate what layout the user wants. Philippe |