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
(4) |
2
|
|
3
(1) |
4
(3) |
5
(4) |
6
(1) |
7
(5) |
8
(5) |
9
(4) |
|
10
|
11
(1) |
12
(3) |
13
(3) |
14
(19) |
15
(8) |
16
|
|
17
|
18
(5) |
19
(9) |
20
(1) |
21
(17) |
22
(5) |
23
|
|
24
(2) |
25
(2) |
26
(1) |
27
(3) |
28
(3) |
29
(6) |
30
|
|
31
|
|
|
|
|
|
|
|
From: David L <id...@gm...> - 2009-05-14 05:09:37
|
With this code:
#include <stdio.h>
class MyClass {
public:
short int foo_ : 6;
};
int main(int argc, char *argv[]) {
MyClass *gce = new MyClass();
double d=0.0;
if (d == 0.0) {
printf("d equals zero.\n");
}
return 0;
}
I get this output from valgrind:
==32293== Conditional jump or move depends on uninitialised value(s)
==32293== at 0x804862F: main (main.cpp:11)
==32293== Uninitialised value was created by a heap allocation
==32293== at 0x400674E: operator new(unsigned int) (vg_replace_malloc.c:224)
==32293== by 0x8048610: main (main.cpp:9)
If I remove the : 6 from foo_, I don't get the error. Is this a valgrind bug?
Thanks,
David
|
|
From: Dallman, J. <joh...@si...> - 2009-05-13 14:53:39
|
> Now back to my problem. The original code has double instead of int (I > just tried both types to be sure and forgot to change back) and on MSVC > std::swap() of uninitialised doubles triggers a floating point > exception (if enabled) as MSVC uses the FPU. > > I was really surprised that the code crashes on Windows as it runs fine > under valgrind on Linux. This is a long-established quirk of Microsoft's compilers. They assume, rather more deeply than most people, that floating point traps will be turned off. -- John Dallman Parasolid Porting Engineer |
|
From: André W. <Woe...@on...> - 2009-05-13 14:22:58
|
On Wednesday 13 May 2009, Nicholas Nethercote wrote: > On Wed, May 13, 2009 at 2:43 AM, Colin Miller <col...@pi...> wrote: > > André Wöbbeking wrote: > > > > Valgrind only reports when an unused variable is used for > > flow-control (or, hopefuly I/O). > > > > Swapping doesn't trigger the alert. This is because, in C, > > structures can legitimately have > > uninitialised areas due to nested unions or padding. > > There's more on this in the manual. And this blog post discusses it > in even more detail: > > http://blog.mozilla.com/nnethercote/2009/02/27/eliminating-undefined- >values-with-valgrind-the-easy-way/ Thanks. Now back to my problem. The original code has double instead of int (I just tried both types to be sure and forgot to change back) and on MSVC std::swap() of uninitialised doubles triggers a floating point exception (if enabled) as MSVC uses the FPU. I was really surprised that the code crashes on WIndows as it runs fine under valgrind on Linux. Cheers, André |
|
From: Seán <sea...@gm...> - 2009-05-13 09:54:44
|
Robert, Fantastic! Valgrind now running with mpich, and returning meaningful results. A simple suppression file gets rid of a few extra errors associated with things like MPI_Init. R. Crockett wrote: > > Sean, > > I have encountered the same problem. The problem lies in how command-line > arguments are parsed. > > Have a look at the following webpage > > https://csd.vpac.org/twiki/bin/view/Tech/ParallelDebugging#Using_valgrind_with_MPICH_to_che > > which gives instructions on getting valgrind to work with mpich. The > upshot is that you will have to create a mpirun_dbg.valgrind shell script > that parses the command line arguments correctly. This may require a > little monkeying around with the script, like stripping of quotes and > such. > > Hope this helps, > Robert > > -- View this message in context: http://www.nabble.com/valgrind-and-MPI-wrappers-tp10324423p23518788.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-12 22:18:17
|
On Wed, May 13, 2009 at 2:43 AM, Colin Miller <col...@pi...> wrote: > André Wöbbeking wrote: > > Valgrind only reports when an unused variable is used for flow-control > (or, hopefuly I/O). > > Swapping doesn't trigger the alert. This is because, in C, structures > can legitimately have > uninitialised areas due to nested unions or padding. There's more on this in the manual. And this blog post discusses it in even more detail: http://blog.mozilla.com/nnethercote/2009/02/27/eliminating-undefined-values-with-valgrind-the-easy-way/ Nick |
|
From: Colin M. <col...@pi...> - 2009-05-12 16:44:37
|
André Wöbbeking wrote: > Hi, > > I'm using Valgrind 3.4.1 and I wonder why I don't get a warning for the > std::swap() call in the attached example. I get one in printf(). Is this > a bug? > > > Cheers, > André > > ------------------------------------------------------------------------ André, Valgrind only reports when an unused variable is used for flow-control (or, hopefuly I/O). Swapping doesn't trigger the alert. This is because, in C, structures can legitimately have uninitialised areas due to nested unions or padding. printf() uses flow-control to decide how many characters to print. HTH, Colin S. Miller |
|
From: André W. <Woe...@on...> - 2009-05-12 16:33:34
|
Hi, I'm using Valgrind 3.4.1 and I wonder why I don't get a warning for the std::swap() call in the attached example. I get one in printf(). Is this a bug? Cheers, André |
|
From: <dan...@in...> - 2009-05-11 16:30:11
|
Just to try something, see if it might bear relation to the allocator issue, try: -DGLIBCXX_FORCE_NEW if you are using gcc >= 3.4.x I know I used that define to prove a "leak" was not a leak in a much older Valgrind installation and added the info to my suppressions file. The current installation I use did not require it. ---Dan >From the Valgrind FAQ (http://www.valgrind.org/docs/manual/faq.html#faq.reports): 4. Valgrind behaves unexpectedly 4.1. My program uses the C++ STL and string classes. Valgrind reports 'still reachable' memory leaks involving these classes at the exit of the program, but there should be none. 4.2. The stack traces given by Memcheck (or another tool) aren't helpful. How can I improve them? 4.3. The stack traces given by Memcheck (or another tool) seem to have the wrong function name in them. What's happening? 4.4. My program crashes normally, but doesn't under Valgrind, or vice versa. What's happening? 4.1. My program uses the C++ STL and string classes. Valgrind reports 'still reachable' memory leaks involving these classes at the exit of the program, but there should be none. First of all: relax, it's probably not a bug, but a feature. Many implementations of the C++ standard libraries use their own memory pool allocators. Memory for quite a number of destructed objects is not immediately freed and given back to the OS, but kept in the pool(s) for later re-use. The fact that the pools are not freed at the exit() of the program cause Valgrind to report this memory as still reachable. The behaviour not to free pools at the exit() could be called a bug of the library though. Using gcc, you can force the STL to use malloc and to free memory as soon as possible by globally disabling memory caching. Beware! Doing so will probably slow down your program, sometimes drastically. With gcc 2.91, 2.95, 3.0 and 3.1, compile all source using the STL with -D__USE_MALLOC. Beware! This was removed from gcc starting with version 3.3. With gcc 3.2.2 and later, you should export the environment variable GLIBCPP_FORCE_NEW before running your program. With gcc 3.4 and later, that variable has changed name to GLIBCXX_FORCE_NEW. There are other ways to disable memory pooling: using the malloc_alloc template with your objects (not portable, but should work for gcc) or even writing your own memory allocators. But all this goes beyond the scope of this FAQ. Start by reading http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#4_4_leak if you absolutely want to do that. But beware: allocators belong to the more messy parts of the STL and people went to great lengths to make the STL portable across platforms. Chances are good that your solution will work on your platform, but not on others. fpga <mgb...@bl...> 05/04/2009 11:32 AM To val...@li... cc Subject [Valgrind-users] Does creating a stringstream object cause a leak #include "sstream" using namespace std; int main(){ stringstream ss; return 0; } Why does the above cause this 'bug'? ==4249== Invalid free() / delete / delete[] ==4249== at 0x40052EA: operator delete(void*, std::nothrow_t const&) (vg_replace_malloc.c:354) ==4249== by 0x5544058: std::__verify_grouping(char const*, unsigned, std::string const&) (locale_facets.cc:108) ==4249== by 0x5544F8C: std::locale::_Impl::_Impl(char const*, unsigned) (localename.cc:218) ==4249== by 0x554500C: std::locale::_Impl::_Impl(char const*, unsigned) (localename.cc:206) ==4249== by 0x5546137: std::locale::locale() (localename.cc:88) ==4249== by 0x5540B9B: std::ios_base::ios_base() (locale.cc:378) ==4249== by 0x557EAA4: std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >::basic_stringstream(std::_Ios_Openmode) (istream:586) ==4249== by 0x804863E: main (/home/me/Desktop/new_play/bug.cpp:4) ==4249== Address 0x55dd188 is not stack'd, malloc'd or (recently) free'd -- View this message in context: http://www.nabble.com/Does-creating-a-stringstream-object-cause-a-leak-tp23370849p23370849.html Sent from the Valgrind - Users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Luc B. <luc...@ma...> - 2009-05-09 20:32:32
|
On 9 May 2009, at 18:09, Julian Seward wrote: > >>> Could a kind soul at least tell me what rev I should check out from >>> the Darwin branch to get the support for stabs back? >> >> Ok, I found the culprit revision: r9586 > > Unfortunately, I don't think (backing out) this will help you. Even > before r9586, Valgrind's stabs reader gave nonsense results on Darwin. I have just done a series of experience with my code and indeed, you are right. I got fooled because I was examining a piece of code where the violations happen in code generated by hairy C macros and I put down to that the odd files and line numbers I got more often than not! Thanks for your prompt answer and thanks for actively supporting valgrind on MacOS X, it's really invaluable. Luc Bourhis |
|
From: Julian S. <js...@ac...> - 2009-05-09 16:05:57
|
> > Could a kind soul at least tell me what rev I should check out from > > the Darwin branch to get the support for stabs back? > > Ok, I found the culprit revision: r9586 Unfortunately, I don't think (backing out) this will help you. Even before r9586, Valgrind's stabs reader gave nonsense results on Darwin. This commit merely disabled the call to the stabs reader (amongst things). It seems that the stabs used by Darwin is somehow different from the stabs used by gcc on Linux, and there was some kind of compatibility problem reading it, although I don't know the details. J |
|
From: Luc B. <luc...@ma...> - 2009-05-09 13:57:42
|
> Could a kind soul at least tell me what rev I should check out from > the Darwin branch to get the support for stabs back? Ok, I found the culprit revision: r9586 r9586 | sewardj | 2009-04-23 13:50:16 +0200 (Thu, 23 Apr 2009) | 28 lines Major rewrite of readmacho.c: [...] * remove ability to read stabs-format info for Darwin; apparently stabs is deprecated [...] Deprecated but still supported even by gcc-4.2. And pretty much compulsory until Apple incorporate the patch for the bug I mentioned in my previous email. Luc Bourhis |
|
From: Luc B. <luc...@ma...> - 2009-05-09 12:40:19
|
Hello there,
it looks like the code currently on the DARWIN branch (I tried with
rev 9801) has dropped support for the stabs gdb format. E.g. the
following snippet:
#include <iostream>
int main() {
const int n = 16;
double *x = new double[n];
for (int i=0; i<n; ++i) x[i] = i;
for (int i=1; i<n; ++i) x[i] = (x[i-1] + x[i] + x[i+1])/3;
std::cout << "| ";
for (int i=0; i<n; ++i) std::cout << x[i] << " | ";
std::cout << "\n";
return 0;
}
and issuing the following on the command line:
~/Developer/Tests> g++ -o valgrind_tst -g2 -gstabs+ valgrind_tst.cpp
~/Developer/Tests> valgrind ./valgrind_tst
[...]
--29353-- ./valgrind_tst:
--29353-- dSYM directory is missing; consider using --auto-run-
dsymutil=yes
[...]
So I ran it again with the suggested option:
~/Developer/Tests> valgrind --auto-run-dsymutil=yes ./valgrind_tst
[...]
--29411-- run: /usr/bin/dsymutil ./valgrind_tst
warning: no debug symbols in executable (-arch i386)
==29411== Invalid read of size 8
==29411== at 0x1DE5: main (in ./valgrind_tst)
That means that Dwarf is now compulsory, doesn't it?
I know that stabs is pretty old and that Apple has officially moved to
dwarf a while ago but then there is bug 27574 which used to plague gcc
4.1/4.2 before it was fixed on the GNU repositories. However Apple has
not integrated that patch to the gdb they ship even with the latest
XCode (3.1). As a result, I am pretty much forced to use stabs because
not being able to inspect variables in constructors is too crippling.
Could a kind soul at least tell me what rev I should check out from
the Darwin branch to get the support for stabs back?
Thanks a bunch,
Luc Bourhis
|
|
From: Theodoros V. K. <th...@gm...> - 2009-05-08 20:54:36
|
On Fri, 8 May 2009, Julian Seward wrote: > I'm not convinced it's really possible. The basic problem is that, due > to how the compiler generates code, the last pointer to a block can be > overwritten at some place which is arbitrarily far away (but in the same > procedure) from where it is overwritten in the source, thus leading to a > nonsensical error report. Hmm, after my little leak-hunting expedition this week, I'd settle even for a tool that shows where any pointer (not just the last) to a block is overwritten. Or maybe the last N pointers that were lost. It would be better than nothing... I actually tried valgrind-3.3.0 and omega. The produced information was not really useful, partly because of the structure of the tested program and partly because of the fact that any accidentally left-over pointer will cover up the leak. I won't even go to the impediments the compiler introduces. I am now thinking that knowing where a particular block was last used might be a tad more useful than the location of the actual leak. > If you can devise a scheme that works reliably in the presence of spilling > (viz, stack loads/stores introduced invisibly by the compiler) then you might > be heading in a good direction. That was one of my main problems with gcc. For example, even with -O0 static functions would still disappear, as if they were macros. Several variables would only be registers or promptly disappear as well. It was surpsingly difficult to figure out in some cases. Perhaps we should attempt to convince the GCC people to have an --I-mean-it-really-do-not-optimize flag. Cheers, Theodoros |
|
From: Julian S. <js...@ac...> - 2009-05-08 07:08:38
|
On Friday 08 May 2009, Theodoros V. Kalamatianos wrote:
> On Fri, 8 May 2009, Nicholas Nethercote wrote:
> > This paper is related too:
> >
> > author = {Jonas Maebe and Michiel Ronsse and Koen De Bosschere},
> > title = {Precise detection of memory leaks},
> > booktitle = {Proceedings of the Second International Workshop on
> > Dynamic Analysis (WODA 2004)},
> > pages = {},
> > address = {Edinburgh, Scotland},
> > month = may,
> > year = 2004,
>
> I'll have a look at it.
>
> > In general, what you are proposing is possible, but it's not easy, is
> > really slow and would be lots of extra code in Memcheck.
I'm not convinced it's really possible. The basic problem is that,
due to how the compiler generates code, the last pointer to a block
can be overwritten at some place which is arbitrarily far away (but
in the same procedure) from where it is overwritten in the source,
thus leading to a nonsensical error report.
How can this happen? Imagine a procedure P which is quite large, and
a block B. Relatively early in P, there is high register pressure and
so a copy of the pointer to B written to a spill slot. A bit further
along, the last pointer to B is overwritten in the source level, but
the tool makes no comment because there's a copy in the spill slot.
Then further along in P, a different value is written into the spill slot.
At this point, the tool complains, but the source location is completely
wrong. What's more, because it's a spill store, there may not even be
any source level store for the user to see, at the stated source line.
I would be interested to hear if the authors of the abovementioned paper
managed to solve this problem.
If you can devise a scheme that works reliably in the presence of spilling
(viz, stack loads/stores introduced invisibly by the compiler) then you might
be heading in a good direction.
J
|
|
From: Nicholas N. <n.n...@gm...> - 2009-05-08 06:10:13
|
On Fri, May 8, 2009 at 3:06 PM, Theodoros V. Kalamatianos <th...@gm...> wrote: >> >> In general, what you are proposing is possible, but it's not easy, is >> really slow and would be lots of extra code in Memcheck. > > What if it was done in two passes? Run memcheck normally, and then re-run > valgrind repeatedly in order to track a specific memory leak each time. You > could say e.g. --tool=analyse-leak --with-alloc=foo.c:111 and have valgrind > track those pointers only. Could we exploit that to make things easier > speed-wise and coding-wise? Two passes introduces problems of its own -- it's great if you have a totally deterministic program, otherwise you're in trouble. Or you can use deterministic replay techniques but that's more complication. > IMO when you _know_ you have a problem, a slower but effective valgrind is > definitely acceptable. Of course. My broader point is that there's an enormous difference between proposing something and implementing it, especially when the proposal is ambitious. Nick |
|
From: Theodoros V. K. <th...@gm...> - 2009-05-08 05:06:37
|
On Fri, 8 May 2009, Nicholas Nethercote wrote:
> This paper is related too:
>
> author = {Jonas Maebe and Michiel Ronsse and Koen De Bosschere},
> title = {Precise detection of memory leaks},
> booktitle = {Proceedings of the Second International Workshop on Dynamic
> Analysis (WODA 2004)},
> pages = {},
> address = {Edinburgh, Scotland},
> month = may,
> year = 2004,
I'll have a look at it.
> In general, what you are proposing is possible, but it's not easy, is
> really slow and would be lots of extra code in Memcheck.
What if it was done in two passes? Run memcheck normally, and then re-run
valgrind repeatedly in order to track a specific memory leak each time.
You could say e.g. --tool=analyse-leak --with-alloc=foo.c:111 and have
valgrind track those pointers only. Could we exploit that to make things
easier speed-wise and coding-wise?
IMO when you _know_ you have a problem, a slower but effective valgrind is
definitely acceptable.
Cheers,
Theodoros
|
|
From: Theodoros V. K. <th...@gm...> - 2009-05-08 04:56:35
|
On Thu, 7 May 2009, John Reiser wrote: >> - The last place where a pointer to a block was clobbered/lost, which >> is a probable location for the actual leak > > Search the Web for "valgrind omega". Ouch, it's even in the valgrind distribution, although disabled by default and undocumented in the wiki. And Google is almost impossible to get to come up with it. The implementation is similar to my thoughts, but in a working stage. I guess I had already suspected what I proposed was not all that new :-) Yes, this does seem to be exactly what I had in mind, although it does not seem to provide the "last-used-at" location, which might also be very useful. I'll see if I can try it out. The main issue is that omega seems to be collecting quite a bit of dust now. Pity... Regards, Theodoros Kalamatianos |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-07 22:49:40
|
On Fri, May 8, 2009 at 12:49 AM, John Reiser <jr...@bi...> wrote:
>> - The last place where a pointer to a block was clobbered/lost, which is a
>> probable location for the actual leak
>
> Search the Web for "valgrind omega".
This paper is related too:
author = {Jonas Maebe and Michiel Ronsse and Koen De Bosschere},
title = {Precise detection of memory leaks},
booktitle = {Proceedings of the Second International Workshop on Dynamic
Analysis (WODA 2004)},
pages = {},
address = {Edinburgh, Scotland},
month = may,
year = 2004,
In general, what you are proposing is possible, but it's not easy, is
really slow and would be lots of extra code in Memcheck.
Nick
|
|
From: John R.
|
> - The last place where a pointer to a block was clobbered/lost, which is a > probable location for the actual leak Search the Web for "valgrind omega". -- |
|
From: Seán <sea...@gm...> - 2009-05-07 14:06:12
|
Seán wrote: > > I seem to have the same problem. > I have solved my initial problem. It was caused by interference of another valgrind version already installed. I did a "complete remove" using synaptic, instead of the "remove" I had previously tried. I now have libmpiwrap.so installed in the directory /usr/local/lib/valgrind/x86-linux/libmpiwrap.so. I am trying to run an MPI HelloWorld program with valgrind. I am not getting the expected output "valgrind MPI wrappers 31901: Active for pid 31901" . Instead I get: sean@seanscomputer:~/CODE$ LD_PRELOAD=/usr/local/lib/valgrind/x86-linux/libmpiwrap.so mpirun -np 2 /usr/local/bin/valgrind ./main ==2869== Memcheck, a memory error detector. ==2869== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==2869== Using LibVEX rev 1884, a library for dynamic binary translation. ==2869== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==2869== Using valgrind-3.4.1, a dynamic binary instrumentation framework. ==2869== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==2869== For more details, rerun with: -v ==2869== valgrind: seanscomputer: command not found p0_2869: p4_error: Child process exited while making connection to remote process on localhost: 0 ==2869== Conditional jump or move depends on uninitialised value(s) ...... Does anyone know what that "valgrind: hostname: command not found" error is? -- View this message in context: http://www.nabble.com/valgrind-and-MPI-wrappers-tp10324423p23427517.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: Seán <sea...@gm...> - 2009-05-07 10:34:00
|
Bugzilla from js...@ac... wrote:
>
>
> - Did it successfully build $prefix/lib/valgrind/<platform>/libmpiwrap.so
> ?
>
>
I seem to have the same problem. ./configure does find a usable mpicc
(though the "secondary target" seems to fail ????)
configure:8693: checking primary target for usable MPI2-compliant C compiler
and mpi.h
configure:8722: mpicc -o conftest -m32 conftest.c >&5
configure:8728: $? = 0
configure:8732: test -z
|| test ! -s conftest.err
configure:8735: $? = 0
configure:8738: test -s conftest
configure:8741: $? = 0
configure:8745: result: yes, mpicc
configure:8778: checking secondary target for usable MPI2-compliant C
compiler and mpi.h
configure:8811: mpicc this will surely fail -o conftest conftest.c >&5
cc: this: No such file or directory
cc: will: No such file or directory
cc: surely: No such file or directory
cc: fail: No such file or directory
configure:8817: $? = 1
configure: failed program was:
| /* confdefs.h. */
The directory /usr/lib/valgrind/ only contains 1 file, python.supp, and I
cant find libmpiwrap.so anywhere on my system.
Here is my http://www.nabble.com/file/p23424032/config.log config.log
Any help greatly appreciated. Sorry if this is a double post.
--
View this message in context: http://www.nabble.com/valgrind-and-MPI-wrappers-tp10324423p23424032.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.
|
|
From: Theodoros V. K. <th...@gm...> - 2009-05-07 06:09:05
|
Hi, I apologise beforehand if this has been discussed before, but in the list archives I only found a 2005 2-message thread that went nowhere. I do not have any experience with the Valgrind code, so if I sound ignorant it's probably because I am :-) I just spent two days trying to find a memory leak, even with valgrind. The program (not my code, thank goodness) was so convoluted that it was nearly impossible to keep track of the allocated block pointers, since they would be suffled back and forth between some stack-like structures as the thing worked. I thought it would very helpful if Valgrind could provide one or both of the following: - The last place in the program where a pointer to a particular block was used. I think this would be useful for people wishing to fine-tune their memory usage in general. It would also show a candidate location for that missing free()... - The last place where a pointer to a block was clobbered/lost, which is a probable location for the actual leak As for the implementation (warning: rampant ignorance ahead), it seems to me that something similar to the valid-value tracking mechanism could be used: - have a bitmap (P-bits ?) that marks certain addresses as pointers. - when a block is allocated, mark the location of the returned pointer in the bitmap. - when a pointer is copied, adjust the bitmap to include the new address. - when a pointer is used mark the place in the block metadata. This might be more accurate if any access to a block was tracked in general. - when the stack is adjusted/blocks freed/etc check all marked locations and update the metadata for any blocks that lost a pointer. If we had a pointer counter it might even be possible to detect memory leaks on the fly. - same for any clobbered pointers. No idea how to deal with the common ptr++ case. Maybe show this info only for definitely lost blocks ? Then corroborate the info collected above with the definite/potential loss info to increase accuracy (maybe for both ?). I understand that this could be quite slow, but I think it would be worth it. Even a slowdown similar to the one induced by --track-origins=yes would be acceptable IMO. And it could always be optional... Does this sound stupid or doable ? Regards, Theodoros Kalamatianos |
|
From: fpga <mgb...@bl...> - 2009-05-05 14:26:00
|
Versions are $ valgrind --version valgrind-3.3.0 $ g++ --version g++ (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7) Thanks for confirming that your g++ configurations run ok and for the supression tip. Yum won't let me upgrade further. Maybe I'll change OS' -- View this message in context: http://www.nabble.com/Does-creating-a-stringstream-object-cause-a-leak-tp23370849p23388130.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: Nicholas N. <n.n...@gm...> - 2009-05-05 12:16:25
|
On Tue, May 5, 2009 at 8:10 PM, Roberto Diaz <rdi...@gm...> wrote: > Hello everybody. > > I am trying to fully understand massif results.. I have the following code: You are using an older version of Massif. It was changed in recent releases, and the results are easier to understand. I recommend upgrading. Nick |
|
From: Roberto D. <rdi...@gm...> - 2009-05-05 10:10:16
|
Hello everybody.
I am trying to fully understand massif results.. I have the following code:
#include <string>
#include <unistd.h>
std::string *giveLargeObject ()
{
return new std::string
("341234123412341234123412341234dfasfasdfassdfasdfasdfasdfasdfasdfasdfasdfasdfasdfaqddfasd");
}
int
main ()
{
std::string *stringArray [100];
for (unsigned int i = 0; i < 100; ++i)
stringArray [i] = giveLargeObject ();
sleep (1);
for (unsigned int i = 0; i < 100; ++i)
delete stringArray[i];
return 0;
}
massif outputs the following:
== 0 ===========================
Heap allocation functions accounted for 53.1% of measured spacetime
Called from:
51.1% : 0x40D9FFA: std::string::_Rep::_S_create(unsigned, unsigned,
std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.8)
2.0% : 0x8048667: giveLargeObject() (massif1.cc:8)
== 1 ===========================
Context accounted for 51.1% of measured spacetime
0x40D9FFA: std::string::_Rep::_S_create(unsigned, unsigned,
std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.8)
Called from:
51.1% : 0x40DAE14: (within /usr/lib/libstdc++.so.6.0.8)
---------------------------------
Context accounted for 2.0% of measured spacetime
0x8048667: giveLargeObject() (massif1.cc:8)
Called from:
2.0% : 0x80486FB: main (massif1.cc:17)
what I dont understand at all is that 2.0% accounted for giveLargeObject
()...I understand more heap memory its being allocated from
std::string::string constructor.. where else is consumed that 2.0% of heap
allocation?
I also dont understand at all the postscript output .. the fringe called
"stack(s)".. what massif means as stack? it is not supposed to be a heap
profiler?
Thanks in advance
Roberto.
|