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
(5) |
2
(11) |
3
(5) |
4
(1) |
5
|
|
6
(6) |
7
(2) |
8
(4) |
9
(7) |
10
(17) |
11
(3) |
12
(3) |
|
13
(5) |
14
(5) |
15
(6) |
16
(6) |
17
(5) |
18
(1) |
19
(5) |
|
20
(6) |
21
(10) |
22
(5) |
23
(5) |
24
(2) |
25
(3) |
26
(1) |
|
27
(1) |
28
|
|
|
|
|
|
|
From: Tom H. <to...@co...> - 2005-02-10 14:44:01
|
In message <Pin...@jd...>
Igmar Palsenberg <mai...@jd...> wrote:
>> I've seen the same thing, environment open hangs in valgrind, but not
>> with all version of linux we test on.
>>
>> I found this post:
>>
>> http://groups-beta.google.com/group/comp.databases.berkeley-
>> db/browse_thread/thread/af5930696f77ff9e/9f8cea87300debd8?
>> q=valgrind&_done=%2Fgroup%2Fcomp.databases.berkeley-db%2Fsearch%3Fgroup%
>> 3Dcomp.databases.berkeley-db%26q%3Dvalgrind%26qt_g%3D1%26searchnow%
>> 3DSearch+this+group%26&_doneTitle=Back+to+Search&&d#9f8cea87300debd8
>>
>> which suggested rebuilding berkeley '--with-mutex=x86/gcc-assembly'.
>> This worked for me, though I'm less than satisfied with this work
>> around: I'd rather test with the production builds of the libraries.
>
> The error is probably due to the kernel lacking support for futexes.
> Usually an export LD_ASSUME_KERNEL=2.4.0 fixes this. Valgrind should
> support native pthreads in the CVS version, no idea if it supports
> futexes.
It supports futexes just fine. So does 2.2.0 in fact, it's just that
our libpthread didn't use them so unless you used then directly you
would never see them.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-02-10 14:38:53
|
On Thu, 10 Feb 2005, Dimitri Papadopoulos-Orfanos wrote: >> So what can I do? I want to test memory leak for our ia64 application. Do >> you know other tool can be used on ia64? > > Insure++ supports on AMD64 and Intel EM64T processors. > http://www.parasoft.com/ > > Purify has no specific hardware requirements so it should work on your > platform: > http://www-306.ibm.com/software/awdtools/purify/ > http://www-306.ibm.com/software/awdtools/purifyplus/ Pin (rogue.colorado.edu/Pin/) is a dynamic binary instrumentation framework that works on ia64, ia32 and amd64. I don't think it has a memory leak detector, but it would be a good framework for building one :) N |
|
From: Igmar P. <mai...@jd...> - 2005-02-10 14:30:43
|
> I've seen the same thing, environment open hangs in valgrind, but not > with all version of linux we test on. > > I found this post: > > http://groups-beta.google.com/group/comp.databases.berkeley- > db/browse_thread/thread/af5930696f77ff9e/9f8cea87300debd8? > q=valgrind&_done=%2Fgroup%2Fcomp.databases.berkeley-db%2Fsearch%3Fgroup% > 3Dcomp.databases.berkeley-db%26q%3Dvalgrind%26qt_g%3D1%26searchnow% > 3DSearch+this+group%26&_doneTitle=Back+to+Search&&d#9f8cea87300debd8 > > which suggested rebuilding berkeley '--with-mutex=x86/gcc-assembly'. > This worked for me, though I'm less than satisfied with this work > around: I'd rather test with the production builds of the libraries. The error is probably due to the kernel lacking support for futexes. Usually an export LD_ASSUME_KERNEL=2.4.0 fixes this. Valgrind should support native pthreads in the CVS version, no idea if it supports futexes. Igmar |
|
From: Tom H. <to...@co...> - 2005-02-10 09:17:53
|
In message <420...@sh...>
Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote:
> Hi,
>
>> So what can I do? I want to test memory leak for our ia64
>> application. Do you know other tool can be used on ia64?
>
>
> Insure++ supports on AMD64 and Intel EM64T processors.
> http://www.parasoft.com/
But IA64 is Itanium which is completely different to AMD64/EMT64T.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2005-02-10 09:03:07
|
Hi, > So what can I do? I want to test memory leak for our ia64 application. > Do you know other tool can be used on ia64? Insure++ supports on AMD64 and Intel EM64T processors. http://www.parasoft.com/ Purify has no specific hardware requirements so it should work on your platform: http://www-306.ibm.com/software/awdtools/purify/ http://www-306.ibm.com/software/awdtools/purifyplus/ Dimitri |
|
From: Howard C. <hy...@sy...> - 2005-02-10 07:00:58
|
ZhangPu wrote: >/usr/include/dlfcn.h >#ifdef __USE_GNU >... ># define RTLD_NEXT ((void *) -1l) >... >#endif > >Need a GNU make? > > No, but you need to add "-D__USE_GNU" to the CFLAGS, I think. On older versions of glibc it was defined by default, not sure when/why it changed. Most of the autoconf machinery in this package is pretty broken. It was like that in the original FunctionCheck 1.4 and I've never bothered to fix it, since I was only interested in getting it to work for myself on Linux and Solaris. Also the test directory is broken, I never use it. It has tests for C and C++, but I've only used this tool for C. (assert( C > C++) ;) >On Thu, 10 Feb 2005 15:36:16 +0900 >ZhangPu <zh...@fj...> wrote: > > > >>Thanks for you supplied this tool. >>I'm compiling it now. >> >>But I got the error fllowing when did 'make': >>fncmalloc.c: In function `hx_init_malloc': >>fncmalloc.c:34: error: `RTLD_NEXT' undeclared (first use in this function) >>fncmalloc.c:34: error: (Each undeclared identifier is reported only once >>fncmalloc.c:34: error: for each function it appears in.) >> >>checked dlfcn.h >>[isdev@ipf124 fnccheck]$ rpm -qf /usr/include/dlfcn.h >>glibc-headers-2.3.3-73 >>[isdev@ipf124 fnccheck]$ grep RTLD_NEXT /usr/include/* 2> /dev/null >>/usr/include/dlfcn.h:/* If the first argument of `dlsym' or `dlvsym' is set to RTLD_NEXT >>/usr/include/dlfcn.h:# define RTLD_NEXT ((void *) -1l) >> >>Any ideas? >> >>Thanks & Regards >>Pu >>On Wed, 09 Feb 2005 21:40:33 -0800 >>Howard Chu <hy...@sy...> wrote: >> >> > > > > -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support |
|
From: ZhangPu <zh...@fj...> - 2005-02-10 06:51:52
|
/usr/include/dlfcn.h #ifdef __USE_GNU =2E.. # define RTLD_NEXT ((void *) -1l) =2E.. #endif Need a GNU make? On Thu, 10 Feb 2005 15:36:16 +0900 ZhangPu <zh...@fj...> wrote: >=20 > Thanks for you supplied this tool. > I'm compiling it now. >=20 > But I got the error fllowing when did 'make': > fncmalloc.c: In function `hx_init_malloc': > fncmalloc.c:34: error: `RTLD_NEXT' undeclared (first use in this function= ) > fncmalloc.c:34: error: (Each undeclared identifier is reported only once > fncmalloc.c:34: error: for each function it appears in.) >=20 > checked dlfcn.h > [isdev@ipf124 fnccheck]$ rpm -qf /usr/include/dlfcn.h > glibc-headers-2.3.3-73 > [isdev@ipf124 fnccheck]$ grep RTLD_NEXT /usr/include/* 2> /dev/null > /usr/include/dlfcn.h:/* If the first argument of `dlsym' or `dlvsym' is s= et to RTLD_NEXT > /usr/include/dlfcn.h:# define RTLD_NEXT ((void *) -1l) >=20 > Any ideas? >=20 > Thanks & Regards > Pu > On Wed, 09 Feb 2005 21:40:33 -0800 > Howard Chu <hy...@sy...> wrote: >=20 > > Robert Walsh wrote: > >=20 > > >>So what can I do? I want to test memory leak for our ia64 application.= =20 > > >>Do you know other tool can be used on ia64?=20 > > >> =20 > > >> > > > > > >Sorry - I can't think of any. You might want to try porting to x86 an= d > > >testing there, but it won't be perfect. > > > > > I think FunctionCheck should work. I have an update to correct some=20 > > int/long portability issues I encountered on an x86_64 test, still need= =20 > > to get that posted onto my web site. (See the HighlandSun link in my=20 > > .sig...) > >=20 > > --=20 > > -- Howard Chu > > Chief Architect, Symas Corp. Director, Highland Sun > > http://www.symas.com http://highlandsun.com/hyc > > Symas: Premier OpenSource Development and Support >=20 >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: ZhangPu <zh...@fj...> - 2005-02-10 06:36:58
|
Thanks for you supplied this tool. I'm compiling it now. But I got the error fllowing when did 'make': fncmalloc.c: In function `hx_init_malloc': fncmalloc.c:34: error: `RTLD_NEXT' undeclared (first use in this function) fncmalloc.c:34: error: (Each undeclared identifier is reported only once fncmalloc.c:34: error: for each function it appears in.) checked dlfcn.h [isdev@ipf124 fnccheck]$ rpm -qf /usr/include/dlfcn.h glibc-headers-2.3.3-73 [isdev@ipf124 fnccheck]$ grep RTLD_NEXT /usr/include/* 2> /dev/null /usr/include/dlfcn.h:/* If the first argument of `dlsym' or `dlvsym' is set to RTLD_NEXT /usr/include/dlfcn.h:# define RTLD_NEXT ((void *) -1l) Any ideas? Thanks & Regards Pu On Wed, 09 Feb 2005 21:40:33 -0800 Howard Chu <hy...@sy...> wrote: > Robert Walsh wrote: > > >>So what can I do? I want to test memory leak for our ia64 application. > >>Do you know other tool can be used on ia64? > >> > >> > > > >Sorry - I can't think of any. You might want to try porting to x86 and > >testing there, but it won't be perfect. > > > I think FunctionCheck should work. I have an update to correct some > int/long portability issues I encountered on an x86_64 test, still need > to get that posted onto my web site. (See the HighlandSun link in my > .sig...) > > -- > -- Howard Chu > Chief Architect, Symas Corp. Director, Highland Sun > http://www.symas.com http://highlandsun.com/hyc > Symas: Premier OpenSource Development and Support |
|
From: t. s. u. <sc...@ap...> - 2005-02-10 06:09:13
|
On Wed, 2005-02-09 at 14:17 -0500, Jeff Woods (Boca Raton ) wrote: > I am having trouble getting valgrind to work with an application which > uses the Berkeley DB library. The error I am getting is: > > [8305] ERROR: db_env->open: Function not implemented (main.c:1788) > [8305] ERROR: Abnormal exit status (from main.c:1789): 1 > ==8305== > ==8305== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 59 from 1) > ==8305== malloc/free: in use at exit: 264271 bytes in 651 blocks. > ==8305== malloc/free: 722 allocs, 71 frees, 267037 bytes allocated. > ==8305== For a detailed leak analysis, rerun with: --leak-check=yes > ==8305== For counts of detected errors, rerun with: -v > > Note that the lines prefixed by the PID in brackets are generated by my > application. The error is not within valgrind itself (it is being > returned from a dbenv->open() call in the Berkeley DB library), but > valgrind does seem to be triggering this error. The application will > run normally outside of valgrind, but fails consistently at this point > when run under valgrind. I will trim down my application to a bare > minimum of code to reprodcuce this problem and post it here if necessary. I've seen the same thing, environment open hangs in valgrind, but not with all version of linux we test on. I found this post: http://groups-beta.google.com/group/comp.databases.berkeley- db/browse_thread/thread/af5930696f77ff9e/9f8cea87300debd8? q=valgrind&_done=%2Fgroup%2Fcomp.databases.berkeley-db%2Fsearch%3Fgroup% 3Dcomp.databases.berkeley-db%26q%3Dvalgrind%26qt_g%3D1%26searchnow% 3DSearch+this+group%26&_doneTitle=Back+to+Search&&d#9f8cea87300debd8 which suggested rebuilding berkeley '--with-mutex=x86/gcc-assembly'. This worked for me, though I'm less than satisfied with this work around: I'd rather test with the production builds of the libraries. -- t. scott urban <sc...@ap...> |
|
From: Howard C. <hy...@sy...> - 2005-02-10 05:38:53
|
Robert Walsh wrote: >>So what can I do? I want to test memory leak for our ia64 application. >>Do you know other tool can be used on ia64? >> >> > >Sorry - I can't think of any. You might want to try porting to x86 and >testing there, but it won't be perfect. > I think FunctionCheck should work. I have an update to correct some int/long portability issues I encountered on an x86_64 test, still need to get that posted onto my web site. (See the HighlandSun link in my .sig...) -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support |
|
From: Robert W. <rj...@du...> - 2005-02-10 05:15:31
|
> So what can I do? I want to test memory leak for our ia64 application.=20 > Do you know other tool can be used on ia64?=20 Sorry - I can't think of any. You might want to try porting to x86 and testing there, but it won't be perfect. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: ZhangPu <zh...@fj...> - 2005-02-10 05:00:16
|
So what can I do? I want to test memory leak for our ia64 application. Do you know other tool can be used on ia64? Thanks & Regards Pu On Wed, 09 Feb 2005 20:52:04 -0800 Robert Walsh <rj...@du...> wrote: > > But from the http://fedora.server4you.net/fedora/core/development/ia64/SRPMS/ > > a valgrind-2.2.0-8.src.rpm package which includes some patchs was supplied > > yesterday. > > > > It seemed like this one can be worked on ia64. > > Looks to me like the stock Valgrind 2.2.0 source RPM with some useful > non-arch-specific patches attached. There's nothing in there to port it > to IA64, though. There's no corresponding RPM file in the Fedora/RPMS > directory either, so they didn't build it. They probably just grabbed > all the stock Fedora source RPMS, stuck them in there and ported what > they could. > > Valgrind isn't going to be running on IA64 any time soon. > > Regards, > Robert. > > -- > Robert Walsh > Amalgamated Durables, Inc. - "We don't make the things you buy." > Email: rj...@du... |
|
From: Robert W. <rj...@du...> - 2005-02-10 04:52:10
|
> But from the http://fedora.server4you.net/fedora/core/development/ia64/SR= PMS/ > a valgrind-2.2.0-8.src.rpm package which includes some patchs was supplie= d=20 > yesterday. >=20 > It seemed like this one can be worked on ia64.=20 Looks to me like the stock Valgrind 2.2.0 source RPM with some useful non-arch-specific patches attached. There's nothing in there to port it to IA64, though. There's no corresponding RPM file in the Fedora/RPMS directory either, so they didn't build it. They probably just grabbed all the stock Fedora source RPMS, stuck them in there and ported what they could. Valgrind isn't going to be running on IA64 any time soon. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: ZhangPu <zh...@fj...> - 2005-02-10 04:28:49
|
Thanks for your answer. > You can't. Valgrind is currently x86-only, and ia64 support is very > unlikely to occur any time soon. But from the http://fedora.server4you.net/fedora/core/development/ia64/SRPMS/ a valgrind-2.2.0-8.src.rpm package which includes some patchs was supplied yesterday. It seemed like this one can be worked on ia64. Did sb. compile this successfully? On my machine, I cannot clear make error. If sb. compiled it, would you please paste your steps on this mailing list? Pu |
|
From: Nicholas N. <nj...@cs...> - 2005-02-09 19:17:43
|
On Wed, 9 Feb 2005, ZhangPu wrote: > How can I compile the valgrind-2.2.0 on a ia64 machine? You can't. Valgrind is currently x86-only, and ia64 support is very unlikely to occur any time soon. N |
|
From: Jeff W. (B. R. ) <Jef...@ch...> - 2005-02-09 19:17:37
|
I am having trouble getting valgrind to work with an application which uses the Berkeley DB library. The error I am getting is: [8305] ERROR: db_env->open: Function not implemented (main.c:1788) [8305] ERROR: Abnormal exit status (from main.c:1789): 1 ==8305== ==8305== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 59 from 1) ==8305== malloc/free: in use at exit: 264271 bytes in 651 blocks. ==8305== malloc/free: 722 allocs, 71 frees, 267037 bytes allocated. ==8305== For a detailed leak analysis, rerun with: --leak-check=yes ==8305== For counts of detected errors, rerun with: -v Note that the lines prefixed by the PID in brackets are generated by my application. The error is not within valgrind itself (it is being returned from a dbenv->open() call in the Berkeley DB library), but valgrind does seem to be triggering this error. The application will run normally outside of valgrind, but fails consistently at this point when run under valgrind. I will trim down my application to a bare minimum of code to reprodcuce this problem and post it here if necessary. I found this report from more than a year ago which is nearly identical to the problem I'm having: http://sourceforge.net/mailarchive/forum.php?forum_id=32038&style=flat&viewday=15&viewmonth=200311 I tried applying the patch, but the structure of the vg_malloc_replace.c file is completely different than what is described in the patch. There is no reference to __posix_memalign() to be found, and there is no line 375. Being a year old, I'm sure that this patch has made its way into the source if it was the solution to the problem described. I am currently using the valgrind package provided by my distribution (SuSE 9.2 professional, valgrind = 2.2.0-3). I have tried building from the sources on valgrind.kde.org, but the build fails at: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include -I../include -I./x86 -DVG_LIBDIR="\"/usr/local/valgrind/lib/valgrind"\" -DKICKSTART_BASE=0xb0000000 -Winline -Wall -Wshadow -O -fno-omit-frame-pointer -mpreferred-stack-boundary=2 -g -DELFSZ=32 -MT vg_syscalls.o -MD -MP -MF ".deps/vg_syscalls.Tpo" -c -ovg_syscalls.o vg_syscalls.c; \ then mv -f ".deps/vg_syscalls.Tpo" ".deps/vg_syscalls.Po"; else rm -f ".deps/vg_syscalls.Tpo"; exit 1; fi In file included from /usr/include/linux/msg.h:5, from vg_unsafe.h:56, from vg_syscalls.c:35: /usr/include/linux/list.h:699:2: warning: #warning "don't include kernel headers in userspace" In file included from /usr/include/linux/mii.h:12, from vg_unsafe.h:76, from vg_syscalls.c:35: /usr/include/linux/if.h:95: error: redefinition of `struct ifmap' /usr/include/linux/if.h:131: error: redefinition of `struct ifreq' /usr/include/linux/if.h:181: error: redefinition of `struct ifconf' make[4]: *** [vg_syscalls.o] Error 1 |
|
From: Michael R. <val...@no...> - 2005-02-09 17:28:42
|
Hi all.
First of all, I'm quite new to Valgrind, so it might well be that I'm
stumbling over something that is well known and commonly accepted.
I'm trying to hunt down some memory leaks in a program I'm writing. The
relevant lines go like this:
=== cut ===
#define PROG_DEFAULT_CFGFILE "/etc/prog.conf"
#define PROG_DEFAULT_PIDFILE "/var/run/prog.pid"
void atexit_handler(void) {
[...]
if (config.cfgfile)
free(config.cfgfile);
if (config.pidfile)
free(config.pidfile);
[...]
return;
}
int main(int argc, char *argv[]) {
config.cfgfile = strdup(PROG_DEFAULT_CFGFILE);
config.pidfile = strdup(PROG_DEFAULT_PIDFILE);
[...]
atexit(atexit_handler);
[...]
while(1) {
// main program loop
}
}
=== cut ===
The program has also a handler for SIGINT and SIGTERM, which emits a
short information and then calls "exit(0);". This way the
atexit_handler() routine is executed and the memory that has been
malloc'ed by strdup() gets freed. Well, at least that's the theory.
I run valgrind and my program with the following command:
valgrind --tool=memcheck --leak-check=yes -v ./prog --debug
The program runs fine, and when I press CTRL+C it exits as expected
after calling atexit_handler(). But still I see the following report
from valgrind:
=== cut ===
[...]
==10140== malloc/free: in use at exit: 5085 bytes in 6 blocks.
==10140== malloc/free: 1012 allocs, 1006 frees, 898940 bytes allocated.
==10140==
==10140== searching for pointers to 6 not-freed blocks.
==10140== checked 1420944 bytes.
==10140==
==10140==
==10140== 20 bytes in 1 blocks are definitely lost in loss record 2 of 6
==10140== at 0x1B904C4D: malloc (vg_replace_malloc.c:131)
==10140== by 0x1B99392F: strdup (in /lib/libc-2.3.4.so)
==10140== by 0x804A5FC: main (main.c:520)
[...]
=== cut ===
main.c:520 is the line that says:
config.pidfile = strdup(PROG_DEFAULT_PIDFILE);
The question is: why does this happen? I verified that atexit_handler()
is called when pressing CTRL+C. I also verified that
"free(config.pidfile)" is actually executed. So I'd expect that this
message should not appear at all. But it is.
Any ideas? I'm completely clueless and begin to feel like an idiot :)
Please let me know when I missed to mention relevant information.
Bye, Mike
|
|
From: Ross B. <ro...@bu...> - 2005-02-09 17:19:06
|
On Wed, 2005-02-09 at 14:24 +0100, Josef Weidendorfer wrote:
> Hmm... Can you try again? Yesterday I committed some changes (as response to
> your mail), and Sourceforge always seems to be 1 day behind for anonymous CVS
> access (?).
Ah, much better, thanks.
Note that I did have to insert #include <setjmp.h> into src/sim.c to
make it compile.
Thanks again,
Ross
--
Ross Burton mail: ro...@bu...
jabber: ro...@bu...
www: http://www.burtonini.com./
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
|
|
From: Josef W. <Jos...@gm...> - 2005-02-09 16:10:08
|
On Tuesday 08 February 2005 15:50, Ross Burton wrote: > On Tue, 2005-02-08 at 14:32 +0100, Josef Weidendorfer wrote: > > Officially: Wait for next VG release. Callgrind never will suport CVS > > versions. > > But you can check out Callgrind CVS. Module callgrind in KCachegrind > > project at sourceforge.net. > > This is with callgrind from CVS... Hmm... Can you try again? Yesterday I committed some changes (as response to your mail), and Sourceforge always seems to be 1 day behind for anonymous CVS access (?). Josef > > Ross |
|
From: ZhangPu <zh...@fj...> - 2005-02-09 11:14:44
|
Hello How can I compile the valgrind-2.2.0 on a ia64 machine? Thank you Pu |
|
From: Ben <b_...@ya...> - 2005-02-09 11:11:29
|
Hello I'm using valgrind to check very large and complex application. Originally we used valgrind-2.0.0 on RedHat7.2 and it worked nice. Now we've migrated to RedHat9.0 and valgrind-2.2.0 ( 2.0.0 doesn't work on RH9 for some reasons). First valgrind runs VERY slowly even when I use addrcheck ( I used to run memcheck with 2.0.0 ) and even worse, at some execution point valgrind exits with the following error VG_(get_memory_from_mmap): newSuperblock's request for 65536 bytes failed. VG_(get_memory_from_mmap): 253139360 bytes already allocated. I use the following options --tool=addrcheck --leak-check=yes --num-callers=30 --show-reachable=yes --error-limit=no --logfile=valgr_log I would appreciate some advice Thanks __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Ross B. <ro...@bu...> - 2005-02-08 14:52:28
|
On Tue, 2005-02-08 at 14:32 +0100, Josef Weidendorfer wrote: > Officially: Wait for next VG release. Callgrind never will suport CVS > versions. > But you can check out Callgrind CVS. Module callgrind in KCachegrind project > at sourceforge.net. This is with callgrind from CVS... Ross -- Ross Burton mail: ro...@bu... jabber: ro...@bu... www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF |
|
From: Josef W. <Jos...@gm...> - 2005-02-08 13:33:14
|
On Tuesday 08 February 2005 11:54, Ross Burton wrote: > Hi, > > I've build valgrind from CVS for the signal improvements, but when I build > callgrind also from CVS it fails at runtime: > > Can't open tool "callgrind": > /home/users/ross/bin/BUILD/lib/valgrind/vgskin_callgrind.so: > undefined symbol: vgPlain_register_compact_helper > > It appears that the valgrind API has changed and callgrind isn't matching Such things are unavoidable with CVS versions. > it. What changes should I make to fix this? Officially: Wait for next VG release. Callgrind never will suport CVS versions. But you can check out Callgrind CVS. Module callgrind in KCachegrind project at sourceforge.net. Josef > > Thanks, > Ross |
|
From: Hans t. H. <hos...@gm...> - 2005-02-08 11:58:12
|
I'm running the Fedora core and prelinking was set, but unfortunatley the problem persists after running the "prelink -ua" command. Hans. On Mon, 7 Feb 2005 11:01:39 -0800, Paul Pluzhnikov <ppl...@gm...> wrote: > > valgrind: Couldn't allocate address space for shadow memory. > > The funny thing is that it worked fine on Friday. I rebooted the > > Are you running Fedora Core2. > You probably have "random" prelinking enabled (by default it happens > once every 2 weeks) > > Undo the prelinking (as root) "prelink -ua", and try again. > If that helps, edit /etc/sysconfig/prelink, set "PRELINKING=no" > > Cheers, > |
|
From: Ross B. <ro...@bu...> - 2005-02-08 11:02:22
|
Hi,
I've build valgrind from CVS for the signal improvements, but when I build
callgrind also from CVS it fails at runtime:
Can't open tool "callgrind":
/home/users/ross/bin/BUILD/lib/valgrind/vgskin_callgrind.so:
undefined symbol: vgPlain_register_compact_helper
It appears that the valgrind API has changed and callgrind isn't matching
it. What changes should I make to fix this?
Thanks,
Ross
--
Ross Burton mail: ro...@bu...
jabber: ro...@bu...
www: http://www.burtonini.com./
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
|