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
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(18) |
2
(6) |
|
3
(2) |
4
(2) |
5
(5) |
6
(12) |
7
(2) |
8
(1) |
9
(2) |
|
10
(6) |
11
(11) |
12
(12) |
13
(3) |
14
(3) |
15
(2) |
16
|
|
17
(2) |
18
(3) |
19
(43) |
20
(22) |
21
(10) |
22
(21) |
23
(5) |
|
24
|
25
(3) |
26
(12) |
27
(3) |
28
(14) |
29
(25) |
30
(5) |
|
31
(6) |
|
|
|
|
|
|
|
From: Yeshurun, M. <mei...@in...> - 2005-07-21 12:52:12
|
I had the same problem. It's no big deal, I kept multiplying by 10 until it worked. I also had to increase another constant - the number of segments (#defined near VG_N_SEGNAMES, don't remember the exact name). Perhaps these constants should be increased in the released version. Regards, Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Christoph Bartoschek Sent: Thursday, July 21, 2005 3:33 PM To: val...@li... Subject: [Valgrind-users] AMD64 and memory Hi, Someone mentioned that with --enable-pie one can use more memory on AMD64=20 than 1.5GB. Is this correct? However I tried this and it goes further thant without --enable-pie and uses=20 3.5GB when it stops with the following message: coregrind/m_aspacemgr/aspacemgr.c: VG_N_SEGNAMES is too small: increase it and rebuild Valgrind. coregrind/m_aspacemgr/aspacemgr.c: giving up now. What would be a reasonable value for this constant? Should I also increase the=20 other constants in this file? Christoph ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. = http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Julian S. <js...@ac...> - 2005-07-21 12:39:03
|
> coregrind/m_aspacemgr/aspacemgr.c: > VG_N_SEGNAMES is too small: increase it and rebuild Valgrind. > coregrind/m_aspacemgr/aspacemgr.c: > giving up now. > > What would be a reasonable value for this constant? Should I also increase > the other constants in this file? Just keep doubling it until it works, then let me know what you had to set it to. J |
|
From: Christoph B. <bar...@or...> - 2005-07-21 12:34:06
|
Hi, Someone mentioned that with --enable-pie one can use more memory on AMD64 than 1.5GB. Is this correct? However I tried this and it goes further thant without --enable-pie and uses 3.5GB when it stops with the following message: coregrind/m_aspacemgr/aspacemgr.c: VG_N_SEGNAMES is too small: increase it and rebuild Valgrind. coregrind/m_aspacemgr/aspacemgr.c: giving up now. What would be a reasonable value for this constant? Should I also increase the other constants in this file? Christoph |
|
From: Nicholas N. <nj...@cs...> - 2005-07-21 00:15:16
|
On Wed, 20 Jul 2005, parag shah wrote: > ya this works. what i was actually doing is running valgrind as a backgrond > process and thus could not do a cltr c. doing a kill -9 didnt work. > > if i dont run it with & then i can do a cltr c which propogates to my > precess, kills it and then valgrind can calculate the memory leak. kill -9 sends "SIGKILL" which no process can catch, which is why Valgrind doesn't do the leak checking. Use "kill -2" or "kill -15" (SIGTERM and SIGINT respectively) instead and Valgrind will do leak checking. N |
|
From: Nicholas N. <nj...@cs...> - 2005-07-20 18:26:09
|
On Wed, 20 Jul 2005, parag shah wrote: > i want to run valdring on a process that does not die by itself. the only > way to kill it is usually kill or cltr c . however i cant do that without > killing valgrind. > > so i was wondering if valgrind creates some log file of some kind which it > keeps on updating all the time that the process is running and then uses > this log file at the end of the process to calculate the memory leaks. > > if this is present then i can just kill valgrind and then ask it to analyse > that log file to give me the leak summary. If you Ctrl-C a program running under Valgrind it should terminate and then Valgrind should do it's normal termination actions, including leak checking when you are using Memcheck. So maybe something else is going wrong. You'll have to give more details, such as the program you are running and how you are invoking, what version of Valgrind, etc. If you can produce a small test case that would help a lot. N |
|
From: Brian C. <cr...@fi...> - 2005-07-20 17:24:03
|
You can send other signals to your process using kill... if interrupts and sigquit are being eaten by valgrind, try using one of the SIGUSR signals. -- Brian parag shah wrote: > hey > > i am having the following problem.... > > i want to run valdring on a process that does not die by itself. the > only way to kill it is usually kill or cltr c . however i cant do that > without killing valgrind. > > so i was wondering if valgrind creates some log file of some kind which > it keeps on updating all the time that the process is running and then > uses this log file at the end of the process to calculate the memory leaks. > > if this is present then i can just kill valgrind and then ask it to > analyse that log file to give me the leak summary. > > i would really appretiate it if the developers can let me know if > something of this sort is possible. > > > thanks > parag shah > |
|
From: parag s. <par...@gm...> - 2005-07-20 17:17:35
|
hey i am having the following problem....=20 i want to run valdring on a process that does not die by itself. the only= =20 way to kill it is usually kill or cltr c . however i cant do that without= =20 killing valgrind.=20 so i was wondering if valgrind creates some log file of some kind which it= =20 keeps on updating all the time that the process is running and then uses=20 this log file at the end of the process to calculate the memory leaks.=20 if this is present then i can just kill valgrind and then ask it to analyse= =20 that log file to give me the leak summary.=20 i would really appretiate it if the developers can let me know if something= =20 of this sort is possible.=20 thanks parag shah |
|
From: Julian S. <js...@ac...> - 2005-07-20 15:27:36
|
> > As I've said, it is a RedHat Linux 6.0, > > kernel version 2.4.2-2smp, libc-2.2.2. > > > > What seem to be the problem? > > RedHat 6.0 and kernel 2.4.2 are very old, possibly too old for Valgrind to > handle correctly... Correct. At the moment really the oldest we support is Red Hat 7.3, and that is pretty old. Maybe it is time to upgrade your Linux installation? J |
|
From: Tom H. <to...@co...> - 2005-07-20 15:27:08
|
In message <200...@ge...>
Christian Parpart <tr...@ge...> wrote:
> On Wednesday 20 July 2005 16:54, Tom Hughes wrote:
>
>> It's mapping it to stop anything else being given that part of the
>> address space - it is how valgrind controls where the OS puts stuff.
>>
>> Note that the memory will never be touched so it is an entirely
>> virtual concept and how much memory or swap you should not matter
>> in the slightest. That is why we pass the NORESERVE flag to indicate
>> that the kernel doesn't need to reserve any swap to back the mapping.
>
> Ah, I seem to understand; however, I now start wondering why the kernel takes
> so long there. Might this be a kernel bug (regarding performance)?
Probably something to do with setting up the page tables. I can't say
that I've noticed it on my amd64 box.
> Although - I'm just curious - how are you thinking of working around such
> (mis)behaviors when not using m[un]map?
There was a thread the other day where Julian and I explained about
the places to rework the address space manager so that there is no
need to maintain a rigid split of the address space.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Christian P. <tr...@ge...> - 2005-07-20 15:11:22
|
On Wednesday 20 July 2005 16:54, Tom Hughes wrote: > In message <200...@ge...> > Christian Parpart <tr...@ge...> wrote: > > On Wednesday 20 July 2005 15:39, Nicholas Nethercote wrote: > >> The mmap and munmap calls are very big -- 61680GB and 69390GB > >> respectively. The fact that it happens before the usage message shows > >> this is happening very early. I guess these mmap/munmap calls are from > >> the start-up padding, but then the question is why isn't this causing > >> problems on other AMD64 systems? > > > > I'm having 2GB RAM, and 1GB swap. maybe this matters? > > Besides, why the hell is valgrind m[un]mapping such a huge space (I even > > haven't that much RAM et al) > > It's mapping it to stop anything else being given that part of the > address space - it is how valgrind controls where the OS puts stuff. > > Note that the memory will never be touched so it is an entirely > virtual concept and how much memory or swap you should not matter > in the slightest. That is why we pass the NORESERVE flag to indicate > that the kernel doesn't need to reserve any swap to back the mapping. Ah, I seem to understand; however, I now start wondering why the kernel tak= es=20 so long there. Might this be a kernel bug (regarding performance)? Although - I'm just curious - how are you thinking of working around such=20 (mis)behaviors when not using m[un]map? And why am I (obviousely) the only one having this problem? Regards, Christian Parpart. |
|
From: Nicholas N. <nj...@cs...> - 2005-07-20 15:09:49
|
On Tue, 19 Jul 2005, Konstantin Karganov wrote: > I've just downloaded & installed valgrind (ver. 2.4.0) on RedHat 6.0 box. > But all it can say is > "valgrind: we didn't see enough auxv entries (seen=0)" > > (even when called as "valgrind --version"). > > As I've said, it is a RedHat Linux 6.0, > kernel version 2.4.2-2smp, libc-2.2.2. > > What seem to be the problem? RedHat 6.0 and kernel 2.4.2 are very old, possibly too old for Valgrind to handle correctly... N |
|
From: Nicholas N. <nj...@cs...> - 2005-07-20 15:05:51
|
On Tue, 12 Jul 2005, Nicholas Nethercote wrote: >> I have some news! First off I would like to thank Mr. Weidendorfer >> for >> all the help. I have found, through his suggestion that running a >> program with a space in the path causes these problems. The program was >> originally in >> >> /home/prophecy/Desktop/Summer Project/treffytng/src/treffytng >> >> I moved it to and recompiled it to >> >> /home/prophecy/Desktop/treffytng >> >> and it works great. > > Ah... this is bug #88678 (http://bugs.kde.org/show_bug.cgi?id=88678). I fixed this a few days ago. The fix will be present in 3.0.0 when it is released. N |
|
From: Tom H. <to...@co...> - 2005-07-20 14:54:15
|
In message <200...@ge...>
Christian Parpart <tr...@ge...> wrote:
> On Wednesday 20 July 2005 15:39, Nicholas Nethercote wrote:
>
>> The mmap and munmap calls are very big -- 61680GB and 69390GB
>> respectively. The fact that it happens before the usage message shows
>> this is happening very early. I guess these mmap/munmap calls are from
>> the start-up padding, but then the question is why isn't this causing
>> problems on other AMD64 systems?
>
> I'm having 2GB RAM, and 1GB swap. maybe this matters?
> Besides, why the hell is valgrind m[un]mapping such a huge space (I even
> haven't that much RAM et al)
It's mapping it to stop anything else being given that part of the
address space - it is how valgrind controls where the OS puts stuff.
Note that the memory will never be touched so it is an entirely
virtual concept and how much memory or swap you should not matter
in the slightest. That is why we pass the NORESERVE flag to indicate
that the kernel doesn't need to reserve any swap to back the mapping.
It has been known for kernels to get upset by big mappings however
which is one reason why we plan to reorganise things so that these
large mappings are not required.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Christian P. <tr...@ge...> - 2005-07-20 14:47:38
|
On Wednesday 20 July 2005 15:39, Nicholas Nethercote wrote: > On Wed, 20 Jul 2005, Christian Parpart wrote: > > below is an extract of $(strace valgrind --help); It took me about 2 > > minutes or so to see the output, well, at least, very long. Although, a > > $(ps ax) on another terminal in parralel seems to freeze while traversi= ng > > through the process list. $(top) shows valgrind to be using 98% of my > > CPU. > > > > /* below follows the obove mentioned output (stripped) */ > > > > munmap(0, 66229278605312 > > > > /* here it freeyes for about 20 seconds */ > > > > ) =3D 0 > > mmap(0x3c3c34b00000, 74507940265984, PROT_NONE, > > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0 > > > > /* it freezes again */ > > > > ) =3D 0x3c3c34b00000 > > > > ... > > > > write(1, "usage: valgrind --tool=3D<toolname"..., 90usage: valgrind > > --tool=3D<toolname> [options] prog-and-args > > > > /* ... */ > > > > exit_group(0) =3D ? > > > > /* again, it freezes, and then returns to command prompt */ > > > > NOW, I'd be happy when someone tells me that this is a known issue and = is > > gonna be fixed right the way (before 3.0.0 hits the line) > > I haven't seen this one. > > The mmap and munmap calls are very big -- 61680GB and 69390GB > respectively. The fact that it happens before the usage message shows > this is happening very early. I guess these mmap/munmap calls are from > the start-up padding, but then the question is why isn't this causing > problems on other AMD64 systems? I'm having 2GB RAM, and 1GB swap. maybe this matters? Besides, why the hell is valgrind m[un]mapping such a huge space (I even=20 haven't that much RAM et al) > Can you re-run with "valgrind -d" and post the output? Thanks. simple "valgrind -d" (without any other args)? hmm... hold on... run of $(valgrind -d): =2D-22000:1:debuglog DebugLog system started by Stage 1, level 1 logging=20 requested =2D-22000:1:stage1 main(): running main2() on new stack =2D-22000:1:stage1 main2(): starting stage2 =2D-22000:1:debuglog DebugLog system started by Stage 2 (main), level 1 log= ging=20 requested =2D-22000:1:main Doing scan_auxv() =2D-22000:1:main Preprocess command line opts =2D-22000:1:main Loading tool =2D-22000:1:main Laying out remaining space /* big big sleep */ =2D-22000:1:main Loading client valgrind: no program specified valgrind: Use --help for more information. /* big big sleep */ /* return to terminal */ Hope this helps, Christian Parpart. |
|
From: Tom H. <to...@co...> - 2005-07-20 14:39:39
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Wed, 20 Jul 2005, Tom Hughes wrote:
>
>> The vki_sigevent_t definition was out of sync with the 2.6.12 kernel
>> source and I have fixed that.
>
> Did the kernel type change? If so, will this cause problems when
> running Valgrind with older kernels?
The kernel type did change, yes, but only for 64 bit platforms. For
a 32 bit platform both the old and new definitions work out the same.
The structure has three fixed member followed by a union which
contains a couple of members plus an array which is intended to
pad the structure to 64 bytes so there is space for expansion.
On 64 bit platforms it used to add too much padding so there was
more reserved space than was intended because the calculation was
assuming that sigval_t was 32 bits but on 64 bit platforms it is
actually 64 bits.
So although the type has changed it shouldn't cause us any problem
with older kernels.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-20 14:26:33
|
On Wed, 20 Jul 2005, Tom Hughes wrote: > The vki_sigevent_t definition was out of sync with the 2.6.12 kernel > source and I have fixed that. Did the kernel type change? If so, will this cause problems when running Valgrind with older kernels? N |
|
From: Tom H. <to...@co...> - 2005-07-20 14:00:06
|
In message <423...@ds...>
C. Western <mf...@ds...> wrote:
> My knowledge of stabs is very limited, but with a bit of guess work
> and some help from a bugzilla report I was able to get valgrind
> working on my free pascal programs by applying the attached patch to
> rc4.
Thanks for the report.
> --- ./coregrind/vg_stabs.c.orig 2005-03-12 08:22:46.000000000 +0000
> +++ ./coregrind/vg_stabs.c 2005-03-19 19:25:21.813549592 +0000
> @@ -646,6 +646,7 @@
> case -27: type = VG_(st_mkint)(def, 1, True); break;
> case -28: type = VG_(st_mkint)(def, 2, True); break;
> case -29: type = VG_(st_mkint)(def, 4, True); break;
> + case -30: type = VG_(st_mkint)(def, 2, False); break;
> case -31: type = VG_(st_mkint)(def, 8, True); break;
> case -32: type = VG_(st_mkint)(def, 8, False); break;
> case -33: type = VG_(st_mkint)(def, 8, False); break;
I've committed this to the valgrind 3.0 SVN repository.
> --- ./coregrind/vg_stabs.c.orig 2005-03-19 21:33:03.000000000 +0000
> +++ ./coregrind/vg_stabs.c 2005-03-19 21:33:29.000000000 +0000
> @@ -1610,8 +1610,8 @@
> scope.nsyms = 0;
> }
>
> - vg_assert(scope.addr != 0);
> - VG_(addScopeInfo)(si, scope.addr, addr, scope.scope);
> + if (scope.addr != 0)
> + VG_(addScopeInfo)(si, scope.addr, addr, scope.scope);
>
> /* XXX LEAK: free scope if it or any of its inner scopes was
> never added to a scope range */
How did you manage to get a scope at address zero? why do you think
such a scope should be ignored rather than added - maybe your program
really does have code at address zero?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-07-20 13:47:41
|
In message <1798.84.189.216.251.1121865617.squirrel@84.189.216.251>
Christian Parpart <tr...@ge...> wrote:
> syswrap-generic.c:5564 *seems* to report a false positive.
>
> I even zeroed everything out:
>
> struct sigevent event;
> memset(&event, 0, sizeof(event)); before
> /* ... */
> timer_create(CLOCK_REALTIME, &event, &handle);
>
> but valgrind seems to report there an uninitialized evp (event) anyway.
The vki_sigevent_t definition was out of sync with the 2.6.12 kernel
source and I have fixed that. If you ask for SIGEV_THREAD you are still
likely to get a warning however as in that case glibc generate it's
own SIGEV_SIGNAL structure and passes it, and glibc doesn't fill in
irrelevant details in the structure...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Arndt M. <amu...@is...> - 2005-07-20 13:41:30
|
Nicholas Nethercote wrote: > On Tue, 19 Jul 2005, Julian Seward wrote: > >> I must say I find helgrind perplexing and frustrating, because it's >> potentially such an incredibly useful tool, yet we have never really >> made it work as convincingly as I'd like, and now we seem to be >> slipping away from being able to support it. I'd love to be able to >> make a good showing with Helgrind in the future, but it strikes me >> that the difficulties with it put it right at the edge of the >> state-of-the-art. > > > I think data race detection is definitely not a solved problem. As > Arndt pointed out, being able to use Valgrind/Helgrind as a platform > for research in this area is a worthy goal. That's the point, indeed. How much work is it to make Helgrind work in 3.0 again? (Roughly) I would like to volunteer if it's not too difficult and I get some help. Anyway, it would be good for me to understand Valgrind and Helgrind, because afterwards it would be easier to experiment with this platform. I suppose on-the-fly methods are the only practical ways to hunt for concurrent bugs, I found static or model checking techniques impractical for most real-world and large applications. Concerning the performance issues: Did you try to implement a logging mechanism that lets you do the analyses offline? Although, in most cases the amount of data that has to be stored would be too much, but sometimes it might be a useful feature. Arndt |
|
From: Nicholas N. <nj...@cs...> - 2005-07-20 13:39:27
|
On Wed, 20 Jul 2005, Christian Parpart wrote: > below is an extract of $(strace valgrind --help); It took me about 2 > minutes or so to see the output, well, at least, very long. Although, a > $(ps ax) on another terminal in parralel seems to freeze while traversing > through the process list. $(top) shows valgrind to be using 98% of my CPU. > > /* below follows the obove mentioned output (stripped) */ > > munmap(0, 66229278605312 > > /* here it freeyes for about 20 seconds */ > > ) = 0 > mmap(0x3c3c34b00000, 74507940265984, PROT_NONE, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0 > > /* it freezes again */ > > ) = 0x3c3c34b00000 > > ... > > write(1, "usage: valgrind --tool=<toolname"..., 90usage: valgrind > --tool=<toolname> [options] prog-and-args > > /* ... */ > > exit_group(0) = ? > > /* again, it freezes, and then returns to command prompt */ > > NOW, I'd be happy when someone tells me that this is a known issue and is > gonna be fixed right the way (before 3.0.0 hits the line) I haven't seen this one. The mmap and munmap calls are very big -- 61680GB and 69390GB respectively. The fact that it happens before the usage message shows this is happening very early. I guess these mmap/munmap calls are from the start-up padding, but then the question is why isn't this causing problems on other AMD64 systems? Can you re-run with "valgrind -d" and post the output? Thanks. N |
|
From: Christian P. <tr...@ge...> - 2005-07-20 13:20:26
|
Hi, syswrap-generic.c:5564 *seems* to report a false positive. I even zeroed everything out: struct sigevent event; memset(&event, 0, sizeof(event)); before /* ... */ timer_create(CLOCK_REALTIME, &event, &handle); but valgrind seems to report there an uninitialized evp (event) anyway. I'm running on Gentoo/Linux, kernel 2.6.12-gentoo-r2, valgrind3 from svn. Regards, Christian Parpart |
|
From: Ralf B. <ral...@ch...> - 2005-07-20 12:40:49
|
Hi,
I do not have an bugzilla@kde account and won't create one ;) Maybe
someone can file it if its useful for you.
When calling valgrind --tool=massif and specifying a logfile location
like --logfile=/home/user/massif.log, the massif.<pid>.ps and
massif.<pid>.txt get created at the place, where valgrind ist started.
It would be better to store those data also in the directory specified
by the user.
Background:
Currently, I have a script, which tests our product automatically in a
loop with different tools. One test is massif and the script code looks
like the following:
# get informations about this benchmark
foreach $benchmark ( @XMLfiles )
{
my $xmlbenchmark = XMLin(
$ENV{'ORINOCO_LIB_BASE_PATH'}."/regression/config/".$benchmark );
print "Executing valgrind with dale for testcase $benchmark\n";
my $dirname = $xmlbenchmark->{'base'};
my $executable = $xmlbenchmark->{'executable'};
my $arguments = $xmlbenchmark->{'arguments'};
# create temporary directory, copy benchmark, execute valgrind
tool, delete temporary benchmark
# write logfiles to cwd
system( "mkdir -p ".$ENV{'HOME'}."/work/regression/tmp/" );
system( "cp -r
".$ENV{'ORINOCO_LIB_BASE_PATH'}."/regression/benchmarks/".$dirname."
".$ENV{'HOME'}."/work/regression/tmp/".$$."valgrindcheck" );
chdir( $ENV{'HOME'}."/work/regression/tmp/".$$."valgrindcheck" );
system( "valgrind --logfile=${currentdir}/${benchmark}.log
--tool=$tool ".$tooloptions.
" $executable $arguments >> ${currentdir}/execution.log 2>&1" );
chdir( ".." );
system( "rm -rf
".$ENV{'HOME'}."/work/regression/tmp/".$$."valgrindcheck" );
chdir( $currentdir );
}
All the massif output (except log) get deleted, when deleting the
temporary working directory.
A current workaround for me is moving massif.* to $currentdir.
Anyway: thanks for your tools! They are very valuable for us, and they
are really useful, when doing automated tests every day ;)
Kind regards,
Ralf Beckers
--
Ralf Beckers
Lead Development Engineer
ChipVision Design Systems AG
Fritz-Bock-Strasse 5 - 26121 Oldenburg - Germany
phone +49-441-35042-360 fax +49-441-35042-350
email ral...@ch... www.chipvision.com
|
|
From: Dennis L. <pla...@in...> - 2005-07-20 12:34:19
|
Hi, after looking how to tell valgrind about own memory allocators or mempools, I found that it looks like I need to insert client requests. Now this is not always possible, since it needs recompiling and change (maybe not available) source code. Now my Idea (and thus the question if this is possible) was to use some function interception stuff to tell valgrind that those functions allocate memory? Maybe even with some config files so neither recompilation of valgrind nor the executable is needed ? greets Dennis Carpe quod tibi datum est |
|
From: Christian P. <tr...@ge...> - 2005-07-20 11:09:24
|
Hi all,
below is an extract of $(strace valgrind --help); It took me about 2
minutes or so to see the output, well, at least, very long. Although, a
$(ps ax) on another terminal in parralel seems to freeze while traversing
through the process list. $(top) shows valgrind to be using 98% of my CPU=
.
/* below follows the obove mentioned output (stripped) */
open("./.valgrindrc", O_RDONLY) =3D -1 ENOENT (No such file or
directory)
brk(0) =3D 0x5ca000
brk(0x5eb000) =3D 0x5ca000
mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) =3D 0x7ffff147d000
open("/opt/valgrind/lib/valgrind/vgtool_memcheck.so", O_RDONLY) =3D 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360Z\0\0"..., 640=
)
=3D 640
fstat(5, {st_mode=3DS_IFREG|0755, st_size=3D229323, ...}) =3D 0
mmap(NULL, 3796432, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0)
=3D 0x7ffff157d000
mprotect(0x7ffff1597000, 3689936, PROT_NONE) =3D 0
mmap(0x7ffff1697000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x1a000) =3D 0x7ffff1697000
mmap(0x7ffff1698000, 2637264, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) =3D 0x7ffff1698000
close(5) =3D 0
access("/opt/valgrind/lib/valgrind/vgpreload_memcheck.so", R_OK) =3D 0
mmap(0x3c3c34a00000, 1048576, PROT_NONE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) =3D 0x3c3c34a00=
000
munmap(0, 66229278605312
/* here it freeyes for about 20 seconds */
) =3D 0
mmap(0x3c3c34b00000, 74507940265984, PROT_NONE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0
/* it freezes again */
) =3D 0x3c3c34b00000
fstat(3, {st_mode=3DS_IFREG, st_size=3D0, ...}) =3D 0
open("/proc/self/maps", O_RDONLY) =3D 5
read(5, "3c3c34a00000-7ffff0000000 ---p 3"..., 10240) =3D 2079
close(5) =3D 0
munmap(0x7ffff0135000, 1048576) =3D 0
munmap(0x7ffff0741000, 9170944) =3D 0
close(3) =3D 0
mmap(0x3c3c349fe000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) =3D 0x3c3c349fe000
getrlimit(RLIMIT_NOFILE, {rlim_cur=3D1024, rlim_max=3D1024}) =3D 0
setrlimit(RLIMIT_NOFILE, {rlim_cur=3D1024, rlim_max=3D1024}) =3D 0
fcntl(4, F_DUPFD, 1014) =3D 1014
close(4) =3D 0
fcntl(1014, F_SETFD, FD_CLOEXEC) =3D 0
open("/proc/self/maps", O_RDONLY) =3D 3
read(3, "3c3c349fe000-3c3c34a00000 rwxp 3"..., 50000) =3D 1930
read(3, "", 48070) =3D 0
close(3) =3D 0
mmap(0x7ffff0741000, 1048576, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) =3D 0x7ffff0741000
write(1, "usage: valgrind --tool=3D<toolname"..., 90usage: valgrind
--tool=3D<toolname> [options] prog-and-args
/* ... */
exit_group(0) =3D ?
/* again, it freezes, and then returns to command prompt */
NOW, I'd be happy when someone tells me that this is a known issue and is
gonna be fixed right the way (before 3.0.0 hits the line)
I just fetched the sources from svn trunk.
Thanks in advance,
Christian Parpart.
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-20 05:32:43
|
On Wed, 20 Jul 2005, Dennis Lubert wrote: > In the current suppression mechanism, you ask for generating suppression, > copy/paste it into some suppression file, and use this at the command line to > re-run the program. Better would be some mechanism, where the currently > generated suppresion can be chosen to be suppressed for the further program > run, and automagically entered into some program-specific suppression file. > So "disabling" the false positives would be rather fast and filtering the > real bad situations should be faster and more straightforward... Yes. People have written patches for this before, but it's never got into the repository, either because the patches were no good or none of the developers had the time or inclination... N |