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) |
2
(1) |
3
|
4
|
|
5
|
6
(2) |
7
(1) |
8
|
9
(1) |
10
(1) |
11
(2) |
|
12
(1) |
13
(3) |
14
(5) |
15
|
16
|
17
(4) |
18
|
|
19
(4) |
20
|
21
|
22
|
23
(2) |
24
(1) |
25
|
|
26
|
27
|
28
|
29
|
30
|
31
|
|
|
From: Philippe W. <phi...@so...> - 2018-08-01 19:59:28
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=b9cfb2d15413d16f330878938af3d6fa1617f8b4 commit b9cfb2d15413d16f330878938af3d6fa1617f8b4 Author: Philippe Waroquiers <phi...@sk...> Date: Wed Aug 1 21:49:07 2018 +0200 Fix a few leaks in VG_(make_core_dump) Probably not very critical, as very surely the process will die shortly after, but better still clean the memory, as the code was already doing some effort to free memory (e.g. VG_(free)(seg_starts);). Note that when testing on debian 9/amd64, the resulting core dump was not very usable (e.g. was not really showing what the guest threads are doing). So, there must be a bug in the core dumping logic. Diff: --- coregrind/m_coredump/coredump-elf.c | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/coregrind/m_coredump/coredump-elf.c b/coregrind/m_coredump/coredump-elf.c index 647338a..b851968 100644 --- a/coregrind/m_coredump/coredump-elf.c +++ b/coregrind/m_coredump/coredump-elf.c @@ -580,14 +580,14 @@ void make_elf_coredump(ThreadId tid, const vki_siginfo_t *si, ULong max_size) Int core_fd; NSegment const * seg; ESZ(Ehdr) ehdr; - ESZ(Phdr) *phdrs; + ESZ(Phdr) *phdrs = NULL; Int num_phdrs; Int i, idx; UInt off; struct note *notelist, *note; UInt notesz; struct vki_elf_prpsinfo prpsinfo; - Addr *seg_starts; + Addr *seg_starts = NULL; Int n_seg_starts; if (VG_(clo_log_fname_unexpanded) != NULL) { @@ -598,7 +598,7 @@ void make_elf_coredump(ThreadId tid, const vki_siginfo_t *si, ULong max_size) vg_assert(coreext); vg_assert(basename); - buf = VG_(malloc)( "coredump-elf.mec.1", + buf = VG_(malloc)( "coredump-elf.mec.1", VG_(strlen)(coreext) + VG_(strlen)(basename) + 100/*for the two %ds. */ ); @@ -625,7 +625,7 @@ void make_elf_coredump(ThreadId tid, const vki_siginfo_t *si, ULong max_size) } if (sr_isError(sres) && sr_Err(sres) != VKI_EEXIST) - return; /* can't create file */ + goto cleanup; /* can't create file */ } /* Get the client segments */ @@ -700,7 +700,7 @@ void make_elf_coredump(ThreadId tid, const vki_siginfo_t *si, ULong max_size) fill_phdr(&phdrs[idx], seg, off, (seg->end - seg->start + 1 + off) < max_size); - + off += phdrs[idx].p_filesz; idx++; @@ -712,7 +712,7 @@ void make_elf_coredump(ThreadId tid, const vki_siginfo_t *si, ULong max_size) for(note = notelist; note != NULL; note = note->next) write_note(core_fd, note); - + VG_(lseek)(core_fd, phdrs[1].p_offset, VKI_SEEK_SET); for(i = 0, idx = 1; i < n_seg_starts; i++) { @@ -731,9 +731,14 @@ void make_elf_coredump(ThreadId tid, const vki_siginfo_t *si, ULong max_size) idx++; } - VG_(free)(seg_starts); - VG_(close)(core_fd); + + cleanup: + if (VG_(clo_log_fname_unexpanded) != NULL) + VG_(free)(basename); + VG_(free)(buf); + VG_(free)(seg_starts); + VG_(free)(phdrs); } void VG_(make_coredump)(ThreadId tid, const vki_siginfo_t *si, ULong max_size) |
|
From: Philippe W. <phi...@so...> - 2018-08-01 17:43:45
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=c97f132676cb1e41844c622528265e06a06aedfe commit c97f132676cb1e41844c622528265e06a06aedfe Author: Philippe Waroquiers <phi...@sk...> Date: Wed Aug 1 19:37:13 2018 +0200 Fix segmentation violation caused by stack misalignment when vgdb use ptrace to force activate gdbserver On amd64, on a big application, a vgdb call that wakes up the application using ptrace fails unfrequently (we speak about one failure every few thousands vgdb calls). The failure started to appear when valgrind was compiled with gcc 7.3 instead of gcc 6.4 After investigation: * gcc 7.3 is using (more) sse instructions * Such instructions imply to have a stack pointer aligned on 16 bytes. * vgdb-invoker-ptrace.c 'ptrace' modification of the stack pointer was not respecting the amd64 ABI convention to align on 16 bytes. It was also not protecting the red zone (unclear if this could cause the problem, but in any case, this ptrace logic is similar to a signal handler, and cannot modify the redzone. The fix consists in respecting the ABI. Without the patch, segmentation violation due to an sse instruction being executed with an address on the stack not aligned on 16 bytes, happening something like every 5000 vgdb execution. With the patch, 250_000 executions without problems. Diff: --- coregrind/vgdb-invoker-ptrace.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/coregrind/vgdb-invoker-ptrace.c b/coregrind/vgdb-invoker-ptrace.c index 98092c7..bd640ed 100644 --- a/coregrind/vgdb-invoker-ptrace.c +++ b/coregrind/vgdb-invoker-ptrace.c @@ -970,14 +970,16 @@ Bool invoker_invoke_gdbserver (pid_t pid) // vgdb speaking with a 64 bit executable. const int regsize = 8; int rw; - + /* give check arg in rdi */ user_mod.regs.rdi = check; /* push return address on stack : return to breakaddr */ + sp &= ~0xf; // keep the stack aligned on 16 bytes ... + sp = sp - 128; // do not touch the amd64 redzone sp = sp - regsize; DEBUG(1, "push bad_return return address ptrace_write_memory\n"); - rw = ptrace_write_memory(pid, sp, + rw = ptrace_write_memory(pid, sp, &bad_return, sizeof(bad_return)); if (rw != 0) { |