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
(1) |
2
(2) |
3
(2) |
4
|
5
|
6
|
7
|
|
8
|
9
(5) |
10
(3) |
11
|
12
(3) |
13
(1) |
14
|
|
15
|
16
(3) |
17
|
18
(1) |
19
(1) |
20
|
21
|
|
22
|
23
|
24
|
25
|
26
|
27
(2) |
28
(1) |
|
29
|
30
|
|
|
|
|
|
|
From: Philippe W. <phi...@sk...> - 2019-09-02 20:34:08
|
On Mon, 2019-09-02 at 12:49 +0100, João M. S. Silva wrote: > > You will probably have to understand why you get SIGSEGV, as this is likely to > > be the origin of the below abort. > > As a wildguess, maybe stack size limit ? > > I have ran the previous test (increased number of callers) with > unlimited stack size but there is no difference. Valgrind does not have a concept of unlimited stack size. See manual or --help about option --main-stacksize. You might also read about --max-stackframe To eliminate the wild guess, you really need to capture some data *when running under valgrind* to show/prove that the address access that causes the SIGSEGV is not due to a stack too small. You can do this when debugging under Valgrind + vgdb + gdb (e.g. examine the value of the SP, examine where is the failing address, ...). Using 'monitor v.info scheduler' at the time of SIGSEGV is also useful, as it will show the client stack size and the value of the SP. If the wild guess is eliminated, then you have to dig further on the code that causes the SEGV: what address is accessed ? In which (or around which) segment is that pointing ? what is this (asm) code doing ? (you have to look at assembly, because as you say, on the source code level, everything is probably correct, as explained by your next paragraph). If further digging on your side does not ring a bell, on valgrind developer side, there is not much we can do without a (small compilable) reproducer. So, then the next step is to produce a small testcase. > > It points to something in the elaboration of Ada. But that line (472) > does not have problems outside Valgrind and has also been proven by > SPARK. Valgrind can of course change the behaviour, and that is what you then have to investigate. Philippe |
|
From: João M. S. S. <joa...@gm...> - 2019-09-02 11:50:08
|
Thanks. > The above seems to be an error reported with the default value of > --num-callers (12). It might be good to increase the value to have > a bigger stacktrace. Increasing the number of callers allows to reach the same conclusion: ==13055== Process terminating with default action of signal 6 (SIGABRT) ==13055== at 0x16934207: raise (in /usr/lib64/libc-2.17.so) ==13055== by 0x16935A37: abort (in /usr/lib64/libc-2.17.so) ==13055== by 0x166F6E90: uw_init_context_1 (unwind-dw2.c:1580) ==13055== by 0x166F7A17: _Unwind_Backtrace (unwind.inc:283) ==13055== by 0x8182C0: __gnat_backtrace (in /home/AltranUK/jsilva.fs/svn/integration/FWP/FWP_Engine/pw_fwp_engine.eab) ==13055== by 0x80DEBC: system__traceback__call_chain__2 (s-traceb.adb:93) ==13055== by 0x80DEE4: system__traceback__call_chain (s-traceb.adb:109) ==13055== by 0x7FED29: ada__exceptions__call_chain (a-excach.adb:65) ==13055== by 0x7FEE7C: ada__exceptions__complete_occurrence (a-except.adb:928) ==13055== by 0x7FEEAC: ada__exceptions__complete_and_propagate_occurrence (a-except.adb:942) ==13055== by 0x7FF249: ada__exceptions__raise_with_location_and_msg (a-except.adb:1168) ==13055== by 0x7FF204: __gnat_raise_storage_error_msg (a-except.adb:1145) ==13055== by 0x7FF379: __gnat_rcheck_SE_Explicit_Raise (a-except.adb:1446) ==13055== by 0x7FB4B0: system__interrupt_management__notify_exception (in /home/AltranUK/jsilva.fs/svn/integration/FWP/FWP_Engine/pw_fwp_engine.eab) ==13055== by 0x15A445CF: ??? (in /usr/lib64/libpthread-2.17.so) ==13055== by 0x46DCB1: adaptation__airspace_adaptation__segmented_holds___elabs (adaptation-airspace_adaptation-segmented_holds.ads:472) > You will probably have to understand why you get SIGSEGV, as this is likely to > be the origin of the below abort. > As a wildguess, maybe stack size limit ? I have ran the previous test (increased number of callers) with unlimited stack size but there is no difference. It points to something in the elaboration of Ada. But that line (472) does not have problems outside Valgrind and has also been proven by SPARK. João M. S. Silva |