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
(9) |
2
(1) |
3
(1) |
|
4
(1) |
5
(1) |
6
(1) |
7
(1) |
8
(5) |
9
(9) |
10
(1) |
|
11
(1) |
12
(2) |
13
(10) |
14
(4) |
15
(1) |
16
|
17
(1) |
|
18
(1) |
19
(1) |
20
(8) |
21
(1) |
22
(2) |
23
|
24
|
|
25
|
26
(2) |
27
(15) |
28
(12) |
29
(9) |
30
(5) |
31
(5) |
|
From: Konstantin S. <kon...@gm...> - 2009-10-22 07:36:52
|
-valgrind-users+valgrind-developers I observe a situation where the number of invocations of PRE(sys_epoll_wait) is greater than the number of invocations of POST(sys_epoll_wait). Is that expected? This is causing memcheck to think that memory passed to epoll_wait() as a second parameter is left uninitialized... Thanks, --kcc On Tue, Oct 20, 2009 at 3:30 PM, Konstantin Serebryany < kon...@gm...> wrote: > Hi, > I am investigating a memcheck's report near a call to epoll_wait(). > I am running my program (sorry, not small test case) with > --trace-syscalls=yes. > > Usually I get this: > SYSCALL[29628,125](232) sys_epoll_wait ( 62, 0x1540ca30, 1024, 1000 ) --> > [async] ... > SYSCALL[29628,125](232) ... [async] --> Success(0x0:0x0) > I assume these two lines come from PRE(sys_epoll_wait) and > POST(sys_epoll_wait). > > But sometimes I get this: > SYSCALL[29628,156](232) sys_epoll_wait ( 96, 0x15948a30, 1024, 417 ) --> > [async] ... > SYSCALL[29628,156]( 15) sys_rt_sigreturn ( ) --> [pre-success] > NoWriteResult > > So, POST(sys_epoll_wait) does not get called and memcheck thinks that the > second parameter of epoll_wait is uninitialized. > > What does this sys_rt_sigreturn mean? Why POST(sys_epoll_wait) is not > called? > Any idea? > > Thanks, > > --kcc > > > > > |
|
From: Konstantin S. <kon...@gm...> - 2009-10-22 05:56:46
|
Hi,
Here is a small bug which leads to memcheck false positives on x86_64.
In short, sizeof(siginfo_t)==136, while it needs to be 128.
Would you mind fixing this (see patch below)?
Test:
$ cat sigqueue_test.c
#include <signal.h>
#include <syscall.h>
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
int main() {
siginfo_t *si;
const size_t sz = sizeof(*si);
printf("sizeof(*si) = %lu\n", sz);
printf("%ld %ld %ld %ld\n",
(char*)&si->si_signo - (char*)si,
(char*)&si->si_errno - (char*)si,
(char*)&si->si_code - (char*)si,
(char*)&si->_sifields - (char*)si
);
si = malloc(sz);
memset(si, 0, sz);
si->si_signo = SIGWINCH;
si->si_code = SI_QUEUE;
si->si_pid = getpid();
si->si_uid = getuid();
syscall(__NR_rt_sigqueueinfo, getpid(), SIGWINCH, si);
return 0;
}
$ gcc -g sigqueue_test.c && ./a.out && ~/valgrind/trunk/inst/bin/valgrind
./a.out
sizeof(*si) = 128
0 4 8 16
==13294== Memcheck, a memory error detector
==13294== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==13294== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright
info
==13294== Command: ./a.out
==13294==
sizeof(*si) = 128
0 4 8 16
==13294== Syscall param rt_sigqueueinfo(uinfo) points to unaddressable
byte(s)
==13294== at 0x4EE82E9: syscall (in /usr/grte/v1/lib64/libc-2.3.6.so)
==13294== by 0x400750: main (sigqueue_test.c:24)
==13294== Address 0x516a0c0 is 0 bytes after a block of size 128 alloc'd
==13294== at 0x4C1BE27: malloc (vg_replace_malloc.c:195)
==13294== by 0x4006DB: main (sigqueue_test.c:18)
==13294==
==13294==
==13294== HEAP SUMMARY:
==13294== in use at exit: 128 bytes in 1 blocks
==13294== total heap usage: 1 allocs, 0 frees, 128 bytes allocated
==13294==
==13294== LEAK SUMMARY:
==13294== definitely lost: 128 bytes in 1 blocks
==13294== indirectly lost: 0 bytes in 0 blocks
==13294== possibly lost: 0 bytes in 0 blocks
==13294== still reachable: 0 bytes in 0 blocks
==13294== suppressed: 0 bytes in 0 blocks
==13294== Rerun with --leak-check=full to see details of leaked memory
==13294==
==13294== For counts of detected and suppressed errors, rerun with: -v
==13294== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 5 from 5)
Fix (something like):
Index: include/vki/vki-linux.h
===================================================================
--- include/vki/vki-linux.h (revision 10904)
+++ include/vki/vki-linux.h (working copy)
@@ -340,16 +340,17 @@
void __user *sival_ptr;
} vki_sigval_t;
-#ifndef __VKI_ARCH_SI_PREAMBLE_SIZE
-#define __VKI_ARCH_SI_PREAMBLE_SIZE (3 * sizeof(int))
-#endif
-
#define VKI_SI_MAX_SIZE 128
#ifndef VKI_SI_PAD_SIZE
-#define VKI_SI_PAD_SIZE ((VKI_SI_MAX_SIZE -
__VKI_ARCH_SI_PREAMBLE_SIZE) / sizeof(int))
+# if defined (VGA_amd64) // or whatever is right for 64-bit arch.
+# define VKI_SI_PAD_SIZE ((VKI_SI_MAX_SIZE / sizeof (int)) - 4)
+# else
+# define VKI_SI_PAD_SIZE ((VKI_SI_MAX_SIZE / sizeof (int)) - 3)
+# endif
#endif
+
#ifndef __VKI_ARCH_SI_UID_T
#define __VKI_ARCH_SI_UID_T vki_uid_t
#endif
Thanks,
--kcc
|