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
(8) |
2
(11) |
3
(21) |
4
(15) |
5
(10) |
|
6
(7) |
7
(7) |
8
(5) |
9
(7) |
10
(5) |
11
(1) |
12
(21) |
|
13
(8) |
14
(17) |
15
(6) |
16
(10) |
17
(7) |
18
(6) |
19
(15) |
|
20
(12) |
21
(16) |
22
(25) |
23
(14) |
24
(10) |
25
(7) |
26
(6) |
|
27
(34) |
28
(13) |
29
(10) |
30
(8) |
|
|
|
|
From: Jeremy F. <je...@go...> - 2004-06-01 21:09:39
|
On Tue, 2004-06-01 at 09:46 +0100, Tom Hughes wrote: > The code to setup the signal frame in arch/i386/kernel/signal.c is > doing this: > > restorer = current->mm->context.vdso + (long)&__kernel_sigreturn; > > Now if vdso is set to zero then current->mm->context.vdso will be null > as no vdso will have been allocated. Hence restorer will be in zero > page which seems rather nasty. I'm a bit surprised anything at all > works with vdso's turned off in fact. Oh, I see how it works. It actually uses the sa_restorer in sigaction, to point to an alternative function __restore_rt: 0x550113f0 <__restore_rt+0>: mov $__NR_rt_sigreturn,%eax 0x550113f5 <__restore_rt+5>: int $0x80 0x550113f7 <__restore_rt+7>: nop This should be pretty easy to duplicate. J |
|
From: Jeremy F. <je...@go...> - 2004-06-01 20:38:59
|
On Tue, 2004-06-01 at 09:46 +0100, Tom Hughes wrote: > In message <1086068817.2794.7.camel@localhost.localdomain> > Jeremy Fitzhardinge <je...@go...> wrote: > > > The initial problem is caused by VDSOs, which are placed low in the > > address space. When Valgrind clears out the client area in stage2, it > > also clears out the sysinfo page, which happens to be where the munmap > > syscall returns to... > > I believe they are actually placed at a random address, or so the > kernel source claims. It's random within the range 0x00111000-0x01000000, I think. > The code to setup the signal frame in arch/i386/kernel/signal.c is > doing this: > > restorer = current->mm->context.vdso + (long)&__kernel_sigreturn; > > Now if vdso is set to zero then current->mm->context.vdso will be null > as no vdso will have been allocated. Hence restorer will be in zero > page which seems rather nasty. I'm a bit surprised anything at all > works with vdso's turned off in fact. Yes that's pretty much exactly what I was expecting to see. I guess people don't run with vdsos off. I'm trying to get a little standalone program to fail in the same way, but it seems to work for reasons I don't understand yet. J |
|
From: Tom H. <th...@cy...> - 2004-06-01 08:46:41
|
In message <1086068817.2794.7.camel@localhost.localdomain>
Jeremy Fitzhardinge <je...@go...> wrote:
> The initial problem is caused by VDSOs, which are placed low in the
> address space. When Valgrind clears out the client area in stage2, it
> also clears out the sysinfo page, which happens to be where the munmap
> syscall returns to...
I believe they are actually placed at a random address, or so the
kernel source claims.
> So, if you turn off VDSOs (echo 0 > /proc/sys/kernel/vdso), you get to
> the next crash. This is a fair bit further on, typicially when the
> client wants to expand the stack. It gets a fault, calls our SIGSEGV
> handler, which expands the stack, and then returns from the handler with
> the intent of restarting the faulting instruction - BANG. The handler
> returns to address 0x440 and explodes. I haven't confirmed this yet,
> but it looks to me like a FC2 kernel bug. I'm guessing that when it
> sets up the signal frame return address, it uses the sysinfo syscall
> return address, which is sysinfo_page + 0x440 - and since the sysinfo
> page hasn't been installed, it's just 0x440.
The code to setup the signal frame in arch/i386/kernel/signal.c is
doing this:
restorer = current->mm->context.vdso + (long)&__kernel_sigreturn;
Now if vdso is set to zero then current->mm->context.vdso will be null
as no vdso will have been allocated. Hence restorer will be in zero
page which seems rather nasty. I'm a bit surprised anything at all
works with vdso's turned off in fact.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-06-01 08:43:33
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Mon, 31 May 2004, Jeremy Fitzhardinge wrote:
>
>> The initial problem is caused by VDSOs, which are placed low in the
>> address space.
>
> What are VDSOs?
From looking at the kernel source I think it's just another name
for the sysinfo page - the map_vsyscall routine basically does nothing
if the vdso flag is turned off.
>> Either way, this is pretty tricky to deal with. We basically have to
>> leave the sysinfo page alone, even though it's sitting in the middle of
>> the client address space. We can't unmap it, because the signal
>> delivery machinery will still keep trying to use it.
>
> Is it the sysinfo page for stage1 or stage2? Where does the sysinfo page
> normally live -- I thought it was at a really high address?
Well there is only one sysinfo page because it is allocated by the
kernel on a per-process basis, so it effectively belongs to the stage1
valgrind process.
We currently then hide it from the simulated program so that it falls
back to using old style system calls. That should also be what happens
once the kernel.vdso sysctl is set to zero or if you boot with vdso=0.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-01 08:09:03
|
On Mon, 31 May 2004, Jeremy Fitzhardinge wrote: > The initial problem is caused by VDSOs, which are placed low in the > address space. What are VDSOs? > Either way, this is pretty tricky to deal with. We basically have to > leave the sysinfo page alone, even though it's sitting in the middle of > the client address space. We can't unmap it, because the signal > delivery machinery will still keep trying to use it. Is it the sysinfo page for stage1 or stage2? Where does the sysinfo page normally live -- I thought it was at a really high address? N |
|
From: Jeremy F. <je...@go...> - 2004-06-01 05:47:00
|
On Sat, 2004-05-29 at 12:13 +0100, Tom Hughes wrote: > Has anybody actually had valgrind running on FC2 yet? > > I don't seem to be able to get it to do anything more that SEGV on > startup at the moment, and I can't even attach gdb to it as it just > seems to hang... I built my own gdb 6 from source, and it seems to work - the FC2 standard one hangs for me too. I got some insight into what's happening. The initial problem is caused by VDSOs, which are placed low in the address space. When Valgrind clears out the client area in stage2, it also clears out the sysinfo page, which happens to be where the munmap syscall returns to... So, if you turn off VDSOs (echo 0 > /proc/sys/kernel/vdso), you get to the next crash. This is a fair bit further on, typicially when the client wants to expand the stack. It gets a fault, calls our SIGSEGV handler, which expands the stack, and then returns from the handler with the intent of restarting the faulting instruction - BANG. The handler returns to address 0x440 and explodes. I haven't confirmed this yet, but it looks to me like a FC2 kernel bug. I'm guessing that when it sets up the signal frame return address, it uses the sysinfo syscall return address, which is sysinfo_page + 0x440 - and since the sysinfo page hasn't been installed, it's just 0x440. Either way, this is pretty tricky to deal with. We basically have to leave the sysinfo page alone, even though it's sitting in the middle of the client address space. We can't unmap it, because the signal delivery machinery will still keep trying to use it. J |
|
From: <js...@ac...> - 2004-06-01 02:55:57
|
Nightly build on phoenix ( SuSE 8.2 ) started at 2004-06-01 04:00:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 153 tests, 12 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: <js...@ac...> - 2004-06-01 02:27:06
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-06-01 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 153 tests, 12 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |