|
From: Julian S. <js...@ac...> - 2019-03-11 14:53:31
|
Greetings all. I'd like to propose a 3.15.0 release in just under a month from now, on 5 April. The last release, 3.14.0, was on 9 Oct 2018. In the past few years we've released pretty much once a year. That has the undesirable effect of making fixes and new features available only after a long wait. By contrast, making a release in early April means only a six-month interval, and would get useful changes to users and distro packagers sooner rather than later. Primarily these: * Support for Gcc 9. * Overhaul of the DHAT heap-usage profiler, including addition of a GUI. * Reduced Memcheck false-positive rates on amd64 (x86_64) and ppc64 targets. * Much improved s390x z13 support. * Reduced overhead for handling indirect branches in very large applications. * The usual stack of bug fixes. I've made a first pass through all bugs reported since 3.14.0. The results are in docs/internals/3_14_BUGSTATUS.txt. If there are any bugs in there (or even, not in there) that you think are important to fix for the release, please do mention them. I'll shortly send a second message listing the bugs I think are a priority. One thing that I'd like to ask at this point is: what level of support for Solaris should we say there is, in the release announcement? Now that we unfortunately no longer have a Solaris maintainer, I am concerned that could wind up shipping a non-working Solaris port. A similar question goes for the Mac OSX port, although there at least we have a maintainer. J |
|
From: Julian S. <js...@ac...> - 2019-03-11 15:03:23
|
> I'll shortly send a second message listing the bugs I think are a priority.
Please feel free to disagree and/or add other bugs. This is only my personal
prioritisation.
J
Higher prio (really should fix for 3.15.0)
404843 s390x: backtrace sometimes ends prematurely
405182 Valgrind fails to build with Clang
398183 (amd64) Vex errors with _mm256_shuffle_epi8/vpshufb
Potentially serious?
399287 (amd64) Illegal Instruction vcmptrueps
404272 vex amd64->IR: 0x66 0xF 0x38 0x23 0xC0 0xF3 (PMOVSXWD)
Should fix
400099 Memcheck produces truncated backtrace when len(argv + env) = 4096
Possible stack overrun problem; should investigate
n-i-bz (amd64) Support RDRAND/RDSEED ? We really should.
Medium prio (would be nice to fix for 3.15.0)
399355 Add callgrind_diff
400793 pthread_rwlock_timedwrlock false positive
Probably would be easy to fix, but requires testing
401284 False positive "Source and destination overlap in strncat"
possibly valid; possible off-by-one error in overlap checking?
405201 Incorrect size of struct vki_siginfo on 64-bit Linux architectures
400162 Patch: Guard against __GLIBC_PREREQ for musl libc
Looks like simple fix; should take
398870 (amd64) Please add support for instruction vcvtps2ph
400538 vex amd64->IR: 0x48 0xCF 0xF 0x1F 0x0 0xFF 0xD2 0xCC 0x90 0x55
Should fix (Wine/Windows)
401719 (x86) sterrror_r on i686 causes a GPF
32-bit segreg problem; maybe we should fix?
n-i-bz (amd64) Support RDPMC ?
n-i-bz Improve PDB reading ? I thought I saw some patches for this ..
is it 253657 ? Who can help test this?
|
|
From: Austin E. <aus...@gm...> - 2019-03-11 15:27:37
|
On Mon, Mar 11, 2019 at 4:03 PM Julian Seward <js...@ac...> wrote: > n-i-bz Improve PDB reading ? I thought I saw some patches for this .. > is it 253657 ? Who can help test this? > I saw the patch, but haven't had a good opportunity to test (currently traveling). If me testing it will help it get in, I can probably make time this week or next (I normally valgrind win32, not win64, so may need some time to test win64 first). -- -Austin GPG: 267B CC1F 053F 0749 (expires 2021/02/18) |
|
From: Olaf H. <ol...@ae...> - 2019-03-11 15:17:24
|
Am Mon, 11 Mar 2019 15:53:19 +0100 schrieb Julian Seward <js...@ac...>: > docs/internals/3_14_BUGSTATUS.txt Well, no mention of Xen in that file. How am I supposed to address bug#390553? Olaf |
|
From: Ivo R. <iv...@iv...> - 2019-03-11 15:26:38
|
> One thing that I'd like to ask at this point is: what level of support for > Solaris should we say there is, in the release announcement? Now that we > unfortunately no longer have a Solaris maintainer, I am concerned that could > wind up shipping a non-working Solaris port. A similar question goes for the > Mac OSX port, although there at least we have a maintainer. Hi Julian, I am no longer in a position to do any serious Solaris maintenance. I don't have resources and access to Solaris source code which is necessary to get a deep understanding of the underlying problems. One manifestation is a message received yesterday: it seems that new Solaris 11.4 does things differently than 11.3 did, at least in debug info area. Another manifestation is a lack of bugs opened against Solaris support in Valgrind in the past year ;-) So it would be fair to say that Solaris port is supported on a voluntary effort basis in general and Valgrind on Solaris 11.4 has not been tested. Anyway, future of Solaris is quite murky [1] (search for "11.4"). I'd like to hear of any (prospective) maintainers from illumos community as well [2]. Kind regards, Ivosh [1] https://en.wikipedia.org/wiki/Solaris_(operating_system) [2] https://illumos.topicbox.com/groups/discuss/T5f2d86b0b56e6f31-Mcede5f51be0764230a7f7310/illumos-valgrind-maintainer-needed |
|
From: Ed M. <em...@fr...> - 2019-03-15 19:12:05
|
On Mon, 11 Mar 2019 at 10:53, Julian Seward <js...@ac...> wrote: > > One thing that I'd like to ask at this point is: what level of support for > Solaris should we say there is, in the release announcement? Now that we > unfortunately no longer have a Solaris maintainer, I am concerned that could > wind up shipping a non-working Solaris port. A similar question goes for the > Mac OSX port, although there at least we have a maintainer. Speaking of ports - Apr 5 is definitely too soon to get the FreeBSD port into a state where it could be included in the release, but I think it is feasible for October. As has been the case for quite some time the port is basically usable but we (FreeBSD porters) have a bunch of work to do to triage and address test failures still. Can we work on a plan to upstream the port for the presumably-October release (assuming that tests are addressed)? |