|
From: Julian S. <js...@ac...> - 2011-04-20 10:13:13
|
Greetings.
It's time to think a bit about a 3.7.0 release. The following are
proposals, for contemplation/discussion.
I'd propose a release at end July or some time in August. That would
put it approximately 10 months after 3.6.0. In the past the gap
between releases has become IMO too long, so I'd like to ship 3.7.0
sooner rather than leave it late in the year.
Pretty definite to go in is:
* support for Fedora 15, Ubuntu 11.04, gcc 4.6, LLVM 2.9 [bug 242137,
unresolved, apparently line numbers don't work], Xcode 4.0.x [bug
267997, complete, but needs more testing]. General help in
testing/verifying these is required -- there's no way I can properly
test all this stuff myself.
* s390x port [bug 243404, completed, misc tidyup patches in progress]
* initial support for Power7 instructions [bug 267630, in progress]
* merge the HGDEV2 branch -- scalability and feature improvements for
Helgrind [no bug number]
* gdbserver integration [bug 214909, in progress]
* remove the AIX port. It has not been buildable since 3.4.1 and is
badly bit-rotted
* reduce the scope of exp-ptrcheck by removing the heap checks,
leaving just the stack and global array checking. The heap checking
was expensive, sometimes had a high false positive level, and
Memcheck does a better job 99%+ of the time. But the stack and
global checks are marginally useful. As a result, rename it to
"exp-sgcheck" ("sg" == stack and global)
More speculative:
* Alon Zakai's massdiff (Massif heap-snapshot differencing) patch [bug
269067]. I'd like this to be included, in some form -- the ability
to difference heap snapshots is very useful.
* Support for Android? [bug 266035] There appear to be increasing
requests for this. I have no idea of the state of the patchset on
266035. If it works well and is low-ish risk then maybe it should
be integrated for 3.7.0. If you care about Android support, please
try this out and give feedback.
* AVX (256-bit vector instructions) support for x86_64. AVX is a
massive bundle of stuff, and getting this completed in the next
three months strikes me as close to impossible. It might be
possible to get the basic infrastructure in place, though (VEX
prefix decoding, basic 256-bit vector stuff in IR and in the x86_64
backend, etc).
It also seems fairly low priority to me. AFAICS we have no bug
reports about non-support of AVX so far. Even the uptake of SSE4.x
was surprisingly slow.
* change of backtrace format? For years we've had code addresses
in backtraces. They use up valuable screen space, but 99% of the
time are completely useless. Should we omit them by default,
as does the TSan tool?
eg
Invalid write of size 1
at 0x400544: ddd (errs1.c:7)
by 0x400550: ccc (errs1.c:8)
by 0x40055B: bbb (errs1.c:9)
by 0x400566: aaa (errs1.c:10)
by 0x4005AE: main (errs1.c:17)
vs
Invalid write of size 1
#0 ddd (errs1.c:7)
#1 ccc (errs1.c:8)
#2 bbb (errs1.c:9)
#3 aaa (errs1.c:10)
#4 main (errs1.c:17)
Other stuff that I forgot / missed?
|
|
From: Tom H. <to...@co...> - 2011-04-20 11:17:30
|
On 20/04/11 11:12, Julian Seward wrote: > * change of backtrace format? For years we've had code addresses > in backtraces. They use up valuable screen space, but 99% of the > time are completely useless. Should we omit them by default, > as does the TSan tool? > eg > Invalid write of size 1 > at 0x400544: ddd (errs1.c:7) > by 0x400550: ccc (errs1.c:8) > by 0x40055B: bbb (errs1.c:9) > by 0x400566: aaa (errs1.c:10) > by 0x4005AE: main (errs1.c:17) > vs > Invalid write of size 1 > #0 ddd (errs1.c:7) > #1 ccc (errs1.c:8) > #2 bbb (errs1.c:9) > #3 aaa (errs1.c:10) > #4 main (errs1.c:17) I agree that the address is generally not useful, except I would say in the case of the first frame, where it gives you the address of the exact instruction which triggered the report. Maybe we could capture that on the first line, something like: Invalid write of size 1 at 0x400544 and then drop the addresses from the stack trace. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Alexander P. <gl...@go...> - 2011-04-20 14:21:27
|
Spending much time on debugging the reports from the TSan tool I would
suggest not to remove the addresses.
You don't need those while you have the debug info, but if you don't,
you'll have to re-run the program with the --show-pc=yes option in
order to debug a newly appeared report (the old and known ones are
already suppressed, aren't they?).
Maybe just move the address to the end of line? Like this:
Invalid write of size 1
at ddd (errs1.c:7), pc=0x400544
by ccc (errs1.c:8), pc=0x400550
by bbb (errs1.c:9), pc=0x40055B
Alex
On Wed, Apr 20, 2011 at 3:17 PM, Tom Hughes <to...@co...> wrote:
> On 20/04/11 11:12, Julian Seward wrote:
>
>> * change of backtrace format? For years we've had code addresses
>> in backtraces. They use up valuable screen space, but 99% of the
>> time are completely useless. Should we omit them by default,
>> as does the TSan tool?
>> eg
>> Invalid write of size 1
>> at 0x400544: ddd (errs1.c:7)
>> by 0x400550: ccc (errs1.c:8)
>> by 0x40055B: bbb (errs1.c:9)
>> by 0x400566: aaa (errs1.c:10)
>> by 0x4005AE: main (errs1.c:17)
>> vs
>> Invalid write of size 1
>> #0 ddd (errs1.c:7)
>> #1 ccc (errs1.c:8)
>> #2 bbb (errs1.c:9)
>> #3 aaa (errs1.c:10)
>> #4 main (errs1.c:17)
>
> I agree that the address is generally not useful, except I would say in
> the case of the first frame, where it gives you the address of the exact
> instruction which triggered the report.
>
> Maybe we could capture that on the first line, something like:
>
> Invalid write of size 1 at 0x400544
>
> and then drop the addresses from the stack trace.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
--
Alexander Potapenko
Software Engineer
Google Moscow
|
|
From: John R. <jr...@bi...> - 2011-04-20 15:00:45
|
On 04/20/2011 07:21 AM, Alexander Potapenko wrote: > Spending much time on debugging the reports from the TSan tool I would > suggest not to remove the addresses. > You don't need those while you have the debug info, In practice, line numbers are not precise enough. The same line often maps to many different and non-consecutive PCs, and consecutive PCs often map to non-consecutive lines. Debugging often involves mental "backward execution". Not having the correct PC as a starting point makes it much harder than necessary. but if you don't, > you'll have to re-run the program with the --show-pc=yes option in > order to debug a newly appeared report (the old and known ones are > already suppressed, aren't they?). > Maybe just move the address to the end of line? Like this: > > Invalid write of size 1 > at ddd (errs1.c:7), pc=0x400544 > by ccc (errs1.c:8), pc=0x400550 > by bbb (errs1.c:9), pc=0x40055B Fields that have an almost-fixed width should have a preference for the fixed side [the left side] of a line, so that columnar organization tends to be evident and usable. The width of the PC is nearly fixed, while the width of the source designator is much more variable. The above example, with only one filename, and with line numbers having the same floor(log10(__LINE__)), is not typical. -- |
|
From: Konstantin S. <kon...@gm...> - 2011-04-20 18:13:17
|
I would implement an option to enable/disable addresses (--show-pc=no/yes). As for the default value -- I don't know. (TSan's default is no, but I myself suffer from it periodically). --kcc On Wed, Apr 20, 2011 at 6:21 PM, Alexander Potapenko <gl...@go...>wrote: > Spending much time on debugging the reports from the TSan tool I would > suggest not to remove the addresses. > You don't need those while you have the debug info, but if you don't, > you'll have to re-run the program with the --show-pc=yes option in > order to debug a newly appeared report (the old and known ones are > already suppressed, aren't they?). > Maybe just move the address to the end of line? Like this: > > Invalid write of size 1 > at ddd (errs1.c:7), pc=0x400544 > by ccc (errs1.c:8), pc=0x400550 > by bbb (errs1.c:9), pc=0x40055B > > > Alex > > On Wed, Apr 20, 2011 at 3:17 PM, Tom Hughes <to...@co...> wrote: > > On 20/04/11 11:12, Julian Seward wrote: > > > >> * change of backtrace format? For years we've had code addresses > >> in backtraces. They use up valuable screen space, but 99% of the > >> time are completely useless. Should we omit them by default, > >> as does the TSan tool? > >> eg > >> Invalid write of size 1 > >> at 0x400544: ddd (errs1.c:7) > >> by 0x400550: ccc (errs1.c:8) > >> by 0x40055B: bbb (errs1.c:9) > >> by 0x400566: aaa (errs1.c:10) > >> by 0x4005AE: main (errs1.c:17) > >> vs > >> Invalid write of size 1 > >> #0 ddd (errs1.c:7) > >> #1 ccc (errs1.c:8) > >> #2 bbb (errs1.c:9) > >> #3 aaa (errs1.c:10) > >> #4 main (errs1.c:17) > > > > I agree that the address is generally not useful, except I would say in > > the case of the first frame, where it gives you the address of the exact > > instruction which triggered the report. > > > > Maybe we could capture that on the first line, something like: > > > > Invalid write of size 1 at 0x400544 > > > > and then drop the addresses from the stack trace. > > > > Tom > > > > -- > > Tom Hughes (to...@co...) > > http://compton.nu/ > > > > > ------------------------------------------------------------------------------ > > Benefiting from Server Virtualization: Beyond Initial Workload > > Consolidation -- Increasing the use of server virtualization is a top > > priority.Virtualization can reduce costs, simplify management, and > improve > > application availability and disaster protection. Learn more about > boosting > > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > > > -- > Alexander Potapenko > Software Engineer > Google Moscow > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Michael S. <ms...@ap...> - 2011-04-20 15:53:04
|
Or only show the address when line number information is not available? On Apr 20, 2011, at 7:21 AM, Alexander Potapenko wrote: > Spending much time on debugging the reports from the TSan tool I would > suggest not to remove the addresses. > You don't need those while you have the debug info, but if you don't, > you'll have to re-run the program with the --show-pc=yes option in > order to debug a newly appeared report (the old and known ones are > already suppressed, aren't they?). > Maybe just move the address to the end of line? Like this: > > Invalid write of size 1 > at ddd (errs1.c:7), pc=0x400544 > by ccc (errs1.c:8), pc=0x400550 > by bbb (errs1.c:9), pc=0x40055B > > > Alex > > On Wed, Apr 20, 2011 at 3:17 PM, Tom Hughes <to...@co...> wrote: >> On 20/04/11 11:12, Julian Seward wrote: >> >>> * change of backtrace format? For years we've had code addresses >>> in backtraces. They use up valuable screen space, but 99% of the >>> time are completely useless. Should we omit them by default, >>> as does the TSan tool? >>> eg >>> Invalid write of size 1 >>> at 0x400544: ddd (errs1.c:7) >>> by 0x400550: ccc (errs1.c:8) >>> by 0x40055B: bbb (errs1.c:9) >>> by 0x400566: aaa (errs1.c:10) >>> by 0x4005AE: main (errs1.c:17) >>> vs >>> Invalid write of size 1 >>> #0 ddd (errs1.c:7) >>> #1 ccc (errs1.c:8) >>> #2 bbb (errs1.c:9) >>> #3 aaa (errs1.c:10) >>> #4 main (errs1.c:17) >> >> I agree that the address is generally not useful, except I would say in >> the case of the first frame, where it gives you the address of the exact >> instruction which triggered the report. >> >> Maybe we could capture that on the first line, something like: >> >> Invalid write of size 1 at 0x400544 >> >> and then drop the addresses from the stack trace. >> >> Tom >> >> -- >> Tom Hughes (to...@co...) >> http://compton.nu/ >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >> > > > > -- > Alexander Potapenko > Software Engineer > Google Moscow > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers __________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair |
|
From: John R. <jr...@bi...> - 2011-04-20 14:41:18
|
> It's time to think a bit about a 3.7.0 release. [snip] > Other stuff that I forgot / missed? https://bugs.kde.org/show_bug.cgi?id=250101 [contains patch] huge "free" memory usage due to m_mallocfree.c "superblocks fragmentation" Quadratic behavior should not be tolerated. -- |
|
From: Julian S. <js...@ac...> - 2011-04-26 09:05:11
|
On Wednesday, April 20, 2011, John Reiser wrote: > > It's time to think a bit about a 3.7.0 release. [snip] > > > > Other stuff that I forgot / missed? > > https://bugs.kde.org/show_bug.cgi?id=250101 [contains patch] > huge "free" memory usage due to m_mallocfree.c "superblocks > fragmentation" Quadratic behavior should not be tolerated. Will do. J |
|
From: Konstantin S. <kon...@gm...> - 2011-04-20 18:15:47
|
> > > * Support for Android? [bug 266035] There appear to be increasing > requests for this. I have no idea of the state of the patchset on > 266035. If it works well and is low-ish risk then maybe it should > be integrated for 3.7.0. If you care about Android support, please > try this out and give feedback. > > Evgeniy will update the bug very soon. He can run a hacked Memcheck and TSan on Android, but that's not as smooth as on x86/Linux yet :) --kcc |
|
From: Philippe W. <phi...@sk...> - 2011-04-20 20:12:10
|
I also support the statement that line numbers are often not precise enough. If there is a user demand for this (at work, nobody ever complained), then this should for sure not be hardcoded, i.e. this should be the addition of a command line option to disable showing the program counter. > On 04/20/2011 07:21 AM, Alexander Potapenko wrote: >> Spending much time on debugging the reports from the TSan tool I would >> suggest not to remove the addresses. >> You don't need those while you have the debug info, > > In practice, line numbers are not precise enough. The same line often > maps to many different and non-consecutive PCs, and consecutive PCs > often map to non-consecutive lines. Debugging often involves mental > "backward execution". Not having the correct PC as a starting point > makes it much harder than necessary. |
|
From: Julian S. <js...@ac...> - 2011-04-26 09:04:20
|
On Wednesday, April 20, 2011, Philippe Waroquiers wrote: > I also support the statement that line numbers are often not precise > enough. [...] ok .. I'll just forget about this. It's clear there are disadvantages in getting rid of the addresses. J > If there is a user demand for this (at work, nobody ever > complained), then this should for sure not be hardcoded, i.e. this should > be the addition of a command line option to disable showing the program > counter. > > > On 04/20/2011 07:21 AM, Alexander Potapenko wrote: > >> Spending much time on debugging the reports from the TSan tool I would > >> suggest not to remove the addresses. > >> You don't need those while you have the debug info, > > > > In practice, line numbers are not precise enough. The same line often > > maps to many different and non-consecutive PCs, and consecutive PCs > > often map to non-consecutive lines. Debugging often involves mental > > "backward execution". Not having the correct PC as a starting point > > makes it much harder than necessary. > > --------------------------------------------------------------------------- > --- Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Eric P. <eri...@or...> - 2011-04-21 07:26:51
|
Le 20/04/2011 12:12, Julian Seward a écrit : > Greetings. > > It's time to think a bit about a 3.7.0 release. The following are > proposals, for contemplation/discussion. > > [snip] > > Other stuff that I forgot / missed? I'd like to see the register support for x86_64 be merged into 3.7 A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams) |
|
From: Julian S. <js...@ac...> - 2011-04-26 09:17:31
|
On Thursday, April 21, 2011, Eric Pouech wrote: > Le 20/04/2011 12:12, Julian Seward a écrit : > > Greetings. > > > > It's time to think a bit about a 3.7.0 release. The following are > > proposals, for contemplation/discussion. > > > > [snip] > > > > Other stuff that I forgot / missed? > > I'd like to see the register support for x86_64 be merged into 3.7 > A+ FTR, this is bug 253657 (https://bugs.kde.org/show_bug.cgi?id=253657) J |
|
From: Robert W. <rj...@du...> - 2011-04-26 18:18:52
|
I just filed this: https://bugs.kde.org/show_bug.cgi?id=271799 This is a problem on Darwin: ioctls that don't take an arg (e.g. TIOCSCTTY) are performing a validity check on the non-existent arg anyway. The attached patch fixes the problem and also adds support for TIOCEXCL. Any chance we could get this in 3.7.0, too? Regards, Robert. On Tue, Apr 26, 2011 at 2:15 AM, Julian Seward <js...@ac...> wrote: > > On Thursday, April 21, 2011, Eric Pouech wrote: > > Le 20/04/2011 12:12, Julian Seward a écrit : > > > Greetings. > > > > > > It's time to think a bit about a 3.7.0 release. The following are > > > proposals, for contemplation/discussion. > > > > > > [snip] > > > > > > Other stuff that I forgot / missed? > > > > I'd like to see the register support for x86_64 be merged into 3.7 > > A+ > > FTR, this is bug 253657 (https://bugs.kde.org/show_bug.cgi?id=253657) > > J > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Florian K. <br...@ac...> - 2011-04-27 03:10:27
|
On 04/20/2011 06:12 AM, Julian Seward wrote: > > Greetings. > > It's time to think a bit about a 3.7.0 release. The following are > proposals, for contemplation/discussion. > [snip] > > Other stuff that I forgot / missed? > There were a few bug reports since 3.6.1 that we should take a look at and possibly fix, time permitting. I remember at least the following which are easy to reproduce and/or have testcases/patches: 269144 - missing "Bad option" error message V fails to complain about the invalid option syntax and silently does the wrong thing 267020 - hardwired directory name /tmp 270326 - valgrind segfault.. I'm going to triage these and perhaps some more that were opened since 3.6.1. Florian |
|
From: Manoj <man...@gm...> - 2011-04-27 03:38:05
|
Any plans to support MIPS in near future. TIA Manoj On Apr 27, 2011, at 8:40 AM, Florian Krohm <br...@ac...> wrote: > On 04/20/2011 06:12 AM, Julian Seward wrote: >> >> Greetings. >> >> It's time to think a bit about a 3.7.0 release. The following are >> proposals, for contemplation/discussion. >> > [snip] >> >> Other stuff that I forgot / missed? >> > > There were a few bug reports since 3.6.1 that we should take a look at > and possibly fix, time permitting. I remember at least the following > which are easy to reproduce and/or have testcases/patches: > > 269144 - missing "Bad option" error message > V fails to complain about the invalid option syntax and silently does > the wrong thing > > 267020 - hardwired directory name /tmp > > 270326 - valgrind segfault.. > > I'm going to triage these and perhaps some more that were opened since > 3.6.1. > > Florian > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Philippe W. <phi...@sk...> - 2011-05-01 12:16:39
|
> Greetings.
>
> It's time to think a bit about a 3.7.0 release. The following are
> proposals, for contemplation/discussion.
For 3.7.0, I work or can work or provide help on:
* (of course :) 214909 gdbserver integration (and the delta leak to follow)
I have just uploaded a new version (upgraded to last SVN + retested on many platforms)
* 250101 (quadratic memory usage for some realloc patterns of big blocks)
Some days ago, uploaded a new patch version updated to a recent SVN
Once this is integrated, if I have time, I might work on
250065 Handling large allocations
(I find this one important, as doing big alloc/free decreases significantly the
probability to find dangling references).
* 267925 laog data structure quadratic for a single sequence of lock
I have a working patch doing garbage collection of the laog data structure.
Good results obtained (i.e. helgrind now works on a big appl. at my work,
doing many locks. And it found some wrong lock ordering :).
However, I believe a simpler data structure might be possible, so will investigate
further before posting the patch.
I can't really help but a fix or integration of a patch would be nice for the following:
219156 Valgrind does not handle custom allocation functions
A patch is attached to this, to support tcmalloc. At work, we will very probably switch
to tcmalloc, so ...
271438 sse4-64.c does not compile on at least 2 distrib
This is quite annoying when trying to run the tests.
|
|
From: Nicholas N. <n.n...@gm...> - 2011-06-01 05:40:47
|
On Wed, Apr 20, 2011 at 8:12 PM, Julian Seward <js...@ac...> wrote: > > > * Alon Zakai's massdiff (Massif heap-snapshot differencing) patch [bug > 269067]. I'd like this to be included, in some form -- the ability > to difference heap snapshots is very useful. What I don't like about that script is that, IIRC, it operates on the output of ms_print, rather than the massif.out files. Also, the output is more verbose than I would like, though that's easier to fix. Also, is it a python script? Everything else we have is Perl... I guess that doesn't matter so much. Nick |