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
(3) |
2
(2) |
3
|
4
(1) |
|
5
|
6
(2) |
7
|
8
(1) |
9
|
10
(2) |
11
(8) |
|
12
(2) |
13
(9) |
14
(2) |
15
(6) |
16
(5) |
17
(3) |
18
|
|
19
|
20
(1) |
21
(1) |
22
(6) |
23
(8) |
24
(2) |
25
(1) |
|
26
|
27
(3) |
28
(8) |
29
(17) |
30
(6) |
31
(3) |
|
|
From: Aleksandar R. <ale...@rt...> - 2017-03-30 12:27:51
|
I'm not able to reproduce this issue on Octeon3 (or any other board). It looks like https://bugs.kde.org/show_bug.cgi?id=342356 issue which is fixed in r15813. Can you confirm that you are running the latest SVN version of Valgrind ? On 30.03.2017. 13:22, John Reiser wrote: >> As there is no getconf cmd on my board, I wrote a program called >> 'getpagesize'. And the pagesize it returned is 65536B. > [[those lines above are from another message]] > >> test@xxx:~$ strace -e trace=memory valgrind > [[snip]] >> mmap(0x802001000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, >> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = -1 EINVAL (Invalid argument) > [[snip]] >> mmap(0x802001000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, >> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = -1 EINVAL (Invalid argument) > So the valgrind bug is asking for MAP_FIXED with an address that is not > on a page boundary (PAGE_SIZE [also spelled PAGESIZE] being 65536==0x10000). > (Notice that all the successful calls to mmap(), which have been snipped above, > all specify an address that is a multiple of 64KiB.) > > Please file a bug report at bugs.kde.org with component 'valgrind'. > In the bug report please include the hardware info (output from > /usr/bin/lscpu or "cat /proc/cpuinfo") and software info ("uname -a") > and the info that the pagesize is 64KiB. > > Then run valgrind under gdb, use a breakpoint to find the call to > mmap(0x....1000,,,MAP_FIXED,,), look at the backtrace, > and try to figure out why valgrind thought it could specify > an address that was not a multiple of the pagesize. > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
Author: sewardj
Date: Thu Mar 30 13:14:23 2017
New Revision: 16290
Log:
Bug 358697 - valgrind.h: Some code remains even when defining NVALGRIND.
Patch from Matthias Schwarzott (zz...@ge...). The patch removes
a volatile memory read which was only there to stop compilers warning
about |format| being unused.
Added:
trunk/none/tests/vgprintf_nvalgrind.stderr.exp
trunk/none/tests/vgprintf_nvalgrind.vgtest
Modified:
trunk/include/valgrind.h
trunk/none/tests/Makefile.am
Modified: trunk/include/valgrind.h
==============================================================================
--- trunk/include/valgrind.h (original)
+++ trunk/include/valgrind.h Thu Mar 30 13:14:23 2017
@@ -6769,7 +6769,7 @@
VALGRIND_PRINTF(const char *format, ...)
{
#if defined(NVALGRIND)
- if (format) *(volatile const char *)format; /* avoid compiler warning */
+ (void)format;
return 0;
#else /* NVALGRIND */
#if defined(_MSC_VER) || defined(__MINGW64__)
@@ -6808,7 +6808,7 @@
VALGRIND_PRINTF_BACKTRACE(const char *format, ...)
{
#if defined(NVALGRIND)
- if (format) *(volatile const char *)format; /* avoid compiler warning */
+ (void)format;
return 0;
#else /* NVALGRIND */
#if defined(_MSC_VER) || defined(__MINGW64__)
Modified: trunk/none/tests/Makefile.am
==============================================================================
--- trunk/none/tests/Makefile.am (original)
+++ trunk/none/tests/Makefile.am Thu Mar 30 13:14:23 2017
@@ -203,6 +203,7 @@
tls.vgtest tls.stderr.exp tls.stdout.exp \
unit_debuglog.stderr.exp unit_debuglog.vgtest \
vgprintf.stderr.exp vgprintf.vgtest \
+ vgprintf_nvalgrind.stderr.exp vgprintf_nvalgrind.vgtest \
process_vm_readv_writev.stderr.exp process_vm_readv_writev.vgtest
check_PROGRAMS = \
@@ -248,6 +249,7 @@
unit_debuglog \
valgrind_cpp_test \
vgprintf \
+ vgprintf_nvalgrind \
coolo_sigaction \
gxx304 \
process_vm_readv_writev
@@ -362,6 +364,9 @@
tls2_so_LDFLAGS = -shared
endif
+vgprintf_nvalgrind_SOURCES = vgprintf.c
+vgprintf_nvalgrind_CFLAGS = -DNVALGRIND
+
valgrind_cpp_test_SOURCES = valgrind_cpp_test.cpp
valgrind_cpp_test_LDADD = -lstdc++
Added: trunk/none/tests/vgprintf_nvalgrind.stderr.exp
==============================================================================
--- trunk/none/tests/vgprintf_nvalgrind.stderr.exp (added)
+++ trunk/none/tests/vgprintf_nvalgrind.stderr.exp Thu Mar 30 13:14:23 2017
@@ -0,0 +1,4 @@
+
+0
+0
+
Added: trunk/none/tests/vgprintf_nvalgrind.vgtest
==============================================================================
--- trunk/none/tests/vgprintf_nvalgrind.vgtest (added)
+++ trunk/none/tests/vgprintf_nvalgrind.vgtest Thu Mar 30 13:14:23 2017
@@ -0,0 +1 @@
+prog: vgprintf_nvalgrind
|
|
From: John R. <jr...@bi...> - 2017-03-30 11:22:24
|
> As there is no getconf cmd on my board, I wrote a program called > 'getpagesize'. And the pagesize it returned is 65536B. [[those lines above are from another message]] > test@xxx:~$ strace -e trace=memory valgrind [[snip]] > mmap(0x802001000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = -1 EINVAL (Invalid argument) [[snip]] > mmap(0x802001000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = -1 EINVAL (Invalid argument) So the valgrind bug is asking for MAP_FIXED with an address that is not on a page boundary (PAGE_SIZE [also spelled PAGESIZE] being 65536==0x10000). (Notice that all the successful calls to mmap(), which have been snipped above, all specify an address that is a multiple of 64KiB.) Please file a bug report at bugs.kde.org with component 'valgrind'. In the bug report please include the hardware info (output from /usr/bin/lscpu or "cat /proc/cpuinfo") and software info ("uname -a") and the info that the pagesize is 64KiB. Then run valgrind under gdb, use a breakpoint to find the call to mmap(0x....1000,,,MAP_FIXED,,), look at the backtrace, and try to figure out why valgrind thought it could specify an address that was not a multiple of the pagesize. |
|
From: zboom <net...@fo...> - 2017-03-30 10:49:06
|
I have got the svn trunk code, but I could not find the Macro defined in the patch, Why ? $ svn info Path: . Working Copy Root Path: /home/zboom/Downloads/valgrind URL: svn://svn.valgrind.org/valgrind/trunk Relative URL: ^/trunk Repository Root: svn://svn.valgrind.org/valgrind Repository UUID: a5019735-40e9-0310-863c-91ae7b9d1cf9 Revision: 16289 Node Kind: directory Schedule: normal Last Changed Author: iraisr Last Changed Rev: 16287 Last Changed Date: 2017-03-27 13:06:32 +0800 (一, 27 3月 2017) zboom@zboom-Lenovo:~/Downloads/valgrind$ grep -rn "_MIPS_ARCH_OCTEON3" . -- View this message in context: http://valgrind.10908.n7.nabble.com/Why-valgrind-could-not-be-used-on-cavium-octeon3-tp57531p57548.html Sent from the Valgrind - Dev mailing list archive at Nabble.com. |
|
From: zboom <net...@fo...> - 2017-03-30 10:23:37
|
Here is the system message about memory:
$ free -m
total used free shared buff/cache
available
Mem: 8070 527 6535 254 1007
6392
Swap: 414 0 414
$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 8070
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 8070
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
$ uname -a
Linux 3.10.87-rt80-yocto-standard #2 SMP Wed Mar 22 17:17:38 CST 2017 mips64
mips64 mips64 GNU/Linux
$ cat /proc/meminfo
MemTotal: 8264384 kB
MemFree: 6886656 kB
Buffers: 42560 kB
Cached: 935424 kB
SwapCached: 0 kB
Active: 492672 kB
Inactive: 687744 kB
Active(anon): 345088 kB
Inactive(anon): 118144 kB
Active(file): 147584 kB
Inactive(file): 569600 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 424704 kB
SwapFree: 424704 kB
Dirty: 768 kB
Writeback: 0 kB
AnonPages: 202496 kB
Mapped: 51968 kB
Shmem: 260864 kB
Slab: 59712 kB
SReclaimable: 25984 kB
SUnreclaim: 33728 kB
KernelStack: 8704 kB
PageTables: 9792 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 8275840 kB
Committed_AS: 712512 kB
VmallocTotal: 4290772864 kB
VmallocUsed: 15232 kB
VmallocChunk: 4290754624 kB
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 524288 kB
As there is no getconf cmd on my board, I wrote a program called
'getpagesize'. And the pagesize it returned is 65536B.
--
View this message in context: http://valgrind.10908.n7.nabble.com/Why-valgrind-could-not-be-used-on-cavium-octeon3-tp57531p57547.html
Sent from the Valgrind - Dev mailing list archive at Nabble.com.
|
|
From: zboom <net...@fo...> - 2017-03-30 09:01:35
|
Here is the message printed by the non superuser: root@xxx:~# adduser test Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully root@xxx:~# su test test@xxx:~$ strace -e trace=memory valgrind brk(NULL) = 0x12b160000 mmap(NULL, 9594, PROT_READ, MAP_PRIVATE, 3, 0) = 0xffe80d0000 mmap(NULL, 1790224, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffe7f10000 mmap(0xffe80a0000, 196608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x180000) = 0xffe80a0000 mprotect(0xffe80a0000, 65536, PROT_READ) = 0 munmap(0xffe80d0000, 9594) = 0 brk(NULL) = 0x12b160000 brk(0x12b190000) = 0x12b190000 mmap(0x802001000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = -1 EINVAL (Invalid argument) --4198:0: aspacem <<< SHOW_SEGMENTS: out_of_memory (13 segments) --4198:0: aspacem 1 segment names in 1 slots --4198:0: aspacem freelist is empty --4198:0: aspacem (0,4,2) /usr/lib/valgrind/memcheck-mips64-linux --4198:0: aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed --4198:0: aspacem 1: 0004000000-0037ffffff 832m --4198:0: aspacem 2: FILE 0038000000-003823ffff 2359296 r-x-- d=0xb301 i=12614 o=0 (0,4) --4198:0: aspacem 3: FILE 0038240000-003826ffff 196608 rw--- d=0xb301 i=12614 o=2293760 (0,4) --4198:0: aspacem 4: ANON 0038270000-003943ffff 17m rwx-- --4198:0: aspacem 5: 0039440000-0801ffffff 31883m --4198:0: aspacem 6: RSVN 0802000000-0802000fff 4096 ----- SmFixed --4198:0: aspacem 7: 0802001000-0fffffffff 32735m --4198:0: aspacem 8: RSVN 1000000000-ffdf95ffff 982521m ----- SmFixed --4198:0: aspacem 9: ANON ffdf960000-ffdf98ffff 196608 rwx-- --4198:0: aspacem 10: RSVN ffdf990000-fffffeffff 518m ----- SmFixed --4198:0: aspacem 11: ANON ffffff0000-ffffffffff 65536 r-x-- --4198:0: aspacem 12: RSVN 10000000000-ffffffffffffffff 16383e ----- SmFixed --4198:0: aspacem >>> --4198-- core : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB --4198-- dinfo : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB --4198-- (null) : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 0 rzB --4198-- demangle: 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB --4198-- ttaux : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB --4198-- translate: no SP updates identified --4198-- translate: PX: SPonly 0, UnwRegs 0, AllRegs 0, AllRegsAllInsns 0 --4198-- tt/tc: 0 tt lookups requiring 0 probes --4198-- tt/tc: 0 fast-cache updates, 0 flushes --4198-- transtab: new 0 (0 -> 0; ratio 0.0) [0 scs] avg tce size 0 --4198-- transtab: dumped 0 (0 -> ??) (sectors recycled 0) --4198-- transtab: discarded 0 (0 -> ??) --4198-- scheduler: 0 event checks. --4198-- scheduler: 0 indir transfers, 0 misses (1 in 0) --4198-- scheduler: 0/0 major/minor sched events. --4198-- sanity: 0 cheap, 0 expensive checks. mmap(0x802001000, 4194304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0, 0) = -1 EINVAL (Invalid argument) ==4198== ==4198== Valgrind's memory management: out of memory: ==4198== newSuperblock's request for 4194304 bytes failed. ==4198== 18,939,904 bytes have already been mmap-ed ANONYMOUS. ==4198== Valgrind cannot continue. Sorry. ==4198== ==4198== There are several possible reasons for this. ==4198== - You have some kind of memory limit in place. Look at the ==4198== output of 'ulimit -a'. Is there a limit on the size of ==4198== virtual memory or address space? ==4198== - You have run out of swap space. ==4198== - Valgrind has a bug. If you think this is the case or you are ==4198== not sure, please let us know and we'll try to fix it. ==4198== Please note that programs can take substantially more memory than ==4198== normal when running under Valgrind tools, eg. up to twice or ==4198== more, depending on the tool. On a 64-bit machine, Valgrind ==4198== should be able to make use of up 32GB memory. On a 32-bit ==4198== machine, Valgrind should be able to use all the memory available ==4198== to a single process, up to 4GB if that's how you have your ==4198== kernel configured. Most 32-bit Linux setups allow a maximum of ==4198== 3GB per process. ==4198== ==4198== Whatever the reason, Valgrind cannot continue. Sorry. +++ exited with 1 +++ -- View this message in context: http://valgrind.10908.n7.nabble.com/Why-valgrind-could-not-be-used-on-cavium-octeon3-tp57531p57546.html Sent from the Valgrind - Dev mailing list archive at Nabble.com. |