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
(2) |
5
(1) |
|
6
(1) |
7
|
8
(2) |
9
|
10
(1) |
11
|
12
(2) |
|
13
(3) |
14
(2) |
15
(1) |
16
|
17
|
18
|
19
|
|
20
|
21
|
22
(1) |
23
(1) |
24
|
25
|
26
|
|
27
|
28
(2) |
29
(2) |
30
(1) |
31
|
|
|
|
From: <sv...@va...> - 2015-12-13 16:54:41
|
Author: philippe
Date: Sun Dec 13 16:54:34 2015
New Revision: 15748
Log:
Fix the bug description in NEWS
Modified:
trunk/NEWS
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Sun Dec 13 16:54:34 2015
@@ -39,7 +39,7 @@
https://bugs.kde.org/show_bug.cgi?id=XXXXXX
where XXXXXX is the bug number as listed below.
-191069 report fatal signal in XML output
+191069 Exiting due to signal not reported in XML output
278744 cvtps2pd with redundant RexW
353083 arm64 doesn't implement various xattr system calls
353084 arm64 doesn't support sigpending system call
|
Author: philippe
Date: Sun Dec 13 16:53:46 2015
New Revision: 15747
Log:
Fix 191069 Exiting due to signal not reported in XML output
Patch from Matthias Schwarzott (slightly modified)
Added:
trunk/memcheck/tests/gone_abrt_xml.stderr.exp
trunk/memcheck/tests/gone_abrt_xml.vgtest
Modified:
trunk/NEWS
trunk/coregrind/m_signals.c
trunk/docs/internals/xml-output-protocol4.txt
trunk/memcheck/tests/Makefile.am
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Sun Dec 13 16:53:46 2015
@@ -39,6 +39,7 @@
https://bugs.kde.org/show_bug.cgi?id=XXXXXX
where XXXXXX is the bug number as listed below.
+191069 report fatal signal in XML output
278744 cvtps2pd with redundant RexW
353083 arm64 doesn't implement various xattr system calls
353084 arm64 doesn't support sigpending system call
Modified: trunk/coregrind/m_signals.c
==============================================================================
--- trunk/coregrind/m_signals.c (original)
+++ trunk/coregrind/m_signals.c Sun Dec 13 16:53:46 2015
@@ -1740,14 +1740,26 @@
core = False;
}
- if ( (VG_(clo_verbosity) >= 1 ||
- (could_core && is_signal_from_kernel(tid, sigNo, info->si_code))
- ) &&
- !VG_(clo_xml) ) {
- VG_(umsg)(
- "\n"
- "Process terminating with default action of signal %d (%s)%s\n",
- sigNo, VG_(signame)(sigNo), core ? ": dumping core" : "");
+ if ( VG_(clo_verbosity) >= 1
+ || (could_core && is_signal_from_kernel(tid, sigNo, info->si_code))
+ || VG_(clo_xml) ) {
+ if (VG_(clo_xml)) {
+ VG_(printf_xml)("<fatal_signal>\n");
+ VG_(printf_xml)(" <tid>%d</tid>\n", tid);
+ ThreadState* tst = VG_(get_ThreadState)(tid);
+ if (tst->thread_name) {
+ VG_(printf_xml)(" <threadname>%s</threadname>\n",
+ tst->thread_name);
+ }
+ VG_(printf_xml)(" <signo>%d</signo>\n", sigNo);
+ VG_(printf_xml)(" <signame>%s</signame>\n", VG_(signame)(sigNo));
+ VG_(printf_xml)(" <sicode>%d</sicode>\n", info->si_code);
+ } else {
+ VG_(umsg)(
+ "\n"
+ "Process terminating with default action of signal %d (%s)%s\n",
+ sigNo, VG_(signame)(sigNo), core ? ": dumping core" : "");
+ }
/* Be helpful - decode some more details about this fault */
if (is_signal_from_kernel(tid, sigNo, info->si_code)) {
@@ -1820,13 +1832,21 @@
break;
} /* switch (sigNo) */
- if (event != NULL) {
- if (haveaddr)
- VG_(umsg)(" %s at address %p\n",
- event, info->VKI_SIGINFO_si_addr);
- else
- VG_(umsg)(" %s\n", event);
- }
+ if (VG_(clo_xml)) {
+ if (event != NULL)
+ VG_(printf_xml)(" <event>%s</event>\n", event);
+ if (haveaddr)
+ VG_(printf_xml)(" <siaddr>%p</siaddr>\n",
+ info->VKI_SIGINFO_si_addr);
+ } else {
+ if (event != NULL) {
+ if (haveaddr)
+ VG_(umsg)(" %s at address %p\n",
+ event, info->VKI_SIGINFO_si_addr);
+ else
+ VG_(umsg)(" %s\n", event);
+ }
+ }
}
/* Print a stack trace. Be cautious if the thread's SP is in an
obviously stupid place (not mapped readable) that would
@@ -1845,8 +1865,8 @@
if (tid == 1) { // main thread
Addr esp = VG_(get_SP)(tid);
Addr base = VG_PGROUNDDN(esp - VG_STACK_REDZONE_SZB);
- if (VG_(am_addr_is_in_extensible_client_stack)(base) &&
- VG_(extend_stack)(tid, base)) {
+ if (VG_(am_addr_is_in_extensible_client_stack)(base)
+ && VG_(extend_stack)(tid, base)) {
if (VG_(clo_trace_signals))
VG_(dmsg)(" -> extended stack base to %#lx\n",
VG_PGROUNDDN(esp));
@@ -1889,6 +1909,11 @@
VG_(threads)[1].client_stack_szB);
}
}
+ if (VG_(clo_xml)) {
+ /* postamble */
+ VG_(printf_xml)("</fatal_signal>\n");
+ VG_(printf_xml)("\n");
+ }
}
if (VG_(clo_vgdb) != Vg_VgdbNo
@@ -2683,8 +2708,8 @@
then extend the stack segment.
*/
Addr base = VG_PGROUNDDN(esp - VG_STACK_REDZONE_SZB);
- if (VG_(am_addr_is_in_extensible_client_stack)(base) &&
- VG_(extend_stack)(tid, base)) {
+ if (VG_(am_addr_is_in_extensible_client_stack)(base)
+ && VG_(extend_stack)(tid, base)) {
if (VG_(clo_trace_signals))
VG_(dmsg)(" -> extended stack base to %#lx\n",
VG_PGROUNDDN(fault));
@@ -2783,11 +2808,11 @@
vg_assert(info != NULL);
vg_assert(info->si_signo == sigNo);
- vg_assert(sigNo == VKI_SIGSEGV ||
- sigNo == VKI_SIGBUS ||
- sigNo == VKI_SIGFPE ||
- sigNo == VKI_SIGILL ||
- sigNo == VKI_SIGTRAP);
+ vg_assert(sigNo == VKI_SIGSEGV
+ || sigNo == VKI_SIGBUS
+ || sigNo == VKI_SIGFPE
+ || sigNo == VKI_SIGILL
+ || sigNo == VKI_SIGTRAP);
info->si_code = sanitize_si_code(info->si_code);
Modified: trunk/docs/internals/xml-output-protocol4.txt
==============================================================================
--- trunk/docs/internals/xml-output-protocol4.txt (original)
+++ trunk/docs/internals/xml-output-protocol4.txt Sun Dec 13 16:53:46 2015
@@ -743,3 +743,53 @@
* STACK is only present in case of VALGRIND_PRINTF_BACKTRACE. See above
for a definition of STACK.
+
+====================================================================
+
+FATAL_SIGNAL
+
+FATAL_SIGNAL defines a message that was caused by a signal that killed them
+process.
+
+Definition:
+
+ <fatal_signal>
+ <tid>INT</tid>
+ <threadname>NAME</threadname> if set
+
+ <signo>INT</signo>
+ <signame>NAME</signame>
+
+ <sicode>INT</sicode>
+ <event>NAME</event>
+ <siaddr>ADDR</siaddr>
+
+ STACK
+
+ </fatal_signal>
+
+* The <tid> tag indicates the Valgrind thread number. This value
+ is arbitrary but may be used to determine which threads produced
+ which errors (at least, the first instance of each error).
+
+* The <threadname> tag identifies the name of the thread if it was
+ set by the client application. If no name was set, the tag is
+ omitted.
+
+* The <signo> tag indicates signo value from struct siginfo.
+
+* In <signame> tag there is the decoded name of signo.
+
+* The <sicode> tag contains the sicode from struct siginfo.
+
+* The <event> tag indicates the decoded name of the sicode. If sicode
+ has no name, the tag is omitted.
+
+* The <siaddr> tag indicates the address that is the reason
+ why the signal was triggered. This can be an unaligned pointer value or
+ just the address of not mapped memory that is accessed nevertheless.
+ If the signal reason is not related to an address, the tag is omitted.
+
+* STACK is defined above and shows where the thread was when it
+ catched the signal. When sending the signal to itself using raise,
+ then raise is visible in this stack.
Modified: trunk/memcheck/tests/Makefile.am
==============================================================================
--- trunk/memcheck/tests/Makefile.am (original)
+++ trunk/memcheck/tests/Makefile.am Sun Dec 13 16:53:46 2015
@@ -297,7 +297,8 @@
writev1.stderr.exp writev1.stderr.exp-solaris writev1.vgtest \
xml1.stderr.exp xml1.stdout.exp xml1.vgtest xml1.stderr.exp-s390x-mvc \
threadname.vgtest threadname.stderr.exp \
- threadname_xml.vgtest threadname_xml.stderr.exp
+ threadname_xml.vgtest threadname_xml.stderr.exp \
+ gone_abrt_xml.vgtest gone_abrt_xml.stderr.exp
check_PROGRAMS = \
accounting \
Added: trunk/memcheck/tests/gone_abrt_xml.stderr.exp
==============================================================================
--- trunk/memcheck/tests/gone_abrt_xml.stderr.exp (added)
+++ trunk/memcheck/tests/gone_abrt_xml.stderr.exp Sun Dec 13 16:53:46 2015
@@ -0,0 +1,63 @@
+<?xml version="1.0"?>
+
+<valgrindoutput>
+
+<protocolversion>4</protocolversion>
+<protocoltool>memcheck</protocoltool>
+
+<preamble>
+ <line>...</line>
+ <line>...</line>
+ <line>...</line>
+ <line>...</line>
+</preamble>
+
+<pid>...</pid>
+<ppid>...</ppid>
+<tool>memcheck</tool>
+
+<args>
+ <vargv>...</vargv>
+ <argv>
+ <exe>./../../gdbserver_tests/gone</exe>
+ <arg>abort</arg>
+ </argv>
+</args>
+
+<status>
+ <state>RUNNING</state>
+ <time>...</time>
+</status>
+
+starting ...
+aborting ...
+<fatal_signal>
+ <tid>...</tid>
+ <signo>6</signo>
+ <signame>SIGABRT</signame>
+ <sicode>0</sicode>
+ <stack>
+ <frame>
+ <ip>0x........</ip>
+ <obj>...</obj>
+ <fn>main</fn>
+ <dir>...</dir>
+ <file>gone.c</file>
+ <line>...</line>
+ </frame>
+ </stack>
+</fatal_signal>
+
+
+<status>
+ <state>FINISHED</state>
+ <time>...</time>
+</status>
+
+<errorcounts>
+</errorcounts>
+
+<suppcounts>...</suppcounts>
+
+</valgrindoutput>
+
Added: trunk/memcheck/tests/gone_abrt_xml.vgtest
==============================================================================
--- trunk/memcheck/tests/gone_abrt_xml.vgtest (added)
+++ trunk/memcheck/tests/gone_abrt_xml.vgtest Sun Dec 13 16:53:46 2015
@@ -0,0 +1,5 @@
+prog: ../../gdbserver_tests/gone
+args: abort
+vgopts: --xml=yes --xml-fd=2 --log-file=/dev/null
+stderr_filter: filter_xml
+cleanup: rm -f vgcore.*
|
On Sat, 2015-12-12 at 21:41 +0100, Ivo Raisr wrote: > I wonder if I can adjust the test case by introducing an intermediate > function > so that the stack trace will look like (--show-below-main=no): > n2: (page allocation syscalls) mmap/mremap/brk, --alloc-fns, etc. > n1: mmap (syscall-template.S:81) > n1: f (mmapunmap.c:11) > n1: main (mmapunmap.c:20) > > or > n2: (page allocation syscalls) mmap/mremap/brk, --alloc-fns, etc. > > n1: mmap (in /lib/amd64/libc.so.1) > n1: main (mmapunmap.c:20) > > > > and grep in mmapunmap.vgtest just for "mmapunmap.c". Would such test > still cover > the bug you fixed? What the test checks is that we have in the peak snapshot a (unique) part of the stacktrace that does the 'big mmap' (to check that the peak is properly computed). So, introducing a function f, that is only in the stacktrace leading to the big mmap of 80Mb will be good enough to precisely check the (fixed) bug (if needed, you can have f calling g calling mmap (80Mb). > > I tried to get stack traces also with gdb. It gives "correct" stack > traces on > Solaris with original sources, such as: > mmap (in /lib/amd64/libc.so.1) > main (mmapunmap.c:11) > It cannot use DWARF CFI for libc as there is none. And following %rbp > chain just gives > mmap() and _start(), but not main(). Do you have any idea what gdb > does behind the scenes? Humph, no clear idea. gdb unwinder is very sophisticated, it has a bunch of heuristics to unwind e.g. in function prologues or epilogues, even without dwarf unwind info. Thanks for the massif test failure analysis, and upcoming fix :). Philippe |