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) |
4
(5) |
5
(5) |
6
(3) |
7
|
8
|
|
9
|
10
(8) |
11
(13) |
12
(12) |
13
(1) |
14
(1) |
15
(5) |
|
16
|
17
(12) |
18
(7) |
19
(5) |
20
|
21
(11) |
22
(8) |
|
23
(8) |
24
(6) |
25
|
26
(2) |
27
(3) |
28
(9) |
29
|
|
30
|
31
(5) |
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2011-01-06 11:18:32
|
> > (Actually .. to be more precise .. won't it fail if the size of > > text + data + bss exceeds about 800MB ?) > > > > Konstantin, what happens if you edit configure.in and change all the > > 0x38000000 to (eg) 0x58000000, to select a higher load address > > for V? > > This makes the warning look like this: > valgrind: mmap(0x58000000, 2375680) failed in UME with error 22 (Invalid > argument). Hmm, that's odd. But it depends on the text/bss/data sizes for your executable. Did you check that they will fit in (0x58000000 - 0x400000) bytes? J |
|
From: Konstantin S. <kon...@gm...> - 2011-01-06 09:05:40
|
On Tue, Jan 4, 2011 at 4:59 PM, Julian Seward <js...@ac...> wrote: > On Monday, January 03, 2011, Tom Hughes wrote: > > On 03/01/11 20:23, Konstantin Serebryany wrote: > > > We are seeing more and more of this error: > > > valgrind: mmap(0x38000000, 2375680) failed in UME with error 22 > (Invalid > > > argument). > > > valgrind: this can be caused by executables with very large text, data > > > or bss segments. > > > > > > (known as > > > http://bugs.kde.org/show_bug.cgi?id=138424, > > > http://bugs.kde.org/show_bug.cgi?id=184981, > > > http://code.google.com/p/chromium/issues/detail?id=28439). > > > > > > Any chance to fix it? Do you have a reliable reproducer? (If no, we > > > could send a pre-built binary for Ubuntu 10.04)... > > > > What makes you think it can be fixed? It's a basic limitation of > > valgrind that it needs to reserve some memory for itself and hence there > > will be less available for the client program than when it is not > > running valgrind. > > > > That is, I believe, the basic cause of this error, that after valgrind > > has reserved memory for itself there is not enough room to load the > > executable. > > It could also really be caused by executables with very large > text etc segments. Since the text segment will get mapped to > 0x8048000 (roughly 134MB), if its size exceeds about 800MB then > the top part will overlap valgrind's load point of 0x38000000 > (939MB) and so the UME will fail. > > (Actually .. to be more precise .. won't it fail if the size of > text + data + bss exceeds about 800MB ?) > > Konstantin, what happens if you edit configure.in and change all the > 0x38000000 to (eg) 0x58000000, to select a higher load address > for V? > This makes the warning look like this: valgrind: mmap(0x58000000, 2375680) failed in UME with error 22 (Invalid argument). :( --kcc > > J > |
|
From: Jeffrey Y. <jya...@gm...> - 2011-01-06 00:38:04
|
I was removing warnings from valgrind.h with the svn version of gcc-4.6 (https://bugs.kde.org/show_bug.cgi?id=262260), and while testing my change I ran into a couple other warnings that you might want to know about. They're not in my way, so I don't plan to fix them myself, but if you want me to validate a patch against my gcc build (since gcc takes a while to build yourself) I can do that. The line numbers are all at r11492. $ make check -k CFLAGS="-Werror" CXXFLAGS="-Werror" /home/jyasskin/opensource/gcc/trunk/install/bin/gcc-4.6svn -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -Ipriv -m64 -fo mit-frame-pointer -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prot otypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -Wbad-function- cast -Wcast-qual -Wcast-align -fstrict-aliasing -Wno-pointer-sign -Werror -MT libvex_amd64 _linux_a-guest_arm_toIR.o -MD -MP -MF .deps/libvex_amd64_linux_a-guest_arm_toIR.Tpo -c -o libvex_amd64_linux_a-guest_arm_toIR.o `test -f 'priv/guest_arm_toIR.c' || echo './'`priv/g uest_arm_toIR.c priv/guest_arm_toIR.c: In function ‘disInstr_ARM’: priv/guest_arm_toIR.c:17787:14: error: ‘insn1’ may be used uninitialized in this function [-Werror=uninitialized] priv/guest_arm_toIR.c:15761:11: note: ‘insn1’ was declared here priv/guest_arm_toIR.c:17793:15: error: ‘old_itstate’ may be used uninitialized in this fun ction [-Werror=uninitialized] priv/guest_arm_toIR.c:14276:11: note: ‘old_itstate’ was declared here cc1: all warnings being treated as errors /home/jyasskin/opensource/gcc/trunk/install/bin/gcc-4.6svn -DHAVE_CONFIG_H -I. -I../../.. -I../../.. -I../../../include -I../../../coregrind -I../../../include -I../../../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -Winline -Wall -Wshadow -g -m32 -mmmx -msse -Wno-pointer-sign -Werror -MT fxtract.o -MD -MP -MF .deps/fxtract.Tpo -c -o fxtract.o fxtract.c fxtract.c: In function ‘main’: fxtract.c:60:3: error: floating constant truncated to zero [-Werror=overflow] fxtract.c:61:3: error: floating constant truncated to zero [-Werror=overflow] fxtract.c:94:3: error: floating constant truncated to zero [-Werror=overflow] fxtract.c:95:3: error: floating constant truncated to zero [-Werror=overflow] cc1: all warnings being treated as errors There are also a huge number of -Wpointer-sign warnings. I've copied a small sample, but I can send the whole list if you're interested: m_transtab.c:1559:4: error: pointer targets in passing argument 5 of ‘vgPlain_assert_fail’ differ in signedness [-Werror=pointer-sign] ../include/pub_tool_libcassert.h:58:1: note: expected ‘const Char *’ but argument is of type ‘const char *’ m_debuginfo/readdwarf3.c:508:4: error: pointer targets in passing argument 5 of ‘vgPlain_assert_fail’ differ in signedness [-Werror=pointer-sign] ../include/pub_tool_libcassert.h:58:1: note: expected ‘const Char *’ but argument is of type ‘const char *’ m_initimg/initimg-pathscan.c:144:7: error: pointer targets in passing argument 1 of ‘vgPlain_getenv’ differ in signedness [-Werror=pointer-sign] ../include/pub_tool_libcproc.h:42:1: note: expected ‘Char *’ but argument is of type ‘char *’ mc_leakcheck.c:939:4: error: pointer targets in passing argument 1 of ‘find_active_chunks’ differ in signedness [-Werror=pointer-sign] mc_leakcheck.c:330:1: note: expected ‘UInt *’ but argument is of type ‘Int *’ mc_main.c:1357:20: error: pointer targets in initialization differ in signedness [-Werror=pointer-sign] mc_main.c:1358:49: error: pointer targets in assignment differ in signedness [-Werror=pointer-sign] mc_replace_strmem.c:847:1: error: pointer targets in return differ in signedness [-Werror=pointer-sign] -- Jeffrey |