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
(31) |
2
(27) |
|
3
(25) |
4
(21) |
5
(21) |
6
(21) |
7
(32) |
8
(23) |
9
(15) |
|
10
(12) |
11
(9) |
12
(10) |
13
(10) |
14
(9) |
15
(7) |
16
(20) |
|
17
(14) |
18
(71) |
19
(67) |
20
(50) |
21
(25) |
22
(15) |
23
(37) |
|
24
(25) |
25
(41) |
26
(34) |
27
(57) |
28
(20) |
29
(30) |
30
(13) |
|
31
(18) |
|
|
|
|
|
|
|
From: <sv...@va...> - 2005-07-27 23:04:30
|
Author: tom
Date: 2005-07-28 00:04:28 +0100 (Thu, 28 Jul 2005)
New Revision: 4287
Log:
Move (commented out) call to VG_(tm_thread_switchto) to VG_(set_running) =
so
that it is always called when a new thread starts running. Add in a direc=
t
call to VG_TRACK to issue a thread_run event at the same place until thre=
ad
modelling is working again.
Modified:
trunk/coregrind/m_scheduler/scheduler.c
Modified: trunk/coregrind/m_scheduler/scheduler.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_scheduler/scheduler.c 2005-07-27 22:59:50 UTC (rev =
4286)
+++ trunk/coregrind/m_scheduler/scheduler.c 2005-07-27 23:04:28 UTC (rev =
4287)
@@ -203,6 +203,10 @@
=20
if (VG_(clo_trace_sched))
print_sched_event(tid, "now running");
+
+ // While thre modeling is disable, issue thread_run events here
+ // VG_(tm_thread_switchto)(tid);
+ VG_TRACK( thread_run, tid );
}
=20
/*=20
@@ -626,7 +630,6 @@
VG_(set_sleeping)(tid, VgTs_Yielding);
/* nothing */
VG_(set_running)(tid);
- //VG_(tm_thread_switchto)(tid);
=20
/* OK, do some relatively expensive housekeeping stuff */
scheduler_sanity(tid);
|
|
From: <sv...@va...> - 2005-07-27 22:59:57
|
Author: tom
Date: 2005-07-27 23:59:50 +0100 (Wed, 27 Jul 2005)
New Revision: 4286
Log:
Ignore prefetch information when decoding Intel cache details. Patch
from Josef Weidendorfer <Jos...@gm...>.
Modified:
trunk/cachegrind/cg-x86.c
Modified: trunk/cachegrind/cg-x86.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/cachegrind/cg-x86.c 2005-07-27 22:57:18 UTC (rev 4285)
+++ trunk/cachegrind/cg-x86.c 2005-07-27 22:59:50 UTC (rev 4286)
@@ -169,6 +169,10 @@
case 0x86: *L2c =3D (cache_t) { 512, 4, 64 }; L2_found =3D True;=
break;
case 0x87: *L2c =3D (cache_t) { 1024, 8, 64 }; L2_found =3D True;=
break;
=20
+ /* Ignore prefetch information */
+ case 0xf0: case 0xf1:
+ break;
+
default:
VG_(message)(Vg_DebugMsg,=20
"warning: Unknown Intel cache config value "
|
|
From: <sv...@va...> - 2005-07-27 22:57:40
|
Author: tom
Date: 2005-07-27 23:57:18 +0100 (Wed, 27 Jul 2005)
New Revision: 4285
Log:
Handle the fadvise64 system calls correctly on 32 bit platforms.
Modified:
trunk/coregrind/m_syswrap/syswrap-amd64-linux.c
trunk/coregrind/m_syswrap/syswrap-linux.c
Modified: trunk/coregrind/m_syswrap/syswrap-amd64-linux.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-amd64-linux.c 2005-07-27 20:31:57 U=
TC (rev 4284)
+++ trunk/coregrind/m_syswrap/syswrap-amd64-linux.c 2005-07-27 22:57:18 U=
TC (rev 4285)
@@ -587,6 +587,7 @@
DECL_TEMPLATE(amd64_linux, sys_ptrace);
DECL_TEMPLATE(amd64_linux, sys_pread64);
DECL_TEMPLATE(amd64_linux, sys_pwrite64);
+DECL_TEMPLATE(amd64_linux, sys_fadvise64);
=20
=20
PRE(sys_clone)
@@ -1147,6 +1148,13 @@
PRE_MEM_READ( "pwrite64(buf)", ARG2, ARG3 );
}
=20
+PRE(sys_fadvise64)
+{
+ PRINT("sys_fadvise64 ( %d, %lld, %llu, %d )", ARG1,ARG2,ARG3,ARG4);
+ PRE_REG_READ4(long, "fadvise64",
+ int, fd, vki_loff_t, offset, vki_size_t, len, int, advi=
ce);
+}
+
#undef PRE
#undef POST
=20
@@ -1433,7 +1441,7 @@
// (__NR_restart_syscall, sys_restart_syscall),// 219=20
=20
PLAX_(__NR_semtimedop, sys_semtimedop), // 220=20
- LINX_(__NR_fadvise64, sys_fadvise64), // 221=20
+ PLAX_(__NR_fadvise64, sys_fadvise64), // 221=20
GENXY(__NR_timer_create, sys_timer_create), // 222=20
GENXY(__NR_timer_settime, sys_timer_settime), // 223=20
GENXY(__NR_timer_gettime, sys_timer_gettime), // 224=20
Modified: trunk/coregrind/m_syswrap/syswrap-linux.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-linux.c 2005-07-27 20:31:57 UTC (re=
v 4284)
+++ trunk/coregrind/m_syswrap/syswrap-linux.c 2005-07-27 22:57:18 UTC (re=
v 4285)
@@ -103,6 +103,9 @@
#define PRE(name) DEFN_PRE_TEMPLATE(linux, name)
#define POST(name) DEFN_POST_TEMPLATE(linux, name)
=20
+// Combine two 32-bit values into a 64-bit value
+#define LOHI64(lo,hi) ( (lo) | ((ULong)(hi) << 32) )
+
PRE(sys_set_tid_address)
{
PRINT("sys_set_tid_address ( %p )", ARG1);
@@ -653,16 +656,20 @@
=20
PRE(sys_fadvise64)
{
- PRINT("sys_fadvise64 ( %d, %lld, %lu, %d )", ARG1,ARG2,ARG3);
- PRE_REG_READ4(long, "fadvise64",
- int, fd, vki_loff_t, offset, vki_size_t, len, int, advi=
ce)
+ PRINT("sys_fadvise64 ( %d, %lld, %lu, %d )",
+ ARG1, LOHI64(ARG2,ARG3), ARG4, ARG5);
+ PRE_REG_READ5(long, "fadvise64",
+ int, fd, vki_u32, offset_low, vki_u32, offset_high,
+ vki_size_t, len, int, advice);
}
=20
PRE(sys_fadvise64_64)
{
- PRINT("sys_fadvise64_64 ( %d, %lld, %lld, %d )", ARG1,ARG2,ARG3);
- PRE_REG_READ4(long, "fadvise64_64",
- int, fd, vki_loff_t, offset, vki_loff_t, len, int, advi=
ce)
+ PRINT("sys_fadvise64_64 ( %d, %lld, %lld, %d )",
+ ARG1, LOHI64(ARG2,ARG3), LOHI64(ARG4,ARG5), ARG6);
+ PRE_REG_READ6(long, "fadvise64_64",
+ int, fd, vki_u32, offset_low, vki_u32, offset_high,
+ vki_u32, len_low, vki_u32, len_high, int, advice);
}
=20
// Nb: this wrapper has to pad/unpad memory around the syscall itself,
|
|
From: Josef W. <Jos...@gm...> - 2005-07-27 21:55:12
|
On Wednesday 27 July 2005 21:30, Nicholas Nethercote wrote:
> On Wed, 27 Jul 2005, Josef Weidendorfer wrote:
> >>> Some sort of thread modelling should hopefully come back...
> >>>
> >>> We could just put VG_TRACK( thread_run, tid ) into the scheduler
> >>> for now, where it currently calls VG_(tm_thread_switchto).
> >>
> >> That sounds like a good solution.
> >
> > See the other mail. Shouldn't thread_run be called on any thread switch?
>
> I don't understand the issues here. Josef, perhaps it would be best if
> you just write a patch for m_scheduler.c containing the code that you
> want?
VG_(set_running)(ThreadId tid) is called from 2 places in scheduler.c:
(1) from VG_(vg_yield)(void)
(2) from VG_(scheduler) ( ThreadId tid )
Tom suggested to insert VG_TRACK( thread_run, tid ) into VG_(scheduler),
directly after the call to VG_(set_running). Unfortunately, this way a tool
misses thread switches triggered by VG_(vg_yield). So my suggestion is the
following:
--- scheduler.c.orig 2005-07-27 23:36:08.000000000 +0200
+++ scheduler.c 2005-07-27 15:47:26.000000000 +0200
@@ -203,6 +203,8 @@ void VG_(set_running)(ThreadId tid)
if (VG_(clo_trace_sched))
print_sched_event(tid, "now running");
+
+ VG_TRACK( thread_run, tid );
}
If we reestablish m_threadmodel.c, VG_(tm_thread_switchto) should be called
from VG_(set_running) to get both switch cases, and not only from
VG_(scheduler).
Regarding your question for VG 2.4: Yes, I have the problem there that my tool
is not reliable notified about all thread switched via thread_run.
Josef
>
> N
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Christian P. <tr...@ge...> - 2005-07-27 21:38:22
|
On Wednesday 27 July 2005 22:17, Julian Seward wrote: > amd64 running SuSE 9.2 amd64 running Gentoo/Linux (2005.0, ~amd64 testing/unstable packages) ^^ works fine for me, too, however, I do *STILL* have that freezing=20 (mmap/munmap) problem on VG start and exit. Regards, Christian Parpart. =2D-=20 23:36:08 up 126 days, 12:43, 2 users, load average: 2.37, 9.55, 7.26 |
|
From: Nicholas N. <nj...@cs...> - 2005-07-27 21:37:29
|
On Wed, 27 Jul 2005, Julian Seward wrote:
>> - if it's an executable, execute natively
>> - if it's a script with a "#!" line, use the named interpreter
>> - else default to interpreting with /bin/sh
>>
>> Valgrind doesn't do that 3rd step. Perhaps it should?
>
> I guess it should, yes. How intrusive a change would it be?
Not very, it's just a few lines in m_ume.c. Below is a preliminary patch
(done with "diff -b", because I had to indent a section of code). I
haven't tested it thoroughly but the cases I tested worked. I don't know
whether defaulting to /bin/sh is Linux-specific, though.
N
*** ../trunk7/coregrind/m_ume.c Mon Jul 18 19:33:34 2005
--- coregrind/m_ume.c Wed Jul 27 16:32:11 2005
***************
*** 581,587 ****
static int match_script(const char *hdr, Int len)
{
! return (len > 2) && memcmp(hdr, "#!", 2) == 0;
}
--- 581,590 ----
+ // If we don't match as ELF, assume it's a script. (If there's not #!
line,
+ // we default to assuming a /bin/sh script.)
static int match_script(const char *hdr, Int len)
{
! //return (len > 2) && memcmp(hdr, "#!", 2) == 0;
! return True;
}
***************
*** 595,598 ****
--- 598,603 ----
int eol;
+ if (hdr[0] == '#' && hdr[1] == '!') {
+
interp = hdr + 2;
while(interp < end && (*interp == ' ' || *interp == '\t'))
***************
*** 635,638 ****
--- 640,649 ----
printf("#! script: interp_name=\"%s\" interp_args=\"%s\"\n",
info->interp_name, info->interp_args);
+
+ } else {
+ interp = "/bin/sh";
+ info->interp_name = interp;
+ info->interp_args = NULL;
+ }
return do_exec_inner(interp, info);
|
|
From: Tom H. <to...@co...> - 2005-07-27 21:30:16
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> Please download and test this release candidate, and let us know of
> any problems you encounter. This tarball is known to build and work
> on the following platforms:
>
> amd64 running SuSE 9.2
FC 2, 3 and 4 should be OK as well. My overnights are running amd64
on all of those.
> x86 running SuSE 9.1, SuSE 9.3, RedHat 7.3, Fedora Core 4
RH 8.0 should be OK as well.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-07-27 21:13:02
|
> - if it's an executable, execute natively > - if it's a script with a "#!" line, use the named interpreter > - else default to interpreting with /bin/sh > > Valgrind doesn't do that 3rd step. Perhaps it should? I guess it should, yes. How intrusive a change would it be? J |
|
From: Julian S. <js...@ac...> - 2005-07-27 21:11:25
|
> Regression tests go as expected (3 failures), and StarOffice worked ok. > Although I did see this output at the end: Good. OOo 1.1.3 on LinuxThreads works, I know that much. > > ==8095== Syscall param write(buf) points to uninitialised byte(s) > ==8095== at 0x1CC26404: write (in /lib/libc-2.2.5.so) > ==8095== by 0x1C7528E3: osl_joinWithThread (in > /lusr/opt/staroffice7/program/libsal.so.3.1.0) > ==8095== by 0x1C412377: vos::OThread::join() (in > /lusr/opt/staroffice7/program/libvos3gcc3.so) > ==8095== by 0x806EABF: > desktop::OfficeIPCThread::DisableOfficeIPCThread() (in > /lusr/opt/staroffice7/program/soffice.bin) > ==8095== by 0x80605F5: desktop::Desktop::DeInit() (in > /lusr/opt/staroffice7/program/soffice.bin) > ==8095== by 0x1B9D4C34: DeInitVCL() (in > /lusr/opt/staroffice7/program/libvcl645li.so) > ==8095== by 0x1B9D4692: SVMain() (in > /lusr/opt/staroffice7/program/libvcl645li.so) > ==8095== by 0x1BB987E3: main (in > /lusr/opt/staroffice7/program/libvcl645li.so) Isn't that a classic buffer-contains-uninitialised-padding problem? > Notice that the prompt is buried in there before the final output. This > could be caused by the change in how termination is handled. It is indeed. Bear in mind that OOo/SO was the first known deadlock-at- exit case and so it makes sense now that the main thread exits before all of its children. J |
|
From: Nicholas N. <nj...@cs...> - 2005-07-27 20:55:58
|
On Wed, 27 Jul 2005, Nicholas Nethercote wrote: >> Valgrind-3.0.0 Release Candidate 1 is available from >> http://www.valgrind.org/downloads/valgrind-3.0.RC1.tar.bz2 >> (md5sum == c3dc8089bebe7aba0822667b7850451e) > > Regression tests go as expected (3 failures), and StarOffice worked ok. I forgot to say: [~/scale/dev1/scale] uname -a Linux charco.cs.utexas.edu 2.4.29 #1 SMP Mon Jan 24 09:20:36 CST 2005 i686 unknown [~/scale/dev1/scale] /lib/libc.so.6 GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. This is an oldish Debian-something system. N |
|
From: Nicholas N. <nj...@cs...> - 2005-07-27 20:53:02
|
Hi, I just discovered that Valgrind refuses to execute any shell script missing a "#!" line at the start, saying: valgrind: do_exec(./foo) failed: Exec format error It seems that the normal behaviour when executing an executable file with the shell: - if it's an executable, execute natively - if it's a script with a "#!" line, use the named interpreter - else default to interpreting with /bin/sh Valgrind doesn't do that 3rd step. Perhaps it should? N |
|
From: Madhu M K. <mm...@ya...> - 2005-07-27 20:50:38
|
Hi, On Wed, 2005-07-27 at 13:17, Julian Seward wrote: > Please download and test this release candidate, and let us know of > any problems you encounter. This tarball is known to build and work > on the following platforms: > > amd64 running SuSE 9.2 > > x86 running SuSE 9.1, SuSE 9.3, RedHat 7.3, Fedora Core 4 > You can add Fedora Core 1 and Fedora Core 2 to that list. Some warnings from the compile were: -- gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../coregrind -I../.. -I../../coregrind/x86 -I../../coregrind/linux -I../../coregrind/x86-linux -I../../include -I/home/mmk/valgrind/valgrind-3.0.RC1/VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -MT symtypes.o -MD -MP -MF ".deps/symtypes.Tpo" -c -o symtypes.o symtypes.c; \ then mv -f ".deps/symtypes.Tpo" ".deps/symtypes.Po"; else rm -f ".deps/symtypes.Tpo"; exit 1; fi symtypes.c: In function `vgPlain_describe_addr': symtypes.c:764: warning: no previous prototype for `newvar' symtypes.c:984: warning: no previous prototype for `genstring' and gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I/home/mmk/valgrind/valgrind-3.0.RC1/VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -DKICKSTART_BASE=0xb0000000 -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -MT m_mallocfree.o -MD -MP -MF ".deps/m_mallocfree.Tpo" -c -o m_mallocfree.o m_mallocfree.c; \ then mv -f ".deps/m_mallocfree.Tpo" ".deps/m_mallocfree.Po"; else rm -f ".deps/m_mallocfree.Tpo"; exit 1; fi In file included from m_mallocfree.c:252: m_mallocfree.c:267: warning: inlining failed in call to `get_bszB' m_mallocfree.c:249: warning: called from here -- Apart from those, things seem pretty rock solid. I've run some basic sanity checks and they seem fine, I'm going to get the regression testing going tonight. Cheerio, M -- Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
From: Nicholas N. <nj...@cs...> - 2005-07-27 20:49:49
|
On Wed, 27 Jul 2005, Julian Seward wrote: > Valgrind-3.0.0 Release Candidate 1 is available from > http://www.valgrind.org/downloads/valgrind-3.0.RC1.tar.bz2 > (md5sum == c3dc8089bebe7aba0822667b7850451e) Regression tests go as expected (3 failures), and StarOffice worked ok. Although I did see this output at the end: ==8095== Syscall param write(buf) points to uninitialised byte(s) ==8095== at 0x1CC26404: write (in /lib/libc-2.2.5.so) ==8095== by 0x1C7528E3: osl_joinWithThread (in /lusr/opt/staroffice7/program/libsal.so.3.1.0) ==8095== by 0x1C412377: vos::OThread::join() (in /lusr/opt/staroffice7/program/libvos3gcc3.so) ==8095== by 0x806EABF: desktop::OfficeIPCThread::DisableOfficeIPCThread() (in /lusr/opt/staroffice7/program/soffice.bin) ==8095== by 0x80605F5: desktop::Desktop::DeInit() (in /lusr/opt/staroffice7/program/soffice.bin) ==8095== by 0x1B9D4C34: DeInitVCL() (in /lusr/opt/staroffice7/program/libvcl645li.so) ==8095== by 0x1B9D4692: SVMain() (in /lusr/opt/staroffice7/program/libvcl645li.so) ==8095== by 0x1BB987E3: main (in /lusr/opt/staroffice7/program/libvcl645li.so) ==8095== Address 0x52BFE3CC is on thread 1's stack [~/grind/trunk2/tmp/valgrind-3.0.RC1] ==8128== ==8128== ERROR SUMMARY: 1578 errors from 64 contexts (suppressed: 8 from 3) ==8128== malloc/free: in use at exit: 801466 bytes in 6295 blocks. ==8128== malloc/free: 22603 allocs, 16308 frees, 4661380 bytes allocated. ==8128== For counts of detected errors, rerun with: -v ==8128== searching for pointers to 6295 not-freed blocks. ==8128== checked 22230836 bytes. ==8128== ==8128== LEAK SUMMARY: ==8128== definitely lost: 18050 bytes in 22 blocks. ==8128== possibly lost: 44884 bytes in 399 blocks. ==8128== still reachable: 738532 bytes in 5874 blocks. ==8128== suppressed: 0 bytes in 0 blocks. ==8128== Use --leak-check=full to see details of leaked memory. Notice that the prompt is buried in there before the final output. This could be caused by the change in how termination is handled. N |
|
From: <sv...@va...> - 2005-07-27 20:33:17
|
Author: njn Date: 2005-07-27 21:31:57 +0100 (Wed, 27 Jul 2005) New Revision: 4284 Log: Removed dead declaration. Modified: trunk/include/pub_tool_libcfile.h Modified: trunk/include/pub_tool_libcfile.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/include/pub_tool_libcfile.h 2005-07-27 17:49:17 UTC (rev 4283) +++ trunk/include/pub_tool_libcfile.h 2005-07-27 20:31:57 UTC (rev 4284) @@ -51,11 +51,6 @@ // Returns False on failure (eg. if the buffer isn't big enough). extern Bool VG_(getcwd) ( Char* buf, SizeT size ); =20 -/* Easier to use than VG_(getcwd)() -- does the buffer fiddling itself. - String put into 'cwd' is VG_(malloc)'d, and should be VG_(free)'d. - Returns False if it fails. Will fail if the pathname is > 65535 byte= s. */ -extern Bool VG_(getcwd_alloc) ( Char** cwd ); - extern Int VG_(readlink)( Char* path, Char* buf, UInt bufsize ); extern Int VG_(getdents)( UInt fd, struct vki_dirent *dirp, UInt count = ); =20 |
|
From: Julian S. <js...@ac...> - 2005-07-27 20:23:36
|
Ok. RC1 is out (finally-at-last :-) so the freeze is over. J > I was hoping to roll RC1 this morning, and it is very nearly done, > but I need to run round and do other urgent stuff for a couple of hours. > Please don't commit anything now. I hope to un-freeze by the end of > the day (GMT+1). > > J > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Julian S. <js...@ac...> - 2005-07-27 20:17:50
|
Greetings. Valgrind-3.0.0 Release Candidate 1 is available from http://www.valgrind.org/downloads/valgrind-3.0.RC1.tar.bz2 (md5sum == c3dc8089bebe7aba0822667b7850451e) This is our first attempt at what we believe to be a release-quality snapshot of the Valgrind-3.0 line. If all goes well, we hope to release a final 3.0 in about a week's time. This is the first Valgrind to support both x86-linux and amd64-linux. Support for ppc32-linux is also integrated but does not yet work well enough to be useful. Please download and test this release candidate, and let us know of any problems you encounter. This tarball is known to build and work on the following platforms: amd64 running SuSE 9.2 x86 running SuSE 9.1, SuSE 9.3, RedHat 7.3, Fedora Core 4 ppc32 running Yellow Dog 4.0.1 (subject to caveats above) The attached release notes detail what is new in 3.0. Many thanks to all those who contributed to Valgrind's development. This RC represents a great deal of time, energy and effort on the part of many people. The Valgrind Developers --------------------------------------------------------------------- Release 3.0.0 ([[TODO: add release date]]) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.0.0 is a major overhaul of Valgrind. The most significant user-visible change is that Valgrind now supports architectures other than x86. The new architectures it supports are AMD64 and PPC32, and the infrastructure is present for other architectures to be added later. The AMD64 support works well, but has some shortcomings: - It generally won't be as solid as the x86 version. For example, support for more obscure instructions and system calls may be missing. We will fix these as they arise. - Address space may be limited; see the point about position-independent executables below. - If Valgrind is built on an AMD64 machine, it will only run 64-bit executables. If you want to run 32-bit x86 executables under Valgrind on an AMD64, you will need to build Valgrind on an x86 machine and copy it to the AMD64 machine. And it probably won't work if you do something tricky like exec'ing a 32-bit program from a 64-bit program while using --trace-children=yes. We hope to improve this situation in the future. The PPC32 support is very basic. It may not work reliably even for small programs, but it's a start. Many thanks to Paul Mackerras for his great work that enabled this support. We are working to make PPC32 usable as soon as possible. Other user-visible changes: - No longer building Valgrind as a position-independent executable (PIE) by default, as it caused too many problems. Without PIE enabled, AMD64 programs will only be able to access 2GB of address space. We will fix this eventually, but not for the moment. Use --enable-pie at configure-time to turn this on. - Support for programs that use stack-switching has been improved. Use the --max-stackframe flag for simple cases, and the VALGRIND_STACK_REGISTER, VALGRIND_STACK_DEREGISTER and VALGRIND_STACK_CHANGE client requests for trickier cases. - Support for programs that use self-modifying code has been improved, in particular programs that put temporary code fragments on the stack. This helps for C programs compiled with GCC that use nested functions, and also Ada programs. This is controlled with the --smc-check flag, although the default setting should work in most cases. - Output can now be printed in XML format. This should make it easier for tools such as GUI front-ends and automated error-processing schemes to use Valgrind output as input. The --xml flag controls this. As part of this change, ELF directory information is read from executables, so absolute source file paths are available if needed. [[TODO: describe the related CLOs added (eg. --log-file-qualifier)]] - Programs that allocate many heap blocks may run faster, due to improvements in certain data structures. - Addrcheck is currently not working. We hope to get it working again soon. Helgrind is still not working, as was the case for the 2.4.0 release. - The JITter has been completely rewritten, and is now in a separate library, called Vex. This enabled a lot of the user-visible changes, such as new architecture support. The new JIT unfortunately translates more slowly than the old one, so programs may take longer to start. We believe the code quality is produces is about the same, so once started, programs should run at about the same speed. Feedback about this would be useful. On the plus side, Vex and hence Memcheck tracks value flow properly through floating point and vector registers, something the 2.X line could not do. That means that Memcheck is much more likely to be usably accurate on vectorised code. - There is a subtle change to the way exiting of threaded programs is handled. In 3.0, Valgrind's final diagnostic output (leak check, etc) is not printed until the last thread exits. If the last thread to exit was not the original thread which started the program, any other process wait()-ing on this one to exit may conclude it has finished before the diagnostic output is printed. This may not be what you expect. 2.X had a different scheme which avoided this problem, but caused deadlocks under obscure circumstances, so we are trying something different for 3.0. - Small changes in control log file naming which make it easier to use valgrind for debugging MPI-based programs. - As part of adding AMD64 support, DWARF2 CFI-based stack unwinding support was added. In principle this means Valgrind can produce meaningful backtraces on x86 code compiled with -fomit-frame-pointer providing you also compile your code with -fasynchronous-unwind-tables. - [[TODO: add more here]] Changes that are not user-visible: - The code has been massively overhauled in order to modularise it. As a result we hope it is easier to navigate and understand. - Lots of code has been rewritten. - [[TODO: add more here]] BUGS FIXED [[TODO: add the full list here (once the RCs are out of the way?)]] (3.0RC1: 27 July 05, vex r1303, valgrind r4283). |
|
From: Nicholas N. <nj...@cs...> - 2005-07-27 19:30:40
|
On Wed, 27 Jul 2005, Josef Weidendorfer wrote: >>> Some sort of thread modelling should hopefully come back... >>> >>> We could just put VG_TRACK( thread_run, tid ) into the scheduler >>> for now, where it currently calls VG_(tm_thread_switchto). >> >> That sounds like a good solution. > > See the other mail. Shouldn't thread_run be called on any thread switch? I don't understand the issues here. Josef, perhaps it would be best if you just write a patch for m_scheduler.c containing the code that you want? N |
|
From: Josef W. <Jos...@gm...> - 2005-07-27 19:15:10
|
On Wednesday 27 July 2005 15:35, Nicholas Nethercote wrote: > m_libcfile.c wouldn't depend on on m_mallocfree.c. Josef, please use > VG_(getcwd)() with a static buffer, as done in Cachegrind. Yes. > >> * I used to track VG_(track_thread_run) to be able to regularly poll for > >> existiance of a "command file". This is my way to be able to control the > >> simulation interactively, and this is quite a crucial feature. > >> Currently, the according stuff in m_threadmodel.c is commented out. Will > >> this ever be uncommented again? Or what is a better way to wait/poll for > >> interactive commands? > > Was this a problem with 2.4.0 also? If not, what changed between 2.4.0 > and 3.0.0? The problem with 3.0 currently is that a tool will never get thread_run called as it is commented out. In 2.4 it worked, there was no problem there. Or do I miss the point in your question? > > Some sort of thread modelling should hopefully come back... > > > > We could just put VG_TRACK( thread_run, tid ) into the scheduler > > for now, where it currently calls VG_(tm_thread_switchto). > > That sounds like a good solution. See the other mail. Shouldn't thread_run be called on any thread switch? Josef |
|
From: <sv...@va...> - 2005-07-27 17:49:24
|
Author: sewardj Date: 2005-07-27 18:49:17 +0100 (Wed, 27 Jul 2005) New Revision: 4283 Log: Bump version number. Modified: trunk/NEWS trunk/configure.in Modified: trunk/NEWS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/NEWS 2005-07-27 10:33:08 UTC (rev 4282) +++ trunk/NEWS 2005-07-27 17:49:17 UTC (rev 4283) @@ -113,6 +113,10 @@ [[TODO: add the full list here (once the RCs are out of the way?)]] =20 =20 +(3.0RC1: 27 July 05, vex r1303, valgrind r4283). + + + Stable release 2.4.0 (March 2005) -- CHANGES RELATIVE TO 2.2.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2.4.0 brings many significant changes and bug fixes. The most Modified: trunk/configure.in =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/configure.in 2005-07-27 10:33:08 UTC (rev 4282) +++ trunk/configure.in 2005-07-27 17:49:17 UTC (rev 4283) @@ -1,5 +1,5 @@ # Process this file with autoconf to produce a configure script. -AC_INIT(Valgrind, 3.0.0.SVN, val...@li...) +AC_INIT(Valgrind, 3.0.RC1, val...@li...) AC_CONFIG_SRCDIR(coregrind/m_main.c) AM_CONFIG_HEADER(config.h) AM_INIT_AUTOMAKE |
|
From: Tom H. <to...@co...> - 2005-07-27 17:33:30
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Wed, 27 Jul 2005, sv...@va... wrote:
>
> > Log:
> > Prevent the rule for installing the VEX headers from trying to add
> > them to the distribution as it doesn't work due to the full paths and
> > they are in EXTRA_DIST anyway.
>
> Now I'm really confused: The Vex headers aren't included in EXTRA_DIST
> (VEX_PRIMARY_SOURCES is, but VEX_PUBLIC_HDRS is not), and the headers are
> marked as "nodist", yet when I do 'make dist' and install from it the
> headers get installed. Which is good and what we want, but I don't
> understand how it works...
The VEX headers are in both PRIMARY_SOURCES and PUBLIC_HDRS now. I had
to move them back because make dist wants the local ones but make install
want the ones we configured with.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-27 17:30:58
|
On Wed, 27 Jul 2005, sv...@va... wrote: > Log: > Prevent the rule for installing the VEX headers from trying to add > them to the distribution as it doesn't work due to the full paths and > they are in EXTRA_DIST anyway. Now I'm really confused: The Vex headers aren't included in EXTRA_DIST (VEX_PRIMARY_SOURCES is, but VEX_PUBLIC_HDRS is not), and the headers are marked as "nodist", yet when I do 'make dist' and install from it the headers get installed. Which is good and what we want, but I don't understand how it works... N |
|
From: Nicholas N. <nj...@cs...> - 2005-07-27 17:14:05
|
On Wed, 27 Jul 2005, Tom Hughes wrote: >> * for VG_(getcwd_alloc), which is defined in pub_tool_libcfile.h as part of >> the tool API, there is no implementation > > It was removed by Nick in revision 3995: > > Remove VG_(getcwd_alloc)(), which can be done otherwise pretty easily. > This halves m_libcfile's dependence on m_mallocfree. > > Obviously the header should be fixed as well. I'll fix it after the freeze. I removed getcwd_alloc() so that m_libcfile.c wouldn't depend on on m_mallocfree.c. Josef, please use VG_(getcwd)() with a static buffer, as done in Cachegrind. >> * is VG_(clo_pointercheck) used at all? I used to have to set it to False to >> be able to run my tool (I instrument code which writes to valgrind space). >> Is this check (whether a store is into client space) really currently done? > > It isn't currently enabled for any platform as far as I know. The > previous implementation was x86 specific anyway and won't work on amd64. The code in m_aspacemgr.c:VG_(setup_pointercheck)() makes it look like it's doing something on x86. >> * I used to track VG_(track_thread_run) to be able to regularly poll for >> existiance of a "command file". This is my way to be able to control the >> simulation interactively, and this is quite a crucial feature. Currently, the >> according stuff in m_threadmodel.c is commented out. Will this ever be >> uncommented again? Or what is a better way to wait/poll for interactive >> commands? Was this a problem with 2.4.0 also? If not, what changed between 2.4.0 and 3.0.0? > Some sort of thread modelling should hopefully come back... > > We could just put VG_TRACK( thread_run, tid ) into the scheduler > for now, where it currently calls VG_(tm_thread_switchto). That sounds like a good solution. N |
|
From: Tom H. <to...@co...> - 2005-07-27 17:13:00
|
In message <yek...@de...>
Tom Hughes <to...@co...> wrote:
> In message <Pin...@ch...>
> Nicholas Nethercote <nj...@cs...> wrote:
>
>> The code in m_aspacemgr.c:VG_(setup_pointercheck)() makes it look like
>> it's doing something on x86.
>
> The segment limits are setup yes, but as VEX won't put a segment
> prefix on any of the loads or stores it does that won't have any
> effect will it?
Indeed, in 2.4.0 vg_from_ucode.c had code to add a %fs prefix to
memory accesses if pointer checks were enabled. There is no equivalent
to that in 3.0.0 so enabling pointer checks will do nothing.
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-27 17:08:05
|
On Wed, 27 Jul 2005, Tom Hughes wrote: >> The code in m_aspacemgr.c:VG_(setup_pointercheck)() makes it look like >> it's doing something on x86. > > The segment limits are setup yes, but as VEX won't put a segment > prefix on any of the loads or stores it does that won't have any > effect will it? Oh yes, I think you're right. N |
|
From: Dirk M. <mu...@kd...> - 2005-07-27 16:58:06
|
SVN commit 439304 by mueller: revert last commit M +2 -2 README =20 --- trunk/valgrind/README #439303:439304 @@ -47,8 +47,8 @@ =20 Valgrind is closely tied to details of the CPU, operating system and to a less extent, compiler and basic C libraries. This makes it -difficult to make it portable. Nonetheless, it is available for -the following platforms: x86/Linux, AMD64/Linux and PPC32/Linux. +difficult to make it portable, so I have chosen at the outset to +concentrate on what I believe to be a widely used platform: x86/Linux. =20 Valgrind is licensed under the GNU General Public License, version 2.=20 Read the file COPYING in the source distribution for details. |