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
(1) |
2
(4) |
3
(2) |
4
|
|
5
(1) |
6
|
7
(1) |
8
(2) |
9
(3) |
10
(1) |
11
(6) |
|
12
|
13
(2) |
14
(4) |
15
(2) |
16
(1) |
17
(1) |
18
(24) |
|
19
(1) |
20
(4) |
21
(1) |
22
|
23
|
24
(5) |
25
(2) |
|
26
(6) |
27
(3) |
28
(5) |
|
|
|
|
|
From: <sv...@va...> - 2017-02-03 01:20:03
|
Author: petarj
Date: Fri Feb 3 01:19:55 2017
New Revision: 16220
Log:
fix leak-segv-jmp test for platforms with 64K pagesize
Increase the size of allocated array, so mprotect call does not end up
protecting non-allocated areas. This enables the test to work on
platforms with pagesize=64K.
Issue discovered on MIPS XLP machine with 64K pagesize.
Modified:
trunk/memcheck/tests/leak-segv-jmp.c
trunk/memcheck/tests/leak-segv-jmp.stderr.exp
Modified: trunk/memcheck/tests/leak-segv-jmp.c
==============================================================================
--- trunk/memcheck/tests/leak-segv-jmp.c (original)
+++ trunk/memcheck/tests/leak-segv-jmp.c Fri Feb 3 01:19:55 2017
@@ -287,7 +287,7 @@
long pagesize;
#define RNDPAGEDOWN(a) ((long)a & ~(pagesize-1))
int i;
- const int nr_ptr = (10000 * 4)/sizeof(char*);
+ const int nr_ptr = (10000 * 20)/sizeof(char*);
b10 = calloc (nr_ptr * sizeof(char*), 1);
for (i = 0; i < nr_ptr; i++)
Modified: trunk/memcheck/tests/leak-segv-jmp.stderr.exp
==============================================================================
--- trunk/memcheck/tests/leak-segv-jmp.stderr.exp (original)
+++ trunk/memcheck/tests/leak-segv-jmp.stderr.exp Fri Feb 3 01:19:55 2017
@@ -6,7 +6,7 @@
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
- still reachable: 41,000 bytes in 2 blocks
+ still reachable: 201,000 bytes in 2 blocks
suppressed: 0 bytes in 0 blocks
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-leak-kinds=all
@@ -21,7 +21,7 @@
definitely lost: 1,000 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
- still reachable: 40,000 bytes in 1 blocks
+ still reachable: 200,000 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-leak-kinds=all
@@ -37,7 +37,7 @@
definitely lost: 1,000 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
- still reachable: 40,000 bytes in 1 blocks
+ still reachable: 200,000 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-leak-kinds=all
@@ -53,7 +53,7 @@
definitely lost: 1,000 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
- still reachable: 40,000 bytes in 1 blocks
+ still reachable: 200,000 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-leak-kinds=all
@@ -65,7 +65,7 @@
by 0x........: f (leak-segv-jmp.c:295)
by 0x........: main (leak-segv-jmp.c:370)
-40,000 bytes in 1 blocks are possibly lost in loss record ... of ...
+200,000 bytes in 1 blocks are possibly lost in loss record ... of ...
at 0x........: calloc (vg_replace_malloc.c:...)
by 0x........: f (leak-segv-jmp.c:342)
by 0x........: main (leak-segv-jmp.c:370)
@@ -73,8 +73,8 @@
LEAK SUMMARY:
definitely lost: 1,000 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
- possibly lost: 40,000 bytes in 1 blocks
- still reachable: 40,000 bytes in 1 blocks
+ possibly lost: 200,000 bytes in 1 blocks
+ still reachable: 200,000 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-leak-kinds=all
@@ -83,19 +83,19 @@
LEAK SUMMARY:
definitely lost: 1,000 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
- possibly lost: 40,000 bytes in 1 blocks
- still reachable: 40,000 bytes in 1 blocks
+ possibly lost: 200,000 bytes in 1 blocks
+ still reachable: 200,000 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
Rerun with --leak-check=full to see details of leaked memory
leaked: 1000 bytes in 1 blocks
-dubious: 40000 bytes in 1 blocks
-reachable: 40000 bytes in 1 blocks
+dubious: 200000 bytes in 1 blocks
+reachable: 200000 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
HEAP SUMMARY:
- in use at exit: 81,000 bytes in 3 blocks
- total heap usage: 3 allocs, 0 frees, 81,000 bytes allocated
+ in use at exit: 401,000 bytes in 3 blocks
+ total heap usage: 3 allocs, 0 frees, 401,000 bytes allocated
For a detailed leak analysis, rerun with: --leak-check=full
|
|
From: <sv...@va...> - 2017-02-03 00:35:02
|
Author: petarj
Date: Fri Feb 3 00:34:52 2017
New Revision: 16219
Log:
add suppression for helgrind/tests/tc22_exit_w_lock
Function pthread_create indirectly calls function memcpy. Helgrind
considers that memcpy is not thread safe function. For error reported
from pthread_create there is the suppression helgrind---_dl_allocate_tls
in the file glibc-2.34567-NPTL-helgrind.supp.
Since glibc version 2.23, memcpy is implemented by __mempcpy_inline.
This causes that call to memcpy from pthread_create is no longer
recognized by the suppression.
In test helgrind/tests/tc22_exit_w_lock, pthread_create is called twice,
and second call reports error, which causes failing of the test.
This patch adds suppression for glibc 2.23 and greater.
Patch by Tamara Vlahovic.
Related issue #375806.
Modified:
trunk/NEWS
trunk/glibc-2.34567-NPTL-helgrind.supp
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Fri Feb 3 00:34:52 2017
@@ -113,6 +113,7 @@
375514 valgrind_get_tls_addr() does not work in case of static TLS
375772 +1 error in get_elf_symbol_info() when computing value of 'hi' address
for ML_(find_rx_mapping)()
+375806 Test helgrind/tests/tc22_exit_w_lock fails with glibc 2.24
Release 3.12.0 (20 October 2016)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Modified: trunk/glibc-2.34567-NPTL-helgrind.supp
==============================================================================
--- trunk/glibc-2.34567-NPTL-helgrind.supp (original)
+++ trunk/glibc-2.34567-NPTL-helgrind.supp Fri Feb 3 00:34:52 2017
@@ -267,6 +267,18 @@
fun:pthread_create@*
}
+{
+ helgrind---_dl_allocate_tls2
+ Helgrind:Race
+ fun:memcpy
+ fun:__mempcpy_inline
+ fun:_dl_allocate_tls_init
+ ...
+ fun:pthread_create@@GLIBC_2.2*
+ fun:pthread_create_WRK
+ fun:pthread_create@*
+}
+
####################################################
# To do with GNU libgomp
#
|
|
From: Philippe W. <phi...@sk...> - 2017-02-02 18:16:51
|
On Thu, 2017-02-02 at 18:14 +0100, Petar Jovanovic wrote: > Has anyone tested memcheck/tests/leak-segv-jmp on platforms with larger > page sizes, e.g. 64K? > It causes a segmentation fault, since mprotect call protects non- > allocated areas too, and the call to calloc crashes afterwards. > > Anyone objects if value of nr_ptr is increased to cover this case? > See the patch below. The change looks good to me. Philippe |
|
From: Mark W. <mj...@re...> - 2017-02-02 17:27:04
|
Hi Hackers, users and valgrind enthusiasts, This is a reminder that our valgrind devroom meeting at Fosdem, Brussels, is this Saturday. For detials, see below. Also please let me know if you have any issues you want to discuss during the valgrind hackaton event (even if you cannot come, you can submit ideas!) If you are giving a presentation earlier on the day, but have some bonus slides that you might not have time to present (we will be strict on time) then feel free to sent them to me and/or feel free to suggest you present the extra bonus material at the hackaton. On Mon, Dec 12, 2016 at 01:46:39PM +0100, Mark Wielaard wrote: > Hi Valgrind users, hackers and enthusiasts, > > We have program from the valgrind devroom that will take place during > Fosdem in Brussels on Saturday 5 February 2017: > https://fosdem.org/2017/schedule/track/valgrind/ > > The last session will be the Valgrind BoF and Hackaton! > > We need your help for that session! The simplest way to help is to just > show up and discuss anything you like and then start hacking! But it is > also fun to have a little structure to the session by letting us know > beforehand what you think we should discuss and/or hack on. > > Here is the current desciption, please help improve it: > > Valgrind BoF and Hackaton > Open discussion of ideas for Valgrind - and then we hack! > https://fosdem.org/2017/schedule/event/valgrind_hackaton/ > > Come and hack on Valgrind together. Open discussion about small (or big) > ideas to improve or change Valgrind. > > Valgrind developers and users are encouraged to participate either by > submitting ideas/suggestions or by joining the discussion. And of course > by kindly (or bitterly) complain about bugs you find important that are > still Not YET solved for that many years!?@!!! > > Afterwards we will sit together and try to fix or implement some of the > things discussed. > > > Discuss any kind of possible improvement (technical or functional) to > Valgrind. > > If you want to put something on the agenda please send a small > description (one or two paragraphs) to the the moderator Mark Wielaard > mj...@re... with in the subject: "FOSDEM devroom discuss: ..." If you > want to discuss a somewhat larger topic please do feel free to send two > or three slides in advance. > > Mark will collect ideas/suggestions/... and present these and coordinate > the discussion (and keep track of the time, so every idea will be > discussed). > > Some discussion topic ideas: > > * Release/bugfixing strategy/policy. > * Can we move to git yet? > * Valgrind and transactional memory. > * Making Valgrind really multi-threaded, parallelising Memcheck, > parallelising the rest of the framework, and tools. > * Instant leak detector. Modify memcheck to report the last leaked > pointer to a block. Integrate "omega" as a memcheck option or > omega as a separate tool. > http://www.brainmurders.eclipse.co.uk/omega.html > * Make Callgrind work sanely on ARM (and PPC). The Callgrind > algorithm to track call and return is to be improved to work > properly on these platforms. Is there a way to make this better? > E.g. by having a fast way working in most cases, and rely on > unwind info in the difficult cases. Can we detect at > instrumentation time that an instruction is a difficult case? > * Packaging valgrind for distros, handling patches, suppressions, > etc. > * 32-bit x86 vs modern instruction sets (avx, etc.) > * VEX is in theory cross-architecture. What would it take to make > valgrind cross-arch? How about starting with i686 on x86_64? > * Which CPUID is it anyway? Valgrind isn't completely consistent > in handling host CPU capabilities vs VEX emulation capabilities. > What can we do to improve that? Make it user tunable? > * <YOUR SUGGESTION HERE!> > > And now is the time on Sprockets when we hack! |
|
From: <sv...@va...> - 2017-02-02 17:24:23
|
Author: petarj
Date: Thu Feb 2 17:24:14 2017
New Revision: 16218
Log:
Add PROT_READ flag to mmap, as Valgrind needs to be able to read the
code before it executes it.
This fixes none/tests/bigcode on some MIPS platforms.
Modified:
trunk/perf/bigcode.c
Modified: trunk/perf/bigcode.c
==============================================================================
--- trunk/perf/bigcode.c (original)
+++ trunk/perf/bigcode.c Thu Feb 2 17:24:14 2017
@@ -75,7 +75,7 @@
printf("%d copies of f(), %d reps\n", n_fns, n_reps);
char* a = mmap(0, FN_SIZE * n_fns,
- PROT_EXEC|PROT_WRITE,
+ PROT_EXEC|PROT_WRITE|PROT_READ,
MAP_PRIVATE|MAP_ANONYMOUS, -1,0);
assert(a != (char*)MAP_FAILED);
|
|
From: Petar J. <mip...@gm...> - 2017-02-02 17:14:45
|
Has anyone tested memcheck/tests/leak-segv-jmp on platforms with larger
page sizes, e.g. 64K?
It causes a segmentation fault, since mprotect call protects non-
allocated areas too, and the call to calloc crashes afterwards.
Anyone objects if value of nr_ptr is increased to cover this case?
See the patch below.
Regards,
Petar
diff --git a/memcheck/tests/leak-segv-jmp.c b/memcheck/tests/leak-segv-jmp.c
index 1d1f84c..5435185 100644
--- a/memcheck/tests/leak-segv-jmp.c
+++ b/memcheck/tests/leak-segv-jmp.c
@@ -287,7 +287,7 @@ void f(void)
long pagesize;
#define RNDPAGEDOWN(a) ((long)a & ~(pagesize-1))
int i;
- const int nr_ptr = (10000 * 4)/sizeof(char*);
+ const int nr_ptr = (10000 * 20)/sizeof(char*);
b10 = calloc (nr_ptr * sizeof(char*), 1);
for (i = 0; i < nr_ptr; i++)
diff --git a/memcheck/tests/leak-segv-jmp.stderr.exp
b/memcheck/tests/leak-segv-jmp.stderr.exp
index 1ee37cd..f455bd5 100644
--- a/memcheck/tests/leak-segv-jmp.stderr.exp
+++ b/memcheck/tests/leak-segv-jmp.stderr.exp
@@ -6,7 +6,7 @@ LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
- still reachable: 41,000 bytes in 2 blocks
+ still reachable: 201,000 bytes in 2 blocks
suppressed: 0 bytes in 0 blocks
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-leak-kinds=all
@@ -21,7 +21,7 @@ LEAK SUMMARY:
definitely lost: 1,000 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
- still reachable: 40,000 bytes in 1 blocks
+ still reachable: 200,000 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-leak-kinds=all
@@ -37,7 +37,7 @@ LEAK SUMMARY:
definitely lost: 1,000 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
- still reachable: 40,000 bytes in 1 blocks
+ still reachable: 200,000 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-leak-kinds=all
@@ -53,7 +53,7 @@ LEAK SUMMARY:
definitely lost: 1,000 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
- still reachable: 40,000 bytes in 1 blocks
+ still reachable: 200,000 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-leak-kinds=all
@@ -65,7 +65,7 @@ expecting heuristic not to crash after full mprotect
by 0x........: f (leak-segv-jmp.c:295)
by 0x........: main (leak-segv-jmp.c:370)
-40,000 bytes in 1 blocks are possibly lost in loss record ... of ...
+200,000 bytes in 1 blocks are possibly lost in loss record ... of ...
at 0x........: calloc (vg_replace_malloc.c:...)
by 0x........: f (leak-segv-jmp.c:342)
by 0x........: main (leak-segv-jmp.c:370)
@@ -73,8 +73,8 @@ expecting heuristic not to crash after full mprotect
LEAK SUMMARY:
definitely lost: 1,000 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
- possibly lost: 40,000 bytes in 1 blocks
- still reachable: 40,000 bytes in 1 blocks
+ possibly lost: 200,000 bytes in 1 blocks
+ still reachable: 200,000 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
Reachable blocks (those to which a pointer was found) are not shown.
To see them, rerun with: --leak-check=full --show-leak-kinds=all
@@ -83,19 +83,19 @@ finished
LEAK SUMMARY:
definitely lost: 1,000 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
- possibly lost: 40,000 bytes in 1 blocks
- still reachable: 40,000 bytes in 1 blocks
+ possibly lost: 200,000 bytes in 1 blocks
+ still reachable: 200,000 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
Rerun with --leak-check=full to see details of leaked memory
leaked: 1000 bytes in 1 blocks
-dubious: 40000 bytes in 1 blocks
-reachable: 40000 bytes in 1 blocks
+dubious: 200000 bytes in 1 blocks
+reachable: 200000 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
HEAP SUMMARY:
- in use at exit: 81,000 bytes in 3 blocks
- total heap usage: 3 allocs, 0 frees, 81,000 bytes allocated
+ in use at exit: 401,000 bytes in 3 blocks
+ total heap usage: 3 allocs, 0 frees, 401,000 bytes allocated
For a detailed leak analysis, rerun with: --leak-check=full
|
|
From: Petar J. <mip...@gm...> - 2017-02-01 16:43:56
|
Hi All,
I would like to add a minor change to bigcode.c test:
Index: perf/bigcode.c
===================================================================
--- perf/bigcode.c (revision 16216)
+++ perf/bigcode.c (working copy)
@@ -75,7 +75,7 @@
printf("%d copies of f(), %d reps\n", n_fns, n_reps);
char* a = mmap(0, FN_SIZE * n_fns,
- PROT_EXEC|PROT_WRITE,
+ PROT_EXEC|PROT_WRITE|PROT_READ,
MAP_PRIVATE|MAP_ANONYMOUS, -1,0);
assert(a != (char*)MAP_FAILED);
The test is failing on some MIPS platforms, as PROT_READ is not allowed.
I guess that most of the platforms implement PROT_EXEC as
PROT_READ|PROT_EXEC, otherwise this would be failing on other systems
too.
Let me know if anyone objects or if I am missing something obvious.
Regards,
Petar
|