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
(1) |
2
(2) |
3
(2) |
4
(3) |
5
(1) |
|
6
(2) |
7
|
8
|
9
|
10
(1) |
11
|
12
|
|
13
|
14
(2) |
15
(27) |
16
(1) |
17
(4) |
18
(4) |
19
|
|
20
|
21
(1) |
22
(2) |
23
|
24
(2) |
25
|
26
(2) |
|
27
|
28
(22) |
29
(5) |
30
(3) |
31
(6) |
|
|
|
From: Ivo R. <ir...@so...> - 2017-08-15 09:52:15
|
The branch 'jit-hacks' was created pointing to: fc47a58... Fix VEX register allocator (v3) to work with HInstrSB, HIns |
|
From: Austin E. <aus...@gm...> - 2017-08-15 06:17:38
|
n Mon, Aug 14, 2017 at 9:20 AM, Ivo Raisr <iv...@iv...> wrote: > Dear Valgrind users and developers, > > Valgrind source code repository has been migrated today successfully > from Subversion > to git SCM at sourceware.org. Valgrind www pages has been updated as well > to reflect new situation. > > Repositories "valgrind" and "vex" should be treated as read-only from now on. > All the development is now done with git at > git://sourceware.org/git/valgrind.git: > > git clone git://sourceware.org/git/valgrind.git/ valgrind > <edit/compile> > git status/add/show > git pull --rebase origin/master > <build + test> > git commit > git show > > if you have write access, then: > git remote set-url --push origin > ssh://<username>@sourceware.org/git/valgrind.git/ > git push > > > There are a lot of good tutorials on simple git workflows, so please > have a look. > Bart prepared small GIT howto: > https://sourceware.org/git/?p=valgrind.git;a=blob;f=docs/internals/git-HOWTO.txt > > If you are using something more complicated, please share with us and > ideally send us a write up. > > Kind regards, > I. > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers Wonderful Ivo, thank you and everyone else for your efforts in getting this done! -- -Austin GPG: 14FB D7EA A041 937B |
|
From: Varun G. <var...@li...> - 2017-08-14 20:27:04
|
Dear Valgrind developers,
Currently Valgrind allows us to create objects in a memory pool, destroy
them individually and destroy them all with the pool.
We are working with linking Valgrind into garbage collector in Eclipse
OMR framework. The garbage collector's implementation is such that it
keeps track of areas in memory that are available and free. It does not
keep track of allocated objects (target language running over it does
that) and in each run is informed by it about the ones that are still
present. Based on this information, it marks remaining area as free
without caring about dead objects.
We now have only have areas that are available and not individual
objects so it is not possible to call Valgrind to free them
individually. Using a set to store them temporarily solves this but it
goes against the whole architecture that is ignoring them.
Since Valgrind is already keeping a track of these objects, it can also
free them in a given range without any extra effort, without sacrificing
existing behavior.
Author: Andrew Young
Index: include/valgrind.h
===================================================================
diff --git a/trunk/include/valgrind.h b/trunk/include/valgrind.h
--- a/trunk/include/valgrind.h (revision 16461)
+++ b/trunk/include/valgrind.h (working copy)
@@ -6157,6 +6157,7 @@
VG_USERREQ__MOVE_MEMPOOL = 0x1308,
VG_USERREQ__MEMPOOL_CHANGE = 0x1309,
VG_USERREQ__MEMPOOL_EXISTS = 0x130a,
+ VG_USERREQ__MEMPOOL_CLEAR = 0x130c,
/* Allow printfs to valgrind log. */
/* The first two pass the va_list argument by value, which
@@ -6546,6 +6547,11 @@
VALGRIND_DO_CLIENT_REQUEST_STMT(VG_USERREQ__MEMPOOL_TRIM, \
pool, addr, size, 0, 0)
+/* Disassociate any pieces inside a particular range. */
+#define VALGRIND_MEMPOOL_CLEAR(pool, addr, size) \
+ VALGRIND_DO_CLIENT_REQUEST_STMT(VG_USERREQ__MEMPOOL_CLEAR, \
+ pool, addr, size, 0, 0)
+
/* Resize and/or move a piece associated with a memory pool. */
#define VALGRIND_MOVE_MEMPOOL(poolA, poolB) \
VALGRIND_DO_CLIENT_REQUEST_STMT(VG_USERREQ__MOVE_MEMPOOL, \
Index: memcheck/mc_include.h
===================================================================
diff --git a/trunk/memcheck/mc_include.h b/trunk/memcheck/mc_include.h
--- a/trunk/memcheck/mc_include.h (revision 16461)
+++ b/trunk/memcheck/mc_include.h (working copy)
@@ -115,6 +115,7 @@
Addr addr, SizeT size );
void MC_(mempool_free) ( Addr pool, Addr addr );
void MC_(mempool_trim) ( Addr pool, Addr addr, SizeT size );
+void MC_(mempool_clear) ( Addr pool, Addr addr, SizeT size );
void MC_(move_mempool) ( Addr poolA, Addr poolB );
void MC_(mempool_change) ( Addr pool, Addr addrA, Addr addrB, SizeT
size );
Bool MC_(mempool_exists) ( Addr pool );
Index: memcheck/mc_main.c
===================================================================
diff --git a/trunk/memcheck/mc_main.c b/trunk/memcheck/mc_main.c
--- a/trunk/memcheck/mc_main.c (revision 16461)
+++ b/trunk/memcheck/mc_main.c (working copy)
@@ -6934,6 +6934,7 @@
&& VG_USERREQ__MEMPOOL_ALLOC != arg[0]
&& VG_USERREQ__MEMPOOL_FREE != arg[0]
&& VG_USERREQ__MEMPOOL_TRIM != arg[0]
+ && VG_USERREQ__MEMPOOL_CLEAR != arg[0]
&& VG_USERREQ__MOVE_MEMPOOL != arg[0]
&& VG_USERREQ__MEMPOOL_CHANGE != arg[0]
&& VG_USERREQ__MEMPOOL_EXISTS != arg[0]
@@ -7200,6 +7201,15 @@
return True;
}
+ case VG_USERREQ__MEMPOOL_CLEAR: {
+ Addr pool = (Addr)arg[1];
+ Addr addr = (Addr)arg[2];
+ UInt size = arg[3];
+
+ MC_(mempool_clear) ( pool, addr, size );
+ return True;
+ }
+
case VG_USERREQ__MOVE_MEMPOOL: {
Addr poolA = (Addr)arg[1];
Addr poolB = (Addr)arg[2];
Index: memcheck/mc_malloc_wrappers.c
===================================================================
diff --git a/trunk/memcheck/mc_malloc_wrappers.c
b/trunk/memcheck/mc_malloc_wrappers.c
--- a/trunk/memcheck/mc_malloc_wrappers.c (revision 16461)
+++ b/trunk/memcheck/mc_malloc_wrappers.c (working copy)
@@ -1075,6 +1075,91 @@
VG_(free)(chunks);
}
+void MC_(mempool_clear)(Addr pool, Addr addr, SizeT szB)
+{
+ MC_Mempool* mp;
+ MC_Chunk* mc;
+ ThreadId tid = VG_(get_running_tid)();
+ UInt n_shadows, i;
+ VgHashNode** chunks;
+
+ if (VG_(clo_verbosity) > 2) {
+ VG_(message)(Vg_UserMsg, "mempool_trim(0x%lx, 0x%lx, %ld)\n",
+ pool, addr, szB);
+ VG_(get_and_pp_StackTrace) (tid, MEMPOOL_DEBUG_STACKTRACE_DEPTH);
+ }
+
+ mp = VG_(HT_lookup)(MC_(mempool_list), (UWord)pool);
+ if (mp == NULL) {
+ MC_(record_illegal_mempool_error)(tid, pool);
+ return;
+ }
+
+ check_mempool_sane(mp);
+ chunks = VG_(HT_to_array) ( mp->chunks, &n_shadows );
+ if (n_shadows == 0) {
+ tl_assert(chunks == NULL);
+ return;
+ }
+
+ tl_assert(chunks != NULL);
+ for (i = 0; i < n_shadows; ++i) {
+
+ Addr lo, hi, min, max;
+
+ mc = (MC_Chunk*) chunks[i];
+
+ lo = mc->data;
+ hi = mc->szB == 0 ? mc->data : mc->data + mc->szB - 1;
+
+#define EXTENT_CONTAINS(x) ((addr <= (x)) && ((x) < addr + szB))
+
+ if (EXTENT_CONTAINS(lo) && EXTENT_CONTAINS(hi)) {
+
+ /* The current chunk is entirely inside the trim extent:
+ delete it. */
+
+ if (VG_(HT_remove)(mp->chunks, (UWord)mc->data) == NULL) {
+ MC_(record_free_error)(tid, (Addr)mc->data);
+ VG_(free)(chunks);
+ if (MP_DETAILED_SANITY_CHECKS) check_mempool_sane(mp);
+ return;
+ }
+
+ die_and_free_mem ( tid, mc, mp->rzB );
+
+ } else if ( (! EXTENT_CONTAINS(lo)) &&
+ (! EXTENT_CONTAINS(hi)) ) {
+
+ /* The current chunk is entirely outside the trim extent: keep
+ it. */
+
+ continue;
+
+ } else {
+
+ /* Remove any chunk that intersects. TODO this should only
remove the
+ * part of the chunks which intersects, so it works the same
way as
+ * trim */
+
+ if (VG_(HT_remove)(mp->chunks, (UWord)mc->data) == NULL) {
+ MC_(record_free_error)(tid, (Addr)mc->data);
+ VG_(free)(chunks);
+ if (MP_DETAILED_SANITY_CHECKS) check_mempool_sane(mp);
+ return;
+ }
+
+ die_and_free_mem ( tid, mc, mp->rzB );
+
+ }
+
+#undef EXTENT_CONTAINS
+
+ }
+ check_mempool_sane(mp);
+ VG_(free)(chunks);
+}
+
void MC_(move_mempool)(Addr poolA, Addr poolB)
{
MC_Mempool* mp;
Regards,
Varun Garg
|
|
From: Ivo R. <iv...@iv...> - 2017-08-14 14:20:28
|
Dear Valgrind users and developers, Valgrind source code repository has been migrated today successfully from Subversion to git SCM at sourceware.org. Valgrind www pages has been updated as well to reflect new situation. Repositories "valgrind" and "vex" should be treated as read-only from now on. All the development is now done with git at git://sourceware.org/git/valgrind.git: git clone git://sourceware.org/git/valgrind.git/ valgrind <edit/compile> git status/add/show git pull --rebase origin/master <build + test> git commit git show if you have write access, then: git remote set-url --push origin ssh://<username>@sourceware.org/git/valgrind.git/ git push There are a lot of good tutorials on simple git workflows, so please have a look. Bart prepared small GIT howto: https://sourceware.org/git/?p=valgrind.git;a=blob;f=docs/internals/git-HOWTO.txt If you are using something more complicated, please share with us and ideally send us a write up. Kind regards, I. |
|
From: Nicolas S. <nic...@ya...> - 2017-08-10 14:25:38
|
Hello, bonjour, I work with Valgrind 3.13. First of all this is a usefull tool ! I work with a big software and I have to ignore some large chucks of memory. In order to tell that to valgrind, I use --ignore-ranges. But my chucks of memory are too large for valgrind. I had a look to the code and some commits related to that function and I found : 348949 Bogus "ERROR: --ignore-ranges: suspiciously large range" which is the exact error message I have. When I have a look to the source (https://sourceforge.net/p/valgrind/mailman/message/34198705/) I see a constant (hardcoded value) : "UWord limit = 0x4000000; /* 64M - entirely arbitrary limit */" which defines the range limit. I am above this limit because my software uses big chucks of memory I have to ignore. I possibly misunderstand the code but could you tell me how I can overcome this problem ? I read the documentation and it is possible to drive valgrind through MACROS such as VALGRIND_{DISABLE,ENABLE}_ERROR_REPORTING_IN_RANGE so I think I can make a C program linked to valgrind that sets-up my ranges to be ignored by using the macro then do an exec of my program. Or change this limit in the source code and recompile valgrind on my own. Do you think it is a good idea to make this limit configurable if we need to increase it ? I look forward to discussing this proposal with you in more detail. Merci bien. Nicolas Sauvaget. |
|
From: Ivo R. <iv...@iv...> - 2017-08-06 20:35:20
|
2017-08-06 22:28 GMT+02:00 Rhys Kidd <rhy...@gm...>: > On 31 July 2017 at 07:47, Ivo Raisr <iv...@iv...> wrote: >> >> 2017-07-31 13:41 GMT+02:00 Rhys Kidd <rhy...@gm...>: >> > I plan this week on doing a quick check on macOS, primarily to ensure >> > there >> > are no issues that pop up with clang. >> >> Awesome! >> Let me know your findings. >> I. > > > Compile and regression suite tested on AMD64/Darwin (macOS 10.11, > clang-800.0.42.1). No new regressions seen with v13 of the patches. > > Looks good for the macOS platform. Thank you, Rhys! I. |
|
From: Rhys K. <rhy...@gm...> - 2017-08-06 20:28:38
|
On 31 July 2017 at 07:47, Ivo Raisr <iv...@iv...> wrote: > 2017-07-31 13:41 GMT+02:00 Rhys Kidd <rhy...@gm...>: > > I plan this week on doing a quick check on macOS, primarily to ensure > there > > are no issues that pop up with clang. > > Awesome! > Let me know your findings. > I. > Compile and regression suite tested on AMD64/Darwin (macOS 10.11, clang-800.0.42.1). No new regressions seen with v13 of the patches. Looks good for the macOS platform. |
|
From: Ivo R. <iv...@iv...> - 2017-08-05 20:56:50
|
2017-08-05 1:13 GMT+02:00 Mark Wielaard <ma...@kl...>: > On Fri, 2017-08-04 at 21:58 +0200, Mark Wielaard wrote: > >> > How the test migration was performed: >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > See recipes at https://github.com/ivosh/valgrind-git-migration >> >> I'll follow that to recreate the git repository with all branches >> and put it back on sourceware. > > That are some very nice instructions. Thanks! > It does take a while though and eats up lots of disk space. > > I didn't put the result on sourceware. Since I am not sure that wouldn't > screw up something. I placed a copy at: > https://code.wildebeest.org/git/user/mjw/valgrind/ > > Looking at the result it also doesn't have the svn/VEX_x_YY_BRANCHes I > assumed would be there. Looking at the migration steps I think they > weren't supposed to be? > > If so, then I didn't actually mess up and you might want to change Step > 16 to do a git gc --prune=now --aggressive. It really saves a lot of > space (and it gives everybody that git clones a much more compact > repository). > > You also might want to consider moving Step 15. Add SVN->GIT patches > after Step 17 verification. It causes the branches.diff to look scary. > > The diffs also get slightly confused by the empty VEX/docs directory. We > probably should remove that directory before/after migration. > > The tags.diff show a couple of "off by ones" (if you could call them > that). Which look mostly harmless (configure.ac version > with/without .SVN postfix and some copyright year updates), but for > 3.0.1, 3.2.3 and 3.4.1 they look slightly bigger. I haven't investigated > why yet. I am also not sure it really matters too much given how old > these tags are. The last 5 tags/releases look spot on perfect. Hi Mark, I incorporated all your suggestions to the latest migration recipe and refreshed https://sourceware.org/git/?p=valgrind.git. Thank you for going through this with me! I. |
|
From: Mark W. <ma...@kl...> - 2017-08-04 23:14:07
|
On Fri, 2017-08-04 at 21:58 +0200, Mark Wielaard wrote: > > How the test migration was performed: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > See recipes at https://github.com/ivosh/valgrind-git-migration > > I'll follow that to recreate the git repository with all branches > and put it back on sourceware. That are some very nice instructions. Thanks! It does take a while though and eats up lots of disk space. I didn't put the result on sourceware. Since I am not sure that wouldn't screw up something. I placed a copy at: https://code.wildebeest.org/git/user/mjw/valgrind/ Looking at the result it also doesn't have the svn/VEX_x_YY_BRANCHes I assumed would be there. Looking at the migration steps I think they weren't supposed to be? If so, then I didn't actually mess up and you might want to change Step 16 to do a git gc --prune=now --aggressive. It really saves a lot of space (and it gives everybody that git clones a much more compact repository). You also might want to consider moving Step 15. Add SVN->GIT patches after Step 17 verification. It causes the branches.diff to look scary. The diffs also get slightly confused by the empty VEX/docs directory. We probably should remove that directory before/after migration. The tags.diff show a couple of "off by ones" (if you could call them that). Which look mostly harmless (configure.ac version with/without .SVN postfix and some copyright year updates), but for 3.0.1, 3.2.3 and 3.4.1 they look slightly bigger. I haven't investigated why yet. I am also not sure it really matters too much given how old these tags are. The last 5 tags/releases look spot on perfect. Cheers, Mark |
|
From: Mark W. <ma...@kl...> - 2017-08-04 19:58:27
|
On Fri, Aug 04, 2017 at 08:14:19PM +0200, Ivo Raisr wrote: > Where I will find the new repo: > ~~~~~~~~~~~~~~~~~~~~~~~ > At sourceware.org. Precisely at: > git://sourceware.org/git/valgrind.git/ > http://sourceware.org/git/valgrind.git/ > Right now a snapshot of SVN sources as of 2017-06-26 is available for > you to test. I might have made a mistake by trying to compress the new git repository on the server with git gc --aggressive. I probably should have used git repack instead. It looks like the git gc pruned some VEX branches. I thought I was working on a copy, but I had copied a symlink to the bare git repository, not the directory itself... (It did seem to compress from 750MB down to 40MB, but if that means some branches were deleted that is not good of course...) > How the test migration was performed: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > See recipes at https://github.com/ivosh/valgrind-git-migration I'll follow that to recreate the git repository with all branches and put it back on sourceware. Apologies, Mark |
|
From: Ivo R. <iv...@iv...> - 2017-08-04 18:14:28
|
Dear Valgrind community, I am happy to announce that migration of Valgrind sources from existing Subversion SCM to modern git SCM will happen 14th August 2017. What is going on now? ~~~~~~~~~~~~~~~~~ The migration has been tested and all infrastructure is in place now. We still use the official SVN Valgrind repository for our work until 14th August 2017. If you have some patches ready now, send them for review. What will be migrated: ~~~~~~~~~~~~~~~~~ Valgrind and VEX sources. Precisely sources available today under svn://svn.valgrind.org/valgrind and svn://svn.valgrind.org/vex, including all production release branches and tags. Valgrind and VEX repos will be merged into one, so no more SVN externals. Where I will find the new repo: ~~~~~~~~~~~~~~~~~~~~~~~ At sourceware.org. Precisely at: git://sourceware.org/git/valgrind.git/ http://sourceware.org/git/valgrind.git/ Right now a snapshot of SVN sources as of 2017-06-26 is available for you to test. How the test migration was performed: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See recipes at https://github.com/ivosh/valgrind-git-migration What is the plan for the migration to go forward: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. The test repo is still available to test - see below for details. 2. The migration final date has been announced. 3. On the day of the migration, the following will happen: 4. Completely eradicate contents in the git repository at sourceware.org so the migration can start from scratch. 5. Switch SVN valgrind+vex repo readonly. 6. Perform the final migration to sourceware.org (takes several hours). 7. Enable email notifications from the new git repo. 8. Push website changes to SVN www repo (www repo is not migrated). What will not be migrated: ~~~~~~~~~~~~~~~~~~~~ - Valgrind www (website) repo. Not now, but later. - Non production release branches and tags from old SVN Valgrind+VEX repos. If you need to preserve some other branches or tags, let us know *now*: https://sourceware.org/git/?p=valgrind.git;a=heads https://sourceware.org/git/?p=valgrind.git;a=tags I have a write access to existing SVN repo. What shall I do for the new one? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please contact Julian Seward. He will point you to specific instructions. All developers with write access are required to subscribe their sourceware.org email account with valgrind-developers alias. I've sent the instructions separately - if you are missing them, let me know. What will be my simple workflow in new git SCM? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Not much will be changed from the way we worked in SVN. We still prepare patches, send them for review, have someone with write access to push them. A minimalistic workflow would be: git clone git://sourceware.org/git/valgrind.git/ valgrind edit/compile git status/add/show git pull --rebase origin/master build + test git commit git show if you have write access, then: git remote set-url --push origin ssh://<username>@sourceware.org/git/valgrind.git/ git push There are a lot of good tutorials on simple git workflows, so please have a look. Bart prepared small GIT howto: https://sourceware.org/git/?p=valgrind.git;a=blob;f=docs/internals/git-HOWTO.txt If you are using something more complicated, please share with us and ideally send us a write up. Kind regards, I. |
|
From: Ivo R. <ir...@so...> - 2017-08-03 11:50:45
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=b19899361b3a13d7c7dc71d2eccac862342e1200 commit b19899361b3a13d7c7dc71d2eccac862342e1200 Author: Ivosh Raisr <iv...@iv...> Date: Thu Aug 3 13:50:03 2017 +0200 Testing message for Valgrind source repository git migration. Please ignore for now but prepare yourself for the real migration to happen very soon. All necessary infrastructure should be in place now, including emails. Diff: --- NEWS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 062f870..7ec5560 100644 --- a/NEWS +++ b/NEWS @@ -23,7 +23,7 @@ X86/Solaris, AMD64/Solaris and AMD64/MacOSX 10.12. Valgrind is going to be migrated to git very soon. All infrastructure should be in place now, including emails. -That's a big NEWS! +That's really exciting news! * ==================== FIXED BUGS ==================== |
|
From: Ulrich T. <ulr...@ax...> - 2017-08-03 06:58:06
|
Hi Ivo & all, > Please if you know of any users interested in sparc64/Linux or > sparc64/Solaris Valgrind ports, let me know. We would like to > determine how much time and effort to put into developing and > maintaining them further in a foreseeable future. > > More information here: > http://valgrind.org/info/platforms.html At least I would be *very* happy if there would be a sparc64/Linux port. There are efforts to get the Debian sparc64 port into an offical release and a working valgrind is another tool you really want to have to track down release critical issues! Thanks for all the work on valgrind, CU, Uli Ulrich Teichert Diplominformatiker Resarch & Development Axion Technologies GmbH Oderstr. 47 24539 Neumünster Germany Phone: + 49- (0) 4321-75455-0 Fax: + 49- (0) 4321-75455-10 E-Mail: ulr...@ax... Web: www.axiontech.de Geschäftsführer: Avi Zisman, Carl Cassista Amtsgericht Kiel, HRB 1612 NM StNr.:2029810446 Ust.-ID-Nr.: DE201063418 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. |
|
From: Lionel C. <lio...@gm...> - 2017-08-02 18:02:05
|
On 2 August 2017 at 18:26, Ivo Raisr <iv...@iv...> wrote: > Dear Valgrind users, > > Please if you know of any users interested in sparc64/Linux or > sparc64/Solaris Valgrind ports, let me know. We would like to > determine how much time and effort to put into developing and > maintaining them further in a foreseeable future. Our development group at CERN would welcome valgrind&memcheck&cachegrind on SPARC64 a *LOT*. Preferably Illumos. Lionel |
|
From: Ivo R. <iv...@iv...> - 2017-08-02 16:26:18
|
Dear Valgrind users, Please if you know of any users interested in sparc64/Linux or sparc64/Solaris Valgrind ports, let me know. We would like to determine how much time and effort to put into developing and maintaining them further in a foreseeable future. More information here: http://valgrind.org/info/platforms.html Kind regards, I. |
Author: philippe
Date: Tue Aug 1 21:21:38 2017
New Revision: 16466
Log:
Various minor fixes and correction in user manual and monitor command help
Modified:
trunk/docs/xml/manual-core-adv.xml
trunk/gdbserver_tests/mssnapshot.stderrB.exp
trunk/helgrind/docs/hg-manual.xml
trunk/helgrind/hg_main.c
trunk/massif/docs/ms-manual.xml
trunk/massif/ms_main.c
trunk/memcheck/docs/mc-manual.xml
Modified: trunk/docs/xml/manual-core-adv.xml
==============================================================================
--- trunk/docs/xml/manual-core-adv.xml (original)
+++ trunk/docs/xml/manual-core-adv.xml Tue Aug 1 21:21:38 2017
@@ -1398,7 +1398,7 @@
<listitem>
<para><varname>xtmemory [<filename> default xtmemory.kcg.%p.%n]</varname>
- requests the tool to produce an xtree heap memory report.
+ requests the tool (Memcheck, Massif, Helgrind) to produce an xtree heap memory report.
See <xref linkend="manual-core.xtree"/> for
a detailed explanation about execution trees. </para>
</listitem>
Modified: trunk/gdbserver_tests/mssnapshot.stderrB.exp
==============================================================================
--- trunk/gdbserver_tests/mssnapshot.stderrB.exp (original)
+++ trunk/gdbserver_tests/mssnapshot.stderrB.exp Tue Aug 1 21:21:38 2017
@@ -23,6 +23,6 @@
saves all snapshot(s) taken so far in <filename>
default <filename> is massif.vgdb.out
xtmemory [<filename>]
- dump xtree memory profile in <filename> (default xtmemory.kcg)
+ dump xtree memory profile in <filename> (default xtmemory.kcg.%p.%n)
monitor command request to kill this process
Remote connection closed
Modified: trunk/helgrind/docs/hg-manual.xml
==============================================================================
--- trunk/helgrind/docs/hg-manual.xml (original)
+++ trunk/helgrind/docs/hg-manual.xml Tue Aug 1 21:21:38 2017
@@ -1401,6 +1401,12 @@
]]></programlisting>
</listitem>
+ <listitem>
+ <para><varname>xtmemory [<filename> default xtmemory.kcg.%p.%n]</varname>
+ requests Helgrind tool to produce an xtree heap memory report.
+ See <xref linkend="manual-core.xtree"/> for
+ a detailed explanation about execution trees. </para>
+ </listitem>
</itemizedlist>
Modified: trunk/helgrind/hg_main.c
==============================================================================
--- trunk/helgrind/hg_main.c (original)
+++ trunk/helgrind/hg_main.c Tue Aug 1 21:21:38 2017
@@ -4923,7 +4923,7 @@
" accesshistory <addr> [<len>] : show access history recorded\n"
" for <len> (or 1) bytes at <addr>\n"
" xtmemory [<filename>]\n"
-" dump xtree memory profile in <filename> (default xtmemory.kcg)\n"
+" dump xtree memory profile in <filename> (default xtmemory.kcg.%%p.%%n)\n"
"\n");
}
Modified: trunk/massif/docs/ms-manual.xml
==============================================================================
--- trunk/massif/docs/ms-manual.xml (original)
+++ trunk/massif/docs/ms-manual.xml Tue Aug 1 21:21:38 2017
@@ -888,6 +888,12 @@
<filename> (default massif.vgdb.out).
</para>
</listitem>
+ <listitem>
+ <para><varname>xtmemory [<filename> default xtmemory.kcg.%p.%n]</varname>
+ requests Massif tool to produce an xtree heap memory report.
+ See <xref linkend="manual-core.xtree"/> for
+ a detailed explanation about execution trees. </para>
+ </listitem>
</itemizedlist>
</sect1>
Modified: trunk/massif/ms_main.c
==============================================================================
--- trunk/massif/ms_main.c (original)
+++ trunk/massif/ms_main.c Tue Aug 1 21:21:38 2017
@@ -1598,7 +1598,7 @@
" saves all snapshot(s) taken so far in <filename>\n"
" default <filename> is massif.vgdb.out\n"
" xtmemory [<filename>]\n"
-" dump xtree memory profile in <filename> (default xtmemory.kcg)\n"
+" dump xtree memory profile in <filename> (default xtmemory.kcg.%%p.%%n)\n"
"\n");
}
Modified: trunk/memcheck/docs/mc-manual.xml
==============================================================================
--- trunk/memcheck/docs/mc-manual.xml (original)
+++ trunk/memcheck/docs/mc-manual.xml Tue Aug 1 21:21:38 2017
@@ -904,7 +904,7 @@
</itemizedlist>
<para>The increase or decrease for all events above will also be output in
- the file to provide the delta (increase or decreaseà between 2
+ the file to provide the delta (increase or decrease) between 2
successive leak searches. For example, <option>iRB</option> is the
increase of the <option>RB</option> event, <option>dPBk</option> is the
decrease of <option>PBk</option> event. The values for the increase and
@@ -2175,6 +2175,13 @@
</listitem>
+ <listitem>
+ <para><varname>xtmemory [<filename> default xtmemory.kcg.%p.%n]</varname>
+ requests Memcheck tool to produce an xtree heap memory report.
+ See <xref linkend="manual-core.xtree"/> for
+ a detailed explanation about execution trees. </para>
+ </listitem>
+
</itemizedlist>
</sect1>
|