You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(1) |
2
(4) |
3
|
4
(18) |
5
(20) |
6
(2) |
7
|
|
8
|
9
|
10
(6) |
11
|
12
(12) |
13
(3) |
14
(1) |
|
15
(2) |
16
(3) |
17
|
18
(9) |
19
(10) |
20
(18) |
21
(1) |
|
22
(10) |
23
(3) |
24
(25) |
25
(13) |
26
(2) |
27
(5) |
28
|
|
29
(1) |
30
(1) |
31
(6) |
|
|
|
|
|
From: sean y. <sea...@ho...> - 2006-10-05 18:55:07
|
it seems that this goup is not listed on groups.google. Why is that? It would be much useful if that happens based on my understanding. Thanks, Sean _________________________________________________________________ Add fun gadgets and colorful themes to express yourself on Windows Live Spaces http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://www.get.live.com/spaces/features |
|
From: Bob R. <bob...@co...> - 2006-10-05 18:42:42
|
On Thu, Oct 05, 2006 at 07:01:31PM +0100, Bryan Meredith wrote: > Bob Rossi wrote: > > On Sat, Sep 23, 2006 at 05:50:07PM +0100, Bryan Meredith wrote: > >> Fellow Valgrinders, > >> > >> please see http://www.brainmurders.eclipse.co.uk/omega.html for a > >> complete overview of what this tool can do for you! > >> > >> (We use this heavily at work - feel free to give it a spin...) > >> > >> As ever, I would welcome your comments, bug reports and especially any > >> news of success stories. Please share them with us on the list and copy > >> me in so I don't miss them. > > > > Hi, > > > > I just installed valgrind with omega support. valgrind was reporting a > > memory leak with the memcheck tool, and I spent a good 2 hours trying to > > figure out if it was a leak or not, cause I couldn't find WHERE it > > leaked. > > > > After running with the omega tool, I'm now confronted with 122 > > memory leaks, where as the memcheck was saying I only had 2. > > The results shouldn't be that different apart from the indirect leaks > will also be reported each time. If this isn't because of indirect leak > reporting, I have more work to do. Try running with "--instant-reports > --show-indirect" as this will make the indirect leaks stand out a bit > better. You might want to stick the output in a log file though :D Would it be possible to not print the indirect leaks via an option? > > It looks like omega is not honoring the suppressions when reporting > > on memory leaks, is this true? > > That is correct - I don't have suppression support in Omega. Any plans on adding this? Basically, there are some memory leaks in our tool that are not going away any time soon. It is sort of a pain for me to see them in the reports, cause it takes more time to sort through what is fixable now, and what is not fixable. Also, when our nigtly testsuite runs, when the suprressions are used, memcheck reports there are no memory leaks, which is really helpful. We can say if things passed or failed off of this. > > Can omega total the memory leaks that it found and report a number the > > way memcheck does? That number usually provides a "wow factor" to people > > explaining to there boss that they just stopped the coffee brewing > > network application from leaking 100 megs of memory each time a pot of > > coffee is brewed ... > > Happy to include this for you - it will be in RC2. Thanks! Bob Rossi |
|
From: Mohit T. <moh...@gm...> - 2006-10-05 18:18:14
|
Hello, I notice that running the floating point benchmarks (like ammp) takes a substantial time. (ammp took ~15min natively and 1.5 hrs using nulgrind) With Memcheck's ~50X overhead, it might take this 12.5 hrs to finish. Is there a way I can switch between native and valgrind executions of a program, so I could use a phase analyzing software like Simpoint to simulate only certain instructions. (A simulator like ptlsim can do such switching...) I saw in the tool_iface that any particular function can be wrapped around with macros to execute them natively, but is there a way I can insert switch_to_native() or switch_to_VG() calls in the profiled program's (like ammp) code? Thanks a lot, Mohit |
|
From: Julian S. <js...@ac...> - 2006-10-05 18:04:06
|
Committed, including your documentation stuff (r6196 and 6197). Thanks for that. At some point (no hurry) it would be good if you could confirm that a clean checkout of the trunk now works as you intend viz-a-viz mozilla's memory pools. J On Thursday 05 October 2006 18:45, Graydon Hoare wrote: > Julian Seward wrote: > > Looks fine. The only problem I can see is that you #included > > coregrind/pub_core_options.h into memcheck/mc_malloc_wrappers.c, > > which totally breaks the core/tool abstraction :-) Tools are > > only allowed to include pub_tool_*.h. > > > > But AFAICS it's only to provide debugging printing (for the mempools > > machinery itself) at -v -v and above. So how about if I just hardwire > > a fixed backtrace depth, say 16, in place of those uses of > > VG_(clo_backtrace_size) ? > > Sure. I was just trying to conform to house style; whatever works for you. > > -graydon |
|
From: Bryan M. <bra...@go...> - 2006-10-05 18:01:39
|
Bob Rossi wrote: > On Sat, Sep 23, 2006 at 05:50:07PM +0100, Bryan Meredith wrote: >> Fellow Valgrinders, >> >> please see http://www.brainmurders.eclipse.co.uk/omega.html for a >> complete overview of what this tool can do for you! >> >> (We use this heavily at work - feel free to give it a spin...) >> >> As ever, I would welcome your comments, bug reports and especially any >> news of success stories. Please share them with us on the list and copy >> me in so I don't miss them. > > Hi, > > I just installed valgrind with omega support. valgrind was reporting a > memory leak with the memcheck tool, and I spent a good 2 hours trying to > figure out if it was a leak or not, cause I couldn't find WHERE it > leaked. > > After running with the omega tool, I'm now confronted with 122 > memory leaks, where as the memcheck was saying I only had 2. The results shouldn't be that different apart from the indirect leaks will also be reported each time. If this isn't because of indirect leak reporting, I have more work to do. Try running with "--instant-reports --show-indirect" as this will make the indirect leaks stand out a bit better. You might want to stick the output in a log file though :D > > It looks like omega is not honoring the suppressions when reporting > on memory leaks, is this true? That is correct - I don't have suppression support in Omega. > > Also, I was only trying to fix the "definatly" lost instances of > memory leaks that memcheck found. Then I was going to turn on leak > checking in the nightly test suite. At that point, I could then continue > to fix the rest of the memory leaks memcheck found (ie. indirect lost). > > So, two more questions. > > Why does omega find so many more memory leaks than memcheck? > Are they real leaks or false positives? See above for indirect leak reporting. Apart from that, its hard to tell without having the source available in order to work out why Omega generated the leak report. > > Can omega total the memory leaks that it found and report a number the > way memcheck does? That number usually provides a "wow factor" to people > explaining to there boss that they just stopped the coffee brewing > network application from leaking 100 megs of memory each time a pot of > coffee is brewed ... Happy to include this for you - it will be in RC2. > > Thanks, > Bob Rossi > Thanks for taking the time to try my tool and tell me about it. Bryan |
|
From: Graydon H. <gr...@po...> - 2006-10-05 17:46:20
|
Julian Seward wrote: > Looks fine. The only problem I can see is that you #included > coregrind/pub_core_options.h into memcheck/mc_malloc_wrappers.c, > which totally breaks the core/tool abstraction :-) Tools are > only allowed to include pub_tool_*.h. > > But AFAICS it's only to provide debugging printing (for the mempools > machinery itself) at -v -v and above. So how about if I just hardwire > a fixed backtrace depth, say 16, in place of those uses of > VG_(clo_backtrace_size) ? Sure. I was just trying to conform to house style; whatever works for you. -graydon |
|
From: Julian S. <js...@ac...> - 2006-10-05 16:24:12
|
Looks fine. The only problem I can see is that you #included coregrind/pub_core_options.h into memcheck/mc_malloc_wrappers.c, which totally breaks the core/tool abstraction :-) Tools are only allowed to include pub_tool_*.h. But AFAICS it's only to provide debugging printing (for the mempools machinery itself) at -v -v and above. So how about if I just hardwire a fixed backtrace depth, say 16, in place of those uses of VG_(clo_backtrace_size) ? J On Saturday 09 September 2006 00:43, Graydon Hoare wrote: > Here's an update to the mempool move / change client requests and sanity > checking. The following changes are present: > > - Added one more (hopefully last) client request, a predicate to > test whether a mempool anchor address is currently tracked. > It turns out mozilla's arena-using code is sufficiently inconsistent > in its assumptions that it's very difficult to phrase the valgrind > client-request annotations without this request. Namely: sometime > arena-init and arena-free operations are assumed to be idempotent. > > - Fixed a very rapid tool-memory leak in the mempool sanity check > routine. The previous version of the patch I posted would use all > memory even on my Very Beefy Test Machine within ~15 minutes of > browsing with firefox. > > - Added a little logging code to print the counts of pools and chunks > active every ~10000 sanity checks, when running with -v. > > You'll also need to tack on this paragraph to the suggested mempool > client-request documentation I posted: > > VALGRIND_MEMPOOL_EXISTS(pool) > > This request informs the caller whether or not memcheck is currently > tracking a mempool at anchor address "pool". It evaluates to 1 when > there is a mempool associated with that address, 0 otherwise. This is a > rare request, only useful in circumstances when client code might have > lost track of the set of active mempools. > > Thanks, > > -graydon |
|
From: Modest B. <me...@dh...> - 2006-10-05 16:09:25
|
Hi, AMBhlEN VALhlUM VlAhGRA ClAhLIS Save 60 % with http://www.gosslide.info =20 _____ =20 life sentences. His grim voice grew even grimmer. But there is even impossible. He knew he couldnt tell me. But had been suspicious will never know that they have been in it. |
|
From: Bob R. <bob...@co...> - 2006-10-05 13:38:54
|
On Thu, Oct 05, 2006 at 02:36:39PM +0100, Julian Seward wrote:
>
> On Thursday 05 October 2006 14:21, Bob Rossi wrote:
> > On Thu, Oct 05, 2006 at 02:05:33PM +0100, Julian Seward wrote:
> > > > priv/main/vex_svnversion.h:1:1: missing terminating " character
> > > > priv/main/vex_svnversion.h:1:1: warning: no newline at end of file
> > >
> > > (cd VEX && make version) && make
> >
> > Apparently you can't build valgrind if subversion is not on your path.
> > Is this a known issue?
>
> The deal is: if you are building from an svn checkout then you
> are assumed to be a developer and so you need svn, svnversion,
> automake, autoconf to be available, not to mention tons of ugly
> XML toolchain gunk if you want to build the documentation.
>
> If you are building from a tarball you are assumed to be an end-user
> and none of those things are required for the build; everything
> needed is baked into the tarball at tarball-creation ("make dist")
> time.
OK, that's fair enough. I happened to check out valgrind like
PATH=/home/TOOLS/subversion/bin:$PATH svn co ...
and then make failed. It might be helpful to have a configure
check to make sure the svn tools required are on the path. However, it's
just a suggestion, and understand if no one wants to do that ...
Bob Rossi
|
|
From: Bob R. <bob...@co...> - 2006-10-05 13:37:17
|
On Sat, Sep 23, 2006 at 05:50:07PM +0100, Bryan Meredith wrote: > Fellow Valgrinders, > > please see http://www.brainmurders.eclipse.co.uk/omega.html for a > complete overview of what this tool can do for you! > > (We use this heavily at work - feel free to give it a spin...) > > As ever, I would welcome your comments, bug reports and especially any > news of success stories. Please share them with us on the list and copy > me in so I don't miss them. Hi, I just installed valgrind with omega support. valgrind was reporting a memory leak with the memcheck tool, and I spent a good 2 hours trying to figure out if it was a leak or not, cause I couldn't find WHERE it leaked. After running with the omega tool, I'm now confronted with 122 memory leaks, where as the memcheck was saying I only had 2. It looks like omega is not honoring the suppressions when reporting on memory leaks, is this true? Also, I was only trying to fix the "definatly" lost instances of memory leaks that memcheck found. Then I was going to turn on leak checking in the nightly test suite. At that point, I could then continue to fix the rest of the memory leaks memcheck found (ie. indirect lost). So, two more questions. Why does omega find so many more memory leaks than memcheck? Are they real leaks or false positives? Can omega total the memory leaks that it found and report a number the way memcheck does? That number usually provides a "wow factor" to people explaining to there boss that they just stopped the coffee brewing network application from leaking 100 megs of memory each time a pot of coffee is brewed ... Thanks, Bob Rossi |
|
From: Julian S. <js...@ac...> - 2006-10-05 13:36:54
|
On Thursday 05 October 2006 14:21, Bob Rossi wrote:
> On Thu, Oct 05, 2006 at 02:05:33PM +0100, Julian Seward wrote:
> > > priv/main/vex_svnversion.h:1:1: missing terminating " character
> > > priv/main/vex_svnversion.h:1:1: warning: no newline at end of file
> >
> > (cd VEX && make version) && make
>
> Apparently you can't build valgrind if subversion is not on your path.
> Is this a known issue?
The deal is: if you are building from an svn checkout then you
are assumed to be a developer and so you need svn, svnversion,
automake, autoconf to be available, not to mention tons of ugly
XML toolchain gunk if you want to build the documentation.
If you are building from a tarball you are assumed to be an end-user
and none of those things are required for the build; everything
needed is baked into the tarball at tarball-creation ("make dist")
time.
J
|
|
From: Bob R. <bob...@co...> - 2006-10-05 13:21:58
|
On Thu, Oct 05, 2006 at 02:05:33PM +0100, Julian Seward wrote: > > > priv/main/vex_svnversion.h:1:1: missing terminating " character > > priv/main/vex_svnversion.h:1:1: warning: no newline at end of file > > (cd VEX && make version) && make Apparently you can't build valgrind if subversion is not on your path. Is this a known issue? Thanks, Bob Rossi |
|
From: Julian S. <js...@ac...> - 2006-10-05 13:05:47
|
> priv/main/vex_svnversion.h:1:1: missing terminating " character > priv/main/vex_svnversion.h:1:1: warning: no newline at end of file (cd VEX && make version) && make J |
|
From: Bob R. <bob...@co...> - 2006-10-05 13:00:22
|
Hi,
I'm trying to compile valgrind svn with the omega patch. I just got this
error. Any ideas?
Thanks,
Bob Rossi
make all-recursive
make[1]: Entering directory `/home/USERS/bar/download/valgrind/valgrind'
Making all in include
make[2]: Entering directory `/home/USERS/bar/download/valgrind/valgrind/include'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/USERS/bar/download/valgrind/valgrind/include'
Making all in coregrind
make[2]: Entering directory `/home/USERS/bar/download/valgrind/valgrind/coregrind'
make all-am
make[3]: Entering directory `/home/USERS/bar/download/valgrind/valgrind/coregrind'
make -C ../VEX pub/libvex_guest_offsets.h
make[4]: Entering directory `/home/USERS/bar/download/valgrind/valgrind/VEX'
make[4]: `pub/libvex_guest_offsets.h' is up to date.
make[4]: Leaving directory `/home/USERS/bar/download/valgrind/valgrind/VEX'
for f in vgpreload_core-x86-linux.so ; do \
p=`echo $f | sed -e 's/^[^-]*-//' -e 's/\..*$//'`; \
n=`echo $f | sed -e 's/-[^-]\{1,\}-[^-.]\{1,\}//'`; \
mkdir -p ../.in_place/$p; \
rm -f ../.in_place/$p/$n; \
ln -f -s ../../coregrind/$f ../.in_place/$p/$n; \
done
make[3]: Leaving directory `/home/USERS/bar/download/valgrind/valgrind/coregrind'
make[2]: Leaving directory `/home/USERS/bar/download/valgrind/valgrind/coregrind'
Making all in .
make[2]: Entering directory `/home/USERS/bar/download/valgrind/valgrind'
mkdir -p ./.in_place
rm -f ./.in_place/default.supp ./.in_place/glibc-2.2.supp ./.in_place/glibc-2.3.supp ./.in_place/glibc-2.4.supp ./.in_place/xfree-3.supp ./.in_place/xfree-4.supp
ln -s ../default.supp ./.in_place
ln -s .././glibc-2.2.supp .././glibc-2.3.supp .././glibc-2.4.supp .././xfree-3.supp .././xfree-4.supp ./.in_place
make[2]: Leaving directory `/home/USERS/bar/download/valgrind/valgrind'
Making all in tests
make[2]: Entering directory `/home/USERS/bar/download/valgrind/valgrind/tests'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/USERS/bar/download/valgrind/valgrind/tests'
Making all in perf
make[2]: Entering directory `/home/USERS/bar/download/valgrind/valgrind/perf'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/USERS/bar/download/valgrind/valgrind/perf'
Making all in auxprogs
make[2]: Entering directory `/home/USERS/bar/download/valgrind/valgrind/auxprogs'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/USERS/bar/download/valgrind/valgrind/auxprogs'
Making all in memcheck
make[2]: Entering directory `/home/USERS/bar/download/valgrind/valgrind/memcheck'
Making all in .
make[3]: Entering directory `/home/USERS/bar/download/valgrind/valgrind/memcheck'
make -C ../VEX CC="gcc" libvex_x86_linux.a \
EXTRA_CFLAGS=" -mpreferred-stack-boundary=2 -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations "
make[4]: Entering directory `/home/USERS/bar/download/valgrind/valgrind/VEX'
gcc -Wall -Wmissing-prototypes -Wshadow -Winline -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wmissing-declarations -mpreferred-stack-boundary=2 -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -g -O2 -Ipub -Ipriv -o priv/main/vex_main.o \
-c priv/main/vex_main.c
In file included from priv/main/vex_main.c:86:
priv/main/vex_svnversion.h:1:1: missing terminating " character
priv/main/vex_svnversion.h:1:1: warning: no newline at end of file
make[4]: *** [priv/main/vex_main.o] Error 1
make[4]: Leaving directory `/home/USERS/bar/download/valgrind/valgrind/VEX'
make[3]: *** [../VEX/libvex_x86_linux.a] Error 2
make[3]: Leaving directory `/home/USERS/bar/download/valgrind/valgrind/memcheck'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/USERS/bar/download/valgrind/valgrind/memcheck'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/USERS/bar/download/valgrind/valgrind'
make: *** [all] Error 2
|
|
From: Bryan M. <bra...@go...> - 2006-10-04 22:23:15
|
Nicholas Nethercote wrote: > On Wed, 4 Oct 2006, Bryan Meredith wrote: > >> I have just moved ISP from eclipse to demon. Therefore, Omega is now >> hosted here: >> >> http://www.brainmurders.demon.co.uk/omega.html >> ----- >> >> Nick - would you update link on the patches page for me please? > > Sure. Do you want your email updated to the googlemail.com one above as > well? > > Nick > that would be great - thanks. Bryan |
|
From: Nicholas N. <nj...@cs...> - 2006-10-04 22:12:27
|
On Wed, 4 Oct 2006, Bryan Meredith wrote: > I have just moved ISP from eclipse to demon. Therefore, Omega is now > hosted here: > > http://www.brainmurders.demon.co.uk/omega.html > ----- > > Nick - would you update link on the patches page for me please? Sure. Do you want your email updated to the googlemail.com one above as well? Nick |
|
From: Nicholas N. <nj...@cs...> - 2006-10-04 22:09:58
|
On Wed, 4 Oct 2006, Janne Hellsten wrote:
> We do embedded development and have generally very limited amount of
> stack space available (4-8KB or so). Is it somehow possible to
> use valgrind to track how many bytes of stack is used during the
> execution of an application? Just getting the peak usage is enough
> for us. I remember trying to do it with massif, but IIRC I couldn't
> get fine-grained enough results out of it.
>
> Is this possible out of the box or should I look into patching say
> massif myself? If patching is the only option, what would be the best
> place to start?
Easier would be writing a new tool from scratch.
This probably sounds intimidating, but it shouldn't be. Use "nulgrind" (the
tool that does nothing) as the starting point, and have it register callback
functions for the "new_mem_stack" and "die_mem_stack" functions, which are
called every time the SP changes. See VG_(track_{new,die}_mem_stack) in
include/pub_tool_tooliface.h.
Nick
|
|
From: Bryan M. <bra...@go...> - 2006-10-04 21:42:23
|
Peter Nahas wrote: > Bryan Meredith wrote: >> Hmmm - stored size on the website is 30K, uncompressed size is ~100K. >> Did your browser/download tool decompress on the fly? > > I suppose it must have, though I've never seen it do that before. Wget > seems to get the gz version, but Opera tries to be smart. Oh well... > > > Anyway, I'm cross-compiling Omega for Linux on an embedded PPC, so > compiling o_main.c #errors out with "I know even less about PPC than x86 > -- please add appropriate registers" :~(. I presume there's no quick > fix or easy workaround? > > -Peter Nahas Nope - Omega is x86 and x86_64 only - I don't have the knowledge or the hardware to get it working on Power - sorry. If you fancy sending patches... Bryan |
|
From: Peter N. <pn...@mr...> - 2006-10-04 21:10:39
|
Bryan Meredith wrote: > Hmmm - stored size on the website is 30K, uncompressed size is ~100K. > Did your browser/download tool decompress on the fly? I suppose it must have, though I've never seen it do that before. Wget seems to get the gz version, but Opera tries to be smart. Oh well... Anyway, I'm cross-compiling Omega for Linux on an embedded PPC, so compiling o_main.c #errors out with "I know even less about PPC than x86 -- please add appropriate registers" :~(. I presume there's no quick fix or easy workaround? -Peter Nahas -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Bryan Meredith Sent: Wednesday, October 04, 2006 4:57 PM To: Peter Nahas Cc: val...@li... Subject: Re: [Valgrind-users] Omega - ReleaseCandidate 1 Announcement Peter Nahas wrote: >> I haven't had any feedback at all on this :( surely someone has tried > it and >> either it worked or it didn't? Please, post on the list so I know how > you got on. >=20 >=20 > Just giving this a try right now... THANK YOU!!! :D By the way, it seems that the patch > file isn't actually gziped despite the .gz in the filename.=20 >=20 > -Peter Nahas Hmmm - stored size on the website is 30K, uncompressed size is ~100K. Did your browser/download tool decompress on the fly? Bryan ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Bryan M. <bra...@go...> - 2006-10-04 20:57:26
|
Peter Nahas wrote: >> I haven't had any feedback at all on this :( surely someone has tried > it and >> either it worked or it didn't? Please, post on the list so I know how > you got on. > > > Just giving this a try right now... THANK YOU!!! :D By the way, it seems that the patch > file isn't actually gziped despite the .gz in the filename. > > -Peter Nahas Hmmm - stored size on the website is 30K, uncompressed size is ~100K. Did your browser/download tool decompress on the fly? Bryan |
|
From: Peter N. <pn...@mr...> - 2006-10-04 20:51:02
|
> I haven't had any feedback at all on this :( surely someone has tried it and=20 > either it worked or it didn't? Please, post on the list so I know how you got on. Just giving this a try right now... By the way, it seems that the patch file isn't actually gziped despite the .gz in the filename.=20 -Peter Nahas |
|
From: Bryan M. <bra...@go...> - 2006-10-04 20:40:42
|
Fellow Valgrinders, I have just moved ISP from eclipse to demon. Therefore, Omega is now hosted here: http://www.brainmurders.demon.co.uk/omega.html ----- Nick - would you update link on the patches page for me please? I haven't had any feedback at all on this :( surely someone has tried it and either it worked or it didn't? Please, post on the list so I know how you got on. Happy Hunting, Bryan "Brain Murders" Meredith |
|
From: Dirk M. <dm...@gm...> - 2006-10-04 20:12:34
|
On Wednesday, 4. October 2006 13:14, Nicholas Nethercote wrote: > Yes, it could be a very interesting project. It would also be a very > challenging one, certainly without any guarantee of a complete final > outcome, but maybe that isn't a problem. There is an easier one: implementing lockdep for valgrind: http://www.linuxhq.com/kernel/v2.6/18/Documentation/lockdep-design.txt This should be more or less straight forward, except for the locking order validation algorithm (for which white papers exist). Dirk |
|
From: Brad F. <bra...@gm...> - 2006-10-04 17:56:28
|
Thanks, Valgrind 3.2.1 worked like a charm! Not sure why I didn't think of trying it in the first place. Your suggestion is much appreciated, Brad On 10/4/06, Josef Weidendorfer <Jos...@gm...> wrote: > > On Monday 02 October 2006 19:40, Brad Fish wrote: > > vex x86->IR: unhandled instruction bytes: 0xDB 0x8D 0xF0 0xDB > > ==28501== valgrind: Unrecognised instruction at address 0x4390741. > > Have you checked with Valgrind 3.2.1? > If you get the same problem, please rise a bug report for it. > > > instruction. The only major change on my system since I ran valgrind on > this > > app successfully a few months ago was my recent switch to GCC 4.1 from > 3.4. > > My -march hasn't changed at all (prescott). > > That seems to be the reason. The autovectorizer (for using the SIMD > instructions, ie. SSEx) in gcc improved a lot in GCC 4.0/1, so probably > GCC 3.4 never produced the above instruction. > > Josef > |
|
From: Janne H. <ja...@hy...> - 2006-10-04 16:16:16
|
Hi all, We do embedded development and have generally very limited amount of stack space available (4-8KB or so). Is it somehow possible to use valgrind to track how many bytes of stack is used during the execution of an application? Just getting the peak usage is enough for us. I remember trying to do it with massif, but IIRC I couldn't get fine-grained enough results out of it. Is this possible out of the box or should I look into patching say massif myself? If patching is the only option, what would be the best place to start? Thank you so much for valgrind! Janne |