|
From: Julian S. <js...@ac...> - 2004-08-22 20:55:50
|
Greetings all. Now seems like a good time to start a new 2.2.X branch, and emit 2.2.0. The reasons for doing so now are: * 2.0.0 is getting long in the tooth, yet people still tend to think of it as the use-by-default version, not unreasonably considering it is branded the 'stable' release. 2.1.2 is a big improvement on 2.0.0, yet many people won't get those improvements until they are released as 2.2.0. * There are some potentially destabilising changes coming up in the head, and it would be nice to ship something before then. So I propose create a new stable branch and release 2.2.0. I'd hope to do complete the process within a week. Comments? Are there any specific issues which should be addressed prior to 2.2.0 ? J |
|
From: Eric E. <eri...@fr...> - 2004-08-22 21:20:46
|
Julian Seward wrote: > So I propose create a new stable branch and release 2.2.0. > I'd hope to do complete the process within a week. > > Are there any specific issues which should be addressed prior > to 2.2.0 ? That's a good idea. I'm currently in active development mode on Valgui (yes, the obscure Qt frontend everybody may have thought was dead ;-). I expect to make an official pre-release within the next weeks, once I have finished the doc and fixed a few more bugs. The issue is that it still requires a patched version of Valgrind, and it may trouble users. I would be glad if we could consider the current patch for inclusion: http://eric.estievenart.free.fr/tmp/vg212.diff Which fixes: - the dwarf2 reading (source file names were not absolute) - a more complete output when --fmt=valgui is given - log of program exit status (needed to know when children have exited) I've used it intensively during the past months, and there seems to be no problem, but it is of course not to be added just one day before release, so a good week testing should be good. Any remarks welcome. Cheers -- Eric |
|
From: Tom H. <th...@cy...> - 2004-08-22 22:03:09
|
In message <412...@fr...>
Eric Estievenart <eri...@fr...> wrote:
> The issue is that it still requires a patched version of Valgrind,
> and it may trouble users.
> I would be glad if we could consider the current patch for inclusion:
> http://eric.estievenart.free.fr/tmp/vg212.diff
> Which fixes:
> - the dwarf2 reading (source file names were not absolute)
> - a more complete output when --fmt=valgui is given
> - log of program exit status (needed to know when children have exited)
I have to say that I don't like --fmt=valgui as an option.
The idea of a more machine readable output format is admirable, but
a more generalised name would be better I think. It may also be that
if the aim is for a machine readable output format you should go further
than just making the filenames absolute and go for something that is as
easy as possible for machines to parse.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Eric E. <eri...@fr...> - 2004-08-22 22:43:07
|
Tom Hughes wrote: > I have to say that I don't like --fmt=valgui as an option. > > The idea of a more machine readable output format is admirable, but > a more generalised name would be better I think. It may also be that > if the aim is for a machine readable output format you should go further > than just making the filenames absolute and go for something that is as > easy as possible for machines to parse. I completely agree, the option has been named to allow further extensions like --fmt=xxx where xxx could be anything else. (like txt for current 'short' format, html, xml, whatever people want). For now it was the shortest path, and I must confess that the complexity of parsing the output is one thing which has pained me a lot (and still does...). What I see as future requirements for output is: - typed output - extensible without needing to update the parsers - errors should contain attributes like severity - the parser must know immediately when an error block is finished - still permit to output using actual format (for other parsers) but of course this can't be done for 2.2.0 ! I would be glad to work on that, since it would greatly simplify my life :-) If you have a better name for that option, which suits every one, I can make update my patch against cvs head to reflect that. Cheers -- Eric PS: I thought you were an advocate of simple changes ;-) |
|
From: Tom H. <th...@cy...> - 2004-08-22 22:05:24
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> So I propose create a new stable branch and release 2.2.0.
> I'd hope to do complete the process within a week.
>
> Comments?
>
> Are there any specific issues which should be addressed prior
> to 2.2.0 ?
There's one issue that definitely needs to be addressed, which is
bug #85658 which has come up dozens of times now - just look at the
number of duplicates that have been attached to it.
I've got a patch for it - an early version is on the bug. One or
two people still seem to have problems but in general the patch seems
to fix it for most people so I'll commit it shortly.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bryan O'S. <bo...@se...> - 2004-08-23 03:43:23
|
On Sun, 2004-08-22 at 21:55 +0100, Julian Seward wrote: > Are there any specific issues which should be addressed prior > to 2.2.0 ? It would be very helpful to verify that bug 85658 (crash unless linked explicitly with libpthread) is really fixed, because it affects rather a lot of code. I'll check it today or tomorrow. <b |
|
From: Robert W. <rj...@du...> - 2004-08-23 05:04:17
|
> Are there any specific issues which should be addressed prior > to 2.2.0 ?=20 I have a patch at: http://www.durables.org/software/valgrind/06-amd64.diff which fixes a runtime problem on amd64 boxes. Jeremy and I were talking about this today: it does actually appear to fix the problem (Valgrind aborts early when running in 32-bit mode on amd64 boxes), and doesn't effect any of the tests on amd64 or x64 machines, so we were thinking that perhaps that should be included too? There's another possible solution to the problem, but we can implement that later if needs be - for the moment, this should be just fine. If everyone is OK with this, I can commit it tomorrow or Tuesday. Please let me know. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Nicholas N. <nj...@ca...> - 2004-08-23 08:14:10
|
On Sun, 22 Aug 2004, Robert Walsh wrote: > I have a patch at: > > http://www.durables.org/software/valgrind/06-amd64.diff > > which fixes a runtime problem on amd64 boxes. Jeremy and I were talking > about this today: it does actually appear to fix the problem (Valgrind > aborts early when running in 32-bit mode on amd64 boxes), and doesn't > effect any of the tests on amd64 or x64 machines, so we were thinking > that perhaps that should be included too? > > There's another possible solution to the problem, but we can implement > that later if needs be - for the moment, this should be just fine. > > If everyone is OK with this, I can commit it tomorrow or Tuesday. > Please let me know. I second this -- it's required to run 32-bit programs under Valgrind on x86-64. But can you please add a comment when you commit explaining that it means that VG_(valgrind_end) has a slightly different meaning to all the other VG_(*_end) vars -- ie. it names the last byte, whereas the others go one byte past the end. Thanks. N |
|
From: Robert W. <rj...@du...> - 2004-08-23 18:15:38
|
> > If everyone is OK with this, I can commit it tomorrow or Tuesday. > > Please let me know. >=20 > I second this -- it's required to run 32-bit programs under Valgrind on=20 > x86-64. >=20 > But can you please add a comment when you commit explaining that it means= =20 > that VG_(valgrind_end) has a slightly different meaning to all the other=20 > VG_(*_end) vars -- ie. it names the last byte, whereas the others go one=20 > byte past the end. Done. Comment added to check-in notice and code. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |