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
|
4
|
5
(4) |
6
(3) |
7
(3) |
8
(2) |
|
9
(1) |
10
(1) |
11
(2) |
12
(2) |
13
(3) |
14
(7) |
15
(2) |
|
16
|
17
|
18
(1) |
19
|
20
(4) |
21
(1) |
22
(1) |
|
23
|
24
|
25
(2) |
26
(1) |
27
(2) |
28
(2) |
29
(1) |
|
From: Paul F. <pj...@wa...> - 2020-02-12 18:50:58
|
Arrgh please ignore. I had forgotten to set the signal handlers. A+ Paul |
|
From: Paul F. <pj...@wa...> - 2020-02-12 16:49:08
|
Hi
Currently if I run memcheck under gd I'm gett ing a sigsegv. I don't get this when running outside of gdb. (on Linux amd64, a fairly old gdb, 7.11.1-86.fc24)
The test application just does one trivial malloc
#include
int main(void)
{
int* pi = malloc(4);
}
Judging by the scheduler output, the code being executed is in ld.so dl_main.
I set the following breakpoints
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x00000000580694c4 in vgPlain_translate at m_translate.c:1599
stop only if bbs_done == 509
breakpoint already hit 1 time
2 breakpoint keep n 0x00000000580c3b00 in run_thread_for_a_while at m_scheduler/scheduler.c:933
The first was based on the last message that I saw, with the condition bbs_done == 509.
The second breakpoint is just to get closer to the crash site a bit more quickly.
The last code to execute in 'run_a_thread_for_a_while' is
>│1031 SCHEDSETJMP(
│1032 tid,
│1033 jumped,
│1034 VG_(disp_run_translations)(
│1035 two_words,
│1036 (volatile void*)&tst->arch.vex,
│1037 host_code_addr
│1038 )
│1039 );
It's VG_(disp_run_translations) that corrupts the stack
The input arguments are
(gdb) p two_words
$3 = (HWord *) 0x1003039eb0
(gdb) p tst->arch.vex
$4 = {host_EvC_FAILADDR = 1477127896, host_EvC_COUNTER = 99491, pad0 = 0, guest_RAX = 0, guest_RCX = 69357824, guest_RDX = 0, guest_RBX = 69357824, guest_RSP = 137422176144, guest_RBP = 137422176656, guest_RSI = 67109208,
guest_RDI = 137422180173, guest_R8 = 67235712, guest_R9 = 1, guest_R10 = 4, guest_R11 = 69359304, guest_R12 = 1, guest_R13 = 1879048225, guest_R14 = 69357872, guest_R15 = 0, guest_CC_OP = 20, guest_CC_DEP1 = 137422180173,
guest_CC_DEP2 = 0, guest_CC_NDEP = 0, guest_DFLAG = 1, guest_RIP = 67128168, guest_ACFLAG = 0, guest_IDFLAG = 0, guest_FS_CONST = 0, guest_SSEROUND = 0, guest_YMM0 = {0, 0, 0, 0, 0, 0, 0, 0}, guest_YMM1 = {1, 0, 1651076143,
1815032886, 0, 0, 0, 0}, guest_YMM2 = {0, 65793, 0, 0, 0, 0, 0, 0}, guest_YMM3 = {0, 0, 0, 0, 0, 0, 0, 0}, guest_YMM4 = {0, 0, 0, 0, 0, 0, 0, 0}, guest_YMM5 = {0, 0, 0, 0, 0, 0, 0, 0}, guest_YMM6 = {0, 0, 0, 0, 0, 0, 0, 0},
guest_YMM7 = {0, 0, 0, 0, 0, 0, 0, 0}, guest_YMM8 = {0, 0, 0, 0, 0, 0, 0, 0}, guest_YMM9 = {0, 0, 0, 0, 0, 0, 0, 0}, guest_YMM10 = {0, 0, 0, 0, 0, 0, 0, 0}, guest_YMM11 = {0, 0, 0, 0, 0, 0, 0, 0}, guest_YMM12 = {0, 0, 0, 0, 0, 0, 0,
0}, guest_YMM13 = {0, 0, 0, 0, 0, 0, 0, 0}, guest_YMM14 = {0, 0, 0, 0, 0, 0, 0, 0}, guest_YMM15 = {0, 0, 0, 0, 0, 0, 0, 0}, guest_YMM16 = {0, 0, 0, 0, 0, 0, 0, 0}, guest_FTOP = 0, pad1 = 0, guest_FPREG = {0, 0, 0, 0, 0, 0, 0, 0},
guest_FPTAG = "\000\000\000\000\000\000\000", guest_FPROUND = 0, guest_FC3210 = 0, guest_EMNOTE = 0, pad2 = 0, guest_CMSTART = 0, guest_CMLEN = 0, guest_NRADDR = 0, guest_SC_CLASS = 0, guest_GS_CONST = 0, guest_IP_AT_SYSCALL = 0,
pad3 = 0}
(gdb) p host_code_addr
$5 = 68770170016
At the end of VG_(disp_run_translations) there is
jmpq *%rdx
rdx 0x10030584a0 68770170016
and
(gdb) p/x *$rdx
$11 = 0x79084dff
gdb can't disassemble this address
stepping into the jump causes the segfault.
Going back to 'run_a_thread_for_a_while', 'host_code_addr' is coming from VG_(lookupInFastCache)
Any ideas why this address is getting into the cache?
A+
Paul
|