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
|
2
(9) |
3
(14) |
4
|
5
(2) |
6
|
|
7
|
8
(2) |
9
(5) |
10
(4) |
11
(1) |
12
(14) |
13
(1) |
|
14
|
15
(4) |
16
(3) |
17
(7) |
18
(2) |
19
|
20
|
|
21
|
22
(2) |
23
(2) |
24
(23) |
25
(15) |
26
(7) |
27
(2) |
|
28
(7) |
29
(2) |
30
(8) |
31
(5) |
|
|
|
|
From: Nicholas N. <nj...@cs...> - 2006-05-17 18:59:08
|
On Wed, 17 May 2006, Julian Seward wrote: > Try 3.1.1 or (better) the current svn trunk. 3.1.0 and later > support up to 32G memory on amd64, which gives you about 14G > usable for 3.1.1. The trunk has a more compact representation > of definedness bits and so you should be good for up to 22+ G > using that. Or even more; if the maps are large and read-only they should be represented very compactly (only one pointer per 64KB). Nick |
|
From: Julian S. <js...@ac...> - 2006-05-17 17:17:43
|
3.0.X on amd64 simply inherited the x86 port's address space management, which means you can't use more than 4G ever. Try 3.1.1 or (better) the current svn trunk. 3.1.0 and later support up to 32G memory on amd64, which gives you about 14G usable for 3.1.1. The trunk has a more compact representation of definedness bits and so you should be good for up to 22+ G using that. J On Wednesday 17 May 2006 18:06, Thomas Womack wrote: > I'm using valgrind-3.0.1.SVN as shipped with SuSE Linux 10, on an AMD64 > box. > > My code maps several hundred very large images into memory - a total of > about fifteen gigabytes. > > Running without valgrind, it works without trouble; with valgrind, the > seventh and subsequent mmaps fail. > > These are read-only mmaps, so the question of definedness probably > oughtn't to apply; is there any way to tell valgrind not to care about > the huge mappings? > > > Thomas Womack, Global Phasing Ltd. > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Thomas W. <tw...@gl...> - 2006-05-17 17:06:35
|
I'm using valgrind-3.0.1.SVN as shipped with SuSE Linux 10, on an AMD64 box. My code maps several hundred very large images into memory - a total of about fifteen gigabytes. Running without valgrind, it works without trouble; with valgrind, the seventh and subsequent mmaps fail. These are read-only mmaps, so the question of definedness probably oughtn't to apply; is there any way to tell valgrind not to care about the huge mappings? Thomas Womack, Global Phasing Ltd. |
|
From: Dennis L. <pla...@in...> - 2006-05-17 16:10:01
|
Yip it is Am Mittwoch, den 17.05.2006, 02:57 +0100 schrieb Julian Seward: > Ok, that's helpful. Will do. Is that a SuSE 10.0 -> 10.1 upgrade > you did? > > J |
|
From: Nicholas N. <nj...@cs...> - 2006-05-17 16:09:13
|
On Fri, 12 May 2006, Ashley Pittman wrote: >> Hmm, this leads me to ask can the diagnostic output also report where >> the data first came from to end up in the buffer ? A sort of tracking >> system for copied uninitialised data giving me a trail. Maybe even >> reporting trails that don't end up getting as far as a system call but >> thrown around internally. > > It's an idea that's been banded about but I'm fairly sure there isn't > one. Perhaps somebody will correct me here? We'd love to do it, but we don't know how without huge slow-downs. Nick |
|
From: Morten W. J. <mo...@ne...> - 2006-05-17 05:42:49
|
=2D-=20 Morten W. J=F8rgensen Newtec A/S St=E6rmoseg=E5rdsvej 18 5230 Odense M Denmark Tlf.: 66 15 84 44 |
|
From: Julian S. <js...@ac...> - 2006-05-17 01:57:45
|
Ok, that's helpful. Will do. Is that a SuSE 10.0 -> 10.1 upgrade you did? J On Monday 15 May 2006 22:22, Dennis Lubert wrote: > Hi, > > I recently upgraded my distro and my valgrind package build (which > rebuilds also the docs) failed, because of docbook stylesheets beeing in > version 1.69.1 not 1.69.0 which was hardcoded into the makefiles. Even > the path is hardcoded > as /usr/share/xml/docbook/stylesheet/nwalsh/1.69.0/manpages/docbook.xsl > so I would at least suggest to set it > to /usr/share/xml/docbook/stylesheet/nwalsh/current/manpages/docbook.xsl > since most distros I saw have this symlink set. > > greets > > Dennis > > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Tom H. <to...@co...> - 2006-05-16 14:07:44
|
In message <Pine.LNX.4.64.0605121115440.3645@betty>
Ricardo Reis <rr...@ae...> wrote:
> I'm trying to use callgrind to profile a fortran code. It was
> compiled with gfortran but when I run it, under callgrind, it exits
> before normal termination with the message
>
> "Profiling timer expired"
>
> I've looked in the list (one unanswered message) and the manual and
> faq (even googled about it) without success. Can someone shed some
> light on this? How can I increase the timer?
It means something sent SIGPROF to your process. It has nothing
to do with callgrind as that doesn't do profiling like that.
Are you sure you haven't built your program with gprof profiling
or something?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2006-05-16 12:49:37
|
In message <446...@ra...>
Andy Howell <And...@ra...> wrote:
> I checked out the latest from SVN, but was not able build. It fails with:
>
> gcc -Wno-long-long -Wdeclaration-after-statement -o
> valgrind-listener -m64 -fomit-frame-pointer -O -g -Wmissing-prototypes
> -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes
> -Wmissing-declarations valgrind_listener-valgrind-listener.o
> mpicc -g -O -fno-omit-frame-pointer -Wall -fpic -shared \
> -I../include \
> -m64 \
> -o libmpiwrap.so libmpiwrap.c
> /usr/bin/ld: /usr/lib64/libmpi.a(laminit.o): relocation R_X86_64_32S
> against `lam_mpi_comm_world' can not be used when making a shared
> object; recompile with -fPIC
> /usr/lib64/libmpi.a: could not read symbols: Bad value
>
> I tried changes the -fpic to -fPIC in auxprogs/Makefile.in and
> Makefile.am, but no luck.
It's libmpi.a that needs to be recompiled with -fPIC not callgrind.
The problem is that it is trying to link a static library into a
shared object and you can't do that on amd64 (unless you happen to
have compiled the code in the static library as PIC code for some
weird reason).
On x86 you shouldn't really do it but you can get away with it because
the dynamic linker will do the necessary relocations when the
resulting shared object is loaded. The amd64 dynamic linker doesn't
have that kludge so the linker stops you creating an object that
would require it.
So what you really need is a libmpi.so with PIC code in it ;-)
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-05-16 11:56:39
|
This is a FAQ, although I can't find it on any of our documentation. Most likely explanation is that V isn't handling uninitialised memory in the way you expect. See here for details http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.machine The short story is that whilst it's true that callocing the buffer gives you a defined buffer, it's what happens after calloc and before the write that matters. Hence: char* p = calloc(...) p[1] = .. some uninitialised value .. write(.., p, ..) will get you the same complaint. Usually, the uninitialised junk in the buffer is as a result of doing assignments to struct-typed lvalues in the buffer. The uninitialised stuff is padding bytes in the struct(s). > Is it possible to directly manipulate the A and V bits of memcheck from > within the program by linking with some sort of valgrind stub library > which could communicate with valgrind at runtime. Naturally. It doesn't even require a stub library. See http://www.valgrind.org/docs/manual/manual-core.html#manual-core.clientreq and http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.clientreqs (you need to read both; read the first URL first). J |
|
From: Dennis L. <pla...@in...> - 2006-05-15 21:22:13
|
Hi, I recently upgraded my distro and my valgrind package build (which rebuilds also the docs) failed, because of docbook stylesheets beeing in version 1.69.1 not 1.69.0 which was hardcoded into the makefiles. Even the path is hardcoded as /usr/share/xml/docbook/stylesheet/nwalsh/1.69.0/manpages/docbook.xsl so I would at least suggest to set it to /usr/share/xml/docbook/stylesheet/nwalsh/current/manpages/docbook.xsl since most distros I saw have this symlink set. greets Dennis |
|
From: Dennis L. <pla...@in...> - 2006-05-15 16:33:46
|
Am Montag, den 15.05.2006, 10:22 +0200 schrieb Christian Keil: > Andy, > > > The code in question is for a reference counted chunk of memory. Its > > created in one thread and freed in another. Its protected by a mutex, > > which is why I pretty sure I'm not freeing it twice. While I have the > > mutex, I free and then NULL out the pointer. Even it did get called > > twice, the pointer would be NULL, so I would not get a double-free. > > I'm not sure if this could be related to your findings, but the last > sentence rings me a bell. I had a similar issue once and it turned out > that with compiler optimization enabled the check for a null pointer in > delete seemed to vanish. I had to explicitly check for null before > calling delete in order to avoid the double free. Unfortunately I don't > recall the exact circumstances right now, but it might be worth a try. Code like: if( ptr != NULL) delete ptr; ptr = NULL; is unnecessary. The following is well defined: delete ptr; ptr = 0; as delete on a nullpointer will have no effect. greets Dennis PS: You should maybe check the backtrace it gives, where the ptr was deleted the first time. And maybe add some debugoutput *after* setting the ptr to 0. Although its evil to throw from within a dtor, this could be one of the reasons the 0 assign never was reached. |
|
From: Christian K. <chr...@tu...> - 2006-05-15 08:23:21
|
Andy, > The code in question is for a reference counted chunk of memory. Its > created in one thread and freed in another. Its protected by a mutex, > which is why I pretty sure I'm not freeing it twice. While I have the > mutex, I free and then NULL out the pointer. Even it did get called > twice, the pointer would be NULL, so I would not get a double-free. I'm not sure if this could be related to your findings, but the last sentence rings me a bell. I had a similar issue once and it turned out that with compiler optimization enabled the check for a null pointer in delete seemed to vanish. I had to explicitly check for null before calling delete in order to avoid the double free. Unfortunately I don't recall the exact circumstances right now, but it might be worth a try. Cheers, Christian -- Christian Keil /"\ Institute for Reliable Computing \ / ASCII Ribbon Campaign Hamburg University of Technology X against HTML email & vCards mail:c....@tu... / \ |
|
From: prashantha a.s <pra...@ya...> - 2006-05-15 05:44:24
|
Hi, We just started using valgrind to test our exe for memory leak, and got an assertion failure, following are the details attached regarding the environment. There was a similar issue mentioned in FAQ.txt of valgrind, but here its not the same probably, since the entire execution environment differs. Please let us know if there is any solution or workaround for this. Details: Valgrind version: 3.1.1 Valgrind log file: ==25764== Memcheck, a memory error detector. ==25764== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==25764== Using LibVEX rev 1575, a library for dynamic binary translation. ==25764== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==25764== Using valgrind-3.1.1, a dynamic binary instrumentation framework. ==25764== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==25764== For more details, rerun with: -v ==25764== ==25764== My PID = 25764, parent PID = 25001. Prog and args are: ==25764== ./DataCollector ==25764== ==25764== Warning: set address range perms: large range 114298880, a 0, v 0 valgrind: m_debuginfo/symtab.c:511 (vgModuleLocal_addCfiSI): Assertion 'cfisi->len > 0 && cfisi->len < 2000000' failed. ==25764== at 0xB000E7CD: report_and_quit (m_libcassert.c:122) ==25764== by 0xB000E955: vgPlain_assert_fail (m_libcassert.c:185) ==25764== by 0xB0025848: vgModuleLocal_addCfiSI (symtab.c:552) ==25764== by 0xB0047446: run_CF_instructions (dwarf.c:2157) ==25764== by 0xB0047C44: vgModuleLocal_read_callframe_info_dwarf2 (dwarf.c:2503) ==25764== by 0xB002824B: read_lib_symbols (symtab.c:1718) ==25764== by 0xB00283DD: vgPlain_read_seg_symbols (symtab.c:1790) ==25764== by 0xB0025227: vgPlain_di_notify_mmap (symtab.c:199) ==25764== by 0xB002ED7E: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:1873) ==25764== by 0xB004286F: vgSysWrap_x86_linux_sys_mmap2_before (syswrap-x86-linux.c:1308) ==25764== by 0xB00386FB: vgPlain_client_syscall (syswrap-main.c:658) ==25764== by 0xB002B9F3: handle_syscall (scheduler.c:623) ==25764== by 0xB002BCA4: vgPlain_scheduler (scheduler.c:726) ==25764== by 0xB0039830: thread_wrapper (syswrap-linux.c:86) ==25764== by 0xB00398EC: run_a_thread_NORETURN (syswrap-linux.c:119) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==25764== at 0x4010C03: mmap (mmap.S:56) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. DataCollector --> 13MB Total Memory available: top - 13:50:59 up 37 min, 3 users, load average: 5.93, 6.52, 6.90 Tasks: 315 total, 4 running, 306 sleeping, 0 stopped, 5 zombie Cpu(s): 2.3% us, 93.1% sy, 3.3% ni, 0.0% id, 0.0% wa, 0.3% hi, 1.0% si Mem: 3091024k total, 2359740k used, 731284k free, 60296k buffers Swap: 0k total, 0k used, 0k free, 1700156k cached PS: Our exe is linked with a stripped library of size 1.2GB exe is running on MontaVista CarrierGrade Linux Linux sb1-1 2.6.10_mvlcge40_sit-omm01_V1.1.1 #1 SMP Tue Feb 21 11:30:42 CET 2006 i686 unknown Regards, Prashantha.AS __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: T. S. N. <tse...@ya...> - 2006-05-13 06:47:42
|
Dear Team,
Kindly reply me for my queries which I have sent in
the last mail, I am waiting for it.
With reference to previous mail, please check why the
stack allocation is not captured by the valgrind. Are
there any changes I have to do in valgrind for it.
Kindly let me ASAP, its very urgent.
Thanking you,
T.Senthil Nathan
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com |
|
From: Julian S. <js...@ac...> - 2006-05-12 22:46:26
|
You're absolutely 110% sure you don't have any race conditions or threading bugs associated with this memory? > Maybe its my problem. Not sure. Anything else I can try? Run it on V with the tools (--tool=...) none, lackey, cachegrind, callgrind and memcheck, and see which of those get the double-free problem and which don't. When you say it runs ok with memcheck, you mean memcheck reports no errors, or merely that it doesn't crash? J |
|
From: Julian S. <js...@ac...> - 2006-05-12 21:12:17
|
Christian I believe this is 'femms' and I also believe it's already fixed in the 3.2 line (svn trunk). Can you test it? J On Sunday 16 April 2006 18:49, Christian Parpart wrote: > Hi all, > > When valgrindizing my little app which is using the xvid lib > generated the above unhandled instruction bytes message. > > I guess this is something about AMD64 and the cpu set features > the xvid lib wanna use. > > Regards, > Christian Parpart. |
|
From: Andy H. <And...@ra...> - 2006-05-12 21:05:43
|
Julian Seward wrote: >> I tried changes the -fpic to -fPIC in auxprogs/Makefile.in and >> Makefile.am, but no luck. > > Known problem. Re-run configure with --with-mpicc=some_bogus_mpicc_name > so as to inhibit the compilation of libmpiwrap.so. > Got the SVN ( today ) version running. I'm still seeing the double-free problem. Checking the vgcore, it is in my app where I'm doing a free. Its odd that it runs by itself ok, and under valgrind memcheck. The code in question is for a reference counted chunk of memory. Its created in one thread and freed in another. Its protected by a mutex, which is why I pretty sure I'm not freeing it twice. While I have the mutex, I free and then NULL out the pointer. Even it did get called twice, the pointer would be NULL, so I would not get a double-free. Maybe its my problem. Not sure. Anything else I can try? |
|
From: Julian S. <js...@ac...> - 2006-05-12 19:44:08
|
> I tried changes the -fpic to -fPIC in auxprogs/Makefile.in and > Makefile.am, but no luck. Known problem. Re-run configure with --with-mpicc=some_bogus_mpicc_name so as to inhibit the compilation of libmpiwrap.so. J |
|
From: Andy H. <And...@ra...> - 2006-05-12 17:59:38
|
Josef Weidendorfer wrote:
> On Friday 12 May 2006 06:16, Andy Howell wrote:
>> Hello,
>>
>> I'm having a problem with callgrind on AMD64. My app cores with:
>>
>> ** glibc detected *** double free or corruption (out) 0X0000000588e010 ***
>>
>> I'm 99% sure that I'm not doing a double free where it cores.
>
> memcheck is running this code without errors on AMD64?
> Can you check out the SVN version of VG (which includes callgrind)?
>
> Hmmm... I would love to run memcheck on callgrind. Perhaps something
> is not 64bit clean.
>
Josef,
I tried "valgrind callgrind myapp" but it didn't come up with anything.
I checked out the latest from SVN, but was not able build. It fails with:
gcc -Wno-long-long -Wdeclaration-after-statement -o valgrind-listener
-m64 -fomit-frame-pointer -O -g -Wmissing-prototypes -Winline -Wall
-Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations
valgrind_listener-valgrind-listener.o
mpicc -g -O -fno-omit-frame-pointer -Wall -fpic -shared \
-I../include \
-m64 \
-o libmpiwrap.so libmpiwrap.c
/usr/bin/ld: /usr/lib64/libmpi.a(laminit.o): relocation R_X86_64_32S
against `lam_mpi_comm_world' can not be used when making a shared
object; recompile with -fPIC
/usr/lib64/libmpi.a: could not read symbols: Bad value
I tried changes the -fpic to -fPIC in auxprogs/Makefile.in and
Makefile.am, but no luck.
|
|
From: Paul P. <ppl...@gm...> - 2006-05-12 13:22:02
|
Howard Chu wrote: > Reporting the trail might get pretty annoying. But it would probably > be good to note the first read of an uninitialized memory location, > instead of just the first time it affects a decision. This has been discussed before. See this message and thread: http://sourceforge.net/mailarchive/message.php?msg_id=12007505 |
|
From: Howard C. <hy...@sy...> - 2006-05-12 10:51:13
|
Ashley Pittman wrote: > On Fri, 2006-05-12 at 10:47 +0100, Darryl Miles wrote: > >> Ashley Pittman wrote: >> >>> On Fri, 2006-05-12 at 07:10 +0100, Darryl Miles wrote: >>> >>> As your error is only 27 bytes into 16k and I doubt you are sending 16 >>> of blank data! it's likely that what you copied into the buffer was >>> itself uninitialised. >>> >> Ah. I did read something about this somewhere (in the docs) but the >> penny has not hit home that what I am seeing is the result of valgrind >> able to track where uninitialised data can end up. >> > > Exactly. > > >> Hmm, this leads me to ask can the diagnostic output also report where >> the data first came from to end up in the buffer ? A sort of tracking >> system for copied uninitialised data giving me a trail. Maybe even >> reporting trails that don't end up getting as far as a system call but >> thrown around internally. >> > > It's an idea that's been banded about but I'm fairly sure there isn't > one. Perhaps somebody will correct me here? > Reporting the trail might get pretty annoying. But it would probably be good to note the first read of an uninitialized memory location, instead of just the first time it affects a decision. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ |
|
From: Ricardo R. <rr...@ae...> - 2006-05-12 10:19:08
|
Hi I'm trying to use callgrind to profile a fortran code. It was compiled with gfortran but when I run it, under callgrind, it exits before normal termination with the message "Profiling timer expired" I've looked in the list (one unanswered message) and the manual and faq (even googled about it) without success. Can someone shed some light on this? How can I increase the timer? many thanks, Ricardo Reis "Non Serviam" n.p.: http://radio.ist.utl.pt n.r.: http://atumtenorio.blogspot.com <- Send with Pine Linux/Unix/Win/Mac OS-> |
|
From: Ashley P. <as...@qu...> - 2006-05-12 10:00:05
|
On Fri, 2006-05-12 at 10:47 +0100, Darryl Miles wrote: > Ashley Pittman wrote: > > On Fri, 2006-05-12 at 07:10 +0100, Darryl Miles wrote: > > > As your error is only 27 bytes into 16k and I doubt you are sending 16 > > of blank data! it's likely that what you copied into the buffer was > > itself uninitialised. > > Ah. I did read something about this somewhere (in the docs) but the > penny has not hit home that what I am seeing is the result of valgrind > able to track where uninitialised data can end up. Exactly. > Hmm, this leads me to ask can the diagnostic output also report where > the data first came from to end up in the buffer ? A sort of tracking > system for copied uninitialised data giving me a trail. Maybe even > reporting trails that don't end up getting as far as a system call but > thrown around internally. It's an idea that's been banded about but I'm fairly sure there isn't one. Perhaps somebody will correct me here? > <snip> > Anyway food for another topic maybe. I think the thing here is to use suppressions where needed but try to ensure that error reports get properly looked at so they are understood. Performance isn't the only reason to leave the code as it is in places. I can't see the need for suppressions going away any time soon. As you say, another topic entirely. Ashley, |
|
From: Darryl M. <dar...@ne...> - 2006-05-12 09:47:55
|
Ashley Pittman wrote: > On Fri, 2006-05-12 at 07:10 +0100, Darryl Miles wrote: > As your error is only 27 bytes into 16k and I doubt you are sending 16 > of blank data! it's likely that what you copied into the buffer was > itself uninitialised. Ah. I did read something about this somewhere (in the docs) but the penny has not hit home that what I am seeing is the result of valgrind able to track where uninitialised data can end up. Then ultimately report it being read with a kernel call. Hmm, this leads me to ask can the diagnostic output also report where the data first came from to end up in the buffer ? A sort of tracking system for copied uninitialised data giving me a trail. Maybe even reporting trails that don't end up getting as far as a system call but thrown around internally. > Have a look in <prefix>/valgrind/memcheck.h, in particular at the > VALGRIND_MAKE_READABLE() and VALGRIND_MAKE_NOACCESS() macros. These are > a little heavy handed though as they work on both the V and A bits at > the same time, I know there was talk of macros that only work on the V > bits without affecting the A bits but it's not finished yet. SVN code > has more macros of this nature if your serious about it... > > That said I'm not 100% sure what you are trying to do here, most, > *almost all* people get by without needing to manipulate the bits > directly, are you sure you are tackling the problem in the right way? Maybe I don't, maybe I still have Checker GCC ways of thinking about the problem of memory checking / bound checking. I have found some info in the documentation from your clue, so I shall play a lot more and maybe even investigate the problems I have found in X11/Xlib and Mozilla. Another difference to GCC Cherker: Some other stuff online I read a few comments that the glibc maintainer isn't too cool with addressing issues that aren't really bugs but STFU patches. While I agree their goal is to provide maximum runtime performance on as many platforms as possible there must be some workable happy medium. Is there any active project to deal with that situation at source, i.e. some form of agreed cooperation of both parties needs. A mechanism to be able to mark symbols/offsets, sizes and initialisation value in a table which is stored in glibc itself but is never used or executed under normal operating conditions. Maybe adding an ELF section is good enough for this. Then we just teach valgrind to look and initialise from the table as necessary. You could even teach the ld.so loader to do the same thing if a magic envvar is set. My current understanding of the workaround is to suppress these messages, which doesn't seem like the same thing as implementing the initialization at runtime. Anyway food for another topic maybe. Thanks for your info, a great help. Darryl L. Miles |