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
(1) |
3
|
|
4
|
5
(1) |
6
(2) |
7
(1) |
8
(1) |
9
(2) |
10
|
|
11
|
12
|
13
(6) |
14
(4) |
15
(1) |
16
(4) |
17
(2) |
|
18
(1) |
19
(8) |
20
(8) |
21
(2) |
22
(3) |
23
(3) |
24
|
|
25
|
26
|
27
(1) |
28
|
29
|
30
|
31
(2) |
|
From: Petar J. <pe...@so...> - 2019-08-20 14:12:24
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=23a950be4be11685a62e08374cd339bbdd25b9d9 commit 23a950be4be11685a62e08374cd339bbdd25b9d9 Author: Petar Jovanovic <mip...@gm...> Date: Tue Aug 20 13:30:45 2019 +0000 mips32: hook up vhangup syscall Hook up vhangup syscall for mips32. This fixes vhangup01 in the LTP test suite. Diff: --- coregrind/m_syswrap/syswrap-mips32-linux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/coregrind/m_syswrap/syswrap-mips32-linux.c b/coregrind/m_syswrap/syswrap-mips32-linux.c index fe1531f..9512510 100644 --- a/coregrind/m_syswrap/syswrap-mips32-linux.c +++ b/coregrind/m_syswrap/syswrap-mips32-linux.c @@ -876,7 +876,7 @@ static SyscallTableEntry syscall_main_table[] = { GENXY (__NR_fstat, sys_newfstat), // 108 //.. // (__NR_olduname, sys_uname), // 109 //.. GENX_(__NR_iopl, sys_iopl), // 110 - //.. LINX_(__NR_vhangup, sys_vhangup), // 111 + LINX_ (__NR_vhangup, sys_vhangup), // 111 //.. GENX_(__NR_idle, sys_ni_syscall), // 112 //.. // (__NR_vm86old, sys_vm86old), // 113 GENXY (__NR_wait4, sys_wait4), // 114 |
|
From: Petar J. <pe...@so...> - 2019-08-20 14:12:19
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=b086d63a730a008be4eb311fe42a95706ecd6c96 commit b086d63a730a008be4eb311fe42a95706ecd6c96 Author: Petar Jovanovic <mip...@gm...> Date: Tue Aug 20 13:17:02 2019 +0000 mips32: hook up utimes syscall Hook up utimes syscall for mips32. This fixes utimes01 in the LTP test suite. Diff: --- coregrind/m_syswrap/syswrap-mips32-linux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/coregrind/m_syswrap/syswrap-mips32-linux.c b/coregrind/m_syswrap/syswrap-mips32-linux.c index a7e0ca5..fe1531f 100644 --- a/coregrind/m_syswrap/syswrap-mips32-linux.c +++ b/coregrind/m_syswrap/syswrap-mips32-linux.c @@ -1029,7 +1029,7 @@ static SyscallTableEntry syscall_main_table[] = { LINXY (__NR_clock_getres, sys_clock_getres), // 264 LINXY (__NR_clock_nanosleep, sys_clock_nanosleep), // 265 LINXY (__NR_tgkill, sys_tgkill), // 266 - //.. GENX_(__NR_utimes, sys_utimes), // 267 + GENX_ (__NR_utimes, sys_utimes), // 267 LINXY (__NR_get_mempolicy, sys_get_mempolicy), // 269 LINX_ (__NR_set_mempolicy, sys_set_mempolicy), // 270 LINXY (__NR_mq_open, sys_mq_open), // 271 |
|
From: Petar J. <pe...@so...> - 2019-08-20 14:12:14
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=fd640dacde15705f1f233d2d53bc06588ffdcba0 commit fd640dacde15705f1f233d2d53bc06588ffdcba0 Author: Petar Jovanovic <mip...@gm...> Date: Tue Aug 20 12:41:59 2019 +0000 mips32: hook up unshare syscall Hook up unshare syscall for mips32. This fixes unshare02 in the LTP test suite. Diff: --- coregrind/m_syswrap/syswrap-mips32-linux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/coregrind/m_syswrap/syswrap-mips32-linux.c b/coregrind/m_syswrap/syswrap-mips32-linux.c index 5c34526..a7e0ca5 100644 --- a/coregrind/m_syswrap/syswrap-mips32-linux.c +++ b/coregrind/m_syswrap/syswrap-mips32-linux.c @@ -1059,7 +1059,7 @@ static SyscallTableEntry syscall_main_table[] = { LINX_ (__NR_faccessat, sys_faccessat), // 300 LINXY (__NR_pselect6, sys_pselect6), // 301 LINXY (__NR_ppoll, sys_ppoll), // 302 - //.. + LINX_ (__NR_unshare, sys_unshare), // 303 LINX_ (__NR_splice, sys_splice), // 304 PLAX_ (__NR_sync_file_range, sys_sync_file_range), // 305 LINX_ (__NR_tee, sys_tee), // 306 |
|
From: Petar J. <pe...@so...> - 2019-08-20 14:12:09
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=8055312c422f808b6794cf22a68422414524b4eb commit 8055312c422f808b6794cf22a68422414524b4eb Author: Petar Jovanovic <mip...@gm...> Date: Tue Aug 20 12:29:57 2019 +0000 mips32: hook up truncate64 syscall Hook up truncate64 syscall for mips32. This helps truncate02_64 and several other tests pass without warnings in the LTP test suite. Diff: --- coregrind/m_syswrap/syswrap-mips32-linux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/coregrind/m_syswrap/syswrap-mips32-linux.c b/coregrind/m_syswrap/syswrap-mips32-linux.c index 6da479b..5c34526 100644 --- a/coregrind/m_syswrap/syswrap-mips32-linux.c +++ b/coregrind/m_syswrap/syswrap-mips32-linux.c @@ -973,7 +973,7 @@ static SyscallTableEntry syscall_main_table[] = { //.. GENXY(__NR_getpmsg, sys_getpmsg), // 208 //.. GENX_(__NR_putpmsg, sys_putpmsg), // 209 PLAX_ (__NR_mmap2, sys_mmap2), // 210 - // GENX_(__NR_truncate64, sys_truncate64), // 211 + GENX_ (__NR_truncate64, sys_truncate64), // 211 GENX_ (__NR_ftruncate64, sys_ftruncate64), // 212 PLAXY (__NR_stat64, sys_stat64), // 213 PLAXY (__NR_lstat64, sys_lstat64), // 214 |
|
From: Tom H. <to...@co...> - 2019-08-20 13:47:16
|
On 20/08/2019 14:40, João M. S. Silva wrote:
> Thanks.
>
> I was using this before:
>
> #include <stdio.h>
>
> #define G 1<<30
>
> int main() {
> double w[G];
> double x[G];
> double y[G];
> double z[G];
>
> printf("w[1000] = %d\n", w[1000]);
> printf("x[1000] = %d\n", w[1000]);
> printf("y[1000] = %d\n", w[1000]);
> printf("z[1000] = %d\n", w[1000]);
>
> return 0;
> }
>
> I used the printf's in case the arrays were being removed by optimisation.
That is putting the arrays on the stack, which is completely different.
>> Nothing to do with Ada at all.
>
> When I mentioned Ada's elaboration I was referring to the other error
> I'm getting now:
>
> ==4925== Warning: set address range perms: large range [0xaef000,
> 0x13ef3000) (defined)
> ==4925==
> ==4925== Process terminating with default action of signal 6 (SIGABRT)
> ==4925== at 0x16592207: raise (in /usr/lib64/libc-2.17.so)
> ==4925== by 0x16593A37: abort (in /usr/lib64/libc-2.17.so)
> ==4925== by 0x16354E90: uw_init_context_1 (unwind-dw2.c:1580)
> ==4925== by 0x16355A17: _Unwind_Backtrace (unwind.inc:283)
> ==4925== by 0x816280: __gnat_backtrace (in
> /u/wh/rel/ifaplrel/pw_fwp_engine.eab)
> ==4925== by 0x80BE7C: system__traceback__call_chain__2 (s-traceb.adb:93)
> ==4925== by 0x80BEA4: system__traceback__call_chain (s-traceb.adb:109)
> ==4925== by 0x7FCCE9: ada__exceptions__call_chain (a-excach.adb:65)
> ==4925== by 0x7FCE3C: ada__exceptions__complete_occurrence (a-except.adb:928)
> ==4925== by 0x7FCE6C:
> ada__exceptions__complete_and_propagate_occurrence (a-except.adb:942)
> ==4925== by 0x7FD209: ada__exceptions__raise_with_location_and_msg
> (a-except.adb:1168)
> ==4925== by 0x7FD1C4: __gnat_raise_storage_error_msg (a-except.adb:1145)
>
> and that I mentioned yesterday.
That's a completely different issue by the looks of it.
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|
|
From: João M. S. S. <joa...@gm...> - 2019-08-20 13:41:20
|
> It's trivial:
>
> static char foo[2ULL * 1024 * 1024 * 1024];
>
> int main(int argc, char **argv)
> {
> return 0;
> }
Thanks.
I was using this before:
#include <stdio.h>
#define G 1<<30
int main() {
double w[G];
double x[G];
double y[G];
double z[G];
printf("w[1000] = %d\n", w[1000]);
printf("x[1000] = %d\n", w[1000]);
printf("y[1000] = %d\n", w[1000]);
printf("z[1000] = %d\n", w[1000]);
return 0;
}
I used the printf's in case the arrays were being removed by optimisation.
> Nothing to do with Ada at all.
When I mentioned Ada's elaboration I was referring to the other error
I'm getting now:
==4925== Warning: set address range perms: large range [0xaef000,
0x13ef3000) (defined)
==4925==
==4925== Process terminating with default action of signal 6 (SIGABRT)
==4925== at 0x16592207: raise (in /usr/lib64/libc-2.17.so)
==4925== by 0x16593A37: abort (in /usr/lib64/libc-2.17.so)
==4925== by 0x16354E90: uw_init_context_1 (unwind-dw2.c:1580)
==4925== by 0x16355A17: _Unwind_Backtrace (unwind.inc:283)
==4925== by 0x816280: __gnat_backtrace (in
/u/wh/rel/ifaplrel/pw_fwp_engine.eab)
==4925== by 0x80BE7C: system__traceback__call_chain__2 (s-traceb.adb:93)
==4925== by 0x80BEA4: system__traceback__call_chain (s-traceb.adb:109)
==4925== by 0x7FCCE9: ada__exceptions__call_chain (a-excach.adb:65)
==4925== by 0x7FCE3C: ada__exceptions__complete_occurrence (a-except.adb:928)
==4925== by 0x7FCE6C:
ada__exceptions__complete_and_propagate_occurrence (a-except.adb:942)
==4925== by 0x7FD209: ada__exceptions__raise_with_location_and_msg
(a-except.adb:1168)
==4925== by 0x7FD1C4: __gnat_raise_storage_error_msg (a-except.adb:1145)
and that I mentioned yesterday.
> A workaround is to link your executable to load at an address
> above the tool, for example:
>
> % gcc -Wl,-Ttext-segment=0x68000000 -o large large.c
> % valgrind ./large
> ...
I have created bug https://bugs.kde.org/show_bug.cgi?id=411100
according to your test case and Philippe's recommendation.
> or you could try editing configure.ac and changing the value
> of valt_load_address_pri_norml for your platform and rebuilding
> valgrind with the load address higher.
That's what I did when you suggested that in 2017 or 2018 but then the
program grew from ~1,7 GB to ~4 GB and that solution stopped being
effective.
But now, whether I use the linker option or not, I get the error
above, so I no longer get the mmap error.
João M. S. Silva
|
|
From: Tom H. <to...@co...> - 2019-08-20 11:16:46
|
On 20/08/2019 11:48, João M. S. Silva wrote:
>> You should:
>> 1) File a bug report, and post here a link to the bug report.
>
> Yes, I tried to create a reproducer by defining huge arrays but did
> not observe the error. That's when I tried to check the original code
> again.
>
>> 2) Attach to the bug report the source code for a reproducible test case.
>> Please use C language. If Ada, then be EXPLICIT about your build tools and recipe.
>
> Yes, I tried to create the test case in C but could not originate the error.
It's trivial:
static char foo[2ULL * 1024 * 1024 * 1024];
int main(int argc, char **argv)
{
return 0;
}
% gcc -o large large.c
% valgrind ./large
valgrind: mmap(0x405000, 2147483648) failed in UME with error 22 (Invalid argument).
valgrind: this can be caused by executables with very large text, data or bss segments.
>> IF YOU DO NOT DO THOSE TWO THINGS, THEN YOUR COMPLAINT LIKELY WILL BE FORGOTTEN AND/OR IGNORED.
>
> I thank you for you work and time. And I can assure you that I have
> put lots of effort in this issue already, and was not planning not to
> create a bug report. I always create issue reports when I find them in
> software, that's the least I can do. As I said, I was trying to create
> the report, but couldn't. I then thought I had come up with a
> different error, that's why I reported it here. I don't know if it's
> an error in Valgrind or our code, so I thought I could discuss it here
> before.
>
> It seems an error during Ada's elaboration.
Nothing to do with Ada at all.
The issue is that's valgrind's tools are, by default, linked to
load at 0x58000000 which means your executable needs to fit below
that if linked to load at the default load address.
A workaround is to link your executable to load at an address
above the tool, for example:
% gcc -Wl,-Ttext-segment=0x68000000 -o large large.c
% valgrind ./large
...
or you could try editing configure.ac and changing the value
of valt_load_address_pri_norml for your platform and rebuilding
valgrind with the load address higher.
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|
|
From: João M. S. S. <joa...@gm...> - 2019-08-20 10:49:11
|
> Some of your earlier reports related to this issue were in 2017 and 2018. > valgrind often releases a new version approximately yearly. I have observed the error a few weeks ago (maybe a month ago), so I don't think it's a change in Valgrind's version. > You should: > 1) File a bug report, and post here a link to the bug report. Yes, I tried to create a reproducer by defining huge arrays but did not observe the error. That's when I tried to check the original code again. > 2) Attach to the bug report the source code for a reproducible test case. > Please use C language. If Ada, then be EXPLICIT about your build tools and recipe. Yes, I tried to create the test case in C but could not originate the error. > IF YOU DO NOT DO THOSE TWO THINGS, THEN YOUR COMPLAINT LIKELY WILL BE FORGOTTEN AND/OR IGNORED. I thank you for you work and time. And I can assure you that I have put lots of effort in this issue already, and was not planning not to create a bug report. I always create issue reports when I find them in software, that's the least I can do. As I said, I was trying to create the report, but couldn't. I then thought I had come up with a different error, that's why I reported it here. I don't know if it's an error in Valgrind or our code, so I thought I could discuss it here before. It seems an error during Ada's elaboration. João M. S. Silva |