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
(11) |
2
(13) |
3
(7) |
|
4
(9) |
5
(23) |
6
(19) |
7
(18) |
8
(2) |
9
(7) |
10
(21) |
|
11
(13) |
12
|
13
(8) |
14
(17) |
15
(19) |
16
(25) |
17
(43) |
|
18
(22) |
19
(12) |
20
(19) |
21
(12) |
22
(9) |
23
(12) |
24
(5) |
|
25
(16) |
26
(25) |
27
(24) |
28
(19) |
29
(26) |
30
(25) |
31
(6) |
|
From: Julian S. <js...@ac...> - 2004-07-17 23:44:53
|
CVS commit by jseward:
Version wibble
M +3 -3 manual.html 1.49
--- valgrind/docs/manual.html #1.48:1.49
@@ -26,6 +26,6 @@
<a name="title"> </a>
-<h1 align=center>Valgrind, version 2.1.0</h1>
-<center>This manual was last updated on 21 January 2004</center>
+<h1 align=center>Valgrind, version 2.1.2</h1>
+<center>This manual was last updated on 18 July 2004</center>
<p>
@@ -33,5 +33,5 @@
<a href="mailto:js...@ac...">js...@ac...</a>,
<a href="mailto:nj...@ca...">nj...@ca...</a><br>
-Copyright © 2000-2003 Julian Seward, Nick Nethercote
+Copyright © 2000-2004 Julian Seward, Nick Nethercote
<p>
|
|
From: Julian S. <js...@ac...> - 2004-07-17 23:44:41
|
CVS commit by jseward:
Track bug resolutions which happened today.
M +12 -3 NEWS 1.21
--- valgrind/NEWS #1.20:1.21
@@ -31,7 +31,14 @@
8-byte aligned.
+81970 vg_alloc_ThreadState: no free slots available
+ (closed because the workaround is simple: increase
+ VG_N_THREADS, rebuild and try again.)
+
78514 Conditional jump or move depends on uninitialized value(s)
(a slight mishanding of FP code in memcheck)
+77952 pThread Support (crash) (due to initialisation-ordering probs)
+ (also 85118)
+
80942 Addrcheck wasn't doing overlap checking as it should.
78048 return NULL on malloc/new etc failure, instead of asserting
@@ -51,5 +58,8 @@
82999 show which cmdline option was erroneous (wishlist)
83040 make valgrind VPATH and distcheck-clean (wishlist)
-77952 pThread Support (crash) (due to initialisation-ordering probs)
+83998 Assertion `newfd > vgPlain_max_fd' failed (see below)
+82722 Unchecked mmap in as_pad leads to mysterious failures later
+78958 memcheck seg faults while running Mozilla
+
@@ -93,6 +103,5 @@
in the soft limit causing assertions when valgrind tries to allocate
descriptors from the reserved area.
- (This actually came from bug #83998 although we're still waiting
- on confirmation that the change actually fixed the bug.)
+ (This actually came from bug #83998).
* Major overhaul of Cachegrind implementation. Only user visible change
|
|
From: Julian S. <js...@ac...> - 2004-07-17 23:26:56
|
CVS commit by jseward:
Deltas from Jeremy.
M +5 -7 NEWS 1.20
--- valgrind/NEWS #1.19:1.20
@@ -21,11 +21,9 @@
76869 Crashes when running any tool under Fedora Core 2 test1
This fixes the problem with returning from a signal handler
- when VDSOs are turned off in FC2. Note that we don't
- (yet) support VDSOs being on
- (use "echo 0 > /proc/sys/kernel/vdso").
-
-69508 java 1.4.2 client fails with erroneous "stack size too small"
- (make more of the pthread stack attribute related functions
- work properly)
+ when VDSOs are turned off in FC2.
+
+69508 java 1.4.2 client fails with erroneous "stack size too small".
+ This fix makes more of the pthread stack attribute related
+ functions work properly. Java still doesn't work though.
71906 malloc alignment should be 8, not 4
|
|
From: Jeremy F. <je...@go...> - 2004-07-17 23:23:41
|
On Sat, 2004-07-17 at 14:19 +0200, Julian Seward wrote: > CVS commit by jseward: > > 2.1.2 is imminent. I've tried to find all the changes since 2.1.1 and > list them here. (Reading 4 months worth of commit logs is sooo > fascinating :-) Please let me know asap of anything I've forgotten or > been erroneous on. > > > M +104 -1 NEWS 1.17 > > > --- valgrind/NEWS #1.16:1.17 > @@ -1,6 +1,109 @@ > > +Unstable (cvs head) release 2.1.2 (18 July 2004) > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > +2.1.2 contains four months worth of bug fixes and refinements. > +Although officially an "unstable" release, we believe it to be stable > +enough for widespread day-to-day use. A large number of minor > +problems with 2.1.1 have been fixed, and so if you use 2.1.1 you > +should try 2.1.2. Users of the last stable release, 2.0.0, might also > +want to try this release. > + > + > +The following bugs, and probably many more, have been fixed. These > +are listed at http://bugs.kde.org. Reporting a bug for valgrind in > +the http://bugs.kde.org is much more likely to get you a fix than > +mailing developers directly, so please continue to keep sending bugs > +there. > + > +76869 Crashes when running any tool under Fedora Core 2 test1 > + This fixes the problem with returning from a signal handler > + when VDSOs are turned off in FC2. Note that we don't > + (yet) support VDSOs being on > + (use "echo 0 > /proc/sys/kernel/vdso"). Actually, I think VDSOs should work as well now. > +69508 java 1.4.2 client fails with erroneous "stack size too small" > + (make more of the pthread stack attribute related functions > + work properly) I think the pthread stack functions are there, but Java still doesn't run. J |
|
From: Julian S. <js...@ac...> - 2004-07-17 23:22:06
|
On Saturday 17 July 2004 15:16, Robert Walsh wrote: > On Sat, 2004-07-17 at 07:03, Julian Seward wrote: > > (This is probably a question for Jeremy really ...) > > Me, actually. I did those originally. Oh. Apologies Jeremy. > > I suspect that somehow gcc honours the weak attribute and > > so linking works out, throwing away duplicate appearances, > > whereas icc somehow does not. However, I wondered why > > these fns are defined in header files. Presumably there's > > something special about the arrangments which preclude > > putting the definitions in a .c file somewhere? > > Yeah - they use varargs, which doesn't work very well with preprocessor > macros and what I needed to do. I hate this hack anyway, so perhaps > it's time to rethink how these can be done. (If anyone has suggestions, > I'd love to hear them.) Putting "static" on those fns sorts it out (kludgily) and some other stuff is kludgable around too. However, Icc 8 doesn't seem to recognise __builtin_setjmp / __builtin_longjmp, which is (a) strange considering I'm sure I remember Icc 7 doing so, and (b) fatal, since the scheduler/dispatcher use them to catch exceptions in generated code. So that puts the tin hat on that one. Bah. J |
|
From: Jeremy F. <je...@go...> - 2004-07-17 23:19:32
|
On Sat, 2004-07-17 at 18:19 +0100, Nicholas Nethercote wrote: > The brk-limit returned by brk() (the kernel version, not the glibc > version) -- is that the last byte in the heap you can touch, or is it one > past the last byte? I looked in the kernel sources but couldn't work it > out. I think its the first inaccessible byte. J |
|
From: Jeremy F. <je...@go...> - 2004-07-17 23:15:23
|
On Fri, 2004-07-16 at 19:30 +0100, Nicholas Nethercote wrote: > (1) and (2) are better for 32-bit machines, where address space is > cramped, because direct mapping is an address space hog, and we only need > a 2-level table for 32-bit addresses. > > (3) is better for 64-bit machines because address space is plentiful and a > shadow chunk table is difficult to do well with 64-bit addresses. Um, 2 seems completely pointless to me, so I was only considering 1 and 3. We can get the kernel to do allocate-on-write by making the shadow segment mapped with PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE - the kernel will only allocate real pages once you write to it. The problem with this is that it allows a buggy Tool to use memory it wasn't expecting to or something. I think its valuable to make the skin explicitly allocate the address space in case 1. J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-17 17:22:35
|
On Sat, 17 Jul 2004, Julian Seward wrote: > 2.1.2 is imminent. When you do it, could you also please update the docs on the website? The 2.0.0 docs don't mention Massif at all. Thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-17 17:19:38
|
Hi, I'm looking at bug 79138... The brk-limit returned by brk() (the kernel version, not the glibc version) -- is that the last byte in the heap you can touch, or is it one past the last byte? I looked in the kernel sources but couldn't work it out. Thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-17 16:40:57
|
CVS commit by nethercote:
Add a bunch of asserts to check the results of calls to system malloc().
Assertions are arguably not the right thing here, but the practice is
widespread and we're not planning on making asserts optional, and it's a lot
better than no checking.
M +3 -0 ume.c 1.13
M +8 -0 vg_main.c 1.172
--- valgrind/coregrind/ume.c #1.12:1.13
@@ -245,4 +245,5 @@ struct elfinfo *readelf(int fd, const ch
int phsz;
+ assert(e);
e->fd = fd;
@@ -283,4 +284,5 @@ struct elfinfo *readelf(int fd, const ch
phsz = sizeof(ESZ(Phdr)) * e->e.e_phnum;
e->p = malloc(phsz);
+ assert(e->p);
if (pread(fd, e->p, phsz, e->e.e_phoff) != phsz) {
@@ -423,4 +425,5 @@ static int load_ELF(char *hdr, int len,
int baseaddr_set;
+ assert(buf);
pread(fd, buf, ph->p_filesz, ph->p_offset);
buf[ph->p_filesz] = '\0';
--- valgrind/coregrind/vg_main.c #1.171:1.172
@@ -654,4 +654,5 @@ static void augment_command_line(Int* vg
vg_argv = malloc( (vg_argc + env_arg_count + f1_arg_count
+ f2_arg_count + 2) * sizeof(char **));
+ vg_assert(vg_argv);
to = vg_argv;
@@ -712,4 +713,5 @@ static void get_command_line( int argc,
vg_argv = malloc(sizeof(char **) * (vg_argc + 1));
+ vg_assert(vg_argv);
cpp = vg_argv;
@@ -843,4 +845,5 @@ static char **fix_environment(char **ori
inject_path_len = sizeof(inject_so) + vgliblen + preloadlen + 16;
inject_path = malloc(inject_path_len);
+ vg_assert(inject_path);
if (preload)
@@ -858,4 +861,5 @@ static char **fix_environment(char **ori
/* Allocate a new space */
ret = malloc(sizeof(char *) * (envc+3+1)); /* 3 new entries + NULL */
+ vg_assert(ret);
/* copy it over */
@@ -876,4 +880,5 @@ static char **fix_environment(char **ori
int len = strlen(*cpp) + vgliblen*2 + 16;
char *cp = malloc(len);
+ vg_assert(cp);
snprintf(cp, len, "%s%s:%s",
@@ -888,4 +893,5 @@ static char **fix_environment(char **ori
int len = strlen(*cpp) + inject_path_len;
char *cp = malloc(len);
+ vg_assert(cp);
snprintf(cp, len, "%s%s:%s",
@@ -905,4 +911,5 @@ static char **fix_environment(char **ori
int len = ld_library_path_len + vgliblen*2 + 16;
char *cp = malloc(len);
+ vg_assert(cp);
snprintf(cp, len, "%s%s", ld_library_path, VG_(libdir));
@@ -914,4 +921,5 @@ static char **fix_environment(char **ori
int len = ld_preload_len + inject_path_len;
char *cp = malloc(len);
+ vg_assert(cp);
snprintf(cp, len, "%s%s",
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-17 16:18:05
|
On Sat, 17 Jul 2004, Tom Hughes wrote: >> ld's --wrap option is exactly what we want, I think. > > Except that would require the user to build their program using > that option if I'm reading the manual page correctly. Sorry, I should have been clearer: we want to do ourselves exactly what ld --wrap does. Ie. function replacement as we do now, but be able to call the original function within the replacement. N |
|
From: Tom H. <th...@cy...> - 2004-07-17 16:14:36
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Sat, 17 Jul 2004, Tom Hughes wrote:
>
> > Well we already have an interception system for doing full
> > replacement, what's missing is way of adding code while still
> > using the original function implementation - something like
> > the advice system in emacs lisp.
>
> ld's --wrap option is exactly what we want, I think.
Except that would require the user to build their program using
that option if I'm reading the manual page correctly.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-17 16:09:22
|
On Sat, 17 Jul 2004, Tom Hughes wrote: > Well we already have an interception system for doing full > replacement, what's missing is way of adding code while still > using the original function implementation - something like > the advice system in emacs lisp. ld's --wrap option is exactly what we want, I think. N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-17 16:08:13
|
On Sat, 17 Jul 2004, Robert Walsh wrote: > Yup. "At the start of this function, or at this address here, when this > condition is true, do this", where "do this" can be a bunch of different > things, including executing arbitrary code, etc. Neat. Would it give access to function arguments, or would you have to ferret around and get them yourself? N |
|
From: Tom H. <th...@cy...> - 2004-07-17 15:41:39
|
In message <109...@dr...>
Robert Walsh <rj...@du...> wrote:
> > What is code injection? It's not function wrapping, is it? Cos that
> > would be really cool to have.
>
> Yup. "At the start of this function, or at this address here, when this
> condition is true, do this", where "do this" can be a bunch of different
> things, including executing arbitrary code, etc. I haven't gotten very
> far yet, though. Too many other things to do, especially at work after
> coming back from a 3-week vacation. Sigh.
Can it manage doing things at the end of the function as well?
It sounds like what we need in order to continue tracking mutexes
and things if we dump our libpthread and use the glibc one.
> Might be a better way of doing library call interception.
Well we already have an interception system for doing full
replacement, what's missing is way of adding code while still
using the original function implementation - something like
the advice system in emacs lisp.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Robert W. <rj...@du...> - 2004-07-17 15:28:03
|
> > I'm doing some minor experimental stuff that isn't release-critical=20 > > (code injection being one of them.) >=20 > What is code injection? It's not function wrapping, is it? Cos that=20 > would be really cool to have. Yup. "At the start of this function, or at this address here, when this condition is true, do this", where "do this" can be a bunch of different things, including executing arbitrary code, etc. I haven't gotten very far yet, though. Too many other things to do, especially at work after coming back from a 3-week vacation. Sigh. Might be a better way of doing library call interception. 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-07-17 15:05:48
|
On Sat, 17 Jul 2004, Robert Walsh wrote: > I'm doing some minor experimental stuff that isn't release-critical > (code injection being one of them.) What is code injection? It's not function wrapping, is it? Cos that would be really cool to have. N |
|
From: Tom H. <th...@cy...> - 2004-07-17 14:28:03
|
In message <109...@dr...>
Robert Walsh <rj...@du...> wrote:
> On Sat, 2004-07-17 at 07:03, Julian Seward wrote:
>
> > I was trying to build with Icc 8 and got a bunch of link errors
> > concerning duplicate definitions of VALGRIND_PRINTF,
> > VALGRIND_PRINTF_BACKTRACE, VALGRIND_INTERNAL_PRINTF
> > and VALGRIND_INTERNAL_PRINTF_BACKTRACE. All 4 of these
> > are defined (not merely declared) in header files, and
> > all with the "weak" attribute.
> >
> > I suspect that somehow gcc honours the weak attribute and
> > so linking works out, throwing away duplicate appearances,
> > whereas icc somehow does not. However, I wondered why
> > these fns are defined in header files. Presumably there's
> > something special about the arrangments which preclude
> > putting the definitions in a .c file somewhere?
>
> Yeah - they use varargs, which doesn't work very well with preprocessor
> macros and what I needed to do. I hate this hack anyway, so perhaps
> it's time to rethink how these can be done. (If anyone has suggestions,
> I'd love to hear them.)
Wouldn't making them inline rather than weak have the desired effect?
Of course in C99 (and earlier in gcc) you can have varargs macros.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Robert W. <rj...@du...> - 2004-07-17 14:16:14
|
On Sat, 2004-07-17 at 07:03, Julian Seward wrote:=20 > (This is probably a question for Jeremy really ...) Me, actually. I did those originally. > I was trying to build with Icc 8 and got a bunch of link errors > concerning duplicate definitions of VALGRIND_PRINTF,=20 > VALGRIND_PRINTF_BACKTRACE, VALGRIND_INTERNAL_PRINTF > and VALGRIND_INTERNAL_PRINTF_BACKTRACE. All 4 of these > are defined (not merely declared) in header files, and > all with the "weak" attribute. >=20 > I suspect that somehow gcc honours the weak attribute and > so linking works out, throwing away duplicate appearances, > whereas icc somehow does not. However, I wondered why > these fns are defined in header files. Presumably there's > something special about the arrangments which preclude=20 > putting the definitions in a .c file somewhere? Yeah - they use varargs, which doesn't work very well with preprocessor macros and what I needed to do. I hate this hack anyway, so perhaps it's time to rethink how these can be done. (If anyone has suggestions, I'd love to hear them.) Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Tom H. <th...@cy...> - 2004-07-17 14:16:12
|
CVS commit by thughes:
Make the _dl_relocate_object suppressions more general so that they
work on more systems. The glibc 2.3 suppressions are already like this.
M +2 -6 glibc-2.2.supp 1.25
--- valgrind/glibc-2.2.supp #1.24:1.25
@@ -352,18 +352,14 @@
}
{
- _dl_relocate_object/dl_main/_dl_sysdep_start/_dl_start_final(Cond)
+ _dl_relocate_object/dl_main(Cond)
Memcheck:Cond
fun:_dl_relocate_object
fun:dl_main
- fun:_dl_sysdep_start
- fun:_dl_start_final
}
{
- _dl_relocate_object_internal/dl_main/_dl_sysdep_start/_dl_start_final(Cond)
+ _dl_relocate_object_internal/dl_main(Cond)
Memcheck:Cond
fun:_dl_relocate_object_internal
fun:dl_main
- fun:_dl_sysdep_start
- fun:_dl_start_final
}
|
|
From: Robert W. <rj...@du...> - 2004-07-17 14:10:26
|
> Greetings, all. I'm trying to get 2.1.2 out the door very shortly > (ideally this weekend). Does anyone have any outstanding changes > which need to go in before it ships? Nothing on this end. I'm doing some minor experimental stuff that isn't release-critical (code injection being one of them.) Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Julian S. <js...@ac...> - 2004-07-17 14:01:25
|
(This is probably a question for Jeremy really ...) I was trying to build with Icc 8 and got a bunch of link errors concerning duplicate definitions of VALGRIND_PRINTF, VALGRIND_PRINTF_BACKTRACE, VALGRIND_INTERNAL_PRINTF and VALGRIND_INTERNAL_PRINTF_BACKTRACE. All 4 of these are defined (not merely declared) in header files, and all with the "weak" attribute. I suspect that somehow gcc honours the weak attribute and so linking works out, throwing away duplicate appearances, whereas icc somehow does not. However, I wondered why these fns are defined in header files. Presumably there's something special about the arrangments which preclude putting the definitions in a .c file somewhere? Pls advise ... J |
|
From: Julian S. <js...@ac...> - 2004-07-17 13:41:18
|
> Can we use "developer release" or some other word that is less scary that > "unstable"? Some people see "unstable" and choose 2.0.0. And we don't > have any intention of doing a 2.0.1, right? Maybe say something like > "2.1.2 is good, try it first, although there is a chance it won't work so > then try 2.0.0 and tell us what went wrong." Although 2.1.2 fixes a lot > of problems present in 2.0.0... Good plan. Done. > I even thought calling this 2.2.0 stable could be good, since no really > big changes have gone into this (as opposed to 2.1.0 and 2.1.1 both of > which had big changes). But maybe the next release should be 2.2.0, just > to let things settle some more. I'd prefer to wait for this 2.1.2 to settle a bit more. Hopefully I should be able to get 2.1.3/2.2.0 more quickly than 2.1.2 followed 2.1.1. J |
|
From: Julian S. <js...@ac...> - 2004-07-17 13:38:21
|
CVS commit by jseward: Update preamble a la Nick's suggestions. Remove duplicate re SIOCGMIIPHY. Remove claim that it compiles with icc-8.0. It doesn't. (/me is confused; I thought relevant fixes had already been committed). M +17 -16 NEWS 1.19 --- valgrind/NEWS #1.18:1.19 @@ -1,12 +1,15 @@ -Unstable (cvs head) release 2.1.2 (18 July 2004) +Developer (cvs head) release 2.1.2 (18 July 2004) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2.1.2 contains four months worth of bug fixes and refinements. -Although officially an "unstable" release, we believe it to be stable -enough for widespread day-to-day use. A large number of minor -problems with 2.1.1 have been fixed, and so if you use 2.1.1 you -should try 2.1.2. Users of the last stable release, 2.0.0, might also -want to try this release. - +Although officially a developer release, we believe it to be stable +enough for widespread day-to-day use. 2.1.2 is pretty good, so try it +first, although there is a chance it won't work. If so then try 2.0.0 +and tell us what went wrong." 2.1.2 fixes a lot of problems present +in 2.0.0 and is generally a much better product. + +Relative to 2.1.1, a large number of minor problems with 2.1.1 have +been fixed, and so if you use 2.1.1 you should try 2.1.2. Users of +the last stable release, 2.0.0, might also want to try this release. The following bugs, and probably many more, have been fixed. These @@ -62,4 +65,7 @@ memory when using memcheck now. +* Improved checking when laying out memory. Should hopefully avoid + the random segmentation faults that 2.1.1 sometimes caused. + * Support for Fedora Core 2 and SuSE 9.1. Improvements to NPTL support to the extent that V now works properly on NPTL-only setups. @@ -74,15 +80,8 @@ improve the checking of other interface related ioctls. -* Removed all uses of nested functions as they only work with gcc and - cause the stack to be marked as executable in order for them to work. - Valgrind should be buildable with Intel Icc now. - * Fix building with gcc-3.4.1. * Remove limit on number of semaphores supported. -* Add support for SIOCGMIIPHY, SIOCGMIIREG and SIOCSMIIREG ioctls and - improve the checking of other interface related ioctls. - * Add support for syscalls: set_tid_address (258), acct (51). @@ -96,4 +95,6 @@ in the soft limit causing assertions when valgrind tries to allocate descriptors from the reserved area. + (This actually came from bug #83998 although we're still waiting + on confirmation that the change actually fixed the bug.) * Major overhaul of Cachegrind implementation. Only user visible change @@ -105,6 +106,6 @@ -Unstable (cvs head) release 2.1.1 (12 March 2004) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Developer (cvs head) release 2.1.1 (12 March 2004) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2.1.1 contains some internal structural changes needed for V's long-term future. These don't affect end-users. Most notable |
|
From: Nicholas N. <nj...@ca...> - 2004-07-17 13:11:40
|
On Sat, 17 Jul 2004, Julian Seward wrote: > 2.1.2 is imminent. Dirk, can you please add a 2.1.2 target (or 2.2.0 is that is chosen instead) for bugzilla? Thank you. N |