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
(2) |
2
(6) |
3
|
4
|
|
5
|
6
(3) |
7
|
8
|
9
|
10
|
11
(4) |
|
12
(6) |
13
(6) |
14
(17) |
15
(1) |
16
(4) |
17
(6) |
18
|
|
19
(5) |
20
(7) |
21
(3) |
22
(8) |
23
(4) |
24
(8) |
25
(2) |
|
26
(1) |
27
(19) |
28
(5) |
29
(3) |
30
(11) |
31
(6) |
|
|
From: Ivan N. <nov...@gm...> - 2009-07-14 19:22:02
|
Hi, I am getting: WARNING: unhandled syscall: 142 My machine is Ubuntu: Linux paloalto 2.6.27-9-generic #1 SMP Thu Nov 20 22:15:32 UTC 2008 x86_64 GNU/Linux Is system call 142 handled in the most recent codebase of valgrind? Thank you, Ivan |
|
From: Zachary T. <div...@gm...> - 2009-07-14 18:20:33
|
On Tue, Jul 14, 2009 at 1:07 PM, Colin Miller<col...@pi...> wrote:
> Zachary Turner wrote:
>>
>> On Tue, Jul 14, 2009 at 12:27 PM, Colin Miller<col...@pi...>
>> wrote:
>>
>> ==7439== Use of uninitialised value of size 4
>> ==7439== at 0x82D32D6: _int_malloc (in /usr/sbin/snip/bin/snip)
>> ==7439== by 0x82D4E3A: malloc (in /usr/sbin/snip/bin/snip)
>> ==7439== by 0x82992E6: operator new(unsigned) (in
>> /usr/snip/snip/bin/snip)
>> ==7439== by 0x827945A: std::string::_Rep::_S_create(unsigned,
>> unsigned, std::allocator<char> const&) (in /usr/sbin/snip/bin/snip)
>> ==7439== by 0x8279D5C:
>> std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned) (in
>> /usr/snip/snip/snip/snip)
>> ==7439== by 0x827A659: std::string::reserve(unsigned) (in
>> /usr/sbin/snip/bin/snip)
>> ==7439== by 0x827A77C: std::string::append(unsigned, char) (in
>> /usr/sbin/snip/bin/snip)
>> ==7439== by 0x827B80F: std::string::resize(unsigned) (in
>> /usr/sbin/snip/bin/snip)
>> ==7439== by 0x80D8153: Foo::Foo(x&, y const&) (Foo.cpp:147)
>> ==7439== by 0x80D4C96: Foo::foi(x&, y const&) (Foo.cpp:234)
>> ==7439== by 0x80D7006: Foo::foj(RsaKeyInfo&) (Foo.cpp:60)
>> ==7439== by 0x80CF313: Bar::Baz() (Bar.cpp:141)
>>
>>
>> The first few all have their roots in libc, and the last one, while it
>> does at least have my code on the callstack, is really nothing
>> special. For example, Foo::Foo (Foo.cpp:147) listed above is
>> basically just the following:
>>
>> class Foo
>> {
>> Foo(x&, const y)
>> {
>> std::stringstream input_buf;
>> //initialize input_buf using whatever method
>>
>> unsigned short length;
>> input_buf.read((char*)&length, sizeof(length));
>> length = ntohs(length);
>> str_.resize(length);
>> }
>> private:
>> std::string str_;
>> };
>>
>>
>
> It's been a while since I've done C++,
> but IIRC, the stream input_buf hasn't had a string associated with it.
> Therefore the read() will read 0 bytes,
> and the variable 'length'
> with be uninitialised
>
> Now assuming that this is just an artefact of stripping the code for display
> here,
> it might be worthwhile calling
> |VALGRIND_CHECK_MEM_IS_DEFINED(length, 4)
> just before the resize(length).
> Prototype is in valgrind/memcheck.h
>
> This will verify that 'length' has been properly initialised.
>
> HTH,
> Colin S. Miller
Thanks! I'll definitely give that a shot, I didn't know about that.
I don't guess this could have anything to do with converting smaller
types to larger types could it? For example, above I've defined
length as a 2-byte value, but then passing it (by value) to a function
which takes a 4-byte value.
Also, for what it's worth, the value _is_ actually uninitialized
except that I pass it to that input_buf.read() method by pointer which
does raw modification of the memory. Is valgrind able to detect this?
In other words, how much dynamic analysis is it actually doing? Is
it actually detecting writes to individual bytes of memory and then
tagging each byte as 'dirty', and verifying for every read that
occurs, that every byte being read from is dirty?
Suppose, for example, that I do the following:
//Process 1
//1. Map a 256-byte region in shared memory.
//2. Wait on a shared condition variable.
//3. Read 256-bytes from the shared memory
//Process 2
//1. Map the same 256-byte region in shared memory.
//2. Write 256-bytes into the shared memory
//3. Signal the shared condition variable
Will valgrind correctly note in this case that the data is
initialized? I bring up this specific scenario because this way
valgrind presumably has no correlation between the two process's
source codes / debug information and would be unable to perform any
static analysis whatsoever. Whereas the example I'm actually
encountering above with the length variable is the same in the sense
that it's relying on non-type-safe, external memory modification, but
it could still in theory be detected with some static analysis.
Also, any suggestions about the libc errors? Those don't have any of
my code on the stack at all. (I'm also not using the most recent
version of Valgrind, I'm using 3.1.x, is there a huge difference?)
|
|
From: Zachary T. <div...@gm...> - 2009-07-14 17:49:00
|
On Tue, Jul 14, 2009 at 12:27 PM, Colin Miller<col...@pi...> wrote: > Zachary Turner wrote: >> Hello, >> >> I'm somewhat a valgrind noob, so apologies if this is a RTFM question. >> I did search around however and did not see anything definitive about >> this. I ran valgrind on an app I have and it generated thousands of >> spurious warnings. I know I can create a .supp file to suppress these, >> but my question is how do I know which ones are spurious and which >> ones are not? I found one website that mentioned that there was a >> .supp file somewhere in the valgrind code repository, but for some >> reason I cannot access the SVN repository. I'm using the correct SVN >> url (svn://svn.valgrind.org/valgrind/trunk), shown on the website at >> (http://www.valgrind.org/downloads/repository.html) but it just says >> the server timed out or did not respond appropriately. I've never had >> any problem accessing other svn repositories. >> >> Is there a way to tell which warnings are spurious to easily disable >> them, or is this .supp file which I can't seem to currently access the >> correct approach? 95% of the errors I get are either "Use of >> uninitialised value of size 4" (usually in _int_malloc, memcpy, or >> malloc_consolidate), and "Conditional jump or move depends on >> uninitialized value" (in anything have to do with static variable >> initialization / cleanup, etc). >> >> > The short answer is *ALL* Valgrind reports are errors, and should be > fixed. > (with the possible exception of leaked reachable memory). > > Suppressions are there for reports inside third-party code that you > can't fix. > > Valgrind comes with a set of suppressions for some standard libraries > with are known to be buggy. > > Running > valgrind -v /bin/true > should print out the default suppressions that valgrind is using > > > The lack of line numbers means the library does not have debug > information with it. > For Debian, try installing > libstdc++*-dbg and libc6-dbg > > > HTH, > Colin S. Miller Hi, thanks for the info about the debug libraries. Regarding your point about fixing all errors, I get thousands of errors that happen during process initialization. Just to give a couple examples: ==7373== Syscall param set_robust_list(head) points to uninitialised byte(s) ==7373== at 0x82A8C61: __pthread_initialize_minimal (in /usr/sbin/snip/bin/snip) ==7373== by 0x82A8FCC: (below main) (in /usr/sbin/snip/bin/snip) ==7373== Address 0x83FC898 is not stack'd, malloc'd or (recently) free'd ==7373== Conditional jump or move depends on uninitialised value(s) ==7373== at 0x82EA155: __register_atfork (in /usr/sbin/snip/bin/snip) ==7373== by 0x82EA26A: __libc_pthread_init (in /usr/sbin/snip/bin/snip) ==7373== by 0x82A8E19: __pthread_initialize_minimal (in /usr/sbin/snip/bin/snip) ==7373== by 0x82A8FCC: (below main) (in /usr/sbin/snip/bin/snip) ==7373== Conditional jump or move depends on uninitialised value(s) ==7373== at 0x82D4E22: malloc (in /usr/sbin/snip/bin/snip) ==7373== by 0x82D4DE7: malloc (in /usr/sbin/snip/bin/snip) ==7373== by 0x830A5DB: _dl_init_paths (in /usr/sbin/snip/bin/snip) ==7373== by 0x82ED78B: _dl_non_dynamic_init (in /usr/sbin/snip/bin/snip) ==7373== by 0x82EE065: __libc_init_first (in /usr/sbin/snip/bin/snip) ==7373== by 0x82A9050: (below main) (in /usr/sbin/snip/bin/snip) ==7439== Use of uninitialised value of size 4 ==7439== at 0x82D32D6: _int_malloc (in /usr/sbin/snip/bin/snip) ==7439== by 0x82D4E3A: malloc (in /usr/sbin/snip/bin/snip) ==7439== by 0x82992E6: operator new(unsigned) (in /usr/snip/snip/bin/snip) ==7439== by 0x827945A: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (in /usr/sbin/snip/bin/snip) ==7439== by 0x8279D5C: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned) (in /usr/snip/snip/snip/snip) ==7439== by 0x827A659: std::string::reserve(unsigned) (in /usr/sbin/snip/bin/snip) ==7439== by 0x827A77C: std::string::append(unsigned, char) (in /usr/sbin/snip/bin/snip) ==7439== by 0x827B80F: std::string::resize(unsigned) (in /usr/sbin/snip/bin/snip) ==7439== by 0x80D8153: Foo::Foo(x&, y const&) (Foo.cpp:147) ==7439== by 0x80D4C96: Foo::foi(x&, y const&) (Foo.cpp:234) ==7439== by 0x80D7006: Foo::foj(RsaKeyInfo&) (Foo.cpp:60) ==7439== by 0x80CF313: Bar::Baz() (Bar.cpp:141) The first few all have their roots in libc, and the last one, while it does at least have my code on the callstack, is really nothing special. For example, Foo::Foo (Foo.cpp:147) listed above is basically just the following: class Foo { Foo(x&, const y) { std::stringstream input_buf; //initialize input_buf using whatever method unsigned short length; input_buf.read((char*)&length, sizeof(length)); length = ntohs(length); str_.resize(length); } private: std::string str_; }; So unless libstdc++ has some kind of error in it, I'm not sure what else I can do. Could it be that that there's some switch I can compile my program with, or some switch I can run valgrind with to make the results more accurate? Or do these still look like legitimate errors that should be fixed somehow (even if "fixed" turns out to mean "you built your libraries incorrectly, rebuild them" )? |
|
From: Colin M. <col...@pi...> - 2009-07-14 17:30:25
|
Olly Betts wrote: > On 2009-07-13, Colin Miller <col...@pi...> wrote: > >> According to the manual, Valgrind tries to force glibc (the C runtime >> library) to free all its memory by calling __libc_freeres(), I'm not >> sure why a suppression was used. >> > > I don't think Mac OS X uses glibc, and presumably its C runtime doesn't > have a way to force all memory to be released. > > Ah, I didn't notice the OP was using a Mac; my Linux-centricism. Colin S. Miller. |
|
From: Colin M. <col...@pi...> - 2009-07-14 17:27:50
|
Zachary Turner wrote: > Hello, > > I'm somewhat a valgrind noob, so apologies if this is a RTFM question. > I did search around however and did not see anything definitive about > this. I ran valgrind on an app I have and it generated thousands of > spurious warnings. I know I can create a .supp file to suppress these, > but my question is how do I know which ones are spurious and which > ones are not? I found one website that mentioned that there was a > .supp file somewhere in the valgrind code repository, but for some > reason I cannot access the SVN repository. I'm using the correct SVN > url (svn://svn.valgrind.org/valgrind/trunk), shown on the website at > (http://www.valgrind.org/downloads/repository.html) but it just says > the server timed out or did not respond appropriately. I've never had > any problem accessing other svn repositories. > > Is there a way to tell which warnings are spurious to easily disable > them, or is this .supp file which I can't seem to currently access the > correct approach? 95% of the errors I get are either "Use of > uninitialised value of size 4" (usually in _int_malloc, memcpy, or > malloc_consolidate), and "Conditional jump or move depends on > uninitialized value" (in anything have to do with static variable > initialization / cleanup, etc). > > The short answer is *ALL* Valgrind reports are errors, and should be fixed. (with the possible exception of leaked reachable memory). Suppressions are there for reports inside third-party code that you can't fix. Valgrind comes with a set of suppressions for some standard libraries with are known to be buggy. Running valgrind -v /bin/true should print out the default suppressions that valgrind is using The lack of line numbers means the library does not have debug information with it. For Debian, try installing libstdc++*-dbg and libc6-dbg HTH, Colin S. Miller |
|
From: Zachary T. <div...@gm...> - 2009-07-14 16:54:04
|
Hello, I'm somewhat a valgrind noob, so apologies if this is a RTFM question. I did search around however and did not see anything definitive about this. I ran valgrind on an app I have and it generated thousands of spurious warnings. I know I can create a .supp file to suppress these, but my question is how do I know which ones are spurious and which ones are not? I found one website that mentioned that there was a .supp file somewhere in the valgrind code repository, but for some reason I cannot access the SVN repository. I'm using the correct SVN url (svn://svn.valgrind.org/valgrind/trunk), shown on the website at (http://www.valgrind.org/downloads/repository.html) but it just says the server timed out or did not respond appropriately. I've never had any problem accessing other svn repositories. Is there a way to tell which warnings are spurious to easily disable them, or is this .supp file which I can't seem to currently access the correct approach? 95% of the errors I get are either "Use of uninitialised value of size 4" (usually in _int_malloc, memcpy, or malloc_consolidate), and "Conditional jump or move depends on uninitialized value" (in anything have to do with static variable initialization / cleanup, etc). A slightly unrelated question is that valgrind doesn't always seem to report source / line number information for C++ STL functions. Is this normal? For example one of my warnings shows this: ==7439== Use of uninitialised value of size 4 ==7439== at 0x827A563: std::string::assign(std::string const&) (in /usr/sbin/snip/bin/snip) ==7439== <snipped> ==7439== <snipped> ==7439== by 0x826D023: std::ostream::flush() (in /usr/sbin/snip/bin/snip) ==7439== <snipped> ==7439== <snipped> ==7439== <snipped> ==7439== by 0x807A332: boost::_mfi::mf1<void, snip, snip*>::operator()(snip*, snip*) const (mem_fn_template.hpp:162) ==7439== by 0x807A4BD: void boost::_bi::list2<boost::_bi::value< snip*>, boost::_bi::value< snip*> >::operator()<boost::_mfi::mf1<void, snip, snip*>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf1<void, snip, snip*>&, boost::_bi::list0&, int) (bind.hpp:306) Here, the entire callstack shows line number information (including the lines I've snipped), except for the two STL calls. Is this normal? I suspect they might be inlined functions, but then again I would expect the boost code at the bottom to be inlined as well, so I don't think that's necessarily the issue. Thanks |
|
From: Dan K. <da...@ke...> - 2009-07-14 15:46:46
|
Our users are starting to rebel at using valgrind without line numbers, but dsymutil is too slow to use. Continuous build and test is most effective with cycle times under 30 minutes, but dsymutil alone takes ~ 1 hour to process chrome last I tried. (YMMV.) Are any other groups having similar problems? |
|
From: Olly B. <ol...@su...> - 2009-07-14 15:19:57
|
On 2009-07-13, Colin Miller <col...@pi...> wrote:
> According to the manual, Valgrind tries to force glibc (the C runtime
> library) to free all its memory by calling __libc_freeres(), I'm not
> sure why a suppression was used.
I don't think Mac OS X uses glibc, and presumably its C runtime doesn't
have a way to force all memory to be released.
Cheers,
Olly
|
|
From: Simone M. <sma...@gm...> - 2009-07-14 05:55:37
|
Hi Nicholas, Thanks for the hint. Good to know all this. Best, S. On Jul 14, 2009, at 3:49 AM, Nicholas Nethercote wrote: > On Mon, Jul 13, 2009 at 8:27 PM, simone > marras<sma...@gm...> wrote: >> ==18862== >> ==18862== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 >> from 0) >> ==18862== malloc/free: in use at exit: 4,436 bytes in 9 blocks. >> ==18862== malloc/free: 9 allocs, 0 frees, 4,436 bytes allocated. >> ==18862== For counts of detected errors, rerun with: -v >> ==18862== searching for pointers to 9 not-freed blocks. >> ==18862== checked 1,124,356 bytes. >> ==18862== >> ==18862== LEAK SUMMARY: >> ==18862== definitely lost: 0 bytes in 0 blocks. >> ==18862== indirectly lost: 0 bytes in 0 blocks. >> ==18862== possibly lost: 0 bytes in 0 blocks. >> ==18862== still reachable: 0 bytes in 0 blocks. >> ==18862== suppressed: 4,436 bytes in 9 blocks. > > The Mac libc allocates some memory with malloc() but never frees it. > There are some suppressions for this in darwin9.supp, which becomes > part of default.supp, so that these aren't reported as leaks, because > you have no control over them. > > The moral of the story is: the code you write is not the only code > being run. > > Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-07-14 01:50:05
|
On Mon, Jul 13, 2009 at 8:27 PM, simone marras<sma...@gm...> wrote: > ==18862== > ==18862== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > ==18862== malloc/free: in use at exit: 4,436 bytes in 9 blocks. > ==18862== malloc/free: 9 allocs, 0 frees, 4,436 bytes allocated. > ==18862== For counts of detected errors, rerun with: -v > ==18862== searching for pointers to 9 not-freed blocks. > ==18862== checked 1,124,356 bytes. > ==18862== > ==18862== LEAK SUMMARY: > ==18862== definitely lost: 0 bytes in 0 blocks. > ==18862== indirectly lost: 0 bytes in 0 blocks. > ==18862== possibly lost: 0 bytes in 0 blocks. > ==18862== still reachable: 0 bytes in 0 blocks. > ==18862== suppressed: 4,436 bytes in 9 blocks. The Mac libc allocates some memory with malloc() but never frees it. There are some suppressions for this in darwin9.supp, which becomes part of default.supp, so that these aren't reported as leaks, because you have no control over them. The moral of the story is: the code you write is not the only code being run. Nick |
|
From: Colin M. <col...@pi...> - 2009-07-13 10:56:20
|
simone marras wrote: > Hi Colin, > > Thanks for replying. Here I send you the main.c written for the test > (no "apparent allocation"), and the valgrind output. > I hope this helps you > > thank you in advance, > Simone > > -------------------------------------------------------------------------------------------- > Valgrind output: > > > ==18862== > ==18862== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > ==18862== malloc/free: in use at exit: 4,436 bytes in 9 blocks. > ==18862== malloc/free: 9 allocs, 0 frees, 4,436 bytes allocated. > ==18862== For counts of detected errors, rerun with: -v > ==18862== searching for pointers to 9 not-freed blocks. > ==18862== checked 1,124,356 bytes. > ==18862== > ==18862== LEAK SUMMARY: > ==18862== definitely lost: 0 bytes in 0 blocks. > ==18862== indirectly lost: 0 bytes in 0 blocks. > ==18862== possibly lost: 0 bytes in 0 blocks. > ==18862== still reachable: 0 bytes in 0 blocks. > ==18862== suppressed: 4,436 bytes in 9 blocks. > > > Simone, The "suppressed: 4,436 bytes in 9 blocks." line indicates that Valgrind has detected an error but has been told not to report the details. This behaviour is controlled by a suppression file. Since you did not specify a suppressions file, I'd assume it in the default suppression file. (Use valgrind -v to find its name). Therefore, I'd further assume that it is a known bug in a runtime library you are using (possible the stdio) According to the manual, Valgrind tries to force glibc (the C runtime library) to free all its memory by calling __libc_freeres(), I'm not sure why a suppression was used. I can't see a way to tell Valgrind not to use its default suppression file, which would ascertain this for certain. HTH, Colin S. Miller |
|
From: simone m. <sma...@gm...> - 2009-07-13 10:27:45
|
Hi Colin,
Thanks for replying. Here I send you the main.c written for the test
(no "apparent allocation"), and the valgrind output.
I hope this helps you
thank you in advance,
Simone
--------------------------------------------------------------------------------------------
Valgrind output:
simone-marras-macbook-aero:Source simone$ valgrind ./meteoIni.a
meteoIni.inp agnesi_NH_80kmX19km_dx400mXdz400m_mount1mHeight.msh 2
==18862== Memcheck, a memory error detector.
==18862== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==18862== Using LibVEX rev 1908, a library for dynamic binary translation.
==18862== Copyright (C) 2004-2009, and GNU GPL'd, by OpenWorks LLP.
==18862== Using valgrind-3.5.0.SVN, a dynamic binary instrumentation framework.
==18862== Copyright (C) 2000-2009, and GNU GPL'd, by Julian Seward et al.
==18862== For more details, rerun with: -v
==18862==
--18862-- ./meteoIni.a:
--18862-- dSYM directory has wrong UUID; consider using --auto-run-dsymutil=yes
###################################################################
# Welcome to MeteoIni!
#
# This code reads in a GID mesh file
# and initializes an atmospheric field on the mesh nodes.
###################################################################
==18862==
==18862== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==18862== malloc/free: in use at exit: 4,436 bytes in 9 blocks.
==18862== malloc/free: 9 allocs, 0 frees, 4,436 bytes allocated.
==18862== For counts of detected errors, rerun with: -v
==18862== searching for pointers to 9 not-freed blocks.
==18862== checked 1,124,356 bytes.
==18862==
==18862== LEAK SUMMARY:
==18862== definitely lost: 0 bytes in 0 blocks.
==18862== indirectly lost: 0 bytes in 0 blocks.
==18862== possibly lost: 0 bytes in 0 blocks.
==18862== still reachable: 0 bytes in 0 blocks.
==18862== suppressed: 4,436 bytes in 9 blocks.
--------------------------------------------------------------------------------------------
main.c
#include "include_.h"
#include "def_thermo.h"
#define MAX_NVARS 20
#define PROB_ENTRIES 5
#define MAX_STR_LENGTH 64
#define MAX_INPUT_ENTRIES 35
#define MAX_NBOUND 4 //Maximum number of boundaries in the domain
#define EPSI 0.000001
int main(int argc, char *argv[])
{
int inode,i,j;
int nsd, nnodes, nelem, nbdy_nodes, max_elnodes;
float height, x_min, x_max, z_min, z_max;
int **CONN;
int *ELTYPE;
float **COORDS;
float **INITV;
int *BFLAG;
float PROBVars[MAX_INPUT_ENTRIES];
const char *BC_flags[MAX_NBOUND] = {"o", "s", "o", "s"};
char *input_file, *msh_file, *msh_generator;
/************************************************/
//Begin:
if(argc <= 3){
//Remember that the first argument of argc is the name of the program
by default,
//thus argc == 1 correswponds to that and the program recognizes that
you did not put any input
printf("\n You did not enter the input file\n");
printf(" Call the program as:\n");
printf("\n ./alya_initialize.a [inputFile] [meshFile] [nsd]\n");
printf("\n [inputFile]: input file with the perturb. characteristics.");
printf("\n [meshFile]: mesh file to read (only. GID for now).\n");
printf(" [nsd] indicates the number of space dimensions (2 ONLY for
now).\n");
printf("\n");
exit(1);
}
else{
printf("\n ###################################################################\n");
printf(" #\t Welcome to MeteoIni!\n #\n");
printf(" #\t This code reads in a GID mesh file\t\n");
printf(" #\t and initializes an atmospheric field on the mesh nodes.\n");
printf(" ###################################################################\n\n");
}
/************************************************/
//If adding new variables, you need to update nvars also!
int nvars = 7;
const char *varnames[] = {"PRESS", "DENSI", "TEMPE", "THETA",
"XVELO_bound", "ZVELO_bound", "EXNER"};
return;
}
On Mon, Jul 13, 2009 at 12:03 PM, Colin Miller<col...@pi...> wrote:
> simone marras wrote:
>> Hi everyone,
>>
>> I was having problems of memory allocation that valgirnd identified as
>> a mismatched number in "malloc/free". Not knowing where the problem
>> could be I tried to not allocate anything in my code and see if there
>> was still a similar error. I realized that valgrind still gave me a
>> mismatched number although I am not actually using malloc and free for
>> this test.
>> Where could the problem be? Does valgrind identify the declaration of
>> a pointer already as if I were to malloc it?
>>
>>
> Simone,
>
> Valgrind should give a full backtrace for each error.
> If you built and linked your program with debug info
> ( -g option in gcc/g++ ), then the symbol names will be printed,
> otherwise just the addresses of the functions.
>
> What error(s) is valgrind reporting?
> It is possible that a library that you are using is buggy.
>
>
> If you put some of the output here, I'm sure the we can give
> you further assistance.
>
> Colin S. Miller
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
--
Simone Marras, Ph.D. candidate
Barcelona Supercomputing Center
Universitat Politecnica de Catalunya
Avd. Diagonal 647,
Edificio H, planta 10
Barcelona, 08028
SPAIN
Tel.: (+34) 93 4011744
web: www.cranfield.ac.uk/~c086030
|
|
From: Colin M. <col...@pi...> - 2009-07-13 10:18:04
|
simone marras wrote: > Hi everyone, > > I was having problems of memory allocation that valgirnd identified as > a mismatched number in "malloc/free". Not knowing where the problem > could be I tried to not allocate anything in my code and see if there > was still a similar error. I realized that valgrind still gave me a > mismatched number although I am not actually using malloc and free for > this test. > Where could the problem be? Does valgrind identify the declaration of > a pointer already as if I were to malloc it? > > Simone, Valgrind should give a full backtrace for each error. If you built and linked your program with debug info ( -g option in gcc/g++ ), then the symbol names will be printed, otherwise just the addresses of the functions. What error(s) is valgrind reporting? It is possible that a library that you are using is buggy. If you put some of the output here, I'm sure the we can give you further assistance. Colin S. Miller |
|
From: Ashley P. <as...@pi...> - 2009-07-13 09:45:47
|
On Mon, 2009-07-13 at 08:45 +1000, Nicholas Nethercote wrote: > > http://www.valgrind.org/docs/manual/faq.html#faq.crashes is relevant > here. It looks like you are in an unlucky situation. Probably the > best thing you can do is report any Valgrind errors that occur before > the crash to nVidia, and hope that the next version of the driver > works better :( Given this is a device driver and GPU off-load code it could well not be to do with errors in the driver but possibly that the driver has mapped some pages into userspace that Valgrind doesn't know about? As I recall OpenGL didn't work on Linux for a couple of years for just this reason. Are there any "unrecognised syscall" errors before the crash? Ultimately I suppose the cause doesn't make any difference, all you can do is try and find a way of running the code using different library's, the use of a software renderer sounds like a promising solution. Ashley, -- Ashley Pittman, Bath, UK. Padb - A parallel job inspection tool for cluster computing http://padb.pittman.org.uk |
|
From: simone m. <sma...@gm...> - 2009-07-13 08:29:32
|
Hi everyone, I was having problems of memory allocation that valgirnd identified as a mismatched number in "malloc/free". Not knowing where the problem could be I tried to not allocate anything in my code and see if there was still a similar error. I realized that valgrind still gave me a mismatched number although I am not actually using malloc and free for this test. Where could the problem be? Does valgrind identify the declaration of a pointer already as if I were to malloc it? I surfed the list to find a similar error from someone else, but although partly similar, I didn't find the same. Apologies in advance if I am re-posting the same. I hope someone can help. Thank you in advance |
|
From: Dan K. <da...@ke...> - 2009-07-13 00:14:12
|
On Sun, Jul 12, 2009 at 1:38 PM, Simon Gornall<sim...@ma...> wrote: > So, I'm new to this, and I'm not sure if it's a mac-specific thing, or > a general issue... Be gentle :) > > I'm trying to run my application under valgrind, and it's failing when > I initialise the OpenGL context... I get the debug log: > > ==50304== ... (snipped) > ==50304== Process terminating with default action of signal 11 (SIGSEGV) Bam. Stop right there. If it crashes, all bets are off. Figure out why it crashes first. You might find valgrind's --db-attach=yes command handy. Alternately, insert printf's until you figure out why the crash occurs. - Dan |
|
From: Nicholas N. <n.n...@gm...> - 2009-07-12 22:45:27
|
On Mon, Jul 13, 2009 at 8:33 AM, Simon Gornall<sim...@ma...> wrote: > > 1) There's a piece of code not under my control that has a memory- > access issue > 2) Valgrind kills my program whenever there's a memory-access issue > > What I'd like valgrind to do (in this case) is run my program, report > the problem, and not kill my program if it's in the 'suppressed' file > > Is it possible to do that ? From what you say above, I got the > impression that it was just the reporting of the problem that the > suppression file affects, not whether valgrind kills my program. Correct; ie. the suppressions file won't help. > I'd > happily take valgrind just reporting the issue (and me subsequently > ignoring it) if I could get past the SIGSEGV :) http://www.valgrind.org/docs/manual/faq.html#faq.crashes is relevant here. It looks like you are in an unlucky situation. Probably the best thing you can do is report any Valgrind errors that occur before the crash to nVidia, and hope that the next version of the driver works better :( Nick |
|
From: Simon G. <sim...@ma...> - 2009-07-12 22:33:25
|
On Jul 12, 2009, at 3:14 PM, tom fogal wrote: > Hi Simon, > > let's keep discussions on-list. Mostly since I'm no valgrind expert, > and if I make incorrect statements I'd like one to jump in with a clue > bat :) Yeah, I hit 'reply' rather than 'reply-all'. I actually re-posted it to "users" afterwards :) > > > Simon Gornall <sim...@ma...> writes: >> >> On Jul 12, 2009, at 2:02 PM, tom fogal wrote: >> >>> Simon Gornall <sim...@ma...> writes: >>>> I'm trying to run my application under valgrind, and it's failing >>>> when I initialise the OpenGL context... >>> [snip] >>>> I started off with more-specific suppressions, but even with the >>>> above, the application is aborted every time I run. >>> >>> This sentence implies you are slightly confused about the >>> semantics of a suppression file. These files are merely to >>> suppress *reporting* of errors; the existance or not of any given >>> suppression should not change the behavior of a program. It will >>> certainly change what valgrind prints out, but not what's going on >>> under the hood. >> >> Ah - yes, I was hoping it was more along the lines of "yes, I know >> there's an issue there, just ignore it for now". I take it there's no >> way of doing that, then ? > > Sorry, "that" reads ambiguously to me. You mean no way of modifying > the behavior of a program using valgrind? No, not beyond the normal > valgrind instrumentation. A suppression is your way of saying exactly > what you've put in quotes, if I was unclear earlier. Right. The problem (for me at least) is that 1) There's a piece of code not under my control that has a memory- access issue 2) Valgrind kills my program whenever there's a memory-access issue What I'd like valgrind to do (in this case) is run my program, report the problem, and not kill my program if it's in the 'suppressed' file Is it possible to do that ? From what you say above, I got the impression that it was just the reporting of the problem that the suppression file affects, not whether valgrind kills my program. I'd happily take valgrind just reporting the issue (and me subsequently ignoring it) if I could get past the SIGSEGV :) > > >>> Since you're using nvidia's driver, I'd ask you to re-run using the >>> command line option `--smc-check=all'. > [snip] >> Yep, it fails in the same way. > > Doh, sorry that wasn't any help :( > >>> If that fails, I suggest linking your program against Mesa [. . .] >> >> Thanks, I'll see if that helps - the application uses CoreImage (and >> therefore a lot of GPU shader code) quite heavily though, so I'm not >> sure if Mesa is up to it (I haven't used it in a decade or so, so I >> might be unfairly maligning Mesa :) > > I do GPU-based raycasted volume rendering through Mesa quite > regularly. > It works. The swrast Mesa backend supports OpenGL 2.1. It's about an > order of magnitude slower than my nvidia card. > > It's also about 2 order of magnitudes faster than Apple's software > fallback. Cool - I'll give it a go then :) ATB, Simon |
|
From: Simon G. <sim...@ma...> - 2009-07-12 22:18:33
|
On Jul 12, 2009, at 2:02 PM, tom fogal wrote:
> Simon Gornall <sim...@ma...> writes:
>> I'm trying to run my application under valgrind, and it's failing
>> when I initialise the OpenGL context... I get the debug log:
>
> To clarify -- are you saying that it can initialize the context fine
> when run standalone, and only fails through valgrind?
Well, the application runs fine without valgrind, and I have no reason
to suspect it doesn't work - the GL output is as-expected. It may well
be that there is a problem in the nVidia drivers, but it's not causing
any application-level problems :)
> (I'm going to assume `yes'... sorry.)
>
>> ==50304== ... (snipped)
>> ==50304== Process terminating with default action of signal 11
>> (SIGSEGV)
>> ==50304== Access not within mapped region at address 0x187E7108
>> ==50304== at 0x1466316: memcpy (mc_replace_strmem.c:482)
>> ==50304== by 0x16050DFA: gldGetTextureLevel (in /System/Library/
>> Extensions/GeForce8xxxGLDriver.bundle/Contents/MacOS/
>> GeForce8xxxGLDriver)
> [snip]
>> I've been playing with suppressions because the above are OS-internal
>> issues, and eventually (after failing to stop the SIGSEGV being
>> sent),
>> my 'valgrind' file looks like:
>>
>> -----8<-----8<----- Snip here -----8<-----8<-----
>> {
>> GL context creation
>> Memcheck:Addr16
>> fun:memcpy
>> ...
>> fun:CGLCreateContext
>> }
> [snip]
>> I started off with more-specific suppressions, but even with the
>> above, the application is aborted every time I run.
>
> This sentence implies you are slightly confused about the semantics of
> a suppression file. These files are merely to suppress *reporting* of
> errors; the existance or not of any given suppression should not
> change
> the behavior of a program. It will certainly change what valgrind
> prints out, but not what's going on under the hood.
Ah - yes, I was hoping it was more along the lines of "yes, I know
there's an issue there, just ignore it for now". I take it there's no
way of doing that, then ?
> Since you're using nvidia's driver, I'd ask you to re-run using the
> command line option `--smc-check=all'. I am not as familiar with
> nvidia's Mac driver, but on Linux the driver utilizes self modifying
> code, which causes me to see a lot of errors similar to the one you
> describe above. Note that even with SMC checking, I still see a lot
> of
> nvidia-based errors, so don't expect this will be a 100% solution.
Yep, it fails in the same way.
> If that fails, I suggest linking your program against Mesa, probably
> mangled Mesa for logistical reasons. That will valgrind much more
> `nicely'. This:
> http://visitusers.org/index.php?title=Mangled_Mesa
> might help you, if you need to go that route.
Thanks, I'll see if that helps - the application uses CoreImage (and
therefore a lot of GPU shader code) quite heavily though, so I'm not
sure if Mesa is up to it (I haven't used it in a decade or so, so I
might be unfairly maligning Mesa :)
Hmm - actually I think I could force the use of the software-renderer
within CoreImage, which would slow the app down a lot, but might get
me past this...
ATB,
Simon
|
|
From: tom f. <tf...@al...> - 2009-07-12 22:12:57
|
Hi Simon, let's keep discussions on-list. Mostly since I'm no valgrind expert, and if I make incorrect statements I'd like one to jump in with a clue bat :) Simon Gornall <sim...@ma...> writes: > > On Jul 12, 2009, at 2:02 PM, tom fogal wrote: > > > Simon Gornall <sim...@ma...> writes: > >> I'm trying to run my application under valgrind, and it's failing > >> when I initialise the OpenGL context... > > [snip] > >> I started off with more-specific suppressions, but even with the > >> above, the application is aborted every time I run. > > > > This sentence implies you are slightly confused about the > > semantics of a suppression file. These files are merely to > > suppress *reporting* of errors; the existance or not of any given > > suppression should not change the behavior of a program. It will > > certainly change what valgrind prints out, but not what's going on > > under the hood. > > Ah - yes, I was hoping it was more along the lines of "yes, I know > there's an issue there, just ignore it for now". I take it there's no > way of doing that, then ? Sorry, "that" reads ambiguously to me. You mean no way of modifying the behavior of a program using valgrind? No, not beyond the normal valgrind instrumentation. A suppression is your way of saying exactly what you've put in quotes, if I was unclear earlier. > > Since you're using nvidia's driver, I'd ask you to re-run using the > > command line option `--smc-check=all'. [snip] > Yep, it fails in the same way. Doh, sorry that wasn't any help :( > > If that fails, I suggest linking your program against Mesa [. . .] > > Thanks, I'll see if that helps - the application uses CoreImage (and > therefore a lot of GPU shader code) quite heavily though, so I'm not > sure if Mesa is up to it (I haven't used it in a decade or so, so I > might be unfairly maligning Mesa :) I do GPU-based raycasted volume rendering through Mesa quite regularly. It works. The swrast Mesa backend supports OpenGL 2.1. It's about an order of magnitude slower than my nvidia card. It's also about 2 order of magnitudes faster than Apple's software fallback. -tom |
|
From: tom f. <tf...@al...> - 2009-07-12 21:01:35
|
Simon Gornall <sim...@ma...> writes:
> I'm trying to run my application under valgrind, and it's failing
> when I initialise the OpenGL context... I get the debug log:
To clarify -- are you saying that it can initialize the context fine
when run standalone, and only fails through valgrind?
(I'm going to assume `yes'... sorry.)
> ==50304== ... (snipped)
> ==50304== Process terminating with default action of signal 11 (SIGSEGV)
> ==50304== Access not within mapped region at address 0x187E7108
> ==50304== at 0x1466316: memcpy (mc_replace_strmem.c:482)
> ==50304== by 0x16050DFA: gldGetTextureLevel (in /System/Library/
> Extensions/GeForce8xxxGLDriver.bundle/Contents/MacOS/
> GeForce8xxxGLDriver)
[snip]
> I've been playing with suppressions because the above are OS-internal
> issues, and eventually (after failing to stop the SIGSEGV being sent),
> my 'valgrind' file looks like:
>
> -----8<-----8<----- Snip here -----8<-----8<-----
> {
> GL context creation
> Memcheck:Addr16
> fun:memcpy
> ...
> fun:CGLCreateContext
> }
[snip]
> I started off with more-specific suppressions, but even with the
> above, the application is aborted every time I run.
This sentence implies you are slightly confused about the semantics of
a suppression file. These files are merely to suppress *reporting* of
errors; the existance or not of any given suppression should not change
the behavior of a program. It will certainly change what valgrind
prints out, but not what's going on under the hood.
Since you're using nvidia's driver, I'd ask you to re-run using the
command line option `--smc-check=all'. I am not as familiar with
nvidia's Mac driver, but on Linux the driver utilizes self modifying
code, which causes me to see a lot of errors similar to the one you
describe above. Note that even with SMC checking, I still see a lot of
nvidia-based errors, so don't expect this will be a 100% solution.
If that fails, I suggest linking your program against Mesa, probably
mangled Mesa for logistical reasons. That will valgrind much more
`nicely'. This:
http://visitusers.org/index.php?title=Mangled_Mesa
might help you, if you need to go that route.
Cheers,
-tom
|
|
From: Simon G. <sim...@ma...> - 2009-07-12 20:38:17
|
So, I'm new to this, and I'm not sure if it's a mac-specific thing, or
a general issue... Be gentle :)
I'm trying to run my application under valgrind, and it's failing when
I initialise the OpenGL context... I get the debug log:
==50304== ... (snipped)
==50304== Process terminating with default action of signal 11 (SIGSEGV)
==50304== Access not within mapped region at address 0x187E7108
==50304== at 0x1466316: memcpy (mc_replace_strmem.c:482)
==50304== by 0x16050DFA: gldGetTextureLevel (in /System/Library/
Extensions/GeForce8xxxGLDriver.bundle/Contents/MacOS/
GeForce8xxxGLDriver)
==50304== by 0x160528A0: gldGetTextureLevel (in /System/Library/
Extensions/GeForce8xxxGLDriver.bundle/Contents/MacOS/
GeForce8xxxGLDriver)
==50304== by 0x160EBA76: gldGetTextureLevel (in /System/Library/
Extensions/GeForce8xxxGLDriver.bundle/Contents/MacOS/
GeForce8xxxGLDriver)
==50304== by 0x160EBDDA: gldGetTextureLevel (in /System/Library/
Extensions/GeForce8xxxGLDriver.bundle/Contents/MacOS/
GeForce8xxxGLDriver)
==50304== by 0x1606ED55: gldGetTextureLevel (in /System/Library/
Extensions/GeForce8xxxGLDriver.bundle/Contents/MacOS/
GeForce8xxxGLDriver)
==50304== by 0x15FEA6CE: gldAllocVertexBuffer (in /System/Library/
Extensions/GeForce8xxxGLDriver.bundle/Contents/MacOS/
GeForce8xxxGLDriver)
==50304== by 0x15FEA7D0: gldAllocVertexBuffer (in /System/Library/
Extensions/GeForce8xxxGLDriver.bundle/Contents/MacOS/
GeForce8xxxGLDriver)
==50304== by 0x15FC9EFB: gldCreateContext (in /System/Library/
Extensions/GeForce8xxxGLDriver.bundle/Contents/MacOS/
GeForce8xxxGLDriver)
==50304== by 0x15E1387C: gliCreateContext (in /System/Library/
Frameworks/OpenGL.framework/Versions/A/Resources/GLEngine.bundle/
GLEngine)
==50304== by 0x24F58E7: cglInitializeContext (in /System/Library/
Frameworks/OpenGL.framework/Versions/A/OpenGL)
==50304== by 0x24F51DD: CGLCreateContext (in /System/Library/
Frameworks/OpenGL.framework/Versions/A/OpenGL)
==50304== If you believe this happened as a result of a stack
==50304== overflow in your program's main thread (unlikely but
==50304== possible), you can try to increase the size of the
==50304== main thread stack using the --main-stacksize= flag.
==50304== The main thread stack size used in this run was 8388608.
--50304:0:schedule VG_(sema_down): read returned -4
==50304==
==50304== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from
2)
==50304== malloc/free: in use at exit: 6,482,048 bytes in 23,552 blocks.
==50304== malloc/free: 110,105 allocs, 86,553 frees, 17,010,063 bytes
allocated.
==50304== For counts of detected errors, rerun with: -v
==50304== searching for pointers to 23,552 not-freed blocks.
==50304== checked 47,251,752 bytes.
==50304==
==50304== LEAK SUMMARY:
==50304== definitely lost: 272 bytes in 17 blocks.
==50304== indirectly lost: 6,828 bytes in 12 blocks.
==50304== possibly lost: 868,510 bytes in 2,184 blocks.
==50304== still reachable: 5,600,608 bytes in 21,197 blocks.
==50304== suppressed: 5,830 bytes in 142 blocks.
==50304== Rerun with --leak-check=full to see details of leaked memory.
I've been playing with suppressions because the above are OS-internal
issues, and eventually (after failing to stop the SIGSEGV being sent),
my 'valgrind' file looks like:
-----8<-----8<----- Snip here -----8<-----8<-----
{
GL context creation
Memcheck:Addr16
fun:memcpy
...
fun:CGLCreateContext
}
{
GL context creation
Memcheck:Addr8
fun:memcpy
...
fun:CGLCreateContext
}
{
GL context creation
Memcheck:Addr4
fun:memcpy
...
fun:CGLCreateContext
}
{
GL context creation
Memcheck:Addr2
fun:memcpy
...
fun:CGLCreateContext
}
{
GL context creation
Memcheck:Addr1
fun:memcpy
...
fun:CGLCreateContext
}
-----8<-----8<----- Snip here -----8<-----8<-----
I started off with more-specific suppressions, but even with the
above, the application is aborted every time I run. As far as I can
tell from the manual, *any* access with a chain starting with
'CGLCreateContext' and ending with 'memcpy' ought to be ignored by
memcheck... Either I'm missing something, or I've tickled a bug... I
tried making the stack larger, but that made no difference ...
Any help gratefully received :)
Simon
|
|
From: Tim P. <ec...@ec...> - 2009-07-11 20:17:24
|
On Mon, 2009-06-29 at 15:10 +1000, Nicholas Nethercote wrote: > FWIW, this is in the bug database: > > https://bugs.kde.org/show_bug.cgi?id=191062 > > Nick What was hacky now becomes viral :) Sorry to be delayed in my Xen patches, my free time has degenerated into int64_t in the last two weeks. This seems to be a persistent problem, so I'll send patches to xen-devel for a more valgrind commented and friendly snippet to exist. BTW, FWIW, I quite like the current behavior when dealing with something that _should_ generate a fault, its quite easy to work around when you _know_ its bogus. Cheers, --Tim |
|
From: tom f. <tf...@al...> - 2009-07-11 18:29:20
|
Please keep discussions on-list.
David Gregorczyk <in...@we...> writes:
> but what can I do to summarize massif's multiple outputs for
> each child process? I've tried to watch out memory usage for
> Xerces-C++ and get more than 10 output files. To get complete memory
> consumption, I have to intrepret every file with ms_print and search
> for the peak consumption. For one measurement that seems ok, but I
> have to check out the program's behaviour for 16 input files.
Sounds like a job for your friendly neighborhood awk.
BEGIN {
max_percent=0
max_bytes=0
}
/heap allocation functions/ {
percent=$1
bytes=$2
if(percent > max_percent || bytes > max_bytes) {
max_percent=percent
max_bytes=bytes
max_file=FILENAME
}
}
END {
printf "Largest heap usage was %d (%d%%) from output %s\n", \
max_bytes, max_percent, max_file
}
Untested, I've actually never even used massif, just basing that on the
doc's output. You get the idea though.
Massif might have an xml output mode too (I don't know). I would
expect programmatically parsing the default output will break in some
subsequent version, but presumably an xml output would be designed for
consistency across revisions.
Cheers,
-tom
|
|
From: tom f. <tf...@al...> - 2009-07-11 17:06:20
|
David Gregorczyk <in...@we...> writes: > is there any possibility to detect maximum heap memory usage of an > application? [snip] > I've tried --tool=massif but I didn't understand to interpret it > correctly. > > Can anybody help me? http://valgrind.org/docs/manual/ms-manual.html#ms-manual.theoutputpreamble -tom |