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
(6) |
|
2
(4) |
3
(9) |
4
(11) |
5
(16) |
6
(6) |
7
(1) |
8
(11) |
|
9
(11) |
10
(6) |
11
(10) |
12
(23) |
13
(23) |
14
(6) |
15
(10) |
|
16
(5) |
17
(13) |
18
(9) |
19
(4) |
20
(6) |
21
(16) |
22
(3) |
|
23
(5) |
24
(7) |
25
(6) |
26
(4) |
27
(8) |
28
|
29
(3) |
|
30
(2) |
31
(17) |
|
|
|
|
|
|
From: <sv...@va...> - 2015-08-27 12:43:41
|
Author: sewardj
Date: Thu Aug 27 13:43:32 2015
New Revision: 15593
Log:
First pass at tidying up the release notes for 3.11.0.
Modified:
trunk/NEWS
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Thu Aug 27 13:43:32 2015
@@ -1,57 +1,80 @@
-Release 3.11.0 (?? ????????? 201?)
+
+Release 3.11.0 (?? September 2015)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Release 3.11.0 is under development, not yet released.
+
+3.11.0 is a feature release with many improvements and the usual
+collection of bug fixes.
+
+This release supports X86/Linux, AMD64/Linux, ARM32/Linux,
+ARM64/Linux, PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux,
+MIPS32/Linux, MIPS64/Linux, TILEGX/Linux, ARM/Android, ARM64/Android,
+MIPS32/Android, X86/Android, X86/Solaris, AMD64/Solaris,
+X86/MacOSX 10.10 and 10.11 and AMD64/MacOSX 10.10 and 10.11.
* ================== PLATFORM CHANGES =================
-* s390x: It is now required for the host to have the long displacement
- facility. The oldest supported machine model is z990.
+* Support for the Tilera TileGX architecture has been added.
+
+* Support for Solaris/x86 and Solaris/amd64 has been added.
-* x86: on an SSE2 only host, Valgrind in 32 bits now claims to be a Pentium 4.
- 3.10.1 was wrongly claiming to be a CORE 2, which is SSSE3.
+* Preliminary support for Mac OS X 10.11 (El Capitan) has been added.
-* Preliminary support for OS X 10.11 (El Capitan) has been added.
+* s390x: It is now required for the host to have the "long displacement"
+ facility. The oldest supported machine model is z990.
+
+* x86: on an SSE2 only host, Valgrind in 32 bit mode now claims to be a
+ Pentium 4. 3.10.1 wrongly claimed to be a Core 2, which is SSSE3.
+
+* The JIT's register allocator is significantly faster, making the JIT
+ as a whole somewhat faster, so JIT-intensive activities (like
+ program startup) are modestly faster, around 5%.
* ==================== TOOL CHANGES ====================
* Memcheck:
- - A new monitor command 'xb <addr> <len>' shows the validity bits
- of <len> bytes at <addr>. Below the validity bits, the byte
- values are shown using a layout similar to the GDB command
- 'x /<len>xb <addr>'. The monitor command 'xb' is easier to use than
- get_vbits (in particular on little endian computers) when you need to
- associate byte data value with their corresponding validity bits.
+
+ - A new monitor command 'xb <addr> <len>' shows the validity bits of
+ <len> bytes at <addr>. The monitor command 'xb' is easier to use
+ than get_vbits when you need to associate byte data value with
+ their corresponding validity bits.
- The 'block_list' monitor command now accepts an optional argument
- 'limited <max_blocks>' to control the nr of block addresses printed.
+ 'limited <max_blocks>' to control the nr of block addresses
+ printed.
+
+ - The C helper functions used to instrument loads on x86-linux and
+ arm-linux (both 32-bit only) have been replaced by handwritten
+ assembly sequences. This gives speedups in the region of 0% to 7%
+ for those targets only.
* Massif:
- - New monitor command 'all_snapshots <filename>' that dumps all snapshots
- taken so far.
+
+ - New monitor command 'all_snapshots <filename>' that dumps all
+ snapshots taken so far.
* Helgrind:
- - The default value for --conflict-cache-size=N has been doubled to 2000000.
- Users that were not using the default value should preferrably also
- double the value they give.
- The default was updaded due to the changes in the full history
- implementation. Doubling the value gives in average a slightly more
+
+ - Significant memory reduction and moderate speedups for
+ --history-level=full for applications accessing a lot of memory
+ with many different stacktraces.
+
+ - The default value for --conflict-cache-size=N has been doubled to
+ 2000000. Users that were not using the default value should
+ preferably also double the value they give.
+
+ The default was changed due to the changes in the "full history"
+ implementation. Doubling the value gives on average a slightly more
complete history and uses similar memory (or significantly less memory
- in the worst case) than the previous Helgrind version.
+ in the worst case) than the previous implementation.
- - Significant memory improvement and moderate speed improvement for
- --history-level=full for applications accessing a lot of memory with
- many different stacktraces.
-
- - The helgrind monitor command 'info locks' now accepts an optional
- argument 'lock_addr', to only show information about the lock at the
- given address.
+ - The Helgrind monitor command 'info locks' now accepts an optional
+ argument 'lock_addr', which shows information about the lock at the
+ given address only.
- - When using --history-level=full, the new helgrind monitor command
+ - When using --history-level=full, the new Helgrind monitor command
'accesshistory <addr> [<len>]' will show the recorded accesses for
<len> (or 1) bytes at <addr>.
-* Callgrind:
-
* ==================== OTHER CHANGES ====================
* The command line options --db-attach and --db-command have been removed.
@@ -69,36 +92,36 @@
searching/extracting errors in output files mixing valgrind
errors with program output.
-* New Option --max-threads=<number> can be used to change the
- number of threads valgrind can handle. The default is 500 threads
- which should be more than enough for most applications.
-
-* New Option --valgrind-stacksize=<number> can be used to change
- the size of the private thread stacks used by Valgrind.
- Useful to reduce memory use or increase the stack size if Valgrind
- segfaults due to stack exhausted.
-
-* New Option --avg-transtab-entry-size=<number> can be used to tune
- the size of the translation table sectors, either to gain memory
- or to avoid too many retranslations.
+* New option --max-threads=<number> can be used to change the number
+ of threads valgrind can handle. The default is 500 threads which
+ should be more than enough for most applications.
+
+* New option --valgrind-stacksize=<number> can be used to change the
+ size of the private thread stacks used by Valgrind. This is useful
+ for reducing memory use or increasing the stack size if Valgrind
+ segfaults due to stack overflow.
+
+* New option --avg-transtab-entry-size=<number> can be used to specify
+ the expected instrumented block size, either to reduce memory use or
+ to avoid excess retranslations.
-* Valgrind can be built with Intel's ICC compiler. The required
- compiler version is 14.0 or later.
+* Valgrind can be built with Intel's ICC compiler, version 14.0 or later.
* New and modified GDB server monitor features:
+
- When a signal is reported in GDB, you can now use the GDB convenience
variable $_siginfo to examine detailed signal information.
- - Valgrind gdbserver now allows the user to change the signal
- to deliver to the process. So, use 'signal SIGNAL' to continue execution
+ - Valgrind's gdbserver now allows the user to change the signal
+ to deliver to the process. So, use 'signal SIGNAL' to continue execution
with SIGNAL instead of the signal reported to GDB. Use 'signal 0' to
continue without passing the signal to the process.
- With recent GDB (>= 7.9.50.20150514-cvs), the command 'target remote'
will automatically load the executable file of the process running
under Valgrind. This means you do not need to specify the executable
- file yourself, GDB will discover it itself.
- See GDB documentation about 'qXfer:exec-file:read' packet for more info.
+ file yourself, GDB will discover it itself. See GDB documentation about
+ 'qXfer:exec-file:read' packet for more info.
* ==================== FIXED BUGS ====================
@@ -121,21 +144,17 @@
201435 Fix Darwin: -v does not show kernel version
208217 "Warning: noted but unhandled ioctl 0x2000747b" on Mac OS X
211256 Fixed an outdated comment regarding the default platform.
-211529 valgrind doesn't show proper call stacks for programs compiled
- by newer versions of visual c++
+211529 Incomplete call stacks for code compiled by newer versions of MSVC
211926 Avoid compilation warnings in valgrind.h with -pedantic
212291 Fix unhandled syscall: unix:132 (mkfifo) on OS X
== 263119
226609 Crediting upstream authors in man page
231257 Valgrind omits path when executing script from shebang line
-254164 OS X task_info: UNKNOWN task message [id 3405, to mach_task_self(),
- reply 0x........]
+254164 OS X task_info: UNKNOWN task message [id 3405, to mach_task_self() [..]
269360 s390x: Fix addressing mode selection for compare-and-swap
-302630 Memcheck on multithreaded program fails with Assertion
- 'sizeof(UWord) == sizeof(UInt)' failed in m_syscall.c
+302630 Memcheck: Assertion failed: 'sizeof(UWord) == sizeof(UInt)'
== 326797
-312989 ioctl handling needs to do POST handling on generic ioctls and
- needs to handle BPF ioctls
+312989 ioctl handling needs to do POST handling on generic ioctls and [..]
319274 Fix unhandled syscall: unix:410 (sigsuspend_nocancel) on OS X
324181 mmap does not handle MAP_32BIT (handle it now, rather than fail it)
327745 Fix valgrind 3.9.0 build fails on Mac OS X 10.6.8
@@ -180,14 +199,12 @@
segment if it is past the heap end
341613 Enable building of manythreads and thread-exits tests on Mac OS X
341615 Fix none/tests/darwin/access_extended test on Mac OS X
-341698 Valgrind's AESKEYGENASSIST gives wrong result in words 0 and 2
- when dest register = source register
+341698 Valgrind's AESKEYGENASSIST gives wrong result in words 0 and 2 [..]
341789 aarch64: shmat fails with valgrind on ARMv8
341997 MIPS64: Cavium OCTEON insns - immediate operand handled incorrectly
342038 Unhandled syscalls on aarch64 (mbind/get/set_mempolicy)
342063 wrong format specifier for test mcblocklistsearch in gdbserver_tests
-342117 Valgrind hangs after loading PDB file for MSVC compiled Firefox
- under Wine
+342117 Hang when loading PDB file for MSVC compiled Firefox under Wine
342221 socket connect false positive uninit memory for unknown af family
342353 Allow dumping full massif output while valgrind is still running
342571 Valgrind chokes on AVX compare intrinsic with _CMP_GE_QS
@@ -208,25 +225,19 @@
343306 OS X 10.10: UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
343332 Unhandled instruction 0x9E310021 (fcvtmu) on aarch64
343335 unhandled instruction 0x1E638400 (fccmp) aarch64
-343523 OS X mach_ports_register: UNKNOWN task message [id 3403, to
- mach_task_self(), reply 0x30f]
-343525 OS X host_get_special_port: UNKNOWN host message [id 412, to
- mach_host_self(), reply 0x........]
+343523 OS X mach_ports_register: UNKNOWN task message [id 3403, to [..]
+343525 OS X host_get_special_port: UNKNOWN host message [id 412, to [..]
343597 ppc64le: incorrect use of offseof macro
-343649 OS X host_create_mach_voucher: UNKNOWN host message [id 222, to
- mach_host_self(), reply 0x........]
-343663 [OSX Yosemite 10.10.1] The memcheck tool always reports a
- leak regardless of the simplicity of the program.
+343649 OS X host_create_mach_voucher: UNKNOWN host message [id 222, to [..]
+343663 OS X 10.10 Memchecj always reports a leak regardless of [..]
343732 Unhandled syscall 144 (setgid) on aarch64
343733 Unhandled syscall 187 (msgctl and related) on aarch64
-343802 s390x: Fix false positives "conditional jump or move depends on
- unitialised value(s)"
+343802 s390x: False positive "conditional jump or move depends on [..]
343902 --vgdb=yes doesn't break when --xml=yes is used
343967 Don't warn about setuid/setgid/setcap executable for directories
343978 Recognize DWARF5/GCC5 DW_LANG_Fortran 2003 and 2008 constants
344007 accept4 syscall unhandled on arm64 (242) and ppc64 (344)
-344033 Helgrind on ARM32 loses track of mutex lockedness state in
- pthread_cond_wait
+344033 Helgrind on ARM32 loses track of mutex state in pthread_cond_wait
344054 www - update info for Solaris/illumos
344416 'make regtest' does not work cleanly on OS X
344235 Remove duplicate include of pub_core_aspacemgr.h
@@ -236,12 +247,10 @@
344314 callgrind_annotate ... warnings about commands containing newlines
344318 socketcall should wrap recvmmsg and sendmmsg
344337 Fix unhandled syscall: mach:41 (_kernelrpc_mach_port_guard_trap)
-344416 Fix âmake regtest' does not work cleanly on OS X
-344499 Fix compilation for Linux kernel >= 4. With this, also require
- a Linux kernel >= 2.6 as 2.4 is mostly untested and might trigger
- obvious and non-obvious issues
-344512 Fix unhandled syscall: unix:348 (__pthread_chdir) and unhandled
- syscall: unix:349 (__pthread_fchdir) on OS X
+344416 Fix 'make regtest' does not work cleanly on OS X
+344499 Fix compilation for Linux kernel >= 4.0.0
+344512 OS X: unhandled syscall: unix:348 (__pthread_chdir),
+ unix:349 (__pthread_fchdir)
344559 Garbage collection of unused segment names in address space manager
344560 Fix stack traces missing penultimate frame on OS X
344621 Fix memcheck/tests/err_disable4 test on OS X
@@ -283,19 +292,18 @@
347151 Fix suppression for pthread_rwlock_init on OS X 10.8
347233 Fix memcheck/tests/strchr on OS X 10.10 (Haswell)
347322 Power PC regression test cleanup
-347379 valgrind --leak-check=full memleak errors from system libraries on OS X 10.8
+347379 valgrind --leak-check=full leak errors from system libraries on OS X 10.8
== 217236
347389 unhandled syscall: 373 (Linux ARM syncfs)
347686 Patch set to cleanup PPC64 regtests
347978 Remove bash dependencies where not needed
-347982 Fix undefined symbols for architecture x86_64: "_global", referenced from:
- _test_so_global in tls_so-tls_so.o
-347988 Fix Memcheck: the 'impossible' happened: unexpected size for Addr (OSX/wine)
+347982 OS X: undefined symbols for architecture x86_64: "_global" [..]
+347988 Memcheck: the 'impossible' happened: unexpected size for Addr (OSX/wine)
== 345929
348102 Patch updating v4l2 API support
-348247 jno jumps wrongly when overflow is not set
+348247 amd64 front end: jno jumps wrongly when overflow is not set
348269 Improve mmap MAP_HUGETLB support.
-348334 (ppc) valgrind does not simulate dcbfl - then my program terminates
+348334 (ppc) valgrind does not simulate dcbfl - then my program terminates
348345 Assertion fails for negative lineno
348377 Unsupported ARM instruction: yield
348565 Fix detection of command line option availability for clang
@@ -305,10 +313,8 @@
348890 Fix clang warning about unsupported --param inline-unit-growth=900
348949 Bogus "ERROR: --ignore-ranges: suspiciously large range"
349034 Add Lustre ioctls LL_IOC_GROUP_LOCK and LL_IOC_GROUP_UNLOCK
-349086 Fix UNKNOWN task message [id 3406, to mach_task_self(),
- reply 0x........] (task_set_info)
-349087 Fix UNKNOWN task message [id 3410, to mach_task_self(),
- reply 0x........] (task_set_special_port)
+349086 Fix UNKNOWN task message [id 3406, to mach_task_self(), [..]
+349087 Fix UNKNOWN task message [id 3410, to mach_task_self(), [..]
349626 Implemented additional Xen hypercalls
349769 Fix clang/osx: ld: warning: -read_only_relocs cannot be used with x86_64
349790 Clean up of the hardware capability checking utilities.
@@ -316,18 +322,18 @@
349874 Fix typos in source code
349879 memcheck: add handwritten assembly for helperc_LOADV*
349941 di_notify_mmap might create wrong start/size DebugInfoMapping
-350062 vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xB (ROUNDSD) on OS X
+350062 vex x86->IR: 0x66 0xF 0x3A 0xB (ROUNDSD) on OS X
350202 Add limited param to 'monitor block_list'
350809 Fix none/tests/async-sigs for Solaris
350811 Remove reference to --db-attach which has been removed.
-350813 Use handwritten memcheck assembly helpers on x86/Solaris in addition to {arm,x86}-linux
+350813 Memcheck/x86: enable handwritten assembly helpers for x86/Solaris too
350854 hard-to-understand code in VG_(load_ELF)()
351140 arm64 syscalls setuid (146) and setresgid (149) not implemented
-351386 Cannot run ld.so.1 under Valgrind
+351386 Solaris: Cannot run ld.so.1 under Valgrind
351474 Fix VG_(iseqsigset) as obvious
351534 Fix incorrect header guard
n-i-bz Provide implementations of certain compiler builtins to support
- compilers who may not provide those
+ compilers that may not provide those
n-i-bz Old STABS code is still being compiled, but never used. Remove it.
n-i-bz Fix compilation on distros with glibc < 2.5
n-i-bz (vex 3098) Avoid generation of Neon insns on non-Neon hosts
@@ -336,6 +342,9 @@
n-i-bz Fix incorrect sizeof expression in syswrap-xen.c reported by Coverity
n-i-bz In VALGRIND_PRINTF write out thread name, if any, to xml
+(3.10.1.BETA?: ?? September 2015, vex r????, valgrind r?????)
+
+
Release 3.10.1 (25 November 2014)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
From: Ivo R. <ivo...@gm...> - 2015-08-27 12:32:57
|
2015-08-27 13:58 GMT+02:00 Julian Seward <js...@ac...>: > > --read-inline-info=yes > > My experience of the inlined-unwind functionality introduced in 3.10.0 has > been positive, and I always use it. I think it's time to enable it by > default. > +1 for this one. It provides huge help. I. |
|
From: Julian S. <js...@ac...> - 2015-08-27 11:58:12
|
> I am thinking a.o. to 2 candidates: > > * Change --leak-check-heuristics=none to --leak-check-heuristics=all > This avoids false possibly lost in c++ code. > No memory or cpu impact (except neglectible cpu needed for heuristic > during leak search, when encountering a possibly leaked block). > > * Change --keep-stacktraces=alloc-then-free to alloc-and-free > This gives more information for writes to freed blocks, showing > also the stacktrace where the block was allocated. > Neglectible cpu impact. Memory impact is one word per client > allocated block. These both sound good to me. The only concern I have is that they might cause a lot of regtests to fail, so we'd have to update the expected output files too. I would also like to propose the following changes: --smc-check=all-non-file So as to give transparent support for JIT generated code. No perf effect on "normal" (file-backed) code. --dsymutil=yes Since you always need to use this on MacOS, else stack traces are missing or wrong. --read-inline-info=yes My experience of the inlined-unwind functionality introduced in 3.10.0 has been positive, and I always use it. I think it's time to enable it by default. J |
|
From: Tom H. <to...@co...> - 2015-08-27 11:53:50
|
On 27/08/15 12:43, Julian Seward wrote: > >>> ==51151== at 0x1004C8C3F: _platform_memchr$VARIANT$Haswell (in >>> /usr/lib/system/libsystem_platform.dylib) > >> This is missing system library suppression for a hardware-specific >> optimisation path. > > No need to suppress. Instead, we need to intercept calls to this function. > Have a look at the "memchr" section in shared/vg_replace_strmem.c. It's a > 1-liner fix. Or 2 lines if you duplicate the comment :) See https://bugs.kde.org/show_bug.cgi?id=351756 where that fix has already been tested and Rhys said he'd commit it. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Julian S. <js...@ac...> - 2015-08-27 11:43:12
|
>> ==51151== at 0x1004C8C3F: _platform_memchr$VARIANT$Haswell (in >> /usr/lib/system/libsystem_platform.dylib) > This is missing system library suppression for a hardware-specific > optimisation path. No need to suppress. Instead, we need to intercept calls to this function. Have a look at the "memchr" section in shared/vg_replace_strmem.c. It's a 1-liner fix. Or 2 lines if you duplicate the comment :) J |
|
From: Florian K. <fl...@ei...> - 2015-08-26 20:27:44
|
I could not reproduce the problem but opted for implementing solution #2
in r15592. Let me know if this does not work for you.
Florian
On 13.08.2015 23:07, Matthias Schwarzott wrote:
> Hi!
>
> The testcase gdbserver_tests/nlgone_exit fails if the locale is set to a
> non english value.
>
> To reproduce this on any system, run soemthing like this:
> # LANG="de_DE" perl tests/vg_regtest gdbserver_tests/nlgone_exit.vgtest
>
> It then fails with this stdoutB.diff:
> --- nlgone_exit.stderrB.exp 2015-05-17 14:29:09.000000000 +0200
> +++ nlgone_exit.stderrB.out 2015-08-13 22:56:52.000000000 +0200
> @@ -1 +1,2 @@
> relaying data between gdb and process ....
> +32 ../sysdeps/unix/sysv/linux/_exit.c: Datei oder Verzeichnis nicht
> gefunden.
>
>
> Possible Solutions:
>
> 1. Cleanup of environment in vg_regtest: For all tests clear several
> known bad variables like LC_* or define others like LC_ALL=C. Cleanup
> could also include to set core file limit to a known value (if test does
> not decide otherwise).
>
> 2. add envB to vgtest syntax, so the affected testcase can define LC_ALL=C.
>
> Regards
> Matthias
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|
|
From: <sv...@va...> - 2015-08-26 20:24:55
|
Author: florian
Date: Wed Aug 26 21:24:47 2015
New Revision: 15592
Log:
Support
envB: var=value
in the .vgtest file. This is similar to "env:" except the environment
variable is set prior to invoking progB.
Adapt gdbserver_tests/nlgone_exit.vgtest to fix a problem reported
by Matthias Schwarzott <zz...@ge...>
Modified:
trunk/gdbserver_tests/nlgone_exit.vgtest
trunk/tests/vg_regtest.in
Modified: trunk/gdbserver_tests/nlgone_exit.vgtest
==============================================================================
--- trunk/gdbserver_tests/nlgone_exit.vgtest (original)
+++ trunk/gdbserver_tests/nlgone_exit.vgtest Wed Aug 26 21:24:47 2015
@@ -7,6 +7,7 @@
stderr_filter: filter_stderr
prereq: test -e gdb
progB: gdb
+envB: LC_ALL=C
argsB: --quiet -l 60 --nx ./gone
stdinB: nlgone_exit.stdinB.gdb
stdoutB_filter: filter_gdb
Modified: trunk/tests/vg_regtest.in
==============================================================================
--- trunk/tests/vg_regtest.in (original)
+++ trunk/tests/vg_regtest.in Wed Aug 26 21:24:47 2015
@@ -71,6 +71,7 @@
# - stderr_filter_args: <args for stderr_filter> (default: basename of .vgtest file)
#
# - progB: <prog to run in parallel with prog> (default: none)
+# - envB: <environment variable for progB> (default: none)
# - argsB: <args for progB> (default: none)
# - stdinB: <input file for progB> (default: none)
# - stdoutB_filter: <filter progB stdout through> (default: none)
@@ -91,6 +92,7 @@
#
# There can be more than one env: declaration. Here is an example:
# env: PATH=/opt/bin:$PATH
+# Likewise for envB.
#
# Expected stdout (filtered) is kept in <test>.stdout.exp* (can be more
# than one expected output). It can be missing if it would be empty. Expected
@@ -162,6 +164,7 @@
my $post; # check command after running test
my $cleanup; # cleanup command to run
my @env = (); # environment variable to set prior calling $prog
+my @envB = (); # environment variable to set prior calling $progB
my @failures; # List of failed tests
@@ -344,6 +347,8 @@
$cleanup = $1;
} elsif ($line =~ /^\s*env:\s*(.*)$/) {
push @env,$1;
+ } elsif ($line =~ /^\s*envB:\s*(.*)$/) {
+ push @envB,$1;
} else {
die "Bad line in $f: $line\n";
}
@@ -460,6 +465,11 @@
if (defined $progB) {
+ # Collect environment variables, if any.
+ my $envBvars = "";
+ foreach my $e (@envB) {
+ $envBvars = "$envBvars $e";
+ }
# If there is a progB, let's start it in background:
printf("%-16s valgrind $extraopts $vgopts $prog $args (progB: $progB $argsB)\n",
"$name:");
@@ -468,11 +478,13 @@
# to e.g. redirect stdoutB to stderrB
if (defined $stdinB) {
mysystem("(rm -f progB.done;"
- . " < $stdinB > $name.stdoutB.out 2> $name.stderrB.out $progB $argsB;"
+ . " < $stdinB > $name.stdoutB.out 2> $name.stderrB.out"
+ . " $envBvars $progB $argsB;"
. "touch progB.done) &");
} else {
mysystem("(rm -f progB.done;"
- . " > $name.stdoutB.out 2> $name.stderrB.out $progB $argsB;"
+ . " > $name.stdoutB.out 2> $name.stderrB.out"
+ . "$envBvars $progB $argsB;"
. "touch progB.done) &");
}
} else {
|
|
From: Mark W. <mj...@re...> - 2015-08-26 10:28:09
|
On Tue, 2015-08-25 at 21:00 +0200, Philippe Waroquiers wrote: > Ok to go with the filter, that is largely good enough for the following > reasons: > 1. implementing file transfer in valgrind gdbserver implies some > non minor work (a few hundreds lines of code, I would say). > 2. the typical use case of Valgrind gdbserver is to have Valgrind and > GDB on the same host, so using gdbserver remote protocol to access > files will just be significantly slower, in most cases, and GDB > will automatically use the remote file access if V gdbserver would > provide it. > > Of course, without remote file access, it means that for a 'real' remote > valgrind (i.e. using vgdb via tcp/ip), that you must have a local copy > of the executable and libraries, so that gdb can read them locally. OK, I checked in the filter for now (valgrind svn r15591). I opened a bug for the remote files access feature so we can add it for some version after 3.11 if we can find the time to implement it (and do it efficiently): https://bugs.kde.org/show_bug.cgi?id=351792 Thanks, Mark |
|
From: <sv...@va...> - 2015-08-26 10:27:27
|
Author: mjw
Date: Wed Aug 26 11:27:19 2015
New Revision: 15591
Log:
Filter out gdb file transfer warnings in gdbserver_tests/filter_stderr.
GDB is correct that we don't support that at the moment.
See bug #351792 - vgdb doesn't support remote file transfers.
Modified:
trunk/gdbserver_tests/filter_stderr
Modified: trunk/gdbserver_tests/filter_stderr
==============================================================================
--- trunk/gdbserver_tests/filter_stderr (original)
+++ trunk/gdbserver_tests/filter_stderr Wed Aug 26 11:27:19 2015
@@ -10,4 +10,5 @@
-e '/\/path\/to\/gdb/d' \
-e '/and then give GDB the following command/d' \
-e '/target remote |/d' \
- -e '/pid is optional if only one valgrind process is running/d'
+ -e '/pid is optional if only one valgrind process is running/d' \
+ -e '/warning: remote target does not support file transfer, attempting to access files from local filesystem./d'
|
|
From: <sv...@va...> - 2015-08-25 21:39:52
|
Author: philippe
Date: Tue Aug 25 22:39:44 2015
New Revision: 15590
Log:
Fix a leak of the abbrev hash table when --read-var-info=yes is given
Modified:
trunk/coregrind/m_debuginfo/readdwarf3.c
Modified: trunk/coregrind/m_debuginfo/readdwarf3.c
==============================================================================
--- trunk/coregrind/m_debuginfo/readdwarf3.c (original)
+++ trunk/coregrind/m_debuginfo/readdwarf3.c Tue Aug 25 22:39:44 2015
@@ -4590,8 +4590,9 @@
cu_offset_now = (cu_start_offset + cc.unit_length
+ (cc.is_dw64 ? 12 : 4));
+ clear_CUConst ( &cc);
+
if (cu_offset_now >= escn_debug_types.szB) {
- clear_CUConst ( &cc);
break;
}
|
|
From: Rhys K. <rhy...@gm...> - 2015-08-25 19:15:18
|
Hello,
This is missing system library suppression for a hardware-specific
optimisation path.
Will be easy enough to fix.
Regards,
Rhys
On Wednesday, 26 August 2015, Mark Pauley <pa...@un...> wrote:
> Hi all, I’m seeing a very obviously weird error message on Yosemite with
> trunk valgrind:
>
> ---
>
> $ cat helloWorldPlusPlus.cpp
> #include <string>
> #include <iostream>
>
> int main(int argc, char** argv) {
> std::string output = *(new std::string("Hello, World!\n"));
>
> std::cout << output << std::endl;
>
> return 0;
> }
>
> ---
>
> $ clang++ -std=c++11 -stdlib=libc++ -o helloWorldPlusPlus
> helloWorldPlusPlus.cpp
> $ valgrind ./helloWorldPlusPlus
>
> …
>
> ==51151== Conditional jump or move depends on uninitialised value(s)
> ==51151== at 0x1004C8C3F: _platform_memchr$VARIANT$Haswell (in
> /usr/lib/system/libsystem_platform.dylib)
> ==51151== by 0x1002BC9F6: __sfvwrite (in
> /usr/lib/system/libsystem_c.dylib)
> ==51151== by 0x1002BCF0A: fwrite (in /usr/lib/system/libsystem_c.dylib)
> ==51151== by 0x100028D29: std::__1::__stdoutbuf<char>::overflow(int)
> (in /usr/lib/libc++.1.dylib)
> ==51151== by 0x10001E91C: std::__1::basic_streambuf<char,
> std::__1::char_traits<char> >::xsputn(char const*, long) (in
> /usr/lib/libc++.1.dylib)
> ==51151== by 0x100001BBD: std::__1::ostreambuf_iterator<char,
> std::__1::char_traits<char> > std::__1::__pad_and_output<char,
> std::__1::char_traits<char> >(std::__1::ostreambuf_iterator<char,
> std::__1::char_traits<char> >, char const*, char const*, char const*,
> std::__1::ios_base&, char) (in ./helloWorldPlusPlus)
> ==51151== by 0x1000015F6: std::__1::basic_ostream<char,
> std::__1::char_traits<char> >& std::__1::__put_character_sequence<char,
> std::__1::char_traits<char> >(std::__1::basic_ostream<char,
> std::__1::char_traits<char> >&, char const*, unsigned long) (in
> ./helloWorldPlusPlus)
> ==51151== by 0x1000011F1: std::__1::basic_ostream<char,
> std::__1::char_traits<char> >& std::__1::operator<< <char,
> std::__1::char_traits<char>, std::__1::allocator<char>
> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&,
> std::__1::basic_string<char, std::__1::char_traits<char>,
> std::__1::allocator<char> > const&) (in ./helloWorldPlusPlus)
> ==51151== by 0x100000F6C: main (in ./helloWorldPlusPlus)
> ==51151==
> ==51151== Conditional jump or move depends on uninitialised value(s)
> ==51151== at 0x1004C8C47: _platform_memchr$VARIANT$Haswell (in
> /usr/lib/system/libsystem_platform.dylib)
> ==51151== by 0x1002BC9F6: __sfvwrite (in
> /usr/lib/system/libsystem_c.dylib)
> ==51151== by 0x1002BCF0A: fwrite (in /usr/lib/system/libsystem_c.dylib)
> ==51151== by 0x100028D29: std::__1::__stdoutbuf<char>::overflow(int)
> (in /usr/lib/libc++.1.dylib)
> ==51151== by 0x10001E91C: std::__1::basic_streambuf<char,
> std::__1::char_traits<char> >::xsputn(char const*, long) (in
> /usr/lib/libc++.1.dylib)
> ==51151== by 0x100001BBD: std::__1::ostreambuf_iterator<char,
> std::__1::char_traits<char> > std::__1::__pad_and_output<char,
> std::__1::char_traits<char> >(std::__1::ostreambuf_iterator<char,
> std::__1::char_traits<char> >, char const*, char const*, char const*,
> std::__1::ios_base&, char) (in ./helloWorldPlusPlus)
> ==51151== by 0x1000015F6: std::__1::basic_ostream<char,
> std::__1::char_traits<char> >& std::__1::__put_character_sequence<char,
> std::__1::char_traits<char> >(std::__1::basic_ostream<char,
> std::__1::char_traits<char> >&, char const*, unsigned long) (in
> ./helloWorldPlusPlus)
> ==51151== by 0x1000011F1: std::__1::basic_ostream<char,
> std::__1::char_traits<char> >& std::__1::operator<< <char,
> std::__1::char_traits<char>, std::__1::allocator<char>
> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&,
> std::__1::basic_string<char, std::__1::char_traits<char>,
> std::__1::allocator<char> > const&) (in ./helloWorldPlusPlus)
> ==51151== by 0x100000F6C: main (in ./helloWorldPlusPlus)
> ==51151==
>
> …
>
> followed by the expected leak detection, 24 bytes.
>
> Is this a real issue in libc++ / libsystem, or just a bug in valgrind
> trunk?
>
>
> -Pauley
>
>
|
|
From: Philippe W. <phi...@sk...> - 2015-08-25 19:00:30
|
On Tue, 2015-08-25 at 11:34 +0200, Mark Wielaard wrote: > + -e '/warning: remote target does not support file transfer, attempting to access files from local filesystem./d' > > Makes all gdbserver_tests PASS again, except one gdbserver_tests/hgtls. > But that seems an unrelated issue. Shall we just go with a filter, or do > you want to look into supporting file transfers in vgdb first? Hello Mark, Thanks for looking at these failures, and for the filter. Ok to go with the filter, that is largely good enough for the following reasons: 1. implementing file transfer in valgrind gdbserver implies some non minor work (a few hundreds lines of code, I would say). 2. the typical use case of Valgrind gdbserver is to have Valgrind and GDB on the same host, so using gdbserver remote protocol to access files will just be significantly slower, in most cases, and GDB will automatically use the remote file access if V gdbserver would provide it. Of course, without remote file access, it means that for a 'real' remote valgrind (i.e. using vgdb via tcp/ip), that you must have a local copy of the executable and libraries, so that gdb can read them locally. For what concerns the hgtls failure: this is due to a regression in GDB, see bug 'regression in showing __thread so extern variable' https://sourceware.org/bugzilla/show_bug.cgi?id=18564 that has a small reproducer. If someone has a 'gdb bissect setup', this might help to find the regression origin. Philippe |
|
From: Mark P. <pa...@un...> - 2015-08-25 18:42:04
|
Hi all, I’m seeing a very obviously weird error message on Yosemite with trunk valgrind:
---
$ cat helloWorldPlusPlus.cpp
#include <string>
#include <iostream>
int main(int argc, char** argv) {
std::string output = *(new std::string("Hello, World!\n"));
std::cout << output << std::endl;
return 0;
}
---
$ clang++ -std=c++11 -stdlib=libc++ -o helloWorldPlusPlus helloWorldPlusPlus.cpp
$ valgrind ./helloWorldPlusPlus
…
==51151== Conditional jump or move depends on uninitialised value(s)
==51151== at 0x1004C8C3F: _platform_memchr$VARIANT$Haswell (in /usr/lib/system/libsystem_platform.dylib)
==51151== by 0x1002BC9F6: __sfvwrite (in /usr/lib/system/libsystem_c.dylib)
==51151== by 0x1002BCF0A: fwrite (in /usr/lib/system/libsystem_c.dylib)
==51151== by 0x100028D29: std::__1::__stdoutbuf<char>::overflow(int) (in /usr/lib/libc++.1.dylib)
==51151== by 0x10001E91C: std::__1::basic_streambuf<char, std::__1::char_traits<char> >::xsputn(char const*, long) (in /usr/lib/libc++.1.dylib)
==51151== by 0x100001BBD: std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> > std::__1::__pad_and_output<char, std::__1::char_traits<char> >(std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >, char const*, char const*, char const*, std::__1::ios_base&, char) (in ./helloWorldPlusPlus)
==51151== by 0x1000015F6: std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*, unsigned long) (in ./helloWorldPlusPlus)
==51151== by 0x1000011F1: std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<< <char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (in ./helloWorldPlusPlus)
==51151== by 0x100000F6C: main (in ./helloWorldPlusPlus)
==51151==
==51151== Conditional jump or move depends on uninitialised value(s)
==51151== at 0x1004C8C47: _platform_memchr$VARIANT$Haswell (in /usr/lib/system/libsystem_platform.dylib)
==51151== by 0x1002BC9F6: __sfvwrite (in /usr/lib/system/libsystem_c.dylib)
==51151== by 0x1002BCF0A: fwrite (in /usr/lib/system/libsystem_c.dylib)
==51151== by 0x100028D29: std::__1::__stdoutbuf<char>::overflow(int) (in /usr/lib/libc++.1.dylib)
==51151== by 0x10001E91C: std::__1::basic_streambuf<char, std::__1::char_traits<char> >::xsputn(char const*, long) (in /usr/lib/libc++.1.dylib)
==51151== by 0x100001BBD: std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> > std::__1::__pad_and_output<char, std::__1::char_traits<char> >(std::__1::ostreambuf_iterator<char, std::__1::char_traits<char> >, char const*, char const*, char const*, std::__1::ios_base&, char) (in ./helloWorldPlusPlus)
==51151== by 0x1000015F6: std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::__put_character_sequence<char, std::__1::char_traits<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*, unsigned long) (in ./helloWorldPlusPlus)
==51151== by 0x1000011F1: std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<< <char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) (in ./helloWorldPlusPlus)
==51151== by 0x100000F6C: main (in ./helloWorldPlusPlus)
==51151==
…
followed by the expected leak detection, 24 bytes.
Is this a real issue in libc++ / libsystem, or just a bug in valgrind trunk?
-Pauley
|
|
From: <sv...@va...> - 2015-08-25 13:07:50
|
Author: mjw
Date: Tue Aug 25 14:07:42 2015
New Revision: 15589
Log:
Add safe-pthread.h to helgrind/tests/Makefile.am noinst_HEADERS.
Otherwise the header file won't show up in the dist tar ball.
Modified:
trunk/helgrind/tests/Makefile.am
Modified: trunk/helgrind/tests/Makefile.am
==============================================================================
--- trunk/helgrind/tests/Makefile.am (original)
+++ trunk/helgrind/tests/Makefile.am Tue Aug 25 14:07:42 2015
@@ -115,6 +115,9 @@
tls_threads.vgtest tls_threads.stdout.exp \
tls_threads.stderr.exp
+# Wrapper header used by some check programs.
+noinst_HEADERS = safe-pthread.h
+
# XXX: tc18_semabuse uses operations that are unsupported on Darwin. It
# should be conditionally compiled like tc20_verifywrap is.
check_PROGRAMS = \
|
|
From: Mark W. <mj...@re...> - 2015-08-25 09:34:50
|
Hi Philippe, On Mon, 2015-08-24 at 11:14 +0200, Mark Wielaard wrote: > I did notice we have several vgdb test failures because newer GDB will > warn of the remove gdbserver doesn't support the new vfile support (host > I/O packets): "warning: remote target does not support file transfer, > attempting to access files from local filesystem." > https://sourceware.org/gdb/onlinedocs/gdb/Host-I_002fO-Packets.html > Do you think it makes sense (is it easy?) to implement that, or should > we just "set sysroot /" or filter out the warning in our testsuite? So simply filtering out the warning like: Index: gdbserver_tests/filter_stderr =================================================================== --- gdbserver_tests/filter_stderr (revision 15586) +++ gdbserver_tests/filter_stderr (working copy) @@ -10,4 +10,5 @@ -e '/\/path\/to\/gdb/d' \ -e '/and then give GDB the following command/d' \ -e '/target remote |/d' \ - -e '/pid is optional if only one valgrind process is running/d' + -e '/pid is optional if only one valgrind process is running/d' \ + -e '/warning: remote target does not support file transfer, attempting to access files from local filesystem./d' Makes all gdbserver_tests PASS again, except one gdbserver_tests/hgtls. But that seems an unrelated issue. Shall we just go with a filter, or do you want to look into supporting file transfers in vgdb first? Thanks, Mark |
|
From: Mark W. <mj...@re...> - 2015-08-24 20:19:10
|
I hoped to fix the SIGABRT issue with tc18 and tc20 for sem_post in a similar way. See attached. It does "fix" the tc18 case, but not the tc20 case. Since hellgrind doesn't actually see the failure now it doesn't report anything. Which works for tc18 since there is an alternate exp file with that result (silent bad sem_post), but tc20 doesn't have an alternative where there is no EINVAL so it still reports an error. But at least not an abort, but a missing EINVAL. I do think glibc not detecting a bad semaphore might be allowed, so maybe we could just add an alternative tc20.exp that just doesn't see the EINVAL. Or would that be too much "cheating"? Cheers, Mark |
|
From: Matthias S. <zz...@ge...> - 2015-08-24 19:39:45
|
Hi! Will this patch or at least this idea be considered for commiting? This makes diagnosis of valgrind/client app abnormal exits a lot simpler. Especially in automated valgrind execution. Regards Matthias |
|
From: <sv...@va...> - 2015-08-24 19:27:03
|
Author: tom
Date: Mon Aug 24 20:26:56 2015
New Revision: 15588
Log:
Use sigjmp_buf
Modified:
trunk/helgrind/tests/safe-pthread.h
Modified: trunk/helgrind/tests/safe-pthread.h
==============================================================================
--- trunk/helgrind/tests/safe-pthread.h (original)
+++ trunk/helgrind/tests/safe-pthread.h Mon Aug 24 20:26:56 2015
@@ -4,7 +4,7 @@
#include <errno.h>
#include <assert.h>
-static jmp_buf env;
+static sigjmp_buf env;
/*
* Starting with glibc 2.20 some pthread calls may execute
|
|
From: Tom H. <to...@co...> - 2015-08-24 19:11:24
|
On 24/08/15 19:28, Matthias Schwarzott wrote: > Am 23.08.2015 um 11:13 schrieb Tom Hughes: > >> Can you try changing setjmp to sigsetjmp (with a non-zero second >> argument) and longjmp to siglongjmp, and see if that helps? >> > Yes, that fixes the issue. Thanks for confirming that. Committed as r15587. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: <sv...@va...> - 2015-08-24 19:10:13
|
Author: tom
Date: Mon Aug 24 20:10:06 2015
New Revision: 15587
Log:
Restore signal masks when recovering from xend related signals
Modified:
trunk/helgrind/tests/safe-pthread.h
Modified: trunk/helgrind/tests/safe-pthread.h
==============================================================================
--- trunk/helgrind/tests/safe-pthread.h (original)
+++ trunk/helgrind/tests/safe-pthread.h Mon Aug 24 20:10:06 2015
@@ -15,7 +15,7 @@
static void sigill_handler( int signum, siginfo_t *siginfo, void *sigcontext ) {
unsigned char *pc = siginfo->si_addr;
assert( pc[0] == 0x0f && pc[1] == 0x01 && pc[2] == 0xd5 );
- longjmp( env, EPERM );
+ siglongjmp( env, EPERM );
}
/*
@@ -25,7 +25,7 @@
* just zero, so we cannot add an assert/sanity check.
*/
static void segv_handler( int signum, siginfo_t *siginfo, void *sigcontext ) {
- longjmp( env, EPERM );
+ siglongjmp( env, EPERM );
}
/*
@@ -54,7 +54,7 @@
sigaction( SIGSEGV, &sa_segv, &oldsa_segv );
- if ( ( r = setjmp( env ) ) == 0 ) {
+ if ( ( r = sigsetjmp( env, 1 ) ) == 0 ) {
r = pthread_rwlock_unlock( rwlock );
} else {
r = 0;
|
|
From: Matthias S. <zz...@ge...> - 2015-08-24 18:28:54
|
Am 23.08.2015 um 11:13 schrieb Tom Hughes: > On 22/08/15 06:51, Matthias Schwarzott wrote: >> Am 22.08.2015 um 01:02 schrieb Tom Hughes: >> >>> There shouldn't be a second SIGILL signal. >> >> For me tc20_verifywrap.c triggers SIGILL in three locations: >> * tc20_verifywrap.c:189 (pthread_rwlock_unlock after init) >> * tc20_verifywrap.c:206 (double pthread_rwlock_unlock) >> * tc20_verifywrap.c:227 (three pthread_rwlock_unlock after two >> pthread_rwlock_rdlock) >> >> So technically there should be three SIGILL signals. > > Yes but each one is from a separate call to pthread_rwlock_unlock that > installs the signal handler before it starts and removes it afterwards. > > So there is no question of SA_NODEFER being needed because we are not > getting a SIGLLL while still handling the previous one. We are getting > one, handling it, then getting a second one, handling it, and then > getting a thired one. > >>> When SIGILL is caught we jump >>> out and restore the original handler. >> Yes, but we do not restore the signal mask. And if SA_NODEFER is not >> set, the signal will stay blocked afterwards. And we also do not call >> sigmask/sigblock/sigsetmask. >> >> From man sigaction: >> sa_mask specifies a mask of signals which should be blocked >> (i.e., added to the signal mask of the thread in which the signal >> handler >> is invoked) during execution of the signal handler. In >> addition, the signal which triggered the handler will be blocked, >> unless the >> SA_NODEFER flag is used. > > That mask is only applied while the signal is being handled though, and > should be removed afterwards. > > I have to admit that I'm not quite sure how (or if?) that happens when > you jump out of the handler... So maybe that is the real problem here in > which case the correct solution is likely sigsetjmp/siglongjmp. I think it just does not happen. Normally the return address of the signal handler points to a signal trampoline that cleans up and then calls sigreturn. This function restores the signal mask. Calling longjmp out of the signal handler skips this cleanup part. > > The trouble is that the current solution somehow seems to work for me in > that tc20 survives all three unlocks and then hits the abort. > Hmm, I have no clue. > Can you try changing setjmp to sigsetjmp (with a non-zero second > argument) and longjmp to siglongjmp, and see if that helps? > Yes, that fixes the issue. Regards Matthias |
|
From: Mark W. <mj...@re...> - 2015-08-24 09:15:07
|
On Sat, 2015-08-22 at 00:02 +0200, Philippe Waroquiers wrote: > On Fri, 2015-08-21 at 12:24 +0200, Julian Seward wrote: > > I would like to change the default value for the --partial-loads-ok flag > > so that it is =yes on all targets. Currently it defaults to =yes on OS X > > targets only, and =no on all other targets. > > > > The flag changes the way Memcheck handles loads that are word-sized or > > larger, are naturally aligned, and overlap the end of a heap allocated > > block (typically). Originally, Memcheck would complain about the > > invalid access (due to overlapping the end of the block). But as > > compilers and handwritten assembly have become more agressive about > > vectorization, more and more of these loads show up. They can't cause > > any faults, so the code is correct, but Memcheck complains nonetheless. > > > > Setting the value to =yes causes Memcheck not to complain about the > > invalid access, but to mark the part of the loaded data from the > > "inaccessible" area as undefined. So if it really gets used, Memcheck > > will still complain, but this time, validly. > > > > So I propose to change it to =yes for all targets for 3.11. > Looks reasonable to me. > > Maybe we could change some other clo defaults ? > > I am thinking a.o. to 2 candidates: > > * Change --leak-check-heuristics=none to --leak-check-heuristics=all > This avoids false possibly lost in c++ code. > No memory or cpu impact (except neglectible cpu needed for heuristic > during leak search, when encountering a possibly leaked block). > > * Change --keep-stacktraces=alloc-then-free to alloc-and-free > This gives more information for writes to freed blocks, showing > also the stacktrace where the block was allocated. > Neglectible cpu impact. Memory impact is one word per client > allocated block. I think all three suggestions are good. If we flip these default in the first beta/rc for 3.11 we can ask people to give feedback on them (and see if there is too much performance impact) and then decide to keep them that way for the final release. > Otherwise, for 3.11, I have on my todo list the following things: > 1. run valgrind under valgrind (memcheck) to search for leaks or other > errors inside valgrind itself. > > 2. investigate the shell_script exec test that causes gdbserver to be > closed twice (reported by Florian). Nothing serious, but it is not > supposed to happen. I have now packaged current svn for fedora rawhide and running it on all arches to look for testsuite issues. See the build.logs for armv7hl, i686 and x86_64 here: http://koji.fedoraproject.org/koji/buildinfo?buildID=678051 (ppc64, ppc64le, aarch64 and s390x are still pending) I did notice we have several vgdb test failures because newer GDB will warn of the remove gdbserver doesn't support the new vfile support (host I/O packets): "warning: remote target does not support file transfer, attempting to access files from local filesystem." https://sourceware.org/gdb/onlinedocs/gdb/Host-I_002fO-Packets.html Do you think it makes sense (is it easy?) to implement that, or should we just "set sysroot /" or filter out the warning in our testsuite? Cheers, Mark |
|
From: <sv...@va...> - 2015-08-23 16:58:03
|
Author: philippe
Date: Sun Aug 23 17:57:55 2015
New Revision: 15586
Log:
Use memset + assign to VgdbShared, to avoid memcheck warning that
uninit holes bytes are written to the shared file.
Modified:
trunk/coregrind/m_gdbserver/remote-utils.c
Modified: trunk/coregrind/m_gdbserver/remote-utils.c
==============================================================================
--- trunk/coregrind/m_gdbserver/remote-utils.c (original)
+++ trunk/coregrind/m_gdbserver/remote-utils.c Sun Aug 23 17:57:55 2015
@@ -310,17 +310,20 @@
{
const HChar *user, *host;
int len;
- VgdbShared vgdbinit =
+ VgdbShared vgdbinit;
+ const int pid = VG_(getpid)();
+ Addr addr_shared;
+ SysRes o;
+ int shared_mem_fd = INVALID_DESCRIPTOR;
+
+ VG_(memset) (&vgdbinit, 0, sizeof (VgdbShared));
+ vgdbinit = (VgdbShared)
{0, 0, (Addr) VG_(invoke_gdbserver),
(Addr) VG_(threads), VG_N_THREADS, sizeof(ThreadState),
offsetof(ThreadState, status),
offsetof(ThreadState, os_state) + offsetof(ThreadOSstate, lwpid),
0};
- const int pid = VG_(getpid)();
- Addr addr_shared;
- SysRes o;
- int shared_mem_fd = INVALID_DESCRIPTOR;
-
+
user = VG_(getenv)("LOGNAME");
if (user == NULL) user = VG_(getenv)("USER");
if (user == NULL) user = "???";
|
|
From: <sv...@va...> - 2015-08-23 14:37:54
|
Author: rhyskidd
Date: Sun Aug 23 15:37:47 2015
New Revision: 15585
Log:
docs: env variable handling behaviour consistent between OS X and Linux, thus remove redundant comment and #ifdef. n-i-bz.
Modified:
trunk/coregrind/m_libcproc.c
trunk/docs/internals/Darwin-notes.txt
Modified: trunk/coregrind/m_libcproc.c
==============================================================================
--- trunk/coregrind/m_libcproc.c (original)
+++ trunk/coregrind/m_libcproc.c Sun Aug 23 15:37:47 2015
@@ -230,14 +230,6 @@
void VG_(env_remove_valgrind_env_stuff)(HChar** envp, Bool ro_strings,
void (*free_fn) (void *) )
{
-
-#if defined(VGO_darwin)
-
- // Environment cleanup is also handled during parent launch
- // in vg_preloaded.c:vg_cleanup_env().
-
-#endif
-
Int i;
HChar* ld_preload_str = NULL;
HChar* ld_library_path_str = NULL;
Modified: trunk/docs/internals/Darwin-notes.txt
==============================================================================
--- trunk/docs/internals/Darwin-notes.txt (original)
+++ trunk/docs/internals/Darwin-notes.txt Sun Aug 23 15:37:47 2015
@@ -69,13 +69,6 @@
- PRE(sys_posix_spawn) completely ignores signal issues, and
also ignores the file_actions argument
-* env var handling w/ exec on Darwin: is there something odd? Compare
- "valgrind env" on Darwin and Linux. On the former there are
- settings VALGRIND_LIB and VALGRIND_LIB_INNER, but not for the
- former.
- There's a suspicious-looking "#if defined(VGO_darwin)" in
- VG_(env_remove_valgrind_env_stuff). Maybe related?
-
* Cleanups: sort wrappers in syswrap-darwin.c and priv_syswrap-darwin.h
alphabetically. Also, some aren't properly implemented -- check and
print warnings
|
|
From: Tom H. <to...@co...> - 2015-08-23 09:13:53
|
On 22/08/15 06:51, Matthias Schwarzott wrote: > Am 22.08.2015 um 01:02 schrieb Tom Hughes: > >> There shouldn't be a second SIGILL signal. > > For me tc20_verifywrap.c triggers SIGILL in three locations: > * tc20_verifywrap.c:189 (pthread_rwlock_unlock after init) > * tc20_verifywrap.c:206 (double pthread_rwlock_unlock) > * tc20_verifywrap.c:227 (three pthread_rwlock_unlock after two > pthread_rwlock_rdlock) > > So technically there should be three SIGILL signals. Yes but each one is from a separate call to pthread_rwlock_unlock that installs the signal handler before it starts and removes it afterwards. So there is no question of SA_NODEFER being needed because we are not getting a SIGLLL while still handling the previous one. We are getting one, handling it, then getting a second one, handling it, and then getting a thired one. >> When SIGILL is caught we jump >> out and restore the original handler. > Yes, but we do not restore the signal mask. And if SA_NODEFER is not > set, the signal will stay blocked afterwards. And we also do not call > sigmask/sigblock/sigsetmask. > > From man sigaction: > sa_mask specifies a mask of signals which should be blocked > (i.e., added to the signal mask of the thread in which the signal handler > is invoked) during execution of the signal handler. In > addition, the signal which triggered the handler will be blocked, unless the > SA_NODEFER flag is used. That mask is only applied while the signal is being handled though, and should be removed afterwards. I have to admit that I'm not quite sure how (or if?) that happens when you jump out of the handler... So maybe that is the real problem here in which case the correct solution is likely sigsetjmp/siglongjmp. The trouble is that the current solution somehow seems to work for me in that tc20 survives all three unlocks and then hits the abort. Can you try changing setjmp to sigsetjmp (with a non-zero second argument) and longjmp to siglongjmp, and see if that helps? Tom -- Tom Hughes (to...@co...) http://compton.nu/ |