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
(32) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
(4) |
|
2
(5) |
3
(3) |
4
(3) |
5
(7) |
6
(7) |
7
(9) |
8
(10) |
|
9
(12) |
10
(26) |
11
(9) |
12
(6) |
13
(7) |
14
(15) |
15
(25) |
|
16
(20) |
17
(32) |
18
(11) |
19
(19) |
20
(22) |
21
(6) |
22
(8) |
|
23
(16) |
24
(25) |
25
(11) |
26
(16) |
27
(12) |
28
(15) |
29
(11) |
|
30
(5) |
31
(8) |
|
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2005-01-24 00:52:46
|
On Mon, 2005-01-24 at 11:48 +1100, Eyal Lebedinsky wrote: > Should I assume that zz36 does not reproduce the problem for you? No, I can reproduce it. Could you file a bug with zz36 attached just to make sure the issue gets tracked? J |
|
From: Eyal L. <ey...@ey...> - 2005-01-24 00:48:40
|
Jeremy Fitzhardinge wrote:
> On Sun, 2005-01-23 at 23:34 +1100, Eyal Lebedinsky wrote:
>
>>Please do not ignore the original report, the problem is still
>>there.
>>
>>Attached is a program that shows how the backtrace is displayed
>>when in main but is missing from a thread.
>
>
> Valgrind has to guess where the thread's stack is, because it isn't
> explicitly told. It assumes that the limits of the stack is between the
> initial stack pointer and the base of that memory mapping; this may not
> be a good assumption.
>
> In coregrind/x86-linux/syscalls.c:do_clone(), could you set "debug" to
> True and tell me what the guessed stack range is for the thread which is
> reporting bad stack backtraces? Also, the contents of /proc/<pid>/maps
> for that process.
>
> J
Should I assume that zz36 does not reproduce the problem for you?
Also, at what point do you want the /proc entry? I will need to
insert some code into VG to dump it. Here is what I inserted at
the top of do_clone():
vki_sigset_t blockall, savedmask;
{
char cmd[256];
VG_(sprintf) (cmd, "cat /proc/%d/maps", (Int)VG_(getpid ()));
VG_(system) (cmd);
}
I hope that getpid() gets the required value.
It took me a while to discover that '%ld' in VG means 'Long' which is
type 'long long' and I need to use '%d' and 'Int' which are 'long'...
==22241== Memcheck, a memory error detector for x86-linux.
==22241== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==22241== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux.
==22241== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==22241== For more details, rerun with: -v
==22241==
/home/eyal/zz/zz36.c(75) testing in main
==22241== Conditional jump or move depends on uninitialised value(s)
==22241== at 0x1B905D32: memcmp (mac_replace_strmem.c:325)
==22241== by 0x8048636: func (zz36.c:23)
==22241== by 0x8048831: main (zz36.c:77)
/home/eyal/zz/zz36.c(80) testing in thread
/home/eyal/zz/zz36.c(38) will pthread_attr_init
/home/eyal/zz/zz36.c(41) pthread_attr_init=0
08048000-08049000 r-xp 00000000 03:06 344360 /home/eyal/zz/zz36
08049000-0804a000 rw-p 00000000 03:06 344360 /home/eyal/zz/zz36
1b8e4000-1b8fa000 r-xp 00000000 03:06 167200 /lib/ld-2.3.2.so
1b8fa000-1b8fb000 rw-p 00015000 03:06 167200 /lib/ld-2.3.2.so
1b8fc000-1b8fd000 rw-p 1b8fc000 00:00 0
1b8fe000-1b8ff000 r-xp 00000000 03:07 5767177 /data2/usr/local/lib/valgrind/vg_inject.so
1b8ff000-1b900000 rw-p 00000000 03:07 5767177 /data2/usr/local/lib/valgrind/vg_inject.so
1b901000-1b907000 r-xp 00000000 03:07 5767318 /data2/usr/local/lib/valgrind/vgpreload_memcheck.so
1b907000-1b908000 rw-p 00005000 03:07 5767318 /data2/usr/local/lib/valgrind/vgpreload_memcheck.so
1b909000-1b90a000 rw-p 1b909000 00:00 0
1b91d000-1b91e000 rw-p 1b91d000 00:00 0
1b91f000-1b92b000 r-xp 00000000 03:06 395375 /lib/tls/libpthread-0.60.so
1b92b000-1b92c000 rw-p 0000c000 03:06 395375 /lib/tls/libpthread-0.60.so
1b92c000-1b92e000 rw-p 1b92c000 00:00 0
1b92f000-1ba58000 r-xp 00000000 03:06 395242 /lib/tls/libc-2.3.2.so
1ba58000-1ba60000 rw-p 00129000 03:06 395242 /lib/tls/libc-2.3.2.so
1ba60000-1ba63000 rw-p 1ba60000 00:00 0
1ba64000-1ba65000 rw-p 1ba64000 00:00 0
1ba66000-1bb66000 rwxp 1ba66000 00:00 0
1bb67000-1bb68000 ---p 1bb67000 00:00 0
1bb68000-1c367000 rwxp 1bb68000 00:00 0
52bfb000-52bff000 rwxp 52bfb000 00:00 0
52bff000-52c00000 r-xp 52bff000 00:00 0
52c00000-52d00000 ---p 52c00000 00:00 0
52d00000-537f8000 rw-p 52d00000 00:00 0
537f8000-b0000000 ---p 537f8000 00:00 0
b0000000-b00af000 r-xp 00000000 03:07 5767176 /data2/usr/local/lib/valgrind/stage2
b00af000-b00b1000 rw-p 000ae000 03:07 5767176 /data2/usr/local/lib/valgrind/stage2
b00b1000-b0205000 rw-p b00b1000 00:00 0
b0206000-b0306000 rwxp b0206000 00:00 0
b0307000-b0407000 rwxp b0307000 00:00 0
b0408000-b0409000 ---p b0408000 00:00 0
b0409000-b0419000 rw-p b0409000 00:00 0
b041a000-b0422000 rwxp b041a000 00:00 0
b0423000-b0433000 rwxp b0423000 00:00 0
b0434000-b0444000 rwxp b0434000 00:00 0
b063b000-b073b000 rwxp b063b000 00:00 0
b073c000-b0986000 rwxp b073c000 00:00 0
b1000000-b1016000 r-xp 00000000 03:06 167200 /lib/ld-2.3.2.so
b1016000-b1017000 rw-p 00015000 03:06 167200 /lib/ld-2.3.2.so
b1018000-b1705000 rwxp b1018000 00:00 0
b7c88000-b7ca1000 r-xp 00000000 03:07 5767317 /data2/usr/local/lib/valgrind/vgskin_memcheck.so
b7ca1000-b7ca2000 rw-p 00018000 03:07 5767317 /data2/usr/local/lib/valgrind/vgskin_memcheck.so
b7ca2000-b7eb5000 rw-p b7ca2000 00:00 0
b7eb5000-b7fde000 r-xp 00000000 03:06 395242 /lib/tls/libc-2.3.2.so
b7fde000-b7fe6000 rw-p 00129000 03:06 395242 /lib/tls/libc-2.3.2.so
b7fe6000-b7fe9000 rw-p b7fe6000 00:00 0
b7fe9000-b7feb000 r-xp 00000000 03:06 395245 /lib/tls/libdl-2.3.2.so
b7feb000-b7fec000 rw-p 00002000 03:06 395245 /lib/tls/libdl-2.3.2.so
b7fff000-b8000000 rw-p b7fff000 00:00 0
bffeb000-c0000000 rw-p bffeb000 00:00 0
ffffe000-fffff000 ---p 00000000 00:00 0
guessed client stack range 0x1BB68000-0x1C367000
clone child has SETTLS: tls info at 0x52BFEB40: idx=6 base=0x1C366BB0 limit=FFFFF; esp=0x52BFEB00 fs=0 gs=33
==22241==
==22241== Thread 2:
==22241== Conditional jump or move depends on uninitialised value(s)
==22241== at 0x1B905D32: memcmp (mac_replace_strmem.c:325)
/home/eyal/zz/zz36.c(60) joined
/home/eyal/zz/zz36.c(65) pthread_attr_destroy=0
/home/eyal/zz/zz36.c(85) test done
0
0
==22241==
==22241== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 13 from 1)
==22241== malloc/free: in use at exit: 68 bytes in 1 blocks.
==22241== malloc/free: 3 allocs, 2 frees, 70 bytes allocated.
==22241== For counts of detected errors, rerun with: -v
==22241== searching for pointers to 1 not-freed blocks.
==22241== checked 9860356 bytes.
==22241==
==22241==
==22241== 68 bytes in 1 blocks are possibly lost in loss record 1 of 1
==22241== at 0x1B904FE5: calloc (vg_replace_malloc.c:175)
==22241== by 0x1B8F25A8: (within /lib/ld-2.3.2.so)
==22241== by 0x1B8F287B: _dl_allocate_tls (in /lib/ld-2.3.2.so)
==22241== by 0x1B92424A: allocate_stack (in /lib/tls/libpthread-0.60.so)
==22241== by 0x1B923C54: pthread_create@@GLIBC_2.1 (in /lib/tls/libpthread-0.60.so)
==22241== by 0x80486DF: test (zz36.c:43)
==22241== by 0x8048868: main (zz36.c:82)
==22241==
==22241== LEAK SUMMARY:
==22241== definitely lost: 0 bytes in 0 blocks.
==22241== possibly lost: 68 bytes in 1 blocks.
==22241== still reachable: 0 bytes in 0 blocks.
==22241== suppressed: 0 bytes in 0 blocks.
==22241== Reachable blocks (those to which a pointer was found) are not shown.
==22241== To see them, rerun with: --show-reachable=yes
--
Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/>
attach .zip as .dat
|
|
From: Jeremy F. <je...@go...> - 2005-01-23 23:24:45
|
On Sun, 2005-01-23 at 23:34 +1100, Eyal Lebedinsky wrote: > Please do not ignore the original report, the problem is still > there. > > Attached is a program that shows how the backtrace is displayed > when in main but is missing from a thread. Valgrind has to guess where the thread's stack is, because it isn't explicitly told. It assumes that the limits of the stack is between the initial stack pointer and the base of that memory mapping; this may not be a good assumption. In coregrind/x86-linux/syscalls.c:do_clone(), could you set "debug" to True and tell me what the guessed stack range is for the thread which is reporting bad stack backtraces? Also, the contents of /proc/<pid>/maps for that process. J |
|
From: Tom H. <th...@cy...> - 2005-01-23 17:10:05
|
CVS commit by thughes:
Link in libarch.a and use VG_(cpuid) for x86 CPU feature tests rather
than trying to use our own inline version which has a habit of failing
to compile on some versions of gcc due to register starvation.
BUG: 96321
M +2 -1 Makefile.am 1.38
M +9 -8 cputest.c 1.7
--- valgrind/tests/Makefile.am #1.37:1.38
@@ -23,5 +23,6 @@
cputest_SOURCES = cputest.c
cputest_CFLAGS = $(AM_CFLAGS) -D__$(VG_ARCH)__
+cputest_DEPENDENCIES = ../coregrind/${VG_ARCH}/libarch.a
+cputest_LDADD = ../coregrind/${VG_ARCH}/libarch.a
toobig_allocs_SOURCES = toobig-allocs.c
true_SOURCES = true.c
-
--- valgrind/tests/cputest.c #1.6:1.7
@@ -23,13 +23,14 @@ char* all_archs[] = {
#ifdef __x86__
-static __inline__ void cpuid(unsigned int n,
+extern void vgPlain_cpuid(unsigned int n,
+ unsigned int *a, unsigned int *b,
+ unsigned int *c, unsigned int *d);
+
+static inline void cpuid(unsigned int n,
unsigned int *a, unsigned int *b,
unsigned int *c, unsigned int *d)
{
- __asm__ __volatile__ (
- "cpuid"
- : "=a" (*a), "=b" (*b), "=c" (*c), "=d" (*d) /* output */
- : "0" (n) /* input */
- );
+ vgPlain_cpuid(n, a, b, c, d);
+ return;
}
|
|
From: Tom H. <th...@cy...> - 2005-01-23 16:51:13
|
CVS commit by thughes:
Don't die if we find a type of size zero. It isn't clear how to create
such a type but it has apparently been seend to happen.
MERGE TO STABLE
M +1 -1 vg_symtypes.c 1.7.2.1
--- valgrind/coregrind/vg_symtypes.c #1.7:1.7.2.1
@@ -873,5 +873,5 @@ Char *VG_(describe_addr)(ThreadId tid, A
VG_(printf)(" non-followable array (sz=%d): checking addr %p in range %p-%p\n",
sz, addr, var->valuep, (var->valuep + sz));
- if (addr >= var->valuep && addr <= (var->valuep + sz))
+ if (ty->size > 0 && addr >= var->valuep && addr <= (var->valuep + sz))
min = max = (addr - var->valuep) / ty->size;
else
|
|
From: Tom H. <th...@cy...> - 2005-01-23 16:50:20
|
CVS commit by thughes:
Don't die if we find a type of size zero. It isn't clear how to create
such a type but it has apparently been seend to happen.
BUG: 96923
M +1 -1 vg_symtypes.c 1.13
--- valgrind/coregrind/vg_symtypes.c #1.12:1.13
@@ -873,5 +873,5 @@ Char *VG_(describe_addr)(ThreadId tid, A
VG_(printf)(" non-followable array (sz=%d): checking addr %p in range %p-%p\n",
sz, addr, var->valuep, (var->valuep + sz));
- if (addr >= var->valuep && addr <= (var->valuep + sz))
+ if (ty->size > 0 && addr >= var->valuep && addr <= (var->valuep + sz))
min = max = (addr - var->valuep) / ty->size;
else
|
|
From: Eyal L. <ey...@ey...> - 2005-01-23 12:34:30
|
Please do not ignore the original report, the problem is still there. Attached is a program that shows how the backtrace is displayed when in main but is missing from a thread. ==19059== Memcheck, a memory error detector for x86-linux. ==19059== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==19059== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. ==19059== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==19059== For more details, rerun with: -v ==19059== /home/eyal/zz/zz36.c(75) testing in main ==19059== Conditional jump or move depends on uninitialised value(s) ==19059== at 0x1B905D32: memcmp (mac_replace_strmem.c:325) <<<<< good stack ***** ==19059== by 0x8048636: func (zz36.c:23) ==19059== by 0x8048831: main (zz36.c:77) 0 /home/eyal/zz/zz36.c(80) testing in thread /home/eyal/zz/zz36.c(38) will pthread_attr_init /home/eyal/zz/zz36.c(41) pthread_attr_init=0 ==19059== ==19059== Thread 2: ==19059== Conditional jump or move depends on uninitialised value(s) ==19059== at 0x1B905D32: memcmp (mac_replace_strmem.c:325) <<<<<< missing stack ***** 0 /home/eyal/zz/zz36.c(60) joined /home/eyal/zz/zz36.c(65) pthread_attr_destroy=0 /home/eyal/zz/zz36.c(85) test done ==19059== ==19059== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 13 from 1) ==19059== malloc/free: in use at exit: 68 bytes in 1 blocks. ==19059== malloc/free: 3 allocs, 2 frees, 70 bytes allocated. ==19059== For counts of detected errors, rerun with: -v ==19059== searching for pointers to 1 not-freed blocks. ==19059== checked 9860212 bytes. ==19059== ==19059== ==19059== 68 bytes in 1 blocks are possibly lost in loss record 1 of 1 ==19059== at 0x1B904FE5: calloc (vg_replace_malloc.c:175) ==19059== by 0x1B8F25A8: (within /lib/ld-2.3.2.so) ==19059== by 0x1B8F287B: _dl_allocate_tls (in /lib/ld-2.3.2.so) ==19059== by 0x1B92424A: allocate_stack (in /lib/tls/libpthread-0.60.so) ==19059== by 0x1B923C54: pthread_create@@GLIBC_2.1 (in /lib/tls/libpthread-0.60.so) ==19059== by 0x80486DF: test (zz36.c:43) ==19059== by 0x8048868: main (zz36.c:82) ==19059== ==19059== LEAK SUMMARY: ==19059== definitely lost: 0 bytes in 0 blocks. ==19059== possibly lost: 68 bytes in 1 blocks. ==19059== still reachable: 0 bytes in 0 blocks. ==19059== suppressed: 0 bytes in 0 blocks. ==19059== Reachable blocks (those to which a pointer was found) are not shown. ==19059== To see them, rerun with: --show-reachable=yes -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Eyal L. <ey...@ey...> - 2005-01-23 06:10:44
|
Jeremy Fitzhardinge wrote: [trimmed] > What does your test suite do? How much can you simplify it and > get the same result? > > J I have tried it before and failed. If you still want me to try (after you finish your investigation) then i will give it another go. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Eyal L. <ey...@ey...> - 2005-01-23 06:09:02
|
Jeremy Fitzhardinge wrote: > On Sun, 2005-01-23 at 11:53 +1100, Eyal Lebedinsky wrote: > >>Was this reported to linux-kernel? Who is handling it there? I am >>ready to do testing/investigation as I can reproduce it consistently. >> >>I cannot report it myself as I do not know enough about the nature >>of the problem (or what faultstatus does). However, if this test >>program is a simple one that should always work but sometimes does >>not (and can be built stand-alone) then it may be enough for a >>report. > > > Hm, I've worked out what it is, and it probably is a Valgrind bug. > There's a system-wide limit to the number of queued signals; if that > limit gets hit, then signals are delivered without extra info. I can > reproduce it easily if I change faultstatus to send itself a lot of > blocked signals before doing the main part of the test. > > Does your test do a lot of thread exits? Probably. My testsuit is running clients against servers and each client session gets a thread, and a typical test will have no more than 10 threads at a time active on the server. I have seen the failure after 11 tests or it managed up to 25. > J > -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: <js...@ac...> - 2005-01-23 03:56:40
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-01-23 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 193 tests, 15 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-01-23 03:25:26
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-01-23 03:20:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 200 tests, 12 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-23 03:22:48
|
Nightly build on audi ( Red Hat 9 ) started at 2005-01-23 03:15:13 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) none/tests/tls (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-23 03:16:27
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-01-23 03:10:17 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 198 tests, 12 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-23 03:10:47
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-01-23 03:05:12 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 198 tests, 14 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/post-syscall (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-23 03:06:08
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-01-23 03:00:14 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 198 tests, 13 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2005-01-23 02:32:07
|
On Sun, 2005-01-23 at 11:53 +1100, Eyal Lebedinsky wrote: > Was this reported to linux-kernel? Who is handling it there? I am > ready to do testing/investigation as I can reproduce it consistently. > > I cannot report it myself as I do not know enough about the nature > of the problem (or what faultstatus does). However, if this test > program is a simple one that should always work but sometimes does > not (and can be built stand-alone) then it may be enough for a > report. Hm, I've worked out what it is, and it probably is a Valgrind bug. There's a system-wide limit to the number of queued signals; if that limit gets hit, then signals are delivered without extra info. I can reproduce it easily if I change faultstatus to send itself a lot of blocked signals before doing the main part of the test. Does your test do a lot of thread exits? J |
|
From: Jeremy F. <je...@go...> - 2005-01-23 01:54:33
|
On Sun, 2005-01-23 at 11:53 +1100, Eyal Lebedinsky wrote: > However, running as non-root it does fail 'in that state': > > eyal@e7:~$ /data2/valgrind/valgrind/none/tests/faultstatus > Test 0: FAIL: expected si_code==1, not 0 > Test 1: FAIL: expected si_code==2, not 0 > Test 2: FAIL: expected si_code==2, not 0 > Test 3: FAIL: expected si_code==2, not 0 > Test 4: FAIL: expected si_code==1, not 0 > > My application runs non-root. > > 'killall' makes it work instantly. > > This is on vanilla 2.6.11-rc2. OK, definitely a kernel problem. faultstatus shouldn't depend on UID at all. > Was this reported to linux-kernel? Who is handling it there? I am > ready to do testing/investigation as I can reproduce it consistently. I haven't seen it reported against a stock kernel, so I haven't reported it to linux-kernel. > I cannot report it myself as I do not know enough about the nature > of the problem (or what faultstatus does). However, if this test > program is a simple one that should always work but sometimes does > not (and can be built stand-alone) then it may be enough for a > report. Yes. What does your test suite do? How much can you simplify it and get the same result? J |
|
From: Eyal L. <ey...@ey...> - 2005-01-23 00:53:39
|
Jeremy Fitzhardinge wrote: > When it is in this state, before you killall -9 valgrind, please run > none/tests/faultstatus (natively, not under Valgrind). If this fails, > it is definitely a kernel bug. > > J Done this, and faultstatus is not failing 'in that state': root@e7:/data2/valgrind/valgrind/none/tests# ./faultstatus Test 0: PASS 1 Test 1: PASS 2 Test 2: PASS 3 Test 3: PASS 4 Test 4: PASS 5 However, running as non-root it does fail 'in that state': eyal@e7:~$ /data2/valgrind/valgrind/none/tests/faultstatus Test 0: FAIL: expected si_code==1, not 0 Test 1: FAIL: expected si_code==2, not 0 Test 2: FAIL: expected si_code==2, not 0 Test 3: FAIL: expected si_code==2, not 0 Test 4: FAIL: expected si_code==1, not 0 My application runs non-root. 'killall' makes it work instantly. This is on vanilla 2.6.11-rc2. Was this reported to linux-kernel? Who is handling it there? I am ready to do testing/investigation as I can reproduce it consistently. I cannot report it myself as I do not know enough about the nature of the problem (or what faultstatus does). However, if this test program is a simple one that should always work but sometimes does not (and can be built stand-alone) then it may be enough for a report. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> attach .zip as .dat |
|
From: Chris J. <ch...@at...> - 2005-01-22 17:51:07
|
coregrind/vg_transtab.c includes memcheck/memcheck.c which doesn't exist if you configure outside the build tree. Adding -I$(top_srcdir) to AM_CPPFLAGS in coregrind/Makefile.am solves the problem. Chris -- http://www.atomice.com |
|
From: Jeremy F. <je...@go...> - 2005-01-22 17:17:18
|
On Thu, 2005-01-20 at 19:21 +1100, Eyal Lebedinsky wrote: > - run my tests. It should do 11-12 of them before failing > - wait for my tests to hang > - run my zz35 which fails sig 11 (zz35-sig11.log). It fails > consistently for as long as I want. > - 'killall -9 valgrind' to release my failed tests/servers > - without any waiting run my zz35 which works OK again (zz35-ok.log) > > So, stopping the running valgrind instances allowed zz35 to run > OK. There does not seem to be a period where the kernel is in > 'a mood', but rather one needs to ensure all valgrind instances > are stopped. When it is in this state, before you killall -9 valgrind, please run none/tests/faultstatus (natively, not under Valgrind). If this fails, it is definitely a kernel bug. J |
|
From: Jeremy F. <je...@go...> - 2005-01-22 17:17:18
|
On Fri, 2005-01-21 at 02:00 +0100, Josef Weidendorfer wrote: > On Wednesday 19 January 2005 22:29, Jeremy Fitzhardinge wrote: > > [...] > > OK, so that's normal call-return: how to deal with longjmp/exceptions? > > Well, we could just ignore it. If you call a wrapped function, and it > > longjmps back, it means that the "before" function is called but not the > > "after", and the cookie store fills up with junk. That's not optimal. > > With longjmp/exceptions, 2 cookies could be created with the same > TID+ESP+RETADDR (same call chain after a exception). Is this a problem? Well, after the longjmp, the first instance has been invalidated after ESP changes, so should "disappear". If there is a second occurance, the first should just be replaced. > > 3. Generate the call to wrap_after_func, just by overwriting the > > standard preamble. > > What happens if the TC is flushed before the function returns? A retranslation > would have to know about changing the preamble. That would be the common case - the first time a BB after a call is generally run is when that call returns. So there would need to be a structure to let the codegen know to generate the call to wrap_after_func in this case. > The calling convention is platform specific. Would it be detectable via > configure tests? Well, yes, it is platform-specific, like all the other CPU-specific stuff. So I don't think this is a special case. > General function wrapping is expensive. In my tool, I manage my own call stack > for this, and insert a callback at start of every BB which syncs/unwinds the > call stack according to %ESP. This doesn't need any temporary modification of > instrumented code, and works for longjump/execptions in a natural way. Wrapping every function is going to be expensive, yes. My design goal was for a mechanism which is efficient when applied to a relatively small number of functions. J |
|
From: Tom H. <to...@co...> - 2005-01-22 03:24:44
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-01-22 03:20:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 200 tests, 12 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-22 03:22:00
|
Nightly build on audi ( Red Hat 9 ) started at 2005-01-22 03:15:13 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) none/tests/tls (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-22 03:15:04
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-01-22 03:10:08 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 198 tests, 12 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-22 03:10:14
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-01-22 03:05:12 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 198 tests, 14 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/post-syscall (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |