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
(5) |
3
|
|
4
(1) |
5
(8) |
6
(16) |
7
(5) |
8
(1) |
9
(3) |
10
|
|
11
|
12
(10) |
13
(5) |
14
(14) |
15
(6) |
16
(4) |
17
(2) |
|
18
(2) |
19
(13) |
20
(1) |
21
(5) |
22
(2) |
23
(1) |
24
|
|
25
|
26
(5) |
27
(10) |
28
(8) |
29
(7) |
30
(2) |
31
|
|
From: senganal <set...@ci...> - 2004-07-08 08:03:52
|
Hi
While using valgrind for memory leak testing of my application, i am
facing the following issue :
valgrind doesent wait on ACE_Manual_Event.wait() or
ACE_Condition_Thread_Mutex.wait().. It immediatly exits out of the wait..
The binary when run without valgrind runs normally though, waiting for
the specified amount of time before returning. ACE internally uses
pthread_cond_wait() for implementing these wait() functions. So, i
tried using pthread_cond_wait() and valgrind works fine and waits for
the required period of time before returning.
valgrind throws an error message when the code is run on redhat 9.0 but
no error message is generated on AS3.0, but in both case it doesent wait
on these functions. I have attached a sample program and the valgrind
output on both redhat 9 and as3.0 in this mail.
Will be grateful for any suggestions.
ACE version : 5.3.5
valgrind version : 2.0.0 ( tried with 2.1.1 also )
Thanks and Regards
Senganal
|
|
From: Jeremy H. <jh...@ma...> - 2004-07-07 22:26:25
|
Hello, I am attempting to run vdr (videodisk recorder) under valgrind but it uses pthread_rwlock_timedwrlock and pthread_rwlock_timedrdlock in thread.c. I considered a temporary hack to forice it to use pthread_rwlock_wrlock and pthread_rwlock_rdlock but that can lead to threads freezing indefinitely. I'm not a fan of avoiding a deadlock by time delayed response, but I'm sure there is a good reason why the timed versions are being used, indeed I have noticed strange problems with the nontimed ones. What is the possability that these functions could be implemented in valgrind's pthreads library? Thanks in advance, Jeremy |
|
From: Tom H. <th...@cy...> - 2004-07-07 22:09:17
|
In message <108...@pe...>
Steven Dake <sd...@mv...> wrote:
> ==2834== Syscall param socketcall.recvmsg(msg.msg_iov[i] contains
> uninitialised or unaddressable byte(s)
> ==2834== at 0x3C111A16: sendmsg (socket.S:63)
> ==2834== by 0x8053371: message_handler_orf_token (gmi.c:2240)
> ==2834== by 0x8054779: recv_handler (gmi.c:3012)
> ==2834== by 0x8050876: poll_run (poll.c:458)
> ==2834== Address 0x3C182171 is 9 bytes inside a block of size 52
> alloc'd
> ==2834== at 0x3C01D2CB: malloc (vg_replace_malloc.c:105)
> ==2834== by 0x8050AC7: gmi_pend_trans_item_store (gmi.c:501)
> ==2834== by 0x8050F59: gmi_mcast (gmi.c:669)
> ==2834== by 0x804A52F: clmNodeJoinSend (clm.c:323)
>
> I'm not quite sure how to read this message.
>
> It says "at sendmsg" but the syscall param is "socketcall.recvmsg". So
> which one is it? I have cleaned up all uninitialized variables that
> could possibly be related so I'm a little stuck as to what to do next to
> remove this error.
I can't see anything in valgrind that would cause it to print recvmsg
when it should say sendmsg, and you do have recv_handler on the stack
so I suspect the sendmsg line in that stack trace is bogus. It may be
that the debug data is confused, or that recvmsg and sendmsg share part
of their implementation inside the C library or something.
> Also, what does the "address X is 9 bytes insid ea block of size 52
> alloced". does that tell where the iov[i] was allocated?
Basically, yes. It tells you where the block that contained the
uninitialised byte was allocated.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-07-07 22:05:16
|
In message <200...@we...>
Daniel Aloise <alo...@ya...> wrote:
> What does this error mean?
>
> Invalid read of size 4
> ==2249== at 0x804A4CF: Instance::Vehicles(char*)
> (instance.cpp:294)
> ==2249== Address 0xBFEAE0C4 is on thread 1's stack
It means that something on line 294 of instance.cpp is reading uninitialised
data from address 0xBFEAE0C4 which is on thread 1's stack.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Steven D. <sd...@mv...> - 2004-07-07 21:07:00
|
Folks I am using valgrind 2.1.1 to run the openais project (developer.osdl.org/dev/openais) through its paces. Its an excellent tool and I have already found a few errors. I am trying to sanitize all of the remaining errors and get an error that is: ==2834== Syscall param socketcall.recvmsg(msg.msg_iov[i] contains uninitialised or unaddressable byte(s) ==2834== at 0x3C111A16: sendmsg (socket.S:63) ==2834== by 0x8053371: message_handler_orf_token (gmi.c:2240) ==2834== by 0x8054779: recv_handler (gmi.c:3012) ==2834== by 0x8050876: poll_run (poll.c:458) ==2834== Address 0x3C182171 is 9 bytes inside a block of size 52 alloc'd ==2834== at 0x3C01D2CB: malloc (vg_replace_malloc.c:105) ==2834== by 0x8050AC7: gmi_pend_trans_item_store (gmi.c:501) ==2834== by 0x8050F59: gmi_mcast (gmi.c:669) ==2834== by 0x804A52F: clmNodeJoinSend (clm.c:323) I'm not quite sure how to read this message. It says "at sendmsg" but the syscall param is "socketcall.recvmsg". So which one is it? I have cleaned up all uninitialized variables that could possibly be related so I'm a little stuck as to what to do next to remove this error. Also, what does the "address X is 9 bytes insid ea block of size 52 alloced". does that tell where the iov[i] was allocated? |
|
From: <alo...@ya...> - 2004-07-07 20:49:10
|
What does this error mean? Invalid read of size 4 ==2249== at 0x804A4CF: Instance::Vehicles(char*) (instance.cpp:294) ==2249== Address 0xBFEAE0C4 is on thread 1's stack Thank you, Daniel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Nicholas N. <nj...@ca...> - 2004-07-06 23:22:45
|
On Wed, 7 Jul 2004, Julian Seward wrote: > Er, ah, ok. Good. So does that mean we can get rid of the > LD_ASSUME_KERNEL hack that the old valgrind startup shell > script used to do? Or perhaps it's already gone, post > full-virtualisation? It's long gone. N |
|
From: Julian S. <js...@ac...> - 2004-07-06 23:12:28
|
On Tuesday 06 July 2004 22:31, Tom Hughes wrote: > > > You're sure you're not experiencing the differences between LinuxThreads > > and NPTL ? RH90 uses NTPL by default, and Valgrind only emulates > > LinuxThreads, not NPTL. You might try to set LD_ASSUME_KERNEL=2.2.5, and > > see if the program runs differently. > > Actually valgrind doesn't emulate either, it emaulates pthreads, which > is what both linuxthreads and NPTL are supposed to be implementing. I think Valgrind at least tries to conform to the POSIX pthreads spec, rather mimic LinuxThread's behaviour, which doesn't always conform exactly to the spec. > The need for LD_ASSUME_KERNEL wasn't really to do with NPTL at all, it > was to do with TLS support, and recent versions of valgrind can handle > that just fine. Er, ah, ok. Good. So does that mean we can get rid of the LD_ASSUME_KERNEL hack that the old valgrind startup shell script used to do? Or perhaps it's already gone, post full-virtualisation? J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-06 22:55:49
|
On Tue, 6 Jul 2004, Aditya wrote: > I am using cachegrind skin of valgrind to get the address traces of an > application. I have been capturing the addresses as they are generated, > in log_xD_yI_cache_access(....) functions (in cg_main.c file). I now want to > collect for each access if it is a load or store operation. How do i do > that ? Try the attached tool, Memtrace, which prints the data address trace: 1. Get the current CVS HEAD (see valgrind.kde.org/cvs.html for how). 2. Apply the diff against the current CVS head. 3. Make a directory called 'memtrace' and put mt_main.c and Makefile.am in it. Build according to the instructions in README. Et voila. I did this because several people have asked about this functionality before (even though mpatrol does it better). I'm tempted to include it in the main distro now, just to stop people asking this question. I think I would rename the tool "Dullard" before I do, though. N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-06 21:36:42
|
On Tue, 6 Jul 2004, Tom Hughes wrote: > Actually valgrind doesn't emulate either, it emaulates pthreads, which > is what both linuxthreads and NPTL are supposed to be implementing. Yep. But the implementation is probably closer to LinuxThreads, since that's what Valgrind's implementation was based on. For example, various struct layouts mirror those of LinuxThreads. N |
|
From: Tom H. <th...@cy...> - 2004-07-06 21:30:48
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
> > Additionally, I have found that in more than one case, Valgrind's
> > intercepted implementation of threads differs from Linux threads (RH 9,
> > kernel 2.4.20-19.9, gcc 3.2.2 20030222, libc 2.3.2). The differences are
> > slight, including return values on certain functions (see my other post) and
> > the like. IMHO, this is a benefit because I get to debug against a
> > different implementation of threads making the end result more portable and
> > robust.
>
> You're sure you're not experiencing the differences between LinuxThreads
> and NPTL ? RH90 uses NTPL by default, and Valgrind only emulates
> LinuxThreads, not NPTL. You might try to set LD_ASSUME_KERNEL=2.2.5, and
> see if the program runs differently.
Actually valgrind doesn't emulate either, it emaulates pthreads, which
is what both linuxthreads and NPTL are supposed to be implementing.
The need for LD_ASSUME_KERNEL wasn't really to do with NPTL at all, it
was to do with TLS support, and recent versions of valgrind can handle
that just fine.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Igmar P. <mai...@jd...> - 2004-07-06 21:13:24
|
> Additionally, I have found that in more than one case, Valgrind's > intercepted implementation of threads differs from Linux threads (RH 9, > kernel 2.4.20-19.9, gcc 3.2.2 20030222, libc 2.3.2). The differences are > slight, including return values on certain functions (see my other post) and > the like. IMHO, this is a benefit because I get to debug against a > different implementation of threads making the end result more portable and > robust. You're sure you're not experiencing the differences between LinuxThreads and NPTL ? RH90 uses NTPL by default, and Valgrind only emulates LinuxThreads, not NPTL. You might try to set LD_ASSUME_KERNEL=2.2.5, and see if the program runs differently. > The Linux implementation and PTHREAD_MUTEX_FAST_NP *does* allow a different > thread to unlock a mutex. ERRORCHECK_NP does *not*. However, don't rely on this to be portable. > Thanks again, > Russ Igmar |
|
From: Aditya <ad...@re...> - 2004-07-06 18:50:23
|
hi,=0A=0AI am using cachegrind skin of valgrind to get the address traces o= f an application. I have been capturing the addresses as they are generated= , in log_xD_yI_cache_access(....) functions (in cg_main.c file). I now want= to collect for each access if it is a load or store operation. How do i do= that ? =0A=0AThanks,=0A=0APS: I am collecting only DATA references.=0A=0A |
|
From: Nicholas N. <nj...@ca...> - 2004-07-06 12:35:31
|
On Tue, 6 Jul 2004, Dennis Lubert wrote: > Dont know if its relevant, but I would like to have this option so > configurable that you can set a number, rather than high/mid/low. And > this number should always be at least the one what num-callers was set > to, since if it wasnt, it was confusing even more. If this number is always higher than num-callers, then it would make sense to remove --leak-resolution altogether, as no traces would ever be merged. Perhaps this is the sensible thing to do, if people are always using --leak-resolution=high anyway. > If there was a way to determine where this leak logically occurs (like > whenever calling do_sort_something_out() which resorts and forgots to > deallocate something, but is called from different places), the merging > would be nice to make it more clear, but I dont know if theres such a > way. Unfortunately identifying when a leak occurs is very difficult to do without being horribly slow. N |
|
From: Dennis L. <pla...@tz...> - 2004-07-06 12:17:56
|
Am Di, den 06.07.2004 schrieb Nicholas Nethercote um 12:55: > I don't know how much people use --leak-resolution. It would be > interesting to hear what people think: > > - is the default trace merging confusing Too often, yes. > > - does anyone use --leak-resolution=high? Yes, I have my own start script for valgrind (so that I can link to the script and valgrind uses the skin of the links name) and in memcheck case I always add there this option. > > And any other relevant opinions. Dont know if its relevant, but I would like to have this option so configurable that you can set a number, rather than high/mid/low. And this number should always be at least the one what num-callers was set to, since if it wasnt, it was confusing even more. If there was a way to determine where this leak logically occurs (like whenever calling do_sort_something_out() which resorts and forgots to deallocate something, but is called from different places), the merging would be nice to make it more clear, but I dont know if theres such a way. > > N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-06 11:35:15
|
On Tue, 6 Jul 2004, Howard Chu wrote: > Just posting this to verify. (I already found and fixed the leaks using > FunctionCheck). The nice thing about valgrind is that it doesn't require > recompiling your target, and since it emulates the target it can drop you > into gdb at the moment Something Bad happens (such as touching freed memory). > But damn is it slow... Using FunctionCheck is a pain sometimes because it > requires a specially compiled binary, but it runs on the real CPU so it only > takes 30 minutes to run my test. It can't protect itself from a wildly > misbehaving program though. Oh well. No tool is perfect. Use a combination of tools that works for you. N |
|
From: Howard C. <hy...@sy...> - 2004-07-06 11:07:24
|
Tom Hughes wrote: > All allocations made from malloc called from ber_memalloc_x will be > grouped together in that report, regardless of where ber_memalloc_x > was called from. Changing the leak resolution will stop that. Well, 5 hours later, the test is complete and the results are more sensible. Thanks for clarifying this situation for me. Just posting this to verify. (I already found and fixed the leaks using FunctionCheck). The nice thing about valgrind is that it doesn't require recompiling your target, and since it emulates the target it can drop you into gdb at the moment Something Bad happens (such as touching freed memory). But damn is it slow... Using FunctionCheck is a pain sometimes because it requires a specially compiled binary, but it runs on the real CPU so it only takes 30 minutes to run my test. It can't protect itself from a wildly misbehaving program though. Oh well. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support |
|
From: Crispin F. <val...@fl...> - 2004-07-06 11:03:22
|
> - is the default trace merging confusing? I certainly find it confusing, as when using C++, you have the new() call in the frame before the malloc() so a lot of things are merged wrongly. > - does anyone use --leak-resolution=high? I use this all the time, so much that I have it in my .valgrindrc file (along with --num-callers=40) :-) Crispin |
|
From: Nicholas N. <nj...@ca...> - 2004-07-06 10:55:46
|
On Tue, 6 Jul 2004, Howard Chu wrote: > This may be a silly question, but why does this leak-resolution option even > exist? When is it ever useful to have leak-resolution and num-callers set > differently? E.g., it's pointless to have leak-resolution=high and > num-callers < 4. Or num-callers > 2 and leak-resolution=low, or num-callers > > 4 and leak-resolution=mid. > > It would make more sense to just have the num-callers option, perhaps with > num-callers=0 meaning "the entire stack" which would be the equivalent of > leak-resolution=high. The manual describes --leak-resolution like this: When doing leak checking, determines how willing Memcheck is to consider different backtraces to be the same. When set to low, the default, only the first two entries need match. When med, four entries have to match. When high, all entries need to match. For hardcore leak debugging, you probably want to use --leak-resolution=high together with --num-callers=40 or some such large number. Note however that this can give an overwhelming amount of information, which is why the defaults are 4 callers and low-resolution matching. I don't know how much people use --leak-resolution. It would be interesting to hear what people think: - is the default trace merging confusing? - does anyone use --leak-resolution=high? And any other relevant opinions. N |
|
From: Howard C. <hy...@sy...> - 2004-07-06 08:41:37
|
Tom Hughes wrote: > All allocations made from malloc called from ber_memalloc_x will be > grouped together in that report, regardless of where ber_memalloc_x > was called from. Changing the leak resolution will stop that. Thanks. I had actually used --leak-resolution=high in an older test script, I just seem to have forgotten about it this time around. My mistake. This may be a silly question, but why does this leak-resolution option even exist? When is it ever useful to have leak-resolution and num-callers set differently? E.g., it's pointless to have leak-resolution=high and num-callers < 4. Or num-callers > 2 and leak-resolution=low, or num-callers > 4 and leak-resolution=mid. It would make more sense to just have the num-callers option, perhaps with num-callers=0 meaning "the entire stack" which would be the equivalent of leak-resolution=high. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support |
|
From: Tom H. <th...@cy...> - 2004-07-06 06:17:33
|
In message <40E...@sy...>
Howard Chu <hy...@sy...> wrote:
> Tom Hughes wrote:
>
> > Bear in mind the leak resolution is set to low by default, which means
> > that any leaks which share the same two locations at the bottom of the
> > stack trace will be merged - try using --leak-resolution=high and see
> > if that changes things.
>
> Here's the actual report:
> ==13499== 29454 bytes in 519 blocks are definitely lost in loss record
> 24 of 25
> ==13499== at 0x7501E8B4: malloc (vg_replace_malloc.c:105)
> ==13499== by 0x812BE28: ber_memalloc_x (memory.c:232)
> ==13499== by 0x812BF30: ber_strdup_x (memory.c:662)
> ==13499== by 0x807368B: ch_strdup (ch_malloc.c:136)
> ==13499== by 0x804CD9D: main (main.c:412)
>
> This is from OpenLDAP slapd, current CVS HEAD. I didn't expect that
> leak-resolution would change anything, because there simply isn't any
> other code path possible from this point. No branches, no loops, and no
> other function calls. This result was produced with --num-callers=8 so
> this stack trace is complete, bottom to top of stack, and there
> certainly isn't anything above main().
All allocations made from malloc called from ber_memalloc_x will be
grouped together in that report, regardless of where ber_memalloc_x
was called from. Changing the leak resolution will stop that.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Howard C. <hy...@sy...> - 2004-07-06 02:17:52
|
Tom Hughes wrote: > In message <40E...@sy...> > Howard Chu <hy...@sy...> wrote: >>While looking for memory leaks in my code I found that valgrind reported >>519 lost blocks attributed to a line of code that is only executed once. >>In this case it is a strdup that copies a single command-line argument, >>in the startup phase of the program's main(). >>Needless to say, this was a bit puzzling; but since I know there cannot >>be 519 passes thru this bit of code, I pretty much ignored that part of >>the report. But seeing that makes me very skeptical about the other >>leaks that it reported. Any idea why it's so far from reality? > Bear in mind the leak resolution is set to low by default, which means > that any leaks which share the same two locations at the bottom of the > stack trace will be merged - try using --leak-resolution=high and see > if that changes things. Here's the actual report: ==13499== 29454 bytes in 519 blocks are definitely lost in loss record 24 of 25 ==13499== at 0x7501E8B4: malloc (vg_replace_malloc.c:105) ==13499== by 0x812BE28: ber_memalloc_x (memory.c:232) ==13499== by 0x812BF30: ber_strdup_x (memory.c:662) ==13499== by 0x807368B: ch_strdup (ch_malloc.c:136) ==13499== by 0x804CD9D: main (main.c:412) This is from OpenLDAP slapd, current CVS HEAD. I didn't expect that leak-resolution would change anything, because there simply isn't any other code path possible from this point. No branches, no loops, and no other function calls. This result was produced with --num-callers=8 so this stack trace is complete, bottom to top of stack, and there certainly isn't anything above main(). At the moment I'm unable to test this with memcheck; as I reported earlier my desktop machine runs too slowly to test (it's stuck on kernel 2.2.25 and would take weeks to get the result) and my laptop doesn't seem to have enough RAM for the test, it always aborts with a malloc failure. (I'm waiting for a new machine, a few more days before it gets delivered...) The actual invocation was: valgrind -v --skin=addrcheck --gdb-attach=yes --num-callers=8 --leak-check=yes --gdb-path=~/bin/rungdb --logfile-fd=3 3>&1 slapd -f $CONF1 -h $URI1 -d $LVL > $LOG1 2>&1 < /dev/tty & CONF1 is ./testrun/slapd.1.conf URI1 is ldap://:9011 LVL is 4 LOG1 is ./testrun/slapd.1.log There were no errors; gdb was never invoked during this run. I'll try again with leak-resolution=high and see if that makes a difference. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support |
|
From: Tom H. <th...@cy...> - 2004-07-05 22:14:49
|
In message <40E...@sy...>
Howard Chu <hy...@sy...> wrote:
> While looking for memory leaks in my code I found that valgrind reported
> 519 lost blocks attributed to a line of code that is only executed once.
> In this case it is a strdup that copies a single command-line argument,
> in the startup phase of the program's main().
>
> Needless to say, this was a bit puzzling; but since I know there cannot
> be 519 passes thru this bit of code, I pretty much ignored that part of
> the report. But seeing that makes me very skeptical about the other
> leaks that it reported. Any idea why it's so far from reality?
Bear in mind the leak resolution is set to low by default, which means
that any leaks which share the same two locations at the bottom of the
stack trace will be merged - try using --leak-resolution=high and see
if that changes things.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Crispin F. <val...@fl...> - 2004-07-05 22:09:55
|
On Mon, 2004-07-05 at 21:32 +0100, Julian Seward wrote: > > Needless to say, this was a bit puzzling; but since I know there cannot > > be 519 passes thru this bit of code, I pretty much ignored that part of > > the report. But seeing that makes me very skeptical about the other > > leaks that it reported. Any idea why it's so far from reality? > > That is a little strange. One question is, if you re-run it with > memcheck instead of addrcheck, do you get more plausible results? > Reason I ask is that the leak checkers have to scan all address > space they believe is accessible, to search for pointers to blocks. > Since memcheck tracks definedness as well as addressibility, it > may wind up scanning less memory and therefore produce more accurate > results. Just a thought. Isn't this just the --leak-resolution defaulting to just the top 3 (or is it 2) stack frames ? Does it help if you use --leak-resolution=high on the command line? Crispin |
|
From: Julian S. <js...@ac...> - 2004-07-05 20:31:05
|
> Needless to say, this was a bit puzzling; but since I know there cannot > be 519 passes thru this bit of code, I pretty much ignored that part of > the report. But seeing that makes me very skeptical about the other > leaks that it reported. Any idea why it's so far from reality? That is a little strange. One question is, if you re-run it with memcheck instead of addrcheck, do you get more plausible results? Reason I ask is that the leak checkers have to scan all address space they believe is accessible, to search for pointers to blocks. Since memcheck tracks definedness as well as addressibility, it may wind up scanning less memory and therefore produce more accurate results. Just a thought. J |