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
(13) |
2
(16) |
3
(10) |
4
(5) |
5
(1) |
6
|
|
7
(4) |
8
(3) |
9
(1) |
10
(1) |
11
(1) |
12
(3) |
13
(2) |
|
14
(8) |
15
(4) |
16
(17) |
17
(6) |
18
(20) |
19
(12) |
20
(1) |
|
21
(3) |
22
(17) |
23
(10) |
24
(9) |
25
|
26
|
27
(4) |
|
28
(4) |
29
(2) |
30
|
31
(5) |
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-01 16:29:48
|
CVS commit by nethercote: Added summary of survey results, and some actions we've taken in response so far. Not linking to these from the site yet. I will do this tomorrow, unless anyone objects. A survey-response 1.1 A survey-summary 1.1 |
|
From: Nicholas N. <nj...@ca...> - 2003-12-01 14:37:51
|
Hi, There was a thread about malloc() alignment on the users list not long ago. Should V's malloc() return 8-byte aligned blocks? The malloc() man page says: For calloc() and malloc(), the value returned is a pointer to the allocated memory, which is suitably aligned for any kind of variable, or NULL if the request fails. The C standard, section 7.20.3 (from wwwold.dkuug.dk/jtc1/sc22/open/n2794/n2794.txt) says: The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly freed or reallocated). I'm not sure what this actually means. For x86, does "suitably aligned" have any meaning at all, since unaligned accesses are ok? In short, I'd like it if we had a good reason to change the default malloc() alignment to 8-bytes, because it's one less thing for users to trip over. But if there isn't a good reason, I guess we should keep things as they are. N |
|
From: Tom H. <th...@cy...> - 2003-12-01 14:31:14
|
In message <Pin...@gr...>
Nicholas Nethercote <nj...@ca...> wrote:
> Ah. Should I back out the changes? In HEAD and stable branch?
Possibly. I'd be interested to know how the original submitter was
triggering the problem. Although RH9 does use gettid for certain
things I thought that it only did so when the TLS/NPTL version of
the C library was in use, and valgrind can't use that at the moment.
The main place that the C library seems to use it is raise() and
that also uses tkill() which he hasn't mentioned in the bug report.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-01 14:24:02
|
On Mon, 1 Dec 2003, Tom Hughes wrote:
> > +PRE(gettid)
> > +{
> > + /* pid_t gettid(void); */
> > + MAYBE_PRINTF("gettid ()\n");
> > +}
>
> That may stop valgrind complaining, but it doesn't really do what
> anybody expects as it will return the same value in all threads. In
> particular a signal sent to the returned value will not go to the
> right thread.
>
> The way I've done it in my NPTL patch, which is just about complete
> now, is to mark it as a blocking system call so that it is executed
> in the proxy LWP which means that it will get a unique ID for each
> thread, and that signals sent to that ID will get routed to the right
> thread in valgrind.
>
> Jeremy wasn't entirely sure that my solution was a good idea, or even
> that it was worth trying to implement it at all at the moment. He had
> some concerns about people managing to kill a proxy LWP with nasty
> consequences.
Ah. Should I back out the changes? In HEAD and stable branch?
N
|
|
From: Tom H. <th...@cy...> - 2003-12-01 14:16:18
|
In message <200...@of...>
Nicholas Nethercote <nj...@ca...> wrote:
> +PRE(gettid)
> +{
> + /* pid_t gettid(void); */
> + MAYBE_PRINTF("gettid ()\n");
> +}
That may stop valgrind complaining, but it doesn't really do what
anybody expects as it will return the same value in all threads. In
particular a signal sent to the returned value will not go to the
right thread.
The way I've done it in my NPTL patch, which is just about complete
now, is to mark it as a blocking system call so that it is executed
in the proxy LWP which means that it will get a unique ID for each
thread, and that signals sent to that ID will get routed to the right
thread in valgrind.
Jeremy wasn't entirely sure that my solution was a good idea, or even
that it was worth trying to implement it at all at the moment. He had
some concerns about people managing to kill a proxy LWP with nasty
consequences.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-01 14:01:55
|
CVS commit by nethercote:
Add gettid() syscall.
M +8 -0 vg_syscalls.c 1.40.2.10
--- valgrind/coregrind/vg_syscalls.c #1.40.2.9:1.40.2.10
@@ -1646,4 +1646,12 @@ void VG_(perform_assumed_nonblocking_sys
break;
+#if defined(__NR_gettid)
+ case __NR_gettid: /* syscall 224 */
+ /* pid_t gettid(void); */
+ MAYBE_PRINTF("gettid ()\n");
+ KERNEL_DO_SYSCALL(tid, res);
+ break;
+#endif
+
case __NR_getpgid: /* syscall 132 */
/* pid_t getpgid(pid_t pid); */
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-01 14:00:43
|
CVS commit by nethercote:
Add gettid() syscall.
M +7 -0 vg_syscalls.c 1.60
--- valgrind/coregrind/vg_syscalls.c #1.59:1.60
@@ -1937,4 +1937,10 @@ PRE(getpid)
}
+PRE(gettid)
+{
+ /* pid_t gettid(void); */
+ MAYBE_PRINTF("gettid ()\n");
+}
+
PRE(getpgid)
{
@@ -4636,4 +4642,5 @@ static const struct sys_info sys_info[]
SYSB_(getgid32, False),
SYSB_(getpid, False),
+ SYSB_(gettid, False),
SYSB_(getpgid, False),
SYSB_(getpgrp, False),
|
|
From: Robert S. <rsc...@un...> - 2003-12-01 13:35:10
|
On Mon, Dec 01, 2003 at 12:58:08PM +0000, Nick Nethercote wrote: > Hi, >=20 > Is there any difference between RESOLVED, VERIFIED and CLOSED in Bugzilla? > bugs.kde.org/bug_status.html doesn't show any difference. For the developer fixing the bug there is not much difference between these states. You can use these states for quality management: The developer that fixes the bug sets it to RESOLVED. Someone else has to check then whether t= he fix works and is appropriate to fix the problem. =3D=3D> VERIFIED Finally w= hen the fix sneaked into a released product, the bug is no longer an issue. =3D=3D>= CLOSED But the meaning of these states have to be clearly defined for a project to= be of real use. Robert --=20 Robert Schiele Tel.: +49-621-181-2517 Dipl.-Wirtsch.informatiker mailto:rsc...@un... |
|
From: Nicholas N. <nj...@ca...> - 2003-12-01 13:12:17
|
CVS commit by nethercote:
Fix broken assertion, thanks to Tom Hughes.
M +3 -3 hg_main.c 1.68
--- valgrind/helgrind/hg_main.c #1.67:1.68
@@ -2766,7 +2766,7 @@ Bool SK_(read_extra_suppression_info) (
Bool SK_(error_matches_suppression)(Error* err, Supp* su)
{
- sk_assert(VG_(get_supp_kind) (su) == EraserSupp);
- sk_assert(VG_(get_error_kind)(err) == EraserErr);
- return True;
+ sk_assert(VG_(get_supp_kind)(su) == EraserSupp);
+
+ return (VG_(get_error_kind)(err) == EraserErr);
}
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-01 13:11:46
|
CVS commit by nethercote:
Fix broken assertion, thanks to Tom Hughes.
M +2 -2 hg_main.c 1.60.2.3
--- valgrind/helgrind/hg_main.c #1.60.2.2:1.60.2.3
@@ -2749,6 +2749,6 @@ Bool SK_(error_matches_suppression)(Erro
{
sk_assert(VG_(get_supp_kind) (su) == EraserSupp);
- sk_assert(VG_(get_error_kind)(err) == EraserErr);
- return True;
+
+ return (VG_(get_error_kind)(err) == EraserErr);
}
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-01 13:03:43
|
On Sun, 30 Nov 2003, KJK::Hyperion wrote: > >I imagine it would be much easier to port to a *nix OS than to Windows. > > hm, I don't know. How does Valgrind's memory checking work? does it keep a > cache of the memory status somewhere? and the real memory of the process is > kept in synch with the emulated memory? Real memory is shadowed by shadow memory, which records accessibility for every byte, and validity for every bit. Some other tools (Valgrind is a suite of tools, the memory checker is only one) have similar shadow memory, some don't shadow memory at all. > >Sure, it is possible to find out about Windows internals, but a port to an > >open-source OS would be *much* easier. > > I think that's not the major problem here. What do you think is the major problem? > Let's say I am providing a precedent you can point people at (is this > mailing list archived somewhere?) The list is archived at SF.net, but unfortunately I don't think it's searchable, which is pretty lame. N |
|
From: Nicholas N. <nj...@ca...> - 2003-12-01 12:58:28
|
Hi, Is there any difference between RESOLVED, VERIFIED and CLOSED in Bugzilla? bugs.kde.org/bug_status.html doesn't show any difference. Thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2003-12-01 11:54:48
|
CVS commit by nethercote:
Fixed test in section finding code that was broken for .plt and .got sections.
Thanks to Tom Hughes for the patch.
M +4 -7 vg_symtab2.c 1.60
--- valgrind/coregrind/vg_symtab2.c #1.59:1.60
@@ -983,15 +983,12 @@ Bool vg_read_lib_symbols ( SegInfo* si )
if (0 != sec_data) \
VG_(core_panic)("repeated section!\n"); \
- if (in_exec) { \
+ if (in_exec) \
sec_data = (type)(si->offset + shdr[i].sh_addr); \
- sec_size = shdr[i].sh_size; \
- } else { \
+ else \
sec_data = (type)(oimage + shdr[i].sh_offset); \
sec_size = shdr[i].sh_size; \
- } \
TRACE_SYMTAB( "%18s: %p .. %p\n", \
sec_name, sec_data, sec_data + sec_size - 1); \
- if ( sec_size + (UChar*)sec_data > n_oimage + (UChar*)oimage) \
- { \
+ if ( shdr[i].sh_offset + sec_size > n_oimage ) { \
VG_(symerr)(" section beyond image end?!"); \
goto out; \
|