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
(1) |
4
|
|
5
(1) |
6
|
7
|
8
(1) |
9
|
10
(1) |
11
|
|
12
|
13
|
14
(1) |
15
(2) |
16
|
17
|
18
|
|
19
(3) |
20
(2) |
21
(7) |
22
(9) |
23
(2) |
24
|
25
|
|
26
|
27
|
28
(3) |
29
(2) |
30
(16) |
31
(3) |
|
|
From: Tom H. <th...@cy...> - 2003-10-21 23:10:05
|
In message <1066774658.4409.2.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> OK, there seems to be some slight timing difference between 2.4-RH and
> 2.6, or something. Anyway, I think this is the right fix - can you test
> it out?
I'm running on a dual processor box which may change things given
that there are at least three threads of control running here.
That patch certainly improves things - it fixes the case where there is
no handler installed for the signal. The modified test program that is
attached to this message, and which installs a SIGCHLD handler, exhibits
a different problem however.
Specifically the wait4 system call exists with ERESTARTSYS but is isn't
restarted and the waitpid library call returns 114 which is the number of
the wait4 system call, as shown here:
==9444== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==9444== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==9444== Using valgrind-20030725, a program supervision framework for x86-linux.
==9444== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
--9444-- sys_wait_results: got PX_SetSigmask for TID 1
--9444-- sys_wait_results: got PX_SetSigmask for TID 1
==9444== Estimated CPU clock rate is 2005 MHz
==9444== For more details, rerun with: -v
==9444==
SYSCALL[9444,1](174) special:sigaction ( 17, 0xBFFFD420, 0x0 )
SYSCALL[9444,1]( 2):fork ()
fork: process 9444 created child 9451
SYSCALL[9444,1]( 37):kill ( 9451, 9 )
SYSCALL[9444,1](114) blocking:wait4 ( 9451, 0xBFFFD504, 0, 0x0 )
--9444-- sys_wait_results: got PX_Signal for TID 1, signal 17
--9444-- sys_wait_results: got PX_RunSyscall for TID 1: syscall 114 result -512
--9444-- sys_wait_results: got PX_SetSigmask for TID 1
SYSCALL[9444,1](197):fstat64 ( 1, 0xBFFFCD20 )
SYSCALL[9444,1](192):mmap2 ( 0x0, 4096, 3, 34, -1, 0 )
==9444== Use of uninitialised value of size 4
==9444== at 0x4027C94F: _IO_vfprintf_internal (in /lib/i686/libc-2.3.2.so)
==9444== by 0x40285311: _IO_printf (in /lib/i686/libc-2.3.2.so)
==9444== by 0x8048668: main (in /home/thh/vgtest/sigkill)
==9444== by 0x40248A06: __libc_start_main (in /lib/i686/libc-2.3.2.so)
==9444==
==9444== Conditional jump or move depends on uninitialised value(s)
==9444== at 0x4027C957: _IO_vfprintf_internal (in /lib/i686/libc-2.3.2.so)
==9444== by 0x40285311: _IO_printf (in /lib/i686/libc-2.3.2.so)
==9444== by 0x8048668: main (in /home/thh/vgtest/sigkill)
==9444== by 0x40248A06: __libc_start_main (in /lib/i686/libc-2.3.2.so)
==9444==
==9444== Conditional jump or move depends on uninitialised value(s)
==9444== at 0x4027C020: _IO_vfprintf_internal (in /lib/i686/libc-2.3.2.so)
==9444== by 0x40285311: _IO_printf (in /lib/i686/libc-2.3.2.so)
==9444== by 0x8048668: main (in /home/thh/vgtest/sigkill)
==9444== by 0x40248A06: __libc_start_main (in /lib/i686/libc-2.3.2.so)
==9444==
==9444== Conditional jump or move depends on uninitialised value(s)
==9444== at 0x4027C07E: _IO_vfprintf_internal (in /lib/i686/libc-2.3.2.so)
==9444== by 0x40285311: _IO_printf (in /lib/i686/libc-2.3.2.so)
==9444== by 0x8048668: main (in /home/thh/vgtest/sigkill)
==9444== by 0x40248A06: __libc_start_main (in /lib/i686/libc-2.3.2.so)
==9444==
==9444== Conditional jump or move depends on uninitialised value(s)
==9444== at 0x4027C0AF: _IO_vfprintf_internal (in /lib/i686/libc-2.3.2.so)
==9444== by 0x40285311: _IO_printf (in /lib/i686/libc-2.3.2.so)
==9444== by 0x8048668: main (in /home/thh/vgtest/sigkill)
==9444== by 0x40248A06: __libc_start_main (in /lib/i686/libc-2.3.2.so)
==9444==
==9444== Conditional jump or move depends on uninitialised value(s)
==9444== at 0x4027C0E0: _IO_vfprintf_internal (in /lib/i686/libc-2.3.2.so)
==9444== by 0x40285311: _IO_printf (in /lib/i686/libc-2.3.2.so)
==9444== by 0x8048668: main (in /home/thh/vgtest/sigkill)
==9444== by 0x40248A06: __libc_start_main (in /lib/i686/libc-2.3.2.so)
==9444==
==9444== Conditional jump or move depends on uninitialised value(s)
==9444== at 0x4027C10C: _IO_vfprintf_internal (in /lib/i686/libc-2.3.2.so)
==9444== by 0x40285311: _IO_printf (in /lib/i686/libc-2.3.2.so)
==9444== by 0x8048668: main (in /home/thh/vgtest/sigkill)
==9444== by 0x40248A06: __libc_start_main (in /lib/i686/libc-2.3.2.so)
SYSCALL[9444,1]( 4) blocking:write ( 1, 0x40230000, 40 )
Child 114 exited with status 1073831928
--9444-- sys_wait_results: got PX_RunSyscall for TID 1: syscall 4 result 40
SYSCALL[9444,1]( 91):munmap ( 0x40230000, 4096 )
--9444-- Caught __NR_exit; running __libc_freeres()
SYSCALL[9444,1]( 91):munmap ( 0x0, 0 )
--9444-- __libc_freeres() done; really quitting!
==9444==
==9444== ERROR SUMMARY: 25 errors from 7 contexts (suppressed: 0 from 0)
==9444== malloc/free: in use at exit: 0 bytes in 0 blocks.
==9444== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==9444== For a detailed leak analysis, rerun with: --leak-check=yes
==9444== For counts of detected errors, rerun with: -v
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2003-10-21 23:07:00
|
In message <1066768769.4354.2.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Tue, 2003-10-21 at 04:04, Tom Hughes wrote:
> > Unfortunately this is now hanging because the pre-syscall action for
> > kill looks like this:
> >
> > PRE(kill)
> > {
> > /* int kill(pid_t pid, int sig); */
> > MAYBE_PRINTF("kill ( %d, %d )\n", arg1,arg2);
> > if (arg2 == VKI_SIGVGINT || arg2 == VKI_SIGVGKILL)
> > res = -VKI_EINVAL;
> > }
> >
> > Because this suppresses SIGKILL the waitpid then hangs...
>
> No, it suppresses SIG*VG*INT and SIG*VG*KILL, which is are magic
> internal signals I'm using (32 and 33).
Yes I realised that shortly after I sent that which is what led to
the later posts pinpointing waitpid as the problem.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-10-21 22:34:35
|
On Tue, 2003-10-21 at 04:30, Tom Hughes wrote:
> My real problem seems to be that the waitpid is sometimes returning a
> nonsense error of -512 at the system call level. I've written a little
> test program, which is attached, and when it is run under valgrind
> this is what I see:
OK, there seems to be some slight timing difference between 2.4-RH and
2.6, or something. Anyway, I think this is the right fix - can you test
it out?
Index: vg_syscalls.c
===================================================================
RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_syscalls.c,v
retrieving revision 1.50
diff -c -r1.50 vg_syscalls.c
*** vg_syscalls.c 19 Oct 2003 16:46:06 -0000 1.50
--- vg_syscalls.c 21 Oct 2003 22:12:12 -0000
***************
*** 4467,4472 ****
--- 4467,4482 ----
VGP_POPCC(VgpSkinSysWrap);
}
+ if (tst->m_eax == -VKI_ERESTARTSYS) {
+ /* Applications never expect to see this, so we should actually
+ restart the syscall (it means the signal happened before the
+ syscall made any progress, so we can safely restart it and
+ pretend the signal happened before the syscall even
+ started) */
+ tst->m_eax = tst->syscallno;
+ tst->m_eip -= 2; /* sizeof(int $0x80) */
+ }
+
tst->status = VgTs_Runnable; /* runnable again */
tst->syscallno = -1;
J
|
|
From: Tom H. <th...@cy...> - 2003-10-21 18:16:54
|
In message <106...@ix...>
Jeremy Fitzhardinge <je...@go...> wrote:
> This is a large, complex change. I've been testing it pretty
> extensively, but I expect there's still some bugs in there (I found one
> just before checking in). Please sync to CVS HEAD and try it out on
> your favorite programs.
I've another problem now - all attempts to send SIGINT or SIGKILL seem
to be suppressed for some reason. We have some code which does this:
kill( child, SIGKILL );
waitpid( child, &status, 0 );
Unfortunately this is now hanging because the pre-syscall action for
kill looks like this:
PRE(kill)
{
/* int kill(pid_t pid, int sig); */
MAYBE_PRINTF("kill ( %d, %d )\n", arg1,arg2);
if (arg2 == VKI_SIGVGINT || arg2 == VKI_SIGVGKILL)
res = -VKI_EINVAL;
}
Because this suppresses SIGKILL the waitpid then hangs...
Actually there is something even more bizarre than that happening
as we only actually do the waitpid if the kill succeeds, but we still
seem to be hanging in waitpid, as shown:
SYSCALL[14042,1]( 37):kill ( 14080, 9 )
SYSCALL[14042,1](114) blocking:wait4 ( 14080, 0xBFFF69F0, 0, 0x0 )
Anyway, the point is that it's highly antisocial to mysteriously
break kill for certain signals, and I can't see an obvious reason
for it.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2003-10-21 17:03:50
|
On Tue, 2003-10-21 at 04:57, Tom Hughes wrote: > In message <yek...@au...> > Tom Hughes <th...@cy...> wrote: > > > My real problem seems to be that the waitpid is sometimes returning a > > nonsense error of -512 at the system call level. I've written a little > > test program, which is attached, and when it is run under valgrind > > this is what I see: > > So the -512 is actually ERESTARTSYS but that shouldn't be making it > back to my program - either the system call should be restarted for me > or I should get EINTR back. > > Bizarrely if I install a signal handler for SIGCHLD then although > valgrind still shows ERESTARTSYS as the result of the wait4 system > call the waitpid library routine gives me a zero result, without it > having restarted the system call. > > Without the signal handler I get ERESTARTSYS back from the waitpid > library routine. Hm, yes, you shouldn't be seeing that. Can you send me your code (or ideally, carve out a minimal piece which shows the problem)? Which kernel are you using again? J |
|
From: Tom H. <th...@cy...> - 2003-10-21 15:31:41
|
In message <yek...@au...>
Tom Hughes <th...@cy...> wrote:
> My real problem seems to be that the waitpid is sometimes returning a
> nonsense error of -512 at the system call level. I've written a little
> test program, which is attached, and when it is run under valgrind
> this is what I see:
So the -512 is actually ERESTARTSYS but that shouldn't be making it
back to my program - either the system call should be restarted for me
or I should get EINTR back.
Bizarrely if I install a signal handler for SIGCHLD then although
valgrind still shows ERESTARTSYS as the result of the wait4 system
call the waitpid library routine gives me a zero result, without it
having restarted the system call.
Without the signal handler I get ERESTARTSYS back from the waitpid
library routine.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|